salt jobs anzeigen und killen

Es kann hin und wieder mal vorkommen, dass man ein salt Kommando mit Ctrl-C beenden möchte. Der Job läuft jedoch weiter und kann wie folgt gekillt werden:

susemanager:/srv/salt # salt minion saltutil.running
minion:
    |_
      ----------
      arg:
      fun:
	  state.apply
      jid:
	  20180122140250113092
      pid:
	  18939
      ret:
      tgt:
	  minion
      tgt_type:
	  glob
      user:
	  root
susemanager:/srv/salt # salt minion saltutil.kill_job 20180122140250113092
minion:
    Signal 9 sent to job 20180122140250113092 at pid 18939

Automatisches ausführen von Highstate

Ein regelmäßiges Highstate kann natürlich über cron getriggert werden ( oder über die minion.conf auf dem client), eleganter ist es jedoch, das über pillars zu machen.

Man legt /srv/pillar an. Dort kommt ein top.sls rein, das sieht im Prinzip so aus wie ein salt top.sls

susemanager:/srv/salt # cat ../pillar/top.sls
base:
   '*':
     - schedule

Dort wird also auf allen Server der pillar schedule ausgeführt.

susemanager:/srv/salt # cat ../pillar/schedule.sls
schedule:
  highstate:
    function: state.highstate
    minutes: 60

Die Änderungen an den Pillars müssen den minions mitgeteilt werden:

salt '*' saltutil.refresh_pillar

Und das wars auch schon, jetzt wird alle 60 Minuten ein highstate gemacht. Mehr Infos unter https://docs.saltstack.com/en/latest/topics/tutorials/pillar.html

Anzeigen lassen kann man sich das mit

susemanager:/srv/salt # salt minion pillar.get schedule
minion:
    ----------
    highstate:
	----------
	function:
	    state.highstate
	minutes:
	    60

Adressing salt Clients mit cmd.run und pillars

Mehrere Minions können mit -C ‘MinionA or MinionB’ angesprochen werden.

salt -C 'server1 or server2' test.ping

Grains kann man ebenfalls nutzen um nur einen Teil seiner Minions anzusprechen.

Alle SLES12 Systeme

salt -G 'osmajorrelease:12' cmd.run 'cat /etc/os-release'

Alle 12.3 Systeme:

salt -G 'osrelease:12.3' cmd.run 'cat /etc/os-release'

Die im Susemanager zugewiesen Gruppen werden als pillars auf den Systemen gepeichert. (nur bei den salt Clients)

susemanager:~ # salt MINION pillar.get group_ids
minion:
    - 12
    - 7
    - 10
    - 17

#Anzeigen der zypper Locks auf den Systemen in der Gruppe devel:

salt -I 'group_ids:9' cmd.run 'zypper ll'

Einzelne User mit salt anlegen

Einzelne Benutzer lassen sich schnell mit salt anlegen. Einfach die folgenden Statements in ein user.sls File schreiben und anschließend wie folgt vom salt-master testen. Sollen mehrer User angelegt werden, dan können die user.present Statements natürlich kopiert und angepasst werden. Bei einer größeren Anzahl wird das dann jedoch schnell unübersichtlich und spätestens dann sollte man über ein jinja2 templating nachdenken.

SLES # salt MINION state.apply user test=true

Wenn hierbei keine Fehler auftreten kann das test=true weggelassen werden.

add_USER_group :
  group.present :
    - name : USER
    - gid : 1201

add_USER :
  user.present :
    - name : USER
    - fullname: USER for something
    - shell: /bin/bash
    - home: /home/USER
    - uid: 1201
    - gid: 1201
    - groups :
      - users
      - video
    - createhome : True
    - password : $1$TFaCDG0s$xH.MAWxgptzfJuQgVBEst.

Den Passworthash erzeugt man mit:

SLES # openssl passwd -1
Password:
Verifying - Password:
$1$TFaCDG0s$xH.MAWxgptzfJuQgVBEst.

Welche Statefiles werden auf einen Minion angewandt?

Wenn man saltstack einsetzt kommt manchmal die Frage auf, welche Statefiles werden nun eigentlich auf dem speziellen Minion angewandt? Diese Frage lässt sich relativ einfach klären:

Auf dem Client nachsehen:

Angezeigt werden nicht nur die im top.sls definierten sondern auch die vom Suse Manager automatisch definierten.

SLES saltminion:~ # salt-call state.show_top
local:
----------
  base:
      - states.users.ssh_keys_root
      - custom_groups
      - states.packages.lshw_package
      - states.network.intra.ntp_conf
      - formulas
      - states.network.intra.proxy
      - states.network.intra.resolv_conf
      - states.users.ssh_keys
      - custom
      - channels
      - states.network.ntpd_restart
      - services.salt-minion
      - certs
      - services.docker
      - packages
      - custom_org
      - states.users.m42
      - states.packages.reboot_sh

vom Saltmaster aus

SLES saltmaster:~# salt server state.show_top
server:
    ----------
    base:
	- states.users.ssh_keys_root
	- custom_groups
	- states.packages.lshw_package
	- states.network.intra.ntp_conf
	- formulas
	- states.network.intra.proxy
	- states.network.intra.resolv_conf
	- states.users.ssh_keys
	- custom
	- channels
	- states.network.ntpd_restart
	- services.salt-minion
	- certs
	- services.docker
	- packages
	- custom_org
	- states.users.m42
	- states.packages.reboot_sh

Das Ergebnis sollte in beiden Fällen das gleiche sein.