Scenario:
install a replica with DNS, with the replica part of a forward zone.
The replica installation should proceed successfully and avoid
trying to add a DNS record for the replica in the forward zone,
as the forward zone is not managed by IPA DNS.
Test added to nightly definitions.
Related to https://pagure.io/freeipa/issue/7369
Reviewed-By: Francois Cami <fcami@redhat.com>
authselect changed pam_systemd session from optional to required. When
the HBAC rule allow_all is disabled and replaced with more fine grained
rules, loginsi now to fail, because systemd's user@.service is able to
create a systemd session.
Add systemd-user HBAC service and a HBAC rule that allows systemd-user
to run on all hosts for all users by default. ipa-server-upgrade creates
the service and rule, too. In case the service already exists, no
attempt is made to create the rule. This allows admins to delete the
rule permanently.
See: https://bugzilla.redhat.com/show_bug.cgi?id=1643928
Fixes: https://pagure.io/freeipa/issue/7831
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
ipa-pkinit-manage enable was failing when run on a replica
without a CA instance.
Add a test with the following scenario:
- install a replica with --no-pkinit
- check that the KDC cert is self signed
- call ipa-pkinit-manage enable
- check that the KDC cert is signed by IPA CA
Related to https://pagure.io/freeipa/issue/7795
Reviewed-By: Francois Cami <fcami@redhat.com>
The test is failing when calling (on the replica)
ipa-replica-manage re-initialize --from <master>
because the tool needs to resolve master.
The test does not set /etc/resolv.conf on the replica, as a
consequence it relies on whatever DNS server is configured in
your test environment prior to launching the test, and makes
the test unreliable.
In PR-CI env, /etc/resolv.conf points to the machine hosting
the replica vm, which is unable to resolve master.ipa.test.
The fix is modifying the replica's /etc/resolv.conf to use the
master as DNS.
Fixes https://pagure.io/freeipa/issue/7778
Reviewed-By: Christian Heimes <cheimes@redhat.com>
test_replica_install_after_restore is calling tasks.uninstall_master which
is disabling the firewall services for freeipa. The following ipa-restore
call is not reapplying the firewall settings. Calling tasks.uninstall_master
with clean=False will disable the firewall cleanup.
See: https://pagure.io/freeipa/issue/7755
Signed-off-by: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
In order to work with IPA and Yubikey, libyubikey is required.
Before the fix, if yubikey added without having packages, it used to
result in traceback. Now it the exception is handeled properly.
It needs Yubikey hardware to make command successfull. This test
just check of proper error thrown when hardware is not attached.
related ticket : https://pagure.io/freeipa/issue/6979
Signed-off-by: Mohammad Rizwan Yusuf <myusuf@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The test is using a stale ldap connection to the master
(obtained before calling upgrade, and the upgrade stops
and starts 389-ds, breaking the connection).
The fix re-connects before using the ldap handle.
Related to https://pagure.io/freeipa/issue/7775
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
Add a test for ipa-pkinit-manage with the following scenario:
- install master with option --no-pkinit
- call ipa-pkinit-manage enable
- call ipa-pkinit-manage disable
- call ipa-pkinit-manage enable
At each step, check that the PKINIT cert is consistent with the
expectations: when pkinit is enabled, the cert is signed by IPA
CA and tracked by 'IPA' ca helper, but when pkinit is disabled,
the cert is self-signed and tracked by 'SelfSign' CA helper.
The new test is added in the nightly definitons.
Related to https://pagure.io/freeipa/issue/7200
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The following tests are added in test_ntp_options.py :: TestNTPoptions
- test_server_and_client_install_without_option_n
- test_server_and_client_install_with_option_n
- test_server_and_client_install_with_multiple_ntp_server
- test_server_replica_and_client_install_with_ntp_pool_and_ntp_server
- test_server_and_client_install_with_mixed_options
- test_two_step_replica_install_using_ntp_options
- test_two_step_replica_install_without_ntp_options
Details in the ticket: https://pagure.io/freeipa/issue/7719
and https://pagure.io/freeipa/issue/7723
Signed-off-by: Varun Mylaraiah <mvarun@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Tibor Dudlak <tdudlak@redhat.com>
The tests in this file are calling ipa-[server,replica]-install directly
instead of using methods from tasks. Therefore it is required to enable
or disable the needed firewall services also.
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Armando Neto <abiagion@redhat.com>
The dns firewall service needs to be enabled for the servers and replicas
where dns support has not been enabled at install time. Also it is needed
to enable the dns firewall service on the replica for migrating the dns
server to the replica.
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Armando Neto <abiagion@redhat.com>
Instead of using ip[6]tables commands, use new firewall class to deny
access to TCP and UDP port 88 on external machines using the OUTPUT chain.
The iptables calls in the install method are replaced by a
prepend_passthrough_rules call with the rules defined in the class.
The firewall rules are defined in the class as fw_rules without
--append/-A, --delete/-D, .. First entry of each rule is the chain name,
the argument to add or delete the rule will be added by the used Firewall
method. See firewall.py for more information.
The "iptables -F" call (IPv4 only) in the uninstall method is replaced by
a remove_passthrough_rules call with the rules defined in the class.
See: https://pagure.io/freeipa/issue/7755
Signed-off-by: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Armando Neto <abiagion@redhat.com>
Instead of using iptables command, use "unshare --net" for uninstalling
client in the restore_client method.
The uninstall_client method has been extended with the additional argument
unshare (bool) which defaults to False. With unshare set, the call for
"ipa-client-install --uninstall -U" will be used with "unshare --net". The
uninstall command will not have network access.
See: https://pagure.io/freeipa/issue/7755
Signed-off-by: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Armando Neto <abiagion@redhat.com>
Create a test for upgrade with the following scenario:
- install master
- write a double-encoded cert in the entry
cn=cacert,,cn=ipa,cn=etc,$basedn
to simulate bug 7775
- call ipa-server-upgrade
- check that the upgrade fixed the value
The upgrade should finish successfully and repair
the double-encoded cert.
Related to https://pagure.io/freeipa/issue/7775
Reviewed-By: Christian Heimes <cheimes@redhat.com>
pylint 2.2.0 has a new checker for unnecessary pass statements. There is
no need to have a pass statement in functions or classes with a doc
string.
Fixes: https://pagure.io/freeipa/issue/7772
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
test_topology.py is failing because of a wrong scenario.
Currently, test_replica_uninstall_deletes_ruvs does:
- install master + replica with CA
- ipa-replica-manage list-ruv to check that the repl is
propery setup
- ipa-replica-manage del $replica
- (on replica) ipa-server-install --uninstall -U
- ipa-replica-manage list-ruv to check that replica
does not appear any more in the RUV list
When ipa-replica-manage del is run, the topology plugin
creates 2 tasks cleanallruvs (one for the domain, one for the ca)
and they are run asynchronously. This means that the ruvs may
still be present when the test moves forward and calls list-ruv.
The test should wait for the cleanallruvs tasks to finish before
checking that list-ruv does not display replica anymore.
Fixes https://pagure.io/freeipa/issue/7545
Reviewed-By: Thierry Bordaz <tbordaz@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Pylint warns about inconsistent return statements when some paths of a
function return None implicitly. Make all implicit returns either
explicit or raise a proper exception.
See: https://pagure.io/freeipa/issue/7758
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The test test_http_intermediate_ca was expecting success when
it should expect a failure. Scenario:
- install IPA ca-less with certs signed by rootCA
- call ipa-server-certinstall with a cert signed by a subCA
to replace http cert.
In this case, the command should refust changing the cert
(otherwise the clients won't be able any more to use
ipa * commands as the subca is not installed in /etc/ipa/nssdb
or in /etc/ipa/ca.crt).
The commit fixes the test expectation and marks the test as
xfail (see ticket 7759).
The test test_ds_intermediate_ca was expecting success when
it should expect a failure. Same scenario as above, but for
the ldap server cert.
The commit fixes the test expectation and removes the xfail
(ticket 6959 was closed as invalid).
Note:
The behavior differs for ldap and http cert because LDAP server
is using a NSSDB and http server is using openssl, hence
ipa-server-certinstall follows 2 different code paths when
changing the server cert.
Related to https://pagure.io/freeipa/issue/7759
Related to https://pagure.io/freeipa/issue/6959
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Add a new integration test for the following scenario:
- create a user with the "User Administrator" role
- as this user, create a user with a --radius=<radius_proxy_server>
This scenario was previously failing because ipa user-add --radius
requires read access to the radius server entries, and there was no
permission granting this access.
Related to https://pagure.io/freeipa/issue/7570
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
The test TestServerInstall::test_ca_2_certs has a
wrong expectation. Scenario:
install a CA-less master with
ipa-server-install --ca-cert-file root.pem
where root.pem contains the CA that signed the http and ldap
certificates + an additional (unneeded) CA cert.
The test was expecting a failure, but this scenario is not
problematic as long as the unneeded CA cert is not added.
Related to https://pagure.io/freeipa/issue/6289 which has been
closed as won't fix
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reuse master instance when installing replica with custom DS config.
This avoids one extra ipa-server-install and also tests replica
installation from a master with custom DS config.
See: https://pagure.io/freeipa/issue/7743
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
For smart card authentication, ipaapi must be able to access to sss-ifp.
During installation and upgrade, the ipaapi user is now added to
[ifp]allowed_uids.
The commit also fixes two related issues:
* The server upgrade code now enables ifp service in sssd.conf. The
existing code modified sssd.conf but never wrote the changes to disk.
* sssd_enable_service() no longer fails after it has detected an
unrecognized service.
Fixes: https://pagure.io/freeipa/issue/7751
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Test that
1) sudo is not enabled for members of admins group by default
2) sudo is enabled for them after execution of script provided
by ipa-advise enable_admins_sudo
Related to https://pagure.io/freeipa/issue/7538
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
The install_master() function performs additional steps besides just
installing a server. It also sets up log collection and performs
additional tests.
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Some incorrect errors are possible if a client installation
fails and a configuration rollback is required.
These include:
1. Unconfigured automount client failed: CalledProcessError(Command
['/usr/sbin/ipa-client-automount', '--uninstall', '--debug']
returned non-zero exit status 1: '')
Caused by check_client_configuration() not returning the correct
return value (2).
2. WARNING: Unable to revert to the pre-installation state ('authconfig'
tool has been deprecated in favor of 'authselect'). The default sssd
profile will be used instead.
The authconfig arguments would have been: authconfig --disableldap
--disablekrb5 --disablesssdauth --disablemkhomedir
If installation fails before SSSD is configured there is no state
to roll back to. Detect this condition.
3. An error occurred while removing SSSD's cache.Please remove the
cache manually by executing sssctl cache-remove -o.
Again, if SSSD is not configured yet then there is no cache to
remove. Also correct the missing space after the period.
https://pagure.io/freeipa/issue/7729
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
The test is putting server.p12 / replica.p12 in the test_dir directory,
and the error message is printing the file name with its full path.
Related to https://pagure.io/freeipa/issue/5378
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
The KRA installation code explicity quits if trying to
install a KRA during a replica installation if there is not
already a KRA in the topology.
A KRA can be added afterward.
https://pagure.io/freeipa/issue/7651
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Commit 5dbcc1a9d3 marked
the base class method test_replica0_with_ca_kra_dns_install
as known failure, but this does not work with inherited
classes. The child class methods need to be marked
themselves as known failures with @pytest.mark.xfail
Furthermore, TestInstallWithCA_KRA2 and TestInstallWithCA_KRA_DNS2
tests should succeed because the master is installed with KRA
(issue 7651 is related to replica install with --setup-kra
when it is the first KRA instance).
Related to https://pagure.io/freeipa/issue/7651
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Florence Blanc-Renaud
Sergey Orlov
Christian Heimes
François Cami
Thomas Woerner
Mohammad Rizwan Yusuf
Varun Mylaraiah
Stanislav Laznicka
Rob Crittenden
Fraser Tweedale