Installation Replica reports error: Full PKINIT configuration did not succeed

[74cmonty]

Hi,
after completing master installation I started setup of replica.
This means I first enrolled the replica server as a client and then executed this
command:
ipa-replica-install

The installation log reports this error:
Full PKINIT configuration did not succeed
The setup will only install bits essential to the server functionality
You can enable PKINIT after the setup completed using 'ipa-pkinit-manage'

Is this an error or normal behavior of replica installation?
 

Configuring certificate server (pki-tomcatd)
  [1/2]: configure certmonger for renewals
  [2/2]: Importing RA key
Done configuring certificate server (pki-tomcatd).
Configuring Kerberos KDC (krb5kdc)
  [1/1]: installing X509 Certificate for PKINIT
Full PKINIT configuration did not succeed
The setup will only install bits essential to the server functionality
You can enable PKINIT after the setup completed using 'ipa-pkinit-manage'
Done configuring Kerberos KDC (krb5kdc).
Applying LDAP updates
Upgrading IPA:. Estimated time: 1 minute 30 seconds
  [1/10]: stopping directory server
  [2/10]: saving configuration
  [3/10]: disabling listeners
  [4/10]: enabling DS global lock
  [5/10]: disabling Schema Compat
  [6/10]: starting directory server
  [7/10]: upgrading server
  [8/10]: stopping directory server
  [9/10]: restoring configuration
  [10/10]: starting directory server
Done.
Finalize replication settings
Restarting the KDC

[Alexander Bokovoy]

On su, 02 joulu 2018, 74cmonty via FreeIPA-users wrote:
> Hi,
> after completing master installation I started setup of replica.
> This means I first enrolled the replica server as a client and then executed this
> command:
> ipa-replica-install
>
> The installation log reports this error:
> Full PKINIT configuration did not succeed
> The setup will only install bits essential to the server functionality
> You can enable PKINIT after the setup completed using 'ipa-pkinit-manage'
>
> Is this an error or normal behavior of replica installation? 
It is a bug tracked at
https://pagure.io/freeipa/issue/7200. 

For a solution try to move away both /var/kerberos/krb5kdc/kdc.key and
kdc.crt, then re-run 'ipa-pkinit-manage enable', this is what a pull
request at https://github.com/freeipa/freeipa/pull/2630 is doing.

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[74cmonty]

Actually I executed these commands before you replied on the replica server:
[root@ipa-replica ~]# ipa-pkinit-manage status
PKINIT is disabled
The ipa-pkinit-manage command was successful
[root@ipa-replica ~]# ipa-pkinit-manage enable
Configuring Kerberos KDC (krb5kdc)
  [1/1]: installing X509 Certificate for PKINIT
Done configuring Kerberos KDC (krb5kdc).
The ipa-pkinit-manage command was successful
[root@ipa-replica ~]# ipa-pkinit-manage status
PKINIT is enabled
The ipa-pkinit-manage command was successful

This means I didn't delete any kdc.key / kdc.crt file.

Now the content in directory looks this:
[root@ipa-replica ~]# ls -l /var/kerberos/krb5kdc/
insgesamt 20
-rw-r--r--. 1 root root 1322  2. Dez 17:42 cacert.pem
-rw-------. 1 root root   22  9. Okt 22:59 kadm5.acl
-rw-------. 1 root root  666  2. Dez 17:21 kdc.conf
-rw-r--r--. 1 root root 1480  2. Dez 17:26 kdc.crt
-rw-------. 1 root root 1704  2. Dez 17:26 kdc.key

The files are different compared to ipa-master.

Should I repeat creating the files on replica server?

THX

[Alexander Bokovoy]

On su, 02 joulu 2018, 74cmonty via FreeIPA-users wrote:
> Actually I executed these commands before you replied on the replica
> server:
> [root@ipa-replica ~]# ipa-pkinit-manage status
> PKINIT is disabled
> The ipa-pkinit-manage command was successful
> [root@ipa-replica ~]# ipa-pkinit-manage enable
> Configuring Kerberos KDC (krb5kdc)
>   [1/1]: installing X509 Certificate for PKINIT
> Done configuring Kerberos KDC (krb5kdc).
> The ipa-pkinit-manage command was successful
> [root@ipa-replica ~]# ipa-pkinit-manage status
> PKINIT is enabled
> The ipa-pkinit-manage command was successful
>
> This means I didn't delete any kdc.key / kdc.crt file. 
Can you show the output
of 'getcert list -f /var/kerberos/krb5kdc/kdc.crt'

If you see something like below, then you are OK, if not, then do follow
my suggestion. Your CA must be IPA and issuer must be cn=Certificate
Authority,O=$REALM, principal name must be krbtgt/$REALM@$REALM, as well
as proper key usage and EKUs.

# getcert list -f /var/kerberos/krb5kdc/kdc.crt
Number of certificates and requests being tracked: 10.
Request ID '20181128171106':
	status: MONITORING
	stuck: no
	key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
	certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
	CA: IPA
	issuer: CN=Certificate Authority,O=EXAMPLE.COM
	subject: CN=echo.example.com,O=EXAMPLE.COM
	expires: 2020-11-28 18:11:07 CET
	principal name: krbtgt/EXAMPLE.COM(a)EXAMPLE.COM
	key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
	eku: id-kp-serverAuth,id-pkinit-KPKdc
	pre-save command: 
	post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
	track: yes
	auto-renew: yes

> The files are different compared to ipa-master.
>
> Should I repeat creating the files on replica server? 
Yes, they should be different
as they stored and managed by each server
separately (note the subject in each case).

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[74cmonty]

Hi,
this is the output that looks good to me... but I'm not the expert.

[root@ipa-replica ~]# getcert list -f /var/kerberos/krb5kdc/kdc.crt
Number of certificates and requests being tracked: 4.
Request ID '20181202164246':
        status: MONITORING
        stuck: no
        key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
        certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
        CA: IPA
        issuer: CN=ipa-replica.mydomain.de,O=MYDOMAIN.DE
        subject: CN=ipa-replica.mydomain.de,O=MYDOMAIN.DE
        expires: 2019-12-02 17:26:59 CET
        principal name: krbtgt/MYDOMAIN.DE(a)MYDOMAIN.DE
        certificate template/profile: KDCs_PKINIT_Certs
        pre-save command:
        post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
        track: yes
        auto-renew: yes

THX for your advise.

[Alexander Bokovoy]

On su, 02 joulu 2018, 74cmonty via FreeIPA-users wrote:
> Hi,
> this is the output that looks good to me... but I'm not the expert. 
It is not
good, as I suspected.

> [root@ipa-replica ~]# getcert list -f /var/kerberos/krb5kdc/kdc.crt
> Number of certificates and requests being tracked: 4.
> Request ID '20181202164246':
>         status: MONITORING
>         stuck: no
>         key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
>         certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
>         CA: IPA
>         issuer: CN=ipa-replica.mydomain.de,O=MYDOMAIN.DE 
You have wrong issuer
here.

>         subject: CN=ipa-replica.mydomain.de,O=MYDOMAIN.DE
>         expires: 2019-12-02 17:26:59 CET
>         principal name: krbtgt/MYDOMAIN.DE(a)MYDOMAIN.DE
>         certificate template/profile: KDCs_PKINIT_Certs 
And no EKUs and usage
defined.

Please follow my suggestion to move out the cert/key and try again
'ipa-pkinit-manage enable'
-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[Florence Blanc-Renaud]

On 12/2/18 5:39 PM, 74cmonty via FreeIPA-users wrote:
>  Hi,
>  after completing master installation I started setup of replica.
>  This means I first enrolled the replica server as a client and then executed this
> command:
>  ipa-replica-install
>  
>  The installation log reports this error:
>  Full PKINIT configuration did not succeed
>  The setup will only install bits essential to the server functionality
>  You can enable PKINIT after the setup completed using 'ipa-pkinit-manage'
>  
>  Is this an error or normal behavior of replica installation?
>    
>  
>  Configuring certificate server (pki-tomcatd)
>     [1/2]: configure certmonger for renewals
>     [2/2]: Importing RA key
>  Done configuring certificate server (pki-tomcatd).
>  Configuring Kerberos KDC (krb5kdc)
>     [1/1]: installing X509 Certificate for PKINIT
>  Full PKINIT configuration did not succeed
>  The setup will only install bits essential to the server functionality
>  You can enable PKINIT after the setup completed using 'ipa-pkinit-manage'
>  Done configuring Kerberos KDC (krb5kdc).
>  Applying LDAP updates
>  Upgrading IPA:. Estimated time: 1 minute 30 seconds
>     [1/10]: stopping directory server
>     [2/10]: saving configuration
>     [3/10]: disabling listeners
>     [4/10]: enabling DS global lock
>     [5/10]: disabling Schema Compat
>     [6/10]: starting directory server
>     [7/10]: upgrading server
>     [8/10]: stopping directory server
>     [9/10]: restoring configuration
>     [10/10]: starting directory server
>  Done.
>  Finalize replication settings
>  Restarting the KDC
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>   
Hi,

you are probably seeing issue https://pagure.io/freeipa/issue/7655 
during ipa-replica-install.
After that, if you run ipa-pkinit-manage enable, because of issue 
https://pagure.io/freeipa/issue/7200 described by Alexander, the command 
will wrongly report success but you need to follow Alexander's advice 
and delete the cert file first.

flo

[74cmonty]

OK... following your advise and delete the "old" files.
Then run ipa-pkinit-manage enable and get this output:
[root@ipa-replica ~]# rm /var/kerberos/krb5kdc/kdc.crt
rm: reguläre Datei '/var/kerberos/krb5kdc/kdc.crt' entfernen? y
[root@ipa-replica ~]# rm /var/kerberos/krb5kdc/kdc.key
rm: reguläre Datei '/var/kerberos/krb5kdc/kdc.key' entfernen? y
[root@ipa-replica ~]# ipa-pkinit-manage enable
Configuring Kerberos KDC (krb5kdc)
  [1/1]: installing X509 Certificate for PKINIT
PKINIT certificate request failed: Certificate issuance failed (CA_UNREACHABLE: Error 7
connecting to
https://ipa-replica.biszumbitterenen.de:8443/ca/ee/ca/profileSubmitSSLClient: Couldn't
connect to server.)
Failed to configure PKINIT
Full PKINIT configuration did not succeed
The setup will only install bits essential to the server functionality
You can enable PKINIT after the setup completed using 'ipa-pkinit-manage'
Done configuring Kerberos KDC (krb5kdc).
The ipa-pkinit-manage command was successful

The relevant logfile shows this:
[root@ipa-replica ~]# tail /var/log/krb5kdc.log
Dez 03 09:01:46 ipa-replica.biszumbitterenen.de krb5kdc[2523](Information):
Dateideskriptor 8 wird geschlossen
Dez 03 09:01:46 ipa-replica.biszumbitterenen.de krb5kdc[2523](Information):
Dateideskriptor 7 wird geschlossen
Dez 03 09:01:46 ipa-replica.biszumbitterenen.de krb5kdc[2525](Information): Aktion wird
begonnen
Dez 03 09:01:46 ipa-replica.biszumbitterenen.de krb5kdc[2524](Information): Aktion wird
begonnen
Dez 03 09:08:48 ipa-replica.biszumbitterenen.de krb5kdc[2524](Information): AS_REQ (8
etypes {18 17 20 19 16 23 25 26}) 192.168.100.201: NEEDED_PREAUTH:
host/ipa-replica.biszumbitterenen.de(a)BISZUMBITTERENEN.DE für
krbtgt/BISZUMBITTERENEN.DE(a)BISZUMBITTERENEN.DE, zusätzlich Vorauthentifizierung
erforderlich
Dez 03 09:08:48 ipa-replica.biszumbitterenen.de krb5kdc[2524](Information):
Dateideskriptor 11 wird geschlossen
Dez 03 09:08:48 ipa-replica.biszumbitterenen.de krb5kdc[2524](Information): AS_REQ (8
etypes {18 17 20 19 16 23 25 26}) 192.168.100.201: ISSUE: authtime 1543824528, etypes
{rep=18 tkt=18 ses=18}, host/ipa-replica.biszumbitterenen.de(a)BISZUMBITTERENEN.DE for
krbtgt/BISZUMBITTERENEN.DE(a)BISZUMBITTERENEN.DE
Dez 03 09:08:48 ipa-replica.biszumbitterenen.de krb5kdc[2524](Information):
Dateideskriptor 11 wird geschlossen
Dez 03 09:08:48 ipa-replica.biszumbitterenen.de krb5kdc[2524](Information): TGS_REQ (8
etypes {18 17 20 19 16 23 25 26}) 192.168.100.201: ISSUE: authtime 1543824528, etypes
{rep=18 tkt=18 ses=18}, host/ipa-replica.biszumbitterenen.de(a)BISZUMBITTERENEN.DE for
ldap/ipa-replica.biszumbitterenen.de(a)BISZUMBITTERENEN.DE
Dez 03 09:08:48 ipa-replica.biszumbitterenen.de krb5kdc[2524](Information):
Dateideskriptor 11 wird geschlossen


What is causing this error?

THX

[Alexander Bokovoy]

On ma, 03 joulu 2018, 74cmonty via FreeIPA-users wrote:
> OK... following your advise and delete the "old" files.
> Then run ipa-pkinit-manage enable and get this output:
> [root@ipa-replica ~]# rm /var/kerberos/krb5kdc/kdc.crt
> rm: reguläre Datei '/var/kerberos/krb5kdc/kdc.crt' entfernen? y
> [root@ipa-replica ~]# rm /var/kerberos/krb5kdc/kdc.key
> rm: reguläre Datei '/var/kerberos/krb5kdc/kdc.key' entfernen? y
> [root@ipa-replica ~]# ipa-pkinit-manage enable
> Configuring Kerberos KDC (krb5kdc)
>   [1/1]: installing X509 Certificate for PKINIT
> PKINIT certificate request failed: Certificate issuance failed (CA_UNREACHABLE: Error 7
> connecting to
> https://ipa-replica.biszumbitterenen.de:8443/ca/ee/ca/profileSubmitSSLClient: Couldn't
> connect to server.) 
As this line says, certmonger was unable to to talk to
https://ipa-replica.biszumbitterenen.de:8443/ca/ee/ca/profileSubmitSSLClient

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[74cmonty]

This is true, the connect error is clear.

However, I don't understand why there's a connection error to the replica-server?
Please note that command ipa-pkinit-manage enable is executed on the replica-server, means
the connection fails to itself.
And there's no instruction to open port 8443 on the server (for whatever this port is
used for).

Please advise.

[Alexander Bokovoy]

On ma, 03 joulu 2018, 74cmonty via FreeIPA-users wrote:
> This is true, the connect error is clear.
>
> However, I don't understand why there's a connection error to the
> replica-server?  Please note that command ipa-pkinit-manage enable is
> executed on the replica-server, means the connection fails to itself.
> And there's no instruction to open port 8443 on the server (for
> whatever this port is used for). 
I guess this is reincarnation of
https://pagure.io/freeipa/issue/6016
(fixed in 4.3) as https://pagure.io/freeipa/issue/6878 which is fixed in
4.6.0 and above.  Installers talk to local CA directly on 8443 but
everything else should not. (See last set of comments in latter the ticket).

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland

[74cmonty]

I have installed freeipa-server-common=4.7.0, so I don't understand the relation to an
issue that should be fixed with 4.6.0.

I have no restarted command ipa-pkinit-manage enable after opening port 8443 on both,
master and replica server.

In my opinion the root cause is different.
According to error message and log the connection to
https://ipa-replica.biszumbitterenen.de:8443/ca/ee/ca/profileSubmitSSLClient
fails, however there's no service listening on port 8443 on the replica server
(192.168.100.201).
On the master server (192.168.100.200) port 8443 is accessible:
nmap -p 80,443,53,88,464,389,636,8443 192.168.100.200

Starting Nmap 7.40 ( https://nmap.org ) at 2018-12-05 20:58 CET
Nmap scan report for vm200-freeipa.local.biszumbitterenen.de (192.168.100.200)
Host is up (0.00023s latency).
PORT     STATE SERVICE
53/tcp   open  domain
80/tcp   open  http
88/tcp   open  kerberos-sec
389/tcp  open  ldap
443/tcp  open  https
464/tcp  open  kpasswd5
636/tcp  open  ldapssl
8443/tcp open  https-alt

Nmap done: 1 IP address (1 host up) scanned in 0.03 seconds

[Rob Crittenden]

74cmonty via FreeIPA-users wrote:
>  I have installed freeipa-server-common=4.7.0, so I don't
> understand the relation to an issue that should be fixed with 4.6.0. 
You never did say before which version you were using...

>  I have no restarted command ipa-pkinit-manage enable after opening
> port 8443 on both, master and replica server.
>  
>  In my opinion the root cause is different.
>  According to error message and log the connection to
>  https://ipa-replica.biszumbitterenen.de:8443/ca/ee/ca/profileSubmitSSLClient
>  fails, however there's no service listening on port 8443 on the replica server
> (192.168.100.201).
>  On the master server (192.168.100.200) port 8443 is accessible: 
So I assume there is no CA installed on this replica?

Can we see the current getcert output for the KDC cert?

rob

BTW your comments are coming in with zero context which makes more
difficult to see what has gone on before.

[74cmonty]

I was instructed to delete the existing cert before executing 
ipa-pkinit-manage enable.

And I have provided the output of getcert in an earlier response.
I was told that this cert is incomplete/incorrect.

[Rob Crittenden]

74cmonty via FreeIPA-users wrote:
>  I was instructed to delete the existing cert before executing 
>  ipa-pkinit-manage enable.
>  
>  And I have provided the output of getcert in an earlier response.
>  I was told that this cert is incomplete/incorrect. 
Again, no context :-(

Yes, I asked for the CURRENT tracking for it.

rob

[74cmonty]

Well, then I will repeat the context...

After completing FreeIPA master (vm200; 192.168.100.200) installation I started setup of
replica (vm201; 192.168.100.201).
This means I first enrolled the replica server as a client successfully and then executed
this command:
ipa-replica-install

The installation log reports this error:
Full PKINIT configuration did not succeed
The setup will only install bits essential to the server functionality
You can enable PKINIT after the setup completed using 'ipa-pkinit-manage'

Is this an error or normal behavior of replica installation?

This is the full installation output in the console:
Configuring certificate server (pki-tomcatd)
[1/2]: configure certmonger for renewals
[2/2]: Importing RA key
Done configuring certificate server (pki-tomcatd).
Configuring Kerberos KDC (krb5kdc)
[1/1]: installing X509 Certificate for PKINIT
Full PKINIT configuration did not succeed
The setup will only install bits essential to the server functionality
You can enable PKINIT after the setup completed using 'ipa-pkinit-manage'
Done configuring Kerberos KDC (krb5kdc).
Applying LDAP updates
Upgrading IPA:. Estimated time: 1 minute 30 seconds
[1/10]: stopping directory server
[2/10]: saving configuration
[3/10]: disabling listeners
[4/10]: enabling DS global lock
[5/10]: disabling Schema Compat
[6/10]: starting directory server
[7/10]: upgrading server
[8/10]: stopping directory server
[9/10]: restoring configuration
[10/10]: starting directory server
Done.
Finalize replication settings
Restarting the KDC

And this is the output of getcert list -f /var/kerberos/krb5kdc/kdc.crt:
[root@ipa-replica ~]# getcert list -f /var/kerberos/krb5kdc/kdc.crt
Number of certificates and requests being tracked: 4.
Request ID '20181206075804':
        status: MONITORING
        stuck: no
        key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
        certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
        CA: SelfSign
        issuer: CN=ipa-replica.biszumbitterenen.de,O=BISZUMBITTERENEN.DE
        subject: CN=ipa-replica.biszumbitterenen.de,O=BISZUMBITTERENEN.DE
        expires: 2019-12-06 08:58:04 CET
        principal name: krbtgt/BISZUMBITTERENEN.DE(a)BISZUMBITTERENEN.DE
        certificate template/profile: KDCs_PKINIT_Certs
        pre-save command:
        post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
        track: yes
        auto-renew: yes

[Florence Blanc-Renaud]

On 12/6/18 8:59 AM, 74cmonty via FreeIPA-users wrote:
>  Well, then I will repeat the context...
>  
>  After completing FreeIPA master (vm200; 192.168.100.200) installation I started setup of
> replica (vm201; 192.168.100.201).
>  This means I first enrolled the replica server as a client successfully and then executed
> this command:
>  ipa-replica-install
>  
>  The installation log reports this error:
>  Full PKINIT configuration did not succeed
>  The setup will only install bits essential to the server functionality
>  You can enable PKINIT after the setup completed using 'ipa-pkinit-manage'
>  
>  Is this an error or normal behavior of replica installation?
>   
Hi,

1. Error message during ipa-replica-install
it is an error that was tracked in pagure ticket 7655: PKINIT 
configuration fails while promoting a replica using IPA 4.7.0 [1]

In short, the replica is trying to contact itself in order to get a new 
KDC cert, while it should contact the master instead. The fix is 
delivered in IPA 4.7.1 and 4.7.2.
Without the fix, a KDC cert is installed but it is self-signed (issuer 
shows the replica name instead of IPA CA).

2. running ipa-pkinit-manage enable afterwards:
the command reports success but does not properly replace the 
self-signed KDC cert with a IPA-CA-signed KDC cert. This is tracked in 
pagure ticket 7200 ipa-pkinit-manage reports a switch from local pkinit 
to full pkinit configuration was successful although it was not. [2]

3. deletion of the KDC cert + re-run ipa-pkinit-manage:
Here you are seeing an error CA_UNREACHABLE, certificate issuance 
failed. This is the part that needs to be investigated.
In this step, the command ipa-pkinit-manage enable contacts certmonger 
in order to get a new cert. The error message shows connection to the 
replica itself, but certmonger should have contacted the master as the 
replica does not have any CA instance. I think this is a bug, as we can 
see in ipaserver/install/krbinstance.py:

             if use_dogtag_submit:
                 ca_args = [
                     paths.CERTMONGER_DOGTAG_SUBMIT,
                     '--ee-url', 'https://%s:8443/ca/ee/ca' % self.fqdn,
                     '--certfile', paths.RA_AGENT_PEM,
                     '--keyfile', paths.RA_AGENT_KEY,
                     '--cafile', paths.IPA_CA_CRT,
                     '--agent-submit'

The code is always connecting locally (self.fqdn) but it should check on 
which host the CA is deployed.
Could you please open an issue (https://pagure.io/freeipa/new_issue)? 
Thanks,
flo

[1] https://pagure.io/freeipa/issue/7655
[2] https://pagure.io/freeipa/issue/7200

>  This is the full installation output in the console:
>  Configuring certificate server (pki-tomcatd)
>  [1/2]: configure certmonger for renewals
>  [2/2]: Importing RA key
>  Done configuring certificate server (pki-tomcatd).
>  Configuring Kerberos KDC (krb5kdc)
>  [1/1]: installing X509 Certificate for PKINIT
>  Full PKINIT configuration did not succeed
>  The setup will only install bits essential to the server functionality
>  You can enable PKINIT after the setup completed using 'ipa-pkinit-manage'
>  Done configuring Kerberos KDC (krb5kdc).
>  Applying LDAP updates
>  Upgrading IPA:. Estimated time: 1 minute 30 seconds
>  [1/10]: stopping directory server
>  [2/10]: saving configuration
>  [3/10]: disabling listeners
>  [4/10]: enabling DS global lock
>  [5/10]: disabling Schema Compat
>  [6/10]: starting directory server
>  [7/10]: upgrading server
>  [8/10]: stopping directory server
>  [9/10]: restoring configuration
>  [10/10]: starting directory server
>  Done.
>  Finalize replication settings
>  Restarting the KDC
>  
>  And this is the output of getcert list -f /var/kerberos/krb5kdc/kdc.crt:
>  [root@ipa-replica ~]# getcert list -f /var/kerberos/krb5kdc/kdc.crt
>  Number of certificates and requests being tracked: 4.
>  Request ID '20181206075804':
>           status: MONITORING
>           stuck: no
>           key pair storage: type=FILE,location='/var/kerberos/krb5kdc/kdc.key'
>           certificate: type=FILE,location='/var/kerberos/krb5kdc/kdc.crt'
>           CA: SelfSign
>           issuer: CN=ipa-replica.biszumbitterenen.de,O=BISZUMBITTERENEN.DE
>           subject: CN=ipa-replica.biszumbitterenen.de,O=BISZUMBITTERENEN.DE
>           expires: 2019-12-06 08:58:04 CET
>           principal name: krbtgt/BISZUMBITTERENEN.DE(a)BISZUMBITTERENEN.DE
>           certificate template/profile: KDCs_PKINIT_Certs
>           pre-save command:
>           post-save command: /usr/libexec/ipa/certmonger/renew_kdc_cert
>           track: yes
>           auto-renew: yes
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>

[74cmonty]

Hi Florence,

thank you for this detailed analysis.
I fully support your conclusion.
Before you replied to this ticket I have already opened a bug report:
https://pagure.io/freeipa/issue/7795

Question:
Is there any workaround to temporarily fix this issue and complete the setup of replica
server?

THX

[Florence Blanc-Renaud]

On 12/6/18 1:26 PM, 74cmonty via FreeIPA-users wrote:
>  Hi Florence,
>  
>  thank you for this detailed analysis.
>  I fully support your conclusion.
>  Before you replied to this ticket I have already opened a bug report:
> https://pagure.io/freeipa/issue/7795
>  
>  Question:
>  Is there any workaround to temporarily fix this issue and complete the setup of replica
> server?
>   
The easiest is to also install a CA instance on the replica:
# ipa-ca-install
Moreover, it is better to have multiple hosts with a CA instance :)

Then repeat the steps removing the .crt and .key file, and 
ipa-pkinit-manage enable.

flo
>  THX
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>

[74cmonty]

Hello Flo,

I've decided to follow your advise.
This means I will install another CA instance on the replica server.

However I would prefer to upgrade FreeIPA to version 4.7.2 before.
Unfortunately I failed on this task.

I've executed ipa-server-upgrade and this process finished successfully after a few
minutes:
The IPA services were upgraded
The ipa-server-upgrade command was successful

Checking the installed packages revealed: no updated packages
[root@ipa-replica ~]# rpm -q freeipa-server freeipa-client ipa-server ipa-client
389-ds-base pki-ca krb5-server
freeipa-server-4.7.0-3.fc29.x86_64
freeipa-client-4.7.0-3.fc29.x86_64
Das Paket ipa-server ist nicht installiert
Das Paket ipa-client ist nicht installiert
389-ds-base-1.4.0.16-1.fc29.x86_64
pki-ca-10.6.6-2.fc29.noarch
krb5-server-1.16.1-21.fc29.x86_64

Then I tried command dnf update freeipa-server w/o success: nothing to do

What am I doing wrong here?

[Florence Blanc-Renaud]

On 12/7/18 6:33 PM, 74cmonty via FreeIPA-users wrote:
>  Hello Flo,
>  
>  I've decided to follow your advise.
>  This means I will install another CA instance on the replica server.
>  
>  However I would prefer to upgrade FreeIPA to version 4.7.2 before.
>  Unfortunately I failed on this task.
>  
>  I've executed ipa-server-upgrade and this process finished successfully after a few
> minutes:
>  The IPA services were upgraded
>  The ipa-server-upgrade command was successful
>  
>  Checking the installed packages revealed: no updated packages
>  [root@ipa-replica ~]# rpm -q freeipa-server freeipa-client ipa-server ipa-client
> 389-ds-base pki-ca krb5-server
>  freeipa-server-4.7.0-3.fc29.x86_64
>  freeipa-client-4.7.0-3.fc29.x86_64
>  Das Paket ipa-server ist nicht installiert
>  Das Paket ipa-client ist nicht installiert
>  389-ds-base-1.4.0.16-1.fc29.x86_64
>  pki-ca-10.6.6-2.fc29.noarch
>  krb5-server-1.16.1-21.fc29.x86_64
>  
>  Then I tried command dnf update freeipa-server w/o success: nothing to do
>  
>  What am I doing wrong here? 
Please see my answer in the other thread:
https://lists.fedorahosted.org/archives/list/[e-mail]...

HTH,
flo
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>

[74cmonty]

Hello Flo,
I successfully installed FreeIPA 4.7.2 packages on replica server:
```
[root@ipa-replica ~]# rpm -q freeipa-server freeipa-client ipa-server ipa-client 3        
                                                                             89-ds-base
pki-ca krb5-server
freeipa-server-4.7.2-1.fc29.x86_64
freeipa-client-4.7.2-1.fc29.x86_64
Das Paket ipa-server ist nicht installiert
Das Paket ipa-client ist nicht installiert
389-ds-base-1.4.0.16-1.fc29.x86_64
pki-ca-10.6.8-3.fc29.noarch
```
However, the upgrade is failing.
When I execute this command `ipa-server-upgrade` manually I get this error:
```
ipaserver.install.service: DEBUG:   [5/9]: starting directory server
  [5/9]: starting directory server
ipapython.ipautil: DEBUG: Starting external process
ipapython.ipautil: DEBUG: args=['/bin/systemctl', 'start',
'dirsrv@BISZUMBITTERENE                                                               
                      N-DE.service']
ipapython.ipautil: DEBUG: Process finished, return code=1
ipapython.ipautil: DEBUG: stdout=
ipapython.ipautil: DEBUG: stderr=Job for dirsrv(a)BISZUMBITTERENEN-DE.service failed        
                                                                              because the
control process exited with error code.
See "systemctl status dirsrv(a)BISZUMBITTERENEN-DE.service" and "journalctl
-xe" for                                                                             
         details.
```

So I checked log `/var/log/dirsrv/slapd-BISZUMBITTERENEN-DE/errors` and found this:
```
[root@ipa-replica ~]# tail -n 40 /var/log/dirsrv/slapd-BISZUMBITTERENEN-DE/errors
[11/Dec/2018:10:45:10.505923459 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=computers,cn=compat,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.515595444 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=ng,cn=compat,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.524433521 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
ou=sudoers,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.534653076 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=users,cn=compat,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.543444060 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.550404494 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.559231814 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.574312715 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.581500986 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.588207817 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.598901345 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.608874140 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.624449543 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.635198157 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.644514201 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.652438328 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=ad,cn=etc,dc=biszumbitterenen,dc=de does not exist
[11/Dec/2018:10:45:10.666047779 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=biszumbitterenen,dc=de does
not exist
[11/Dec/2018:10:45:10.676464447 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=biszumbitterenen,dc=de does
not exist
[11/Dec/2018:10:45:10.758108000 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=automember rebuild membership,cn=tasks,cn=config does not exist
[11/Dec/2018:10:45:10.768519636 +0100] - ERR - cos-plugin - cos_dn_defs_cb - Skipping CoS
Definition cn=Password Policy,cn=accounts,dc=biszumbitterenen,dc=de--no CoS Templates
found, which should be added before the CoS Definition.
[11/Dec/2018:10:45:10.807844822 +0100] - ERR - set_krb5_creds - Could not get initial
credentials for principal [ldap/ipa-replica.biszumbitterenen.de(a)BISZUMBITTERENEN.DE] in
keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested
realm)
[11/Dec/2018:10:45:10.822417907 +0100] - INFO - slapd_daemon - slapd started.  Listening
on /var/run/slapd-BISZUMBITTERENEN-DE.socket for LDAPI requests
[11/Dec/2018:10:45:10.991091930 +0100] - INFO - op_thread_cleanup - slapd shutting down -
signaling operation threads - op stack size 3 max work q size 2 max work q stack size 2
[11/Dec/2018:10:45:11.001531238 +0100] - INFO - slapd_daemon - slapd shutting down -
waiting for 2 threads to terminate
[11/Dec/2018:10:45:11.014214280 +0100] - INFO - slapd_daemon - slapd shutting down -
closing down internal subsystems and plugins
[11/Dec/2018:10:47:10.908408935 +0100] - ERR - NSMMReplicationPlugin - bind_and_check_pwp
- agmt="cn=meToipa-master.biszumbitterenen.de" (ipa-master:389) - Replication
bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) ()
[11/Dec/2018:10:47:11.147205700 +0100] - INFO - dblayer_pre_close - Waiting for 4 database
threads to stop
[11/Dec/2018:10:47:13.151397617 +0100] - INFO - dblayer_pre_close - All database threads
now stopped
[11/Dec/2018:10:47:13.174133191 +0100] - INFO - ldbm_back_instance_set_destructor - Set of
instances destroyed
[11/Dec/2018:10:47:13.182242796 +0100] - INFO - connection_post_shutdown_cleanup - slapd
shutting down - freed 2 work q stack objects - freed 3 op stack objects
[11/Dec/2018:10:47:13.193043173 +0100] - INFO - main - slapd stopped.
[11/Dec/2018:10:49:34.420307507 +0100] - ERR - init_schema_dse_ext - Could not add
attribute type "objectClass" to the schema: attribute type objectClass: Unknown
attribute syntax OID "1.3.6.1.4.1.1466.115.121.1.15"
[11/Dec/2018:10:49:34.436344560 +0100] - ERR - dse_read_one_file - The entry cn=schema in
file /usr/share/dirsrv/schema/00core.ldif (lineno: 1) is invalid, error code 21 (Invalid
syntax) - attribute type aci: Unknown attribute syntax OID
"1.3.6.1.4.1.1466.115.121.1.15"
[11/Dec/2018:10:49:34.443437573 +0100] - ERR - setup_internal_backends - Please edit the
file to correct the reported problems and then restart the server.
[11/Dec/2018:10:50:08.568553528 +0100] - ERR - init_schema_dse_ext - Could not add
attribute type "objectClass" to the schema: attribute type objectClass: Unknown
attribute syntax OID "1.3.6.1.4.1.1466.115.121.1.15"
[11/Dec/2018:10:50:08.580692294 +0100] - ERR - dse_read_one_file - The entry cn=schema in
file /usr/share/dirsrv/schema/00core.ldif (lineno: 1) is invalid, error code 21 (Invalid
syntax) - attribute type aci: Unknown attribute syntax OID
"1.3.6.1.4.1.1466.115.121.1.15"
[11/Dec/2018:10:50:08.588399834 +0100] - ERR - setup_internal_backends - Please edit the
file to correct the reported problems and then restart the server.
[11/Dec/2018:10:52:26.598725479 +0100] - ERR - init_schema_dse_ext - Could not add
attribute type "objectClass" to the schema: attribute type objectClass: Unknown
attribute syntax OID "1.3.6.1.4.1.1466.115.121.1.15"
[11/Dec/2018:10:52:26.610499920 +0100] - ERR - dse_read_one_file - The entry cn=schema in
file /usr/share/dirsrv/schema/00core.ldif (lineno: 1) is invalid, error code 21 (Invalid
syntax) - attribute type aci: Unknown attribute syntax OID
"1.3.6.1.4.1.1466.115.121.1.15"
[11/Dec/2018:10:52:26.618930090 +0100] - ERR - setup_internal_backends - Please edit the
file to correct the reported problems and then restart the server.
```

And this is the relevant content of file `/usr/share/dirsrv/schema/00core.ldif`:
```
attributeTypes: ( 2.16.840.1.113730.3.1.55 NAME 'aci'
  DESC 'Netscape defined access control information attribute type'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
  USAGE directoryOperation
  X-ORIGIN 'Netscape Directory Server' )
```

Comparing this content with `/usr/share/dirsrv/schema/00core.ldif` on master server
there's no difference.

I thought to restart deployment of replica server from scratch, but I cannot delete the
host ipa-replica in WebUI.

Any advise?

[Florence Blanc-Renaud]

On 12/11/18 11:23 AM, 74cmonty via FreeIPA-users wrote:
>  Hello Flo,
>  I successfully installed FreeIPA 4.7.2 packages on replica server:
>  ```
>  [root@ipa-replica ~]# rpm -q freeipa-server freeipa-client ipa-server ipa-client 3       
>                                                                               89-ds-base
> pki-ca krb5-server
>  freeipa-server-4.7.2-1.fc29.x86_64
>  freeipa-client-4.7.2-1.fc29.x86_64
>  Das Paket ipa-server ist nicht installiert
>  Das Paket ipa-client ist nicht installiert
>  389-ds-base-1.4.0.16-1.fc29.x86_64
>  pki-ca-10.6.8-3.fc29.noarch
>  ```
>  However, the upgrade is failing.
>  When I execute this command `ipa-server-upgrade` manually I get this error:
>  ```
>  ipaserver.install.service: DEBUG:   [5/9]: starting directory server
>     [5/9]: starting directory server
>  ipapython.ipautil: DEBUG: Starting external process
>  ipapython.ipautil: DEBUG: args=['/bin/systemctl', 'start',
> 'dirsrv@BISZUMBITTERENE                                                               
>                       N-DE.service']
>  ipapython.ipautil: DEBUG: Process finished, return code=1
>  ipapython.ipautil: DEBUG: stdout=
>  ipapython.ipautil: DEBUG: stderr=Job for dirsrv(a)BISZUMBITTERENEN-DE.service failed       
>                                                                                because the
> control process exited with error code.
>  See "systemctl status dirsrv(a)BISZUMBITTERENEN-DE.service" and "journalctl
> -xe" for                                                                             
>          details.
>  ```
>  
>  So I checked log `/var/log/dirsrv/slapd-BISZUMBITTERENEN-DE/errors` and found this:
>  ```
>  [root@ipa-replica ~]# tail -n 40 /var/log/dirsrv/slapd-BISZUMBITTERENEN-DE/errors
>  [11/Dec/2018:10:45:10.505923459 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=computers,cn=compat,dc=biszumbitterenen,dc=de does not exist
>  [11/Dec/2018:10:45:10.515595444 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=ng,cn=compat,dc=biszumbitterenen,dc=de does not exist
>  [11/Dec/2018:10:45:10.524433521 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> ou=sudoers,dc=biszumbitterenen,dc=de does not exist
>  [11/Dec/2018:10:45:10.534653076 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=users,cn=compat,dc=biszumbitterenen,dc=de does not exist
>  [11/Dec/2018:10:45:10.543444060 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
>  [11/Dec/2018:10:45:10.550404494 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
>  [11/Dec/2018:10:45:10.559231814 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
>  [11/Dec/2018:10:45:10.574312715 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
>  [11/Dec/2018:10:45:10.581500986 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
>  [11/Dec/2018:10:45:10.588207817 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
>  [11/Dec/2018:10:45:10.598901345 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
>  [11/Dec/2018:10:45:10.608874140 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
>  [11/Dec/2018:10:45:10.624449543 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
>  [11/Dec/2018:10:45:10.635198157 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
>  [11/Dec/2018:10:45:10.644514201 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=vaults,cn=kra,dc=biszumbitterenen,dc=de does not exist
>  [11/Dec/2018:10:45:10.652438328 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=ad,cn=etc,dc=biszumbitterenen,dc=de does not exist
>  [11/Dec/2018:10:45:10.666047779 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=biszumbitterenen,dc=de does
> not exist
>  [11/Dec/2018:10:45:10.676464447 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=biszumbitterenen,dc=de does
> not exist
>  [11/Dec/2018:10:45:10.758108000 +0100] - ERR - NSACLPlugin - acl_parse - The ACL target
> cn=automember rebuild membership,cn=tasks,cn=config does not exist
>  [11/Dec/2018:10:45:10.768519636 +0100] - ERR - cos-plugin - cos_dn_defs_cb - Skipping CoS
> Definition cn=Password Policy,cn=accounts,dc=biszumbitterenen,dc=de--no CoS Templates
> found, which should be added before the CoS Definition.
>  [11/Dec/2018:10:45:10.807844822 +0100] - ERR - set_krb5_creds - Could not get initial
> credentials for principal [ldap/ipa-replica.biszumbitterenen.de(a)BISZUMBITTERENEN.DE] in
> keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested
> realm)
>  [11/Dec/2018:10:45:10.822417907 +0100] - INFO - slapd_daemon - slapd started.  Listening
> on /var/run/slapd-BISZUMBITTERENEN-DE.socket for LDAPI requests
>  [11/Dec/2018:10:45:10.991091930 +0100] - INFO - op_thread_cleanup - slapd shutting down -
> signaling operation threads - op stack size 3 max work q size 2 max work q stack size 2
>  [11/Dec/2018:10:45:11.001531238 +0100] - INFO - slapd_daemon - slapd shutting down -
> waiting for 2 threads to terminate
>  [11/Dec/2018:10:45:11.014214280 +0100] - INFO - slapd_daemon - slapd shutting down -
> closing down internal subsystems and plugins
>  [11/Dec/2018:10:47:10.908408935 +0100] - ERR - NSMMReplicationPlugin - bind_and_check_pwp
> - agmt="cn=meToipa-master.biszumbitterenen.de" (ipa-master:389) - Replication
> bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) ()
>  [11/Dec/2018:10:47:11.147205700 +0100] - INFO - dblayer_pre_close - Waiting for 4
> database threads to stop
>  [11/Dec/2018:10:47:13.151397617 +0100] - INFO - dblayer_pre_close - All database threads
> now stopped
>  [11/Dec/2018:10:47:13.174133191 +0100] - INFO - ldbm_back_instance_set_destructor - Set
> of instances destroyed
>  [11/Dec/2018:10:47:13.182242796 +0100] - INFO - connection_post_shutdown_cleanup - slapd
> shutting down - freed 2 work q stack objects - freed 3 op stack objects
>  [11/Dec/2018:10:47:13.193043173 +0100] - INFO - main - slapd stopped.
>  [11/Dec/2018:10:49:34.420307507 +0100] - ERR - init_schema_dse_ext - Could not add
> attribute type "objectClass" to the schema: attribute type objectClass: Unknown
> attribute syntax OID "1.3.6.1.4.1.1466.115.121.1.15"
>  [11/Dec/2018:10:49:34.436344560 +0100] - ERR - dse_read_one_file - The entry cn=schema in
> file /usr/share/dirsrv/schema/00core.ldif (lineno: 1) is invalid, error code 21 (Invalid
> syntax) - attribute type aci: Unknown attribute syntax OID
> "1.3.6.1.4.1.1466.115.121.1.15"
>  [11/Dec/2018:10:49:34.443437573 +0100] - ERR - setup_internal_backends - Please edit the
> file to correct the reported problems and then restart the server.
>  [11/Dec/2018:10:50:08.568553528 +0100] - ERR - init_schema_dse_ext - Could not add
> attribute type "objectClass" to the schema: attribute type objectClass: Unknown
> attribute syntax OID "1.3.6.1.4.1.1466.115.121.1.15"
>  [11/Dec/2018:10:50:08.580692294 +0100] - ERR - dse_read_one_file - The entry cn=schema in
> file /usr/share/dirsrv/schema/00core.ldif (lineno: 1) is invalid, error code 21 (Invalid
> syntax) - attribute type aci: Unknown attribute syntax OID
> "1.3.6.1.4.1.1466.115.121.1.15"
>  [11/Dec/2018:10:50:08.588399834 +0100] - ERR - setup_internal_backends - Please edit the
> file to correct the reported problems and then restart the server.
>  [11/Dec/2018:10:52:26.598725479 +0100] - ERR - init_schema_dse_ext - Could not add
> attribute type "objectClass" to the schema: attribute type objectClass: Unknown
> attribute syntax OID "1.3.6.1.4.1.1466.115.121.1.15"
>  [11/Dec/2018:10:52:26.610499920 +0100] - ERR - dse_read_one_file - The entry cn=schema in
> file /usr/share/dirsrv/schema/00core.ldif (lineno: 1) is invalid, error code 21 (Invalid
> syntax) - attribute type aci: Unknown attribute syntax OID
> "1.3.6.1.4.1.1466.115.121.1.15"
>  [11/Dec/2018:10:52:26.618930090 +0100] - ERR - setup_internal_backends - Please edit the
> file to correct the reported problems and then restart the server.
>  ```
>  
>  And this is the relevant content of file `/usr/share/dirsrv/schema/00core.ldif`:
>  ```
>  attributeTypes: ( 2.16.840.1.113730.3.1.55 NAME 'aci'
>     DESC 'Netscape defined access control information attribute type'
>     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>     USAGE directoryOperation
>     X-ORIGIN 'Netscape Directory Server' )
>  ```
>  
>  Comparing this content with `/usr/share/dirsrv/schema/00core.ldif` on master server
> there's no difference.
>  
>  I thought to restart deployment of replica server from scratch, but I cannot delete the
> host ipa-replica in WebUI.Hi, 
what is the error you are seeing?

If the replica is not a single point of failure for any service (CA, 
DNS, replication to other master...) you can do the following:
(on replica) ipa-server-install --uninstall -U
(on master) ipa-replica-manage del <replica> --force --cleanup

then retry the replica installation.
flo
>  
>  Any advise?
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>

[74cmonty]

Hi Flo,

thanks for your reply.

I decided to start replica setup from scratch.
This means I executed this command on master: ipa-replica-manage del
ipa-replica.biszumbitterenen.de
Then I restored the replica server to a previous state, installed freeipa-packages 4.7.2
(and its dependencies).
Then I run this command on replica: ipa-server-install --uninstall

After this I was able to run this command ipa-client-install --mkhomedir successfully and
the replica server is listed in WebUI.

Now I consider to run this command on replica: ipa-replica-install --setup-ca --setup-dns
This would give me no single-point-of-failure for DNS and CA.
However the installed is asking me this:
ipa-replica-install: error: You must specify at least one of --forwarder,
--auto-forwarders, or --no-forwarders options

I had setup master with this command
ipa-server-install --setup-dns --allow-zone-overlap
because I'm still using the DNS of my domain provider.
To my (best) knowledge I have configured DNS forwarder on master.

Question:
Is it correct to configure a DNS forwarder on replica, too?
If yes, how can I verify what have been entered on master?

THX

[Florence Blanc-Renaud]

On 12/11/18 12:59 PM, 74cmonty via FreeIPA-users wrote:
>  Hi Flo,
>  
>  thanks for your reply.
>  
>  I decided to start replica setup from scratch.
>  This means I executed this command on master: ipa-replica-manage del
> ipa-replica.biszumbitterenen.de
>  Then I restored the replica server to a previous state, installed freeipa-packages 4.7.2
> (and its dependencies).
>  Then I run this command on replica: ipa-server-install --uninstall
>  
>  After this I was able to run this command ipa-client-install --mkhomedir successfully and
> the replica server is listed in WebUI.
>  
>  Now I consider to run this command on replica: ipa-replica-install --setup-ca
> --setup-dns
>  This would give me no single-point-of-failure for DNS and CA.
>  However the installed is asking me this:
>  ipa-replica-install: error: You must specify at least one of --forwarder,
> --auto-forwarders, or --no-forwarders options
>  
>  I had setup master with this command
>  ipa-server-install --setup-dns --allow-zone-overlap
>  because I'm still using the DNS of my domain provider.
>  To my (best) knowledge I have configured DNS forwarder on master.
>  
>  Question:
>  Is it correct to configure a DNS forwarder on replica, too?
>  If yes, how can I verify what have been entered on master?
>   
Yes, you can configure a DNS forwarder on the replica, too.
In order to find the settings on the master, you can use
# ipa dnsserver-show $master
It will print the forwarder.

If you want to specify the same one on the replica, use 
--forwarder=<forwarder>. You can also let the installer find which 
forwarder to use with --auto-forwarder (it will read the content of 
/etc/resolv.conf and propose this DNS server as forwarder).

HTH,
flo
>  THX
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>

[74cmonty]

Hi Flo,

I have defined the IP of my router as DNS:
[root@ipa-master ~]# ipa dnsserver-show
Servername: ipa-master.biszumbitterenen.de
  Servername: ipa-master.biszumbitterenen.de
  SOA mname override: ipa-master.biszumbitterenen.de.
  Forwarders: 192.168.100.1
  Forward policy: only

The same IP is maintained in /etc/resolv.conf:
[root@ipa-master ~]# more /etc/resolv.conf
# Generated by NetworkManager
search biszumbitterenen.de
nameserver 192.168.100.1

On replica server the same settings apply in /etc/resolv.conf:
[root@ipa-replica ~]# more /etc/resolv.conf
# Generated by NetworkManager
search biszumbitterenen.de
nameserver 192.168.100.1

Now I start this command to setup replica server:
[root@ipa-replica ~]# ipa-replica-install --setup-ca --setup-dns --auto-forwarder
Password for admin(a)BISZUMBITTERENEN.DE:
Reverse DNS resolution of address 192.168.100.201 (ipa-replica.biszumbitterenen.de)
failed. Clients may not function properly. Please check your DNS setup. (Note that this
check queries IPA DNS directly and ignores /etc/hosts.)
Continue? [no]:
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more
information

How can I analyse the root cause for the reverse DNS resolution?
I assume this function should be provided by master, right? My router won't support
reverse DNS resolution.
And is this required for the setup of replica server?
Or is the configuration wrong with router as DNS server?

[74cmonty]

In my opinion this issue is related to this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1493531

Based on this I would consider to open another bug report.