Tiger server, webcal sharing and the giant access_log

Hi all

I’ve encountered a mighty strange situation, and I wanted to share it with you. My client is an office of roughly 25 people, running OS X 10.4.4 Server and a mixture of Panther and Tiger workstations. We have a Sonicwall Pro 100 firewall. Our server machine is the mail server, and also serves the shared webcal/iCal calendars. Everyone publishes and subscribes to each other’s iCal calendars.

Recently, a handful of users reported intermittent problems refreshing one of the users’ calendars. Sometimes the calendar would appear with a red exclamation mark next to it; sometimes the “refresh” process would generate an endlessly spinning gear next to the calendar name. The issue was intermittent, and deleting and re-subscribing usually worked.

When I looked at the server, I found that the /var/log/httpd/access_log file was 10GB in size. It was filled with lines that looked like this:

x.x.x.x – – [date/time] “GET /AF_Schedule.ics HTTP/1.1” 401 489

There would be dozens of such errors within a very short time period (say, a minute), and then, a time later, dozens more. Just for that one user. In the error_log (which was much smaller), there would be a corresponding line for that timeframe:

[error] [client x.x.x.x] Authenticating using checkpw failed, trying legacy method

Now, the IP address x.x.x.x is that of our firewall. I understand that the firewall is also doing internal routing, so the fact that the request comes from the firewall’s IP doesn’t necessarily mean much. The mail/calendar server is outside the firewall.

I was curious that this user was the only one affected, and I noticed that he was alphabetically the first calendar on the server. I ran a test by creating a new calendar called “AA_Schedule”, and having one user subscribe to it, refreshing daily. Sure enough, the logs reported:

access_log: x.x.x.x – – “GET /AA_Schedule.ics HTTP/1.1” 401 489
error_log: [error] [client x.x.x.x] Authenticating using checkpw failed, trying legacy method

…and from that point on, *no* errors were reported in the log for the original “AF_Schedule” user.

I’m mystified. Anyone care to throw any ideas in?

Matt