strange behaviour of ptloader unable to canonify identifier

Tue Aug 29 14:28:49 CEST 2017

On 2017 m. rugpjūčio 29 d., antradienis 13:30:16 EEST Jan Kowalsky wrote:
> Hi Liutauras,
> 
> Am 29.08.2017 um 10:29 schrieb Liutauras Adomaitis:
> > Hi Jan,
> > 
> > On 2017 m. rugpjūčio 29 d., antradienis 11:10:42 EEST Jan Kowalsky wrote:
> >> Hi Liutauras,
> >> 
> >> thanks for answer.
> >> 
> >> Am 14.08.2017 um 15:29 schrieb Liutauras Adomaitis:
> >>> Hi,
> >>> 
> >>> On 2017 m. rugpjūčio 11 d., penktadienis 17:52:34 EEST Jan Kowalsky 
wrote:
> >>>> Lookup works:
> >>>> 
> >>>> [11/Aug/2017:16:08:49 +0200] conn=2131533 op=2 SRCH
> >>>> base="dc=example,dc=org" scope=2
> >>>> filter="(&(objectClass=inetorgperson)(|(uid=example.user1)(mail=example
> >>>> .u
> >>>> ser 1 at fas-dresden.de)(alias=example.user1 at fas-dresden.de)))"
> >>>> attrs="displayName mail alias nsRoleDN uid"
> >>>> 
> >>>> Lookup doesn't work
> >>>> 
> >>>> [11/Aug/2017:16:14:14 +0200] conn=2118186 op=8777 SRCH
> >>>> base="dc=example,dc=org" scope=2
> >>>> filter="(|(&(|(uid=cyrus-admin)(uid=cyrus-murder))(uid=example.user2))(
> >>>> &(
> >>>> 
> >>>> |(u
> >>>> 
> >>>> id=example.user2)(mail=example.user2 at fas-dresden.de)(mail=example.user2
> >>>> @
> >>>> ))(o bjectClass=kolabinetorgperson)))" attrs="1.1"
> >>>> 
> >>>> But other entries with attrs="1.1" don't lead to problems.
> >>>> 
> >>>> I I change the ldap Server in the second webmailer for using the other
> >>>> ldap-server: no problem. But we have some fancy aci for separating
> >>>> domains.
> >>>> 
> >>>> So one question: does the ldapserver cyrus makes its lookups from have
> >>>> to be the same where the mailclient (roundcube) looks up?
> >>> 
> >>> No, but if you use different servers, then you must know what you are
> >>> doing, as that can lead to all sorts of problems.
> >>> 
> >>>> I have no Idea for further debugging. Any hint is welcome.
> >>> 
> >>> The LDAP log which doesn't work looks like generated by Cyrus PTS
> >>> module.
> >>> What i would do is:
> >>> - take that filter from LDAP log record and use it for manual ldapsearch
> >>> command line utility to find out why it doesn't find what you expect.
> >>> Make
> >>> sure you use same bind dn and password as it is configured in
> >>> /etc/imapd.conf for pts module. I usually remove parts of the filter
> >>> until ldapsearch utility finds the LDAP object.
> >> 
> >> That's exactly, what I did. And the same filter works on the command
> >> line. But it comes even more strange:
> >> 
> >> Today I tried to create mailboxes, which where not created by kolab
> >> during user creation.
> > 
> > Why is that? Doesn't your kolabd do the work it supposed to? Did you see
> > any errors in /var/log/kolab/pykolab.log file? Maybe increase logging
> > level in / etc/sysconfig/kolabd (assuming you are running RedHat
> > derivative distribution)
> it supposed. But it doesn't always. Mostly yes. But sometime not.
> It's on Debian. But there I already increased the debug-level to 9. But
> there is nothing usable in the pykolab.log.
> 
> >> >From 20 mailboxes for 9 of them the acl where not assigned - while the
> >> 
> >> mailbox was created. The reason: while mailbox creation is just a task
> >> for cyrus for setting the acl the ptloader queries ldap. And exactly
> > 
> >> this failed for the 9 mailboxes:
> > Do you mean it fails for 9 out of 20 mailboxes?
> 
> yes, exactly. For (the first) 11 mailboxes it worked like expected for
> the remaining 9 not.
> 
> >> Aug 29 09:50:17 mail ptloader[15994]: No entries found
> >> Aug 29 09:50:17 mail imaps[15883]: ptload(): bad response from ptloader
> >> server: identifier not found
> >> Aug 29 09:50:17 mail imaps[15883]: ptload completely failed: unable to
> >> canonify identifier: example.user at example.org
> >> 
> >> looking at the ldap access log there is this corresponding line:
> >> 
> >> [29/Aug/2017:09:41:14 +0200] conn=3144893 op=7837 SRCH
> >> base="dc=example,dc=org" scope=2
> >> filter="(|(&(|(uid=cyrus-admin)(uid=cyrus-murder))(uid=example.user))(&(|
> >> (ui
> >> d=example.user)(mail=example.user at example.org)(mail=example.user@))(obje
> >> ctCl ass=kolabinetorgperson)))" attrs="1.1"
> >> [29/Aug/2017:09:41:14 +0200] conn=3144893 op=7837 RESULT err=0 tag=101
> >> nentries=0 etime=0
> >> 
> >> But with the same filter on ldapsearch:
> >> 
> >> /usr/lib/mozldap/ldapsearch -x -h ldap -p 389 -D "cn=Directory Manager"
> >> -w $(cat /etc/kolab/kolab.conf |grep ^bind_pw | cut -d' ' -f 3) -s sub
> >> -b "dc=example,dc=org"
> >> '(|(&(|(uid=cyrus-admin)(uid=cyrus-murder))(uid=example.user))(&(|(uid=ex
> >> amp
> >> le.user)(mail=example.user at example.org)(mail=example.user@))(objectClass
> >> =kol abinetorgperson)))'
> >> 
> >> it results the object.
> > 
> > How is your ptloader configured in /etc/imapd.conf, does it use
> > cn=Directory Manager to bind to LDAP? You should use ldap_bind_dn value
> > from your /etc/ imapd.conf for ldapsearch -D to do a correct test on
> > command line.
> no, you're right. It's the kolab-service user. But I tried the ldap
> query on command line with kolab-service user -> same result.
> 
> >> I tried a couple of times to set mailbox acls by command line:
> >> 
> >> kolab sam user/example.user at example.org user/example.user at example.org all
> > 
> > I see error in your command, you list mailbox name twice, while you should
> > assign acls to user:
> > kolab sam user/example.user at example.org example.user at example.org all
> 
> I always do it like this and it worked. I thought the imap aci subject
> ist the mail address? It's the same like
> 
> kolab sam user/example.user at example.org
> -> and then use "example.user at example.org" as aci Subject and "all" for
> the rights.
> 
> >> but always the same error in mail.log
> >> 
> >> After a while: Just doing the same command again with no changes in
> >> configuration the ptloader query worked and the acls are set.
> >> 
> >> Again: this problem only occurs with some of about 40 domains. And I'm
> >> completely clueless.
> > 
> > So you have a multidomain setup? Is that reflected in /etc/imapd.conf
> > ptloader ldap configuration? Does every domain have it's own suffix in
> > LDAP (like dc=example,dc=com and dc=example,dc=org)? Did you take care of
> > LDAP ACI's to allow necessary access for kolab-admin bind dn?
> 
> yes, it's multidomain. And the imapd.conf ist configured for multidomain:
> 
> auth_mech: pts
> ptscache_timeout: 600
> pts_module: ldap
> ldap_servers: ldap://ldap:389
> ldap_sasl: 0
> ldap_base: dc=primary-domain,dc=net
> ldap_bind_dn: uid=kolab-service,ou=Special Users,dc=primary-domain,dc=net
> ldap_password: SECRET
> ldap_filter:
> (|(&(|(uid=cyrus-admin)(uid=cyrus-murder))(uid=%U))(&(|(uid=%U)(mail=%U@%d)(
> mail=%U@%r))(objectclass=kolabinetorgperson))) ldap_user_attribute: mail
> ldap_group_base: dc=primary-domain,dc=net
> ldap_group_filter:
> (&(cn=%u)(objectclass=ldapsubentry)(objectclass=nsroledefinition))
> ldap_group_scope: one
> ldap_member_base: ou=People,dc=%2,dc=%1
> 
> 
> ldap_domain_base_dn: cn=kolab,cn=config
> ldap_domain_filter:
> (&(objectclass=domainrelatedobject)(associateddomain=%s))
> ldap_domain_name_attribute: associatedDomain
> ldap_domain_scope: sub
> ldap_domain_result_attribute: inetdomainbasedn
> 
> 
> The really strange thing ist that it works sometimes and sometimes not.
> 
> Thanks and Regards
> Jan
> _______________________________________________
> users mailing list
> users at lists.kolab.org
> https://lists.kolab.org/mailman/listinfo/users

I find it very strange that ldapsearch command works from command line, but 
exactly the same ldap search query doesn't for ptloader module.
I also find strange that kolabd (kolab-server) doesn't create all the 
mailboxes correctly.
That leads me to think that there might be some inconsistensies with LDAP data 
or maybe talking to different LDAP servers. Maybe replication is not working 
properly? BTW - do you replicate Kolab domain information also? I am asking 
because as I see domain information is storred under cn=kolab,cn=config 
suffix.
All the situation reminds me a similar issue I've seen with Univention 
Corporate Server and Kolab. Ptsmodule was failing there. UCS is debian 
derivative so that is worth checking, but I don't remember exactly what Cyrus 
version on UCS was with these issues. You can disable pts_module and run 
without it perfectly fine. Wonder if disabling pts_module will also solve 
mailbox creation issues.

Liutauras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/users/attachments/20170829/2d107c6e/attachment.sig>