Menu
▾
▴
#2 ldapcat map additions
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.
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?
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.
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?
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.