OT: linux dists and such (Re: Off Topic Telnet problems)

[Bill Campbell]

On Wed, Mar 18, 2009, Fairlight wrote:
>On Tue, Mar 17, 2009 at 04:08:46PM -0700, Bill Campbell, the prominent pundit,
>witicized:
>> 
>> We are talking OpenServer here so sanity isn't in question.
>
>If I hadn't been watching Alias tonight, that would have actually been my
>best laugh of the day.  :)  Good one!

Glad to give a grin.

>> Be aware that major Linux vendors (e.g. Red Hat/CentOS) do not
>> support SHA1 passwords in their standard installs, which can be a
>> major PITA if moving from SuSE boxes that support it.  We
>> generally use MD5 as it is reasonably secure, and is supported by
>> any Linux using the normal glibc crypt extensions.  Naturally I
>> found out about this the hard way.
>
>You know, I totally misspoke.  Kind of understandable if you know what I'd
>been working on lately. :) I was recently working on some mail syncing
>software, and I was using MD5 initially to track checksums to hash files
>on a combination of message headers that should always be able to uniquely
>identify a message (in theory, and 99.9999%+ in practise, barring forged
>spam).  I had started off using Digest::MD5 for my checksums.  Partway
>through, I ran into issues where I was seeing duplicates and didn't
>think I should have been.  I was worried MD5 was broken.  I switched to
>Digest::SHA1 and it -still- gave me duplicates when tracking.  Turns out,
>forged spam -was- using the same Message-ID.  That's when I added in the
>Date: and all the Received: headers, figuring there was pretty much no way
>in hell you should ever get 100% matches across that entire subselection of
>headers.  I never reverted back from SHA1 to MD5, as I had no real reason
>to.  They're functionally equivalent for my use in this context.

My mail delivery routines use MD5 digests of the entire message
body, using that as the main part of the Maildir file sequence
which makes it easy to detect duplicate messages by simply
splitting the file name without recomputing MD5 digests.

One item on my round-tuit list is to build a database of
spamassassin scores indexed by the MD5 digest to allow me to
bypass the rather expensive spamassassin checking on identical
message bodies with high SA scores.

>So the last thing I used was SHA1 in that context.  As such, I had that
>fresh in my head. *sigh*
>
>When talking earlier, I just had SHA1 on the mind, and forgot that MD5
>was the most common newly introduced standard for the password field
>and reversed them in my mind because I've worked with both lately.  Not
>explicitly for passwords, but in general.  You're right, of course; MD5
>passwords are in use on RHEL, not SHA1, and SuSE did fairly recently
>introduce SHA1 for authentication.  I think just in the 10.x series, yes?
>Does FBSD support SHA1 yet?  Not that I've seen a reason to go past MD5.
>Different algorithms, but I thought they were both relatively equivalent in
>terms of the results being unique, etc.  Fair assumption?

Somebody in an earlier post talked about having the encrypted
password in the /etc/passwd file, which is a major NO_NO.  These
should be in /etc/shadow, which should be readable only by root
or other processes necessary for authentication.

IMHO, machines that only handle DES encryption should be well
behind a firewall with no direct access from the Internet.

>What really annoys me is that SuSE keeps changing what they think the
>default encryption should be at installation.  I really feel it should have
>stayed at MD5 once they implemented MD5.  There are security implications
>to leaving it at DES, or I'd have said they should have defaulted to a
>long-standing standard and let the admin check.  But I'm sick of them
>putting in something new and just assuming that people are going to catch
>that they've decided to switch horses again.

That describes my biggest gripe with Linux, and to a degree other
open source software.  The developers tend to forget about
backward compatibility, and think their way is the right way
(kinda reminds me of Ivy League elites who think they know it all).

>Actually, Novell has royally ticked me off in the last 2.5 years.  SLES10
>has been a royal PITA.  If I had to make a call, I'd just go with OpenSuSE
>and stick with that, to be honest.  An investment in Novell is -not- worth
>it unless you flat-out have no linux admin at all.  Licensing the
>professional versions is pretty much useless.  You get NO support from them
>past installation, even getting them to talk to you semi-officially about a
>bug that -their own service pack introduces- will cost you $675 unless you
>have a contract with them, and you get to deal with ZMD and all that cruft.
>Plus the lack of SRPMs, and a dependance on a single point of distribution
>instead of mirrors that you can hop around.  Novell's done no good for
>SuSE, IMNSHO.

That's the main reason we moved from SuSE to CentOS a couple of
years ago.  Even though we were Novell ``Partners'', we could not
get many questions answered.  The CentOS mailing lists have been
far better in that regard, and Dead Rat's documentation isn't bad
either.

There are many things I like about SuSE's engineering, but we don't
use most of the distribution's back-end server stuff in any case,
replacing it with the OpenPKG portable package management system's
packages which are easy to build on any of the *ix platforms we
support.

...
>Next time around, I'm pushing for a non-commercial distribution.  Probably
>OpenSuSE.  Fedora is too rapid-fire chaseware.  I don't like the political
>agenda and philosophizing that Ubuntu brings to the plate.  Debian is so
>far behind the curve, I don't even consider it modern.  CentOS may be a
>contender but I'd have to look at it first.

CentOS is basically Red Hat Enterprise Linux without the huge
fees.  CentOS releases tend to lag RH by a month or so as they
build and test the upstream packages into their own repositories.
We started with CentOS 4.5 several years ago, and I have been
pretty happy with it since then.

I am not a particular fan of Red Hat, going back to the early
days when we were using Caldera, largely because RH tended to
release things with incompatible libraries, and with what
appeared to be little testing.  I have not seen similar problems
with their Enterprise releases though.

I am planning on looking at OpenSolaris for file server
applications so we can take advantage of the zfs file system.

Bill
-- 
INTERNET:   bill at celestial.com  Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/  PO Box 820; 6641 E. Mercer Way
Voice:          (206) 236-1676  Mercer Island, WA 98040-0820
Fax:            (206) 232-9186

Make no laws whatever concerning speech and, speech will be free; so soon as
you make a declaration on paper that speech shall be free, you will have a
hundred lawyers proving that freedom does not mean abuse, nor liberty
license; and they will define and define freedom out of existence.
	- Voltarine de Cleyre (1866-1912)