Package: puppet-agent Version: 7.23.0-1 Severity: minor File: /usr/bin/puppet X-Debbugs-Cc: debian-b...@henk.geekmail.org
Dear Maintainer, * What led up to the situation? I was trying to build an exclude list for my backups and went through the content of my filesystems. * What was the outcome of this action? I noticed that there are reports of puppet runs in /var/cache/puppet/reports. * What outcome did you expect instead? I did expect all data in /var/cache and its subdirectories to be regeneratable and not contain any information one might want to backup. According to the FHS in https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s05. > /var/cache is intended for cached data from applications. Such data is > locally generated as a result of time-consuming I/O or calculation. The > application must be able to regenerate or restore the data. This is not the case for reports: Puppet can not regenerate the report for a specific run. Also "cache" usually refers to data that will be reused which is not the case for these reports. /var/log seems a better fit for those. In my concrete case, it seems suboptimal that these reports are in a directory that I would like to exclude from backups because it should not contain anything worth backing up anyway as all data in there is supposed to be regeneratable and these reports clearly are not. Under the "Rationale" this use case is even mentioned explicitly: > The existence of a separate directory for cached data allows system > administrators to set different disk and backup policies from other > directories in /var. The argument has been made on IRC that usually reports are not stored locally anyway, but it seemed implied that the server would also store the reports in a directory named "cache", but outside the FHS in /opt/puppetlabs/puppet/cache/reports in the case of a non-debian installation. I have no puppetserver installation with debian on hand, so I don’t know how the debian package would behave. Another argument has been made that the reports are stored in puppetdb and the reports are thus only stored temporarily as files on a disk. IMHO that still wouldn’t make them "cache" data. "temporary" data maybe, so in that case they should probably go to /var/tmp or /tmp. Or, as https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s14.html mentions: > /var/spool contains data which is awaiting some kind of later processing. > Data in /var/spool represents work to be done in the future (by a program, > user, or administrator); often data is deleted after it has been processed. Both of these arguments are kind of OK for a certain set of circumstances but not everybody is running a puppetdb or even a puppetserver. I am running puppet standalone, i.e. with `puppet apply`, so the reports will not be transferred to the server and will not be consumed into/by puppetdb. In any case, treating reports as "cached" data seems quite clearly wrong. In the case of standalone puppet (i.e. `puppet apply`) IMHO they are "logs" and should go to /var/log. In the case of a puppet-agent (i.e. a puppet client/agent connecting to a puppet server _without_ a puppetdb), they should probably not be saved on the client at all but if so, they are also "logs" IMHO and should be treated like mentioned above. On the server, they should also be treated like "logs" but not necessarily go to /var/log like machine-local log data. I don’t think I have a concrete sensible suggestion for this case. Maybe /var/lib. In the case of a puppetserver with a puppetdb, they should probably not be saved as files at all on the server. Unless they are sent directly to the puppetdb from the puppedserver, but consumed later, they are probably "spool" data. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (1, 'unstable'), (1, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-20-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=de_CH.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages puppet-agent depends on: ii adduser 3.134 ii debconf [debconf-2.0] 1.5.82 ii facter 4.3.0-2 ii hiera 3.10.0-1 ii init-system-helpers 1.65.2 ii ruby 1:3.1 ii ruby-augeas 1:0.5.0+gem-1 ii ruby-concurrent 1.1.6+dfsg-5 ii ruby-deep-merge 1.1.1-2 ii ruby-semantic-puppet 1.0.4-1 ii ruby-shadow 2.5.1-1 ii ruby-sorted-set 1.0.3-3 Versions of packages puppet-agent recommends: pn augeas-tools <none> ii debconf-utils 1.5.82 ii lsb-release 12.0-1 pn ruby-selinux <none> Versions of packages puppet-agent suggests: pn hiera-eyaml <none> pn puppet-module-puppetlabs-augeas-core <none> pn puppet-module-puppetlabs-cron-core <none> pn puppet-module-puppetlabs-host-core <none> pn puppet-module-puppetlabs-mount-core <none> pn puppet-module-puppetlabs-selinux-core <none> pn puppet-module-puppetlabs-sshkeys-core <none> pn puppet-module-puppetlabs-stdlib <none> ii ruby-hocon 1.3.1-2 pn ruby-msgpack <none> -- Configuration Files: /etc/puppet/hiera.yaml [Errno 2] No such file or directory: '/etc/puppet/hiera.yaml' /etc/puppet/puppet.conf changed: [main] freeze_main = true strict_variables = true [user] environment = hnjs -- debconf information excluded
