I'm running FC14 and I'm having a hell of a time trying to get my client
authenticating to my 389-ds server.
Here are the specs
389-ds server: FC13
Client machines are a mix of FC 13 and FC14
I have SSL set up and listening on port 636. I used
system-config-authentication to set up the client. When I run getent passwd
<username> there is not output on the client, but I see a query in the
server. Am I missing a step?
I have followed the instructions of the SSL Howto, but I am still stick at
the SSL activation.
>From a clean installation, I try to launch the setupssl.sh script, but at
the end, I have
ldapmodify: invalid format (line 11) entry: "cn=encryption,cn=config"
There is not specific configuration except that I use the port 9831 for my
DS instead of 389 (I already use the standard LDAP port for OpenLDAP and I
do not want to migrate (it is for testing)). I have modified the setupssl
script to execute on this port.
If I just try the end of the script, you can see the error :
ldapmodify -x -h localhost -p 9831 -D "cn=Directory Manager" -W <<EOF
nsSSLToken: internal (software)
Enter LDAP Password:
ldapmodify: invalid format (line 11) entry: "cn=encryption,cn=config"
I have checked every part of these ldif data. The error is here :
But if I do the modifications except this piece of code, ldaps can be
started on the port 636, but the cert files could not be loaded from dirsrv,
so I can not do any request in SSL... I also try to :
- edit dse.ldif file in the dirsrv DS configuration directory and delete
the line corresponding to the cert files as Red Hat documentation tells
(after stoping dirsrv service). We can see that dirsrv reload the cert files
in the dse.ldif file, but it changed nothing.
- delete every *.db and *.txt files and cacert.csa. Then, if I reexecute
setupssl.sh, it generates the cert files, but (again), there is no
Obviously, if I open 389-console, I could see this string in the properties
I have checked my real hostname and other stuffs specified in the
documentation... I know that I do not use the standard LDAP port but I do
not see why this section could not work... Other ldap request on this port
Sorry for my bad english...
Any help would be gracefull !
After updating to the latest 389-ds packages I can connect to my admin
console again but I happened to notice that the version displayed when I
click on Directory Server shows 1.2.6 but yum says differently:
Name : 389-ds-base
Arch : x86_64
Version : 18.104.22.168
Release : 1.fc14
Size : 5.5 M
Repo : installed
>From repo : updates
Summary : 389 Directory Server (base)
URL : http://port389.org/
License : GPLv2 with exceptions
Description : 389 Directory Server is an LDAPv3 compliant server. The base
: package includes the LDAP server and command line utilities
: server administration.
Obviously not a big deal but may confuse people. This is on a completely
up-to-date fedora 14 x86_64 machine.
I'm hoping to get some help/suggestions for setting up a directory server for
a company with multiple offices.
Our goal is to provide unified logins/passwords company-wide. We also have
local Windows domains. In my office, the domain is run by a Samba 3 server
with 389 providing the back end.
Any general suggestions? Currently I have all of our users in the top
dc=nwra,dc=com domain since I wanted to provide a unified space, but now not
so sure how this will interact with the windows domains.
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
> > im not sure about centos, but in debian land is very tipical to
> > found messages like that after installing/upgrading:
> > "Remember to restart XXX package!"
> > can yum do that?
> rpm can do that, if you run it from the command line. If you use a
> graphical tool to install/update packages, this information is not
> But when you update 389-ds-base, rpm will upgrade and restart the
> servers for you (if they were running when you did the upgrade).
so, if rpm can detect you have an instance, why don't just run setup-ds-admin.pl -u?
> > do you think is a good idea?
> > should i file a bug/feature request?
> I'd like to find out what is the problem with the way it is done now,
> and the motivation (i.e. what is the problem that you are attempting
> to solve).
i though it was clear with my previous questions.
upgrading your system from packages can be dangerous if you dont perform specific steps (setup-ds-admin.pl -u).
there's few packages that needs to perform a manual operation after upgrading, so a system may be misconfigured whithout your knowledge.
anyway, if you dont find this usefull just forget it. maybe is my problem because i tend to update my systems very often.
Okay, I have 389-admin-console-1.1.5-1 installed on RHEL5 with
httpd-2.2.3-43.el5_5.3 and SELinux enforcing.
We have installed on two hosts. It runs Okay on one host, but fails to
finish setup-ds-admin.pl on the other. All I can find is a repeated
segfault in dirsrv/admin-server/error (admin serve httpd error log).
I'm presuming the console does not work because the HTTP server cannot
stay up because of the Segfault. The directory server appears to be
working fine (ldapsearch verifies), but I want to get into the console.
I have reviewed the configurations between the two hosts (the one that
works and the one that does not) and I am a bit stumped as they appear
to be identical.
I did restart (from the command line) the console on the one that did
work, and now it has started segfaulting. I noted that the SEL context
changed for httpd.worker from system_u to user_u (presumably it picked
up system_u from the boot/init). I rebooted the second host and it came
up with system_u, but still segfaults.
I'm kindof at the end of the road here on troubleshooting. Any suggestions?
----- Missatge original -----
> Gerrard Geldenhuis wrote:
> >> -----Original Message-----
> >> From: 389-users-bounces(a)lists.fedoraproject.org [mailto:389-users-
> >> bounces(a)lists.fedoraproject.org] On Behalf Of Rich Megginson
> >> Sent: 10 November 2010 14:26
> >> To: General discussion list for the 389 Directory server project.
> >> Subject: Re: [389-users] upgrading packages
> >> Angel Bosch Mora wrote:
> >>> hi,
> >> In general, it can't. The reason is that you may be using a
> >> centralized configuration directory server to manage several hosts
> >> with one 389-
> >> console. If you do that, the data that needs to be updated is on
> >> the remote
> >> server which hosts the configuration directory server (the one with
> >> the o=NetscapeRoot suffix). We need to get at least the console
> >> admin password to update that information remotely.
i'm refloting this thread to make a little suggestion.
when 389 packages are upgraded it could be usefull to show a warning if one or more instances are found.
im not sure about centos, but in debian land is very tipical to found messages like that after installing/upgrading:
"Remember to restart XXX package!"
can yum do that?
do you think is a good idea?
should i file a bug/feature request?
Have some troubles in setup AD -> DS replication.
386ds version 22.214.171.124 build 2010.272.2313 installed from EPEL repo
I have created sync agreement based on this article:
But sync doesn't work. Have many same events at error log:
"NSMMReplicationPlugin - agmt="cn=WinSyncAgreement" (ldap:389): Replica has
no update vector. It has never been initialized."
Also when i try to delete this agreement, dirsrv service dies.
# service dirsrv status
dirsrv 389ds dead but pid file exists
In error log only - "NSMMReplicationPlugin - agmt_delete: begin"
I tried to build 1.2.7 with openldap only, but it seems I still require
mozldap for the ldif.h (like specified in the documentation).
Do you suggesto to continue building 1.2.7 with mozldap only?
Babel S.r.l. - http://www.babel.it
T: +39.06.91801075 M: +39.340.6522736 F: +39.06.91612446
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)
CONFIDENZIALE: Questo messaggio ed i suoi allegati sono di carattere
confidenziale per i destinatari in indirizzo.
E' vietato l'inoltro non autorizzato a destinatari diversi da quelli indicati
nel messaggio originale.
Se ricevuto per errore, l'uso del contenuto e' proibito; si prega di
comunicarlo al mittente e cancellarlo immediatamente.