#2 ldapcat map additions

Aaron Hope

This is the second set of changes made to implement NIS
push synchronization at our site.
* Support for the shadow.byname map has been added and
the password hash in passwd.by* made contingent on the
presence of the new -m (merge) option.
* Results are sorted by key, if specified, else "cn".
* Autofs wildcard translation was broken; fixed.


  • Larry Lile

    Larry Lile - 2005-04-19
    • assigned_to: nobody --> lile
  • Larry Lile

    Larry Lile - 2005-04-19

    Logged In: YES

    I had completely forgotten about shadow in ldapcat when I
    implemented the shadow map in led. I would however prefer
    to have Configure manifest the shadow map under $shadow the
    same way led does and avoid adding -m. Would that be acceptable
    to you? It maintains command line option compatibility with

    Sorting the output by key, it had honestly never occurred to me.
    Some days the most obvious stuff can escape me... I think
    the server sort it would be more efficient, using

    Net::LDAP::Search( sorted => ($by ? $maps{$map}{$by} :
    'cn') )

    Would that be an acceptable alternative?

  • Larry Lile

    Larry Lile - 2005-04-19

    Logged In: YES

    I should have said,

    Net::LDAP::Search->(sorted => ($by ? $maps{$map}{$by} :
    'cn') )

    which is a part of Net::LDAP, not the server.

  • Aaron Hope

    Aaron Hope - 2005-04-20

    Logged In: YES

    I'm still pretty new to LDAP, and at the time I was only
    really interested in getting NIS updates working, so I
    hadn't even gotten to looking at led. Had I realized that
    led already had shadow support, I would looked to it as a

    It strikes me that the ldapcat functionality is a pure
    subset of that of led. Would it not make sense to avoid
    duplication by installing led as ldapcat as well (as a link
    naturally) and taking adding a --cat or --dump option to be
    implied when $0 =~ /ldapcat$/ ? Given, I haven't even read
    through the whole script yet, so I can't judge the
    implications. I just thought I'd mention it. The only
    issue I can think of off the bat is that "led shadow" leaves
    the {CRYPT} signature in place, which would not be
    appropriate for NIS export. But then, I'd argue that it
    should be stripped regardless. Was this intentional, by the

  • Larry Lile

    Larry Lile - 2005-04-20

    Logged In: YES

    ldapcat is a purpose built replacement for ypcat/ypmatch,
    led is a huge hammer for editing ldap with some extra
    utility built in. Where I work we had many scripts that
    used ypcat/ypmatch and we needed something to replace that

    I think ldapcat/ldapmatch could probably be completely
    integrated into led, but I think it would only complicate
    the code. I would have to consider it for a while. If you
    look at the code you will probably notice that while ldapcat
    borrows code from led, they were developed independently.

    At various points during our NIS->LDAP migration we have
    used led inside scripts to generate any number of NIS maps,
    make mass updates to maps, etc. I would be happy to provide
    them to you if they would be useful. In fact you could
    probably generalize them and they could be distributed with
    led and ldapcat.

    The {CRYPT} header on userPassword is the crypt scheme for
    that particular password. There are other schemes like
    {SSHA}, {MD5}, etc. that is why led makes them visible.

    BTW, I have integrated your fixes for all the above issues
    with some modifications.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks