gosa

[Benoit Mortier]

Le Friday 20 March 2009 21:17:47 John McMonagle, vous avez écrit :
> 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.

My preference is 4,3,2,1

> What problems are there going to be during upgrades?

i desactive the openldap from kolab completely and use a real openldap 
instance with my GOsa setup.

If you use the openpkg stuff you have to be carefull that i doesn't change 
the template you modified to use another ldap serveur.

If you are running on debian just use the package made by mathieu parent 
they are really good and integrate very well on debian
 
> 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.

In openldap 2.4 you can store schema inside openldap so that way you just 
replicate schema like everything else...  

Cheers
-- 
Benoit Mortier
CEO 
OpenSides "logiciels libres pour entreprises" : http://www.opensides.be/
Contributor to Gosa Project : http://gosa-project.org/