We'd like to thank our sponsors:
- The Operating System of
the 21st Century
Silicon Valley Linux User Group: Web Team Instructions
The SVLUG Web Team performs the tasks that are usually thought of as the
"webmaster". In fact, firstname.lastname@example.org is just an alias for the
email@example.com mailing list. We expect Web Team volunteers to
be trustworthy, able to work in a team, and have some prior experience.
Though not everyone can be accepted for the Web Team, people interested
in volunteering to help SVLUG will still find numerous activities where
he/she can help, such as at the meetings and installfests.
Organization of the Group
We divide Web tasks between these coordinators:
To join the Web Team, contact
or talk to the appropriate coordinator for the kind of work you prefer to do.
Any SVLUG members interested in Web Team affairs, whether Web Team members
or not, should consider completing the "Subscribing to Web-Team" form on the
mailing list page.
- 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)
— Secure Shell (SSH) is required to log into our server
- svn — the Subversion Version Control System (VCS).
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:
- 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.
- 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").
- 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
- 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.
- 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
- 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).
- New files (one not yet in the repository) need to first be added
svn add filename1, before you can do a ci (check in)
- 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
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?
(There have been other virtual hosts in the past. We have only two at the
|Virtual Web Server
||Document Root Directory
- 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
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. :-)
- After each meeting, update the meetings.txt file, which
is a source data file that is parsed by the
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
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):
- 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
- 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
- Web Team members need to be in the "www-data" group.
- Anyone authorized for Web content maintenance needs to be added to
- 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.
|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
- Voting Booth Software: We have a severely underused voting booth at
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
Both are licensed under GPL version 2.
Feedback to SVLUG webmasters.