kolab ldap migration questions.

[Bernhard Reiter]

John,

On Montag, 26. Januar 2009, John McMonagle wrote:
> Bernhard Reiter wrote:

> > On Donnerstag, 22. Januar 2009, John McMonagle wrote:

> >> Here is  one of our current records:
> >> dn: uid=bradb,ou=People,dc=advocap,dc=org
> >> uid: bradb
> >>    
> >> From kolab test:
> >> dn: cn=Brad Bingham,dc=advocap,dc=org
> >>    
>
> Doesn't a dn have to be unique.
> If so it's probable a larger organization will have more than one person
> with the same name.
> uid needs to be unique anyway.

it is true that a dn must be unique. 
Larger organisations could consider using more dn elements
or a different dn scheme. The current scheme has a history,
for some discussion see
kolab/issue1549 (Patch to change dn: cn=... -> dn: mail=...)

> If I were to keep our method is there any "simple" way to change
> kolab's  settings.
>
> Particularly the user data is used by a lot of different programs. It
> makes me concerned if forced into a particular format.  What do I do
> when 2 systems require different formats.

That is a general problem with several applications trying to use a directory 
server and (missdesigned) LDAP.
You need to check the requirements and details and might need to adapt
some of the applications. Kolab Server can be adapted a lot, so you are not 
completely at a loss here. Still doing this change might require some 
experience. I wish it was simpler, but apparently it isn't.

> Sort of related.
> If an external program creates a new ldap user does one have to manually
> create the imap mailbox?

No, kolabd will pick changes up and create the imap account for you.
So using external LDAP tools is fine.

> I doesn't see anything in kolab admin concerning groups.
> Do I need to be concerned migrating groups at all?

Maybe.

> I see a substantial difference in mailing lists :-(
> A simple example
> kolab:
> dn: cn=postmaster at advocap.org,dc=advocap,dc=org
> objectClass: top
> objectClass: kolabGroupOfNames
> cn: postmaster at advocap.org
> mail: postmaster at advocap.org
> member: cn=John McMonagle,dc=advocap,dc=org
> structuralObjectClass: kolabGroupOfNames
>
> advocap:
> # spam, Aliases, advocap.org
> dn: cn=spam,ou=Aliases,dc=advocap,dc=org
> cn: spam
> rfc822MailMember: sysmail
> objectClass: nisMailAlias
>
> Have the company mailing lists defined as rfc822MailMember.
> No way a simple search and replace will fix this :-(
> I could edit /kolab/etc/postfix/ldapdistlist.cf
> That will make postfix happy but am I likely to regret it?

I would make a list of necessary email paths and tests this after a change
to be sure. Those kind of configuration changes are sometimes necessary.

> Was thinking maybe could run both mailing list methods  at least for a
> while.

Sure, why not.
Note the Kolab's groups (aka server distribution lists) can be used to set 
ACLs for IMAP folders.

Bernhard


-- 
Managing Director - Owner: www.intevation.net      (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 206 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/users/attachments/20090127/dfdfdf74/attachment.sig>