This is probably old news by now, but it may as well be put on the public record.

There were some issue that prevented IDS 11.50 produced on MacOS X 10.5.x (Leopard) from working properly if your machine was upgraded to MacOS X 10.6.2.  However, the majority of these can be worked around.

This item describes what I did after a quasi-forced upgrade to MacOS X 10.6.2.  That happened when my disk drive started to fail.  Fortunately, I have an Apple Time Capsule acting as my base station and had full backups of the machine made via Time Machine.  When Apple replaced the hard drive, I got 10.6.2 put on it, and then recovered everything else - including the IDS setup - from the Time Machine.  That was pretty easy; I was grateful that I'd spent the money providing the backup solution, and would unhesitatingly recommend that you consider it unless you want to find and use something better.

I upgraded IDS 11.50.FC4 from MacOS X 10.5.8 to 10.6.2, and after just a small bit of work, was able to get it to work fine (it seems).

• Before the upgrade, user informix had UID = 507 and GID = 100; group informix had GID 100.
• After the upgrade, group 100 was now labelled _lpoperator, and there was no group informix (but user informix still had GID = 100 as the primary GID).

To fix the resulting problems, I created group informix with /usr/sbin/dseditgroup:

dseditgroup -o create -p -u jl -i 507 informix

This creates group informix with GID 507; it prompts for a password (-p) and uses the user jl to obtain administrator privileges.  The name of the user needs to be the name of a (the) system administrator.  I chose GID 507 because it is the same as the UID.

I also had to edit the directory service entry for user informix to set the primary GID to 507, using /usr/bin/dscl:

Show the attributes for user informix:

$ dscl . -read /Users/informix
dsAttrTypeNative:_writers_hint: informix
dsAttrTypeNative:_writers_jpegphoto: informix
dsAttrTypeNative:_writers_LinkedIdentity: informix
dsAttrTypeNative:_writers_picture: informix
AppleMetaNodeLocation: /Local/Default
AuthenticationAuthority: ;ShadowHash; ;Kerberosv5;;informix@LKDC:SHA1.9CAFD79CD5663D3797FAE18249971499D1166450;LKDC:SHA1.9CAFD79CD5663D3797FAE18249971499D1166450;
GeneratedUID: 6E7D7BBD-D500-41CE-9382-217451F101EF
NFSHomeDirectory: /Users/informix
Password: ********
PrimaryGroupID: 507
RealName: informix
RecordName: informix
RecordType: dsRecTypeStandard:Users
UniqueID: 507
UserShell: /bin/bash
$


To change the Primary Group ID:

dscl -p -u jl . -change /Users/informix PrimaryGroupID 100 507

The -p means prompt for password; -u jl means use 'jl' as the admin user.  The . means the local host (datasource).

Then -change /Users/informix identifies the entry to change; PrimaryGroupID identified the field to change; 100 was the old value, and 507 the required new value.

The final operation needed was to set the group of any files under the Informix directories that were owned by group _lpoperator to group informix - as an administrator:

find /Applications/IBM ! -group informix -print0 | sudo -u root xargs -0 chgrp informix

On my machine, I also had to fix up a few other directories I'd set up with group informix privileges - it depends on how you handle your IDS instances on MacOS X.

With these changes made, I've been able to run basic IDS operations perfectly successfully.  It was a nuisance working out how to do it, but far from insuperable.

I'm mildly puzzled that the IDS installer on my machine chose 507 for the informix UID (because UIDs 502..506 were already in use by sundry other users; I'm not sure why 500 and 501 were not used, but it could be related to antique changes on my original Mac back in 2001 or thereabouts); it clearly uses the lowest available user ID.  But that leaves me wondering why the installer did not apply a similar algorithm to the groups.

This was all done with IDS 11.50.FC4 installed. Since then, IDS 11.50.FC6 has been released for Snow Leopard.

There is one issue that IDS (11.50.FC4, for example) used to have with Snow Leopard; it seems that there was a problem would show up only if you use the fully qualified domain name while bringing up the server. Apparently, getipnodebyname() is broken on Snow Leopard. The IDS team checked in a fix for this issue in 11.50.xC6 - we are not using this function on Mac OS X for now because we still have not been able to get a fix for getipnodebyname() issue from Apple and decided to go with the alternative as we were running out of time. This problem didn't affect me as I was using localhost to identify the machine. Over the course of a week, it gets multiple names depending on which network it is connected to, and the only stable name is localhost.