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

[John A. Sullivan III]

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: [e-mail]
telephonenumber: [phone]

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

[Rich Megginson]

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: [e-mail]
> telephonenumber: [phone]
>
> 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]

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: [e-mail]
> > telephonenumber: [phone]
> >
> > 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

[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: [e-mail]
> > > telephonenumber: [phone]
> > >
> > > 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.