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 |
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 | |
We also thank MIT for the use of their facilities. |