openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

Sample Large ldiff file to support 1K users
by Meena Ram 06 Apr '10

06 Apr '10

Dear folks: If anyone has sample large ldiff file which supports around 1000 users please let me know. Require it for some particular purpose so that it saves some time.Really appreciate your help on this. Send me the link or the ldif file itself Cheers!!!!!!!!!!! RAM

3 2

too many open files and over 1K xinetd running
by Seger, Mark 06 Apr '10

06 Apr '10

I'm using xinetd forwarding to allow a number of compute nodes that don't have a direct path to our ldap server to get forward on by a host that does. When running a highly parallel job that starts over 1K instances at the same time, I see all these xinetd instances also start up on my forwarding server and in fact they don't seem to go away, at not any time soon. Meanwhile back on my ldap server I see number of 'too many open files' errors in /var/log/messages and if I try to "su user" on one of the nodes I'll see it hang for awhile. I have bumped the number of open files very high on the ldap server and in fact: [root@aicgateway ~]# cat /proc/sys/fs/file-nr 5610 0 201116 So out of a pool of 200K we're only using 5K. Anyhow, I'm wondering if there are any special tricks to configuring the environment to handling this type of load on ldap OR should it be able to handle it the way I'm currently configured? Any special tuning hints? Any more info I can supply? -mark

3 4

failure to connect ldap
by m.anis 05 Apr '10

05 Apr '10

Hi all, i just install open-ldap server, and i'm following this steps: i'm installing it on FreeBSD 8.0 #*cd /usr/local/etc/openldap* #*sed -I .old 's/rootpw/# rootpw/' slapd.conf* #*echo -n "rootpw ">> slapd.conf* #*slappasswd>> slapd.conf *#*ee /usr/local/etc/openldap/slapd.conf* suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" here what i confused about, i'm running this on localhost, so what should i use? suffix "dc=localhost,dc=localdomain" or my host name ( i got it from nslookup from windows) is 11.<unit name>.<institute name>.ac.id suffix "dc=11.<unit name>.<institute name> ,dc=ac.id" or anything else? then when i tried to do this #*ldapadd -x -D "cn=Manager,dc=*example*,dc=*com*" -W -f domainmgr.ldif -c it asks for my password, then i insert my password and then and error messages occured ldap bind: can't contact LDAP server (-1) i had search through google but i don't get the answer, thanks for your help, * -- -- Best Regards Muhammad Anis

2 1

uri="" bug
by DT Piotr Wadas 04 Apr '10

04 Apr '10

Hello, http://www.openldap.org/lists/openldap-technical/201001/msg00181.html Is it in progress or fixed in repository, or should I try to create a patch? P. -- http://dtpw.pl/buell [ 25th anniversary of Buell - American Motorcycles ] Linux aleft 2.6.27.29-0.1_lustre.1.8.1.1-default #1 SMP drbd version: 8.3.7 (api:88/proto:86-91) pacemaker 1.0.6-cebe2b6ff49b36b29a3bd7ada1c4701c7470febe

1 2

Sample Large ldiff file to support 1K users
by Meena Ram 03 Apr '10

03 Apr '10

1 0

handshake failure / SSL3_GET_CLIENT_HELLO:no shared cipher s3_srvr
by Götz Reinicke - IT-Koordinator 01 Apr '10

01 Apr '10

Hi, this drives my crazy for about two days: I do have two virtual Red Hat El 5.4 servers in a test environment. One should be an openldap master, the second should be a openldap slave. openssl-0.9.8e-12.el5_4.1, openldap-2.3.43-3.el5 (RH EL original rpms) I followed some instructions to set up TLS: Set up a CA, generate/sign certificates and keys, install tham on the servers and configure openldap, restart. My problem is: tls works on the master (which also is my CA for the test), but not on the slave. I've "openssl verify"ed and "openssl x509 -text"ed the certs - everything seams o.k. I've checked ip addresses, name resolving, locations, pathes, permissions, fileversions - anything I can think of. I've regenerated the key and cert for the slave following an other documentation (at least with the same steps), but alway do get the same error: from the ldap server debug: TLS trace: SSL3 alert write:fatal:handshake failure TLS trace: SSL_accept:error in SSLv3 read client hello B TLS trace: SSL_accept:error in SSLv3 read client hello B TLS: can't accept. TLS: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher s3_srvr.c:975 connection_read(13): TLS accept failure error=-1 id=0, closing from the ldap client debug: TLS trace: SSL3 alert read:fatal:handshake failure TLS trace: SSL_connect:error in SSLv2/v3 read server hello A TLS: can't connect. ldap_perror ldap_start_tls: Connect error (-11) additional info: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure May be I missed a step or still skiped something ... A thousand kowtows for any helping hint...!! Best regards, Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reinicke(a)filmakademie.de Filmakademie Baden-Württemberg GmbH Akademiehof 10 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzende des Aufsichtsrats: Prof. Dr. Claudia Hübner Geschäftsführer: Prof. Thomas Schadt

1 0

remote connections cannot write to LDAP
by Ray Carrender 01 Apr '10

01 Apr '10

Not sure what's going on here, but when I try making a non TLS connection to the LDAP Repository and it's local (say using ldapmodify) I can write to it, but when trying to connect to remotely (on the internal network) it doesn't throw an error but it ignores the write command. Am I missing something here? Maybe it's because I'm using JNDI instead of the written ldapmodify. Also, remotely I can read information, just not write it. Thanks!

2 1

New LDAP Appliances
by Howard Chu 01 Apr '10

01 Apr '10

No, not the VMware kind... http://www.symas.com/blog/ -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ldap_sasl_interactive_bind_s failed (-2) using openldap v2.3.43 when trying to replicate via syncrepl.
by Kristian Kostecky 01 Apr '10

01 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys, I have a configuration that consists of 3 ldap servers. One is the provider and there are 2 consumers. I am using syncrepl to do the synchronization. simple and anonymous binds are totally disabled and Kerberos must be used via SASL (GSSAPI) and TLS to connect to the LDAP server. distro: centos 5.4 openldap 2.3.43 cyrus-sasl 2.1.22 Other things: - - clocks are all in sync - - hostnames all have forward and reverse mappings and all dns servers in /etc/resolv.conf respond with proper entries on the consumer and both providers. Here's the catch, the two providers are configured the same (except for hostnames/ips) and the first one works perfect. What is really frustrating is the lack of logging that is available to tell me what the problem is. I've tried loglevel -1 and it gave me even less info in regards to the SASL authentication than leaving it off. The affected consumer is giving me: Mar 31 22:41:00 ZZZ slapd[2442]: slapd starting Mar 31 22:41:02 ZZZ slapd[2442]: do_syncrep1: rid 010 ldap_sasl_interactive_bind_s failed (-2) Mar 31 22:41:02 ZZZ slapd[2442]: do_syncrepl: rid 010 quitting On the "Provider": Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 ACCEPT from IP=10.130.1.230:60288 (IP=0.0.0.0:389) Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=0 STARTTLS Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=0 RESULT oid= err=0 text= Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 TLS established tls_ssf=256 ssf=256 Mar 31 17:49:54 XXX slapd[3494]: conn=212 op=1 UNBIND Mar 31 17:49:54 XXX slapd[3494]: conn=212 fd=21 closed This is what's REALLY weird - from the affected/broken box, ZZZ, after I kinit, I can do an LDAP search or ldapwhoami, no problems! So, kerberos and GSSAPI via SASL is working fine. ie: ldapsearch -H ldaps://XXX/ -Y GSSAPI -> will dump the entries. or ldapwhoami -H ldaps://XXX/ -Y GSSAPI -> shows me that proper creds If I destroy the credentials, it doesn't work as would be expected. ON the working consumer, the behaviour is that I can ldapsearch and ldapwhoami properly after I kinit and when I start ldap it will authenticate properly with the provider via SASL GSSAPI and replicates the DB. If I kdestroy the credentials and start it, I get the same error that I'm struggling with on the box that doesn't work ->ldap_sasl_interactive_bind_s failed (-2) This behaviour leads me to believe that for some reason the ldap server on the box that doesn't work is having problems transmitting the kerberos credentials to the provider, whereas the ldapsearch and ldapwhoami binaries are not having problems. There are some suspicious differences between the consumer that works and the broken one. The provider and consumer that works both have TLDs that match - '.com' and the consumer whose synrepl process won't authenticate is part of the .eu TLD. However, as you can see below in the krb5.conf files, the .com and .eu TLDS are always mapped to the same authentication realm. PLUS, again, ldapsearch and ldapwhoami WORK. It's just the syncrepl process that isn't quite getting the auth right. This is the provider's pertinent configs: slapd.conf: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 This is the consumer's pertinent configs (WORKS ON one, not on the other) slapd.conf: syncrepl rid=10 provider=ldap://xxx.XXX.com starttls=yes type=refreshOnly interval=00:00:01:00 searchbase="dc=XXX,dc=com" schemachecking=off bindmethod=sasl saslmech=GSSAPI krb5.conf [same as provider and kerb server]: [libdefaults] default_realm = BOUNCE.AAA.COM encrypt = true allow_weak_crypto = false clockskew = 600 dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 8h forwardable = no proxiable = no [realms] BOUNCE.AAA.COM = { kdc = XXX.com kdc = YYY.com kdc = ZZZ.eu admin_server = XXX.com } [domain_realm] .com = BOUNCE.AAA.COM .eu = BOUNCE.AAA.COM All help is greatly appreciated! This has been going on for days and I've already yanked out most of my hair. Thank you. Kris. PGP Key: 4CC63A18 PGP Server: pool.sks-keyservers.net -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) iEYEARECAAYFAkuzyroACgkQ2C/J5/UUQWEuUACdH/BhiZgTXFWbNMXS7Q99k8Rg VY8An3YWKcpnkxVYvZMlelkT0TIpYuAP =O9KI -----END PGP SIGNATURE-----

1 2

Re: Re-engaging the Samba4 LDAP backend
by Endi Sukma Dewata 31 Mar '10

31 Mar '10

Hi Andrew, ----- "Andrew Bartlett" <abartlet(a)samba.org> wrote: > - a replacement for the Samba4 rdn_name module. For OpenLDAP I have > tried out ITS#6055 but it fails, sadly. > http://www.openldap.org/its/index.cgi/Development?id=6055;selectid=6055 > I don't know of any comparable effort in Fedora DS. We're considering this proposal for FDS: http://directory.fedoraproject.org/wiki/RDN_Value At this point it's still being designed, so I can't say yet when this would become available. > - Transaction support. While most of the transaction-aware tasks in > Samba have now been either pushed off as 'too hard on LDAP' or into > modules that are now in the LDAP backend, we still do need > transactions > over LDAP. Transaction on FDS is deferred until later this year: http://directory.fedoraproject.org/wiki/LDAP_Transactions > - A way to easily detect that we have OpenLDAP or Fedora DS > installed > on the system, and what it's version is. Once we have that, we could > start trying to run at least some of Samba4's tests against such a > backend regularly (and stop breaking it so often). The buildsamba02 machine is configured to test against FDS: http://build.samba.org/?function=View+Build;host=buildsamba02;tree=samba_4_… I hope there's somebody who could maintain a similar system configured with OpenLDAP. > - Some help debugging the existing 'make test' failures! I've fixed some FDS-specific failures. I'll send you the patches soon. > To address a broader range of use cases, I'm looking forward to the > work > Endi has promised for a 'ldap backend config file' as input to > provision. Hopefully this will reduce the options we have to present > to > users on the provision command line. Sorry about the delay on this. It's coming but slowly because I have to handle other issues as well. Thanks! -- Endi S. Dewata

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical