TODO NOW:
-- Make parallel-find.pl use `sudo -u username git describe --tags`
- to determine version
-- Make the installer use 'wizard install' /or/ do a migration
- after doing a normal install (the latter makes it easier
- for mass-rollbacks).
-
-- Better error message if daemon/scripts-security-upd
- is not on scripts-security-upd list
-
-- Fix retarded logging mechanism
- - This is interesting because the non-retarded way would be
- to have each subprocess send data through stdout, but
- this runs the risk of filling up the tubes. Maybe just
- create a log directory and give each process different
- files.
-
-- The great initial deploy:
- - Turn on mediawiki new autoinstaller
- - Migrate all mediawiki installs
- - Build research scripts, determine if a re-migration is necessary
-
-- Make upgrade and install take version as a parameter
+- Make it faster
+ - Wipe temp directories if the upgrade succeeds
+ - Put temp directories on tmpfs before merging, then move to disk
+ if it fails and needs resolution. /var/run is a pretty good
+ choice if your running as root, not so good if you're not. Find
+ other common tmpfs locations (mount | grep tmpfs) and perhaps
+ check some common ones.
+ - Certain classes of error will continually fail, so they should
+ put in a different "seen" file which also skips them, unless
+ we have some sort of gentle force
+
+- Keep my sanity when upgrading 1000 installs
+ - Distinguish between errors(?)
+ - 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)
+ - Snap-in conflict resolution teaching:
+ 1. View the merge conflicts after doing a short run
+ 2. Identify common merge conflicts
+ 3. Copypaste the conflict markers to the application. Scrub
+ user-specific data; this may mean removing the entire
+ upper bit which is the user-version.
+ 4. Specify which section to keep. /Usually/ this means
+ punting the new change, but if the top was specified
+ it means we get a little more flexibility. Try to
+ minimize wildcarding: those things need to be put into
+ subpatterns and then reconstituted into the output.
+ Example:
+ Input:
+ <<<<<<<
+ ***1***
+ =======
+ upstream
+ >>>>>>>
+ Output:
+ [1] # discard system string
+ Input:
+ <<<<<<<
+ old upstream
+ =======
+ new upstream
+ >>>>>>>
+ Output:
+ ['R'] # keep the new upstream string
+ # This would be useful if a particular upstream change
+ # is really close to where user changes are, so that
+ # the conflict pops up a lot and it's actually spurious
+ Input:
+ <<<<<<<
+ ***1***
+ old upstream
+ ***2***
+ old upstream
+ ***3***
+ =======
+ new upstream
+ >>>>>>>
+ Output:
+ ['R', 1, 2, 3] # should be evident
+ # it's not actually clear to me if this is useful
+ To resolve: do we need the power of regexes? This might suck
+ because it means we need to implement escaping. We might want
+ simple globbing to the end of line since that's common in
+ configuration files.
+
+- Distinguish from logging and reporting (so we can easily send mail
+ to users)
+ - Remove "already migrated" cruft that will accumulate if we do small
+ --limit and then increase.
+ - Logs aren't actually useful, /because/ most operations are idempotent.
+ Thus, scratch logfile and make our report files more useful: error.log
+ needs error information; we don't care too much about machinability.
+ All report files should be overwritten on the next run, since we like
+ using --limit to incrementally increase the number of things we run. Note
+ that if we add soft ignores, you /do/ lose information, so there needs
+ to be some way to also have the soft ignore report a "cached error"
+ - Report the identifier number at the beginning of all of the stdout logs
+ - Log files that already exist should be initialized with some sort
+ of separator THAT CONTAINS THE LOCATION OF THE INSTALL
+ - Don't really care about having the name in the logfile name, but
+ have a lookup txt file
+ - Figure out a way of collecting blacklist data from .scripts/blacklisted
+ and aggregate it together
+ - Failed migrations should be wired to have wizard commands in them
+ automatically log to the relevant file. In addition, the seen file
+ should get updated when one of them gets fixed.
+ - Log files need to have dates, since it looks like upgrades will be
+ multi-day affairs
+ - Failed migration should report how many unmerged files there are
+ (so we can auto-punt if it's over a threshold)
+ - Verification failures should be written to a report file, possibly
+ with short HTML fingerprints so we can inspect them easily and
+ numbers to look at the log files
+
+- 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)
-- Summary script should be more machine friendly, and should not
- output summary charts when I increase specificity
-
-Some other stuff to do in your copious free time:
-- Summary script should do something intelligent when distinguishing
- between old-style and new-style installs
-- 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`)
-- 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.
+- 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
+
+- Other stuff
+ - 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
/- 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
- The actual application's files, as from the official tarball
- - A .scripts directory, which contains the following information:
-
- * .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
-
- * .scripts/version (deprecated)
+ - 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.mit.edu / wizard.git / blobdiff