[Fedora-directory-users] Command line created posix user shows posix disabled in console

[Rich Megginson]

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 at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20081126/f38b7212/attachment.bin>