Silicon Valley Linux User Group: Web Team Instructions

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, filling in for an over-occupied-with-real-life 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 Apache HTTPD server, CGI programs, embedded mod_perl 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, our last Web Software Coordinator, now has a beautiful child and is waaaay too busy for volunteer work. The task has gone un-tended for a while.

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 RCS 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
• RCS — Revision Control System, overview (19K PDF), white paper (330K PDF)

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	/home/httpd/html
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.php page, so that it has the date of the next meeting. If you don't know the speaker or subject, remove him/her from the page heading.
• After each meeting, update the prevmeet.php page to include a description of the meeting, the location, the attendance, and any other notes that were significant about it.
• After each meeting, update the events.html file that is referenced from the Web site's front page via include directive, to update the meeting date, speaker, and topic. (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 run "/home/httpd/bin/mk_live_links svlug_news" to deploy your change. Use other news entries as a model if you need to. (Make the title a one-liner summary. Set the expiration date to the day of the meeting, so it will disappear from the home page at midnight, even if we're all at the restaurant at the time. :-) )
• Also, once a meeting speaker is announced, update the meetings.php page, so that the heading includes lines with the speaker's name and the topic. Update the table of meetings to include that meeting and speaker. (Or replace the "TBA" if that was already there.)
• Last, once a month, you'll also want to update the upcoming-dates list on the installfest/index.php page.

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 SSIs on any new pages, so that can be continued in the future.

Use the Revision Control System (RCS).

We use RCS 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. Some pages that haven't been modified in a long time are not (yet) under RCS: When you need to change one, check it into RCS, first.

To check out a file prior to editing:

co -l filename

To check in a file after editing:

ci -u filename
Use a meaningful but brief description of the changes that were made.

A cron job will complain to the Web Team (reaching the Web-Team list-members) every 6 hours, if an RCS-controlled file is left locked for more than 8 hours. So, remember to check them in, when you're done editing.

Web Team members need to be in the "webslave" group.

Anyone authorized for Web content maintenance needs to be added to the "webslave" group. This group was named back when it was just Chris and Rob on the server — it was supposed to be an inside joke for what they called themselves, so don't let the name bother you. We like humour, so we're not changing the name.

What's up with the directory and file write permissions?

You will find that all the directories are group-writable by "webslave", though many files are not writable at all. That's normal — RCS turns off write permissions on checked-in files. It'll become owned / writable by you when you check it out.

Establishing RCS control on a file

If you want to create a new file or modify a file that is not under RCS control, check it in first, in order to establish RCS control. First, create an RCS directory, if one doesn't already exist. Then, use the usual "ci -u filename" method to check in the file. RCS will prompt you for a description of the file: Use the title if no other one-liner description comes to mind. RCS will not prompt you for a revision comment, because the first revision's comment is always "initial revision".

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 volunteers may write and install CGIs and mod_perl scripts.
• Do anything that's necessary, but don't waste CPU. We have only an old PIII/512MB, until something bigger gets donated. Even its 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 mod_perl script, so it can be reviewed for performance, security, and API conformance.
• Changes to the Apache HTTPD 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.

• The Web server is Apache 1.3 with mod_perl. We have a local copy of the manual at http://www.svlug.org/sw/apache/
• These files (which are all in the fetch/ directory, to keep them separate from the manually-maintained files) are automatically updated by cron jobs.

  File	Description	Included by	Produced by
  authors.html	list author summary	mail lists page	Perl5 WebFetch::EGAuthors
  freshmeat.html	Freshmeat summary	home page	Perl5 WebFetch::Freshmeat
  linuxtoday.html	LinuxToday summary	home page	Perl5 WebFetch::LinuxToday
  slashdot.html	Slashdot summary	home page	Perl5 WebFetch::Slashdot
  subdoms_ann.html	announce list subscriptions	mail lists page	Perl5 WebFetch::ListSubs
  subdoms_digest.html	digest list subscriptions	mail lists page	Perl5 WebFetch::ListSubs
  subdoms_svlug.html	SVLUG list subscriptions	mail lists page	Perl5 WebFetch::ListSubs
  svlug_news_long.html	long version of SVLUG news	news page	Perl5 WebFetch::SiteNews
  svlug_news_short.html	short version of SVLUG news	home page	Perl5 WebFetch::SiteNews
  yahoo_biz.html	Linux refs in Yahoo Business News	home page	Perl5 WebFetch::YahooBiz

  The Perl5 WebFetch module and documentation can be found at http://www.svlug.org/sw/webfetch/ (Perl5's WebFetch module was created by Ian Kluft for SVLUG.)

  You can recognize the output files by these lines in them:

  <!--- begin text generated by Perl5 WebFetch 0.05 - do not manually edit --->
  <!--- end text generated by Perl5 WebFetch 0.05 - do not manually edit --->
  

• You can add to the SVLUG News on the home page and the news page at once by editing (including RCS check-out/check-in) svlug-news.txt. It has comments with the file format. Add new items at the end. 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. Then you can leave it, and a cron job will pick it up within 20 minutes. (2005 addition: This cronjob is currently broken.) Or run "/home/httpd/bin/mk_live_links svlug_news" to force an update of both pages immediately. Try not to force an update at the same time as the cron job, which is 2, 22, and 42 after each hour.
• We have a severely underused voting booth at

          http://www.svlug.org/cgi-bin/stv
  

  This program (also 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. Ask Ian to set it up, if you want any kind of preference poll.