389-users October 2020

389-users@lists.fedoraproject.org

12 participants
19 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

Plugin development licensing
by DUVERT Vincent 09 May '23

09 May '23

Hello, I have a question regarding the licensing of developed 389-ds plugins. The FAQ (https://directory.fedoraproject.org/docs/389ds/FAQ/licensing.html#directory…) indicates that the Directory Server core code is licensed under a GPL + Exception license that allows non-GPL 389-ds plugins to link to 389-ds and to use specific header files. However, the LICENSE file in the current 389-ds-base source does not contain this exception. It was apparently removed by the following commit, when the license was changed to GPLv3+: https://pagure.io/389-ds-base/c/88cae401aee39a19ac6b07c3c36ee8daa07192e7 Does that means that the license exception does not apply to the current version of 389-ds? Regards, Vincent Duvert

2 2

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

Announcing 389 Directory Server 1.4.4.6
by Mark Reynolds 26 Oct '20

26 Oct '20

389 Directory Server 1.4.4.6 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.4.6 Fedora packages are available on Fedora 33 and Rawhide (Fedora 34). Fedora 33: https://koji.fedoraproject.org/koji/taskinfo?taskID=54270607 <https://koji.fedoraproject.org/koji/taskinfo?taskID=54270607> - Koji https://bodhi.fedoraproject.org/updates/FEDORA-2020-a998e68006 <https://bodhi.fedoraproject.org/updates/FEDORA-2020-a998e68006> - Bohdi Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=46829414 <https://koji.fedoraproject.org/koji/taskinfo?taskID=46829414> The new packages and versions are: * 389-ds-base-1.4.4.6-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.6.tar.bz2> Highlights in 1.4.4.6 * 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 GitHub project: https://github.com/389ds/389-ds-base * Bump version to 1.4.4.6 * Issue 4262 - Remove legacy tools subpackage (final cleanup) * Issue 4262 - Remove legacy tools subpackage (restart instances after rpm install) * Issue 4262 - Remove legacy tools subpackage * Issue 2526 - revert API change in slapi_be_getsuffix() * Issue 4363 - Sync repl: per thread structure was incorrectly initialized (#4395) * Issue 4392 - Update create_test.py * Issue 2820 - Fix CI tests (#4365) * Issue 2526 - suffix management in backends incorrect * Issue 4389 - errors log with incorrectly formatted message parent_update_on_childchange * Issue 4295 - Fix a closing quote issue (#4386) * Issue 1199 - Misleading message in access log for idle timeout (#4385) * Issue 3600 - RFE - openldap migration tooling (#4318) * Issue 4176 - import ldif2cl task should not close all changelogs * Issue 4159 - Healthcheck code DSBLE0002 not returned on disabled suffix * Issue 4379 - allow more than 1 empty AttributeDescription for ldapsearch, without the risk of denial of service (#4380) * Issue 4329 - Sync repl - if a serie of updates target the same entry then the cookie get wrong changenumber (#4356) * Issue 3555 - Fix npm audit issues (#4370) * Issue 4372 - BUG - Chaining DB did not validate bind mech parameters (#4374) * Issue 4334 - RFE - Task timeout may cause larger dataset imports to fail (#4359) * Issue 4361 - RFE - add - dscreate –advanced flag to avoid user confusion * Issue 4368 - ds-replcheck crashes when processing glue entries * Issue 4366 - lib389 - Fix account status inactivity checks * Issue 4265 - UI - Make the secondary plugins read-only (#4364) * Issue 4360 - password policy max sequence sets is not working as expected * Issue 4348 - Add tests for dsidm * Issue 4350 - One line, fix invalid type error in tls_cacertdir check (#4358) -- 389 Directory Server Development Team

1 0

Announcing 389 Directory Server 1.4.3.14
by Mark Reynolds 26 Oct '20

26 Oct '20

389 Directory Server 1.4.3.14 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.3.14 Fedora packages are available on Fedora 32. https://koji.fedoraproject.org/koji/taskinfo?taskID=54261773 <https://koji.fedoraproject.org/koji/taskinfo?taskID=54261773> - Fedora 32 https://bodhi.fedoraproject.org/updates/FEDORA-2020-9dddffb6a2 <https://bodhi.fedoraproject.org/updates/FEDORA-2020-9dddffb6a2> - Bodhi The new packages and versions are: * 389-ds-base-1.4.3.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.3.14.tar.bz2> Highlights in 1.4.3.14 * 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. 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 GitHub project: https://github.com/389ds/389-ds-base * Bump version to 1.4.3.14 * Issue 2526 - revert API change in slapi_be_getsuffix() * Issue 4372 - BUG - Chaining DB did not validate bind mech parameters (#4374) * Issue 4334 - RFE - Task timeout may cause larger dataset imports to fail (#4359) * Issue 4363 - Sync repl: per thread structure was incorrectly initialized (#4395) * Issue 2526 - suffix management in backends incorrect * Issue 1199 - Misleading message in access log for idle timeout (#4385) * Issue 4295 - Fix a closing quote issue (#4386) * Issue 4389 - errors log with incorrectly formatted message parent_update_on_childchange * Issue 4297 - On ADD replication URP issue internal searches with filter containing unescaped chars (#4355) * Issue 4379 - allow more than 1 empty AttributeDescription for ldapsearch, without the risk of denial of service (#4380) * Issue 4159 - Healthcheck code DSBLE0002 not returned on disabled suffix * Issue 4265 - UI - Make the secondary plugins read-only (#4364) * Issue 4361 - RFE - add - dscreate –advanced flag to avoid user confusion * Issue 4368 - ds-replcheck crashes when processing glue entries * Issue 4366 - lib389 - Fix account status inactivity checks * Issue 4360 - password policy max sequence sets is not working as expected -- 389 Directory Server Development Team

1 0

Max number of users in a group?
by murmansk＠hotmail.com 23 Oct '20

23 Oct '20

We have a two machine 389DS multimaster cluster holding about 850.000 users. It's been working great for over three years now. But we are creating some big groups, that will have about 150.000 users in them. I've read in the list some posts about groups larger than that. But I would like to know if there is any limit or precaution when working with groups this size?

3 2

Limits for Multi Master Replication?
by Eugen Lamers 22 Oct '20

22 Oct '20

Hi, We use the 389 Directory Server version 1.4.2.15. In the documentation of the Red Hat Directory Server it says, as many as 20 masters are supported in an MMR. It sounds to be a hardcoded limitation defined to avoid overloaded servers and network. Shouldn't it be depending on the MMR topology, i.e. rather on the total number of replication agreements within the whole scenario? Or does "20 masters" indeed mean that the limitation of the MMR topology is the number of 380 replication agreements as shown in the "fully connected mesh" scenario (https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/h…) with 20 masters and 20x19 replication agreements? Is there someone who possibly has experience with scenarios of more than 20 master servers? Thanks, Eugen

4 4

Fwd: 389-AD on CentOS 8
by Mark Reynolds 21 Oct '20

21 Oct '20

Forwarding to the correct list... First it is NOT 389 Actrive Directory Server. Active Directory is Microsoft's LDAP server... Going back to your question, there is no 389-admin package on CentOS 8 anymore. There is a new Web UI that is a Cockpit plugin (cockpit-389-ds). For more info see the admin guide: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/11/ Regards, Mark -------- Forwarded Message -------- Subject: 389-AD on CentOS 8 Date: Wed, 21 Oct 2020 10:03:09 +0100 From: Frank Allotey <noblyfrank(a)gmail.com> To: 389-users-owner(a)lists.fedoraproject.org Hello team, I wanted to get hands-on experience with the 389 active directory but then after doing the installation on a server I seem not to find my way around for an admin console. After further research on how to get the admin console failed I decided to revert to CentOS 7 but some of the repositories are not available for download. Kindly assist with the necessary support to achieve this. -- Kind Regards, Allotey Frank Kpakpo +233241293585 +233501373619 /DISCLAIMER: / /The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future./

1 0

Re: 389-users Digest, Vol 185, Issue 12
by Ghiurea, Isabella 15 Oct '20

15 Oct '20

Thank you ! yes there were groups associate to that users,removing them solved the issues -----Original Message----- From: 389-users-request(a)lists.fedoraproject.org [mailto:389-users-request@lists.fedoraproject.org] Sent: Wednesday, October 14, 2020 9:02 PM To: 389-users(a)lists.fedoraproject.org Subject: 389-users Digest, Vol 185, Issue 12 Send 389-users mailing list submissions to 389-users(a)lists.fedoraproject.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to 389-users-request(a)lists.fedoraproject.org You can reach the person managing the list at 389-users-owner(a)lists.fedoraproject.org When replying, please edit your Subject line so it is more specific than "Re: Contents of 389-users digest..." Today's Topics: 1. Re: ldapdelete error (Mark Reynolds) ---------------------------------------------------------------------- Date: Wed, 14 Oct 2020 08:03:00 -0400 From: Mark Reynolds <mreynolds(a)redhat.com> Subject: [389-users] Re: ldapdelete error To: "General discussion list for the 389 Directory server project." <389-users(a)lists.fedoraproject.org>, William Brown <wbrown(a)suse.de> Message-ID: <9fdfe761-9cb3-e0c5-72d1-2ead5a282141(a)redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed ldapdelete has a "-r" option to recursiviely delete. So that would solve your problem, but you better make sure you know what is under that user entry before blindly removing it and its child entries :-) On 10/13/20 10:23 PM, William Brown wrote: > Generally this means there is content still under the ou=Users. You can't do a subtree delete in LDAP, so that's probably the error here. Can you check what's under the OU? > >> On 14 Oct 2020, at 10:32, Ghiurea, Isabella <Isabella.Ghiurea(a)nrc-cnrc.gc.ca> wrote: >> >> Hi List >> I’m looking for a solution for the following ldapdelete error in a multimaster replication cfg with memberof pluging enabled locally on each server and excluded from replication agreement : >> ldapdelete -D "cn=directory manager" -W -x "ou=Users,ou=ds,dcxxxxx " "(uid=9995)" >> Enter LDAP Password: >> ldap_delete: Operation not allowed on non-leaf (66) >> >> My DS version is : 389-ds-base-1.3.7.5-24.el7_5.x86_64 >> >> Running a basic search for this error seems this was a known bug in older version 7 years ago which I assume is been fixed. >> Thank you >> Isabella >> _______________________________________________ >> 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, Australia > _______________________________________________ > 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 Directory Server Development Team ------------------------------ Subject: Digest Footer _______________________________________________ 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… ------------------------------ End of 389-users Digest, Vol 185, Issue 12 ******************************************

1 0

ldapdelete error
by Ghiurea, Isabella 14 Oct '20

14 Oct '20

Hi List I'm looking for a solution for the following ldapdelete error in a multimaster replication cfg with memberof pluging enabled locally on each server and excluded from replication agreement : ldapdelete -D "cn=directory manager" -W -x "ou=Users,ou=ds,dcxxxxx " "(uid=9995)" Enter LDAP Password: ldap_delete: Operation not allowed on non-leaf (66) My DS version is : 389-ds-base-1.3.7.5-24.el7_5.x86_64 Running a basic search for this error seems this was a known bug in older version 7 years ago which I assume is been fixed. Thank you Isabella

3 2

Password policy applicable to bind?
by Grant Byers 11 Oct '20

11 Oct '20

Hi, I'm looking at applying local password policy to our existing users. Reading the Red Hat Directory Server Deployment Guide, I see the paragraphs below[1]. If I'm reading this correctly, it would appear that users will no longer be able to bind to the directory server after application of the policy if their existing password doesn't meet the policy we apply. Is this true? If so, is there a way to prevent this, and only apply the policy on password modify operations? Thanks. Grant [1] "When a user attempts to bind to the directory, Directory Server determines whether a local policy has been defined and enabled for the user's entry. To determine whether the fine-grained password policy is enabled, the server checks the value (on or off) assigned to the nsslapd- pwpolicy-local attribute of the cn=config entry. If the value is off, the server ignores the policies defined at the subtree and user levels and enforces the global password policy. To determine whether a local policy is defined for a subtree or user, the server checks for the pwdPolicysubentry attribute in the corresponding user entry. If the attribute is present, the server enforces the local password policy configured for the user. If the attribute is absent, the server logs an error message and enforces the global password policy. The server then compares the user-supplied password with the value specified in the user's directory entry to make sure they match. The server also uses the rules defined by the password policy to ensure that the password is valid before allowing the user to bind to the directory. "

1 0

OS err 12 - Cannot allocate memory
by Jan Kowalsky 09 Oct '20

09 Oct '20

Hi all, suddenly one of our ldap-servers crashed and don't restart. When restarting dirsrv we find in logs: libdb: BDB2034 unable to allocate memory for mutex; resize mutex region mmap in opening database environment failed trying to allocate 500000 bytes. (OS err 12 - Cannot allocate memory) Same error, if we run dbverify. We are running version 3.5.17 of 389-ds on debian stretch: 389-ds 1.3.5.17-2 Ram doesn't seem to be the problem. Only 200 MB of 4GB is used. The server is part of a replicated cluster. Other servers (running same software version - more or less on the same virtualisation hardware) are not affected. But we got similar errors also some times in the past. But restarting the service was always possible. Any ideas? Thanks and kind regards Jan

4 6

Re: Table of duration and acceptable distance between two synchronized directories.
by William Brown 08 Oct '20

08 Oct '20

Glad to have helped. If you have more specific questions or details, we are happy to help at any time. Thanks! > On 8 Oct 2020, at 17:29, Vincent Lemière <vincent(a)lemiere.org> wrote: > > Hi, > Thanks for your reply, > I agree with you. > Duration and quality of links are more qualified. > The TTL value is more qualified to grant transaction. > I needed to know if some other solution could be envisaged. > Your answer confirms my view. > Thanks a lot > > -----Message d'origine----- > De : William Brown <wbrown(a)suse.de> > Envoyé : mercredi 7 octobre 2020 00:29 > À : vincent(a)lemiere.org; 389-users(a)lists.fedoraproject.org > Objet : Re: [389-users] Table of duration and acceptable distance between two synchronized directories. > > Hi there, > > (removing 389-devel list from reply, this is probably better on the 389-users list :) ) > > We don't have tables per-say. We don't have these because there are many factors involved that you need to consider when designing this kind of topology. > > For example, what rate of changes do you expect to be incoming? How much latency and bandwidth exists between the replicas? How many replicas do you want to deploy? How much latency are you willing to tolerate between the nodes becoming consistent? > > We are aware of a number of deployments that have high rates of change (thousands of writes per second) that are replicating between continents (ie US/EU). However they also have high bandwidth/low latency links between these locations to assist this. > > So I think there are more questions to answer here about your potential deployment and your specific concerns you have. > > Thanks, > >> On 7 Oct 2020, at 07:24, 389ds(a)lemiere.org wrote: >> >> Hello, >> do you have tables estimating the reasonable distance to synchronize two 389 directories between two sites. Are there tables of recommendations depending on the distance? >> What software tools or scripts allow evaluating it. >> >> Cordially, >> Vincent Lemiere >> >> _______________________________________________ >> 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, Australia > > — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia

1 0

Table of duration and acceptable distance between two synchronized directories.
by 389ds＠lemiere.org 06 Oct '20

06 Oct '20

Hello, do you have tables estimating the reasonable distance to synchronize two 389 directories between two sites. Are there tables of recommendations depending on the distance? What software tools or scripts allow evaluating it. Cordially, Vincent Lemiere

2 1

Getting started
by Hendrik Steiner 06 Oct '20

06 Oct '20

Hi guys! Being an absolute NOOB, mailing the first time to this group, I hope you're patient with my lack of knowledge ... I have an issue with following documentation (is this the right place for issues?): https://directory.fedoraproject.org/docs/389ds/howto/quickstart.html My company works with RHDS11 (RHEL8) so I tried to recreate some stuff (Fedora 32): useradd -c "RedHat Directory Server" -u 389 -g 389 -s /sbin/nologin slapd groupadd -g 389 ds Needs to be done before the installation of "389-base", or user and group will be created automatically (dirsrv.dirsrv). Adapting basic configuration as described (instance.inf): [general] group = ds user = slapd leads to ERR - dse_read_one_file - The configuration file /etc/dirsrv/slapd-example/schema//usr/share/dirsrv/schema/60trust.ldif could not be accessed, error -1 after a copy: cp /usr/share/dirsrv/schema/60trust.ldif /etc/dirsrv/schema/ instance creation works like a charm ... Sorry again for being annoying, but ... where am I doing wrong? also having some SELinux related questions, is this the right place for such kind of issues? Best regards, Hendrik Steiner

2 3

Table of duration and acceptable distance between two synchronized directories.
by 389ds＠lemiere.org 06 Oct '20

06 Oct '20

1 0

Announcing 389 Directory Server 1.4.3.13
by Mark Reynolds 05 Oct '20

05 Oct '20

389 Directory Server 1.4.3.13 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.3.13 Fedora packages are available on Fedora 32. https://koji.fedoraproject.org/koji/taskinfo?taskID=52811659 <https://koji.fedoraproject.org/koji/taskinfo?taskID=52811659> - Fedora 32 https://bodhi.fedoraproject.org/updates/FEDORA-2020-f7a1de9dec <https://bodhi.fedoraproject.org/updates/FEDORA-2020-f7a1de9dec> - Bodhi The new packages and versions are: * 389-ds-base-1.4.3.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.3.13.tar.bz2> Highlights in 1.4.3.13 * 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. 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 GitHub project: https://github.com/389ds/389-ds-base * Bump version to 1.4.3.13 * Issue 4342 - UI - additional fixes for creation instance modal * Issue 3996 - Add dsidm rename option (#4338) * Issue 4258 - Add server version information to UI * Issue 4209 - RFE - add bootstrap credentials to repl agreement (UI update) * Issue 4209 - RFE - add bootstrap credentials to repl agreement (CLI update) * Issue 4209 - RFE - add bootstrap credentials to repl agreement * Issue 4319 - Performance search rate: listener may be erroneously waken up (#4323) * Ticket 51190 - SyncRepl plugin provides a wrong cookie * Ticket 51253 - dscreate should LDAPI to bootstrap the config * Ticket 51228 - Fix lock/unlock wording and lib389 use of methods * Ticket 51229 - Server Settings page gets into an unresponsive state * Ticket 51165 - Set the operation start time for extended ops * Ticket 51228 - Clean up dsidm user status command * Ticket 51233 - ds-replcheck crashes in offline mode * Ticket 50260 - Fix test according to #51222 fix -- 389 Directory Server Development Team

1 0

389 DS on CentOS 8
by Paul Whitney 05 Oct '20

05 Oct '20

Hi guys, I am just now looking into our 389-ds migration strategy from CentOS 7 to 8. I successfully created my first master 389 instance on 8. It took some getting used to doing it on the cockpit plugin. But what I am missing is how do I merge a view where I can manage all of my DS from one view? I recall you saying the there will no longer be a java console, is there an alternative solution, such as an application, that will allow me to view all of my systems in a console (that is deprecated)? Thanks, Paul M. Whitney paul.whitney(a)mac.com Sent from my Mac Book Pro

4 5

Complex MMR scenarios
by Eugen Lamers 05 Oct '20

05 Oct '20

Hi, we want to setup a Multi Master Replication that represents a scenario with several mobile environments which need to replicate with some immobile server from time to time. Is it possible - and reasonable - to group the servers of a mobile environment together to a kind of sub-level MMR which replicates with the higher level MMR of the immobile environment. This replication between the different "levels" would be triggered somehow externally, because there would not always be a (sufficient) connection between them. This would represent some kind of combination of MMR and cascading replication. Is there someone with experience with such kind of scenarios? Thanks, Eugen

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users October 2020