[Fedora-directory-devel] slapi extednded match plugin: How to limit attribute's to match on?
by Andrew Bartlett
I've got my bitwise match plugin to load and run, but now I have an
issue. it appears that my matching rule needs to limit what attributes
it applies itself to.
That is, when I step though to code, from this query:
[abartlet@piglett source]$ bin/ldbsearch -H
ldapi:///data/samba/samba4/svn/source/st/dc/ldap/ldapi -b
"dc=samba,dc=example,dc=com" -s sub
'(|(&(!(groupType:1.2.840.113556.1.4.803:=1))(groupType:1.2.840.113556.1.4.803:=2147483648)(groupType:1.2.840.113556.1.4.804:=10)))' sAMAccountName groupType
# returned 0 records
I seem to be walking all the attributes, not just the attributes in the
search expression:
75 errno = 0;
76 a = strtoull((*vals)->bv_val, NULL, 10);
77 if (errno == ERANGE) {
78 ber_bvecfree( vals );
79 vals = NULL;
80 continue;
81 }
(gdb) p (*vals)->bv_val
$5 = 0x8411038 "(targetattr = \"*\") (version 3.0;acl \"full access to
all by all\";allow (all)(userdn = \"ldap:///anyone\");)\n"
The collation plugin is again to opaque for me to quite get how I'm
meant to handle this...
My plugin in attached.
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc. http://redhat.com
16 years, 6 months
[Fedora-directory-devel] Please review: [Bug 233215] verify-db.pl still assumes the db dir is always in the instance dir
by Noriko Hosoi
Summary: verify-db.pl still assumes the db dir is always in the instance dir
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233215
nhosoi(a)redhat.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|MODIFIED |ASSIGNED
This review request contains the proposed changes on ldapserver, internal spec file for Berkeley DB 4.2.52, and the Berkeley DB 4.2.52.
------- Additional Comments From nhosoi(a)redhat.com 2007-03-29 21:30 EST -------
There are mutiple problems found around verify-db.pl on Solaris... :(
1, I introduced "DB-DIR" macro for template-verify-db.pl.in, but the
corresponding version if create_instance.c hasn't been checked in yet (*
create_instance.c.diff is being attached)
2. template-verify-db.in has the following envirament variable PATH set:
$ENV{'PATH'} = "$prefix@db_bindir@:$prefix/usr/bin:@db_bindir@:/usr/bin";
And the derived verify-db.pl on 64-bit Solaris looks like this:
$ENV{'PATH'} = "$prefix/usr/bin:$prefix/usr/bin:/usr/bin:/usr/bin";
2-1. The problem is db_* utilities on 64-bit Solaris are installed in
/usr/bin/sparcv9, thus verify-db.pl fails to find the executables and exits.
2-2. To get the right path, db4 packaging is supposed to generate db.pc and put
the file in /usr/lib/sparcv9/pkgconfig, but svn:pkgs/db4 spec file does not have
the code (** db4.template.diff is being attached) Note: the system Berkeley DB
on RHELs has db.pc in /usr/lib/pkgconfig.
2-3. Even though db.pc is placed in the right place, ldapserver/m4/db.m4 does
not check db.pc with pkg-config, but sets the hardcoded path /usr/bin to
db_bindir (*** db.m4.diff is being attached)
3. With all the above fixes, ran verify-db.pl, then one of the Berkeley DB
utilities db_printlog crashed... The cause of the crash was a field called
timestamp is declared as int32_t, but the pointer to the value is casted to
(time_t *), where time_t is 64 bits on the 64-bit machine. The cast mismatch
makes ctime/localtime fail and it leads the utility crash. I looked at the db
4.4.20 code, and verified it was fixed. I back-ported the change to 4.2.52 and
made a patch since I could not find the patch on the Sleepycat site. (****
patch.4.2.52.txn is being attached)
------- Additional Comments From nhosoi(a)redhat.com 2007-03-29 21:32 EST -------
Created an attachment (id=151245)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151245&action=view)
cvs diff create_instance.c (* create_instance.c.diff in Comment #7)
File: ldap/admin/src/create_instance.c
Change:
1, I introduced "DB-DIR" macro for template-verify-db.pl.in, but the
corresponding version if create_instance.c hasn't been checked in yet.
------- Additional Comments From nhosoi(a)redhat.com 2007-03-29 21:37 EST -------
Created an attachment (id=151246)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151246&action=view)
svn diff db4.template (** db4.template.diff in Comment #7)
File: svn:rpms/pkgs/db4/SPECS/db4.template
Changes:
1) added a code to generate db.pc for pkg-config
2) apply a patch to fix the db_printlog crash problem. The patch proposal is
being attached later (**** patch.4.2.52.txn)
------- Additional Comments From nhosoi(a)redhat.com 2007-03-29 21:42 EST -------
Created an attachment (id=151247)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151247&action=view)
cvs diff ldapserver/m4/db.m4 (*** db.m4.diff)
File: ldapserver/m4/db.m4
Change: To set db_bindir, if db.pc exists, check if bindir variable is defined
in the file or not. If it's defined, set it to db_bindir. If not, set the
default path /usr/bin to db_bindir.
------- Additional Comments From nhosoi(a)redhat.com 2007-03-29 21:47 EST -------
Created an attachment (id=151248)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151248&action=view)
Proposed patch (**** patch.4.2.52.txn)
File: svn:rpms/pkgs/db4/SOURCES/patch.4.2.52.txn
Fix Description: The cause of the db_printlog crash was the unexpected cast
from the pointer to the 32-bit integer to the pointer to time_t/long (64-bit).
The patch is a back-port from db 4.4.20, where the problem was already fixed.
16 years, 6 months
[Fedora-directory-devel] Please review: [Bug 233215] verify-db.pl still assumes the db dir is always in the instance dir
by Noriko Hosoi
Summary: verify-db.pl still assumes the db dir is always in the instance dir
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233215
Product: Fedora Directory Server
Version: 1.0.4
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: medium
Component: Command Line Utilities
AssignedTo: nhosoi(a)redhat.com
ReportedBy: nhosoi(a)redhat.com
QAContact: ohegarty(a)redhat.com
Estimated Hours: 0.0
Description of problem:
The command line utility failed to be updated with the FHS change.
If the db is not in the instance dir (or the directory where verify-db.pl is
located), it does not check the db files.
------- Additional Comments From nhosoi(a)redhat.com 2007-03-21 13:28 EST -------
Created an attachment (id=150603)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=150603&action=view)
cvs diff template-verify-db.pl.in
File: ldap/admin/src/scripts/template-verify-db.pl.in
Changes:
0) eliminated the "current directory" from the utility. Now, it can be run
from any location.
1) updated to take a new option [-a <fullpath_to_db_dir> ] to allow specifying
the db dir/changelog dir; by default the start point is "db_dir"
(nsslapd-directory in cn=config,cn=ldbm database,cn=plugins,cn=config)
2) instead of assuming the db dir structure (e.g.,
db/<backend_instance>/<db_files>), now it checks all the db files found under
the specified path. This allows to run the utility against the backup files,
as well.
16 years, 6 months
[Fedora-directory-devel] Please review: [Bug 233027] make db2bak.pl & db2ldif.pl user more user-friendly
by Noriko Hosoi
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233027
Summary: make db2bak.pl & db2ldif.pl user more user-friendly
Product: Fedora Directory Server
Version: 1.0.4
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: medium
Component: Command Line Utilities
AssignedTo: nhosoi(a)redhat.com
ReportedBy: nhosoi(a)redhat.com
QAContact: ohegarty(a)redhat.com
Estimated Hours: 0.0
------- Additional Comments From nhosoi(a)redhat.com 2007-03-19 18:41 EST -------
Created an attachment (id=150442)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=150442&action=view)
cvs diff template-db2bak.pl.in template-db2ldif.pl.in
Files:
ldap/admin/src/scripts/template-db2bak.pl.in
ldap/admin/src/scripts/template-db2ldif.pl.in
Changes:
db2bak.pl: print out the back up directory
Back up directory: ...
db2ldif.pl: print out the exported ldif file name
Exported ldif file: ...
The ldif file name format: <server id>-[<backend>}<first suffix value>]+-<date_time>.ldif
Description of problem:
[background info]
> > Both db2bak.pl and db2ldif.pl do not say much about where they are backing up
>
or exporting.
> > ./db2ldif.pl -D "cn=Directory Manager" -w <pw> -n userRoot`
> > adding new entry cn=export_2007_3_19_11_1_38, cn=export, cn=tasks, cn=config
> >
> > ./db2bak.pl -D 'cn=Directory Manager' -w <pw>
> > adding new entry cn=backup_2007_3_19_11_14_51, cn=backup, cn=tasks, cn=config
> >
> > Isn't it nicer the perl scripts prints out something like "exporting to
>
<fullpath>/<ldiffilename>" or "backing up to <backup_dir>" if it's not too noisy?
Yes, they should print something like that.
> >
> > Maybe, we'd better add "backend name" to the path as well? E.g.,
>
laputa-userRoot_2007_3_19_11_14_51.ldif.
Sure.
[Fix proposal]
db2bak.pl
=========
./db2bak.pl -D 'cn=Directory Manager' -w <pw>
Back up directory: /opt/fedora-ds/slapd-laputa/bak/2007_3_19_14_18_17
adding new entry cn=backup_2007_3_19_14_18_17, cn=backup, cn=tasks, cn=config
db2ldif.pl
==========
1) if suffixes are given, the first rdn values are added to the ldif file name
following the server id separated by '-'s.
./db2ldif.pl -D 'cn=Directory Manager' -w <pw> -s dc=example,dc=com -s
o=netscaperoot
Exported ldif file:
/opt/fedora-ds/slapd-laputa/ldif/laputa-example-netscaperoot-2007_3_19_14_18_7.ldif
adding new entry cn=export_2007_3_19_14_18_7, cn=export, cn=tasks, cn=config
2) if backend instance names are given, the instance names are added to the ldif
file name following the server id separated by '-'s.
./db2ldif.pl -D 'cn=Directory Manager' -w <pw> -n userRoot -n netscapeRoot
Exported ldif file:
/opt/fedora-ds/slapd-laputa/ldif/laputa-userRoot-netscapeRoot-2007_3_19_14_18_14.ldif
adding new entry cn=export_2007_3_19_14_18_14, cn=export, cn=tasks, cn=config
note: if '-a' options are given to the both utilities, the specified path is
used for the back up dir/ldif file.
16 years, 6 months
[Fedora-directory-devel] tls_checkpeer coresponding for the openldap API
by Yoram Kahana
Hi,
I am using the FDS with the SSL/TLS enable. I had to activate my
ldap.confconfig file to the "tls_checkpeer no".
It works fine and solved the problem.
I am looking for the corresponding solution when using the openldap (or
Fedora) API.
After the ldap_start_tls_s(ldap,NULL,NULL)
I am getting the problem that the server certificate failed in the verifying
procedure.
The client side error is SSL3_GET_SERVER_CERTIFICATE: certificate verify
failed
In the server i am getting an error notifying me that the peer could not
verify the ca certificate.
Any idea for how to define (through the API) to ignore the server
certificate similar to the tls_checkpeer
Thanks in advance
Yoram
16 years, 6 months
[Fedora-directory-devel] Please review: [Bug 232050] Change format of DBVERSION and guardian files (changelog)
by Noriko Hosoi
Summary: Change format of DBVERSION and guardian files
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232050
[Problem description]
The DBVERSION and guardian files used by the database backends should convey
some information about the database implementation used (e.g. berkeley db,
sqlite), the version, the directory server database backend used, and any other
information pertinent to the server being able to use or upgrade the files. The
following format is proposed:
implementation/version/server backend plugin name[/other tag][/other tag]....
For example:
bdb/4.2/libback-ldbm/newidl
This indicates that the files use Berkeley DB version 4.2, they are used by the
server libback-ldbm database plugin, and the index files use the newidl format.
The other tags are optional and may be implementation specific. At a minimum,
the file must contain the implementation/version/pluginname.
The reasons for changing the format are as follows:
1) Make it easy for humans and code to identify what the files are, how they are
used, and how to upgrade or migrate them
2) Separate the database file version and formats from the directory server
version, vendor, and brand
3) Allow new database implementations, plugins, and features e.g.
sqlite/3.0/libback-sqlite
4) A one line description is easy to read in and easy to parse
When the server reads in a database with an old format DBVERSION or guardian
file, it will change the file to use the new format and upgrade the data as
necessary.
--------------------------------------------------------------------------------
This change is made against the changelog used by the replication plugin following the format change on the main backend.
------- Additional Comments From nhosoi(a)redhat.com 2007-03-15 16:39 EST -------
Created an attachment (id=150172)
--> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=150172&action=view)
cvs diffs
Files:
repl_shared.h
cl5_api.h
cl5_api.c
Changes:
1) change the format of changelogdb/{DBVERSION,guardian} files
[before]
Changelog5/NSMMReplicationPlugin/4.0
[after]
bdb/4.4/libreplication-plugin
Note: changelog guardian file stores the same string as DBVERSION does,
thus changed the format to follow the DBVERSION style.
As being done for the backend, use DB_VERSION_MAJOR and _MINOR to get
the current version of the Berkeley DB.
2) Added the 3-rd arg buflen to _cl5ReadDBVersion.
3) Added transaction removing code to _cl5Upgrade3_4
4) Added _cl5Upgrade4_4 which is a subset of _cl5Upgrade3_4.
16 years, 6 months
[Fedora-directory-devel] Please review: Bug 232377: PAM passthru ENTRY method not working
by Rich Megginson
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232377
Resolves: bug 232377
Bug Description: PAM passthru ENTRY method not working
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: There are several problems.
1) For the ENTRY method to perform the internal search to get the entry
for the bind DN, it must have a component ID (aka plugin identity). The
code was already there to get/set it, but it was never initialized in
the init function.
2) You cannot mix slapi_sdn_new* with slapi_sdn_init* - slapi_sdn_init
will erase the knowledge that the Slapi_DN was allocated with malloc and
it will not free it in slapi_sdn_free().
3) People may assume they can specify a subtree (e.g.
ou=people,dc=example,dc=com) instead of a suffix for the list of
included/excluded suffixes. The error message will not print a list of
valid suffixes for the admin to use.
4) slapi_be_exist was failing because the database does not notify the
mapping tree code that the backend is started during startup. This
works fine under normal conditions because most all of the code in
mapping_tree.c will lookup the backend if the mtn_be pointer in the
mapping tree node is NULL. However, slapi_be_exist and slapi_be_select
do not do this. The proper solution is to call slapi_mtn_be_started()
at database startup time. This is the same thing that happens when a
backend is added at runtime.
Platforms tested: FC6
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=150138&action=diff
16 years, 6 months