Inconsistent behaviour when updating beats via Yum/RPM - Previous configuration not always retained.

[jamesspi]

• Version: 6.4.0
• Operating System: Centos 7.5.1804

Previously When updating via Yum/RPM, the existing yaml configuration file was retained and used by the daemon. The yml configuration provided by the package would be saved to beatname.yml.rpmnew.

I've just updated some beats to 6.4.0 from 6.3.2 and 1 of them did not use my existing configuration, but rather, the one bundled in the package. My existing configuration was moved to beatname.yml.rpmsave.

What normally happens:

-rw-r--r--. 1 root root 68549 Aug 17 22:21 fields.yml
-rw-r--r--. 1 root root 65074 Aug 17 22:21 filebeat.reference.yml
-rw-------. 1 root root 7410 Aug 1 11:00 filebeat.yml
-rw-------. 1 root root 7231 Aug 17 22:21 filebeat.yml.rpmnew
drwxr-xr-x. 2 root root 4096 Aug 24 07:04 modules.d

What happened for one of the other beats:

-rw-r--r--. 1 root root 43702 Aug 17 22:19 auditbeat.reference.yml
-rw-------. 1 root root 6250 Aug 17 22:19 auditbeat.yml
-rw-------. 1 root root 7252 Aug 1 11:11 auditbeat.yml.rpmsave
drwxr-xr-x. 2 root root 84 Aug 24 09:27 audit.rules.d
-rw-r--r--. 1 root root 38035 Aug 17 22:19 fields.yml

This is not ideal, as many customers updating in the same way will have to manually replace rename the configuration files so the correct one is used, especially large deployments being updated via Ansible etc.

Thanks,
James

[adriansr]

I tested upgrading filebeat from 6.1.0 to 6.2.0 with a minor config change and had the same issue:

[root@localhost vagrant]# diff /etc/filebeat/filebeat.yml*
24c24
<   #enabled: false
---
>   enabled: false
170c170
< # Available log levels are: critical, error, warning, info, debug
---
> # Available log levels are: error, warning, info, debug
176a177,191
>
> #============================== Xpack Monitoring ===============================
> # filebeat can export internal metrics to a central Elasticsearch monitoring
> # cluster.  This requires xpack monitoring to be enabled in Elasticsearch.  The
> # reporting is disabled by default.
>
> # Set to true to enable the monitoring reporter.
> #xpack.monitoring.enabled: false
>
> # Uncomment to send the metrics to Elasticsearch. Most settings from the
> # Elasticsearch output are accepted here as well. Any setting that is not set is
> # automatically inherited from the Elasticsearch output configuration, so if you
> # have the Elasticsearch output configured, you can simply uncomment the
> # following line.
> #xpack.monitoring.elasticsearch:

I think this rules out any issue with the recent packaging refactor.

However, it's still a good idea to investigate how/if we can improve this behavior

[andrewkroh]

rpm -qc auditbeat is not showing any files so none are marked as configfile in the package metadata. This is a regression due to the packaging refactor.

The causes is that we are missing Config: true for the customized configuration files in the auditbeat RPM.

beats/auditbeat/magefile.go

Lines 168 to 177 in bf72246

	shortConfig = mage.PackageFile{
	Mode: 0600,
	Source: "{{.PackageDir}}/auditbeat.yml",
	Dep: generateShortConfig,
	}
	referenceConfig = mage.PackageFile{
	Mode: 0644,
	Source: "{{.PackageDir}}/auditbeat.reference.yml",
	Dep: generateReferenceConfig,
	}

This will not affect debian packages because deb automatically marks everything in /etc as config.

So the simplest fix is to just add Config: true to the customizations in Auditbeat's packaging. But a better fix IMO would probably be to automatically set Config: true for any package files with strings.HasPrefix(Target, "/etc").

[adriansr]

Oh now I see my check was wrong, didn't realise the difference between rpmsave and rpmnew files