TODO NOW:
-- Keep my sanity when upgrading 1000 installs
- - Custom merge algo: absolute php.ini symlinks to relative symlinks (this
- does not seem to have been a problem in practice)
- - Custom merge algo: check if it's got extra \r's in the file,
- and dos2unix it if it does, before performing the merge
- - `vos exa` in order to check what a person's quota is. We can
- figure out roughly how big the upgrade is going to be by
- doing a size comparison of the tars: `git pull` MUST NOT
- fail, otherwise things are left conflicted, and not easy to fix.
- - Prune -7 call errors and automatically reprocess them (with a
- strike out counter of 3)--this requires better error parsing
-
-- Distinguish from logging and reporting (so we can easily send mail
- to users)
- - Figure out a way of collecting blacklist data from .scripts/blacklisted
- and aggregate it together
-
-- Let users use Wizard when ssh'ed into Scripts
- - Make single user mass-migrate work when not logged in as root
-
-- Make the rest of the world use Wizard
- - Make parallel-find.pl use `sudo -u username git describe --tags`
- to determine version. Make parallel-find.pl have this have greater
- precedence. This also means, however, that we get
- full mediawiki-1.2.3-2-abcdef names (Have patch, pending testing and commit)
- - Make deployed installer use 'wizard install' /or/ do a migration
- after doing a normal install (the latter makes it easier
- for mass-rollbacks).
-
-- 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)
+- 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
- - Genericize callAsUser and drop_priviledges in shell
+ - 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
- - 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
- 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
- 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
+- 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.
-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.
+[ XXX: metadata.rst ]
COMMIT MESSAGE FIELDS:
Committer: Real Name <username@mit.edu>
Author: lockername locker <lockername@scripts.mit.edu>
-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 after
- deployment.
-
-- 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 (creates a dir and lots of little logfiles)
- - default is OFF
- - log-file => loglevel = INFO
-
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
-
- 1. Have the Git repository and working copy for the project on hand.
-
-/- wizard prepare-pristine --
-
-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)
+ - get-homedirs.sh. which needs to be run as root on scripts. Store
+ in /mit/scripts/sec-tools/store/scriptslist
-A 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]
- Check if any patches are needed to make the application work
- on Scripts (ideally, it shouldn't.
-
-/- wizard prepare-new --
-
- Currently not used for anything besides parallel-find.pl, but
- we reserve the right to place files in here in the future.
-
-A mkdir .scripts
-A echo "Deny from all" > .scripts/.htaccess
-
-\---
-
- 10. Check if there are any special update procedures, and update
- the wizard.app.APPNAME module accordingly (or create it, if
- need be).
-
- 11. Run 'wizard prepare-config' on a scripts server while in a checkout
- of this newest version. This will prepare a new version of the
- configuration file based on the application's latest installer.
- Manually merge back in any custom changes we may have made.
- Check if any of the regular expressions need tweaking by inspecting
- the configuration files for user-specific gunk, and modify
- wizard.app.APPNAME accordingly.
-
- 12. 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
-
- 13. Test the new update procedure using our test scripts. See integration
- tests for more information on how to do this.
-
- http://scripts.mit.edu/wizard/testing.html#acceptance-tests
+ - 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.
-A 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.
-A 15. Run `wizard mass-upgrade 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, there are a few extra things:
-
- * Many applications had patches associated with them. Be sure to
- apply them, so later merges work better.
-
- # the following operation might require -p1
- patch -p0 < ../app-1.2.3/app-1.2.3.patch # [FIDDLY BIT]
-
- * When running 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
+ 11. Run `wizard mass-upgrade appname`, which applies the update to all working
+ copies possible.
- You could also just try your luck with a manual merge using the patch
- as your guide.
+ 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, with the intent of holding Scripts specific files
if they become necessary.
- * .scripts/lock (generated) which locks an autoinstall during upgrade
+ - .scripts/dsn, overriding database source name