[sf-lug] Rick's explanation of his internet setup.

[Rick Moen]

Quoting Adrien Lamothe (alamozzz at yahoo.com):

> Happy New Year!

Thank ghod, we're a bit over half-way through the Noughties.  I won't 
miss 'em.

> Have you ever monitored RAM usage on uncle-enzo? RAM is really
> inexpensive these days, even the older PC-100 (you can also usually
> use PC-133 safely in a PC-100 system.) 

You know, I could, but why?  Like most Linux Internet hosts in most
situations, uncle-enzo is I/O-bound, courtesy of living at the slow end
of an aDSL line.  Given its role in life, it could actually be a much 
less powerful (and quieter, and smaller, and less electricity-gulping) 
machine, and still perform just as well.  vmstat and other tools show
it doesn't eat into virtual memory much, and in general runs fairly
healthily with its mere 256MB.  

About the only real benefit of (say) doubling that RAM would be stretch
the life of its twin 9GB SCSI-2 drives, by giving more resources to the
system disk cache.  But, really:  Extending the life of 9GB SCSI-2
drives?  In 2006?

You see, I really did think that one over.  I'm not sure it even merits
spending tbe price of several Quiznos Classic Italian sandwitches at SA
Technology, let alone having to spin down the machine, get all the junk
off the 2U case, crack it open, blow all the dust out, and cram in more
RAM.  

For that matter, I don't even know offhand how many free RAM
slots the Intel Nightshade (N440BX) motherboard has, or what it maxes
out at.  Hmm, searching reveals:  four DIMM slots, total max 1GB.  

Jury says:  Not even worth cracking the case to find out whether the
number of open slots is two or zero.

Remember, this is junk hardware, like any computer _that_ old (8 yrs.).


> UPSes have also come way down in price.

And you then get to pay pretty much the same amount again every few
years to get battery replacements.  And the periodic amount you have to
pay is proportional to the capacity.  (There's also the possibility of
automatic orderly shutdown, discussed below, with even very low-capacity
UPSes.)

Let's think about that:  For there to be much point, I'd need to put the
system box, the aDSL modem, and at least the house's outer ethernet hub
on the UPS.  Let's say for the sake of discussion that it's 220W, on
average.  An APC Smart-UPS XL 750VA provides... hmm, the units of their 
capacity figures don't makes sense to me.  Shouldn't it be in something
like kilowatt-hours?  (Turns out this is complex, and is explained at
http://www.pcguide.com/ref/power/ext/ups/funcCapacity-c.html .)

Costs $420, weighs 53 pounds.  220 watts over 110 VAC implies a 2 amp 
current draw.  Anyhow, they have a chart that claims about 1 1/4 hours
of battery runtime at that current draw -- for $420 every few years.

And for what?  Currently, the power trips off:  uncle-enzo is off the
air.  Power comes back:  uncle-enzo is back with everything undamaged
and just fine.  This is no fluke:  The SQL database uses ACID-compliant
tables, the non-static filesystems are journaled, all services restart
automatically.  Even vim keeps temporary files so you can reopen the
unsaved file you had open where power dropped off, without lossage.
Most outages are during winter storms at 4 AM while I'm asleep, anyway.
I wake up, and the only way I can even tell there's _been_ downtime is
that my GNU Screen sessions aren't running, any more.

So, basically, $420 every few years would buy my uninterrupted operation
through two or three power failures per year that are shorter than 1.25
hours.  Presumbly, $100 every few years might buy me uniterrupted
operation through 15 minute or shorter power outages.  But I really
don't care that much. 

Deirdre has an unused UPS that would probably run uncle-enzo (and the
other stuff) for ten minutes. 

The other thing alluded to above is that UPSes don't _have_ to simply 
run silently along on battery power until suddenly they run out of juice
and everything falls over:  With a suitable RS-232C serial or USB cable, 
your UPS can send out status signals to an attached machine that is
running UPS-minitoring daemon software.  That software then will wake up
and do whatever it's configured for, when there is X estimated minutes
of battery runtime remaining:  page the administrator, do an orderly
shutdown of affected machines, or whatever.

This can be important if, say, you have application servers that depend
on database servers, etc., that really need to be brought down and back
up in a specific order.  I don't, and as far as I can tell my needs are
limited to:  please bring the machine back up when the power comes back.
And I already have that, with no UPS.

APCC (and possibly others) makes the monitoring thing gratuitously
difficult by requiring bizarrely non-standard cables for the
interconnects involved, which are -- of course -- absurdly expensive and
exotic.  (This may have changed.  It was the case some years ago.)

Some smarter guy than I might imagine something useful that can be done
within a 10 (or 75) minute battery runtime, using such a mechanism.
Personally, I don't really see any, and so don't see any significant
advantage.


> I would ask what kernel uncle-enzo is running, but that is probably an
> improper question due to security concerns.

No, I have no problem disclosing that.  It's a Debian-packaged binary
kernel (because I'm lazy, and because many distro-provided precompiled
modular kernels are good enough):

~ $ uname -r
2.4.27-2-686
^ ^  ^ ^  ^
| |  | |  |-- CPU-optimisation (best you can do for a PIII) and architecture,
| |  | | -- Version of the distro's package of this kernel variant.
| |  |-- Release version for this kernel.
| |-- Minor series number, for this kernel release.  Even numbers are
| |   stable releases, through 2.4.  2.6 introduced different versioning.
| |-- Major series number, for this kernel release.

People new to Debian and related distros (MEPIS, Kanotix, Ubuntu, etc.) 
sometimes just assume that they'll automatically get a suitable kernel
every time they update packages using apt-get -- and never stop to
consider what kernel _package_ they're using.   Worse, prior to Debian
3.0 "sarge" (current "stable" branch), if you took no explicit action to
manually pick an explicit kernel package, you ended up by default with
the _installer's_ kernel and no actual kernel _package_ at all.

The result was that you persisted in running an extremely generic
kernel, which then never received any updates because the package system
didn't even know about it.

It somehow never occurred to the Debian package maintainers that many
people would _not_ take an explicit step to pick a kernel package.  This
oversight was fixed in the (now-current) "sarge"-branch's default
installer.

Anyhow, if you browse through available precompiled kernel packages for
your CPU family (x86, PPC, SPARC...), you find various 2.4.x, 2.6.x, and 
even 2.2.x release versions.  You also find, for each release version
present, packages with different compiler optimisations (386, 586, 686, 
k6, k7).  For each of those, you find packages compiled either with or
without SMP support.

The specific Debian kernel package I have installed is called:  

  Pacakge: kernel-image-2.4-686

  Description: Linux kernel image for version 2.4 on PPro/Celeron/PII/PIII/P4
  This package will always depend on the latest 2.4 kernel image available for
  Pentium Pro/Celeron/Pentium II/Pentium III/Pentium 4.
  Tag: admin::boot, admin::kernel, role::aux:metapackage

As indicated, this is a "metapackage" (or virtual package), sort of like
a movable symlink for packaging:  Its presence is a reminder memo to the
packaging system that it should fetch any newer _actual_ physical package with
any name of the form "kernel-image-2.4.N-686, where N is a number higher
than the current value.

(Kernel metapackages aka virtual packages were introduced sometime in
the "sarge" testing cycle.  If you have a Debian-ish system, you might
check to see if it maybe got accidentially stuck at 2.4.N for low values
of N, because that's the physical-package version you picked once upon a
time, and you never revisited the matter or switched to a metapackage.)

And, of course, N is currently 27:  I have package "kernel-image-2.4.27-686",
which package is at release #2, as shown earlier.  This is a
uniprocessor (non-SMP) kernel, compiled with PPro (686) optimisation.

Now, you might be thinking, "Wait!  isn't the 2.4 kernel series up to
2.4.31?"  Yes, it is.  Debian, like most distros, occasionally chooses
to pick a kernel release that looks really good for the medium term and 
standardise on it for a while.  As 2.4.28, -29, -30, and -31 came out,
the Debian kernel maintainers consider whether each will make a better
substitute interim standard, and whether the new version's improvements
can be easily backported to 2.4.27.  So far, they have preferred to
backport.  Thus, even though 2.4.x releases after 2.4.27 have provided
security fixes, the fact that I'm still on a 2.4.27 kernel doesn't mean
I've missed those fixes.

I mention that matter because it's a frequent area of confusion among
people new to kernel issues:  You can't just look at package numbers and
say "Oh no!  That's a vulnerable version."  Backports make the matter
not quite that simple.

If I actually had some compelling reason to run a 2.4.31 kernel, the
fact that Debian doesn't (yet) provide one precompiled isn't much of an
obstacle, because Debian provides the make-kpkg (make kernel package)
tool, allowing you to easily compile and build Debianised binary kernel
packages from the source tarballs of your choosing.  

I could do that -- but I'm lazy, and I also have a reasonable amount of
faith in the package maintainers' oversight.

And, by the way, there wouldn't be a whole lot of point in being
secretive about what Linux kernel I'm running:  The nmap and p0f  
remote-scanning tools, among others, can make a somewhat reasonable guess 
about what OS and kernel reversion you're running, through testing TCP
packet signatures and such things.


linuxmafia:~# nmap -sT -sV -sU -O linuxmafia.com
Starting nmap 3.93 (http://www.insecure.org/nmap/ ) at 2006-01-01 15:01 PST
Interesting ports on linuxmafia.com (198.144.195.186):
(The 3135 ports scanned but not shown below are in state: closed)
PORT      STATE         SERVICE VERSION
21/tcp    open          ftp     vsFTPd 2.0.3
22/tcp    open          ssh     OpenSSH 4.2p1 Debian-5 (protocol 2.0)
23/tcp    open          ssh     OpenSSH 4.2p1 Debian-5 (protocol 2.0)
25/tcp    open          smtp    Exim smtpd 4.54
53/tcp    open          domain
53/udp    open          domain?
80/tcp    open          http    Apache httpd 1.3.33 ((Debian GNU/Linux) mod_ssl/2.8.24 OpenSSL/0.9.8 DAV/1.0.3)
119/tcp   open          nntp    Leafnode nntpd 2.0b8_ma9
123/udp   open          ntp?
443/tcp   open          http    Apache httpd 1.3.33 ((Debian GNU/Linux) mod_ssl/2.8.24 OpenSSL/0.9.8 DAV/1.0.3)
873/tcp   open          rsync (protocol version 29)
8080/tcp  open          ssh     OpenSSH 4.2p1 Debian-5 (protocol 2.0)
32768/udp open|filtered omadDevice type: generalpurpose


Running: Linux 2.4.X|2.5.X
OS details: Linux 2.4.0 - 2.5.20
Uptime 1.017 days (since Sat Dec 31 14:37:58 2005)
Service Info: OS: Unix

Nmap finished: 1 IP address (1 host up) scanned in 55.254 seconds


linuxmafia:~# p0f
p0f - passive os fingerprinting utility, version 2.0.5
(C) M. Zalewski <lcamtuf at dione.cc>, W. Stearns <wstearns at pobox.com>
p0f: listening (SYN) on 'eth1', 231 sigs (13 generic), rule: 'all'.
198.144.195.186:43966 - Linux 2.4/2.6 <= 2.6.7 (up: 24 hrs) 
[snip]


_Do_ try that at home, kids:  Studying your own machines' external
profile via remote-probing tools is an _extremely_ good idea.  However,
think long and hard before security-scanning other folks' networks,
since many people may get a little trigger-happy about that.