Accounts and Resources

Following are all the accounts and resources used by the FSP IT infrastructure. All account passwords are centrally stored at the Clipperz site, and administrators have the master password to this account to recover individual username / password pairs for other accounts.

FSP Web Standards

This page will evolve continuously. Refer also to the Create Content Procedure for step-by-step instructions for creating pages and images.

Metadata

Naming Conventions

For page titles, file names, and path aliases, do not abbreviate unnecessarily. Use longer, descriptive names and complete words. These are more easily recognized by your fellow content maintainers and picked up by search engines. Especially for file names consisting of many words, start with the most significant word (the reverse of English grammar). Examples:

• Title: "FSP Web Standards" rather than "Standards"
• Title: "Operations Meeting Minutes 2005-12-31" rather than "December Meeting Minutes"
• Path alias: "/it/web_standards" rather than "webstds"
• File name: map_nh_large.gif rather than large_nh_map.gif

Every path alias should begin with the Center to which the page will be assigned. At present there are ten Centers, which generally correspond to one of the FSP's departments: org, press, news, events, merchandise, photo, nhinfo, community, volunteer, advertising, and it. Paths should be *entirely* in lower case.

Keywords, Categories, and Taxonomy

Pages should be assigned a Center and, if appropriate, an Issue, Strategy, and/or State. These help to categorize pages for easier searching.

Layout

Choose a one or two-column layout depending on the nature of your content. As a general rule, one-column layouts are appropriate for "documents" (e.g. something you might bang out in MS Word), while two-column layouts are better for home pages, or other information-dense pages. But narrower columns are also easier to read, as the human eye has a hard time following long lines of text and finding the beginning of the next, so consider using two columns even for ordinary documents.

Try to include a photograph or other graphic! These catch the user's eye, and make the page more memorable. However, keep all images less than 500px in width to avoid breaking the layout at screen widths of less than 1024.

Linking

When linking to another page on the FSP site, leave off the domain name, e.g. use /org/presidentscorner instead of http://freestateproject.org/org/presidentscorner.

Semantics Before Style

Avoid forcing styles--concentrate primarily on the content and not its style. Use *semantic* tags like H1, H2, p, ul, ol, strong, etc. That way the look and feel of the entire site will be consistent, even if changes are made.

Colors

• Dark Blue (logo): Blue (logo): PMS 2766 C  
  Approximate hex: #2b265b
  
• Tan: Tan (logo): PMS 465 C
  
  Approximate hes: #c1a875
  
• Light Gray: #DDDDDD = RGB (121, 121, 121)

How to set up a development instance

Architecture

There are four possible instances in the FSP development environment:

1. dev.freestateproject.org
2. dev1.freestateproject.org
3. dev2.freestateproject.org
4. dev3.freestateproject.org

Each of these points to a folder link (note: not a folder, but a link that can point to folders) in the /home/freestat/public_html directory on the development server, and this folder link is named after the development instance (i.e. dev, dev1, ....). Each of these instances is also associated with a unique database named after the instance (freestat_dev, freestat_dev1, ...), and a unique user with the same name as the database.

An anonimized copy of the production database is copied to the development environment once a week, to /home/freestat/anondb/fsp_anon.sql.gz. This copy can also be generated at will when required. On the development server, an hourly cron batch processes any fresh copies of this file into four files ready to be loaded into any of the development databases (named dev.sql, dev1.sql, etc.).

Procedure

To bring up a new instance of a development environment, follow these steps:

1. Pick one of the four development environments. Check with the FSP IT mailing list if anyone else is using it. For the following steps we assume that the dev1 environment was chosen.
2. Get the database password from the current settings for the selected development environment (e.g. in dev1/sites/dev1.freestateproject.org/settings.php).
3. Reload the database from the latest anonymized production database copy (note that the password will be requested):
   

   cat ~/anondb/dev1.sql | mysql -u freestat_dev1 freestat_dev1 -p
   

4. Export from the source repository the branch of code that will be used in this environment into the public_html folder. E.g. if the trunk will be used (see the source control topic for the value of $FSPSVN):
   

   cd ~/public_html
   svn export $FSPSVN/trunk

5. There will be a folder named "~/public_html/trunk". Rename that to something unique, in order that it will not be overwritten by another developer:
   

   mv trunk dev_stuff

6. Set the database password in the new copy of the code to the correct password for the dev environment (in ~/public_html/dev_stuff/sites/dev1.freestateproject.org/settings.php).
7. Note where the current folder link points to:
   

   ls -l ~/public_html/dev1
   

8. Move the appropriate folder link to point to the new code:
   

   rm ~/public_html/dev1
   ln -s ~/public_html/dev_stuff ~/public_html/dev1

9. Remove the folder that the folder link pointed to previously (e.g. old_dev1), unless it needs to be kept around for some purpose:
   

   rm -rf ~/public_html/old_dev1

Infrastructure

Production Host

Development Host

DNS

DNS hosted at EasyDNS.

Email, Lists, and Forwarders

Monitoring

The site is being monitored for availability via a basic free monitoring account at HostTracker. It should be considered to upgrade this account to a paid account with a higher poll frequency and content check features when the service has been tested thoroughly. The details are:

Registration Management

This documents the current registration process, the transfer of registrations between the original system, and the history of registrations. It is a work in progress.

User Types

1. Member: A person that registers with the FSP as either a Participant, Pioneer, or Friend
   
2. Participant: A person not residing in NH, that undertakes to move to New Hampshire.
3. Pioneer: A person wishing to support the FSP, but already residing in New Hampshire.
4. Friend: A person that does not intend to move to New Hampshire, but is supportive of, or interested in, the movement.
5. User: Anyone that has a user account in Drupal. Not all users may have registered as a member of the FSP.

Statistics

Already in New Hampshire

This count is shown below the participant count in the site header. The count should consist of the following:

1. 256 pre-vote residents of New Hampshire (per Seth Cohn).
2. All participants that subsequently to registration moved to New Hampshire. In practice, the system considers anyone that has a type of "Participant", but a resident state of "New Hampshire", or, has a value of "Already Moved" in their move date registration field as part of this group.
   

Release Management

Release Procedure

The following steps must be followed when releasing a new version of the Drupal site code. If needed, the site can be made unavailable during this procedure via the admin maintenance setting in Drupal. Also, major releases may require a database backup to precede this procedure.

1. Merge all the changes going into the release (see the source control procedure).
2. Copy the web site subversion repository trunk directory to a release tag (e.g. tags/release_3.16).
3. ssh into the webadmin@freestateproject.org account.
4. Export the release into /var/www:
   

   cd /var/www
   svn export $FSVN/tags/release_3.16
   mv release_3.16 www-r3.16
   

5. Set the database password for the new release in www-r3.16/sites/www.freestateproject.org/settings.php, using the current password in the same location in the www-r3.15 folder.
6. Move the site link over to the new release (it would be pointing at www-r3.15 when we start):
   

   rm www.freestateproject.org; ln -s ./www-r3.16 ./www.freestateproject.org

7. Test by reloading the front page. If a problem occurs, switch back to the previous version by:
   

   rm www.freestateproject.org; ln -s ./www-r3.15 ./www.freestateproject.org

8. The previous version should not be erased immediately, but kept around as a fall-back position. Older releases (e.g. 3.14 and older in our example), can be deleted at this point.

Roadmap and Status

Find attached a spreadsheet showing the development roadmap and status. The IT Plan for 2006 is also attached for reference.

Mission

The FSP Information Technology Department (FSP IT) supports the FSP mission by providing IT services to all FSP stakeholders as represented by the various FSP departments. These IT services are primarily content and functionality that are found on the FSP web site. Every web site function shall have an owner among the FSP leadership, and every FSP leader should have a clearly defined area on the web site which he maintains and improves. As the FSP is an activist organization facing significant challenges and competition, FSP IT services should reflect best practices among the FSP's peers: namely, charitable, libertarian and activist organizations.

Goals

As a virtual, decentralized, web-based volunteer organization that owes its conception, existence, and success to the Web, the FSP needs to make maximum use of web technologies. Googling the buzzword "Web 2.0" will provide a wellspring of inspiration. Throughout this document, functionality and goals are divided into three categories: Content, Community, and Collaboration.

Primary goals are:

1. Consolidate applications and servers into one Content Management System (CMS) on one server in order to facilitate administration, share data, and provide a coherent platform on which to build future functionality.
2. Reorganize content according to the Center concept, with specific Departments (and individuals) responsible for each Center. Shift the emphasis from dry information towards persuasion, especially promoting New Hampshire and community.
3. Build community with social networking features, including rich profiles, buddy lists, organic groups, and karma-based reputation tracking.
4. Support decentralized project collaboration among the FSP community members (Participants and Friends), in order to make better use of our greatest resource.

Source control procedures

The FSP Drupal site code is under version control. All items contributing to site functionality outside of the "files" subdirectory, and outside the database are kept in the source repository. Specifically included are:

1. All files provided with the Drupal software distribution.
2. All contributed modules from third parties.
3. All custom modules.
4. All theme files and supporting collateral (logo's, visual elements, style sheets, etc.).
5. All configuration files.

Source and Release Control

All releases of code are made from the source repository. Changes directly to the site are deprecated.

In the rare event where there was no alternative to making an emergency change directly on the site, the FSP IT group mailing list has to be notified immediately, with a description of the change and a list of files changed. The changes will then be accomodated after the change, and the emergency release tagged after the fact. Needless to say, this should be avoided, as it can lead to changes being lost with resultant time wasted.

Repository Access

The source code repository is maintained with subversion, and the subversion server can be accessed at http://svn2.assembla.com/svn/fsp. A local svn client (see the support section below) will be needed to access the repository, and a valid username/password combination will be needed (mail a request to the FSP IT mailing list to get one).

Repository Structure

The structure was chosen because it lends itself to a loosely-coupled environment like the FSP IT group. The main features of the structure are:

1. A source tree "trunk" where all changes are eventually merged to, and where all releases are made from. This represents the source code in the production environment.
2. All development and non-trivial defect fixes are made on branches - one branch for each line of development or defect. This allows several contributors to work at their own pace on unrelated functions, and then have their contributions released without influencing the timeline of other releases.
3. All branch points, merge points, and releases are tagged.

Inside the repository, there is the high-level structure below:

Examples

Here are a couple of examples using the command-line version of subversion. In the examples, $FSVN is used as shorthand for the repository URL given above.

Creating a new branch & checking it out

First, create the starting point tag for the branch (useful to compare changes to where the branch started from):

svn cp $FSVN/www/trunk $FSVN/www/tags/dev_organic_start -m "Created dev_organic branch start tag"

Then, create the branch itself:

svn cp $FSVN/www/tags/dev_organic_start $FSVN/www/branches/dev_organic -m "Created dev_organic branch"

And finally check it out locally:

svn co $FSVN/www/branches/dev_organic

Checking out the trunk, merging a branch, and creating a release

First get the current trunk, which is usually equal to what's in production:

svn co $FSVN/www/trunk

Then, merge the branch, using the branch start tag and current tip:

cd trunk
svn merge $FSVN/www/tags/dev_organic_start $FSVN/www/branches/dev_organic .

Review the merged changes, ensure there are no conflicts, and confirm that they make sense:

svn diff | less

Then tag the pre-commit point, commit the changes, and tag the post-commit point:

svn cp $FSVN/www/trunk $FSVN/www/tags/dev_organic_premerge -m "dev_organic pre-merge tag"
svn commit -m "Merged dev_organic branch"
svn cp $FSVN/www/trunk $FSVN/www/tags/dev_organic_postmerge -m "dev_organic post-merge tag"

Learn More

There is a subvrsion book available at svnbook.red-bean.com. The main subversion site is at subversion.tigris.org, where a list of clients for various platforms can be obtained, including TortoiseSVN at tortoisesvn.net, which is a popular GUI client.

Backups

John Companies

The hosting company backs up the following directories on a daily basis:

Database backups

Each database on the server is backed up via a daily webadmin cron process The backups are written to the /home/webadmin/db-backups directory. The script takes care of rotating files, and keeping weekly and monthly backups. Monthly backups need to be cleaned out from time to time.

The following backups are kept, in a separate file for each database:

1. A daily backup for each of the past 7 days, made each morning at 1:30 AM PST
2. Five weeks worth of weekly backups, made every Saturday morning.
3. Monthly backups made on the first of the month, kept indefinitely (should be erased by admin if repository grows too large)

Offsite backups

Offsite backups of the database and files folders are made daily via a webadmin cron rsync:

1. The daily database backup set is copied via rsync to the fspadmin@loomtree.com account, in the ~/dbbakwebadmin folder.
2. The drupal files folder content is copied via rsync to the freestat@dev.freestateproject.org account, in the ~/prdfilebak folder.