389-users September 2019

389-users@lists.fedoraproject.org

20 participants
24 discussions

sudoers tree missing on a 389-ds replica
by Sergei Gerasenko 23 Sep '19

23 Sep '19

Hello, I’ve run into an interesting situatuion with the sudoers tree in 389-ds. All the nodes in the 389-ds cluster have it, but one doesn’t. I’ve tried dumping the database on a good node with db2ldif and reloading on the bad node with ldif2db, but the situation is not changing. I’ve also tried db2index on the bad node without much luck. Any ideas? Thanks, Sergei

3 4

Monitoring 389ds with telegraf
by Olivier JUDITH 19 Sep '19

19 Sep '19

Hi all , For all those who are interested , i started to develop with the help of Marco Favero <aka falon> a monitoring solution based on telegraf to gather metrics from my 389 instances . All metrics are stored in influxdb ( timeseries db) and can be visualized on Grafana. The code source is available here : https://github.com/influxdata/telegraf/pull/5691 Grafana Dashboard is here : https://grafana.com/grafana/dashboards/10587 Regards

2 3

389ds ldaps issue after upgrade
by Mihai Carabas 17 Sep '19

17 Sep '19

Hello, After upgrading to the latest 389ds (1.4.0.27) with FC29, I have the following issue on LDAPS: ldap_url_parse_ext(ldaps://ldap.curs.pub.ro) ldap_create ldap_url_parse_ext(ldaps://ldap.curs.pub.ro:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ldap.curs.pub.ro:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 141.85.241.48:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before SSL initialization tls_write: want=303, written=303 0000: 16 03 01 01 2a 01 00 01 26 03 03 72 71 d6 83 08 ....*...&..rq... 0010: 7a 5f 26 69 2b f7 f7 4f 59 76 87 c0 07 bc 6c db z_&i+..OYv....l. 0020: fe 51 69 e4 2c dc 65 3d 52 48 f6 20 2b c1 75 d1 .Qi.,.e=RH. +.u. 0030: 98 3b dc 70 3e 69 82 a4 41 91 7f 89 0e fc 52 43 .;.p>i..A.....RC 0040: ab be c9 77 0b 02 a7 f1 9f ec a7 d0 00 48 13 02 ...w.........H.. 0050: 13 03 13 01 13 04 c0 2c c0 30 cc a9 cc a8 c0 ad .......,.0...... 0060: c0 2b c0 2f c0 ac c0 23 c0 27 c0 0a c0 14 c0 09 .+./...#.'...... 0070: c0 13 00 9d c0 9d 00 9c c0 9c 00 3d 00 3c 00 35 ...........=.<.5 0080: 00 2f 00 9f cc aa c0 9f 00 9e c0 9e 00 6b 00 67 ./...........k.g 0090: 00 39 00 33 00 ff 01 00 00 95 00 0b 00 04 03 00 .9.3............ 00a0: 01 02 00 0a 00 0c 00 0a 00 1d 00 17 00 1e 00 19 ................ 00b0: 00 18 00 23 00 00 00 16 00 00 00 17 00 00 00 0d ...#............ 00c0: 00 30 00 2e 04 03 05 03 06 03 08 07 08 08 08 09 .0.............. 00d0: 08 0a 08 0b 08 04 08 05 08 06 04 01 05 01 06 01 ................ 00e0: 03 03 02 03 03 01 02 01 03 02 02 02 04 02 05 02 ................ 00f0: 06 02 00 2b 00 09 08 03 04 03 03 03 02 03 01 00 ...+............ 0100: 2d 00 02 01 01 00 33 00 26 00 24 00 1d 00 20 4c -.....3.&.$... L 0110: 3f b1 bc f8 d0 a1 54 e7 a2 6f d4 d4 d1 ab b3 77 ?.....T..o.....w 0120: 67 2c ea 51 94 f3 fa 43 de 96 5f 9b eb 12 10 g,.Q...C.._.... TLS trace: SSL_connect:SSLv3/TLS write client hello tls_read: want=5, got=5 0000: 15 03 03 00 02 ..... tls_read: want=2, got=2 0000: 02 50 .P TLS trace: SSL3 alert read:fatal:internal error TLS trace: SSL_connect:error in error TLS: can't connect: error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error. ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) All the things remained the same like before upgrading. I see tihs internal error and I could not find any hints about it. Did someone hit this issue? Thank you, Mihai Carabas

3 6

Re: FIPS 140-2 and dirsrv-admin
by William Brown 13 Sep '19

13 Sep '19

If memory serves correctly ... there are some un-resolved issues between dirsrv-admin + fips. I remember discussing this with Mark as something that may fall into the "fix when someone runs into it" because that combination we thought would be rare. But I'm not sure that this issue here is a fips one? I've seen another issue lately where the dirsrv-admin used a different pin.txt to the dirsrvinstances, but I'm not sure of the details. Are there fresh installs of ds? Or upgrades? > On 28 Aug 2019, at 05:51, Paul Whitney <paul.whitney(a)chesapeake-it.com> wrote: > > Hi guys, > > I have SSL enabled both slapd instances and dirsrv-admin on FIPS enabled CentOS 7. The instances seem to start up no problem. However, the admin console (dirsrv-admin) is complaining the password credentials are not valid for the NSS FIPS 140-2 DB even through the exact same credentials are presented to the SLAPD instances. I am using a pin.txt file in the correct format for both SLAPD and DIRSRV-ADMIN. > > Are there compatibility issues with FIPS and 389-DS admin-serv? > > Paul M. Whitney > _______________________________________________ > 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

4 12

groupofuniquenames vs. groupofnames / post hooks or actions after object creation
by Weigel Stefan 11 Sep '19

11 Sep '19

Hi, I need a little help with two topics: 1. users should be able to use a simple web frontend to change ldap password and manage ssh pubkeys. We evaluated Fusion Directory (https://www.fusiondirectory.org/) for this. In Fusion Directory group membership is using groupofnames rather than groupofuniquenames used in 389. I played around but can't find a solution to fix this. I tried to modify cn=group,cn=defaultobjectclassescontainer,ou=1.1,ou=admin,ou=global preferences,ou=genua.de,o=netscaperoot -> nsDefaultObjectClass from groupofuniquenames to groupofnames and renamed cn=groupofuniquenames,cn=ResourceEditorExtension,ou=1.1,ou=Admin,ou=Global Preferences,ou=genua.de,o=netscaperoot to cn=groupofnames,cn=ResourceEditorExtension,ou=1.1,ou=Admin,ou=Global Preferences,ou=genua.de,o=netscaperoot but in 389-console it shows me message: uniqueMember is not allowed. Is it possible to change the default object class of the group? How to to do it? Otherwise could you point me to a simple webgui to edit values? 2. When creating a user object under I want to trigger some post actions (create directories, copy files, etc.) As I understand this should be possible with the plugins. I'm asking myself if there's already such a plugin or could you provide me some more infos. Thanks in advance, Stefan

2 2

Re: urp_fixup_add_cenotaph errors
by Morgan, Iain (ARC-TN)[InuTeq, LLC] 10 Sep '19

10 Sep '19

On 9/5/19, 18:11, "Iain Morgan" <Iain.Morgan(a)nasa.gov> wrote: Hello, While testing 389-ds 1.3.9.1 on RHEL 7.7, I noticed the the errors listed below. The actual LDAP operations all succeed, but I find the errors disconcerting. [28/Aug/2019:10:42:13.446609256 -0700] - ERR - conn=44 op=5 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:14.202854398 -0700] - ERR - conn=52 op=5 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:18.504412946 -0700] - ERR - conn=95 op=3 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:24.412896470 -0700] - ERR - conn=160 op=8 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 These all appear to be related to modrdn operations. -- Iain Morgan

3 2

Re: Docker official image
by Olivier JUDITH 09 Sep '19

09 Sep '19

Hi all, I'm back on this topic, Can you tell me with the docker image how to create the root suffix ? I tried this step but othing appears on Apache Directory server IDE ldapmodify -a -D "cn=Directory manager" -w mypass -p 3389 -h 10.109.139.63 -x dn: cn="dc=domain,dc=net",cn=mapping tree,cn=config changetype: add cn: dc=domain,dc=net objectclass: top objectclass: extensibleObject objectclass: nsMappingTree nsslapd-state: backend nsslapd-backend: UserData Regards

3 7

Re: urp_fixup_add_cenotaph errors
by Morgan, Iain (ARC-TN)[InuTeq, LLC] 08 Sep '19

08 Sep '19

Hello Marc, Yes, it is 389-ds-base1.3.9.1-10.el7, but we are not using IPA and there are no memberOf plugin errors. The actual modrdn operations have error=0. -- Iain Morgan On 9/6/19, 15:05, "Marc Sauton" <msauton(a)redhat.com> wrote: could you check the system has 389-ds-base-1.3.9.1-10.el7 <https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_down…> or above? do the MODRDN fail with err=53? is it in IPA context with memberof-plugin errors? there was a bug fix in bz 1680245 that seem related to this, may be there is till something going on, or may be it can be ignored. we would likely need to privately review more logs to tell (open a RH case?) Thanks, M. On Fri, Sep 6, 2019 at 10:38 AM Morgan, Iain (ARC-TN)[InuTeq, LLC] <iain.morgan(a)nasa.gov> wrote: On 9/5/19, 18:11, "Iain Morgan" <Iain.Morgan(a)nasa.gov> wrote: Hello, While testing 389-ds 1.3.9.1 on RHEL 7.7, I noticed the the errors listed below. The actual LDAP operations all succeed, but I find the errors disconcerting. [28/Aug/2019:10:42:13.446609256 -0700] - ERR - conn=44 op=5 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:14.202854398 -0700] - ERR - conn=52 op=5 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:18.504412946 -0700] - ERR - conn=95 op=3 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:24.412896470 -0700] - ERR - conn=160 op=8 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 These all appear to be related to modrdn operations. -- Iain Morgan _______________________________________________ 389-users mailing list -- 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org…> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines <https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki…> List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject… <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedoraproject.or…>

2 1

urp_fixup_add_cenotaph errors
by Iain Morgan 05 Sep '19

05 Sep '19

Hello, While testing 389-ds 1.3.9.1 on RHEL 7.7, I noticed the the errors listed below. The actual LDAP operations all succeed, but I find the errors disconcerting. [28/Aug/2019:10:42:13.446609256 -0700] - ERR - conn=44 op=5 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:14.202854398 -0700] - ERR - conn=52 op=5 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:18.504412946 -0700] - ERR - conn=95 op=3 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 [28/Aug/2019:10:42:24.412896470 -0700] - ERR - conn=160 op=8 - urp_fixup_add_cenotaph - failed to add cenotaph, err= 21 -- Iain Morgan

1 0

sync AD account state
by DaV 05 Sep '19

05 Sep '19

Hi guys, How can I sync account state from Windows AD to 389ds 1. account disabled 2. account lockout 3. password expired I want to sync these attributes from Windows AD to 389ds, would you please tell me? Thanks in advance. Sincerely, -- DaV

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users September 2019