0

I'm trying to write a puppet module that writes a templated config out but onlyif it's the stock config from the RPM (so as to not screw with any formatting they have going on). The rest of config management is done through augeas. Previously this worked but for some reason rpm -Vf isn't printing that smb.conf does indeed vary from when it was first installed. For example, I've made heavy changes to it and its timestamp yet:

[root@vlmat ~]# rpm -Vf /etc/samba/smb.conf
[root@vlmat ~]# echo $?
0

Doesn't reflect that the md5sum as changed at all nor does it change the return code.

And smb.conf is in the rpm database but verifying the whole package doesn't yield anything:

[root@vlmat ~]# rpm -qf /etc/samba/smb.conf
samba-common-3.6.23-35.el6_8.x86_64
[root@vlmat ~]# rpm -V samba-common
[root@vlmat ~]#

After editing another config file in that rpm:

[root@vlmat ~]# rpm -V samba-common
S.5....T.  c /etc/sysconfig/samba

The SHA256 sum does differ from what the database has:

[root@vlmat ~]# rpm -ql --dump samba-common | grep smb
/etc/samba/smb.conf 9778 1461617087 2474992be3adf11ef60aa754151f19b5756aaf9919cd6eacbd3f6b75c303dbb1 0100644 root root 1 0 0 X
[...snip..]
[root@vlmat ~]# sha256sum /etc/samba/smb.conf
270cd0ca5bce64448c31dc6c8e01d12f3d1217b8c208008a1dd1ddc976714774  /etc/samba/smb.conf

I seem to remember this method working before, but not sure what could have changed.

EDIT:

I've worked around the issue by having a bash script copy the template over if the sha256 checksum on the file and in the DB are the same but I'd like an explanation/workaround for the above method since I think it should work. Why does it see the change to one config file but not the one I was looking at?

2

The creator of an rpm spec file can override the default things to check for the verification of a given file. For example,

%config(noreplace) %verify(not md5 size mtime) %{_sysconfdir}/samba/smb.conf

means do not check the file's md5sum (size or mtime). These are still recorded in the database, but variation will be suppressed during a -V operation. You can still list all the verifications by adding -v to your -V (though my rpm shows an md5 difference if there is one without this).

 $ rpm -Vvf /etc/samba/smb.conf | grep /etc/samba/smb.conf
 .........  c /etc/samba/smb.conf
  • I'll consider this an answer. I'm updating with the actual line from the spec file, though. – Bratchley Jun 14 '16 at 18:24
0

Configuration files such as smb.conf are often fiddled with by sysadmins, so it does not make sense for rpm to verify something that will be changed. "stock" will also only be whatever was installed on the first install of smb.conf; the contents of this file may vary if the version of samba first installed has changes to its smb.conf, and if a sysadmin has modified /etc/smb.conf, those (new!) stock values may instead appear in /etc/smb.conf.rpmnew.

Why not instead have the configuration management specify what the smb.conf should contain, and only change the configuration if it departs from that state? This would avoid the complications of having to maintain a list of stock configurations over time, and would better handle cases where something has created a smb.conf that is neither stock nor the version specified by configuration management.

  • "Why not instead have the configuration management specify what the smb.conf should contain, and only change the configuration if it departs from that state?" It does do that but the problem is that the stock smb.conf is huge and isn't well organized. It also has a huge amount of comments in it. The template I want to put down is better organized but if the app owner has their own comments/organization that makes sense to them I want to preserve that. Bsaically I'm just looking to override Red Hat, not the app owner. – Bratchley Jun 14 '16 at 17:39
  • But as to your point, rpm does verify config files, such as in the original question where /etc/sysconfig/samba is marked as a config file (the c) but an rpm -V still shows that it changed. – Bratchley Jun 14 '16 at 17:40
  • So on machine provision, install your smb.conf, then evict config management (or just of smb.conf) when you turn the system over to the app owner. No need to fiddle around with rpm, as you're simply transitioning from provisioned but unconfigured to deployed for the owner. – thrig Jun 14 '16 at 20:05
  • No you should never turn config management off for any reason. You re-work config management so that it tolerates changes the app owners have to make. If you disable it would be impossible to do things like disable SSL in mod_ssl because nobody would be running puppet. Just finding a way to replace RH's stock smb.conf with your own is sufficient. If it's not stock the app owner is apparently either alright with that much cruft or they've already re-organized it how they like it. Failing that it can be resolved on an individual basis if it turns into an issue. But you never stop managing a node – Bratchley Jun 14 '16 at 20:16
  • Why isn't the app owner also using puppet? Why is the node's management split between two groups? Fix those issues, and you can reduce the amount of code (and consequent bugs and maintenance issues) that has to be piled into the configuration management. – thrig Jun 14 '16 at 21:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.