Template was not set to shutdown after patch to avoid double the amount
of startups at shutdown required due to the salt patch that a package
needs to be installed during the "create" state. Proven to cause
problems in case a qube based on the same template requires a package
that is installed during the "install" state. Other fedora-minimal
templates "mgmt" and "sys-pgp" are unaffected.
Fixes: https://github.com/ben-grande/qusal/issues/70
The state module git.latest does not allow setting environment variable
for us to set the correct GNUPGHOME. The module environ.set does not
work as we call git as the normal user and not as root, but may still be
the problem of git.latest not respecting environment variables.
The problem with always pulling new commits is that it may conflict with
the current work the user has done on the repository locally. It will
also not work in case the last commit is not signed by a trusted key
deployed by the formula, in this case, you should add the key manually
to verify the commit.
Setting the gpg.program only for the required repositories solves the
aforementioned problem and also enhances usability by removing extra
commands that the user needs to learn and remember.
Fixes: https://github.com/ben-grande/qusal/issues/58
The wget package can be downloaded from the command-line, but as Salt
does not follow DNF package redirects, the package is installed but the
state fails as Salt cannot find a package with the same name installed.
Updates happens multiple times, normally 2 to 3, even if we consider a
state without includes. On states with multiple includes, it could
easily get approximately 10 updates being ran. This behavior leads to
unnecessary network bandwidth being spent and more time to run the
installation state. When the connection is slow and not using the
cacher, such as torified connections on Whonix, the installation can
occurs much faster.
Adding external repositories has to be done prior to update to ensure it
is also fetched.
Fixes: https://github.com/ben-grande/qusal/issues/29
Split-gpg V1 allowed for querying public keys, but as split-gpg2 is
running as an agent, public keys are not queried. Allowing connection to
the server to query only public parts of the key exposes the server more
than needed to the client.
All clients now have to hold the public key they need locally in order
to do GPG operations.
