marg(a)rz.tu-clausthal.de wrote:
>> i use this line (on my ldif file) to add a picture on my LDAP directory:
>>
>> jpegPhoto: < file///etc/ldap/pictures/test.jpg
>
> Are you sure that you aren't missing a colon (':')? According to the
> manpage of ldapadd the line should look like this:
>
> jpegPhoto: < file:///etc/ldap/pictures/test.jpg
Moreover, this bug appears to have already been fixed. It is
recommended to check the latest version before reporting bugs.
> Oh, and that special syntax is a function of ldapadd/ldapmodify, not
> some standard way of importing images - so using it with slapadd won't work.
well, that's a SHOULD in RFC2849, so it is indeed a standard way of
importing values (works with any value) using LDIF. The fact it doesn't
work with slapadd should be seen as a limitation of that tool, which it
is not intended for use with arbitrary LDIF but rather with LDIF
produced by slapcat.
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
---------------------------------------
Hello,
nicolas.sandraz(a)gmail.com wrote:
> when i use a LDIF file with the falowing attribute jpegPhoto associate with the
> object class inetOrgPerson i have this error:
>
> slapadd : /tmp/build/openldap2.3-2.3.30/servers/slapd/schema_check.c:87 :
> entry_schema_check: Assertion `a->a_vals[0].bv_val != ((void *)0)' failed.
>
> i use this line (on my ldif file) to add a picture on my LDAP directory:
>
> jpegPhoto: < file///etc/ldap/pictures/test.jpg
Are you sure that you aren't missing a colon (':')? According to the
manpage of ldapadd the line should look like this:
jpegPhoto: < file:///etc/ldap/pictures/test.jpg
Oh, and that special syntax is a function of ldapadd/ldapmodify, not
some standard way of importing images - so using it with slapadd won't work.
bye
Christian
--
Christian Marg mail : mailto:marg@rz.tu-clausthal.de
Dezernat 2 TU Clausthal web : http://www.tu-clausthal.de
D-38678 Clausthal-Zellerfeld fon : 05323/72-2107
Germany jabber: ifcma(a)jabber.tu-clausthal.de
Full_Name: Sandraz Nicolas
Version: 2.3.30
OS: Linux (debian Etch)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.252.72.177)
when i use a LDIF file with the falowing attribute jpegPhoto associate with the
object class inetOrgPerson i have this error:
slapadd : /tmp/build/openldap2.3-2.3.30/servers/slapd/schema_check.c:87 :
entry_schema_check: Assertion `a->a_vals[0].bv_val != ((void *)0)' failed.
i use this line (on my ldif file) to add a picture on my LDAP directory:
jpegPhoto: < file///etc/ldap/pictures/test.jpg
note: when i remove this line from my ldif file i can import all information!
Full_Name: Michael Ströder
Version: HEAD
OS: openSUSE 10.2
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (83.124.34.52)
Running ./scripts/test043-delta-syncrepl...
running defines.sh
Starting producer slapd on TCP/IP port 9011...
Using ldapsearch to check that producer slapd is running...
Using ldapadd to create the context prefix entries in the producer...
Starting consumer slapd on TCP/IP port 9012...
Using ldapsearch to check that consumer slapd is running...
Waiting 5 seconds for slapd to start...
Using ldapadd to populate the producer directory...
Waiting 15 seconds for syncrepl to receive changes...
Stopping the provider, sleeping 10 seconds and restarting it...
Using ldapsearch to check that producer slapd is running...
Using ldapmodify to modify producer directory...
Waiting 15 seconds for syncrepl to receive changes...
Stopping consumer to test recovery...
Modifying more entries on the producer...
Restarting consumer...
Waiting 25 seconds for syncrepl to receive changes...
Try updating the consumer slapd...
Waiting 15 seconds for syncrepl to receive changes...
Using ldapsearch to read all the entries from the producer...
Using ldapsearch to read all the entries from the consumer...
Filtering producer results...
Filtering consumer results...
Comparing retrieved entries from producer and consumer...
test failed - producer and consumer databases differ
<quote who="Pierangelo Masarati">
> Gavin Henry wrote:
>
>> OK, thanks. Do you have any reference for custom monitoring examples?
>
> Not sure what you mean. By "custom monitoring" I mean that pieces of
> code may register callbacks in back-monitor to enrich the monitor
> entries with dynamically generated data. Right now, the only code that
> exploits this functionality is back-bdb/back-hdb, but it's something we
> use intensively for custom modules we develop (the monitor database can
> be proficiently used as an interface for non-persistent interaction with
> the DSA).
Ah, right. Sorry, I misunderstood custom as something done via
configuration in the front end, not via callbacks.
>
> With reference to code, see servers/slapd/back-bdb/monitor.c (the API is
> implemented in servers/slapd-back-monitor/init.c).
Will do, sounds very useful indeed.
>
> What back-bdb/hdb publishes by means of this API is not documented,
> AFAIK; it might be worth mentioning somewhere in the docs, as this
> monitoring could be quite useful for tuning. Nothing that cannot be
> accessed thru db_stat, the advantage is access via LDAP protocol.
Exactly, sounds very useful and one that I can investigate and document in
the Monitoring section, with implementation examples (not code) in the
Tuning and Maintenance sections of our guide.
>
> A recent addition was the capability to monitor what unindexed
> attributes were used in searches.
Yeah, I commented on that previously. Nice.
Gavin.
>
> 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
> ---------------------------------------
>
>
>
Gavin Henry wrote:
> OK, thanks. Do you have any reference for custom monitoring examples?
Not sure what you mean. By "custom monitoring" I mean that pieces of
code may register callbacks in back-monitor to enrich the monitor
entries with dynamically generated data. Right now, the only code that
exploits this functionality is back-bdb/back-hdb, but it's something we
use intensively for custom modules we develop (the monitor database can
be proficiently used as an interface for non-persistent interaction with
the DSA).
With reference to code, see servers/slapd/back-bdb/monitor.c (the API is
implemented in servers/slapd-back-monitor/init.c).
What back-bdb/hdb publishes by means of this API is not documented,
AFAIK; it might be worth mentioning somewhere in the docs, as this
monitoring could be quite useful for tuning. Nothing that cannot be
accessed thru db_stat, the advantage is access via LDAP protocol.
A recent addition was the capability to monitor what unindexed
attributes were used in searches.
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
---------------------------------------
<quote who="ando(a)sys-net.it">
> ghenry(a)suretecsystems.com wrote:
>
>> Ok. What can the rootdn do on the monitor database then? Write to
>> anything?
>> I can update the "Monitoring" section with this info then ;-)
>
> As usual, the privilege of the rootdn consists in bypassing ACLs. In
> this case, you just need the rootdn, it doesn't need to be able to bind
> (i.e. no rootpw and no fancy SASL rules to map someone with that
> identity), since it will only be used for internal purposes, namely to
> look up where bdb custom monitoring will be placed.
OK, thanks. Do you have any reference for custom monitoring examples?
Gavin.
>
> 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
> ---------------------------------------
>
>
>
>
Quanah,
for which is which, HEAD now has back-config support for both slapo-rwm
and slapd-relay. You may resume your configuration replication
experiments...
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
---------------------------------------
ghenry(a)suretecsystems.com wrote:
> Ok. What can the rootdn do on the monitor database then? Write to anything?
> I can update the "Monitoring" section with this info then ;-)
As usual, the privilege of the rootdn consists in bypassing ACLs. In
this case, you just need the rootdn, it doesn't need to be able to bind
(i.e. no rootpw and no fancy SASL rules to map someone with that
identity), since it will only be used for internal purposes, namely to
look up where bdb custom monitoring will be placed.
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
---------------------------------------
Full_Name: Pierangelo Masarati
Version: HEAD/re23
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (82.63.140.131)
Submitted by: ando
When extra objectClasses for an entry are listed in table ldap_entry_objclasses,
if any of them is structural and derived from the objectClass used to map the
RDBMS data to LDAP, the entry is now rejected because the computed objectClass
does not match the objectClass used to map data, although the entry would be
perfectly valid from an LDAP standpoint.
This is now fixed in HEAD/re23.
p.