[web-team] Quick summary of new web host

[Rick Moen]

Quoting Lisa Corsetti (svlug at flygirl.com):

> Okay, here's a quick summary.... someone can put it on the server if you 
> like:

You'll see a reminder (for everyone, not specifically intended for Lisa)
about site docs lower down in this reply.

> - All files are owned by the group www-data.  Please add yourself to the 
> www-data group if you are going to edit any of the files

Query:  What's your view about reimplementing the webslave group?  I
know (and really appreciate!) your getting things going in a
quick-and-slightly-dirty-but-systematic way, but this might be  the
right time to go after details.  Specifically:

I notice that both processes lighthttpd and php-cgi run as the
"www-data" user and group.  Having the same group have edit access to
the document tree strikes me as bad security, no?  I recall that one
wants the httpd (and associated CGI processes) to (of course) have the
ability to read the document tree, but not to write to it.

I just realised that, if we _do_ change that group ownership, we want to
be careful to keep /var/www/svlug-main/svlug-news-{long|short}.html
writable by the www-data user (and probably group), because otherwise
the output code you have in longnews.php and shortnews.php would break.

> - I changed the default umask to 002 and the directory is set to mod 
> 6775 so that any new files created will be writeable by the group

Good.  Just for general knowledge, this is one of the things that the
former rcs wrapper on the old site used to (in part) take care of, if I
recall correctly.

Still, I used to have to go in, occasionally, and wield root-user
authority to correctively chown/chgrp sets of files that some twinkie
(I strongly suspect Paul Reiber) used to set up as root-owned files
rather than owned by group webslave.

> - The files svlug-news-short.html and svlug-news-long.html are derived 
> as needed from svlug-news.txt by shortnews.php and longnews.php.  The 
> need is determined in a very "make-like" way: if the destination file is 
> older than the source file, a new destination file is created.  The net 
> result of which is that the files are created the first time that they 
> are needed to paint a web page where they are used.  PLEASE do not check 
> these files into SVN.
> 
> - I am uncertain if we will have to add users to svn (frankly I haven't 
> tried as anyone but myself), but to do so, you simply type "svn commit" 
> from the /var/www/svlug-main directory and enter the comments to be 
> committed with your changes.

We still have some kinks in svn usage, and user setup.  I'm
not yet being allowed to do checkin:

rick at gruyere:/var/www/svlug-main$ svn ci meetings.php 
Authentication realm: <svn://localhost:3690>
02ad40a7-6131-0410-b702-9cc8296e38bd
Password for 'rick': 
Authentication realm: <svn://localhost:3690> 02ad40a7-6131-0410-b702-9cc8296e38bd
Us': ame: ^[[A^[[A^[[B^H^H^H^H^H^H^H^H^H^H^H^H
Authentication realm: <svn://localhost:3690>
02ad40a7-6131-0410-b702-9cc8296e38bd
Username: rick
Password for 'rick': 
svn: Commit failed (details follow):
svn: Authentication error from server: Username not found
svn: Your commit message was left in a temporary file:
svn:    '/var/www/svlug-main/svn-commit.tmp'
rick at gruyere:/var/www/svlug-main$ $ svn commit meetings.php
Authentication realm: <svn://localhost:3690> 02ad40a7-6131-0410-b702-9cc8296e38bd
Password for 'rick': 
Authentication realm: <svn://localhost:3690> 02ad40a7-6131-0410-b702-9cc8296e38bd
Username: rick
Password for 'rick': 
Authentication realm: <svn://localhost:3690> 02ad40a7-6131-0410-b702-9cc8296e38bd
Username: svn: Commit failed (details follow):
svn: Caught signal
svn: Your commit message was left in a temporary file:
svn:    '/var/www/svlug-main/svn-commit.2.tmp'
rick at gruyere:/var/www/svlug-main$

FYI, the gist of the above is that I _have_ now corrected / updated all
of the stuff on the front page and the Meetings page about the July
speaker, but so far have been stymied in checking my changes into svn.

So, something needs to be done to make me (and others?) permitted to do
checkins, and I'm not yet clear on what that thing is.  (I'm looking
through the docs on svn's overengineered functionality as we speak.)  

For context, I should explain:  I've used many existing svn repos, and
am familiar with the dirt-simple routine of "svn update", edit, "svn
ci", but have never _administered_ an svn repo, and so am missing a lot
of basic knowledge and understanding.  (Well, let's say I've skim-read
some fundamental docs on svn design & implementation, but long ago and
they didn't sink in very well.  So, some stuff is faintly familiar, but
I lack admin-level competence.)

There's a whole slew of things I'm unclear on, e.g., I only just now
figured out how to determine what's _in_ an svn repo.  (You do "svn
info"). 

Which means, by the way, that at least one other subtree needs to be
imported (I gather, using "svn import"):  /etc/nsd (with /etc/nsd/primary).
Also /usr/local/src, which is where the site docs live.  But I probably 
can't do that until the auth problem gets fixed.  Help?  (Thanks.)

I'll need to catch up on recent knowledge about the machine
configuration in /usr/local/src (site docs), but figure I should wait until
I have a better grasp on the version-control setup, otherwise I'm likely
to write wrong or misleading docs.



I won't harp on this too much, but you may already know that I don't
like svn a _whole_ lot:  It meets its design goal of being an exact
replacement for cvs without cvs's more gross defects (notably lack of
atomicity, which svn cures along with all the other more-infamous cvs
defects).  What has resulted is a tolerable mediocrity that is an
incremental improvement over cvs but isn't very good:  It's overly
baroque (e.g., the schizophrenia of supporting several different
authentication models at once: WebDAV, svnserve, svn+ssh), it's
heavyweight with an absurdly long list of dependencies, it uses
snapshots rather than proper changesets (deltas), it cannot version file
"mv"/rename operations (proponents lie about that), there's no
history-sensitive merging, and the only data model it supports is fully
centralised.

And I'm always unimpressed by a Unix command-line tool that has useless
manpages and pushes you to use its own separate and incompatible help
system.  (The fact that this same attitude problem also afflicts the
GNOME and Java communities doesn't help me trust these guys much.)

I'd frankly be happier with your choice of Mercurial ("hg"), git, or
Bazaar ("bzr").  All of those would likewise involve a learning curve --
but I figured it's smarter to speak now than be still slightly grumpy
about this matter years from now and have you say "Well, why didn't you
_say_ anything?"