389-users May 2020

389-users@lists.fedoraproject.org

10 participants
30 discussions

Re: [EXTERNAL] Re: Re: Advice to bring new servers into production
by William Brown 27 May '20

27 May '20

> 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.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… — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs

1 0

Re: [EXTERNAL] Re: Advice to bring new servers into production
by William Brown 27 May '20

27 May '20

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.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: Advice to bring new servers into production
by Leo Pleiman 26 May '20

26 May '20

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.fedoraproject… >

2 1

Advice to bring new servers into production
by Crocker, Deborah 26 May '20

26 May '20

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

1 0

Change TLS protocol
by Alberto Viana 21 May '20

21 May '20

Hi Guys, My packages: 389-ds-base1.4.2.8-20200414gitfae920fc8.el8.x86_64 openssl-1.1.1c-2.el8.x86_64 I'm trying to set tls-protocol-min to TLS 1.0 but it's not working, I used dsconf and ldapmodify like this: dn: cn=encryption,cn=config changetype: modify replace: sslVersionMin sslVersionMin: TLS1.1 - replace: sslVersionMax sslVersionMax: TLS1.2 Also tried to set on variables like this: nsTLS11: on nsTLS10: on dsconf RNP security set --tls-protocol-min="TLS1.0" Set Allow Weak Ciphers to on, but seems to be related to ssl3 and not TLS. Change cipher suite to all All commands seems to works, also modify my dse.ldif but When I start my 389: [28/Apr/2020:23:10:58.855549735 -0300] - INFO - Security Initialization - slapd_ssl_init2 - Configured SSL version range: min: TLS1.1, max: TLS1.2 [28/Apr/2020:23:10:58.858132149 -0300] - INFO - Security Initialization - slapd_ssl_init2 - NSS adjusted SSL version range: min: TLS1.2, max: TLS1.2 This last try was setting to --tls-protocol-min="TLS1.1" Thanks Alberto Viana

3 3

intro to 389 LDAP administration
by Matt Zagrabelny 14 May '20

14 May '20

Greetings 389 users, I am a sysadmin that has never really used LDAP before. I have installed 389-ds and am a little stuck as to how to start. I am using Debian Buster... 389-ds: Installed: 1.4.0.21-1 From the site: https://www.port389.org/docs/389ds/howto/howto-install-389.html I see it recommends setting a .dsrc file to ease usage as the root user: For local instance administration (on the server), you want to use settings like: # cat ~/.dsrc [localhost] # Note that '/' is replaced to '%%2f'. uri = ldapi://%%2fvar%%2frun%%2fslapd-localhost.socket basedn = dc=example,dc=com binddn = cn=Directory Manager I don't have the socket file in my installation. I don't see any sockets owned by the directory service: # systemctl status dirsrv(a)gopher.service ● dirsrv(a)gopher.service - 389 Directory Server gopher. Loaded: loaded (/lib/systemd/system/dirsrv@.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2020-05-13 12:38:22 CDT; 2h 5min ago Main PID: 12270 (ns-slapd) Status: "slapd started: Ready to process requests" Tasks: 25 (limit: 4722) Memory: 19.2M CGroup: /system.slice/system-dirsrv.slice/dirsrv(a)gopher.service └─12270 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-gopher -i /var/run/dirsrv/slapd-gopher.pid # tree /var/run/dirsrv /var/run/dirsrv ├── slapd-gopher.pid └── slapd-gopher.stats The Debian package states to initialize the server to run the command: /usr/sbin/setup-ds I don't know if that is a distribution agnostic program or not. The command did prompt me for a password - which I entered. When I run a command like dsidm or ldapmodify, the command prompts me for a password. I enter the one that was prompted for with setup-ds, but I get: SASL/SCRAM-SHA-1 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Invalid credentials (49) I guess I have two questions. 1. Should there be a socket somewhere owned by slapd for local communication? 2. What password should I enter for ldap<command> and dsidm? Thanks for any pointer, advice, or help! -m

2 3

2FA authentication enable on FREEIPA
by Dhinakaran M 13 May '20

13 May '20

As per below scenario trying to enable 2FA but no luck , please let me know if any one faced this kind of issue and how it was resolved I'm trying to enable 2FA authentication only in 2 hosts out-of 5 hosts test case 1 ) I have enabled 2FA in global configuration of FREEIPA but is working on all 5hosts test case 2) Disabled 2FA in Global configuration of freeipa and enabled OTP indicator only 2 hosts but OTP mechanism doesn't working https://www.freeipa.org/page/V4/Authentication_Indicators

2 1

replication problems
by Alberto Viana 12 May '20

12 May '20

Hey Guys, 389-Directory/1.4.2.8 389 (master) <=> 389 (master) In a master to master replication, start to see this error : [31/Mar/2020:17:30:52.610637150 +0000] - WARN - NSMMReplicationPlugin - replica_check_for_data_reload - Disorderly shutdown for replica dc=rnp,dc=local. Check if DB RUV needs to be updated Even after restart the service the problem persists, I have to disable and re-enable replication (and replication agr) on both sides, it works for some time, and the problem comes back. Any tips? Thanks Alberto Viana

4 24

Announcing 389 Directory Server 1.4.1.19
by Mark Reynolds 08 May '20

08 May '20

389 Directory Server 1.4.1.19 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.1.19 Fedora packages are available on Fedora 30. https://koji.fedoraproject.org/koji/taskinfo?taskID=44237705 <https://koji.fedoraproject.org/koji/taskinfo?taskID=44237705> Bodhi https://bodhi.fedoraproject.org/updates/FEDORA-2020-1e86bff22f <https://bodhi.fedoraproject.org/updates/FEDORA-2020-1e86bff22f> The new packages and versions are: * 389-ds-base-1.4.1.19-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.1.19.tar.bz2> Highlights in 1.4.1.19 * Bug fixes, and UI completion Installation and Upgrade See Download <http://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 <http://www.port389.org/docs/389ds/howto/howto-install-389.html> for more information about the initial installation and setup See Source <http://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.1.19 * Issue 50787 - fix implementation of attr unique * Issue 51078 - Add nsslapd-enable-upgrade-hash to the schema * Issue 51068 - deadlock when updating the schema * Issue 51060 - unable to set sslVersionMin to TLS1.0 * Issue 51064 - Unable to install server where IPv6 is disabled * Issue 51051 - CLI fix consistency issues with confirmations * Issue 51047 - React deprecating ComponentWillMount * Issue 50499 - fix npm audit issues * Issue 51035 - Heavy StartTLS connection load can randomly fail with err=1 * Issue 51031 - UI - transition between two instances needs improvement -- 389 Directory Server Development Team

1 0

Announcing 389 Directory Server 1.4.2.13
by Mark Reynolds 08 May '20

08 May '20

389 Directory Server 1.4.2.13 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.2.13 Fedora packages are available on Fedora 31. https://koji.fedoraproject.org/koji/taskinfo?taskID=44236196 <https://koji.fedoraproject.org/koji/taskinfo?taskID=44236196> Bodhi https://bodhi.fedoraproject.org/updates/FEDORA-2020-43914ebb85 <https://bodhi.fedoraproject.org/updates/FEDORA-2020-43914ebb85> The new packages and versions are: * 389-ds-base-1.4.2.13-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.13.tar.bz2> Highlights in 1.4.2.13 * Bug fixes, and UI completion Installation and Upgrade See Download <http://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 <http://www.port389.org/docs/389ds/howto/howto-install-389.html> for more information about the initial installation and setup See Source <http://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.13 * Issue 50787 - fix implementation of attr unique * Issue 51078 - Add nsslapd-enable-upgrade-hash to the schema * Issue 51068 - deadlock when updating the schema * Issue 51060 - unable to set sslVersionMin to TLS1.0 * Issue 51064 - Unable to install server where IPv6 is disabled * Issue 51051 - CLI fix consistency issues with confirmations * Issue 51047 - React deprecating ComponentWillMount * Issue 50499 - fix npm audit issues * Issue 51035 - Heavy StartTLS connection load can randomly fail with err=1 * Issue 51031 - UI - transition between two instances needs improvement -- 389 Directory Server Development Team

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users May 2020