LDAP schema ?

[Steffen Kaiser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 21 Apr 2017, Mihai Badici wrote:
> On Friday 21 April 2017 08:36:47 Steffen Kaiser wrote:
>> On Tue, 18 Apr 2017, Dave Dodd wrote:
>>> I am trying to determine the correct LDAP schema I need to use to have
>>> either mailLocation or mailboxPath available ?
>>>
>>> Should I be just adding this to one of my own custom objectClasses ?
>>
>> Surprisingly, lots of installations seem to work with standard schemas -
>> if you believe internet search results.
>>
>> Dovecot's LDAP connection is very generic, so maybe it's easier to adopt
>> Dovecot to an existing infrastructure than vice verse.
>>
>> However, I have added several Dovecot related attributes and some
>> objectclasses to my schema, esp. to support the generic userdb_import .
>>
>> --
>> Steffen Kaiser
> Let me summarize:
> In fact, when using the /etc/passwd the only information dovecot need is the
> username and the password.
> So if you switch to ldap you only need those attributes. ( The e-mail address
> is not needed by dovecot, but is needed for MTA)
> You can then use the inetorgperson schema without problems.
> But, since you want to use LDAP, you probably want to take advantage of the
> user managements tools, you want to use a Global Address List, maybe multiple
> servers etc.
> When I started to configure my template, i searched for a schema with
> "vacation" attribute. I even wrote a postfix filter who used this attribute to
> generate autoresponder messages. I found ispenv2.ldif , i still use it, even I
> switched to sieve for autoresponder so i don't need vacation anymore.
> But ispenv2 has also some nice attributes for managing users "ISP style":
> details about payment, contract, price, user disabled etc
>
> In the mean time I started to use parts from the kolab project. So I consider
> to start using also their schema in the future, because it has some attributes
> useful for enterprise usage scenario ( and because I want to have some
> compatibility)
>
> So, at the end, the reason for choosing a schema or extending the existing one
> is not related mainly to the mail system ( which works great with
> inetorgperson schema, for example) but rather to the organizational model you
> use .

Yes, my thinking, too. I have:

quota
mail location (as override for some users)
import (generic, for anything else, e.g. some users have a home override 
or specific system_uids or groups)

Actually I discovered import too late, otherwise I would not have added 
quota and mail location as stand alone attributes.

There are some other local attributes for other services, so they don't 
hurt. :)

- -- 
Steffen Kaiser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEVAwUBWPm3tnz1H7kL/d9rAQKoAQgAl4XHW+0DW6+gk1O6AAJu0+5+nRP6756g
4a3hl/+7o3qBOOMma8kPxy6IEWAQu0cCI9r3CVeR8aCLL3HNPgArhv+eOH9FWL1n
I3DSutLQDTZbb1jMafAuBiykA5A04vk3SAsHA24UgwmjSK2rEkM29U91FEW9umrm
jcolgrLJrloWG1JAaePaNopx7TneDBbHFLlwn4to0t8Ra0OHAA60tEuF0EfXPWLl
2QJz+hq1gPhQ2K3C1dSSK7e7AAdX/Nvm/x7ehXFHpq1KAGnMteeAaDuk1nD+f43F
S5wgcASFOzIMKD2NxkMvBbvR79Ly0YHmJ4JFVa9SBwBOzGQ0dUPxwA==
=cFDV
-----END PGP SIGNATURE-----