#2 ldapcat map additions

open
Larry Lile
None
5
2005-04-19
2005-04-05
Aaron Hope
No

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.

Discussion

  • Aaron Hope
    Aaron Hope
    2005-04-05

     
    Attachments
  • Larry Lile
    Larry Lile
    2005-04-19

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

    Logged In: YES
    user_id=839907

    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
    ypcat/ypmatch.

    Sorting the output by key, it had honestly never occurred to me.
    Some days the most obvious stuff can escape me... I think
    having
    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
    user_id=839907

    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
    user_id=1253102

    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
    model.

    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
    way?

     
  • Larry Lile
    Larry Lile
    2005-04-20

    Logged In: YES
    user_id=839907

    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
    functionality.

    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.