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, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
