Linux == reduced life expectancy

Miscellaneous Topics
#1

EDIT: some great good may come out of all this. Eventually I switched to using Courier-MTA as the email server, and …it has a fully documented and fully configurable system for using arbitrary MySQL databases to provide all the authentication data. user@jgf.org email accounts appear to be very simple to provide…don’t even have to change the DB (courier lets you use any schema)

Debian is the only linux distro which is safe enough to use in production.

Debian is the worst documented of all linux distros. Most of the docuementation is WRONG, and lots of really important stuff (like the one-line change you have to make to Bugzilla’s conf after you install, the default of which is pretty much “disable_myself ==true”) is UNDOCUMENTED.

I’m trying to configure a mailserver on a Debian system. 1 hour later, I STILL can’t find the fricking documentation on the config for mailservers on debian.

Most docs say “run eximconfig”. Eximconfig has been deleted from Debian as of over a year ago and has no replacement.

IF you try and manually edit exim conf, you discover they have f*cked it up and made their own propriteraty config system for this ONE piece of software.

If you try to use the Debian proprietary config system you find references to lots of variables which are debian specific and undocumented, but have the word “debconf” inside them.

Debconf is supposed to be used to configure all Debian programs. Weird. I’d never used it, never even heard of it. Why? Oh. That’s right - there’s NO DOCUMENTATION FOR IT.

I ran the manpages: “man debconf”

Brings up a 3-line file saying “see debconf(7)”

Debconf(7) doesn’t exist. I tried on other debian machines - doesn’t exist there either. Eventually…I discover another website that says debconf is documented at “debconf(8)”.

Doesn’t exist either. Look it up yourself in your favourite manpages site - only debconf(1) exists, and it tells you the documentation is located in debconf(7) which I’m starting to think doesn’t actually exist on this damn planet.

****ing - *** ****ers. As they say, I feel like “Punching them till my knuckles bleed”. My only option appears to be to remove all email packages from Debian entirely and then manually install (breaking the Debian packaging system) a copy of exim which has NOT been hacked by morons and so I can actually just use the real, standard, fully documented, extremely widely used exim.

The stress of this ridiculous farce must have taken a good few weeks off my life expectancy. So, be warned folks: debian is slowly killing you :P.

Just don’t even try to install and maintain an email server on Debian, that’s my advice.

#2

Crikey, this is close to belonging in the land of the trolls.

Kev

#3

I thought it might spare someone some pain before they got started. Or just amuse those who are prone to schadenfreude…

#4

[quote]Debian is the only linux distro which is safe enough to use in production.
[/quote]
Oh really?! I do wish you’d told me this 4 or 5 years ago before we installed redhat in our production servers. Excuse me while I phone up our sys admin team, get them to format our 10 or so servers running Fedora Core immediately and install Debian, since you obviously have so much experience in these matters. I’m sure they’ll probably object. After all, we’ve been running Redhat in prod for years without any hitches… but no, it’s now obvious to me that we must’ve been wrong.

:stuck_out_tongue:

#5

Yeah, sorry Blah but I don’t agree with you either. Our production Fedore Core Linux servers are fine, have been for years, and likely will be for years to come.

And as for the docs, you have to learn the “Linux way”: if you want to use a Linux server for any mission-critical work, don’t use the bundled apps! Download a known unmodified version from the developers’ website, install and configure. Ignore the fact that you’re “breaking the packaging system” - that’s also irrelevant. This way you have the developer’s code, with the developer’s documentation - and can likely get support on it… from the developers.

Concerning your missing file, 2 minutes and Google turns up “Bug#275768: debconf: debconf(7) man page missing”, so they know about it and will likely fix it in time. But that’s irrelevant - Debian have modified the software, so you shouldn’t be relying on it; get a fresh copy from the Exim developers.

#6

LOL. Sure it’s a personal opinion, but it’s based upon the bug in the linux kernel which means installing redhat packages can prevent you from recompiling your kernel. Last time I checked, the kernel sources haven’t been changed, and RPM is still buggy, so you’re still at risk of buggering your server. Been there, done that, not pleased. Debian doesn’t prevent this, but it reduces the chances from “small” to “minute” by making it much much less likely you’ll ever get a screwed RPM setup.

Every single RH I’ve run since RH 7 has, sooner or later, broken it’s RPM database. The system will carry on functioning but, usually, you can no longer compile kernels.

Debian’s superiority comes partly because it’s better tested overall (RH testing has historically been really poor - their network installer was broken with the same 5 showstopper bugs for 3 successive releases (5, 6, 7) and still had one or two of them in 8! That was ridiculous) but mainly because it’s packaging system is much less likely to break, both in small ways: the design (slightly better), the UI (much better) and in big ways, such as the base packages (much much better tested) - which make it much less likely to break.

I’ve admined 5+ different debian machines now for approx 12 months, a mixutre of workstations and servers, and no-one has managed to break the packaging system. We have had one bad package that had problems, none of them dangerous to the system, and we had to contact the authors and get them to fix their package. In the same time period with RH, I usually see 5+ bad packages on the server (of which one may be a seriously dangerous brokenness) and 15+ on the workstations (of which 3-5 are seriously bad).

I belive the BSD’s packaging system is even safer but we can’t use them on any of the machines because of problems with BSD itself being not linux, along with some major system-level bugs in the BSD’s (for instance some very bad networking problems in each of them, which we unfortunately cannot live with).

#7

For production deployment, I simply don’t have the time, manpower, and too much responsibility to avoid the packaging system. We need efficiently maintainable systems, and packaging saves a huge amount of time and effort when doing maintenance, backups, particular builds, etc. With a bigger budget for these systems, and 3-5 100% linux-maintenance personnel it woudl be the way to go. But it’s always going to cost you money, forcing a significantly inflated busget on you :(.

LOL. So…possibly the attitude one needs for D is “if anything goes wrong with debian, don’t bother trying to fix it, search the debian bugs DB first”. I’ve spent years getting into the habit of assuming that any linux admin problem wasn’t a bug but a feature I just misunderstood, or a typo in some seemingly irrelevant field, or that you used the letter “t” inside a variable value and for silly reasons you weren’t allowed to.

But my experiences are pointing me in this new direction.

Yup. I finally found the debconf author, who explained how to get at the docs. I read the docs, and they don’t include an explanation of the magic DEBCONF variables that pepper the application config files (the “complete user’s guide” turns out to be just a few pages long) so I’m completely giving up at this point. Those variables don’t exist anywhere in any script on the system, so they must be internal logic from debconf, i.e. presumably you have to read the DEBCONF developer’s guide, learn how to write applications using debconf, and only then are you allowed the knowledge of how to configure someone else’s application. Just like the good old days of linux support mailing lists with responses like “if you have to ask that question you don’t deserve to know the answer” :P.

Insult to injury: all the debian stuff for the previous version of exim works fine, and is NOT bastardized, because I’ve actually maintained exim3 stuff using Debian. But…exim3 is so out of date that the original developers don’t touch it any more and, basically, if new security holes are found no-one’s going to patch them. Ha. Debian + exim works fine, so long as you don’t mind using a copy of exim so old it’s dangerous (old/unsupported mailservers loaded onto a hosted server are something to fear, IME).

#8

[quote] Download a known unmodified version from the developers’ website, install and configure.
[/quote]
EDIT: below when I say “not possible” I really meant “not possible to remove the MTA”. I was intending to have two MTA’s sitting on the hard disk (debian forces you to) and one of them just delete it from all startup scripts. In the end, I decided to just install and use courier, since Debian haven’t screwed up the config for that one :).

I don’t think it’s possible. :(. Debian won’t let me. That “package system so great it prevents you from breaking your system so that you can’t compile the kernel” is so good it’s preventing me from breaking the system. I would cry, so I’m jsut going to laugh instead.

Unfortunately, lots of packages (any distro) have stupid crap like this in them. For instance:

  • mysql server requires you to have an email-reading application
  • the email applications all require an email server to be installed

Very hard to see why either of those are requirements hard-coded in and unavoidable. I actively do not want MySQL to ever read any email from anywhere. Equally, I don’t want any email client on this server only machine that will never be configured to accept incoming emails and will never have anyone logging in to read system mailboxes.

Sigh. Sometimes just using linux feels like bashing your head against a wall made by the people who think that just because they like “cool features” those features must be forced upon the rest of the world - like the stereotypical linux user who visits your house and while you’re getting them a cup of tea they’re deleting telnet from your machine and replacing it with ssh (has actually happened to me, once).

The fact that telnet is essential to anyone doing network protocol testing (it’s a TCP protocol testkit!) is something that you have to patiently explain to such people using words of no more than one syllable, preferably whilst they’re sedated so they actually listen.

(tongue in cheek. Although I would probably go postal if someone just walked in and did this to one of my network dev workstations…)

EDIT: PS: Apologies for being a grump; this kind of crap just trying to do something trivial (get javamail API to work) has delayed JGF work by 5 days. In the first place I don’t understand why Sun released an API for sending email that doesn’t include a class that sends email (it only includes classes to login to someone else’s mail server and upload emails), and my tolerance has been worn down by each blow since then. Sigh.

#9

I have the perfect solution for this!

FreeBSD :slight_smile:

DP

#10

[quote]I have the perfect solution for this!

FreeBSD :slight_smile:

DP
[/quote]
Getting all the linux apps to run is too hard or too scary.

And the last I heard, the networking layer is buggered in most of the BSD’s at the kernel level, using O(N) or worse algorithms for functions that are supposed to be O(1) (And are, in linux). Although, IIRC, FreeBSD has considerably better networking than the others, even the one supposed to be good at networking?

Just my little bit of FUD. But investigation gave me enough confidence that those might be accurate that I couldn’t risk it.

#11

no no noooo, FreeBSD 5.1 is the networking thing you were referring to. Its at 5.3 now (5.4 is the due stable release)

The networking of freebsd is the best i have ever seen. It has more drivers than all of the linux distros combined (over statement, but you get the gist).

I have never managed to get Samba to work on any linux distro, but it worked flawlessly in freebsd. I even managed to get it to bind with our ActiveDirectory server.

Its very neat, you should give it a shot on a test pc. If it doesn’t impress u like debian does and more, I will get my head shaved and stick it on my monitor! ;D

DP

#12

Just to be clear: I couldn’t care less about the drivers, it’s the fundamental shared features, like how it manages readiness notifications, file-descriptors for connections, etc. How fast can it iterate across 5k connected channels and find those that are ready, how efficient is the kernel at pullign data out of the NIC buffer and into the application across all drivers (i.e. what’s the kernel overhead etc).

That’s saying a lot :). Then again, the real test of Samba is: can you mount the samba server as part of your root FS in linux, and then kill the server, without it screwing up all your cilent machines? The samba mount daemon stuff and kernel modules are FUBAR (just a pile of turd, really), so much so that IIRC the samba project disavows any involvement with the linux kernel module because it’s so bad. Maybe that’s been fixed by now in the linux kernels.

#13

Well, debconf is the tool, which configures your packages. Were you never asked any question when you installed a package? You can reconfigure your package using "dpkg-reconfigure ", where stands for the name of the package you want to reconfigure. If you want to reconfigure debconf itself, then you have to run “dpkg-reconfigure debconf”. Debconf only does some basic configuration to make life easier. It does not stop you from editing the config files manually. Actually that’s an advantage. If you want real help, then please ask in an appropriate mailing list / newsgroup like linux.debian.user (if the problem is really Debian specific).