I needed to install a wiki to document CalDAV stuff, so I installed Confluence on macti.ca, and I'm closing this blog in one month. You can find the blog post at:
http://www.macti.ca/wiki/display/blog/
Pascal's corner
Wednesday, February 20, 2013
Wednesday, January 23, 2013
Storing past events on iCal Server
I'm migrating a customer from TeamAgenda to iCal Server, and past events (e.g., events that happens before the migration date) didn't book the rooms and resources associated with the events. After looking at what was the cause, I didn't find anything. So I fired up an email to the ical-server mailing list, and the answer was:
For better performance with data sets that grow over time, we limit what time-range data we cache in the data base, and as a result also limit the allowed range of time-range queries. That is controlled by the "FreeBusyIndexLowerLimitDays" caldavd.plist item which defaults to 365 days. A room/resource will attempt a time-range query in order to check for double-bookings, and that fails because of the lower limit and thus prevents the past bookings.
If you set "FreeBusyIndexLowerLimitDays" to 0, no limit applies. But I would advise against running with it that way, beyond just doing it for the import/migration.
Might be useful to know that if you are trying to do the same thing.
Wednesday, December 19, 2012
TeamAgenda: watch out for open LDAP connections
If you are running TeamAgenda STS (version 4.x, I don't know about v5) and your server is available on public network or DMZ, make sure your LDAP port is blocked for non authorized users. Why? Because all TeamAgenda STS installations use the same user and password for LDAP!
It's cool for people who needs to connect to it to migrate away from TA (I noticed that "security problem" when I was migrating someone from TA to Kerio Connect) so that you can get the data out, but it's not cool if you have a TA server running on the whole Internet.
It's cool for people who needs to connect to it to migrate away from TA (I noticed that "security problem" when I was migrating someone from TA to Kerio Connect) so that you can get the data out, but it's not cool if you have a TA server running on the whole Internet.
Tuesday, December 18, 2012
Sharing calendars with groups
I need to share calendar collections from iCal Server to groups, but sadly, with CalDAV it doesn't work. Why? Because even if the invitation is not sent by email, the user or contact that is going to get the invitation must have an email address. In Open Directory, groups don't have email addresses by default, so I said: "hey, let's add one with dscl!". So I added an existing email address to the group's OD record, but the problem is that it's the user who receive the invitation and must accept it in iCal.
So I asked the ical-server@lists.apple.com mailing list, and it seems the best ways to share calendars with groups instead of inviting every member of the group directly are:
So I asked the ical-server@lists.apple.com mailing list, and it seems the best ways to share calendars with groups instead of inviting every member of the group directly are:
Are you using icalserver standalone or as part of OS X server? With OS X server the wiki feature does offer a way to manage group calendars via the wiki group membership. Users who are members of a wiki can directly "subscribe" to the wiki calendar via a special sharing mode that involves simply clicking a link in the wiki calendar - that will "bind" the wiki calendar into the user's calendar home where it appears as if it were a calendar shared by an individual.
If you don't have the wiki available, then you can do something similar with resource calendars:
1) Create a resource for "Movie Editing".
2) Create an OD group "movie-editing".
3) Assign the group as a read-only or read-write proxy of the resource using the command line proxy management tool. (the command line tool is: calendarserver_manage_principals).
4) Users can "subscribe" to the shared calendar by clicking on a URL and authenticating in their browser using their calendar server credentials:
https://calendar.example.com/calendars/resources/movieediting/calendar/?action=shareThis is for servers that implements the caldav-sharing draft. To my knowledge, only iCal Server 10.7 and 10.8, or CalendarServer (the open source version of iCal Server) implements it. Other CalDAV implementations don't allow you to share individual calendar collections by iCal/Calendar.app (but some will allow you to share them by doing it by their Web interface, like Zimbra or Kerio Connect).
Wednesday, December 5, 2012
Alfresco JMX dump and authentification
I see a couple of Web pages that tell you how to do a JMX dump for Alfresco, but all of those pages, they forget to say that you have to be authentified with a admin account in Alfresco Explorer BEFORE you call the URL for the JMX dump! The JMX dump page is not asking for authentification.
So in short, you need to login at http://your.alfrescoserver.com/alfresco and after, you can do the dump at http://your.alfrescoserver.com/alfresco/faces/jsp/admin/jmx-dumper.jsp
So in short, you need to login at http://your.alfrescoserver.com/alfresco and after, you can do the dump at http://your.alfrescoserver.com/alfresco/faces/jsp/admin/jmx-dumper.jsp
Tuesday, November 27, 2012
Getting access to iCal Server database
On Mac OS X Server 10.7 and 10.8, the data for the iCal and Address Book services is located inside a PostgreSQL database. If you wish to see the data in the database, you can connect to the database by logging with SSH on the server, and call:
If you wish to delete the data because you are not using the services anymore, call:
sudo psql -U _postgres caldavAll iCalendar objects are in the calendar_object table, and all vCard objects are in the addressbook_object table.
If you wish to delete the data because you are not using the services anymore, call:
sudo dropdb -U caldav caldav
Tuesday, November 20, 2012
SSL issues with git and CentOS
Someone told me of a problem with Jenkins and Git who can't do a clone because of a SSL issue with the certificate from GitHub. I remember having the same issue a couple of months ago. The main problem is that the root certificates in CentOS (and I assume Amazon Linux and RedHat) are too old and don't have the root certificate of the provider that GitHub use.
How to fix this? See this blog post.
How to fix this? See this blog post.
Subscribe to:
Posts (Atom)