DoveCot vs Cyrus-Imapd Performance

[Aleksandar Milivojevic]

Les Mikesell wrote:
> Yes, the bits and pieces are all there, although I'm not sure the
> mail part is really standard (do sendmail/postfix/cyrus all use
> the same thing, and what about aliases and groups?), but how useful
> is it if you can't expect all versions to match?  You also need a
> tool that populates all of the common fields at once.  By default
> you probably want the posix, samba, and email accounts to match
> without typing them again and you'll want to change passwords in
> one place and affect them all. Redhat/fedora has the market share
> to become the standard if they just shipped something that came up
> working as installed.  I doubt if anyone else can do that now.

I don't see where's the problem.  You want user to have attributes from 
posixAccount?  Add posixAccount to list of his objectClass(es), and than 
you can add attributes that are defined in that class, and use LDAP as 
replacement for NIS.  You want to add Sendmail LDAP mail routing for 
that user, add inetLocalMailRecipient to list of his objectClass(es), 
and add attributes such as mailLocalAddress or mailRoutingAddress.  You 
don't create separate tree for every service that needs to store data 
about user.  You add object classes needed to describe user to his 
objectClass attribute, and than you add service specific attributes.

As for passwords, old style Windows passwords needed to support older 
Windows implementations are not compatible with more or less anything. 
So those will have to be separate.  Even in Active Directory, they are 
stored as base64 representation of UTF8 plaintext password.  The reason 
is basically the same as behind using smbpasswd file.  More or less 
anything else should be happy with userPassword attribute.  If all your 
Windows clients are 2000 and newer, Kerberos in combination with Cyrus 
SASL might save you there (depending on your actual configuration, and 
what really you want/need to implement).  Either have Windows side 
authenticate against Unix-side Kerberos server, or have slapd use 
Windows side Kerberos server to authenticated against Active Directory 
domain (use {SASL}username at KRB-REALM.COM as value for userPassword 
attribute).  Works both way.

If you don't like fiddling with LDIF files in vi editor, use GUI tools 
such as gq, jxplorer, and/or ldapbrowser (there are probably others). 
Those are general purpose tools (basically GUI versions of 
ldapsearch/add/modify), however they do the job fairly well.  The only 
thing Fedora folks might do, IMHO, is to include one of them into 
distribution (probably gq, since jxplorer and ldapbrowser are Java 
applications, and they don't work with gcj, or at least I couldn't get 
them to work with anything but Sun's Java).

Want something more custom made for your installation (rather than 
general tools)?  There are easy to use Perl and PHP LDAP modules that 
will let you develop whatever interface for managing users you might 
wish.  You type add_user.pl, and script sets up user in LDAP database 
whatever way you want.

-- 
Aleksandar Milivojevic <amilivojevic at pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7