David Batey said: > > I work at a midwest ISP, and we've got an opportunity to switch > from an older openBSD to something more recent -- and apparently > upgrading to the current openBSD might be as much of a chore as > switching to something entirely different, such as Debian.
i switched a few systems from openbsd to debian last year .. i doubt ill try openbsd again anytime soon. although i am working on deploying freebsd systems... > STABILITY: is Debian a good choice for heavy lifting? I know > about apt-get for easy installation of bug/security patches; does > the ease-of-install ever compromise security or functionality? > OpenBSD is pretty secure; how does Debian compare? Is Woody ready > for prime-time yet? (If not, would an upgrade from potato to > woody likely cause hiccups?) in most cases the ease-of-install does not compromise security. i can think of one(IMO) glaring security problem in debian, that is the (now almost a year old) DOS attack against the openbsd ftpd port in debian potato. ive reported it to multiple places(including the security list) but never got a reply. woody is ok for prime-time PROVIDED you don't upgrade it often. i have 1 woody server in production(compared to about 38-39 potato servers). and i very rarely upgrade it. it serves a very specific purpose, to run web apps that would not run under potato even after weeks of trying (ezpub - developer.ez.no, and also webrt www.fsck.com tho i didn't try rt under potato i just deployed it straight to woody because of the bleeding edge perl requirements) for any other server i would(and do) use potato. i don't like upgrading often. > > FUNCTIONALITY: We need DNS server packages, ssh (with ssh > tunneling available for other services), smtp/pop, web-based > scheduling/claendaring/email facilities, HTTP (apache/mod_perl) > servers, and so on... all is available. i heavily modify the BIND setup that debian has to run in chroot() and as non root uid/gid. openbsd is much easier to do this with(just flip a switch in one of the conf files). some don't like the SSH1 protocol which potato ships with, i personally think it is ok. especially combined with forced RSA authentication(e.g. do not allow password logins). security is really most important with untrusted users. i don't run any systems with untrusted users, and haven't for quite a while. back when i ran an isp i had my servers page me anytime a user logged in with username/IP/date/time of login. with a lot of shell logins this probably wouldnt be very fun to deal with tho. one of the biggest cons to openbsd i found was upgrading. i wanted to upgrade my nameserver which ran openbsd. from the docs i found the only way to do it was from cvs. and doing it from cvs, everything i read said i'd be reinstalling EVERYTHING. its not really an upgrade, but a reinstall/overwrite. i tried several times to upgrade but the compile kept puking(memory error). i got pissed because it was compiling stuff i did not have installed and did not WANT installed like kerberos. from the folks i talked to they said this is expected behavoior. that shocked me..i expect an upgrade to upgrade what you have, nothing more. the only binary upgrade i could find for openbsd was boot from the cd and do it, and that doesn't work if the server is 1100 miles away from me. so i had a guy that was local to the colocation replace the server with a debian one. least i can upgrade from potato->woody without even a reboot when the time comes (ive already done it twice ..) biggest con to debian is the near immediate abandonment of "stable" releases once a new "stable" release comes out. e.g. security/other fixes are not backported to the previous stable release. other vendors like redhat, suse, sun, etc(not sure about the bsds) typically backport their security fixes(at least) to the previous 2-3 stable releases.i wish debian would maintain that, at least backporting security fixes(nevemind the rest) 1 stable release. in this case, if a problem was found in potato, backport it to slink(if slink was vulnerable). i was worried when potato came out i had a slink system that was pretty heavily modified, and at a remote location, did not want to risk trying a dist-upgrade from remote, luckily the server was decommishioned a few months later and i didn't have to worry about it anymore. hope this helps. nate
