Bug 1820176 - ipa-server-install fails at step restarting directory server
Summary: ipa-server-install fails at step restarting directory server
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: freeipa
Version: 32
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: IPA Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-04-02 12:21 UTC by Jan Pazdziora (Red Hat)
Modified: 2020-09-09 21:46 UTC (History)
13 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-09-09 21:46:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jan Pazdziora (Red Hat) 2020-04-02 12:21:15 UTC
Description of problem:

Running ipa-server-install fails, the dirsrv service fails to run with error about

attribute type nisDomain: Does not match the OID "1.3.6.1.4.1.1.1.1.12". Another attribute type is already using the name or OID.

Version-Release number of selected component (if applicable):

freeipa-server-4.8.6-1.fc32.x86_64
389-ds-base-1.4.3.5-1.fc32.x86_64

How reproducible:

Deterministic.

Steps to Reproduce:
1. ipa-server-install -U -r EXAMPLE.TEST -p Secret123 -a Secret123 --no-ntp
2. systemctl status dirsrv -l --no-pager

Actual results:

  [18/44]: configuring topology plugin
  [19/44]: creating indices
  [20/44]: enabling referential integrity plugin
  [21/44]: configuring certmap.conf
  [22/44]: configure new location for managed entries
  [23/44]: configure dirsrv ccache and keytab
  [24/44]: enabling SASL mapping fallback
  [25/44]: restarting directory server
Failed to restart the directory server (CalledProcessError(Command ['/bin/systemctl', 'restart', 'dirsrv'] returned non-zero exit status 1: 'Job for dirsrv failed because the control process exited with error code.\nSee "systemctl status dirsrv" and "journalctl -xe" for details.\n')). See the installation log for details.
  [error] NetworkError: cannot connect to 'ldapi://%2Fvar%2Frun%2Fslapd-EXAMPLE-TEST.socket': Connection refused
cannot connect to 'ldapi://%2Fvar%2Frun%2Fslapd-EXAMPLE-TEST.socket': Connection refused
The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information

● dirsrv - 389 Directory Server EXAMPLE-TEST.
     Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled)
    Drop-In: /usr/lib/systemd/system/dirsrv@.service.d
             └─custom.conf
             /etc/systemd/system/dirsrv.d
             └─ipa-env.conf
     Active: failed (Result: exit-code) since Thu 2020-04-02 08:15:34 EDT; 1min 17s ago
    Process: 15024 ExecStartPre=/usr/libexec/dirsrv/ds_systemd_ask_password_acl /etc/dirsrv/slapd-EXAMPLE-TEST/dse.ldif (code=exited, status=0/SUCCESS)
    Process: 15030 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-EXAMPLE-TEST -i /run/dirsrv/slapd-EXAMPLE-TEST.pid (code=exited, status=1/FAILURE)
   Main PID: 15030 (code=exited, status=1/FAILURE)
        CPU: 143ms

Apr 02 08:15:33 master.example.test systemd[1]: Starting 389 Directory Server EXAMPLE-TEST....
Apr 02 08:15:34 master.example.test ns-slapd[15030]: [02/Apr/2020:08:15:34.003257255 -0400] - ERR - dse_read_one_file - The entry cn=schema in file /etc/dirsrv/slapd-EXAMPLE-TEST/schema/15rfc2307bis.ldif (lineno: 1) is invalid, error code 20 (Type or value exists) - attribute type nisDomain: Does not match the OID "1.3.6.1.4.1.1.1.1.12". Another attribute type is already using the name or OID.
Apr 02 08:15:34 master.example.test ns-slapd[15030]: [02/Apr/2020:08:15:34.012556482 -0400] - ERR - setup_internal_backends - Please edit the file to correct the reported problems and then restart the server.
Apr 02 08:15:34 master.example.test systemd[1]: dirsrv: Main process exited, code=exited, status=1/FAILURE
Apr 02 08:15:34 master.example.test systemd[1]: dirsrv: Failed with result 'exit-code'.
Apr 02 08:15:34 master.example.test systemd[1]: Failed to start 389 Directory Server EXAMPLE-TEST..

Expected results:

ipa-server-install finishes without error, directory server runs fine.

Additional info:

Comment 2 Jan Pazdziora (Red Hat) 2020-04-02 12:56:30 UTC
The following AVC denials were also observed:

type=AVC msg=audit(1585829725.069:473): avc:  denied  { remove_name } for  pid=1 comm="systemd" name="Server-Cert-Key.pem" dev="tmpfs" ino=58211 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:dirsrv_tmp_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1585829725.069:474): avc:  denied  { remove_name } for  pid=1 comm="systemd" name="Server-Cert.pem" dev="tmpfs" ino=58210 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:dirsrv_tmp_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1585829725.069:475): avc:  denied  { remove_name } for  pid=1 comm="systemd" name="Self-Signed-CA.pem" dev="tmpfs" ino=58209 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:dirsrv_tmp_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1585829725.069:476): avc:  denied  { rmdir } for  pid=1 comm="systemd" name="slapd-EXAMPLE-TEST" dev="tmpfs" ino=58208 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:dirsrv_tmp_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1585829733.849:539): avc:  denied  { remove_name } for  pid=1 comm="systemd" name="Server-Cert-Key.pem" dev="tmpfs" ino=59587 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:dirsrv_tmp_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1585829733.849:540): avc:  denied  { remove_name } for  pid=1 comm="systemd" name="Server-Cert.pem" dev="tmpfs" ino=59586 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:dirsrv_tmp_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1585829733.849:541): avc:  denied  { remove_name } for  pid=1 comm="systemd" name="Self-Signed-CA.pem" dev="tmpfs" ino=59585 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:dirsrv_tmp_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1585829733.849:542): avc:  denied  { rmdir } for  pid=1 comm="systemd" name="slapd-EXAMPLE-TEST" dev="tmpfs" ino=59584 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:dirsrv_tmp_t:s0 tclass=dir permissive=0

Could they be the reason for the failure?

Comment 3 Jan Pazdziora (Red Hat) 2020-04-02 12:58:23 UTC
I see the same (or similar) AVC denials on Fedora rawhide but ipa-server-install passes there.

Comment 4 Alexander Bokovoy 2020-04-02 13:00:58 UTC
389-ds changed RFC2307/RFC2307bis-related attributes recently: https://pagure.io/389-ds-base/issue/50933, https://pagure.io/389-ds-base/pull-request/50934#request_diff

However, there is a difference which I cannot pin anywhere right now.

Below is how FreeIPA defines RFC2307bis additions (15rfc2307bi.ldif):
commit ec1585f83179fa147f3f7510e3d7b153b8855e9d
Author: Petr Viktorin <pviktori>
Date:   Mon Apr 29 18:09:45 2013 +0200

    Add formerly update-only schema
    
    Some schema was only delivered in updates. Add it back as ldif files.
    
    https://fedorahosted.org/freeipa/ticket/3454

diff --git a/install/share/15rfc2307bis.ldif b/install/share/15rfc2307bis.ldif
new file mode 100644
index 000000000..b78dc9a94
--- /dev/null
+++ b/install/share/15rfc2307bis.ldif
@@ -0,0 +1,16 @@
+#
+# Schema derived from RFC 2307bis:
+#       "An Approach for Using LDAP as a Network Information Service"
+#
+dn: cn=schema
+attributeTypes: ( 1.3.6.1.1.1.1.28 NAME 'nisPublickey' DESC 'nisPublickey' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'RFC2307bis' )
+attributeTypes: ( 1.3.6.1.1.1.1.29 NAME 'nisSecretkey' DESC 'nisSecretkey' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'RFC2307bis' )
+attributeTypes: ( 1.3.6.1.4.1.1.1.1.12 NAME 'nisDomain' DESC 'NIS domain' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'RFC2307bis' )
+attributeTypes: ( 2.16.840.1.113730.3.1.30 NAME 'mgrpRFC822MailMember' DESC 'mgrpRFC822MailMember' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'RFC2307bis' )
+attributeTypes: ( 1.3.6.1.4.1.42.2.27.1.1.12 NAME 'nisNetIdUser' DESC 'nisNetIdUser' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'RFC2307bis' )
+attributeTypes: ( 1.3.6.1.4.1.42.2.27.1.1.13 NAME 'nisNetIdGroup' DESC 'nisNetIdGroup' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'RFC2307bis' )
+attributeTypes: ( 1.3.6.1.4.1.42.2.27.1.1.14 NAME 'nisNetIdHost' DESC 'nisNetIdHost' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'RFC2307bis' )
+objectClasses: ( 1.3.6.1.1.1.2.14 NAME 'nisKeyObject' DESC 'nisKeyObject' SUP top MUST ( cn $ nisPublickey $ nisSecretkey ) MAY ( uidNumber $ description ) )
+objectClasses: ( 1.3.1.6.1.1.1.2.15 NAME 'nisDomainObject' DESC 'nisDomainObject' SUP top AUXILIARY MUST nisDomain )
+objectClasses: ( 2.16.840.1.113730.3.2.4 NAME 'mailGroup' DESC 'mailGroup' SUP top MUST mail MAY ( cn $ mgrpRFC822MailMember ) )
+objectClasses: ( 1.3.6.1.4.1.42.2.27.1.2.6 NAME 'nisNetId' DESC 'nisNetId' SUP top MUST cn MAY ( nisNetIdUser $ nisNetIdGroup $ nisNetIdHost ) )


nisDomain is using OID 1.3.6.1.4.1.1.1.1.12 which is associated with memberUid attribute in 389-ds schema. In actual RFC2307bis draft it always was .30 OID, not .12.

memberUid is not defined in FreeIPA schema and comes from 389-ds, so when memberUID changed its definition, it started conflicting.

Comment 5 Alexander Bokovoy 2020-04-02 13:03:58 UTC
It looks like .12 nisDomain was a mistake overlooked in 2013, so we now need to solve it.

Comment 6 Alexander Bokovoy 2020-04-02 13:10:04 UTC
I'm wrong about memberUid. OID "1.3.6.1.4.1.1.1.1.12" does not exist in 389-ds. memberUid is "1.3.6.1.1.1.1.12", so there is no conflict. It is really nisDomain using wrong OID on FreeIPA side.

The fix would be by using the right OID as nisDomain never existed before in 389-ds.

Comment 7 Alexander Bokovoy 2020-04-02 13:14:45 UTC
Actually, I was too fast. Looking into 389-ds history, it did have nisDomain with OID "1.3.6.1.4.1.1.1.1.12" in ldap/schema/60nis.ldif

commit 9fca66e92dcacdba41db3eab88629015c05be75e
Author: Rich Megginson <rmeggins>
Date:   Thu Oct 16 16:43:37 2008 +0000

    Resolves: bug 455026 bug 441026
    Bug Description: RFE: include RFC4876 schema - Autofs does not include
    LDAP schema for Fedora Directory Server
    Reviewed by: nkinder (Thanks!)
    Fix Description: Pieter D.J. Krul has contributed many schema files that
    have been tested in production environments.  They are divided into two
    groups - those that conflict with existing schema in DS, CertSys, and
    IPA, and those which do not.  The latter are installed in the default
    schema directory to be available for new instances - the former are
    installed in the data directory just as the rfc2307bis schema.  The
    schema provided cover autofs and rfc4876, as in the bug reports, and
    more.  Here is the full list of new files:
    60trust.ldif 60pureftpd.ldif 60sudo.ldif 60nis.ldif 60samba.ldif
    60mozilla.ldif
    60samba3.ldif 60krb5kdc.ldif 60sabayon.ldif 60kerberos.ldif
    60rfc4876.ldif 60inetmail.ldif 60rfc3712.ldif 60eduperson.ldif
    60rfc2739.ldif 60changelog.ldif 60radius.ldif 60autofs.ldif 60qmail.ldif
    Platforms tested: RHEL5
    Flag Day: no
    Doc impact: yes - document the new schema

among others, nisDomain is defined in 389-ds in ldap/schema/60nis.ldif as

attributeTypes: (
  1.3.6.1.4.1.1.1.1.12
  NAME 'nisDomain'
  DESC 'NIS domain'
  SUP name
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
  EQUALITY caseIgnoreIA5Match
  SUBSTR caseIgnoreIA5SubstringsMatch
  )

and at the same time in ldap/schema/10rfc2307bis.ldif as

attributeTypes: (
  1.3.6.1.1.1.1.30 NAME 'nisDomain'
  DESC 'NIS domain'
  EQUALITY caseIgnoreIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
  )

I think we definitely need to synchronise them all, so the fix has to be in both 389-ds and FreeIPA.

Comment 8 Alexander Bokovoy 2020-04-02 13:37:40 UTC
The biggest issue is multimaster replication. A schema change like this is going to break things in a replicated environment.

BTW, OpenQA also caught this in Fedora 32: https://bodhi.fedoraproject.org/updates/FEDORA-2020-4b99fc12da has broken FreeIPA-related tests.

Comment 9 Adam Williamson 2020-04-03 21:35:25 UTC
openQA tests are failing on Rawhide too, BTW. I think it's the same thing.

Comment 10 mreynolds 2020-09-09 15:55:40 UTC
Adam are these still failing?  They should not be any more.  I just want to confirm before closing out related bugs.
Thanks!

Comment 11 Adam Williamson 2020-09-09 19:34:09 UTC
Oh yeah, this got fixed up a while back I believe. Tests are passing on 32 and 33 ATM (Rawhide composes are failing lately). Go ahead and close it.

Comment 12 mreynolds 2020-09-09 21:46:01 UTC
(In reply to Adam Williamson from comment #11)
> Oh yeah, this got fixed up a while back I believe. Tests are passing on 32
> and 33 ATM (Rawhide composes are failing lately). Go ahead and close it.

Thanks, closing...


Note You need to log in before you can comment on or make changes to this bug.