we upgrade our master/slave 389-DS from 1.2.2 to 1.3.4, now I 'm
seeing the following error in master DS ( fractional replication with
memberof excluded), when running tests seeing db deadlocks in
errorlog , I found the RH case #47409/979169 mentioned to add and
cfg nsslapd-db-deadlock to 6 , this did not solve the deadlock issues
( deleting memberOf entries fails !) and the slave goes out of sync
with master etc.
I wonder if there are new cfg param to be added to DS to solve the
deadlock contention in a replication env or other tips you may have much
appreciate it !
NSMMReplicationPlugin - agmt="cn=.............): Consumer failed to
replay change (uniqueid 3f7d7113-bae911e5-aea4abb9-cafb5c20, CSN
5697e35b000200030000): Referral (10). Will retry later.
NSMMReplicationPlugin - agmt=".............): Consumer failed to
replay change (uniqueid 3f7d7116-bae911e5-aea4abb9-cafb5c20, CSN
5697e35b000d00030000): Referral (10). Will retry later.
NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn:
retry (49) the transaction (csn=5697e35f000600030000) failed (rc=-30994
(DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock))
NSMMReplicationPlugin - changelog program - _cl5WriteOperationTxn:
failed to write entry with csn (5697e35f000600030000); db error - -30994
DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock
[14/Jan/2016:10:05:23 -0800] NSMMReplicationPlugin -
write_changelog_and_ruv: can't add a change for uid (uniqid:
dc1f8dfb-4e5b11e4-8187e93b-470eedd8, optype: 8) to changelog csn
[14/Jan/2016:10:05:23 -0800] memberof-plugin - memberof_postop_modify:
failed to replace list (cn=................). Error (1)
I have 389 up and running in my lab, with encryption enabled, but when I connect too the Administration panel and double click on the Directory Server it just hangs. The CA certificate has been imported using:
d:\Scratch\firefox_add-certs\bin>certutil -A -d "C:\Documents and Settings\phild\.389-console" -n "CA Certificate" -t CT,, -i d:\Downloads\CA-chain.pem -a
Am I missing something obvious please ?
am trying to understand how the admin certificates work in relation to the directory service ones. So I created the P12 using my PKI and imported the CA chain and certificate using certutil and p12util. Then I went into the Administration console, selected encryption, and chose the certificate I had imported. Next created the password.conf and updated nss.conf. Finally restarted dirsrv-admin which worked fine. Attempted to connect and it failed. In the error log I see:
"[Tue Jan 12 20:07:37.248469 2016] [:error] [pid 3516:tid 140704929720384] Misconfiguration of certificate's CN and virtual name. The certificate CN has ldap01admin.testlab.local. We expected ldap01.testlab.local as virtual name."
So if I create a certificate called ldap01.testlab.local how do I then create the same CN for the directory service itself ?!?
few days ago, as today, the ldap process crashed. I found this in
Jan 6 17:26:24 ds1 kernel: ns-slapd trap invalid opcode
ip:7f1372fabd60 sp:7f13499e7518 error:0 in
Jan 11 14:28:41 ds1 kernel: ns-slapd trap invalid opcode
ip:7f852c56fd60 sp:7f85037ea518 error:0 in
There is no process in the memory, so I had to do "service dirsrv
Does someone else have the same problem(s)? I see there are updates for
ds-base and ds-base-libs, and I will update later.
Here is more information about my setup:
OS: Centos 6,
Hi census experts!
At first, I wanted to thank you for that wonderful technology, providing
secure (tls ready, acl ready, clusterable) product: you're the only one
driving annuary (directory) as mature as this.
I'm encountering an untraditional issue: I'm trying to make a kind of cloud
service all ldap centric: all my services are consuming ldap to give user
credentials (jenkins, webmail, nexus, etc...).
I'm able to make a first-time ldap installation that fits all my needs but
not able to makes it repeatable.
The issues are that:
* docker image are really difficult to tackle:
mains parts are on the same db: netscaperoot things, ssl configuration,
maxbersize, as well as the users db (dc=mydn, dc=people), so splitting
concerns are difficult.
* remove-ds.pl then setup-ds.pl does not make admin-ds recognizable within
the new ldap.
* remove-ds-admin.pl removes some rpm mandatory files, so yum erase
(389-ds-base, 389-admin, 389-adminutil), yum install is mandatory (but it
looks like its not sufficient, and can cause some side effect: removing
So how can I make a repeatable 389 install?
What I want to achieve:
* Install a 389 server importing a personal CA and certs
* Securizing access (my cloud has prices depending on the number of users)
so my cloud adds users to 'dc=mycompany,ou=people, ou=company' but company
can add users to 'dc=mycompany,ou=people, ou=webmail,ou=contacts'
* Making it repeatable (exporting contacts data, yum erase 389-ds, yum
install 389-ds then configure stuff and importing contacts data should
lead to the same result as before), and I'm not able to do that after 3
month of work.
I've a sample Opscode Chef recipe mounting all this stuff, but
re-provisioning machine leads to errors, I can give access to one of your
dev if wanted.
Can 389 can be improved to uninstall ds then reinstall an installation
(without the admin things) and being as complete as before?
Full OSGI/EE stack made with Karaf:
Hi, we are using SSLv3 certs, and have a multi-master replication environment.
I have over 2000 clients currently using these CAs, and updating them to TLS seems highly disruptive.
Does anyone know of a way to add the updated TLS cert, while still honoring the old SSLv3 certs from clients?
Or perhaps a way to add new replicas in to the environment with the new TLS certs, but also add them in to the replication pool with the old SSLv3 systems?
Maybe a good guide/white paper on how to achieve this for PCI requirements?
Enterprise Systems Engineer
SD Group: EIT Infrastructure – OMA
I’m experimenting with upgrading 389DS to 22.214.171.124-21.el7_2 on CentOS 7 (I neglected to note what version I had previously).
`setup-ds-admin.pl —upgrade` can’t connect to the admin server. Oh look, it’s not running! And, to make this more fun, it may not have been running before the upgrade…
This is what I went through, trying to start the Admin Server… I’m chopping the “systemctl restart” and “systemctl status” commands….
Jan 02 21:26:34 $HOSTNAME systemd: Starting 389 Administration Server....
Jan 02 21:26:34 $HOSTNAME httpd: (2)No such file or directory: AH02291: Cannot access directory '/var/log/dirsrv/admin-serv/' for main error log
Jan 02 21:26:34 $HOSTNAME httpd: AH00014: Configuration check failed
Jan 02 21:26:34 $HOSTNAME systemd: dirsrv-admin.service: control process exited, code=exited status=1
Jan 02 21:26:34 $HOSTNAME systemd: Failed to start 389 Administration Server..
Jan 02 21:26:34 $HOSTNAME systemd: Unit dirsrv-admin.service entered failed state.
Jan 02 21:26:34 $HOSTNAME systemd: dirsrv-admin.service failed.
Well, that’s easy to fix…
[root@$HOSTNAME ~]# mkdir -p /var/log/dirsrv/admin-serv/
Jan 02 21:27:22 $HOSTNAME systemd: Starting 389 Administration Server....
Jan 02 21:27:22 $HOSTNAME httpd: (13)Permission denied: AH00072: make_sock: could not bind to address 0.0.0.0:9830
Jan 02 21:27:22 $HOSTNAME httpd: no listening sockets available, shutting down
Jan 02 21:27:22 $HOSTNAME httpd: AH00015: Unable to open logs
Jan 02 21:27:22 $HOSTNAME systemd: dirsrv-admin.service: control process exited, code=exited status=1
Jan 02 21:27:22 $HOSTNAME systemd: Failed to start 389 Administration Server..
Jan 02 21:27:22 $HOSTNAME systemd: Unit dirsrv-admin.service entered failed state.
Jan 02 21:27:22 $HOSTNAME systemd: dirsrv-admin.service failed.
Slightly more challenging, but SELinux is “enforcing,” so let’s try fixing that…
[root@$HOSTNAME ~]# semanage port -a -t http_port_t -p tcp 9830
That seems to have fixed the binding port problem, because systemd just notes a failure to start, and I had to go look in the error log...
Jan 02 21:32:12 $HOSTNAME systemd: Starting 389 Administration Server....
Jan 02 21:32:12 $HOSTNAME systemd: dirsrv-admin.service: control process exited, code=exited status=1
Jan 02 21:32:12 $HOSTNAME systemd: Failed to start 389 Administration Server..
Jan 02 21:32:12 $HOSTNAME systemd: Unit dirsrv-admin.service entered failed state.
Jan 02 21:32:12 $HOSTNAME systemd: dirsrv-admin.service failed.
[root@$HOSTNAME ~]# cat /var/log/dirsrv/admin-serv/error
[Sat Jan 02 21:32:12.628586 2016] [core:notice] [pid 1497:tid $THREAD] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
[Sat Jan 02 21:32:12.629960 2016] [:warn] [pid 1497:tid $THREAD] NSSSessionCacheTimeout is deprecated. Ignoring.
[Sat Jan 02 21:32:12.630027 2016] [:crit] [pid 1497:tid $THREAD] do_admserv_post_config(): unable to create AdmldapInfo
AH00016: Configuration Failed
And here, Google fails me. Is this fixable short of bailing out and reinstalling 389DS from scratch?
(Also, would you like a bug on the missing log directory? If so, where would you like me to write it? Would you like an Enhancement Request to check SELinux and offer to open port 9830 to httpd?)
David - Offbeat
dafydd - Online http://pgp.mit.edu/
Pavlov walks into a bar. The phone rings and he says,
"Damn! I forgot to feed the dog!"
we need to fix Error (65) we are seeing with memberOf pluging in
last DS 1.3.4. with already existing groups entries,
after some research I found the new param: |memberofAutoAddOC needs to
be added to membeOf plugin cfg , would this be sufficient to maintain
the exiting DS entries ?