uid not case-sensitiv / How can i modify to octetstring / in core.schema not included / Version 2.3.80 [Virus checked]
by ems＠Sparkassen-Informatik.de
Hello,
i'am new on this List.
We upgraded from openldap 2.2.30 to 2.3.80. (Solaris 10)
Is it right, that in core.schema the entry for uid (and others) is now
removed (commented) ? How can i now found this entry ? Is it hardcoded in
Source ?
The Reason/Problem is, that we have modified the core.schema (in Version
2.2.30) for entry uid, while uid is not case-sensitiv (it allows, that
uid=a4711 is the same as uid=A4711). We need strict lowercase.
So we change some times ago:
attributetype ( 0.9.2342.19200300.100.1.1
NAME ( 'uid' 'userid' )
DESC 'RFC1274: user identifier'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
To new
attributetype ( 0.9.2342.19200300.100.1.1
NAME ( 'uid' 'userid' )
DESC 'RFC1274: user identifier'
EQUALITY octetStringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
OK, it was not good, to modify the core.schema. So i have now an new
local.schema. But when i copy this section to local.schema i got an error
about "duplicate entry". (so i remove it, an local.schema is empty and
LDAP works but with case-insensitiv for uid).
The reason was, that the uid is NOT CaseSensitiv. So with octetStringMatch
the uid was case-sensitiv. And it works fine with Apache and cgi-scripts.
But now, when i upgrade to 2.3.80, first i got an Error, while we use the
"old" core.schema. Then i correct this with the original core.schema and
it will now work.
But i can not found any place, how uid is defined in Version 2.3.80.
in slapd.conf we include
include /soft/openldap/etc/openldap/schema/core.schema
include /soft/openldap/etc/openldap/schema/cosine.schema
include /soft/openldap/etc/openldap/schema/nis.schema
include /soft/openldap/etc/openldap/schema/local.schema
How can i change uid ? Or how can i overwrite it ?
Many thanks
MFG
K.H.O.
16 years
Can't see DIT
by Daniel Guerrero
Hi all,
I'm trying to see my DIT with ldapsearch, but I can't see anything... the
answer is the following:
prompt> ldapsearch -x -b "dc=example,dc=com"
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 2
result: 32 No such object
I added two identities, one organisational unit and an object included in
this ou, without errors.
I think is not rellevant, but i could authenticate remotely with the rootdn
user and password.
Is there any other way to check the database to see if there has been any
error adding the ou and the object?
I attach my slapd.conf file, but i can bring more information, only if
needed.
Thank you very much.
16 years
Advice on restoring database and keeping kerberos mappings to users in the database
by Ezra Taylor
Hello all:
I'm running Openldap version 2.2.13-7.4E and kerberos on
Redhat 4 u4. I know we are in desperate need of an upgrade. I noticed that
the database is corrupted and would like to know if I do a restore with
slapadd if the Kerberos passwords continue to map with the users in ldap
database? If not, what tasks do I have to execute to map the kerberos
passwords with the users in the ldap database?
Thanks for all your help.
--
Ezra Taylor
16 years
Re: optimal index for ldap
by Ace
> The problem here is when I have index on cn, it didn't finds what I search
> for. Here is search query -
> ldapsearch -x -b "dc=zlemail,dc=com" "(cn=rr1)"
>Did you consult the documentation? For instance, please see the section on
the
>index directive in the man page for slapd-bdb. It says:
>
>"Note: changing index settings in
> slapd.conf(5) requires rebuilding indices, see
>slapindex(8);"
Thanks Buchan! I did slapdindex and its working fine now.....Thanks once
again for your help!
> Now if I remove index on cn, it does finds record but complains about
index
> failed on cn. Also it takes considerable amount of time for search
> operation to complete. Do I need to revisit my ldap database structuring?
--
I may be miles away... but I am just a mail away.... so keep mailing...!!!
Cheers,
Rajan
16 years
Re: optimal index for ldap
by Ace
On Wednesday 19 September 2007 15:52:02 Ace wrote:
>> Hi Masters,
>>
>> We have around 100000 entries of the form -
>>
>> dn: cn=rr1,ou=addressbook,dc=zlemail,dc=com
>> objectClass: top
>> objectClass: inetOrgPerson
>> mail: rr1(a)oo.com
>> userPassword: a@123
>> cn: rr1
>> sn: rr1
>>
>> What should be the index for fast search?
>As Quanah and Aaron replied, the search filters you use will determine the
>indexes you need.
>However, most mail clients will search on the cn, sn, and maybe the mail
>attribute, so you probable need equality and substring indexes on those 3
>attributes, plus the standard equality index on objectclass. It is unlikely
>that you will need to index userPassword.
Ok. I tried having indexes on cn, sn and mail as -
index default eq
index cn eq,pres
index sn eq, pres
index mail eq,pres
index objectClass eq
The problem here is when I have index on cn, it didn't finds what I search
for. Here is search query -
ldapsearch -x -b "dc=zlemail,dc=com" "(cn=rr1)"
Now if I remove index on cn, it does finds record but complains about index
failed on cn. Also it takes considerable amount of time for search operation
to complete. Do I need to revisit my ldap database structuring?
>However, I note that with a relatively large database, your entry cache and
>backend database cache tuning is also critical to performance.
Yes. I am using cachesize = 1000000 and DB_CONFIG file same as
DB_CONFIG.example (no changes made)
>If you are seeing high CPU utilisation, check the logs for errors relating
to
>indexes, and add the indexes slapd is complaining are missing. If you have
>high load average but low CPU utilisation (thus high load due to IO wait),
>you need to look at your cache tuning.
Its a high CPU utilization. Refer above reply for index problem.
>For anyone to provide more assistance, you need to provide more details on
>your configuration (OpenLDAP version, backend you are using, any tuning you
>have done, possibly the sizes of the files in your database directory).
My LDAP version is 2.3.32, bdb backend.
>Regards,
>Buchan
--
I may be miles away... but I am just a mail away.... so keep mailing...!!!
Cheers,
Rajan
16 years
optimal index for ldap
by Ace
Hi Masters,
We have around 100000 entries of the form -
dn: cn=rr1,ou=addressbook,dc=zlemail,dc=com
objectClass: top
objectClass: inetOrgPerson
mail: rr1(a)oo.com
userPassword: a@123
cn: rr1
sn: rr1
What should be the index for fast search?
--
I may be miles away... but I am just a mail away.... so keep mailing...!!!
Cheers,
Rajan
16 years
Can I delete the database to start over
by Keryx Info
Hi again
Having experimented with my first installation of OpenLDAP I've come to
the conclusion that I had better start all over. Is the following
procedure safe (using Fedora 7)?
1. service ldap stop
2. delete slapd.conf and ldap.conf
3. delete all contents in /var/lib/ldap
4. Create a new slapd.conf and ldap.conf
5. Service ldap start
+ Anything else I should do?
Lars Gunther
16 years
TLS handshake failure
by Esther Puente
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I follow the instructions in
http://www.openldap.org/faq/data/cache/185.html and in other
tutorials from the Web for activate TLS and use a CA and I can't get it
works right. The error I obtained is a "Handshake failure".
Somebody can help me?
I paste you my slapd.conf and my ldap.conf:
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
database bdb
suffix "dc=abc,dc=es"
checkpoint 32 30 # <kbyte> <min>
rootdn "cn=Manager,dc=abc,dc=es"
rootpw asdhjka
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/openldap-data
# Indices to maintain
index objectClass eq
TLSCACertificateFile /etc/openldap/ssl/cacert.pem
TLSCertificateFile /etc/openldap/ssl/certs/servidorcert.pem
TLSCertificateKeyFile /etc/openldap/ssl/private/servidorkey.pem
TLSVerifyClient demand
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
BASE dc=abc,dc=es
URI ldap://localhost ldaps://localhost
PORT 636
TLS_CACERT /etc/openldap/ssl/cacert.pem
TLS_CERT /etc/openldap/ssl/clientecert.pem
TLS_KEY /etc/openldap/ssl/clientekey.pem
TLS_REQCERT demand
- --
AVISO: Las opiniones expresadas en este mensaje son estrictamente
personales y no es una posición oficial de la Universidade da Coruña.
AVISO LEGAL: Este mensaje y sus ficheros adjuntos tienen carácter
privado y confidencial y van dirigidos exclusivamente a sus
destinatarios. Si ha recibido este mensaje por error, no debe revelarlo,
copiarlo o distribuirlo en ningún sentido sin previo consentimiento por
escrito del destinatario. Rogamos lo comunique al remitente y elimine
dicho mensaje y cualquier documento adjunto que pudiera contener. De no
hacerlo así puede vulnerar la legislación vigente.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7-ecc0.1.6 (GNU/Linux)
iD8DBQFG77c4M/ZbFVfHDjwRArWtAJ0fcj68YMSLOK4yIF+Yts1QFb9arACdHnKw
YADPlfMT51Iny0NhupLqgFY=
=hVor
-----END PGP SIGNATURE-----
16 years
What is this? It doesn't work...
by Hex Star
I don't understand how complicated software like this gets widely deployed
and accepted when documentation on it is so limited and unclear... It is
quite difficult to get ldap to function properly and am left with the
question of how the hell anyone can figure out how to get this piece of
software to do anything! If there was some form of acceptable
documentation....
16 years
cn=config crashes on modification
by Dieter Kluenter
Hi,
I am experiencing weird errors with 2.4.5beta, i.e. modifying config
backand for example I get
=> access_allowed: read access to "olcDatabase={1}hdb,cn=config" "olcDbDNcacheSize" requested
<= root access granted
=> access_allowed: read access granted by manage(=mwrscxd)
<= acl_access_allowed: granted to database root
filter_free: unknown filter type=1168
*** glibc detected *** double free or corruption (out): 0x085c46c0 ***
Abgebrochen
Is this a bug. a corrupted cn=config database or is glibc-2.3.4-23.4
the reason?
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dkluenter.de
GPG Key ID:8EF7B6C6
16 years
