[sf-lug] the new colo box is now minimally built

jim stockford jim at well.com
Tue Nov 6 08:47:50 PST 2007


thanks for the comments, rick.

* the CD-ROM drive option was a last-gasp alternative:
i'd've had to take one out of a box, hang it on the new box,
then put it back in the old box--a hassle.
    Also, i'd never done the usbstick thing, so now i learned
something.

* my native bias would be to make a bunch of RAID 1
partitions. but, it seems like LVM is becoming more
prevalent, and there are proponents, so "what the hey! "
became the policy of the moment.
    note there are two 250GB disks in the box, so there's now
something like 100GB on each that's raw and unclaimed.

* thanks for the apt-get command. i'll have to learn the debian
walk, now.
    [1] i had understood aptitude to be exactly a GUI front end
to apt-get. i now understand differently.
    per item (3), that's a convincer not to use aptitude.

* what i believe we want to do with the box is have it be a
properly set up and administrable host for sf-lug and balug
services, i.e. web sites, mainly. we'll include email and a
wiki or two.
    "properly set up" means no kitchen sinks: only what's
needed to perform the tasks required. i think there are two
views: system administration of the box and all its processes,
and community services, mainly web sites for balug and
sf-lug.
    note: i'm not in charge and don't want to be in charge.
hopefully a few of us will collaborate and come to some
policy agreements.
    default SA software includes nagios and osiris and sshd
and some cron jobs.
    I'd like to try tom dizoglio's trick of having some other box
elsewhere peep into our new colo box from time to time to
ensure that there's no cracking going on behind our backs
(have it capture who, ps, and log file data every so often).

* as to config, seems the best thing is to install the software
in the approved manner and then use an editor to modify
the config files so's the software does what we've got going
on the current box, and maybe improve things a bit as we
go (like not choking on pagermonkeys at localhost...).
    bringing over the web pages and wiki data seems a
matter of copying files from the old box to the new box,
but after we've set up the directory structure and config
files on the new box.
    as to user accounts, those will be drastically reduced to
just those people committed to administering the box
itself or to administering the sf-lug or balug software. I
promise to set up a different box with internet accessibility
for those who want an internet playpen.
    note, wrt internet playpen, that those studying python
or bash command-line skills, will benefit from using a
common box rather than working on their own boxes at
home for the reason that they'll have common software
and machine resources that allow properly pointed
questions and answers.

* i'm hoping other members of the list will respond with
suggestions, cautions, requests... wrt to which packages
should be on the new box.
    note that time's a-wastin'



On Nov 5, 2007, at 1:21 PM, Rick Moen wrote:

> Quoting jim stockford (jim at well.com):
>
> [Building the new 1U colo box using some minimal Debian image:]
>
>>     for the record, i had to get a boot image on a USB stick:
>
> FWIW, I keep around a known-good, old ATAPI CD-ROM drive for situations
> like this one.  To load distros, you needn't mount the drive inside the
> box; it suffices to hang a ribbon cable and a power one out the back or
> top, for just long enough to complete installation.
>
>> * make 120GB RAID 1 md1 for LVM
>
> Again, for whatever it's worth, I'm personally not sold on LVM in the
> general case.  It's yet another layer of indirect reference that I'm 
> not
> sure is useful enough to offset the extra system complexity.
>
>>     Now i gotta have help setting things up on this very
>> minimum box (doesn't even have sshd on it anywhere).
>
> "apt-get install openssh-server openssh-client"[1]
>
> (I assume you want the client, as well.)
>
>> * what system utilities and standard daemons should go
>> on it (sshd, DNS, nagios, osiris, nmap...)?
>
> Well, doesn't that depend entirely on what you want to with the box?
>
> One of the benefits of running Debian is that you can hold off on
> loading it with stuff, and add only what you need (and its
> dependencies), when you need it.  So, you might want to fight off the
> instinct to grab the kitchen sink.
>
>> * how to get our config and data files transferred over?
>
> Carefully.  ;->
>
> Please consider not just clobbering the default (Debian) system config
> files and dropping in ones from the /etc tree of some other
> distribution.  First, that may not work without massive twiddling, and,
> second, you risk accidentally blowing away some useful infrastructure.
> E.g., Debian tends to package http and SMTP daemons in a modular 
> fashion
> that's upgrade-friendly.  So, in general, it's in your interest to 
> study
> the default Debian-installed configuration files and reimplement the
> _ideas_ of your configs from other distributions, rather than just
> overwriting the former files with the latter ones.
>
> The same goes for user home-directory dotfiles (and dot-directories),
> for the same reason.
>
>>     got ideas, suggestions? note this box will replace the tower
>> we're currently running at the colo and will serve at least
>> sf-lug and balug web sites and mail and other related.
>
> OK, so you need to figure out what packages provide the desired network
> services, etc.  In general, it's not difficult to figure out, and the
> package tools will take care of dependencies.
>
> [1] The currently recommended tool for package retrieval and
> dependency-resolution is actually no longer apt-get, but rather
> aptitude, which has both a full-screen ncurses operating mode and a
> command-line one.  The command-line mode has the same syntax as does
> apt-get.   I still use apt-get because (1) I'm set in my ways, (2)
> aptitude is slow, and (3) I don't like aptitude's more-expansive
> approach to grabbing extra packages beyond those minimally required to
> satisfy dependencies.  However, whichever toolset you use, you should
> carefully avoid switching back and forth, because they keep the same
> sorts of internal records but don't share that information.
>
>
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
>





More information about the sf-lug mailing list