TODO

   1 The Git Autoinstaller
   2
   3 TODO NOW:
   4
   5 - Consider adding user config to repository
   6 - Put php.ini links in repos (probably will need another
   7   script in .scripts)
   8 - Version configuration
   9
  10 - Consider making usermode wizard operation a support mode
  11   (mostly for letting users upgrade things themself)
  12
  13 - Add repository flag to migrate so that we can specify an
  14   arbitrary repository to migrate to
  15
  16 - The great initial deploy:
  17     - Turn on mediawiki new autoinstaller
  18     - Migrate all mediawik installs
  19
  20 - Implement proper deploy log parsing; this basically means we
  21   need to be able to introspect Git Log. Consider using git-python
  22   for this.  There's also missing functionality, bad error handling
  23   and hacks in the prototype implementation of upgrade
  24
  25 - Wordpress needs to have .scripts dir in all -scripts versions
  26   (remember --no-walk!) (also make .scripts/.htaccess)
  27 - Wordpress needs to have a .scripts/update script written for
  28   its latest version (do this after its migration)
  29 - Wordpress needs to check for php.ini files (which it almost
  30   certianly has) and commit messages
  31
  32 - Summary script should be more machine friendly, and should not
  33   output summary charts when I increase specificity
  34 - Check how many autoinstalls are missing w bits for
  35   daemon.scripts (this would need pyafs)
  36 - Consider fixing Wizard's commit messages
  37
  38 PULLING OUT CONFIGURATION FILES IN AN AUTOMATED MANNER
  39
  40 advancedbook: Two template files to fill out
  41 advancedpoll: Template file to fill out
  42 django: Noodles of template files
  43 e107: Multistage install process
  44 gallery2: Multistage install process
  45 joomla: Template file
  46 mediawiki: One-step install process
  47 phpbb: Multistage install process
  48 phpical: Template file
  49 trac: NFC
  50 turbogears: NFC
  51 wordpress: Multistage install process
  52
  53 COMMIT MESSAGE FIELDS:
  54
  55 Installed-by: username@hostname
  56 Pre-commit-by: Real Name <username@mit.edu>
  57 Upgraded-by: Real Name <username@mit.edu>
  58 Migrated-by: Real Name <username@mit.edu>
  59 Wizard-revision: abcdef1234567890
  60 Wizard-args: /wizard/bin/wizard foo bar baz
  61
  62 GIT COMMIT FIELDS:
  63
  64 Committer: Real Name <username@mit.edu>
  65 Author: lockername locker <lockername@scripts.mit.edu>
  66
  67 NOTES:
  68
  69 - A perfectly formed autoinstall with upgrade paths for all of
  70   the intervening versions is not really feasible to implement.
  71   As such, we want to migrate everything to -scripts, and then
  72   generate a -scripts2 with the correct .scripts directory.
  73   We will then nop update some installs, but this will prevent
  74   us from having to migrate and update concurrently.  Treat
  75   a scripts2 upgrade from migration the same way you would treat
  76   a botched scripts upgrade.
  77
  78 - Currently all repositories are initialized with --shared, which
  79   means they have basically ~no space footprint.  However, it
  80   also means that /mit/scripts/wizard/srv MUST NOT lose revs.
  81
  82 - Full fledged logging options. Namely:
  83   x all loggers (delay implementing this until we actually have debug stmts)
  84     - default is WARNING
  85     - debug     => loglevel = DEBUG
  86   x stdout logger
  87     - default is WARNING (see below for exception)
  88     - verbose   => loglevel = INFO
  89   x file logger (only allowed for serial processing)
  90     - default is OFF
  91     - log-file   => loglevel = INFO
  92   x database logger (necessary for parallel processing, not implemented)
  93     - default is OFF
  94     - log-db    => loglevel = INFO
  95
  96 - More on the database logger: it will be very simple with one
  97   table named `logs` in SQLite, with columns: `job`, `level`,
  98   `message`.  Job identifies the subprocess/thread that emitted
  99   the log, so things can be correlated together.  We will then
 100   have `wizard dump` which takes a database like this and dumps
 101   it into a file logger type file.  The database may also store
 102   a queue like structure which can be used to coordinate jobs.
 103
 104 OVERALL PLAN:
 105
 106 * Some parts of the infrastructure will not be touched, although I plan
 107   on documenting them.  Specifically, we will be keeping:
 108
 109     - parallel-find.pl, and the resulting
 110       /mitalso make .scripts/.htaccess/scripts/sec-tools/store/scriptslist
 111       This script might need to be adapted if we decide to nuke
 112       .scripts-version files.
 113
 114     - The current install scripts will be kept in place, sans changes
 115       necessary to make them use Git install of copying the script over.
 116       Porting these scripts to Python and making them modular would be
 117       nice, but is priority.  For the long term, seeing this scripts
 118       be packaged with rest of our code would be optimal.
 119
 120 * The new procedure for generating an update is as follows:
 121   (check out the mass-migration instructions for something in this spirit,
 122   although uglier in some ways)
 123
 124     0. ssh into not-backward, temporarily give the daemon.scripts-security-upd
 125        bits by blanching it on system:scripts-security-upd, and run parallel-find.pl
 126
 127     1. Have the Git repository and working copy for the project on hand.
 128
 129     2. Checkout the pristine branch
 130
 131     3. Remove all files from the working copy.  Use `wipe-working-dir`
 132
 133     4. Download the new tarball
 134
 135     5. Extract the tarball over the working copy (`cp -R a/. b` works well,
 136        remember that the working copy is empty)
 137
 138     6. Check for empty directories and add stub files as necessary.
 139        Use `preserve-empty-dir`
 140
 141     7. Git add it all, and then commit as a new pristine version (v1.2.3)
 142
 143     8. Checkout the master branch
 144
 145     9. [FOR EXISTING REPOSITORIES]
 146        Merge the pristine branch in. Resolve any conflicts that our
 147        patches have with new changes. Do NOT let Git auto-commit it
 148        with --no-commit (otherwise, you want to git commit --amend
 149        to keep our history clean
 150
 151        [FOR NEW REPOSITORIES]
 152        See if any patches are needed to make this run smoothly on
 153        scripts.
 154
 155     [FOR NEW REPOSITORIES]
 156         mkdir .scripts
 157         echo "Deny from all" > .scripts/.htaccess
 158         touch .scripts/update
 159         chmod a+x .scripts/update
 160
 161    10. Check if there are any special update procedures, and update/create the
 162        .scripts/update shell script as necessary (this means that any
 163        application specific update logic will be kept with the actual
 164        source code.  The language of this update script will vary
 165        depending on context.)
 166
 167    11. Commit your changes, and tag as v1.2.3-scripts (or scripts2, if
 168        you are amending an install without an upstream changes)
 169
 170    12. Test the new update procedure using
 171        `wizard upgrade --with=/path/to/repo /your/autoinstall` (this will
 172        read out master as your "latest" version).
 173        Use git commit --amend to fix any bugs (alternatively, squash them
 174        together later).
 175
 176    13. You can also do a "mass" version of this using:
 177        `wizard -d testbed.txt massupgrade --with=/path/to/repo app`
 178        You'll need perms for any testbed stuff you want.
 179
 180       GET APPROVAL BEFORE PROCEEDING ANY FURTHER
 181
 182       NOTE: The following commands are to be run on not-backward.mit.edu.
 183       You'll need to add daemon.scripts-security-upd to
 184       scripts-security-upd to get bits to do this.  Make sure you remove
 185       these bits when you're done.
 186
 187    14. Run `wizard research appname`
 188        which uses Git commands to check how many
 189        working copies apply the change cleanly, and writes out a logfile
 190        with the working copies that don't apply cleanly.  It also tells
 191        us about "corrupt" working copies.
 192
 193    15. Run `wizard massupgrade appname`, which applies the update to all working
 194        copies possible, and sends mail to users to whom the working copy
 195        did not apply cleanly. It also frobs .scripts-version for successful
 196        upgrades (maybe not, depending on our plans).
 197
 198    16. Run parallel-find.pl to update our inventory
 199
 200 * For mass importing into the repository, the steps are:
 201   (this probably won't ever be automated, becuase there are fiddly bits)
 202
 203 [TO SET IT UP]
 204 # let app-1.2.3 be the scripts folder originally in deploydev
 205 # let this folder be srv/
 206 # you can also do a git clone
 207     mkdir app
 208     cd app
 209     git init
 210     cd ..
 211 unfurl app-1.2.3 app  # [FIDDLY BIT]
 212 # NOTE: contents of application are now in app directory
 213 cd app
 214 git add .
 215 git commit -s -m "App 1.2.3"
 216 git tag v1.2.3
 217 git branch pristine
 218 # NOTE: you're still on master branch
 219 # WARNING: the following operation might require -p1
 220 patch -p0 < ../app-1.2.3/app-1.2.3.patch  # [FIDDLY BIT]
 221 # NOTE: please sanity check the patch!
 222 git add .
 223 # NOTE: -a flag is to handle if the patch deleted something
 224 git commit -as -m "App 1.2.3-scripts"
 225 git tag v1.2.3-scripts
 226
 227 [TO ADD AN UPDATE]
 228 # let this folder be srv/app.git
 229 git checkout pristine
 230 # NOTE: this preserves your .git folder, but removes everything
 231 wipe-working-dir .
 232 cd ..
 233 unfurl app-1.2.3 app  # [FIDDLY BIT]
 234 cd app
 235 # NOTE: please sanity check app directory
 236 git add .
 237 # NOTE: -a is to take care of deletions
 238 git commit -as -m "App 1.2.3"
 239 git tag v1.2.3
 240 [FIDDLE AROUND. FIDDLE AROUND]
 241 [IF THE PATCH HAS CHANGED]
 242     # You are on the pristine branch
 243     # NOTE: Now, the tricky part (this is different from a real update)
 244     git symbolic-ref HEAD refs/heads/master
 245     # NOTE: Now, we think we're on the master branch, but we have
 246     # pristine copy checked out
 247     # NOTE: -p0 might need to be twiddled
 248     patch -p0 < ../app-1.2.3/app-1.2.3.patch
 249     git add .
 250     # COMMENT: used to git checkout .scripts here
 251     # then check if the directory needs an updated update script
 252     # NOTE: Fake the merge
 253     git rev-parse pristine > .git/MERGE_HEAD
 254 [IF THE PATCH HASN'T CHANGED]
 255     git checkout master
 256     git merge --no-commit pristine
 257 git commit -as -m "App 1.2.3-scripts"
 258 git tag v1.2.3-scripts
 259
 260 * The repository for a given application will contain the following files:
 261
 262     - The actual application's files, as from the official tarball
 263
 264     - A .scripts directory, which contains the following information:
 265
 266         * .scripts/update shell script (with the +x bit set appropriately),
 267           which performs the commands necessary to update a script.  This can
 268           be in any language.
 269
 270         * .scripts/.htaccess to prevent this directory from being accessed
 271           from the web.
 272
 273         * .scripts/database (generated) contains the database the
 274           user installed the script to, so scripts-remove can clean it
 275
 276             XXX: Could cause problems if a user copies the autoinstall,
 277             fiddles with the DB credentials, and then scripts-remove's
 278             the autoinstall.  Possible fix is to add the original
 279             directory as a sanity check.  Additionally, we could have
 280             the application read out of this file.
 281
 282         * .scripts/old-version (optional) the old value of .scripts-versoin
 283
 284         * .scripts/install (eventually) interactively installs the
 285           applicatoin from command line.
 286
 287 * The autoupgrade shall be the process of:
 288
 289     # Make the directory not accessible by the outside world (htaccess, but be careful!)
 290     git add -u .
 291     git commit -m 'automatically generated backup'
 292     git pull origin master
 293     if [ $? ne 0 ]; then git reset --hard; echo 'conflicts during upgrade'; fi
 294     ./.scripts/update
 295     # Make it accessible
 296
 297   (with some more robust error checking, a proper dry run mechanism to, and
 298   lots of su'ing)
 299
 300 * Make 'wizard summary' generate nice pretty graphs of installs by date
 301   (more histograms, will need to check actual .scripts-version files.)
 302
 303 * Update AFS patch to advertise its existence, so we can check for it
 304   here.