[TriLUG] The buck stops here (unfortunately)

[Aaron S. Joyner]

rwshep2000.2725323 at bloglines.com wrote:

>I am an apps developer for a small company, and I happen to also be the manager
>of our IS department, deservingly or not.  I am faced with a fairly important
>decision about our email, and being a relative Linux newbie, I feel unqualified
>to make it without some additional assistance.
>
>My sys-admin, god love him,
>a F/OSS guru, keeps me on my toes.  The current proposal is to change our
>email server as follows:
><...snipped...>
>His rationale...
>  
>
I'll attempt to address each of these specifically, and provide what 
insight I can.

>"I want to replace OpenLDAP with MySQL for the accounts.  Making SQL queries
>will be more intuitive for both of us, vastly increasing the amount of control
>we may exercise over the system."
>  
>
Disclaimer: I am not yet quite comfortable with LDAP, and I think a lot 
of people feel that way.  I can set it up, and make it do the base tasks 
I want, but I honestly don't have my head all the way around it's 
internals yet (and we use it for the TriLUG servers *blush*).  On the 
other hand, and I think this is true of most people, I get MySQL.  Maybe 
it's just because it's required for other tasks so I have more 
experience with it, or is fundamentally more transparent, but *most* 
people are able to do magical tricks with SQL, compared to what *most* 
people are capable of doing with LDAP.  It's always good to leverage 
that existing knowledge, if your situation permits it.

>"The reason I want to use certs is, simply,
>to make my life easier on the mail server.  Our current SMTP AUTH process
>uses SASL ("Simple Authentication and Security Library", although there's
>little simple about it).  "
>  
>
This is a misnomer.  It's entirely possible to use TLS *and* SASL on the 
same mail server.  In fact, I do it myself.  Having both allows you to 
do interesting things, such as only allowing encrypted (Digest, CramMD5, 
etc) authentication when your are using an unencrypted channel, and if 
you do use an encrypted TLS/SSL tunnel, allowing plain-text 
authentication (PLAIN or LOGIN).

>My initial reaction is, if it ain't broke why
>fix it.  But if this is a better solution, then I'm willing to approve it.
>  
>
I certainly share this perspective in a lot of respects, but don't 
forget that systems do require maintenance, and occasionally overhauls, 
to keep the daily maintenance to a minimum.  A real big concern I would 
have, which you didn't expressly mention in your email, is the ease with 
which those two systems can be updated.  The older RH system is going to 
require a good bit of care and feeding by hand.  It's probably running 
an older kernel which is not fit for allowing local user-level access 
(privilege escalation bugs, etc).  If it's not running that older 
kernel, then it's definitely a headache to manage because you've (at 
some point) had to either roll your own RPMs for a lot of stuff, or move 
away from the package manager in not-so-small ways.  The Debian 
alternative your admin is proposing will allow for much easier upgrades 
of individual packages (think security and small features), as well as 
major distribution upgrades (think not having to make this choice again, 
in so substantial a way).  Debian is much more capable of upgrading from 
an old Woody or Potato based system, to a modern distribution such as 
the current testing branch, Sarge, or even SID (not recommended).  
RedHat and it's derivatives are not so flexible.

To speak to Jason's particular recommendation that local user accounts 
might be preferable, I'm going to take a guess.  You've probably got 
centralized authentication going either via an Active Directory domain, 
or something else that ties your various machines together (probably not 
Kerberos/LDAP or I doubt you'd move away from it).  Because of that, 
it's not likely that you'll be able to implement local user accounts in 
a reasonable fashion.

Also to touch on another topic that wasn't directly mentioned - the 
(presumed) change of POP/IMAP server from (probably) UW-IMAP to 
Courier.  You didn't mention what the old system runs, which I'll guess 
means you're using the default for RH, which was UW-IMAP back in the 7.x 
days.  Courier is a bit more complicated, conceptually, but the benefits 
are well worth it in my opinion.  Courier's benefits shine with virtual 
users and domains in particular, because it allows you to virtualize 
accounts entirely.  There is no required relationship between a login 
account, and an email account.  Make sure your admin understands how to 
make the migration work (the mail is stored very differently in the two 
types of mail systems), and make sure he understands the difference 
between procmail and Sieve rules (and how to migrate those as well).  I 
imagine if he's proposing this solution, it's been tested at least to 
some degree - so these issues are probably all covered, but I would be 
burying my head in the sand if I didn't at least mention it in passing.

Personally, I've been recommending SquirrelMail over Neomail lately - 
but I wonder if anyone else has any thoughts on that.  Anyone on the 
other side of the coin who prefers Neomail to SquirrelMail?

Aaron S. Joyner
System Administrator
Triangle Linux User's Group
Intrex.net Internet Services