openldap-technical

openldap-technical@openldap.org

7 participants
9901 discussions

Removing olcAccess entry
by Katherine Faella 12 Jan '16

12 Jan '16

For the life of me I can not figure out the syntax for performing this. Here is my snippet of config.ldif: dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcSuffix: dc=sakai,dc=uri,dc=edu olcAccess: {0}to * by peername.ip="131.128.1.0%255.255.255.0" +0 break by peername.ip="131.128.122.0%255.255.255.0" +0 break by peername.ip="158.123 .255.8%255.255.255.248" +0 break by peername.ip="127.0.0.1" +0 break olcAccess: {1}to * by dn.regex="^URIEduauthid=.+,dc=sakai,dc=uri,dc=edu$$" read by * auth olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,dc=sakai,dc=uri,dc=edu ..... I need to remove the olcAccess {0} as we need to access this server from new ips. We are using a firewall to protect the server going forward. I have created the file removeips containing: dn: olcDatabase={1}hdb,cn=config changetype: modify delete: olcAccess olcAccess: {1} Running the command ldapmodify -W -x -h antons.uri.edu -D "cn=admin,cn=config" -f /root/ldapscripts/removeips gives me: modifying entry "olcDatabase={1}hdb,cn=config" ldap_modify: No such attribute (16) additional info: modify/delete: olcAccess: no such attribute What am I doing wrong? Thanks, Kathy -- Katherine Faella tel: (401) 874-4469 Senior Technical Programmer kmf(a)uri.edu University of Rhode Island University Computing Systems(UCS) 210 Flagg Road Kingston, Rhode Island

4 4

lmdb VL32 high virtual address usage
by Jeremiah Morrill 11 Jan '16

11 Jan '16

This sort of coincides with ITS issue 8347 I just reported. With ldmb VL32, I’ve noticed that it can eat up a lot of memory space. Sometimes ~500mb for an 800mb db after reading every record, one by one using the same readonly transaction/cursor. I found that modifying MDB_ERPAGE_SIZE from 16384 to 256 brought virtual memory usage down substantially (~30megs). I have not noticed any adverse effects from this change or MDB_MAP_FULL. The mapped address spaces to seem to get deallocated on the close of the environment, not the transaction, which sounds like its being cached in the env->me_rpages for reasons explained in mdb_rpage_get comments. Is the mem map cache supposed to be this aggressive by design, or just because this area of the code is so new...or simply a usage error on my part? If it’s by design, could there be a consideration to make MDB_ERPAGE_SIZE a #define’able value in the public lmdb.h so one could tweak the behavior? -Jer

2 1

Re: what databases are to be replicated for a slave?
by Jephte Clain 08 Jan '16

08 Jan '16

2015-12-29 20:38 GMT+04:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Tuesday, December 29, 2015 12:48 PM +0400 Jephte Clain > <jephte.clain(a)univ-reunion.fr> wrote: > > > >>> No. Replicas do not accept writes. Replicas do not have a master >>> configuration for cn=config. Replica's do not have server IDs. >> >> ok I guess I understand. this is the reason why I usually call them >> "slaves", not replicas (but I messed things up and called them replicas >> this time ^^) >> I also have replicas that only replicate data (or a subset of data) for >> some services > > > No. The terms replica and slave are interchangeable. As are master and > provider. Given the very negative connotations of the concept of masters > and slaves, the preferred terms are "provider" instead of "master" and > "replica" instead of "slaves". Aaargh, now I can't help thinking about "providers" whipping "replicas". slapd can be so cruel sometimes :-) And in case you wonder, here in reunion island we have a (relatively) long history of slavery. We even have a day to commemorate abolition of slavery: december 20th > > >> the slaves are there in case of catastrophic failure of both masters (we >> had one of these failure for another service due to a problem with the >> shared storage. No one want to have this kind of emergency...) >> If the master(s) crash, I just have to choose a slave as the new master, >> slapcat the cn=config database, update the provider address, slapadd the >> updated config, and update the loadbalancer settings. this is a bit of >> work but at least we can restore service in a (relatively) small amount >> of time. > > > If they accept writes, they are not slaves/replicas. If you are replicating > cn=config across all the systems, then they must all be masters. Your > general description above sounds like you do not correctly understand how > MMR functions. OK... I finally understand what was bothering you My replicas do _not_ accept writes. Sorry to have let you think so I have two setups: - a "legacy" one, with one master accessible to the applications that can write, and two complete replicas (data + cn=config) behind a loadbalancer for the reads. One of these replicas could become the new master if the needs arise. And there are a bunch of partial replicas (only a subset of data) for some specific services. The reason is on our vmware farm, network access is regularly cut (don't know why, the system guy neither), and these services cannot reconnect on their own... piece of #$*! software :( - a "new" one, with two masters in mirror mode (only one get the writes at anytime thanks to the loadbalancer), and two replicas (only data) which get all the reads. I feel like configuring chaining to be able to write from the replicas, but I have no experience of the benefits of this configuration... I have read the admin guide several times, but I am open to any suggestion to improve my skills > >>> Accesslog is unique to a given master. >> >> Ok that's what I wanted to know for sure >> >> Shouldn't the doc stat this clearly? > > > Please file an ITS noting the docs should be updated on this point. Ok. I may even provide a patch. I'll do it tomorrow. Have a nice day/night (don't know where you live ^^) Regards, Jephté -- Jephté CLAIN | Développeur, Intégrateur d'applications Service Système d'Information Direction des Systèmes d'Information Tél: +262 262 93 86 31 || Gsm: +262 692 29 58 24

2 2

Out of ideas when troubleshooting TLS negotiation failure
by Graham Allan 08 Jan '16

08 Jan '16

This feels like a lame question, but I'm out of ideas, so... I'm moving samba service between a couple of FreeBSD systems (9.3 to 10.2), and I'm stuck on getting samba on the new machine to connect to our openldap server over ssl - frustrating since I've been running samba+ldap for 15 years or so; feel sure I'm missing something basic! The smbd-to-ldap connection works fine with no encryption, but I get errors when using either TLS to port 389 ("Failed to issue the StartTLS instruction: Connect error") or SSL to 636. However I'm pretty certain it's not a certificate or CA validation issue. All my other ldap clients on that server are working as expected, including a simple "ldapsearch -ZZ". Both openssl s_client and gnutls-cli show the ldap server certificate validating. Maximum debugging on the ldap server gave me: connection_read(3): TLS accept failure error=-1 id=1042, closing conn=1042 fd=3 closed (TLS negotiation failure) Running smbd under gbd shows ldap_start_tls_s (ldap_struct, NULL, NULL) in smb_ldap_start_tls is returning -11 (LDAP_CONNECT_ERROR). That doesn't give me any ideas, sadly! Capturing the packet exchange between smbd and slapd, I'm seeing the (smbd) client sends a "decrypt error" (TLS alert code 51) to the ldap server after receiving the certificate, while the working "ldapsearch -ZZ" moves on to client key exchange etc. Besides all my other ldap clients working successfully, I think I'd expect to see a TLS alert more like 42-48 if it were a cert validation problem. I'm not sure where to try looking next for the cause, would welcome any suggestions... Thanks, Graham

3 5

Knowing free mdb space
by Angel L. Mateo 07 Jan '16

07 Jan '16

Hello, I have recently migrated my openldap server from hdb to mdb. In this kind of database you configure the maximal database size with maxsize option. Although I have configure this option with 8GB, more than the double of my actual database size, I would like to know if there is any way to calculate the remaining size. According to [1] you can get the actual size with a du. But my problem is that I'm using zfs with a compressed file system, so du reports the compressed size, not the real one. Is there any way to get this value? Or my real maximum size is 8GB after compression? [1] https://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning_8.0 -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868887590 Fax: 868888337

4 5

LMDB ITS 8324 WriteMap performance on Windows
by Victor Baybekov 05 Jan '16

05 Jan '16

Hi, Thanks a lot for ITS#8324! For embedded, not server, use case that change adds much convenience. I have tested the master from .NET via P/Invoke and do not see any major slowdown with default options. To insert 10M <int32,int32> pairs inside a single transaction v.0.9.14 takes minimum 3400 msec, latest master takes minimum 3750 msec. This is not scientific, just best result from 10 runs. Sometimes both timings increase to 5000+ msecs. On average slowdown is visible but tolerable - from 2.9 Mops to 2.6 Mops (absolute numbers are still awesome!). With Append and NoSync I could get 3.45 Mops on the same test with master build. However, with WriteMap performance of master drops 3x to 10000 msec or just 1 Mops, while for the v.0.9.14 performance with WriteMap improves to 2350 msec or 4.25 Mops. Is this the cost of convenience or it could be fixed so that WriteMap still "is faster and uses fewer mallocs" as the docs say? Best regards, Victor

3 5

2.4.43 "make test" hanging in "test039-glue-ldap-concurrency" on Solaris 10
by Greg Earle 04 Jan '16

04 Jan '16

Forgive me if this is the wrong place (maybe openldap-build?). I've built OpenLDAP 2.4.43 on Solaris 10 1/13 OK, but when I run the "make test" phase it hangs in the "test039-glue-ldap-concurrency" test: -- >>>>> Starting test039-glue-ldap-concurrency for bdb... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9012... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9013... Using ldapsearch to check that slapd is running... MONITORDB yes SRCDIR /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/testrun/./testdata DSTDIR /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/testrun pwd /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests Using tester for concurrent server access... PID=16664 - Read(1000): entry="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". [... blah blah etc. ...] PID=17066 - Bind(1000): dn="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=17080 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). PID=17096 - Read(1000): entry="cn=Somewhere,ou=Meta,o=Example,c=US". slapd-bind PID=17066: ldap_sasl_bind_s: Invalid credentials (49) PID=17102 - Bind(1000): dn="cn=Bjorn Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=17112 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). PID=17118 - Read(1000): entry="cn=Backend 1,cn=Backends,cn=Monitor". PID=17135 - Bind(1000): base="ou=People,o=Example,c=US", filter="(userPassword=*)" attr="userPassword". PID=17135 - Bind base="ou=People,o=Example,c=US" filter="(userPassword=*)" got 3 values. -- This is the last output I get. "ps" shows several test servers running as well as the test harness clients; "lsof" shows the clients stuck in poll() and doing nothing. They all have ESTABLISHED connections to their servers. -- zorro:1:1014 [/] # truss -p 17118 pollsys(0x0002CEFC, 1, 0x00000000, 0x00000000) (sleeping...) ^C zorro:1:1015 [/] # truss -p 17135 pollsys(0x0002C39C, 1, 0x00000000, 0x00000000) (sleeping...) -- I did a "gcore" and it says it's waiting in ldap_int_select(): -- (dbx) where [1] __pollsys(0x2c39c, 0x1, 0x0, 0x0, 0xfef523f0, 0x0), at 0xfeede7ac [2] _pollsys(0x2c39c, 0x1, 0x0, 0x0, 0x0, 0x2bb00), at 0xfeece490 [3] _poll(0x2c39c, 0x1, 0xffffffff, 0xffbfed8c, 0xff3ec2cc, 0x0), at 0xfee74ccc =>[4] ldap_int_select(ld = 0x289d0, timeout = (nil)), line 1139 in "os-ip.c" [5] wait4msg(ld = 0x289d0, msgid = 3, all = 1, timeout = (nil), result = 0xffbfef30), line 312 in "result.c" [6] ldap_result(ld = 0x289d0, msgid = 3, all = 1, timeout = (nil), result = 0xffbfef30), line 117 in "result.c" [7] ldap_sasl_bind_s(ld = 0x289d0, dn = 0x2ba58 "cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US", mechanism = (nil), cred = 0xffbff080, sctrls = (nil), cctrls = (nil), servercredp = (nil)), line 210 in "sasl.c" -- Why are these things just sitting here instead of completing and exiting? BTW I am using the Solaris robust mutex fix patch (it wouldn't build otherwise) posted a few weeks back. Configured via ./configure --prefix=/opt/openldap --enable-modules --with-ldap-module=dynamic\ --enable-bdb --enable-rlookups --enable-wrappers --enable-dynamic \ --enable-ldap --disable-ipv6 --enable-overlays --with-threads --enable-relay\ --enable-syslog Puzzled in Pasadena, - Greg P.S. Here's the "ps" output if it matters zorro:1:1011 [/] # ps -ax PID TT S TIME COMMAND [...] 4413 pts/5 S 0:00 make test 4414 pts/5 S 0:00 sh -ce cd tests; make test 4415 pts/5 S 0:00 make test 4416 pts/5 S 0:00 make bdb 4418 pts/5 S 0:00 /bin/sh ./run -b bdb all 4429 pts/5 S 0:00 /bin/sh ./scripts/all 13917 pts/5 S 0:00 -sh 13922 pts/5 S 0:00 -csh 16491 pts/5 S 0:00 /bin/sh ./scripts/test039-glue-ldap-concurrency 16502 pts/5 S 0:44 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/servers/slapd/.libs/slapd -s0 -f /usr/local/src/networking/OpenLDAP 16560 pts/5 S 0:05 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/servers/slapd/.libs/slapd -s0 -f /usr/local/src/networking/OpenLDAP 16604 pts/5 S 2:05 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/servers/slapd/.libs/slapd -s0 -f /usr/local/src/networking/OpenLDAP 16649 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-tester -P ./progs -d /usr/local/src/network 16668 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 16674 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 16677 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-modrdn -h localhost -p 9013 -D cn=Man 16680 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 16943 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-modrdn -h localhost -p 9013 -D cn=Man 16957 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-modify -h localhost -p 9013 -D cn=Man 16959 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-addel -h localhost -p 9013 -D cn=Mana 16981 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 17005 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-search -h localhost -p 9013 -D cn=Man 17017 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-read -h localhost -p 9013 -D cn=Manag 17033 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 17047 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-search -h localhost -p 9013 -D cn=Man 17061 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-read -h localhost -p 9013 -D cn=Manag 17066 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 17080 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-search -h localhost -p 9013 -D cn=Man 17096 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-read -h localhost -p 9013 -D cn=Manag 17102 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L 17112 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-search -h localhost -p 9013 -D cn=Man 17118 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-read -h localhost -p 9013 -D cn=Manag 17135 pts/5 S 0:00 /usr/local/src/networking/OpenLDAP/openldap-2.4.43/tests/progs/.libs/slapd-bind -h localhost -p 9013 -l 1000 -L

1 0

Re: pass-through authentication
by Dan White 04 Jan '16

04 Jan '16

On 12/17/15 18:32 -0600, Timothy Keith wrote: >We are attempting to set up an LDAP server which will answer queries >from an application. The database will contain metadata on a set of >users in the application. The application will also query the server >to authenticate the user’s password, however, this server will not >house the password. That resides on another server, which our server >will query. We do not have administrative rights to the other >server. > > The difficulty we are having now is setting up the pass-through >authentication for the passwords. Any pointers in how to proceed with >this would be greatly appreciated. On 12/21/15 17:24 -0600, Timothy Keith wrote: >We have limited access to the servers. Same company, different IT >organization. Our LDAP requirement must be transparent to those servers. >We want to inherit the LDAP directory information from the Unix servers - >mostly the user Id and passwords, and add information that is needed by >applications that our servers will manage. On 12/31/15 09:51 -0600, Timothy Keith wrote: > On Wed, Dec 30, 2015 at 7:04 PM, Dan White <dwhite(a)cafedemocracy.org> wrote: >> On 12/30/15 18:51 -0600, Timothy Keith wrote: >> >>> This is tail of the latest saslauthd debug output : >>> >>> ldap_sasl_interactive_bind: user selected: DIGEST-MD5 >>> >> >> res_errno: 7, res_error: <SASL(-4): no mechanism available: >, res_matched: >>> <> >>> ldap_free_request (origid 1, msgid 1) >>> ldap_int_sasl_bind: DIGEST-MD5 >>> ldap_parse_sasl_bind_result >>> ldap_parse_result >>> ldap_msgfree >>> ldap_err2string >>> >> >> Is DIGEST-MD5 available on your ldap server? Try: >> >> ldapsearch -LLL -x -H ldap://1.2.3.4 -s "base" -b "" >> supportedSASLMechanisms >> Which should list the advertised sasl mechanisms. >> >> Verify the digest-md5 mechanism is installed with >> saslpluginviewer/pluginviewer. > >Dan, that ldapsearch returns : >dn: >supportedSASLMechanisms: PLAIN The server is only offering the PLAIN mechanism to you. It appears you're using saslauthd's ldap backend, and have explicitly configured 'ldap_mech: digest-md5' in your corresponding config. If that's correct, you could change that to PLAIN instead. Consider protecting the bind with tls if available. slapo-pbind may be a simpler alternative (to pass-through sasl authentication), depending on the specifics of your setup. -- Dan White

3 8

Re: openldap 2.4.43 keeps crashing
by Jephte Clain 04 Jan '16

04 Jan '16

2015-12-30 22:51 GMT+04:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Wednesday, December 30, 2015 10:36 PM +0400 Jephte Clain > <jephte.clain(a)univ-reunion.fr> wrote: > >> 2015-12-29 20:47 GMT+04:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: >>> >>> --On Monday, December 28, 2015 10:18 PM -0800 Quanah Gibson-Mount >>> <quanah(a)zimbra.com> wrote: >>> >>>> David, >>>> >>>> Why haven't you reported this to the ITS? >>> >>> >>> >>> Discussed with Howard. It isn't in 0.9 yet because it hasn't been >>> confirmed if the fix is good or not. David, if that fix has resolved >>> the issue, *please* follow up with the ITS noting that to be the case. >>> >> >> Hello, >> >> I can confirm this is the problem I have. Starting slapd in debug >> mode, it dies after some time: >> >> /tmp/buildd/openldap-2.4.43/servers/slapd/back-mdb/../../../libraries/lib >> lmdb/mdb.c:5276: Assertion 'NUMKEYS(mp) > 1' failed in >> mdb_page_search_root() >> /usr/local/slaptools/lib/functions: line 44: 30232 Abandon >> /usr/sbin/slapd -h "$SLAPD_SERVICES" -g "$SLAPD_GROUP" -u >> "$SLAPD_USER" -F "$SLAPDD" -d "$dlevel" "$@" >> >> I didn't notice it because it doesn't dump core. And somehow, the >> initscript I use eats the stderr output of slapd (I'll fix it for >> future errors) >> >> For now, I'll revert to the previous working version, but I'm willing >> to test any fix >> The funny part is only the replica dies regularly, not the master >> although it is the one to receive the writes > > > You can apply the patch that was made to mdb.master to the 2.4.43 source > tree, and see if it resolves the problem or not. ;) Hmmm... I really need some holidays... I couldn't manage to find the commit today (too tired?) and now I remember grep is my friend $ git checkout mdb.master $ git log --pretty=oneline | grep 8336 58d1fd4c73c96ef3097816e975b3d421ead4d86e ITS#8336 fix page_search_root assert on FreeDB I'll have a look tomorrow. Thanks. Regards, Jephté -- Jephté CLAIN | Développeur, Intégrateur d'applications Service Système d'Information Direction des Systèmes d'Information Tél: +262 262 93 86 31 || Gsm: +262 692 29 58 24

2 2

Re: users don't get prompt to change password (pwdMustChange attribute)
by Rajagopal Rc 31 Dec '15

31 Dec '15

Hi All, Can any one help me on this please Thanks From: Rajagopal Rc/BLR/TCS To: openldap-technical(a)openldap.org Date: 12/24/2015 12:07 PM Subject: users don't get prompt to change password (pwdMustChange attribute) Hello, I am trying to force user to change their password at first logon and on password reset. OS RHEL7 Openldap version 2.4.39-7.el7_1.x86_64 I have tried the following 1) I have set the pwdMustChange attribute to TRUE in ppolicy, but when user logon to client at first time or after resetting password, it just allow suer to logon without prompting to change the password, 2) I have set the pwdReset attribute to TRUE in user attribute for particular user, this doesn't allow user to login at all and keep prompting for password without allowing to login. Also i red in blogs this is not correct way, but couldn't find more information on this. is there any way to force users to change their password at first logon and after resetting password by admin. ? Current ppolicy Thanks & Regards Raj =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical