Hi Sven,
On Thu, Jun 13, 2019, at 12:27 AM, Sven Schwedas wrote:
> Is there another way to get ptloader to spit out debug information and
> pinpoint what's not set up correctly?
>
I remember this thing as being very noisy, let me see...
Okay, in your cyrus.conf SERVICES entry, if you add "-d1" to the ptloader line
like this,
ptloader cmd="ptloader -d1" listen="/path/to/some/socket"
then ptloader will syslog every user that it's asked about...
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:
https://www.cyrusimap.org/imap/installing.html#setting-up-syslog
If you turn on the "ptloader -d1" switch and set debug:1 and *don't* 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 :)
Here's an example of some ptloader log output from running our test suite, for
example:
> Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: executed
> Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: starting: ptloader.c
> 3.1.6-696-gf38559858
> Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: accepted connection
> Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: user admin
> Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: collecting all domains
> from ou=domains,o=cyrus
> Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Domain filter:
> (&(objectclass=domainrelatedobject)(associateddomain=*))
> Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: we have a domain internal.
> Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: ptsmodule_standard_root_dn
> called for domain internal.
> Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Root DN now dc=
> Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Root DN now dc=internal
> Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Root DN now dc=internal
> Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Root DN now dc=internal
> Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: Found admin in dc=internal
> Jun 14 12:08:03 debian 02032301C4/ptloader[29481]: we have found admin in
> dc=internal
And part of another run, showing it resolving a group membership (sorry these
lines got truncated during copy&paste, but you get the idea):
> Jun 14 13:11:47 debian 0311460101/ptloader[16345]: accepted connection
> Jun 14 13:11:47 debian 0311460101/ptloader[16345]: user group:group co
> Jun 14 13:11:47 debian 0311460101/ptloader[16345]: (groups) about to search
> ou=groups,o=cy
> Jun 14 13:11:47 debian 0311460101/imap[16344]: timeout_select exiting. r = 1;
> errno = 0
> Jun 14 13:11:47 debian 0311460101/imap[16344]: timeout_select: sock = 15, rp
> = 0x7ffca95e3
> Jun 14 13:11:47 debian 0311460101/imap[16344]: timeout_select exiting. r = 1;
> errno = 0
> Jun 14 13:11:47 debian 0311460101/imap[16344]: ptload read data back
> Jun 14 13:11:47 debian 0311460101/imap[16344]: ptload returning data
> Jun 14 13:11:47 debian 0311460101/imap[16344]: canonified group:group co ->
> group:group co
Not sure if this is helpful, but this is the directory structure our tests are
working with:
https://github.com/cyrusimap/cassandane/blob/master/data/directory.ldif
... ohhhhhhh,
> ldap_member_attribute: memberUid
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?
As far as I've been able to figure out while building tests, Cyrus seems to
expect each *user* 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??
Hopefully this is enough for you to get some useful logging out of the thing
anyway,
Cheers,
ellie
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
