-The Git Autoinstaller
-
-TODO NOW:
-
-- Add support for mypristine workflow
-- Make a nicer backtrace if not in a Git working copy directory
-- 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.
-- Wizard needs a correct arch/ setup
-- The wizard command, when not on scripts, should automatically SSH to
- scripts and start executing there?
-- Write the code to make Wordpress figure out its URL from the database
-
-- Plugin architecture
- http://peak.telecommunity.com/DevCenter/setuptools#dynamic-discovery-of-services-and-plugins
- http://peak.telecommunity.com/DevCenter/PkgResources#entry-points
- https://xvm.mit.edu:1111/trunk/packages/invirt-base/python/invirt/authz.py
- https://xvm.mit.edu:1111/trunk/packages/xvm-authz-locker/setup.py
- http://pylonshq.com/docs/en/0.9.7/advanced_pylons/entry_points_and_plugins/
+- 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
+ 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.
- 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
-- Replace gaierror with a more descriptive name (this is a DNS error)
+- [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.
-- Pre-emptively check if daemon/scripts-security-upd
- is not on scripts-security-upd list (/mit/moira/bin/blanche)
-- 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.
+- [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
- - 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
+ - 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
- - Code annotation!
- 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
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:
+- [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
+ - 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:
Committer: Real Name <username@mit.edu>
Author: lockername locker <lockername@scripts.mit.edu>
-NOTES:
-
-- 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 after
- deployment.
-
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
+ - get-homedirs.sh. which needs to be run as root on scripts. Store
+ in /mit/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. [ see doc/upgrade.rst ]
-
- [ENTER HERE FROM CREATING A NEW REPO]
-
- 9. Push all of your changes in a public place, and encourage others
- to test, using --srv-path and a full path.
+ - parallel-find.pl, and the resulting
+ /mit/scripts/sec-tools/store/versions
[ XXX: doc/deploy.rst ]
GET APPROVAL BEFORE PROCEEDING ANY FURTHER;
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 ]
+[ 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