Bug 715064 - ldclt adds a leading space to values when using -e attrreplace
ldclt adds a leading space to values when using -e attrreplace
Product: Fedora
Classification: Fedora
Component: 389-ds-base (Show other bugs)
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Rich Megginson
Fedora Extras Quality Assurance
: screened
Depends On:
Blocks: 690319 781544
  Show dependency treegraph
Reported: 2011-06-21 14:40 EDT by Sankar Ramalingam
Modified: 2012-02-28 03:40 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 781544 (view as bug list)
Last Closed: 2012-02-28 03:40:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Sankar Ramalingam 2011-06-21 14:40:43 EDT
Description of problem: LDCLT fails to complete the modify(attrreplace) operation when operational attributes are used.
For eg: When try to replace the "lastLoginTime" attribute of the users to activate them which are inactivated by Account Policy plugin, it throws an error 21(Invalid Syntax error).

How reproducible: Consistently

Steps to Reproduce:
1. Configure Global Account policy plugin using the following ldif file.

cat Account.ldif
dn: cn=Account Policy Plugin,cn=plugins,cn=config
changetype: modify
replace: nsslapd-pluginEnabled
nsslapd-pluginEnabled: on
replace: nsslapd-pluginarg0
nsslapd-pluginarg0: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config

dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config
changetype: modify
replace: alwaysrecordlogin
alwaysrecordlogin: yes
replace: stateattrname
stateattrname: lastLoginTime
replace: altstateattrname
altstateattrname: createTimestamp
replace: specattrname
specattrname: acctPolicySubentry
replace: limitattrname
limitattrname: accountInactivityLimit
replace: accountInactivityLimit
accountInactivityLimit: 60
2. Add 1000 users using ldclt operation.
        ldclt -v -h $HOST -p $PORT -D "cn=directory manager" -w $PASSWD -b "$SUFFIX" -e object=/tmp/Users.ldif,rdn=uid:test_01stress[A=INCRNNOLOOP(1000;1999;4)] -e add,commoncounter -n 20 -N 120 -T 100

3. Run ldclt operations to bind to each users to create the lastLoginTime attribute.
        ldclt -v -h $HOST -p $PORT -D "uid=test_01stressXXXX,$SUFFIX" -w $USERPW -b "$SUFFIX" -e esearch -f "uid=test_01stress*" -e "randombinddn,randombinddnlow=1000,randombinddnhigh=1999" -n 20 -N 20 -I 19

4. Wait for 60 secs(to reach AccountInactivityLimit) to make the account inactivated by the Account Policy plugin. 

5. Run ldclt operation to reset the "lastLoginTime" attribute, so that the accounts will be activated.

NewLoginTime=`date -u +"%Y%m%d%H%M%SZ"`

ldclt -v -h $HOST -p $PORT -D "cn=directory manager" -w $PASSWD -b "$SUFFIX" -f uid=test_01stressXXXX -e incr -e noloop -r 1000 -R 1999 -e attreplace='lastLoginTime:$NewLoginTime' -n 1 -N 20 -T 1000

LDCLT operations fail to activate the user accounts and logs "Invalid syntax error"- 21. 

Actual results: 
ldclt modify operation fails to replace the operational attributes.

Expected results: 
ldclt operation should successfully modify the operational attributes as like ldapmodify.

Additional info: 
ldclt operation to reset the "lastLoginTime" attribute succeeds when setting the "nsslapd-syntaxcheck" is set to off.
Comment 1 Nathan Kinder 2011-06-21 16:19:40 EDT
This bug actually has nothing to do with operational attributes.  It appears that ldclt is adding a leading space, which causes the value for lastLoginTime to violate the requirements of the Generalized Time syntax.

> dn: uid=test_01stress1000,ou=people,dc=accPolicy,dc=com
> lastLoginTime:: IDIwMTEwNjIxMTgzMDU2Wg==

>>> import base64
>>> base64.b64decode('IDIwMTEwNjIxMTgzMDU2Wg==')
' 20110621183056Z'

The value has a leading space (note the space after the ' and before the 2).  The proper thing to do is for ldclt to not add a leading space to the value.
Comment 4 Noriko Hosoi 2011-12-13 21:47:22 EST
Could you attach /tmp/Users.ldif to this bug?

> 2. Add 1000 users using ldclt operation.
>   ldclt -v -h $HOST -p $PORT -D "cn=directory manager" -w $PASSWD -b "$SUFFIX" -e
>   object=/tmp/Users.ldif,rdn=uid:test_01stress[A=INCRNNOLOOP(1000;1999;4)] -e 
>   add,commoncounter -n 20 -N 120 -T 100
Comment 5 Rich Megginson 2012-01-09 10:51:31 EST
Upstream ticket:
Comment 6 Noriko Hosoi 2012-01-25 19:37:34 EST
Cannot reproduce the problem.  I could not see ldclt to add leading space(s).

Here's the steps I tried:
1. Check nsslapd-syntaxcheck is enabled.
# egrep nsslapd-syntaxcheck /etc/dirsrv/slapd-jiji/dse.ldif
nsslapd-syntaxcheck: on

2. Set NewLoginTime as suggested.
NewLoginTime=`date -u +"%Y%m%d%H%M%SZ"
$ echo $NewLoginTime

3. Run ldclt with '-v'; make sure attribute's head does not start with space(s).
$ ldclt -v -h localhost -p 389 -D 'cn=directory manager' -w <pw> -b "dc=example,dc=com" -f uid=testX -e incr -e noloop -r 0 -R 9 -e attreplace="lastLoginTime:$NewLoginTime" -n 1 -T 10
Attribute's head   = "20120125231440Z"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Note: no space in front of the value
Attribute's tail   = ""

4. Search entries with lastLoginTime in the attrlist.
$ ldapsearch -LLLx -h localhost -p 389 -D 'cn=directory manager' -w <pw> -b "dc=example,dc=com" lastLoginTime
dn: dc=example,dc=com
dn: uid=test0,dc=example,dc=com
lastLoginTime: 20120125231440Z
dn: uid=test1,dc=example,dc=com
lastLoginTime: 20120125231440Z

5. Run dbscan against the primary db file and see the lastLoginTime values are not base64 encoded.
# dbscan -f id2entry.db4 | egrep lastLoginTime
	lastLoginTime: 20120125231440Z
	lastLoginTime: 20120125231440Z

Please provide steps/test data to reproduce the problem.  The due of this bug fix is Feb. 3rd.  If no steps are provided, we are closing this bug with WORKSFORME...
Comment 7 Sankar Ramalingam 2012-02-28 03:40:27 EST
Problem doesn't seems to be reproducible. In my ldclt command, I used single quotes to attreplace='lastLoginTime:$NewLoginTime', instead of double quotes.

When I use the double quotes for the same, the problem disappears.

Hence closing the bug as WORKSFORME as Noriko stated.

Note You need to log in before you can comment on or make changes to this bug.