Bug 250986 - /etc/xinetd.d/telnet should be marked as noverify in the specfile
/etc/xinetd.d/telnet should be marked as noverify in the specfile
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: rpm (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Panu Matilainen
Depends On:
  Show dependency treegraph
Reported: 2007-08-06 07:44 EDT by David Kovalsky
Modified: 2014-03-31 19:44 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-04 03:00:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Kovalsky 2007-08-06 07:44:31 EDT
+++ This bug was initially created as a clone of Bug #250740 +++

Description of problem:
When the xinetd telnet config file is modified, RPM verify test fails. Since the
nature of config files is to be modifiable by the user, it should be marked as
no verify in the spec file. 

This affects automated TPS  test done by URT. Since we have telnet setup on
stable systems all of the TPS tests fail, so having this fixed would save us
some false positives.

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

How reproducible:
Comment 1 Adam Tkac 2007-08-31 04:44:57 EDT
reassigning to rpm because it doesn't make sence change %config directive in all
packages. Attributes like MD5, size, mtime won't be checked if %config directive
is specified by default
Comment 2 Panu Matilainen 2007-08-31 05:22:40 EDT
Um, no. Users and especially sysadmins very much want to know if a configuration
file was modified from the shipped package defaults. If you don't want to know
about config file changes, filter them out of the verification results.

Making filtering easier is something I'm willing to consider for future rpm
versions, otherwise WONTFIX.

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