its 2.2.20 :(
On Nov 13, 2007 2:48 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> --On Tuesday, November 13, 2007 2:38 PM -0500 Naufal Sheikh
> <naufalzamir(a)gmail.com> wrote:
> > Hello everyone,
> > Is there anyway to detetct the modifications made and/or
> > addition,subtraction made to directory for a certain period of time
> > without using replication? I will be running openldap on my backup
> > machine for two hours and I am not sure how I can see if there were
> > any changes made during those two hours, so that I can do the same on
> > my production.
> Assuming OpenLDAP 2.3 or later, set up an accesslog database.
> Quanah Gibson-Mount
> Principal Software Engineer
> Zimbra, Inc
> Zimbra :: the leader in open source messaging and collaboration
>> In other words, you have software that was broken for the past 10 years
>> that RFC2251 was in effect, before RFC4511 was written to allow your
>> software vendor to get away with never fixing their broken code. Nice.
> What makes you think my software is that old? Sort of telepathy?
> I think they added functionality we talk about just in the past year.
> All: and guys, I don't understand why the simple fact which was completely
> explained by Hallvard, leads to your negative reaction.
I never said that, I merely meant for you to re-read Hallvards reply. The
relevant part is:
"In RFC 2251 (the previous revision of LDAPv3), the client had to ensure
the latter: The "MAY or MAY NOT include..." you quoted was "MUST
include". In RFC 4511, that has become the server's job."
So, in RFC 4511, this has become the servers job, i.e. slapd.
I am planning on utilizing OpenLdap as a repository for users and
authentication credentials. I have installed the software and edited
the slapd.conf specific to my domain. In slapd.conf, I noticed that
it includes core.schema, so I took a look inside this file to see what
fields (attributes) are specified. The 'uid' and 'userPassword'
attributes are commented out and since it is recommended not to edit
this file, I was wondering how I go about enabling these attributes?
I have already tried creating another schema file and including that
in my slapd.conf, but when I attempted to run, it stated that those
attributes already exist.
Thanks in advance,
<quote who="Kevin Burnett">
> slapd version: 2.3.32
> on RHEL4 i386
The usual story applies here, please try with our latest version and get
back to us.
> On Nov 11, 2007 1:17 PM, Gavin Henry <ghenry(a)openldap.org> wrote:
>> Kevin Burnett wrote:
>> > I am implementing an OpenLDAP installation that utilizes inetOrgPerson
>> > as the main user structure with roughly forty attributes that may be
>> > used with each user. Of the forty attributes, I have added a custom
>> > schema which includes 15 custom attributes. I am using MySQL 5 as the
>> > backend via backsql.
>> > The problem I am seeing is that for a given user, if I write values to
>> > all 40 attributes and then read them back using an LDAP browser, three
>> > of the attributes do not return their values. The three attributes
>> > are: cn, userPassword, and employeeType.
>> > I have run slapd with the debug level of -1 (all) to capture a trace
>> > of what happens when I read an attribute that correctly returns its
>> > value and also a trace of reading an attribute that does not return
>> > its value (cn, userPassword, or employeeType). Comparing the two
>> > traces, the only appreciable difference between the two is as follows,
>> > which is in the failing trace:
>> > ==>backsql_id2entry()
>> > backsql_id2entry(): custom attribute list
>> > ==>backsql_get_attr_vals(): oc="inetOrgPerson" attr="employeeType"
>> > backsql_get_attr_vals(): error executing attribute count query 'SELECT
>> > COUNT(*) FROM users WHERE users.id=? AND '
>> > Return code: -1
>> > nativeErrCode=1064 SQLengineState=37000 msg="[MySQL][ODBC 3.51
>> > Driver][mysqld-5.0.45-community-log]You have an error in your SQL
>> > syntax; check the manual that corresponds to your MySQL server version
>> > for the right syntax to use near '' at line 1"
>> > ==>backsql_get_attr_vals(): oc="inetOrgPerson" attr="objectClass"
>> > I also set up a MySQL error trace and ran the two attribute reads and
>> > came up with the only appreciable difference being the SQL statement,
>> > as above:
>> > 43 Query SELECT COUNT(*) FROM users WHERE users.id=8 AND
>> > It appears to me that the SQL statement is not being completed for
>> > some reason, since in the slapd trace where the attribute read is
>> > successful, the backsql_get_attr_vals(); just prints out, number of
>> > values in query: 1, followed by, number of values in query: 0,
>> > followed by the actual data packets containing the value of the
>> > attribute.
>> > I can provide additional information if needed. I was unable to find
>> > information about this problem on the OpenLDAP site.
>> > Kevin Burnett
>> You don't say what slapd version you are using. Please provide the
>> Kind Regards,
>> Gavin Henry.
>> OpenLDAP Engineering Team.
>> E ghenry(a)OpenLDAP.org
>> Community developed LDAP software.
<quote who="Howard Chu">
> Greg Martin wrote:
>> Gavin Henry wrote:
>>> Greg Martin wrote:
>>>> Hmmm. I could have sworn the slaptest -f... -F... built the
>>>> config.ldif for me. Its there and I didn't create it. Guess I'll
>>>> try again and see what I get. I really want to understand this.
>>>> Thanks, Howard.
>>> You mean this?
>>> [ghenry@suretec ~]$ ls /usr/local/etc/openldap/slapd.d/
>>> cn=config cn=config.ldif
>> Indeed, I do.
> It seems pretty obvious to me that "ETCDIR/slapd.d/cn=config.ldif" is
> completely different from an arbitrary "config.ldif" residing in an
> unspecified directory mentioned in the slapd-config(5) example.
I hope this is now clear Greg.
I loaded up 2.4.6 for my small home network use. It and the apps
(phpldapadmin, tikiwiki, Webcalendar) that use it are running fine. Sweet!
Now I want to convert to cn=config. I ran:
slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
to build the config, then ran:
slapadd -d -1 -F /etc/openldap/slapd.d -n 0 -l cn=config.ldif
to import it
I get this error:
: config_add_internal: DN="cn=config" already exists
slapadd: could not add entry dn="cn=config" (line=1):
slapadd shutdown: initiated
I tried -c to ignore errors, but this must be serious.
Not much when I ask Google, but I saw a post from Howard months back
that suggested there was a bug surrounding this process and that it was
fixed in the 2.3.x HEAD.
Other than that - no other help.
Is there a way to force overwrite?
A fairly basic question to confirm functionality (and options).
Currently, we have a fairly basic configuration of a "master" server and
then a couple of "slaves" using syncrepl and chaining. All is working great
(in this prototype). We have come across one point we would like to confirm
When an update is sent to a "slave", the updateref tells the slave to make
the update on the master and the client is non-the wiser. That is, until the
master returns an error. If the master returns an error (master unavailable
or master actually returned a non-zero error code), the slave returns the
referral to the client to the master and the client needs to connect to the
master to determine what's up (of course, the client might not have
permissions to do what it needs on the master to even be able to replicate
the same situation to get the same error message?)
Is the above the expected functionality?
Are there options for the above which would pass the error code from the
master to the slave to the client instead of passing the referral of the
master to the client?
Currently using 2.3.38.
Kudos to the OpenLDAP team. This is really pretty slick.
I've configured accesslog overlay on our directory project because all
modification history is very (very) important for us. The most frequent
query (and currently the only query) to the accesslog database is to
look for modification to a certain record. Typically like this:
Currently the database behave strangely:
(reqAuthzID=uid=paul_smith,ou=contacts,ou=xxx,dc=xxx,dc=xxx) -> return
result in 4 seconds
(reqDN=uid=paul_smith,ou=contacts,ou=xxx,dc=xxx,dc=xxx) -> return result
in 4 minutes
The interesting thing: I have configured to index reqDN but not reqAuthzID:
I read the admin's manual (2.4), as in the manual the set up of index is
as simple as configure it in slapd.conf and run slapindex, which I did,
with no error at all.
[snip from slapd.conf]
index reqDN,reqType eq
I also double checked /var/lib/ldap-log to confirm there is "reqDN.dbd"
The total number of modification records is around 50k. Openldap 2.3.27
running on Debian/x86
My question is: The 4 minute search time is not reasonable (Excel can do
much faster with same number of records), and not acceptable for our use
(because checking modification history is daily routine). How can I
improve it? What other information I didn't provider to have asked this
question properly? What else (besides admin manual which only described
indexing a few pages) should I read?
Thanks a lot in advance!
Huateng Tower, Unit 1788
Jia 302 3rd area of Jinsong, Chao Yang
Tel: +86 (10) 8773 0650 ext 603
Mobile: 135 9950 2413
I'm getting the following error when I run getent group:
Nov 8 15:45:29 machine1 slapd: SRCH "ou=Group,dc=mydomain,dc=com" 2 0
Nov 8 15:45:29 machine1 slapd: 0 0 0
Nov 8 15:45:29 machine1 slapd: filter: (objectClass=*)
Nov 8 15:45:29 machine1 slapd: attrs:
Nov 8 15:45:29 machine1 slapd:
Nov 8 15:45:29 machine1 slapd: bdb_idl_fetch_key: @ou=group,dc=mydomain,dc=com
Nov 8 15:45:29 machine1 slapd: connection_get(10)
Nov 8 15:45:29 machine1 slapd: connection_get(10)
Nov 8 15:45:29 machine1 slapd: send_ldap_result: err=0 matched="" text=""
Nov 8 15:45:29 machine1 slapd: connection_get(10)
When I run ldapsearch -Y GSSAPI -b 'ou=group,dc=mydomain,dc=com' I get many records, what is wrong? Here is my /etc/libnss_ldap.conf:
My server is Debian 4 and I installed all packages using apt-get
Discover the new Windows Vista
Is this possible? The only way to connect to my OpenLDAP server is through Kerberos, I disabled all other authentications. I created a principal for nss_ldap and I exported its key to the keytab file on the server. How can I force nss_ldap to use it to connect my ldap server?
Here is the contents of my /etc/libnss_ldap.conf:
Note that my Kerberos is working correctly and I can successfully ldapsearch -Y GSSAPI over a self-signed certificate.
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!