cyberkov.at

Herbert mach das! - OSAD 2022

Sat, 15 Oct 2022 16:45:00 +0200

Dieses Mal war ich wirklich nervös. Ursprünglich habe ich mir eingebildet, den Vortrag sehr technisch anzulegen und eher eine Einführung in Stackstorm zu geben. Jedoch ist mir dann aufgefallen, dass eigentlich nur sehr wenig über das “zusammen arbeiten”, das m.M.n. ja eigentlich das Wesentliche an StackStorm ist, existiert. Also habe ich mich getraut und die eher soften Seiten herausgestellt und gezeigt, wie das bei uns im Büro so funktioniert:

Die Vortragsfolien können hier oder auf der Vortragsseite heruntergeladen werden.

Diesmal habe ich auch versucht, die Präsentation mit showoff zu machen. Das hat einerseits wirklich Spass gemacht, weil das schreiben wirklich ein Genuss ist. Andererseits hats mich und Lukas schlaflose Nächste beschert, das CSS so hinzubekommen, dass niemand einen Unterschied zu unseren Powerpointfolien bemerkt ;-)

Deshalb ists auch diesmal eine statische HTML Seite geworden, weil ich an der PDF Erzeugung gescheitert bin. Man muss ja auch nicht alles können :-)

OSAD 2021

Tue, 19 Oct 2021 10:50:00 +0200

Auch dieses Jahr haben wir uns wieder, leider nur virtuell, auf die Open Source Automation Days gewagt, um ein wenig aus unserem Alltag zu erzählen. Ich habe eine Integration unseres Ticketsystem in die Foreman Remote Execution gebaut, um damit automatisiertes Patching von Linux, sowie zukünftig auch Windows, durchzuführen.

Wie das grob umrissen funktioniert kann man hier sehen:

Die Vortragsfolien können hier oder auf der Vortragsseite heruntergeladen werden.

foreman provisioning tests mit gitlab-ci und serverspec

Thu, 03 Dec 2020 00:00:00 +0100

Eine meiner Hauptbeschäftigungen ist die Administration unseres Foreman/orcharhino und Pflege der diversen Betriebssysteme, die wir tagtäglich an unsere Kunden ausliefern. Nachdem immer wieder neue Releases kommen, Anforderungen verändert werden oder einfach mal ein Update des Betriebssystems den Provisionierungsprozess verändert, habe ich mir mal die Zeit genommen einen automatischen Test des Provisionings zu bauen. Hier hat sich gitlab-ci mit den kürzlich eingeführten Rules als sehr nützlich erwiesen. Davor habe ich mir Jenkins von unseren Entwicklern ausgeborgt, aber voll integriert in gitlab find ichs irgendwie schöner.

Der Ablauf in .gitlab-ci.yml:

workflow:
    rules:
        - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
stages:
    - build
    - wait
    - verify
    - cleanup

hammer host create erzeugt den Server in VMWare.

.build: &build
    image: hammer:latest
    stage: build
    resource_group: foreman
    only:
        - master
    before_script:
        - hammer auth login basic -u ${FOREMAN_USER} -p ${FOREMAN_PASSWORD}
    script:
        - ./build_${OS}.sh

hammer ist das commandline interface für Foreman.

Damit die Authentifizierung bei Foreman funktioniert muss der session support in hammer aktiviert werden. Dies mache ich bereits im hammer-image mit sed.

Das build_ubuntu2004.sh enthält dann die notwendigen Parameter. Hier fand ich möglichst wenig Dynamik vorteilhaft, da meine Kollegen gerne solche Commands kopieren wenn mal mehr hosts aufzusetzen sind. Der geneigte Leser kann dies auch gerne mit Makefiles (und argbash zB) und/oder anderen Dingen vereinfachen.

hammer \
  host create \
  --name="ubuntu20" \
  --domain "test.lan" \
  --ip="192.168.5.20" \
\
  --operatingsystem "Ubuntu 20.04 LTS" \
  --partition-table "preseed-default" \
  --medium "Ubuntu" \
  --lifecycle-environment-id 1 \
  --content-view "Ubuntu 20.04" \
\
  --subnet 'provisioning_tests' \
  --organization 'APA-IT' \
  --location 'DC1' \
  --compute-profile "small" \
  --hostgroup-title "Canary" \
  --compute-resource='vcenter' \
  --compute-attributes='start=1,annotation="provisioning tests #nobackup# required.",guest_id="ubuntu64Guest"'

wait-for-it.sh testet regelmäßig ob ein Login per ssh möglich ist. Da der Key erst mit dem ersten puppetrun ausgebracht wird, wird sichergestellt dass wir “nicht zu früh” vorbeikommen.

.wait: &wait
    stage: wait
    image: toughiq/toolbox:gitlab
    only:
        - master
    before_script:
        - 'which ssh-agent || ( apk add openssh-client )'
        - eval $(ssh-agent -s)
    script:
        - ./wait.sh $OS_IP

wait.sh sieht entsprechend aus:

#!/bin/bash
# shellcheck disable=SC1090
set -euo pipefail
IFS=$'\n\t'
OS_IP=$1

# We need to wait for the ssh port to be reachable
./utils/wait-for-it.sh -h "${OS_IP}" -p 22 -t 1800 && \

echo "Waiting for puppet to finish..." # && sleep 600

until ssh "${OS_IP}" -l provtest -o "PasswordAuthentication=no" -o "StrictHostKeyChecking=no" -o "UserKnownHostsFile=/dev/null" id; do
  echo "sleeping 2 seconds until ssh becomes available..." && sleep 2
done

echo "Login successful. Continuing in a few seconds..."
sleep 60

echo 'Done waiting.'

serverspec überprüft ob die Anforderung erfüllt sind und nicht versehentlich Settings geändert wurden

.verify: &verify
    stage: verify
    image: serverspec:latest
    only:
        - master
    artifacts:
        when: always
        paths:
            - rspec.xml
        reports:
            junit: rspec.xml
    before_script:
        - 'which ssh-agent || ( apk add openssh-client )'
        - eval $(ssh-agent -s)
    script:
        - rake spec:${OS_FQDN}

spec/base_spec.rb sieht dann zum Beispiel so aus:

require 'spec_helper'

describe port(22) do
  it { should be_listening }
end

describe cron do
  its(:table) do
    should match %r{/opt/puppetlabs/bin/puppet agent --onetime --no-daemonize}
  end
end

describe package('sudo') do
  it { should be_installed }
end

cleanup löscht den Server mittels hammer host delete:

.cleanup: &cleanup
    stage: cleanup
    image: hammer:latest
    when: always
    resource_group: foreman
    allow_failure: true
    before_script:
        - hammer auth login basic -u ${FOREMAN_USER} -p ${FOREMAN_PASSWORD}
    script:
        - hammer host delete --name ${OS_FQDN}
    only:
        - master

Ab hier kopiert man die jeweilige Konfiguration und lädt die dazupassenden Steps:

# OS Config
.ubuntu2004: &ubuntu2004
  variables:
    OS: ubuntu2004
    OS_FQDN: ubuntu20.test.lan
    OS_IP: '192.168.5.20'
ubuntu2004:build:
  <<: [*ubuntu2004, *build]
ubuntu2004:wait:
  needs: ['ubuntu2004:build']
  <<: [*ubuntu2004, *wait]
ubuntu2004:verify:
  needs: ['ubuntu2004:wait']
  <<: [*ubuntu2004, *verify]
ubuntu2004:cleanup:
  needs: ['ubuntu2004:verify']
  <<: [*ubuntu2004, *cleanup]

Jetzt nur noch den Build regelmäßig von gitlab triggern lassen - fertig.

Leider musste ich nahezu alle DockerImages selbst bauen, welche jedoch relativ simpel sind (serverspec installieren, hammer nach Anleitung installieren).

Ein wenig störend fand ich jeden Tag ein Email von Foreman zu bekommen, dass alle Server erfolgreich gebaut wurden. Hier wäre es schön einen Schalter in hammer zu haben um built notifications für diesen Host abzuschalten.

OSAD 2019

Tue, 29 Oct 2019 22:33:59 +0100

Hab ich mich doch mal getraut einen Vortrag auf einer Konferenz, in diesem Fall den Open Source Automation Days 2019 in München zu halten. Ergeben hat sich dies kurzfristig, da ein Vortragender krankheitsbedingt ausgefallen ist und ich eigentlich eh schon länger mal über onceover sprechen wollte. So hab ich am Vortag noch schnell ein paar Slides zusammengebaut…

Die Folien können hier oder auf der Vortragsseite abgerufen werden.

pushing metrics with mqtt

Thu, 15 Jan 2015 11:37:01 +0100

I came across a really good post from J.P.Mens, who wrote the brilliant mqttwarn script to effectively send MQTT messages to different types of services. Since I was in the mood to finally switch my Nagios instance running on the old monitoring box to Icinga, I decided to give mqttwarn a shot as wll.

Until now I’m really impressed how easy the setup, despite there is no debian package for it (I defintely should create one :) ).

Since I tried to get the metrics from openhab over the internet into my InfluxDB instance running on my webserver and failed, I wanted to have something more reliable in place. Thats when I found mqttwarn to replace it.

Install the mqtt-presistence in openhab
setup openhab.cfg with your mqtt server (I’m using RabbitMQ but I guess Mosqitto would do as well)
add the persistence file for mqtt
Setup mqttwarn on the server
enable the Grahite input in InfluxDB (Port 2003)
…
Profit!

OpenHAB and vim

Thu, 15 Jan 2015 11:13:36 +0100

Recently I started using OpenHAB to automate my house. Unfortunately the OpenHAB Designer is a real PAI for the default use case in my opinion. Usually I would expect that the core runtime is installed on a linux box (e.g. a Raspberry PI or something) and the designer is used on a Desktop. So how does the data get to the server?

One possibility would be to use Dropbox, using the Dropbox bundle to have OpenHAB fetch the folder and reload it’s config. I found this to be relatively uncomfortable for development, since you don’t get instant feedback if it works as expected. So I decided to ssh into the box running openhab and edit the files directly in the configuration folder. Well I guess the problem is clear. To use the designer, one would need to have a graphical interface or X-Forwarding enabled (including having all the necessary libraries installed which also not an option on the server).

Therefore I created a vim syntax file, which can be downloaded from https://github.com/cyberkov/openhab-vim. As of now it works, but I don’t feel like I’m really using all the features of syntax highlighting of vim. Especially I don’t think the folding features are working and the automatic indentation.

I still hope it’s helping and I would be glad about any pull requests and improvements :-)

Wisdom of the ancients

Wed, 11 Jan 2012 00:00:00 +0100

Via xkcd

cool tools

Wed, 11 Jan 2012 00:00:00 +0100

Today at DevOpsDays Göteborg we rounded out the day’s events with an Open Space session on Cool Tools. Basically I wanted to have a session where as experts in our field we can suggest life-saving, life-changing or just handy tools we use from day to day that others may not be aware of. Each person got up, said some small amount about the tool in question and wrote it on the board. In the end we had a board full of suggestions and used up all the time!

So in the interests of posterity here is the list:

Graphite – metrics
RVM – Ruby Gem versioning
rbenv – Ruby Gem versioning
Maatkit/Percona-toolkit – DB Toolkit
Soasta Cloudtest – Load testing
Sahara – Vagrant sandboxing/snapshotting
collectd – metrics
git-subtree – Git add-ons
ksar – graphical sar
ngrep – network packet grep
tcpflow – TCP flow recorder
ack-grep – grep replacement
keepass* – password store
statsite – statistics server
notmuch/mutt-notmuch – mail indexer/search
sup-mail – mutt on steroids
charles – http dumper
gx – smart git pull and other tools
ItsAllText! – textarea editing with external programme in firefox
vimdiff – side-by-side diff in vim
meld – UI-based diff/merge tool
nvALT – searchable snippet editor
bash-it – community bash configs
pandoc – markup format convertor
gitflow – git extensions
etckeeper – config SCM
Hg Mq – mercurial patch management
ReviewBoard – peer review tool
gerrit – peer review tool for git
Beetil – ITIL tracker
xperf/symchk – profiling on Windows
oprofile – system profiling for Linux
perftools.rb – Ruby profiling
eatmydata – transparently disable fsyncs
MMS – MongoDB monitoring service
VPN-Cubed – inter-cloud-domain VPN
jclouds/Deltacloud/Libcloud/fog – cloud abstraction APIs
mtr – matt’s traceroute
gltail – log visualisation
varnishreplay – cache warming / http testing
conntrack-tools – firewall HA tools

So there you have it. Please let me know if any of the URLs are wrong, and I hope some of these links help you in some way!

Via paperairoplane.net

Diaspora

Mon, 23 May 2011 00:00:00 +0200

Diaspora hat vor knapp einem Jahr für Aufsehen in den Medien gesorgt, durch das Versprechen eine gut eund sichere Alternative für Facebook zu werden.

Jeder kann seine Daten auf eigenen “Pods” ablegen und selbst entscheiden ob er diese veröffentlichen will. Er kann seine Posts löschen und auch nur bestimmten Personen zugänglich machen, wie es ihm oder ihr gefällt.

Ich habe nun die Gelegenheit genutzt und ein wenig hineinzuschnuppern und bin vollends überzeugt worden. Daher gibt es für alle die es interssiert nun auch einen diaspora pod unter https://foobar.cx/

Natürlich gibt es dort ebenfalls eine Facebook und Twitterintegration um nicht den Anschluss zu den alten Kontakten zu verlieren.

IPv6

Thu, 13 May 2010 00:00:00 +0200

Nachdem ich in den letzten Tagen sehr erfolgreich den IPv6 Tunnel von SixXS in Betrieb genommen habe, Firewall konfiguriert und Subnet beantragt, ist es nun an der Zeit meine Webseiten auf IPv6 ebenfalls umzustellen. Daher ist nun auch cyberkov.at hier angekommen und über ipv6.cyberkov.at (oder auf herkömmlichen Wege über cyberkov.at) erreichbar.