Problem with nis.schema and resources

[gnatbite]

Hi folks,

we are running Zimbra 5.0.21 on our productive environment with ~ 150 users. Right now I am preparing the upgrade to Zimbra v6.0.6 but unfortunately I ran into some issues with the nis.schema. We are using the schema for posixGroups etc.

There are some objects in my LDAP tree which brake the constraints inherited from the objectClass: posixAccount

According to the original Zimbra nis.schema for this objectClass the following attributes are mandatory:

cn
uid
uidNumber
gidNumber
homeDirectory

The according line within the nis.schema is: MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )

Unfortunately there are some objects in our LDAP tree braking this rule.
These are all resources (just two which we are using for tests) and the original Zimbra accounts ham and spam

Please see the according LDAP output for the spam account below

# spam, people, zimbra.ourdomain.com
dn: uid=spam,ou=people,dc=zimbra,dc=ourdomain,dc=com
zimbraAttachmentsIndexingEnabled: FALSE
objectClass: organizationalPerson
objectClass: zimbraAccount
objectClass: amavisAccount
objectClass: posixAccount
...

uidNumber, gidNumber and homeDirectory are missing for the spam object, which is basically not possible since these attributes are mandatory for the objectClass posixAccount.

Same problem with our Zimbra resources. I deleted the resources within the Zimbra Admin interface and tried to create them again to see, if the new resource object will be created correctly but unfortunately I can't create any new resource object, due to the mentioned objectClass restrictions for posixAccount.
I get the following error message within the Admin webinterface:

Invalid request Message: invalid request: createAccount invalid schema change: [LDAP: error code 65 - object class 'posixAccount' requires attribute 'uidNumber'] Error code: service.INVALID_REQUEST Method: CreateCalendarResourceRequest Details:soap:Sender

I am wondering why Zimbra uses the objectClass posixAccount for resources and doesn't set the right attributes as defined in the original nis.schema?

Of course I could change the lines in nis.schema from:

MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
MAY ( userPassword $ loginShell $ gecos $ description ) )

to

MUST ( cn $ uid )
MAY ( userPassword $ loginShell $ gecos $ description $ uidNumber $ gidNumber $ homeDirectory) )

but this is definitely not recommended and I really don't want to mess something up.

Hopefully someone can help me out, seems to me like the chicken or the egg dilemma.

[gnatbite]

hmm, noone?