DS 1.3.4: nsslapd-db-deadlock cfg (deadlock issues)
by ghiureai
Hi List,
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 !
version:
389-ds-base-1.3.4.4-000.x86_64
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
5697e35f000600030000
[14/Jan/2016:10:05:23 -0800] memberof-plugin - memberof_postop_modify:
failed to replace list (cn=................). Error (1)
Isabella
4 years, 2 months
389 Windows Console
by Phil Daws
Hello,
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 ?
Thanks, Phil
4 years, 2 months
Admin certificate issue
by Phil Daws
Hello:
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 ?!?
Thanks, Phil
4 years, 2 months
389-ds crash
by Todor Petkov
Hello,
few days ago, as today, the ldap process crashed. I found this in
/var/log/messages:
Jan 6 17:26:24 ds1 kernel: ns-slapd[18010] trap invalid opcode
ip:7f1372fabd60 sp:7f13499e7518 error:0 in
libfreeblpriv3.so[7f1372f59000+72000]
Jan 11 14:28:41 ds1 kernel: ns-slapd[14263] trap invalid opcode
ip:7f852c56fd60 sp:7f85037ea518 error:0 in
libfreeblpriv3.so[7f852c51d000+72000]
There is no process in the memory, so I had to do "service dirsrv
restart"
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,
kernel: 2.6.32-431.17.1.el6.x86_64
389-ds packages:
389-admin-console-1.1.8-1.el6.noarch
389-ds-1.2.2-1.el6.noarch
389-ds-base-libs-1.2.11.15-65.el6_7.x86_64
389-adminutil-1.1.19-1.el6.x86_64
389-ds-console-1.2.6-1.el6.noarch
389-admin-console-doc-1.1.8-1.el6.noarch
389-admin-1.1.35-1.el6.x86_64
389-ds-base-1.2.11.15-65.el6_7.x86_64
389-console-1.1.7-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-dsgw-1.1.11-1.el6.x86_64
Regards,
4 years, 2 months
Repeatable 389-ds installation
by Charlie Mordant
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
other deps).
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?
Best regards
--
Charlie Mordant
Full OSGI/EE stack made with Karaf:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent
4 years, 2 months
PCI SSL TLS certificate requirements change
by Mayberry, Alexander
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?
Alexander Mayberry
Enterprise Systems Engineer
SD Group: EIT Infrastructure – OMA
Enterprise.Systems Engineering.Infrastructure
4 years, 2 months
CentOS 7: unable to create AdmldapInfo
by David Barr
Good Morning,
I’m experimenting with upgrading 389DS to 1.3.4.0-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[1]: Starting 389 Administration Server....
Jan 02 21:26:34 $HOSTNAME httpd[1076]: (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[1076]: AH00014: Configuration check failed
Jan 02 21:26:34 $HOSTNAME systemd[1]: dirsrv-admin.service: control process exited, code=exited status=1
Jan 02 21:26:34 $HOSTNAME systemd[1]: Failed to start 389 Administration Server..
Jan 02 21:26:34 $HOSTNAME systemd[1]: Unit dirsrv-admin.service entered failed state.
Jan 02 21:26:34 $HOSTNAME systemd[1]: dirsrv-admin.service failed.
```
Well, that’s easy to fix…
```
[root@$HOSTNAME ~]# mkdir -p /var/log/dirsrv/admin-serv/
```
Try again…
```
Jan 02 21:27:22 $HOSTNAME systemd[1]: Starting 389 Administration Server....
Jan 02 21:27:22 $HOSTNAME httpd[1204]: (13)Permission denied: AH00072: make_sock: could not bind to address 0.0.0.0:9830
Jan 02 21:27:22 $HOSTNAME httpd[1204]: no listening sockets available, shutting down
Jan 02 21:27:22 $HOSTNAME httpd[1204]: AH00015: Unable to open logs
Jan 02 21:27:22 $HOSTNAME systemd[1]: dirsrv-admin.service: control process exited, code=exited status=1
Jan 02 21:27:22 $HOSTNAME systemd[1]: Failed to start 389 Administration Server..
Jan 02 21:27:22 $HOSTNAME systemd[1]: Unit dirsrv-admin.service entered failed state.
Jan 02 21:27:22 $HOSTNAME systemd[1]: 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[1]: Starting 389 Administration Server....
Jan 02 21:32:12 $HOSTNAME systemd[1]: dirsrv-admin.service: control process exited, code=exited status=1
Jan 02 21:32:12 $HOSTNAME systemd[1]: Failed to start 389 Administration Server..
Jan 02 21:32:12 $HOSTNAME systemd[1]: Unit dirsrv-admin.service entered failed state.
Jan 02 21:32:12 $HOSTNAME systemd[1]: 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?)
Thanks!
David
--
David - Offbeat
dafydd - Online http://pgp.mit.edu/
----5----1----5----2----5----3----5----4----5----5----5----6----5----7--
Pavlov walks into a bar. The phone rings and he says,
"Damn! I forgot to feed the dog!"
4 years, 3 months
memberOf + error65
by ghiureai
Hi LIst,
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 ?
Thank you
Isabella
|
4 years, 3 months
Unsubscribe please
by Taylor, Greg (ES)
Greg Taylor
Northgrop Grumman Electronic Systems
VaDER System Administrator
410-294-01390
Gregory.a.taylor(a)ngc.com
4 years, 3 months
