Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1155112

Summary: after code introduction to prevent clear text PW, now no logging occurs
Product: Red Hat OpenStack Reporter: Mike Abrams <mabrams>
Component: python-django-horizonAssignee: Matthias Runge <mrunge>
Status: CLOSED NOTABUG QA Contact: Ido Ovadia <iovadia>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 5.0 (RHEL 7)CC: aortega, jpichon, mabrams, mrunge, yeylon
Target Milestone: ---Keywords: ZStream
Target Release: 5.0 (RHEL 7)   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-10-22 09:20:09 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
/etc/openstack-dashboard/local_settings none

Description Mike Abrams 2014-10-21 11:44:56 UTC
Description of problem:

After a mod to disable clear text passwords in horizon logs, horizon now seems to log nothing at all.

Version-Release number of selected component (if applicable):

python-django-horizon-2014.1.3-1.el7ost.noarch

How reproducible:

manipulate log files to DEBUG level

Steps to Reproduce:
1. set log levels to debug
2. restart services
3. observe that nothing is logged upon authentication results

Actual results:

no logging occurs

Expected results:

some logging should occur (sans clear text passwords), especially at the DEBUG log level

Additional info:

Confirmed that new code to correct clear text passwords does make it to the install base.

Comment 2 Julie Pichon 2014-10-21 12:56:41 UTC
I have a system running with the following version, all logging correctly:

python-django-horizon-2014.1.2-2.el7ost.noarch

After upgrading to python-django-horizon-2014.1.3-1.el7ost.noarch and restarting httpd, I still see logging statements added to /var/log/horizon/horizon.log as expected, including at the DEBUG level. It looks like there is something else going on.

Could you provide your /etc/openstack-dashboard/local_settings file?
How did you install Horizon? Packstack?

I doubt it's related to the keystoneclient change on redacting passwords, I updated python-keystoneclient too to make sure and Horizon still logs a lot.

Comment 3 Mike Abrams 2014-10-22 07:25:23 UTC
Created attachment 949266 [details]
/etc/openstack-dashboard/local_settings

Comment 4 Mike Abrams 2014-10-22 07:26:25 UTC
/etc/openstack-dashboard/local_settings attached.

horizon install:  packstack was installed 'allinone'

Comment 5 Matthias Runge 2014-10-22 08:32:21 UTC
I have a recent AIO install. Like Julie said in #c2, it logs to /var/log/horizon/horizon.log
no matter if SELinux is permissive or enforcing.

Your local_settings looks sane to me.

Could you please:
- turn Selinux to permissive
- check that /var/log/horizon/horizon.log is growing

My horizon.log has those access rights:
[root@euler horizon]# ls -lZ /var/log/horizon/
-rw-r-----. apache apache system_u:object_r:httpd_log_t:s0 horizon.log

Comment 6 Mike Abrams 2014-10-22 08:39:40 UTC
selinux is set to permissive as per an earlier request.

/var/log/horizon/horizon.log is set to those directory permissions, but is not growing with each run of the following command:

curl -i -X POST http://localhost:5000/v2.0/tokens -H "Content-Type: application/json" -H "Accept: application/json" -H "User-Agent: python-keystoneclient" -d '{"auth": {"passwordCredentials": {"username": "admin", "password": "xxxxxxxxxxxxxxxxxxxxx"}}}'

However, /var/log/keystone/keystone.log does grow with each run of the above command.

What is generating your horizon log entries?

TIA,

Mike

Comment 7 Matthias Runge 2014-10-22 08:49:21 UTC
OK, that's totally clear. You're not hitting horizon at all.

You'd need to visit http://localhost/dashboard with a browser.

Comment 8 Mike Abrams 2014-10-22 08:57:28 UTC
thanks a lot; I see horizon logs responding now (and to answer the original bz, without a clear text pw).

Thanks and apologies for having the wrong verify method.

I will close if no objections.

Comment 9 Matthias Runge 2014-10-22 09:20:09 UTC
Thank you for looking into this. IMHO it's better to look twice rather than doing it hasty.