This makes it easier for new and experienced users to run cdist with higher
verbosity levels, both to know that things are working as expected and to debug
issues.
Documentation has been modified accordingly and default behaviour is not
changed.
By abstracting away vendor-dependent pattern matching for the linux code, we can
re-use that and be reasonably sure about OpenBSD machines being virtualised when
we can identify the undelrying virtualisation technology.
It remains to be solved how to tell if an OpenBSD machine is physical; in that
case previous cdist behaviour ("unknown") remains.
For NetBSD something similar to OpenBSD could be done, with different sysctls:
hw.machine and hw.model wary of adding those without testing though, so for
NetBSD previous cdist behaviour ("unknown") remains.
https://netbsd.gw.com/cgi-bin/man-cgi?sysctl+7.i386+NetBSD-9.0
More research is needed for {Net,Open}BSD support.
Indentation is left as-is for the linux code as I intend to simplify it in a
future MR, this way the diff is minimal.
Because at least the --mode default value may not be expected, the
manual lists the "default values". As they are not explicitly set in the
`__file` type, it is a bit more difficult, but should resolve to
following:
- the mode comes from the umask set in the cdist code to protect file
creation and uses the strongest umask possible.
- the owner and group comes from the ssh user, which should always be
the root user. (I think this can be swaped, too, but who will?)
At the owner and group parameter, it could be replaced with something
like "the ssh user and group", which would be more correct, but less
understandable.
This fixes#806 which contains more information about the issue.
The TL;DR: this warning is not being useful and hinders debugging types because
it creates an innecessary line for each explorer.
An alternative proposal was #807 but was abandoned in favour of just dropping
the warning.
__pf_apply the way it exists on cdist is not really useful and __pf_ruleset does
not take advantage of other types as it should, being instead overly complex and
not as reliable.
The new __pf_ruleset is compatible with the previous one, and __pf_apply_anchors
allows for a simple and powerful way of managing pf anchors.
The functionality previously provided by __pf_apply is still possible out of the
box in __pf_ruleset.
These patches were mostly contributed by Kamila Součková and made fit for
upstreaming by Evilham.
It is quite likely that the package is going to be called postfix, rather
than trying to have an exhaustive "allow list" for this package, we can
just add special cases for OSs where that is not the case (not aware of any
atm).
