openldap-technical January 2011

openldap-technical@openldap.org

91 participants
107 discussions

nss_override_attribute_value
by Hugo Monteiro 20 Jan '11

20 Jan '11

Hello, I was wondering if there are any plans to make nss_override/default_attribute_value allow the use of env vars to perform substitutions. Something along the line of nss_override_attribute_value homeDirectory /home/users/${USER} This would allow great flexibility, specially when combined with pam_env and such. Regards, Hugo Monteiro. -- fct.unl.pt:~# cat .signature Hugo Monteiro Email : hugo.monteiro(a)fct.unl.pt Telefone : +351 212948300 Ext.15307 Web : http://hmonteiro.net Divisão de Informática Faculdade de Ciências e Tecnologia da Universidade Nova de Lisboa Quinta da Torre 2829-516 Caparica Portugal Telefone: +351 212948596 Fax: +351 212948548 www.fct.unl.pt apoio(a)fct.unl.pt fct.unl.pt:~# _

2 2

Best and most efficient way to upgrade openLDAP
by Ghyslain Tissot 19 Jan '11

19 Jan '11

Hello, We are looking for input on how to upgrade openLDAP from 2.2 to 2.3. We have looked and it seems the only documented way to upgrade is by unloading and reloading the data which is very time consuming (approx. 8-10 hours). Since this is a production system it is not adequate. What options are available? To give more more background: - there are currently approximately 7M entries in the LDAP; - we are migrating to a new server with a new version of openLDAP (dependant on RHEL version - previously RHEL 4 now RHEL 5); - we tried the option creating a staging server with 2.2 and importing on the new system (v2.3) the extracted data on the new system. Then we activated replication (SLURPD) between the two and tried updating the staging server with the transaction logs of production hoping the data would then replicate to the new system. But that does not work. Any ideas on how it can be done with minimal impact to the current LDAP and reducing the outage period?

3 2

No remote writes, only reads
by mike＠grounded.net 18 Jan '11

18 Jan '11

ldap_bind: Can't contact LDAP server (-1) On local server, I can write to LDAP server. From any remote server, I can only read from server. I don't have TLS enabled, that I know of, nothing in slapd.conf at least. I do see tls_cacertdir /etc/openldap/cacerts in the /etc/ldap.conf. I don't see anything for errors in the log file when remotes fail. The 389 port is open, no selinux or iptables or any other firewall in the way. Been searching google for hours, finding a ton of leads all of them dead ends. Wondering if someone could help me out and give me some leads on what to look for next. Thanks.

4 9

"slapadd: corrupted double-linked list"
by Marc Patermann 18 Jan '11

18 Jan '11

Hi, what could the following possibly be? When I do a # slapadd -q -v -c -l dump.ldif to a SLES 11 SP1 (openldap 2.3.20) I get this after a few 1000 entries: *** glibc detected *** slapadd: corrupted double-linked list: 0x00007f3ef0cb9920 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x75018)[0x7f3eedeb2018] /lib64/libc.so.6(+0x76e0e)[0x7f3eedeb3e0e] /lib64/libc.so.6(+0x7ad91)[0x7f3eedeb7d91] /lib64/libc.so.6(realloc+0xfa)[0x7f3eedeb81aa] /usr/lib64/liblber-2.4.so.2(ber_memrealloc_x+0x48)[0x7f3eeffd4f48] slapadd(ldif_read_record+0x121)[0x7f3ef07bcd81] slapadd(slapadd+0x28b)[0x7f3ef070426b] slapadd(main+0xd4)[0x7f3ef0678b84] /lib64/libc.so.6(__libc_start_main+0xe6)[0x7f3eede5bbc6] slapadd(+0x2d509)[0x7f3ef0678509] ======= Memory map: ======== 7f3ecc000000-7f3ecc021000 rw-p 00000000 00:00 0 7f3ecc021000-7f3ed0000000 ---p 00000000 00:00 0 7f3ed0364000-7f3ed037a000 r-xp 00000000 08:02 48688 /lib64/libgcc_s.so.1 7f3ed037a000-7f3ed0579000 ---p 00016000 08:02 48688 /lib64/libgcc_s.so.1 7f3ed0579000-7f3ed057a000 r--p 00015000 08:02 48688 /lib64/libgcc_s.so.1 7f3ed057a000-7f3ed057b000 rw-p 00016000 08:02 48688 /lib64/libgcc_s.so.1 7f3ed057b000-7f3ed094c000 rw-p 00000000 00:00 0 7f3ed094c000-7f3ed1308000 rw-s 00000000 fd:05 172038 /var/lib/ldap/main-data/__db.003 7f3ed1308000-7f3ed16d9000 rw-p 00000000 00:00 0 7f3ed16d9000-7f3ed681b000 rw-s 00000000 fd:05 49158 /var/lib/ldap/human-data/__db.003 7f3ed681b000-7f3ed6d09000 rw-s 00000000 fd:05 49157 /var/lib/ldap/human-data/__db.002 7f3ed6d09000-7f3ed70da000 rw-p 00000000 00:00 0 7f3ed70da000-7f3eeb0dc000 rw-s 00000000 fd:05 335878 /var/lib/ldap/linux-data/__db.003 7f3eeb0dc000-7f3eeba8a000 rw-s 00000000 fd:05 335877 /var/lib/ldap/linux-data/__db.002 7f3eeba8a000-7f3eebaa7000 r-xp 00000000 fd:0a 163907 /usr/lib/openldap/modules/back_meta-2.4.so.2.5.3 7f3eebaa7000-7f3eebca6000 ---p 0001d000 fd:0a 163907 /usr/lib/openldap/modules/back_meta-2.4.so.2.5.3 7f3eebca6000-7f3eebca7000 r--p 0001c000 fd:0a 163907 /usr/lib/openldap/modules/back_meta-2.4.so.2.5.3 7f3eebca7000-7f3eebca8000 rw-p 0001d000 fd:0a 163907 /usr/lib/openldap/modules/back_meta-2.4.so.2.5.3 7f3eebca8000-7f3eebcac000 r-xp 00000000 fd:0a 795580 /usr/lib64/sasl2/libanonymous.so.2.0.22 7f3eebcac000-7f3eebeab000 ---p 00004000 fd:0a 795580 /usr/lib64/sasl2/libanonymous.so.2.0.22 7f3eebeab000-7f3eebeac000 r--p 00003000 fd:0a 795580 /usr/lib64/sasl2/libanonymous.so.2.0.22 7f3eebeac000-7f3eebead000 rw-p 00004000 fd:0a 795580 /usr/lib64/sasl2/libanonymous.so.2.0.22 7f3eebead000-7f3eebeaf000 r-xp 00000000 08:02 48656 /lib64/libkeyutils-1.2.so 7f3eebeaf000-7f3eec0ae000 ---p 00002000 08:02 48656 /lib64/libkeyutils-1.2.so 7f3eec0ae000-7f3eec0af000 r--p 00001000 08:02 48656 /lib64/libkeyutils-1.2.so 7f3eec0af000-7f3eec0b0000 rw-p 00002000 08:02 48656 /lib64/libkeyutils-1.2.so 7f3eec0b0000-7f3eec0b7000 r-xp 00000000 fd:0a 778733 /usr/lib64/libkrb5support.so.0.1 7f3eec0b7000-7f3eec2b7000 ---p 00007000 fd:0a 778733 /usr/lib64/libkrb5support.so.0.1 7f3eec2b7000-7f3eec2b8000 r--p 00007000 fd:0a 778733 /usr/lib64/libkrb5support.so.0.1 7f3eec2b8000-7f3eec2b9000 rw-p 00008000 fd:0a 778733 /usr/lib64/libkrb5support.so.0.1 7f3eec2b9000-7f3eec2bc000 r-xp 00000000 08:02 48700 /lib64/libcom_err.so.2.1 7f3eec2bc000-7f3eec4bb000 ---p 00003000 08:02 48700 /lib64/libcom_err.so.2.1 7f3eec4bb000-7f3eec4bc000 r--p 00002000 08:02 48700 /lib64/libcom_err.so.2.1 7f3eec4bc000-7f3eec4bd000 rw-p 00003000 08:02 48700 /lib64/libcom_err.so.2.1 7f3eec4bd000-7f3eec4e1000 r-xp 00000000 fd:0a 778721 /usr/lib64/libk5crypto.so.3.1 7f3eec4e1000-7f3eec6e0000 ---p 00024000 fd:0a 778721 /usr/lib64/libk5crypto.so.3.1 7f3eec6e0000-7f3eec6e2000 r--p 00023000 fd:0a 778721 /usr/lib64/libk5crypto.so.3.1 7f3eec6e2000-7f3eec6e3000 rw-p 00025000 fd:0a 778721 /usr/lib64/libk5crypto.so.3.1 7f3eec6e3000-7f3eec781000 r-xp 00000000 fd:0a 778731 /usr/lib64/libkrb5.so.3.3 7f3eec781000-7f3eec980000 ---p 0009e000 fd:0a 778731 /usr/lib64/libkrb5.so.3.3 7f3eec980000-7f3eec983000 r--p 0009d000 fd:0a 778731 /usr/lib64/libkrb5.so.3.3 7f3eec983000-7f3eec985000 rw-p 000a0000 fd:0a 778731 /usr/lib64/libkrb5.so.3.3 7f3eec985000-7f3eec9b0000 r-xp 00000000 fd:0a 778717 /usr/lib64/libgssapi_krb5.so.2.2 7f3eec9b0000-7f3eecbaf000 ---p 0002b000 fd:0a 778717 /usr/lib64/libgssapi_krb5.so.2.2 7f3eecbaf000-7f3eecbb0000 r--p 0002a000 fd:0a 778717 /usr/lib64/libgssapi_krb5.so.2.2 7f3eecbb0000-7f3eecbb1000 rw-p 0002b000 fd:0a 778717 /usr/lib64/libgssapi_krb5.so.2.2 7f3eecbb1000-7f3eecbb8000 r-xp 00000000 fd:0a 795710 /usr/lib64/sasl2/libgssapiv2.so.2.0.22 7f3eecbb8000-7f3eecdb7000 ---p 00007000 fd:0a 795710 /usr/lib64/sasl2/libgssapiv2.so.2.0.22 7f3eecdb7000-7f3eecdb8000 r--p 00006000 fd:0a 795710 /usr/lib64/sasl2/libgssapiv2.so.2.0.22 7f3eecdb8000-7f3eecdb9000 rw-p 00007000 fd:0a 795710 /usr/lib64/sasl2/libgssapiv2.so.2.0.22 7f3eecdb9000-7f3eecdbd000 r-xp 00000000 fd:0a 795583 /usr/lib64/sasl2/liblogin.so.2.0.22 7f3eecdbd000-7f3eecfbc000 ---p 00004000 fd:0a 795583 /usr/lib64/sasl2/liblogin.so.2.0.22 7f3eecfbc000-7f3eecfbd000 r--p 00003000 fd:0a 795583 /usr/lib64/sasl2/liblogin.so.2.0.22 7f3eecfbd000-7f3eecfbe000 rw-p 00004000 fd:0a 795583 /usr/lib64/sasl2/liblogin.so.2.0.22 7f3eecfbe000-7f3eecfc3000 r-xp 00000000 fd:0a 795586 /usr/lib64/sasl2/libsasldb.so.2.0.22 7f3eecfc3000-7f3eed1c2000 ---p 00005000 fd:0a 795586 /usr/lib64/sasl2/libsasldb.so.2.0.22 7f3eed1c2000-7f3eed1c3000 r--p 00004000 fd:0a 795586 /usr/lib64/sasl2/libsasldb.so.2.0.22 7f3eed1c3000-7f3eed1c4000 rw-p 00005000 fd:0a 795586 /usr/lib64/sasl2/libsasldb.so.2.0.22 7f3eed1c4000-7f3eed1c8000 r-xp 00000000 fd:0a 795707 /usr/lib64/sasl2/libplain.so.2.0.22 7f3eed1c8000-7f3eed3c7000 ---p 00004000 fd:0a 795707 /usr/lib64/sasl2/libplain.so.2.0.22 7f3eed3c7000-7f3eed3c8000 r--p 00003000 fd:0a 795707 /usr/lib64/sasl2/libplain.so.2.0.22 7f3eed3c8000-7f3eed3c9000 rw-p 00004000 fd:0a 795707 /usr/lib64/sasl2/libplain.so.2.0.22 7f3eed3c9000-7f3eed3cd000 r-xp 00000000 fd:0a 795716 /usr/lib64/sasl2/libcrammd5.so.2.0.22 7f3eed3cd000-7f3eed5cd000 ---p 00004000 fd:0a 795716 Without the "-q" switch it is running happily till the end. Marc

8 24

modules directory
by Christ Schlacta 17 Jan '11

17 Jan '11

I've found something odd in regard to the modules directory. I ended up needing to use checkval module for ldap authentication to work properly for me. the documentation I found said to place the following in config files: checkval { item-name = Calling-Station-Id check-name = Calling-Station-Id data-type = string notfound-reject = no } at the location I wanted the check to occur, but instead I ended up needing to use just: checkval because the above code was located in modules/checkval . The question is at this point, how could I, for example, have two different checkval checks? suppose I want to check an additional attribute? I recon I need a new file, but I'm not sure if it matters what I call the new file, or, for that matter, I'm not sure what to put inside the new file, except that I'm sure it must look very similar to that above. if someone could explain the specifics of this, or tell me where to find them explained, I would much appreciate the help. one more question: can there be multiples of ANY module specified? for example, can I use two different ldap or sql modules if I were to need to (just as a bad example, I propose: 1 radius server, 2 wlans with different user bases that can't be merged into one directory for whatever reasons).

2 2

cleaning house on ldap server?
by Christ Schlacta 17 Jan '11

17 Jan '11

I've got a radius server up and running, and I want to clean up my configuration as much as possible. is it a safe assumption that if I remove a file (actually move it out of the way) and attempt to authenticate a client that if the client can successfully authenticate that everything is working? is it also safe to assume that any file with no uncommented lines is also safe to remove? I'm most interrested in removing the SQL directories and all the unused modules in the modules directory.

2 2

Re: [sipx-users] joomla ldap; joomla users not created
by mike＠grounded.net 17 Jan '11

17 Jan '11

One more thing I've wondered about is that the domain that the joomla server connecting to ldap server is different than ldap. I'm not sure if that would somehow prevent the user from being created.

1 3

joomla ldap; joomla users not created
by mike＠grounded.net 17 Jan '11

17 Jan '11

Guessing there are no joomla users on this whole list?

2 3

One root and two domain?
by gael therond 17 Jan '11

17 Jan '11

Is it possible to add a domain on an already existing root? I got the following root for now: dc=lab,dc=corp and I want to create a second Top entry on my root which will be named like this: dc=prod,dc=corp Is that possible? I've try the following syntaxe without succes. Racine.ldif: #Racine dn: dc=prod, dc=corp ObjectClass: Top ObjectClass: dcObject ObjectClass: organization o: prod.corp dc: prod #OU Groups dn: ou=groups, dc=prod, dc=geka ObjectClass: organizationalUnit ObjectClass: top ou: groups #OU Users dn: ou=users, dc=prod, dc=geka ObjectClass: organizationalUnit ObjectClass: top ou: users And then I've done the usual LdapADD command, but with the following error returned: ldap_add: Server is unwilling to perform (53) Additional info: No global Superior Knowledge. Well, my guest is that I didn't set correctly Slapd because my default root is lab.corp instead of being TLD .corp Is that theory right? Many thanks

2 2

joining several directories into a single one, then replicating it
by LALOT Dominique 17 Jan '11

17 Jan '11

Hello, We are in the process of merging several universities into a single one. As we are working on the authentication part, we already test some solutions. We put a server as a replica of our three directories, then two other replicas from this one. It works but I am not sure this is the best solution. Is it better to put a back-meta ou back-relay server for relaying data, then replication from this one? Also, if we put all data into a single one as we did, what happens if we have the same entry-uuid? Thanks in advance Dom -- Dominique LALOT Ingénieur Systèmes et Réseaux http://annuaire.univmed.fr/showuser.php?uid=lalot

1 0

← Newer
1
2
3
4
5
6
7
8
...
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical January 2011