Re: backupd IOERROR reading backup files larger than 2GB

2019-06-13 Thread ellie timoney 
Hi Carlos,

This is quite weird, I'm not sure why a 64bit platform would have any trouble 
around the 2GB mark??

What does the Cyrus ./configure report for your system's integer sizes? e.g. 
mine shows:

> checking size of int... 4 
> checking size of long... 8 
> checking size of size_t... 8 
> checking size of off_t... 8 
> checking size of time_t... 8 
> checking size of long long int... 8 
> checking size of unsigned long long int... 8 
> checking whether byte ordering is bigendian... no

What's your level of comfort with C debugging? It'd be very helpful to see a 
core file+binary from the time that lseek error occurs?

Cheers,

ellie

On Fri, Jun 7, 2019, at 1:58 AM, Carlos Larrañaga wrote:
> Hi Ellie,
> 
>  Thanks for answering. We use latest 64bit Oracle Linux (not CentOs like I 
> said before, sorry) and zlib is also 64bit version:
>> # uname -a
>> Linux xxx 3.10.0-957.12.2.el7.x86_64 #1 SMP Tue May 14 17:35:45 PDT 2019 
>> x86_64 x86_64 x86_64 GNU/Linux
>> 
>> # yum list installed zlib
>> Loaded plugins: langpacks, ulninfo
>> Installed Packages
>> zlib.x86_64 1.2.7-18.el7 @ol7_latest
>> 
>>  # lsof -p 17005 |grep lib |grep -i z
>>  backupd 17005 cyrus mem REG 253,0 90248 134400930 /usr/lib64/libz.so.1.2.7
>> 
>>  # file /usr/lib64/libz.so.1.2.7
>>  /usr/lib64/libz.so.1.2.7: ELF 64-bit LSB shared object, x86-64, version 1 
>> (SYSV), dynamically linked, 
>> BuildID[sha1]=b9d5f73428bd6ad68c96986b57bea3b7cedb9745, stripped
>> 
>>  # rpm -qf /usr/lib64/libz.so.1.2.7
>>  zlib-1.2.7-18.el7.x86_64
> I have summarized here some information about the backupd error reading the 
> file descriptor 15, which is a backup larger than 2GB. The error is logged 
> 1755 times. Instead, there is no error for fd 12, which is a backup of less 
> than 2 GB:
>> *#-- CLIENT SIDE*
>> *---*
>> 
>> 
>> # time sync_client -v -o -n backup -A
>>  Thu Jun 6 17:08:02 CEST 2019
>>  USER aaa
>>  QUOTA user.aaa
>>  USER ccc
>>  Error from do_user(ccc): bailing out!
>> 
>>  real 30m16.223s
>>  user 0m0.006s
>>  sys 0m0.006s
>> **
>> 
>> *#-- BACKUP SERVER SIDE 
*
>> # LOGFILE
>> 
>> # tail -f /var/log/imapd.log
>>  Jun 6 17:09:11 bcrux cyrus/backupd[2584]: IOERROR: gzuc_read: lseek 15: No 
>> such file or directory
>>  Jun 6 17:09:11 bcrux cyrus/backupd[2584]: IOERROR: gzuc_read: lseek 15: No 
>> such file or directory
>>  Jun 6 17:09:11 bcrux cyrus/backupd[2584]: IOERROR: gzuc_read: lseek 15: No 
>> such file or directory
>>  Jun 6 17:09:11 bcrux cyrus/backupd[2584]: IOERROR: gzuc_read: lseek 15: No 
>> such file or directory
>> 
>> 
>> *# lsof of the backupd PROCESS
*# lsof -P -p 2584 
>> 
>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
>> backupd 2584 cyrus cwd DIR 253,0 4096 128 /
>> backupd 2584 cyrus rtd DIR 253,0 4096 128 /
>> backupd 2584 cyrus txt REG 253,0 768632 939542214 
>> /usr/local/cyrus/libexec/backupd
>> backupd 2584 cyrus mem REG 253,0 37208 135746334 /usr/lib64/libnss_sss.so.2
>> backupd 2584 cyrus mem REG 253,0 31416 134406707 
>> /usr/lib64/libnss_dns-2.17.so
>> backupd 2584 cyrus mem REG 253,0 61632 134406709 
>> /usr/lib64/libnss_files-2.17.so
>> backupd 2584 cyrus mem REG 253,0 43336 68814977 
>> /usr/lib64/sasl2/webmail.so.0.0.0
>> backupd 2584 cyrus mem REG 253,0 57960 68856627 
>> /usr/lib64/sasl2/libdigestmd5.so.3.0.0
>> backupd 2584 cyrus mem REG 253,0 24232 68797220 
>> /usr/lib64/sasl2/libcrammd5.so.3.0.0
>> backupd 2584 cyrus mem REG 253,0 20088 68797044 
>> /usr/lib64/sasl2/libplain.so.3.0.0
>> backupd 2584 cyrus mem REG 253,0 20056 68797036 
>> /usr/lib64/sasl2/liblogin.so.3.0.0
>> backupd 2584 cyrus mem REG 253,0 1845816 135873512 /usr/lib64/libdb-5.3.so
>> backupd 2584 cyrus mem REG 253,0 28272 67113426 
>> /usr/lib64/sasl2/libsasldb.so.3.0.0
>> backupd 2584 cyrus mem REG 253,0 20064 67113423 
>> /usr/lib64/sasl2/libanonymous.so.3.0.0
>> backupd 2584 cyrus mem REG 253,0 11448 135872733 /usr/lib64/libfreebl3.so
>> backupd 2584 cyrus mem REG 253,0 155784 134400716 /usr/lib64/libselinux.so.1
>> backupd 2584 cyrus mem REG 253,0 15464 134401447 
>> /usr/lib64/libkeyutils.so.1.5
>> backupd 2584 cyrus mem REG 253,0 40672 134399432 /usr/lib64/libcrypt-2.17.so
>> backupd 2584 cyrus mem REG 253,0 105824 134781819 
>> /usr/lib64/libresolv-2.17.so
>> backupd 2584 cyrus mem REG 253,0 53944 134406785 
>> /usr/lib64/libjansson.so.4.10.0
>> backupd 2584 cyrus mem REG 253,0 88776 135352942 
>> /usr/lib64/libgcc_s-4.8.5-20150702.so.1
>> backupd 2584 cyrus mem REG 253,0 1137032 134400337 /usr/lib64/libm-2.17.so
>> backupd 2584 cyrus mem REG 253,0 991616 135352396 
>> /usr/lib64/libstdc++.so.6.0.19
>> backupd 2584 cyrus mem REG 253,0 19296 134399434 /usr/lib64/libdl-2.17.so
>> backupd 2584 cyrus mem REG 253,0 142008 134722750 
>> /usr/lib64/libpthread-2.17.so
>> backupd 2584 cyrus mem REG 253,0 2151704 134365659 /usr/lib64/libc-2.17.so
>> backupd 2584 cyrus mem REG 253,0 753232 134401161 
>> /usr/lib64/libsqlite3.so.0.8.6
>> b

Re: LDAP auth and ptloader

2019-06-13 Thread ellie timoney 
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

... ohhh,

> 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