Re: ISP asking about switching to Debian from OpenBSD
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
Reply to: