Bug 1020552 - iptraf-ng rpm installs /var/lock/iptraf-ng but should really be using the tmpfiles.d mechanism
Summary: iptraf-ng rpm installs /var/lock/iptraf-ng but should really be using the tmp...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: iptraf-ng
Version: 7.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 7.6
Assignee: Phil Cameron
QA Contact: Daniel Rusek
URL:
Whiteboard:
Depends On:
Blocks: 1554861
TreeView+ depends on / blocked
 
Reported: 2013-10-17 22:11 UTC by Andrew J. Schorr
Modified: 2018-10-30 07:49 UTC (History)
7 users (show)

Fixed In Version: iptraf-ng-1.1.4-3.fc19
Doc Type: Bug Fix
Doc Text:
Cause: change in coding requirements Consequence: waring in build Fix: code to current standard Result: no warning
Clone Of:
Environment:
Last Closed: 2018-10-30 07:49:17 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3030 0 None None None 2018-10-30 07:49:43 UTC

Description Andrew J. Schorr 2013-10-17 22:11:51 UTC
Description of problem:
If you install iptraf-ng and then reboot, rpm reports that /var/lock/iptraf-ng
is missing:

bash-4.2$ rpm --verify iptraf-ng
missing     /var/lock/iptraf-ng

Instead of trying to install the /var/lock/iptraf-ng directory, it should
use the tmpfiles.d mechanism to create this directory, since /run/lock
is now created that way:

bash-4.2$ grep /run/lock /usr/lib/tmpfiles.d/legacy.conf | head -1
d /run/lock 0755 root root -



Version-Release number of selected component (if applicable):
iptraf-ng-1.1.4-2.fc19.x86_64


How reproducible:
Install iptraf-ng, reboot, then run rpm --verify

Steps to Reproduce:
1. Install iptraf-ng rpm
2. Reboot
3. Run "rpm --verify iptraf-ng" and note the error.

Actual results:
missing     /var/lock/iptraf-ng


Expected results:
No complaints.


Additional info:

Comment 1 Nikola Pajkovsky 2013-10-18 12:37:43 UTC
Hello Andrew,

yeah, true. The whole story happened when /var/lock became symlink to /run/lock and /run was mounted as tmpfs. Hence, I had two options to address this issue.
1) your solution, 2) write sanity check for lock directory in iptraf-ng. I did 2) and that's why you don't see any issues (when run iptraf-ng, dir is created if not exists).

Nevertheless, I should drop iptraf-ng.conf to /usr/lib/tmpfiles.d/.

Comment 2 Andrew J. Schorr 2013-10-18 13:38:46 UTC
Hi Nikola,

I'm not sure of the correct fix, because it seems as if using /var/lock
is deprecated.  Or that's how I interpret this comment in /usr/lib/tmpfiles.d/legacy.conf:

bash-4.2$ head -13 /usr/lib/tmpfiles.d/legacy.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# See tmpfiles.d(5) for details

# These files are considered legacy and are unnecessary on legacy-free
# systems.

d /run/lock 0755 root root -

This gives the impression that one should avoid using /run/lock (or /var/lock).
I'm not sure what the correct solution is.  Maybe the iptraf-ng locking
directory should be direcly under /run rather than /run/lock.  If under /run/lock,
I wonder if there's a race condition regarding which tmpfiles.d file gets 
processed first.

Regards,
Andy

Comment 3 Nikola Pajkovsky 2013-11-18 11:48:45 UTC
sorry for long delay, I should buy you a beer.

It seems it's another way around, see

$ ll /var/ | grep lock
lrwxrwxrwx.  1 root root   11 Oct 18 13:58 lock -> ../run/lock

and according packaging guide lines (http://fedoraproject.org/wiki/Packaging:Tmpfiles.d) I should create lock file right into /run.

Comment 4 Andrew J. Schorr 2013-11-18 13:36:43 UTC
That sounds good to me.  Thanks!

Comment 5 Cristian Ciupitu 2014-01-04 06:54:52 UTC
When this is implemented, please make sure that the file mode is the
same in %files section of the RPM SPEC and the tmfiles config file.
Right now I'm getting this with iptraf-ng-1.1.4-3.fc20.x86_64:

# rpm -V -f /var/lock/iptraf-ng
.M.......    /var/lock/iptraf-ng

Comment 7 Fedora Admin XMLRPC Client 2014-02-05 20:17:57 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 8 Fedora Update System 2014-03-03 00:29:47 UTC
iptraf-ng-1.1.4-5.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/iptraf-ng-1.1.4-5.fc20

Comment 9 Fedora Update System 2014-03-03 00:29:59 UTC
iptraf-ng-1.1.4-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/iptraf-ng-1.1.4-3.fc19

Comment 10 lnie 2014-03-03 08:37:51 UTC
iptraf-ng-1.1.4-3.fc19 works

Comment 11 Cristian Ciupitu 2014-03-03 16:04:24 UTC
[root@hermes ~]# rpm -q iptraf-ng 
iptraf-ng-1.1.4-3.fc20.x86_64
[root@hermes ~]# rpm -V iptraf-ng 
missing     /var/lock/iptraf-ng

Comment 12 Alejandro_Perez 2014-03-03 18:43:44 UTC
On f20 you need to test https://admin.fedoraproject.org/updates/iptraf-ng-1.1.4-5.fc20

Comment 13 Fedora Update System 2014-03-04 06:39:30 UTC
Package iptraf-ng-1.1.4-5.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing iptraf-ng-1.1.4-5.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-3373/iptraf-ng-1.1.4-5.fc20
then log in and leave karma (feedback).

Comment 14 Fedora Update System 2014-03-07 06:28:55 UTC
iptraf-ng-1.1.4-5.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 15 Fedora Update System 2014-03-08 03:34:02 UTC
iptraf-ng-1.1.4-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 16 Andrew J. Schorr 2016-11-02 18:11:45 UTC
If I'm not mistaken, this same issue applies to the RHEL 7.2 version of the package.

Comment 20 Daniel Rusek 2018-05-02 15:16:05 UTC
:: [ 11:14:43 ] :: [   PASS   ] :: Command 'rpm --verify iptraf-ng' (Expected 0, got 0)
:: [ 11:14:43 ] :: [   PASS   ] :: File '/var/tmp/rlRun_LOG.BO0K9C8m' should not contain 'missing     /var/lock/iptraf-ng'

I can confirm that this is fixed since RHEL 7.3.

Comment 22 errata-xmlrpc 2018-10-30 07:49:17 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-2018:3030


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