During development of a fix to workaround certmonger effectivly
hanging server uninstallation the test was re-worked to force
uninstall during the test execution itself.
https://pagure.io/freeipa/issue/8506
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Some certificates may have started renewal so returning to
present time can bind the server up with trying to renew.
certmonger fires off helpers when it's time to renew
certificates. This scenario puts the time within the renewal
window. If certmonger notices while the test is running it
will kick off renewal for all 12 certificates.
A lock is used to serialize things. The CA was shut down prior
to changing time so there is no chance of issuing new certs.
A fixture was used to ensure that things restarted when
the test was over. This was for chronyd and the CA. By restarting
the CA we allow the chance that it will be able to do some
work, versus returning a connection error and letting
certmonger just error out (CA_UNREACHABLE).
During uninstallation we call certmonger remove_request over
DBus (the equivalent to stop-tracking). As part of this
certmonger waits for any child (helper) processes to go away.
This used to do it via SIGKILL but that caused other problems
so it was changed to waitpid(). We know that it isn't going to
return for a while because the CA isn't up. DBus has a
hardcoded 25 second timeout. So we're guaranteed to get a
DBus timeout. We *could* try to play with it and change the
timeout, or retry a bunch of times, but it isn't worth the
hassle.
This is a contrived scenario that uninstalls immediately after
tweaking time forward. So rather than trying to make this
succesful, uninstall at the future time with the CA stopped
so that helpers won't be hanging around and certmonger can
remove the certs.
This is the last test so also the last time we need the replica
so to avoid replication bogging things down remove that prior
to executing the test. It's one less moving part during the
uninstall phase.
https://pagure.io/freeipa/issue/8506
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
There may be both IPv4 and IPv6 AJP connectors. Test that both
are upgraded with the new tomcat attribute and the passwords are
kept in sync.
The Apache password will be updated if needed elsewhere in the
upgrade process.
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
This is needed so we can mock the DogtagInstance class
and have control over the version of tomcat.
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The output from pki-spawn is already displayed to the user
as well as a short traceback so re-displaying the CalledProcess
error provides no value and only provokes confusion,
particularly because it is condensed and includes embedded
newlines.
Re-raise the exception from None so that the traceback is
removed and while there is still an immense traceback from
the admintool class it is significantly shorter than before
and removes:
"During handling of the above exception, another exception occurred"
The handling is in fact expected.
This changes the user-facing installer output from:
[1/28]: configuring certificate server instance
Failed to configure CA instance: CalledProcessError(Command ['/usr/sbin/pkispawn', '-s', 'CA', '-f', '/tmp/tmpr5x2l0gm', '--debug'] returned non-zero exit status 1: 'INFO: Connecting to LDAP server at ldap://ipa.example.test:389\nINFO: Connecting to LDAP server at ldap://ipa.example.test:389\nDEBUG: Installing Maven dependencies: False\nERROR: KeyError: \'CA\'\n File "/usr/lib/python3.9/site-packages/pki/server/pkispawn.py", line 575, in main\n raise KeyError(\'CA\')\n\n')
See the installation logs and the following files/directories for more information:
/var/log/pki/pki-tomcat
[error] RuntimeError: CA configuration failed.
CA configuration failed.
The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information
to
[1/28]: configuring certificate server instance
Failed to configure CA instance
See the installation logs and the following files/directories for more information:
/var/log/pki/pki-tomcat
[error] RuntimeError: CA configuration failed.
CA configuration failed.
The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information
The output is similarly reduced in the installer log. There is no
reason to acknowledge that a CalledProcessError was raised since
the output is already available and it's just an intermediary.
Hopefully this will encourage users to focus on the logs rather than
the malformed traceback.
https://pagure.io/freeipa/issue/8565
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
If the CA fails to deploy then the CRL directory will not exist
but will report an error that it has failed to be removed.
There is no need to try to navigate a directory if it doesn't exist.
Related: https://pagure.io/freeipa/issue/8565
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
This file was missed in the first pass to remove support for
csrgen.
This was never feature complete and currently has issues and
we lack the resources to maintain it.
Drop it for now. It can be revived from git history in the
future if we see the need.
https://pagure.io/freeipa/issue/8669
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
If the Apache, 389-ds or KDC certificate was issued by
a third party there is nothing we can do, regardless of
whether it is expired or not.
Report which certificates will not be renewed so the
admin can manually do do (likely in the event of a
third-party certificate).
https://pagure.io/freeipa/issue/8600
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The nickname of the 389-ds certificate was hardcoded as
Server-Cert which failed if the user had installed a
third-party certificate using ipa-server-certinstall.
Instead pull the nickname from the DS configuration and
retrieve it based on that.
https://pagure.io/freeipa/issue/8600
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
ACME uses nonce values to prevent replay attacks. Since the
ipa-ca name can go to any of the IPA servers in order to verify the
nonce the servers need to know the value that was set which
relies on replication. Sometimes the client is faster than
replication so a request can fail.
This change returns the baseURL to the client as the name of the
ACME server during discovery which should pin all requests to this
one IPA server and alleviate the replication issue.
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
https://pagure.io/freeipa/issue/8712
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
The UI in RHEL has a different set of logos and different
background colors. Some direct adjustments were made that
are not buildable so apply them as a patch.
https://pagure.io/freeipa/issue/8669
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The KRA attempts to unregister itself from the security domain
which requires that IPA be running for this to succeed.
1. Move the KRA uninstall call prior to stopping all IPA
services
2. Try to start IPA if it isn't running and a KRA is configured
It isn't mandatory that IPA be running for the KRA uninstall to
succeed but it will suppress a pretty scary backtrace and error
message.
https://pagure.io/freeipa/issue/8550
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
This is an informational message and clutters the installation
screen with no end-user benefit. Logging it as debug is
sufficient to know what is going on.
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The string was updated to include the directory the for the database
but this was not reflected in the test and not picked up because
the tests were executed on Fedora 32 which supports dbm so the
test wasn't executed.
https://pagure.io/freeipa/issue/8675
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
If NSSDatabase() throws a ValueError it means we can't open it
to look for an existing ipaCert to migrate. Chances are there is
no certificate to migrate at this point in Fedora so don't let
it blow up the entire installation/upgrade. Warn the user and let
them figure it out.
We have no real path forward on this and by proceeding it could
lead to more errors (like no RA) but it is extremely unlikely and
would require a user to upgrade from very old Fedora to very
new Fedora in one step.
https://pagure.io/freeipa/issue/8675
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Stanislav Levin <slev@altlinux.org>
If the system lacks DBM support and an older database is
opened then an exception is raised. Include the directory in
the exception so it is clearer which database cannot be opened.
https://pagure.io/freeipa/issue/8675
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Stanislav Levin <slev@altlinux.org>
This was never feature complete and currently has issues and
we lack the resources to maintain it.
Drop it for now. It can be revived from git history in the
future if we see the need.
https://pagure.io/freeipa/issue/8669
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
In order to simplify the build process between upstream FreeIPA
and downstream builds (such as CentOS Stream) we are changing
some file references from FreeIPA to IPA (and Identity Management).
https://pagure.io/freeipa/issue/8669
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The return value of functions managing the cursor in the keytab
were not checked or reported in a consistent way. This should
assure a reasonable error message in case something goes wrong.
https://pagure.io/freeipa/issue/8658
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
This makes it clearer what the return value means.
Replace closing of keytab based on the numeric return value
and do it based on whether the keytab was opened at all.
https://pagure.io/freeipa/issue/8658
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
This reverts commit 81c97bb992.
This is to make IPA installable again with older versions of dogtag
so it will install on CentOS 8 Stream.
ACME will not be deployed but on upgrade, if pki 10.10.x is available
then it will be.
https://pagure.io/freeipa/issue/8634
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
It is already confirmed that item_data is not NULL so there
is no need to check it again.
Discovered by coverity.
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Robbie Harwood <rharwood@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
ipadb_get_principal() allocates client_actual. Call
ipadb_free_principal to release it.
Rather than spreading the free() amongst the code introduce
done as a target to match behavior in similar functions.
Discovered by coverity.
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Robbie Harwood <rharwood@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The purpose is to set a default if the RID doesn't match
expectations.
Discovered by coverity
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Robbie Harwood <rharwood@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Per the ssh_config(5) man page under ProxyCommand:
"The command string extends to the end of the line, and is
executed using the user's shell ‘exec’ directive to avoid a
lingering shell process."
<shell> -c <proxy command>
Some older versions of nologin (RHEL/CentOS) do not support
the -c option so will still fail but since nologin doesn't
actually execute properly it doesn't include the output
'This account is currently not available' so don't assert
in that case. The returncode of 1 is sufficient to know
that the login is denied.
https://pagure.io/freeipa/issue/7676
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
On a failed permission update if the generated ACI is
invalid then the updated permission is rolled back.
Add the virtual relationship attributes to list of attributes
to be ignored when rolling back the entry.
This relies on the current order in the LDAPObject
relationships field where member and memberof are the first
two values.
https://pagure.io/freeipa/issue/8646
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Upstream dnspython 2.1.0 introduced additional error checking
on SRV values and now rejects invalid priorities.
Remove the sorting test for priority of -1.
https://pagure.io/freeipa/issue/8650
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The CA tracking request was modified to drop the profile which
was caught by ipa-healthcheck. Run ipa-certupdate then
ipa-healthcheck to confirm that no problems are introduced.
https://pagure.io/freeipa/issue/8644
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The CA tracking request is modified (it calls renew but it doesn't
actually do a renewal) as part of ipa-certupdate and it dropped
the profile. ipa-healthcheck discovered this condition.
https://pagure.io/freeipa/issue/8644
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
mod_md requires its own SELinux policy which is only available
in the upstream github. It is beyond the scope of this test to
maintain SELinux policy only for the scenario so skip it
if the client is in enforcing.
Note that no check needs to be done on OS because that is
already handled by the outer skipif for skip_mod_md_tests.
https://pagure.io/freeipa/issue/8514
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The associated service doesn't need to be enabled. Enabling the
timer is suffient for it to execute. It requires the timers
service so will be ready automatically to run on the configured
period.
https://pagure.io/freeipa/issue/8589
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
- Force wipe all existing ccaches
- Set the ticket policy to a short value, 30 seconds.
- Do a series of kinit, ipa command, kdestroy to generate ccaches
- sleep(30)
- Run the sweeper
- Verify that all ccaches are gone
https://pagure.io/freeipa/issue/8589
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
Rather than having a shared ccache per user, configure
mod_auth_gssapi to create a unique one. This requires cleanup
to remove expired caches. A new script is added,
ipa-ccache-sweeper to do this. It will be invoked by a
new service, ipa-ccache-sweep, which will be executed every
12 hours by an equally-named timer.
https://pagure.io/freeipa/issue/8589
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
There is still some exposure to killing in a bad place. This was
reproduced by killing the process in the parser.parse() call within
__restore_config (line 230) so the values were restored from the
backup but the new dse.ldif never written or copied. But the values
had already been restored from the state file.
I'm not sure this can ever be 100% bullet-proof since it can be
externally killed but if rather than calling restore_state() on the
values in __restore_config we use get_state() which will peek at the
values in the state file without removing them. Then the last step
is to pop upgrade-in-progress and then the rest.
If the values have been restored and the new ldif written and copied
then it's only upgrade-in-progress that really matters. The rest will
be overwritten.
https://pagure.io/freeipa/issue/7534
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
On upgrading a server without ACME to one with ACME
the RA Agent DN needs to be added as a member of the
ACME Enterprise Users group. This was previously
done as part of the creation of that entry.
So on upgrade the RA Agent wouldn't be a member so
ipa-acme-manage didn't have access to operate against
the CA REST API.
In order to add the RA Agent to this group during installation
the ACME provisioning has to come after that step so it is
moved from the middle of an installation to the end and
the group addition moved into the setup_acme() method.
https://pagure.io/freeipa/issue/8603
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Mohammad Rizwan Yusuf <myusuf@redhat.com>
This method was added temporarily while the required packages
were still under development and not available in stable
repositories.
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Mohammad Rizwan Yusuf <myusuf@redhat.com>
Any request other than the FQDN is redirected with a permanent
move (301). Allowing ipa-ca as a valid name saves a round-trip.
This is only allowed on /ca, /kra, /pki, /acme and /ipa/crl.
https://pagure.io/freeipa/issue/8595
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The KRA was previously configured with Internal CA profiles
which did not work with the IPA RA.
Use public, common profiles to manage renewal of the KRA
subsystem certificates.
https://pagure.io/freeipa/issue/8545
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Internal profiles were assigned which prevented rewewals.
dogtag is providing a new profile for the audit signing cert,
caAuditSigningCert.
There are existing profiles for the transport (caTransportCert)
and storage (caStorageCert) certificates.
https://pagure.io/freeipa/issue/8545
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
TestACMEwithExternalCA subclasses TestACME which subclasses
CALessBase.
CALessBase is necessary to generate the certificates for the
test_third_party_certs() test.
This means that the TestACME install classmethod needs to be
called by its subclasses. But the install actually does the
installation of the servers as well so needs to be aborted
at that point in the case of a subclass.
https://pagure.io/freeipa/issue/8581
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Reviewed-By: Armando Neto <abiagion@redhat.com>
This directory defines the location for ACME-related files
used by mod_md. Specify and create it rather than relying
on defaults to both fix a test failure and to make the
files accessable for debugging purposes.
https://pagure.io/freeipa/issue/8581
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Reviewed-By: Armando Neto <abiagion@redhat.com>
This command doesn't require any permissions that a host doesn't
already have and it simplifies overall credential handling.
It also corrects the case where the server API cache is out of
date and there are no credentials available to refresh it which
can lead to a confusing error message.
Also switch to MEMORY-based ccache rather than file to avoid
having to clean up the filesystem.
https://pagure.io/freeipa/issue/8531
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
The basic idea is:
* add a user with a password
* kinit with a bad password for the user until lockout
* on another server administratively reset the password
* wait for replication to finish
* kinit on the original server again and the user should
be able to kinit again meaning the lockout was removed
https://pagure.io/freeipa/issue/8551
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
This fixes the case where an account is locked on one or more servers
and the password is reset by an administrator. The account would
remain locked on those servers for the duration of the lockout.
This is done by setting krbLastAdminUnlock to the current date and
time. The lockout plugin will see this and unlock the account. Since
the value should be replicated along with the password any server
that has the new password will also be unlocked.
This does incur an additional attribute that must be replicated,
whether it is needed or not, but since lockout is computed
per-server this is the only guaranteed way to be sure that the
account will be unlocked everywhere.
My original thought was to grab password replication events and detect
whether the user was locked out and unlock them. On any given server
you can only know if the user is locked out on that server by
computing it. Doing this would require generalizing the lockout code
so it could be computed on password change. krbLastFailedAuth could
be wiped which would unlock the account on that master (the attribute
is not replicated by default).
So it is complexity vs additional replication. Assuming that admin
reset is relatively rare let's start with that. This doesn't lock
us into this solution for the future.
We could set this attribute on user-driven password changes as
well but the original ask and my thinking are that if you forgot
your password and got locked out, how can you change it yourself?
Upon reflection I guess a user could fat-finger it a bunch of times
against one IPA server then have a revelation and log in against a
different server. So they would still be locked out for the duration
on the first one. I'm not sure the extra replication is worth it for
user-generated password changes or that users would be saavy enough
to try another server for the change.
https://pagure.io/freeipa/issue/8551
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
If no results are returned then find_entries will raise
EmptyResult and not NotFound. NotFound is returned if
the search base doesn't exist.
The test for not entries can be removed as well since this
is the EmptyResult case. In case of a NotFound this will
be handled by the ExecutionError clause.
Found with https://pagure.io/freeipa/issue/8555
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
ipapwdpolicy is the objectclass which defines the libpwquality
attributes. For older sytems it isn't strictly necessary (or
visible) but not having it included will result in policies
not being visible with pwpolicy-find.
https://pagure.io/freeipa/issue/8555
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Traditionally in IPA 0 = success, 1 = error and then
specific error messages follow from that. Shift the
ipa-acme-manage return codes for "not installed" and
"not a CA" up by one.
https://pagure.io/freeipa/issue/8498
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
ACME requires an ipa-ca SAN to have a fixed URL to connect to.
If the Apache certificate is replaced by a 3rd party cert then
it must provide this SAN otherwise it will break ACME.
https://pagure.io/freeipa/issue/8498
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
The initial ACME support required that each server individually
enable/disable the service. PKI 10.10.0 stores this state in LDAP
so global enable/disable is available and the IPA code relies on
this.
Parse the VERSION file shipped with PKI to determine the version.
https://pagure.io/freeipa/issue/8524
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
This allows non-plugin components to import the RestClient
classes.
Removed code that only imported pki if in_server was True. This
was legacy code from when the plugins were also loaded in the
client.
Left the ra_plugin stanza for now. This is part of the old
abstraction that allowed for different CA plugins.
https://pagure.io/freeipa/issue/8524
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Mohammad Rizwan <myusuf@redhat.com>
When applying update files to 389 the listeners are disabled.
There is a large try/except around this so that if a failure
happens then the configuration should be automatically
restored.
We've seen multiple cases where this doesn't occur. Best guess
is that users are killing or ^C breaking out of the script.
What happens in that case is that when the next upgrade is run
the configuration is backed up again overwriting the original
values. This leaves dirsrv with no listener on 389.
Add a new state, upgrade-in-progress, so that the backup of the
config information can be skipped when the upgrader is executed
again after a failure.
The idea behind using a new state value is that if additional
attributes are ever backed up we don't need to remember to update
the list of possible saved values to check to decide if the
upgrade is in progress.
https://pagure.io/freeipa/issue/7534
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Enable checking:
maxrepeat - reject passwrods which contain more than N consecutive
characters.
maxsequence - rejected passwords which contain character sequences
(abcde).
dictcheck - check passwords using cracklib
usercheck - check whether the password contains the user name.
The class checking provided by libpwpolicy is not used because this
overlaps with the existing IPA checking. This includes the options
dcredit, ucredit, lcredit, ocredit, minclass and maxclassrepeat.
The pwquality min length is fixed at 6 so if there is a conflict between
the system policy and pwquality log that length is enforced at 6.
https://pagure.io/freeipa/issue/6964https://pagure.io/freeipa/issue/5948https://pagure.io/freeipa/issue/2445https://pagure.io/freeipa/issue/298
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
certmonger was later restarted to remove the custom CA entries
and the startup delay sometimes caused uninstallation to fail.
certmonger is stopped in cainstance.py::uninstall() so it will
still be stopped post-install.
https://pagure.io/freeipa/issue/8533
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Rob Crittenden