Hello,
I tried to set a password with the -T option. It failed so I tried -d 11 to see the dump in hexa. I discovered that a 0xa is append to the password. Is it a bug ? if so please confirm I will open a bugreport.
Version : squeeze/debian
On 21/09/11 17:48 +0200, David Dumortier wrote:
Hello,
I tried to set a password with the -T option. It failed so I tried -d 11 to see the dump in hexa. I discovered that a 0xa is append to the password. Is it a bug ? if so please confirm I will open a bugreport.
Version : squeeze/debian
Does the specified password file contain a newline character?
If so, try creating the password file without a trailing newline character, like this:
echo -n "password" > password.file
On 09/21/2011 05:48 PM, David Dumortier wrote:
Hello,
I tried to set a password with the -T option. It failed so I tried -d 11 to see the dump in hexa. I discovered that a 0xa is append to the password. Is it a bug ? if so please confirm I will open a bugreport.
slappasswd hashes the contents of the file, whatever it is. Usually, one should generate a file that contains a single line without a newline (0xa) at the end. For example:
$ echo "secret" > x && slappasswd -T x -h '{CLEARTEXT}' | od -c Warning: Password file x is publicly readable/writeable 0000000 s e c r e t \n \n 0000010 $ echo -n "secret" > x && slappasswd -T x -h '{CLEARTEXT}' | od -c Warning: Password file x is publicly readable/writeable 0000000 s e c r e t \n 0000007
notice the extra '\n' you get when the file is terminated by a newline.
p.
Hello,
Le mer. sept. 21 2011 � 06:11:00 +0200, Pierangelo Masarati dit :
On 09/21/2011 05:48 PM, David Dumortier wrote:
Hello,
I tried to set a password with the -T option. It failed so I tried -d 11 to see the dump in hexa. I discovered that a 0xa is append to the password. Is it a bug ? if so please confirm I will open a bugreport.
slappasswd hashes the contents of the file, whatever it is. Usually, one should generate a file that contains a single line without a newline (0xa) at the end. For example:
$ echo "secret" > x && slappasswd -T x -h '{CLEARTEXT}' | od -c Warning: Password file x is publicly readable/writeable 0000000 s e c r e t \n \n 0000010 $ echo -n "secret" > x && slappasswd -T x -h '{CLEARTEXT}' | od -c Warning: Password file x is publicly readable/writeable 0000000 s e c r e t \n 0000007
notice the extra '\n' you get when the file is terminated by a newline.
p.
Sorry, I forgot to say I verified there's no newline on the file (with vi but I didn't try with od, I'll do it this morning). And as I said I use ldappasswd as it is for users' password, perhaps have I to use slappassword?
Anyway thx for reply.
Le jeu. sept. 22 2011 � 03:53:45 +0200, David Dumortier dit :
Hello,
Le mer. sept. 21 2011 � 06:11:00 +0200, Pierangelo Masarati dit :
On 09/21/2011 05:48 PM, David Dumortier wrote:
Hello,
I tried to set a password with the -T option. It failed so I tried -d 11 to see the dump in hexa. I discovered that a 0xa is append to the password. Is it a bug ? if so please confirm I will open a bugreport.
slappasswd hashes the contents of the file, whatever it is. Usually, one should generate a file that contains a single line without a newline (0xa) at the end. For example:
$ echo "secret" > x && slappasswd -T x -h '{CLEARTEXT}' | od -c Warning: Password file x is publicly readable/writeable 0000000 s e c r e t \n \n 0000010 $ echo -n "secret" > x && slappasswd -T x -h '{CLEARTEXT}' | od -c Warning: Password file x is publicly readable/writeable 0000000 s e c r e t \n 0000007
notice the extra '\n' you get when the file is terminated by a newline.
In fact it was a \n that troubled ldappasswd, you were both right.
p.
Sorry, I forgot to say I verified there's no newline on the file (with vi but I didn't try with od, I'll do it this morning).
od is great :)
And as I said I use ldappasswd as it is for users' password, perhaps have I to use slappassword?
Anyway thx for reply.
David Dumortier
I'm sorry for the noise, I hoped vi was fine to see newline. I'll be more carefull next time :)
openldap-technical@openldap.org