[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Strange nisMapEntry
- To: Michael Ströder <michael@stroeder.com>
- Subject: Re: Strange nisMapEntry
- From: David Leroux <elhijo.mgl@gmail.com>
- Date: Wed, 10 Feb 2010 23:52:06 +0100
- Cc: elhijo@macguff.fr, openldap-technical@openldap.org
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=JbMgO4roQ7oj6cdmO9T8ZL1q805MeuBzCkWebTA8iek=; b=UmbycWxadrCuVYMoNRdw5x8ZBK9AgFQCkqifbOTwCDuIxXpk7sQPfrz25NU6DuCAEB PTTepLf9i+x64ZLIQfBMYW+hpNBcJCYWGsxkRYWtDQ8hlPez+1xYSFCfXEnU74cM/8Xn bEA35XpdzJ4eIeNW20YJ3E4P9eW2/O5UEVzi8=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=EjOhUQZakuiC7jOLta7krBxViCNiM2+JMz+mb6MtHrIVTQx2Azq7DwP103PXVb2MoR mj/7rHV6LUag5vzPFRa9j7dR8/koljydUCoDOz9z/2Vk4TyhNcvS6YZ0hqRmryf75aAu vmn3J8eeb7xmnzMk1oYhBrHSRkchYlsTUqPl0=
- In-reply-to: <4B732D8E.4010007@stroeder.com>
- References: <4B72F482.1070802@gmail.com> <4B732D8E.4010007@stroeder.com>
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1
Le 10/02/2010 23:05, Michael Ströder a écrit :
David LEROUX wrote:
I have in my ldifs, whatever the way I do them (slapcat ldapsearch
-LLL...) some strange entry, like if it was hashed.
Here is a sample:
nisMapEntry::
LXJ3LHRjcCxpbnRyLHJzaXplPTMyNzY4LHdzaXplPTMyNzY4LHRpbWVvPTUwLHJldHJhbnM9MTAgeWFrMjA6L3VzcjIvdXNlcnMvJiA=
Which should be:
nisMapEntry: -rw,tcp,intr,rsize=32768,wsize=32768,timeo=50,retrans=10
yak20:/usr2/users/&
In LDIF syntax :: behind the attribute type name indicates that the attribute
value is base64-encoded (see RFC 2849).
$ python -c "print
'LXJ3LHRjcCxpbnRyLHJzaXplPTMyNzY4LHdzaXplPTMyNzY4LHRpbWVvPTUwLHJldHJhbnM9MTAgeWFrMjA6L3VzcjIvdXNlcnMvJiA='.decode('base64')"
-rw,tcp,intr,rsize=32768,wsize=32768,timeo=50,retrans=10 yak20:/usr2/users/&
Ciao, Michael.
Thank you for that piece of code, but, any idea why it's bas64 encoded ?
As I've been told:
"If an attribute contains non-printing characters or begins with a
space, a colon or a less than (<) the value will be base64 encoded.
Your NIS entries might have an extra white space in the generated
LDIF."
But with those two entries, which looks to me "exactly" the same, once
sorted with a slapcat, store12's one is base64 encoded while store11's
one isn't.
dn: cn=store11,nisMapName=auto.homeLINUX,ou=Automounts,dc=macguff,dc=fr
objectClass: nisObject
cn: store11
nisMapEntry: -rw,tcp,intr,rsize=32768,wsize=32768,timeo=50,retrans=10
yak19:/usr3/users/&
nisMapName: auto.homeLINUX
dn: cn=store12,nisMapName=auto.homeLINUX,ou=Automounts,dc=macguff,dc=fr
objectClass: nisObject
cn: store12
nisMapEntry: -rw,tcp,intr,rsize=32768,wsize=32768,timeo=50,retrans=10
yak20:/usr2/users/&
nisMapName: auto.homeLINUX
---
dn: cn=store11,nisMapName=auto.homeLINUX,ou=Automounts,dc=macguff,dc=fr
objectClass: nisObject
cn: store11
nisMapEntry: -rw,tcp,intr,rsize=32768,wsize=32768,timeo=50,retrans=10
yak19:/usr3/users/&
nisMapName: auto.homeLINUX
dn: cn=store12,nisMapName=auto.homeLINUX,ou=Automounts,dc=macguff,dc=fr
objectClass: nisObject
cn: store12
nisMapName: auto.homeLINUX
nisMapEntry::
LXJ3LHRjcCxpbnRyLHJzaXplPTMyNzY4LHdzaXplPTMyNzY4LHRpbWVvPTUwLHJl
dHJhbnM9MTAgeWFrMjA6L3VzcjIvdXNlcnMvJiA=
Merci.