On Tue, Oct 12, 2021 at 9:53 AM Spencer Olson <olso...@umich.edu> wrote:
>
> On Sun, Oct 10, 2021 at 12:58 PM Timo Aaltonen <tjaal...@debian.org> wrote:
> >
> > >
> > >
> > > Maybe the CI will finish before I can get back to my testing.
> >
> > And it did, this error is fixed now :)
> >
> > But it fails later on, so there's some work still to catch up with the
> > current distro, but at least this particular annoyance is resolved, so
> > many thanks for figuring it out! I was sure the reason was something
> > silly and related to the SSL stack (or maybe ciphers) but was blind to
> > see it.
>
> I borrowed the .deb packages from the build artifacts and tested more.
> You probably already have this fixed but,
> * /var/lib/gssproxy directory has to be created so that gssproxy can
> be started.
>
> I manually created the path and ran the script again. It passes the
> gssproxy error that the CI got stuck on, but it failed at creating the
> client with this error:
>
> DEBUG The ipa-client-install command failed, exception: KerberosError:
> No valid Negotiate header in server response
> 2021-10-11T09:32:49Z ERROR No valid Negotiate header in server response
>
> I've found a few posts online with errors similar to this in 2019 (one
> "solution" supposedly posted on RedHat's site that I don't have access
> to). But, I haven't figured this one out yet. Perhaps you already
> know how to fix this one.
So, I am now wondering if the latest issue I am seeing (where iti
complains about the Negotiate problem) might be due to the bind9
configuration/installation not being quite correct.
I have two VMs, one for CentOS Stream.
For the CentOS stream VM:
- just uses a DHCP address because I was lazy in the setup and didn't
take the time to change this
- ipa-server-install finished successfully
- there is a named-pkcs11 program installed and corresponding
processing running
- the named-pkcs11 program is certainly linked to a few libraries
that the normal named program is not linked to
- the nameserver resolves things as expected: the host of the server
("sid" in my test case) and certainly also ipa-ca.domain resolve just
fine
- bind9-dyndb-ldap *is* installed
- doing "fuser /usr/lib64/bind/ldap.so" does show the process ID of
named-pkcs11
For the Debian sid install:
- Uses netplan to specify a static IP. This is the same VM i've been
using for all my tests, though I have been using and unwinding
snapshots a lot from test to test.
- ipa-server-install fails at the point that the ipa-client-install runs
- named-pkcs11 does *not* exist as an installed program
- `named` process is running and does respond to queries, but it does
not resolve anything useful
- browsing through the LDAP entries for DNS, I can see entries for
the ipa server, but named does not resolve these
- bind9-dyndb-ldap *is* installed.
- doing "fuser /usr/lib64/bind/ldap.so" does show the process ID of
named-pkcs11
So, clearly, there is a difference between the install on CentOS and
Debian Sid with the latest updates. I might add that my working old
ubuntu machine does indeed have the named-pkcs11 process. I am
wondering if this is a problem that was never resolved since the
updates to the new bind9 that plagued getting freeipa to work for
debian originally. Perhaps this was never fully finished because we
never had freeipa to actually test the changes in the bind9 package.
