On Monday 12 March 2007 18:04, you wrote:
> 2.2.13 is historical. ldap_sasl_bind(3) eventually got documented (only
> the prototype in 2.3, more docs in 2.4). Please check current 2.4
> documentation and, in case, adapt your contribution to it. In fact, that
> man page does not contain any coding example, as we usually refer to client
> tools implementations. Please feel free to submit your contribution, lined
> up to active code, as a FAQ entry <http://www.openldap.org/faq/>. The FAQ
> is interactive.
Hi,
thanx for reply.
Indeed, 2.2.13 may be historical, yet this is the version used in large
production systems (e.g. RedHat Enterprise Linux).
I'll try to have a look at what's in 2.4.
best regards:
Piotr
Full_Name: Kevin Vargo
Version: 2.3.32
OS: Linux (RH-EL4)
URL: ftp://ftp.openldap.org/incoming/openldap-2.3.32-kv1-patch_support-binary-at…
Submission from: (NULL) (128.237.242.55)
These address the use of Binary-valued attributes (#3113, #3386):
For example, inetOrgPerson.userCertificate is usually transferred with the
";binary" directive. ";binary" is not handled by OpenLDAP/Back-SQL. As well,
the data itself, when stored in the database is not properly read out -- all
data is read as SQL_C_CHAR data. This supports SQL_C_BINARY-based data.
There remains an issue with selecting attributes using, e.g.,
"userCertificate;binary" -- nothing is returned. Someone with a better
understanding of the attribute-processing method would be much more effective in
terms of finding the correct place to remove the ";binary" from the
"attribute-name." (i.e. "userCertificate;binary" is NOT the attribute-name;
"userCertificate" is the attribute-name, ";binary" is a transport directive (see
#3113).
Additionally, I included to the patch to remove the "assert(0)" in Back-SQL's
verification that a search filter and ldap-data don't mis-match on suffix.
Tags: OpenLDAP, Back-SQL, MySQL, userCertificate, Binary Attributes, Client
Certificates
(1)
./servers/slapd/back-sql/search.c.patch
Addressed ITS#4856 -- I think you already fixed this
(2)
./servers/slapd/back-sql/back-sql.h.patch
./servers/slapd/back-sql/entry-id.c.patch
./servers/slapd/back-sql/sql-wrap.c.patch
Address ITS#3113, ITS#3386
Support for binary attribute values
(3)
./servers/slapd/back-sql/schema-map.c.patch
Addresses issue with accessing attributes that have been provided with
";binary" directive
note that I have no doubts whatso ever that there are many better ways to do
(3).
Full_Name: Piotr.Golonka(a)CERN.CH
Version: 2.2.13
OS: Linux
URL: ftp://ftp.openldap.org/incoming/golonka-pkg-070312.tgz
Submission from: (NULL) (137.138.170.170)
Hi,
the documentation of the ldap_sasl_bind* family of functions is missing, and
getting the actual DIGEST-MD5 authentication in your C code working seems to be
completely undocumented.
I went through the complete code of ldapsearch.c and extracted the minimal code
that succesfully demonstrates DIGEST-MD5 authentication. In my case, I
authenticated against ActiveDirectory server.
I uploaded the example into your FTP server as golonka-pkg-070312.tgz
I hope it may be useful to publish it as a short "Howto" material...
regards
Piotr Golonka
CERN
Full_Name: Maruthi Gullapudi
Version:
OS: AIX
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (194.221.133.211)
Hi,
I wanted to list all the users based on the value of one attribute using the
LDAPSEARCH Command. The value of that attribute is NULL. I dont know whether
LDAPSEARCH will capture null values.
Can anyone tell me how to list users from an LDAP directory based on a NUll
valued attribute.
Thanks in Advance
Maruthi
[please keep the ITS in CC]
Eubank, Chris LCS:EX wrote:
> Am running Solaris 10, and the version I stuck in the log.
>
> When I created an "openldaprc" and used the variable for the
> replication log,
What is the "variable for the replication log"? All one usually needs
to do is define a replogfile in slapd.conf(5)
> (which ends up obviously running the slurpd daemon
> with the -r switch),
Again: there's no need to use -r if replogfile is in slapd.conf(5); if
there is no replogfile in slapd.conf(5), slapd(8) will not generate any
log, so slurpd(8) will have nothing to do
> it sent the replication data to the logfile and
> not to the replication hosts being specified.
Who sent the replication data to the logfile? slapd(8) is supposed to
write replication data to the file specified in replogfile
(sladp.conf(5)); slurpd(8) is supposed to read that file (whose
existence and location is known by parsing slapd.conf(5)), copy the
content it is able to process to its own replication log, which resides
in slurpd's working directory (default or passed with -t) and is called
slurpd.replog, send that content to the slaves, and remove the data that
has been handled from slapd's replication log.
This is how things are expected to work. As you may see, -r never comes
into play; it's intended to be used to force slurpd processing of a
different file, which may be required for special purposes. Do you have
any special needs, or are you simply trying to set up usual replication?
> Does that make more sense?
See comments above.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
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
------------------------------------------
raphael.ouazana(a)linagora.com wrote:
> Fixing these issues, I saw that set_parent will be very similar to
> set_chase. Do you think I should create a new gatherer instead of ?
I don't see so much similarity: set_chase() is intended to use the
gatherer to fetch objects and extract a value from them, including
"closure" (recursion). Sublevel does not require fetching, and takes a
negative digit as extra argument, rather than an attribute type, so
you'd need to add an outer test before calling set_chase() anyway,
extend the interface of set_chase() to allow an AttributeDescription and
an integer, and so on, while you don't need any callback capability to
fetch an object or expand values or so. I'd keep it simple as it is now.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
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
------------------------------------------
chris.eubank(a)gov.bc.ca wrote:
> Full_Name: Chris Eubank
> Version: 2.3.31 (Jan 7 2007 08:51:37)
> OS: Solaris 10
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (142.32.230.251)
>
>
> If the -r option is used with the 'slurpd' daemon it breaks the replication
> function and sends the replication data to the specified logfile instead.
What does this mean? According to the documentation, -r must point to
slapd's replog file, namely the file where replications are logged by
the producer. Of course, if you point it to a file that is not a valid
replication log, the behavior will be unexpected.
> This behaviour is not documented in the manpage for slurpd.
Please describe what behavior you obtain and how it differs from
documented. Note that regular users are not supposed to use the -r
switch, since slurpd typically knows where to get the replog file.
Also, note that slurpd is deprecated; syncrepl should be used instead.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
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
------------------------------------------
Full_Name: Bret Lambert
Version: -HEAD
OS: OpenBSD
URL: ftp://ftp.openldap.org/incoming/bret-lambert-070309.patch
Submission from: (NULL) (70.179.123.124)
There are two declarations of "int i;" in main.c main(). The patch listed
removes the second (spurious) declaration of the variable.
Found via lint(1) on OpenBSD
Full_Name: Chris Eubank
Version: 2.3.31 (Jan 7 2007 08:51:37)
OS: Solaris 10
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (142.32.230.251)
If the -r option is used with the 'slurpd' daemon it breaks the replication
function and sends the replication data to the specified logfile instead.
This behaviour is not documented in the manpage for slurpd.
Full_Name: Michael Burr
Version: 2.3.30
OS: Debian 4.0 (sid)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (70.145.225.250)
Referring to the Administrator's Guide hosted at openldap.org, in the "Access
Control" section (http://www.openldap.org/doc/admin23/slapdconf2.html#Access%20Control),
if I copy this statement:
olcAccess: to attr=member,entry
by dnattr=member selfwrite
directly into my configuration (replacing "olcAccess: " with "access to"),
slaptest complains:
slapd.conf: line 40: "attr" is deprecated (and undocumented); use "attrs"
instead.
config file testing succeeded
As is suggested by the output, slaptest returns with success (0).