Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Debian, and its shortcomings



On Tue, 4 Nov 2003, John Chambers wrote:

> Well, I'd expect a server machine to include all the usual text editors,
> because you need them to handle config files and logs.  And it would be
> handy to have as many shells and languages like perl, python, tcl, etc.,
> because you need things like that to properly manage a server.  Things
> like C/C++ and their libraries, or the printer packages should probably
> be kept separate so they can be installed only when needed.  (Though I
> always feel somewhat crippled on a machine without a C compiler.  ;-)

Ideally, anyone that cracks into your server should also feel hindered by
the lack of a compiler. As useful as it is to have a copy of GCC laying
around (or for that matter, Perl & Python & Tcl), these also increase how
much of a mess a system intruder can make.

There's a strong case to be made that a public facing server shouldn't
have any of this stuff if at all possible. Obviously there are exceptions:
a mod_perl server isn't that useful without Perl; a Zope server can't get
very far without Python; a Vignette server will need to have a copy of Tcl
(or Java, I think -- not that familiar with Vignette, but it's the only Tcl
thing I can think of).  But unless you're running something that *needs* a
programming tool, it probably shouldn't be on a server.

Perl is pretty indispensable, but you can at least -- for example -- avoid
having any extraneous CPAN modules installed. (One of the promised traits
of Perl6 will be a distribution with a very restricted CPAN library [or
whatever the equivalent is, maybe CPAN2 or something]. This will be a good
thing.)

I thought best practice was to have development & deployment be near
clones of each other -- same OS & version, same core libraries, etc --
but all the development tools should live on the development / staging
server, and only deployed, bare bones software should be uploaded to the
public facing deployment server.

You could even take this as far as not giving that machine the usual suite
of text editors, except maybe /bin/vi or [muhahaha!] /bin/ed, just because
it's nearly impossible to do any work on config files without some kind of
editor on hand. But then if you're really paranoid, you can just scp
everything over from the other side of a firewall, so realistically you
could even do without tools that basic on a server.

No idea if anyone is really this restrained in practice, but there are
certainly worse configurations imaginable.



-- 
Chris Devers      cdevers at pobox.com
http://devers.homeip.net:8080/blog/




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org