Now I need to incorporate the system backup function (I don't know if it is more than a sql dump) and exclude some directories from the tarring process... and then make a button under computing, which ideally spawns a monitor window, sort of like the web admin does for certain functions.
The backup/restore process is a little more tricky.
The database is updated as the core is upgraded... Subsequent MD updates may have minor updates/changes applied to the database. Restoring the database from a backup would mean that the database information will be out of sync with the installed packages on the core. So a database restore should only be performed if the CORE packages would be restored to their original state as well. This is probably best done, by the user, through a clonezilla image or other external backup system. Perhaps there is a way to store a list of the upgraded packages to restore them at the same time as a database restore... This seems like it'd be pretty flaky.
Restoring a 'live' MD (one that is running) that had been upgraded through SSH means that the MD in question cannot simply be 'restored' from the backup directly. The machine would have to be powered down for the /usr/pluto/diskless/XX directory to be removed and then un-tar'd. Tricky, especially if someone is using the MD in question at the time.
Restoring an MD that is not running (updated through chroot) is trivial. The directory can be removed and restored from the .tar archive. Unless the MD is booted partway through the update/restore process... This would present an issue.
I think there are some big issues that would need to be addressed before any kind of restore capability could be implemented.
Other notes:
Use a variable for the DATE in your script, otherwise it is possible for a user to start the script one day and have the initial tar-ing of the backup archive, or the upgrades, take long enough it rolls over to the next day. For instance, lets say I start the script at 11:55pm, it tars for 20 minutes, and upgrades for 20 minutes. Later in the script the backup archive and the backed-up sources.list files will not be found because the date has rolled over to the next day... Perhaps just don't use the date in the backup name, unless you see a need for it to be there.
mv /usr/pluto/diskless/$moonDir/usr/sbin/invoke-rc.d{,.lmce-update}
mv /usr/pluto/diskless/$moonDir/sbin/start-stop-daemon{,.lmce-update}
echo -en '#!/bin/bash\necho "WARNING: fake invoke-rc.d called"\n' > /usr/pluto/diskless/$moonDir/usr/sbin/invoke-rc.d
echo -en '#!/bin/bash\necho "WARNING: fake start-stop-daemon called"\n' > /usr/pluto/diskless/$moonDir/sbin/start-stop-daemon
chmod +x /usr/sbin/invoke-rc.d
chmod +x /sbin/start-stop-daemon
The first 4 lines, above, affect the desired scripts in the MDs directories. The 2 final 'chmod' lines unfortunately are affecting the files on the core, not the MDs where you just created the diversion scripts. Those two lines need to point to the /usr/pluto/diskless/XX/... structure so the appropriate files are affected.
rsh moon$moonDir apt-get update || /bin/true
rsh moon$moonDir apt-get -f -y upgrade
rsh moon$moonDir apt-get upgrade -f -y --force-yes
In this code the middle line should be 'apt-get upgrade -f -y install', rather than the two 'upgrade' commands.
cat /usr/pluto/diskless/$moonDir/etc/apt/sources.list-`date +%Y%m%d`.bak > /usr/pluto/diskless/$moonDir/etc/apt/sources.list
Are you using 'cat' here for a specific purpose? I would use 'mv' here rather than cat. Unless you see a need to maintain lots of chronological backup files. Again, perhaps drop the date portion and use another file extension (such as .lmce-update) or something else. This can be done with the 'mv' command and using {..}, like the backup of the scripts.
cp -ru /var/cache/apt/archives/* /usr/pluto/deb-cache
This line doesn't need the 'r' option. I would also alter this and 'mv' (move) the files rather than duplicating them and comsuming the extra HD space. The only files that need to be affected here are the '*.deb' files, you don't want to move any sub-directories from ../apt/archives/ to ../pluto/deb-cache/ -- just the .deb files.
dpkg-scanpackages /usr/pluto/deb-cache /dev/null | gzip -9c > /usr/pluto/deb-cache/Packages.gz
Although I havn't tested it, this line will not create the 'Packages' file, only the 'Packages.gz' file. I did this is a couple steps in the version I edited to ensure both files are created. I think the both files are required, but I am not certain.
The cleanup trap should probably umount the bound deb-cache folder for the chroot updated MDs.
Wow, lots to look at! Keep it up!
J.
