Add the IPA version, and vendor version if applicable, to the beginning
of admintool logs -- both framework and indivitual tools that don't yet
use the framework.
This will make debugging easier.

https://fedorahosted.org/freeipa/ticket/4219

Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>

Reviewed-By: Petr Viktorin <pviktori@redhat.com>

When Dogtag 10 based FreeIPA replica is being installed for a Dogtag 9
based master, the PKI database is not updated and miss several ACLs
which prevent some of the PKI functions, e.g. an ability to create
other clones.

Add an update file to do the database update. Content is based on
recommendation from PKI team:
   * https://bugzilla.redhat.com/show_bug.cgi?id=1075118#c9

This update file can be removed when Dogtag database upgrades are done
in PKI component. Upstream tickets:
   * https://fedorahosted.org/pki/ticket/710 (database upgrade framework)
   * https://fedorahosted.org/pki/ticket/906 (checking database version)

Also make sure that PKI service is restarted in the end of the installation
as the other services to make sure it picks changes done during LDAP
updates.

https://fedorahosted.org/freeipa/ticket/4243

Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Petr Viktorin <pviktori@redhat.com>

When creating replica from a Dogtag 9 based IPA server, the port 7389
which is required for the installation is never checked by
ipa-replica-conncheck even though it knows that it is being installed
from the Dogtag 9 based FreeIPA. If the 7389 port would be blocked by
firewall, installation would stuck with no hint to user.

Make sure that the port configuration parsed from replica info file
is used consistently in the installers.

https://fedorahosted.org/freeipa/ticket/4240

Reviewed-By: Petr Viktorin <pviktori@redhat.com>

The checks for existing host and existing replication agreement
set a flag that caused an exit() if any of them failed.

Between these checks there was an unrelated check, DNS resolution.
If the host and DNS checks both failed, this made it look like
the DNS check was the cause of failed install. Especially if the user
ignored the DNS check in unattended mode, the output was confusing.

Remove the flag and fail directly.
Do the replication agreement check first; fixing this with
ipa-replica-manage del will also remove the host entry.

Also, use the logger for error messages so they appear in the log
file as well as on the console.

https://fedorahosted.org/freeipa/ticket/3889

Part of the effort to port FreeIPA to Arch Linux,
where Python 3 is the default.

FreeIPA hasn't been ported to Python 3, so the code must be modified to
run /usr/bin/python2

https://fedorahosted.org/freeipa/ticket/3438

Updated by pviktori@redhat.com

https://fedorahosted.org/freeipa/ticket/3975

Since mod_nss-1.0.8-24, mod_nss and mod_ssl can co-exist on one
machine (of course, when listening to different ports).

To make sure that mod_ssl is not configured to listen on 443
(default mod_ssl configuration), add a check to the installer checking
of either mod_nss or mod_ssl was configured to listen on that port.

https://fedorahosted.org/freeipa/ticket/3974

This works around pk12util refusing to use empty password files, which prevents
the use of PKCS#12 files with empty password.

https://fedorahosted.org/freeipa/ticket/3897

ipa-restore would fail if DS user did not exist. Check for presence of DS
user and group and create them if needed.

https://fedorahosted.org/freeipa/ticket/3856