I'm new to the community and apologize if posting to the wrong area. I'm
looking for "_current_" information relating to a forum or documentation on
RHEL Directory Server wrt to application integration. I'm making the
assumption that the FDS is a parallel effort. I've used RHDS for basic user
authentication but would like to do more with it. The docs that come with
it are pretty extensive but really don't cover basic things such as
integrating say autofs etc. Everywhere I read it says things like "you can
easily extend it to do ..." but no where does it say "here's how".
Probably just looking in the wrong places.
If this is the wrong area, please advise on where to post if you know. No
I am running 389 DS version 1.2.5, build number 2010.012.2034 on RHEL 5.2.
I have a problem that slapd didn't close a connection and eventually get
into a CLOSE_WAIT state after my JAVA application exit.
The scenario only happen when my application registers a NamingListener via
the JAVA JNDI (Java Naming Directory Interface). I believe the
NamingListener is equivalent to the Persistent Search. This problem doesn't
exist if I don't use the JNDI NamingListener capability.
>From my understanding, I did everything correctly in my application. I
create a context, add a listener, do some stuffs, remove the listener and
then close the context.
One thing I notice is that in the slapd's error log, I see the following...
"-get_ldapmessage_controls failed: 12 (Unavailable critical extension)
This message prints out right after I remove the listener and before my
application closes the context.
The closest bug report I found is this and it said the problem has been
At this point, I'm clueless. :-(
Can someone help me or give me some recommendation that I could try?
I will attach my JAVA JNDI replicator along with this e-mail. You will need
to modify 2-3 lines of code to get it running in your environment. Search
for "MODIFY ME" and that should be the lines that you need to modify.
I try to migrate an old Netscape Directory Server to 389ds.
When I import the export database, I get a lor of reject because of empty
I get reject like :
Error adding object 'dn: uid=XXXXXX,o=Annuaire,o=directoryRoot'. The error
sent by the server was 'null. l: value #0 invalid per syntax
c: value #0 invalid per syntax
I test with centos-ds 8.1.0 and I didn't get these errors.
Is there a way to configure 389ds to accept empty attributes ?
Ldif example :
cn: XXXXX Christelle
I have been struggling with this one for a while.
In switching to 389, I am trying to figure out how to get my Solaris clients
working with account management and ssh keys. SunDS 5.? has an oid control
that allows for account management and ssh keys to proceed with their
server, and I was wondering if anyone has deal with a similar instance of
such on 389. I would really prefer to use the native ldap settings that
comes with Solaris.
> Message: 2
> Date: Tue, 23 Feb 2010 10:56:41 -0800
> From: "Morris, Patrick" <patrick.morris(a)hp.com>
> Subject: Re: [389-users] RH 3-5 systems hanging requiring autofs
> restart to fix issue
> To: "General discussion list for the 389 Directory server project."
> Message-ID: <4B8424E9.9060004(a)hp.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Charles Gilbert wrote:
> > Hi everyone,
> > I am experiencing an issue with my systems in that autofs, or even
> > nscd or crond hangs after our RH 3, 4, and 5 machines are being used
> > for a while. This issue is causing concern that our LDAP install is
> > not stable obviously, and has sent me on a goose chase to find some
> > answers.
> > Errors I get in the syslog are that automount: nss_ldap: can not
> > contact LDAP server.
> > Make sure you've got the most recent version of nss_ldap. Some of the
> > older Red Hat versions were buggy and could cause screwiness with LDAP
> > lookups.
> I have RH5.3 systems with up to date nss_ldap on it that are also having
> these problems. I am looking right now to verify that all the other systems
> are up todate.
I am trying to make our directory more "user friendly". We are in Spain, so
there are people names like mine, "Juan Asensio Sánchez" (Sánchez with
tilde). Well, i I do a search with filter "(cn=*sánchez)" (with tilde), and
I get my user in the results, but if i try with the filter "(cn=*sanchez)"
(without tilde), i get no results (I understand why). Is there anyway to
make searches using indexes with the attribute nsMatchingRule to behave as I
I have tried with:
in the cn index, but using the second filter "(cn=*sanchez)", i am already
having no results.
NB: I know I can use cn;lang-en, but this implies add more attributes
manually, duplicate similar values, etc.
just one question (maybe silly one, but I have to be sure). Soon, we
will change the IP address of one of our servers running CentOS DS. Are
there any DS configuration files (or file) that need to be changed
accordingly? I took a look at /etc/dirsrv/slapd-instance and parsed for
IP address but there is none. Also, I tried to change IP addres of a
test LDAP server and everything works fine. But, as I mentioned before,
I have to be sure before (maybe there are some other configuration files
that I am not aware of) I do that in production environment? Any
Thanks in advance!
I am experiencing an issue with my systems in that autofs, or even nscd or
crond hangs after our RH 3, 4, and 5 machines are being used for a while.
This issue is causing concern that our LDAP install is not stable obviously,
and has sent me on a goose chase to find some answers.
Errors I get in the syslog are that automount: nss_ldap: can not contact
However, I am not using LDAP to store automount maps. Our home maps are
local files that are read, and the entry in nsswitch.conf has automount:
My theory is that since we are mounting home dirs with automount, it is
trying to verify ownership and permision by contacting the server. However,
after a time of users logging in and out on the servers, I have to log in as
root and restart autofs to allow users to continue to use the system.
I am not sure if this is an issue with tuning 389 or if it is my client
configuration. I have read about instances where soft binds can cause
issues, and instead, people are setting their systems to hard bind and using
the nss_reconnect_ values to prevent the connection from hanging
Any help would be greatly appreciated!
I'm trying to retrieve the csn with ldapsearch and ldapadd/modify.
I need it for syncing ldap with a custom backend.
For now I'm using the modifytimestamp, but for each add/modify I have to issue
a subsequent ldapsearch to retrieve the modifytimestamp...
The control I'm trying to use is the following:
the csn of the entry is reported into fedorads logs.
[18/Feb/2010:17:05:32 +0100] ... ADD dn="piEntryId=1..134c..."
[18/Feb/2010:17:05:33 +0100] RESULT err=0 .. csn=4b7d654e000000010000
Hope somebody can help.
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
Tel. cel +39.340.6522736
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)
"Il seguente messaggio contiene informazioni riservate. Qualora questo
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene
notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto
della legge in materia di protezione dei dati personali."
I have just one problem left that prevent me to migrate from ibm tivoli to
389 ldap. The format of the birthdate
i have generated a date AAAAMMJJHHMMSS with this format but 389 still refuse
to add it must i encode this
also in base64 to be able to use this format ? i have used this trick to add
a space value to a attribute
the syntax of birthdate is generralizetime
#!ERROR [LDAP: error code 21 - birthdate: value #0 invalid per syntax ]