Bug 656454
| Summary: | log levels don't seem to match ISC levels | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Rob Crittenden <rcritten> |
| Component: | bind-dyndb-ldap | Assignee: | Adam Tkac <atkac> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 13 | CC: | atkac, nagy.martin, ovasik |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | bind-dyndb-ldap-0.2.0-1.fc13 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-01-31 19:51:01 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. 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 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 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 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. 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. 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 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. |
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