[Freeipa-users] Re: Broken WebUI

[Marek Wiewiórka via FreeIPA-users]

Hi Guys - we are facing exactly the same issue. 
Did you find any root cause of it or any temporary workaround besides 
refreshing a page each time ?
Any hints welcome.

Thanks!
Marek
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Broken WebUI

[Kristian Petersen via FreeIPA-users]

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:
>> 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 : 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 : 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 : 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
>> : 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 > > 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
>> mailto:givaldol...@gmail.com>
>> > >> wro

[Freeipa-users] Re: Broken WebUI

[Rob Crittenden via FreeIPA-users]

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 : 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 : 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 : 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 : 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
: 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 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
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
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
 

[Freeipa-users] Re: Broken WebUI

[Kristian Petersen via FreeIPA-users]

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: 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: 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: 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: 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: 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 >>> > 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  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
> D

[Freeipa-users] Re: Broken WebUI

[Pavel Vomacka via FreeIPA-users]

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 > 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
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
    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 
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] Re: Broken WebUI

[Kristian Petersen via FreeIPA-users]

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 >>> > 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  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
> 
> To unsubscribe send an email to
> freeipa-users-le...@lists.fedorahosted.org
> 
>




 --
 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

 ___
>>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>> To unsubscribe send an email to
>>> freeipa-users-le...@lists.fedorahosted.org
>>>
>>
>>
>


-- 
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

[Freeipa-users] Re: Broken WebUI

[Rob Crittenden via FreeIPA-users]

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 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
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  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

To unsubscribe send an email to
freeipa-users-le...@lists.fedorahosted.org






--
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


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-le...@lists.fedorahosted.org



___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Broken WebUI

[Rob Crittenden via FreeIPA-users]

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 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
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  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

To unsubscribe send an email to
freeipa-users-le...@lists.fedorahosted.org






--
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


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Broken WebUI

[Givaldo Lins via FreeIPA-users]

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 
>>>  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
>>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> 
> 
> 
> -- 
> 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

[Freeipa-users] Re: Broken WebUI

[Rob Crittenden via FreeIPA-users]

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 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
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  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

To unsubscribe send an email to
freeipa-users-le...@lists.fedorahosted.org






--
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


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Broken WebUI

[Kristian Petersen via FreeIPA-users]

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 <
> 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
>  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
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
>


-- 
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

[Freeipa-users] Re: Broken WebUI

[Givaldo Lins via FreeIPA-users]

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 
>  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
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org