-The Git Autoinstaller
-
-TODO NOW:
-
-- geofft/web_scripts.compromised/wiki* have malformed
- .scripts-versions; user friendly error if parse error
- there happens
-- Something needs to be done if disk quota is exceeded:
- - Catch the OSError and throw a domain-specific error
- so massmigrate can deal gracefully
- - Perform an added memory calculation, check this against
- remaining quotai, and bail out if it's within some
- percentage of their remaining quota
- - Checks should also be performed against the partition
- X with the new --shared flag this may not be necessary
- as repos weighs less than 200K
-- Should write to a "processed" file to make resuming with
- unexpected failure faster.
-- Check how many autoinstalls are missing w bits for
- daemon.scripts
-- Whiteboard the flow for performing an upgrade on a single
- install. How assisted does it need to be?
-- Conduct migration tool testing (check andersk, geofft for
- sample MediaWikis)
-- Set up migration server
-- Run parallel-find.pl
-- Migrate all mediawikis
-- Wordpress needs to have a .scripts/update script written for
- its latest version
-
-NOTES:
-
-- 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.
-
-- summary and info are still not using loggers. Maybe they should,
- maybe they shouldn't
-
-- We should think about stewarding the amount of objects we use
- by using some arcane Git flags and objects/alternates. Much
- research is needed.
+- Make scripts_plugin email heuristic less stupid, or maybe even ask for an
+ email. This is tracked as Scripts #224 (this issue) and Scripts #193
+ (tracking a contact address).
+- Current parallelization probably does a bad job distributing
+ working tasks over different components of the pipeline. Fix
+ this by adding jitter? Trying to smear things out?
+
+- Test head doesn't do quite the right thing with version numbers
+ (shouldn't git describe, instead should give a version infinitely
+ in the future.)
+- Strategy introspection and disabling.
+- prepare-config (and others) create .wizard dir even
+ when not strictly necessary
+- Bug out immediately if tags are not present in the master tip
+ of the repository
+- pending doesn't seem to get written out properly sometimes (or
+ it's being deleted); this makes it hard to --continue on the
+ event of an upgrade failure. Also, we seem to bounce back to
+ the production copy to check pending even when we run --continue
+ from the working dir.
+- Newline checks are /really really/ expensive on AFS; see if
+ we can minimize them or something. Right now, we're testing
+ a fix where we don't clone with --shared.
+- Replace .split("\n") with .splitlines()
+
+- Need to fix existing repo history? (not adding extra commits;
+ that'll be more difficult)
+
+ git rebase -i -p --root --onto COMMITID
+
+ This won't work if you need to change the very root of the
+ repository. You'll probably end up with conflicts and have
+ to manually resolve everything afterwards.
+
+ But usually you won't need --root --onto unless you really
+ fucked up the pristine branch. If you just need to change
+ the scripts spine,
+
+ git rebase -i -p COMMITID
+
+ should work.
+
+- [SCRIPTS] MediaWiki 1.6.7, 1.9.3 and 1.10.0
+
+- geofft comments:
+ "Connection to scripts.mit.edu closed" is confusing (tracked #393)
+ the URL should be easier to copy and paste, which means we should
+ move it out of dialog
+ We should ... upgrade our autoinstaller
+ Apparently installing WordPress updates or themes never indicates
+ completion, and just says "Downloading..", and you have to guess
+ when it's done
+
+- [SCRIPTS] phpBB
+ - phpBB or phpbb? (right now it's the former)
+ - need an upgrade story; srv needs more versions
+ - need a story about install/ contrib/
+
+- Give users a "certificate" of their merge, which they can
+ use to reuse that merge commit if something unrelated fails.
+
+- Human readable quota output
+- Nice error message on --continue if you forgot to git add your
+ resolved file (look for conflict markers)
+- The merge interface is a kind of major UI disaster; you won't
+ be able to use it unless you know how Git works. Also, the
+ merges can be quite difficult to resolve if upstream has made
+ large formatting changes like reindenting. We may also consider
+ providing a --rebase option, which seems to do better when
+ big problems like this show up.
+
+- Better mass-* support for just one user (this includes letting
+ a user mass upgrade just his own autoinstalls)
+
+- Show progress or something when upgrading
+- Allow 'sticky notes' for future upgraders to notice
+- .wizard/url semantics are subtly wrong: in particular, if we
+ explicitly configure a URL at install, we should be able to
+ detect this URL as baked in from the configuration
+
+- Rerere support doesn't actually work
+- "Version 3.0.0 doesn't exist; did you mean 3.0?"
+- Be a little more intelligent when perform web checks; for example,
+ if we get a forbidden message, that probably means we go the right
+ address but it's blocked off; if we get a 404 message, that probably
+ means wrong address. Account Unknown is something particularly good
+ to check for.
+- Wordpress module can do something intelligent if we get redirected
+ to the installation page.
+- wizardResolve* files seem to get left in tmp en-mass, and we don't
+ know why.
+
+- [SCRIPTS] 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
+
+- [SCRIPTS] 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.
+
+- [SCRIPTS] 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
+ - util.fetch() should use urllib under the hood, not httplib. Code
+ has to be changed. We should log if we get redirected.
+
+- Other stuff
+ - Add support for mypristine workflow
+ - 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.
+
+- [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.
+ - Whatever happens here should be used to improve user.email()
+
+[ XXX: metadata.rst ]
+
+COMMIT MESSAGE FIELDS:
+
+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
+
+GIT COMMIT FIELDS:
+
+Committer: Real Name <username@mit.edu>
+Author: lockername locker <lockername@scripts.mit.edu>
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/sec-tools/store/scriptslist
-
- - 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.
-
-* The new procedure for generating an update is as follows (this is
- also similar to procedure for creating these repositories):
-
- 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 (rm -Rf *, and then delete
- any dot stragglers. A script to do this would be handy)
-
- 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 THE FIRST TIME]
- Apply the scripts patch that was used for that version here
- (usually patch -p1 < patch)
-
- 10. Check if there are any special update procedures, and update 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.)
+ - get-homedirs.sh. which needs to be run as root on scripts. Store
+ in /mit/scripts/sec-tools/store/scriptslist
- 11. Commit your changes, and tag as v1.2.3-scripts
+ - parallel-find.pl, and the resulting
+ /mit/scripts/sec-tools/store/versions
- If you're setting up a repository from scratch, stop here, and
- repeat as necessary
+[ XXX: doc/deploy.rst ]
+ GET APPROVAL BEFORE PROCEEDING ANY FURTHER;
+ THIS IS PUSHING THE CHANGES TO THE PUBLIC
- XXX: Should we force people to push to the real repository at
- this point, or just make the repository that the script pulls
- stuff out of configurable? (Twiddling origin can get you a
- devel setup with no code changes)
+ 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.
- 12. Run the "dry-run script", which uses Git commands to check how many
+ 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.
-
- 13. Run the "limited run" script, which applies the update to our
- test-bed, and lets us check the basic functionality of the update.
- This can include a script that lets us update a single directory
- with verbose output.
-
- 14. Run the "deploy" script, 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.
-
- 15. Run parallel-find.pl
-
-* For mass importing into the repository, the steps are:
-
-[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
-# 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
-# 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
-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
-[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
+ 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.
+
+ 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/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:
-
- [IF THIS IS THE FIRST UPDATE]
- mkdir .scripts
- echo "Deny from all" > .scripts/.htaccess
- touch .scripts/update
- chmod a+x .scripts/update
- # OPERATION: create the update script
-
- * .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.
-
-* 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 .scripts directory, with the intent of holding Scripts specific files
+ if they become necessary.
-* 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.
+ - .scripts/dsn, overriding database source name
-* Make 'wizard summary' generate nice pretty graphs of installs by date
- (more histograms, will need to check actual .scripts-version files.)
scripts.mit.edu / wizard.git / blobdiff