I've had a calendar server running happily for years with no problems. Recently - since restoring my virtual server - it has stopped working. In the error.log I get lots of 2013-03-03 22:30:05+0000 [-] [caldav-8008] [HTTPChannel,55,82.0.114.204] PROPFIND /calendars/__uids__/2e8f93bb-353d-50f1-a24a-3471395786cc/inbox/ HTTP/1.1 but I don't think that's anything unusual. However whenever I try to change something in a calendar - that should write to the server - the logs will say something like: [-] [caldav-8008] [HTTPChannel,68,82.0.114.204] PUT /calendars/__uids__/2e8f93bb-353d-50f1-a24a-3471395786cc/5AD40E77-ED61-4D6D-BDBD-735EAF0A3723/2791CEAB-F641-41DA-B78B-D5B02C70E77A.ics HTTP/1.1 [-] [caldav-8008] [HTTPChannel,69,82.0.114.204] PUT /calendars/__uids__/2e8f93bb-353d-50f1-a24a-3471395786cc/5AD40E77-ED61-4D6D-BDBD-735EAF0A3723/2791CEAB-F641-41DA-B78B-D5B02C70E77A.ics HTTP/1.1 [-] [caldav-8008] [HTTPChannel,69,82.0.114.204] Writing request stream to /var/spool/caldavd/calendars/__uids__/2e8f93bb-353d-50f1-a24a-3471395786cc/5AD40E77-ED61-4D6D-BDBD-735EAF0A3723/2791CEAB-F641-41DA-B78B-D5B02C70E77A.ics [-] [caldav-8008] [HTTPChannel,69,82.0.114.204] Writing to file /var/spool/caldavd/calendars/__uids__/2e8f93bb-353d-50f1-a24a-3471395786cc/5AD40E77-ED61-4D6D-BDBD-735EAF0A3723/2791CEAB-F641-41DA-B78B-D5B02C70E77A.ics [-] [caldav-8008] [-] 'Rollback: commit' [-] [caldav-8008] [-] 'Rollback: removed destination backup /var/spool/caldavd/calendars/__uids__/2e8f93bb-353d-50f1-a24a-3471395786cc/5AD40E77-ED61-4D6D-BDBD-735EAF0A3723/2791CEAB-F641-41DA-B78B-D5B02C70E77A.ics.rollback' Is that normal? Is it possible I have fallen foul of some user id number issue when restoring the server, that's affecting file permissions? The Calendar on Mac OS X clients are not reporting any issues; they seem to think that everything is fine and that the server has saved their events, but none of the events appear on the other clients. The iCal client on a machine running Leopard has obviously not saved any of its events locally, because its calendar is completely empty now. Thanks for any help. Daniele -- Daniele Procida Web Officer Cardiff University School of Medicine Tel.: +44 29 2074 2144
On Mar 3, 2013, at 2:43 PM, Daniele Procida <procida@cf.ac.uk> wrote:
I've had a calendar server running happily for years with no problems. Recently - since restoring my virtual server - it has stopped working.
What kind of virtual server? What version of Calendar Server?
Is that normal? Is it possible I have fallen foul of some user id number issue when restoring the server, that's affecting file permissions?
By themselves, these messages aren't harmful, but they do look a bit peculiar if you're getting a lot of them (rollbacks). You don't see tracebacks logged anywhere, or errors?
The Calendar on Mac OS X clients are not reporting any issues; they seem to think that everything is fine and that the server has saved their events, but none of the events appear on the other clients. The iCal client on a machine running Leopard has obviously not saved any of its events locally, because its calendar is completely empty now.
On the OS X clients, do you see any log messages from Calendar.app? -glyph
[Sorry, I didn't notice this had gone to the user rather than the list] On 5 Mar 2013, at 03:38, Glyph <glyph@twistedmatrix.com> wrote:
On Mar 3, 2013, at 2:43 PM, Daniele Procida <procida@cf.ac.uk> wrote:
I've had a calendar server running happily for years with no problems. Recently - since restoring my virtual server - it has stopped working.
What kind of virtual server? What version of Calendar Server?
It's an ancient version of Debian, 3.2.35, running an old version of calendar server (I can't work out how to get it to tell me which one).
Is that normal? Is it possible I have fallen foul of some user id number issue when restoring the server, that's affecting file permissions?
By themselves, these messages aren't harmful, but they do look a bit peculiar if you're getting a lot of them (rollbacks). You don't see tracebacks logged anywhere, or errors?
Nothing. The error log shows a lot of PROPFINDs, which I think is just the clients connecting successfully, but any write operation produces those rollbacks. Here are the logs where I launch a client, and edit an event: <http://dpaste.org/7343Q/>.
The Calendar on Mac OS X clients are not reporting any issues; they seem to think that everything is fine and that the server has saved their events, but none of the events appear on the other clients. The iCal client on a machine running Leopard has obviously not saved any of its events locally, because its calendar is completely empty now.
On the OS X clients, do you see any log messages from Calendar.app?
Actually yes: 05/03/2013 08:39:06.529 CalendarAgent[6251]: Invalid char _ for PropertyName in line 7 05/03/2013 08:39:06.540 CalendarAgent[6251]: Unexpected EOF, returning last token as fallback But that's all. Thanks, Daniele -- Daniele Procida Web Officer Cardiff University School of Medicine Tel.: +44 29 2074 2144
On Mar 5, 2013, at 1:35 AM, Daniele Procida <procida@cf.ac.uk> wrote:
[Sorry, I didn't notice this had gone to the user rather than the list]
On 5 Mar 2013, at 03:38, Glyph <glyph@twistedmatrix.com> wrote:
On Mar 3, 2013, at 2:43 PM, Daniele Procida <procida@cf.ac.uk> wrote:
I've had a calendar server running happily for years with no problems. Recently - since restoring my virtual server - it has stopped working.
What kind of virtual server? What version of Calendar Server?
It's an ancient version of Debian, 3.2.35, running an old version of calendar server (I can't work out how to get it to tell me which one).
OK. It looks like you're using a version of Calendar Server old enough that it uses the file system to store calendar events. That's _super_ old, and it's not a branch which will ever receive bug-fixes again. I'm afraid you'll really need to upgrade. The good news is that the new version is a lot easier to manage, in a variety of ways. One such way is that it's easier to make backups, because the data store is just a database (Postgres, or Oracle, with the possibility for you to implement your own SQL dialect if you like) plus some filesystem stuff for attachments. If you're upgrading a Calendar Server running on Linux from a filesystem version, be _very_ careful how you make your backups: you need to make sure to preserve all extended filesystem attributes. Many versions of tar, rsync, etc, that are shipped with Linux distributions won't do this by default, so be sure that you specify any options that are necessary to preserve that informaiton. -glyph
On 5 Mar 2013, at 21:40, Glyph <glyph@twistedmatrix.com> wrote:
On Mar 5, 2013, at 1:35 AM, Daniele Procida <procida@cf.ac.uk> wrote:
[Sorry, I didn't notice this had gone to the user rather than the list]
On 5 Mar 2013, at 03:38, Glyph <glyph@twistedmatrix.com> wrote:
On Mar 3, 2013, at 2:43 PM, Daniele Procida <procida@cf.ac.uk> wrote:
I've had a calendar server running happily for years with no problems. Recently - since restoring my virtual server - it has stopped working.
What kind of virtual server? What version of Calendar Server?
It's an ancient version of Debian, 3.2.35, running an old version of calendar server (I can't work out how to get it to tell me which one).
OK. It looks like you're using a version of Calendar Server old enough that it uses the file system to store calendar events. That's _super_ old, and it's not a branch which will ever receive bug-fixes again. I'm afraid you'll really need to upgrade. The good news is that the new version is a lot easier to manage, in a variety of ways.
One such way is that it's easier to make backups, because the data store is just a database (Postgres, or Oracle, with the possibility for you to implement your own SQL dialect if you like) plus some filesystem stuff for attachments. If you're upgrading a Calendar Server running on Linux from a filesystem version, be _very_ careful how you make your backups: you need to make sure to preserve all extended filesystem attributes. Many versions of tar, rsync, etc, that are shipped with Linux distributions won't do this by default, so be sure that you specify any options that are necessary to preserve that informaiton.
Well, I am pretty sure that I have fallen foul of just the kind of xattr issue you hint at. I've tried running contrib/tools/fix_calendar to fix them, but that doesn't seem to have helped (I also had to edit fix_calendar, to use "user." as a prefix rather than "WebDAV:" - see http://trac.calendarserver.org/ticket/337). My fix is the one I found on the web, which I'd forgotten about: https://lists.macosforge.org/pipermail/calendarserver-users/2010-August/0016... Thanks for the input, Daniele -- Daniele Procida Web Officer Cardiff University School of Medicine Tel.: +44 29 2074 2144
participants (2)
-
Daniele Procida
-
Glyph