X-Git-Url: https://scripts.mit.edu/gitweb/wizard.git/blobdiff_plain/f442e7cf52b92c6072676bf4eb96dacb7f31f02f..db709749a3e3b1cba85a6869c87af925ae33d441:/TODO diff --git a/TODO b/TODO index ac022ca..260941d 100644 --- a/TODO +++ b/TODO @@ -2,111 +2,68 @@ The Git Autoinstaller TODO NOW: -- Make sure massmigrate cleanly ignores already migrated - installs -- Make sure MediaWiki repository is as close to perfect - as possible: - - Do an install, migrate and then `git status` - - Check out possible missing php.ini's - - Remove "Merge comments" from lines - - Fix Signed-off-by lines -- Add some safeguard code to make sure you don't run migrate - or upgrade as root - -- We have safe, non-braindead - version detection with `git describe --tags`. Switch - everything to use it. (I think the only thing left is - parallel-find.pl) -- wizard.util is pretty braindead at this point. Fix up - the wildly varying conventions in it. -- Move migration code into Wizard, since we already deal - with installation there anyway. - -- Better error message if daemon/scripts-security-upd - is not on scripts-security-upd list - -- Fix retarded logging mechanism - -- The great initial deploy: - - Turn on mediawiki new autoinstaller - - Migrate all mediawiki installs - -Doing Wordpress: -- 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) -- 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 - -Some other stuff to do in your copious free time: -- 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. - (This might be otherwise possible using `fs sysname` -- Implement proper deploy log parsing; this basically means we - need to be able to introspect Git Log. Consider using git-python - for this. -- 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. - -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. +- If no newlines at all, DON'T CARE (don't rewrite the file again!) +- Plugin-ify! + +- Add support for mypristine workflow +- Wordpress needs to get rid of the siteurl hack, so that it actually + has a fully-qualified URL http://foo.scripts.mit.edu/blah. This will + also fix Wordpress's cron functionality. We should be careful not + to write over users who are on vhosts. We should figure out who is + still on twiddle paths. We should make sure the redirect is handled + correctly. + +- Remerges aren't reflected in the parent files, so `git diff` output is + spurious. Not sure how to fix this w/o tree hackery. +- Sometimes users remove files. Well, if those files change, they automatically + get marked as conflicted. Maybe we should say for certain files "if they're + gone, they're gone forever"? What is the proper resolution? + +- 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 + +- 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. + +- 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; + namely cooking up the sudo and environment variable lines + - Summary script should be more machine friendly, and should not + output summary charts when I increase specificity + +- 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 + - 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. + +[ XXX: metadata.rst ] COMMIT MESSAGE FIELDS: @@ -122,205 +79,46 @@ GIT COMMIT FIELDS: Committer: Real Name Author: lockername locker -NOTES: - -- It is not expected or required 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. - OVERALL PLAN: +[ XXX: doc/deps.rst ] * 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/.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.) - - 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 - -A 1. Have the Git repository and working copy for the project on hand. + - get-homedirs.sh. which needs to be run as root on scripts. Store + in /mit/scripts/sec-tools/store/scriptslist -A 2. Checkout the pristine branch - -A 3. Remove all files from the working copy. Use `wipe-working-dir` - -A 4. Download the new tarball - -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) - -A 6. Check for empty directories and add stub files as necessary. - Use `preserve-empty-dir` - -A 7. Git add it all, and then commit as a new pristine version (v1.2.3) - -A 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] -A mkdir .scripts -A 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) - - NOTE: These steps should be run on a scripts server - - 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). - - 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) + - parallel-find.pl, and the resulting + /mit/scripts/sec-tools/store/versions - 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, 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) + 11. Run `wizard mass-upgrade appname`, which applies the update to all working + copies possible. -[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 + 12. Run parallel-find.pl to update our inventory +[ XXX: doc/metadata.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. (XXX: This is going to get removed soon) - - * .scripts/.htaccess to prevent this directory from being accessed - from the web. - - * .scripts/old-version (optional) the old value of .scripts-version, - basically used for reverting an install to pre-migrated state. - - * .scripts/lock (generated) which locks the autoinstall during an upgrade + - A .scripts directory, with the intent of holding Scripts specific files + if they become necessary. + - .scripts/dsn, overriding database source name