TODO NOW:
-* Migrate and upgrade the lone mediawiki-1.5.6 install
-* Create the migration script
+- Better error message if daemon/scripts-security-upd
+ is not on scripts-security-upd list
+
+- Add repository flag so that we can specify an
+ arbitrary repository to migrate to
+- Fix retarded logging mechanism
+
+- The great initial deploy:
+ - Turn on mediawiki new autoinstaller
+ - Migrate all mediawiki installs
+
+- Testing:
+ - Need a scriptable autoinstaller, which means we rewrite
+ all of the autoinstall machinery. This doesn't need
+ to be able to create pre-wizard autoinstalls, since migration
+ is easy to test+revert
+
+- Build automation for generating config files; this automation
+ will be shared with the migrate script and the installer script
+ (migrate script needs to be able to pull out values from config
+ file, so will we; installer script needs to be able to run
+ the installer to generate config files, so will this)
+
+- Implement proper deploy log parsing; this basically means we
+ need to be able to introspect Git Log. Consider using git-python
+ for this.
+
+- This should all be automated:
+ - Wordpress needs to have .scripts dir in all -scripts versions
+ (also make .scripts/.htaccess)
+ - Wordpress needs to have a .scripts/update script written for
+ its latest version (do this after its migration)
+ - Wordpress needs to check for php.ini files (which it almost
+ certianly has) and commit messages
+ - Wordpress needs user config and php.ini links made
+
+- Summary script should be more machine friendly, and should not
+ output summary charts when I increase specificity
+- Summary script needs to be updated for new format
+- Check how many autoinstalls are missing w bits for
+ daemon.scripts (this would need pyafs)
+- Make scripts AFS patch advertise its existence so we can check for it
+
+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
+
+PHILOSOPHY ABOUT LOGGING
+
+Logging is most useful when performing a mass run. This
+includes things such as mass-migration as well as when running
+summary reports. An interesting property about mass-migration
+or mass-upgrade, however, is that if they fail, they are
+idempotent, so an individual case can be debugged simply running
+the single-install equivalent with --debug on. (This, indeed,
+may be easier to do than sifting through a logfile).
+
+It is a different story when you are running a summary report:
+you are primarily bound by your AFS cache and how quickly you can
+iterate through all of the autoinstalls. Checking if a file
+exists on a cold AFS cache may
+take several minutes to perform; on a hot cache the same report
+may take a mere 3 seconds. When you get to more computationally
+expensive calculations, however, even having a hot AFS cache
+is not enough to cut down your runtime.
+
+There are certain calculations that someone may want to be
+able to perform on manipulated data. As such, this data should
+be cached on disk, if the process for extracting this data takes
+a long time. Also, for usability sake, Wizard should generate
+the common case reports.
+
+Ensuring that machine parseable reports are made, and then making
+the machinery to reframe this data, increases complexity. Therefore,
+the recommendation is to assume that if you need to run iteratively,
+you'll have a hot AFS cache at your fingerprints, and if that's not
+fast enough, then cache the data.
+
+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:
+
+- A perfectly formed autoinstall with upgrade paths for all of
+ the intervening versions is not really feasible to implement.
+ As such, we want to migrate everything to -scripts, and then
+ generate a -scripts2 with the correct .scripts directory.
+ We will then nop update some installs, but this will prevent
+ us from having to migrate and update concurrently. Treat
+ a scripts2 upgrade from migration the same way you would treat
+ a botched scripts upgrade.
+ ADDENDUM: You MUST NOT migrate to a -scripts2 version; the
+ machinery can't actually handle this.
+
+- 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.
+
+- Full fledged logging options. Namely:
+ x all loggers (delay implementing this until we actually have debug stmts)
+ - default is WARNING
+ - debug => loglevel = DEBUG
+ x stdout logger
+ - default is WARNING (see below for exception)
+ - verbose => loglevel = INFO
+ x file logger (only allowed for serial processing)
+ - default is OFF
+ - log-file => loglevel = INFO
+ x database logger (necessary for parallel processing, not implemented)
+ - default is OFF
+ - log-db => loglevel = INFO
+
+- More on the database logger: it will be very simple with one
+ table named `logs` in SQLite, with columns: `job`, `level`,
+ `message`. Job identifies the subprocess/thread that emitted
+ the log, so things can be correlated together. We will then
+ have `wizard dump` which takes a database like this and dumps
+ it into a file logger type file. The database may also store
+ a queue like structure which can be used to coordinate jobs.
OVERALL 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)
- 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
+A 1. Have the Git repository and working copy for the project on hand.
- 3. Extract the tarball over the working copy (`cp -R a/. b` works well)
+A 2. Checkout the pristine branch
- 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.)
+A 3. Remove all files from the working copy. Use `wipe-working-dir`
- X. Check for empty directories and add stub files as necessary
- (use preserve-empty-dir)
+A 4. Download the new tarball
- 5. Commit your changes, and tag as v1.2.3-scripts
+A 5. Extract the tarball over the working copy (`cp -R a/. b` works well,
+ remember that the working copy is empty; this needs some intelligent
+ input)
- 6. Run the "dry-run script", 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.
+A 6. Check for empty directories and add stub files as necessary.
+ Use `preserve-empty-dir`
- 7. Run the "limited run" script, which applies the update to our
- test-bed, and lets us check the basic functionality of the update.
+A 7. Git add it all, and then commit as a new pristine version (v1.2.3)
- 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)
+A 8. Checkout the master branch
- Note: The last three scripts will need to be implemented, with an
- eye towards speed.
+ 9. [FOR EXISTING REPOSITORIES]
+ Merge the pristine branch in. Resolve any conflicts that our
+ patches have with new changes. Do NOT let Git auto-commit it
+ with --no-commit (otherwise, you want to git commit --amend
+ to keep our history clean
-* How to migrate an old autoinstaller to the new autoinstaller
+ [FOR NEW REPOSITORIES]
+ See if any patches are needed to make this run smoothly on
+ scripts.
- - Find the oldest tarball/patch set for the application that still
- is in use and upgradable.
+ [FOR NEW REPOSITORIES]
+A mkdir .scripts
+A echo "Deny from all" > .scripts/.htaccess
+ touch .scripts/update
+ chmod a+x .scripts/update
- - Untar, apply patch, place in a directory (unfurl) and git init
+ 10. Check if there are any special update procedures, and update/create 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.)
+
+ 11. Commit your changes, and tag as v1.2.3-scripts (or scripts2, if
+ you are amending an install without an upstream changes)
- - Commit this as the "pristine" version (branch "pristine")
+ NOTE: These steps should be run on a scripts server
- - Apply scripts patches
+ 12. Test the new update procedure using
+ `wizard upgrade --with=/path/to/repo /your/autoinstall` (this will
+ read out master as your "latest" version).
+ Use git commit --amend to fix any bugs (alternatively, squash them
+ together later).
- - Create the .scripts directory and populate it with the interesting
- information (see below)
+ 13. You can also do a "mass" version of this using:
+ `wizard -d testbed.txt massupgrade --with=/path/to/repo app`
+ You'll need perms for any testbed stuff you want. (not implemented)
- - Commit this as the "scripts" version (branch "master")
+ GET APPROVAL BEFORE PROCEEDING ANY FURTHER
-* How to update the autoinstaller repository
+ 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.
- - Checkout pristine branch
- - Delete contents of pristine branch (excluding .git, try rm -Rf * and remove stragglers)
- - Unfurl tarball
- - Commit as new pristine branch
- - Checkout scripts branch
- - Merge pristine branch
- - Fix as necessary
+ 14. 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. It also tells
+ us about "corrupt" working copies, i.e. working copies that
+ have over a certain threshold of changes.
+
+ 15. Run `wizard massupgrade appname`, which applies the update to all working
+ copies possible, and sends mail to users to whom the working copy
+ did not apply cleanly.
+
+ 16. Run parallel-find.pl to update our inventory
+
+* For mass importing into the repository, the steps are:
+ (this probably won't ever be automated, becuase there are fiddly bits)
+
+[TO SET IT UP]
+# let app-1.2.3 be the scripts folder originally in deploydev
+# let this folder be srv/
+# you can also do a git clone
+ mkdir app
+ cd app
+ git init
+ cd ..
+unfurl app-1.2.3 app # [FIDDLY BIT]
+# NOTE: contents of application are now in app directory
+cd app
+git add .
+git commit -s -m "App 1.2.3"
+git tag v1.2.3
+git branch pristine
+# NOTE: you're still on master branch
+# WARNING: the following operation might require -p1
+patch -p0 < ../app-1.2.3/app-1.2.3.patch # [FIDDLY BIT]
+# NOTE: please sanity check the patch!
+git add .
+# NOTE: -a flag is to handle if the patch deleted something
+git commit -as -m "App 1.2.3-scripts"
+git tag v1.2.3-scripts
+
+[TO ADD AN UPDATE]
+# let this folder be srv/app.git
+git checkout pristine
+# NOTE: this preserves your .git folder, but removes everything
+wipe-working-dir .
+cd ..
+unfurl app-1.2.3 app # [FIDDLY BIT]
+cd app
+# NOTE: please sanity check app directory
+git add .
+# NOTE: -a is to take care of deletions
+git commit -as -m "App 1.2.3"
+git tag v1.2.3
+[FIDDLE AROUND. FIDDLE AROUND]
+[IF THE PATCH HAS CHANGED]
+ # You are on the pristine branch
+ # 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 .
+ # COMMENT: used to git checkout .scripts here
+ # then check if the directory needs an updated update script
+ # NOTE: Fake the merge
+ git rev-parse pristine > .git/MERGE_HEAD
+[IF THE PATCH HASN'T CHANGED]
+ git checkout master
+ git merge --no-commit pristine
+git commit -as -m "App 1.2.3-scripts"
+git tag v1.2.3-scripts
* The repository for a given application will contain the following files:
* .scripts/database (generated) contains the database the
user installed the script to, so scripts-remove can clean it
- * .scripts/version (generated) which contains the version
- last autoinstalled (as distinct from the actual version
- the script is) (This is the same as .scripts-version right
- now; probably want to keep that for now)
-
- - 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, but preferred mode
- of operation is to operate on a clean install.
-
-* The migration process shall be as such:
-
- 1. git init
-
- 2. git remote add origin /foo
+ XXX: Could cause problems if a user copies the autoinstall,
+ fiddles with the DB credentials, and then scripts-remove's
+ the autoinstall. Possible fix is to add the original
+ directory as a sanity check. Additionally, we could have
+ the application read out of this file.
- 3. git config branch.master.merge refs/heads/master
+ * .scripts/old-version (optional) the old value of .scripts-version
- 4. git fetch origin
+ * .scripts/version something like "app-1.2.3-scripts"
- 5. git reset v1.2.3-scripts
+ * .scripts/install (eventually) interactively installs the
+ application from command line. (This might go into wizard.app
+ Python module)
- 5. git checkout .scripts
+ * .scripts/lock which locks the autoinstall during an upgrade
- 6. Setup .scripts/version (probably pipe the output of real-version)
- UNCLEAR if this is a good thing; if it is, make sure we add
- a .gitignore to the .scripts directory
-
-* 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:
-
- # Make the directory not accessible by the outside world (htaccess, but be careful!)
- git add -u .
- git commit -m 'automatically generated backup'
- git pull origin master
- if [ $? ne 0 ]; then git reset --hard; echo 'conflicts during upgrade'; fi
- ./.scripts/update
- # Make it accessible
-
- (with some more robust error checking)
-
-* Make install-statistics generate nice pretty graphs of installs by date
+* Make 'wizard summary' generate nice pretty graphs of installs by date
(more histograms, will need to check actual .scripts-version files.)
+
scripts.mit.edu / wizard.git / blobdiff