[volunteers] Speaker Coordinator Introduction

[Rick Moen]

Quoting Mehma Sarja (mehmasarja at gmail.com):

> Should we broach the replacement h/w subject? There is an Atom D510 
> SuperMicro 1U machine which I may be able to pry out of my hands. 
> Unrelated, I have a couple of 1 TB drives also. Suddenly, "volunteering" 
> is taking on a new meaning.

Much information about this subject is in prior discussions in the
archives of this mailing list.

Nobody ever bothers to consult the prior dozen recaps of SVLUG
particulars in those archives.  Instead, they always ask me to explain
everything from scratch.  I try not to be too surly about it.  ;->


1.  Why didn't SVLUG migrated everything to the Linode virthost?

VP Micah Dowty arranged through the generosity of Linode CEO Chris Aker
for us to have a free of charge 'Linode 80' (80MB RAM, 3GB disk, 50GB
transfer) User Mode Linux virthost, starting April 2006.  Micah picked
Ubuntu Server as the system load, then handed it over to me with the
claim that it should easily host all of SVLUG's services (SMTP, mailing
lists served by GNU Mailman, DNS nameservice, Web server, Web pages
served by the GNU Mailman CGI to the httpd, version control repository).
It was also expected that the httpd would be fine for the then-underway
conversion from static HTML to MoinMoin wiki pages.[1]  I said I had
serious doubts about adequacy of the virthost's RAM and disk.  Micah
assured me we'd be fine.

Micah is a coder; I'm a sysadmin.  Micah was wrong; I was correct.

I tried every possible trick to shoehorn all of that functionality into
80 MB RAM:  We switched from Apache httpd to Lighthttpd.  We switched
from BIND9 to NSD.  This did a lot of good, but it proved flat-out
impossible to also do SMTP with spam protection in the remaining RAM.

However, in the years since 2006, Linode has upgraded our virthost:  It
now has 256 MB total RAM and 8 GB disk.  I just did some disk cleanup:
About the only wasted space is 186 MB of compressed files left behind 
by Micah that were for the failed MoinMoin conversion project.  Bearing
that in mind, the current free space is 6.5 GB.

I now see the migration of all of our content over to Linode as possible
-- if barely.  It will require care in ensuring that the SMTP antispam 
is done correctly.  


The other question, aside from RAM, is disk.  The biggest consumer of
disk on lists.svlug.org is the Mailman tree, which is in
/var/local/mailman.  Total space currently consumed there:

# du -sh /var/local/mailman
4.5G	/var/local/mailman
#

Out of that, I'm pretty sure these can be omitted:

# du -shc /var/local/mailman/archives/private/svlug-old.mbox/ \
/var/local/mailman/archives/private/mailman-owner/ \
/var/local/mailman/archives/private/mailman-owner.mbox/ 
119M	private/svlug-old.mbox
1.7G	private/mailman-owner
548M	private/mailman-owner.mbox
2.3G	total
#

So, in round figures, there are 2.2 GB of files in the Mailman tree that
need migration.  There are only trivial amounts of other significant
files remaining (outside /var/local/mailman) on lists.svlug.org that we
care about.

Therefore, while in 2006, it couldn't be done, I believe it can
be done today.  The only gotchas are (1) we'd have to be a little
careful about RAM, and (2) we'd need to make sure Mailman's growth over
time in disk space doesn't overflow the virthost's disk.

We'll also have to watch homedirs and system mail spools to make sure 
people don't indulge past antisocial habits such as numerous past SVLUG 
officers who subscribe to high-volume mailing lists at their svlug.org
mailboxes and then never cleaned them out.


The lists.svlug.org machine runs a now-unmaintainable installation of
Debian 3.0/Woody from around 2001-2002 when 3.0 woody was the Debian
'testing' branch.  It has a grsecurity-hardened kernel and
infrastructure.  Several key components (notably Mailman and sa-exim) 
were hand-compiled by Marc Merlin, who constructed the machine.  Package
operations are no longer safely possible, because of some of the choices
Marc made in running the machine.


2.  What is SVLUG's relationship with Via.net like?

Via.net, a small, family-run hosting company in Palo Alto, run by Joe
McGuckin, his wife Mary, and a couple of staffers, houses the legacy
lists.svlug.org host, which is a shallow-depth Rackspace-branded 2U
sitting on a shelf at Via.net.  512 MB RAM, 80 GB disk (single PATA hard
drive).

They let us keep the machine there for free.  Sometimes when we visit,
they mention to us that it's _customary_ for their 'free' hosted
machines' sponsoring groups to give them a bit of money every year, but
we have never done so.  Once when I came there and mentioned our hopes
to replace the machine with a more-redundant, more durable machine, they 
mentioned something about how they'd prefer that we, instead, migrated
to some sort of virtual-hosted alternative.  

I did not write down details.  However, the main point is that our
welcome there is not unconditional; it'd be fairer to say that we are
tolerated there because we are mostly not a problem for them and we
seldom do anything to remind them of our presence.

Unfortunately, most possible improvements to our presence at Via.net,
including replacing the 2U with a 1U taking less space and drawing less
power, would tend to draw their attention to us and at least slightly
inconvenience them.


3.  State of the Linode virthost.

As I mentioned, Ubuntu Server was Micah Dowty's choice, not mine.  He
didn't bother to consult me or anyone else.  He just opted for it and 
told us to use it.  I'm actually not fully comfortable with Ubuntu
Server.  (By contrast, I am extremely familiar with maintaining Debian
systems over long periods of time.)

In particular, I am apprehensive about upgrades from one Ubuntu branch
to the next one, on a headless virtual host.  Consequently, the Linode
virthost is alarmingly behind on versions of everything:

rick at gruyere:~$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=7.10
DISTRIB_CODENAME=gutsy
DISTRIB_DESCRIPTION="Ubuntu 7.10"
rick at gruyere:~$ 

Ubuntu 7.10 "Gutsy Gibbon" was released 2007-10-18, and was end-of-lifed 
in April 2009.  The virthost is thus at risk for vulnerabilities and
bugs because of unmaintained software.

Frankly, I would greatly prefer to blow the current virthost away,
replace it with Linode's Debian build, synchronise that build with the
current Debian-testing branch (7.0/Wheezy), and recreate on it the 
present configuration of Lightthpd (httpd) with FastCGI support, NSD
(DNS nameserver), ntpd, xinetd (for svnserve), and svn -- because I
really think Micah's offhand choice of Ubuntu Server was a bad idea for
long-term maintenance.


As you can see, SVLUG's needs really aren't those of new hardware.
SVLUG _has_ received a number of old computers in the past, notably
huge, power-sucking old VA Linux Systems gear and a huge, power-sucking
JBOD chassis capable of holding qty. eight of 3.5" SCSI SCA disks.
Somehow, these have all ended up in my garage.


[1] This included reformatting all extant static Web pages into MoinMoin
format and reimplementation in MoinMoin of a number of CGIs.  Heather
Stern, our MoinMoin expert, promised to convert over the few difficult 
pieces requiring MoinMoin experience.  I agreed to do the other 80% of
the recoding.  I completed my 80%.  Heather did none of the rest.  So,
the conversion effort failed. 

The attempted wiki conversion was mandated by President J. Paul Reed,
who was convinced that the only thing detering greater participation in
SVLUG's Web presence was users' inability to cope with ssh'ing into a
shell and editing HTML using a text editor, and that SVLUG's problem 
getting enough volunteer help to maintain its pages would go away if 
the pages were wikified.  I felt his assumption was mistaken, and that
editing difficult wasn't the problem.  However, he was in charge, so the
wiki project occurred -- ending up with all of my work on it being
wasted and thrown away because Heather flaked out.

Later, Lisa Corsetti helped update the static pages to use PHP rather
than server-side includes, and to convert several of the legacy Perl CGI 
components into PHP.