From kvapss at gmail.com  Thu Nov  1 15:40:13 2018
From: kvapss at gmail.com (kvaps)
Date: Thu, 1 Nov 2018 15:40:13 +0100
Subject: [Kolab-devel] Kolab and FreeIPA article
In-Reply-To: <CAGO-sgOmv+-biFyQQO1ik_QPMS8v4iWDKu2rRZoJuVroNPr0GQ@mail.gmail.com>
References: <CAGO-sgNbkrtPFLNvbp4hh7myJz4LRjOG7mi+dGR6Mjv5gVy45A@mail.gmail.com>
	<83r2hgyt1l.fsf@jochen.org> <20181001090802.GE5318@reaktio.net>
	<CAGO-sgMxg7wQKLK=VAyio3uG6Kc5Vce2=2_TwgevZsv+_SmsUw@mail.gmail.com>
	<20181003153829.GG5318@reaktio.net>
	<CAGO-sgNmMoC9jc4-BCEBvORaDJj23m=fT0+qf5pd5JWx3aenHQ@mail.gmail.com>
	<835zyhzmq2.fsf@jochen.org>
	<CAGO-sgOmv+-biFyQQO1ik_QPMS8v4iWDKu2rRZoJuVroNPr0GQ@mail.gmail.com>
Message-ID: <CAGO-sgOPXr2GEvYeBe2xrLNeNzeCNr=b-h0Jgiv80pS8aFBcgw@mail.gmail.com>

Hi, article updated.

Patch is not needed anymore, setting unique_attribute to ipauniqueid
fully solves this issue.

There was also some problems, with auto renaming some random users.
Some fields like displayName and uid can be updated by Kolab.
I was updated their type from Generated (read-only) to Normal, now it seems ok.

Hey is that possible to make them readonly but disable automatic
generation for them?

- kvaps
On Thu, Oct 11, 2018 at 11:37 AM kvaps <kvapss at gmail.com> wrote:
>
> Hi Jochen, thanks for your notes,
>
> >Here I think we should create "special users", not normal FreeIPA
> >accounts:
>
> Good point about placing special users to
> `cn=sysaccounts,cn=etc,dc=example,dc=org`, I will review that.
>
> >That way you could leave that out:
> >
> >> Now we can exclude users which ends with -svc from our addressbook:
>
> I still need to receive mail for some service users (not humans), it
> always better to have a way for exclude them from global address book
>
> >Can you elaborate why the pykolab patch is needed?
>
> Yep, I forgot to say about the patch. Without this patch pykolab
> wasn't create mailboxes.
> Sorry, I'm not saved the logs, but if I remember well, there was an
> error something like:
>
>     AttributeError("'bool' object has no attribute 'lower'",)
>
> I found the solution on git.kolab.org for the similar error for the
> attribute "type" and applied it for the "uid" attribute too.
> (can't find this link anymore)
>
> > Do we need to replicate the tree cn=kolab,cn=config to IPA replicas?
>
> This tree contains kolab domain namespaces and aliases configuration.
> In my opinion If this configuration static for you, you can just add
> it to all your servers which kolab can connect to.
> In case if you want to have opportunity to manage domains and add
> aliases any time, you probably should configure replication.
>
> - kvaps
> On Thu, Oct 4, 2018 at 6:44 PM Jochen Hein <jochen at jochen.org> wrote:
> >
> > kvaps <kvapss at gmail.com> writes:
> >
> > > OK, here is my article about Kolab and FreeIPA integration:
> > >
> > > https://medium.com/@kvapss/install-kolab-and-integrate-it-with-freeipa-c80c3b34b7b7
> >
> > Wonderful.  It mostly looks like what I'd do.  Some comments:
> >
> > ,----
> > | On FreeIPA server
> > |
> > | Create users:
> > |
> > |     kolab-svc
> > |     kolab-admin-svc
> > |     cyrus-svc
> > `----
> >
> > Here I think we should create "special users", not normal FreeIPA
> > accounts:
> >
> > dn: uid=<user>,cn=sysaccounts,cn=etc,dc=example,dc=org
> > changetype: add
> > objectclass: account
> > objectclass: simplesecurityobject
> > uid: nextcloud-fetch
> > userPassword: <password>
> > passwordExpirationTime: 20380119031407Z
> > nsIdleTimeout: 0
> >
> > And probably setting rights like that:
> >
> > dn: dc=example,dc=org
> > changetype: modify
> > add: aci
> > aci: (targetattr = "nsuniqueid || dn || uid || telephoneNumber || mobile || mail || sn || givenName || objectClass || displayName || gecos || uid || sn ||ou || dc || cn || homeDirectory") (version 3.0; acl "Kolab user can access some fields."; allow (read,search) userdn = "ldap:///uid=<user>,cn=sysaccounts,cn=etc,dc=example,dc=org";)
> >
> > That way you could leave that out:
> >
> > > Now we can exclude users which ends with -svc from our addressbook:
> >
> > Can you elaborate why the pykolab patch is needed?
> >
> > Do we need to replicate the tree cn=kolab,cn=config to IPA replicas?
> > That's something we should have in mind.
> >
> > I can add some comments for these:
> >
> > - Using ipa-getcert to get TLS certificates for IMAP, SMTP,
> >   Webmail/Webadmin.  I do run IMAP, SMTP and Kolab on logical hosts -
> >   that makes the configuration interesting :-)
> >
> > - Single-Sign-On for IMAP (I never got roundcube and Kerberos to
> >   cooperate).
> >
> > Thanks for sharing!
> >
> > Jochen
> >
> > --
> > This space is intentionally left blank.
> > _______________________________________________
> > devel mailing list
> > devel at lists.kolab.org
> > https://lists.kolab.org/mailman/listinfo/devel

From kvapss at gmail.com  Thu Nov  1 16:27:55 2018
From: kvapss at gmail.com (kvaps)
Date: Thu, 1 Nov 2018 16:27:55 +0100
Subject: [Kolab-devel] Kolab and FreeIPA article
In-Reply-To: <CAGO-sgOPXr2GEvYeBe2xrLNeNzeCNr=b-h0Jgiv80pS8aFBcgw@mail.gmail.com>
References: <CAGO-sgNbkrtPFLNvbp4hh7myJz4LRjOG7mi+dGR6Mjv5gVy45A@mail.gmail.com>
	<83r2hgyt1l.fsf@jochen.org> <20181001090802.GE5318@reaktio.net>
	<CAGO-sgMxg7wQKLK=VAyio3uG6Kc5Vce2=2_TwgevZsv+_SmsUw@mail.gmail.com>
	<20181003153829.GG5318@reaktio.net>
	<CAGO-sgNmMoC9jc4-BCEBvORaDJj23m=fT0+qf5pd5JWx3aenHQ@mail.gmail.com>
	<835zyhzmq2.fsf@jochen.org>
	<CAGO-sgOmv+-biFyQQO1ik_QPMS8v4iWDKu2rRZoJuVroNPr0GQ@mail.gmail.com>
	<CAGO-sgOPXr2GEvYeBe2xrLNeNzeCNr=b-h0Jgiv80pS8aFBcgw@mail.gmail.com>
Message-ID: <CAGO-sgOcEKN+VHeRiqMkCg1o7cfNU9j3nLAMng2AJbcbRzDgDw@mail.gmail.com>

I remember why I not changed nsuniquieid  to ipauniqueid.

Because after change kolab-webadmin can't edit entries, only create new ones.
Unfortunately kolab-webadmin can't operate with ipauniqueid even if I
add ipaObject class to all kolab objects :(

Now I've added workaround for make kolab-webadmin use different config
thank kolabd. In this config unique_attribute changed back to
nsuniqueid.

If someone knows better solution please write.

- kvaps
On Thu, Nov 1, 2018 at 3:40 PM kvaps <kvapss at gmail.com> wrote:
>
> Hi, article updated.
>
> Patch is not needed anymore, setting unique_attribute to ipauniqueid
> fully solves this issue.
>
> There was also some problems, with auto renaming some random users.
> Some fields like displayName and uid can be updated by Kolab.
> I was updated their type from Generated (read-only) to Normal, now it seems ok.
>
> Hey is that possible to make them readonly but disable automatic
> generation for them?
>
> - kvaps
> On Thu, Oct 11, 2018 at 11:37 AM kvaps <kvapss at gmail.com> wrote:
> >
> > Hi Jochen, thanks for your notes,
> >
> > >Here I think we should create "special users", not normal FreeIPA
> > >accounts:
> >
> > Good point about placing special users to
> > `cn=sysaccounts,cn=etc,dc=example,dc=org`, I will review that.
> >
> > >That way you could leave that out:
> > >
> > >> Now we can exclude users which ends with -svc from our addressbook:
> >
> > I still need to receive mail for some service users (not humans), it
> > always better to have a way for exclude them from global address book
> >
> > >Can you elaborate why the pykolab patch is needed?
> >
> > Yep, I forgot to say about the patch. Without this patch pykolab
> > wasn't create mailboxes.
> > Sorry, I'm not saved the logs, but if I remember well, there was an
> > error something like:
> >
> >     AttributeError("'bool' object has no attribute 'lower'",)
> >
> > I found the solution on git.kolab.org for the similar error for the
> > attribute "type" and applied it for the "uid" attribute too.
> > (can't find this link anymore)
> >
> > > Do we need to replicate the tree cn=kolab,cn=config to IPA replicas?
> >
> > This tree contains kolab domain namespaces and aliases configuration.
> > In my opinion If this configuration static for you, you can just add
> > it to all your servers which kolab can connect to.
> > In case if you want to have opportunity to manage domains and add
> > aliases any time, you probably should configure replication.
> >
> > - kvaps
> > On Thu, Oct 4, 2018 at 6:44 PM Jochen Hein <jochen at jochen.org> wrote:
> > >
> > > kvaps <kvapss at gmail.com> writes:
> > >
> > > > OK, here is my article about Kolab and FreeIPA integration:
> > > >
> > > > https://medium.com/@kvapss/install-kolab-and-integrate-it-with-freeipa-c80c3b34b7b7
> > >
> > > Wonderful.  It mostly looks like what I'd do.  Some comments:
> > >
> > > ,----
> > > | On FreeIPA server
> > > |
> > > | Create users:
> > > |
> > > |     kolab-svc
> > > |     kolab-admin-svc
> > > |     cyrus-svc
> > > `----
> > >
> > > Here I think we should create "special users", not normal FreeIPA
> > > accounts:
> > >
> > > dn: uid=<user>,cn=sysaccounts,cn=etc,dc=example,dc=org
> > > changetype: add
> > > objectclass: account
> > > objectclass: simplesecurityobject
> > > uid: nextcloud-fetch
> > > userPassword: <password>
> > > passwordExpirationTime: 20380119031407Z
> > > nsIdleTimeout: 0
> > >
> > > And probably setting rights like that:
> > >
> > > dn: dc=example,dc=org
> > > changetype: modify
> > > add: aci
> > > aci: (targetattr = "nsuniqueid || dn || uid || telephoneNumber || mobile || mail || sn || givenName || objectClass || displayName || gecos || uid || sn ||ou || dc || cn || homeDirectory") (version 3.0; acl "Kolab user can access some fields."; allow (read,search) userdn = "ldap:///uid=<user>,cn=sysaccounts,cn=etc,dc=example,dc=org";)
> > >
> > > That way you could leave that out:
> > >
> > > > Now we can exclude users which ends with -svc from our addressbook:
> > >
> > > Can you elaborate why the pykolab patch is needed?
> > >
> > > Do we need to replicate the tree cn=kolab,cn=config to IPA replicas?
> > > That's something we should have in mind.
> > >
> > > I can add some comments for these:
> > >
> > > - Using ipa-getcert to get TLS certificates for IMAP, SMTP,
> > >   Webmail/Webadmin.  I do run IMAP, SMTP and Kolab on logical hosts -
> > >   that makes the configuration interesting :-)
> > >
> > > - Single-Sign-On for IMAP (I never got roundcube and Kerberos to
> > >   cooperate).
> > >
> > > Thanks for sharing!
> > >
> > > Jochen
> > >
> > > --
> > > This space is intentionally left blank.
> > > _______________________________________________
> > > devel mailing list
> > > devel at lists.kolab.org
> > > https://lists.kolab.org/mailman/listinfo/devel