Bug 656454 - log levels don't seem to match ISC levels
Summary: log levels don't seem to match ISC levels
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: bind-dyndb-ldap
Version: 13
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Adam Tkac
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-23 19:13 UTC by Rob Crittenden
Modified: 2013-04-30 23:47 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2011-01-31 19:51:01 UTC


Attachments (Terms of Use)

Description Rob Crittenden 2010-11-23 19:13:45 UTC
Description of problem:

We use this package as part of IPA and got a report that a user is seeing entries like:

24-Oct-2010 10:32:33.025 edns-disabled: info: success resolving 'www.mailscanner.tv/A' (in 'mailscanner.tv'?) after reducing the advertised EDNS UDP packet size to 512 octets
24-Oct-2010 10:34:41.137 database: error: querying 'idnsName=wpad, idnsname=uzdomain.ca,cn=dns,dc=uzdomain,dc=ca' with '(objectClass=idnsRecord)'
24-Oct-2010 10:34:41.140 database: error: querying 'idnsname=uzdomain.ca,cn=dns,dc=uzdomain,dc=ca' with '(objectClass=idnsRecord)'
24-Oct-2010 10:34:41.143 database: error: entry count: 1
24-Oct-2010 10:34:41.146 database: error: querying 'idnsName=wpad, idnsname=uzdomain.ca,cn=dns,dc=uzdomain,dc=ca' with '(objectClass=idnsRecord)'
24-Oct-2010 10:39:43.581 database: error: querying 'idnsName=wpad, idnsname=uzdomain.ca,cn=dns,dc=uzdomain,dc=ca' with '(objectClass=idnsRecord)'
24-Oct-2010 10:39:43.583 database: error: querying 'idnsname=uzdomain.ca,cn=dns,dc=uzdomain,dc=ca' with '(objectClass=idnsRecord)'
24-Oct-2010 10:39:43.586 database: error: entry count: 1
24-Oct-2010 10:39:43.589 database: error: querying 'idnsName=wpad, idnsname=uzdomain.ca,cn=dns,dc=uzdomain,dc=ca' with '(objectClass=idnsRecord)'

This is hosing up their log analyzer because it is interpreting what is a successful LDAP search as a failure (presumably because of the error level).

I looked at the logging code and it doesn't seem to be using a valid log level. It ends up using a log level of 2 and as far as I can tell the log levels range from 0 to -5.

I haven't been able to reproduce this behavior myself but I'm wondering if the log level not matching has something to do with this. From what I can read their log level shouldn't be logging these messages.

This is their logging configuration:

// *******************
// Logging definitions
// *******************

// Logging
logging {
   channel "named_log" {
      file "data/log/named.run" versions 5 size 4m;
      severity dynamic;
      print-category yes;
      print-severity yes;
      print-time yes;
   };

   channel "security_log" {
      file "data/log/security.log" versions 5 size 10m;
      severity dynamic;
      print-category yes;
      print-severity yes;
      print-time yes;
   };

   channel "query_log" {
      file "data/log/query.log" versions 5 size 50m;
      #severity dynamic;
      severity debug;
      print-category yes;
      print-severity yes;
      print-time yes;
   };

   channel "transfer_log" {
      file "data/log/transfer.log" versions 5 size 10m;
      severity dynamic;
      print-category yes;
      print-severity yes;
  };

   category "default" {
      "named_log";
      "default_syslog";
      "default_debug";
   };

   category "general" {
      "named_log";
   };

  category "queries" {
    "query_log";
   };

   category "lame-servers" {
      null;
   };

   category "security" {
      "security_log";
   };

   category "config" {
      "named_log";
   };

   category "resolver" {
      "query_log";
   };

   category "xfer-in" {
      "transfer_log";
   };

   category "xfer-out" {
      "transfer_log";
   };

   category "notify" {
      "transfer_log";
   };

   category "client" {
      "query_log";
   };

   category "network" {
      "named_log";
   };

   category "update" {
      "transfer_log";
   };

   category "dnssec" {
      "security_log";
   };

 category "dispatch" {
      "security_log";
   };
};


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

bind-dyndb-ldap-0.1.0-0.5.a1.fc13

Comment 1 Fedora Admin XMLRPC Client 2010-12-15 15:41:35 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 2 Fedora Update System 2011-01-14 13:58:47 UTC
bind-dyndb-ldap-0.2.0-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/bind-dyndb-ldap-0.2.0-1.fc14

Comment 3 Fedora Update System 2011-01-14 13:58:54 UTC
bind-dyndb-ldap-0.2.0-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/bind-dyndb-ldap-0.2.0-1.fc13

Comment 4 Fedora Update System 2011-01-14 20:32:12 UTC
bind-dyndb-ldap-0.2.0-1.fc14 has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update bind-dyndb-ldap'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-0.2.0-1.fc14

Comment 5 Fedora Update System 2011-01-31 19:50:56 UTC
bind-dyndb-ldap-0.2.0-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 6 Fedora Update System 2011-01-31 19:52:18 UTC
bind-dyndb-ldap-0.2.0-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 7 Fedora Update System 2012-12-03 18:26:20 UTC
geome-1.4-2.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/geome-1.4-2.el6

Comment 8 Fedora Update System 2012-12-27 20:06:13 UTC
geome-1.4-2.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.


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