This page is intended to be updated and maintained by the team.
The goals of this group
- Remove technical and workflow difficulties from the work of the people working on the Drupal.org redesign.
- Give themers a good place to work, where they get feedback about what they do.
- Give module developers a way to test their stuff on a real site.
- Provide a stable and recreatable environment
- Work out migration paths for code, content, and data so that we have a smooth process to deployment.
- Keep the sites on stagingvm.drupal.org working right.
Tasks that a redesign admin might take on
- Troubleshooting a site problem on staging*.drupal.org
- Reloading databases with a refreshed version
- Preparing a site database dump for people to use on their own machines
- Preparing a canned "appliance" for themers to work with
- Handling the issues in the issue queue on component "staging.drupal.org"
- Supporting people who are running a d.o clone on their own local box for development.
Current Assignments
- Content migration: Ezra
- Appliance/Desktop: Ezra/Jonathan
- Database updates: Jonathan
Servers that we use
We have two virtual machines that are dedicated or partially dedicated to us. They're both in the Oregon State University Open Source Lab (OSU OSL). Both of these machines are running gentoo, which is just another linux, but has some quirks that will be unfamiliar to those coming from Debian/Ubuntu or CentOS/Redhat.
- stagingvm.drupal.org has the sites staging1 through staging10.drupal.org, which are clones of drupal.org running on the redesign code. It also has api.drupal.org, drupal.org, groups.drupal.org, and localize.drupal.org sites set up for actual staging of the redesign code.
- stagingdb.drupal.org has the mysql database server used for all the sites. It also serves as a solr server and perhaps some other tasks for some d.o infrastructure needs.
Contacts and resources
- Most conversation about this goes on in the Infrastructure issue queue marked component=staging.drupal.org. You should probably subscribe by email to the infrastructure queue.
- Immediate needs are in the IRC #drupal-infrastructure channel. At least some of you should plan to be there most of the time. However, not much happens, and this hasn't been a big job. In IRC you will find
- Amazon, who is running this redesign project and knows lots of stuff and has lots of contacts.
- basic`, who is the fantastic OSU OSL intern responsible for these boxes. He's quite responsive and can get many problems solved for you.
- nnewton, a key administrator of the Drupal infrastructure. Avoid bothering him until you need to. He has lots of fires going.
- The channel as a whole is quite responsive, so it's worth just opening your mouth there.
- DamZ knows everything about everything. He's certainly the technical lead of the redesign effort as well. He also set up and maintains the staging_api, staging_drupal, staging_groups, and staging_localize sites.
- rfay and calebg are former members of the administrators group who can help you get a grasp of the history of these staging boxes and why things were done the way they were done. calebg has a good grasp of what's happened with branching and merging, and the plans for this going forward.
- The Drupal.org Redesign Implementers group has the current status and history of the effort. In the Redesign Implementers Guide you'll find instructions about how to checkout the right branch of code and how to use modules and themes in a sandbox environment on a shared site.
Details and quirks
- Admins should already have ssh into both the machines and sudo on those machines. If you don't, you can find basic` in IRC.
- Updating svn is done like this. Go to /var/www.
sudo -u apache ./svnupdate_everywhere.sh. (The reason it has to be run as apache is that updates are often done by users using the web interface at http://staging*.drupal.org/update_themes.php and that results in a permissions dance when you use svn.) - Database updates:In /var/www
./drush_everywhere.sh updatedb - staging_drupal_org module: The staging_drupal_org module does the various things that need to be done to deploy a staging site. It turns off some modules, makes some adjustments, and sets administrator access for a long list of people. When it needs updating, it gets updated in svn, svn gets updated on the sites (with
sudo -u apache ./svnupdate_everywhere.sh, and then the updatedb gets run with./drush_everywhere.sh updatedb. To update the list of admins:- In your svn checkout, add to the administrators list in the .install in staging_drupal_org.
- Increment the number of the last hook_update_N() (which is the one that does the admins; make it happen on updatedb)
- Check it in
- On stagingvm:
cd /var/www
sudo -u apache ./svnupdate_everywhere.sh
sh drush_everywhere.sh updatedb
- drush is installed, but you should know that due to a patch quirk on the version of Drupal code we're using, you don't see the "are you sure you want to" prompt. Therefore, always use
drush -y - You've all been around, so you know there's always a better way to do something. It's OK to do things better. When you find something you don't approve of and you have the time to make it better without destabilizing things, do it.
- cron runs every 5 minutes to update the modules and themes. It runs some scripts in /usr/local/sbin that do the work that needs to be done.
- settings.php: Note that the settings.php that actually gets used is the one in sites/staging*.drupal.org/settings.php, not the one in sites/default. This can be confusing.
- Theming and module workflow: Note that in general the actual workflow to get something into svn has been to post patches to the relevant project and get it approved there. You'll want to drop in and take a look at these projects:
- Redesign
- Blue Cheese (the new theme)
- Drupal.org customizations (where the drupal_org module is maintained
Again, this page is a wiki, intended for you to update and maintain. More pages can be added if necessary. Please fix things that are wrong. Please add things that are missing.