Bug 166230 - Admin Server management window misparses access log
Admin Server management window misparses access log
Status: CLOSED CURRENTRELEASE
Product: Red Hat Directory Server
Classification: Red Hat
Component: UI - Configuration (Show other bugs)
8.1
All Linux
medium Severity high
: DS8.1
: ---
Assigned To: Rich Megginson
Chandrasekar Kannan
:
: 165822 (view as bug list)
Depends On:
Blocks: 152373 249650 FDS1.2.0
  Show dependency treegraph
 
Reported: 2005-08-17 23:38 EDT by Sean Cotter
Modified: 2015-01-04 18:19 EST (History)
5 users (show)

See Also:
Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-29 18:57:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
diffs (1.87 KB, patch)
2008-12-11 10:50 EST, Rich Megginson
no flags Details | Diff
cvs commit log (276 bytes, text/plain)
2008-12-11 15:43 EST, Rich Megginson
no flags Details

  None (edit)
Description Sean Cotter 2005-08-17 23:38:03 EDT
+++ This bug was initially created as a clone of Bug #165822 +++

Description of problem:

In Red Hat Console in Red Hat Directory Server 7.1, the Admin Server's
management window misparses access log entries which include host names that
have a hyphen in them.  (Hyphens are permitted by RFC 1034.)  The - is 
treated as a field separator and the remainder of the hostname appears 
in the username field with the username.

Version-Release number of selected component (if applicable):
redhat-ds-7.1-2

Steps to Reproduce:
1.  Have a host with a hyphen in its shortname access Admin Server
2.  In Red Hat Console, open the Admin Server's management window,
    switch to the Configuration tab, and navigate to Administration
    Server -> Logs -> Accesses
  
Actual results:
Screenshot of bug is attached.  The actual log entry highlighted in the
screenshot as stored in /opt/redhat-ds/admin-serv/logs/access read:

sbonnevi-lt.rdu.redhat.com - - [09/Aug/2005:17:33:18 -0400] "GET /dist/download
HTTP/1.1" 200 4786
Comment 3 Rich Megginson 2008-12-11 10:50:09 EST
Created attachment 326632 [details]
diffs
Comment 4 Rich Megginson 2008-12-11 15:43:55 EST
Created attachment 326664 [details]
cvs commit log

Reviewed by: nkinder (Thanks!)
Fix Description: Look for ' - ' instead of just a '-'
Platforms tested: RHEL5
Flag Day: no
Doc impact: no
Comment 5 Rich Megginson 2008-12-19 19:23:23 EST
*** Bug 165822 has been marked as a duplicate of this bug. ***
Comment 6 Jenny Galipeau 2009-02-26 13:16:41 EST
I am seeing the IP address rather than a hostname in these log entries now - please advice.  Thanks Jenny
Comment 7 Rich Megginson 2009-02-26 13:49:28 EST
(In reply to comment #6)
> I am seeing the IP address rather than a hostname in these log entries now -
> please advice.  Thanks Jenny

Can the admin server do a reverse host/DNS lookup to determine the hostname from the IP address?  If so, you should see the hostname.  If not, you should see errors in the error log to that effect.
Comment 8 Jenny Galipeau 2009-02-26 14:01:21 EST
I can do a reverse lookup - but I do see the error messages too.

[jgalipea@jgalipea ~]$ ssh root@dhcp-100-2-17.bos.redhat.com
root@dhcp-100-2-17.bos.redhat.com's password: 
Last login: Thu Feb 26 11:47:17 2009
[root@dhcp-100-2-17 ~]# nslookup 10.16.2.17
Server:         10.16.255.2
Address:        10.16.255.2#53

17.2.16.10.in-addr.arpa name = dhcp-100-2-17.bos.redhat.com.

[Thu Feb 26 13:14:41 2009] [notice] [client 10.16.2.17] admserv_host_ip_check: ap_get_remote_host could not resolve 10.16.2.17
Comment 9 Rich Megginson 2009-02-26 14:13:53 EST
(In reply to comment #8)
> I can do a reverse lookup - but I do see the error messages too.
> 
> [jgalipea@jgalipea ~]$ ssh root@dhcp-100-2-17.bos.redhat.com
> root@dhcp-100-2-17.bos.redhat.com's password: 
> Last login: Thu Feb 26 11:47:17 2009
> [root@dhcp-100-2-17 ~]# nslookup 10.16.2.17
> Server:         10.16.255.2
> Address:        10.16.255.2#53
> 
> 17.2.16.10.in-addr.arpa name = dhcp-100-2-17.bos.redhat.com.
> 
> [Thu Feb 26 13:14:41 2009] [notice] [client 10.16.2.17] admserv_host_ip_check:
> ap_get_remote_host could not resolve 10.16.2.17

Looks like you need to enable HostnameLookups
http://httpd.apache.org/docs/1.3/mod/core.html#hostnamelookups

It is a security thing - it takes resources to do a reverse lookup every time - so you want to make sure that your server can handle the extra load

We should add this to the docs

You should be able to add this directive to /etc/dirsrv/admin-serv/console.conf

We should also add this directive to the default console.conf we ship
Comment 10 Jenny Galipeau 2009-02-26 14:23:17 EST
I am going to re-open the bug to take care of the console.conf directive.  If we add it - do we still need to doc it?
Comment 11 Steve Bonneville 2009-02-26 14:57:44 EST
When I filed the original bug #165822 against the Netscape Enterprise Server version of Admin Server, I wasn't thinking about the implication that the equivalent of Apache's 'HostnameLookups on' was set, and what this implied about all the extra DNS lookups that were being generated.

It might actually make sense from a performance perspective to leave this off to avoid generating the extra DNS lookups...the logs were (are?) in Common Log Format, so an offline tool like Webalizer could be used by an admin to analyze the logs if the hostnames matter.

On the other hand, I can see the argument in favor of turning them on to avoid a change in logging behavior.  Not sure how much overhead this actually adds, either.
Comment 12 Rich Megginson 2009-02-26 16:16:42 EST
We still need to add documentation for it for existing installations, in case they want to see hostnames in the logs.
Comment 13 Rich Megginson 2009-02-26 18:46:59 EST
Added HostnameLookups

Checking in console.conf.in;
/cvs/dirsec/adminserver/admserv/cfgstuff/console.conf.in,v  <--  console.conf.in
new revision: 1.5; previous revision: 1.4
done
Comment 14 Jenny Galipeau 2009-03-19 11:04:14 EDT
fix verified - DS 8.1 RHEL 5

# By default, the log files will only log the client IP address,
# not the hostname, to avoid having to do a DNS lookup
# for each request.  If HostnameLookups is off, you will also see
# notices in the error log saying that
# admserv_host_ip_check: ap_get_remote_host could not resolve the IP address
# If you want to have hostnames in the log instead of IP addresses, change
# this to "on".  Use a value of "double" to make it do double reverse DNS
lookups.
HostnameLookups off


with HostnameLookups on

[root@dhcp-100-2-17 ~]# tail -f /var/log/dirsrv/admin-serv/access 
dhcp-100-2-17.bos.redhat.com - admin [19/Mar/2009:11:04:25 -0400] "GET
/admin-serv/authenticate HTTP/1.0" 200 421
dhcp-100-2-17.bos.redhat.com - uid=admin, ou=Administrators,
ou=TopologyManagement, o=NetscapeRoot [19/Mar/2009:11:04:32 -0400] "GET
/admin-serv/tasks/operation/StatusPing HTTP/1.0" 200 19
dhcp-100-2-17.bos.redhat.com - uid=admin, ou=Administrators,
ou=TopologyManagement, o=NetscapeRoot [19/Mar/2009:11:04:32 -0400] "GET
/admin-serv/tasks/operation/StatusPing HTTP/1.0" 200 19
dhcp-100-2-17.bos.redhat.com - uid=admin, ou=Administrators,
ou=TopologyManagement, o=NetscapeRoot [19/Mar/2009:11:04:34 -0400] "POST
/admin-serv/tasks/Configuration/ServerSetup HTTP/1.0" 200 134
Comment 15 Deon Ballard 2009-04-19 22:53:14 EDT
I added a really brief section to the new admin server guide that mentions setting that parameter to perform DNS lookups and use hostnames in the logs:
http://elladeon.fedorapeople.org/DirServer/8.1/admin-server/Administration_Server_Basics-Logging_Options.html#hostnames-ipaddresses
Comment 16 Chandrasekar Kannan 2009-04-29 18:57:54 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0455.html

Note You need to log in before you can comment on or make changes to this bug.