I would really appreciated if any one can help me out here.
I have installed fedora directory server
as soon as i ran bellow script, its executes fine witout any issues.
dirsrv-admin, dirsrv is running,
but i cant connect to console
I am trying with
username : admin/cn=Directory Manager
but no luck
Dont understand why its failling to open 389.
Thanks for your help.
I have 2 389 DS with multimaster replicaton and one of them replicating
(multimaster) with my AD server
389DS2 <--> 389DS1 <--> ADServer
AD Server 2008 R2
With 2 specific groups, for some reason that could not identify in my logs,
all members are deleted (i'm not sure if the root cause is the 389DS or my
Can someone take a look on my log file and point me what is going on?
I dont want to send my log to the list because that a lot of information of
my users. Can I send direct to someone?
Thanks a lot
I'm sorry for nagging you, but Fedora 20 release day is coming and I have
experienced serious issues with 389-ds-base-18.104.22.168-1.fc20.x86_64.
Would it be worth to build a 389-ds-base-1.3.1 for Fedora 20 (and bump epoch
in RPM spec file)? That will give us more time for debugging and testing ...
Have a nice day.
I have setup the directory server with version 1.2.11. I am running a
subtree password policy and was wondering if it's possible to disabled
the feature that requests a password changed once the user's password
has expired. If a user let's their password expire I just want them to
get an "access denied" or "password expired" message and not let them
in. Is this possible?
There is a flow chart on the Redhat website
that shows what is happening. In the bottom right if you follow Grace
Logins? > No > Prompt: Password Change
2 MMR master servers (this hang happened on one of the masters) along with 3 read-only replicas.
Linux XXXX 2.6.32-358.18.1.el6.x86_64 #1 SMP Fri Aug 2 17:04:38 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
389-admin.x86_64 1.1.29-1.el6 @epel-x86_64-server-6
389-admin-console.noarch 1.1.8-1.el6 @epel-x86_64-server-6
389-admin-console-doc.noarch 1.1.8-1.el6 @epel-x86_64-server-6
389-adminutil.x86_64 1.1.15-1.el6 installed
389-console.noarch 1.1.7-3.el5 installed
389-ds.noarch 1.2.2-1.el6 @epel-x86_64-server-6
389-ds-console.noarch 1.2.6-1.el6 @epel-x86_64-server-6
389-ds-console-doc.noarch 1.2.6-1.el6 @epel-x86_64-server-6
389-dsgw.x86_64 1.1.10-1.el6 @epel-x86_64-server-6
389-admin.i686 1.1.29-1.el6 epel-x86_64-server-6
389-adminutil.i686 1.1.15-1.el6 epel-x86_64-server-6
389-adminutil-devel.i686 1.1.15-1.el6 epel-x86_64-server-6
389-adminutil-devel.x86_64 1.1.15-1.el6 epel-x86_64-server-6
389-ds-base.x86_64 22.214.171.124-1.el6 389_rhel6_x86_64
389-ds-base-debuginfo.x86_64 126.96.36.199-1.el6 389_rhel6_x86_64
389-ds-base-devel.x86_64 188.8.131.52-1.el6 389_rhel6_x86_64
389-ds-base-libs.x86_64 184.108.40.206-1.el6 389_rhel6_x86_64
nothing in the error log.
non-buffered access log: last 2 seconds
[11/Dec/2013:00:07:07 -0500] conn=104961 fd=84 slot=84 connection from 172.19.224.96 to XX
[11/Dec/2013:00:07:07 -0500] conn=104961 op=0 BIND dn="" method=128 version=2
[11/Dec/2013:00:07:07 -0500] conn=104961 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn=""
[11/Dec/2013:00:07:07 -0500] conn=104961 op=1 SRCH base="dc=cmu,dc=edu" scope=0 filter="(objectClass=*)" attrs=ALL
[11/Dec/2013:00:07:07 -0500] conn=104961 op=1 RESULT err=0 tag=101 nentries=1 etime=0
[11/Dec/2013:00:07:07 -0500] conn=104961 op=2 UNBIND
[11/Dec/2013:00:07:07 -0500] conn=104961 op=2 fd=84 closed - U1
[11/Dec/2013:00:07:07 -0500] conn=104962 fd=85 slot=85 SSL connection from 172.19.224.96 to XX
[11/Dec/2013:00:07:07 -0500] conn=104963 fd=84 slot=84 SSL connection from 172.19.224.96 to XX
[11/Dec/2013:00:07:07 -0500] conn=104962 SSL 256-bit AES
[11/Dec/2013:00:07:07 -0500] conn=104962 op=-1 fd=85 closed - B1
[11/Dec/2013:00:07:07 -0500] conn=104963 SSL 256-bit AES
[11/Dec/2013:00:07:07 -0500] conn=104963 op=0 BIND dn="uid=zenoss,ou=Account,dc=andrew,dc=cmu,dc=edu" method=128 version=2
[11/Dec/2013:00:07:08 -0500] conn=104963 op=0 RESULT err=0 tag=97 nentries=0 etime=1 dn="uid=zenoss,ou=Account,dc=andrew,dc=cmu,dc=edu”
stack trace of threads apply all bt full attached. I have the core file so am happy to do any additional gdb poking.
there is no SASL activity (given our previous reports) so this is something else. We have to kill -9 and then start the server to get it back up and running. Happy to make a bug report if that is more appropriate. I wanted to move to 220.127.116.11 but could not given the unprotected cert db problem.
Paul M. Whitney
On Dec 09, 2013, at 11:27 AM, Rich Megginson <rmeggins(a)redhat.com> wrote:
> On 12/09/2013 09:30 AM, Paul Whitney wrote:
>> I deinstalled and reinstalled my DS 9.0 ISO, then ran through the updates:
>> - DS9-RHBA-2011-1788 (nothing to update/install from here since the ISO is as current in versions)
>> - DS9-RHBA-2012-1345 (updated the 389-ds-console to 1.2.7-1)
>> - DS9-RHBA-2013-0960 (updated everything to 9.1)
>> So now this is what I have installed:
> Did you run setup-ds-admin.pl -u on all of the systems that you upgraded?
I ran it and am getting the following error: Error adding entry 'cn=PAM Pass Through Auth,cn=plugins,cn=config'. Error: Already exists (i tried to remedy this by removing the entry, but still getting the same error).
>> As root (just to eliminate any write permissions issue), I launched the 389-console.
> That shouldn't make any difference.
>> Log in successfully to master on local host. However a couple of things:
>> - The console window cannot access any of the slapd instances or the admin portion because system "failed to install a local copy of redhat-admin-9.0.jar or one of its supporting files." (The 9.0 jar links were replaced with 9.1). Links in this directory are confusing as all get out. Not sure why so many are needed....
> setup-ds-admin.pl -u is supposed to change the versions of the required jar files from 9.0 to 9.1.
> Links in which directory are confusing? You should never have to look in the directory.
I agree I should not have to look in the html/java directory. But that is where the jar files come from and wanted to verify that 9.0 jar files were replaced.
>> In the admin-serv error log I am getting error: File does not exist: /usr/share/dirsrv/html/redhat-admin-9.0.jar (the java directory was not overlooked in the path, this is the error in the log, as if it is looking for the 9.0 jar files in html).
> Let's see what the console is looking for. Run
> redhat-idm-console -D 9 -f console.log
Unfortunately, I cannot capture this information and post here. Info is on intranet with no access to Internet.
> scrub the console.log and email it to me (it will probably be too large to post to the list)
>> Paul M. Whitney
>> E-mail: paul.whitney(a)mac.com
>> On Dec 06, 2013, at 04:59 PM, Rich Megginson <rmeggins(a)redhat.com> wrote:
>>> On 12/06/2013 02:34 PM, Paul Whitney wrote:
>>>> I think the problem has to do with the version of JAR files the console I am running is looking for. I see in /usr/share/dirsrv/html/java a lot of symbolic links that cascade back to 389 jar files.
>>> The console downloads these from the admin server and stores them in ~/.redhat-idm-console/jars. It is the latter directory used by the console.
>>>> They are all 9.1 and my console is looking for 9.0.
>>> A 9.1 server installation should use the 9.1 jars.
>>> What do you mean by "my console is looking for 9.0"?
>>>> While I am ok with creating symbolic links and for 9.0 jar files, why will the console not use the jars already present?
>>> A 9.1 server must use the 9.1 jars, not the 9.0 jars.
>>>> Paul M. Whitney
>>>> E-mail: paul.whitney(a)mac.com
>>>> Cell: 410.493.9448
>>>> On Dec 06, 2013, at 12:35 PM, Rich Megginson <rmeggins(a)redhat.com> wrote:
>>>>> On 12/06/2013 10:41 AM, Paul Whitney wrote:
>>>>>> I recently upgraded my DS9 instance (RHDS9 RHBA-2013-0960) on both ldap server and my console. This should bring my servers to DS 9.1. Yet, I still see Version 9.0.0. Is this correct or did I miss a step?
>>>>> There should have been something in the upgrade docs about running setup-ds-admin.pl -u after doing the yum update.
>>>>>> Paul M. Whitney
>>>>>> E-mail: paul.whitney(a)mac.com
>>>>>> 389 users mailing list
I have a 4-way multi-master replication configuration; the servers are
slightly different versions, as below:
A - 18.104.22.168-1.el5 (CentOS 5)
B - 22.214.171.124-1.el5 (CentOS 5)
C - 126.96.36.199-20.el6_3 (CentOS 6)
D - 188.8.131.52-22.el6_4 (CentOS 6)
D was recently brought into the configuration to replace A (ultimately).
I initialized D as a consumer directly from A, and I've confirmed that
replication proceeds throughout the mesh without apparent incident --
there are no errors in /var/log/dirsrv/slapd*/errors relating to
The problem is that *some* objects under ou=people,dc=foo,dc=bar on D do
not show some objectclasses, notably "person" and
"organizationalPerson". These values don't show up in the output of
ldapsearch, via the console, or when used by an internal search process,
such as populating an nsFilteredRole.
These objects *do* have those objectclasses visible on all the other
servers (A, B, and C). Searches against those other servers return
If I explicitly add the objectclass to the object via server D, the
objectclasses are now visible. Added objectclasses do not create
duplicates on the other servers in the replication mesh.
Has anyone seen anything like this before? The objects which exhibit
this behaviour don't seem to have any commonality with each other, and
are interspersed (by createtimestamp) with other almost identical
objects which do *not* exhibit the behaviour.
If the answer is "known bug fixed in version BLAH", then I'm perfectly
Tech Lead - Infrastructure, REA Group
Ph: +61 (0)3 8456 4636 Mb: +61 (0) 457 788 259
I recently upgraded my DS9 instance (RHDS9 RHBA-2013-0960) on both ldap server and my console. This should bring my servers to DS 9.1. Yet, I still see Version 9.0.0. Is this correct or did I miss a step?
Paul M. Whitney
I have 2 389 running (389-Directory/184.108.40.206 and 389-Directory/220.127.116.11) with
multiple master configuration.
When I set the option "check hostname against name in certificate for
outbound SSL connections" the agreement does not work and shows me this
[05/Dec/2013:14:35:55 -0200] slapi_ldap_bind - Error: could not send bind
request for id [uid=app.389.w,cn=config] authentication mechanism [SIMPLE]:
error -1 (Can't contact LDAP server), system error -5987 (Invalid function
argument.), network error 115 (Operation now in progress, host
[05/Dec/2013:14:35:55 -0200] NSMMReplicationPlugin - agmt="cn=389-HMG2"
(hmg2:636): Replication bind with SIMPLE auth failed: LDAP error -1 (Can't
contact LDAP server) ((unknown error code))
When I unset the option, everything works as expected.
Here's the subject of my certificates:
Subject: C=BR, ST=Rio de Janeiro, L=Rio de Janeiro, O=Rede Nacional de
Ensino e Pesquisa, OU=GTI, CN=hmg3.homolog.rnp
Subject: C=BR, ST=Rio de Janeiro, L=Rio de Janeiro, O=Rede Nacional de
Ensino e Pesquisa, OU=GTI, CN=hmg2.homolog.rnp
My DNS is configured correctly (the reverse too).
In my production enviroment this options works fine, but it's a little bit