John A. Sullivan III
2008-Nov-26 01:47 UTC
[Fedora-directory-users] Command line created posix user shows posix disabled in console
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
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
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society
Rich Megginson
2008-Nov-26 15:27 UTC
Re: [Fedora-directory-users] Command line created posix user shows posix disabled in console
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 >
John A. Sullivan III
2008-Nov-26 17:25 UTC
Re: [Fedora-directory-users] Command line created posix user shows posix disabled in console
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 -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan@opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society
Rich Megginson
2008-Nov-26 17:38 UTC
Re: [Fedora-directory-users] Command line created posix user shows posix disabled in console
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.