News:
Expect to InSpec - Routine-Checks automatisieren

Mit dem kostenfreien Tool Inspec lassen sich Routine-Checks einfach automatisieren.

Icon Unternehmen

Eine Automatisierung der internen IT-Infrastruktur sollte in der heutigen Zeit zum guten Standard einer jeden Firma gehören. Platzhirsche wie z.B. "Puppet", "Chef" oder "Ansible" geben einen guten Einstieg in die automatisierte Installation und Konfiguration von Client- und Serverlandschaften.

Was ist aber zu tun, wenn man in der Projektarbeit auf fremden Strukturen unterwegs ist und jegliche Eingriffe strikt und einfach nicht möglich sind?

Vordefinierte Installationsrichtlinien sollten hierbei die Gleichheit von Systemen sicherstellen. Eine im Supportfall "bekannte", "routinierte" Umgebung vorzufinden, erleichtert und beschleunigt vor allem die Fehlersuche und -behebung.

Auch im Datenbank(server)-Umfeld sollten solche Richtlinien definiert und gelebt werden. Die Absicherung der Einhaltung ist hierbei ggf. zeitaufwendig. Checklisten abhaken ist, zugegeben, nicht die Lieblingsaufgabe eines jeden IT-Mitarbeiters.

Abhilfe schafft hier das kostenfreie Tool "inspec" vom Softwareentwickler "Chef". Inspiriert wurden die Entwickler hierbei durch die Software "ServerSpec", welche der Vollständigkeit halber als Alternative genannt werden sollte.

Dieser Artikel behandelt jedoch "InSpec" und dessen Einsatzmöglichkeit(en) im Oracle-Bereich.

"Sehr geehrte Damen und Herren,

der neue neue Server 'XYZ' steht zur Installation der Oracle Datenbanksoftware und Erzeugung einer Instanz bereit!
[...]"

Und jetzt? Wurden alle nötigen Vorbereitungen getroffen? Sind alle relevanten Pakete installiert? Laufen alle Dienste?
Die Prüfung des installierten Betriebssystems ist zeitaufwendig - also wird diese Aufgabe durch "InSpec" erledigt.

Vorab aber, als kleine - und kurze - Einführung, folgende Erklärung:
Inspec ist in Ruby verfasst und versteht somit auch selbige Syntax. Projekte werden in "Profiles" zusammengefasst, welche eine oder mehrere "Controls" beinhalten können.

Im hier dargelegten Beispiel wäre dies das Profile "00-operating-system" mit den Controls: "filesystem", "kernel-parameters", "network", "packages", "services" und "users".
Variablendefinitionen können in einem "attributes.yml"-File als Key-Value-Paare hinterlegt werden.

Damit wir einen detaillierten Einblick in eines dieser Controls haben, hier der Inhalt von "services.rb":

  control "services" do
    #--[ metadata ]
    impact 1.0
    title "verify services and daemons"
    desc '
      This control verifies the [non] existence and status of specific service and daemons.
      '
      tag 'os','services','daemons','systemd'

      #--[ systemd ]
      describe file('/etc/systemd/logind.conf') do
      its('content') { should match /RemoveIPC\s?=\s?no/ }
      end

      #--[ syslog ]
      describe file('/etc/rsyslog.conf') do
      its('content') { should match /^kern.*\t*\/var\/log\/kern/ }
      end
      describe file('/etc/logrotate.d/syslog') do
      its('content') { should match /\/var\/log\/kern/ }
      end

      #--[ ntpd/ ntpdate ]
      describe file('/etc/sysconfig/ntpd') do
      its('content') { should match /-x/ }
      its('content') { should match /-p \/var\/run\/ntpd.pid/ }
      end

      describe file('/etc/sysconfig/ntpdate') do
      its('content') { should match /SYNC_HWCLOCK\s?=\s?yes/ }
      end

      describe file('/etc/ntp/step-tickers') do
      its('content') { should match /(([0-9a-zA-z]*)\.?)+/ }
      end

      describe systemd_service('ntpd') do
      it { should be_installed }
      it { should be_enabled }
      it { should be_running }
      end

      describe systemd_service('ntpdate') do
      it { should be_installed }
      it { should be_enabled }
      it { should be_running }
      end

      #--[ NetworkManager ]
      describe systemd_service('NetworkManager') do
      it { should_not be_enabled }
      it { should_not be_installed }
      it { should_not be_running }
      end

      #--[ selinux ]
      describe file('/etc/sysconfig/selinux') do
      its('content') { should match /SELINUX\s?=\s?disabled/ }
      end

  end

An diesem Beispiel ist gut zu erkennen, wie "InSpec" in der Syntax versucht, eine "Lesbarkeit" zu integrieren. Der Zustand eines Services "should be_installed" oder "should be_running" vereinfacht die Verständlichkeit der Tests enorm.

Ein Beispiel:

[root@c-two-sandbox-01 inspec]# inspec exec profiles/00-operating-system --controls=services --attrs=profiles/00-operating-system/attributes/attributes.yml

  Profile: ASPICON GmbH Quality Assurance (operating-system)
  Version: 0.1.0
  Target:  local://

    ✔  services: verify services and daemons
      ✔  File /etc/systemd/logind.conf content should match /RemoveIPC\s?=\s?no/
      ✔  File /etc/rsyslog.conf content should match /^kern.*\t*\/var\/log\/kern/
      ✔  File /etc/logrotate.d/syslog content should match /\/var\/log\/kern/
      ✔  File /etc/sysconfig/ntpd content should match /-x/
      ✔  File /etc/sysconfig/ntpd content should match /-p \/var\/run\/ntpd.pid/
      ✔  File /etc/sysconfig/ntpdate content should match /SYNC_HWCLOCK\s?=\s?yes/
      ✔  File /etc/ntp/step-tickers content should match /(([0-9a-zA-z]*)\.?)+/
      ✔  Service ntpd should be installed
      ✔  Service ntpd should be enabled
      ✔  Service ntpd should be running
      ✔  Service ntpdate should be installed
      ✔  Service ntpdate should be enabled
      ✔  Service ntpdate should be running
      ✔  Service NetworkManager should not be enabled
      ✔  Service NetworkManager should not be installed
      ✔  Service NetworkManager should not be running
      ✔  File /etc/sysconfig/selinux content should match /SELINUX\s?=\s?disabled/   

    Profile Summary: 1 successful control, 0 control failures, 0 controls skipped
    Test Summary: 24 successful, 0 failures, 0 skipped

Unser Test/ unsere Control war erfolgreich! Alle definierten Tests wurden mit einem Haken ("✔") quittiert und - hier nicht ersichtlich - im Output grün hinterlegt.
Im Fehlerfall würden hier ein "X" und eine rote Kennzeichnung erscheinen:

  [root@c-two-sandbox-01 inspec]# service ntpdate stop
  Redirecting to /bin/systemctl stop ntpdate.service
  [root@c-two-sandbox-01 inspec]# inspec exec profiles/00-operating-system --controls=services --attrs=profiles/00-operating-system/attributes/attributes.yml

  Profile: ASPICON GmbH Quality Assurance (operating-system)
  Version: 0.1.0
  Target:  local://

    ×  services: verify services and daemons (1 failed)
      ✔  Service oswatcher should be installed
      ✔  Service oswatcher should be enabled
      ✔  Service oswatcher should be running
      ✔  File /etc/systemd/logind.conf content should match /RemoveIPC\s?=\s?no/
      ✔  File /etc/rsyslog.conf content should match /^kern.*\t*\/var\/log\/kern/
      ✔  File /etc/logrotate.d/syslog content should match /\/var\/log\/kern/
      ✔  File /etc/sysconfig/ntpd content should match /-x/
      ✔  File /etc/sysconfig/ntpd content should match /-p \/var\/run\/ntpd.pid/
      ✔  File /etc/sysconfig/ntpdate content should match /SYNC_HWCLOCK\s?=\s?yes/
      ✔  File /etc/ntp/step-tickers content should match /(([0-9a-zA-z]*)\.?)+/
      ✔  Service ntpd should be installed
      ✔  Service ntpd should be enabled
      ✔  Service ntpd should be running
      ✔  Service ntpdate should be installed
      ✔  Service ntpdate should be enabled
      ×  Service ntpdate should be running
      expected that `Service ntpdate` is running
      ✔  Service NetworkManager should not be enabled
      ✔  Service NetworkManager should not be installed
      ✔  Service NetworkManager should not be running
      ✔  File /etc/sysconfig/selinux content should match /SELINUX\s?=\s?disabled/
      ✔  firewalld should not be running
      ✔  Service chrony should not be enabled
      ✔  Service chrony should not be installed
      ✔  Service chrony should not be running

  Profile Summary: 0 successful controls, 1 control failure, 0 controls skipped
  Test Summary: 23 successful, 1 failure, 0 skipped

Der Service läuft nicht - der Test wurde also nicht bestanden (ein "expected" weist hierbei zusätzlich auf den Idealzustand hin)!

Fazit

Mit etwas Zeit und dem bekannten "Gehirnschmalz" bekommt man schnell die ersten Controls auf die Beine gestellt. Die Community - und die Entwickler von Chef und InSpec selbst - ist sehr schnelllebig und Bugs werden nahezu umgehend behoben. Ist man also nicht abgeneigt, sich der Ruby-Syntax etwas zu widmen, kann man in Zukunft dem QA-Management schnell und einfach Ergebnisse liefern.

InSpec ist mit einer Vielfalt von Output-Formaten ("documentation", "html", "json", etc.) auch für Dokumentationszwecke ein sehr gute Alternative zu bekannten Tools wie beispielsweise dem RDA-Report.