No reports from minions

Support
,
1

Hi all,

Problem: I have no reports from my Minion.
And also Foreman doesn’t add the minion to Hosts by itself as soon as the key is accepted.

Foreman and Proxy versions:
I’m using Salt Master - 2018.3.2 version
Salt Minion - 2018.3.2
Foreman-installer - 1.17.1-1
Salt API - 2018.3.2
CherryPy as a REST API for Salt.

I can accept/delete the key from the Foreman interface. Here I don’ have the host of Minion automatically added… If I create it by myself - I can run “Run Salt” command to apply the states.

I think that the problem is in the certificates. I am a little bit confused, which certificate where I need to put in config files.

I have one machine with Foreman and Salt Master – 10.11.49.117, dns: cosmoforeman.cosmo-foreman.com

Another is Salt minion

I have generated the TLS key as it is mentioned there: https://salt-api.readthedocs.io/en/latest/ref/netapis/all/saltapi.netapi.rest_cherrypy.html#a-rest-api-for-salt

So, in /etc/salt/master I have:

interface: 10.11.49.117

external_auth:
pam:
saltuser:
- .*
- ‘@runner’

rest_cherrypy:
port: 9191
host: 0.0.0.0
ssl_key: /etc/puppetlabs/puppet/ssl/private_keys/cosmoforeman.cosmo-foreman.com.pem
ssl_crt: /etc/puppetlabs/puppet/ssl/certs/cosmoforeman.cosmo-foreman.com.pem

In /etc/foreman-proxy/settings.d/salt.yml :

:enabled: https
:autosign_file: /etc/salt/autosign.conf
:salt_command_user: root
:use_api: true
:api_url: https://cosmoforeman.cosmo-foreman.com:9191
:api_auth: pam

in /etc/salt/foreman.yaml

:proto: https
:host: cosmoforeman.cosmo-foreman.com
:port: 443
:ssl_ca: “/etc/puppetlabs/puppet/ssl/certs/ca.pem”
:ssl_cert: “/etc/puppetlabs/puppet/ssl/private_keys/cosmoforeman.cosmo-foreman.com.pem”
:ssl_key: “/etc/puppetlabs/puppet/ssl/certs/cosmoforeman.cosmo-foreman.com.pem”
:timeout: 10
:salt: /usr/bin/salt
:upload_grains: true

Do you see the problem?
Could it be because I am using Salt 2018.3.2 version?

Thank you in advance!

2

Can you confirm which version of the foreman_salt plugin you have. I recently released 10.1.0 which fixes quite a few issues with Salt 2017/2018 and Foreman 1.17+

Regarding reports, there’s a couple of quirks:

  • Ensure you’re calling state.highstate and not state.apply, as the latter isn’t current tracked by our plugin
  • Then try executing /usr/sbin/upload-salt-reports and see what you get. I’m seeing intermittent crashes with it, but at least one report always sends (because the crash happens in the return-code handling).

If the report uploader isn’t working for some other reason, we can dig into that.

3

Hi All,

I’m experiencing the same problem on:

foreman 1.19.0
salt-master 2018.3.2 (Oxygen)
salt-minion 2018.3.2 (Oxygen)
salt-api 2018.3.2 (Oxygen)
tfm-rubygem-foreman_salt 10.1.0

I do however do not believe the problem lies within certificates as I can see the data coming into foreman properly in /var/log/foreman/production.log.

2018-09-17T15:03:47 [I|app|] Started POST "/salt/api/v2/jobs/upload" for 10.255.22.1 at 2018-09-17 15:03:47 +0200
2018-09-17T15:03:47 [I|app|89a8b] Processing by ForemanSalt::Api::V2::JobsController#upload as JSON
2018-09-17T15:03:47 [I|app|89a8b] Parameters: {"job"=>{"function"=>"state.highstate", "result"=>{"foreman.virtualt00bz.lan"=>{"cmd_|-dandit_|-echo \"Huuuj gematched\"_|-run"=>{"comment"=>"Command \"echo \"Huuuj gematched\"\" run", "name"=>"echo \"Huuuj gematched\"", "start_time"=>"15:02:52.449245", "result"=>true, "duration"=>14.126, "__run_num__"=>6, "__sls__"=>"testtarget", "changes"=>{"pid"=>27493, "retcode"=>0, "stderr"=>"", "stdout"=>"Huuuj gematched"}, "__id__"=>"dandit"}, "file_|-root-bashrc_|-/root/.bashrc_|-managed"=>{"comment"=>"File /root/.bashrc is in the correct state", "pchanges"=>{}, "name"=>"/root/.bashrc", "start_time"=>"15:02:52.334399", "result"=>true, "duration"=>33.568, "__run_num__"=>2, "__sls__"=>"baseline.config", "changes"=>{}, "__id__"=>"root-bashrc"}, "file_|-etc-screenrc_|-/etc/screenrc_|-managed"=>{"comment"=>"File /etc/screenrc is in the correct state", "pchanges"=>{}, "name"=>"/etc/screenrc", "start_time"=>"15:02:52.368520", "result"=>true, "duration"=>24.548, "__run_num__"=>3, "__sls__"=>"baseline.config", "changes"=>{}, "__id__"=>"etc-screenrc"}, "pkg_|-baseline-pkg_|-baseline-pkg_|-installed"=>{"comment"=>"All specified packages are already installed", "name"=>"dstat", "start_time"=>"15:02:52.308946", "result"=>true, "duration"=>22.239, "__run_num__"=>1, "__sls__"=>"baseline.install", "changes"=>{}, "__id__"=>"baseline-pkg"}, "file_|-cron-daily-yum_|-/etc/cron.d/yum_|-managed"=>{"comment"=>"File /etc/cron.d/yum is in the correct state", "pchanges"=>{}, "name"=>"/etc/cron.d/yum", "start_time"=>"15:02:52.420588", "result"=>true, "duration"=>26.107, "__run_num__"=>5, "__sls__"=>"baseline.config", "changes"=>{}, "__id__"=>"cron-daily-yum"}, "pkg_|-epel-release-pkg_|-epel-release_|-installed"=>{"comment"=>"All specified packages are already installed", "name"=>"epel-release", "start_time"=>"15:02:51.089711", "result"=>true, "duration"=>1218.956, "__run_num__"=>0, "__sls__"=>"baseline.pkgrepo.redhat", "changes"=>{}, "__id__"=>"epel-release-pkg"}, "file_|-root-vimrc_|-/root/.vimrc_|-managed"=>{"comment"=>"File /root/.vimrc is in the correct state", "pchanges"=>{}, "name"=>"/root/.vimrc", "start_time"=>"15:02:52.393617", "result"=>true, "duration"=>26.347, "__run_num__"=>4, "__sls__"=>"baseline.config", "changes"=>{}, "__id__"=>"root-vimrc"}}}, "job_id"=>"20180917150242180723"}, "apiv"=>"v2"}
2018-09-17T15:03:48 [I|app|89a8b] Processing job 20180917150242180723 from Salt.
2018-09-17T15:03:48 [I|app|89a8b] Completed 200 OK in 178ms (Views: 0.3ms | ActiveRecord: 33.6ms)

After this i see on the dashboard under the section “Task Status” that there is another task with the state “planned” and the result “pending”. These tasks never get executed.

Please let me know if I can provide some other information.

4

I’m away from my desk this week, so I can’t test much, but check if dynflowd is running - it sounds like the background task runner isn’t processing the jobs.

5

Thank you very much @Gwmngilfen,
How could I have missed this?! Yes, this was exactly my problem.

Did this service already exist in foreman 1.16?

1 Like
6

It did, but it used to be called foreman-tasks, so perhaps you just didn’t realise it was missing :slight_smile:

7

Ack! :love_you_gesture:

8

For what it’s worth, the installer should set this up if you enable the salt plugin.