gosa

[John McMonagle]

On Friday 20 March 2009 01:41:40 pm Benoit Mortier wrote:
> Le Friday 20 March 2009 19:18:27 John McMonagle, vous avez écrit :
> > On Friday 20 March 2009 05:06:39 am Benoit Mortier wrote:
> > > Le Friday 20 March 2009 05:42:46 Gunnar Wrobel, vous avez écrit :
> > > > Quoting John McMonagle <johnm at advocap.org>:
> > > > > Any opinions on gosa and kolab?
> > > > >
>
> - some import of specific objects from kolab ldap to the your ldap if you
> don't use the ldap server from kolab, mainly the manager and other
> special users.
>> - some change to the template and / or files to tell him where the ldap
> reside if not using kolab ldap.
>
> other than that it should roll
>
Thanks 

Not really gosa issues but brings up a couple more issues.
I wonder what kind of issues there will be with upgrades if the kolab server 
is not the ldap master?

Some of my sites have poor network connections and slurpd replication doesn't 
work well. Don't want to consider using slurpd again.

 I can think of 4 possible ways to do the ldap for kolab.

1 Use kolab openpkg ldap as master adding sync replication. 
2 Use kolab openpkg ldap as sync replication slave.
3 Use openldap install on kolab host as sync replication slave. Disable 
openpkg ldap.
4 Use openldap server on the local network.  Disable openpkg ldap.

At the moment my preference is  3,4,2,1.

What problems are there going to be during upgrades?

The biggest thing I can see is any schema and acl changes may need to be 
manually made through the system first.  As schemacheck is on could be an 
issue on a pure openpkg system with multiple kolab servers.

John


> I have to make a new install start of april will try to put some
> explanations in the wiki.
>
> > I'll need to to a lot of tweeking to ldap anyway.
> > At the moment working on my ldap conversion strategy.
> > Have 6 ldap servers not counting kolab.
> > At the moment breaking kolab is the least of my concerns :-)
>
> Sure
>
> Have a nice evening