starred/xiosk

Fork 0

mirror of https://github.com/debloper/xiosk.git synced 2026-04-26 21:35:51 +03:00

[GH-ISSUE #37] Internet source of configured websites, or even all settings #34

New issue

Open

opened 2026-03-03 11:13:34 +03:00 by kerem · 6 comments

kerem commented

2026-03-03 11:13:34 +03:00

Owner

Originally created by @andiohn on GitHub (Oct 3, 2024).
Original GitHub issue: https://github.com/debloper/xiosk/issues/37

OOOOhhhhh. Good idea here. What if we could specify the websites to use and maybe some other small settings on our github? That way it could just read that on boot up, if it exists, it uses those! If it's not set, then show the default!

That would be a big step to make this really reliable because then overlay can be turned on all of the time. You run the setup, specify the settings URL to injest, then once it's done, you turn on the overlay protection! No more power outage issues (this killed at least 2 of my setups so far)

Originally created by @andiohn on GitHub (Oct 3, 2024). Original GitHub issue: https://github.com/debloper/xiosk/issues/37 OOOOhhhhh. Good idea here. What if we could specify the websites to use and maybe some other small settings on our github? That way it could just read that on boot up, if it exists, it uses those! If it's not set, then show the default! That would be a big step to make this really reliable because then overlay can be turned on all of the time. You run the setup, specify the settings URL to injest, then once it's done, you turn on the overlay protection! No more power outage issues (this killed at least 2 of my setups so far)

kerem added the

question

label

2026-03-03 11:13:34 +03:00

kerem commented

2026-03-03 11:13:34 +03:00

Author

Owner

@debloper commented on GitHub (Oct 7, 2024):

How would you describe the process to be during the setup? What would the steps be for the user to configure a remote source (github or otherwise; but please mention specifics, if relevant).

As it stands now, you can simply copy/backup the config.json file (commit it to a repo or push it to S3 bucket etc), and then on a new/broken setup, just drop it in to restore the configurations.

Does that not suffice?

@debloper commented on GitHub (Oct 7, 2024): How would you describe the process to be during the setup? What would the steps be for the user to configure a remote source (github or otherwise; but please mention specifics, if relevant). As it stands now, you can simply copy/backup the `config.json` file (commit it to a repo or push it to S3 bucket etc), and then on a new/broken setup, just drop it in to restore the configurations. Does that not suffice?

kerem commented

2026-03-03 11:13:34 +03:00

Author

Owner

@andiohn commented on GitHub (Oct 7, 2024):

I'm basically thinking of it this way because if it exists online, you can make the system disk read only and yet still update it. Just like you said, keep it in a repo but ask if you have a config you'd like to use in the setup script. If you say yes, you could fetch it on each boot up.

That way it would be almost impossible to mess up and it would also be able to be updated any time? It would fetch the new copy, then the next time it reboots, the overlay would be reset and it would fetch the new copy, so basically self-healing after reboot.

@andiohn commented on GitHub (Oct 7, 2024): I'm basically thinking of it this way because if it exists online, you can make the system disk read only and yet still update it. Just like you said, keep it in a repo but ask if you have a config you'd like to use in the setup script. If you say yes, you could fetch it on each boot up. That way it would be almost impossible to mess up and it would also be able to be updated any time? It would fetch the new copy, then the next time it reboots, the overlay would be reset and it would fetch the new copy, so basically self-healing after reboot.

kerem commented

2026-03-03 11:13:34 +03:00

Author

Owner

@debloper commented on GitHub (Oct 7, 2024):

If the media gets corrupted due to power-cut, it won't be just the config.json that gets corrupted. You'll need to flash it again. So, the second part of what you said:

It would fetch the new copy, then the next time it reboots, the overlay would be reset and it would fetch the new copy, so basically self-healing after reboot.

...that wouldn't really work.

So, if you're flashing/installing again anyway, it's actually no harder to just wget the config from a location, than feeding the installer a remote file location.

Also, expecting/halting for user-input during installation is kind of an antithesis of "handsfree" installation PiOSK thrives to be.

@debloper commented on GitHub (Oct 7, 2024): If the media gets corrupted due to power-cut, it won't be just the config.json that gets corrupted. You'll need to flash it again. So, the second part of what you said: > It would fetch the new copy, then the next time it reboots, the overlay would be reset and it would fetch the new copy, so basically self-healing after reboot. ...that wouldn't really work. So, if you're flashing/installing again anyway, it's actually no harder to just wget the config from a location, than feeding the installer a remote file location. Also, expecting/halting for user-input during installation is kind of an antithesis of "handsfree" installation PiOSK thrives to be.

kerem commented

2026-03-03 11:13:34 +03:00

Author

Owner

@andiohn commented on GitHub (Oct 7, 2024):

Basically, if it's read only it's unlikely to be corrupted, that's what I've experienced. I've already had to redo the install a couple times because of a poor quality usb stick :) lol. I'm just trying to think about how it can be more reliable and having the settings fed in from a link is a good idea, but I like your wget idea too.

@andiohn commented on GitHub (Oct 7, 2024): Basically, if it's read only it's unlikely to be corrupted, that's what I've experienced. I've already had to redo the install a couple times because of a poor quality usb stick :) lol. I'm just trying to think about how it can be more reliable and having the settings fed in from a link is a good idea, but I like your wget idea too.

kerem commented

2026-03-03 11:13:35 +03:00

Author

Owner

@debloper commented on GitHub (Oct 8, 2024):

it's read only it's unlikely to be corrupted

That's correct, but then it can't change the config as well (including the remote destination you want it to load from - cause I don't know what that destination is for you, so I can't bake it in PiOSK).

And if we have to apply overlay protection AFTER configuring the list of sites, then remote doesn't have any advantage over local (copy, paste a bit of text in a file or the file itself - in either case).

However, these two features can be dashboard update:

allow remote config: #37
toggle write protection: #36

@debloper commented on GitHub (Oct 8, 2024): > it's read only it's unlikely to be corrupted That's correct, but then it can't change the config as well (including the remote destination you want it to load from - cause I don't know what that destination is for you, so I can't bake it in PiOSK). And if we have to apply overlay protection AFTER configuring the list of sites, then remote doesn't have any advantage over local (copy, paste a bit of text in a file or the file itself - in either case). --- However, these two features can be dashboard update: - allow remote config: #37 - toggle write protection: #36

kerem commented

2026-03-03 11:13:35 +03:00

Author

Owner

@andiohn commented on GitHub (Oct 9, 2024):

Ok, so what I was thinking is if there is a flag set to try a remote config, wait until the web is up and pull the config down. The overlay will save that file in ram, then we can run browser.sh. If it fails to download, it can try again and then fail back to the loaded on (which could be 'localbackup.conf' or something).

Basically, I don't mind if it has to fetch everyday and 'fake overwrite' in the temporary overlay partition because when it boots up again, it'll get the new one. If you catch what I'm saying. That way the overlay will always be protected because it's read-only and it will still get a fresh config each night.

@andiohn commented on GitHub (Oct 9, 2024): Ok, so what I was thinking is if there is a flag set to try a remote config, wait until the web is up and pull the config down. The overlay will save that file in ram, then we can run browser.sh. If it fails to download, it can try again and then fail back to the loaded on (which could be 'localbackup.conf' or something). Basically, I don't mind if it has to fetch everyday and 'fake overwrite' in the temporary overlay partition because when it boots up again, it'll get the new one. If you catch what I'm saying. That way the overlay will always be protected because it's read-only and it will still get a fresh config each night.