Re: (ITS#4994) Clarify -y option in man pages
by rra＠stanford.edu
Pierangelo Masarati <ando(a)sys-net.it> writes:
> rra(a)stanford.edu wrote:
>> A Debian user was confused by the -y option and its inclusion of
>> whitespace in the password. The current man page text does explain
>> this, but it doesn't make a point of it, and I think a bit more
>> explanation would be useful. Here's a patch for the ldapcompare.1 man
>> page; if you think this is a good idea, similar changes could be made
>> to all the other command-line utilities that take the -y option.
> I have committed a different clarification that provides a hint to a
> portable manner to generate appropriate password files. Please check
> and improve; afterwards I'll apply it to other command line tools man
> pages.
Perfect, and a substantial improvement over my patch. Thank you!
--
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
15 years, 2 months
Re: (ITS#4997) lmpasswd support using gcrypt
by rra＠stanford.edu
Kurt Zeilenga <kurt(a)OpenLDAP.org> writes:
> Without involvement from the authors of this patch, it's better to
> simply rewrite the feature from scratch.
No problem. The patch is conceptually trivial. I'll plan on
reimplementing it from scratch unless I can contact the original author
(or possibly anyway if it's faster).
--
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>
15 years, 2 months
Re: (ITS#4971)
by ando＠sys-net.it
jemeterisan(a)mail.ru wrote:
> O.k, thanks. But, I would like to know, what does the termin "HEAD
> code" mean?
the HEAD branch out of the CVS.
> And where can I get it?
<http://www.openldap.org/software/repo.html#AnonCVS>
>> Any blob-like format would be fine (although I haven't tested it
>> with PostgreSQL yet).
>
> So, do You mean BLOB-like format as oid (in PostgreSQL), or just
> something like varbit type?
I'm not that familiar with variable size binary data in PostgreSQL, but
I guess something like "bytea" should work. With MySQL, "LONGBLOB" worked.
> I tried to put BLOBs in PostgreSQL by
> ldapadd - it's possible.
Usually, you need to encode those objects in a way ldapadd can munch.
For example, base64 encode them, like
binaryAttr:: thisisabase64encodedvalue=
or ask it to swallow the file as is, using
binaryAttr:< file:///path/to/binary.dat
> But I had some problems when I tried to read
> from oid. I just had got the value of oid, but not stored data.
Not sure I understand what you mean. But here we're getting off-topic
with this ITS; please continue discussion, if needed, on the
openldap-software mailing list.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 2 months
Re: (ITS#4971)
by h.b.furuseth＠usit.uio.no
jemeterisan(a)mail.ru writes:
> what does the termin "HEAD code" mean?
> And where can I get it? Sorry for my educationless...
The source code is stored in a CVS repository, as described here:
http://www.openldap.org/software/repo.html
The development branch is named HEAD. As the above URL says,
you can check it out with
% setenv CVSROOT :pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP
% cvs login
Password: (enter OpenLDAP)
% cvs -z3 checkout -P ldap
% cvs logout
--
Regards,
Hallvard
15 years, 2 months
Re: (ITS#4989) Quirk in Dynlist overlay configuration
by ando＠sys-net.it
Christian Marg wrote:
> Hmm - I object.
>
> posixGroup and groupOfURLs are both "structural" objectclasses so an
> entry is either a "groupofURL" or a "posixGroup", never both.
OK, my example was stupid. But you got the idea below.
> And in
> this case the memberURL can have different meanings according to the
> Objectclass it is used in.
>
> Otherwise I'd have to create an Attribute for every expansion I want to
> use - that can't be right!
>
> You are right for expansions in auxillary OCs, of course! They shouldn't
> be using the same attribute...
>
>> Please test and report.
>
> Will do, sometime soon.
Thanks, p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 2 months
Re: (ITS#4989) Quirk in Dynlist overlay configuration
by marg＠rz.tu-clausthal.de
Hello...
ando(a)sys-net.it wrote:
> marg(a)rz.tu-clausthal.de wrote:
>
>> I found a behaviour issue with the dynlist overlay configuration:
>>
>> I tried the following configuration:
>>
>> overlay dynlist
>> dynlist-attrset posixGroup memberURL
>> dynlist-attrset groupOfURLs memberURL owner
>
> The reason of that check is that the same attribute "memberURL" could
> otherwise be used by both group classes to expand.
[...]
> However, I believe something like
>
> dynlist-attrset posixGroup memberURL
> dynlist-attrset groupOfURLs memberURL
>
> should still be forbiden, otherwise the same "memberURL" would expand
> twice. This, strictly speaking, is not an issue, as duplicates would
> simply be discarded, but it would cause unnecessary overhead. Right
> now, I have decided to turn this check into a config-time warning.
Hmm - I object.
posixGroup and groupOfURLs are both "structural" objectclasses so an
entry is either a "groupofURL" or a "posixGroup", never both. And in
this case the memberURL can have different meanings according to the
Objectclass it is used in.
Otherwise I'd have to create an Attribute for every expansion I want to
use - that can't be right!
You are right for expansions in auxillary OCs, of course! They shouldn't
be using the same attribute...
> Please test and report.
Will do, sometime soon.
bye
Christian
--
Christian Marg mail: mailto:marg@rz.tu-clausthal.de
Rechenzentrum TU Clausthal web : http://www.rz.tu-clausthal.de
D-38678 Clausthal-Zellerfeld fon : 05323/72-2043
Germany ICQ : <on request>
15 years, 2 months
(ITS#4971)
by jemeterisan＠mail.ru
-----Original Message-----
From: Pierangelo Masarati <ando(a)sys-net.it>
To: jemeterisan(a)mail.ru
Date: Fri, 18 May 2007 19:10:03 +0200
Subject: Re: (ITS#4971) patch for OpenLDAP 2-3-32
> I assume you refer to a patch that was submitted along with ITS#4868;
> that patch is absolutely incorrect and in fact it has been rejected. A
> consistent fix has been applied to hEAD code. It has never been
> backported to OpenLDAP 2.3 because nobody fed back about it. If you
> wish to test HEAD code and report success, I'll be happy to backport it
> to OpenLDAP 2.3 so that it gets released with the next release.
>
O.k, thanks. But, I would like to know, what does the termin "HEAD code" mean? And where can I get it? Sorry for my educationless...
> Any blob-like format would be fine (although I haven't tested it with
> PostgreSQL yet).
So, do You mean BLOB-like format as oid (in PostgreSQL), or just something like varbit type? I tried to put BLOBs in PostgreSQL by ldapadd - it's possible. But I had some problems when I tried to read from oid. I just had got the value of oid, but not stored data.
With best wishes,
Dmitry...
15 years, 2 months
Re: (ITS#4997) lmpasswd support using gcrypt
by kurt＠OpenLDAP.org
On Jun 2, 2007, at 6:31 AM, rra(a)stanford.edu wrote:
> Full_Name: Russ Allbery
> Version: 2.4 (HEAD)
> OS: Debian
> URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245341
> Submission from: (NULL) (171.66.157.14)
>
>
> Now that 2.4 has native GnuTLS support, the patch that's been
> sitting around in
> Debian bug #245341 becomes potentially interesting (see the
> associated URL).
> This is a request to support LAN Manager password hashes when
> OpenLDAP is built
> with GnuTLS instead of OpenSSL, thus requiring using libgcrypt to
> do the DES
> work instead of OpenSSL's DES library.
>
> The patch in that bug almost certainly isn't okay in its current form,
Note that 3rd party contributions are generally not acceptable (for
IPR reasons).
That is, we generally require the author(s) of the patch to
contribute the patch.
If you think this patch is useful, you might suggest to its authors
that they
contribute it to the Project. In doing so, it's good to provide a
link to our
contributing guidelines, http://www.openldap.org/devel/
contributing.html.
> but I
> wanted to get the ITS filed for this feature request so that
> there's a record in
> the database and just in case someone else feels inspired to bring
> the patch up
> to date and clean it up. (Unlikely, I know.) Otherwise, I will
> probably clean
> this patch up for further submission at some point near the 2.4
> release (on
> which side of it, I'm not sure).
Without involvement from the authors of this patch, it's better to
simply
rewrite the feature from scratch.
-- Kurt
15 years, 2 months
Re: (ITS#4951) [contrib] RADIUS password module fixes
by ando＠sys-net.it
richton(a)nbcs.rutgers.edu wrote:
Committed.
Cheers, p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 2 months
Re: (ITS#4989) Quirk in Dynlist overlay configuration
by ando＠sys-net.it
marg(a)rz.tu-clausthal.de wrote:
> I found a behaviour issue with the dynlist overlay configuration:
>
> I tried the following configuration:
>
> overlay dynlist
> dynlist-attrset posixGroup memberURL
> dynlist-attrset groupOfURLs memberURL owner
The reason of that check is that the same attribute "memberURL" could
otherwise be used by both group classes to expand.
>
> but slaptest complains about it - and the slapd doesn't start with it:
>
> @(#) $OpenLDAP: slapd 2.3.34[...]
> /usr/local/etc/openldap/slapd.conf: line 91: "dynlist-attrset <oc>
> <URL-ad> [<member-ad>]": URL attributeDescription "memberURL" already
> mapped.
> slapd stopped.
>
> When I use multiple "overlay dynlist"-entries like:
>
> overlay dynlist
> dynlist-attrset posixGroup memberURL
> overlay dynlist
> dynlist-attrset groupOfURLs memberURL owner
>
> it works as expected, but there is a warning:
>
> overlay_config(): warning, overlay "dynlist" already in list
>
> PS: Although the new Version 2.3.35 isn't available via FreeBSD Ports
> yet, I don't think that it would change anything, because the source
> file of the dynlist-overlay doesn't seem to have changed in any part
> that matters to this issue.
I think the documentation describes the intended behavior, but
configuration parsing is not (no longer?) in agreement with the
documentation. I think the real issue is that the behavior is no longer
consistent for compares and searches:
- for searches, only the first group that matches the entry's
objectClass will be expanded
- for compares, all groups that match will be expanded until a match is
found
I'm reworking the configuration test to be consistent with the
documentation, and the code to be self-consistent: now all groups
matching the entry are expanded. So now a configuration like
dynlist-attrset groupOfURLs memberURL
dynlist-attrset groupOfURLs memberURL member
will simultaneously merge all attributes listed in a "memberURL", and
add the expanded entries' DN as "member".
However, I believe something like
dynlist-attrset posixGroup memberURL
dynlist-attrset groupOfURLs memberURL
should still be forbiden, otherwise the same "memberURL" would expand
twice. This, strictly speaking, is not an issue, as duplicates would
simply be discarded, but it would cause unnecessary overhead. Right
now, I have decided to turn this check into a config-time warning.
Please test and report.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 2 months
