<jonesv[m]>
Does anybody here have opinions about it? I have some experience with Yocto, and I wonder if that could be an interesting project. My guess would be that it should be setup to run exclusively Sandstorm (somehow using AppArmor/SELinux maybe?) and that it should have an update mechanism as described. Also I would need to read about secure boot.
mnutt has joined #sandstorm
<jonesv[m]>
Sounds like it shouldn't be two big (i.e. it could be an interesting side-project), but I wonder if I completely miss/underestimate some very important parts of it.
<jonesv[m]>
s/two big/too big
<isd>
I'd never heard of Yocto before. Thoughts:
<isd>
- I'm not sure AppArmor/SELinux is really necessary; sandstorm self-sandboxes anyway, and the idea is that yeah, this would be dedicated to run sandstorm, so there's not really anything else on the system to be compromised anyway
<isd>
- The goal here is to make it so folks not already comfortable setting up linux sand administering a linux server can set up sandstorm without having to learn that first. This means in addition to just getting an install image that has linux + sandstorm on it, we'd also need to build out integration with the Sandstorm web ui, and rig up auto-updating for the distro itself (sandstorm already does this for sandstorm)
<isd>
I haven't looked, but the IoT focus of Yocto has me worrying that they may not have that kind of update story.
<isd>
I do think it's a substantially project, but if you want to start exploring the design space that's where to get started.
<isd>
The other thing: before I'd really want to strongly promote the sandstorm distro, I'd want us to get to a place where we've filled in the few gaps that Sandstorm has where using the cli becomes necessary -- there's a hazard in making it easy for folks to install something without it actually being easy enough to use, and folks often don't come back after an experience like that. That doesn't mean we can't work on the distro in parallel though.
<isd>
tbh, putting the distro together and trying to use it might be the best way to shake out those issues.
<jonesv[m]>
Yeah, honestly that just sounds like a fun playground, it's fine if all it brings is a few lessons learned 👍️
<jonesv[m]>
About the update: I imagine something like a simple daemon that would check for update artifacts on a remote server. The distro would have some certificate to authenticate the server/check the signed artifacts. When an update artifact is available, it would download it, and somehow let Sandstorm know that a new update is available and requires a reboot. I guess that daemon should also expose an interface for Sandstorm to "check for updates"
<jonesv[m]>
(because the web UI would probably show a button for the user to do that).
<jonesv[m]>
Am I being overly naive, or does it make some sense?
<isd>
broadly; we could probably re-use some of the update code for sandstorm itself. I think the main bit that's new is managing machine reboots and integration with the UI.
<jonesv[m]>
Could you point me to the update code for sandstorm?
<ocdtrekkie>
I think there's an interesting possibility in cannibalizing/integrating Cockpit to provide OS integration into the Sandstorm UI.
<isd>
jonesv: it's in src/sandstorm/run-bundle.c++
<jonesv[m]>
Jacob Weisz: Cockpit being the sandstorm update mechanism?
<ocdtrekkie>
There would be security risks in exposing Cockpit as it stands now to the Internet, but I imagine a concept where Sandstorm could add it's authentication around access to it.
<ocdtrekkie>
Yep
<ocdtrekkie>
I think if we can borrow parts of it, it may save us having to maintain our own code to integrate with a bunch of Linux system features only tangentially related to Sandstorm.
<jonesv[m]>
I was thinking about leveraging Mender (A/B scheme) or OSTree (that would be my preferred one), and run the updates from a daemon that would expose a Cap'n Proto interface for Sandstorm to use. Could that be an interesting approach?
<jonesv[m]>
(part of the motivation being that I'd like to play with OSTree, too)
<jonesv[m]>
The Cap'n Proto interface being something simple, maybe like CheckUpdates, FetchUpdate, Update, Rollback
<isd>
That was closer to my thinking
<ocdtrekkie>
I mean, anything using Cap'n Proto sounds more Sandstorm-y too. ;) Within reasonable security intentions, I think the design choices of a Sandstorm distro probably lies with whoever is actually going to do the work. Right now nobody is doing it.
<ocdtrekkie>
I also find a lot of selfhosting projects have something in that space, and we do not. I think it'd be a big help to adoption of Sandstorm.
<isd>
Yeah I try not to bikeshed as long as the thing I'm looking at is reasonable
<ocdtrekkie>
I would love to see a perhaps-initially-optional feature to add OS management capabilities to the Sandstorm admin UI though, I think that'd be a good gateway to testing a distro solution.
<ocdtrekkie>
In addition to updates, I see some areas Sandstorm really would benefit from being more aware of system limitations: We have often gotten weird bug reports which turn out to be insufficient RAM or being straight up out of storage, and there's no visibility of that in the Sandstorm UI at all.
<isd>
My thinking is that ShellCli in backend.capnp is your entry point here; a daemon running outside of sandstorm could use a new set of methods on that to communicate with sandstorm
<isd>
...if no such daemon is running, sandstorm behaves as it does now, but that can be used to inject requests for reboots, etc.
<isd>
...we should add some comments to that interface. Everything else is so nicely documented, but that was one kentonv added when getting the acme stuff going.
<isd>
You know what, I've had this thought before, I'm just going to do it now before I forget.
<isd>
Ack, I guess SandstormCoreFactory is actually the bootstrap interface on that socket.
<jonesv[m]>
Ok, I'll look into `backend.capnp`. But first I need to read about secure boot :)
<jonesv[m]>
Jacob Weisz: I get your point about OS management, but I think I'll leave it aside for now. Feels like secure boot + update + daemon with capnp API is a nice thing to explore already!
<ocdtrekkie>
Yeah, just planting the thoughts on where it could grow.
<jonesv[m]>
You mentioned competing projects that have some kind of distro. Do you have names for them, that I could check? I guess maybe NextCloud?
<ocdtrekkie>
NextCloud I think has a box, PiBox/KubeSail is a thing. Helm was out there once... HASS is home automation specific but has a thing.
<jonesv[m]>
Got it
<ocdtrekkie>
Of course many of them are ARM/RasPi based.
<ocdtrekkie>
I guess some of these kinda have distros, some of them sell a box with software on it, probably some odd things in between. I don't think as an open source project we'll hit "can sell you a box at cost with Sandstorm on it", but it'd be nice if the code was there that someone could do that.
<ocdtrekkie>
The Home Assistant/HASS example is probably one of the most interesting, HASS is the distro they built solely to run HA, and then they sell preloaded boxes with it now too.
<jonesv[m]>
Sounds good
<jonesv[m]>
> I don't think as an open source project we'll hit "can sell you a box at cost with Sandstorm on it"
<jonesv[m]>
Why is that? Logistics you mean? If you can put it on something like an RPi, then you have your box, right?
<ocdtrekkie>
Well, Sandstorm would need an x86 box, but I mean, yeah, a distro someone would presumably still have to install on hardware themselves.
<jonesv[m]>
Oh, Sandstorm does not support ARM?
<jonesv[m]>
(out of curiosity, not that I care much)
<jonesv[m]>
And then, completely unrelated: is there a grain meant for Android synchronization? For instance on my /e/OS (some LineageOS-based Android), they have a NextCloud integration (that I still need to try). It's meant to replace the Google Drive backups, I would say. Is there something along that lines with Sandstorm? I haven't seen anything in the app store, but maybe I missed it.
<isd>
Nothing specific jumps to mind
<ocdtrekkie>
Davros still should support Nextcloud's protocol I think.
<ocdtrekkie>
It was broken for a long time but someone fixed it, so I think things which are designed to backup data to Nextcloud should backup to Davros successfully as well.
<jonesv[m]>
Oh, that would be neat, it would "just work" with my /e/OS in that case! I'll look into it.
<ocdtrekkie>
I know there's been some recent contributions to Davros too that haven't gotten into a release yet, so if you test it and find a bug there maybe we can get it addressed. But back in the day I could use the ownCloud app on my Android to auto-backup photos to Davros.
mnutt has quit [Remote host closed the connection]
mnutt has joined #sandstorm
<jonesv[m]>
I'm reading the Sandstorm docs and seeing: "App servers are aggressively killed off as soon as the user closes the browser tab, then restarted when the user returns later.". How does that work for a long-running app, say I guess Davros?
<jonesv[m]>
Or for instance, could Sandstorm be used to host an IRC bouncer or a Matrix server?
<isd>
If there's an active network connection it won't be shut down
<isd>
I did port znc at some point.
<isd>
Also apps can request a "wake lock" to keep them alive.
<isd>
(in the case of davros it doesn't actually matter -- the app will be started back up when an http request comes in.
mnutt_ has quit [Remote host closed the connection]
mnutt_ has joined #sandstorm
mnutt has quit [Remote host closed the connection]
mnutt has joined #sandstorm
<jonesv[m]>
Right, for davros it doesn't, but say for an IRC bouncer
<jonesv[m]>
Do you mean an active connection to the outside, or an active connection from an app client?