Description of problem: [root@kvmbck02 ~]# rpm -q -V libvirt-daemon-config-nwfilter SM5....T. /etc/libvirt/nwfilter/allow-arp.xml SM5....T. /etc/libvirt/nwfilter/allow-dhcp-server.xml SM5....T. /etc/libvirt/nwfilter/allow-dhcp.xml SM5....T. /etc/libvirt/nwfilter/allow-incoming-ipv4.xml SM5....T. /etc/libvirt/nwfilter/allow-ipv4.xml SM5....T. /etc/libvirt/nwfilter/clean-traffic.xml SM5....T. /etc/libvirt/nwfilter/no-arp-ip-spoofing.xml SM5....T. /etc/libvirt/nwfilter/no-arp-mac-spoofing.xml SM5....T. /etc/libvirt/nwfilter/no-arp-spoofing.xml SM5....T. /etc/libvirt/nwfilter/no-ip-multicast.xml SM5....T. /etc/libvirt/nwfilter/no-ip-spoofing.xml SM5....T. /etc/libvirt/nwfilter/no-mac-broadcast.xml SM5....T. /etc/libvirt/nwfilter/no-mac-spoofing.xml SM5....T. /etc/libvirt/nwfilter/no-other-l2-traffic.xml SM5....T. /etc/libvirt/nwfilter/no-other-rarp-traffic.xml SM5....T. /etc/libvirt/nwfilter/qemu-announce-self-rarp.xml SM5....T. /etc/libvirt/nwfilter/qemu-announce-self.xml [root@kvmbck02 ~]# Version-Release number of selected component (if applicable): libvirt-daemon-config-nwfilter-2.2.0-2.fc25.x86_64 How reproducible: 100% Steps to Reproduce: 1. rpm -q -V libvirt-daemon-config-nwfilter Actual results: RPM inconsistencies Expected results: RPM happy Additional info: Something is changing the files, I'm not sure what. This may hurt the reproducability, but the true issue is the fact that these /etc files should be specified as config files in RPM.
Those files are shipped without a UUID, which forces libvirt to generate one (UUIDs are supposed to uniquely identify libvirt objects so we don't want to ship a static one to all users). After first libvirtd run, the UUID is saved to disk for those files, which is where the change comes from. Given that, do you have a suggestion? If we mark them as config, is every libvirt update going to generate .rpmnew files? I don't know the particulars offhand
I see a kind of parrallel with ssh: bash-4.3$ ls -l /etc/ssh/ total 580 -rw-r--r--. 1 root root 553185 Mar 3 18:15 moduli -rw-r--r--. 1 root root 1874 Mar 3 18:15 ssh_config drwxr-xr-x. 2 root root 4096 Mar 22 09:36 ssh_config.d -rw-------. 1 root root 3887 Mar 3 18:15 sshd_config -rw-r-----. 1 root ssh_keys 227 Aug 8 2016 ssh_host_ecdsa_key -rw-r--r--. 1 root root 162 Aug 8 2016 ssh_host_ecdsa_key.pub -rw-r-----. 1 root ssh_keys 387 Aug 8 2016 ssh_host_ed25519_key -rw-r--r--. 1 root root 82 Aug 8 2016 ssh_host_ed25519_key.pub -rw-r-----. 1 root ssh_keys 1679 Aug 8 2016 ssh_host_rsa_key -rw-r--r--. 1 root root 382 Aug 8 2016 ssh_host_rsa_key.pub bash-4.3$ There are "config" files *_key and *_key.pub that are not part of the RPM. They are needed for ssh though, so they are generated as part of the ssh daemon startup. Maybe the same could be done for libvirt: store the initial files in /usr/share/libvirt... On startup of libvirt check if the files in /etc are present/OK, of not copy the /usr/share/.. files and make libvirt add UUIDS on startup. Would that be a working scenario?
Yeah I think that's what we would have to do. We kinda sorta do similar stuff with libvirt-daemon-config-network, it moves files into place in its %post section but they aren't actually tracked in %files
Given the fact that the current package has these files in %files, the following will probably happen if the new package doesn't and uses %post to create them: 3. files of new package will be installed (none) 4. %post of new pacaage actually (re)creates the files 10. files of old package will be removed (despite step 4 they will be gone) This according to the steps here:https://fedoraproject.org/wiki/Packaging:Scriptlets I think %posttrans may be needed, which is run as step 14. I don't see another way te get around step 10 when upgrading from the current package.
Did some testing, and it's easier: not %posttrans needed, just %ghost the /etc files. * they won't be removed during an update * they will be removed when the packages is removed * the %post writes are persistent.
> Did some testing, and it's easier: not %posttrans needed, just %ghost the > /etc files. Adding %ghost to the files is not enough, is it? We still need to install the files. Do you suggest to install the real files somewhere in /usr/share, mark /etc files as %ghost and copy the files from /usr/share to /etc in %post or is there a more elegant/easier solution for this?
You're right: the packaged (static) files should be in /usr/share, the "modified duplicates" of these files in /etc as %ghost Having them as %ghost isn't that bad actually; if the package is removed then so are the %ghost files, which make sense. There may be more elegant solutions, but I'm not aware of them. One may argue though that the /etc files should not be in /etc. They are not config files, and manual changes are void when upgrading the package. A better place might be /var/lib. But that's another discussion.
This should be fixed upstream by commit 1d3963dba5b8fbaa1d465d642d516be530618d25 Refs: v3.2.0-181-g1d3963dba Author: Jiri Denemark <jdenemar> AuthorDate: Wed Apr 12 21:36:01 2017 +0200 Commit: Jiri Denemark <jdenemar> CommitDate: Wed Apr 19 11:36:06 2017 +0200 spec: Avoid RPM verification errors on nwfilter XMLs /etc/libvirt/nwfilter/*.xml files are installed with no UUID, which means libvirtd will automatically alter all of them once it starts. Thus RPM verification will always fail on them. Let's use a trick similar to the default network XML and store nwfilter XMLs in /usr/share. They will be copied into /etc in %post. Additionally the /etc files are marked as %ghost so that they are uninstalled if the RPM package is removed. Note that the %post script overwrites existing files with new ones on upgrade, which is what has always been happening. https://bugzilla.redhat.com/show_bug.cgi?id=1431581 https://bugzilla.redhat.com/show_bug.cgi?id=1378774 Signed-off-by: Jiri Denemark <jdenemar>
libvirt-2.2.1-1.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-4b67f65db3
libvirt-2.2.1-1.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-4b67f65db3
libvirt-2.2.1-1.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.