Broken WebUI

[Kristian Petersen]

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.

[Givaldo Lins]

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  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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Kristian Petersen]

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?

On Thu, Oct 12, 2017 at 10:25 AM, Givaldo Lins 
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 <
> [e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Rob Crittenden]

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
> On Thu, Oct 12, 2017 at 10:25 AM, Givaldo Lins <[e-mail]
> > 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
> <[e-mail]
> <mailto:[e-mail]>> 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 -- [e-mail]
> > <mailto:[e-mail]>
> > To unsubscribe send an email to
> > [e-mail]
> > <mailto:[e-mail]>
>
> --
> Kristian Petersen
> System Administrator
> Dept. of Chemistry and Biochemistry
>
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Rob Crittenden]

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?

rob
> > On Thu, Oct 12, 2017 at 10:25 AM, Givaldo Lins <[e-mail]
> > > 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
> > <[e-mail]
> > <mailto:[e-mail]>> 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 -- [e-mail]
> > > <mailto:[e-mail]>
> > > To unsubscribe send an email to
> > > [e-mail]
> > > <mailto:[e-mail]>
> >
> > --
> > Kristian Petersen
> > System Administrator
> > Dept. of Chemistry and Biochemistry
> >
> > FreeIPA-users mailing list -- [e-mail]
> > To unsubscribe send an email to
> > [e-mail]
>
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Rob Crittenden]

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 <[e-mail]
> > > > 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
> > > <[e-mail]
> > > <mailto:[e-mail]>> 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 -- [e-mail]
> > > > <mailto:[e-mail]>
> > > > To unsubscribe send an email to
> > > > [e-mail]
> > > > <mailto:[e-mail]>
> > >
> > > --
> > > Kristian Petersen
> > > System Administrator
> > > Dept. of Chemistry and Biochemistry
> > >
> > > FreeIPA-users mailing list -- [e-mail]
> > > To unsubscribe send an email to
> > > [e-mail]
> >
> > FreeIPA-users mailing list -- [e-mail]
> > To unsubscribe send an email to
> > [e-mail]

[Kristian Petersen]

Another thing I spotted in the UI: after a refresh of a page that loads
whith the user appearing as if they were disabled the actions menu has
extra options as shown in the image below.  You have both enable and
disable, as well as two deletes.

​

On Fri, Oct 13, 2017 at 8:24 AM, Rob Crittenden  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 <[e-mail]
> > > > > 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
> > > > <[e-mail]
> > > > <mailto:[e-mail]>> 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 -- [e-mail]
> > > > > <mailto:[e-mail]>
> > > > > To unsubscribe send an email to
> > > > > [e-mail]
> > > > > <mailto:[e-mail]>
> > > >
> > > > --
> > > > Kristian Petersen
> > > > System Administrator
> > > > Dept. of Chemistry and Biochemistry
> > > >
> > > > FreeIPA-users mailing list -- [e-mail]
> > > > To unsubscribe send an email to
> > > > [e-mail]
> > >
> > > FreeIPA-users mailing list -- [e-mail]
> > > To unsubscribe send an email to
> > > [e-mail]

[Pavel Vomacka]

On 10/13/2017 05:35 PM, Kristian Petersen wrote:
> Another thing I spotted in the UI: after a refresh of a page that 
> loads whith the user appearing as if they were disabled the actions 
> menu has extra options as shown in the image below.  You have both 
> enable and disable, as well as two deletes.

Does it happen only temporarily or does it stay in this state for the 
whole time? This is the way how the page is created and only then, after 
loading all information, unnecessary items are hidden or grayed out. If 
this is temporary and it disappears after while it is expected behavior 
and it can show that you have slow connection to your IPA master.

Could you please check steps which Rob wrote in previous mails?
> ​
>
> On Fri, Oct 13, 2017 at 8:24 AM, Rob Crittenden <[e-mail] 
> > 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
>             <[e-mail] <mailto:[e-mail]>
>             <mailto:[e-mail]
>             <mailto:[e-mail]>>> 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
>                 <[e-mail]
>             <mailto:[e-mail]>
>                 <mailto:[e-mail]
>             <mailto:[e-mail]>>> 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 --
>                 [e-mail]
>                 <mailto:[e-mail]>
>                     <mailto:[e-mail]
>                 <mailto:[e-mail]>>
>                     To unsubscribe send an email to
>                 [e-mail]
>                 <mailto:[e-mail]>
>                    
>                 <mailto:[e-mail]
>                 <mailto:[e-mail]>>
>
>
>
>
>
>             --
>             Kristian Petersen
>             System Administrator
>             Dept. of Chemistry and Biochemistry
>
>
>             _______________________________________________
>             FreeIPA-users mailing list --
>             [e-mail]
>             <mailto:[e-mail]>
>             To unsubscribe send an email to
>             [e-mail]
>             <mailto:[e-mail]>
>
>         _______________________________________________
>         FreeIPA-users mailing list --
>         [e-mail]
>         <mailto:[e-mail]>
>         To unsubscribe send an email to
>         [e-mail]
>         <mailto:[e-mail]>
>
>
>
>
>
>
> -- 
> Kristian Petersen
> System Administrator
> Dept. of Chemistry and Biochemistry

[Kristian Petersen]

Here is the last user_show I did:
[Mon Oct 16 10:27:25.164027 2017] [:error] [pid 24937] ipa: INFO:
[e-mail]: batch: user_show(u'aaburton', rights=True, all=True):
SUCCESS
[Mon Oct 16 10:27:25.216336 2017] [:error] [pid 24937] ipa: INFO:
[e-mail]: 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:
[e-mail]: 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:
[e-mail]: 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] [e-mail]: 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.

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:
[image: 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  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 <[e-mail]
> > > > > 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
> > > > <[e-mail]
> > > > <mailto:[e-mail]>> 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 -- [e-mail]
> > > > > <mailto:[e-mail]>
> > > > > To unsubscribe send an email to
> > > > > [e-mail]
> > > > > <mailto:[e-mail]>
> > > >
> > > > --
> > > > Kristian Petersen
> > > > System Administrator
> > > > Dept. of Chemistry and Biochemistry
> > > >
> > > > FreeIPA-users mailing list -- [e-mail]
> > > > To unsubscribe send an email to
> > > > [e-mail]
> > >
> > > FreeIPA-users mailing list -- [e-mail]
> > > To unsubscribe send an email to
> > > [e-mail]

[Rob Crittenden]

Kristian Petersen wrote:
> Here is the last user_show I did:
> [Mon Oct 16 10:27:25.164027 2017] [:error] [pid 24937] ipa: INFO:
> [e-mail] : batch:
> user_show(u'aaburton', rights=True, all=True): SUCCESS
> [Mon Oct 16 10:27:25.216336 2017] [:error] [pid 24937] ipa: INFO:
> [e-mail] : 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:
> [e-mail] : 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:
> [e-mail] : 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] [e-mail]
> : 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 <[e-mail]
> > 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
>             <[e-mail] <mailto:[e-mail]>
>             <mailto:[e-mail]
>             <mailto:[e-mail]>>> 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
>                 <[e-mail]
>             <mailto:[e-mail]>
>                 <mailto:[e-mail]
>             <mailto:[e-mail]>>> 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 --
>                 [e-mail]
>                 <mailto:[e-mail]>
>                     <mailto:[e-mail]
>                 <mailto:[e-mail]>>
>                     To unsubscribe send an email to
>                     [e-mail]
>                 <mailto:[e-mail]>
>
>                 <mailto:[e-mail]
>                 <mailto:[e-mail]>>
>
>
>
>
>
>             --
>             Kristian Petersen
>             System Administrator
>             Dept. of Chemistry and Biochemistry
>
>
>             _______________________________________________
>             FreeIPA-users mailing list --
>             [e-mail]
>             <mailto:[e-mail]>
>             To unsubscribe send an email to
>             [e-mail]
>             <mailto:[e-mail]>
>
>         _______________________________________________
>         FreeIPA-users mailing list --
>         [e-mail]
>         <mailto:[e-mail]>
>         To unsubscribe send an email to
>         [e-mail]
>         <mailto:[e-mail]>
>
>
>
>
>
>
> --
> Kristian Petersen
> System Administrator
> Dept. of Chemistry and Biochemistry

[Kristian Petersen]

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  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:
> > [e-mail] : batch:
> > user_show(u'aaburton', rights=True, all=True): SUCCESS
> > [Mon Oct 16 10:27:25.216336 2017] [:error] [pid 24937] ipa: INFO:
> > [e-mail] : 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:
> > [e-mail] : 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:
> > [e-mail] : 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] [e-mail]
> > : 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 <[e-mail]
> > > 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
> >             <[e-mail] <mailto:[e-mail]>
> >             <mailto:[e-mail]
> >             <mailto:[e-mail]>>> 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
> >                 <[e-mail]
> >             <mailto:[e-mail]>
> >                 <mailto:[e-mail]
> >
> >             <mailto:[e-mail]>>> 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 --
> >                 [e-mail]
> >                 <mailto:[e-mail]>
> >                     <mailto:[e-mail]
> >                 <mailto:[e-mail]>>
> >                     To unsubscribe send an email to
> >                     [e-mail]
> >                 <mailto:[e-mail]>
> >
> >                 <mailto:[e-mail]
> >                 <mailto:[e-mail]>>
> >
> >
> >
> >
> >
> >             --
> >             Kristian Petersen
> >             System Administrator
> >             Dept. of Chemistry and Biochemistry
> >
> >
> >             _______________________________________________
> >             FreeIPA-users mailing list --
> >             [e-mail]
> >             <mailto:[e-mail]>
> >             To unsubscribe send an email to
> >             [e-mail]
> >             <mailto:[e-mail]>
> >
> >         _______________________________________________
> >         FreeIPA-users mailing list --
> >         [e-mail]
> >         <mailto:[e-mail]>
> >         To unsubscribe send an email to
> >         [e-mail]
> >         <mailto:[e-mail]>
> >
> >
> >
> >
> >
> >
> > --
> > Kristian Petersen
> > System Administrator
> > Dept. of Chemistry and Biochemistry

[Givaldo Lins]

Ipa-server 4.4.0-14 in RHEL 7.3

—
Givaldo Lins
> On Oct 12, 2017, at 9:53 AM, Kristian Petersen  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?
> > On Thu, Oct 12, 2017 at 10:25 AM, Givaldo Lins  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  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 -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
>
> -- 
> Kristian Petersen
> System Administrator
> Dept. of Chemistry and Biochemistry