[Freeipa-users] Re: Disaster Recovery Architecture for IPA servers setup replicating in full mesh
On 11/4/19 8:44 AM, Saurabh Garg via FreeIPA-users wrote: Hi All, Could anyone please share a Disaster Recovery Architecture for IPA servers setup replicating in full mesh with the details of backup and restore procedure. Regards, sgarg ___ 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 Hi, The RHEL7 and RHEL8 documentation sets contain the following topics that may be of interest: - Planning the replica topology [1], in the book "Planning Identity Management" This section provides examples of replica topology and recommendations to achieve disaster recovery. - Backing up and restoring Identity Management [2] in the book "Linux Domain Identity, Authentication, and Policy Guide" - Backup and Restore in IdM/IPA [3] As a general rule, we recommend rebuilding from an existing replica, rather than using backup-restore. HTH, flo [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/planning_identity_management/planning-the-replica-topology_planning-dns-and-host-names [2] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/backup-restore [3] https://access.redhat.com/solutions/626303 ___ 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
[Freeipa-users] Re: FreeIPA having problem after upgrading from Fedora 30 to 31
Hello,
I think I have similar problem like this one, I have spent 2 days on this and I
am helpless.
ipa.service fails to start, just as ipactl start like this:
systemd[1]: Starting Identity, Policy, Audit...
ipactl[1497]: IPA version error: data needs to be upgraded (expected version
'4.8.1-4.fc31', current version '4.8.1-1.fc30')
ipactl[1497]: Automatically running upgrade, for details see
/var/log/ipaupgrade.log
ipactl[1497]: Be patient, this may take a few minutes.
ipactl[1497]: Automatic upgrade failed: Either /etc/krb5.keytab or
/etc/samba/samba.keytab are missing or unreadable
ipactl[1497]: Update complete
ipactl[1497]: Upgrading the configuration of the IPA services
ipactl[1497]: [Verifying that root certificate is published]
ipactl[1497]: [Migrate CRL publish directory]
ipactl[1497]: CRL tree already moved
ipactl[1497]: [Verifying that KDC configuration is using ipa-kdb backend]
ipactl[1497]: [Fix DS schema file syntax]
ipactl[1497]: Syntax already fixed
ipactl[1497]: [Removing RA cert from DS NSS database]
ipactl[1497]: RA cert already removed
ipactl[1497]: [Enable sidgen and extdom plugins by default]
ipactl[1497]: [Updating HTTPD service IPA configuration]
ipactl[1497]: [Updating HTTPD service IPA WSGI configuration]
ipactl[1497]: [Migrating from mod_nss to mod_ssl]
ipactl[1497]: Already migrated to mod_ssl
ipactl[1497]: [Moving HTTPD service keytab to gssproxy]
ipactl[1497]: [Removing self-signed CA]
ipactl[1497]: [Removing Dogtag 9 CA]
ipactl[1497]: [Checking for deprecated KDC configuration files]
ipactl[1497]: [Checking for deprecated backups of Samba configuration files]
ipactl[1497]: [Add missing CA DNS records]
ipactl[1497]: IPA CA DNS records already processed
ipactl[1497]: [Removing deprecated DNS configuration options]
ipactl[1497]: [Ensuring minimal number of connections]
ipactl[1497]: [Updating GSSAPI configuration in DNS]
ipactl[1497]: [Updating pid-file configuration in DNS]
ipactl[1497]: [Checking global forwarding policy in named.conf to avoid
conflicts with automatic empty zones]
ipactl[1497]: Changes to named.conf have been made, restart named
ipactl[1497]: [Upgrading CA schema]
ipactl[1497]: CA schema update complete (no changes)
ipactl[1497]: [Verifying that CA audit signing cert has 2 year validity]
ipactl[1497]: [Update certmonger certificate renewal configuration]
ipactl[1497]: Certmonger certificate renewal configuration already up-to-date
ipactl[1497]: [Enable PKIX certificate path discovery and validation]
ipactl[1497]: PKIX already enabled
ipactl[1497]: [Authorizing RA Agent to modify profiles]
ipactl[1497]: [Authorizing RA Agent to manage lightweight CAs]
ipactl[1497]: [Ensuring Lightweight CAs container exists in Dogtag database]
ipactl[1497]: [Adding default OCSP URI configuration]
ipactl[1497]: [Ensuring CA is using LDAPProfileSubsystem]
ipactl[1497]: [Migrating certificate profiles to LDAP]
ipactl[1497]: IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and
run command ipa-server-upgrade manually.
ipactl[1497]: Unexpected error - see /var/log/ipaupgrade.log for details:
ipactl[1497]: RemoteRetrieveError: Failed to authenticate to CA REST API
ipactl[1497]: The ipa-server-upgrade command failed. See
/var/log/ipaupgrade.log for more information
ipactl[1497]: See the upgrade log for more details and/or run
/usr/sbin/ipa-server-upgrade again
ipactl[1497]: Aborting ipactl
systemd[1]: ipa.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: ipa.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Identity, Policy, Audit.
systemd[1]: ipa.service: Consumed 14.815s CPU time.
The main error for me is "RemoteRetrieveError: Failed to authenticate to CA
REST API". dirsrv starts successfully, then listens on socket, ports 389
udp/tcp and 636 tcp, functions as expect (I can login to server, I can login to
Web UI, ldapsearch works, etc.), even pki-tomcatd@pki-tomcat.service can be
started manually successfully, but fails with this upgrade procedure. I have
tried to troubleshoot TLS issues, but all certificates and ciphers seem OK, I
have even upgraded jss from updates-testing repository as mentioned in other
cases, but the upgrade still fails.The error from /var/log/ipaupgrade.log is:
2019-11-03T23:42:53Z DEBUG request GET
https://:8443/ca/rest/account/login
2019-11-03T23:42:53Z DEBUG request body ''
2019-11-03T23:42:54Z DEBUG response status 500
2019-11-03T23:42:54Z DEBUG response headers Content-Type:
text/html;charset=utf-8
Content-Language: en
Content-Length: 2384
Date: Sun, 03 Nov 2019 23:42:54 GMT
Connection: close
2019-11-03T23:42:54Z DEBUG response body (decoded): b'HTTP Status 500 \xe2\x80\x93 Internal Server
Errorh1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
h2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
h3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
body
[Freeipa-users] Re: FreeIPA having problem after upgrading from Fedora 30 to 31
The stack trace of my last mail should be hitting this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1755634 On Fri, Nov 1, 2019 at 3:20 PM Patrick Dung wrote: > Hello all, > 1) Resent, I used reply instead of reply all in the last mail. > > 2) I tailed the dirsrv log and perform a manual ipa-server-upgrade. > I didn't found connection refused log in the dirsrv. > > 3) > BTW, I had another ipa server that is a replica. Originally both freeipa > server had upgrade problem. > On the replica server, I tried to install jss-4.6.2-2.fc31.x86_64 > (according to https://bugzilla.redhat.com/show_bug.cgi?id=1766451) > The ipa-server-upgrade is successfully run on the replica server. But > there is problem when I access: > https://replica:8443, the error message is shown in below. > HTTP Status 500 – Internal Server Error > -- > > *Type* Exception Report > > *Message* org.apache.jasper.JasperException: Unable to compile class for > JSP > > *Description* The server encountered an unexpected condition that > prevented it from fulfilling the request. > > *Exception* > > org.apache.jasper.JasperException: org.apache.jasper.JasperException: Unable > to compile class for JSP > > org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:604) > > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:422) > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385) > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329) > javax.servlet.http.HttpServlet.service(HttpServlet.java:741) > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > java.lang.reflect.Method.invoke(Method.java:498) > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:282) > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:279) > java.security.AccessController.doPrivileged(Native Method) > javax.security.auth.Subject.doAsPrivileged(Subject.java:549) > org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:314) > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:170) > java.security.AccessController.doPrivileged(Native Method) > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > java.lang.reflect.Method.invoke(Method.java:498) > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:282) > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:279) > java.security.AccessController.doPrivileged(Native Method) > javax.security.auth.Subject.doAsPrivileged(Subject.java:549) > org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:314) > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:253) > > *Root Cause* > > org.apache.jasper.JasperException: Unable to compile class for JSP > > org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:619) > > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:399) > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:385) > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:329) > javax.servlet.http.HttpServlet.service(HttpServlet.java:741) > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > java.lang.reflect.Method.invoke(Method.java:498) > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:282) > org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:279) > java.security.AccessController.doPrivileged(Native Method) > javax.security.auth.Subject.doAsPrivileged(Subject.java:549) > org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:314) > > org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:170) > java.security.AccessController.doPrivileged(Native Method) > org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53) > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >
[Freeipa-users] Re: number of topology segments for 3 servers clean setup?
I followed the thread, and I’m not sure you ever got an answer. Generally ipa replica install seems to create one replication agreement. The exact relationships for 3 servers depends upon which master the replica was created from. It could be 2 replicas talking to the original, or 3 in a line. But either way there’s two replication agreements. The obvious thing for 3 servers is a complete triangle. Without that, failure of the wrong node could cause the other two to become disconnected from each other, which is probably not desirable. So you’d want to add the third node. Whichever one is missing. I assume the reason they don’t add more replicas by default is that in larger configurations you probably don’t want a fully-connected mesh. ipa-replica-install has no way of knowing what your final topology is going to be, and no way to guess what replication agreements you really need. So it does the minimal necessary to maintain connectivity. > On Oct 29, 2019, at 4:44 AM, lejeczek via FreeIPA-users > wrote: > > hi everyone, > > I wanted to ask about number of segments after a clean IPA setup with 3 > servers. > > I see for both 'domain' & 'ca' two segments created by master/replica > installations, which makes me wonder - should there not be three? no/yes > & why? > > many thanks, L. > > ___ > 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 ___ 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
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
Wulf, Along these lines -- in ipaupgrade.log, I see: 2019-11-02T10:55:29Z DEBUG args=['/bin/systemctl', 'start', 'pki-tomcatd@pki-tomcat.service'] 2019-11-02T10:57:00Z DEBUG Process finished, return code=1 2019-11-02T10:57:00Z DEBUG stdout= 2019-11-02T10:57:00Z DEBUG stderr=Job for pki-tomcatd@pki-tomcat.service failed because a timeout was exceeded. See "systemctl status pki-tomcatd@pki-tomcat.service" and "journalctl -xe" for details. However, the pki-tomcat-ca-debug.2019-11-02.log you posted doesn't have any entries from around this time. Additionally, though perhaps a red herring, I see: 2019-11-02T10:55:29Z DEBUG Failed to check CA status: cannot connect to 'http://ipa.mailstation.de:8080/ca/admin/ca/getStatus': [Errno 111] Connection refused So perhaps the Tomcat debug logs from 10:50 -> 11:00 might be a good place to start? Maybe there's an hour shift in there, but I assume the logs would have similar timestamps since they're on the same system. - Alex - Original Message - > From: "Alexander Bokovoy via FreeIPA-users" > > To: "Wulf C. Krueger" > Cc: "FreeIPA users list" , "Alex > Scheel" , "Alexander > Bokovoy" > Sent: Monday, November 4, 2019 11:50:41 AM > Subject: [Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) > fails to start > > On ma, 04 marras 2019, Wulf C. Krueger wrote: > >Hello Alex, > > > >On 2019-11-04 16:49, Alex Scheel via FreeIPA-users wrote: > >>These backtraces from Wulf don't end in JSS at all. In fact, JSS seems to > >>initalize > >>just fine around 2019-11-02 11:55:34 in the Tomcat debug log. This seems > >>like a bug > >>in the LDAPProfileSubsystem of Dogtag. > > > >Thanks for chiming in - any suggestions on how to proceed? > > > >I'm wondering why the LDAP server *only* seems to be listening on that > >socket (cf. log) instead of (or in addition to) ports 389/636. > > I think it is a red herring. ipa-server-upgrade switches off 389/636 > during upgrade to prevent inconsistency leaking out for replication. If > something unexpected happens during the upgrade when these ports were > disabled, they might be left disabled. The question is why it was left > in a state it was left in. > > -- > / 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 > ___ 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
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
On ma, 04 marras 2019, Wulf C. Krueger wrote: Hello Alex, On 2019-11-04 16:49, Alex Scheel via FreeIPA-users wrote: These backtraces from Wulf don't end in JSS at all. In fact, JSS seems to initalize just fine around 2019-11-02 11:55:34 in the Tomcat debug log. This seems like a bug in the LDAPProfileSubsystem of Dogtag. Thanks for chiming in - any suggestions on how to proceed? I'm wondering why the LDAP server *only* seems to be listening on that socket (cf. log) instead of (or in addition to) ports 389/636. I think it is a red herring. ipa-server-upgrade switches off 389/636 during upgrade to prevent inconsistency leaking out for replication. If something unexpected happens during the upgrade when these ports were disabled, they might be left disabled. The question is why it was left in a state it was left in. -- / 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
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
Hello Alex, On 2019-11-04 16:49, Alex Scheel via FreeIPA-users wrote: These backtraces from Wulf don't end in JSS at all. In fact, JSS seems to initalize just fine around 2019-11-02 11:55:34 in the Tomcat debug log. This seems like a bug in the LDAPProfileSubsystem of Dogtag. Thanks for chiming in - any suggestions on how to proceed? I'm wondering why the LDAP server *only* seems to be listening on that socket (cf. log) instead of (or in addition to) ports 389/636. Best regards, Wulf ___ 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
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
On ma, 04 marras 2019, Alex Scheel wrote: - Original Message - From: "Alexander Bokovoy via FreeIPA-users" To: "FreeIPA users list" Cc: "Wulf C. Krueger" , "Alexander Bokovoy" Sent: Sunday, November 3, 2019 4:08:09 AM Subject: [Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start On la, 02 marras 2019, Wulf C. Krueger via FreeIPA-users wrote: >Hello, > >my FreeIPA installation was working well on Fedora 30. After upgrading >to F31, though, it fails to start: > > ># ipactl start >IPA version error: data needs to be upgraded (expected version >'4.8.1-4.fc31', current version '4.8.1-1.fc30') >Automatically running upgrade, for details see /var/log/ipaupgrade.log >Be patient, this may take a few minutes. >Automatic upgrade failed: Update complete >Upgrading the configuration of the IPA services >[Verifying that root certificate is published] >[Migrate CRL publish directory] >CRL tree already moved >IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run >command ipa-server-upgrade manually. >Unexpected error - see /var/log/ipaupgrade.log for details: >CalledProcessError: CalledProcessError(Command ['/bin/systemctl', >'start', 'pki-tomcatd@pki-tomcat.service'] returned non-zero exit >status 1: 'Job for pki-tomcatd@pki-tomcat.service failed because a >timeout was exceeded.\nSee "systemctl status >pki-tomcatd@pki-tomcat.service" and "journalctl -xe" for details.\n') >The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for >more information > >See the upgrade log for more details and/or run >/usr/sbin/ipa-server-upgrade again >Aborting ipactl > > >Logs: > >ipaupgrade.log: https://mailstation.de/ipa-logs/ipaupgrade.log >pki-tomcatd@pki-tomcat log: >https://mailstation.de/ipa-logs/pki-tomc...@pki-tomcat.log >pki-tomcat-ca-debug log: >https://mailstation.de/ipa-logs/pki-tomcat-ca-debug.2019-11-02.log > >So it looks like the LDAP server isn't reachable but its log says it's >running: https://mailstation.de/ipa-logs/dir...@mailstation-de.log > >There's nothing listening on ports 389 and 636, though. > >Help would be highly appreciated. This looks like https://bugzilla.redhat.com/show_bug.cgi?id=1766451 Do you have updates-testing repository enabled? It should provide an update for jss package. Alexander, I don't think this is that bug at all. That bug (#1766451) was an issue in JSS with a stacktrace ending in the NativeProxy class, caused by an improvement in NativeProxy. That lead to a member used in the equals(...) comparator to be NULL, which is less than ideal. These backtraces from Wulf don't end in JSS at all. In fact, JSS seems to initalize just fine around 2019-11-02 11:55:34 in the Tomcat debug log. This seems like a bug in the LDAPProfileSubsystem of Dogtag. Thanks, Alex. I hope you can help then with debugging it? As to #1766451, we seem to hit it in FreeIPA CI regularly. I hope https://bodhi.fedoraproject.org/updates/FEDORA-2019-4129cdf50b will get pushed soon... -- / 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
[Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
- Original Message - > From: "Alexander Bokovoy via FreeIPA-users" > > To: "FreeIPA users list" > Cc: "Wulf C. Krueger" , "Alexander Bokovoy" > > Sent: Sunday, November 3, 2019 4:08:09 AM > Subject: [Freeipa-users] Re: FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) > fails to start > > On la, 02 marras 2019, Wulf C. Krueger via FreeIPA-users wrote: > >Hello, > > > >my FreeIPA installation was working well on Fedora 30. After upgrading > >to F31, though, it fails to start: > > > > > ># ipactl start > >IPA version error: data needs to be upgraded (expected version > >'4.8.1-4.fc31', current version '4.8.1-1.fc30') > >Automatically running upgrade, for details see /var/log/ipaupgrade.log > >Be patient, this may take a few minutes. > >Automatic upgrade failed: Update complete > >Upgrading the configuration of the IPA services > >[Verifying that root certificate is published] > >[Migrate CRL publish directory] > >CRL tree already moved > >IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run > >command ipa-server-upgrade manually. > >Unexpected error - see /var/log/ipaupgrade.log for details: > >CalledProcessError: CalledProcessError(Command ['/bin/systemctl', > >'start', 'pki-tomcatd@pki-tomcat.service'] returned non-zero exit > >status 1: 'Job for pki-tomcatd@pki-tomcat.service failed because a > >timeout was exceeded.\nSee "systemctl status > >pki-tomcatd@pki-tomcat.service" and "journalctl -xe" for details.\n') > >The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for > >more information > > > >See the upgrade log for more details and/or run > >/usr/sbin/ipa-server-upgrade again > >Aborting ipactl > > > > > >Logs: > > > >ipaupgrade.log: https://mailstation.de/ipa-logs/ipaupgrade.log > >pki-tomcatd@pki-tomcat log: > >https://mailstation.de/ipa-logs/pki-tomc...@pki-tomcat.log > >pki-tomcat-ca-debug log: > >https://mailstation.de/ipa-logs/pki-tomcat-ca-debug.2019-11-02.log > > > >So it looks like the LDAP server isn't reachable but its log says it's > >running: https://mailstation.de/ipa-logs/dir...@mailstation-de.log > > > >There's nothing listening on ports 389 and 636, though. > > > >Help would be highly appreciated. > > This looks like https://bugzilla.redhat.com/show_bug.cgi?id=1766451 > Do you have updates-testing repository enabled? It should provide an > update for jss package. Alexander, I don't think this is that bug at all. That bug (#1766451) was an issue in JSS with a stacktrace ending in the NativeProxy class, caused by an improvement in NativeProxy. That lead to a member used in the equals(...) comparator to be NULL, which is less than ideal. These backtraces from Wulf don't end in JSS at all. In fact, JSS seems to initalize just fine around 2019-11-02 11:55:34 in the Tomcat debug log. This seems like a bug in the LDAPProfileSubsystem of Dogtag. My 2c. - Alex > > -- > / 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 > ___ 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
[Freeipa-users] Re: Not able to login into IPA UI after full server backup, error says: "Your session has expired. Please re-login."
On Mon, Nov 4, 2019 at 11:35 AM Saurabh Garg via FreeIPA-users wrote: > > All IPA services work else than IPA UI login. For Admin account it throws the > error "Your session has expired. Please re-login." > > # cat /var/log/httpd/error_log | grep error > [Mon Nov 04 03:30:57.855012 2019] [:error] [pid 26165] ipa: INFO: Starting > new HTTP connection (1): ipaserver.home.mydomain.com > [Mon Nov 04 03:30:57.858643 2019] [:error] [pid 26165] ipa: INFO: Starting > new HTTPS connection (1): ipaserver.home.mydomain.com > [Mon Nov 04 04:14:57.945806 2019] [:error] [pid 31576] ipa: INFO: *** PROCESS > START *** > [Mon Nov 04 04:14:57.973073 2019] [:error] [pid 31579] ipa: INFO: *** PROCESS > START *** > [Mon Nov 04 04:14:57.977523 2019] [:error] [pid 31578] ipa: INFO: *** PROCESS > START *** > [Mon Nov 04 04:14:57.993765 2019] [:error] [pid 31577] ipa: INFO: *** PROCESS > START *** > [Mon Nov 04 04:15:26.343676 2019] [:error] [pid 31578] ipa: INFO: Starting > new HTTP connection (1): ipaserver.home.mydomain.com > [Mon Nov 04 04:15:26.347563 2019] [:error] [pid 31578] ipa: INFO: Starting > new HTTPS connection (1): ipaserver.home.mydomain.com > > # kinit admin > Password for ad...@mydomain.com: > # klist > Ticket cache: KEYRING:persistent:0:0 > Default principal: ad...@mydomain.com > Valid starting Expires Service principal > 11/04/2019 04:39:36 11/05/2019 04:39:23 krbtgt/mydomain@mydomain.com > > # ipa -v ping > ipa: INFO: trying https://ipaserver.home.mydomain.com/ipa/json > ipa: INFO: [try 1]: Forwarding 'schema' to json server > 'https://ipaserver.home.mydomain.com/ipa/json' > ipa: INFO: trying https://ipaserver.home.mydomain.com/ipa/session/json > ipa: INFO: [try 1]: Forwarding 'ping/1' to json server > 'https://ipaserver.home.mydomain.com/ipa/session/json' > --- > IPA server version 4.6.5. API version 2.231 > --- > > > > # kinit -kt /var/lib/ipa/gssproxy/http.keytab h...@mydomain.com > kinit: Keytab contains no suitable keys for h...@mydomain.com while getting > initial credentials > # kinit -kt /var/lib/ipa/gssproxy/http.keytab HTTP/ipaserver.home.mydomain.com > # klist > Ticket cache: KEYRING:persistent:0:krb_ccache_jTRWw54 > Default principal: HTTP/ipaserver.home.mydomain@mydomain.com > Valid starting Expires Service principal > 11/04/2019 04:42:26 11/05/2019 04:42:26 krbtgt/mydomain@mydomain.com I don't think there is an issue there. > Can someone please help me with what might me the issue? > Any suggestions? First: * make sure you have chronyd or ntpd running on both client and server and that they both report being in sync to proper time sources * grep for "AVC" in /var/log/audit/audit.log Then, fully clean your browser's cache fully and retry. It might be faster/easier to use another browser profile or a local user created for testing. The above error_log file is truncated. Please show all lines from a clean attempt (e.g. don't use grep). François > PS: I have already restarted restart krb5kdc,sssd & httpd services. > > Thanks in advance, > Saurabh Garg > ___ > 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 ___ 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
[Freeipa-users] Not able to login into IPA UI after full server backup, error says: "Your session has expired. Please re-login."
All IPA services work else than IPA UI login. For Admin account it throws the error "Your session has expired. Please re-login." # cat /var/log/httpd/error_log | grep error [Mon Nov 04 03:30:57.855012 2019] [:error] [pid 26165] ipa: INFO: Starting new HTTP connection (1): ipaserver.home.mydomain.com [Mon Nov 04 03:30:57.858643 2019] [:error] [pid 26165] ipa: INFO: Starting new HTTPS connection (1): ipaserver.home.mydomain.com [Mon Nov 04 04:14:57.945806 2019] [:error] [pid 31576] ipa: INFO: *** PROCESS START *** [Mon Nov 04 04:14:57.973073 2019] [:error] [pid 31579] ipa: INFO: *** PROCESS START *** [Mon Nov 04 04:14:57.977523 2019] [:error] [pid 31578] ipa: INFO: *** PROCESS START *** [Mon Nov 04 04:14:57.993765 2019] [:error] [pid 31577] ipa: INFO: *** PROCESS START *** [Mon Nov 04 04:15:26.343676 2019] [:error] [pid 31578] ipa: INFO: Starting new HTTP connection (1): ipaserver.home.mydomain.com [Mon Nov 04 04:15:26.347563 2019] [:error] [pid 31578] ipa: INFO: Starting new HTTPS connection (1): ipaserver.home.mydomain.com # kinit admin Password for ad...@mydomain.com: # klist Ticket cache: KEYRING:persistent:0:0 Default principal: ad...@mydomain.com Valid starting Expires Service principal 11/04/2019 04:39:36 11/05/2019 04:39:23 krbtgt/mydomain@mydomain.com # ipa -v ping ipa: INFO: trying https://ipaserver.home.mydomain.com/ipa/json ipa: INFO: [try 1]: Forwarding 'schema' to json server 'https://ipaserver.home.mydomain.com/ipa/json' ipa: INFO: trying https://ipaserver.home.mydomain.com/ipa/session/json ipa: INFO: [try 1]: Forwarding 'ping/1' to json server 'https://ipaserver.home.mydomain.com/ipa/session/json' --- IPA server version 4.6.5. API version 2.231 --- # kinit -kt /var/lib/ipa/gssproxy/http.keytab h...@mydomain.com kinit: Keytab contains no suitable keys for h...@mydomain.com while getting initial credentials # kinit -kt /var/lib/ipa/gssproxy/http.keytab HTTP/ipaserver.home.mydomain.com # klist Ticket cache: KEYRING:persistent:0:krb_ccache_jTRWw54 Default principal: HTTP/ipaserver.home.mydomain@mydomain.com Valid starting Expires Service principal 11/04/2019 04:42:26 11/05/2019 04:42:26 krbtgt/mydomain@mydomain.com Can someone please help me with what might me the issue? Any suggestions? PS: I have already restarted restart krb5kdc,sssd & httpd services. Thanks in advance, Saurabh Garg ___ 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
