On Пан, 03 лют 2025, Russell Long via FreeIPA-users wrote:
Here is the log, sorry for the delay. Logs are redacted, but the only thing
changed was the domain names and DNs.
The upgrade log chokes on the CA application not being registered in
tomcat container (the corresponding /ca/rest/... path is giving 404
error).
So we get back to the same point as before. An upgrade has been in
progress but somehow was interrupted. Directory server was having some
of listeners disabled to avoid external communication during the upgrade
and those listeners weren't recovered due to an interruption. You
recovered some of them but it looks like there is still something that
messes up.
If you are saying all services are working fine, just the upgrade kicks
in every time 'ipactl restart' is run (which is part of ipa.service
machinery), it means the logged IPA data version is older than what IPA
sees in the RPM database. Temporarily, this can be fixed by looking at
/var/lib/ipa/sysupgrade/sysupgrade.state and changing ipa.data_version
value to be exact same as the RPM package version-release values.
However, it would help to understand why an upgrade causes CA apps to
fail to register with the tomcat container. It looks like we have at
least three such cases on this list over past week or so, all on CentOS
9 Stream, so there might be something?
May be you can install sos report tool and collect a larger amount of
data altogether so that we can see a greater picture?
# dnf install sos
# sos report --profile={identity,security,system,services,network} --clean -a
This should produce logs with consistently obfuscated hostnames and
domains across all files. You can add more domains to obfuscate with
`--domains={domain1,domain2,..}` to `sos report` tool.
On Wed, Jan 29, 2025 at 4:51 PM Rob Crittenden <rcrit...@redhat.com> wrote:
Russ Long via FreeIPA-users wrote:
> Things are functional, however IPA still thinks it needs an upgrade, so
any time the service restarts, it breaks again.
>
If you have time to run the upgrade again and send us a compressed
/var/log/ipaupgrade.log we can see if we can identify the root cause.
rob
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
