The scripts will be run from the MDs environment so the scripts need to be overridden there. Yes, the -f option should probably be used.

As for the {,.lmce-update}: the {A,B} substitutes a value of A for the first argument and substitutes the value of B for the second argument. So sometext{A,B} expands to: sometextA sometextB.

J.

I figured that part out... I guess I just don't understand where lmce-update is coming from... and how it is available to both directories... I thought that was why I was creating the TEMP environment, and why I was just moving them about to and from there.

I really appreciate your help.

I see now that it creates /dir/file.lmce-update and then transfers it back.

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.

Dear All I´m very happy to see people interested on this topic, I really wish I could understand Linux more to help, I just dropped the idea but you guys are amazing , for me you are all talking in another language but I'm starting to learn little by little.

Keep up the good work, I wish I could bring the beers for moral support but I guess it will be a little bit difficult.

Dear All I´m very happy to see people interested on this topic, I really wish I could understand Linux more to help, I just dropped the idea but you guys are amazing , for me you are all talking in another language but I'm starting to learn little by little.

Keep up the good work, I wish I could bring the beers for moral support but I guess it will be a little bit difficult.

chears!

T

The best help would be to test it. Of course it is doing upgrade work, which can break things, and in an experimental way, which can break things... if you wanted to test, you might make a clonezilla backup to an external drive.

To test a script, just go download it (bottom of page of link, choose original format) on your core. Find it (typically in /root/Desktop if you use firefox in LMCE) and cd into the directory in a shell. Then do the following

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.

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.

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.

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.

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.

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.

Yes. I have to do something much more substantial to prevent this from occurring. I am intending now to use the General_Info_Plugin to show progress in pending tasks, and I need to lock certain tasks like reboots, and work out a scheme to prevent MD booting while this process happens.

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.

The problem I was trying to overcome by using the date, was in which people did an upgrade, and it did not produce the desired results, and they ran it again, it would hose the good backup. The worst thing to happen from the backup not being found, over the midnight hour, would be that a second backup would occur. This also protects the original sources.list from being overwritten... of course that could happen a different way.

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.

Yes... I thought I fixed that... and I am also moving those on the core because I believe something in them affects the MDs... but I was confused on this issue. I will figure out exactly what they do and what I need to do. Thank you very much.

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.

I tend to use cat to avoid confirmation issues. That just overwrites the file.

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.

I had a weirdo nVidia folder so I did for good measure... I went back and forth on cp vs mv. I am not a big fan of duplication. I will change it.

umount /usr/pluto/diskless/$moonDir/usr/pluto/deb-cachewould do that.It is so incredibly helpful to have fresh eyes reading giving feedback.

The latest script has a cheap global alert up to remind not to interfere with the process. I actually built a ridiculous graphic progress meter for it... but didn't bother including it because I need to do it the right way.