March 2014 - calendarserver-users - lists.macosforge.org

FreeBSD port of CalendarServer 5.1 finished
by Axel Rau 23 Oct '14

23 Oct '14

I just finished a FreeBSD port of CalendarServer 5.1. It is currently waiting for commit to get included in the ports tree: http://www.freebsd.org/cgi/query-pr.cgi?pr=186201 I tested it on FreeBSD 9.2 and did a successful upgrade of the database schema from CalendarServer 4.3 to 5.1. Please test: https://github.com/mc3/fbsd_local_ports Any feedback welcome, Axel --- PGP-Key:29E99DD6 ☀ +49 151 2300 9283 ☀ computing @ chaos claudius

3 4

put attendee
by Atli Thorbjornsson 19 Mar '14

19 Mar '14

Hi all, I'm writing a client for the CalendarServer and hit a small snag. I'm testing the outcome via Calendar app on OS X. I can PUT vcalendar items with rrule to the server and they come out correctly. I can PUT a recurrence with a changed DTEND to the server and it comes out correctly. When I add an ATTENDEE to the recurrence however I have problems. If I do it via the calendar app I can see that it triggers this after the put: "implicit REQUEST - organizer:..." and the attendee gets a copy of the vcalendar. When I run my put request however this does not happen. The contents of the requests are identical but is there anything special I need to do to trigger this? I might be missing something in the headers? Here is my post-data to create a recurrence with changed DTEND and ATTENDEE PUT /calendars/__uids__/MjoxOnVzZXJz/calendar/e1f28de99f062e471cf04c582cc1e994.ics BEGIN:VCALENDAR VERSION:2.0 PRODID:Sling RestAPI BEGIN:VEVENT SUMMARY:Cleaning the 4th floor DTSTART:20140501T120000Z DTEND:20140501T160000Z DTSTAMP:20140319T131700Z UID:e1f28de99f062e471cf04c582cc1e994 SEQUENCE:3 CREATED:20140319T131700Z LOCATION:2 RRULE:FREQ=WEEKLY;COUNT=10;BYDAY=MO,TU,WE,TH,FR END:VEVENT BEGIN:VEVENT SUMMARY:Cleaning the 4th floor DTSTART:20140502T120000Z DTEND:20140502T150000Z DTSTAMP:20140319T131700Z UID:e1f28de99f062e471cf04c582cc1e994 RECURRENCE-ID:20140502T120000Z SEQUENCE:4 ATTENDEE:CN="One sling";CUTYPE=INDIVIDUAL;EMAIL="1(a)sling.is ";PARTSTAT=NEEDS-ACTION;RSVP=TRUE;SCHEDULE-STATUS="1.2":urn:uuid:MToxOnVzZXJz CREATED:20140319T131700Z ORGANIZER:CN="Two sling";EMAIL="2(a)sling.is":urn:uuid:MjoxOnVzZXJz END:VEVENT END:VCALENDAR Thanks, Atli.

1 1

iMIP not working on unbuntu 12.04 calendarserver 2.4.dfsg-7
by waxwhile＠hushmail.com 18 Mar '14

18 Mar '14

Pardon me if I am missing some information or something obvious. This is my first post. Has anyone been able to successfully run iMIP on calendarserver 2.4.dfsg-7 on ubuntu 12.04? I have been playing around for hours with various configurations without success. I have followed the instructions provided here. I have a created a separate IMAP account on the mail server and this mail server is on the same host as the calendarserver. I have set my caldavd.plist as follows: iMIP Enabled MailGatewayServer localhost MailGatewayPort 62310 Username calendar Password mycalendaruserpassword Sending Server mymailserver.fqdn Port 587 UseSSL Username calendar Password mySMTPuserpassword Address calendar(a)mydomain.fqdn Receiving Server mymailserver.fqdn Port 143 Type imap UseSSL Username calendar Password myIMAPuserpassword PollingSeconds 30 AddressPatterns mailto:.* The error logs in debug mode indicate nothing as does the mail.log. # grep imip /var/log/caldavd/error.log # The only messages I see are: 2014-03-18 04:56:26+0100 [-] [caldav-8443] [PooledMemCacheProtocol,client] [twistedcaldav.scheduling.scheduler#error] Unknown calendar user address: mailto:myemail@mydomain.fqdn 2014-03-18 04:56:26+0100 [-] [caldav-8443] [PooledMemCacheProtocol,client] [twistedcaldav.scheduling.scheduler#info] METHOD: REQUEST, Component: VEVENT 2014-03-18 04:56:26+0100 [-] [caldav-8443] [PooledMemCacheProtocol,client] [twistedcaldav.scheduling.scheduler.ScheduleResponseQueue#error] Error during PUT for mailto:myemail@mydomain.fqdn: None I was expecting some twistedcaldav.scheduling.imip messages in the log to indicate that the service/gateway had been enabled. If anyone has a working configuration, would you mind sharing your configuration?

3 3

SSL Ciphers
by m＠ainc.be 11 Mar '14

11 Mar '14

I've setup the latest version of CalendarServer on Wheezy and everything works fine with the exception of SSL functionality. The public, private and CA cert files are configured as described in the default configuration and they are accessible by CalendarServer. Nothing can connect to the SSL port, and neither the access or error logs show anything. Phython2.7 is listening on the SSL port. The only thing I could get was from Firefox giving the error: (Error code: ssl_error_no_cypher_overlap). I tried setting the SSLChiphers key to ALL in caldavd.plist but nothing happened.

3 3

Re: [CalendarServer-users] SSL Ciphers
by Andre LaBranche 11 Mar '14

11 Mar '14

On Mar 10, 2014, at 2:30 PM, m(a)ainc.be wrote: > Thank you for the reply. I also tried with different -cipher flags but no joy. Here is the output: > > CONNECTED(00000003) > 140316387088016:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:741: Hi, List cc re-added. I don't immediately know the problem here, but it could be an SSL / TLS version mismatch. Some suggestions: 1) Try adding -ssl3 or -tls1 after s_client in the openssl command. 2) Try the various options for SSLMethod in caldavd.plist. Possible values are: SSLv2_METHOD, SSLv3_METHOD, SSLv23_METHOD, TLSv1_METHOD. In general, TLS > SSL3 > SSL2 in terms of safety. Backwards compatibility is the typical constraint. 3) In firefox, hit about:config, void your warranty, search for security.ssl, and then verify that there is at least one point of intersection between the enabled ciphers and the output of "openssl ciphers ALL" (or whatever you've got configured in SSLCiphers - see "man ciphers" for more on the cipher groups and how they are defined). In looking at the about:config stuff for the current version of Firefox, I'm only seeing references to ssl3, so my guess is that it requires the server to allow ssl3 (which it totally should). 4) Enjoy a tasty beverage. Nobody really enjoys debugging SSL issues... :) -dre

2 1