openldap-technical

openldap-technical@openldap.org

1 participants
9868 discussions

More about libldap locking
by masarati＠aero.polimi.it 26 Jul '10

26 Jul '10

I'm having trouble in determining what mutex is related to what data in libldap's structures. For example, as far as I understand, lconn_refcnt in LDAPConn is tested and even modified without expressly locking any mutex. Logically, it seems to me that ld_conn_mutex should be the one. Could anybody please confirm this or provide insight? Thanks, p.

2 1

ldap_new_connection() mutex issue
by masarati＠aero.polimi.it 26 Jul '10

26 Jul '10

ldap_new_connection(), if ( connect ) and lconn_server->lud_exts contain the tls ext, first unlocks and then re-locks ld_req_mutex and ld_res_mutex. As far as I understand, while the former is actually held by the caller(s) of ldap_new_connection(), the latter is not. If this analysis is correct, I'll post an ITS. p.

2 5

ldap_sasl_bind_s() with DIGEST-MD5
by Shankar Anand R 26 Jul '10

26 Jul '10

Hi, The problem explained below must be fairly straightforward or even look silly for folks on this mailing list. Sorry for the trouble but I hope one of you might be willing to help a newbie. I am implementing an simple application that finds out a user's attributes using OpenLDAP. This a snippet of my code. ... BerValue cred; cred.bv_len = 10; cred.bv_val = strdup("mypassword"); ldap_sasl_bind_s(ld, "myuser", LDAP_SASL_SIMPLE /*NULL*/, &cred, NULL, NULL, NULL); This succeeds and I am able to proceed with my ldap_search_st() call. But since I don't want to send "mypassword" as plain text over the wire I opted for "DIGEST-MD5" ... BerValue cred; cred.bv_len = 10; cred.bv_val = strdup("mypassword"); ldap_sasl_bind_s(ld, "myuser", "DIGEST-MD5", &cred, NULL, NULL, NULL); This fails with the error 49 ldap_sasl_bind_s: Invalid credentials (49) additional info: 80090326: LdapErr: DSID-0C0904D1, comment: AcceptSecurityContext error, data 57, v1772 Note: I am using Active Directory. And I believe that my cyrus-sasl installation is good. I searched a lot but couldn't find the proper documentation for this. Do I have to fill up cred.bv_val differently while using DIGEST-MD5? Is there an OpenLDAP API to do that? Can someone explain or point me to the right documentation? Thanks and Regards, Shankar

5 9

attribute "reqEnd" undefined
by Peter Clark 26 Jul '10

26 Jul '10

Hello, I upgraded (portmanager on FreeBSD) my openldap install on a delta-synch master and client machines on Friday. All of the client machines upgraded without a hitch and restarted correctly. The master failed with this error on the console: /usr/local/etc/openldap/slapd.conf: line 60: index attribute "reqEnd" undefined Line 60 is from the accesslog definitions: # Accesslog database definitions database bdb suffix cn=accesslog directory /var/db/openldap-data/accesslog rootdn cn=accesslog index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart I changed the loglevel to -1 and tried to start the process. Here is the log output: Jul 26 08:12:04 vanity slapd[55419]: @(#) $OpenLDAP: slapd 2.4.23 (Jul 23 2010 16:39:09) $ blah@vanity:/usr/ports/net/openl dap24-server/work/openldap-2.4.23/servers/slapd Jul 26 08:12:04 vanity slapd[55419]: line 21 (gentlehup on) Jul 26 08:12:04 vanity slapd[55419]: line 24 (pidfile /var/run/openldap/slapd.pid) Jul 26 08:12:04 vanity slapd[55419]: line 25 (argsfile /var/run/openldap/slapd.args) Jul 26 08:12:04 vanity slapd[55419]: line 28 (modulepath /usr/local/libexec/openldap) Jul 26 08:12:04 vanity slapd[55419]: line 29 (moduleload back_bdb) Jul 26 08:12:04 vanity slapd[55419]: loaded module back_bdb Jul 26 08:12:04 vanity slapd[55419]: bdb_back_initialize: initialize BDB backend Jul 26 08:12:04 vanity slapd[55419]: bdb_back_initialize: Berkeley DB 4.6.21: (September 27, 2007) Jul 26 08:12:04 vanity slapd[55419]: module back_bdb: null module registered Jul 26 08:12:04 vanity slapd[55419]: line 35 (sizelimit 262144) Jul 26 08:12:04 vanity slapd[55419]: line 36 (timelimit 300) Jul 26 08:12:04 vanity slapd[55419]: line 39 (TLSCACertificateFile /usr/local/openssl/myCA/ca-cert.pem) Jul 26 08:12:04 vanity slapd[55419]: line 40 (TLSCertificateFile /usr/local/openssl/myCA/vanity.mtmary.edu.cert) Jul 26 08:12:04 vanity slapd[55419]: line 41 (TLSCertificateKeyFile /usr/local/openssl/myCA/vanity.mtmary.edu.key) Jul 26 08:12:04 vanity slapd[55419]: line 42 (TLSRandFile /dev/random) Jul 26 08:12:04 vanity slapd[55419]: line 55 (database bdb) Jul 26 08:12:04 vanity slapd[55419]: bdb_db_init: Initializing BDB database Jul 26 08:12:04 vanity slapd[55419]: line 56 (suffix cn=accesslog) Jul 26 08:12:04 vanity slapd[55419]: >>> dnPrettyNormal: <cn=accesslog> Jul 26 08:12:04 vanity slapd[55419]: <<< dnPrettyNormal: <cn=accesslog>, <cn=accesslog> Jul 26 08:12:04 vanity slapd[55419]: line 57 (directory /var/db/openldap-data/accesslog) Jul 26 08:12:04 vanity slapd[55419]: line 58 (rootdn cn=accesslog) Jul 26 08:12:04 vanity slapd[55419]: >>> dnPrettyNormal: <cn=accesslog> Jul 26 08:12:04 vanity slapd[55419]: <<< dnPrettyNormal: <cn=accesslog>, <cn=accesslog> Jul 26 08:12:04 vanity slapd[55419]: line 59 (index default eq) Jul 26 08:12:04 vanity slapd[55419]: line 60 (index entryCSN,objectClass,reqEnd,reqResult,reqStart) Jul 26 08:12:04 vanity slapd[55419]: index entryCSN 0x0004 Jul 26 08:12:04 vanity slapd[55419]: index objectClass 0x0004 Jul 26 08:12:04 vanity slapd[55419]: slapd destroy: freeing system resources. Jul 26 08:12:04 vanity slapd[55419]: slapd stopped. Jul 26 08:12:04 vanity slapd[55419]: connections_destroy: nothing to destroy. Any help in figuring this out would be appreciated. Peter

2 2

PAM not warning for password expiration
by Obbink, D. (Dannie) 26 Jul '10

26 Jul '10

Hello list, First of all; sorry if this is on the wrong list, reaches the wrong people, has been asked 1000 times before, or is just a basic or stupid question. Yes, I have searched Google and the mailing list archives. We (succesfully) implemented ppolicy on our 2.4.22 OpenLDAP server. Password constraints are enforced correctly, but letting the accounts expiry correctly seems a bit tricky. When users with an expired account try to log on to an application making a bind using the user's own credentials, everything works as expected; users cannot login, access gets denied. In the slapd logging, the following message is displayed: Jul 21 14:06:25 slapd2.4[27182]: ppolicy_bind: Entry uid=<user> has an expired password: 0 grace logins But when trying to log into PAM (ssh, su etc.), there is no warning displayed the account is expired. The user is also allowed to login normally. I've been Googling for a couple of days now, and can't really find the culprit. I was especially interested in this thread: http://www.openldap.org/lists/openldap-technical/201003/msg00197.html So, I've set pwdExpireWarning to 1 second less then pwdMaxAge. When I try to bind directly, such as with an ldapsearch, the logging shows Jul 22 15:31:56 slapd2.4[27182]: ppolicy_bind: Setting warning for password expiry for uid=<user> = 4318121 seconds So, that seems to be correct. But, when logging in via PAM, the log does not display the "setting warning". ldap.conf on the clients read: binddn cn=<binddn> base <base> bindpw <secret> <mailto:P4ons@Ldap> uri ldaps://<master1> <ldaps://<master1>> ldaps:// <ldaps://isibsu0019.iscbeheer.local> <master2> ssl yes bind_timelimit 2 tls_checkpeer yes tls_ciphers TLSv1 tls_cacertdir /etc/ssl/openldap2.4 pam_password crypt pam_check_host_attr yes pam_lookup_policy yes I think this is caused by PAM using the bindDN and then *querying* the user. So the server does not set a password expiry warning. But as I understood, "pam_lookup_policy" should ensure PAM trying to query for an expiry date. How can I configure PAM to display the "Your password will expire in ... days"? /etc/pam.d/system-auth: auth required /lib/security/$ISA/pam_tally2.so onerr=succeed audit auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so broken_shadow account sufficient /lib/security/$ISA/pam_localuser.so account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet account [default=bad success=ok user_unknown=ignore service_err=ignore] /lib/security/$ISA/pam_ldap.so account [default=bad success=ok user_unknown=ignore service_err=ignore] /lib/security/$ISA/pam_krb5.so account required /lib/security/$ISA/pam_permit.so password requisite /lib/security/$ISA/pam_cracklib.so retry=3 type= password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/$ISA/pam_ldap.so use_authtok password sufficient /lib/security/$ISA/pam_krb5.so use_authtok password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_krb5.so sshd_config shows "UsePAM yes" Again, sorry if this is not a question for this list. Thanks you for any responses, Dannie Obbink -------------------------Disclaimer------------------------------- De informatie verzonden met dit e-mailbericht (en bijlagen) is uitsluitend bestemd voor de geadresseerde(n) en zij die van de geadresseerde(n) toestemming kregen dit bericht te lezen. Gebruik door anderen dan geadresseerde(n) is verboden. De informatie in dit e-mailbericht (en bijlagen) kan vertrouwelijk van aard zijn en kan binnen het bereik vallen van een geheimhoudingsplicht en een verschoningsrecht. -------------------------------------------------------------------

1 0

OpenLDAP for lager number of entries
by Marcelo 25 Jul '10

25 Jul '10

Hi, My organization works with public software, and we are interested in use OpenLDAP to control close of 100,000,000 users. Is it a good idea? What kind of database can we use? Is there some research that points what is the limit for the volume of users? Thanks, Marcelo

2 1

Re: segmentation fault when attempting to delete olcOverlay={0}syncprov entry in cn=config (Runtime) Configuration
by jon brandt 23 Jul '10

23 Jul '10

Here is the # of the bug report on bugzilla. Bug 625219 Submitted "OpenLDAP server 2.4.21-47.1 crashes (segmentation fault) when deleting syncprov overlay entry in cn=config configuration" On Thu, Jul 22, 2010 at 2:06 AM, Ralf Haferkamp <rhafer(a)suse.de> wrote: > Am Mittwoch 21 Juli 2010, 20:02:43 schrieben Sie: > > Hi Ralf, > > Sorry for not replying to the entire list, but I have 2 reasons: > > > > 1) I am working on adding the bug report to bugzilla (got my account, > > ect.) ... wasn't sure what product to file the bug under. > openSUSE 11.3 should be fine in your case. (BTW, which product did you > install the 2.4.21 package on?) > > > 2) While searching around other "openLdap" bug reports I found this > > one: *Bug 384787 - OpenLDAP packages do not contain overlays ( > > https://bugzilla.novell.com/show_bug.cgi?id=384787 ) > > *Which is EXACTLY my other issue I am trying to figure out ;o) ... > > Before I submit a detailed report at OpenLDAP.org, maybe you can > > answer this question for me (I can then post in a new email thread as > > not to mess up the current "delete issue" thread). > > > > In 384787, you say that all the overlays are "compiled statically into > > the slapd daemon". How do I fill in the olcModulePath value? I have > > this, and it doesn't seem to be working: > > > > dn: cn=module{0} > > objectClass: olcModuleList > > cn: module{0} > > olcModulePath: ../../../servers/slapd/overlays > > olcModuleLoad: {0}syncprov.la > As the overlays are compiled statically into the slapd binary there is no > need to load any module. So you can just leave out the cn=module object. > > > I still get this error message on both my servers ("do_syncrep2: got > > search entry withour Sync State control"). How do I configure the > > syncprov.laproperly in cn=config ... It works just fine the old way > > using slapd.conf > > files ... > It's a bit hard to tell, what got wrong there. But it could be e.g. that > you try to replicate a database which doesn't have the syncprov overlay > configured. Take a look at your provider's configuration and check that > each database that you want to replicate has the syncprov overlay > configured. If that doesn't help. Open a new thread on openldap-technical > containing the complete configuration (excluding the Schema) for the > provider and the consumer. > > regards, > Ralf > > > On Wed, Jul 21, 2010 at 11:54 AM, Ralf Haferkamp <rhafer(a)suse.de> > wrote: > > > Am Mittwoch 21 Juli 2010, 18:26:58 schrieb jon brandt: > > > > Thanks for the reply Ralf! > > > > > > > > I got the RPMs for SUSE I believe (i.e. I didn't build the server > > > > myself), so I'm assuming the DSLAP_CONFIG_DELETE flag was used. > > > > > > Yes, probably. Might I ask you to open a bug report at > > > bugzilla.novell.com? So we can fix it and probably release an > > > updated RPM. > > > > > > > All > > > > the other deletes work fine (I'm adding then deleting other > > > > directives, for example olcMirrorMode or olcDbIndex and those > > > > delete just fine from cn=config). > > > > > > Yes. The problematic thing is deleting complete objects (e.g. > > > overlays, databases). Deleting single Attributes should work just > > > fine and doesn't require -DSLAP_CONFIG_DELETE. > > > > > > > I will try to upgrade to a newer version > > > > and see if that helps. > > > > > > It'll probably just deny to execute the operations (e.g. when > > > removing overlay entries from the frontend or config db). But I > > > consider that better than crashing the server :). > > > > > > regards, > > > > > > Ralf > > > > > > > > What is strange is that this fails on most of > > > > the servers I have setup, but there there is one server that has a > > > > bit more horsepower that doesn't have the issue, so this leads me > > > > to believe it is a timing related issue. > > > > > > > > On Wed, Jul 21, 2010 at 9:18 AM, Ralf Haferkamp <rhafer(a)suse.de> > wrote: > > > > > Am Dienstag 20 Juli 2010, 20:25:46 schrieb jon brandt: > > > > > > I looked but couldn't find a match to this issue, so was > > > > > > wondering if anyone else has seen something like it or can > > > > > > tell what might be wrong in my configuration. Thanks in > > > > > > advance! > > > > > > > > > > > > I'm using OpenLDAP version 2.4.21-47.1 (here is the relevant > > > > > > output from "rpm -qa | grep ldap" on my server): > > > > > > > > > > > > openldap2-client-2.4.21-51.1 > > > > > > openldap2-2.4.21-47.1 > > > > > > openldap2-back-meta-2.4.21-51.1 > > > > > > > > > > > > I'm trying to get Multi-master replication working between 2 > > > > > > servers. In my testing, I have discovered that when I try to > > > > > > reset the server (remove the configuration and start again) it > > > > > > crashes when trying to remove the > > > > > > olcOverlay={0}syncprov,olcDatabase={0}config,cn=config entry > > > > > > in the cn=config tree. I attached a screen shot of the > > > > > > output from tracing with slapd -d -1 when the fault happened > > > > > > in the attached file called * segFaultOutput.bmp.* > > > > > > > > > > > > If I restart the server, I can run the test again (which > > > > > > configures the olcOverlay={0}syncprov entry and then removes > > > > > > it) and it will work the first time, but if I run it a second > > > > > > time it will crash. > > > > > > > > > > Hm, did you build your server with -DSLAP_CONFIG_DELETE? If yes, > > > > > please note that delete support in cn=config is still > > > > > experimental. So please test again with cvs HEAD if it works > > > > > there. There have been some changes/fixes in that area > > > > > recently. > > > > > > > > > > If you didn't compile with -DSLAP_CONFIG_DELETE please make a > > > > > bugreport slapd should have rejected the delete operation in > > > > > that case. >

1 0

segmentation fault when attempting to delete olcOverlay={0}syncprov entry in cn=config (Runtime) Configuration
by jon brandt 23 Jul '10

23 Jul '10

I looked but couldn't find a match to this issue, so was wondering if anyone else has seen something like it or can tell what might be wrong in my configuration. Thanks in advance! I'm using OpenLDAP version 2.4.21-47.1 (here is the relevant output from "rpm -qa | grep ldap" on my server): openldap2-client-2.4.21-51.1 openldap2-2.4.21-47.1 openldap2-back-meta-2.4.21-51.1 I'm trying to get Multi-master replication working between 2 servers. In my testing, I have discovered that when I try to reset the server (remove the configuration and start again) it crashes when trying to remove the olcOverlay={0}syncprov,olcDatabase={0}config,cn=config entry in the cn=config tree. I attached a screen shot of the output from tracing with slapd -d -1 when the fault happened in the attached file called * segFaultOutput.bmp.* If I restart the server, I can run the test again (which configures the olcOverlay={0}syncprov entry and then removes it) and it will work the first time, but if I run it a second time it will crash. Here is the configuration from the ldif files in /etc/openldap/slapd.d *cn=config.ldif:* dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: 8d35d270-286b-102f-998d-8313efe688a2 creatorsName: cn=config createTimestamp: 20100720165657Z entryCSN: 20100720165733.055688Z#000000#00c#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100720165733Z contextCSN: 20100720165732.317584Z#000000#000#000000 contextCSN: 20100720165733.125549Z#000000#00c#000000 *cn=schema.ldif*: dn: cn=schema objectClass: olcSchemaConfig cn: schema structuralObjectClass: olcSchemaConfig entryUUID: 8d35e49a-286b-102f-998e-8313efe688a2 creatorsName: cn=config createTimestamp: 20100720165657Z entryCSN: 20100720165657.613177Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100720165657Z *olcDatabase={0}config.ldif*: dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcRootDN: cn=manager,cn=config olcRootPW:: Y29uZmln structuralObjectClass: olcDatabaseConfig entryUUID: 8d37bc20-286b-102f-9993-8313efe688a2 creatorsName: cn=config createTimestamp: 20100720165657Z entryCSN: 20100720165657.625245Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100720165657Z *olcDatabase={1}bdb.ldif:* dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=phoenix,dc=com olcRootDN: cn=manager,dc=phoenix,dc=com olcRootPW:: c2VjcmV0 structuralObjectClass: olcBdbConfig entryUUID: 8d37ea88-286b-102f-9995-8313efe688a2 creatorsName: cn=manager,cn=config createTimestamp: 20100720165657Z entryCSN: 20100720165733.125549Z#000000#00c#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100720165733Z *olcDatabase={-1}frontend.ldif:* dn: olcDatabase={-1}frontend objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 8d37c1a2-286b-102f-9994-8313efe688a2 creatorsName: cn=config createTimestamp: 20100720165657Z entryCSN: 20100720165657.625397Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100720165657Z the cn=schema directory has the following (I'm not going to paste the contents of these files): cn={0}core.ldif cn={1}cosine.ldif cn={2}inetorgperson.ldif cn={3}nis.ldif

3 5

back-sql caching
by Frederik Bosch 23 Jul '10

23 Jul '10

Hello, With BackSQL I am trying to make my SQL data available for LDAP purposes. Setup went OK, server starts and my data is available. I have one problem. Modifications in the SQL data do not seem to be executed until I restart slapd. As if the SQL data is cached. My setup uses openldap_2.4.11-1+lenny1 which I recompiled using debuild to enable backsql. My sqlserver is MySQL 5.0.5. So, starting slapd won't generate any errors or problems. When I delete or modify a row - with an other interface (directly accessing the SQL server) then LDAP - slapd does not seem to notify the changes. By enabling query logging for MySQL I found out that it actually executes a new SQL statement. So the problem seems to take place when the resultset is processed. Inserting a new row to ldap_entries gives exactly the same problem. It is not found until the slapd is restarted. When I started slapd with -d 16383 I found the line <==backsql_oc_get_candidates(): 0 which confirms my problem in this case. Annoyingly, restarting the server solves the problem (temporarily). The data modifications are found and the correct tree is available. In order to maintain correct data I could restart slapd each 5 minutes, but I think such a solution should be avoided in any case. Does anyone have a suggestion what could be wrong with my setup? Thanks in advance. Frederik Bosch

2 3

Error "got search entry without sync state control" on N-Way Multimaster cn=config Runtime Configuration
by jon brandt 23 Jul '10

23 Jul '10

I'm getting this error when trying to get N-Way Multimaster configuration working between two servers using cn=config (Runtime Configuration) method: "do_syncrep2: rid=002 got search entry without SyncState control" >From some searching around, I found out this normally means the provider side doesn't have the syncprov overlay configured correctly. I think I have the correct syncprov overlay configured in both my servers (I get the same error on both), but I must have something messed up. I did find this very helpful link in the SUSE bugzilla database (bug 384787): https://bugzilla.novell.com/show_bug.cgi?id=384787 This cleared up some confusion I had with regard to the olcModuleLoad: syncprov.la which the OpenLDAP documentation describes as needed in cn=config. Apparently that is out of date info according to Ralf H. who responded to the above report. He mentions that the overlays are compiled into slapd now, so this isn't needed. Thanks Ralf! Anyway, with or without the olcModuleLoad stuff, my configuration still doesn't work correctly. Here it is, and any help is very much appreciated! Note that I left out the schema ldif files below, they are the following standard ones: core, cosine, inetorgperson, nis. Server 1 (linux-h4bt): *cn=config.ldif* dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: b0a2110e-2926-102f-9fef-bbe8cc5f05fe creatorsName: cn=config createTimestamp: 20100721151632Z olcServerID: 3 entryCSN: 20100721160215.521297Z#000000#000#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160215Z contextCSN: 20100721160232.622424Z#000000#003#000000 *cn=module{0}.ldif* dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: ../../../servers/slapd/overlays olcModuleLoad: {0}syncprov.la structuralObjectClass: olcModuleList entryUUID: 1d89971e-292d-102f-9f46-af88272e60b3 creatorsName: cn=manager,cn=config createTimestamp: 20100721160232Z entryCSN: 20100721160232.622424Z#000000#003#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160232Z *olcDatabase={0}config.ldif* dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcRootDN: cn=manager,cn=config olcRootPW:: Y29uZmln structuralObjectClass: olcDatabaseConfig entryUUID: b0a2daa8-2926-102f-9ff5-bbe8cc5f05fe creatorsName: cn=config createTimestamp: 20100721151632Z entryCSN: 20100721151632.935961Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100721151632Z *olcDatabase={1}bdb.ldif* dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=phoenix,dc=com olcRootDN: cn=manager,dc=phoenix,dc=com olcRootPW:: c2VjcmV0 structuralObjectClass: olcBdbConfig entryUUID: b0a2ed7c-2926-102f-9ff7-bbe8cc5f05fe creatorsName: cn=manager,cn=config createTimestamp: 20100721151632Z olcAccess: {0}to attrs=userPassword by * auth by * +0 break olcAccess: {1}to * by dn.base="cn=manager,dc=phoenix,dc=com" read by * +0 br eak olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcSyncrepl: {0}rid=002 provider=ldap://unidome88xxx bindmethod=simple timeout =0 binddn="cn=manager,dc=phoenix,dc=com" credentials="secret" starttls=no fil ter="(objectclass=*)" searchbase="ou=users,dc=phoenix,dc=com" scope=sub attrs ="*,+" schemachecking=off type=refreshAndPersist retry="5 5 300 +" olcMirrorMode: TRUE entryCSN: 20100721160215.966913Z#000000#003#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160215Z *olcDatabase={-1}frontend.ldif* dn: olcDatabase={-1}frontend objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: b0a2dddc-2926-102f-9ff6-bbe8cc5f05fe creatorsName: cn=config createTimestamp: 20100721151632Z entryCSN: 20100721151632.936051Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100721151632Z *olcOverlay={0}syncprov.ldif* dn: olcOverlay={0}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 structuralObjectClass: olcSyncProvConfig entryUUID: 135f0e4a-292d-102f-9f45-af88272e60b3 creatorsName: cn=manager,cn=config createTimestamp: 20100721160215Z entryCSN: 20100721160215.566453Z#000000#003#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160215Z Server 2 (unidome88xxx): *cn=config.ldif* dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: 24af41c0-292c-102f-9291-b374f89e9aa0 creatorsName: cn=config createTimestamp: 20100721155535Z olcServerID: 2 entryCSN: 20100721160201.051314Z#000000#000#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160201Z contextCSN: 20100721160215.084570Z#000000#002#000000 *cn=module{0}.ldif* dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: ../../../servers/slapd/overlays olcModuleLoad: {0}syncprov.la structuralObjectClass: olcModuleList entryUUID: 1315872a-292d-102f-8dcc-97104602b49d creatorsName: cn=manager,cn=config createTimestamp: 20100721160215Z entryCSN: 20100721160215.084570Z#000000#002#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160215Z *olcDatabase={0}config.ldif* dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcRootDN: cn=manager,cn=config olcRootPW:: Y29uZmln structuralObjectClass: olcDatabaseConfig entryUUID: 24b12f3a-292c-102f-9297-b374f89e9aa0 creatorsName: cn=config createTimestamp: 20100721155535Z entryCSN: 20100721155535.129218Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100721155535Z *olcDatabase={1}bdb.ldif* dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=phoenix,dc=com olcRootDN: cn=manager,dc=phoenix,dc=com olcRootPW:: c2VjcmV0 structuralObjectClass: olcBdbConfig entryUUID: 24b1553c-292c-102f-9299-b374f89e9aa0 creatorsName: cn=manager,cn=config createTimestamp: 20100721155535Z olcAccess: {0}to attrs=userPassword by * auth by * +0 break olcAccess: {1}to * by dn.base="cn=manager,dc=phoenix,dc=com" read by * +0 br eak olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcSyncrepl: {0}rid=002 provider=ldap://linux-h4bt bindmethod=simple timeout=0 binddn="cn=manager,dc=phoenix,dc=com" credentials="secret" starttls=no filte r="(objectclass=*)" searchbase="ou=users,dc=phoenix,dc=com" scope=sub attrs=" *,+" schemachecking=off type=refreshAndPersist retry="5 5 300 +" olcMirrorMode: TRUE entryCSN: 20100721160201.689045Z#000000#002#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160201Z *olcDatabase={-1}frontend.ldif* dn: olcDatabase={-1}frontend objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 24b134a8-292c-102f-9298-b374f89e9aa0 creatorsName: cn=config createTimestamp: 20100721155535Z entryCSN: 20100721155535.129372Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100721155535Z *olcOverlay={0}syncprov.ldif* dn: olcOverlay={0}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 structuralObjectClass: olcSyncProvConfig entryUUID: 0adcc5dc-292d-102f-8dcb-97104602b49d creatorsName: cn=manager,cn=config createTimestamp: 20100721160201Z entryCSN: 20100721160201.290849Z#000000#002#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100721160201Z * *

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical