[volunteers] gruyere (Linode host) upgraded

Rick Moen rick at linuxmafia.com
Tue Dec 18 11:15:46 PST 2007


Quoting Daniel Gimpelevich (daniel at gimpelevich.san-francisco.ca.us):

> IIRC, the Linode kernel setting we left it on was not 2.6.23.1
> specifically, but a pointer to whatever the most recent Linode-compiled
> kernel is at any given time the host boots, which is only currently a
> 2.6.23.1 kernel.

Yes, thanks.

[Site documentation:]

> At the same time, I suggested perhaps using /usr/local/share instead of
> /usr/local/src.

Yes, you did.

Originally, I started writing site documentation within /usr/local/src
for really little more reason than to store it alongside the locally
built software it concerned (i.e., Lighttpd).  That pragmatic reason no
longer applies since the only locally built package is now gone.

/usr/local/share (and /usr/share) is a resting place for read-only
copies of data files shared between networked hosts of different
architectures, e.g., application data shared out over NFS -- game files,
word lists for dictionary and similar apps, locale info, NLS data,
zoneinfo data, etc.

Officially, /usr/local/src (and /usr/src) is per FHS for program source 
code for reference purposes only.  I often use it for that, for
documentation, for locally built packages in general (including
reference copies of the binary package), and for other sitewide purposes
not related to any specific app or service.  

There is no clear FHS-mandated location for site documentation -- just
as there's no unambiguous single right place for an httpd document root
to go.  I happened to use /usr/local/src.  Certainly /usr/local/share
could also be argued.  (I'm just happy it's not in /root or some other
home directory, or somewhere under /var[1].)

> For the moment -- build tools may be needed again in the future, but
> putting them back is trivial.

Quite.  I was also right to the edge of removing GNU screen, and may yet
do so.  (It can certainly be put back, if it's ever needed.)  It's
really easy to accidentally abuse screen, and that abuse occasionally
causes problems on the svlug.svlug.org host -- as well as on my own home
server.

> I have a strong preference for apt-get over aptitude, and with the
> inclusion of apt-get's relatively new "autoremove" command, I see no
> real useful purpose in ever using aptitude.

Regardless, the point is, having _both_ tools around would crete the
potential for (minor) trouble, which is ultimately the major reason I
removed aptitude.

I need to start writing some more-detailed and historically oriented
site docs including a changelog, to catch up on what's been done to the
host and clue in new admins a bit better, e.g., on need to make
changelog entries and check HTML/PHP and (most) conffile changes into
svn.[2]  I will attempt to get to that, next.

[1] The time may come soon when we wish to make (most) site docs
HTTP-accessible from public networks, segregating out the more-sensitive
data into a "private" tree.   Please bear this possibility in mind, if
you write anything within /usr/local/src.

[2] Man, svn is just a piece of bloated mediocrity compared to some of
the better SCMs.  Yes, it's familiar mediocrity, but maybe we could at
least evaluate Mercurial (hg) or Bazaar (bzr) before being victims of
intertia, again.  Over at _Linux Gazette_, we had a recent thread
(partially published in _LG_) about use of SCMs to store the state of
system conffiles:  Turns out, there are lots of gotchas owing
fundamentally to them not having been written for that purpose.  In
particular, capturing of metadata is spotty, and ability to store the
change data outside the working tree isn't always available.  I will be
re-reading those threads, when I have time.  





More information about the volunteers mailing list