389-users March 2012

389-users@lists.fedoraproject.org

45 participants
64 discussions

dirsrv does not start anymore
by Vasil Mikhalenya 07 Mar '12

07 Mar '12

Hi all, I can not solve the following issue. I can not start my master anymore. /var/log/dirsrv/slapd-ldap1/errors: [05/Mar/2012:19:43:06 +0300] - 389-Directory/1.2.10.2 B2012.054.1543 starting up [05/Mar/2012:19:43:06 +0300] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [05/Mar/2012:19:43:06 +0300] - slapi_add_internal: add_values for type uniqueMember failed (rc: 20) [05/Mar/2012:19:43:07 +0300] - slapi_add_internal: add_values for type uniqueMember failed (rc: 20) [05/Mar/2012:19:43:07 +0300] - slapd started. Listening on All Interfaces port 389 for LDAP requests [05/Mar/2012:19:43:07 +0300] - Listening on All Interfaces port 636 for LDAPS requests [05/Mar/2012:19:43:07 +0300] slapi_ldap_bind - Error: could not send bind request for id [uid=sync,cn=config] mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 (Operation now in progress) [05/Mar/2012:19:43:07 +0300] NSMMReplicationPlugin - agmt="cn=eu2-ldap" (eu2-ldap:636): Replication bind with SIMPLE auth failed: LDAP error 91 (Can't connect to the LDAP server) ((null)) [05/Mar/2012:19:43:07 +0300] slapi_ldap_bind - Error: could not send bind request for id [uid=sync,cn=config] mech [SIMPLE]: error 91 (Can't connect to the LDAP server) -5961 (TCP connection reset by peer.) 115 (Operation now in progress) [05/Mar/2012:19:43:07 +0300] NSMMReplicationPlugin - agmt="cn=us1-ldap" (us1-ldap:636): Replication bind with SIMPLE auth failed: LDAP error 91 (Can't connect to the LDAP server) ((null)) [05/Mar/2012:19:43:07 +0300] - slapi_add_internal: add_values for type uniqueMember failed (rc: 20) CentOS release 5.7 (Final) Name : 389-ds Arch : noarch Version : 1.2.1 Release : 1.el5 Google says nothing. Thanks in advance. -- Best regards, Vasil Mikhalenya

3 8

LDAPS configuration/installation
by Gilbert Martin 06 Mar '12

06 Mar '12

Hi All, I've been trying to get SSL working with my LDAP server, but haven't had success. I'm currently implementing a new test environment. Does anyone have some quick and dirty instruction on setting up a CA and SSL certs for my directory server and clients?

3 2

DS ACLs - still
by Karoly Czovek 06 Mar '12

06 Mar '12

Hi there, i faced into the following problem: installed one instance of 389ds to our DR site. Imported the databases Set up SSL Removed the anonymous read ACLs Restarted the dirsrv Replication is not set up. and I stil can pull the whole db, with a simple ldapsearch -x -LLL -h ds-drb -b "dc=foo,dc=bar" 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 389-admin-1.1.25-1.el6.x86_64 389-admin-console-doc-1.1.8-1.el6.noarch 389-console-1.1.7-1.el6.noarch 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 389-admin-console-1.1.8-1.el6.noarch 389-ds-console-doc-1.2.6-1.el6.noarch 389-dsgw-1.1.7-2.el6.x86_64 389-adminutil-1.1.14-2.el6.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-ds-1.2.2-1.el6.noarch Any idea? -- Karoly CZOVEK Senior Systems Administrator

2 1

Setting limits per DN
by Michael Gettes 06 Mar '12

06 Mar '12

My global time limit is 3600. global idle timeout is 0. global size limit is 500. global lookthroughlimit is 5000. on my DN I have established nsidletimeout, nssizelimit, nslookthroughlimit and nstimelimit as -1. i verify in the logs i am properly binding as my DN. i am getting the following result: RESULT err=3 tag=101 nentries=101 etime=121 notes=U what am i missing? i am hoping it's something stupid. Yes, I am trying to perform a search resulting in scanning the directory intentionally. /mrg

2 2

Require SSL/TLS connections?
by David Nguyen 06 Mar '12

06 Mar '12

Hi All, I have TLS connections working and would like to disable non-SSL connections (ie unencrypted traffic). Same situation as what was asked below in 2007: http://lists.fedoraproject.org/pipermail/389-users/2007-October/006347.html Is this possible with the latest version of 389 DS? Thanks in advance, David

2 1

389-ds on Centos 6.2 java probs
by mjames＠guesswho.com 06 Mar '12

06 Mar '12

Hi, I'm trying to install 389-ds on Centos 6.2 and failing with java probs. Sorry for the verbosity below. The Install Guide (http://directory.fedoraproject.org/wiki/Install_Guide) says "If you see something that says gcj or GCJ you're using the wrong version." However, when I install 389-ds, I see the following package in the list: java-1.5.0-gcj. I already have installed java-1.6.0-openjdk, and can't figure out what's wrong. Mike SYMPTOMS: [root@x-analog-01v slapd-x-analog-01v]# 389-console & [1] 5293 [root@x-analog-01v slapd-x-analog-01v]# Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class sun.awt.X11GraphicsEnvironment at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:82) at sun.awt.X11.XToolkit.<clinit>(XToolkit.java:112) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at java.awt.Toolkit$2.run(Toolkit.java:849) at java.security.AccessController.doPrivileged(Native Method) at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:841) at sun.swing.SwingUtilities2$AATextInfo.getAATextInfo(SwingUtilities2.java:126) at javax.swing.plaf.metal.MetalLookAndFeel.initComponentDefaults(MetalLookAndFeel.java:1564) at com.netscape.management.nmclf.SuiLookAndFeel.initComponentDefaults(Unknown Source) at com.netscape.management.nmclf.SuiLookAndFeel.getDefaults(Unknown Source) at javax.swing.UIManager.setLookAndFeel(UIManager.java:530) at com.netscape.management.client.console.Console.common_init(Unknown Source) at com.netscape.management.client.console.Console.<init>(Unknown Source) at com.netscape.management.client.console.Console.main(Unknown Source) INSTALLED: [root@x-analog-01v slapd-x-analog-01v]# rpm -qa | grep java java-1.6.0-openjdk-1.6.0.0-1.43.1.10.6.el6_2.i686 tzdata-java-2011l-4.el6.noarch 389-ds INSTALLATION [root@x-analog-01v slapd-x-analog-01v]# yum install 389-ds ... Dependencies Resolved ================================================================================================================================================================================================= Package Arch Version Repository Size ================================================================================================================================================================================================= Installing: 389-ds noarch 1.2.2-1.el6 epel 9.9 k Installing for dependencies: 389-admin i686 1.1.25-1.el6 epel 341 k 389-admin-console noarch 1.1.8-1.el6 epel 202 k 389-admin-console-doc noarch 1.1.8-1.el6 epel 43 k 389-console noarch 1.1.7-1.el6 epel 72 k 389-ds-console noarch 1.2.6-1.el6 epel 1.4 M 389-ds-console-doc noarch 1.2.6-1.el6 epel 55 k 389-dsgw i686 1.1.7-2.el6 epel 460 k idm-console-framework noarch 1.1.7-2.el6 epel 1.1 M java-1.5.0-gcj i686 1.5.0.0-29.1.el6 base 138 k java_cup i686 1:0.10k-5.el6 base 178 k ldapjdk i686 4.18-6.el6 base 749 k sinjdoc i686 0.5-9.1.el6 base 646 k Transaction Summary ================================================================================================================================================================================================= Install 13 Package(s)

2 1

Per host access
by Ali Jawad 06 Mar '12

06 Mar '12

Hi I did install 389 and LDAP authentication, what i need to do now is allow access to users only to certain systems, I did checkout : http://directory.fedoraproject.org/wiki/Howto:Posix#How_to_set_up_host_base… I tried the old method because I could not figure out the new method, I did enable pam_check_host_attr "did not change any pam settings though" and I have use_pam enabled in sshd_config, but the user was still able to logon through SSH even though no hosts were listed in his attributes. Please advice. Regards

2 2

ChainOnUpdate
by Jim Finn 05 Mar '12

05 Mar '12

Note: I have searched through years past in 389-users and have found a few others experiencing the same problem, yet I could not find any resolution. I am attempting to setup chain on update per http://directory.fedoraproject.org/wiki/Howto:ChainOnUpdate The packages installed are: 389-admin-console-1.1.8-1.el6.noarch 389-ds-1.2.2-1.el6.noarch 389-ds-base-1.2.9.14-1.el6_2.2.x86_64 389-console-1.1.7-1.el6.noarch 389-admin-console-doc-1.1.8-1.el6.noarch 389-ds-base-libs-1.2.9.14-1.el6_2.2.x86_64 389-dsgw-1.1.7-2.el6.x86_64 389-ds-console-1.2.6-1.el6.noarch 389-ds-console-doc-1.2.6-1.el6.noarch 389-adminutil-1.1.14-2.el6.x86_64 389-admin-1.1.25-1.el6.x86_64 The justification for use of chain_on_update is that our clients are “dumb” and unable to follow referrals. As a POC, I am testing with two servers: be1.foo.com (Master) and be2.foo.com (Consumer) Prior to following the instructions in the Howto:ChainOnUpdate (linked above) the environment operated as follows: Scenario A) Client.foo.com attempts to modify be1.foo.com -> Allowed Change made by client.foo.com to be1.foo.com is replicated to be2.foo.com Ldapsearch of both searvers shows the item was properly replicated, value is the same on be1 and be2 ----- Scenario B) Client.foo.com attempts to modify be2.foo.com -> Not allowed, given referral Upon following the instructions in the aforementioned howto the environment operates as follows: Scenario A) Client.foo.com attempts to modify be1.foo.com -> Allowed Change made by client.foo.com to be1.foo.com is replicated to be2.foo.com Ldapsearch of both searvers shows the item was properly replicated, value is the same on be1 and be2 ----- Scenario B) Client.foo.com attempts to modify be2.foo.com -> Allowed Change made by client.foo.com **SHOULD** have been handled by the chaining backend and modified on be1 Ldapsearch of both servers shows the item was modified on be2 but not be1 (be1 still has the old value) It seems the writes from client.foo.com to be2.foo.com are being committed to be local database (userRoot) instead of being handled by the chaining backend (chainbe1). As the howto suggests, I am using the replication manager for the proxy auth. I have confirmed the credentials on all servers. dn: cn=dc\3Dfoo\2Cdc\3Dcom,cn=mapping tree,cn=config objectClass: top objectClass: extensibleObject objectClass: nsMappingTree cn: "dc=foo,dc=com" nsslapd-state: backend nsslapd-backend: userRoot nsslapd-backend: chainbe1 nsslapd-distribution-plugin: libreplication-plugin.so nsslapd-distribution-funct: repl_chain_on_update dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: extensibleObject objectClass: nsBackendInstance cn: userRoot numSubordinates: 7 nsslapd-suffix: dc=foo,dc=com nsslapd-cachesize: -1 nsslapd-cachememsize: 10485760 nsslapd-readonly: off nsslapd-require-index: off nsslapd-directory: /var/lib/dirsrv/slapd-be2/db/userRoot nsslapd-dncachememsize: 10485760 dn: cn=replica,cn=dc\3Dfoo\2Cdc\3Dcom,cn=mapping tree,cn=config objectClass: nsDS5Replica objectClass: top nsDS5ReplicaRoot: dc=foo,dc=com nsDS5ReplicaType: 2 nsDS5Flags: 0 nsds5ReplicaPurgeDelay: 604800 nsDS5ReplicaBindDN: cn=replication manager,cn=replication,cn=config cn: replica nsDS5ReplicaId: 6553 nsDS5ReplicaName: ((REDACTED FOR EMAIL THREAD)) dn: cn=chainbe1,cn=chaining database,cn=plugins,cn=config objectClass: top objectClass: extensibleObject objectClass: nsBackendInstance cn: chainbe1 nsslapd-suffix: "dc=foo,dc=com" nsfarmserverurl: ldap://be1.foo.com/ nsmultiplexorbinddn: cn=replication manager,cn=replication,cn=config nschecklocalaci: off nsusestarttls: on nsbindmethod: nsmultiplexorcredentials: {DES}((REDACTED FOR EMAIL THREAD)) dn: cn=config,cn=chaining database,cn=plugins,cn=config objectClass: top objectClass: extensibleObject cn: config nstransmittedcontrols: 2.16.840.1.113730.3.4.2 nstransmittedcontrols: 2.16.840.1.113730.3.4.9 nstransmittedcontrols: 1.2.840.113556.1.4.473 nstransmittedcontrols: 1.3.6.1.4.1.1466.29539.12 nspossiblechainingcomponents: cn=resource limits,cn=components,cn=config nspossiblechainingcomponents: cn=certificate-based authentication,cn=component s,cn=config nspossiblechainingcomponents: cn=password policy,cn=components,cn=config nspossiblechainingcomponents: cn=sasl,cn=components,cn=config nspossiblechainingcomponents: cn=roles,cn=components,cn=config nspossiblechainingcomponents: cn=ACL Plugin,cn=plugins,cn=config nspossiblechainingcomponents: cn=old plugin,cn=plugins,cn=config nspossiblechainingcomponents: cn=referential integrity postoperation,cn=plugin s,cn=config nspossiblechainingcomponents: cn=attribute uniqueness,cn=plugins,cn=config Any help in getting ChainOnUpdate to work with my 389 servers would be greatly appreciated. Thanks in advance! Jim Finn

2 2

continuously segfault: 389ds 1.2.10.2 - 1.el6
by Roberto Polli 05 Mar '12

05 Mar '12

Hi Rich | everybody, We just experience a continuous segfault (each 20mins). This is the interesting part: #3 0x00007f8e635c20c6 in malloc_printerr () from /lib64/libc.so.6 #4 0x00007f8e65ac8b16 in slapi_ch_free (ptr=0x7f8e28017480) at ldap/servers/slapd/ch_malloc.c:363 #5 0x00007f8e5cfe7190 in cos_cache_query_attr (ptheCache=0x7f8e280178d0, context=0x0, e=0x7f8dc8016d00, type=0x7f8e28003760 "inetcos", out_attr=0x0, test_this=0x0, result=0x0, When exploring the dump, I found that: - everything happens in cache; - it crashes while freeing a string containing a DN; - gdb was able to print out the given string; - the "guilty" code strangely clones the given string, then frees the original one with slapi_ch_free(); Two sample stack traces and rpm infos follow. Do you have any hint? Thx+Peace, R. = Version = rpm -qi 389-ds-base Name : 389-ds-base Relocations: (not relocatable) Version : 1.2.10.2 Vendor: (none) Release : 1.el6 Build Date: Thu 23 Feb 2012 05:13:45 PM CET Install Date: Mon 27 Feb 2012 12:17:52 PM CET Build Host: vmhost Group : System Environment/Daemons Source RPM: 389-ds- base-1.2.10.2-1.el6.src.rpm Size : 4847506 License: GPLv2 with exceptions Signature : (none) URL : http://port389.org/ Summary : 389 Directory Server (base) Description : 389 Directory Server is an LDAPv3 compliant server. The base package includes the LDAP server and command line utilities for server administration. = Trace 1 = #0 0x00007f8e6357f885 in raise () from /lib64/libc.so.6 #1 0x00007f8e63581065 in abort () from /lib64/libc.so.6 #2 0x00007f8e635bc7a7 in __libc_message () from /lib64/libc.so.6 #3 0x00007f8e635c20c6 in malloc_printerr () from /lib64/libc.so.6 #4 0x00007f8e65ac8b16 in slapi_ch_free (ptr=0x7f8e28017480) at ldap/servers/slapd/ch_malloc.c:363 #5 0x00007f8e5cfe7190 in cos_cache_query_attr (ptheCache=0x7f8e280178d0, context=0x0, e=0x7f8dc8016d00, type=0x7f8e28003760 "inetcos", out_attr=0x0, test_this=0x0, result=0x0, props=0x7f8d9c3f8a5c) at ldap/servers/plugins/cos/cos_cache.c:2393 #6 0x00007f8e5cfea9aa in cos_cache_vattr_types (handle=<value optimized out>, e=0x7f8dc8016d00, type_context=0x7f8d9c3f8ad0, flags=<value optimized out>) at ldap/servers/plugins/cos/cos_cache.c:2199 #7 0x00007f8e65b3ad90 in slapi_vattr_list_attrs (e=0x7f8dc8016d00, types=0x7f8d9c3f8c78, flags=4, buffer_flags=0x7f8d9c3f8cbc) at ldap/servers/slapd/vattr.c:1289 #8 0x00007f8e65b1fc00 in send_all_attrs (pb=0x2987dc0, e=0x7f8dc8016d00, ectrls=0x7f8dc8016cd8, attrs=0x0, attrsonly=0, send_result=0, nentries=0, urls=0x0) at ldap/servers/slapd/result.c:915 #9 send_ldap_search_entry_ext (pb=0x2987dc0, e=0x7f8dc8016d00, ectrls=0x7f8dc8016cd8, attrs=0x0, attrsonly=0, send_result=0, nentries=0, urls=0x0) at ldap/servers/slapd/result.c:1362 #10 0x00007f8e65b2046c in send_ldap_search_entry (pb=<value optimized out>, e=<value optimized out>, ectrls=<value optimized out>, attrs=<value optimized out>, attrsonly=<value optimized out>) at ldap/servers/slapd/result.c:814 #11 0x00000000004208e2 in ps_send_results (arg=<value optimized out>) at ldap/servers/slapd/psearch.c:373 #12 0x00007f8e63f516f3 in ?? () from /lib64/libnspr4.so #13 0x00007f8e638f57f1 in start_thread () from /lib64/libpthread.so.0 #14 0x00007f8e6363292d in clone () from /lib64/libc.so.6 = Trace 2 = #0 0x00007f8e6357f885 in raise () from /lib64/libc.so.6 #1 0x00007f8e63581065 in abort () from /lib64/libc.so.6 #2 0x00007f8e635bc7a7 in __libc_message () from /lib64/libc.so.6 #3 0x00007f8e635c20c6 in malloc_printerr () from /lib64/libc.so.6 #4 0x00007f8e65ac8b16 in slapi_ch_free (ptr=0x7f8e28017480) at ldap/servers/slapd/ch_malloc.c:363 #5 0x00007f8e5cfe7190 in cos_cache_query_attr (ptheCache=0x7f8e280178d0, context=0x0, e=0x7f8dc8016d00, type=0x7f8e28003760 "inetcos", out_attr=0x0, test_this=0x0, result=0x0, props=0x7f8d9c3f8a5c) at ldap/servers/plugins/cos/cos_cache.c:2393 #6 0x00007f8e5cfea9aa in cos_cache_vattr_types (handle=<value optimized out>, e=0x7f8dc8016d00, type_context=0x7f8d9c3f8ad0, flags=<value optimized out>) at ldap/servers/plugins/cos/cos_cache.c:2199 #7 0x00007f8e65b3ad90 in slapi_vattr_list_attrs (e=0x7f8dc8016d00, types=0x7f8d9c3f8c78, flags=4, buffer_flags=0x7f8d9c3f8cbc) at ldap/servers/slapd/vattr.c:1289 #8 0x00007f8e65b1fc00 in send_all_attrs (pb=0x2987dc0, e=0x7f8dc8016d00, ectrls=0x7f8dc8016cd8, attrs=0x0, attrsonly=0, send_result=0, nentries=0, urls=0x0) at ldap/servers/slapd/result.c:915 #9 send_ldap_search_entry_ext (pb=0x2987dc0, e=0x7f8dc8016d00, ectrls=0x7f8dc8016cd8, attrs=0x0, attrsonly=0, send_result=0, nentries=0, urls=0x0) at ldap/servers/slapd/result.c:1362 #10 0x00007f8e65b2046c in send_ldap_search_entry (pb=<value optimized out>, e=<value optimized out>, ectrls=<value optimized out>, attrs=<value optimized out>, attrsonly=<value optimized out>) at ldap/servers/slapd/result.c:814 #11 0x00000000004208e2 in ps_send_results (arg=<value optimized out>) at ldap/servers/slapd/psearch.c:373 #12 0x00007f8e63f516f3 in ?? () from /lib64/libnspr4.so #13 0x00007f8e638f57f1 in start_thread () from /lib64/libpthread.so.0 #14 0x00007f8e6363292d in clone () from /lib64/libc.so.6 (14:44:02) Francesco Fiore: [root@inca-mss2 slapd-inca-mss2]# rpm -qi 389-ds-base Name : 389-ds-base Relocations: (not relocatable) Version : 1.2.10.2 Vendor: (none) Release : 1.el6 Build Date: Thu 23 Feb 2012 05:13:45 PM CET Install Date: Mon 27 Feb 2012 12:17:52 PM CET Build Host: vmhost Group : System Environment/Daemons Source RPM: 389-ds- base-1.2.10.2-1.el6.src.rpm Size : 4847506 License: GPLv2 with exceptions Signature : (none) URL : http://port389.org/ Summary : 389 Directory Server (base) Description : 389 Directory Server is an LDAPv3 compliant server. The base package includes the LDAP server and command line utilities for server administration. (14:44:45) # Francesco Fiore has ended his/her participation in the chat session. -- Roberto Polli Community Manager Babel S.r.l. - http://www.babel.it T: +39.06.9826.9651 M: +39.340.652.2736 F: +39.06.9826.9680 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.

3 4

Error updating to 389 1.2.9.9
by Michael Gettes 02 Mar '12

02 Mar '12

Hi, I am upgrading from 1.2.9.9 from 1.2.8.3 and I am getting the following error from setup-ds-admin.pl --update [01/Mar/2012:08:52:51 -0500] - from ldbm instance init: line 0: unknown or invalid matching rule "integerOrderingMatch" in index configuration (ignored) [01/Mar/2012:08:52:51 -0500] - from DSE add: line 0: unknown or invalid matching rule "integerOrderingMatch" in index configuration (ignored) There are several objects in dse.ldif with the above matching rule defined. I'm not sure what to do with this. Either find all instances of the matching rule reference and remove them or put back the matching rule (if i can locate it from another one of my servers). Also, I get the following and I believe these are non-issues - we don't utilize selinux. Is there some way to disable the selinux config in setup-ds-admin.pl??? I have looked through the source code and don't see how to disable it. libsepol.print_missing_requirements: piranha's global requirements were not met: type/attribute piranha_port_t libsemanage.semanage_link_sandbox: Link packages failed /usr/sbin/semanage: Could not add port tcp/9830 I am on RHEL5.7 (if that makes a difference). Many thanks for Rich's help in the past. I am grateful for this mailing list and all the other resources on the net to help me with the few problems I have had bringing up 389 for my institution. /mrg

3 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users March 2012