389-users May 2020

389-users@lists.fedoraproject.org

10 participants
30 discussions

ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0
by Graham Leggett 11 Dec '23

11 Dec '23

Hi all, We have a long standing 389ds master LDAP server that was found to be unable to contact it’s slaves. Most specifically, the slaves show nothing in their logs about any kind of connection, while the master is logging this: [12/Nov/2019:21:39:47.212715697 +0000] - ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0 (Unknown error, host “ldap01:636”) Key is "system error 0 (no error)”, which leaves us stumped. The error is obviously “success”. Has anyone seen this kind of thing before? This is 389ds running on CentOS7 as follows: 389-ds-base-1.3.9.1-10.el7.x86_64 Regards, Graham —

3 9

Replication with SSLCLIENTAUTH: server sent no certificate
by Eugen Lamers 01 Feb '21

01 Feb '21

I'm trying to setup a replication with a certificate based authentication between supplier and consumer. The certificates in the certdb at /etc/dirsrv/slapd-XXX contain the very same CA with which the respective server certificates in the certdbs have been signed. The certificates all have the 'u' flag, and the CA has the C and T flag. The replication (on the supplier) has been setup such that TLS and certificate based authentication is used, see extract from the replication agreement object: objectclass: nsds5ReplicationAgreement nsds5replicahost: <consumer-hostname> nsds5replicaport: 389 nsds5replicatransportinfo: TLS nsds5replicabindmethod: SSLCLIENTAUTH Trying to initialize the consumer raises this error in the error-log of the supplier (the host sending the starttls connection request): Replication bind with EXTERNAL auth failed: LDAP error 48 (Inappropriate authentication) (missing client certificate) The certificate that the server should have sent can, however, be used with the ldap commandline tools as ldapsearch. In this case a wireshark trace clearly shows that the client sends the certificate during the TLS handshake, while in the above case it doesn't. The TLS handshake defines that the client has to send an "empty certificate" if it does not have a certificate that has been issued by a CA offered by the server during the handshake. I can't see a reason for the client to think the condition isn't met. The certificate with which the server (supplier) is setup is the only one available. Is it possible that the server does not know which certificate it has to use for authentication with the consumer server? And if so, how do I make the server know? The 389-ds in use is the version 1.4.1.6~git0.5ac5a8aad. The problem was the same with 1.4.0.3. Thanks, Eugen

3 11

Problem browsing LDAP with Outlook
by Chris Bryant 26 Aug '20

26 Aug '20

When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS. When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well. I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also. Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration. Thanks, Chris USA.NET You Run Your Business. We'll Run Your Email. This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.

3 2

MemberOf group restrictions to a client system (server and client running CentOS 7)
by Janet Houser 06 Aug '20

06 Aug '20

Hi, I'm new to 389-ds and last week downloaded and installed the software. I have a running instance of the server, and I've added TLS/SSL. I've configured a CentOS 7 client to be able to query the server using TLS/SSL, and all appears working. I've created users and groups on the 389-ds server successfully. For each user and group, I've enabled posix attributes and my client can see the unix users and groups using the "getent password" or "getent group" commands. Now, here's where I'm getting tripped up.......... I need to limit which users have access to which systems. I've been trying to do this via memberOf group limitations. I found the following online resource (https://thornelabs.net/2013/01/28/aix-restrict-server-login-via-ldap-groups…) which is close enough to CentOS that the initial commands worked. I enabled the MemberOf plugin and changed the attributes per the link, and restarted the system. I created a test group (that I didn't enable a posix GID) and tried to add a single user via: Right click on group -- > click Properties --> then Members --> click Add --> Search for user --> click Add. When I try to go this route (which worked before enabling the memberOf plugin) it worked. Now it seems I get the error: "Cannot save to directory server. netscape.ldap.LDAPException: error resiult(65): Object class violation" And the messages file throws the error (/var/log/dirsrv/slapd-<instancename>/errors: "Entry "uid=test,ou=People,dc=int,dc=com" -- attribute "memberOf" not allowed [17/Feb/2016:11:22:58 -0700] memberof-plugin - memberof_postop_modify: failed to add dn (cn=testgroup,ou=Groups,dc=int,dc=com) to target. Error (65)" So it seems my server isn't quite using the memberOf plugin properly, but I'm not sure what else to enable. I'll have to solve this issue before I even try to filter login access via groups on my client system. I should mention that if I go under the advanced tab for one of the groups I created, I can add the the attribute "uniquemember", but I'm not sure what I should set the "value" to be. I've tried creating new users to see if I could set their "uniquemember" attributes, but no luck. It seems that I don't have the ability to set this attribute on individual users, only groups. This might not be the right road to head down when trying to restrict access to servers via groups, so I'm open to any suggestions. Any suggestions would be appreciated.

6 19

Re: new server setup hanging
by William Brown 01 Jun '20

01 Jun '20

Hey there, We need to see the pstacks from all threads to really determine the cause here. Can you send us a complete read out? gdb -p "pid" thread apply all bt It'd be great if you can install debug info too to help. Thanks, > On 31 May 2020, at 05:09, Crocker, Deborah <crock(a)ua.edu> wrote: > > Some more information from a coworker: > > Yeah, this sounds like an LDAP server bug. I haven't figured out what to look at to pin it down, but when it's slow to connect, I can see with strace that the primary thread hasn't called accept() yet for the connection I'm trying to open. Once it does, the whole thing goes very quickly, and I usually see a burst of other connections accepted and handled at the same time. > > Deborah Crocker, PhD > Systems Engineer III > Office of Information Technology > The University of Alabama > Box 870346 > Tuscaloosa, AL 36587 > Office 205-348-3758 | Fax 205-348-9393 > deborah.crocker(a)ua.edu > > > -----Original Message----- > From: Crocker, Deborah <crock(a)ua.edu> > Sent: Saturday, May 30, 2020 2:08 PM > To: General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org> > Subject: [EXTERNAL] [389-users] new server setup hanging > > We're trying to move into our new server setup. We have one that seems to be fine under a load but when we bring the next we're having trouble with it hanging. The second does have more clients (and different) so there could be something about what a client is doing. Here is the server: > 389-Directory/1.3.10.1 B2020.133.1625 > Installed from EPEL, running on > CentOS Linux release 7.8.2003 > > And here is the pstack output listing the only thread that is not idle. Can anyone tell me what is going on? > > Thread 44 (Thread 0x7f858e9b3700 (LWP 2515)): > #0 0x00007f860a90fe02 in slapi_atomic_load_32 () at /usr/lib64/dirsrv/libslapd.so.0 > #1 0x00007f860a8d4e8e in slapi_get_mapping_tree_node_by_dn () at /usr/lib64/dirsrv/libslapd.so.0 > #2 0x00007f860a8d5179 in slapi_be_select () at /usr/lib64/dirsrv/libslapd.so.0 > #3 0x00007f860a9296a0 in vattr_test_filter () at /usr/lib64/dirsrv/libslapd.so.0 > #4 0x00007f860a8b6ec4 in slapi_vattr_filter_test_ext_internal () at /usr/lib64/dirsrv/libslapd.so.0 > #5 0x00007f860a8b7ba6 in slapi_vattr_filter_test_ext () at /usr/lib64/dirsrv/libslapd.so.0 > #6 0x00007f8600a99e02 in acl__resource_match_aci () at /usr/lib64/dirsrv/plugins/libacl-plugin.so > #7 0x00007f8600a9b280 in acl_access_allowed () at /usr/lib64/dirsrv/plugins/libacl-plugin.so > #8 0x00007f8600aae9f7 in acl_access_allowed_main () at /usr/lib64/dirsrv/plugins/libacl-plugin.so > #9 0x00007f860a8f0cbc in plugin_call_acl_plugin () at /usr/lib64/dirsrv/libslapd.so.0 > #10 0x00007f860a8b638d in test_filter_access () at /usr/lib64/dirsrv/libslapd.so.0 > #11 0x00007f860a8b6fb5 in slapi_vattr_filter_test_ext_internal () at /usr/lib64/dirsrv/libslapd.so.0 > #12 0x00007f860a8b6d31 in slapi_vattr_filter_test_ext_internal () at /usr/lib64/dirsrv/libslapd.so.0 > #13 0x00007f860a8b7ba6 in slapi_vattr_filter_test_ext () at /usr/lib64/dirsrv/libslapd.so.0 > #14 0x00007f85ff7c0df1 in ldbm_back_next_search_entry_ext () at /usr/lib64/dirsrv/plugins/libback-ldbm.so > #15 0x00007f860a8deca6 in send_results_ext.constprop.5 () at /usr/lib64/dirsrv/libslapd.so.0 > #16 0x00007f860a8e0e09 in op_shared_search () at /usr/lib64/dirsrv/libslapd.so.0 > #17 0x0000557410dd3c0e in do_search () > #18 0x0000557410dc198a in connection_threadmain () > #19 0x00007f86086a0c5b in _pt_root () at /lib64/libnspr4.so > #20 0x00007f8608040ea5 in start_thread () at /lib64/libpthread.so.0 > #21 0x00007f86076ec8dd in clone () at /lib64/libc.so.6 > > Deborah Crocker, PhD > Systems Engineer III > Office of Information Technology > The University of Alabama > Box 870346 > Tuscaloosa, AL 36587 > Office 205-348-3758 | Fax 205-348-9393 > deborah.crocker(a)ua.edu > > > -----Original Message----- > From: William Brown <wbrown(a)suse.de> > Sent: Wednesday, May 27, 2020 5:43 PM > To: 389-users(a)lists.fedoraproject.org > Subject: [EXTERNAL] [389-users] Re: Re: Re: Advice to bring new servers into production > > > >> On 27 May 2020, at 23:20, Crocker, Deborah <crock(a)ua.edu> wrote: >> >> Thanks - I think we have enough ideas in here to get this going. One last question: >> If replication is set up through the host name - how often does the directory server do a DNS look up, or does it do it once on startup (or creation of the rep agreement)? > > I "think" it's every time it initiates the new connection - but remember, for replication, that *is* quite different to a client doing a search, so I'd be pretty careful about this. IMO you should be standing up your replacement servers in parallel, joining them all, moving the IP's then decomission the old servers. Alternately, you'll need an outage window to shutdown your old servers, export the ldif, and then import and bring up the new ones. > > I think having "IP's are a limited resource" really does make this whole process much much harder than it needs to be for you ... :( > >> >> -----Original Message----- >> From: William Brown <wbrown(a)suse.de> >> Sent: Tuesday, May 26, 2020 10:48 PM >> To: 389-users(a)lists.fedoraproject.org >> Subject: [EXTERNAL] [389-users] Re: Re: Advice to bring new servers >> into production >> >> There are a few options. The best would be a load balancer which has the ip's so that it's transparent to your LDAP servers where they are. >> >> But also as mentioned, the virtual IP's honestly is the best way. Linux can have multiple IP's on an interface so you can just have two IP's on one interface, andthat's the best way to do this. >> >> Alternately, don't rely on the IP, lower your DNS ttl's to a very short time, change the DNS A/AAAA records, and then do it that way. >> >> >> >>> On 27 May 2020, at 06:17, Crocker, Deborah <crock(a)ua.edu> wrote: >>> >>> I’d like not to take up two ip addresses per host indefinitely. We have re-IP’d our hosts before so I know we can to do this but it was during a downtime when everything was restarted. Just trying to get away with not restarting the masters. >>> >>> Deborah Crocker, PhD >>> Systems Engineer III >>> Office of Information Technology >>> The University of Alabama >>> Box 870346 >>> Tuscaloosa, AL 36587 >>> Office 205-348-3758 | Fax 205-348-9393 deborah.crocker(a)ua.edu >>> >>> From: Leo Pleiman <lpleiman(a)salsalabs.com> >>> Sent: Tuesday, May 26, 2020 3:08 PM >>> To: General discussion list for the 389 Directory server project. >>> <389-users(a)lists.fedoraproject.org> >>> Subject: [EXTERNAL] [389-users] Re: Advice to bring new servers into >>> production >>> >>> My experience has been that the replicas and consumers have a unique id, more than just an IP address which creates the trust relationship with the master. If your goal is to simply maintain an IP so your clients don't have to be repointed, I would build each new LDAP host and replication agreement, and then as you decommission the old hosts use their IP address as a virtual IP address on the replacement host. It would take a quick restart od the LDAP service to start a listener on the virtual Ip address. >>> >>> >>> Leo Pleiman >>> Senior System Engineer >>> Direct 202-787-3622 >>> Cell 410-688-3873 >>> >>> >>> >>> On Tue, May 26, 2020 at 3:57 PM Crocker, Deborah <crock(a)ua.edu> wrote: >>> We have a setup with 2 multi-masters and 3 consumers. We are now building new host and want to put them in place ultimately at the same IP address as the original ones. I need some advice on how to do this quickly and cleanly. >>> >>> To add a new consumer the idea now is to set it up and set up replications agreements from each master using consumer DNS name (don't start continuous replication yet). After initializing new consumer from one master - turn off old consumer, remove old consumer agreement from each master, and re-IP new consumer. Do we need to restart masters to re-read DNS or will it pick that up when it starts the next replication? Is this the best way to do this? >>> >>> Thanks >>> >>> Deborah Crocker, PhD >>> Systems Engineer III >>> Office of Information Technology >>> The University of Alabama >>> Box 870346 >>> Tuscaloosa, AL 36587 >>> Office 205-348-3758 | Fax 205-348-9393 deborah.crocker(a)ua.edu >>> >>> _______________________________________________ >>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To >>> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> List Guidelines: >>> https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedoraproject.org/archives/list/389-users@lists.fedorap >>> r oject.org _______________________________________________ >>> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To >>> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >>> Fedora Code of Conduct: >>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> List Guidelines: >>> https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: >>> https://lists.fedoraproject.org/archives/list/389-users@lists.fedorap >>> r >>> oject.org >> >> — >> Sincerely, >> >> William Brown >> >> Senior Software Engineer, 389 Directory Server SUSE Labs >> _______________________________________________ >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To >> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: >> https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/389-users@lists.fedorapr >> oject.org _______________________________________________ >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To >> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: >> https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/389-users@lists.fedorapr >> oject.org > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs

2 1

Re: new server setup hanging
by Crocker, Deborah 30 May '20

30 May '20

Some more information from a coworker: Yeah, this sounds like an LDAP server bug. I haven't figured out what to look at to pin it down, but when it's slow to connect, I can see with strace that the primary thread hasn't called accept() yet for the connection I'm trying to open. Once it does, the whole thing goes very quickly, and I usually see a burst of other connections accepted and handled at the same time. Deborah Crocker, PhD Systems Engineer III Office of Information Technology The University of Alabama Box 870346 Tuscaloosa, AL 36587 Office 205-348-3758 | Fax 205-348-9393 deborah.crocker(a)ua.edu -----Original Message----- From: Crocker, Deborah <crock(a)ua.edu> Sent: Saturday, May 30, 2020 2:08 PM To: General discussion list for the 389 Directory server project. <389-users(a)lists.fedoraproject.org> Subject: [EXTERNAL] [389-users] new server setup hanging We're trying to move into our new server setup. We have one that seems to be fine under a load but when we bring the next we're having trouble with it hanging. The second does have more clients (and different) so there could be something about what a client is doing. Here is the server: 389-Directory/1.3.10.1 B2020.133.1625 Installed from EPEL, running on CentOS Linux release 7.8.2003 And here is the pstack output listing the only thread that is not idle. Can anyone tell me what is going on? Thread 44 (Thread 0x7f858e9b3700 (LWP 2515)): #0 0x00007f860a90fe02 in slapi_atomic_load_32 () at /usr/lib64/dirsrv/libslapd.so.0 #1 0x00007f860a8d4e8e in slapi_get_mapping_tree_node_by_dn () at /usr/lib64/dirsrv/libslapd.so.0 #2 0x00007f860a8d5179 in slapi_be_select () at /usr/lib64/dirsrv/libslapd.so.0 #3 0x00007f860a9296a0 in vattr_test_filter () at /usr/lib64/dirsrv/libslapd.so.0 #4 0x00007f860a8b6ec4 in slapi_vattr_filter_test_ext_internal () at /usr/lib64/dirsrv/libslapd.so.0 #5 0x00007f860a8b7ba6 in slapi_vattr_filter_test_ext () at /usr/lib64/dirsrv/libslapd.so.0 #6 0x00007f8600a99e02 in acl__resource_match_aci () at /usr/lib64/dirsrv/plugins/libacl-plugin.so #7 0x00007f8600a9b280 in acl_access_allowed () at /usr/lib64/dirsrv/plugins/libacl-plugin.so #8 0x00007f8600aae9f7 in acl_access_allowed_main () at /usr/lib64/dirsrv/plugins/libacl-plugin.so #9 0x00007f860a8f0cbc in plugin_call_acl_plugin () at /usr/lib64/dirsrv/libslapd.so.0 #10 0x00007f860a8b638d in test_filter_access () at /usr/lib64/dirsrv/libslapd.so.0 #11 0x00007f860a8b6fb5 in slapi_vattr_filter_test_ext_internal () at /usr/lib64/dirsrv/libslapd.so.0 #12 0x00007f860a8b6d31 in slapi_vattr_filter_test_ext_internal () at /usr/lib64/dirsrv/libslapd.so.0 #13 0x00007f860a8b7ba6 in slapi_vattr_filter_test_ext () at /usr/lib64/dirsrv/libslapd.so.0 #14 0x00007f85ff7c0df1 in ldbm_back_next_search_entry_ext () at /usr/lib64/dirsrv/plugins/libback-ldbm.so #15 0x00007f860a8deca6 in send_results_ext.constprop.5 () at /usr/lib64/dirsrv/libslapd.so.0 #16 0x00007f860a8e0e09 in op_shared_search () at /usr/lib64/dirsrv/libslapd.so.0 #17 0x0000557410dd3c0e in do_search () #18 0x0000557410dc198a in connection_threadmain () #19 0x00007f86086a0c5b in _pt_root () at /lib64/libnspr4.so #20 0x00007f8608040ea5 in start_thread () at /lib64/libpthread.so.0 #21 0x00007f86076ec8dd in clone () at /lib64/libc.so.6 Deborah Crocker, PhD Systems Engineer III Office of Information Technology The University of Alabama Box 870346 Tuscaloosa, AL 36587 Office 205-348-3758 | Fax 205-348-9393 deborah.crocker(a)ua.edu -----Original Message----- From: William Brown <wbrown(a)suse.de> Sent: Wednesday, May 27, 2020 5:43 PM To: 389-users(a)lists.fedoraproject.org Subject: [EXTERNAL] [389-users] Re: Re: Re: Advice to bring new servers into production > On 27 May 2020, at 23:20, Crocker, Deborah <crock(a)ua.edu> wrote: > > Thanks - I think we have enough ideas in here to get this going. One last question: > If replication is set up through the host name - how often does the directory server do a DNS look up, or does it do it once on startup (or creation of the rep agreement)? I "think" it's every time it initiates the new connection - but remember, for replication, that *is* quite different to a client doing a search, so I'd be pretty careful about this. IMO you should be standing up your replacement servers in parallel, joining them all, moving the IP's then decomission the old servers. Alternately, you'll need an outage window to shutdown your old servers, export the ldif, and then import and bring up the new ones. I think having "IP's are a limited resource" really does make this whole process much much harder than it needs to be for you ... :( > > -----Original Message----- > From: William Brown <wbrown(a)suse.de> > Sent: Tuesday, May 26, 2020 10:48 PM > To: 389-users(a)lists.fedoraproject.org > Subject: [EXTERNAL] [389-users] Re: Re: Advice to bring new servers > into production > > There are a few options. The best would be a load balancer which has the ip's so that it's transparent to your LDAP servers where they are. > > But also as mentioned, the virtual IP's honestly is the best way. Linux can have multiple IP's on an interface so you can just have two IP's on one interface, andthat's the best way to do this. > > Alternately, don't rely on the IP, lower your DNS ttl's to a very short time, change the DNS A/AAAA records, and then do it that way. > > > >> On 27 May 2020, at 06:17, Crocker, Deborah <crock(a)ua.edu> wrote: >> >> I’d like not to take up two ip addresses per host indefinitely. We have re-IP’d our hosts before so I know we can to do this but it was during a downtime when everything was restarted. Just trying to get away with not restarting the masters. >> >> Deborah Crocker, PhD >> Systems Engineer III >> Office of Information Technology >> The University of Alabama >> Box 870346 >> Tuscaloosa, AL 36587 >> Office 205-348-3758 | Fax 205-348-9393 deborah.crocker(a)ua.edu >> >> From: Leo Pleiman <lpleiman(a)salsalabs.com> >> Sent: Tuesday, May 26, 2020 3:08 PM >> To: General discussion list for the 389 Directory server project. >> <389-users(a)lists.fedoraproject.org> >> Subject: [EXTERNAL] [389-users] Re: Advice to bring new servers into >> production >> >> My experience has been that the replicas and consumers have a unique id, more than just an IP address which creates the trust relationship with the master. If your goal is to simply maintain an IP so your clients don't have to be repointed, I would build each new LDAP host and replication agreement, and then as you decommission the old hosts use their IP address as a virtual IP address on the replacement host. It would take a quick restart od the LDAP service to start a listener on the virtual Ip address. >> >> >> Leo Pleiman >> Senior System Engineer >> Direct 202-787-3622 >> Cell 410-688-3873 >> >> >> >> On Tue, May 26, 2020 at 3:57 PM Crocker, Deborah <crock(a)ua.edu> wrote: >> We have a setup with 2 multi-masters and 3 consumers. We are now building new host and want to put them in place ultimately at the same IP address as the original ones. I need some advice on how to do this quickly and cleanly. >> >> To add a new consumer the idea now is to set it up and set up replications agreements from each master using consumer DNS name (don't start continuous replication yet). After initializing new consumer from one master - turn off old consumer, remove old consumer agreement from each master, and re-IP new consumer. Do we need to restart masters to re-read DNS or will it pick that up when it starts the next replication? Is this the best way to do this? >> >> Thanks >> >> Deborah Crocker, PhD >> Systems Engineer III >> Office of Information Technology >> The University of Alabama >> Box 870346 >> Tuscaloosa, AL 36587 >> Office 205-348-3758 | Fax 205-348-9393 deborah.crocker(a)ua.edu >> >> _______________________________________________ >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To >> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: >> https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/389-users@lists.fedorap >> r oject.org _______________________________________________ >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To >> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: >> https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/389-users@lists.fedorap >> r >> oject.org > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server SUSE Labs > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org To > unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedorapr > oject.org _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org To > unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedorapr > oject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject…

1 0

new server setup hanging
by Crocker, Deborah 30 May '20

30 May '20

We're trying to move into our new server setup. We have one that seems to be fine under a load but when we bring the next we're having trouble with it hanging. The second does have more clients (and different) so there could be something about what a client is doing. Here is the server: 389-Directory/1.3.10.1 B2020.133.1625 Installed from EPEL, running on CentOS Linux release 7.8.2003 And here is the pstack output listing the only thread that is not idle. Can anyone tell me what is going on? Thread 44 (Thread 0x7f858e9b3700 (LWP 2515)): #0 0x00007f860a90fe02 in slapi_atomic_load_32 () at /usr/lib64/dirsrv/libslapd.so.0 #1 0x00007f860a8d4e8e in slapi_get_mapping_tree_node_by_dn () at /usr/lib64/dirsrv/libslapd.so.0 #2 0x00007f860a8d5179 in slapi_be_select () at /usr/lib64/dirsrv/libslapd.so.0 #3 0x00007f860a9296a0 in vattr_test_filter () at /usr/lib64/dirsrv/libslapd.so.0 #4 0x00007f860a8b6ec4 in slapi_vattr_filter_test_ext_internal () at /usr/lib64/dirsrv/libslapd.so.0 #5 0x00007f860a8b7ba6 in slapi_vattr_filter_test_ext () at /usr/lib64/dirsrv/libslapd.so.0 #6 0x00007f8600a99e02 in acl__resource_match_aci () at /usr/lib64/dirsrv/plugins/libacl-plugin.so #7 0x00007f8600a9b280 in acl_access_allowed () at /usr/lib64/dirsrv/plugins/libacl-plugin.so #8 0x00007f8600aae9f7 in acl_access_allowed_main () at /usr/lib64/dirsrv/plugins/libacl-plugin.so #9 0x00007f860a8f0cbc in plugin_call_acl_plugin () at /usr/lib64/dirsrv/libslapd.so.0 #10 0x00007f860a8b638d in test_filter_access () at /usr/lib64/dirsrv/libslapd.so.0 #11 0x00007f860a8b6fb5 in slapi_vattr_filter_test_ext_internal () at /usr/lib64/dirsrv/libslapd.so.0 #12 0x00007f860a8b6d31 in slapi_vattr_filter_test_ext_internal () at /usr/lib64/dirsrv/libslapd.so.0 #13 0x00007f860a8b7ba6 in slapi_vattr_filter_test_ext () at /usr/lib64/dirsrv/libslapd.so.0 #14 0x00007f85ff7c0df1 in ldbm_back_next_search_entry_ext () at /usr/lib64/dirsrv/plugins/libback-ldbm.so #15 0x00007f860a8deca6 in send_results_ext.constprop.5 () at /usr/lib64/dirsrv/libslapd.so.0 #16 0x00007f860a8e0e09 in op_shared_search () at /usr/lib64/dirsrv/libslapd.so.0 #17 0x0000557410dd3c0e in do_search () #18 0x0000557410dc198a in connection_threadmain () #19 0x00007f86086a0c5b in _pt_root () at /lib64/libnspr4.so #20 0x00007f8608040ea5 in start_thread () at /lib64/libpthread.so.0 #21 0x00007f86076ec8dd in clone () at /lib64/libc.so.6 Deborah Crocker, PhD Systems Engineer III Office of Information Technology The University of Alabama Box 870346 Tuscaloosa, AL 36587 Office 205-348-3758 | Fax 205-348-9393 deborah.crocker(a)ua.edu -----Original Message----- From: William Brown <wbrown(a)suse.de> Sent: Wednesday, May 27, 2020 5:43 PM To: 389-users(a)lists.fedoraproject.org Subject: [EXTERNAL] [389-users] Re: Re: Re: Advice to bring new servers into production > On 27 May 2020, at 23:20, Crocker, Deborah <crock(a)ua.edu> wrote: > > Thanks - I think we have enough ideas in here to get this going. One last question: > If replication is set up through the host name - how often does the directory server do a DNS look up, or does it do it once on startup (or creation of the rep agreement)? I "think" it's every time it initiates the new connection - but remember, for replication, that *is* quite different to a client doing a search, so I'd be pretty careful about this. IMO you should be standing up your replacement servers in parallel, joining them all, moving the IP's then decomission the old servers. Alternately, you'll need an outage window to shutdown your old servers, export the ldif, and then import and bring up the new ones. I think having "IP's are a limited resource" really does make this whole process much much harder than it needs to be for you ... :( > > -----Original Message----- > From: William Brown <wbrown(a)suse.de> > Sent: Tuesday, May 26, 2020 10:48 PM > To: 389-users(a)lists.fedoraproject.org > Subject: [EXTERNAL] [389-users] Re: Re: Advice to bring new servers > into production > > There are a few options. The best would be a load balancer which has the ip's so that it's transparent to your LDAP servers where they are. > > But also as mentioned, the virtual IP's honestly is the best way. Linux can have multiple IP's on an interface so you can just have two IP's on one interface, andthat's the best way to do this. > > Alternately, don't rely on the IP, lower your DNS ttl's to a very short time, change the DNS A/AAAA records, and then do it that way. > > > >> On 27 May 2020, at 06:17, Crocker, Deborah <crock(a)ua.edu> wrote: >> >> I’d like not to take up two ip addresses per host indefinitely. We have re-IP’d our hosts before so I know we can to do this but it was during a downtime when everything was restarted. Just trying to get away with not restarting the masters. >> >> Deborah Crocker, PhD >> Systems Engineer III >> Office of Information Technology >> The University of Alabama >> Box 870346 >> Tuscaloosa, AL 36587 >> Office 205-348-3758 | Fax 205-348-9393 deborah.crocker(a)ua.edu >> >> From: Leo Pleiman <lpleiman(a)salsalabs.com> >> Sent: Tuesday, May 26, 2020 3:08 PM >> To: General discussion list for the 389 Directory server project. >> <389-users(a)lists.fedoraproject.org> >> Subject: [EXTERNAL] [389-users] Re: Advice to bring new servers into >> production >> >> My experience has been that the replicas and consumers have a unique id, more than just an IP address which creates the trust relationship with the master. If your goal is to simply maintain an IP so your clients don't have to be repointed, I would build each new LDAP host and replication agreement, and then as you decommission the old hosts use their IP address as a virtual IP address on the replacement host. It would take a quick restart od the LDAP service to start a listener on the virtual Ip address. >> >> >> Leo Pleiman >> Senior System Engineer >> Direct 202-787-3622 >> Cell 410-688-3873 >> >> >> >> On Tue, May 26, 2020 at 3:57 PM Crocker, Deborah <crock(a)ua.edu> wrote: >> We have a setup with 2 multi-masters and 3 consumers. We are now building new host and want to put them in place ultimately at the same IP address as the original ones. I need some advice on how to do this quickly and cleanly. >> >> To add a new consumer the idea now is to set it up and set up replications agreements from each master using consumer DNS name (don't start continuous replication yet). After initializing new consumer from one master - turn off old consumer, remove old consumer agreement from each master, and re-IP new consumer. Do we need to restart masters to re-read DNS or will it pick that up when it starts the next replication? Is this the best way to do this? >> >> Thanks >> >> Deborah Crocker, PhD >> Systems Engineer III >> Office of Information Technology >> The University of Alabama >> Box 870346 >> Tuscaloosa, AL 36587 >> Office 205-348-3758 | Fax 205-348-9393 deborah.crocker(a)ua.edu >> >> _______________________________________________ >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To >> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: >> https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/389-users@lists.fedorap >> r oject.org _______________________________________________ >> 389-users mailing list -- 389-users(a)lists.fedoraproject.org To >> unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: >> https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/389-users@lists.fedorap >> r >> oject.org > > — > Sincerely, > > William Brown > > Senior Software Engineer, 389 Directory Server SUSE Labs > _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org To > unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedorapr > oject.org _______________________________________________ > 389-users mailing list -- 389-users(a)lists.fedoraproject.org To > unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-users@lists.fedorapr > oject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject…

1 0

Announcing 389 Directory Server 1.4.2.14
by Mark Reynolds 30 May '20

30 May '20

389 Directory Server 1.4.2.14 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.2.14 Fedora packages are available on Fedora 31. https://koji.fedoraproject.org/koji/taskinfo?taskID=45153610 <https://koji.fedoraproject.org/koji/taskinfo?taskID=45153610> Bodhi https://bodhi.fedoraproject.org/updates/FEDORA-2020-0a057b856f <https://bodhi.fedoraproject.org/updates/FEDORA-2020-0a057b856f> The new packages and versions are: * 389-ds-base-1.4.2.14-1 Source tarballs are available for download at Download 389-ds-base Source <https://releases.pagure.org/389-ds-base/389-ds-base-1.4.2.14.tar.bz2> Highlights in 1.4.2.14 * Bug fixes, and UI completion Installation and Upgrade See Download <https://www.port389.org/docs/389ds/download.html> for information about setting up your yum repositories. To install the server use *dnf install 389-ds-base* To install the Cockpit UI plugin use *dnf install cockpit-389-ds* After rpm install completes, run *dscreate interactive* For upgrades, simply install the package. There are no further steps required. There are no upgrade steps besides installing the new rpms See Install_Guide <https://www.port389.org/docs/389ds/howto/howto-install-389.html> for more information about the initial installation and setup See Source <https://www.port389.org/docs/389ds/development/source.html> for information about source tarballs and SCM (git) access. New UI Progress (Cockpit plugin) The new UI is complete and QE tested. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list: https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.o… If you find a bug, or would like to see a new feature, file it in our Pagure project: https://pagure.io/389-ds-base * Bump version to 1.4.2.14 * Issue 51113 - Allow using uid for replication manager entry * Issue 51095 - abort operation if CSN can not be generated * Issue 51110 - Fix ASAN ODR warnings * Issue 51102 - RFE - ds-replcheck - make online timeout configurable * Issue 51076 - remove unnecessary slapi entry dups * Issue 51086 - Improve dscreate instance name validation * Issue 50989 - ignore pid when it is ourself in protect_db * Issue 50499 - Fix some npm audit issues * Issue 51091 - healthcheck json report fails when mapping tree is deleted * Issue 51079 - container pid start and stop issues * Issue 50610 - Fix return code when it’s nothing to free * Issue 51082 - abort when a empty valueset is freed * Issue 50610 - memory leaks in dbscan and changelog encryption * Issue 51076 - prevent unnecessarily duplication of the target entry * Issue 50940 - Permissions of some shipped directories may change over time -- 389 Directory Server Development Team

1 0

Announcing 389 Directory Server 1.4.3.9
by Mark Reynolds 30 May '20

30 May '20

389 Directory Server 1.4.3.9 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.3.9 Fedora packages are available on Fedora 32. https://koji.fedoraproject.org/koji/taskinfo?taskID=45153038 <https://koji.fedoraproject.org/koji/taskinfo?taskID=45153038> - Fedora 32 https://bodhi.fedoraproject.org/updates/FEDORA-2020-8b77120ba3 <https://bodhi.fedoraproject.org/updates/FEDORA-2020-8b77120ba3> - Bodhi The new packages and versions are: * 389-ds-base-1.4.3.9-1 Source tarballs are available for download at Download 389-ds-base Source <https://releases.pagure.org/389-ds-base/389-ds-base-1.4.3.9.tar.bz2> Highlights in 1.4.3.9 * Bug fixes, and UI completion Installation and Upgrade See Download <https://www.port389.org/docs/389ds/download.html> for information about setting up your yum repositories. To install the server use *dnf install 389-ds-base* To install the Cockpit UI plugin use *dnf install cockpit-389-ds* After rpm install completes, run *dscreate interactive* For upgrades, simply install the package. There are no further steps required. There are no upgrade steps besides installing the new rpms See Install_Guide <https://www.port389.org/docs/389ds/howto/howto-install-389.html> for more information about the initial installation and setup See Source <https://www.port389.org/docs/389ds/development/source.html> for information about source tarballs and SCM (git) access. New UI Progress (Cockpit plugin) The new UI is complete and QE tested. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list: https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.o… If you find a bug, or would like to see a new feature, file it in our Pagure project: https://pagure.io/389-ds-base * Bump version to 1.4.3.9 * Issue 50931 - RFE AD filter rewriter for ObjectCategory * Issue 51113 - Allow using uid for replication manager entry * Issue 51095 - abort operation if CSN can not be generated * Issue 51110 - Fix ASAN ODR warnings * Issue 51102 - RFE - ds-replcheck - make online timeout configurable * Issue 51076 - remove unnecessary slapi entry dups * Issue 51086 - Improve dscreate instance name validation * Issue 50989 - ignore pid when it is ourself in protect_db * Issue 50499 - Fix some npm audit issues * Issue 51091 - healthcheck json report fails when mapping tree is deleted * Issue 51079 - container pid start and stop issues * Issue 50610 - Fix return code when it’s nothing to free * Issue 51082 - abort when a empty valueset is freed * Issue 50610 - memory leaks in dbscan and changelog encryption * Issue 51076 - prevent unnecessarily duplication of the target entry -- 389 Directory Server Development Team

1 0

Announcing 389 Directory Server 1.4.4.3
by Mark Reynolds 30 May '20

30 May '20

389 Directory Server 1.4.4.3 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.4.3 Fedora packages are available on Rawhide (Fedora 33). https://koji.fedoraproject.org/koji/taskinfo?taskID=45152302 <https://koji.fedoraproject.org/koji/taskinfo?taskID=45152302> The new packages and versions are: * 389-ds-base-1.4.4.3-1 Source tarballs are available for download at Download 389-ds-base Source <https://releases.pagure.org/389-ds-base/389-ds-base-1.4.4.3.tar.bz2> Highlights in 1.4.4.3 * Bug fixes Installation and Upgrade See Download <https://www.port389.org/docs/389ds/download.html> for information about setting up your yum repositories. To install the server use *dnf install 389-ds-base* To install the Cockpit UI plugin use *dnf install cockpit-389-ds* After rpm install completes, run *dscreate interactive* For upgrades, simply install the package. There are no further steps required. There are no upgrade steps besides installing the new rpms See Install_Guide <https://www.port389.org/docs/389ds/howto/howto-install-389.html> for more information about the initial installation and setup See Source <https://www.port389.org/docs/389ds/development/source.html> for information about source tarballs and SCM (git) access. Feedback We are very interested in your feedback! Please provide feedback and comments to the 389-users mailing list: https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject.o… If you find a bug, or would like to see a new feature, file it in our Pagure project: https://pagure.io/389-ds-base * Bump version to 1.4.4.3 * Issue 50931 - RFE AD filter rewriter for ObjectCategory * Issue 50860 - Port Password Policy test cases from TET to python3 part1 * Issue 51113 - Allow using uid for replication manager entry * Issue 51095 - abort operation if CSN can not be generated * Issue 51110 - Fix ASAN ODR warnings * Issue 49850 - ldbm_get_nonleaf_ids() painfully slow for databases with many non-leaf entries * Issue 51102 - RFE - ds-replcheck - make online timeout configurable * Issue 51076 - remove unnecessary slapi entry dups * Issue 51086 - Improve dscreate instance name validation * Issue:51070 - Port Import TET module to python3 part1 * Issue 51037 - compiler warning * Issue 50989 - ignore pid when it is ourself in protect_db * Issue 51037 - RFE AD filter rewriter for ObjectSID * Issue 50499 - Fix some npm audit issues * Issue 51091 - healthcheck json report fails when mapping tree is deleted * Issue 51079 - container pid start and stop issues * Issue 49761 - Fix CI tests * Issue 50610 - Fix return code when it’s nothing to free * Issue 50610 - memory leaks in dbscan and changelog encryption * Issue 51076 - prevent unnecessarily duplication of the target entry * Issue 50940 - Permissions of some shipped directories may change over time * Issue 50873 - Fix issues with healthcheck tool * Issue 51082 - abort when a empty valueset is freed * Issue 50201 - nsIndexIDListScanLimit accepts any value -- 389 Directory Server Development Team

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users May 2020