Casync – A tool for distributing file system images(0pointer.net) |
Casync – A tool for distributing file system images(0pointer.net) |
[1] https://github.com/advancedtelematic/meta-updater
(Full disclosure: I work for Advanced Telematic, the creators and maintainers of the meta-updater Yocto layer.)
I think OSTree is great — but for embedded devices that are installed in the wild, humm, uh, I don't think so? I am pretty sure there are better options than that.
We had looked into OSTree before but given the use case of embedded devices in the wild, we concluded it was too risky as OSTree relies on the filesystem to protect from power failures. And rollback was not built-in and is quite challenging to implement reliably.
By the way, both buzhash and SHA-256 are kinda poor choices for a new system, especially one that targets servers.
Maybe it wasn't geared for CDN delivery during restores but otherwise I've been impressed by borg so far (haven't deployed it in production, only played with it locally though).
https://github.com/borgbackup/borg
This is a description of the internal design:
As far as I can tell, the advantages compared to Borgbackup seem to be:
* casync offers control over which FS metadata is included
* casync, the server, exposes chunks over HTTP
* casync, the library, is written in C so is more easily used by systems software.
I'm betting we'll see machinectl integration. Excellent!
casync does not act as a server. Its on-disk representation and client behaviour is designed in such a way that the server need only serve static files. This makes deployment easy.
systemd-nspawn integration is what I was thinking about too, so yeah! Nice work.
casync also has fs composition, a multitude of recorded file attributes, automatic reflinking/hardlinking, uid/gid shifting, and so much more.
tl;dr: rclone is for files, casync is for entire filesystems/deployments.
And it's not just cell towers or wind power turbines: pretty much any device which is around people not unconditionally trusted needs to be protected against such offline modifications. In fact, if people today build cars, TVs, surveillance cameras or anything else like that and do not deploy dm-verity in some form to make sure the devices cannot be modified offline without noticing are just participating in turning IoT into Internet of Shit.
Wouldn't it be easier to simply dunk the whole device in some epoxy preventing access to the hardware with some anti-tamper deadman switch?
If you have devices like cable box or water meter, the real owners do not want you to modify the device. That's where mechanisms like dm-verity step in.
I will always think physical access is game over whatever 'rocket science' or re-invented old principles people come up with software wise and i'm not sure, but hardware probably too but software is easier to mangle.
And indeed yes, security is layers, layers that make it more difficult, and having many options for layers to choose from that is great.
Also didn't hear about OStree before really, reading up on both for some future project.
I'm more interested to hear about buzhash, though.
(OTOH if your storage is faster than ~200-300 MB/s (buzhash and a hash, naively combined) then there is likely no issue using higher degrees of I/O concurrency, so you can work around these problems).
For IoT devices, hashes that work on 32-bit words, like SHA-256, actually make more sense and will be faster, so BLAKE2s would work well.
What I'd like to hear from the above commenter is about a faster replacement for buzhash, which I'm also interested in.