389-users November 2020

389-users@lists.fedoraproject.org

8 participants
14 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 12 Dec '23

12 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 02 Feb '21

02 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.9
by Mark Reynolds 01 Dec '20

01 Dec '20

389 Directory Server 1.4.4.9 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.4.9 Fedora packages are available on Fedora 33. Fedora 33: https://koji.fedoraproject.org/koji/taskinfo?taskID=56470736 <https://koji.fedoraproject.org/koji/taskinfo?taskID=56470736> - Koji https://bodhi.fedoraproject.org/updates/FEDORA-2020-5f9a6218fa <https://bodhi.fedoraproject.org/updates/FEDORA-2020-5f9a6218fa> - Bohdi The new packages and versions are: * 389-ds-base-1.4.4.9-1 Source tarballs are available for download at Download 389-ds-base Source <https://github.com/389ds/389-ds-base/archive/389-ds-base-1.4.4.9.tar.gz> Highlights in 1.4.4.9 * 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… <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 <https://github.com/389ds/389-ds-base> * Bump version to 1.4.4.9 * Issue 4105 - Remove python.six (fix regression) * Issue 4384 - Use MONOTONIC clock for all timing events and conditions * Issue 4243 - Fix test: SyncRepl plugin provides a wrong cookie (#4467) * Issue 4460 - BUG - lib389 should use system tls policy * Issue 3657 - Add options to dsctl for dsrc file * Issue 3986 - UI - Handle objectclasses that do not have X-ORIGIN set * Issue 4297 - 2nd fix for on ADD replication URP issue internal searches with filter containing unescaped chars (#4439) * Issue 4449 - dsconf replication monitor fails to retrieve database RUV - consumer (Unavailable) (#4451) * Issue 4105 - Remove python.six from lib389 (#4456) * Issue 4440 - BUG - ldifgen with –start-idx option fails with unsupported operand (#4444) * Issue 2054 - do not add referrals for masters with different data generation #2054 (#4427) * Issue 2058 - Add keep alive entry after on-line initialization - second version (#4399) * Issue 4373 - BUG - Mapping Tree nodes can be created that are invalid * Issue 4428 - BUG Paged Results with critical false causes sigsegv in chaining * Issue 4428 - Paged Results with Chaining Test Case * Issue 4383 - Do not normalize escaped spaces in a DN * Issue 4432 - After a failed online import the next imports are very slow * Issue 4404 - build problems at alpine linux * Issue 4316 - performance search rate: useless poll on network send callback (#4424) * Issue 4429 - NULL dereference in revert_cache() * Issue 4391 - DSE config modify does not call be_postop (#4394) * Issue 4412 - Fix CLI repl-agmt requirement for parameters (#4422) -- 389 Directory Server Development Team

1 0

Announcing 389 Directory Server 1.4.3.17
by Mark Reynolds 01 Dec '20

01 Dec '20

389 Directory Server 1.4.3.17 The 389 Directory Server team is proud to announce 389-ds-base version 1.4.3.17 Fedora packages are available on Fedora 32. https://koji.fedoraproject.org/koji/taskinfo?taskID=56455191 <https://koji.fedoraproject.org/koji/taskinfo?taskID=56455191> - Fedora 32 https://bodhi.fedoraproject.org/updates/FEDORA-2020-b73e7caaa7 <https://bodhi.fedoraproject.org/updates/FEDORA-2020-b73e7caaa7> - Bodhi The new packages and versions are: * 389-ds-base-1.4.3.17-1 Source tarballs are available for download at Download 389-ds-base Source <https://github.com/389ds/389-ds-base/archive/389-ds-base-1.4.3.17.tar.gz> Highlights in 1.4.3.17 * 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… <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 <https://github.com/389ds/389-ds-base> * Bump version to 1.4.3.17 * Issue 4384 - Use MONOTONIC clock for all timing events and conditions * Issue 4449 - Add dsconf replication monitor test case (gitHub issue 4449) in 1.4.3 branch * Issue 4243 - Fix test: SyncRepl plugin provides a wrong cookie (#4467) * Issue 4112 - Added a CI test (#4441) * Issue 4460 - BUG - lib389 should use system tls policy * Issue 3657 - Add options to dsctl for dsrc file * Issue 3986 - UI - Handle objectclasses that do not have X-ORIGIN set * Issue 4297 - 2nd fix for on ADD replication URP issue internal searches with filter containing unescaped chars (#4439) * Issue 4187 - improve mutex alloc in conntable * Issue 3986 - Fix OID change between 10rfc2307 and 10rfc2307compat * Issue 3986 - Update 2307compat.ldif * Issue 4449 - dsconf replication monitor fails to retrieve database RUV - consumer (Unavailable) (#4451) * Issue 4440 - BUG - ldifgen with –start-idx option fails with unsupported operand (#4444) * Issue 4427 - do not add referrals for masters with different data generation #2054 (#4427) * Issue 2058 - Add keep alive entry after on-line initialization - second version (#4399) * Issue 4373 - BUG - Mapping Tree nodes can be created that are invalid * Issue 4428 - BUG Paged Results with critical false causes sigsegv in chaining * Issue 4428 - Paged Results with Chaining Test Case * Issue 4383 - Do not normalize escaped spaces in a DN * Issue 4425 - Backport tests from master branch, fix failing tests -- 389 Directory Server Development Team

1 0

dsconf broken for ldaps instances in 1.4.3 but working in 1.4.2
by Ivanov Andrey (M.) 26 Nov '20

26 Nov '20

dsconf works fine for instances using ldaps in v1.4.2 (389-directory-server:stable) bit it seems to be broken (not recognizing TLS certificates) in v1.4.3 for the commands like dsconf ldaps://ldap-model.polytechnique.fr:636 -D "cn=Directory Manager" -w mypass some_command In both cases i am using dsconf to manage the same external LDAP server (1.4.3.x), the OS on both is CentOS 8.2 with latest updates: <With version 1.4.2> [root@ldap-centos8 ~]# rpm -qa | grep 389 [root@ldap-centos8 ~]# dnf -y module enable 389-directory-server:stable [root@ldap-centos8 ~]# dnf -y install 389-ds-base [root@ldap-centos8 ~]# rpm -qa | grep 389 python3-lib389-1.4.2.16-1.module_el8+9435+e6daf39f.noarch 389-ds-base-libs-1.4.2.16-1.module_el8+9435+e6daf39f.x86_64 389-ds-base-1.4.2.16-1.module_el8+9435+e6daf39f.x86_64 [root@ldap-centos8 ~]# dsconf ldaps://ldap-model.polytechnique.fr:636 -D "cn=Directory Manager" -w mypass security get nsslapd-security: on nsslapd-securelistenhost: nsslapd-secureport: 636 ... <everything's fine> <Now the version 1.4.3> [root@ldap-centos8 ~]# dnf -y remove 389* [root@ldap-centos8 ~]# dnf -y module disable 389-directory-server:stable [root@ldap-centos8 ~]# dnf -y module enable 389-directory-server:testing [root@ldap-centos8 ~]# dnf -y install 389-ds-base [root@ldap-centos8 ~]# rpm -qa | grep 389 python3-lib389-1.4.3.13-1.module_el8+10475+b74bca99.noarch 389-ds-base-libs-1.4.3.13-1.module_el8+10475+b74bca99.x86_64 389-ds-base-1.4.3.13-1.module_el8+10475+b74bca99.x86_64 [root@ldap-centos8 ~]# dsconf ldaps://ldap-model.polytechnique.fr:636 -D "cn=Directory Manager" -w mypass security get Error: Can't contact LDAP server - error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate in certificate chain) <dsconf does not seem to recongize the server's certificate it recognized in 1.4.2 even if ldapsearch still works ok> [root@ldap-centos8 ~]# ldapsearch -H ldaps://ldap-model.polytechnique.fr -b 'cn=config' -D "cn=Directory Manager" -W '(cn=config)' nsslapd-security Enter LDAP Password: # extended LDIF # # LDAPv3 # base <cn=config> with scope subtree # filter: (cn=config) # requesting: nsslapd-security # # config dn: cn=config nsslapd-security: on ... <dsconf -v for both cases> [root@ldap-centos8 ~]# dsconf -v ldaps://ldap-model.polytechnique.fr:636 -D "cn=Directory Manager" -w mypass security get DEBUG: The 389 Directory Server Configuration Tool DEBUG: Inspired by works of: ITS, The University of Adelaide DEBUG: dsrc path: /root/.dsrc DEBUG: dsrc container path: /data/config/container.inf DEBUG: dsrc instances: [] DEBUG: dsrc no such section: slapd-ldaps://ldap-model.polytechnique.fr:636 DEBUG: Called with: Namespace(basedn=None, binddn='cn=Directory Manager', bindpw='mypass', func=<function _security_generic_get_parser.<locals>.<lambda> at 0x7fce5a5e7158>, instance='ldaps://ldap-model.polytechnique.fr:636', json=False, prompt=False, pwdfile=None, starttls=False, verbose=True) DEBUG: Instance details: {'uri': 'ldaps://ldap-model.polytechnique.fr:636', 'basedn': None, 'binddn': 'cn=Directory Manager', 'bindpw': None, 'saslmech': None, 'tls_cacertdir': None, 'tls_cert': None, 'tls_key': None, 'tls_reqcert': 1, 'starttls': False, 'prompt': False, 'pwdfile': None, 'args': {'ldapurl': 'ldaps://ldap-model.polytechnique.fr:636', 'root-dn': 'cn=Directory Manager'}} DEBUG: SER_SERVERID_PROP not provided, assuming non-local instance DEBUG: Allocate <class 'lib389.DirSrv'> with ldaps://ldap-model.polytechnique.fr:636 DEBUG: Allocate <class 'lib389.DirSrv'> with ldap-centos8.polytechnique.fr:389 DEBUG: Allocate <class 'lib389.DirSrv'> with ldap-centos8.polytechnique.fr:389 DEBUG: SER_SERVERID_PROP not provided, assuming non-local instance DEBUG: Allocate <class 'lib389.DirSrv'> with ldaps://ldap-model.polytechnique.fr:636 DEBUG: Allocate <class 'lib389.DirSrv'> with ldap-centos8.polytechnique.fr:389 DEBUG: Allocate <class 'lib389.DirSrv'> with ldap-centos8.polytechnique.fr:389 DEBUG: open(): Connecting to uri ldaps://ldap-model.polytechnique.fr:636 DEBUG: open(): bound as cn=Directory Manager DEBUG: cn=config getVal('nsslapd-security') DEBUG: cn=config getVal('nsslapd-securelistenhost') DEBUG: cn=config getVal('nsslapd-securePort') DEBUG: cn=encryption,cn=config getVal('nsSSLClientAuth') DEBUG: cn=encryption,cn=config getVal('nsTLSAllowClientRenegotiation') DEBUG: cn=config getVal('nsslapd-require-secure-binds') DEBUG: cn=config getVal('nsslapd-ssl-check-hostname') DEBUG: cn=config getVal('nsslapd-validate-cert') DEBUG: cn=encryption,cn=config getVal('nsSSLSessionTimeout') DEBUG: cn=encryption,cn=config getVal('sslVersionMin') DEBUG: cn=encryption,cn=config getVal('sslVersionMax') DEBUG: cn=encryption,cn=config getVal('allowWeakCipher') DEBUG: cn=encryption,cn=config getVal('allowWeakDHParam') DEBUG: cn=encryption,cn=config getVal('nsSSL3Ciphers') nsslapd-security: on nsslapd-securelistenhost: nsslapd-secureport: 636 [root@ldap-centos8 ~]# dsconf -v ldaps://ldap-model.polytechnique.fr:636 -D "cn=Directory Manager" -w mypass security get DEBUG: The 389 Directory Server Configuration Tool DEBUG: Inspired by works of: ITS, The University of Adelaide DEBUG: dsrc path: /root/.dsrc DEBUG: dsrc container path: /data/config/container.inf DEBUG: dsrc instances: [] DEBUG: dsrc no such section: slapd-ldaps://ldap-model.polytechnique.fr:636 DEBUG: Called with: Namespace(basedn=None, binddn='cn=Directory Manager', bindpw='mypass', func=<function _security_generic_get_parser.<locals>.<lambda> at 0x7f8b96a197b8>, instance='ldaps://ldap-model.polytechnique.fr:636', json=False, prompt=False, pwdfile=None, starttls=False, verbose=True) DEBUG: Instance details: {'uri': 'ldaps://ldap-model.polytechnique.fr:636', 'basedn': None, 'binddn': 'cn=Directory Manager', 'bindpw': None, 'saslmech': None, 'tls_cacertdir': None, 'tls_cert': None, 'tls_key': None, 'tls_reqcert': 1, 'starttls': False, 'prompt': False, 'pwdfile': None, 'args': {'ldapurl': 'ldaps://ldap-model.polytechnique.fr:636', 'root-dn': 'cn=Directory manager'}} DEBUG: SER_SERVERID_PROP not provided, assuming non-local instance DEBUG: Allocate <class 'lib389.DirSrv'> with ldaps://ldap-model.polytechnique.fr:636 DEBUG: Allocate <class 'lib389.DirSrv'> with ldap-centos8.polytechnique.fr:389 DEBUG: Allocate <class 'lib389.DirSrv'> with ldap-centos8.polytechnique.fr:389 DEBUG: SER_SERVERID_PROP not provided, assuming non-local instance DEBUG: Allocate <class 'lib389.DirSrv'> with ldaps://ldap-model.polytechnique.fr:636 DEBUG: Allocate <class 'lib389.DirSrv'> with ldap-centos8.polytechnique.fr:389 DEBUG: Allocate <class 'lib389.DirSrv'> with ldap-centos8.polytechnique.fr:389 DEBUG: open(): Connecting to uri ldaps://ldap-model.polytechnique.fr:636 DEBUG: Using dirsrv ca certificate /etc/dirsrv/slapd-{instance_name} DEBUG: Using external ca certificate /etc/dirsrv/slapd-{instance_name} DEBUG: Using external ca certificate /etc/dirsrv/slapd-{instance_name} DEBUG: Using certificate policy 1 DEBUG: ldap.OPT_X_TLS_REQUIRE_CERT = 1 DEBUG: Cannot connect to 'ldaps://ldap-model.polytechnique.fr:636' DEBUG: {'desc': "Can't contact LDAP server", 'info': 'error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate in certificate chain)'} Traceback (most recent call last): File "/usr/sbin/dsconf", line 133, in <module> inst = connect_instance(dsrc_inst=dsrc_inst, verbose=args.verbose, args=args) File "/usr/lib/python3.6/site-packages/lib389/cli_base/__init__.py", line 152, in connect_instance starttls=dsrc_inst['starttls'], connOnly=True) File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 1076, in open raise e File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 1072, in open self.simple_bind_s(ensure_str(self.binddn), self.bindpw, escapehatch='i am sure') File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 180, in inner return f(*args, **kwargs) File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line 443, in simple_bind_s msgid = self.simple_bind(who,cred,serverctrls,clientctrls) File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 180, in inner return f(*args, **kwargs) File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line 437, in simple_bind return self._ldap_call(self._l.simple_bind,who,cred,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls)) File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 180, in inner return f(*args, **kwargs) File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line 329, in _ldap_call reraise(exc_type, exc_value, exc_traceback) File "/usr/lib64/python3.6/site-packages/ldap/compat.py", line 44, in reraise raise exc_value File "/usr/lib64/python3.6/site-packages/ldap/ldapobject.py", line 313, in _ldap_call result = func(*args,**kwargs) ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server", 'info': 'error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate in certificate chain)'} ERROR: Error: Can't contact LDAP server - error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate in certificate chain)

4 13

Please Review 4464 - clang builds
by William Brown 26 Nov '20

26 Nov '20

https://github.com/389ds/389-ds-base/pull/4465 — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs, Australia

1 0

Object class violation. missing required attribute "objectclass"
by Mark Y. Goh 23 Nov '20

23 Nov '20

Hello, I am running into a perplexing problme while trying to stand up two replicas. From a fresh ubuntu 18.04 installation, installing, loading custom schema, and configuring 389-ds and upon a replica initiation certain entries are throwing this error - Error adding object 'dn: uid=USER,ou=People,dc=cca,dc=edu'. The error sent by the server was 'Object class violation. missing required attribute "objectclass" I have tried initializing with a ldif file as well but get the same error. I have not edited the dse.ldif file from what ubuntu installed. I have installed other replicas with no issues. 389-Directory/1.3.7.10 B2018.107.1745 on Ubuntu 18.04.5 LTS \n \l thanks mark

2 7

Re: Fwd: How to manage 389DS on CentOS8 ?
by Viktor Ashirov 19 Nov '20

19 Nov '20

On Thu, Nov 19, 2020 at 3:11 PM Alix FALEME <alix.faleme(a)gmail.com> wrote: > Thank you for your reply. > I have installed it, but i would like to find a console to manage > users/groups/etc > We don't have user management at the moment, but it is in our plans. This is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=1654238 In the meantime I recommend to use Apache Directory Studio: https://directory.apache.org/studio/ HTH > > CentOS7 have 389console package for exemple. > > > > Le jeu. 19 nov. 2020 à 10:03, Viktor Ashirov <vashirov(a)redhat.com> a > écrit : > >> >> >> >> On Thu, Nov 19, 2020 at 2:10 PM Mark Reynolds <mreynolds(a)redhat.com> >> wrote: >> >>> Forwarding to the correct list... >>> >>> >>> -------- Forwarded Message -------- >>> Subject: How to manage 389DS on CentOS8 ? >>> Date: Thu, 19 Nov 2020 07:04:45 -0400 >>> From: Alix FALEME <alix.faleme(a)gmail.com> <alix.faleme(a)gmail.com> >>> To: 389-users-owner(a)lists.fedoraproject.org >>> <389-users-owner(a)lists.fedoraproject.org> >>> <389-users-owner(a)lists.fedoraproject.org> >>> >>> > Hello guys, i’m here for an help. >>> >>> > How can i have a web console management for 389DirectoryServer on >>> CentOS8. All i found are on CentOS7 with his 389-console. That package >>> doesn’t exist on CentOS8. >>> > Any help will be much appreciate >>> >>> >>> >>> Correct, the old java console was deprecated in RHEL/Centos 7, in 8 we >>> now have a Cockpit plugin for the UI (cockpit-389-ds). >>> >>> See the RHDS 11 docs for more info: >>> >>> >>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/h… >>> >> And here's how you can install it on CentOS 8: >> https://www.port389.org/docs/389ds/download.html#centos-81-ds-14x >> >> >>> >>> HTH, >>> Mark >>> >>> >>> >>> _______________________________________________ >>> 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… >> >> >>> >> >> -- >> Viktor >> > -- Viktor

1 0

Fwd: How to manage 389DS on CentOS8 ?
by Mark Reynolds 19 Nov '20

19 Nov '20

Forwarding to the correct list... -------- Forwarded Message -------- Subject: How to manage 389DS on CentOS8 ? Date: Thu, 19 Nov 2020 07:04:45 -0400 From: Alix FALEME <alix.faleme(a)gmail.com> To: 389-users-owner(a)lists.fedoraproject.org <389-users-owner(a)lists.fedoraproject.org> > Hello guys, i’m here for an help. > How can i have a web console management for 389DirectoryServer on CentOS8. All i found are on CentOS7 with his 389-console. That package doesn’t exist on CentOS8. > Any help will be much appreciate Correct, the old java console was deprecated in RHEL/Centos 7, in 8 we now have a Cockpit plugin for the UI (cockpit-389-ds). See the RHDS 11 docs for more info: https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/h… HTH, Mark

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users November 2020