Kroon PC, Peter via FreeIPA-users wrote:
Thanks for the super fast reply! I'll do my best to reply in-line, but I'm bound to outlook, which doesn't like it too much.
Hi all!
I'm working on updating my freeipa server from rocky 8 to 9. I'm playing around with a virtual machines as playground server and client, since I'd rather not break my everything right away. As part of this, I first installed ipa-server version 4.10.2-8.el9_3 on the server. Then I did an ipa-restore with a backup from my production ipa server (rocky 8, 4.9.12-11.module+el8.9.0+1652+4ee71f6a), followed by an ipa-server-upgrade. All is well so far (I think).
I don't know how you achieved this. ipa-restore attempts to prevent using restore as a backdoor upgrade mechanism.
It didn't complain /too/ much honestly. It saw the version mismatch between the backup and the installed server, asked for a "yes", and then happily went on its way. Is there a better way to achieve what I want/need?
Create a replica and disconnect it from the topology to have a sandbox.
The client is running Debian bookworm with backports, where the latest ipa-client version is 4.9.11-1. Then, I went with the usual ipa-client-install --no-ntp, which fails with "Joining realm failed: Failed to parse result: PrincipalName not found." after retrieving the CA cert. The logs don't tell me much more, but the --debug flag does. It negotiates a JSON-RPC response, in which it says '{... "principal": "admin@EXAMPLE.COM", ...}'. I note that principal != PrincipalName. Also note, that on the server, the host /is/ added.
So I guess my question is: how much version skew between server and client is supported?
Plenty. There isn't much to client enrollment and the API hasn't changed significantly in a long time.
Ok. Is there any other place I can look for what's going wrong?
The server httpd error log should have something about the request as well as the client install log.
To get more details on the server side you can create /etc/ipa/server.conf with the contents:
[global] debug = True
Then restart httpd. Warning, it can be very verbose so I wouldn't leave it like that for long in production.
rob
Thanks again for the reply :) Short update from my side: turns out it was indeed my upgrade path that was causing issues. I just managed to join my 4.9 client to a 4.10 server without issues. Rather than restoring a 4.9 backup to a 4.10 server (which is unsupported, as it turns out), I restored the backup to a clean server with the exact same version, and then upgraded the OS (rocky) from 8 to 9, which came with a ipa-server upgrade to 4.10. My next move will be to see if I can replicate this to a clean Rocky 9. I didn't chase down what the actual error was, since I was doing strange things anway :)
Peter
________________________________________
From: Rob Crittenden rcritten@redhat.com Sent: Friday, 15 March 2024 18:57 To: FreeIPA users list Cc: Kroon PC, Peter Subject: Re: [Freeipa-users] Re: Cannot enroll a 4.9 client to 4.10 server fails with PrincipalName not found
Kroon PC, Peter via FreeIPA-users wrote:
Thanks for the super fast reply! I'll do my best to reply in-line, but I'm bound to outlook, which doesn't like it too much.
Hi all!
I'm working on updating my freeipa server from rocky 8 to 9. I'm playing around with a virtual machines as playground server and client, since I'd rather not break my everything right away. As part of this, I first installed ipa-server version 4.10.2-8.el9_3 on the server. Then I did an ipa-restore with a backup from my production ipa server (rocky 8, 4.9.12-11.module+el8.9.0+1652+4ee71f6a), followed by an ipa-server-upgrade. All is well so far (I think).
I don't know how you achieved this. ipa-restore attempts to prevent using restore as a backdoor upgrade mechanism.
It didn't complain /too/ much honestly. It saw the version mismatch between the backup and the installed server, asked for a "yes", and then happily went on its way. Is there a better way to achieve what I want/need?
Create a replica and disconnect it from the topology to have a sandbox.
The client is running Debian bookworm with backports, where the latest ipa-client version is 4.9.11-1. Then, I went with the usual ipa-client-install --no-ntp, which fails with "Joining realm failed: Failed to parse result: PrincipalName not found." after retrieving the CA cert. The logs don't tell me much more, but the --debug flag does. It negotiates a JSON-RPC response, in which it says '{... "principal": "admin@EXAMPLE.COM", ...}'. I note that principal != PrincipalName. Also note, that on the server, the host /is/ added.
So I guess my question is: how much version skew between server and client is supported?
Plenty. There isn't much to client enrollment and the API hasn't changed significantly in a long time.
Ok. Is there any other place I can look for what's going wrong?
The server httpd error log should have something about the request as well as the client install log.
To get more details on the server side you can create /etc/ipa/server.conf with the contents:
[global] debug = True
Then restart httpd. Warning, it can be very verbose so I wouldn't leave it like that for long in production.
rob
freeipa-users@lists.fedorahosted.org