TODO NOW:
-- The calling web code invocations are a mess, with stubs living
- in the install, deploy modules and the real deal living in util. Furthermore,
- we use the scripts-specific heuristic to determine where the app
- lives, and the only reason my test scripts work is because they
- get manually fed the domain and path by my environment variables.
-
- We will record the URL used for the initial installation, and save it in
- .scripts/url. If autodetection in either direction is
- available, we verify this value against the actual file path the installation
- lives in (for the scripts case, we can do a file-level comparison because we
- know the web root of any given file). If they mismatch, we error out
- and have someone manually resolve the problem. If autodetection is not
- available, we use the saved .scripts/url for operations.
-
-- wizard install wordpress should ask for password
-- Test code should auto-nuke the database using `wizard remove` before doing a new install
-- git diff :1:$file :2:$file to find out what the user did, or is it :3:?
-- Document how to fix a broken upgrade
-- php.ini needs to get substituted!
-- 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
-- Get rid of our custom sizing code and use dialog's built-in sizing (i.e. width=0, height=0).
- Maybe our sizing code is superior, maybe not.
-
-- 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)
+- 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.) 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.
+ 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
- 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
+ - 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.
+
+[ 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
+ - get-homedirs.sh. which needs to be run as root on scripts. Store
+ in /mit/scripts/sec-tools/store/scriptslist
- 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
- A .scripts directory, with the intent of holding Scripts specific files
if they become necessary.
+ - .scripts/dsn, overriding database source name
+
scripts.mit.edu / wizard.git / blobdiff