-The Git Autoinstaller
-
-TODO NOW:
-
-- Make wizard install accept appname-head (so that you can do a test with
- head, and do things without tags). Also make it accept commit hashes.
- In fact, let it accept any committish. Figure out what to do if we
- do a test script with x.y.z when we REALLY mean x.y.z-scripts. XXX!!!
-- Do early validation of inputs for configuration
-- Let 'wizard configure' be interactive
-- Parse output HTML for class="error" and give those errors back to the user,
- then boot them back into configure
-
-- Replace gaierror with a more descriptive name (this is a DNS error)
-
-- 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)
-
-- Web application for installing autoinstalls has a hard problem
- with credentials (as well as installations that are not conducted
- on an Athena machine.) Possible solutions include asking the user
- to SSH into an athena machine and run a bunch of commands, or writing
- a Java applet (possibly in Clojure or Scala) which gets filesystem
- permissions and then performs the operations.
+- [SCRIPTS] MediaWiki 1.9.3 and 1.6.7
+
+- 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.
+
+- Repeated --continue from a temporary directory doesn't really work...
+ (or maybe this interacts /really/ poorly with restore, in which case
+ restore should ensure all files are present before actually doing the
+ restore)
+- Should be able to run restore from /tmp directory
+- Show progress or something when upgrading
+- Allow 'sticky notes' for future upgraders to notice
+- Blacklist should allow an easy way for a user to override it,
+ described in the error message.
+- .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
+
+- gct has accidentally set the +x bit on a lot of files >.>.
+- Make gct do the right thing with no arguments
+- Rerere support doesn't actually work
+- Utility scripts gct should support multiple filenames
+- "Version 3.0.0 doesn't exist; did you mean 3.0?"
+- util.fetch() should use urllib under the hood, not httplib. Code
+ has to be changed. We should log if we get redirected.
+- 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.
+- The need to run egg_info can make things a little fragile when pulling
+ if you forget. How can we make this less easily forgotten?
+- wizardResolve* files seem to get left in tmp en-mass, and we don't
+ know why.
+
+- Plugin-ify! Hook-ify! In more detail, applications should all be moved
+ out into plugins, scripts specific behavior should be moved into
+ plugins, and hooks need to be made available so that we can exert
+ the correct level of control.
+
+- [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
- - 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. Also,
- the Report object should operate at a higher level of abstraction
- so we don't have to manually increment fails. (in fact, that should
- probably be called something different). The by-percent errors should
- also be automated.
- - Move resolutions in mediawiki.py to a text file? (the parsing overhead
- may not be worth it)
- - If a process is C-ced, it can result in a upgrade that has
- an updated filesystem but not updated database. Make this more
- resilient
- - 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
- Other stuff
- - Make single user mass-migrate work when not logged in as root
+ - 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
- 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:
+
+- [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()
-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
+[ 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
-
-* 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.
-
- 2. Checkout the pristine branch
-
- 3. Run wizard `prepare-pristine APP-VERSION`
-
- X. Commit, with name "Appname x.y.z"
-
- 4. Checkout the master branch
-
- 5. 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
-
- X. Commit, with name "Appname x.y.z-scripts". This is going to be
- amended.
-
- 6. 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. Commit with --amend, and
- propagate back to your local copy (git reset --hard HEAD~; git pull afs).
-
- [ENTER HERE FROM CREATING A NEW REPO]
-
- 7. Check if there are any special update procedures, and update
- the wizard.app.APPNAME module accordingly. If this is the first
- time you are performing an upgrade, implement upgrade() in your
- Application class. (XXX: extended instructions here). Test
- the new update procedure using our test scripts (preferably
- on a scripts server). Check this page for more info on our
- integration tests:
-
- http://scripts.mit.edu/wizard/testing.html#acceptance-tests
+ - get-homedirs.sh. which needs to be run as root on scripts. Store
+ in /mit/scripts/sec-tools/store/scriptslist
- 8. If you have any further changes, git commit --amend, and finally
- tag as v1.2.3-scripts (or scripts2, if you are amending an install
- without an upstream changes)
-
- 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;
THIS IS PUSHING THE CHANGES TO THE PUBLIC
12. 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
-
- You could also just try your luck with a manual merge using the patch
- as your guide.
-
+[ 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.
-* Making the module files for a new application
-
- 1. Create a wizard/app/APPNAME.py file. Create an object Application
- inheriting from wizard.app.Application (check existing modules for
- the boilerplate code).
-
- 2. Implement download()
-
- 3. Create a git repository with `git init`
-
- 4. Use `wizard prepare-pristine APP-VERSION`
-
- 5. `git commit -asm "APP VERSION"`
-
- 6. Check if any patches are needed to make the application work
- on Scripts (ideally, it shouldn't.) Pre-existing patches
- live in /mit/scripts/deploy/APP-VERSION/ directories.
-
- 7. Run `wizard prepare-new` to setup common filesets for our repositories.
-
- 8. If you are running a PHP script, there is usually a php.ini file
- that we package. You can see previous instances of this patch
- at /mit/scripts/deploy/php.ini/ as well as in the repositories
- of any already migrated scripts. We hope to make these changes
- unnecessary once PHP 5.3 arrives.
-
- 9. Do an initial commit (we're gonna be amending the hell of this)
- using `git commit -asm "APP VERSION-scripts"
-
- 10. Implement install(). Test using `wizard install APP`; you won't
- be able to do a version-specific install with `wizard install APP-VERSION`
- until you generate a tag (which will become out of date once you
- amend the commit.)
-
- 11. Push your changes to a directory accessible in the production environment.
- In the case of scripts, this is equivalent to your AFS homedir, and
- the production environment is a scripts.mit.edu. We're going to
- perform a configuration in the production environment to extract
- out the canonical configuration files.
-
- 12. On the production server, call your wizard to perform an installation.
- Inspect the generated configuration files, and implement:
- - extractors
- - substitutions
- These are dictionaries of functions that perform extraction
- and substitution of variables from config files. You don't
- actually have to hand code them; you can app.make_extractors
- and app.make_substitutions on a common dictionary. Check
- out wizard/app/__init__.py for more information on this
- format, as well as other files for samples.
- (XXX: extended instructions here)
- - parametrized_files
- These are any files that contain WIZARD_* variables
- - checkConfig()
- This is a simple, fs based check on whether or not the application
- was configured. Usually checking if some generated config file
- is present is sufficient
- - detectVersion()
- You might be able to reuse machinery from extractors (namely, whatever
- function you were using to generate regular expressions), or you might
- need to code a custom regular expression to parse this out.
- - deprecated_keys?
- Usually you won't need this; use it if there's a configuration variable
- that needs to get parametrized, but isn't actually necessary and
- gets obsoleted in a later version. You probably won't know if that's
- the case until later.
-
- 13. With these implemented, `wizard prepare-config` should now work if you run
- it on the installed copy. The configuration file should now contain only
- generic WIZARD_* variables, and no user-specific config. If it is, your
- script was buggy; try again.
-
- 14. The current changes in the working copy should be merged in. Add any new
- files, and then `git commit --amend`.
-
- 15. In your local copy, you can pull the changes by doing `git reset --hard HEAD~`
- and then a `git pull` from the relevant source. Otherwise, Git will complain
- about a non-fast-forward.
-
- 16. Congratulations! You've implemented the installation code for a new install.
- Now goto "ENTER HERE FROM CREATING A NEW REPO" and finish the rest of the
- instructions.
+ - .scripts/dsn, overriding database source name
scripts.mit.edu / wizard.git / blobdiff