<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Hi Sven,</div><div><br></div><div>On Thu, Jun 13, 2019, at 12:27 AM, Sven Schwedas wrote:<br></div><blockquote id="qt" type="cite"><div>Is there another way to get ptloader to spit out debug information and<br></div><div>pinpoint what's not set up correctly?<br></div><div><br></div></blockquote><div><br></div><div>I remember this thing as being very noisy, let me see...<br></div><div><br></div><div>Okay, in your cyrus.conf SERVICES entry, if you add "-d1" to the ptloader line like this,<br></div><div><br></div><div> ptloader cmd="ptloader -d1" listen="/path/to/some/socket" <br></div><div><br></div><div>then ptloader will syslog every user that it's asked about...<br></div><div><br></div><div>You need "debug: 1" in imapd.conf, which will tell Cyrus to not swallow LOG_DEBUG level log lines, but ALSO: your syslog itself must be configured to log these lines (the default is often to not). We have some makeshift instructions here but ymmv: <a href="https://www.cyrusimap.org/imap/installing.html#setting-up-syslog">https://www.cyrusimap.org/imap/installing.html#setting-up-syslog</a><br></div><div><br></div><div>If you turn on the "ptloader -d1" switch and set debug:1 and <i>don't</i> start seeing entries in your logs like "ptloader[pid]: user [user]", then you need to fiddle with syslog to enable the LOG_DEBUG log level :)<br></div><div><br></div><div>Here's an example of some ptloader log output from running our test suite, for example:<br></div><div><br></div><blockquote type="cite"><div>Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: executed
<br></div><div>Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: starting: ptloader.c 3.1.6-696-gf38559858
<br></div><div>Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: accepted connection
<br></div><div>Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: user admin
<br></div><div>Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: collecting all domains from ou=domains,o=cyrus
<br></div><div>Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Domain filter: (&(objectclass=domainrelatedobject)(associateddomain=*))<br></div><div>Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: we have a domain internal.
<br></div><div>Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: ptsmodule_standard_root_dn called for domain internal.
<br></div><div>Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Root DN now dc=
<br></div><div>Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Root DN now dc=internal
<br></div><div>Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Root DN now dc=internal
<br></div><div>Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Root DN now dc=internal
<br></div><div>Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Found admin in dc=internal
<br></div><div>Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: we have found admin in dc=internal<br></div></blockquote><div><br></div><div>And part of another run, showing it resolving a group membership (sorry these lines got truncated during copy&paste, but you get the idea):<br></div><div><br></div><blockquote type="cite"><div>Jun 14 13:11:47 debian 0311460101/ptloader[16345]: accepted connection
<br></div><div>Jun 14 13:11:47 debian 0311460101/ptloader[16345]: user group:group co
<br></div><div>Jun 14 13:11:47 debian 0311460101/ptloader[16345]: (groups) about to search ou=groups,o=cy
<br></div><div>Jun 14 13:11:47 debian 0311460101/imap[16344]: timeout_select exiting. r = 1; errno = 0
<br></div><div>Jun 14 13:11:47 debian 0311460101/imap[16344]: timeout_select: sock = 15, rp = 0x7ffca95e3
<br></div><div>Jun 14 13:11:47 debian 0311460101/imap[16344]: timeout_select exiting. r = 1; errno = 0
<br></div><div>Jun 14 13:11:47 debian 0311460101/imap[16344]: ptload read data back
<br></div><div>Jun 14 13:11:47 debian 0311460101/imap[16344]: ptload returning data
<br></div><div>Jun 14 13:11:47 debian 0311460101/imap[16344]: canonified group:group co -> group:group co<br></div></blockquote><div><br></div><div>Not sure if this is helpful, but this is the directory structure our tests are working with:<br></div><div><br></div><div><a href="https://github.com/cyrusimap/cassandane/blob/master/data/directory.ldif">https://github.com/cyrusimap/cassandane/blob/master/data/directory.ldif</a><br></div><div><br></div><div>... ohhhhhhh,<br></div><div><br></div><blockquote type="cite"><div>ldap_member_attribute: memberUid <br></div></blockquote><div><br></div><div>This kinda sounds like your groups are what I think of as "normal": a group in LDAP is an entry that contains a multi-valued attribute listing all the group members. Is that a good description of your schema?<br></div><div><br></div><div>As far as I've been able to figure out while building tests, Cyrus seems to expect each <i>user</i> entry to contain a multi-valued attribute listing the groups it is a member of (e.g. see that directory.ldif linked above). This feels backwards to me, but maybe it's normal somewhere?? I don't understand the rationale for this choice, or whether Cyrus can support a "normal" setup... maybe using the "ldap_member_method: filter" configuration (vs the default setting of "attribute") somehow??<br></div><div><br></div><div>Hopefully this is enough for you to get some useful logging out of the thing anyway,<br></div><div><br></div><div>Cheers,<br></div><div><br></div><div>ellie</div></body></html>