The Git Autoinstaller
+TODO NOW:
+
+- XXX: Upgrades don't pull updated tags, breaking git describe --tags!
+ Fix this for the future, and figure out how to make everyone else happy!
+- XXX: Some installs are throwing spurious errors; investigate
+- XXX: Prolly would be nice to have some information about how many installs actually succeeded
+- If you try to do an install on scripts w/o sql, it will sign you up but fail to write
+ the sql.cnf file. This sucks.
+
+- wizard install wordpress should ask for password. One problem with this is that
+ Wordpress will still send mail with the wrong username and password, so Wordpress
+ will need to be patched to not do that. Alternatively we can initally set the admin
+ email to a null address and then fix it manually.
+- --raw parameter for install which means an arbitrary commit can be installed
+- Parse output HTML for class="error" and give those errors back to the user (done),
+ then boot them back into configure so they can enter in something different
+- Get rid of our custom sizing code and use dialog's built-in sizing (i.e. width=0, height=0).
+ Maybe our sizing code is superior, maybe not.
+
+- Replace gaierror with a more descriptive name (this is a DNS error)
+
+- Pre-emptively check if daemon/scripts-security-upd
+ is not on scripts-security-upd list (/mit/moira/bin/blanche)
+
+- Web application for installing autoinstalls has a hard problem
+ with credentials (as well as installations that are not conducted
+ on an Athena machine.) We have some crazy ideas involving a signed
+ Java applet that uses jsch to SSH into athena.dialup and perform
+ operations.
+
+- Pay back code debt
+ - Tidy up common code in callAsUser and drop_priviledges in shell
+ - Summary script should be more machine friendly, and should not
+ output summary charts when I increase specificity
+ - Summary script should do something intelligent when distinguishing
+ between old-style and new-style installs
+ - Report code in wizard/command/__init__.py is ugly as sin. Also,
+ the Report object should operate at a higher level of abstraction
+ so we don't have to manually increment fails. (in fact, that should
+ probably be called something different). The by-percent errors should
+ also be automated.
+ - Move resolutions in mediawiki.py to a text file? (the parsing overhead
+ may not be worth it)
+ - If a process is C-ced, it can result in a upgrade that has
+ an updated filesystem but not updated database. Make this more
+ resilient
+ - PHP end of file allows omitted semicolon, can result in parse error
+ if merge resolutions aren't careful. `php -l` can be a quick stopgap
+
+- Other stuff
+ - Figure out why Sphinx sometimes fails to crossref :func: but wil
+ crossref :meth:, even though the dest is very clearly a function.
+ Example: :func:`wizard.app.php.re_var`
+ - The TODO extension for Sphinx doesn't properly force a full-rebuild
+ - Code annotation!
+ - Make single user mass-migrate work when not logged in as root. The
+ primary difficulty is making the parallel-find information easily
+ accessible to individual users: perhaps we can do a single-user
+ parallel-find on the fly.
+ - Don't use the scripts heuristics unless we're on scripts with the
+ AFS patch. Check with `fs sysname`
+ - Make 'wizard summary' generate nice pretty graphs of installs by date
+ (more histograms, will need to check actual .scripts-version files.)
+ - It should be able to handle installs like Django where there's a component
+ that gets installed in web_scripts and another directory that gets installed
+ in Scripts.
+ - ACLs is a starting point for sending mail to users, but it has
+ several failure modes:
+ - Old maintainers who don't care who are still on the ACL
+ - Private AFS groups that aren't mailing lists and that we
+ can't get to
+ A question is whether or not sending mail actually helps us:
+ many users will probably have to come back to us for help; many
+ other users won't care.
+
+PULLING OUT CONFIGURATION FILES IN AN AUTOMATED MANNER
+
+advancedpoll: Template file to fill out
+django: Noodles of template files
+gallery2: Multistage install process
+joomla: Template file
+mediawiki: One-step install process
+phpbb: Multistage install process
+phpical: Template file
+trac: NFC
+turbogears: NFC
+wordpress: Multistage install process
+
+COMMIT MESSAGE FIELDS:
+
+Installed-by: username@hostname
+Pre-commit-by: Real Name <username@mit.edu>
+Upgraded-by: Real Name <username@mit.edu>
+Migrated-by: Real Name <username@mit.edu>
+Wizard-revision: abcdef1234567890
+Wizard-args: /wizard/bin/wizard foo bar baz
+
+GIT COMMIT FIELDS:
+
+Committer: Real Name <username@mit.edu>
+Author: lockername locker <lockername@scripts.mit.edu>
+
+NOTES:
+
+- It is not required nor expected for update scripts to exist for all
+ intervening versions that were present pre-migration; only for it
+ to work on the most recent migration.
+
+- Currently all repositories are initialized with --shared, which
+ means they have basically ~no space footprint. However, it
+ also means that /mit/scripts/wizard/srv MUST NOT lose revs after
+ deployment.
+
+OVERALL PLAN:
+
* Some parts of the infrastructure will not be touched, although I plan
on documenting them. Specifically, we will be keeping:
- parallel-find.pl, and the resulting
-/mit/scripts/sec-tools/store/scriptslist
-
- - The current install scripts will be kept in place, sans changes
- necessary to make them use Git install of copying the script over.
- Porting these scripts to Python and making them modular would be
- nice, but is priority. For the long term, seeing this scripts
- be packaged with rest of our code would be optimal.
+ /mit/scripts/.htaccess/scripts/sec-tools/store/scriptslist
* The new procedure for generating an update is as follows:
+ (check out the mass-migration instructions for something in this spirit,
+ although uglier in some ways; A indicates the step /should/ be automated)
- 1. Have the Git repository and working copy for the project on hand.
+ 0. ssh into not-backward, temporarily give the daemon.scripts-security-upd
+ bits by blanching it on system:scripts-security-upd, and run parallel-find.pl
- 2. Download the new tarball
+ 1. [ see doc/upgrade.rst ]
- 3. Extract the tarball over the working copy
+ [ENTER HERE FROM CREATING A NEW REPO]
- 4. Check if there are any special update procedures, and update the
- .scripts/update shell script as necessary (this means that any
- application specific update logic will be kept with the actual
- source code. The language of this update script will vary
- depending on context.)
+ 9. Push all of your changes in a public place, and encourage others
+ to test, using --srv-path and a full path.
- X. Check for empty directories and add stub files as necessary
- (use preserve-empty-dir)
+[ XXX: doc/deploy.rst ]
+ GET APPROVAL BEFORE PROCEEDING ANY FURTHER;
+ THIS IS PUSHING THE CHANGES TO THE PUBLIC
- 5. Commit your changes, and tag as v1.2.3-scripts
+ NOTE: The following commands are to be run on not-backward.mit.edu.
+ You'll need to add daemon.scripts-security-upd to
+ scripts-security-upd to get bits to do this. Make sure you remove
+ these bits when you're done.
- 6. Run the "dry-run script", which uses Git commands to check how many
+ 10. Run `wizard research appname`
+ which uses Git commands to check how many
working copies apply the change cleanly, and writes out a logfile
- with the working copies that don't apply cleanly.
-
- 7. Run the "limited run" script, which applies the update to our
- test-bed, and lets us check the basic functionality of the update.
-
- 8. Run the "deploy" script, which applies the update to all working
- copies possible, and sends mail to users to whom the working copy
- did not apply cleanly. (It also frobs .scripts/version)
-
- Note: The last three scripts will need to be implemented, with an
- eye towards speed.
-
-* How to migrate an old autoinstaller to the new autoinstaller
-
- - Find the oldest tarball/patch set for the application that still
- is in use and upgradable.
-
- - Untar, apply patch, place in a directory and git init
-
- - Create the .scripts directory and populate it with the interesting
- information (see below)
-
+ with the working copies that don't apply cleanly. It also tells
+ us about "corrupt" working copies, i.e. working copies that
+ have over a certain threshold of changes.
+
+ 11. Run `wizard mass-upgrade appname`, which applies the update to all working
+ copies possible.
+
+ 12. Run parallel-find.pl to update our inventory
+
+[ XXX: doc/upgrade.rst ]
+* For mass importing into the repository, there are a few extra things:
+
+ * When mass producing updates, if the patch has changed you will have to
+ do a special procedure for your merge:
+
+ git checkout pristine
+ # NOTE: Now, the tricky part (this is different from a real update)
+ git symbolic-ref HEAD refs/heads/master
+ # NOTE: Now, we think we're on the master branch, but we have
+ # pristine copy checked out
+ # NOTE: -p0 might need to be twiddled
+ patch -p0 < ../app-1.2.3/app-1.2.3.patch
+ git add .
+ # reconstitute .scripts directory
+ git checkout v1.2.2-scripts -- .scripts
+ git add .scripts
+ # NOTE: Fake the merge
+ git rev-parse pristine > .git/MERGE_HEAD
+
+ You could also just try your luck with a manual merge using the patch
+ as your guide.
+
+[ XXX: doc/layout.rst ]
* The repository for a given application will contain the following files:
- The actual application's files, as from the official tarball
- - A .scripts directory, which contains the following information:
-
- * .scripts/update shell script (with the +x bit set appropriately),
- which performs the commands necessary to update a script. This can
- be in any language.
-
- * .scripts/version which contains the version last autoinstalled
- (as distinct from the actual version the script is) (This will
- be auto-generated and should not be versioned)
-
- * .scripts/real-version (+x) which checks the source code to find the
- actual version of the application
-
- * .scripts/.htaccess to prevent this directory from being accessed
- from the web.
-
- - Because there will be no .gitignore file, you *must not* run
- `git add .` on an actual running copy of the application.
- `git add -u .` will generally be safe.
-
-* The migration process shall be as such:
-
- 1. git init
-
- 2. git add remote origin /foo
-
- 3. whatever the merge frob is
-
- 4. git fetch origin
-
- 5. git reset
-
- 6. Setup .scripts/version (probably pipe the output of real-version)
-
-* We will not add special code to handle .htaccess; thus the kernel patch
- for allowing Apache access to .htaccess sent to scripts-team@mit.edu
- must be handled first.
-
-* The autoupgrade shall be the process of:
+ - A .scripts directory, with the intent of holding Scripts specific files
+ if they become necessary.
- git add -u .
- git commit -m 'automatically generated backup'
- git pull /mit/scripts/deploy/wordpress.git master
- if [ $? ne 0 ]; then git reset --hard; echo 'conflicts during upgrade'; fi
- ./.scripts/update
+ - .scripts/dsn, overriding database source name
-* Make install-statistics generate nice pretty graphs of installs by date
- (more histograms, will need to check actual .scripts-version files.)
scripts.mit.edu / wizard.git / blobdiff