[volunteers] Fwd: [web-team] Linode Support Ticket 5649987 - Critical Xen Maintenance / Reboot Schedule

Rick Moen rick at linuxmafia.com
Sun May 1 04:03:25 PDT 2016

Apologies, have to correct a bad guess from earlier Saturday evening
that I posted here.  It's about svn access methods and the current
contents of site-docs/svn-instructions.

On reflection, it's been so long, I really should not say:

> I totally swear that the site-docs/svn-instructions method using
> svn+ssh:// checkins and with the svnserve daemon _not_ running is based
> directly on real, live testing of those exact commands.  The described
> commands worked, exactly as documented.  I would not have written that
> text without testing and verifying that they worked precisely as documented.

Er, the problem with the above is that site-docs/svn-instructions
_doesn't say that_.  I was so much of a hurry earlier that I didn't stop
to read my own site-docs file.  Also:
> Anyway, that's very much my understanding and recollection.  You might
> also find entries about all this in site-docs/ChangeLog .

site-docs/ChangeLog is where I find that when I set up new workflow, I
used the file:/// access method, aka direct repository access, not the
svn+ssh:// one.  Quoting site-docs/ChangeLog:

Fr 2011-04-01   Rick Moen <rick at linuxmafia.com>
        * Fixed undocumented dependency of local svn usage's dependency
          on svnserve (which was spawned via xinetd):  Did fresh
          checkout of 'svn checkout file:///var/svn/web/ .', chowned
          that to www-data:www-data, then mv'd that to replace existing
          /var/www/svlug-main tree, which evidently had been checked
          out using 'svn checkout svn://localhost/var/svn/web .', thus
          using svnserve.  Updated site-docs/svn-instructions.
        * Removed /boot (vestigial on a virthost that boots from outside
          the virthost), /opt, /srv, and /selinux, none of which we have
          any use for.  (Screw FHS.)

site-docs/svn-instructions says, basically, to use local tree
/var/www/svlug-main as the svn working area, and check changes into svn
with root authority, e.g., quoting site-docs/svn-instructions again:

  sudo svn ci -m "Adding March meeting, new installfest dates" \
       meetings.txt installfest/index.php

I believe you'll find that that all still works as per design.

What it doesn't do is enable remote checkins from remote working areas,
where svn's access method options are http with WebDAV (and we don't
have WebDAV), svnserve ('svn://'), or svnserve tunneled over ssh

Back in 2011, I appear to have made the judgement call that I'd rather
eschew the svnserve daemon unless/until we actually need it.

To explain the term 'undocumented dependency':  Part of the task in
early days was to make sure we weren't accidentally running a bunch of
junk, given the need to run lean.  So, among the things I did was audit
the ps output.  And I saw xinetd running.

I thought, WTF?  I never turned that on, so why are we suddenly running
it.  So, I looked at the xinetd conffiles, and saw that xinetd was
configured to run exactly one service, some thing called svnserve.  
I looked in site-docs/ChangeLog, and no entry mentioned it!

Because svnserve seemed obvious that had something to do with svn, I
called up Lisa Corsetti, and said 'Hey, there's suddenly a daemon
running called svnserve, under the xinetd superserver.  Do we need it?'
She replied 'No.'  So, I turned xinetd off.

Some days later, I was updating some Web pages, and tried the regular
'svn ci' operation -- and checkin broke.

After some investigation, I determined that Lisa's answer 'No' was
incorrect, that in fact she'd switched on xinetd and svnserve in the
process of getting svn going, had _not_ bothered to say anything about
that in site-docs/ChangeLog, and then had forgotten all about what she'd
done by the time I asked her whether the system needed svnserve.

So, there were two alternative ways to fix that situation.  One was:
Turn svnserve back on, and do remedial documentation.  The other was: 
Figure out how to _not_ need svnserve, and do remedial documentation.
I elected option #2.

Please note that paying attention to ChangeLog and the svn-instructions
documentation file would have clarified this matter earlier.

I believe this takes us right back to the beginning.  So:  If you wish
to check in svn contents into the repo, please see

More information about the volunteers mailing list