John A. Sullivan III wrote:

On Wed, 2008-11-26 at 08:27 -0700, Rich Megginson wrote:

...

John A. Sullivan III wrote:

...

I've created a bash script to add ds entries for new clients as we bring them on board. It automatically creates their user accounts which include the posixaccount object class (as well as account (to allow the host attribute) and posixgroup (to allow gidnumber for personal groups)).

They appear to be created fine. Users can login, change passwords, etc. However, when I view the user in the idm-console, the posix attributes are present but the enable checkbox is unchecked and the attributes are greyed out and uneditable.

If I click the enable check box, the fields are enabled but when I attempt to save the change I get an error: Cannot save to directory server: netscape.ldap.LDAPException: error result(1): Operations error

run the console like this fedora-idm-console -D 9 -f console.log the log should contain much more detailed information you should also look at the directory server access log to see exactly what operation it is performing

...

I would not doubt this is because it's trying to add a posixaccount value to objectclass when one already exists. In any event, if I enable posix and change an attribute, I get the same error. However, if I go to the advanced page instead, and change a posix attribute there, the change saves perfectly fine.

Any idea what is happening and what I've done wrong? In case more information is needed, here are some of the gory details.

There are attribute uniqueness constraints. uidnumber and gidnumber are globally unique. uid and cn are unique within an ou within an o - fairly granular. I did try disabling the global constraints but to no avail.

By the way, those users with NT attributes show up fine with the NT User enabled check box checked.

Here is a typical LDIF entry:

dn: uid=userx,ou=Users,ou=Internal,o=a0000-0002,dc=ssiservices,dc=biz changetype: add objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: posixaccount objectclass: account objectclass: posixgroup uid: userx cn: userx userpassword: ea4cb9eedc uidnumber: 2001 gidnumber: 2001 homedirectory: /data/users/userx loginshell: /bin/sh givenname: John A. sn: Sullivan III mail: userx@somecompany.biz telephonenumber: +1 (207) 999-9999

I can't imagine it is significant but, just in case, here is the LDIF creation from the script: The input syntax is: uid|givenname|sn|emailuser(no domain)|phone|location|W|"|" delimited attribute=value pairs

UIDNUMBERS[$counter]=${CIDU}
PWS=$(echo ${CIDU}${FIRST} | md5sum)
PWS=${PWS:0:10}
echo -e "${FIRST}  ${PWS}\n\n" >> ${CID}.temp
TEMPS="dn: uid=${FIRST},${USUFFIX}\n${ADDPERSON}uid: ${FIRST}\ncn: ${FIRST}\nuserpassword: ${PWS}\nuidnumber: ${CIDU}\ngidnumber: ${CIDU}\nhomedirectory: /data/users/${FIRST}\nloginshell: /bin/sh\n"
c=0
for var in ${REST}
do
	if [ -n "${var}" ]; then
		case ${c} in
		0)
			TEMPS="${TEMPS}givenname: ${var}\n";;
		1)
			TEMPS="${TEMPS}sn: ${var}\n";;
		2)
			TEMPS="${TEMPS}mail: ${var}${EDOMAIN}\n";;
		3)
			TEMPS="${TEMPS}telephonenumber: ${var}\n";;
		4)
			TEMPS="${TEMPS}physicaldeliveryofficename: ${var}\n";;
		5)
			TEMPS="${TEMPS}${ADDWIN}ntuserdomainid: ${FIRST}\nntusercreatenewaccount: true\nntuserdeleteaccount: true\n";;
		*)
			var=${var/=/: }
			TEMPS="${TEMPS}${var}\n";;
		esac
	fi
	((c = c + 1))
done
TEMPS="${TEMPS}\n"
echo -e ${TEMPS} >> ${LDIF}
((counter = counter + 1))
((CIDU = CIDU + 1))

Here are some of the variable definitions: BASE="dc=ssiservices,dc=biz" NEWO="o=${CID},${BASE}" SYSACCOUNTS="ou=SysAccounts,${NEWO}" USUFFIX="ou=Users,ou=Internal,${NEWO}" ADDS="changetype: add\n" TOPS="${ADDS}objectclass: top\n" ADDO="${TOPS}objectclass: organization\n" ADDOU="${TOPS}objectclass: organizationalUnit\n" ADDSYSPERSON="${TOPS}objectclass: person\nobjectclass: organizationalPerson\nobjectclass: inetOrgPerson\n" ADDPERSON="${ADDSYSPERSON}objectclass: posixaccount\nobjectclass: account\nobjectclass: posixgroup\n" ADDGROUP="${TOPS}objectclass: groupofuniquenames\nobjectclass: posixgroup\n" ADDWIN="objectclass: ntuser\n"

What is going on? Thanks - John

<snip> Thanks. This is what the console gives me when I click on the posix tab on the left side of the edit dialog:

ResourceEditor.valueChanged: o=com.netscape.management.client.ug.ResEditorPosixUser[,2,2,506x335,invalid,hidden,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=] ResourceEditor.valueChanged: o=com.netscape.management.client.ug.ResEditorPosixUser[,2,2,506x335,layout=java.awt.BorderLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=9,maximumSize=,minimumSize=,preferredSize=]

As suspected, I think the error is because it is trying to add posixAccount to the objectClass attribute when it already exists. I am assuming that is the action associated with checking the posix check box. Here is the log section:

ResourcePageObservable.save: mod.rep=LDAPAttribute {type='objectclass', values='top,person,organizationalPerson,inetOrgPerson,posixaccount,account,posixgroup,posixAccount'} ResourcePageObservable.save: RDN=uid=jasiii ResourcePageObservable.save: newRDN=uid=jasiii ResourcePageObservable.java:MODIFY LDAP ENTRY:netscape.ldap.LDAPException: error result (1); Operations error

I suppose the question is why the check box is unchecked to begin with. I wonder if the application is case sensitive (posixAccount versus posixaccount). I thought the attribute values were case insensitive.

Let me give that a try. That was it! Users created from the command line with posixaccount show as posix disabled while those created with posixAccount show as enabled. Is this a GUI bug or are they supposed to be case sensitive? Thanks - John

This is a GUI bug - they are not supposed to be case sensitive.