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 <rcrit...@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:
>> nesre...@chem.byu.edu <mailto:nesre...@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:
>> nesre...@chem.byu.edu <mailto:nesre...@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:
>> nesre...@chem.byu.edu <mailto:nesre...@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:
>> nesre...@chem.byu.edu <mailto:nesre...@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] nesre...@chem.byu.edu
>> <mailto:nesre...@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 <rcrit...@redhat.com
>> <mailto:rcrit...@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
>>                 <givaldol...@gmail.com <mailto:givaldol...@gmail.com>
>>                 <mailto:givaldol...@gmail.com
>>                 <mailto:givaldol...@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@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@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-le...@lists.fedorahosted.org
>>                     <mailto:freeipa-users-le...@lists.fedorahosted.org>
>>
>>                     <mailto:freeipa-users-le...@lists.fedorahosted.org
>>                     <mailto:freeipa-users-le...@lists.fedorahosted.org>>
>>
>>
>>
>>
>>
>>                 --
>>                 Kristian Petersen
>>                 System Administrator
>>                 Dept. of Chemistry and Biochemistry
>>
>>
>>                 _______________________________________________
>>                 FreeIPA-users mailing list --
>>                 freeipa-users@lists.fedorahosted.org
>>                 <mailto:freeipa-users@lists.fedorahosted.org>
>>                 To unsubscribe send an email to
>>                 freeipa-users-le...@lists.fedorahosted.org
>>                 <mailto:freeipa-users-le...@lists.fedorahosted.org>
>>
>>             _______________________________________________
>>             FreeIPA-users mailing list --
>>             freeipa-users@lists.fedorahosted.org
>>             <mailto:freeipa-users@lists.fedorahosted.org>
>>             To unsubscribe send an email to
>>             freeipa-users-le...@lists.fedorahosted.org
>>             <mailto:freeipa-users-le...@lists.fedorahosted.org>
>>
>>
>>
>>
>>
>>
>> --
>> Kristian Petersen
>> System Administrator
>> Dept. of Chemistry and Biochemistry
>>
>
>


-- 
Kristian Petersen
System Administrator
Dept. of Chemistry and Biochemistry
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to