dirsrv does not start anymore
by Vasil Mikhalenya
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
12 years, 1 month
LDAPS configuration/installation
by Gilbert Martin
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?
12 years, 1 month
DS ACLs - still
by Karoly Czovek
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
12 years, 1 month
Setting limits per DN
by Michael Gettes
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
12 years, 1 month
389-ds on Centos 6.2 java probs
by mjames@guesswho.com
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)
12 years, 1 month
Per host access
by Ali Jawad
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_ba...
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
12 years, 1 month
ChainOnUpdate
by Jim Finn
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
12 years, 1 month
continuously segfault: 389ds 1.2.10.2 - 1.el6
by Roberto Polli
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.
12 years, 1 month
Error updating to 389 1.2.9.9
by Michael Gettes
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
12 years, 1 month