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(a)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.