Bug 846448 - admin-serv logs filling with "admserv_host_ip_check: ap_get_remote_host could not resolve <ip address>"
Summary: admin-serv logs filling with "admserv_host_ip_check: ap_get_remote_host could...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: 389-admin
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-07 20:11 UTC by John Ellson
Modified: 2020-09-13 20:16 UTC (History)
4 users (show)

Fixed In Version: 389-admin-1.1.36-1.el7dsrv
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-12 01:02:48 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 434 0 None None None 2020-09-13 20:16:13 UTC
Red Hat Product Errata RHBA-2015:1094 0 normal SHIPPED_LIVE Red Hat Directory Server bug fix and enhancement update 2015-06-12 05:02:14 UTC

Description John Ellson 2012-08-07 20:11:01 UTC
Description of problem:
/var/log/dirsrv/admin-serv/error is growing at about one-message/second with messages like:

[Tue Aug 07 10:51:44 2012] [notice] [client 130.8.46.114] admserv_host_ip_check: ap_get_remote_host could not resolve 130.8.46.114

I seen the suggestion to use IP address instead of FQDN, but thats a work-around, not a bug fix.  

The host can resolve itself forward and backwards using nslookup locally.

Version-Release number of selected component (if applicable):
389-admin-1.1.29-1.fc17.x86_64

How reproducible:
100%

Steps to Reproduce:
1. start-dirserv
2. server dirsrc-admin start
3. tail -f /var/log/dirsrv/admin-serv/error
  
Actual results:
errors messages about once/second

Expected results:
no errors

Additional info:

Comment 1 Rich Megginson 2012-08-08 14:16:47 UTC
By default the admin server uses hostname based access control.
http://port389.org/wiki/Howto:AdminServerLDAPMgmt#How_to_set_the_hosts.2FIP_addresses_allowed_to_access_the_Admin_Server

This requires the ability to do reverse hostname lookups, which are not enabled in Apache by default.  See HostnameLookups in /etc/dirsrv/admin-serv/console.conf

So you could
* turn off hostname based access control
or
* turn on hostname lookups
or
* use a default LogLevel that suppresses those messages

I don't think this is a bug, so I'm closing.

Comment 2 John Ellson 2012-08-09 16:51:40 UTC
I don't think this is reasonable.    The admin server was configured by from the rpm, or from the setup perl script.  Its not reasonable to expect a new user to know how to make this change.    It should be set up to work by default.


I looked up the reference and it says:

   ldapmodify [-x] -D "cn=directory manager" -w password
   dn: dn of your admin server config entry
   changetype: modify
   replace: nsAdminAccessAddresses
   nsAdminAccessAddresses: 192.168.1.*
   -
   replace: nsAdminAccessHosts
   nsAdminAccessHosts: *

so already I'm lost!  How am  supposed to know the "dn of your admin server config entry"

Comment 3 Rich Megginson 2012-08-09 16:57:14 UTC
(In reply to comment #2)
> I don't think this is reasonable.    The admin server was configured by from
> the rpm, or from the setup perl script.  Its not reasonable to expect a new
> user to know how to make this change.    It should be set up to work by
> default.

Ok - then what should the default be?

> 
> 
> I looked up the reference and it says:
> 
>    ldapmodify [-x] -D "cn=directory manager" -w password
>    dn: dn of your admin server config entry
>    changetype: modify
>    replace: nsAdminAccessAddresses
>    nsAdminAccessAddresses: 192.168.1.*
>    -
>    replace: nsAdminAccessHosts
>    nsAdminAccessHosts: *
> 
> so already I'm lost!  How am  supposed to know the "dn of your admin server
> config entry"

I guess you missed the section just above this in the page:
http://port389.org/wiki/Howto:AdminServerLDAPMgmt#How_to_find_the_Admin_Server_configuration_entry

You say your logs are filling with these messages - how severe is this problem?  Are you running out of disk space?  Are there some other errors being masked because they are too hard to find/notice?

Comment 4 Rich Megginson 2012-08-22 02:56:39 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/434

Comment 5 Fedora End Of Life 2013-07-04 02:59:48 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 6 Fedora End Of Life 2013-08-01 09:55:53 UTC
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 8 Amita Sharma 2015-04-15 10:13:36 UTC
According to patch https://fedorahosted.org/389/attachment/ticket/434/0001-Ticket-434-admin-serv-logs-filling-with-admserv_host.patch , It seems that we have enhanced our admin error message log to display that how user can get rid of these messages. I am getting exactly the same enhanced message ::

==============================================================
[Tue Apr 14 15:54:34.938123 2015] [:warn] [pid 5971:tid 139707287873280] [client 10.65.201.126:55067] admserv_host_ip_check: Access control based on hostname [*.englab.pnq.redhat.com] is being used, but the server could not resolve the hostname of client IP address [10.65.201.126].  Either enable HostnameLookups in console.conf (by default it is off for performance reasons), or turn off access control by host/domain name and use access control by IP address only.
==============================================================

So, I think it is fixed. If anything else is required to make this bug mark VERIFIED, please let me know.

Thanks,
Amita

Comment 9 Rich Megginson 2015-04-15 13:40:32 UTC
(In reply to Amita Sharma from comment #8)
> According to patch
> https://fedorahosted.org/389/attachment/ticket/434/0001-Ticket-434-admin-
> serv-logs-filling-with-admserv_host.patch , It seems that we have enhanced
> our admin error message log to display that how user can get rid of these
> messages. I am getting exactly the same enhanced message ::
> 
> ==============================================================
> [Tue Apr 14 15:54:34.938123 2015] [:warn] [pid 5971:tid 139707287873280]
> [client 10.65.201.126:55067] admserv_host_ip_check: Access control based on
> hostname [*.englab.pnq.redhat.com] is being used, but the server could not
> resolve the hostname of client IP address [10.65.201.126].  Either enable
> HostnameLookups in console.conf (by default it is off for performance
> reasons), or turn off access control by host/domain name and use access
> control by IP address only.
> ==============================================================
> 
> So, I think it is fixed. If anything else is required to make this bug mark
> VERIFIED, please let me know.
> 
> Thanks,
> Amita

Looks like it is working correctly.

Comment 10 Amita Sharma 2015-04-16 05:28:19 UTC
Marking as VERIFIED.

Comment 12 errata-xmlrpc 2015-06-12 01:02:48 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2015:1094


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