0

I've got quite a head scratcher here. We have multiple Raspberry Pis on the field hundreds of kilometers apart. We need to be able to safe(ish)ly upgrade them remotely, as the price for local access can cost up to few hundred euros.

The raspis run rasbian, / is on SD-card mounted in RO to prevent corruption when power is cut (usually once/day). The SD cards are cloned from same base image, but contain manually installed packages and modified files that might differ between devices. The raspis all have a USB flash as a more corruption resistant RW-drive and a script to format it on boot in case the drive is corrupted. They call home via GPRS connection with varying reliability.

The requirements for the system are as follows:

  • Easy versioning of config files, scripts and binaries, at leasts /etc, /root and home preferably Git
  • Efficient up-/downgrade from any verion to other over GPRS -> transfer file deltas only
  • Possibility to automatically roll back recently applied patch, if connection is no longer working
  • Root file system cannot be in RW mode while downloading changes, the changes need to be stored locally before applying to /

The simple approach might be keeping a complete copy of the file system in a remote git repository, generate a diff file between commits, upload the patch to the field and apply it. However, at the the moment the files on different raspis are not identical. This means, at least when installing the system, the files would have to be synchronized through something similar to rsync -a.

The procedure should be along the lines of "save diff between / and ssh folder to a file on the USB stick, mount / RW, apply diff from file, mount / RO". Rsync does the diff-getting and applying simultaneously, so my first question becomes:

1 Does there exist something like rsync that can save the file deltas from local and remote and apply them later?

Also, I have never made a system like this and the drawt is "closest to legit I can come up with". There's a lot of moving parts here and I'm terrified that something I didn't think of beforehand will cause things to go horribly wrong. Rest of my questions are:

  1. Am I way off base here and is there actually a smarter/safe(r) way to do this?
  2. If not, what kind of best practices should I follow and what kind of things to be extremely careful with (to not brick the devices)?
  3. How do I handle things like installing new programs? Bypass packet manager, install in /opt?
  4. How to manage permissions/owners (root+1 user for application logic)? Just run everything as root and hope for the best?
Juho
  • 427
  • 2
  • 12
  • This is an interesting question so +1, but I think this is too broad in its current form to be succinctly answered. – Anshul Goyal Jun 09 '15 at 11:49

1 Answers1

1

Yes, this is a very broad question. This will not be a direct answer to your questions, but rather provide guidelines for your research.

One means to prevent file system corruption is use an overlay file system (e.g., AUFS, UnionFS) where the root file system is mounted read-only and a tmpfs (RAM based) or flash based read-write is mount "over" the read-only root. This requires your own init scripts including use of the pivot_root command. Since nothing critical is mounted RW, the system robustly handles power outages. The gist is before the pivot_root, the FS looks like

/      read-only root (typically flash)
/rw    tmpfs overlay
/aufs  AUFS union overlay of /rw over /

after the pivot_root

/      Union overlay (was /aufs
/flash read only root (was /)

Updates to the /flash file system are done by remounting it read-write, doing the update, and remounting read-only. For example,

mount -oremount,rw <flash-device> /flash
cp -p new-some-script /flash/etc/some-script
mount -oremount,ro <flash-device> /flash

You may or may not immediately see the change reflected in /etc depending upon what is in the tmpfs overlay.

You may find yourself making heavy use of the chroot command especially if you decide to use a package manager. A quick sample

mount -t proc none /flash/proc
mount -t sysfs none /flash/sys
mount -o bind /dev /flash/dev
mount -o bind /dev/pts /flash/dev/pts
mount -o bind /rw /flash/rw  # 
mount -oremount,rw <flash-device> /flash
chroot /flash
# do commands here to install packages, etc
exit # chroot environment
mount -oremount,ro <flash-device> /flash

Learn to use the patch command. There are binary patch commands How do I create binary patches?.

For super recovery when all goes wrong, you need hardware support with watchdog timers and the ability to do fail-safe boot from alternate (secondary) root file system.

Expect to spend significant amount of time and money if you want a bullet-proof product. There are no shortcuts.

Community
  • 1
  • 1
RTLinuxSW
  • 822
  • 5
  • 9