We found this issue today, upgrading from Fedora 40 to Fedora 41.
In dogtagpki the /ca/rest/account/login endpoint (actually all /ca/rest endpoints) was moved to /ca/v1 in this commit:
https://github.com/dogtagpki/pki/commit/850e6b9e5128264a471e57b70ab8d970cf91...
We were able to complete the upgrade succesfully modifying the file /usr/lib/python3.13/site-packages/ipaserver/plugins/dogtag.py changing al "/rest" to "/v1". With this modification ipa-server-upgrade completed successfully.
It seems there is some kind of version mismatch.
Greetings, Vicente Quintáns.
I can confirm this fixed it for me as well.
--Russ
On Fri, Apr 4, 2025 at 11:15 AM Vicente Quintans via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
We found this issue today, upgrading from Fedora 40 to Fedora 41.
In dogtagpki the /ca/rest/account/login endpoint (actually all /ca/rest endpoints) was moved to /ca/v1 in this commit:
https://github.com/dogtagpki/pki/commit/850e6b9e5128264a471e57b70ab8d970cf91...
We were able to complete the upgrade succesfully modifying the file /usr/lib/python3.13/site-packages/ipaserver/plugins/dogtag.py changing al "/rest" to "/v1". With this modification ipa-server-upgrade completed successfully.
It seems there is some kind of version mismatch.
Greetings, Vicente Quintáns. -- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
I have the same problem however the fix did not quite work for me.
I have two FreeIPA servers running as a replica set, both running Fedora 40. I updated one to Fedora 41 and the ipa service would fail to start. Digging deeper I could see that when the service starts it tries to perform an upgrade. One error message said to look at /var/log/ipaupgrade.log. In this log I could see errors relating to failing to authenticate with the CA REST API.
I tried Vicente Quintans fix above by replacing all occurrences of “/rest” to “/v1” in /usr/lib/python3.13/site-packages/ipaserver/plugins/dogtag.py. This did fix some stuff as I could then start the ipa service which implies the upgrade part is now working. I can also sign into the web UI. The problem I see is that when I go to the authentication page in the web UI I get a popup error saying: IPA ERROR 4301: CertificateOperationError Certificate operation cannot be completed: Unable to communicate with he CMS (Failed to parse error response).
Because these are production servers I have rolled back. Problem is that Fedora 40 is end of life very soon. I’ve kept the broken machine, plus I can easily replicate the error if need be. Not sure what to do next.
I have the same problem however the fix did not quite work for me.
I have two FreeIPA servers running as a replica set, both running Fedora 40. I updated one to Fedora 41 and the ipa service would fail to start. Digging deeper I could see that when the service starts it tries to perform an upgrade. One error message said to look at /var/log/ipaupgrade.log. In this log I could see errors relating to failing to authenticate with the CA REST API.
I tried Vicente Quintans fix above by replacing all occurrences of “/rest” to “/v1” in /usr/lib/python3.13/site-packages/ipaserver/plugins/dogtag.py. This did fix some stuff as I could then start the ipa service which implies the upgrade part is now working. I can also sign into the web UI. The problem I see is that when I go to the authentication page in the web UI I get a popup error saying: IPA ERROR 4301: CertificateOperationError Certificate operation cannot be completed: Unable to communicate with he CMS (Failed to parse error response).
Because these are production servers I have rolled back. Problem is that Fedora 40 is end of life very soon. I’ve kept the broken machine, plus I can easily replicate the error if need be. Not sure what to do next.
I have the same problem however the fix did not quite work for me.
I have two FreeIPA servers running as a replica set, both running Fedora 40. I updated one to Fedora 41 and the ipa service would fail to start. Digging deeper I could see that when the service starts it tries to perform an upgrade. One error message said to look at /var/log/ipaupgrade.log. In this I could see errors relating to failing to authenticate with the CA REST API.
I tried Vicente Quintans fix above by replacing all occurrences of “/rest” to “/v1” in /usr/lib/python3.13/site-packages/ipaserver/plugins/dogtag.py. This did fix some stuff as I could then start the ipa service which implies the upgrade part is now working. I can also sign into the web UI. The problem I see is that when I go to the authentication page in the web UI I get a popup error saying: IPA ERROR 4301: CertificateOperationError Certificate operation cannot be completed: Unable to communicate with he CMS (Failed to parse error response).
Because these are production servers I have rolled back. Problem is that Fedora 40 is end of life very soon. I’ve kept the broken machine, plus I can easily replicate the error. Not sure what to do next really.
Sorry I dont know why my post above has appeared 4 times. If there are any admins reading you can delete the 3 duplicates. I could not find a way to delete myself. Thanks
Hi,
you can install freeipa-healthcheck and launch ipa-healthcheck This tool performs various checks and reports any configuration issue / expired certificates / wrong file permission etc, which helps a lot for diagnostics.
Regarding the pop-up error, you can do the following to gather more logs. - create a file /etc/ipa/server.conf with the following content: [global] debug=True
- restart the apache server with systemctl restart httpd - use a command that requires communication with the certificate server, for instance kinit admin; ipa cert-show 1 - look at the logs generated in /var/log/httpd/error_log You should see some logs containing the "cert_show" command and possibly a traceback with more information. If the command reaches the Certificate Server, there would also be some logs in /var/log/pki/pki-tomcat/ca/debugxxx
flo
On Fri, Apr 18, 2025 at 2:12 PM tipex tipex via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Sorry I dont know why my post above has appeared 4 times. If there are any admins reading you can delete the 3 duplicates. I could not find a way to delete myself. Thanks -- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
@Florence Blanc-Renaud
I did not know about the freeipa-healthcheck tool. This is nice to have thanks! I've installed it on both my good machines which are running Fedora 40. I thought it was worth looking at the health of them as in my mind these are known goods with no issues that I know of. But the health check is showing some issues: - Complaining about invalid IP address which is IPv6. My network is using IPv4. My guess would be that this error can be ignored? - Complaining about not being able to reach machine B (dc-b-prod-it.internal.example.com) on port 443. I am able to reach the web UI of this machine using https on port 443 so not sure why this error is coming up. This is possibly related to the Fedora upgrade issue I was having? - Various warnings about configuration attributes that are not applicable for the backend. My guess would be that these can be ignored? - Error about replication not being in sync. It mentions the following hostname catosg-it-prod-dc-a-euw2az1.internal.example.com. Maybe this is a display issue but the real hostname is sg-it-prod-dc-a-euw2az1.internal.example.com i.e. without the cato in front. This feels like an issue that needs fixing. Not sure why they would not be in sync. - Various warnings about URI records being missing. My servers are in AWS and I use Route 53 as the DNS. There is no option to add RUI records in AWS Route 53. My guess would be that these can be ignored?
I could not see a way to attach a file in this forum so I'm pasting below the output of running sudo ipa-healthcheck on machine B. Running it on A gives the same output.
Invalid IP address fe80::4dc:36ff:fe4e:d1c5 for sg-it-prod-dc-b-euw2az2.internal.example.com.: cannot use link-local IP address fe80::4dc:36ff:fe4e:d1c5 Internal server error HTTPSConnectionPool(host='dc-b-prod-it.internal.example.com', port=443): Max retries exceeded with url: /ca/rest/certs/search?size=3 (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f054c368050>: Failed to establish a new connection: [Errno -2] Name or service not known')) [ { "source": "ipahealthcheck.ds.backends", "check": "BackendsCheck", "result": "WARNING", "uuid": "10a46762-ba2a-4be0-8a83-e6b14a34db19", "when": "20250423071410Z", "duration": "0.080989", "kw": { "key": "DSBLE0005", "items": [ "nsslapd-dbcachesize", "nsslapd-db-logdirectory", "nsslapd-db-transaction-wait", "nsslapd-db-checkpoint-interval", "nsslapd-db-compactdb-interval", "nsslapd-db-compactdb-time", "nsslapd-db-transaction-batch-val", "nsslapd-db-transaction-batch-min-wait", "nsslapd-db-transaction-batch-max-wait", "nsslapd-db-logbuf-size", "nsslapd-db-page-size", "nsslapd-db-locks", "nsslapd-db-locks-monitoring-enabled", "nsslapd-db-locks-monitoring-threshold", "nsslapd-db-locks-monitoring-pause", "nsslapd-db-private-import-mem", "nsslapd-db-deadlock-policy" ], "msg": "Found configuration attributes that are not applicable for the configured backend type." } }, { "source": "ipahealthcheck.ds.backends", "check": "BackendsCheck", "result": "WARNING", "uuid": "aaf8c06e-3e3c-4185-843c-bb5be435416e", "when": "20250423071410Z", "duration": "0.081003", "kw": { "key": "DSBLE0005", "items": [ "nsslapd-dbcachesize", "nsslapd-db-logdirectory", "nsslapd-db-transaction-wait", "nsslapd-db-checkpoint-interval", "nsslapd-db-compactdb-interval", "nsslapd-db-compactdb-time", "nsslapd-db-transaction-batch-val", "nsslapd-db-transaction-batch-min-wait", "nsslapd-db-transaction-batch-max-wait", "nsslapd-db-logbuf-size", "nsslapd-db-page-size", "nsslapd-db-locks", "nsslapd-db-locks-monitoring-enabled", "nsslapd-db-locks-monitoring-threshold", "nsslapd-db-locks-monitoring-pause", "nsslapd-db-private-import-mem", "nsslapd-db-deadlock-policy" ], "msg": "Found configuration attributes that are not applicable for the configured backend type." } }, { "source": "ipahealthcheck.ds.backends", "check": "BackendsCheck", "result": "WARNING", "uuid": "17175c1a-12c2-4890-9725-5988022cf414", "when": "20250423071410Z", "duration": "0.081005", "kw": { "key": "DSBLE0005", "items": [ "nsslapd-dbcachesize", "nsslapd-db-logdirectory", "nsslapd-db-transaction-wait", "nsslapd-db-checkpoint-interval", "nsslapd-db-compactdb-interval", "nsslapd-db-compactdb-time", "nsslapd-db-transaction-batch-val", "nsslapd-db-transaction-batch-min-wait", "nsslapd-db-transaction-batch-max-wait", "nsslapd-db-logbuf-size", "nsslapd-db-page-size", "nsslapd-db-locks", "nsslapd-db-locks-monitoring-enabled", "nsslapd-db-locks-monitoring-threshold", "nsslapd-db-locks-monitoring-pause", "nsslapd-db-private-import-mem", "nsslapd-db-deadlock-policy" ], "msg": "Found configuration attributes that are not applicable for the configured backend type." } }, { "source": "ipahealthcheck.ds.replication", "check": "ReplicationCheck", "result": "ERROR", "uuid": "9c0b870b-688a-4468-afcd-f18f06650e41", "when": "20250423071414Z", "duration": "1.213910", "kw": { "key": "DSREPLLE0003", "items": [ "Replication", "Agreement" ], "msg": "The replication agreement (catosg-it-prod-dc-a-euw2az1.internal.example.com) under "o=ipaca" is not in synchronization.\nStatus message: error (18) can't acquire replica (incremental update transient warning. backing off, will retry update later.)" } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "09ee1304-633c-48b3-841e-b2c3c431b2ba", "when": "20250423071418Z", "duration": "0.036548", "kw": { "msg": "Expected URI record missing", "key": "_kerberos.internal.example.com.:krb5srv:m:tcp:sg-it-prod-dc-a-euw2az1.internal.example.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "85a84e2a-ed3f-4238-ab8d-10762d81b362", "when": "20250423071418Z", "duration": "0.036573", "kw": { "msg": "Expected URI record missing", "key": "_kerberos.internal.example.com.:krb5srv:m:udp:sg-it-prod-dc-a-euw2az1.internal.example.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "87f324e1-ad3c-4284-a53e-2081e9082d7e", "when": "20250423071418Z", "duration": "0.036588", "kw": { "msg": "Expected URI record missing", "key": "_kerberos.internal.example.com.:krb5srv:m:tcp:sg-it-prod-dc-b-euw2az2.internal.example.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "9753a6c1-8d23-472d-a02b-a2a7608aaccf", "when": "20250423071418Z", "duration": "0.036601", "kw": { "msg": "Expected URI record missing", "key": "_kerberos.internal.example.com.:krb5srv:m:udp:sg-it-prod-dc-b-euw2az2.internal.example.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "9509d091-c3cb-4ea3-98b2-eca366a6d13b", "when": "20250423071418Z", "duration": "0.042577", "kw": { "msg": "Expected URI record missing", "key": "_kpasswd.internal.example.com.:krb5srv:m:tcp:sg-it-prod-dc-a-euw2az1.internal.example.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "56cb7ac2-1849-4706-b244-328b47f69d27", "when": "20250423071418Z", "duration": "0.042601", "kw": { "msg": "Expected URI record missing", "key": "_kpasswd.internal.example.com.:krb5srv:m:udp:sg-it-prod-dc-a-euw2az1.internal.example.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "c58fd746-a426-48f7-b832-700db19602ba", "when": "20250423071418Z", "duration": "0.042615", "kw": { "msg": "Expected URI record missing", "key": "_kpasswd.internal.example.com.:krb5srv:m:tcp:sg-it-prod-dc-b-euw2az2.internal.example.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "c8f5c339-a4fb-4350-b02c-3906af5753cb", "when": "20250423071418Z", "duration": "0.042628", "kw": { "msg": "Expected URI record missing", "key": "_kpasswd.internal.example.com.:krb5srv:m:udp:sg-it-prod-dc-b-euw2az2.internal.example.com." } }, { "source": "pki.server.healthcheck.clones.connectivity_and_data", "check": "ClonesConnectivyAndDataCheck", "result": "ERROR", "uuid": "4d7ec689-fed8-42f2-ba8f-9e3163f69d70", "when": "20250423071425Z", "duration": "0.127883", "kw": { "status": "ERROR: pki-tomcat : Internal error testing CA clone. Host: dc-b-prod-it.internal.example.com Port: 443" } } ]
I've not tried the apache thing you suggested yet. It feels like just from the health check alone there are things that need to be addressed. Any suggestions on where to start? I'm surprised there are so many warnings and errors for a system which I consider to be working. Happy to try other things including the apache logs etc. I just didnt want to make this post even longer than it already is.
Thanks
I spotted something. The errors are because its using the wrong hostname: Wrong = dc-b-prod-it.internal.example.com Right = sg-it-prod-dc-b-euw2az2.internal.example.com
Just trying to see were its getting the wrong hostname from.
Hi,
On Wed, Apr 23, 2025 at 10:14 AM tipex tipex via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
@Florence Blanc-Renaud
I did not know about the freeipa-healthcheck tool. This is nice to have thanks! I've installed it on both my good machines which are running Fedora 40. I thought it was worth looking at the health of them as in my mind these are known goods with no issues that I know of. But the health check is showing some issues:
- Complaining about invalid IP address which is IPv6. My network is using
IPv4. My guess would be that this error can be ignored?
Yes, you can ignore that one about link-local IP address.
- Complaining about not being able to reach machine B (
dc-b-prod-it.internal.example.com) on port 443. I am able to reach the web UI of this machine using https on port 443 so not sure why this error is coming up. This is possibly related to the Fedora upgrade issue I was having?
The check is using the reset endpoint /ca/admin/ca/getStatus IIRC. The webui may be accessible but this specific endpoint failing.
- Various warnings about configuration attributes that are not applicable
for the backend. My guess would be that these can be ignored?
- Error about replication not being in sync. It mentions the following
hostname catosg-it-prod-dc-a-euw2az1.internal.example.com. Maybe this is a display issue but the real hostname is sg-it-prod-dc-a-euw2az1.internal.example.com i.e. without the cato in front. This feels like an issue that needs fixing. Not sure why they would not be in sync.
The replication agreement name can be read as "CA to sg-it-..." (Certificate Authority to sg-it...). It allows to distinguish the replication of the domain suffix and the replication of o=ipaca suffix.
- Various warnings about URI records being missing. My servers are in AWS
and I use Route 53 as the DNS. There is no option to add RUI records in AWS Route 53. My guess would be that these can be ignored?
Correct DNS records are pre-requisites, please see https://docs.redhat.com/en/documentation/Red_Hat_Enterprise_Linux/7/html/lin... but the URI records only raise warnings, not errors.
I could not see a way to attach a file in this forum so I'm pasting below the output of running sudo ipa-healthcheck on machine B. Running it on A gives the same output.
Invalid IP address fe80::4dc:36ff:fe4e:d1c5 for sg-it-prod-dc-b-euw2az2.internal.example.com.: cannot use link-local IP address fe80::4dc:36ff:fe4e:d1c5 Internal server error HTTPSConnectionPool(host=' dc-b-prod-it.internal.example.com', port=443): Max retries exceeded with url: /ca/rest/certs/search?size=3 (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f054c368050>: Failed to establish a new connection: [Errno -2] Name or service not known')) [ { "source": "ipahealthcheck.ds.backends", "check": "BackendsCheck", "result": "WARNING", "uuid": "10a46762-ba2a-4be0-8a83-e6b14a34db19", "when": "20250423071410Z", "duration": "0.080989", "kw": { "key": "DSBLE0005", "items": [ "nsslapd-dbcachesize", "nsslapd-db-logdirectory", "nsslapd-db-transaction-wait", "nsslapd-db-checkpoint-interval", "nsslapd-db-compactdb-interval", "nsslapd-db-compactdb-time", "nsslapd-db-transaction-batch-val", "nsslapd-db-transaction-batch-min-wait", "nsslapd-db-transaction-batch-max-wait", "nsslapd-db-logbuf-size", "nsslapd-db-page-size", "nsslapd-db-locks", "nsslapd-db-locks-monitoring-enabled", "nsslapd-db-locks-monitoring-threshold", "nsslapd-db-locks-monitoring-pause", "nsslapd-db-private-import-mem", "nsslapd-db-deadlock-policy" ], "msg": "Found configuration attributes that are not applicable for the configured backend type." } }, { "source": "ipahealthcheck.ds.backends", "check": "BackendsCheck", "result": "WARNING", "uuid": "aaf8c06e-3e3c-4185-843c-bb5be435416e", "when": "20250423071410Z", "duration": "0.081003", "kw": { "key": "DSBLE0005", "items": [ "nsslapd-dbcachesize", "nsslapd-db-logdirectory", "nsslapd-db-transaction-wait", "nsslapd-db-checkpoint-interval", "nsslapd-db-compactdb-interval", "nsslapd-db-compactdb-time", "nsslapd-db-transaction-batch-val", "nsslapd-db-transaction-batch-min-wait", "nsslapd-db-transaction-batch-max-wait", "nsslapd-db-logbuf-size", "nsslapd-db-page-size", "nsslapd-db-locks", "nsslapd-db-locks-monitoring-enabled", "nsslapd-db-locks-monitoring-threshold", "nsslapd-db-locks-monitoring-pause", "nsslapd-db-private-import-mem", "nsslapd-db-deadlock-policy" ], "msg": "Found configuration attributes that are not applicable for the configured backend type." } }, { "source": "ipahealthcheck.ds.backends", "check": "BackendsCheck", "result": "WARNING", "uuid": "17175c1a-12c2-4890-9725-5988022cf414", "when": "20250423071410Z", "duration": "0.081005", "kw": { "key": "DSBLE0005", "items": [ "nsslapd-dbcachesize", "nsslapd-db-logdirectory", "nsslapd-db-transaction-wait", "nsslapd-db-checkpoint-interval", "nsslapd-db-compactdb-interval", "nsslapd-db-compactdb-time", "nsslapd-db-transaction-batch-val", "nsslapd-db-transaction-batch-min-wait", "nsslapd-db-transaction-batch-max-wait", "nsslapd-db-logbuf-size", "nsslapd-db-page-size", "nsslapd-db-locks", "nsslapd-db-locks-monitoring-enabled", "nsslapd-db-locks-monitoring-threshold", "nsslapd-db-locks-monitoring-pause", "nsslapd-db-private-import-mem", "nsslapd-db-deadlock-policy" ], "msg": "Found configuration attributes that are not applicable for the configured backend type." } }, { "source": "ipahealthcheck.ds.replication", "check": "ReplicationCheck", "result": "ERROR", "uuid": "9c0b870b-688a-4468-afcd-f18f06650e41", "when": "20250423071414Z", "duration": "1.213910", "kw": { "key": "DSREPLLE0003", "items": [ "Replication", "Agreement" ], "msg": "The replication agreement ( catosg-it-prod-dc-a-euw2az1.internal.example.com) under "o=ipaca" is not in synchronization.\nStatus message: error (18) can't acquire replica (incremental update transient warning. backing off, will retry update later.)" } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "09ee1304-633c-48b3-841e-b2c3c431b2ba", "when": "20250423071418Z", "duration": "0.036548", "kw": { "msg": "Expected URI record missing", "key": "_kerberos.internal.example.com.:krb5srv:m:tcp: sg-it-prod-dc-a-euw2az1.internal.example.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "85a84e2a-ed3f-4238-ab8d-10762d81b362", "when": "20250423071418Z", "duration": "0.036573", "kw": { "msg": "Expected URI record missing", "key": "_kerberos.internal.example.com.:krb5srv:m:udp: sg-it-prod-dc-a-euw2az1.internal.example.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "87f324e1-ad3c-4284-a53e-2081e9082d7e", "when": "20250423071418Z", "duration": "0.036588", "kw": { "msg": "Expected URI record missing", "key": "_kerberos.internal.example.com.:krb5srv:m:tcp: sg-it-prod-dc-b-euw2az2.internal.example.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "9753a6c1-8d23-472d-a02b-a2a7608aaccf", "when": "20250423071418Z", "duration": "0.036601", "kw": { "msg": "Expected URI record missing", "key": "_kerberos.internal.example.com.:krb5srv:m:udp: sg-it-prod-dc-b-euw2az2.internal.example.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "9509d091-c3cb-4ea3-98b2-eca366a6d13b", "when": "20250423071418Z", "duration": "0.042577", "kw": { "msg": "Expected URI record missing", "key": "_kpasswd.internal.example.com.:krb5srv:m:tcp: sg-it-prod-dc-a-euw2az1.internal.example.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "56cb7ac2-1849-4706-b244-328b47f69d27", "when": "20250423071418Z", "duration": "0.042601", "kw": { "msg": "Expected URI record missing", "key": "_kpasswd.internal.example.com.:krb5srv:m:udp: sg-it-prod-dc-a-euw2az1.internal.example.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "c58fd746-a426-48f7-b832-700db19602ba", "when": "20250423071418Z", "duration": "0.042615", "kw": { "msg": "Expected URI record missing", "key": "_kpasswd.internal.example.com.:krb5srv:m:tcp: sg-it-prod-dc-b-euw2az2.internal.example.com." } }, { "source": "ipahealthcheck.ipa.idns", "check": "IPADNSSystemRecordsCheck", "result": "WARNING", "uuid": "c8f5c339-a4fb-4350-b02c-3906af5753cb", "when": "20250423071418Z", "duration": "0.042628", "kw": { "msg": "Expected URI record missing", "key": "_kpasswd.internal.example.com.:krb5srv:m:udp: sg-it-prod-dc-b-euw2az2.internal.example.com." } }, { "source": "pki.server.healthcheck.clones.connectivity_and_data", "check": "ClonesConnectivyAndDataCheck", "result": "ERROR", "uuid": "4d7ec689-fed8-42f2-ba8f-9e3163f69d70", "when": "20250423071425Z", "duration": "0.127883", "kw": { "status": "ERROR: pki-tomcat : Internal error testing CA clone. Host: dc-b-prod-it.internal.example.com Port: 443" } } ]
I've not tried the apache thing you suggested yet. It feels like just from the health check alone there are things that need to be addressed. Any suggestions on where to start? I'm surprised there are so many warnings and errors for a system which I consider to be working. Happy to try other things including the apache logs etc. I just didnt want to make this post even longer than it already is.
IMO the only area of concern is the ClonesConnectivityAnDataCheck error and it fits well with the apache configuration issue reported at https://bugzilla.redhat.com/show_bug.cgi?id=2350322 Try to follow the steps from comment 3.
flo
Thanks
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Yes I agree the "pki.server.healthcheck.clones.connectivity_and_data" is the main issue to fix. This is present when I run the health check on machine A and machine B. Both machines are reporting that machine B is the problem. I thought that might because A is the master but actually its showing both machines are master:
sudo ipa-replica-manage list sg-it-prod-dc-a-euw2az1.internal.example.com: master sg-it-prod-dc-b-euw2az2.internal.example.com: master
One thing I cant figure out it why its showing the wrong hostname in the "pki.server.healthcheck.clones.connectivity_and_data" check. Its showing dc-b-prod-it.internal.example.com when it should be sg-it-prod-dc-b-euw2az2.internal.example.com
I have no idea where its getting the wrong hostname from. I think a long time ago (years) I changed the hostname which has maybe caused this error.
{ "source": "pki.server.healthcheck.clones.connectivity_and_data", "check": "ClonesConnectivyAndDataCheck", "result": "ERROR", "uuid": "aed2abce-d117-4b06-9352-e030e05eb56d", "when": "20250423094822Z", "duration": "0.200636", "kw": { "status": "ERROR: pki-tomcat : Internal error testing CA clone. Host: dc-b-prod-it.internal.example.com Port: 443" }
Going to try your suggestion of creating the debug log, restarting apache etc. Will let you know what that gives shortly.
Whats the best way to show you logs? Pasting them in here feels like way too much text.
Some other information that might be helpful...
Running sudo ipa cert-show 1 on both machines returns the cert info in the command line.
But running sudo ipa-acme-manage pruning --config-show on both machines fails with: Failed to authenticate to CA REST API The ipa-acme-manage command failed.
In the web UI on the Authentication > Certificates page I could see some certs that looked old (they contained old hostnames from years back). I though this might be related to the errors so I manually revoked them. It got me thinking about how to remove old certs automatically which lead me to this page (https://freeipa.readthedocs.io/en/latest/designs/expired_certificate_pruning...) which is where I found the ipa-acme-manage pruning --config-show command.
tipex tipex via FreeIPA-users wrote:
Some other information that might be helpful...
Running sudo ipa cert-show 1 on both machines returns the cert info in the command line.
But running sudo ipa-acme-manage pruning --config-show on both machines fails with: Failed to authenticate to CA REST API The ipa-acme-manage command failed.
In the web UI on the Authentication > Certificates page I could see some certs that looked old (they contained old hostnames from years back). I though this might be related to the errors so I manually revoked them. It got me thinking about how to remove old certs automatically which lead me to this page (https://freeipa.readthedocs.io/en/latest/designs/expired_certificate_pruning...) which is where I found the ipa-acme-manage pruning --config-show command.
Several others have posted similar issues recently so I'll cut and paste bits and pieces from them.
I suspect that you're hitting bz2350322, https://bugzilla.redhat.com/show_bug.cgi?id=2350322
If you follow the steps from comment 3 it should allow PKI endpoints to be accessible.
Two things are needed: - link to the rewrite file - <valve> in tomcat configuration file
Then you can run ipactl start which should run the upgrade again.
The root cause is that your CA isn't fully functional and may explain some of the healthcheck output.
rob
Hi Rob
Thanks for your suggestion. I've done the following which has got me a step closer...
I created the following symlink: sudo ln -s /usr/share/pki/server/conf/Catalina/localhost/rewrite.config /etc/pki/pki-tomcat/Catalina/localhost/rewrite.config
Then edited this file: sudo vi /etc/pki/pki-tomcat/server.xml
And added in this line after line 132: <Valve className="org.apache.catalina.valves.rewrite.RewriteValve"/>
Ran the upgrade command: sudo ipa-server-upgrade
Now when I run sudo ipa-acme-manage pruning --config-show I get the following which is different to before and sounds less bad: Certificate pruning requires random serial numbers The ipa-acme-manage command failed.
I did the above on both machines. Machine A is the CA master.
The health check is still showing the same errors. Anyone got any ideas why the health check is using the wrong hostname for machine B and how I can fix it? I cant figure out where its getting the wrong hostname from. The only reference I can find to wrong host names is in some old certificates which I have revoked in the web UI.
tipex tipex via FreeIPA-users wrote:
Hi Rob
Thanks for your suggestion. I've done the following which has got me a step closer...
I created the following symlink: sudo ln -s /usr/share/pki/server/conf/Catalina/localhost/rewrite.config /etc/pki/pki-tomcat/Catalina/localhost/rewrite.config
Then edited this file: sudo vi /etc/pki/pki-tomcat/server.xml
And added in this line after line 132:
<Valve className="org.apache.catalina.valves.rewrite.RewriteValve"/>
Ran the upgrade command: sudo ipa-server-upgrade
Now when I run sudo ipa-acme-manage pruning --config-show I get the following which is different to before and sounds less bad: Certificate pruning requires random serial numbers The ipa-acme-manage command failed.
I did the above on both machines. Machine A is the CA master.
The health check is still showing the same errors. Anyone got any ideas why the health check is using the wrong hostname for machine B and how I can fix it? I cant figure out where its getting the wrong hostname from. The only reference I can find to wrong host names is in some old certificates which I have revoked in the web UI.
Its likely not the wrong hostname but an old one. I'm guessing a CA was removed and the PKI securitydomain wasn't updated for some reason. You can confirm this with:
pki securitydomain-show
If indeed that old host shows up you can remove it using https://rcritten.wordpress.com/2023/04/28/dogtag-pki-security-domain-managem...
rob
Interesting. I ran sudo pki securitydomain-show on machine B and got the following error: ERROR: UNKNOWN_ISSUER encountered on 'CN=sg-it-prod-dc-b-euw2az2.internal.example.com,O=INTERNAL.EXAMPLE.COM' results in a denied SSL server cert! SEVERE: FATAL: SSL alert sent: BAD_CERTIFICATE IOException: SocketException cannot write on socket: Failed to write to socket: (-5987) Invalid function argument.
So its got the right hostname but its obviously not happy with something. In the web UI of machine B I have revoked all but the most recent cert for CN=sg-it-prod-dc-b-euw2az2.internal.example.com,O=INTERNAL.EXAMPLE.COM I still get the same error though. I thought maybe an old cert was causing the issue.
In case is helpful I use LetEncrypt certs to provide HTTPS for the web UI. I feel like the certs shown in the web UI (Authentication > Certificates) are not my lets encrypt certs and instead are certs that FreeIPA creates. There is a total of 37 certs. If the prune command was working I could hopefully get this list down to only those that are needed. Although if I'm being honest I dont know what these certs are even used for. I only use FreeIPA for granting SSH access to Linux machines. I'm not using it as a CA but appreciate that it comes with CA built in.
tipex tipex via FreeIPA-users wrote:
Interesting. I ran sudo pki securitydomain-show on machine B and got the following error: ERROR: UNKNOWN_ISSUER encountered on 'CN=sg-it-prod-dc-b-euw2az2.internal.example.com,O=INTERNAL.EXAMPLE.COM' results in a denied SSL server cert! SEVERE: FATAL: SSL alert sent: BAD_CERTIFICATE IOException: SocketException cannot write on socket: Failed to write to socket: (-5987) Invalid function argument.
pki client init certutil -A -d ~/.dogtag/nssdb -n 'IPA CA' -t CT,C,C -a -i /etc/ipa/ca.crt
That should do it.
So its got the right hostname but its obviously not happy with something. In the web UI of machine B I have revoked all but the most recent cert for CN=sg-it-prod-dc-b-euw2az2.internal.example.com,O=INTERNAL.EXAMPLE.COM I still get the same error though. I thought maybe an old cert was causing the issue.
To be clear, you do not need to revoke old certificates. All it is doing is updating the status in LDAP and they will be in the CRL. It does nothing operationally unless you are enforcing OCSP/CRL usage (unlikely).
The cert status is completely independent of the healthcheck warning you are seeing. Note too that that particular check has been retired by the PKI team. So you can ignore it, or see if running my suggested commands let you peek at the securitydomain.
In case is helpful I use LetEncrypt certs to provide HTTPS for the web UI. I feel like the certs shown in the web UI (Authentication > Certificates) are not my lets encrypt certs and instead are certs that FreeIPA creates. There is a total of 37 certs. If the prune command was working I could hopefully get this list down to only those that are needed. Although if I'm being honest I dont know what these certs are even used for. I only use FreeIPA for granting SSH access to Linux machines. I'm not using it as a CA but appreciate that it comes with CA built in.
Pruning only removes expired certificates, with the purpose to keep the database from infinitely growing in the era of short-lived certificates. 37 is basically nothing in terms of size.
rob
Hi Rob
I ran the two commands and this has fixed the error with not being able to show the security domains. Listing them did indeed show that there were two old ones present. I followed the article you provided to remove them. The main error in the health check how now cleared so my system it significantly more healthy than it was before thanks to you and everyone else. Hats off for your knowledge and help.
Before attempting the dist upgrade again from Fedora 40 to 41 I wanted to sense check the things listed in the health check: - Error relating to IPv6 = Ignore, unless there is an easy way to get rid of it. - Warnings on configuration attributes that are not applicable for the configured backend type = Ignore, although it would be nice to get rid of these warnings if possible. - Warnings on missing uri records = Ignore as I cant add uri records in AWS route53. - Error for "ipahealthcheck.ds.replication". "msg": "The replication agreement (catosg-it-prod-dc-a-euw2az1.internal.example.com) under "o=ipaca" is not in synchronization.\nStatus message: error (18) can't acquire replica (incremental update transient warning. backing off, will retry update later.)"
I'm getting this last error on both machines. Feels like one that needs to be addressed before attempting an update. Any ideas?
On Чцв, 24 кра 2025, tipex tipex via FreeIPA-users wrote:
Hi Rob
I ran the two commands and this has fixed the error with not being able to show the security domains. Listing them did indeed show that there were two old ones present. I followed the article you provided to remove them. The main error in the health check how now cleared so my system it significantly more healthy than it was before thanks to you and everyone else. Hats off for your knowledge and help.
Before attempting the dist upgrade again from Fedora 40 to 41 I wanted to sense check the things listed in the health check:
- Error relating to IPv6 = Ignore, unless there is an easy way to get rid of it.
There is no way to clear it, at least now. Link-local IPv6 addresses aren't usable for running IPA servers on them, so we remind admins about that. In most cases we should probably do that only during initial installation and when we see those addresses in actual DNS entries, not just on the interfaces where they'll be almost always configured automatically.
- Warnings on configuration attributes that are not applicable for the
configured backend type = Ignore, although it would be nice to get rid of these warnings if possible.
- Warnings on missing uri records = Ignore as I cant add uri records in
AWS route53.
- Error for "ipahealthcheck.ds.replication". "msg": "The replication
agreement (catosg-it-prod-dc-a-euw2az1.internal.example.com) under "o=ipaca" is not in synchronization.\nStatus message: error (18) can't acquire replica (incremental update transient warning. backing off, will retry update later.)"
I'm getting this last error on both machines. Feels like one that needs to be addressed before attempting an update.
As it says, it is a temporary state reported by the replication process. It goes through these states all the time. If you have non-working replication due to inability to talk to another replica, you'd better fix networking problems (routing, firewalls, etc) that prevent the connection working.
Ok so actually the last error message can also be ignored. I've just tested by adding a temporary user to each server, and that user appears on the other server so replication is working in both directions.
Time to try the dist upgrade again but I will wait for tonight's backup to run so its got todays fixes in. So will likely be Friday or Monday when I try it. I will report back to confirm Vicente Quintans fix.
Just upgraded both my machines from Fedora 40 to 41 and its worked without needing to implement Vicente Quintans fix. Perhaps a FreeIPA fix has been pushed out since I last tried it. Or maybe the other errors people have been helping me fix has helped.
Running ipa-healthcheck again there are some new errors: "ipahealthcheck.ds.backends" "msg": "BDB is deprecated and should not be used as a backend."
Any way to fix this? Should this be fixed before I attempt to upgrade from Fedora 41 to 42? Maybe upgrading to 42 will fix this?
Thanks
tipex tipex via FreeIPA-users wrote:
Just upgraded both my machines from Fedora 40 to 41 and its worked without needing to implement Vicente Quintans fix. Perhaps a FreeIPA fix has been pushed out since I last tried it. Or maybe the other errors people have been helping me fix has helped.
It was fixed when you created the rewrite.config symlink and updated server.xml. A permanent fix needs to be implemented by dogtagpki for those who upgrade as you did. But this shouldn't cause you issues any more.
Running ipa-healthcheck again there are some new errors: "ipahealthcheck.ds.backends" "msg": "BDB is deprecated and should not be used as a backend."
This refers to the backend database used by 389-ds. BDB is the Berkeley Database and it has been supplanted by LMDB instead (at some point, I don't recall when in Fedora). I've cc'd a 389 dev to see what he thinks about this message.
Any way to fix this? Should this be fixed before I attempt to upgrade from Fedora 41 to 42? Maybe upgrading to 42 will fix this?
I'd at least wait for someone from 389 to chime in.
rob
Just a little nudge on the database issue when upgrading form Fedora 40 to 41: "BDB is deprecated and should not be used as a backend."
Thanks
I have the same problem however the fix did not quite work for me.
I have two FreeIPA servers running as a replica set, both running Fedora 40. I updated one to Fedora 41 and the ipa service would fail to start. Digging deeper I could see that when the service starts it tries to perform an upgrade. One error message said to look at /var/log/ipaupgrade.log. In this log I could see errors relating to failing to authenticate with the CA REST API.
I tried Vicente Quintans fix above by replacing all occurrences of “/rest” to “/v1” in /usr/lib/python3.13/site-packages/ipaserver/plugins/dogtag.py. This did fix some stuff as I could then start the ipa service which implies the upgrade part is now working. I can also sign into the web UI. The problem I see is that when I go to the authentication page in the web UI I get a popup error saying: IPA ERROR 4301: CertificateOperationError Certificate operation cannot be completed: Unable to communicate with he CMS (Failed to parse error response).
Because these are production servers I have rolled back. Problem is that Fedora 40 is end of life very soon. I’ve kept the broken machine, plus I can easily replicate the error if need be. Not sure what to do next.
I had the task of upgrading our freeIPA cluster from fedora 37 to the latest a few weeks ago and everything went smoothly until the last upgrade. Thank you for this post, it saved me a lot of time... Once I found it... 😳
I can't see an issue regarding this problem anywhere. Is it being tracked? Just wanna be sure that I won't shoot myself on the foot if I upgrade to RHEL10.
On 2025-04-04 15:38, Vicente Quintans via FreeIPA-users wrote:
We found this issue today, upgrading from Fedora 40 to Fedora 41.
In dogtagpki the /ca/rest/account/login endpoint (actually all /ca/rest endpoints) was moved to /ca/v1 in this commit:
https://github.com/dogtagpki/pki/commit/850e6b9e5128264a471e57b70ab8d970cf9162f8 <https://github.com/dogtagpki/pki/ commit/850e6b9e5128264a471e57b70ab8d970cf9162f8>We were able to complete the upgrade succesfully modifying the file /usr/lib/python3.13/site-packages/ipaserver/plugins/dogtag.py changing al "/ rest" to "/v1". With this modification ipa-server-upgrade completed successfully.
It seems there is some kind of version mismatch.
Greetings, Vicente Quintáns.
Carlos Mogas da Silva via FreeIPA-users wrote:
I can't see an issue regarding this problem anywhere. Is it being tracked? Just wanna be sure that I won't shoot myself on the foot if I upgrade to RHEL10.
It is tracked in https://issues.redhat.com/browse/RHCS-5788
The issue appears during upgrades. Since you can't in-place upgrade IdM between major releases you won't see it. This bug appears when an older installed RHEL 9 (or Fedora) version that lacked the config file is upgraded to a more recent RHEL 9 (or Fedora) version.
rob
On 2025-04-04 15:38, Vicente Quintans via FreeIPA-users wrote:
We found this issue today, upgrading from Fedora 40 to Fedora 41.
In dogtagpki the /ca/rest/account/login endpoint (actually all /ca/rest endpoints) was moved to /ca/v1 in this commit:
https://github.com/dogtagpki/pki/commit/850e6b9e5128264a471e57b70ab8d970cf91... <https://github.com/dogtagpki/pki/ commit/850e6b9e5128264a471e57b70ab8d970cf9162f8>
We were able to complete the upgrade succesfully modifying the file /usr/lib/python3.13/site-packages/ipaserver/plugins/dogtag.py changing al "/ rest" to "/v1". With this modification ipa-server-upgrade completed successfully.
It seems there is some kind of version mismatch.
Greetings, Vicente Quintáns.
On 2025-05-21 22:45, Rob Crittenden via FreeIPA-users wrote:
The issue appears during upgrades. Since you can't in-place upgrade IdM between major releases you won't see it. This bug appears when an older installed RHEL 9 (or Fedora) version that lacked the config file is upgraded to a more recent RHEL 9 (or Fedora) version.
I'm sorry, which config file? (Just to be sure I'm not missing it too). It happened to me on the upgrade from 9.5 to 9.6 of RHEL I think (can't really pinpoint the exact upgrade that borked it)
Thanks for the info! Carlos Mogas da Silva
Carlos Mogas da Silva via FreeIPA-users wrote:
On 2025-05-21 22:45, Rob Crittenden via FreeIPA-users wrote:
The issue appears during upgrades. Since you can't in-place upgrade IdM between major releases you won't see it. This bug appears when an older installed RHEL 9 (or Fedora) version that lacked the config file is upgraded to a more recent RHEL 9 (or Fedora) version.
I'm sorry, which config file? (Just to be sure I'm not missing it too). It happened to me on the upgrade from 9.5 to 9.6 of RHEL I think (can't really pinpoint the exact upgrade that borked it)
/etc/pki/pki-tomcat/Catalina/localhost/rewrite.config. It's in the bug report.
rob
On 2025-05-22 13:44, Rob Crittenden via FreeIPA-users wrote:
Carlos Mogas da Silva via FreeIPA-users wrote:
On 2025-05-21 22:45, Rob Crittenden via FreeIPA-users wrote:
The issue appears during upgrades. Since you can't in-place upgrade IdM between major releases you won't see it. This bug appears when an older installed RHEL 9 (or Fedora) version that lacked the config file is upgraded to a more recent RHEL 9 (or Fedora) version.
I'm sorry, which config file? (Just to be sure I'm not missing it too). It happened to me on the upgrade from 9.5 to 9.6 of RHEL I think (can't really pinpoint the exact upgrade that borked it)
/etc/pki/pki-tomcat/Catalina/localhost/rewrite.config. It's in the bug report.
rob
"You can't view this issue It may have been deleted or you don't have permission to view it."
This is what I get when trying to view it. And yes, I can confirm I don't have that file either :-/
Carlos Mogas da Silva via FreeIPA-users wrote:
On 2025-05-22 13:44, Rob Crittenden via FreeIPA-users wrote:
Carlos Mogas da Silva via FreeIPA-users wrote:
On 2025-05-21 22:45, Rob Crittenden via FreeIPA-users wrote:
The issue appears during upgrades. Since you can't in-place upgrade IdM between major releases you won't see it. This bug appears when an older installed RHEL 9 (or Fedora) version that lacked the config file is upgraded to a more recent RHEL 9 (or Fedora) version.
I'm sorry, which config file? (Just to be sure I'm not missing it too). It happened to me on the upgrade from 9.5 to 9.6 of RHEL I think (can't really pinpoint the exact upgrade that borked it)
/etc/pki/pki-tomcat/Catalina/localhost/rewrite.config. It's in the bug report.
rob
"You can't view this issue It may have been deleted or you don't have permission to view it."
This is what I get when trying to view it. And yes, I can confirm I don't have that file either :-/
It is mentioned earlier in the thread, along with how to correct it.
https://bugzilla.redhat.com/show_bug.cgi?id=2350322
rob
I got this bug today when upgrading to fedora 41. I applied Vincente’s fix - should I be worried or a future upgrade will fix things by itself?
On 22 May 2025, at 15:58, Rob Crittenden via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Carlos Mogas da Silva via FreeIPA-users wrote:
On 2025-05-22 13:44, Rob Crittenden via FreeIPA-users wrote:
Carlos Mogas da Silva via FreeIPA-users wrote:
On 2025-05-21 22:45, Rob Crittenden via FreeIPA-users wrote:
The issue appears during upgrades. Since you can't in-place upgrade IdM between major releases you won't see it. This bug appears when an older installed RHEL 9 (or Fedora) version that lacked the config file is upgraded to a more recent RHEL 9 (or Fedora) version.
I'm sorry, which config file? (Just to be sure I'm not missing it too). It happened to me on the upgrade from 9.5 to 9.6 of RHEL I think (can't really pinpoint the exact upgrade that borked it)
/etc/pki/pki-tomcat/Catalina/localhost/rewrite.config. It's in the bug report.
rob
"You can't view this issue It may have been deleted or you don't have permission to view it."
This is what I get when trying to view it. And yes, I can confirm I don't have that file either :-/
It is mentioned earlier in the thread, along with how to correct it.
https://bugzilla.redhat.com/show_bug.cgi?id=2350322
rob
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
I got this bug today when upgrading to fedora 41. I applied Vincente’s fix - should I be worried or a future upgrade will fix things by itself?
On 22 May 2025, at 15:58, Rob Crittenden via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Carlos Mogas da Silva via FreeIPA-users wrote:
On 2025-05-22 13:44, Rob Crittenden via FreeIPA-users wrote:
Carlos Mogas da Silva via FreeIPA-users wrote:
On 2025-05-21 22:45, Rob Crittenden via FreeIPA-users wrote:
The issue appears during upgrades. Since you can't in-place upgrade IdM between major releases you won't see it. This bug appears when an older installed RHEL 9 (or Fedora) version that lacked the config file is upgraded to a more recent RHEL 9 (or Fedora) version.
I'm sorry, which config file? (Just to be sure I'm not missing it too). It happened to me on the upgrade from 9.5 to 9.6 of RHEL I think (can't really pinpoint the exact upgrade that borked it)
/etc/pki/pki-tomcat/Catalina/localhost/rewrite.config. It's in the bug report.
rob
"You can't view this issue It may have been deleted or you don't have permission to view it."
This is what I get when trying to view it. And yes, I can confirm I don't have that file either :-/
It is mentioned earlier in the thread, along with how to correct it.
https://bugzilla.redhat.com/show_bug.cgi?id=2350322
rob
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Francis Augusto Medeiros-Logeay via FreeIPA-users wrote:
I got this bug today when upgrading to fedora 41. I applied Vincente’s fix - should I be worried or a future upgrade will fix things by itself?
You don't want Vincente's fix. You want the fix in the BZ. It is permanent.
rob
On 22 May 2025, at 15:58, Rob Crittenden via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Carlos Mogas da Silva via FreeIPA-users wrote:
On 2025-05-22 13:44, Rob Crittenden via FreeIPA-users wrote:
Carlos Mogas da Silva via FreeIPA-users wrote:
On 2025-05-21 22:45, Rob Crittenden via FreeIPA-users wrote:
The issue appears during upgrades. Since you can't in-place upgrade IdM between major releases you won't see it. This bug appears when an older installed RHEL 9 (or Fedora) version that lacked the config file is upgraded to a more recent RHEL 9 (or Fedora) version.
I'm sorry, which config file? (Just to be sure I'm not missing it too). It happened to me on the upgrade from 9.5 to 9.6 of RHEL I think (can't really pinpoint the exact upgrade that borked it)
/etc/pki/pki-tomcat/Catalina/localhost/rewrite.config. It's in the bug report.
rob
"You can't view this issue It may have been deleted or you don't have permission to view it."
This is what I get when trying to view it. And yes, I can confirm I don't have that file either :-/
It is mentioned earlier in the thread, along with how to correct it.
https://bugzilla.redhat.com/show_bug.cgi?id=2350322
rob
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Thanks a lot Rob, it worked better, as that fix from Vincente didn’t fix all the issues.
On 2 Jun 2025, at 21:33, Rob Crittenden rcritten@redhat.com wrote:
Francis Augusto Medeiros-Logeay via FreeIPA-users wrote: I got this bug today when upgrading to fedora 41. I applied Vincente’s fix - should I be worried or a future upgrade will fix things by itself?
You don't want Vincente's fix. You want the fix in the BZ. It is permanent.
rob
On 22 May 2025, at 15:58, Rob Crittenden via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Carlos Mogas da Silva via FreeIPA-users wrote: On 2025-05-22 13:44, Rob Crittenden via FreeIPA-users wrote: Carlos Mogas da Silva via FreeIPA-users wrote: On 2025-05-21 22:45, Rob Crittenden via FreeIPA-users wrote: The issue appears during upgrades. Since you can't in-place upgrade IdM between major releases you won't see it. This bug appears when an older installed RHEL 9 (or Fedora) version that lacked the config file is upgraded to a more recent RHEL 9 (or Fedora) version.
I'm sorry, which config file? (Just to be sure I'm not missing it too). It happened to me on the upgrade from 9.5 to 9.6 of RHEL I think (can't really pinpoint the exact upgrade that borked it)
/etc/pki/pki-tomcat/Catalina/localhost/rewrite.config. It's in the bug report.
rob
"You can't view this issue It may have been deleted or you don't have permission to view it."
This is what I get when trying to view it. And yes, I can confirm I don't have that file either :-/
It is mentioned earlier in the thread, along with how to correct it.
https://bugzilla.redhat.com/show_bug.cgi?id=2350322
rob
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Carlos Mogas da Silva -
Dustin Miller -
Florence Blanc-Renaud -
Francis Augusto Medeiros-Logeay -
Francis Augusto Medeiros-Logeay -
Rob Crittenden -
Russell Long -
tipex tipex -
Vicente Quintans