System Restore

[seventhc]

Well, instead of writing destructive code, maybe put a file in there with some suggestions of what to bork or how you want it borked etc. This way you aren't writing malicious code, but still getting to test it in the environment that would be more geared towards the end result.

[LaRoza]

Well, instead of writing destructive code, maybe put a file in there with some suggestions of what to bork or how you want it borked etc. This way you aren't writing malicious code, but still getting to test it in the environment that would be more geared towards the end result.

The function of the script is simple and easy to verify. The UI is what concerns me.

The biggest unknown to me is how to restore, as I never had to do what it is going to do. It is a simple procedure, but one I'd rather test. It wouldn't be good if /etc/fstab was restored, but everything else in /etc was deleted in the process.

[xlinuks]

Well, for instance if we take /etc/fstab:
I guess for now it would be good if we just overwrite the file with the backed-up one.
But later, I think, there should be some code that would actually check what volumes the user has on his computer and based on this info create on the fly a new fstab file to replace the old one. The reason I'm saying this is cause I lost a partition using GParted (it unmounted it but I couldn't find a way to mount it back, a bug in GParted I guess), so after reboot Gutsy threw me to a root console to "repair the filesystem". That's why IMO a simple restore of the backed up file wouldn't be a complete feature. The (your) app should scan (correctly) for volumes (such as /dev/sda3, /dev/sda4 ), at least starting at some future release..
It should not include (into the /etc/fstab) the volumes that are removable drives - which IMO is pretty hard to implement if one doesn't have experience in such domains (thus I mean programmers like me)
Just my 0.02$

[LaRoza]

Well, for instance if we take /etc/fstab:
I guess for now it would be good if we just overwrite the file with the backed-up one.
But later, I think, there should be some code that would actually check what volumes the user has on his computer and based on this info create on the fly a new fstab file to replace the old one. The reason I'm saying this is cause I lost a partition using GParted (it unmounted it but I couldn't find a way to mount it back, a bug in GParted I guess), so after reboot Gutsy threw me to a root console to "repair the filesystem". That's why IMO a simple restore of the backed up file wouldn't be a complete feature. The (your) app should scan (correctly) for volumes (such as /dev/sda3, /dev/sda4 ), at least starting at some future release..
It should not include (into the /etc/fstab) the volumes that are removable drives - which IMO is pretty hard to implement if one doesn't have experience in such domains (thus I mean programmers like me)
Just my 0.02$

I think you have to understand the program design for this.

It restores to a previous state, it doesn't fix anything.

It is solely meant to undo system changes, not fix or diagnose them.

[Cappy]

The biggest problem with it is that if someone messes up the system config they probably aren't going to be able to use this program if it is a self run shell script, hard-to-find application, or not automatically backing things up already.

My opinion is that either
A) Upon encountering a problem with one of the backed up files this script replaces the broken file. This is done in the background. The user is informed that the settings were replaced because they were corrupt.
B) Upon encountering a problem the user can boot up an ubuntu CD. The program can be run off the Live CD and you can choose to restore the state of the newest modified files on the hard drive (or any media obviously). This would require the script making it onto the Ubuntu CD or the Ubuntu repos.

These are both assuming worst case where a normal user cannot boot into X .. possibly due to broken X or driver settings. Possibly a kernel upgrade problem. These are probably the kind of situations people would benefit from a backup system the most.

Making the "restore" function work easily when things are broken is going to be a big challenge.

[LaRoza]

The biggest problem with it is that if someone messes up the system config they probably aren't going to be able to use this program anyway.

My opinion is that either
A) Upon encountering a problem with one of the backed up files this script replaces the broken file. This is done in the background. The user is informed that the settings were replaced because they were corrupt.
B) Upon encountering a problem the user can boot up an ubuntu CD. The program can be run off the Live CD and you can choose to restore the state of the newest modified files on the hard drive (or any media obviously). This would require the script making it onto the Ubuntu CD or the Ubuntu repos.

Making the "restore" function work easily when things are broken is going to be the biggest challenge.

Actually, this agonized me. The problem:

* I can only assume the system has a home directory
* I must store the restore points somewhere
* If something hoses the home, the restore points will be gone to.

It is perfectly functional from any media, including Live CD's, so far. If nothing else, it creates a backup of the settings which any user can manually put back.

Now that you bring it up, it is a good thing to consider when impementing the restore feature (which isn't done yet), because I have to take into account this script might be running from a different user/system/cd.

Because I am restricting it to standard Python modules (now my decision to use Tkinter makes sense), and it is not complex and runs fine from anywhere on my system.

Of course, if someone had made restore points, they don't need to use my program to restore from them. If they are savvy enough to run a program off a live cd to fix a system, they probably understand that it is simple to untar the restore points.

My main focus is on new users:

* I just tried to install <weird package> and now everything looks funny
* I tried editing my fstab (what is it anyway?) and now I can't see my Windows partition
* I tried a new video card, and I don't like it, and when I removed it, everything looks big

and other configuration issues that are easily solved by making backups and knowing what you are doing.

[cprofitt]

I am making a system restore program, not a backup program.

I am sticking with settings for the system, not applications (except GNOME). Tarring up the home directory is not my goal (simpler, but not my goal).

I think I am going to stick with what I listed and perhaps the network settings. Thanks for the suggestions.

Remember that you can take an inventory of installed packages with Synaptic that can be imported in Synaptic to re-install them as well... not sure if that is something you would want, but it would be appreciated by many I think.

[LaRoza]

Remember that you can take an inventory of installed packages with Synaptic that can be imported in Synaptic to re-install them as well... not sure if that is something you would want, but it would be appreciated by many I think.

Could you explain that? I know one can get all the packages installed with a command (forget it though) is there a a file to parse?

Once I get this to work (GUI issues and restore not finished now), I will be very open to adding to it and probably have a little page for it somewhere.

[mssever]

I have to mention that I haven't read the entire thread. I hope I'm not being redundant.

I have a couple thoughts about this program. First, I think that it's a great idea. Back when I used Windows, System Restore was a lifesaver. (Personally, I find Windows easier to hose accidentally than Linux, but maybe that's just me.)

I would like the ability to manually specify files to be included in the restore. Some use cases:

1. On my server, I have Apache's configuration heavily customized, so losing that customization would be more painful than losing fstab. Of course, this is approaching the goals of a backup program.
2. Suppose I want to experiment with some major reconfiguration of my machine that is too extensive to rely on my ability to remember everything I changed. The ability to simply add that stuff to my restore data set would give me the freedom to explore without worrying about losing important configuration if I mess up.

Another thing: Have you considered making a text-based version, as well? I imagine that one common use case would be someone who hosed X. They'd likely end up booting into single-user mode, and wouldn't be able to access a GUI program. But they'd benefit from curses. Presumably, if you try to create a Tkinter window when you're not running X, you'll get an exception. You could then catch that exception and launch the curses interface. (I guess you're dead set on Tkinter. I'm pretty much dead set against it because it's terribly ugly and its menus are broken. I'd much prefer GTK. But, it's your program, not mine.)

Finally, will this program automatically create restore points every so often like the Windows program does?

[seventhc]

IMO Tkinter will work on everyones machine, once you use anything different, then it might no longer work out of the box. Of course I may be completely wrong as I am new to python and programming in general.
I do however think it's a good idea for it to default to a text based version if tkinter can't start due to problems with x.
As far as looks are concerned I don't think that will concern anyone using it as most likely they will be thinking about a hosed system and wanting it back.