salt stack - Using SaltStack's State Modules to Accept Newly Added Repo's Package Signing Key -
problem
on standalone minion, salt.states.pkgrepo.managed
being used add non standard software repo. problem that's occurring, when following sudo zypper update
runs, key has not been (auto) accepted system, preventing packages being updated or installed , next state fails.
to reiterate exact state used mysuse.sls
:
suse-gis-repo: pkgrepo.managed: - name: application_geo - humanname: applications related earth (gis, mapping, geodesy, gps, astronomy) (opensuse_leap_42.1) - baseurl: http://download.opensuse.org/repositories/application:/geo/opensuse_leap_42.1/ - gpgcheck: 1 - gpgkey: http://download.opensuse.org/repositories/application:/geo/opensuse_leap_42.1//repodata/repomd.xml.key
the problem when next phase of state runs:
packages_uptodate: pkg.uptodate: - refresh: true
it fails because of required manual intervention shown below:
new repository or package signing key received: repository: application_geo key name: application:geo obs project <application:geo@build.opensuse.org> key fingerprint: 195e2111 06bc205d 2a9c2222 cc7f0748 9591c39b key created: thu 16 jul 2015 08:01:27 pm cest key expires: sat 23 sep 2017 08:01:27 pm cest rpm name: gpg-pubkey-9591c39b-55a7f177 want reject key, trust temporarily, or trust always? [r/t/a/? shows options] (r):
attempts solve
- even if last 2 lines of
suse-gis-repo
commented out (ie.gpgchk
&gpgkey
), problem described above still occurs. zypper ar -g <uri>
ensures gpgkey not checked there no option in salt state.- one attempt solve problem, instead of using
salt.states.pkgrepo.managed
attempt use corresponding execution modulezypper.mod_repo
tried.
the example described in #3 below:
package_autoaccept_key: module.run: - name: zypper.mod_repo - kwargs: { repo: 'application_geo', baseurl: 'http://download.opensuse.org/repositories/application:/geo/opensuse_leap_42.1/', enabled: 'true', refresh: 'true', gpgcheck: 'true', gpgautoimport: 'true' }
with error:
local: ---------- id: package_autoaccept_key function: module.run name: zypper.mod_repo result: false comment: module function zypper.mod_repo not available started: 02:18:34.108787 duration: 543.087 ms changes: summary local ------------ succeeded: 0 failed: 1 ------------
questions
is there way accept key (always trust) autonomously, either via state or execution modules?
are execution modules able run on standalone minions via
module.run
function?if able run on standalone minions, best way sure required module present?
is approach of using
module.run
in state flawed approach said problem , if why?
Comments
Post a Comment