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:
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.
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"
(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?
Upstream ticket: https://fedorahosted.org/389/ticket/434
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.
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.
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
(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.
Marking as VERIFIED.
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