Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

horakmar
Copy link
Contributor

@horakmar horakmar commented Jun 1, 2018

Salt has problem to fetch repo key from behind proxy with this simple state:

pkgrepo.managed:
- key_url: some_url

This workaround enables adding repo and fetch it's gpg key from behind proxy, if proxy environment is properly configured (curl -s some_url works).

linux_repo_{{ name }}_key:
cmd.run:
- name: "echo '{{ repo.key }}' | apt-key add -"
- onchange:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change this requisite to: require_in [to be processed before the repo]
and add the idemopotency clausule:
unless: "make repo.key fingerpring | apt-key list | grep key fingerprint"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actuall syntax is "onchanges" - https://docs.saltstack.com/en/latest/ref/states/requisites.html

@cznewt, I would give a try, it's actually questionable whether on change implicitly require previous state to have a result - so it's actually as require_in. The doc in this case is not clear. Quite sure it would be safer to user

require_in: 
  - linux_repo_{{ name }}

Add check for existing key for idempotency.
linux_repo_{{ name }}_key:
cmd.run:
- name: "echo '{{ repo.key }}' | apt-key add -"
- onchange:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actuall syntax is "onchanges" - https://docs.saltstack.com/en/latest/ref/states/requisites.html

@cznewt, I would give a try, it's actually questionable whether on change implicitly require previous state to have a result - so it's actually as require_in. The doc in this case is not clear. Quite sure it would be safer to user

require_in: 
  - linux_repo_{{ name }}

Copy link
Member

@epcim epcim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lg

@epcim
Copy link
Member

epcim commented Jun 4, 2018

Seems some gpg data/pkg are missing

gpg: no valid OpenPGP data found.

@epcim
Copy link
Member

epcim commented Jun 4, 2018

Make sure, these two are installed prior GPG is used

        gpgv 
         gnupg2 

@alexandruavadanii
Copy link

I pushed some gpg-parsing changes, as well as a repo url fix in [1], you might want to take a look at that for the tests ...
[1] #138

cmd.run:
- name: "echo '{{ repo.key }}' | apt-key add -"
- onchange:
- unless: "apt-key finger --with-colons | grep -qF $(echo '{{ repo-key }} | gpg --with-fingerprint --with-colons | grep -E '^fpr')"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is the right way, but a simpler (and usually less likely to fail) solution would be to check for the existence of </etc/apt/sources.list.d/{{ name }}.list>. This file should only be created after the GPG is imported, so the check should be safe.

Copy link

@alexandruavadanii alexandruavadanii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't thins is needed, yaml treats everything past : as a single entity anyway.
The tests fail because the apt-mk/.../public.gpg is empty, try adding my commit that replaces s/apt-mk/apt/ from the the PR referenced earlier.

@horakmar
Copy link
Contributor Author

horakmar commented Jun 6, 2018

apt-mk/.../public.gpg is not empty, it's just redirected:

curl -vs http://apt-mk.mirantis.com/public.gpg
...
< HTTP/1.1 301 Moved Permanently
...

Copy link

@alexandruavadanii alexandruavadanii left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My bad, I always forget about redirects. Thanks!

@epcim epcim merged commit 64113f1 into salt-formulas:master Jun 7, 2018
@bbinet
Copy link
Contributor

bbinet commented Jun 8, 2018

This PR breaks the support of key_url that retrieve gpg key from the salt fileserver with "salt://".
See key_url documentation at https://docs.saltstack.com/en/latest/ref/states/all/salt.states.pkgrepo.html#salt.states.pkgrepo.managed :

key_url
    URL to retrieve a GPG key from. Allows the usage of http://, https:// as well as salt://

bbinet added a commit to bbinet/salt-formula-linux that referenced this pull request Jun 8, 2018
bbinet added a commit to bbinet/salt-formula-linux that referenced this pull request Jun 11, 2018
@epcim
Copy link
Member

epcim commented Jun 12, 2018

using curl in cmd.run cases still a proxy issues
@horakmar what version of salt you are using? we minion.conf with proxy_host: xxx.x.x.x set and @smolaon claims the pkgrepo.manage works then if key_url is used.

@horakmar
Copy link
Contributor Author

@epcim: salt 2017.7.5 (Nitrogen)
Problem is that we need to exclude some (local) hosts from connecting via proxy and salt-minion reportedly doesn't support no_proxy settings.

@epcim
Copy link
Member

epcim commented Jun 12, 2018

so the latest code dont for you either. then I would recomend to use key option on a pillar or located at salt://

@epcim
Copy link
Member

epcim commented Jun 12, 2018

no proxy is kind of needed. btw what way you set system curl works for you ? profile scripts? /etc/env ?

@horakmar
Copy link
Contributor Author

Both root's profile or /etc/environment works only if using salt-call from minion.
When using salt from master I realized that salt minion has it's environment cleared. Then .curlrc helps, but it's terrible hack.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants