Re: SyncRep - 1 provider : n co nsumer [auf Viren überprüft]
Hans Moser wrote: Hi! Coming back to this - http://www.openldap.org/lists/openldap-software/200501/msg00375.html where Howard Chu said: In practice this requirement is of little value and is contrary to one of syncrepl's other design points - the provider is not supposed to need to maintain any special state about individual consumers. Verifying that the search parameters are identical between requests would require the provider to maintain a list of all the syncrepl requests it has received, and OpenLDAP doesn't do this. Does it mean, it is not recommened to use n consumers with 1 SynRep-provider (for the same database)? No, that is not what it means. A single provider can serve any number of consumers. My point in the text above is that there is little value in having the syncrepl provider validate the consumer's request cookie by calculating a hash of all of the request parameters. Nothing is gained by performing such a validation step, and OpenLDAP does not do that validation. If not, how should sid and rid be configured? As I stated in the above referenced message, the OpenLDAP 2.2 syncrepl design is flawed. The sessionlog was ineffective on the provider side and there is no way to configure the sid in OpenLDAP 2.2 on the consumer side. Howard Chu said: The sessionlog only looks at the sid, and the provider and consumer sid must match. Put one sessionlog-statement per consumer with individual sid in the provider's slapd.conf? [But I can't see any Relation between the consumer configured rid an the sessionlog-statement..] There is no relation between the rid and the sid. I suggest you switch to OpenLDAP 2.3 and forget everything you have ever read about sid's in OpenLDAP 2.2. It was poorly conceived; none of it made any sense. The notion of sid has been completely removed in OpenLDAP 2.3, the syncrepl is significantly simplified now, and all of this functionality actually works as intended. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support
Re: openldap 2.3 recommended bdb version
Buchan Milne wrote: Quanah Gibson-Mount wrote: OpenLDAP 2.3 requires that you use the transactions patch to BDB 4.2.52 that's available from various locations (see The patch is not required although it is certainly recommended. http://www.stanford.edu/services/directory/openldap/configuration/bdb-build-42.html for example). I thought the patch was included somewhere in the OpenLDAP 2.3 source tarball, but I didn't see it when looking through the code. It was supposed to be included. It will be included in the next 2.3 release. In the meantime you can get it from the OpenLDAP CVS. http://www.openldap.org/devel/cvsweb.cgi/build/BerkeleyDB42.patch Hmm, could there not be a configure check for this patch? My initial Mandriva cooker contrib package of openldap2.3 isn't too stable, and I suspect this is the problem (due to one error message I saw to that effect), but it would be quite tricky for people to track down without knowing where to look ... If there were a patch that were actually required, then of course we would check for it in the configure script, but it is not required. Its presence or absence has no impact on the stability of the BDB library or the OpenLDAP code. It merely allows the library to release the transaction log files without requiring slapd to shutdown, so that you can use db_archive or DB_LOG_AUTOREMOVE. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support
Re: smbk5pwd: pass change exop works, {K5KEY} check doesn't
Kris Maglione wrote: That seems obvious. The problem is, as I said, I can kinit to the principal with the password set with the exop. That pretty much rules out the kdc using another source. I store the keys in K4, K5, and AFS formats, if that makes a difference Yes, that makes the difference. The passwd_exop code sets all of the configured keytypes but the check function only checks the first key value, and it assumes it is a K5 key. It doesn't handle K4/AFS salt formats. So it appears that it's trying to apply a K5 salt to a K4/AFS key, which obviously doesn't work. (It *is* called K5KEY after all, not something generic like KRBKEY because it is only intended for Kerberos 5 keys.) I guess you should file an ITS; the code should at least make sure that the key it is checking has a type that's compatible with the salt it is generating, instead of blindly applying the K5 salt. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support
Re: smbk5pwd: pass change exop works, {K5KEY} check doesn't
Kris Maglione wrote:
I'm sorry I didn't explain that better. I set the value back to
{K5KEY} after the exop changed it. I've read in several places that
password-hash had to be set to {CLEARTEXT} for this module to work,
but that stored the cleartext password.
A quick Google didn't turn up any statements to this effect for me.
Wherever you read that, ignore it. The password-hash should be {K5KEY}
if you want the Kerberos key to be used.
--
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
Re: deferring operation ?
Roderick Petetin wrote: :-S Did you ever experiment a slapd upgrade ? Many, many times. Do you know some documentation about that ? stop slapd, slapcat - install 2.2.27 and import the ldif file ? Could it be that simple ? In this case, since you're only moving within the same minor version, you can just replace the old slapd with the new slapd. Assuming that you keep everything else the same, of course (mainly, keep the same BerkeleyDB version). Thanks for your help, Roderick. Try upgrading to 2.2.27. Here is the full log message for a request : *Jul 4 13:50:03 annuaire slapd[19523]: conn=7554 fd=12 ACCEPT from IP=10.5.1.4:35305 (IP=0.0.0.0:389) Jul 4 13:50:03 annuaire slapd[19523]: conn=7552 fd=18 closed Jul 4 13:50:03 annuaire slapd[19523]: connection_read(18): no connection! -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support
Re: Nested groupOfNames members
Pierre-Francois LAURAND wrote: Hi, Can someone tell me if a groupOfNames object can be used as a member of another groupOfNames object ? You are free to put any valid DN as a member of a groupOfNames. With some acls based like : But OpenLDAP does not recursively expand nested groups when doing ACL evaluation. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support
Re: 2 GB filesize limit
Pierangelo Masarati wrote: You may also split the database in smaller bits, unless it has to be exactly one naming context (I don't recall if 2.1 already had the glue capability). Yes, glue in 2.1 was the groundwork for overlays in 2.2. Gentoo with a 2.6.5 kernel, glibc 2.3.3, openldap 2.1.30. It's doing this on 4 identical systems and 1 with a 2.6.9 kernel, so my configuration is somehow very wrong. System setup: admin1 is the master and replicates out to ldap1 and ldap2. Directory listings are at the end of the email. Last night, an ldap server died with the (non-exact) error unable to write to gdbm. The id2entry.gdbm file was a byte below 2 Gigs. In subsequent testing with dd, I cannot create a file bigger than 2*1024*1024*1024 bytes. Could someone please verify that: a) I need to rebuild something like glibc. b) I do not need to rebuild openldap. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support
Re: openldap profiling tools
Sébastien Georget wrote: I did not mention it because I was looking for a general way to find what's the bottleneck in an openldap installation. I can stress the server and play with the configuration to find what parameters improve performances (reduce failed authentications) but it's a long and not so easy process. I thought that server-side performances mesuring tools would have help in tuning the configuration with information such as It sounds like you're asking a pretty general question about code profiling then, not something specific to LDAP or OpenLDAP. - time spent processing filters - time spent processing acl - time spent in backend specific code On x86 Linux valgrind can be useful here (with calltree module). On Solaris and Linux I use FunctionCheck 1.5.4 for profiling. (Originally written by Yannick Perret, significantly enhanced by me.) http://freshmeat.net/projects/fncchk/ - number of connections rejected - peak request/s - ... Here is the configuration I am using : - openldap 2.2.27 with 8 bdb backends (1 + 7 subordinates) - 250 entries, will certainly grow to 2000-3000 What sort of entry cache do you have? cachesize 2000 default for other parameters I plan to make tests with : idlcachesize, conn_max_pending, timelimit, idletimeout Since the bdb files are very small (200k) I supposed that they stay in memory and I dit not look at DB_CONFIG files, should I ? Probably. Use db_stat -m, that will tell you whether the current (default) settings are working well or not. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support
Re: deferring operation ?
Roderick Petetin wrote: Hello, I upgraded my openldap server to 2.2.27 last week. In my log, i still see some deferring operation messages and i still have some freezes and delays in my slapd connexions (ex : my nagios send me some notifications : slapd server didn't respond in 10 seconds)... There is no indication of any delay or error in the log you attached. All of the activity occurred within less than one second, it all looks normal. I just don't what to do next... Here is the output of the log : Jul 11 09:29:44 annuaire slapd[13859]: conn=4748 op=0 BIND dn= method=128 Jul 11 09:29:44 annuaire slapd[13859]: conn=4748 op=0 RESULT tag=97 err=0 text= Jul 11 09:29:44 annuaire slapd[13859]: conn=4748 op=1 SRCH base=dc=insa-rennes,dc=fr scope=2 deref=0 filter=(uid=lgarcon) Jul 11 09:29:44 annuaire slapd[13859]: conn=4748 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Jul 11 09:29:44 annuaire slapd[13859]: conn=4748 op=2 BIND dn=uid=lgarcon,ou=people,dc=insa-rennes,dc=fr method=128 Jul 11 09:29:44 annuaire slapd[13859]: conn=4748 op=2 BIND dn=uid=lgarcon,ou=people,dc=insa-rennes,dc=fr mech=SIMPLE ssf=0 Jul 11 09:29:44 annuaire slapd[13859]: conn=4748 op=2 RESULT tag=97 err=0 text= Jul 11 09:29:44 annuaire slapd[13859]: connection_input: conn=4748 deferring operation: binding Jul 11 09:29:44 annuaire slapd[13859]: conn=4748 op=3 BIND anonymous mech=implicit ssf=0 Jul 11 09:29:44 annuaire slapd[13859]: conn=4748 op=3 BIND dn= method=128 Jul 11 09:29:44 annuaire slapd[13859]: conn=4748 op=3 RESULT tag=97 err=0 text= Jul 11 09:29:44 annuaire slapd[13859]: connection_input: conn=4748 deferring operation: binding Jul 11 09:29:44 annuaire slapd[13859]: conn=4748 op=4 UNBIND Jul 11 09:29:44 annuaire slapd[13859]: conn=4748 fd=22 closed -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support
Re: concurrency problem
Pruebas wrote: Hi, i'm using openldap-2.0.27 in a redhat 9 box. That's your first problem. OpenLDAP 2.0 was obsoleted 3 years ago. The current stable release is 2.2.26, although 2.2.27 is in better shape. The latest available release is 2.3.4. You seriously need to upgrade, and you should probably complain to your vendor for bundling such antiques in their distros. I have installed qmail-ldap, and it the hours of high traffic it can't get a connection to the ldap server, i wrote to the qmail-ldap list, and they toll me that it was a concurrency problem, so I rise the concurrency and the threads to 500, but i still have the same error. No amount of configuring will make OpenLDAP 2.0 work well in a high load environnment. It is a bad idea to set the threads value to such a high number, regardless of the release. At a minimum each thread consumes 2MB of stack space, so thats 1GB of RAM eaten up right there. In newer releases the stack size per thread is even higher. The optimal number of threads depends on the number and type of CPUs in the system, as well as the available memory size. The default on newer OpenLDAP releases is 16; 12-16 per CPU generally works well. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support
Re: Password Controls support?
See the slapo-ppolicy(5) man page in OpenLDAP 2.3. [EMAIL PROTECTED] wrote: Does openLDAP support password controls such as, 2.16.840.1.113730.3.4.4 LDAP_CONTROL_PWEXPIRED Using Password Policy Controls. 2.16.840.1.113730.3.4.5 LDAP_CONTROL_PWEXPIRING Using Password Policy Controls The ldap.h file does not list those controls. It also says some of the controls are in progress and not yet formalized. I would appreciate if someone throughs some light into this. I am particularly interested in the password controls. Thanks a million. Neo -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support
Re: loglevel -1 in slapd.conf [auf Viren überpr üft]
Hans Moser wrote: Hi! With OL 2.3.4 I get the following issue. When I change loglevel in slapd.conf to -1, OL dies immediatly after startup. No logs are written. When I change loglevel to something else and start slapd with -d -1, I get the debug output on the console as usual. Sounds like you should file an ITS for this. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support
Re: Index problems: search results returning no responses
Graham Leggett wrote: Quanah Gibson-Mount wrote: Did you run slapindex to generate the indices for your existing database? If you modify slapd.conf with new indices, OpenLDAP will only add it for new/changed entries (2.3 with back-config actually does reindexing on the fly). No, I didn't - there was no warning message in the config file or the syslog warning that this was necessary. Is it possible to document this in the default slapd.conf file under the section where indexes are listed to say that this is required? The slapd-bdb(5) manpage already says Note: changing index settings requires rebuilding indices, see slapindex(8). The default slapd.conf is not intended to be a substitute for reading the actual documentation. Or even better, is it possible for openldap to detect when the indexes have been changed, and make sure they are up to date on startup or on reload? Not in OpenLDAP 2.2, since that release is feature-frozen now and going into end-of-life soon. If you want dynamic index management use OpenLDAP 2.3. Regards, Graham -- -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support
Re: poor performance of OpenLDAP vs AD?
Tomasz Chmielewski wrote: Howard Chu schrieb: Quanah Gibson-Mount wrote: --On Wednesday, July 13, 2005 2:49 PM +0200 Tomasz Chmielewski [EMAIL PROTECTED] wrote: Recently, when planning to deploy a directory server, I was confronted with someone claiming that OpenLDAP performs poorly, when compared to Active Directory, and thus, we should choose AD. And I bet they also said that running Microsoft products has a lower Total Cost of Ownership than anything else too. Yeah it's some of the guys that believe in all that. But as I'm able to dismiss all his claims, with all I can't. AD works in a multi-master environment, OpenLDAP doesn't. We don't really need a multi-master environment, but can a claim that a multimaster environment is much more superior over master-slaves model in terms of preformance - can this claim be true? Pure nonsense, just like the TCO claims. As I studied the multimaster AD replication a bit: http://www.comptechdoc.org/os/windows/win2k/win2kadrepl.html and for me, it seems that it can be more efficient, as it would need at least one connection less. It requires one less connection when clients send updates to a slave server, and only in the simplest configuration*. If clients are already configured to send updates only to the master, then the number of connections required is the same as the multimaster case. Also, additional overhead of one connection is trivial as the number of servers increases. In efficiency terms, O(n) = O(n+1) - there is really no efficiency advantage for multimaster, when all else is equal. On the other hand, there seems to be much overhead concerned with additional data that goes around to keep this multimaster state in sync. And here is where the argument really falls down - all else is Not equal, their replication protocol requires a huge amount of metadata to maintain synchronization for each update. * here's a single-master alternative that requires the exact same number of connections as multi-master: Clients can send updates to any server; if a slave receives an update request it chains to the master. When the chained request succeeds on the master, the slave updates its own database and returns the success status to the client. The master then propagates the change to any slaves other than the one that originated the request. It's quite easy to write an overlay for OpenLDAP 2.2 or 2.3 to provide this mode of operation. The efficiency of this approach is far greater than the MSAD replication protocol, as there is no extra metadata involved. -- -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support
Re: ldap newbie again
Hardik Dalwadi wrote: Hello payal, It's very nice that u want to jump again in OpenLdap. Best way to start OpenLdap as a stand alone is to compile it manually from source. Get the source from OpenLdap.org http://www.openldap.org/software/download/ untar it in some good location like /usr/local/src Go in to /usr/local/src/openldap-2.2.26 and run below command. Best doc for OpenLdap is http://www.openldap.org/doc/admin23/quickstart.html http://www.openldap.org/doc/admin23/ While the 2.3 Admin Guide is certainly the best available document, it's important to note that it *is* for OpenLDAP 2.3, not OpenLDAP 2.2. Since you have recommended they download OpenLDAP 2.2.26, you should point them at the OpenLDAP 2.2 Admin Guide instead. http://www.openldap.org/doc/admin22/ And of course, the *easiest* way to get a working installation is to download a CDS build from www.symas.com, as it has all the required libraries correctly integrated already. Using our builds guarantees that you're using software that is known to work, which lets you focus on your own specific data configuration and not worry about whether you specified the right libraries and flags to configure and build the code. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: BDB corruption on windows port of 2.2.19
Safdar Kureishy wrote: Thanks for the information Matthew. I had a follow-up question. I obtained a windows version of db_recover online (since it did not come packaged with the windows OpenLDAP installation). There is a var\openldap-data folder under OpenLDAP under which I have these db files: In general you cannot mix and match BDB utilities, you must use the exact same version that was used to compile OpenLDAP. If you're using a Symas CDS build then all of the proper utilities are included in the package. If you're using a package created by someone else then you should get the utility from them. (Personally, I wouldn't trust a package from someone else if they were too negligent to provide all the needed utilities in the first place.) 07/21/2005 06:50 PM81,920 dn2id.bdb 07/21/2005 06:50 PM 1,015,808 id2entry.bdb 07/21/2005 06:50 PM10,485,760 log.01 07/21/2005 06:50 PM32,768 objectClass.bdb 07/21/2005 06:49 PM16,384 __db.001 07/21/2005 06:49 PM 270,336 __db.002 07/21/2005 06:49 PM98,304 __db.003 07/21/2005 06:49 PM 376,832 __db.004 07/21/2005 06:49 PM24,576 __db.005 9 File(s) 12,402,688 bytes 2 Dir(s) 24,146,268,160 bytes free] I ran the db_recover utility as below: C:\Program Files\OpenLDAPdb_recover -v -h var\openldap-data db_recover: unable to join the environment db_recover: unlink: var\openldap-data\__db.005: Permission denied db_recover: unlink: var\openldap-data\__db.004: Permission denied db_recover: unlink: var\openldap-data\__db.003: Permission denied db_recover: unlink: var\openldap-data\__db.002: Permission denied db_recover: unlink: var\openldap-data\__db.001: Permission denied db_recover: Ignoring log file: var\openldap-data\log.01: unsupported log version 10 You are clearly using the wrong version. The Permission denied errors probably indicate that you tried to run db_recover while slapd was running. You have to stop slapd and insure that no programs have any of the database files open before you can run db_recover. After you get hold of the right version of the utility and make sure that no programs are using the database these problems should go away. db_recover: Invalid log file: log.01: Invalid argument db_recover: PANIC: Invalid argument db_recover: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery db_recover: fatal region error detected; run recovery db_recover: unable to join the environment db_recover: unlink: var\openldap-data\__db.005: Permission denied db_recover: unlink: var\openldap-data\__db.004: Permission denied db_recover: unlink: var\openldap-data\__db.003: Permission denied db_recover: unlink: var\openldap-data\__db.002: Permission denied db_recover: unlink: var\openldap-data\__db.001: Permission denied db_recover: DB_ENV-open: DB_RUNRECOVERY: Fatal error, run database recovery Would you know why I'm getting all these errors? Am I using the wrong version of db_recover? Or is the home directory supposed to be different when running db_recover under the OpenLDAP folder? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Duplicate attributeType: 2.5.4.13
Samuel Tran wrote: Howard Chu wrote: Samuel Tran wrote: Hi All, I am currently testing OpenLDAP 2.3.4. After successfully building it I am now trying to configure slapd using the new style (http://www.openldap.org/doc/admin23/slapdconf2.html). However when I try to run: /usr/local/libexec/slapd -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d I get the following message: /etc/openldap/schema/core.schema: line 128: Duplicate attributeType: 2.5.4.13 Has anyone experienced the same problem? You appear to be using a core.schema file from OpenLDAP 2.2. That won't work, you have to use the 2.3 schema files with the 2.3 code. The core.schema I am using is the one from OpenLDAP 2.3.4. In the 2.3.4 file the definition of attribute 2.5.4.13 is commented out, because the definition is hard-coded. You can only receive a Duplicate attributeType error for 2.5.4.13 because you're using a core.schema file from an older release with the 2.3.4 code, or you have manually edited your 2.3.4 core.schema file (which you are never supposed to do). -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: olcDefaultSearchBase: value #0: olcDefaultSearchBase invalid DN 21 (Invalid syntax)
This appears to be a design flaw in back-config; it is trying to parse
that DN before it has loaded the core schema and so does not have the
dc definition yet. Please submit this information to the OpenLDAP ITS.
Samuel Tran wrote:
Hi All,
I am testing OpenLDAP 2.3.4 + Berkeley DB .4.2.52 on a Debian Sarge
server.
I successfully converted my slapd.conf to the new format slapd.d. I also
imported the latest dump from my production OpenLDAP server.
Now I am trying to start slapd using the new slapd.d:
/usr/local/libexec/slapd -F /etc/openldap/slapd.d -u ldap -d 255
I got the following error:
olcDefaultSearchBase: value #0: olcDefaultSearchBase invalid DN 21
(Invalid syntax)
I cannot find any information on this directive in the admin guide
(http://www.openldap.org/doc/admin23/slapdconf2.html)
In my slapd.conf file, I do have that directive set up:
defaultsearchbase dc=example,dc=com
I can successfully start slapd using slapd.conf.
Has anyone experienced this problem?
I would appreciate any help.
Thanks.
Sam
PS: below is the whole ouput when trying to start slapd
# /usr/local/libexec/slapd -F /etc/openldap/slapd.d -u ldap -d 255
@(#) $OpenLDAP: slapd 2.3.4 (Jul 21 2005 17:11:16) $
[EMAIL PROTECTED]:/usr/local/src/openldap-2.3.4/servers/slapd
daemon_init: null
daemon_init: listen on ldap:///
daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap:///)
daemon: IPv6 socket() failed errno=97 (Address family not supported by
protocol)
daemon: initialized ldap:///
daemon_init: 2 listeners opened
slapd init: initiated server.
slap_sasl_init: initialized!
bdb_back_initialize: initialize BDB backend
bdb_back_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December
3, 2003)
hdb_back_initialize: initialize HDB backend
hdb_back_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December
3, 2003)
backend_startup_one: starting cn=config
= str2entry: dn: cn=config
objectClass: olcGlobal
cn: config
olcConfigFile: slapd.conf
olcConfigDir: /etc/openldap/slapd.d
olcAllows: bind_v2
olcAuthzPolicy: none
olcConcurrency: 0
olcConnMaxPending: 100
olcConnMaxPendingAuth: 1000
olcDefaultSearchBase: dc=example,dc=com
olcGentleHUP: FALSE
olcIdleTimeout: 0
olcIndexSubstrIfMaxLen: 4
olcIndexSubstrIfMinLen: 2
olcIndexSubstrAnyLen: 4
olcIndexSubstrAnyStep: 2
olcLocalSSF: 71
olcLogLevel: Stats
olcPasswordHash: {SSHA}
olcPidFile: /var/tmp/slapd.pid
olcReadOnly: FALSE
olcReplicationInterval: 0
olcReverseLookup: FALSE
olcSaslSecProps: noplain,noanonymous
olcSockbufMaxIncoming: 524288
olcSockbufMaxIncomingAuth: 16777215
olcThreads: 16
olcTLSCRLCheck: none
olcTLSVerifyClient: never
structuralObjectClass: olcGlobal
dnPrettyNormal: cn=config
= ldap_bv2dn(cn=config,0)
ldap_err2string
= ldap_bv2dn(cn=config)=0 Success
= ldap_dn2bv(272)
ldap_err2string
= ldap_dn2bv(cn=config)=0 Success
= ldap_dn2bv(272)
ldap_err2string
= ldap_dn2bv(cn=config)=0 Success
dnPrettyNormal: cn=config, cn=config
= str2entry(cn=config) - 0x81977b8
= test_filter
PRESENT
= access_allowed: search access to cn=config objectClass requested
= root access granted
= test_filter 6
line 1 (slapd.conf)
line 1 (/etc/openldap/slapd.d)
line 1 (bind_v2)
line 1 (none)
line 1 (0)
line 1 (100)
line 1 (1000)
line 1 (dc=example,dc=com)
dnPrettyNormal: dc=example,dc=com
= ldap_bv2dn(dc=example,dc=com,0)
ldap_err2string
= ldap_bv2dn(dc=example,dc=com)=0 Success
ldap_err2string
olcDefaultSearchBase: value #0: olcDefaultSearchBase invalid DN 21
(Invalid syntax)
send_ldap_result: conn=-1 op=0 p=0
send_ldap_result: err=19 matched= text=
slapd destroy: freeing system resources.
slapd stopped.
connections_destroy: nothing to destroy.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://highlandsun.com/hyc
OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Problem finding telephonenumber in a plain numeric search when number is stored with special characters
Walter Kempel wrote: Teleponenumber:+41(61)26-71234 Searchfilter (telephonenumber=+41(61)26-71234) gave correct result Searchfilter (telephonenumber=41612671234) gave correct result Searchfilter (telephonenumber=41(61)26-71234) gave correct result Searchfilter (telephonenumber=+41(61)2671234) gave correct result It seems that Notes keeps all non-digit characters out of the telephonenumber index AND the search. How can I achieve the same under OpenLdap? Currently you can't. OpenLDAP's telephoneNumber syntax only strips the '-' characters out of the number for indexing. Perhaps you should file an ITS requesting that this be changed; it probably would be more useful to only preserve numeric digits in the index (and the matching). By the way, technically a number like +41 (61) x is not well formed; the parentheses are supposed to be omitted for international numbers: http://groups-beta.google.com/group/comp.std.internat/msg/24fc32228689a620?dmode=source -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: How does it handle 10k users and 3k desktops.
Andreas Hasenack wrote: That is, unfortunately, a common misconception. BDB is very powerful and has many buttons. Earlier OpenLDAP documentation did not emphasize enough the importance of these buttons, which lead to many incorrect deployments and data corruption. From the very beginning of OpenLDAP 2.1 releases we stated quite clearly that you need to read the Sleepycat documentation and understand it in order to get the best use of it. People who deployed incorrectly have only themselves to blame for not reading and following directions. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: slapd hangs doing large ldap (add|modify|delete)
There's a lot of good advice here. Just a couple notes... Buchan Milne wrote: If this is your level of experience with OpenLDAP, I would also hesitate. Please review all the relevant sections of the FAQ-o-matic, at minimum: - -do some DB_CONFIG tuning - -set up OpenLDAP caching (cachesize, idlcachesize) - -set up checkpointing, and consider running db_checkpoint (the correct version) as the user slapd is running as via cron or similar The use of db_checkpoint is unnecessary in OpenLDAP 2.3, an internal task will handle this automatically. - -ensure database recovery will run if ever slapd dies unexpectedly (power failure, hardware failure, OS failure, PECKAC) OpenLDAP 2.3 will perform recovery automatically; external startup scripts should not do anything here. For catastrophic failure, the automatic recovery will probably fail, but it would have required manual intervention regardless. - -deal with your transaction logs sanely This may require patching BerkeleyDB to get sane behavior. - -ensure you have some sane means of backups of your data in LDAP (either snapshots of the database and transaction logs, or slapcat the data as the user slapd runs as via cron or similar). slapcat in OpenLDAP 2.2.27 was fixed to prevent any writes/flushes/checkpoints from occurring. As such, it no longer makes any difference what user you run as, it will not accidentally change the ownership of any database files. (In older releases, slapcat performed a checkpoint before closing the database environment. If slapcat was running as root, and the checkpoint caused a new log file to be created, it would be created/owned by root, and other processes would be unable to write to the log. This was ITS#3703.) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Installing Openldap from a tarball
Quanah Gibson-Mount wrote: --On Wednesday, August 10, 2005 3:11 PM -0300 Luis Henrique Machado Jr. [EMAIL PROTECTED] wrote: Thx for you reply but i cant find the BerkeleyDB42.patch my ver of ldap is openldap-2.3.4 where i can find BerkeleyDB42.patch ?? http://www.stanford.edu/services/directory/openldap/configuration/bdb-build-42.html No need to go surfing the web; in OpenLDAP 2.3 the patch is in ./build/BerkeleyDB42.patch in the source tree. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: multiple databases (subordinate) and subschemaSubentry
Sebastian Guarino wrote: Oops. I haven't tried the same rootdn without password on the subordinate suffix. Thanks, it worked. Note that the slapd.conf(5) manpage says explicitly that all subordinate DBs should have the same rootdn as the parent DB. We write these things for a reason... Sebastian Guarino. Michael Eichenberger wrote: Hi Sebastian I've got more or less the same setup, but I've got the same rootdn for all the backend's and the rootpw is only mentioned once (the last database definition). I then access the databases with different users, working with ACL's. See the end of the mail for my example setup. I have a configuration with two databases like this (one inside the other) databasebdb subordinate suffix ou=other,o=org,c=ar rootdn cn=Manager,ou=other,c=org,c=ar rootpw secret directory /var/db/openldap-data/other lastmod on databasebdb suffix o=org,c=ar rootdn cn=Manager,o=org,c=ar rootpw pepe00 directory /var/db/openldap-data lastmod on When I activate the first database (the subordinate one) then I can't search the subschemaSubentry. (0 entries) The schemas can only be searched if I bind with the manager password of the subordinate suffix and not the one from the upper suffix. # # ou=administration,o=stepping-stone,c=ch # databasehdb suffix ou=administration,o=stepping-stone,c=ch rootdn cn=Manager,o=stepping-stone,c=ch subordinate directory /var/lib/openldap-hdb/stepping-stone/administration index objectClass pres,eq index entryUUID eq access to dn.regex=cn=(.+),ou=people,ou=administration,o=stepping-stone,c=ch$ attr=userpassword by dn.regex=cn=$1,ou=people,ou=administration,o=stepping-stone,c=ch write by anonymous auth by * none # # ou=storage,ou=service,o=stepping-stone,c=ch # databasehdb suffix ou=storage,ou=service,o=stepping-stone,c=ch rootdn cn=Manager,o=stepping-stone,c=ch subordinate directory /var/lib/openldap-hdb/stepping-stone/service/storage index objectClass pres,eq index cn,uid eq index entryUUID eq index uidNumber eq index gidNumber eq access to dn.subtree=ou=storage,ou=service,o=stepping-stone,c=ch by group/groupOfUniqueNames/uniqueMember=cn=storage,ou=group,ou=administration,o=stepping-stone,c=ch read ### # MAIN TREE ### databasehdb suffix o=stepping-stone,c=ch rootdn cn=Manager,o=stepping-stone,c=ch rootpw gugus directory /var/lib/openldap-hdb/stepping-stone I know, it doesn't really answer your question, but it works. Kind regards, Michael -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: syncrepl w/ 2.3 and bdb 4.3 working great
Dusty Doris wrote: I uncomment DB_TXT_NOSYNC when doing the original slapadd - then comment it back when I start for the first time. This causes slapd to run db_recover automatically to update the BDB environment and re-enable logging. DB_CONFIG (all servers) set_cachesize 0 536870912 1 set_lg_regionmax 1048576 set_lg_bsize 2097152 set_lg_max 10485760 set_flags DB_LOG_AUTOREMOVE #set_flags DB_TXN_NOSYNC With OpenLDAP 2.3.5 you could use slapadd -q and forget about editing DB_CONFIG. Of course with -q transactions are totally disabled, so if the slapadd is interrupted you will not be able to db_recover it; if you're doing a lot of incremental slapadds over a course of time you probably shouldn't risk -q... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: problem with sasl and openldap
Jesus Bernardo Ruiz Flores wrote: Hi, i'm using openldap 2.2.28 with cyrus-sasl-2.1.21, in a redhat as4 I have compiled the sasl support with my openldap software and ldapdb support in the cyrus-sasl. When I start the openldap server i get the following error in auth.log: Aug 16 14:52:38 mail slapd[7437]: auxpropfunc error invalid parameter supplied Aug 16 14:52:38 mail slapd[7437]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb and this error in the syslog: Aug 16 15:11:50 mail slapd[12214]: auxpropfunc error invalid parameter supplied This error is meaningless in slapd, as slapd doesn't use ldapdb. See the SASL docs (options.html); it specifically says the ldapdb plugin is not for use with slapd. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Problem with Password Policy Overlay - Password Reset
Shawn McKinney wrote: Running version 2.3.4 on Linux - RHE4. 2.3.5 has been released, and there are 2-3 minor fixes to ppolicy included. You should upgrade. Experimenting with PPolicy Overlay features. Password reset usage question: Is it OK for applications to modify user operational attribute pwdReset? Yes. When I set user's pwdReset flag to true, user can't authenticate, exception returned: Operations are restricted to bind/unbind/abandon/StartTLS/modify password; Insufficient access This is fine as user's password has been reset and they will need to change it. What do you mean by user can't authenticate ? Certainly they should still be able to Bind. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: substring index oddity
John Madden wrote: uid=*0371* dn # numResponses: 125 # numEntries: 124 real0m0.052s Further research on the allidsthreshold concept mentioned in the old list thread lead me to SLAPD_LDBM_MIN_MAXIDS, which, at 8192-4, is likely too low for a million objects that were created sequentially. Unfortunately, I'm running Debian for a reason -- going back to compiling from source (as I do now) is a last resort. (Since I'm using bdb, is the #define even relevant?) No. Nothing about LDBM has any relevance to back-bdb. The, uh, good news is that the numEntries I'm seeing for the bad query is far below 8188, just . So perhaps this isn't an allids problem? For reference, the searches with numEntries: uid=*222* : 29 seconds # numEntries: 3700 As already noted, by default a substring term must have at least 4 characters in order for indexing to have any effect. uid=*222 : 0.063 seconds # numEntries: 1000 uid=*2*22 : 0.14 seconds # numEntries: 3439 And then, just for fun I did: uid=*2 : 29 seconds # numEntries: 10 subinitial and subfinal default to a minimum of two characters, so this search didn't use the index either. uid=*22 : 0.41 seconds # numEntries: 1 ...So 10,000 entries can be returned off an index search, well over the 8188. Is there another allids-like limit someplace? There is something like that limit, the default is around 131072 in back-bdb (131072 in memory, 65536 for the on-disk index slots) but it doesn't quite mean the same as allids meant in back-ldbm. That is, when back-ldbm hit its limit, it would return ALLIDS which literally meant all entries in the database. When back-bdb gets to this limit, it turns into a range. The range has a low end at the first/lowest of the ~131,000 IDs, and a high end at the last/highest of the ~131,000 IDs. Once you get into operating as a range, you may get degraded performance, but not quite as bad as back-ldbm. That is, the performance degrades dependong on how discontiguous the original list of IDs was. If they were all contiguous, then there is no degradation. If there were large gaps in the ID list, then performance degrades. e.g., if the threshold for converting to a range was only 4 IDs, and you had the list 1,2,3,4: when you add ID 5 to the list and get the range 1-5, there is no performance penalty. But if you had the list 1,6,10,15 and add the ID 20 to the list and get the range 1-20, then performance suffers because the search will be examining 20 entries instead of just 5. It's still better than examining every entry in the DB, the way back-ldbm does, but people running larger DBs probably still should increase these limits. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: substring index oddity
John Madden wrote: Good. More testing shows much better results in light of that info and I can probably live with that design. However, I'm still seeing a bad case: uid=test* : 28 seconds # numEntries: 111 uid=test2* : 28 seconds # numEntries: 11 This is ITS#2588, fixed in OpenLDAP 2.3. The fix is also in the version of OpenLDAP 2.2 packaged by Symas in our CDS products. Using vendor-supplied software instead of compiling your own is OK, as long as you choose the right vendor to supply the packages. ;) Bad, even though there are more than 4 chars in the string. Yet: uid=test* : 0.007 seconds # numEntries: 100 uid=*est222* : 0.048s # numEntries: Quite good. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: new slapd.d configuration format and Invalid DN syntax (34)
Samuel Tran wrote: On Fri, 2005-08-26 at 11:25 -0400, Samuel Tran wrote: Hi all, I am testing OL 2.3.6 + BerkeleyDB 4.2.52 on Debian Sarge boxes. I am a little bit confused on the new slapd.d configuration format. I have a slapd.conf file that is working with my setup. I converted it to the new slapd.d format using this command: /usr/local/libexec/slapd -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d I re-started slapd using slapd.d: /usr/local/libexec/slapd -d 255 -u ldap -F /etc/openldap/slapd.d -4 Any hints? You're running slapd as -u ldap but you didn't specify that when converting the config format. Are the permissions in slapd.d correct? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: slapcat or ldapsearch could not return complete query result
Note that ITS#3764 and #3703 are relevant here, both fixed in 2.2.27. You should really be running the latest release, 2.2.28 (or 2.3.6). With the fixes for these two ITS's it should be completely safe to run slapcat concurrently with slapd. Ran Li wrote: Hi Quanah, Thanks for following my issue, I sincerely appreciate your effort, I appologize I did not pay attention to the -h option, after running that everything works fine, now I can get the output. I m not sure if the reason was I ran slapcat when slapd was running, but I will avoid this kind of usage and see if the same issue will come up in the future. Thanks again. Regards, -ran -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Quanah Gibson-Mount Sent: Friday, August 26, 2005 3:54 PM To: OpenLDAP-software@OpenLDAP.org Subject: Re: slapcat or ldapsearch could not return complete query result --On Friday, August 26, 2005 3:19 PM -0400 Ran Li [EMAIL PROTECTED] wrote: Hello List, when I ran slapcat (w/ or w/o slapd), it would not return the complete ldif file, and it just hung. If I do ldapsearch for one entry, in a few cases it will give the complete result but most of the time it won't, and it will hang up. slapd log or system log does not say anything. Ran db_recover after stopped slapd, it did not have any output but generated a log.00xx file. Could any one give a clue to start troubleshooting. Thanks. Did you run db_recover -h /path/to/your/database ? Like db_recover -h /db Do you have a DB_CONFIG file? --Quanah -- Quanah Gibson-Mount Principal Software Developer ITSS/Shared Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html These censorship operations against schools and libraries are stronger than ever in the present religio-political climate. They often focus on fantasy and sf books, which foster that deadly enemy to bigotry and blind faith, the imagination. -- Ursula K. Le Guin -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: new slapd.d configuration format and Invalid DN syntax (34)
Quanah Gibson-Mount wrote: --On Friday, August 26, 2005 4:07 PM -0400 Samuel Tran [EMAIL PROTECTED] wrote: The debugging output is actually the result of my ldapsearch: /usr/local/bin/ldapsearch -LLL -x -H ldap://localhost -b dc=example,dc=com Sorry about the confusion. Any hints? Is your database configured to hold dc=example,dc=com ? This question is irrelevant; a misconfigured database suffix would not return an LDAP Syntax error on a search. The only reason to get the syntax error is because the dc attribute is not recognized, which would only happen if the configuration were not read in properly, which is why I asked if the permissions on slapd.d were correct. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: new slapd.d configuration format and Invalid DN syntax (34)
Ah, you still have defaultSearchBase in cn=config, and it is preventing
the rest of the config from being built correctly. I thought I had
removed this from cn=config when I moved the attribute to the Frontend
object, but apparently it's also still present in the cn=config entry.
We'll fix this in the 2.3.7 release.
Samuel Tran wrote:
Here is the full output:
sudo /usr/local/libexec/slapd -d 255 -u ldap -F /etc/openldap/slapd.d -4
[?1h=[57;1H[K@(#) $OpenLDAP: slapd 2.3.6 (Aug 24 2005 12:46:47) $
[EMAIL PROTECTED]:/usr/local/src/openldap-2.3.6/servers/slapd
daemon_init: null
daemon_init: listen on ldap:///
daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap:///)
daemon: initialized ldap:///
daemon_init: 1 listeners opened
slapd init: initiated server.
slap_sasl_init: initialized!
bdb_back_initialize: initialize BDB backend
bdb_back_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December 3,
2003)
hdb_back_initialize: initialize HDB backend
hdb_back_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December 3,
2003)
backend_startup_one: starting cn=config
= str2entry: dn: cn=config
objectClass: olcGlobal
cn: config
olcConfigFile: /etc/openldap/slapd.conf
olcConfigDir: /etc/openldap/slapd.d
olcAllows: bind_v2
olcAuthzPolicy: none
olcConcurrency: 0
olcConnMaxPending: 100
olcConnMaxPendingAuth: 1000
olcDefaultSearchBase: dc=example,dc=com
olcGentleHUP: FALSE
olcIdleTimeout: 0
olcIndexSubstrIfMaxLen: 4
olcIndexSubstrIfMinLen: 2
olcIndexSubstrAnyLen: 4
olcIndexSubstrAnyStep: 2
olcLocalSSF: 71
olcLogLevel: Any
olcPasswordHash: {SSHA}
olcPidFile: /var/tmp/slapd.pid
olcReadOnly: FALSE
olcReplicationInterval: 0
olcReverseLookup: FALSE
olcSaslSecProps: noplain,noanonymous
olcSizeLimit: 5000
olcSockbufMaxIncoming: 524288
olcSockbufMaxIncomingAuth: 16777215
olcThreads: 16
olcTLSCACertificateFile: /etc/openldap/certs/cacert.pem
olcTLSCRLCheck: none
olcTLSVerifyClient: never
structuralObjectClass: olcGlobal
dnPrettyNormal: cn=config
= ldap_bv2dn(cn=config,0)
ldap_err2string
= ldap_bv2dn(cn=config)=0 Success
= ldap_dn2bv(272)
ldap_err2string
= ldap_dn2bv(cn=config)=0 Success
= ldap_dn2bv(272)
ldap_err2string
= ldap_dn2bv(cn=config)=0 Success
dnPrettyNormal: cn=config, cn=config
= str2entry(cn=config) - 0x81c5560
= test_filter
PRESENT
= access_allowed: search access to cn=config objectClass requested
= root access granted
= access_allowed: search access granted by manage(=mwrscxd)
= test_filter 6
line 1 (/etc/openldap/slapd.conf)
line 1 (/etc/openldap/slapd.d)
line 1 (bind_v2)
line 1 (none)
line 1 (0)
line 1 (100)
line 1 (1000)
line 1 (dc=example,dc=com)
dnPrettyNormal: dc=example,dc=com
= ldap_bv2dn(dc=example,dc=com,0)
ldap_err2string
= ldap_bv2dn(dc=example,dc=com)=0 Success
ldap_err2string
olcDefaultSearchBase: value #0: olcDefaultSearchBase invalid DN 21
(Invalid syntax)
= str2entry: dn: cn=include{0}
objectClass: olcIncludeFile
cn: include{0}
olcInclude: /etc/openldap/schema/core.schema
structuralObjectClass: olcIncludeFile
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://highlandsun.com/hyc
OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: new slapd.d configuration format and Invalid DN syntax (34)
This is fixed in CVS slapd/bconfig.c, latest revision in HEAD and
OPENLDAP_REL_ENG_2_3.
Samuel Tran wrote:
Here is the full output:
sudo /usr/local/libexec/slapd -d 255 -u ldap -F /etc/openldap/slapd.d -4
[?1h=[57;1H[K@(#) $OpenLDAP: slapd 2.3.6 (Aug 24 2005 12:46:47) $
[EMAIL PROTECTED]:/usr/local/src/openldap-2.3.6/servers/slapd
daemon_init: null
daemon_init: listen on ldap:///
daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap:///)
daemon: initialized ldap:///
daemon_init: 1 listeners opened
slapd init: initiated server.
slap_sasl_init: initialized!
bdb_back_initialize: initialize BDB backend
bdb_back_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December 3,
2003)
hdb_back_initialize: initialize HDB backend
hdb_back_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December 3,
2003)
backend_startup_one: starting cn=config
= str2entry: dn: cn=config
objectClass: olcGlobal
cn: config
olcConfigFile: /etc/openldap/slapd.conf
olcConfigDir: /etc/openldap/slapd.d
olcAllows: bind_v2
olcAuthzPolicy: none
olcConcurrency: 0
olcConnMaxPending: 100
olcConnMaxPendingAuth: 1000
olcDefaultSearchBase: dc=example,dc=com
olcGentleHUP: FALSE
olcIdleTimeout: 0
olcIndexSubstrIfMaxLen: 4
olcIndexSubstrIfMinLen: 2
olcIndexSubstrAnyLen: 4
olcIndexSubstrAnyStep: 2
olcLocalSSF: 71
olcLogLevel: Any
olcPasswordHash: {SSHA}
olcPidFile: /var/tmp/slapd.pid
olcReadOnly: FALSE
olcReplicationInterval: 0
olcReverseLookup: FALSE
olcSaslSecProps: noplain,noanonymous
olcSizeLimit: 5000
olcSockbufMaxIncoming: 524288
olcSockbufMaxIncomingAuth: 16777215
olcThreads: 16
olcTLSCACertificateFile: /etc/openldap/certs/cacert.pem
olcTLSCRLCheck: none
olcTLSVerifyClient: never
structuralObjectClass: olcGlobal
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://highlandsun.com/hyc
OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: threads v. concurrency?
Ben Beuchler wrote: While threads seems pretty clearly to be the hard limit on the maximum number of slapd threads that will be spawned, how does concurrency relate? Any good rules-of-thumb for how it should be set? concurrency is relevant on systems with M:N threads implementations, and controls how many application threads to assign per kernel thread/lightweight process. (Like new Solaris, old LinuxThreads.) It doesn't really have any effect on e.g. NPTL (which is a 1:1 threads model). Usually you can leave it alone; on an M:N model you could set it to the number of available CPUs. This is very general advice, you need to look at what pthread_set_concurrency really means on your platform (assuming you're using POSIX threads). -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: OL 2.3.x, uid attribute commented out in core.schema
Pierangelo Masarati wrote: Come to think of it, maybe slapd should accept schema redefinitions that are identical to an existing definition? Then hard-coded definitions could be left in in place in the schema files, and new slapds would not conflict with old schemas. Except, I'm not quite sure if it's a feature or a misfeature that one must update core.schema when slapd is updated... This is what back-config does: it (silently?) discards schema redefinitions that are identical to existing ones. I think this only occurs for internal schema (i.e. those that define the configuration stuff). Maybe the same could occur for schema items that are read and match builtin ones, so that (for completeness) core.schema and similar can be complete and consistent with the related specs... I bet Howard will reply that core.schema is now replaced by core.ldif... ;) Not yet, but probably soon ;) back-config collects all hard-coded schema definitions into the cn=schema object. It saves this object only for completeness' sake, and completely ignores updates to this object. There is no special treatment for definitions loaded from core.schema or cn=core,cn=schema - if an element added here has already been defined in cn=schema, it will fail. I guess we could make an exception such that if a user-loaded definition is identical to a hard-coded definition, it is silently ignored. If that's really the desired behavior, someone should file an enhancement request. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Question pertaining to PPolicy overlay feature
In revision 1.58 I updated the operational attribute schema to match draft 9 of the password policy specification; it makes a number of attributes non-user-modifiable, including pwdAccountLockedTime. We may have to back out a couple more of these changes if there is no internal mechanism to alter these attributes. I'll raise this question on the ldapext mailing list and see what answers we get. Shawn McKinney wrote: To reset a user's LDAP account that has been locked due maxFailure bind failures, my client program performs the following steps: On the user entry that is locked: set userPassword = to a new password value set pwdReset = TRUE delete pwdLockedTime operational attribute Testing w/ version 1.56 ppolicy module the above steps work flawlessly. The user must change password on subsequent bind per PW policy setting. But when I upgrade to latest version of ppolicy module, 1.60, I get constraint violation when I attempt removal of user's pwdLockedTime attribute. My question is, for situations when the user account is locked, how do we reset the user account programatically? I have found leaving the pwdReset flag alone will not unlock the user's account. Thanks, Shawn -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: back-meta (Was: (ITS#3971) slapo-glue dissolving after one query)
Perry Nguyen wrote: Ando, Being able to customize the timeout is handy and all, but my main interest is in why JNDI behaves strangely with back-meta and back-ldap, slapd keeps returning no results whenever the query comes from a Java JNDI client. My primary interest with this (problem) is to be able to use a back-meta or back-ldap proxied directory with a java JNDI client. Have you had a chance to look into why the behavior is different with JNDI and the back-meta/ldap setups?. You'll get better answers sooner by investigating this yourself. Turn up debugging on slapd, perform a query using the ldapsearch command line tool, and then perform the same query using your JNDI client. Then it should be pretty easy to spot any differences in behavior. You can point us at the debug logs resulting from this test, but don't expect the project developers to attempt to recreate your test environment (including writing a test client in Java with JNDI) just to see what you're talking about. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Question pertaining to PPolicy overlay feature
Shawn McKinney wrote: Thanks. I would like to make one correction to my earlier post that stated: My question is, for situations when the user account is locked, how do we reset the user account programatically? I have found leaving the pwdReset flag alone will not unlock the user's account. What I intended to say was leaving the pwdlockedTime flag untouched will leave the user's account in a locked state. The current revision in CVS HEAD makes the pwdAccountLockedTime user modifiable again (undoing the draft-9 change for now) and also deletes the attribute automatically when the password is changed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Glue, relay, chain, rwm, meta - which one?
Mitya wrote: Hi all, Our OpenLDAP deployment serves multible bases (suffixes). dc=ourcompany,dc=ru ou=People cn=john dc=ourclient1,dc=ru ou=People cn=jim dc=ourclient2,dc=com ... dc=ourclient3,dc=net ... We are on a way of integration of most our services with LDAP. Modern software like Jabberd2 can derive base DN from username. For example, when JID = [EMAIL PROTECTED] logs on, Jabber server takes ourclient1.ru, looks up the appropriate base DN in its config file, gets dn=dc=ourclient1,dc=ru, searches this base for an entry with uid == somebody, and rebinds with dn=cn=Somebody,ou=People,dc=ourclient1,dc=ru, thus making possible LDAP authentication against multiple base DNs (important!) Legacy software like Courier mail server is not aware of multiple base DNs. In order to make use of LDAP authentication in Courier, we introduce ou=Domains,dc=ourcompany,dc=ru, and try to make all other suffixes available under this DN. Like this: First of all, the best solution here is to use SASL binds. The LDAP client just sends the username [EMAIL PROTECTED] to the LDAP server and the details of how the username are matched to a user entry are entirely managed by the LDAP server. I'm surprised you refer to Courier as a legacy system since it appears that it is still a pretty active open source project. Any LDAP-enabled software that claims to support LDAPv3 should support SASL binds (since SASL binds are a mandatory-to-implement feature of LDAPv3)... dc=ourcompany,dc=ru ou=People cn=john cn=... ou=Domains dc=ourclient1,dc=ru ou=People cn=jim The scheme needs not be exactly like the above. We just want cn=jim,ou=People,dc=ourclient1,dc=ru and others to be returned when ldapsearch'ing -b ou=Domains,dc=ourcompany,dc=ru -s sub (objectClass=person). I will ask you please to help me choose the appropriate combination of OpenLDAP mechanisms to accomplish this. Once I thought that putting referrals to ou=Domains,dc=ourcompany,dc=ru and making slapd chase them internally with slapo-chain will help. But now I see that slapo-chain (as of 2.3.6) is deprecated, moved to back_ldap, and controlled by some LDAP_CONTROL_X_CHAINING_BEHAVIOR, and enabled only in devel builds. Is there any way to enforce server-side chaining, like it was in = 2.3.4? (In this case we just have to process referrals internally, because we cannot rely on referral handling on client-side - in most cases client software like Courier or Apache is not aware of referrals, and ignores them.) slapo-chain is not deprecated. It was originally a component of back-ldap and has always depended on back-ldap's code for its own functionality. It was split out on its own for a while, and we decided that it was better to leave it in back-ldap where it was originally developed. It is not LDAP_DEVEL only, it is automatically enabled whenever back-ldap is enabled. Of course, referrals and chaining are probably the worst-performing way to accomplish what you want. Seems like any other way will lead to additional database (of type relay, ldap or meta) per served suffix. Or maybe slapo-glue or slapo-rwm will help here? Glueing subordinates is an obvious approach. (Note that early 2.3 releases changed the glue syntax from the one used in OpenLDAP 2.1-2.2. The current 2.3.7 release restores the old syntax, and slapo-glue is no longer a separate module. It is integrated back into the slapd core, just like it was in OpenLDAP 2.1 and 2.2.) The relay database would be a good alternative. Either one should work well for this situation. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Question pertaining to PPolicy overlay feature
Shawn McKinney wrote: --- Howard Chu [EMAIL PROTECTED] wrote: The current revision in CVS HEAD makes the pwdAccountLockedTime user modifiable again (undoing the draft-9 change for now) and also deletes the attribute automatically when the password is changed. I've verified that version 1.62 behaves in the manner described above. But, I am not sure which way to proceed - 1. remove the pwdAccountLockedTime attribute w/ client or 2. leave the attribute alone, let the ppolicy overlay modify it. Any recommendations? Right now both ways work. Both ways are intended to work, because there are really two separate use cases. In one case, it should be possible to reset the locked status of an account without requiring the password to be changed at the same time. This would be a situation e.g. where a third party tried unsuccessfully to guess the user's password, causing the account to get locked. The user still knows the password, and the password's integrity has not been violated, so the user ought to be allowed to continue to use it. (There is of course a side issue of tracking down the third party and putting a stop to whatever they're doing, but that's a separate discussion...) The other case is where the user forgot their own password and got the account locked while trying to recall the password. In that case, just resetting the password ought to be sufficient to restore the account to usefulness. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Intermittent hang/deadlock when iterating through LDAP search results using JLDAP
Jon Roberts wrote: I would like to take this opportunity to point out that the above-cited issues were reported over a year ago and have languished in ITS with OPEN status since then. I also wish to add that my own batting average is pretty low: I have submitted 3 JLDAP patches, each with unencouraging outcomes. The first (#3102) was inexplicably misapplied, leading to #3202 (fixed in CVS by June 2004 but only recently closed in ITS). The second (#3728) has been unregarded since its submission last May. Finally there's my most recent attempt to contribute (#3911), which is critical to enabling JLDAP to be compiled under Java v1.5 (it currently fails). This issue was successfully submitted Aug 1 and has now COMPLETELY DISAPPEARED FROM ITS! Thanks. Disappeared? http://www.openldap.org/its/index.cgi/Software%20Bugs?id=3911 Perhaps it should have been filed in Contrib with the rest of the JLDAP reports, but it hasn't disappeared. Jon Roberts www.mentata.com ... forthwith donning my flame-retardant assflaps Speaking as a C programmer, I can only say somebody needs to get their act together. I don't know who that somebody is though. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Alias dereferencing
Hallvard B Furuseth wrote: No, that text is about the alias entry, not the entry which the alias points at. This sounds like an OpenLDAP bug. Look a few paragraphs above in the models draft: The conversion of an alias name to an object name is termed (alias) dereferencing and comprises the systematic replacement of alias names, where found within a purported name, by the value of the corresponding 'aliasedObjectName' attribute. The process may require the examination of more than one alias entry. Note that replacement is not just done when the name itself is an alias, but also with aliases within the name. Hm, looks like you're right. This can easily be fixed in back-bdb, someone should file an ITS. The other issue is, that it also doesn't seem possible to resolve aliases pointing at entries in a different backend ...and that's an old limitation in OpenLDAP, which if I understand correctly it would be quite a bit of work to fix. It is not a limitation per se, but a conscious design choice. Alias behavior in LDAP (as specified in RFC2251) adopts the definition in X.501. Accordingly, the aliasedObjectName attrbiute may only contain a DN. The DN does not have to point to an object that exists, but if it is to be dereferenced successfully it obviously must point to an entry within the DIT. Since there is no URI info attached, (unlike a referral) it obviously cannot point to an entry stored in some other DIT on some other server; it must point to a location within the same naming context as the alias entry itself. Note that by default, slapd treats separate backends as separate DSAs with totally independent DITs. (This is the design choice I was referring to.) Therefore, since those DITs are independent, aliases may only be resolved within the same backend. Once again - not enough information has been presented re: why this particular approach is needed. Most sites should only need a single DIT, and thus a single backend. And sites that need to isolate data into separate DITs generally don't need to transparently refer to one DIT from another. Now, if I'd want to implement this, i.e. to a) transparently handle aliases It would be a mistake to implement (a) since you'll have no way to specify when you want to Modify the alias entry itself, vs what the alias points to. No need, since subordinates of aliases are not needed, just aliases pointing at non-leaf entries. Well, this particular discussion is moot, since dereferencing is only defined for Search operations. E.g., see RFC2251 section 4.6, Modify Operation: Parameters of the Modify Request are: - object: The object to be modified. The value of this field contains the DN of the entry to be modified. The server will not perform any alias dereferencing in determining the object to be modified. So implementing this feature would be a direct violation of the LDAP specification. and b) support references to other backends. It would be a mistake to implement (b); that is already the purpose of referrals. It might be a mistake because of the mess I described above, but as far as I can tell not because of referrals. draft-ietf-ldapbis-protocol-xx.txt defines referrals to be for references to _other_ servers. A server referring to itself seems to be abuse of referrals, at least as far as the standard is concerned. No, you're just using sloppy terminology. Referrals point to information in other DSAs. Each backend in slapd is its own DSA, so referrals are precisely the correct feature needed to implement these references. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: requesting clarification of use of config backend
For docs, see http://www.openldap.org/doc/admin23/slapdconf2.html It is redundant to list the rootdn in any ACL clause; the rootdn always has full privileges and ignores all ACLs. Listing the rootdn merely makes ACL evaluation slower for regular users. The order of directives in your slapd.conf snippets is wrong. The rootdn directive must follow the relevant database directive if you want it to apply to a particular database. The config database currently does not honor ACLs; it is hardcoded to only allow access to the rootdn. There is an outstanding bug in 2.3.7 related to quoting/escaping values in config directives. This bug has been fixed in HEAD. (ITS#3807) It's likely that this bug will cause your ACL definitions to be parsed incorrectly. You can pull the latest version of slapd/bconfig.c and slapd/config.c from CVS to test. Brian Reichert wrote: I've recently begun to explore the config backend for OpenLDAP 2.3.7, and and running into what appears to be an ACL issue, but I can't figure out what I've done wrong, nor how to explore further. What I think are pertinent snippets from my slapd.conf: rootdn cn=manager,com=foo database config defaultaccess none access to dn.subtree=cn=config by dn.exact=cn=manager,com=foo write by * read I created my slapd.d directory: # mkdir -p /etc/openldap/slapd.d # slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d # mv /etc/openldap/slapd.conf /etc/openldap/slapd.conf.test # chown -R ldap:ldap /etc/openldap/slapd.d/ slapd.d does seem to be fully populated, and slapd was successfully restarted. But, when I attempt to search this database: # ldapsearch -x -LLL -D cn=manager,com=foo -w foobar \ -b cn=config /var/tmp/ldif.out Insufficient access (50) Does anyone see anything obviously wrong here? I had several databases with identical ACLs, which I can search, so I know I have my credentials right. Running the server and ldapsearch with '-d -1' doesn't reveal anything like UNIX permission errors. Alas, I could not find a manpage for slapd.d, nor slapd-config, so I'm running blind, here... I'd appreciate any feedback you folks can provide. -- Brian Reichert [EMAIL PROTECTED] 55 Crystal Ave. #286Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Syncrepl does not copy operational attributes?
Dave Horsfall wrote: On Tue, 13 Sep 2005, Howard Chu wrote: createTimestamp creatorsName modifiersName modifyTimestamp [...] Depends on your syncrepl consumer configuration, since you explicitly specify which attributes to replicate there. So attrs=* replicates the operational attributes structuralObjectClass, entryCSN and entryUUID, but not the above? That would be...odd... That being the case, would I need something like; attrs=*,createTimestamp,creatorsName,modifiersName,modifyTimestamp ? Syncrepl uses a regular ldapsearch operation to do its work. The attrs specifier is identical to what you use for ldapsearch. If you want all the operational attributes, use +. Note that syncrepl uses attrs=*,+ by default so if you just want all attributes, you should just use the default and not bother configuring attrs= at all. syncrepl also automatically adds entryUUID and entryCSN to the request if your explicit list doesn't include them, since it won't work without them. That's why they always propagate automatically. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Open LDAP performance tuning
Moe wrote: Is using db_config essential or can i just due the performance tuning through slapd.conf? From http://www.openldap.org/faq/data/cache/893.html A number of important items must be configured in the BDB DB_CONFIG file and not in slapd.conf. Notice the word must. Of course in OpenLDAP 2.3 your question is somewhat meaningless since a slapd.conf keyword has been added for controlling settings in DB_CONFIG. (See the slapd-bdb(5) manpage in OpenLDAP 2.3) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: case sensitivity in DN component attribute
Ben Poliakoff wrote: Assuming I've described the symptoms clearly enough (and I likely haven't), is this behavior a bug or is it just a demonstration of the kind of trouble that can occur with casual schema file modification? One should never casually modify schema definitions. back-bdb now stores the normalized attributes in the database, rather than normalizing repeatedly upon reading the database. If you change the case of schema definitions in between storing and reading an entry, and change the case of the attribute's canonical name, the copy in the database will no longer match the schema definition in memory. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: OL 2.3.7, ppolicy, how to unlock account?
Samuel Tran wrote: Hi all, I am testing the password policy in OL 2.3.7 on a Debian Linux Sarge server. I managed to lock an account after intentionally binding with a wrong password 3 times. Now how can I unlock the account? I looked at the man page for slapo-ppolicy and the draft-behera-ldap-password-policy-xx.txt file. But couldn't find anything. Between 2.3.6 and 2.3.7 I made a schema change to follow draft-09 of the password policy spec. It appears this was a bad idea, as it prevents you from deleting the pwdAccountLockedTime attribute. (In the development source, you can use the ManageDIT control to accomplish it, but this control wasn't enabled in the Release code.) If you grab the current ppolicy.c from CVS HEAD this problem is fixed, some of the draft-09 schema changes are undone so that you can still manipulate these attributes. Also with the version in CVS, resetting the password automatically unlocks the account. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: 2.3.7 build problems (libtool?)
Mitya wrote:
Starting test028-idassert ...
running defines.sh
### This test requires the ldap backend.
### If available, and explicitly requested, it can use SASL bind;
### note that SASL must be properly set up, and the requested
### mechanism must be available. Define SLAPD_USE_SASL={yes|mech},
### with yes defaulting to DIGEST-MD5 to enable SASL authc[/authz].
Using proxyAuthz with simple authc...
Running slapadd to build slapd database...
/home/mitya/openldap-2.3.7/servers/slapd/.libs/lt-slapd: symbol lookup
error: ../servers/slapd/overlays/.libs/rwm-2.3.so.0: undefined symbol:
rewrite_info_init
slapadd -n 1 failed (127)!
./scripts/test028-idassert failed (exit 127)
Since librewrite is static-only now, and build process somehow uses
old-style linking, symbols for librewrite (and for liblutil) stay
unresolved in rwm-2.3.so.0.
This should be fixed now in HEAD, try applying the patch in
slapd/saslauthz.c -r1.158 to your source.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://highlandsun.com/hyc
OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Being a consumer and a provider for the same database (toward different servers) ?
[EMAIL PROTECTED] wrote: So the question is : --- I don't know if in slapd.conf, under a same database I can put entries for being a supplier and a consumer ? Yes. See test019 in the self test suite, it tests this type of configuration. Main server : database bdb suffix ou=subsidiary_i,o=my-company rootdn o=my-company directory /var/ldap/db/subsidiary_i index objectclass,entryCSN,entryUUID eq # Be a consummer for subsidiary_i syncrepl rid=123 provider=ldap://subsidiary_i.ldap_server.com:389 type=refreshOnly interval=01:00:00:00 searchbase=ou=subsidiary_i,o=my-company filter=(objectClass=*) scope=sub ... # Be a provider for subsidiary_j and j i for j=1 to 111 overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 Thanks a lot for anwsers. [EMAIL PROTECTED] with the suffix o=my-company -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: No entries in Accesslog
[EMAIL PROTECTED] wrote: Hi, I'm trying to get the slapo-accesslog overlay to work, but it doesn't seem to fill up with any entries. I'm using OL2.3.7 + BDB4.2.52 + 4 official + OL transactions Patch. The relevant part of my slapd.conf looks like this: # accesslog db database bdb suffix cn=accesslog rootdn cn=root,cn=accesslog rootpw cleartext pass directory /var/lib/ldap/openldap-accesslog index reqStart eq # db with actual data database bdb suffix dc=o2online,dc=de rootdn cn=root,dc=o2online,dc=de rootpw hashed ;) directory /var/lib/ldap/openldap-data overlay accesslog logdb cn=accesslog logops all logpurge 30+00:00 01+:00:00 index objectclass eq ... other indices, uniqueness overlay, etc ... When I issue an ldapsearch -b dc=o2online,dc=de -D uid=myuid,ou=People,dc=o2online,dc=de -h ldap://ldaphost -W -x -ZZ objectclass=* I get all the results I'm supposed to get from the directory server. Issueing an ldapsearch -b cn=accesslog -D cn=root,cn=accesslog -W -x -ZZ -H ldap://ldaphost objectlass=* returns a result: 32 No such object Probably I'm missing something or it's simply not in the documentation. The slapd log with loglevel -1 contains the following after starting up and issueing the ldapsearch on cn=accesslog: Sep 23 14:22:45 sgmldap02 slapd[23385]: = bdb_search Sep 23 14:22:45 sgmldap02 slapd[23385]: bdb_dn2entry(cn=accesslog) Sep 23 14:22:45 sgmldap02 slapd[23385]: = bdb_dn2id(cn=accesslog) Sep 23 14:22:45 sgmldap02 slapd[23385]: = bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30990) Sep 23 14:22:45 sgmldap02 slapd[23385]: send_ldap_result: conn=-1 op=0 p=0 You must initialize the database, the accesslog overlay doesn't do it for you. That is, you must create the suffix entry (cn=accesslog) for the database, just as you would for any other database. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: slapd crashes when accessing accesslog
Michael Ströder wrote: Howard Chu wrote: You must initialize the database, the accesslog overlay doesn't do it for you. That is, you must create the suffix entry (cn=accesslog) for the database, just as you would for any other database. Played with it: Subordinate eEntries are appearing under my ou=accesslog but more than one search operation with web2ldap crashes slapd OPENLDAP_REL_ENG_2_3. It does not happen with command-line tools. :-/ I've tracked it down somewhat: It has to do with an abandon I was sending after retrieving partial search results. If I don't send the abandon request after search/result slapd does not crash. (Well, I will think about whether it's reasonable to abandon the search but slapd should not crash.) I can provide detailed logs if necessary. Should I try with HEAD or is it a known issue? Try with HEAD first, it doesn't sound familiar. File an ITS if it crashes there. Note: web2ldap uses python-ldap which is a wrapper around the OpenLDAP libs. I could provide debug logs of OpenLDAP libs. Since the crash is in slapd, it shouldn't make any difference what libs you used on the client side. You Ciao, Michael. ## # ou=accesslog ### databasebdb suffix ou=accesslog directory /var/openldap/2.3/accesslog rootdn cn=root,ou=accesslog rootpw secret lastmod on index reqStart eq schemacheck on checkpoint 200 5 # Entries to cache in memory cachesize 500 # Search results to cache in memory idlcachesize 50 sizelimit -1 -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Ldapsearch returning incorrect value
Karsten Gorling wrote: * Rohit Kumar (rokumar) [EMAIL PROTECTED] [050926 16:54]: The value returned is as follows: MTI4OTMxODIgIA== while the actual value is 12458 The LDAP-utitilities are not internationalized and so return always the Base64-encoded value as saved in the server. Base64-encoding is for numbers usually not necessary. How is the attribute slot defined? The particular value quoted above MTI4OTMxODIgIA== has two trailing spaces when decoded. That's the reason why ldapsearch displayed it in base64 format, to ensure that the spaces don't get lost. If you got rid of the trailing spaces, then it would just display it without base64 encoding. As usual - garbage in, garbage out. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: problem with sets in 2.2.5 (not in 2.1.25)
Giuseppe Milano wrote: Hi to all, Ok, ACL SETS seems to work fine in normal conditions but i can't understand why in some cases they differ form older versions of openldap. For example I can't understand why acl and sets fail in this condition: My ACL is: access to dn.regex=^ou=(.+),ou=x2x,dc=intesa,dc=it by users set=(user/x2xTenant[$1]) read when i search for ou=all,ou=x2x,dc=intesa,dc=it with user cn=anastacia,ou=People,ou=all,ou=x2x,dc=intesa,dc=it no entry was returned. In 2.1 the set style defaulted to regex, in 2.2 it defaults to exact. So you need to explicitly specify by users set.regex=(user/x2xTenant[$1]) read to get this working in 2.2. By the way, 2.2.28 is the latest 2.2 release. Since you're upgrading anyway, you definitely should not be using something as old as 2.2.5. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Is fedora core 3 a ticking timebomb?
acqant wrote: I know I should just compile the Berkeley DB from source and apply the 4 patches but before I do I just want to make sure that that will end my problem. I'm running fedora core 3, openldap-2.2.24 from source with db4-4.2.52-6 from rpm. I can't seem to find out what if any patches are applied to that db4 rpm and I'm seeing the same problems with my back-dbd that others are commenting on. After a power outage today the db was corrupt and db_verify and db_recover did not work ( I don't have the output for that ). I flushed the data queue and slapadd' the data back in, ran slapindex and before I started the server wanted to see what a db_verify would look like. db_verify id2entry.bdb db_verify: Page 1: out-of-order key at entry 37 db_verify: Page 1: out-of-order key at entry 74 db_verify: DB-verify: id2entry.bdb: DB_VERIFY_BAD: Database verification failed This is not an error for OpenLDAP 2.1-2.2. db_verify does not work because we used a custom sort function in the database. The custom sort functions were removed in OpenLDAP 2.3 to avoid this warning, but the message is meaningless in 2.1-2.2. I guess this needs to go into the FAQ since it has come up a number of times on the list in the past couple days. Better still - this message means you need to upgrade to OpenLDAP 2.3... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: How to raise the open file descriptor limit for slapd?
David Landgren wrote: It is Linux as it happens. We added * hardnofile 4096 to /etc/security/limits.conf at the same time that we added ulimit -n 4096 to the init.d script for ldap. All this did was to change the syslog error message from daemon: accept(6) failed errno=24 (Too many open files) to daemon: 1024 beyond descriptor table size 1024 which to me smells like a recompilation is required. If there's another way I'd love to hear about it. Yes, you need to recompile slapd/daemon.c with an appropriate value #define'd for FD_SETSIZE. You probably need to explicitly #undef it first to remove the default value that glibc uses. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Oddity with BDB backend
Aaron Richton wrote: Boy, makes you wonder if there are any bugs in 2.2.23 with that. Perhaps Fixed back-bdb ldapadd ctxcsn crash (ITS#3685) fixed in 2.2.26 Fixed back-bdb ctxcsn/LRU bug (ITS#3666) fixed in 2.2.25 I'd try an upgrade to 2.2.28 or, preferably, 2.3.7. Releases 2.2.29 and 2.3.8 are being prepared. You could try testing the CVS branches, to get the latest available fixes. On Wed, 5 Oct 2005, Mike Whitaker wrote: Trying to do a MOD on an attribute on a node very occasionally returns me this (slapd v2.2.23) err=80 text=context csn store failed I don't see any changes that directly address this problem; it implies that the BDB library failed with a condition we don't recognize. It could be as simple as an out-of-resource condition (disk space, lock resources, etc), but there would be other BDB error messages accompanying this if that were true. You probably need to run db_recover. Switching up to 2.3 would be a good move, since none of this particular code exists any more in 2.3. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Replicate through an VPN ?
Su Tam Nguyen wrote: Hi all, I intend to make the synchronization between master and slave server through an VPN built before, and after this work complete, the VPN will be disable too. So, this VPN is just active on demand. I want to know when the synchronization starts, and stop. Before the begining of this, the master will create an VPN and signal to the slave to do the same thing. After exchange information on this VPN, the VPN will collapse. I have started slapd and slurpd with the highest debug mode (-d 65535) and got some information when the replication happen, but it seems not enough for me. Could anyone tell me about where the concerned code is , or suggest another way to do so ? Thanks in advance ! Su Tam Nguyen Why tear down the VPN at all, what resource cost is associated with keeping it up all the time? Using a VPN implies at least some concern about malicious users on the intervening networks. What if a malicious user intercepts the message from the master that signals the slave to create the VPN? Why use a VPN at all, why not just use TLS? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: slapd fails to start up in 2.3.8 and 2.3.9
Buchan Milne wrote: On Monday, 10 October 2005 19:34, Howard Chu wrote: errno 38 is ENOSYS, it seems the epoll_ctl system call is not implemented on your target kernel. You say that running make test works though? On the build host, which has a 2.6 kernel. The kernel on the target host is 2.4 (which doesn't have epoll). That's pretty strange. You'll probably have to set ac_cv_header_sys_epoll_h = no and rerun configure. The configure script checks that epoll_create() works, strange that it would succeed but epoll_ctl() fails. I've changed the package to set ac_cv_header_sys_epoll_h = no when building for a target system with a 2.4 kernel, which has fixed that for me. However, build-time checks on kernel features may not be the most robust solution. Ahem. The very nature of autoconf is to perform build-time checks on the build machine, for library and kernel features. E.g., all the checks we do to see if pthreads, regex, etc. works... The fact is that you actually have what should be treated as a cross-compilation setup. When cross-compiling, configure defaults most of these feature tests to no anyway, but your problem is how to get configure to recognize that it should be in a cross-compile mode, since the host *architecture* is the same. In other words, you're trying to do something that autoconf isn't designed to handle automatically. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Upgrade issue ({CLEARTEXT} not available)
Michael Hall wrote:
While upgrading from 2.2.27 to 2.2.28 (on FreeBSD 4.11, using ports) I get the
following error:
Sep 28 02:40:39 vulcan slapd[80851]: @(#) $OpenLDAP: slapd 2.2.28 (Sep 28 2005
02:39:50) $ [EMAIL PROTECTED]:/usr/local/var/tmp/usr/ports/net/ope
nldap22-sasl-server/work/openldap-2.2.28/servers/slapd
Sep 28 02:40:39 vulcan slapd[80851]: /usr/local/etc/openldap/slapd.conf: line 3
2: password scheme {CLEARTEXT} not available
Sep 28 02:40:39 vulcan slapd[80851]: /usr/local/etc/openldap/slapd.conf: line 3
2: no valid hashes found
Sep 28 02:40:39 vulcan slapd[80851]: slapd stopped.
Searching I found references to the new password policy (ppolicy.schema,
slapo-ppolicy man pages, etc) in the 2.3.x series but nothing related to the
2.2.x series. I also didn't find anything anything in the documentation for
2.2.28.
Any pointers or resolution for this issue?
Sounds like ITS#4021. The fix was released in 2.3.8, and was not
backported to 2.2. The patch is simple, you can get it from CVS
libraries/liblutil/passwd.c r1.103
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://highlandsun.com/hyc
OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: ITS#3971 Fix
Mitya wrote: Hi, (Maybe I should have posted this to OpenLDAP-Devel, but I'm not an OpenLDAP developer, and I feel a little bit lazy to subscribe to another one mailing list ;) Since you're discussing ITS#3971, you should simply have replied to openldap-its... The first patch fixes ITS#3971. It needs to be reviewed; I only ran make check (successfully) after applying this patch, but maybe similar corrections need to be done in tool section of backglue. The nature of ITS#3971 is the following; we implicitly make op-o_req_dn-bv_val equal to gi-gi_n[i]-gn_be-be_suffix[0]-bv_val (backglue.c:338), and op-o_req_dn-bv_val after that can be freed by rwm (rwm.c:82), thus filling gi-gi_n[i]-gn_be-be_suffix[0]-bv_val with garbage and rendering backglue inoperational for further invocations. Replacing assignment by ber_dupbv fixes this. Thanks for investigating. I would prefer a different fix in rwm, but knowing why the problem occurs is a great start. Even with this patch backglue and global rwm do not work together in subordinate relays configuration. That's because glue makes no chance for a global rwm instance to act on subordinates, after relaying is done. The nature of this misbehaviour seems to be a little bit deeper, so I didn't investigate this. I don't believe you should be using the rwm overlay as a global overlay since the relay backend automatically invokes it itself. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Slurpd and TLS/SSL
Jim Seymour wrote: Hi All, What OpenLDAP version number... I got replication working on port 389. I can talk to the replica server on port 636 using SSL with JXplorer. But when I try to use port 636 for replication, replication silently fails. (The silently part is especially bothersome :(.) Both servers have self-signed certs, if that matters. All that matters is that both servers are properly configured to recognize/accept each other's certs. However, it's usually a bad idea to use self-signed certs for servers. Any time you need to use more than one cert you should create an actual CA cert and use it to sign all the others that you'll use. I found an item about how slurpd must use TLS on port 389, as opposed to SSL on port 636, and went back to port 389. Tcpdump revealed the connection was not encrypted. I tried uri=https://host.example.com:389; and that, too, failed silently. Well, this is Open *LDAP* after all. I don't believe anybody has enhanced slurpd to replicate using HTTP... uri=ldaps://host.example.com should work fine if host.example.com is listening on ldaps://. You can explicitly specify the port uri=ldaps://host.example.com:636 but I usually don't bother unless someone is using a non-default port. The tls options for replication are set to yes/try, as appropriate. I *think* that should about cover it. Suggestions? Remember that slurpd is an LDAP client, not an LDAP server. It only extracts a few bits of info out of slapd.conf, the rest of its configuration (including TLS parameters) must be set via ldap.conf. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Slurpd and TLS/SSL
Jim Seymour wrote: Remember that slurpd is an LDAP client, not an LDAP server. It only extracts a few bits of info out of slapd.conf, the rest of its configuration (including TLS parameters) must be set via ldap.conf. Got here O'Reilly's LDAP System Administration (now rather out-of-date, but still useful) and the OpenLDAP.org admin guide. Neither mentions anything about ldap.conf in relation of replication. Is now the point at which I mention I'm more confused than ever? In that case, now would be the point to say RTFM. From the slurpd(8) man page, DESCRIPTION section: Note that slurpd reads *replication* directive from *slapd.conf* http://192.168.1.1/%7Ehyc/man/man5/slapd.conf.5(5), but uses *ldap.conf* http://192.168.1.1/%7Ehyc/man/man5/ldap.conf.5(5) to obtain other configuration settings (such as TLS settings). I would also mention that as far as I know, nobody working on that O'Reilly book ever contacted anyone on the OpenLDAP project re: reviewing its content. (And yes, we have done so when asked by other authors in the past.) As such, the book's technical accuracy and best-practice suggestions are somewhat questionable. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Slurpd and TLS/SSL
Jim Seymour wrote: So, I've some more homework to do. (I'm inclined to wonder how many admins *think* they've got encrypted connections between slurpd and remote slapd's, and really don't? How many admins go to the trouble of doing a tcpdump/snoop/ethereal/whatever to see what's actually happening?) You can see what's happening without using any external network debugging tools. Just make sure debug level 2 is included in your debug flags. E.g., run slapd -d2, slurpd -d2, -d3, -d7, etc... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: 2.3.11 test007 fails
You must link slapd with shared libldap (configure --enable-dynamic)
when using back-ldap/back-meta as dynamic modules. There is probably a
way to make libtool take care of this automatically, but right now it
doesn't.
Dieter Kluenter wrote:
Hi,
I'm just testing 2.3.11 on x86_64, building almost everything als
module except for back-hdb, back-bdb and back-monitor.
Running test bdb fails with test007, the last few lines are
,[ output of test007 ]
| Waiting 5 seconds for slave slapd to die...
| Applying more changes to the master slapd...
| Stopping slurpd...
| Waiting 5 seconds for slurpd to die...
| Applying more changes to the master slapd...
| Restarting slave slapd on TCP/IP port 9012...
| Using ldapsearch to check that slave slapd is running...
| Restarting slurpd...
| Waiting 15 seconds for slurpd to send changes...
| Try updating the slave slapd...
| ldapmodify failed (255)!
| ./scripts/test007-replication: line 299: kill: (19436) - Kein passender
Prozess gefunden
| ./scripts/test007-replication failed (exit 255)
| make: *** [bdb-yes] Fehler 255
`
the last few lines of testrun/slapd.2.log are
,[ slapd.2.log ]
| read1msg: ld 0x777530 msgid 1 message type bind
| ber_scanf fmt ({eaa) ber:
| ber_scanf fmt ({eaa}) ber:
| new result: res_errno: 0, res_error: , res_matched:
| read1msg: ld 0x777530 0 new referrals
| read1msg: mark request completed, ld 0x777530 msgid 1
| request done: ld 0x777530 msgid 1
| res_errno: 0, res_error: , res_matched:
| ldap_free_request (origid 1, msgid 1)
| ldap_free_connection 0 1
| ldap_free_connection: refcnt 1
| ldap_parse_result
| ber_scanf fmt ({iaa) ber:
| ber_scanf fmt (}) ber:
| ldap_msgfree
| ../servers/slapd/slapd: symbol lookup error:
../servers/slapd/back-ldap/.libs/back_ldap-2.3.so.0: undefined symbol:
ldap_modify_ext
`
the last few lines of testrun/slapd.1.log are
,[ slapd.1.log ]
| connection_get(13)
| connection_get(13): got connid=5
| connection_read(13): checking for input on id=5
| ber_get_next
| ber_get_next on fd 13 failed errno=0 (Success)
| connection_read(13): input error=-2 id=5, closing.
| connection_closing: readying conn=5 sd=13 for close
| connection_close: conn=5 sd=13
| conn=5 fd=13 closed (connection lost)
| daemon: shutdown requested and initiated.
| slapd shutdown: waiting for 0 threads to terminate
| slapd shutdown: initiated
| bdb_cache_release_all
| slapd destroy: freeing system resources.
| slapd stopped.
`
any hints?
-Dieter
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://highlandsun.com/hyc
OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: 2.3.11 test007 fails
Dieter Kluenter wrote: OK, now I built all backends and overlays as module and made it up to test036 ,[ make bdb ] | Using ldapsearch to retrieve all the entries... | Filtering ldapsearch results... | Filtering original ldif used to create database... | Comparing filter output... | comparison failed - meta search/modification didn't succeed | ./scripts/test036-meta-concurrency failed (exit 1) | make: *** [bdb-mod] Fehler 1 ` This is a known issue with test036 (and test039 as well). (ITS#3832, followups 4, 5, and 6. It probably should get its own ITS as the other factors discussed in that ITS have already been resolved.) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: database directory inside database directory
Hallvard B Furuseth wrote: Is it safe to make the database directory of a glued BDB/HDB/LDBM database a subdirectory of its superior database's directory? E.g. BDB doesn't get clever and merge info from the superior's DB_CONFIG file or something? BDB doesn't look into subdirectories unless you tell it to. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: What is the glue overlay function?
[EMAIL PROTECTED] wrote: Dear all, I'm puzzled about how to use glue overlay. Is it used to support multiple naming contexts in the same DS? No. There is little point in talking about the glue overlay since its functionality has been folded back into the main slapd code (i.e., where it was in 2.2). It no longer exists as a separate module. This change was announced in the 2.3.7 changelog; the current release is 2.3.11. If you're working with a release that still refers to the glue overlay you should upgrade. And in the Man, there is no example, so it's difficult to understand. The slapo-glue man page has been removed from the distribution. See the slapd.conf(5) man page instead, look up the subordinate keyword. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: change related to its 4046 seems to break sasl/gssapi working with AD
Quanah Gibson-Mount wrote: --On Wednesday, October 19, 2005 3:13 PM -0400 Chapman, Kyle [EMAIL PROTECTED] wrote: im not sure this is a legit problem or an issue with how MS deals with sasl/gssapi... changes for cyrus.c 1.112.2.6 to 1.112.2.7 break sasl/gssapi binds to AD (vers 2.3.8 and up, at least for me). if i roll back to 1.112.2.6 in 2.3.11, everything builds ok and ldapsearch/sasl/gssapi to AD work. looking at the diff, there is memory cleanup as well as some changes to checking the values provided by scred following a call to ldap_sasl_bind_s. adding back in the mem cleanup and the first reorder of the if statements and rebuilding, sasl/gssapi still works. changing the second if statement results in (this change is after seeing if the rc and saslrc are OK): You should follow up to the ITS if you want anyone to look at this. Posts to the openldap-software list are seen as purely informational. ITS#4046 doesn't seem to be the right number. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: installation problems
[EMAIL PROTECTED] wrote: Thanks for the reply Sam. I will try your steps to see if they work. They look that same as mine with the exception of parameters enter with the config script. Does anyone know if it is safe to use BDB 4.3.x yet with OpenLDAP? 4.3.21 was definitely unusable. 4.3.27 appeared to work. I haven't tested the current (4.3.29) yet. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Problems with slapcat/slapadd in upgrade from 2.2.23 to 2.3.11
Pierangelo Masarati wrote: On 20 Oct 2005, at 14:24, Pierangelo Masarati wrote: On Thu, 2005-10-20 at 13:29 -0700, Charles Stephens wrote: Is there a reference on ACI syntax? What is wrong with this specific entry? There is no formal specification (yet); values that used to be legal are still legal, and few extensions have been added in HEAD. Of course, ACIs need to be explicitly enabled by using --enable-aci at configure. I read aci.c in 2.3.11 and I am more comfortable with the syntax, but it is still scary that there isn't anything even roughly documented. Look, the syntax is exactly as it was before; only, now you catch blatant error while writing new rules, rather than having them silently discarded at ACL evaluation. What's more scary? ACI has been marked experimental for years. Frankly, that *should* be scary enough all by itself to steer people away from it. As experiments go, if it was successful it should have graduated out of experimental status by now. The fact that it hasn't should be strong hint... Security management is hard enough as it is. If you can't define a coherent policy, then you clearly have no chance of enforcing it, or even validating whether the real system behavior conforms to the policy. When you allow access control rules to be attached to the directory entries they govern, that essentially means pieces of your security rules are created and deleted on the fly as a *side effect* of creating and deleting the data. Clearly in such a situation you have *no* coherent security policy, which in my book is equivalent to having no security. *That's* scary. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: User Schema Load failed ..., using ppolicy.schema overlay
Robert Kupperstein wrote: I've tried that, with no luck. BTW, I'm working with 2.3.11, but I have the same problem with 2.3.7 and 2.3.9. This was written up as a bug, but w/o any mention of how to work around it: That bug was fixed long ago, before 2.3 was ever released. Make sure you're using the correct version of the ppolicy.schema file to match the ppolicy.c code. static ppolicy overlay init (ITS#3137) * To: [EMAIL PROTECTED] * Subject: static ppolicy overlay init (ITS#3137) * From: [EMAIL PROTECTED] * Date: Sat, 8 May 2004 22:33:54 GMT Full_Name: Pierangelo Masarati Version: HEAD (2.2?) OS: Linux (irrelevant) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) If the ppolicy overlay is statically built into slapd, ppolicy_init() fails complaining about User Schema Load failed...; there is no way to aviod this, not even loading ppolicy.schema also when the overlay is not used, because overlay initialization occurs before configuration is read. p. --- Buchan Milne [EMAIL PROTECTED] wrote: On Thursday 27 October 2005 20:13, Robert Kupperstein wrote: Can someone tell me how to work around this problem? Should I use different configure options to build a dynamically loadable version? What options do I need to use? I think the solution to this is to add an include line for the ppolicy.schema file distributed with OpenLDAP to your slapd.conf. Regards, Buchan -- Buchan Milne ISP Systems Specialist B.Eng,RHCE(803004789010797),LPIC-2(LPI74592) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: OpenLDAP Hooks and Integration
Rik Herrin wrote: Hi, I was wondering if the following is doable using OpenLDAP. Is it possible for the server to obtain information and store it in an entry when the user authenticates against it? Your question is poorly specified, which indicates that your objective is poorly conceived and you really have no idea what you're asking for. Using my psychic abilities I'm going to do your thinking for you and take a stab at answering anyway. For example, when a user logs in, would it be possible to configure the OpenLDAP server to obtain things such as the IP and store them in one of the user's attributes? I wanted to do this so that I can integrate OpenLDAP with iptables or any other service (perhaps a proxy service). Thanks for your time. Since you are talking about iptables it appears you're interested in what happens after a user logs into a Linux system. The fact that LDAP is used to verify the user's authentication to Linux is incidental. In this scenario, what you're looking for is purely an application-level concern. I.e., the module that performs the Linux authentication using LDAP should be responsible for squirreling away whatever other information you're interested in maintaining. Note that in this scenario it is impossible for the LDAP server to *gather* any useful information about the *user's* IP address; the only thing the LDAP server sees is the IP address of the Linux machine requesting the authentication. Only the Linux machine knows the actual IP address of the user. Also, even if the LDAP server could somehow divine the necessary information about the user, the information is of no value to the LDAP server itself. It is up to your application-side code to query the attributes anyway. So all of the development required to implement this feature you desire rests on the application side. When you take the time to think through the actual flow of information and steps needed to process it, it's all pretty obvious. No need to wonder. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Tuning BerkeleyDB
Just a bit of an FYI for folks using OpenLDAP with BerkeleyDB on a multi-processor machine - there's some pretty useful hints here http://www.sleepycat.com/docs/ref/transapp/tune.html starting with the section mutex selection. (The information in the previous sections is already accounted for in the back-bdb code and will seldom need adjusting.) You may need to re-configure and rebuild BerkeleyDB to get the best DB mutex performance on your system. Also, the docs are a bit deceptive regarding the DB_ENV-set_tas_spins method: http://www.sleepycat.com/docs/api_c/env_set_tas_spins.html The spin count is used even when you're using POSIX pthread mutexes, and the default value used on multi-processor machines makes BDB extremely slow as the number of active threads increases. The default on a uni-processor machine is 1; our testing shows that setting it to 1 on a multi-processor machine works much better as well. With POSIX mutexes I don't see any reason to spin at all, it should be set to 0 regardless of the number of CPUs. If you're running a Linux kernel up to 2.4 you're probably using LinuxThreads; since LinuxThreads didn't support interprocess mutexes BDB would probably have defaulted to using test-and-set mutexes. If you're on 2.6 with NPTL it would most likely default to using POSIX mutexes. It's worth double-checking your BerkeleyDB build to see exactly how it was configured. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: openldap build problem
Al Lilianstrom wrote: We have been using Openldap on a old Tru64 machine for a couple of years to glue our Oracle database and W2K Active Directory together. We're moving the database to a Linux machine. I rebuilt the Openldap software and it almost works. The Unix machines are in a MIT Kerberos Realm and a trust exists between the MIT realm and the W2K Domain. The account I'm running with on the Unix side is mapped to a Windows account. Using the latest openssl, Cyrus SASL, and stable openldap source packages I built everything in the same manner as before. I tested the SASL code using the sample-client/server programs to make sure that GSSAPI was working properly. I built openldap with --with-cyrus-sasl as my only option. When I test using ldapsearch I'm seeing the infamous ldap_sasl_interactive_bind_s: message $ ldapsearch -Y GSSAPI SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) My config files are set right. I see a logon/logoff to the AD domain when I try the ldapsearch. I get tickets from the Windows domain and from the domain controller I'm attempting to query. If I use -x I get the expected response from the domain controller. Any ideas on what I might have missed? See ITS#4102. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: asynchronous event notification?
Phillip Rhodes wrote: Hi all, I have a question regarding OpenLDAP and asynchronous events. Does OpenLDAP currently support any form of event notification? I spent a lot of time Google'ing and searching the archives of this list and saw some old discussion from back in 1999 on this subject, but nothing current. In case it matters, what I'm seeking is the ability to receive notification of events such as: adding an entry, deleting an entry, modifying an entry, etc. The purpose of this would be for integration with other software... ex: I add a user to OpenLDAP, and want to programatically update the user database of another application to make it aware of that user, etc. The typical directory-friendly way of doing this is to write an LDAP client that issues a persistent search for all of the events of interest. That client can then feed the data into whatever other database you're working with. The clever way to do this is to write a module for OpenLDAP slapd that uses the foreign database's API on the backend and maps it into an LDAP view for the frontend (e.g. back-sql, back-passwd, etc...) and use a replication engine to propagate changes in the main LDAP database into the foreign database. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Corrupt LDAP DB ...
Jose Ildefonso Camargo Tolosa wrote: I think it is. OpenLDAP almost depends on Berkley DB, so it should give some info in the general documentation (there is info, in the FAQ-o-matic), or at least warn about how fragile BDB is. Recent versions (2.3.x) warn (to syslog) if you don't have a DB_CONFIG file for any bdb or hdb database. Cool. It was about time, it took two versions to implement that (please note that I actually give support for OpenLDAP, so I'm not new to it). If you thought this was such a problem two versions ago, why didn't you file an ITS on it back then? Whining on the discussion list doesn't get problems resolved. If you've identified a specific weakness, but don't report it, you shouldn't be surprised that it doesn't get fixed sooner. You have only yourself to blame, for not filing the report. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: ppolicy overlay password problem
The test022 script in the bundled test suite specifically tests for authentication using an incorrect password, and this test works correctly in my 2.3.11 build. As such, I do not believe there is any bug in OpenLDAP software here. You should check whatever software you're using to login. Baoning Pan wrote: Hi, I need help on ppolicy as this is the first time I try to use it for company internal use. I search the mail listing and web and cannot find same problem. I compiled openldap 2.3.11 on Solaris 8, with bdb.4.3.29 and openssl.0.9.7g. First I started slapd without ppolicy, and things works fine. Then, I added ppolicy overlay/schema. slapd started/loaded fine. But I get big problem with user password, user can login with ANY WORD as its password even though I can see new pwdFailureTime entry is added to ldap db for that user. Thanks. Here are the ppolicy related entries/ldif for my slapd.conf include /usr/local/openldap/etc/openldap/schema/ppolicy.schema overlay ppolicy ppolicy_default cn=Standard Policy,ou=Policies,dc=n2p,dc=com ppolicy_use_lockout dn: ou=Policies,dc=n2p,dc=com objectClass: top objectClass: organizationalUnit ou: Policies structuralObjectClass: organizationalUnit dn: cn=Standard Policy,ou=Policies,dc=n2p,dc=com objectClass: top objectClass: device objectClass: pwdPolicy cn: Standard Policy pwdAttribute: userPassword pwdLockoutDuration: 120 pwdInHistory: 5 pwdCheckQuality: 2 pwdExpireWarning: 86400 pwdMaxAge: 864000 pwdMinLength: 5 pwdGraceAuthNLimit: 5 pwdAllowUserChange: TRUE pwdMustChange: FALSE pwdMaxFailure: 3 pwdFailureCountInterval: 120 pwdSafeModify: FALSE structuralObjectClass: device -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Modifying ACIs programmatically?
Aaron Richton wrote: Look around the list and the FAQ-O-Matic for information about back-config. doc/drafts/draft-joslin-config-schema-xx.txt might be good reading too. No, the draft you reference is for DUA configuration and has nothing to do with back-config. The best source of info would be the 2.3 Admin Guide, chapter 5. Note you'll need OpenLDAP 2.3 for this. See http://www.openldap.org/lists/openldap-software/200505/msg00103.html and all links thereof for some good warnings about ACIs and some practical ACLs. On Mon, 7 Nov 2005, Betty Graupe wrote: text-based access to directives, but I don't see any samples of how this can be done programmatically. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: How do I run a query on the bdb database before I've started listening for incoming request?
Krishna Ganugapati wrote: Hi Quanah: I'm doing this experimental hack ( solely for the purpose of understanding the code base as well as I can ) I'm trying to add dynamic schema updates. Here's what I've done OpenLDAP 2.3 already supports dynamic schema loading. See the cn=schema,cn=config subtree and read the OpenLDAP 2.3 Admin Guide. - Original Message - From: Quanah Gibson-Mount [EMAIL PROTECTED] To: Krishna Ganugapati [EMAIL PROTECTED]; openldap-software@OpenLDAP.org Sent: Wednesday, November 09, 2005 12:03 PM Subject: Re: How do I run a query on the bdb database before I've started listening for incoming request? --On Tuesday, November 08, 2005 7:12 PM -0800 Krishna Ganugapati [EMAIL PROTECTED] wrote: Hello, I've managed to get both my naming contexts up and functional. I want to be able to run a query within slapd before I've started listening (before main.c/slapd_daemon() Out of curiosity, *why* do you want to do this? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Translucent overlay odds?
Pierangelo Masarati wrote: Is local addition intended to be supported? Yes, apparently, according to the man page; but I note this case is not tested in test034. So my question is: does my approach make sense, should this be possible and it's not happening because of a bug, or is my design flawed? No, the current design of the translucent overlay does not allow totally local entries to exist. I.e., there must be a corresponding remote entry. Also, it expects the local and remote DB to have the same suffix. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Translucent overlay odds?
Pierangelo Masarati wrote: On Sat, 2005-11-12 at 17:23 -0800, Howard Chu wrote: Pierangelo Masarati wrote: Is local addition intended to be supported? Yes, apparently, according to the man page; but I note this case is not tested in test034. So my question is: does my approach make sense, should this be possible and it's not happening because of a bug, or is my design flawed? No, the current design of the translucent overlay does not allow totally local entries to exist. I.e., there must be a corresponding remote entry. Also, it expects the local and remote DB to have the same suffix. After looking at the code, and thinking myself about its design, I realize it likely doesn't fit the purpose. In fact, even though the local entries are present (and they __are__, as if I comment out the translucent stuff they actually get returned by the local database) they cannot be reached because no local search is performed, but only entry lookups based on the DNs resulting from the remote search (which sounds likely and, I'd say now, obvious :). One drawback of this, that makes slapo-translucent unfit for my purpose, is that local attributes cannot appear in search filters; too bad. This is consistent with the results of my speculations about a meta- engine that merges entries, including searches. If we could speculate a bit more on searches, e.g. specifying which attributes should be only searched locally, which should be only searched remotely, which at both sides, and then do some local merging of the results to track the duplicate DNs, this would fit my current needs. In terms of server load and performances it might be even worse than server side sorting, but it's likely the only solution in cases where I need to augment data from a remote server which I cannot write and in some cases I cannot even entirely read. Yes, we've been discussing this function among ourselves, config keywords for specifying that particular attributes reside local or remote. Splitting the filter and combining the results from local to remote is still going to be pretty intensive. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: BDB 4.4 is released
Jon Roberts wrote: Quanah Gibson-Mount wrote: For those interested, BDB 4.4 has been released. Preliminary support for building OpenLDAP against BDB 4.4 exists in HEAD. At Sleepycat's request, Symas Corporation has been testing BDB 4.4 for several weeks. Initial testing found BDB 4.4 to be slower than BDB 4.2 or BDB 4.3 when doing 'db_load' commands and running slapadd on various size databases. Evaluating slapd's performance under BDB 4.4 is still underway. Please share results when you can. For now, given the reduced performance relative to 4.2, the only reason I find it interesting is that it finally supports cache segments larger than 4GB. This has been somewhat of a hindrance on our testing on large 64-bit deployments, still not sure if that win offsets the other losses. There are still a number of types and structures that are tied to 32 bits, which is somewhat annoying. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: openldap-server-2.2.29: multimaster support
matthew sporleder wrote: On 11/21/05, Pierangelo Masarati [EMAIL PROTECTED] wrote: This would yield two advantages: 1) reduce by 1 the number of sync propagations in the typical case of no conflicts 2) make the change immediately available on the server that received the request (dam'd: I should have patented this ;) Sorry, I'd have beaten you to it... :P http://www.openldap.org/lists/openldap-devel/200304/msg7.html If a link failure occurs on one node, the write wouldn't be guaranteed to exist on all servers, which breaks the Atomicity and Durability requirement of ACID. (I think the first step in a multi-master setup should be ACID compliance, by the way). I believe a journal and a staging database should be employed to first record the write, and then test its application. If those are both successful on all nodes, then a signal can be given to merge that information into the production database at an agreed upon time. That sounds like a distributed transaction manager, like Tuxedo. BerkeleyDB can work with something like that, and we could implement it in slapd without too much trouble. But it's quite different from what most people here are asking for; the overhead for maintaining ACID would drop write throughput to a few operations per second on a moderate sized network. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: sizelimit evaluated before ACLs?
Eric Irrgang wrote: I'm sorry if this has already been discussed, but I can't seem to find such a thread in the archives... With OL 2.2.29 it looks to me like the sizelimit specified by a client search is evaluated after the ACLs on the server side, so that if a client specifies a sizelimit of 10 and receives 8 results, it may be obvious that 2 entries matched the filter but failed the ACL check, disclosing perhaps more information than the directory maintainers would like. Is this expected/intended behavior? It is the as-designed behavior. But you're right, the design is broken here. Currently all sizelimit checking is done in the individual backends, while the search ACLs are checked in the frontend. Checking in the backends means there's a lot of redundant code; it should all be moved into the frontend. Such a change would break the pagedResults implementation in back-bdb. But that's probably OK, since the pagedResults feature properly belongs in the frontend as well. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: sizelimit evaluated before ACLs?
Kurt D. Zeilenga wrote: I think the general assumption was that if the client has some search permission (check by test_filter prior to calling send_search_entry), it has read on entry. Now, with overlays and other things happening, having send_search_result indicate whether or not an entry was actually sent (or possibly the number of entries sent?) would be a good idea. Since send_search_entry() maintains the actual counter of number of entries sent, and has access to the sizelimit in the operation structure, it would make the most sense for it to do the test and return a SIZELIMIT_EXCEEDED result to the caller when appropriate. Then no callers (backends or overlays) need to worry about testing the limit, they just need to handle the non-success return codes. (Which they do already.) At 03:14 PM 11/23/2005, Howard Chu wrote: Eric Irrgang wrote: I'm sorry if this has already been discussed, but I can't seem to find such a thread in the archives... With OL 2.2.29 it looks to me like the sizelimit specified by a client search is evaluated after the ACLs on the server side, so that if a client specifies a sizelimit of 10 and receives 8 results, it may be obvious that 2 entries matched the filter but failed the ACL check, disclosing perhaps more information than the directory maintainers would like. Is this expected/intended behavior? It is the as-designed behavior. But you're right, the design is broken here. Currently all sizelimit checking is done in the individual backends, while the search ACLs are checked in the frontend. Checking in the backends means there's a lot of redundant code; it should all be moved into the frontend. Such a change would break the pagedResults implementation in back-bdb. But that's probably OK, since the pagedResults feature properly belongs in the frontend as well. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: put failed: DB_LOCK_DEADLOCK .....
[EMAIL PROTECTED] wrote: I use an injector with 10 parallel connections to load my directory. I often receive this message : Nov 25 13:37:25 my-server slapd[18333]: = bdb_dn2id_add: put failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock -30995 Does somebody know the meaning of the message and what to do to fix it ? I use openldap 2.3.11. This is not a fatal error and does not need fixing. Read the Sleepycat documentation. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Do overlays affect the speed of OpenLDAP?
--On Saturday, November 26, 2005 3:26 PM -0500 Brian Reichert [EMAIL PROTECTED] wrote: This makes it sound like you're addressing the size issue. If so (just so I clarify for my sake), let me restate my question differently: Is there a performance hit to slapd, if it's compiled with overlays and backends enabled, but slapd isn't configured to use them at run-time? Does a car run slower carrying an extra 100 lbs cargo? How about 500 lbs, or 1000 lbs? Use your own brain, try it and see, if you can't reason it out. Your restated question is still vague and therefore meaningless. Is there an effect - of course there's an effect. The more memory an application occupies, the more time it takes to manage that memory. Is it noticable or significant? That depends on who is trying to notice it and what they think is significant. When you don't qualify the information you're looking for, you can't expect quality information. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: refreshAndPersist filter 2.3.11
Alexey Kravchuk wrote: Hi, syncrepl of slapd 2.3.11 with type = refreshAndPersist works only when the syncrepl filter allows to fetch all parent entries up to the base. Yet it worked fine in 2.2.13. That is if we specify searchbase=dc=example,dc=com, filter=(objectClass=organizationalPerson) for syncrepl as in the LDAP Sync Replication config example from the Doc, but set type = refreshAndPersist instead of type=refreshOnly then syncing does not work. Please submit this information to the ITS, otherwise it will be ignored. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: refreshAndPersist speed
Leigh Porter wrote: Hiya, I would like to use refreshAndPersist between a master and slave but my application uses a load balancer that round-robins ldap requests between a master and slave server. I need to write to LDAP on the master but the read could be from any server. The time between a write and read could be sub second so I need the master and slave to be in sync in a similar timeframe. Will syncrepl refreshAndPersist achieve this kind of instantanious update of the slaves? Yes and no. An individual update can propagate instantaneously. However, the current syncrepl client uses only a single thread to pull updates from the master, while the master can perform updates in many threads at once. As such, if there is a burst of write activity on the master, there will be an increasing lag of updates being processed on the slave. In the future we'll look into making the syncrepl client multi-threaded to address this shortcoming. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Linking against a specific Berkeley DB install
The configure script in 2.3.11 doesn't know about BerkeleyDB 4.4. I believe this has been updated in the 2.3.13 release. Bowie Bailey wrote: I am trying to compile OpenLDAP 2.3.11 from source on CentOS4. I have the rpm for db4-4.2.52-7.1 installed and also a source build of BerkeleyDB in /usr/local/BerkeleyDB.4.4. How do I get OpenLDAP to link with the bdb 4.4? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Some syncrepl questions
Andreas Grabner wrote: Hi, i plan to upgrade my master server to 2.3.11. I have some slave servers version 2.2.23 which get its updates via slurpd through slow (128kb/s) unreliable WAN links. Some questions apper: Does it make sense to change to syncrepl? Plain syncrepl uses more network bandwidth than slurpd. Delta syncrepl may be a better choice here. Can i config syncrepl in cn=config? Yes. How should the .ldif look? See the Admin Guide, section 5.2.6.10. http://www.openldap.org/doc/admin23/slapdconf2.html Are theree any issues with 2.3 to 2.2 replication? You need at least version 2.2.24 to accept replication updates from a 2.3 master. You need at least version 2.3.12 to accept replication updates from any previous release. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: refreshAndPersist filter 2.3.11
Howard Chu wrote: Alexey Kravchuk wrote: Hi, syncrepl of slapd 2.3.11 with type = refreshAndPersist works only when the syncrepl filter allows to fetch all parent entries up to the base. Yet it worked fine in 2.2.13. That is if we specify searchbase=dc=example,dc=com, filter=(objectClass=organizationalPerson) for syncrepl as in the LDAP Sync Replication config example from the Doc, but set type = refreshAndPersist instead of type=refreshOnly then syncing does not work. Please submit this information to the ITS, otherwise it will be ignored. Sorry, I had forgotten that this was already fixed on October 15. You just need to update to 2.3.12. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: FYI - Not an OpenLDAP bug - or OpenLDAP on Windows 2000 using Hummingbird SOCKS client
Lalic, Ranko (Ranko) wrote: FYI I tried to use OpenLDAP on the client side on Windows 2000 (w/ SP4) through the SOCKS server. I had to use the Hummingbird SOCKS client (choosing another SOCKS client is not an option). The problem seems to be in the interaction between the Hummingbird SOCKS client Windows TCP/IP stack. Basically, non-blocking socks calls do not work in this configuration (probably the Hummingbird SOCKS client bug). As OpenLDAP is using them I could not connect to my LDAP server. I spent a week+ trying to find what was going wrong. Finally, changing ldap_pvt_connect in os-ip.c so that ldap_pvt_ndelay_on is not called fixed my problem. This worked for me as I was already using synchronous LDAP calls only. Please notice that if you do this, all your LDAP calls will be synchronous. I am still on 2.0.27 as this works just fine for me. Thanks for the note, your solution sounds correct. OpenLDAP 2.0 was obsoleted quite a few years ago. The current release is 2.3.13, and I'll note that somewhere along the line, I also changed libldap to not make the non-blocking calls when using synchronous LDAP calls. There's a reason we put new releases out... You could have saved yourself your week's worth of effort by getting a more recent OpenLDAP release. Hope this will save someone a lot of time. One can always hope. This is one of the fundamental differences between using open source software and closed source software. Generally with closed source software, you have to register your copy of the software. While this is an annoyance, it at least offers the possibility that the vendor will notify you when updates are available. With open source software that you've downloaded and built yourself, the responsibility falls on you to stay in touch with the software developers so that you can stay informed about bug fixes and new releases. This is yet another reason why we place so much emphasis on the term OpenLDAP community - it isn't just a warm'n'fuzzy term. It is a simple fact that we all have to stay in communication with each other, and by doing so we all naturally help each other as a result. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: bdb indexing limits
Gaël Roualland wrote: Hello, Looking through bdb code in OpenLDAP 2.3.x, it looks like for a specific index key, no more than 65536 entries are indexed, over which only the first and last potential matching entries are kept. This is fine for most usages, but I have two questions : - Is it reasonnably possible to augment this, should this create issues ? You can simply change the #define's in back-bdb.h to a larger number. It will cause per-thread memory usage to increase accordingly. - I noticed this limitation is also enforced on the entry children indexing, which means one you created more than 65536 children for an entry, you can no longer remove it (non leaf is returned), even after deleting all of its children first. This seems a bit annoying... If you delete the first or last entry of the range the range will be reduced by one. As such, if you delete entries in order then the range will collapse to zero and allow deletion of the parent. Would it be possible not to enforce it in that case ? No. back-bdb has no other mechanism of tracking child entries. back-hdb is superior here since the dn2id index keeps exact counts of the number of children. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: master ldap database is not getting populated
You cannot copy the raw database files from a 64-bit architecture to a 32-bit architecture. In general you should not copy raw database files at all, use slapcat and slapadd like the Admin Guide says. Moe wrote: Both master and slave are using openldap-2.2.28. Both are also using Berkekely db (db-4.3.28.NC). the only difference is that the master ldap/database backened packages are compiled on itanium platform. The slave ldap is running on an x-86 platform. I don't know if that's the reason why trying to bring up slapd on master after copying the database files to from slave to master failed. under openldap-data there are these files. __db.001 __db.004 id2entry.bdb __db.002 __db.005 log.01 __db.003 dn2id.bdb objectClass.bdb can anyone please tell me where are the ldap entries stored?. what does __db files and log files used for? The way i tried to do a restore from slave to master is by copying all the above files to the openldap-data of the master. Thanks Moe Quanah Gibson-Mount [EMAIL PROTECTED] wrote: --On Thursday, December 08, 2005 10:38 AM -0800 Moe wrote: My master database has currently 60 missing entries. I tried to restore the database from the slave database but its didn't work cause Berkeley Db is different version. How can i track the different entries and maybe manually add them to the master database?. Im trying to find a quick easy way to restore my missing entries. Im not sure if i can use slave database to export the missing entries to an ldiff file and then use the ldiff file to populate the master database. I also don't know how to find what entries are missing in the master ldap. thanks -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: OpenLDAP, Kerberos not Compatible with DIGEST-MD5?
Jorge Diaz wrote:
Hi Everyone!
Thanks to Kurt D. Zeilenga for the help previosly. I have now other question
about storing passwords.
I Have Kerberos 5 (Heimdal), and i could use GSSAPI and Simple Bind specifiying [EMAIL PROTECTED] and configuring saslauthd. So far... so good!
But i nedd DIGEST-MD5 to be LDAPv3 Fully Compatible! (I need Plain Text Passwords!) It is not a security problem? How could i enable DIGEST-MD5 and KERBEROS how i synchonized them?
(Kerberos doesnt store plain text passwords and DIGEST-MD5 needs plain text). How to solve this dilema?
There is only one easy way to solve this problem: migrate the Heimdal
KDC database into OpenLDAP slapd, so that the Kerberos keys are stored
in each users' entry. Also load the smbk5pwd module (from
contrib/slapd-modules). Then configure slapd's passwd-hash with both
{KRB5KEY} and {CLEARTEXT} so that the plaintext and the Kerberos key are
maintained.
This also means you must use the Cyrus auxprop mechanism, not saslauthd.
(Which is a good idea anyway, the auxprop mechanism is the most efficient.)
Another question...
How to implement DIGEST-MD5 without using sasldb backend? How to store directly passwords on LDAP userPassword attribute and implement DIGEST-MD5?
slapd will automatically search the user's LDAP entry for the
userPassword and use it for SASL authentication, if you use the default
settings (i.e., use auxprop, not saslauthd). For all other SASL-enabled
servers you'll need the ldapdb module, which used to be in OpenLDAP
contrib but is now part of Cyrus SASL.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://highlandsun.com/hyc
OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: ldaps and Active Directory
Marco D'Ettorre wrote: Add TLS_REQCERT try (or allow or never) in your ldap.conf. The default is demand (or hard), then you are trying to verify server certificate. See ldap.conf (5) NO. That simply allows the certificate errors to be ignored. They've gone to the trouble of exporting the CA cert, the correct thing to do here is to tell them how to use the CA cert properly. Please re-read the Admin Guide http://www.openldap.org/doc/admin23/tls.html sections 12.2.1.1, 12.2.1.2, 12.2.2.1, and 12.2.2.2. Note that you are not supposed to use both the TLS_CACERTDIR and TLS_CACERT options, just use one or the other. Run ldapsearch with -d7 and see what the actual TLS error messages are. Also run slapd with -d7 and see the TLS messages on the server side. Don't go changing options at random, find out what the real problem is. Grant Sturgis wrote: Greetings List, I am attempting to get ldap authentication to Active Directory working from our RHEL 4 systems. I have read the several articles and howto documents out there and am very close to getting everything working. pam_ldap and nss_ldap is working well with unencrypted ldap, as is ldapsearch queries. The next step is getting ldaps to work, and I am hoping for some suggestions from the list to get me over the hump. RHEL ES 4 fully patched (up2date) W2K SP4 This works fine: ldapsearch -x -H ldap://server.domain.com/ -D cn=ldap,ou=Users-OU,dc=domain,dc=com -W but changing ldap to ldaps results in this error: ldap_bind: Can't contact LDAP server (-1) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed I have installed Certificate Services on the W2K domain controller and exported the CA Cert and copied the file to the linux box:/etc/openldap/cacerts. In /etc/openldap/ldap.conf I have tried: TLS_CACERTDIR /etc/openldap/cacerts TLS_CACERT /etc/openldap/cacerts/cacert.pem Any suggestions would be greatly appreciated. Grant -- -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: syncrepl'd MOD deleted(?) entry
Quanah Gibson-Mount wrote:
Our master had a LDIF submitted to it changing the value of one
attribute:
Dec 12 09:03:06 master.rutgers.edu slapd[11736] [ID 249368 local4.debug]
conn=647307 op=2 MOD dn=uid=xxx,ou=People,dc=eden,dc=rutgers,dc=edu
The entry syncrepl'd, apparently:
Dec 12 09:03:31 slave1.rutgers.edu slapd[15453]: [ID 260518
local4.debug]
syncrepl_entry: uid=xxx,ou=People,dc=eden,dc=rutgers,dc=edu Dec 12
09:05:36 slave2.rutgers.edu slapd[3515]: [ID 260518 local4.debug]
syncrepl_entry: uid=xxx,ou=People,dc=eden,dc=rutgers,dc=edu Dec 12
09:05:41 slave3.rutgers.edu slapd[3901]: [ID 260518 local4.debug]
syncrepl_entry: uid=xxx,ou=People,dc=eden,dc=rutgers,dc=edu Dec 12
09:06:13 slave5.rutgers.edu slapd[2581]: [ID 260518 local4.debug]
syncrepl_entry: uid=xxx,ou=People,dc=eden,dc=rutgers,dc=edu
Don't worry, slave4 has a failed HDD. So this is great.
What's not great is now the slaves don't have the entry anymore.
slave3$ slapcat -b dc=eden,dc=rutgers,dc=edu | grep \
uid=xxx,ou=People,dc=eden,dc=rutgers,dc=edu | wc -l
0
ldapsearch(1) against slave{1,2,5} confirms (less conclusively) that
they
don't see this entry either. There's lots of stuff in the ITS that this
*could* be, but I can't tell with any certainty. Thoughts?
Turn up debug on the slaves and watch what happens during the update...
Well, syncrepl always propagates by doing a DEL then an ADD.
In 2.3, it doesn't always. The 2.3 consumer will try to just do a Modify
when the entry already exists in the slave.
If the entry is still on the master, doing another MOD *should* update
it on the slave. I personally found 2.3.12 too unstable to put out
into production (which is why I waited for 2.3.13). Of course, now I
have 5 patches to 2.3.13, a couple of which (like the fix to #4250) I
consider critical. ;) Which reminds me I need to get some of the
newer patches up on my site...
At this stage, CVS HEAD and 2.3 are close enough that anyone can just
pull the necessary patches out of HEAD.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sunhttp://highlandsun.com/hyc
OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: Syncrepl and user event
Aaron Richton wrote: Quite honestly, I have no idea. Use the source... On Thu, 15 Dec 2005, [UTF-8] Micha�^B Kasperczyk wrote: Does syncrepl calls overlays while adding new objects to slave LDAP? Yes it does. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
Re: forcing password hash
Jim Boden wrote: That is exactly what I need. Thank you Howard! Can anyone tell me where are the pwd histories stored? I was working with another client that spoke exop and found that I could get pwd expiry to work, but not the quality settings or the history. They're stored in the user entry, in the pwdHistory operational attribute. This attribute is fully described in the manpage. Is there something special that must be added to a user entry? I have the default policy specified in slapd.conf Nothing special is needed. overlay ppolicy ppolicy_default cn=Standard Policy,ou=Policies,dc=mycompany,dc=com ppolicy_use_lockout But the users are just posixAccount and shadowAccount types and the setup I copied from test022. If I use exop with SSHA does that prevent openldap from doing the quality checking? No, the exop only accepts passwords in plaintext and then generates the hash later. As such, quality checking can always be performed when using the exop. Thanks, Jim */Howard Chu [EMAIL PROTECTED]/* wrote: Kurt D. Zeilenga wrote: At 11:57 AM 12/19/2005, Jim Boden wrote: Is there a way to force openldap to hash the userPassword entry if the client does not? As distributed, no. slapd(8) preserves the value of userPassword precisely as presented. But if the client does not use exop, is there anything we can do to force a hash? One could, I guess, write an overlay to hash the value on behalf of the client. The ppolicy overlay has a config option to force hashing on Modifies and Adds. See slapo-ppolicy(5). -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sunhttp://highlandsun.com/hyc OpenLDAP Core Teamhttp://www.openldap.org/project/
