TODO NOW:
-- Migration script needs to make an empty commit with the
- user's changes that says "Initial migration", and then
- has wizard info
-- We need to figure out how much info Wizard will barf into
- the commit message. Candidates:
- o Wizard revision
- o Wizard command line args
- o Person running the command; use env SSH_GSSAPI_NAME
-- Check how many autoinstalls are missing w bits for
- daemon.scripts (this would need pyafs)
-- Add repository flag to migrate so that we can specify an
- arbitrary repository to migrate to
-- Run parallel-find.pl
-- Migrate all mediawikis
-- Wordpress needs to have a .scripts/update script written for
- its latest version
-- Wordpress needs to have .scripts dir in all -scripts versions
- (remember --no-walk!)
-
-- Need to upgrade the installer scripts to work out of the
- repository
-- Need an upgrade script OR
-- Need survey script
-
-- Summary script should be more machine friendly, and should not
- output summary charts when I increase specificity
+- Test code should auto-nuke the database using `wizard remove` before doing a new install
+- git diff :1:$file :2:$file to find out what the user did, or is it :3:?
+- Document how to fix a broken upgrade
+- php.ini needs to get substituted!
+- Make wizard install accept appname-head (so that you can do a test with
+ head, and do things without tags). Also make it accept commit hashes.
+ In fact, let it accept any committish. Figure out what to do if we
+ do a test script with x.y.z when we REALLY mean x.y.z-scripts. XXX!!!
+- Do early validation of inputs for configuration
+- Let 'wizard configure' be interactive
+- Parse output HTML for class="error" and give those errors back to the user,
+ then boot them back into configure
+- 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)
+
+- Redo Wordpress conversion, with an eye for automating everything
+ possible (such as downloading the tarball and unpacking)
+
+- Web application for installing autoinstalls has a hard problem
+ with credentials (as well as installations that are not conducted
+ on an Athena machine.) Possible solutions include asking the user
+ to SSH into an athena machine and run a bunch of commands, or writing
+ a Java applet (possibly in Clojure or Scala) which gets filesystem
+ permissions and then performs the operations.
+
+- Pay back code debt
+ - Genericize 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
+ - 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 # person who ran autoinstaller
-Updated-by: username@hostname # person who upgraded an autoinstall
-Migrated-by: username@hostname # person who migrated an autoinstall
-Wizard-revision: abcdef1234567890 # revision of wizard used
-Wizard-args: wizard foo bar baz # arguments passed to Wizard
+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
-NOTES:
+GIT COMMIT FIELDS:
+
+Committer: Real Name <username@mit.edu>
+Author: lockername locker <lockername@scripts.mit.edu>
-- 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.
+NOTES:
-- summary and info are still not using loggers. Maybe they should,
- maybe they shouldn't. Using loggers means we lose interactivity
- with the Git output
+- 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.
-
-- 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.
+ also means that /mit/scripts/wizard/srv MUST NOT lose revs after
+ deployment.
OVERALL PLAN:
on documenting them. Specifically, we will be keeping:
- parallel-find.pl, and the resulting
- /mit/scripts/sec-tools/store/scriptslist
- This script might need to be adapted if we decide to nuke
- .scripts-version files.
-
- - 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)
+ although uglier in some ways; A indicates the step /should/ be automated)
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
- 1. Have the Git repository and working copy for the project on hand.
-
- 2. Checkout the pristine branch
-
- 3. Remove all files from the working copy. Use `wipe-working-dir`
-
- 4. Download the new tarball
-
- 5. Extract the tarball over the working copy (`cp -R a/. b` works well,
- remember that the working copy is empty)
-
- 6. Check for empty directories and add stub files as necessary.
- Use `preserve-empty-dir`
-
- 7. Git add it all, and then commit as a new pristine version (v1.2.3)
-
- 8. Checkout the master branch
-
- 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
-
- [FOR NEW REPOSITORIES]
- See if any patches are needed to make this run smoothly on
- scripts.
-
- [FOR NEW REPOSITORIES]
- mkdir .scripts
- echo "Deny from all" > .scripts/.htaccess
- touch .scripts/update
- chmod a+x .scripts/update
-
- 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)
+ 1. [ see doc/upgrade.rst ]
- 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).
+ [ENTER HERE FROM CREATING A NEW REPO]
- 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.
+ 9. Push all of your changes in a public place, and encourage others
+ to test, using --srv-path and a full path.
- GET APPROVAL BEFORE PROCEEDING ANY FURTHER
+[ XXX: doc/deploy.rst ]
+ GET APPROVAL BEFORE PROCEEDING ANY FURTHER;
+ THIS IS PUSHING THE CHANGES TO THE PUBLIC
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.
- 14. Run `wizard research appname`
+ 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. It also tells
- us about "corrupt" working copies.
-
- 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. It also frobs .scripts-version for successful
- upgrades (maybe not, depending on our plans).
-
- 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
-
-
+ 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/.htaccess to prevent this directory from being accessed
- from the web.
-
- * .scripts/database (generated) contains the database the
- user installed the script to, so scripts-remove can clean it
-
- 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.
-
- * .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)
-
- XXX: It's unclear if we want to move to this wholesale, or
- delay this indefinitely. quentin thinks that the Git
- repository itself is a sufficient record.
-
-* The migration process has been implemented, see 'wizard migrate'.
-
- XXX: We have not decided what migration should do to .scripts-version;
- if it does move it to .scripts, repositories should have a .gitignore
- in those directories
-
-* 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, a proper dry run mechanism to, and
- lots of su'ing)
-
-* All code that operates on an untrusted Git repository, or runs
- executable code, should be done on NOT-BACKWARD.mit.edu. Pending
- accounts confirmation, it will also get a principal
- daemon.scripts-security-upd, which is what we'll actually put
- in the scripts-security-upd group. parallel-find.pl should also
- be run on not-backward, by virtue of its fat pipe to the AFS servers.
-
-* Make 'wizard summary' generate nice pretty graphs of installs by date
- (more histograms, will need to check actual .scripts-version files.)
+ - A .scripts directory, with the intent of holding Scripts specific files
+ if they become necessary.
-* Update AFS patch to advertise its existence, so we can check for it
- here.