We need to ask the user for a password and connect to the ldap so the
bind uninstallation procedure can remove old records. This is of course
only helpful if one has more than one IPA server configured.
- cache all interactive answers
- set non-interactive to True for the second run so nothing is asked
- convert boolean values that are read in
- require absolute paths for the external CA and signed cert files
- fix the invocation message for the second ipa-server-install run
This creates a new role, replicaadmin, so a non-DM user can do
limited management of replication agreements.
Note that with cn=config if an unauthorized user performs a search
an error is not returned, no entries are returned. This makes it
difficult to determine if there are simply no replication agreements or
we aren't allowed to see them. Once the ipaldap.py module gets
replaced by ldap2 we can use Get Effective Rights to easily tell the
difference.
There are now 3 cases:
- Install a dogtag CA and issue server certs using that
- Install a selfsign CA and issue server certs using that
- Install using either dogtag or selfsign and use the provided PKCS#12 files
for the server certs. The installed CA will still be used by the cert
plugin to issue any server certs.
Also get rid of functions get_host_name(), get_realm_name() and
get_domain_name(). They used the old ipapython.config. Instead, use the
variables from api.env. We also change them to bootstrap() and
finalize() correctly.
Additionally, we add the dns_container_exists() function that will be
used in ipa-replica-prepare (next patch).
Remove a bunch of trailing spaces
Add the --ca option
Add the --no-host-dns option
Add the --subject option
Fix the one-character option for --no-ntp, should be -N not -n
Add missing line break between --no-ntp and --uninstall
Resolves#545260
Let the user, upon installation, set the certificate subject base
for the dogtag CA. Certificate requests will automatically be given
this subject base, regardless of what is in the CSR.
The selfsign plugin does not currently support this dynamic name
re-assignment and will reject any incoming requests that don't
conform to the subject base.
The certificate subject base is stored in cn=ipaconfig but it does
NOT dynamically update the configuration, for dogtag at least. The
file /var/lib/pki-ca/profiles/ca/caIPAserviceCert.cfg would need to
be updated and pki-cad restarted.
We use kadmin.local to bootstrap the creation of the kerberos principals
for the IPA server machine: host, HTTP and ldap. This works fine and has
the side-effect of protecting the services from modification by an
admin (which would likely break the server).
Unfortunately this also means that the services can't be managed by useful
utilities such as certmonger. So we have to create them as "real" services
instead.
If a replica is not up for some reason (e.g. you've already deleted it)
this used to quit and not let you delete the replica, generating errors in
the DS logs. This will let you force a deletion.
The new framework uses default.conf instead of ipa.conf. This is useful
also because Apache uses a configuration file named ipa.conf.
This wipes out the last vestiges of the old ipa.conf from v1.
The pyOpenSSL PKCS#10 parser doesn't support attributes so we can't identify
requests with subject alt names.
Subject alt names are only allowed if:
- the host for the alt name exists in IPA
- if binding as host principal, the host is in the services managedBy attr
The CA was moved from residing in the DS NSS database into the Apache
database to support a self-signed CA certificate plugin. This was not
updated in the installer boilerplate.
The DS db wasn't getting a password set on it. Go ahead and set one.
Installing a CA that is signed by another CA is a 2-step process. The first
step is to generate a CSR for the CA and the second step is to install
the certificate issued by the external CA. To avoid asking questions
over and over (and potentially getting different answers) the answers
are cached.
This also removes the Index option of /ipa-assets as well as the
deprecated IPADebug option.
No need to build or install ipa_webgui anymore. Leaving in the code
for reference purposes for now.
External CA signing is a 2-step process. You first have to run the IPA
installer which will generate a CSR. You pass this CSR to your external
CA and get back a cert. You then pass this cert and the CA cert and
re-run the installer. The CSR is always written to /root/ipa.csr.
A run would look like:
# ipa-server-install --ca --external-ca -p password -a password -r EXAMPLE.COM -u dirsrv -n example.com --hostname=ipa.example.com -U
[ sign cert request ]
# ipa-server-install --ca --external-ca -p password -a password --external_cert_file=/tmp/rob.crt --external_ca_file=/tmp/cacert.crt -U -p password -a password -r EXAMPLE.COM -u dirsrv -n example.com --hostname=ipa.example.com
This also abstracts out the RA backend plugin so the self-signed CA we
create can be used in a running server. This means that the cert plugin
can request certs (and nothing else). This should let us do online replica
creation.
To handle the self-signed CA the simple ca_serialno file now contains
additional data so we don't have overlapping serial numbers in replicas.
This isn't used yet. Currently the cert plugin will not work on self-signed
replicas.
One very important change for self-signed CAs is that the CA is no longer
held in the DS database. It is now in the Apache database.
Lots of general fixes were also made in ipaserver.install.certs including:
- better handling when multiple CA certificates are in a single file
- A temporary directory for request certs is not always created when the
class is instantiated (you have to call setup_cert_request())
If the DNS zones already exist but don't contain our own records, add
them. This patch introduces the ipalib.api into the installers. For now,
the code is still little messy. Later patches will abandon the way we
create zones now and use ipalib.api exclusively.
BIND starting before we apply LDAP updates and restart kdc and directory
server causes trouble. We resolve this for now by postponing BIND setup
to the end of installation. Another reason is that we will be using
xml-rpc during the setup in the future.
This patch adds options --forwarder and --no-forwarders. At least one of
them must be used if you are doing a setup with DNS server. They are
also mutually exclusive. The --forwarder option can be used more than
once to specify more servers. If the installer runs in interactive mode,
it will prompt the user if none of these option was given at the command
line.
This also adds a new option to the template system. If you include
eval(string) in a file that goes through the templater then the
string in the eval will be evaluated by the Python interpreter. This is
used so one can do $UIDSTART+1. If any errors occur during the evaluation
the original string is is returned, eval() and all so it is up to the
developer to make sure the evaluation passes.
The default value for uid and gid is now a random value between
1,000,000 and (2^31 - 1,000,000)
