I checked on the certificates as you suggested and none show they are
expired. Any other suggestions?
sudo getcert list | grep expires
expires: 2019-08-25 20:51:47 UTC
expires: 2019-08-25 20:50:38 UTC
expires: 2019-08-25 20:50:58 UTC
expires: 2035-10-13 20:50:26 UTC
expires: 2019-08-26 20:50:37 UTC
expires: 2019-08-25 20:50:37 UTC
expires: 2019-09-17 20:50:47 UTC
expires: 2019-09-17 20:50:37 UTC
expires: 2018-08-14 19:29:31 UTC
On Mon, Oct 16, 2017 at 2:32 PM, Rob Crittenden <rcritten(a)redhat.com> wrote:
Kristian Petersen wrote:
> Here is the last user_show I did:
> [Mon Oct 16 10:27:25.164027 2017] [:error] [pid 24937] ipa: INFO:
> nesretep(a)CHEM.BYU.EDU <mailto:nesretep@CHEM.BYU.EDU>: batch:
> user_show(u'aaburton', rights=True, all=True): SUCCESS
> [Mon Oct 16 10:27:25.216336 2017] [:error] [pid 24937] ipa: INFO:
> nesretep(a)CHEM.BYU.EDU <mailto:nesretep@CHEM.BYU.EDU>: batch:
> pwpolicy_show(None, rights=True, user=u'aaburton', all=True): SUCCESS
> [Mon Oct 16 10:27:25.269772 2017] [:error] [pid 24937] ipa: INFO:
> nesretep(a)CHEM.BYU.EDU <mailto:nesretep@CHEM.BYU.EDU>: batch:
> krbtpolicy_show(u'aaburton', rights=True, all=True): SUCCESS
> [Mon Oct 16 10:27:25.277407 2017] [:error] [pid 24937] ipa: ERROR:
> ra.find(): Unable to communicate with CMS ([Errno 111] Connection refused)
> [Mon Oct 16 10:27:25.277553 2017] [:error] [pid 24937] ipa: INFO:
> nesretep(a)CHEM.BYU.EDU <mailto:nesretep@CHEM.BYU.EDU>: batch:
> cert_find(None, sizelimit=0, all=True, user=(u'aaburton',)):
> CertificateOperationError
> [Mon Oct 16 10:27:25.277807 2017] [:error] [pid 24937] ipa: INFO:
> [jsonserver_session] nesretep(a)CHEM.BYU.EDU
> <mailto:nesretep@CHEM.BYU.EDU>: batch(({u'params':
([u'aaburton'],
> {u'all': True, u'rights': True}), u'method':
u'user_show'}, {u'params':
> ([], {u'all': True, u'user': u'aaburton', u'rights':
True}), u'method':
> u'pwpolicy_show'}, {u'params': ([u'aaburton'],
{u'all': True, u'rights':
> True}), u'method': u'krbtpolicy_show'}, {u'params': ([],
{u'sizelimit':
> 0, u'all': True, u'user': (u'aaburton',)}),
u'method': u'cert_find'}),
> version=u'2.228'): SUCCESS
>
> I think this supports my suspicion that the failure of pki-tomcatd to
> start the last time I updated IPA is related somehow to his issue
> (correct me if I am wrong). I have been struggling to figure out why
> that failed in the first place.
>
So there is a recently reported issue in the UI when cert-find fails,
https://pagure.io/freeipa/issue/7202
As for why tomcat doesn't start I'd run getcert list first to check on the
status of your certificates. My guess is one or more is expired.
rob
> Pavel:
> The issue with the menu showing all of the options shown in the image I
> sent only lasts until I load another user. The menu initially appears
> (before a refresh) like this:
> Inline image 1
> This is how I would expect it to look for a disabled user. It stays
> like that until I refresh the page, then it looks like the other image I
> sent.
>
> On Fri, Oct 13, 2017 at 8:24 AM, Rob Crittenden <rcritten(a)redhat.com
> <mailto:rcritten@redhat.com>> wrote:
>
> Rob Crittenden wrote:
>
> Rob Crittenden via FreeIPA-users wrote:
>
> Kristian Petersen via FreeIPA-users wrote:
>
> Very possibly a bug if others are experiencing this as
> well. I am
> running IPA v4.5.0 on RHEL 7.4 are you running in a
> similar environment?
>
>
> You might be able to figure out what is going on using
> something like
> the Firefox dev console. In it you could see the JSON
> returned by the
> IPA server, look for errors in the JS console, etc. to try
> to identify
> where the issue is.
>
> And/or file a bug, but since you have a reproducer the more
> data you can
> gather to narrow the cause the easier it will be to fix.
>
> rob
>
>
> Kirstian gave me some javascript errors. We've seen other
> oddness in the
> UI when cert_find() fails. Can you look in
> /var/log/httpd/error_log to
> see if there is a traceback or a failure when you load the user
> in the UI?
>
>
> And one more thing to check. I'm pretty sure under Network you can
> drill down into the details to see what data is returned by the
> server. Find the last user_show('youruser')
>
> In the result there should be a long blog for attributelevelrights.
> Find userpassword in there and ensure the rights contains w, like:
>
> u'userpassword': u'swo'
>
>
> rob
>
>
>
> On Thu, Oct 12, 2017 at 10:25 AM, Givaldo Lins
> <givaldolins(a)gmail.com <mailto:givaldolins@gmail.com>
> <mailto:givaldolins@gmail.com
> <mailto:givaldolins@gmail.com>>> wrote:
>
> I noticed the same thing weeks ago and I am using
> the same
> workaround that Kristian. Might it be a bug on webui?
>
> —
> Givaldo Lins
>
> On Oct 12, 2017, at 9:05 AM, Kristian Petersen via
> FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org
> <mailto:freeipa-users@lists.fedorahosted.org>
> <mailto:freeipa-users@lists.fedorahosted.org
>
> <mailto:freeipa-users@lists.fedorahosted.org>>> wrote:
>
> When trying to reset a password for a user and I
> pull up the page
> for a specific user, it shows them as being
> disabled even if they
> aren't. This causes the reset password option
> to be grayed-out
> among other things. I verified the users
> weren't actually
> disabled by running ipa user-show <username> on
> a few of them. If
> you do a user search in the WebUI or show all of
> the users in the
> system the status shows correctly on that page
> of the Web UI.
> This problem appears to happen across the
> replicas as well.
>
> After playing around with the Web UI for a bit I
> found that a
> refresh of the user's page gives back access to
> the Reset Password
> option, but just for that view. If you go to
> another user the
> problem resurfaces. I have confirmed this
> happens in both chrome
> and firefox running in both Windows or Linux.
> The httpd logs show
> nothing there, /var/log/ipa logs aren't helpful
> either.
>
> IPA got some updates recently (which also appear
> to have broken
> pki-tomcatd), but I'm not sure if the two
> problems are related.
>
> --
> Kristian Petersen
> System Administrator
> Dept. of Chemistry and Biochemistry
> _______________________________________________
> FreeIPA-users mailing list --
> freeipa-users(a)lists.fedorahosted.org
> <mailto:freeipa-users@lists.fedorahosted.org>
> <mailto:freeipa-users@lists.fedorahosted.org
> <mailto:freeipa-users@lists.fedorahosted.org>>
> To unsubscribe send an email to
> freeipa-users-leave(a)lists.fedorahosted.org
> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>
> <mailto:freeipa-users-leave@lists.fedorahosted.org
> <mailto:freeipa-users-leave@lists.fedorahosted.org>>
>
>
>
>
>
> --
> Kristian Petersen
> System Administrator
> Dept. of Chemistry and Biochemistry
>
>
> _______________________________________________
> FreeIPA-users mailing list --
> freeipa-users(a)lists.fedorahosted.org
> <mailto:freeipa-users@lists.fedorahosted.org>
> To unsubscribe send an email to
> freeipa-users-leave(a)lists.fedorahosted.org
> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>
> _______________________________________________
> FreeIPA-users mailing list --
> freeipa-users(a)lists.fedorahosted.org
> <mailto:freeipa-users@lists.fedorahosted.org>
> To unsubscribe send an email to
> freeipa-users-leave(a)lists.fedorahosted.org
> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>
>
>
>
>
>
> --
> Kristian Petersen
> System Administrator
> Dept. of Chemistry and Biochemistry
>
--
Kristian Petersen
System Administrator
Dept. of Chemistry and Biochemistry