Kolab extension companionGroup for posixGroup functionality

[Gunnar Wrobel]

Hi Christian,

Quoting Christian Rößler <Roessler at FuH-E.de>:

> Hallo Gunnar,
>
>>> https://wiki.kolab.org/index.php/Kolab2_Integration_with_posixGroup
>>> from german to english.
>> Thanks a lot!
>
> :)
>
>> I started adding some minor fixes until the first questions popped up.
>> I only looked briefly at the scripts you uploaded and I guess I could
>> extract the information from there but I assumed it is easier to ask in
>> plain text.
>
> Please take another look - I have found to nice show-stopper bugs two
> days after uploading. Sorry for that.
>
> And also I have to excuse myself for another thing: I have thought I
> would find more time to document it on the wiki, alas - I found it not.

This is already a great start and I think it is quite okay to have  
some unfinished things in a wiki.

>
>> You seem to define all attributes available in posixGroup also in
>> companionGroup (except the cn). Why do you actually associate a
>> companionGroup to a Kolab user or a Kolab group (distribution list).
>> Wouldn't it be sufficient to declare a completely new posixGroup that
>> is independent of the Kolab user/group?
>
> Yes, in principle it would be entirely possible to declare an
> independent posixGroup. But then more than one point of management would
> be needed; my intention is to have just a single point, so to say.
>
> Another point would be a migration problem: Until now email group
> functionality was handled by (Suse Linux email server) alias entries to
> posixAccount. This too was translated (in a way): If a 'companion'
> posixGroup is built, also a kolab mail group (kolabGroupOfNames) is made.
>
>> What kind of information does the companionGroup draw from the Kolab
>> user/group it is associated to?
>
> Well, let's have an example (I will talk about that kolabUseMail later):
>
> Here the kolab group:
>
> dn: cn=test test,cn=groups,dc=kolab,dc=xxxxx,dc=de
> kolabHomeServer: kolab.xxxxx.de
> objectClass: top
> objectClass: person
> objectClass: inetOrgPerson
> objectClass: kolabInetOrgPerson
> objectClass: companionGroup
> sn: test
> cn: test test
> givenName: test
> mail: _tst at kolab.xxx.de
> uid: tst
> generateCompanionGroup: 1
> descriptionCompanionGroup: dghfdghdfgh
> gidCompanionGroup: 852
> kolabInvitationPolicy: ACT_MANUAL
> membersCompanionGroup: kro,kse
>
> generateCompanionGroup is set to 1 (generate), so a companion posixGroup
> will be built:
>
> dn: cn=tst,cn=groups,dc=kolab,dc=xxxxx,dc=de
> objectClass: top
> objectClass: posixGroup
> cn: tst
> gidNumber: 852
> description:: ZGdoZmRnaGRmZ2gK
> memberUid: kro
> memberUid: kse
>
> -> cn: generated from kolab group mail entry minus leading underscore to
> @ sign - this was a local requirement here. But it would be very trivial
> to get this from kolab group uid
> -> gidNumber: from kolab group gidCompanionGroup
> -> description: likewise from descriptionCompanionGroup
>
> Also a kolam mail group will be built:
>
> dn: cn=tst at kolab.xxxxx.de,dc=kolab,dc=xxxxx,dc=de
> objectClass: kolabGroupOfNames
> cn: tst at kolab.xxxxx.de
> mail: tst at kolab.xxxxx.de
> member: cn=Kontact Roe,dc=kolab,dc=xxxxx,dc=de
> member: cn=Kontact Sek,dc=kolab,dc=xxxxx,dc=de
>
> -> member(s): from ldapsearch: uid search for membersCompanionGroup
> -> mail: from cn:
>
> Does that help a bit? Please let me know any question you might have!

Yes, that clarified things and now I know what my original question  
should have been :)

I guess the thing I wonder about is why the companion group is  
associated to a kolabInetOrgPerson. This is represented by the  
modification I made to your text: You said "The Kolab server models  
groups by ldap object class inetOrgPerson, extended through the object  
class kolabInetOrgperson" which I rewrote to "Groups on the Kolab  
server are represented by the LDAP object class groupOfNames extended  
by the object class kolabGroupOfNames."

At the moment I don't see why it is necessary to attach the  
companionGroup to a kolabInetOrgPerson object rather than a  
kolabGroupOfNames. Especially since I assume you could get rid of the  
"membersCompanionGroup" attribute. The kolabGroupOfNames already has  
its members defined. So you would not need to specify them again and  
changes to the group could be reflected in the posix group  
automatically. It might be necessary to mark a kolabInetOrgPerson  
object as system user then to indicate that these can be part of a  
resulting posix group. But that would also make sense to me. You might  
not always want to have a mail user as a system user, too.

I'm probably overlooking something but I hope you give me a hint what  
it might be :)

Cheers,

Gunnar

>
> Best regards,
> Christian
>
> _______________________________________________
> Kolab-users mailing list
> Kolab-users at kolab.org
> https://kolab.org/mailman/listinfo/kolab-users
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------