TODO

   1 The Git Autoinstaller
   2
   3 TODO NOW:
   4
   5 - Something needs to be done if disk quota is exceeded:
   6     - Catch the OSError and throw a domain-specific error
   7       so massmigrate can deal gracefully
   8     - Perform an added memory calculation, check this against
   9       remaining quotai, and bail out if it's within some
  10       percentage of their remaining quota
  11     - Checks should also be performed against the partition
  12     X with the new --shared flag this may not be necessary
  13       as repos weighs less than 200K
  14 - Should write to a "processed" file to make resuming with
  15   unexpected failure faster (possibly should be database if
  16   parallelized).  Remember that each subprocess will be a fork
  17 - Figure out IPC logging.
  18 - Make version directory also work with a location (with no
  19   colon) format; this will make making fake "testbed" directories
  20   easier to do.  Also let it accept a file, instead of a directory.
  21 - Check how many autoinstalls are missing w bits for
  22   daemon.scripts (this would need pyafs)
  23 - Run parallel-find.pl
  24 - Migrate all mediawikis
  25 - Wordpress needs to have a .scripts/update script written for
  26   its latest version
  27
  28 NOTES:
  29
  30 - A perfectly formed autoinstall with upgrade paths for all of
  31   the intervening versions is not really feasible to implement.
  32   As such, we want to migrate everything to -scripts, and then
  33   generate a -scripts2 with the correct .scripts directory.
  34   We will then nop update some installs, but this will prevent
  35   us from having to migrate and update concurrently.  Treat
  36   a scripts2 upgrade from migration the same way you would treat
  37   a botched scripts upgrade.
  38
  39 - summary and info are still not using loggers. Maybe they should,
  40   maybe they shouldn't.  Using loggers means we lose interactivity
  41   with the Git output
  42
  43 - Currently all repositories are initialized with --shared, which
  44   means they have basically ~no space footprint.  However, it
  45   also means that /mit/scripts/wizard/srv MUST NOT lose revs.
  46
  47 OVERALL PLAN:
  48
  49 * Some parts of the infrastructure will not be touched, although I plan
  50   on documenting them.  Specifically, we will be keeping:
  51
  52     - parallel-find.pl, and the resulting
  53       /mit/scripts/sec-tools/store/scriptslist
  54       This script might need to be adapted if we decide to nuke
  55       .scripts-version files.
  56
  57     - The current install scripts will be kept in place, sans changes
  58       necessary to make them use Git install of copying the script over.
  59       Porting these scripts to Python and making them modular would be
  60       nice, but is priority.  For the long term, seeing this scripts
  61       be packaged with rest of our code would be optimal.
  62
  63 * The new procedure for generating an update is as follows:
  64   (check out the mass-migration instructions for something in this spirit,
  65   although uglier in some ways)
  66
  67     0. ssh into not-backward, temporarily give the daemon.scripts-security-upd
  68        bits by blanching it on system:scripts-security-upd, and run parallel-find.pl
  69
  70     1. Have the Git repository and working copy for the project on hand.
  71
  72     2. Checkout the pristine branch
  73
  74     3. Remove all files from the working copy.  Use `wipe-working-dir`
  75
  76     4. Download the new tarball
  77
  78     5. Extract the tarball over the working copy (`cp -R a/. b` works well,
  79        remember that the working copy is empty)
  80
  81     6. Check for empty directories and add stub files as necessary.
  82        Use `preserve-empty-dir`
  83
  84     7. Git add it all, and then commit as a new pristine version (v1.2.3)
  85
  86     8. Checkout the master branch
  87
  88     9. [FOR EXISTING REPOSITORIES]
  89        Merge the pristine branch in. Resolve any conflicts that our
  90        patches have with new changes. Do NOT let Git auto-commit it
  91        with --no-commit (otherwise, you want to git commit --amend
  92        to keep our history clean
  93
  94        [FOR NEW REPOSITORIES]
  95        See if any patches are needed to make this run smoothly on
  96        scripts.
  97
  98     [FOR NEW REPOSITORIES]
  99         mkdir .scripts
 100         echo "Deny from all" > .scripts/.htaccess
 101         touch .scripts/update
 102         chmod a+x .scripts/update
 103
 104    10. Check if there are any special update procedures, and update/create the
 105        .scripts/update shell script as necessary (this means that any
 106        application specific update logic will be kept with the actual
 107        source code.  The language of this update script will vary
 108        depending on context.)
 109
 110    11. Commit your changes, and tag as v1.2.3-scripts (or scripts2, if
 111        you are amending an install without an upstream changes)
 112
 113    12. Test the new update procedure using
 114        `wizard upgrade --with=/path/to/repo /your/autoinstall` (this will
 115        read out master as your "latest" version).
 116        Use git commit --amend to fix any bugs (alternatively, squash them
 117        together later).
 118
 119    13. You can also do a "mass" version of this using:
 120        `wizard -d testbed.txt massupgrade --with=/path/to/repo app`
 121        You'll need perms for any testbed stuff you want.
 122
 123       GET APPROVAL BEFORE PROCEEDING ANY FURTHER
 124
 125       NOTE: The following commands are to be run on not-backward.mit.edu.
 126       You'll need to add daemon.scripts-security-upd to
 127       scripts-security-upd to get bits to do this.  Make sure you remove
 128       these bits when you're done.
 129
 130    14. Run `wizard research appname`
 131        which uses Git commands to check how many
 132        working copies apply the change cleanly, and writes out a logfile
 133        with the working copies that don't apply cleanly.  It also tells
 134        us about "corrupt" working copies.
 135
 136    15. Run `wizard massupgrade appname`, which applies the update to all working
 137        copies possible, and sends mail to users to whom the working copy
 138        did not apply cleanly. It also frobs .scripts-version for successful
 139        upgrades (maybe not, depending on our plans).
 140
 141    16. Run parallel-find.pl to update our inventory
 142
 143 * For mass importing into the repository, the steps are:
 144   (this probably won't ever be automated, becuase there are fiddly bits)
 145
 146 [TO SET IT UP]
 147 # let app-1.2.3 be the scripts folder originally in deploydev
 148 # let this folder be srv/
 149 # you can also do a git clone
 150     mkdir app
 151     cd app
 152     git init
 153     cd ..
 154 unfurl app-1.2.3 app  # [FIDDLY BIT]
 155 # NOTE: contents of application are now in app directory
 156 cd app
 157 git add .
 158 git commit -s -m "App 1.2.3"
 159 git tag v1.2.3
 160 git branch pristine
 161 # NOTE: you're still on master branch
 162 # WARNING: the following operation might require -p1
 163 patch -p0 < ../app-1.2.3/app-1.2.3.patch  # [FIDDLY BIT]
 164 # NOTE: please sanity check the patch!
 165 git add .
 166 # NOTE: -a flag is to handle if the patch deleted something
 167 git commit -as -m "App 1.2.3-scripts"
 168 git tag v1.2.3-scripts
 169
 170 [TO ADD AN UPDATE]
 171 # let this folder be srv/app.git
 172 git checkout pristine
 173 # NOTE: this preserves your .git folder, but removes everything
 174 wipe-working-dir .
 175 cd ..
 176 unfurl app-1.2.3 app  # [FIDDLY BIT]
 177 cd app
 178 # NOTE: please sanity check app directory
 179 git add .
 180 # NOTE: -a is to take care of deletions
 181 git commit -as -m "App 1.2.3"
 182 git tag v1.2.3
 183 [FIDDLE AROUND. FIDDLE AROUND]
 184 [IF THE PATCH HAS CHANGED]
 185     # You are on the pristine branch
 186     # NOTE: Now, the tricky part (this is different from a real update)
 187     git symbolic-ref HEAD refs/heads/master
 188     # NOTE: Now, we think we're on the master branch, but we have
 189     # pristine copy checked out
 190     # NOTE: -p0 might need to be twiddled
 191     patch -p0 < ../app-1.2.3/app-1.2.3.patch
 192     git add .
 193     # COMMENT: used to git checkout .scripts here
 194     # then check if the directory needs an updated update script
 195     # NOTE: Fake the merge
 196     git rev-parse pristine > .git/MERGE_HEAD
 197 [IF THE PATCH HASN'T CHANGED]
 198     git checkout master
 199     git merge --no-commit pristine
 200 git commit -as -m "App 1.2.3-scripts"
 201 git tag v1.2.3-scripts
 202
 203
 204 * The repository for a given application will contain the following files:
 205
 206     - The actual application's files, as from the official tarball
 207
 208     - A .scripts directory, which contains the following information:
 209
 210         * .scripts/update shell script (with the +x bit set appropriately),
 211           which performs the commands necessary to update a script.  This can
 212           be in any language.
 213
 214         * .scripts/.htaccess to prevent this directory from being accessed
 215           from the web.
 216
 217         * .scripts/database (generated) contains the database the
 218           user installed the script to, so scripts-remove can clean it
 219
 220             XXX: Could cause problems if a user copies the autoinstall,
 221             fiddles with the DB credentials, and then scripts-remove's
 222             the autoinstall.  Possible fix is to add the original
 223             directory as a sanity check.  Additionally, we could have
 224             the application read out of this file.
 225
 226         * .scripts/version (generated) which contains the version
 227           last autoinstalled (as distinct from the actual version
 228           the script is) (This is the same as .scripts-version right
 229           now; probably want to keep that for now)
 230
 231             XXX: It's unclear if we want to move to this wholesale, or
 232             delay this indefinitely.  quentin thinks that the Git
 233             repository itself is a sufficient record.
 234
 235 * The migration process has been implemented, see 'wizard migrate'.
 236
 237     XXX: We have not decided what migration should do to .scripts-version;
 238     if it does move it to .scripts, repositories should have a .gitignore
 239     in those directories
 240
 241 * The autoupgrade shall be the process of:
 242
 243     # Make the directory not accessible by the outside world (htaccess, but be careful!)
 244     git add -u .
 245     git commit -m 'automatically generated backup'
 246     git pull origin master
 247     if [ $? ne 0 ]; then git reset --hard; echo 'conflicts during upgrade'; fi
 248     ./.scripts/update
 249     # Make it accessible
 250
 251   (with some more robust error checking, a proper dry run mechanism to, and
 252   lots of su'ing)
 253
 254 * All code that operates on an untrusted Git repository, or runs
 255   executable code, should be done on NOT-BACKWARD.mit.edu.  Pending
 256   accounts confirmation, it will also get a principal
 257   daemon.scripts-security-upd, which is what we'll actually put
 258   in the scripts-security-upd group.  parallel-find.pl should also
 259   be run on not-backward, by virtue of its fat pipe to the AFS servers.
 260
 261 * Make 'wizard summary' generate nice pretty graphs of installs by date
 262   (more histograms, will need to check actual .scripts-version files.)