Tag Archives: lion server

Hosting mail on 10.5 server with a 10.7/10.8 Open Directory

In one of my deployments, an emotional connection to an ageing Xserve G5 has meant that mail services continue to be hosted on 10.5 server. With almost all stock packages ripped out replaced with up to date or custom variants (big shoutout to Topicdesk!), everything works very smoothly, and has done for many years.

With the advent of Lion server however, directory and collaboration services were moved to a new Mac mini running 10.7, and as the OD was old and messy, it was entirely rebuilt from scratch, with manual entry of users and groups in Server.app. As 10.5 mail services are keyed off a users shortname and not the GUID, mailboxes carried across nicely when the Xserve was bound to the new 10.7 directory.

An error was encountered however, when users attempted an IMAP login:

Mar 28 12:23:45 mail imaps[27929]: badlogin from: jeddambp []. CRAM-MD5 user: johnsmith. mail is not enabled for this user

Mail SACLs were set correctly for users, but the error persisted.

10.7, having omitted the Mail tab from Workgroup Manager, maintains no way to set individual user quotas, or set a user’s mail server from within the GUI. In doing so, the MailAttribute attribute is not created in a 10.7 directory by default, unless mail services are hosted on the same machine.

Mail service on the 10.5 server was therefore restored by re-defining a MailAttribute based on the following plist for each user you want a mailbox for:

<?xml version="1.0" encoding="UTF-8"?>
<string>Apple Mail 1.0</string>

You will need to define kMailAccountLocation as your mail server’s hostname, and have the ability to set individual user quotas for users with the kUserDiskQuota key.

Adding this attribute is fairly easy in Directory Utility by navigating to the Directory Editor Tab, and clicking the plus button in the horizontal divider. You could also do this for a larger number of users by using dscl. There is good article here that has some examples of doing similar things.


Verifying your Open Directory databases using Nagios

Verifying individual .bdb files in an Open Directory instance is something I have traditionally performed as a troubleshooting step only once a major directory services failure is identified. Recently however, I have moved a weekly scripted verification to my Nagios workflow, and have been pleased with the results.

check_od_bdb.sh is a simple bash script which traverses over the bdb files in /var/db/openldap/openldap-data/, verifies them, and returns any failures it encounters. Due to the non-locking nature of the underlying db_verify tool that it uses, I wouldn’t be running this every 5 minutes in a production environment, but a weekly check should give you some peace of mind that your Open Directory instance is sailing along healthily.

check_od_bdb.sh on GitHub


Lion’s iCal server fails with error 500 response when user loses access to a wiki calendar

One of the fun errors that Lion’s iCal server likes to throw is the “500” response to CalDAVAccountRefreshQueueableOperation. This is telling you that Apache encountered an unexpected condition in fulfilling the request, so in these situations, you should find that you are getting a corresponding error in /var/log/caldavd/error.log.

The server responded with "500" to operation CalDAVAccountRefreshQueueableOperation.

Here is a condition that will see this error crop up, and workaround too:

If you change permissions on a Lion wiki, and remove access for a user who is subscribed to that wiki calendar in iCal, that user will then lose access to all calendaring, and will encounter a 500 response to every request.

The first step in troubleshooting calendaring related issues on OS X server is almost always to crank up the log verbosity. You can do this with the following command:

serveradmin settings calendar:DefaultLogLevel = "debug"

Upon another refresh, the more verbose log now reveals the cause of the error:

2012-03-23 11:31:49+1100 [-] [caldav-1] [QueryProtocol,client] [twistedcaldav.directory.wiki#debug] Wiki ACL result: user [CEC11D56-E3FA-4BC1-BC1B-5BD277EA237A], wiki [management], access [no-access]
2012-03-23 11:31:49+1100 [-] [caldav-1] [QueryProtocol,client] [twext.web2.server#info] Exception rendering:
2012-03-23 11:31:49+1100 [-] [caldav-1] [QueryProtocol,client] [twext.web2.server#error] [Failure instance: Traceback: &lt;type 'exceptions.ValueError'&gt;: list.remove(x): x not in list

Restoring permissive access for the affected user, refreshing, deleting the calendar from iCal, then revoking access again seems to be the quickest workaround. The relationships between users and calendars are defined in the calendar_bind table of the caldav postgres database, but removing matching entries from there does not seem to fix the issue.

Remember to return your calendar server to it’s standard level of verbosity with the following command when done:

serveradmin settings calendar:DefaultLogLevel = "warn"