On ti, 07 elo 2018, Adam Williamson wrote:
On Sun, 2018-08-05 at 10:34 +0300, Alexander Bokovoy wrote:
> On pe, 03 elo 2018, Adam Williamson wrote:
> > On Thu, 2018-08-02 at 15:12 +0300, Alexander Bokovoy wrote:
> > >
> > > Yes, I reviewed those. They are fine.
> > OK, thanks for the feedback. I've merged the tests to master, now, and
> > once we finally get a Rawhide that actually *works*, they should run in
> > production.
> > Do you think there's anything additional we should be testing here,
> > bearing in mind the earlier conversation about not having sufficient
> > testing for F28? Or do you think these tests cover what's essential?
> > Thanks!
> These tests do cover an essential part of deploying FreeIPA.
> We might want to expand that in future but it would really be a
> crossover with the Desktop edition.
> For example, FreeIPA 4.5 added support for PKINIT, Kerberos with smart
> cards. We have it enabled on the server side and also in SSSD. Through
> SSSD it is enabled for GDM. An ideal case would be:
> - add a user
> - issue a certificate to the user
> - ensure user can obtain a Kerberos ticket using this certificate via
> - provision the cert to a SoftHSMv2 token
> - use SoftHSMv2 token as a PKCS#11 'smart card' to login to GNOME
> - ensure that after logon user has a Kerberos ticket and can use it to
> access FreeIPA web UI
> Note that we aren't using passwords anywhere here to login to GNOME.
OK, that's kinda separate from replication. I was thinking specifically
in the area of replication at least in this thread, though obviously
other FreeIPA testing can be done (there's a couple of tickets already
open requesting things).
I guess the thing I was kinda expecting someone to suggest was testing
things with one of the servers not running - the stuff I split out into
the 'advanced' test case on the wiki pages,
. Do you think it's very important to do that testing too, or should
just testing the replication process itself and that the client can
enrol against the replica (rather than the original server) be a good
enough test? I can add the 'advanced' tests if desired, it just
requires some more inter-test communication magic...
It is a good enough scenario
for a basic test.
There are three big areas to test with more than one IPA master at play:
- LDAP server replication
- CA operations that require coordination across the topology (like CRL
- client fail-over behavior
A big part of operations in IPA framework fall under behavior of
LDAP replication. For example, if you'd stand up a replica but never use
it to create any users or groups, it will not acquire a share of the ID
range form its replication master. This means when the master in
question goes down, any operation on replica that would need to allocate
any ID (uidNumber or gidNumber, for example), will fail because that
replica wouldn't have any range to allocate the IDs from.
Testing that you can enroll to a replica is fine but it doesn't really
test more than a basic replication scenario. If you want to expand to a
fail-over test, you'd have an issue in case you have used --server
option to ipa-client-install during enrollment because it actually
pinned the client to that server. See ipa-client-install(1), section
"The failover mechanism". Still, with no --fixed-primare option there
will be _srv_ record added to ipa_server line in sssd.conf and a fail
over will work.
Unfortunately, you call 'realm join' with an explicit server, so realmd
adds --fixed-primary option which forces removal of _srv_ from the
ipa_server option in the domain section of sssd.conf. As result, a
fail-over will not happen.
Thus, if you want to shut down a master and test a fail over, you need
- make sure replica was used to allocate at least some IDs to get its
ID range carved out from the master
- change a way an enrollment happens -- let IPA client to be enrolled
against any master, then see from sssd.conf which master it used for
enrollment and shut it down for a fail-over test.
/ Alexander Bokovoy