noclobber is potentially unsafe, because it relies on the underlying shell to
implement noclobber in a safe way that avoids race conditions between multiple
processes.
mkdir is safer because it is mandated by POSIX to "fail" if the target already
exists.
Instead, rely on `nonparallel`.
In any case cdist should never run explorer and code concurrently even if the
dependency graph would allow to do so as it would result in many more
synchronization issues than this one.
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.
__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).
