I'm using RedHat on my servers; can't do comparison to SuSe since I don't know it, but I'll comment on the RedHat side. I got into RedHat because of the RPM utility, around 4.2 I think, and have stayed with it because nothing has yet annoyed me enough to switch.
Gerd Knops <[EMAIL PROTECTED]> writes: > Besides general observations I am specifically interested in answers > to these questions: > > Apache/modperl installation and updates: I assume installation is > straight forward, how about keeping current? As those are remotely > administered platforms, chances are the OS may not be kept current. So > is it still easy to deal with security updates (Apache, sshd, bind > etc) when the platform is a couple of years old? With FreeBSD this has > become somewhat harder lately (still running 3.x, but the ports system > doesn't support 3.x any longer). I'm still with RPMs for these components, and am hoping intensely to be able to stay there because it's *so* easy to keep up to date. > Remote maintability: Is it possible to remotely upgrade between OS > versions for either of those platforms (not a must, but would be a > plus)? Yes. I'm assuming you understand it's always dangerous to do this; do you at least have people who you can call on the phone to push the reset button if you screw up? With the GRUB loader that's appeared in recent RedHat's, the biggest easy mistake has gone away (you no longer have to do the equivalent of running lilo before rebooting). Of course if the new kernel itself doesn't boot, you're sunk (need somebody at the console to select an alternate boot kernel). The last umpteen kernel upgrades I've made, I've never screwed up badly enough to need to use the reset button, and since the systems are physically right in front of me I haven't been all that careful. I haven't done this, but it looks like it's possible to configure a RedHat system to boot with serial console. If you have the sort of facilities I consider normal for a multi-continental WAN, can you tie the serial port of your server machine to a terminal server and get remote access to the console? That would work around most of the problems with remote maintenance. > Sendmail: Does the system make it easy to replace sendmail with > another mailer of choice (qmail in my case)? Not as easy as it should be, but perfectly possible. I'm installing qmail from source, so I have to override the dependencies in several RPMs for "mailerdaemon". An alternative would be to build your own qmail rpms and have them provide that dependency. So far I've found that you can't make redhat install new without sendmail, but it's easy to rip out once the new install is done. I haven't found it appearing on upgrades, anyway. (I'm also using qmail). > Footprint: Is it easy to weed out unused system components to have a > smaller footprint of the OS? Or does that mean fighting the installer > left and right? For initial installs, you can pick each package individually. Of course that's a very long list to review. After the initial install, you can remove packages very easily (one of the great benefits of RPM). On upgrades, it only upgrades packages already installed (and may ask to bring in dependencies, if they've changed). > perl: Any iussues with perl/modperl? Besides modperl I will be running > a perl application with a few hundred thousend lines of code... I'm not stressing it hard enough to tell. The RPM version is working fine for me, but I'm new to mod_perl, don't have much using it yet. > Security: Is it easy to 'tie down' the system? No harder than any other system, anyway. The /etc/rc.d/init.d structure for controlling subsystems is very useful; that and xinetd are the two places anything is likely to be started. And tools like netstat are around (I like to check and make sure nothing I don't know about is listening to ports, for example, as a sanity check that I've really limited it to the things I want.) > Software-based RAID 1: Is it usable (only for a data partition, not > required for the root partition)? Is it easy to recover from a broken > disk? I'm using it on my primary web server for the user/web partition, seems to work fine. I've survived a broken disk and a broken controller, I think. (With today's prices, I tend to discard questionable components rather than pursuing diagnosis in detail.) > Robustness: While almost all systems I have are/will be on UPSs, they > still tend to occasionally be 'unplugged' (not shut down cleanly), be > it due to an empty or dead UPS battery, someone tripping over or > accidentaly unplugging the power cable etc. etc. Does the system tend > to survive the then due fsck without manual intervention? Better yet, > would it be possible to mount / and /usr read-only, and have a /var > partition that (if the worst should happen) can be recreated on the > fly? If you're doing a new install, use EXT3 (standard in RH7.2 and up at least), which is a journaling extension to EXT2. Doesn't have the large-directory advantages of ReiserFS, and you might maybe want to use ReserFS maybe; I dunno, haven't used it. EXT3 survives crashes *perfectly* so far (of course nothing is guaranteed to *always* survive perfectly). You should also look into appropriate connections between the UPS and the server to have it shut down in an orderly fashion when the 2-minute-warning comes on. I'm trying to do that myself and having endless trouble, probably with cable wiring, but especially for unattended systems you *really* want the cleanest shutdowns possible. > Any other oddities one should be aware of? Well, it's so much what I'm used to that I may not be aware of them. -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
