January 2016 - calendarserver-users

Re: [CalendarServer-users] Trouble upgrading from 5.3 to 7.0
by Jacques Distler 26 Jan '16

26 Jan '16

> On Jan 17, 2016, at 2:19 PM, ebach <ebach2(a)gmail.com> wrote: > > Does anything show up in the various log files calendarserver outputs too? Nope. access.log shows only the server starting up (and, when I hit ^C, shuttung down): Log opened - server start: [Sun Jan 17 14:16:53 2016]. Log closed - server stop: [Sun Jan 17 14:18:35 2016]. error.log shows nothing. A little more playing around (adding debug messages in appropriate-looking places), it seems that it gets as far as running UpgradeReleaseLockStep (in txdav.common.datastore.upgrade.sql.upgrade). But no further than that. > >> On Jan 17, 2016, at 12:49 AM, Jacques Distler <distler(a)golem.ph.utexas.edu> wrote: >> >> >>> On Jan 17, 2016, at 12:52 AM, Jacques Distler <distler(a)golem.ph.utexas.edu> wrote: >>> >>> bin/calendarserver_upgrade >>> >>> completed without errors. But >>> >>> bin/run -n >>> >>> stalls at >>> >>> 2016-01-17 00:26:57-0600 [-] [twistedcaldav.upgrade#warn] Migrating delegates to the store >>> >>> How can I diagnose what's causing the problem? After hitting ^C (the only way to get out), the old >>> >>> proxies.sqlite >>> >>> file is deleted (I can easily restore a copy from backup), but nothing seems to get me any further in the process of initializing the server. >> >> N.B.: The "delegates" and "delegate_groups" tables in postgreSQL both still have zero rows, so none of the delegate data actually got migrated. > >

2 10

Apple's Contacts client doesn't like nonstandard ports
by Kyle Silfer 25 Jan '16

25 Jan '16

Here’s another piece of info I found out by trial and error and have been meaning to report. Apple's Contacts client refuses to connect on nonstandard ports (for example, it wants 8843 for SSL). You have the option to change the port number after it fails its initial connect, but it doesn't really work. Once I matched the port number, it worked fine for newer clients (although not with the OS X 10.6 Address Book). Because calendarserver delivers both Contacts and Calendars on the same port (8443 by default), it becomes necessary to do something like redirect port 8843 to 8443 either on the host (using rinetd in Linux) or using NAT on an external device. ./k

2 2

El Capitan Calendar client doesn't work with calendarserver SSL connections
by Kyle Silfer 25 Jan '16

25 Jan '16

This might save someone from pulling out their hair. El Capitan’s Calendar app requires TLSv1.2 handshaking which calendarserver doesn’t provide. The app simply refuses to connect with a misleading error message about not being able to validate username or password. The workaround is to use a current Apache server to handle the TLSv1.2 portion of the connection and redirect to a plain http connection on the localhost. This killed 3 hours of my day today and I hope someone finds this hard-won knowledge valuable. ./k

3 3

Calendar Server Certificate Issue
by YouGenom . 24 Jan '16

24 Jan '16

Hi, I have set up calendarserver on my Raspberry Pi (Raspbian~Debian) for personal usage. I wanted to handle all communications on a secure connection therefore, I do want to use SSL/TLS only. After I set up everything, I could browse the root directory on non-tls channel. Then I wanted to create a self-signed certificate to secure the connection. I had a pair of .pem and .key files, which I referenced in the configuration. I made sure, they are accessible. Then, I tried to "browse" the root directory again, but webpage never loaded (it was is being loaded for a very long time). Then I checked the error.log file and here what I have found: 2016-01-24 23:01:50+0100 [-] [caldav-1] [-] Unhandled Error 2016-01-24 23:01:50+0100 [-] [caldav-1] Traceback (most recent call last): 2016-01-24 23:01:50+0100 [-] [caldav-1] File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line 73, in callWithContext 2016-01-24 23:01:50+0100 [-] [caldav-1] return context.call({ILogContext: newCtx}, func, *args, **kw) 2016-01-24 23:01:50+0100 [-] [caldav-1] File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 118, in callWithContext 2016-01-24 23:01:50+0100 [-] [caldav-1] return self.currentContext().callWithContext(ctx, func, *args, **kw) 2016-01-24 23:01:50+0100 [-] [caldav-1] File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 81, in callWithContext 2016-01-24 23:01:50+0100 [-] [caldav-1] return func(*args,**kw) 2016-01-24 23:01:50+0100 [-] [caldav-1] File "/usr/lib/python2.7/dist-packages/twisted/internet/selectreactor.py", line 149, in _doReadOrWrite 2016-01-24 23:01:50+0100 [-] [caldav-1] why = getattr(selectable, method)() 2016-01-24 23:01:50+0100 [-] [caldav-1] --- <exception caught here> --- 2016-01-24 23:01:50+0100 [-] [caldav-1] File "/usr/lib/python2.7/dist-packages/twext/internet/sendfdport.py", line 286, in doRead 2016-01-24 23:01:50+0100 [-] [caldav-1] transport = self.transportFactory(skt, description, protocol) 2016-01-24 23:01:50+0100 [-] [caldav-1] File "/usr/lib/python2.7/dist-packages/twext/web2/metafd.py", line 104, in createTransport *2016-01-24 23:01:50+0100 [-] [caldav-1] transport.startTLS(self.contextFactory)2016-01-24 23:01:50+0100 [-] [caldav-1] File "/usr/lib/python2.7/dist-packages/twisted/internet/_newtls.py", line 179, in startTLS2016-01-24 23:01:50+0100 [-] [caldav-1] startTLS(self, ctx, normal, FileDescriptor)2016-01-24 23:01:50+0100 [-] [caldav-1] File "/usr/lib/python2.7/dist-packages/twisted/internet/_newtls.py", line 139, in startTLS* 2016-01-24 23:01:50+0100 [-] [caldav-1] tlsFactory = TLSMemoryBIOFactory(contextFactory, client, None) 2016-01-24 23:01:50+0100 [-] [caldav-1] File "/usr/lib/python2.7/dist-packages/twisted/protocols/tls.py", line 769, in __init__ 2016-01-24 23:01:50+0100 [-] [caldav-1] contextFactory = _ContextFactoryToConnectionFactory(contextFactory) 2016-01-24 23:01:50+0100 [-] [caldav-1] File "/usr/lib/python2.7/dist-packages/twisted/protocols/tls.py", line 648, in __init__ 2016-01-24 23:01:50+0100 [-] [caldav-1] oldStyleContextFactory.getContext() 2016-01-24 23:01:50+0100 [-] [caldav-1] *exceptions.AttributeError: 'NoneType' object has no attribute 'getContext'* 2016-01-24 23:01:50+0100 [-] [caldav-1] I also tried letsencrypt's CA certificate, I had the same problem. What might be the problem? Is it a bug or the server doesn't like the certificate for some reason? Thanks a lot!

1 0

Trouble upgrading from 5.3 to 7.0
by Jacques Distler 21 Jan '16

21 Jan '16

bin/calendarserver_upgrade completed without errors. But bin/run -n stalls at 2016-01-17 00:26:57-0600 [-] [twistedcaldav.upgrade#warn] Migrating delegates to the store How can I diagnose what's causing the problem? After hitting ^C (the only way to get out), the old proxies.sqlite file is deleted (I can easily restore a copy from backup), but nothing seems to get me any further in the process of initializing the server.

2 3

strange calendar/dovecot interaction
by Jim Reid 07 Jan '16

07 Jan '16

This is a bit off-topic since it involves the official Apple calendar server. Sorry. I bought OSX Server, started the calendar service and have got calendar data imported to the server and visible to client apps. So far, so good. However, my logs are filling up with authentication failures and I don't have a clue what is wrong or why these are happening. It's not clear why the calendarserver is trying to speak to my dovecot IMAP server. Does anyone know what's wrong or how to troubleshoot and fix this? Every ~30 seconds, calendarserver reports: % tail /Library/Server/Calendar and Contacts/Logs/error.log 2016-01-07 22:42:38+0000 [-] [caldav-1] [IMAP4DownloadProtocol \ (TLSMemoryBIOProtocol),client] \ [txdav.caldav.datastore.scheduling.imip.inbound.IMAP4DownloadProtocol#error] \ IMAP login failed for com.apple.calendarserver 2016-01-07 22:43:08+0000 [-] [caldav-1] [IMAP4DownloadProtocol \ (TLSMemoryBIOProtocol),client] \ [txdav.caldav.datastore.scheduling.imip.inbound.IMAP4DownloadProtocol#error] \ IMAP login failed for com.apple.calendarserver 2016-01-07 22:43:39+0000 [-] [caldav-1] [IMAP4DownloadProtocol \ (TLSMemoryBIOProtocol),client] \ [txdav.caldav.datastore.scheduling.imip.inbound.IMAP4DownloadProtocol#error] \ IMAP login failed for com.apple.calendarserver And in the dovecot logs, I get this: Jan 7 22:43:14 hutch dovecot[63067]: imap-login: Disconnected \ (auth failed, 2 attempts in 4 secs): user=<com.apple.calendarserver>, \ method=PLAIN, rip=195.54.233.70, lip=195.54.233.70, TLS, session=<dSvTQ8YoXQDDNulG> Jan 7 22:43:40 hutch dovecot[63067]: auth-worker(65378): Error: \ pam(com.apple.calendarserver,195.54.233.70): pam_acct_mgmt() failed: permission denied Jan 7 22:43:44 --- last message repeated 1 time --- an 7 22:43:44 hutch dovecot[63067]: imap-login: Disconnected \ (auth failed, 2 attempts in 4 secs): user=<com.apple.calendarserver>, \ method=PLAIN, rip=195.54.233.70, lip=195.54.233.70, TLS, session=<VBuoRcYocgDDNulG> Jan 7 22:44:11 hutch dovecot[63067]: auth-worker(65378): Error: pam(com.apple.calendarserver,145.54.233.70): pam_acct_mgmt() failed: permission denied Jan 7 22:44:19 --- last message repeated 1 time --- The dovecot server is configured to use PLAIN authentication with PAM and CRAM-MD5, both over TLS. The calendar server is using the credentials for my MacOS login. Which is presumably accessible via PAM for dovecot's imap-login. Mail accounts use MD5 challenge response (again over TLS) for SMTP and IMAPS logins. However my mail MD5 "password" is not the same as my MacOS password even though the user name is unchanged. I suppose the two passwords could be aligned, but I'd prefer to keep these separated. I'd be grateful for any advice and suggestions, thanks.

2 1