Strange nisMapEntry

List overview All Threads
Download

newer

older

nss_map_attribute gidNumber problem

OpenLDAP 2.4 replicated to 2.3?

David LEROUX

10 Feb 2010 10 Feb '10

10:01 a.m.

Hi all, 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/&

If I re import them from a fresh "normal" ldif generated from my nis automount maps, it does the same, it's alway the same affected entries... In phpldapadmin I can see it well, but not in my ldifs and its a bit annoying for me... Any idea ? Thanks,

-- David Leroux

Show replies by date

Benjamin Griese

10 Feb 10 Feb

10:53 a.m.

Hi David,

are you having that for your olcAccess Attrs too? (for ACLs)

# {0}config, config dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess:: ezB9dG8gKiBieSBkbi5leGFjdD1jbj1sb2NhbHJvb3QsY249Y29uZmlnIG1hbmFnZS A= olcRootDN: cn=config olcRootPW:

I got that too, maybe its set for security reasons to not use some holes in the ACLs. I don't know whats in your nismapentry as value, but maybe its for the same reason.

Just a thought from a bloody openldap newb :)

Bye.

On Wed, Feb 10, 2010 at 19:01, David LEROUX elhijo.mgl@gmail.com wrote:

...

Hi all, 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/&

If I re import them from a fresh "normal" ldif generated from my nis automount maps, it does the same, it's alway the same affected entries... In phpldapadmin I can see it well, but not in my ldifs and its a bit annoying for me... Any idea ? Thanks,

-- David Leroux

-- Ted Turner http://www.brainyquote.com/quotes/authors/t/ted_turner.html - "Sports is like a war without the killing."

Michael Ströder

2:05 p.m.

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.

David Leroux

2:52 p.m.

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=store12,nisMapName=auto.homeLINUX,ou=Automounts,dc=macguff,dc=fr objectClass: nisObject cn: store12 nisMapName: auto.homeLINUX nisMapEntry:: LXJ3LHRjcCxpbnRyLHJzaXplPTMyNzY4LHdzaXplPTMyNzY4LHRpbWVvPTUwLHJl dHJhbnM9MTAgeWFrMjA6L3VzcjIvdXNlcnMvJiA=

Merci.

David Leroux

3:04 p.m.

Le 10/02/2010 23:52, David Leroux a écrit :

...

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.

OK, I have some lines ending by space. As RFC2849 says: Values or distinguished names that end with SPACE SHOULD be base-64 encoded.

Thanks for your help

5435

Age (days ago)

5435

Last active (days ago)

openldap-technical@openldap.org

4 comments

4 participants

tags (0)

participants (4)

Benjamin Griese
David Leroux
David LEROUX
Michael Ströder