We'd like to thank our sponsors:

Linux - The Operating System of the 21st Century ^TM

Organization of the Group

Web Content Coordinator

The wording and content of the SVLUG Web site is under the Web Content Coordinator. Responsibility for adding and maintaining text and graphics belongs with and is delegated from this position.

The Web Content Coordinator is Rick Moen, who took over the position from Heather Stern. Heather was aided by Joyce Traugott.

Web Design Coordinator

The look and feel of the SVLUG Web site is under the Web Design Coordinator. (This was a new role added at the 4/27/1999 Web Team meeting, and currently unoccupied.)

The Web Design Coordinator was Amy Abascal. Real life has forced her away from volunteer projects, but we are still enjoying her Web site design.

Web Software Coordinator

The software that makes the system run, including the Lighttpd server, CGI programs, embedded PHP scripts and Web-related cron jobs, are under the Web Software Coordinator. Responsibility for adding and maintaining Web software belongs with and is delegated from this position.

Lisa Corsetti was the original Web Software Coordinator, and now has been helping with that role again, when she has time.

Web Team volunteers may work on content and/or software. Decisions that affect the whole SVLUG server should be run past the appropriate coordinator and/or reviewed on the Web-Team list. Any work that has to be done by / for SVLUG anyway should just be done. Use svn (Subversion) to make sure that changes can be tracked and reversed if necessary.

Software That Web Team Volunteers Use

• Linux (obviously)
• SSH — Secure Shell (SSH) is required to log into our server
• svn — the Subversion Version Control System (VCS). Tutorials elsewhere: 1, 2, 3, 4, 5, 6

SVLUG's Subversion ("svn") Mini-Tutorial

However, in reading the above-cited, sometimes exhaustive tutorials about svn generally, bear in mind that we really use svn only as in the following simplified workflow:

1. When you were given your shell account on www.svlug.org, you should have been put into /etc/sudoers. Attempt "sudo vi /var/svn/web/conf/passwd" (giving your shell password), to check, and add a line for your svn login if there isn't yet one. You also should have been appended to members of group "www-data" in /etc/group: Do "sudo vigr" to check.
2. Notice that your home directory contains symbolic links "www" and "site-docs". The latter is a shortcut to the live Web site's document root, /var/www/svlug-main/ . You will be doing all your maintenance work in the latter directory, i.e., editing the live site's files (which doubles as an svn "working area"), and then checking your changes/additions into svn, to add them to the repository (aka "repo").
3. You do not need to check out files in /var/www/svlug-main/ (the way one does in RCS). They're already checked out: /var/www/svlug-main/ is an svn working directory. Just start editing.
4. Prior to checking in changes on a file, to review your changes relative to the svn repository's latest revision, do:
   svn log filename
   You'll see a standard diff display of your working (i.e., saved, live file in the Web document root) versus the repository's head revision. FYI, the repository is stored inside /var/svn/web.
5. If you want to see the repository head revision's revision number, do:
   svn log filename1 | grep head
   More generally, "svn log filename1 | less" shows the file's full revision history.
6. When you wish to check in a file or files, do:
   svn ci -m "Your check-in message" filename1 [filename2...]
   The first time you do this, you'll be prompted for your svn password, the one in /var/svn/web/conf/passwd . Thereafter, it gets cached in, I believe, somewhere in ~/.subversion (your homedir's tree of subversion config files).
7. New files (one not yet in the repository) need to first be added with svn add filename1, before you can do a ci (check in) step.
8. If you ever make some particularly ghastly error in editing, it's possible to revert the file to any desired checked-in revision, retrieved from the repository. If you've not yet checked in changes:
   svn revert filename1
   This overwrites the working copy using the latest checked-in revision from the repository. If, by contrast, you've already checked in changes and want to revert to a prior checked-in revision, do:
   svn up -r [revision#] filename1
   Again, you can read svn log filename1 | grep head to find the revision you want.

Online svn tutorials dote lovingly on svn's many fancy capabilities that we normally don't use, including several complex schemes for working areas gaining access to remote repositories elsewhere. You certainly can use those complications if you wish, to, e.g., keep a local checked-out copy of our repo contents -- but you don't have to.

Web Content Tasks and Procedures

Keep SVLUG's Web pages up-to-date.

Or make sure someone does.

Where are the Web content files?

Virtual Web Server	Document Root Directory
www.svlug.org	/var/www/svlug-main/
lists.svlug.org	/var/local/mailman/archives/private

(There have been other virtual hosts in the past. We have only two at the moment.)

What is the Web Content Coordinator's role?

The Web Content Coordinator gets to participate in the "herding of the cats", i.e., coordinating everyone who can update the Web site. Major Web content decisions are the Web Content Coordinator's to make — though you'll probably want to put major changes up for review and comments, because consensus is important to make sure volunteers believe their input is being heard. Encourage the Web content volunteers to feel free to help keep parts up to date, or even delegate to them parts they like. (If you delegate something to a volunteer, be serious about the delegation. Consider that person the "owner" and ask him/her first before you do anything to those parts.)

Keep the SVLUG meeting pages up to date.

Keep the pages that refer to meetings up to date, whenever the Speaker Coordinator tells us what has been arranged for future meetings. (Bug him/her for info, when he/she forgets to tell us. :-) Specifically....

• After each meeting, update the meetings.txt file, which is a source data file that is parsed by the meetings.php and prevmeet.php pages every time they load: Insert a new monthly listing like the existing ones below. (You may wish to copy and paste the template section and modify it.) If you don't know the speaker or subject, remove him/her from the page heading. Important: Check your work on meetings.php and prevmeet.php using W3C's validator, any time you edit it. If either page no longer validates, you messed up and need to fix your error.
• After each meeting, update the meeting's entry in meetings.txt to append a description of the meeting, the location, the attendance, and any other notes that were significant about it.
• After each meeting, update events.html, a file referenced from the Web site's front page via another PHP include directive, to tersely show meeting date, speaker, and topic for the next two upcoming meetings. (Put "TBA" until these things are known.)
• Once a meeting speaker is announced, update the svlug-news.txt file to include news about the meeting, and save. A PHP routine will deploy your change (to the front-page "SVLUG News" column and to the cumulative SVLUG News page, which is the "News" link on the site navbar). Use other news entries as a model if you need to. Make the title a one-liner summary. Set the expiration date for SVLUG meetings per your discretion so that we keep a number of interesting entries around in the "SVLUG News" column, regardless of them being old news. I.e., we often want to make meeting items with speaker presentations stick around, and there are often other reasons. Use your judgement. We do not ever snip news items entirely except in very rare cases of a news item becoming a liability, e.g., the item about the ill-fated Google Group. Erasing items takes them from the cumulative SVLUG News page, which is almost always A Bad Thing.)

Example run-throughs of routine maintenance (but bear in mind that these narrations preceded our Sept. 2011 automation of meetings.php / prevmeet.php maintenance via the meetings.txt file):

• In a nutshell
• In detail
• Unborking table entries in meetings.php and prevmeet.php that someone else scrambled
• Finding your way around the www box

How do we make major changes to the site?

Major changes that add on to or change the look of the site should be decided by consensus, led by the Web Content Coordinator. Any volunteer may make a suggestion or even prototype page/layout/etc., but don't install them before others can review them: Expect to make changes to accomodate others' suggestions. If you get suggestions that are in conflict, go ahead and make a suggestion, but let the Web Content Coordinator resolve it, especially if the conflicting suggestions come from other SVLUG officers.

Remember to use the header include file.

Note that we've got an include file, so you only need to change header.php to change the headers and footers of all the pages. Be sure to use header.php on any new pages, so that can be continued in the future.

Use the Version Control System (svn).

We use svn (Subversion) for revision control, so you can be fairly generous in letting others who have SVLUG accounts just make modifications to pages: If something needs to be backed out, it can be done. See svn mini-tutorial, above.

Web Team members need to be in the "www-data" group.

Anyone authorized for Web content maintenance needs to be added to that group.

How do we handle grey areas between software and content?

When there's something that is both content and software, at least the Web Content and Web Software Coordinators, if not the whole team, should talk or e-mail about it.

Web Software Tasks and Procedures

• Web Software volunteers may write and install CGIs and scripts.
• Do anything that's necessary, but don't waste CPU/RAM. We have a small Linode virthost. That replaced our an old PIII/512MB that still runs the mailing lists. Even the PIII's 486 predecessor demonstrated no difficulty handling 30000+ hits per day. We survived the dreaded "Slashdot Effect" during international media coverage of the "Great Linux Revolt", "Launch Win98 on a Rocket", "Future of Linux", and "Silicon Valley Tea Party" events, but one poorly-designed program can bring any server to its knees, so be careful with what you write and install.
• Notify the Web Software Coordinator, either prior to or upon installation of a CGI (but always prior to advertising its existence), so it can be reviewed for performance and security.
• Notify the Web Software Coordinator prior to installation of a script (PHP preferred), so it can be reviewed for performance, security, and API conformance.
• Changes to the Lighttpd configuration should usually be brought to the Web Software Coordinator or the Web Team, first. The exception is emergencies, when any action may be taken to resolve the emergency, and an explanation / summary must then be submitted afterward.

Web Software Resources

• The Web server is Lighttpd with PHP5.
• These files are automatically updated by PHP routines.

  File	Description	Included by	Produced by
  svlug_news_long.html	long version of SVLUG news	news page	longnews.php
  svlug_news_short.html	short version of SVLUG news	home page	shortnews.php

• You can add to the SVLUG News on the home page and the news page at once by editing svlug-news.txt. It has comments with the file format. Add new items at the top. Use an expiration date if you want it to disappear from the home page after a certain date — it will not expire from the News page. A PHP routine will notice the revised, saved file, and implement your change.
• Voting Booth Software: We have a severely underused voting booth at http://www.svlug.org/stv.php.

  This program (by Ian Kluft) can be configured for multiple-preference types of votes. It does some pretty sophisticated "Single Transferable Vote" computations to figure out the highest preference, after each voter submits a list of highest to lowest preference.

  Archivist's note: We've not yet reimplemented the cited 'stv' CGI script after migrating to our new Web host in 2006 (as we haven't yet audited it for security). Therefore, the above link is to a static snapshot of that script's output, rather than to the live script, which lived at http://www.svlug.org/cgi-bin/stv. Interested users can download the stv (Single Transferrable Vote) Perl script and required Perl library Vote::STV. Both are licensed under GPL version 2.