1:52 p.m.
I have made the following proposal for Google Summer of Code 2009 and posted it here on
the advice of Sankarshan Mukhopadhyay and Toshio Kuratomi for Peer Review.
Title: Automated System Recovery Tool
Student: Jeff Chandler
Abstract:
An automated system
recovery tool is needed for average users to feel secure using Fedora
as their primary Desktop OS. Fedora and other Gnu/Linux distros can be
rendered useless to the non-technical user by a failed binary driver
install (Video cards, wireless ethernet, etc.) or malicious programs.
For these users, there is no easy fix available. I propose a daemon
that tracks changes in the filesystem and can restore installed
programs and configuration to a previous point in time when the system
was working. Suspect programs would be cordoned off into a secure area.
A tie-in with smolt could be used to identify troublesome packages.
Content:
== Why do you want to work with our team? ==
I have used Fedora for 3 years and it is my favorite Gnu/Linux
Distribution. I would love to contribute to its development and make
it more accessible to mainstream users.
== Do you have any past involvement with our team or another open source project? ==
Please desribe your past open source experience.
My occupation involves installing and servicing Digital Video
Recorders for CCTV systems. These systems run Proprietary Software on
top of Gnu/Linux and frequently are poorly coded and have multiple
problems, plus nearly useless technical support from the manufactures.
Open Source Tools have been invaluble in troubleshooting and solving
the many issues I've faced with these systems. Even without the source
code of the proprietary software, I've been able to use open source
tools to preserve my companies good reputation with our customers.
Objdump and bvi have been particularly useful.
== Why should we choose you over other applicants? ==
At 37, I am much older than most students, but I have a lot of
experience in real world applications and the benefits of things that
"just work" and are easily recoverable.
== Proposal Description ==
Please describe your proposal in detail. Include:
* An overview of your proposal
A daemon that would track changes in the filesystem, installed
packages and versions, and configuration information. In the event of
a system failure or corruption (by a binary driver, user error,...)the
Automated System Recovery Tool could be used to restore the system to a
previous time. The daemon would also keep a copy of non-standard (not
available from the standard repos) packages for reinstall. The tool
could also be used as a System Backup utility to store all system and
user data in a compressed file in case of a total system or hardware
failure. A tie-in with smolt could be used to make users aware of
system crashing drivers for specific harware.
* The need you believe it fulfils
To penetrate mainstream desktops, Fedora needs to be more
accessible to the average computer user. One of the many hurdles to
this goal, is earning the confidence of the user. The user must feel
that any corruption of the system or mistake by the user has an easy
and effective solution for recovery with no or minimal loss of data.
* Any relevant experience you have
Many, many hours spent recovering from failed attempts to use
binary drivers for video adapters and wireless ethernet. For the last
4 years I've been engaged in independent study of C and Python
programming, Bash Scripting, and Linux administration.
* How you intend to implement your proposal
Create scripts to check the file tree and logs for new packages,
configuration changes and new user data. Create a baseline file
monthly, that can be used independently to perform restores, add change
files weekly or daily (selected by user) to be used in conjunction with
baseline file. Create Graphical tool for user setup and use of
Automated System Recovery Tool. Use combination of custom scripts and
yum to implement actual recovery system.
* A rough timeline for your progress
1.) Implement daemon to record system changes to a recovery file. 1 week
2.) Implement Graphical Interface for user interaction. 1 week
3.) Implement System Recovery backend 2 weeks
4.) Test and Debug. 2 weeks
* Any other details you feel we should consider
4:56 p.m.
On Wed, 2009-04-01 at 11:52 -0700, J C wrote:
Title: Automated System Recovery Tool
Student: Jeff Chandler
Abstract:
An automated system
recovery tool is needed for average users to feel secure using Fedora
as their primary Desktop OS. Fedora and other Gnu/Linux distros can be
rendered useless to the non-technical user by a failed binary driver
install (Video cards, wireless ethernet, etc.) or malicious programs.
For these users, there is no easy fix available.
How are you going to run your daemon (let alone the UI to command it)
if arbitrary parts of the system are broken?
I propose a daemon
that tracks changes in the filesystem and can restore installed
programs and configuration to a previous point in time when the system
was working. Suspect programs would be cordoned off into a secure
area.
So do you only protect packages, and not all files on disk?
If more than packages how do you tell which ones (reverting a config.
file might require reverting a package, and it's much more likely the
other way around).
If only package data, then you should really be monitoring/using the
"yum history" database (not written, yet, but planned for this year).
[...]
A daemon that would track changes in the filesystem, installed
packages and versions, and configuration information. In the event of
a system failure or corruption (by a binary driver, user error,...)the
Automated System Recovery Tool could be used to restore the system to
a
previous time. The daemon would also keep a copy of non-standard (not
available from the standard repos) packages for reinstall. The tool
could also be used as a System Backup utility to store all system and
user data in a compressed file in case of a total system or hardware
failure.
A backup utility like this would be a huge undertaking, on it's own, I
think (even if you ignored the packaging aspect).
[...]
* A rough timeline for your progress
1.) Implement daemon to record system changes to a recovery file. 1
week
2.) Implement Graphical Interface for user interaction. 1 week
3.) Implement System Recovery backend 2 weeks
4.) Test and Debug. 2 weeks
* Any other details you feel we should consider
IMO the above is "optimistic".
--
James Antill <james(a)fedoraproject.org>
Fedora
8:22 p.m.
________________________________
From: James Antill <james(a)fedoraproject.org>
To: Development discussions related to Fedora <fedora-devel-list(a)redhat.com>
Sent: Wednesday, April 1, 2009 5:56:06 PM
Subject: Re: Automated System Recovery Tool
On Wed, 2009-04-01 at 11:52 -0700, J C wrote:
>
> Title: Automated System Recovery Tool
> Student: Jeff Chandler
> Abstract:
> An automated system
> recovery tool is needed for average users to feel secure using Fedora
> as their primary Desktop OS. Fedora and other Gnu/Linux distros can be
> rendered useless to the non-technical user by a failed binary driver
> install (Video cards, wireless ethernet, etc.) or malicious programs.
> For these users, there is no easy fix available.
How are you going to run your daemon (let alone the UI to command it)
if arbitrary parts of the system are broken?
The daemon should already be installed and running as part of the initial installation, at
the users discretion, of course. It will create a series of backup files at specified
intervals, daily, weekly, or monthly. The GUI recovery tool will have three options: Run
from the actual installation, a recovery partition ( essentially a bare bones copy of the
installation cd) or the installation cd itself. It will have to use the backup file from
the local hard drive, unless the user had the foresight to save a backup to another media.
I suppose a reminder could be a part of the system, to copy backups to some other system
or media.
> I propose a daemon
> that tracks changes in the filesystem and can restore installed
> programs and configuration to a previous point in time when the system
> was working. Suspect programs would be cordoned off into a secure
> area.
So do you only protect packages, and not all files on disk?
If more than packages how do you tell which ones (reverting a config.
file might require reverting a package, and it's much more likely the
other way around).
If only package data, then you should really be monitoring/using the
"yum history" database (not written, yet, but planned for this year).
The user will select to revert packages and config data only or all data. In the former
case, packages and config files will be restored to tjhe state they existed at a previous
time ( selected by the user among the available backups) so versions and configuration
data should be in sync. If the latter option is chosen, the same action occurs, but any
user data that has changed (based on file access times) since the backup, will be moved to
a "vault" where it can be recovered by the user with assistance from the
recovery tool.
[...]
> A daemon that would track changes in the filesystem,
installed
> packages and versions, and configuration information. In the event of
> a system failure or corruption (by a binary driver, user error,...)the
> Automated System Recovery Tool could be used to restore the system to
> a
> previous time. The daemon would also keep a copy of non-standard (not
> available from the standard repos) packages for reinstall. The tool
> could also be used as a System Backup utility to store all system and
> user data in a compressed file in case of a total system or hardware
> failure.
A backup utility like this would be a huge undertaking, on it's
own, I
think (even if you ignored the packaging aspect).
[...]
> * A rough timeline for your progress
> 1.) Implement daemon to record system changes to a recovery file. 1
> week
> 2.) Implement Graphical Interface for user interaction. 1 week
> 3.) Implement System Recovery backend 2 weeks
> 4.) Test and Debug. 2 weeks
> * Any other details you feel we should consider
IMO the above is "optimistic".
I realize the timeline seems optimistic, for some reason I was thinking the actual coding
period was only 6 weeks, but now I see it is actually 12 weeks, plus an additional 4 weeks
between the announcement of acceptance and begin of coding. I've update my proposal to
reflect the actual time period.
--
Thank You for your comments,
Jeff Chandler
powerswitch1972(a)yahoo.com
5:09 p.m.
2009/4/1 J C <powerswitch1972(a)yahoo.com>:
1.) Implement daemon to record system changes to a recovery file. 1
week
Would it be appropriate to think of this effort as an extension of etckeeper?
http://joey.kitenet.net/code/etckeeper/
-jef
4:45 a.m.
Just in case you don't know about it, https://fedorahosted.org/firstaidkit/
could be interesting for you, though the approach is different I think.
5504
days inactive
5505
days old
4 comments
4 participants
participants (4)
-
J C -
James Antill -
Jef Spaleta -
Radek Vykydal