Find, verify and configure all IP addresses that can be used to reach the server
FreeIPA is being installed on. Ignore some IP address only if user specifies
subset of detected addresses using --ip-address option.
This change simplyfies FreeIPA installation on multihomed and dual-stacked servers.
https://fedorahosted.org/freeipa/ticket/3575
Reviewed-By: Martin Basti <mbasti@redhat.com>
Sytem users and their groups are always created together.
Also, users & groups should never be removed once they exist
on the system (see comit a5a55ce).
Use a single function for generic user creation, and specific
funtions in dsinstance and cainstance.
Remove code left over from when we used to delete the DS user.
Preparation for: https://fedorahosted.org/freeipa/ticket/3866
Reviewed-By: Tomas Babej <tbabej@redhat.com>
We don't want to copy the extension from master to replica because the
replica may use newer version of FreeIPA and therefore the extension
code might be obsolete. Same reason for upgrades.
https://fedorahosted.org/freeipa/ticket/4478
Reviewed-By: Endi Sukma Dewata <edewata@redhat.com>
This patch adds the capability of installing a Dogtag KRA
to an IPA instance. With this patch, a KRA is NOT configured
by default when ipa-server-install is run. Rather, the command
ipa-kra-install must be executed on an instance on which a Dogtag
CA has already been configured.
The KRA shares the same tomcat instance and DS instance as the
Dogtag CA. Moreover, the same admin user/agent (and agent cert) can
be used for both subsystems. Certmonger is also confgured to
monitor the new subsystem certificates.
To create a clone KRA, simply execute ipa-kra-install <replica_file>
on a replica on which a Dogtag CA has already been replicated.
ipa-kra-install will use the security domain to detect whether the
system being installed is a replica, and will error out if a needed
replica file is not provided.
The install scripts have been refactored somewhat to minimize
duplication of code. A new base class dogtagintance.py has
been introduced containing code that is common to KRA and CA
installs. This will become very useful when we add more PKI
subsystems.
The KRA will install its database as a subtree of o=ipaca,
specifically o=ipakra,o=ipaca. This means that replication
agreements created to replicate CA data will also replicate KRA
data. No new replication agreements are required.
Added dogtag plugin for KRA. This is an initial commit providing
the basic vault functionality needed for vault. This plugin will
likely be modified as we create the code to call some of these
functions.
Part of the work for: https://fedorahosted.org/freeipa/ticket/3872
The uninstallation option in ipa-kra-install is temporarily disabled.
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Petr Viktorin <pviktori@redhat.com>
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>
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
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 patch makes sure that all edits to CS.cfg configuration file
are performed while pki-tomcatd service is stopped.
Introduces a new contextmanager stopped_service for handling
a general problem of performing a task that needs certain service
being stopped.
https://fedorahosted.org/freeipa/ticket/3804
Adds a new simple service called OtpdInstance, that manages
ipa-otpd.socket service. Added to server/replica installer
and ipa-upgradeconfig script.
https://fedorahosted.org/freeipa/ticket/3680
All installers that handle Kerberos auth, have been altered to use
private ccache, that is ipa-server-install, ipa-dns-install,
ipa-replica-install, ipa-ca-install.
https://fedorahosted.org/freeipa/ticket/3666
Since we depend on Dogtag 10 now, there is no need to keep code
that installs a Dogtag 9 CA.
Support for upgraded Dogtag-9-style instances is left in.
https://fedorahosted.org/freeipa/ticket/3529
The ipa-replica-install script tries to add replica's A and PTR
records to the master DNS, if master does manage DNS. However,
master need not manage replica's zone. Properly handle this use
case.
https://fedorahosted.org/freeipa/ticket/3496
The CA cert was not loaded, so if it was missing from the PKCS#12 file,
installation would fail.
Pass the cert filename to the server installers and include it in
the NSS DB.
Part of the work for: https://fedorahosted.org/freeipa/ticket/3363
The unbind and unbind_s functions do the same thing (both are synchronous).
In the low-level IPASimpleLDAPObject, unbind_s rather than unbind is kept.
Part of the work for: https://fedorahosted.org/freeipa/ticket/2660
Fedora 16 introduced chrony as default client time&date synchronization
service:
http://fedoraproject.org/wiki/Features/ChronyDefaultNTP
Thus, there may be people already using chrony as their time and date
synchronization service before installing IPA.
However, installing IPA server or client on such machine may lead to
unexpected behavior, as the IPA installer would configure ntpd and leave
the machine with both ntpd and chronyd enabled. However, since the OS
does not allow both chronyd and ntpd to be running concurrently and chronyd
has the precedence, ntpd would not be run on that system at all.
Make sure, that user is warned when trying to install IPA on such
system and is given a possibility to either not to let IPA configure
ntpd at all or to let the installer stop and disable chronyd.
https://fedorahosted.org/freeipa/ticket/2974
Modify the default IPA CA certificate profile to include CRL and
OCSP extensions which will add URIs to IPA CRL&OCSP to published
certificates.
Both CRL and OCSP extensions have 2 URIs, one pointing directly to
the IPA CA which published the certificate and one to a new CNAME
ipa-ca.$DOMAIN which was introduced as a general CNAME pointing
to all IPA replicas which have CA configured.
The new CNAME is added either during new IPA server/replica/CA
installation or during upgrade.
https://fedorahosted.org/freeipa/ticket/3074https://fedorahosted.org/freeipa/ticket/1431
The new merged database will replicate with both the IPA and CA trees, so all
DS instances (IPA and CA on the existing master, and the merged one on the
replica) need to have the same schema.
Dogtag does all its schema modifications online. Those are replicated normally.
The basic IPA schema, however, is delivered in ldif files, which are not
replicated. The files are not present on old CA DS instances. Any schema
update that references objects in these files will fail.
The whole 99user.ldif (i.e. changes introduced dynamically over LDAP) is
replicated as a blob. If we updated the old master's CA schema dynamically
during replica install, it would conflict with updates done during the
installation: the one with the lower CSN would get lost.
Dogtag's spawn script recently grew a new flag, 'pki_clone_replicate_schema'.
Turning it off tells Dogtag to create its schema in the clone, where the IPA
modifications are taking place, so that it is not overwritten by the IPA schema
on replication.
The patch solves the problems by:
- In __spawn_instance, turning off the pki_clone_replicate_schema flag.
- Providing a script to copy the IPA schema files to the CA DS instance.
The script needs to be copied to old masters and run there.
- At replica CA install, checking if the schema is updated, and failing if not.
The --skip-schema-check option is added to ipa-{replica,ca}-install to
override the check.
All pre-3.1 CA servers in a domain will have to have the script run on them to
avoid schema replication errors.
https://fedorahosted.org/freeipa/ticket/3213
New servers that are installed with dogtag 10 instances will use
a single database instance for dogtag and IPA, albeit with different
suffixes. Dogtag will communicate with the instance through a
database user with permissions to modify the dogtag suffix only.
This user will authenticate using client auth using the subsystem cert
for the instance.
This patch includes changes to allow the creation of masters and clones
with single ds instances.
Previously, ipa-replica-install tried to check DNS resolution on the master
being cloned. If that master was not a DNS server, the check failed.
Change the check to query the first available configured DNS server.
Log about the check before actually running it.
Log in the case the check is skipped (no IPA DNS servers installed).
https://fedorahosted.org/freeipa/ticket/3194
Add uninstall command to the uninstall instructions in the "already
installed" responses of ipa-server-install, ipa-client-install and
ipa-replica-install.
https://fedorahosted.org/freeipa/ticket/3065
This patch is adding a build of kerberosauth.xpi (FF Kerberos authentication extension).
Currently the build is done in install phase of FreeIPA server. It is to allow signing of the extension by singing certificate. The signing might not be necessary because the only outcome is that in extension installation FF doesn't show that the maker is not verified. It shows text: 'Object signing cert'. This might be a bug in httpinstance.py:262(db.create_signing_cert("Signing-Cert", "Object Signing Cert", ca_db)) The value is in place of hostname parameter.
If the extension is not signed, it can be created in rpm build phase, which should make upgrades easier. Current implementation doesn't handle upgrades yet.
In order to keep extension and config pages not dependent on a realm, a krb.js.teplate file was created. This template is used for creating a /usr/share/ipa/html/krb.js file in install phase which holds FreeIPA's realm and domain information. This information can be then used by config pages by importing this file.
Ticket: https://fedorahosted.org/freeipa/ticket/3094
Forward and reverse resolution of the newly created replica is already
checked via get_host_name (which calls verify_fqdn).
Add the same check for the existing master.
Additionally, if DNS is installed on the remote host, check forward
and reverse resolution of both replicas using that DNS only
(ignoring /etc/hosts). These checks give only warnings and, in interactive
installs, a "Continue?" prompt.
https://fedorahosted.org/freeipa/ticket/2845
When a new reverse zone is to be generated based on an IP address without
a network prefix length, we need to use some default value. While netaddr
library default ones (32b for IPv4 and 128b for IPv6) are not very sensible
we should use the defaults already applied in installers. That is 24b for
IPv6 and 64 for IPv6.
Test case has been added to cover the new default.
https://fedorahosted.org/freeipa/ticket/2461
Martin Basti
Jan Cholasta
David Kupka
Petr Viktorin
Petr Vobornik
Ade Lee
Tomas Babej
Martin Kosek
Xiao-Long Chen
Ana Krivokapic
Nikolai Kondrashov