Automated System Recovery Tool

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