Hi!
After reading the manual of slapcat (for 2.5) it recommends using option -H and an URI instead of other obsolete options. So I tried it, but all I get is a usage message, even with "-v" and "-d9". Like this: # slapcat -d9 -H 'ldap:///?entryCSN?sub?(objectClass=*)' usage: slapcat [-v] [-d debuglevel] [-f configfile] [-F configdir] [-o <name>[=<value>]] [-c] [-g] [-n databasenumber | -b suffix] [-l ldiffile] [-a filter] [-s subtree] [-H url] However when I use # slapcat -H 'ldap://?entryCSN?dc=...,dc=de?sub?(objectClass=*)'
I get output.
The URI should be:
scheme COLON SLASH SLASH [host [COLON port]] [SLASH dn [QUESTION [attributes] [QUESTION [scope] [QUESTION [filter] [QUESTION extensions]]]]]
Do I have tomatoes on my eyes? Anyway I think slapcat could provide a better error message.
Even an ltrace did not enlighten me: # ltrace slapcat -d9 -H 'ldap:///?entryCSN?sub?(objectClass=*)?' ber_set_option(0, 0x8002, 0x55ad287ce980, 0x7f7d383ff680) = 0 ldap_pvt_thread_initialize(0x7f7d3862c1c0, 0x55ad287ce980, 32, 0x55ad287ce980) = 0 ldap_create(0x55ad287d6a78, 0, 0, 0) = 0 ldap_pvt_tls_set_option(0x55ad56df1a50, 0x6006, 0x7ffd5d8d1f6c, 48) = 0 strrchr("slapcat", '/') = nil strcmp("slapcat", "slapd") = -1 strcmp("slapcat", "slapadd") = 2 strcmp("slapcat", "slapcat") = 0 ldap_set_option(0, 0x5001, 0x55ad287d12d0, 0x7ffd5d8d2158) = 0 getopt(4, 0x7ffd5d8d2158, "a:b:cd:f:F:gH:l:n:o:s:v") = 100 __ctype_b_loc() = 0x7f7d384c1d60 strtoul(0x7ffd5d8d36a9, 0x7ffd5d8d1bb0, 0, 0) = 9 getopt(4, 0x7ffd5d8d2158, "a:b:cd:f:F:gH:l:n:o:s:v") = 72 ldap_url_parse_ext(0x7ffd5d8d36ae, 0x7ffd5d8d1cb0, 5, 0) = 10 __fprintf_chk(0x7f7d384004e0, 1, 0x55ad2877a9f0, 0x55ad2875c4ddusage: slapcat [-v] [-d debuglevel] [-f configfile] [-F configdir] [-o <name>[=<value>]]) = 88 fputs(" [-c]\n\t[-g] [-n databasenumber |"..., 0x7f7d384004e0 [-c] [-g] [-n databasenumber | -b suffix] [-l ldiffile] [-a filter] [-s subtree] [-H url] ) = 1 exit(1 <no return ...> +++ exited (status 1) +++
Kind regards, Ulrich Windl
On Fri, Apr 25, 2025 at 07:24:56AM +0000, Windl, Ulrich wrote:
Hi!
After reading the manual of slapcat (for 2.5) it recommends using option -H and an URI instead of other obsolete options. So I tried it, but all I get is a usage message, even with "-v" and "-d9". Like this: # slapcat -d9 -H 'ldap:///?entryCSN?sub?(objectClass=*)' usage: slapcat [-v] [-d debuglevel] [-f configfile] [-F configdir] [-o <name>[=<value>]] [-c] [-g] [-n databasenumber | -b suffix] [-l ldiffile] [-a filter] [-s subtree] [-H url] However when I use # slapcat -H 'ldap://?entryCSN?dc=...,dc=de?sub?(objectClass=*)'
In the manpage under the -H option: "use dn, scope and filter from URI to only handle matching entries."
You are adding other parts to the URI (an attribute list) that slapcat is not willing to handle.
Regards,
OMG!
Assuming the tool will parse the URI at least, can't it say "filtering attributes is not implemented (cowardly refusing to run at all)"? The manual suggests, unsupported parts will just be ignored. I think the manual page should state more clearly that LDAP standard URLs cannot be used. The good thing about standards is that there are so many of them.
Apart from that being able to filter specific attributes would be a nice feature.
Kind regards, Ulrich Windl
-----Original Message----- From: Ondřej Kuzník ondra@mistotebe.net Sent: Friday, April 25, 2025 2:47 PM To: Windl, Ulrich u.windl@ukr.de Cc: openldap-technical@openldap.org Subject: [EXT] Re: LDAP URI for slapcat -H
On Fri, Apr 25, 2025 at 07:24:56AM +0000, Windl, Ulrich wrote:
Hi!
After reading the manual of slapcat (for 2.5) it recommends using option -H and an URI instead of other obsolete options. So I tried it, but all I get is a usage message, even with "-v" and "-d9". Like this: # slapcat -d9 -H 'ldap:///?entryCSN?sub?(objectClass=*)' usage: slapcat [-v] [-d debuglevel] [-f configfile] [-F configdir] [-o
<name>[=<value>]] [-c]
[-g] [-n databasenumber | -b suffix] [-l ldiffile] [-a filter] [-s subtree] [-Hurl]
However when I use # slapcat -H 'ldap://?entryCSN?dc=...,dc=de?sub?(objectClass=*)'
In the manpage under the -H option: "use dn, scope and filter from URI to only handle matching entries."
You are adding other parts to the URI (an attribute list) that slapcat is not willing to handle.
Regards,
-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
On Tue, Apr 29, 2025 at 09:02:32AM +0000, Windl, Ulrich wrote:
OMG!
Assuming the tool will parse the URI at least, can't it say "filtering attributes is not implemented (cowardly refusing to run at all)"? The manual suggests, unsupported parts will just be ignored. I think the manual page should state more clearly that LDAP standard URLs cannot be used. The good thing about standards is that there are so many of them.
Manpage literally says: The entry records will include all (user and operational) attributes stored in the database. The entry records will not include dynamically generated attributes (such as subschemaSubentry).
Also I opened ITS#10331 (and MR!767) last week in response to your email re: a more useful error message. If it gets merged before 2.5.20 is released it could end up in there (you are aware that with 2.5.20 and 2.6.10, the 2-year EOL clock starts on the 2.5 release stream?)
Apart from that being able to filter specific attributes would be a nice feature.
This is slapcat and its primary purpose (like other slap* tools) is to help with administrative tasks that need access to the raw database contents, slapcat used mostly for backup purposes.
You can always file an enhancement request and/or provide a patch if you think this would be useful. However, keep in mind that the attribute list in the URI can't be understood in the usual way - an empty list of attributes *MUST* still result in all (even operational!) attributes being returned. And processing of the entries (like removing attributes from them after the entry has been constructed here) might harm those that use it for its intended purpose.
On the other hand, if you can't search a live server for some reason, you can always use grep if that's what you really need.
Regards,
openldap-technical@openldap.org
-
Ondřej Kuzník -
Windl, Ulrich