openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

Re: Slow Mod operations on LDAP
by Bhanush Mehta 18 Jan '23

18 Jan '23

Hi Quanah, We have 80 GB RAM on the system and 300 GB SSD disk allocated for the directory. Regards Bhanush On Wed, Jan 18, 2023 at 7:20 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Wednesday, January 18, 2023 6:31 PM +0530 Bhanush Mehta > <bhanush.mehta(a)flipkart.com> wrote: > > > > > > > Hi Quanah > > > > > > The current mdb data file is GB on disk. We are using XFS, we tried with > > ext2 and ext4, we saw the same behavior for slow mods. > > > > 2376455:/var/lib/ldap$ sudo du -sh data.mdb > > 11G data.mdb > > 2376455:/var/lib/ldap$ sudo du -s data.mdb > > 10519776 data.mdb > > > > The dump from slapcat is 200 MB approx. Whenever we add it to a new > > instance, it balloons up to 10 GB and then stays around the same size. > > local-backups$ du -sh ldapdump202301180000.ldif204M > > ldapdump202301180000.ldif > > > > > > Can DB size be a reason for slow mods? And, how do we investigate the > > slow mod further? > > One is a flat text file export of the database (.ldif) > > The other is a set of binary data based off of the flat text file export, > but includes things such as indices. You cannot correlate the two size > wise. > > If your binary database after an import with slapadd -q is ~11GB, than > that's the "real" size of your database. > > How much memory do you have on the system you're using? > > I would note that it is not advised to use XFS with back-mdb. > > --Quanah > > > > -- *-----------------------------------------------------------------------------------------* *This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.***** **** *Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the organization. Any information on shares, debentures or similar instruments, recommended product pricing, valuations and the like are for information purposes only. It is not meant to be an instruction or recommendation, as the case may be, to buy or to sell securities, products, services nor an offer to buy or sell securities, products or services unless specifically stated to be so on behalf of the Flipkart group. Employees of the Flipkart group of companies are expressly required not to make defamatory statements and not to infringe or authorise any infringement of copyright or any other legal right by email communications. Any such communication is contrary to organizational policy and outside the scope of the employment of the individual concerned. The organization will not accept any liability in respect of such communication, and the employee responsible will be personally liable for any damages or other liability arising.***** **** *Our organization accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information *provided,* unless that information is subsequently confirmed in writing. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.* _-----------------------------------------------------------------------------------------_

2 1

questions on index_hash64
by Geert Hendrickx 18 Jan '23

18 Jan '23

Hi I have a few questions on the index_hash64 / olcIndexHash64 feature; > Use a 64 bit hash for indexing. The default is to use 32 bit hashes. > These hashes are used for equality and substring indexing. The 64 bit > version may be needed to avoid index collisions when the number of > indexed values exceeds ~64 million. (Note that substring indexing > generates multiple index values per actual attribute value.) Indices > generated with 32 bit hashes are incompatible with the 64 bit version, > and vice versa. Any existing databases must be fully reloaded when > changing this setting. This directive is only supported on 64 bit CPUs. What is the effect if hash collisions happen? Will slapd actually return incorrect results, or does it just need to perform extra work to discard false positives from an index search result? Since this feature only impacts indexes and not data, isn't "slapindex" enough to to regenerate indexes, instead of a full slapcat/slapadd ? Finally, is there some way to detect if a given data.mdb file uses 32- or 64-bit index hashes? I can load a "legacy" data.mdb in a server with index_hash64 enabled, and slapd does not complain, indexes are just broken. Thanks Geert

2 1

Q: incrementally adding LDIF entries using ldapadd
by Ulrich Windl 18 Jan '23

18 Jan '23

Hi! I'm working on a program that "mangles" existing LDIF files so that the LDAP server accepts them. So say 75% passed, 25% had errors (need additional fixes). I'm using ldapadd with "-c" (continue) and "-S skipped.ldif" (skipped entries) to add the input LDIF. The idea was to iterate over skipped.ldif until the file is empty, i.e.: make skipped.ldif the new input file for the next run of ldapadd. However "skipped.ldif" also contains entries that were skipped, because they had been imported (successfully) before ("ldap_add: Already exists (68)"). Is there an easy way to extract only those entries that were not added? Of course I could write a program that implements that logic, talking to the LDAP server directly, but if avoidable I'd save the time to write such a program. Regards, Ulrich

2 2

programming ldap clients
by Gustavo Rios 17 Jan '23

17 Jan '23

Hi folks! I would like to write a simple ldap client in ANSI C programming language, to perform some interactions with slapd, things very simple, like howto insert an attribute to a given entry or even how to remove it from the ldap database. May some one here provide any tips on documentation teaching howto to program for ldap ? Thanks a lot for your time and cooperation. Kind regards. -- The lion and the tiger may be more powerful, but the wolves do not perform in the circus

2 1

ldap clients
by Gustavo Rios 17 Jan '23

17 Jan '23

Hi folks, i am looking for a tutorial on how to write ldap clients using C language. May someone in this list give me a reference tutorial ? Thanks a lot for your time and cooperation. Best regards, Gustavo -- The lion and the tiger may be more powerful, but the wolves do not perform in the circus

2 1

Re: Slow Mod operations on LDAP
by Bhanush Mehta 17 Jan '23

17 Jan '23

Hi Quanah, We see the same issue with 2.4.58 (compiled from source). The most common operations are ('attr=authTimestamp', 3890) ('attr=pwdFailureTime', 713) ('attr=userPassword', 29) ('attr=memberuid', 22) ('attr=accountExpiryDate', 21) ('attr=pwdAccountLockedTime pwdFailureTime pwdFailureTime pwdAccountLockedTime', 20) ('attr=pwdAccountLockedTime pwdFailureTime pwdFailureTime', 16) ('dn="cn=DISABLED_USERS,ou=Groups,dc=org,dc=com"', 15) ('attr=member', 15) I am able to debug that mod operations are fast on a fresh mdb, but after a certain number of operations the mdb size is going from 300 MB to 10 GB. And, the time spent per operation is like 1-2 seconds for every mod, and 5-6 seconds when there are a large number of mods. We also use a group for disabling users, when running mod to add users to that group we are seeing all ldap binds and other mods slowing as well. We have sortvals enabled for all groups. We have the following indexes: olcDbIndex: objectClass eq olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: uid eq olcDbIndex: uidNumber eq olcDbIndex: uniqueMember eq olcDbIndex: gidNumber eq olcDbIndex: displayName eq olcDbIndex: cn eq olcDbIndex: sn eq olcDbIndex: member eq Regards Bhanush On Mon, Jan 9, 2023 at 9:11 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, December 23, 2022 9:06 PM +0530 Bhanush Mehta > <bhanush.mehta(a)flipkart.com> wrote: > > > > > Hi All, > > > > We are seeing very slow MOD operations on our ldap (250 MB data dump), > > while using mdb (data.mdb is 6.4 Gb). The average MOD operation is going > > to 8-9 seconds. > > We are seeing 1k disk ops and 6-7MB/s writes. The disk is 4096 IOPS Sata > > SSD, we have seen write speed to be 126 MB/s generally. > > > > The slapd version is slapd (May 14 2022 18:35:44). > > The above is not a valid version. At a guess you're using an OpenLDAP 2.4 > build from Debian, but you'd have to check your package manager to confirm. > > It would be helpful to know what the mod operations are doing (I.e., > adding > new attribute values to a multi-valued attribute that has a lot of values > already, etc) > > --Quanah > > > > -- *-----------------------------------------------------------------------------------------* *This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.***** **** *Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the organization. Any information on shares, debentures or similar instruments, recommended product pricing, valuations and the like are for information purposes only. It is not meant to be an instruction or recommendation, as the case may be, to buy or to sell securities, products, services nor an offer to buy or sell securities, products or services unless specifically stated to be so on behalf of the Flipkart group. Employees of the Flipkart group of companies are expressly required not to make defamatory statements and not to infringe or authorise any infringement of copyright or any other legal right by email communications. Any such communication is contrary to organizational policy and outside the scope of the employment of the individual concerned. The organization will not accept any liability in respect of such communication, and the employee responsible will be personally liable for any damages or other liability arising.***** **** *Our organization accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information *provided,* unless that information is subsequently confirmed in writing. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.* _-----------------------------------------------------------------------------------------_

2 1

Discovering certificate locations from libldap
by Norman Gray 17 Jan '23

17 Jan '23

Greetings. Should I be able to discover the (default) locations of SSL certificates, via the libldap library? This can be useful when debugging why cert checks are failing -- where is the library checking? (am I using the library I think I am...?!) Of course dtruss and co can help here. ldap_get_option with LDAP_OPT_X_TLS_CACERTDIR (and friends) looks like it should say this, but when I explore that, it appears to show only settings added with ldap_set_option, thus only settings overriding a default. And this appears to be confirmed in libraries/libldap/tls_o.c:tlso_ctx_init. That function hands over to SSL functions, and while in principle I could retrieve a TLS session context with LDAP_OPT_X_TLS_{,SSL_}CTX, there are clear warnings that I shouldn't be tinkering with this. The fact that I'm this deep in the code suggests that either (a) this is not supported, or (b) I'm looking in the wrong place. I could in principle use functions from the OpenSSL library, like X509_get_default_cert_dir_env(), but that requires me to know which SSL library the libldap library was linked against (and that it was indeed OpenSSL), which has its own complications. Also, if I'm confident I know that, I have other ways to confirm the cert directory. Best wishes, Norman -- Norman Gray : https://nxg.me.uk

1 0

dynlist vs memberof performance issues
by Mark Cairney 12 Jan '23

12 Jan '23

Hi, I've been out the LDAP loop for a bit but the recent discussion of the memberof overlay on 2.5 piqued my curiosity. Having upgraded a Dev box, removed the memberof elements from the database and replaced the memberof overlay with dynlist the queries appear to work as expected but are both a) slow and b) heavily CPU-intensive on the LDAP server. 2021-09-01T12:47:17.603513+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 fd=12 ACCEPT from IP=192.168.152.33:58738 (IP=129.215.17.9:636) 2021-09-01T12:47:17.687488+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 fd=12 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384 2021-09-01T12:47:17.688032+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" 2021-09-01T12:47:17.688470+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=0 SRCH attr=supportedSASLMechanisms 2021-09-01T12:47:17.688878+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=0 SEARCH RESULT tag=101 err=0 qtime=0.000014 etime=0.000214 nentries=1 text= 2021-09-01T12:47:17.811279+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=1 BIND dn="" method=163 2021-09-01T12:47:17.819249+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=1 RESULT tag=97 err=14 qtime=0.000030 etime=0.009084 text=SASL(0): successful result: 2021-09-01T12:47:17.908889+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=2 BIND dn="" method=163 2021-09-01T12:47:17.909836+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=2 RESULT tag=97 err=14 qtime=0.000031 etime=0.000181 text=SASL(0): successful result: 2021-09-01T12:47:17.938839+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=3 BIND dn="" method=163 2021-09-01T12:47:17.939621+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=3 BIND authcid="mcairney(a)EASE.ED.AC.UK" authzid="mcairney(a)EASE.ED.AC.UK" 2021-09-01T12:47:17.940213+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=3 BIND dn="uid=mcairney,ou=people,ou=central,dc=authorise-dev,dc=ed,dc=ac,dc=uk" mech=GSSAPI bind_ssf=256 ssf=256 2021-09-01T12:47:17.940616+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=3 RESULT tag=97 err=0 qtime=0.000024 etime=0.000409 text= 2021-09-01T12:47:18.227342+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=4 SRCH base="dc=authorise-dev,dc=ed,dc=ac,dc=uk" scope=2 deref=0 filter="(uid=mcairney)" 2021-09-01T12:47:18.227703+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=4 SRCH attr=* + 2021-09-01T12:47:31.392255+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=5 UNBIND 2021-09-01T12:47:31.460705+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 op=4 SEARCH RESULT tag=101 err=0 qtime=0.000031 etime=13.233679 nentries=1 text= 2021-09-01T12:47:31.461098+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[30075]: conn=1019 fd=12 closed I'm guessing that as the values are computed that this will be heavier on the CPU but it seems a bit excessive? Has anyone else noticed any similar performance issues? This is a relatively low-specced DEV server (2 vCPUs, 4GB RAM) so I guess this could be a factor but there's no io waiting on the server and no swapping? The database is on a par in size with our Production service ( about 400K user objects with 1 group object per user and then about 80K actual groups of users) The config for the primary DB (ACLs and rootPW redacted) is: dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /opt/openldap/var/openldap-data/authorise olcSuffix: dc=authorise-dev,dc=ed,dc=ac,dc=uk olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 2 olcReadOnly: FALSE olcSecurity: ssf=1 olcSecurity: update_ssf=112 olcSecurity: simple_bind=64 olcSizeLimit: unlimited olcSyncUseSubentry: FALSE olcTimeLimit: unlimited olcMonitoring: TRUE olcDbEnvFlags: writemap olcDbEnvFlags: nometasync olcDbNoSync: FALSE olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber pres,eq olcDbIndex: gidNumber pres,eq olcDbIndex: eduniType eq olcDbIndex: gecos pres,eq,sub olcDbIndex: eduniCategory eq olcDbIndex: mail pres,eq,sub olcDbIndex: eduniSchoolCode eq olcDbIndex: eduniIDStatus eq olcDbIndex: eduniCollegeCode eq olcDbIndex: eduniOrgCode eq olcDbIndex: memberOf pres,eq olcDbIndex: eduniLibraryBarcode pres,eq olcDbIndex: eduniOrganisation pres,eq,sub olcDbIndex: eduniServiceCode pres,eq olcDbIndex: krbName pres,eq olcDbIndex: eduPersonAffiliation pres,eq olcDbIndex: eduPersonEntitlement pres,eq olcDbIndex: sn pres,eq,sub olcDbIndex: eduniIdmsId pres,eq olcDbIndex: member pres,eq olcDbIndex: memberUid pres,eq olcDbIndex: eduniRefNo pres,eq olcDbIndex: eduniTitle pres,eq olcDbIndex: title pres,eq,sub olcDbIndex: eduniCardNumber pres,eq olcDbIndex: eduniYearOfStudy eq olcDbIndex: description pres,eq,sub olcDbIndex: givenName pres,eq,sub olcDbIndex: aliasedObjectName eq olcDbIndex: yubiKeyId pres,eq olcDbIndex: isMemberOf pres,eq olcDbIndex: hasMember pres,eq olcDbIndex: proxyAddresses pres,eq,sub olcDbMaxReaders: 96 olcDbMaxSize: 32212254720 olcDbMode: 0600 olcDbSearchStack: 16 structuralObjectClass: olcMdbConfig dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcSyncProvConfig olcOverlay: {0}syncprov structuralObjectClass: olcSyncProvConfig dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 02+00:00 00+04:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig dn: olcOverlay={2}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynListConfig olcOverlay: {2}dynlist olcDynListAttrSet: {0}groupOfURLs memberURL member+memberOf@groupOfNames structuralObjectClass: olcDynListConfig -- /**************************** Mark Cairney ITI Enterprise Services Information Services University of Edinburgh Tel: 0131 650 6565 Email: Mark.Cairney(a)ed.ac.uk *******************************/ The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

12 27

Queries regarding Openldap migration from 2.4.51 to 2.6.2
by Nagesh Nikavade (EXT-NSB) 11 Jan '23

11 Jan '23

Hi Team, We are migrating openldap from 2.4.51 to 2.6.2 and we have the following queries 1. What is the End of life date for 2.4.x series? 2. OpenLdap 2.6.x doesn't have BDB Data base Support but has MDB, but in our existing machines where 2.4.51 is installed. Our data is populated in ".BDB" files. So is there is any guide where and how our data will be migrated from .BDB format to .MDB format ? 3. There is a utility db_verify which verifies .BDB files which is not working for .MDB files. What is utility to verify .MDB data files? Best Regards, Nagesh

4 3

newer TLS clients (> 3.0?) can't connect to OpenLDAP's TLS with SSSD
by Jarett DeAngelis 11 Jan '23

11 Jan '23

hi - using OpenLDAP 2.6.3 and finding that newer LDAP client libraries (like the one that comes with Ubuntu 22.04.1 LTS) can't complete a connection to the LDAP server's TLS port. A machine I have running Rocky 8.6, however, with OpenSSL 1.1.1k, connects just fine. This is using self-generated certificates, but the correct CA cert and server cert have been provided to SSSD to use for login. The two machines are using identical certificates and SSSD configuration files. How do we begin to troubleshoot this? The trouble is seen in the SSSD log: (2023-01-09 21:08:26): [be[default]] [fo_resolve_service_send] (0x0100): [RID#13] Trying to resolve service 'LDAP' (2023-01-09 21:08:26): [be[default]] [get_server_status] (0x1000): [RID#13] Status of server '10.8.8.60' is 'name not resolved' (2023-01-09 21:08:26): [be[default]] [get_port_status] (0x1000): [RID#13] Port status of port 636 for server '10.8.8.60' is 'neutral' (2023-01-09 21:08:26): [be[default]] [fo_resolve_service_activate_timeout] (0x2000): [RID#13] Resolve timeout [dns_resolver_timeout] set to 6 seconds (2023-01-09 21:08:26): [be[default]] [get_server_status] (0x1000): [RID#13] Status of server '10.8.8.60' is 'name not resolved' (2023-01-09 21:08:26): [be[default]] [set_server_common_status] (0x0100): [RID#13] Marking server '10.8.8.60' as 'resolving name' (2023-01-09 21:08:26): [be[default]] [check_if_online_delayed] (0x2000): [RID#12] Check online req created. (2023-01-09 21:08:26): [be[default]] [set_server_common_status] (0x0100): [RID#13] Marking server '10.8.8.60' as 'name resolved' (2023-01-09 21:08:26): [be[default]] [be_resolve_server_process] (0x1000): [RID#13] Saving the first resolved server (2023-01-09 21:08:26): [be[default]] [be_resolve_server_process] (0x0200): [RID#13] Found address for server 10.8.8.60: [10.8.8.60] TTL 7200 (2023-01-09 21:08:26): [be[default]] [sdap_uri_callback] (0x0400): [RID#13] Constructed uri 'ldaps://10.8.8.60:636' (2023-01-09 21:08:26): [be[default]] [sssd_async_socket_init_send] (0x4000): [RID#13] Using file descriptor [23] for the connection. (2023-01-09 21:08:26): [be[default]] [sssd_async_socket_init_send] (0x0400): [RID#13] Setting 60 seconds timeout [ldap_network_timeout] for connecting (2023-01-09 21:08:26): [be[default]] [sss_ldap_init_sys_connect_done] (0x0020): [RID#13] ldap_install_tls failed: [Connect error] [unknown error] (2023-01-09 21:08:26): [be[default]] [sss_ldap_init_state_destructor] (0x0400): [RID#13] calling ldap_unbind_ext for ldap:[0x55c44d26c1b0] sd:[23] (2023-01-09 21:08:26): [be[default]] [sss_ldap_init_state_destructor] (0x0400): [RID#13] closing socket [23] (2023-01-09 21:08:26): [be[default]] [sdap_sys_connect_done] (0x0020): [RID#13] sdap_async_connect_call request failed: [5]: Input/output error. (2023-01-09 21:08:26): [be[default]] [sdap_handle_release] (0x2000): [RID#13] Trace: sh[0x55c44d24a740], connected[0], ops[(nil)], ldap[(nil)], destructor_lock[0], release_memory[0] (2023-01-09 21:08:26): [be[default]] [_be_fo_set_port_status] (0x8000): [RID#13] Setting status: PORT_NOT_WORKING. Called from: ../src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_done: 1633 (2023-01-09 21:08:26): [be[default]] [fo_set_port_status] (0x0100): [RID#13] Marking port 636 of server '10.8.8.60' as 'not working' (2023-01-09 21:08:26): [be[default]] [fo_set_port_status] (0x0400): [RID#13] Marking port 636 of duplicate server '10.8.8.60' as 'not working' Thanks, Jarett

5 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical