kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev
<isd> I remember deliberately testing this on the oldest kernel version supporting cgroups2 and it working. Apparently I'm going insane.
<JacobWeisz[m]> I updated my server to 18.04.5 and it still doesn't work. 18.04.5 is supposed to have the 5.4 kernel?
<JacobWeisz[m]> My uname -a still says 4.15 or whatever?
<isd> Yeah, they don't tend to do feature upgrades within an LTS release.
<JacobWeisz[m]> It's confusing because it says 18.04.5 is kernel 5.4 but my 18.04.5 box doesn't say 5.4...
<JacobWeisz[m]> If Sandstorm is the only thing on this machine, is it reasonably safe to yolo 'do-release-upgrade'?
<JacobWeisz[m]> Because while your patch might repair the status quo, I kinda want those atomic backups anyways...
<isd> Should be fine; Sandstorm will be nicely self-contained in /opt/sandstorm
<isd> I really don't like the idea of just silently falling back to something with a buglike that. and longer term, when we start adding resource limits to keep grains from DoSing sandstorm, I will be similarly uncofmortable with just silentnly falling back to what we do now if the relevant kernel functionality is unavailable.
<isd> I don't think it's acceptable to just push a patch that breaks stuff, but we should spend some time thinking about how to grapple with that.
<isd> It's a shame we don't control the kernel like we do everything in the sandstorm bundle...
<JacobWeisz[m]> As I said on that one issue, perhaps we should put a notice in the admin panel encouraging people to upgrade to a newer kernel, and why?
<isd> Yeah, maybe. We could also add a warning to the installer.
<JacobWeisz[m]> Use the less ideal current solution where necessary to keep everything working as it does today, but subtly nudge people to move to a platform that supports the best we can offer.
<JacobWeisz[m]> Also, doesn't your other PR enable backups of offline grains effectively?
<isd> It does.
<isd> Hm, maybe if cgroup.freeze isn't available, we could just kill the grain as a fallback?
<JacobWeisz[m]> That's my thought. Maybe once introducing backup from grain list, let users on the topbar know backup of a running grain isn't allowed. And then have the grain list button kill grains first if freeze isn't supported.
<JacobWeisz[m]> I think having to run a grain to back it up is a severely dumb idea anyways, I say only allow it if we can do it safely.
<JacobWeisz[m]> Otherwise insist on grain list backups of offline grains.
<isd> I wish it were easier to test this stuff.
<JacobWeisz[m]> Oh, apparently I can install the newer kernels on LTS with a single apt-get command. 18.04.x has a "HWE" kernel option which is newer than the one that shipped with the original release.
<JacobWeisz[m]> I guess I should test this PR though before I go moving away from this kernel.
<isd> +1
<JacobWeisz[m]> Of course the link from the Checks tab doesn't actually work if you wget it.
<JacobWeisz[m]> Tested. It works.
<JacobWeisz[m]> Thankfully I already had a stupid SMB share working for backups so I downloaded the file on Windows.
<JacobWeisz[m]> So... if I change my update channel back to dev, will it update itself back to 0.273?
<isd> Yes.
<isd> You can also do 'sandstorm update dev' to have it update right now
<isd> (But you will still need to flip the config back to turn auto-updates back on)
<JacobWeisz[m]> Okay cool. Not that there's much wrong with leaving this PR on it for now, I just wanted to make sure I didn't forget to turn updates back on.
<JacobWeisz[m]> I didn't burn my server to the ground, so I will be more willing to test PRs this way in the future!
<isd> Actually, I'm not sure off-hand how it does version comparison
<JacobWeisz[m]> Now we just need kentonv to do a bugfix release for it.
<isd> But I think it will just pull in whatever the latest thing is on that channel, regardless of what you're running.
<JacobWeisz[m]> The dev build is 0, so I'm kinda hoping it assumes a release build is always newer?
<isd> probably.
<isd> Anyway, as I said you can also force the one update
<JacobWeisz[m]> Kenton's comments with CI suggest the updater is sane.
<JacobWeisz[m]> "By default the build will be set to 0, which Sandstorm's updater logic understands to be a dev build."
<isd> makes sense.
<JacobWeisz[m]> I will report back tomorrow if my server didn't resume normal builds.
TMM_ is now known as TMM
sy has joined #sandstorm
<sy> Hi! I need to write some docs for my org but we cannot decide between Laverna, Permanote and Paperwork, any suggestions what would be most useful?
<JacobWeisz[m]> What kind of docs are you making, sy? I like using DokuWiki as my personal documentation storage. For single documents, SandMD has been popular amongst the community.
<sy> JacobWeisz[m]: usually collections of documents for each tool, at least one level of organisation or a good search feature
<sy> DokuWiki looks good but I'm not sure about the editor
<JacobWeisz[m]> My caution would be to probably prefer apps which have some manner of recent maintenance or that we are likely to maintain. Like DokuWiki is actively maintained on Sandstorm.
<JacobWeisz[m]> Looking for something more WYSIWYG, I suppose?
<sy> MD would be perfect but in general a large viewing space to compose would be a benefit
<sy> like ghost and laverna
<sy> I suppose if I go so simple that it doesn't need updates that's a plus
<JacobWeisz[m]> One of the reasons I like DokuWiki is that the data is all flat-file. It's txt documents, so it's really easy to go in and pull data out if you need to from the grain backup.
<JacobWeisz[m]> I kinda wonder if the width of the editing interface is something you could tweak with a theme.
<JacobWeisz[m]> In theory, Sandstorm apps work pretty well even unmaintained, but the client-side loading fix is eventually going to be rocky for some of the unmaintained apps.
<JacobWeisz[m]> And of course, ideally if your team has feature requests or bug reports, I'd hope we can resolve those. :)
<sy> I guess when you're not sure it's best to go with the one that's the most easily changeable right
<sy> currently at work so can't easily test - do you know if it has collaborative abilities?
<JacobWeisz[m]> I kinda doubt it'll let multiple people edit a page live, that's sadly not a super common ability.
<JacobWeisz[m]> SandMD is collaborative, but I think it's single document per grain.
<sy> alright, I'll just use that and copy paste if I need collaboration ^^
<TimMc> Do I understand correctly that folks are currently working on a way to back up grains as a first-class feature in Sandstorm?
<TimMc> That would be fantastic, because ZFS is being an utter pain to work with.
<TimMc> Would the backups end up in a directory that I could atomically back up without having a snapshotting filesystem?
<JacobWeisz[m]> TimMc: isd is working in that direction.
<JacobWeisz[m]> IMHO, a fully integrated solution has a lot of ability to backup atomically because it can potentially shut down grains or back them up when they are shut down, whereas an outside solution isn't going to be aware of those things.
<JacobWeisz[m]> (Coming from the Windows world, I am still somewhat shocked not having a filesystem that snapshots is like... still a thing, mind you.)
<TimMc> Ah, I didn't know NTFS had that!
<TimMc> And yeah, it's really weird.
<isd> TimMc: Kinda taking the long-way-around with it, building some underlying tech that I'll probably expose in a stand-alone app that I'll start using for my own personal backups, and the idea being at some point we'll integrate the notion of driver grains and have sandstorm use it to store grain backups.
<isd> So it might be a while before we reach that end goal.
<isd> But yes, I am working on that.
<TimMc> Awesome. :-)
<JacobWeisz[m]> Ian has been working on some standardization with other backup solutions too, so hopefully we won't really be on our own exactly either.
<isd> Mostly just the splitting algorihtm, so might be of use when transferring data between two hypothetical backup tools that use the same spec?
<isd> The WIP spec is here:
<isd> And there's a GitHub org with various things: https://github.com/hashsplit
<isd> ...and folks implementing in Rust & Go (In addition to the Haskell stuff I'm working on)
<isd> This is also pushing some bits of haskell-capnp forward.
<isd> The main driver of all this is here: https://github.com/zenhack/ocap-merkledag
<JacobWeisz[m]> The big perk the way I see it, is if someone wants to work with Sandstorm backup data while not using Sandstorm, this is possibly a reasonable thing.
JacobWeisz[m] has quit [*.net *.split]
JacobWeisz[m] has joined #sandstorm
<kentonv> so should I build a new release with the cgroups fix?
<JacobWeisz[m]> kentonv: Yes
<JacobWeisz[m]> It restores the old behavior for a group of kernels which do not support the new behavior, and I tested it on my box.
<kentonv> ok, it's on the way
<JacobWeisz[m]> \o/ Now I am gonna move my box to a newer kernel so I can enjoy the new behavior anyways.