OSCamp on Foreman: Program is online!

Together with Red Hat we present the program for the Open Source Camp on Foreman! Learn about topics like automation, remote execution, and provisioning in the cloud, and the latest know-how and how-to’s from top-level speakers like:

OSCamp on Foreman is organized by NETWAYS and supported by Red Hat. The event takes place directly after the lecture program of OSMC on November 07, 2019 in Nuremberg. Meet like-minded people, share expertise and discover new grounds! Get your ticket at opensourcecamp.de

Julia Hornung
Julia Hornung
Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

Logstash automatisiert ausrollen? Freilich!

Der Lennart sagt mir ja immer, ich soll nicht über ungelegte Eier sprechen, aber momentan fasziniert mit das Thema einfach zu viel, als dass ich nicht drüber was schreiben könnte. Dass ich gern mit dem Elastic Stack arbeite, sollten auch weniger aufmerksamere Leser schon mitbekommen haben, aber mit Ansible hab’ ich mich bisher recht zurückgehalten. Da ich aber eigentlich beides ganz gern mag, dachte ich mir, ich verbinde es mal.

 

Mit Ansible ist es wie bei den meisten Configmanagementsystemen: Man fängt mal an, was zu bauen, findet’s gut, lernt was dazu, findet’s nicht mehr gut, baut’s neu, findet’s richtig gut, lernt dazu, findet’s eher mies, baut’s neu, ein Loch ist Eimer, lieber Reinhard, lieber Reinhard.

Deshalb dachte ich, ich bemüh’ mich jetzt mal, eine Rolle für Logstash zu bauen, die man auch wirklich guten Gewissens so rausgeben kann. Falls was nicht so schön ist, gibt’s dann wenigstens die ganzen lieben Leute da draußen, die Pull Requests machen *wink*. Hier also der aktuelle Stand unserer Ansible Rolle für Logstash.

Ich geb’ ja zu, es ist noch eine recht frühe Version, aber sie ist immerhin so gebaut, dass sie umfassend konfigurierbar ist und auch der Linter von ansible-galaxy beschwert sich dabei nicht mehr. Anders ausgedrückt: Sie kann noch nicht extrem viel, aber das, was sie kann, kann sie ziemlich gut, meiner Meinung nach.

Ein schönes Feature, das mir besonders zusagt ist, dass sie einen dazu bringt, die Konfiguration der einzelnen Pipelines in einem Git Repository zu pflegen und zwar ein Repository pro Pipeline. Damit kann man die Rolle schön in Kombination mit unserer Logstash Pipeline für Icinga Logs nutzen. Ein paar Beispielpipelines, die aktuell nur Logs von A nach B schaufeln, habe ich in meinen persönlichen GitHub Account gelegt, von wo sie auch als Beispiele bei der Installation verwendet werden können. Ob das so bleibt, entscheidet sich noch, auf jeden Fall soll die Pipeline mit minimaler oder keiner Konfiguration zumindest mal Basisfunktionalität in Logstash herstellen. Ganz so, wie Elastic das geplant hat – ein einfacher Einstieg für Neulinge. Aber auch ausgefeiltere Setups sind damit möglich.

Besonders gut funktioniert die Rolle übrigens gemeinsam mit einer Rolle für Redis, aber das ist alles in der Readme beschrieben.

Weitere Rollen zum Rest vom Stack werden wohl noch kommen und die Logstash Rolle kann auch noch einiges an zusätzlichen Konfigoptionen brauchen. Lasst Euch also nicht aufhalten, Issues aufzumachen oder Pullrequests zu schicken.

 

Thomas Widhalm
Thomas Widhalm
Lead Support Engineer

Thomas war Systemadministrator an einer österreichischen Universität und da besonders für Linux und Unix zuständig. Seit 2013 möchte er aber lieber die große weite Welt sehen und hat sich deshalb dem Netways Consulting Team angeschlossen. Er möchte ausserdem möglichst weit verbreiten, wie und wie einfach man persönliche Kommunikation sicher verschlüsseln kann, damit nicht dauernd über fehlenden Datenschutz gejammert, sondern endlich was dagegen unternommen wird. Mittlerweile wird er zum logstash - Guy bei Netways und hält...

Managing your Ansible Environment with Galaxy

Ansible is known for its simplicity, lightweight footprint and flexibility to configure nearly any device in your infrastructure. Therefore it’s used in large scale environments shared between teams or departments. This leads to even bigger Ansible environments which need to be tracked or managed in version control systems like Git.

Mostly environments grow with their usage over time, in this case it can happen that all roles are managed inside one big repository. Which will eventually lead to quite messy configuration and loss of knowledge if roles are tested or work the way they supposed to work.

Ansible provides a solution which is called Galaxy, it’s basically a command line tool which keeps your environment structured, lightweight and enforces your roles to be available in a specific version.

First of all you can use the tool to download and manage roles from the Ansible Galaxy which hosts many roles written by open-source enthusiasts. 🙂


# ansible-galaxy install geerlingguy.ntp -v
Using /Users/twening/ansible.cfg as config file
 - downloading role 'ntp', owned by geerlingguy
 - downloading role from https://github.com/geerlingguy/ansible-role-ntp/archive/1.6.4.tar.gz
 - extracting geerlingguy.ntp to /Users/twening/.ansible/roles/geerlingguy.ntp
 - geerlingguy.ntp (1.6.4) was installed successfully

# ansible-galaxy list
# /Users/twening/.ansible/roles
 - geerlingguy.apache, 3.1.0
 - geerlingguy.ntp, 1.6.4
 - geerlingguy.mysql, 2.9.5

Furthermore it can handle roles from your own Git based repository. Tags, branches and commit hashes can be used to ensure it’s installed in the right version.


ansible-galaxy install git+https://github.com/Icinga/ansible-icinga2.git,v0.2.0
 - extracting ansible-icinga2 to /Users/twening/.ansible/roles/ansible-icinga2
 - ansible-icinga2 (v0.2.0) was installed successfully

It’s pretty neat but how does this help us in large environments with hundreds of roles?

The galaxy command can read requirement files, which are passed with the “-r” flag. This requirements.yml file can be a replacement for roles in the roles path and includes all managed roles of the environment.


# vim requirements.yml
- src: https://github.com/Icinga/ansible-icinga2.git
  version: v0.2.0
  name: icinga2

- src: geerlingguy.mysql
  version: 2.9.5
  name: mysql

Then run ansible-galaxy with the “–role-file” parameter and let galaxy manage all your roles.


# ansible-galaxy install -r requirements.yml
 - icinga2 (v0.2.0) is already installed, skipping.
 - downloading role 'mysql', owned by geerlingguy
 - downloading role from https://github.com/geerlingguy/ansible-role-mysql/archive/2.9.5.tar.gz
 - extracting mysql to /Users/twening/.ansible/roles/mysql
 - mysql (2.9.5) was installed successfully

In case you work with Ansible AWX, you can easily replace all your roles with this file in the roles directory and AWX will download and manage your roles directory automatically.

A example project could look like this.


awx_project/
├── example_playbook.yml
├── group_vars
├── host_vars
├── hosts
└── roles
    └── requirements.yml

In summary, in large environments try to keep your code and configuration data separated, try to maintain your roles in their own repository to avoid conflicts at the main project.

Check out our Blog for more awesome posts and if you need help with Ansible send us a message or sign up for one of our trainings!

Thilo Wening
Thilo Wening
Consultant

Thilo hat bei NETWAYS mit der Ausbildung zum Fachinformatiker, Schwerpunkt Systemadministration begonnen und unterstützt nun nach erfolgreich bestandener Prüfung tatkräftig die Kollegen im Consulting. In seiner Freizeit ist er athletisch in der Senkrechten unterwegs und stählt seine Muskeln beim Bouldern. Als richtiger Profi macht er das natürlich am liebsten in der Natur und geht nur noch in Ausnahmefällen in die Kletterhalle.
Ansible + Icinga 2 = #monitoringlove

Ansible + Icinga 2 = #monitoringlove

Nein, ich bin nicht auf den Hype als solchen mit aufgesprungen. Es ist nur so… Ansible ist extrem nützlich. Und genau das werde ich anhand eines konkreten Beispiels aufzeigen: Ein Icinga 2 Cluster, vollständig aufgesetzt mit Ansible.

Vorkenntnisse

Wer noch nicht weiß, was zum Geier ein Icinga 2 Cluster und/oder Ansible ist, sollte sich vor dem Weiterlesen entsprechend einarbeiten, am besten im Rahmen einer entsprechenden Schulung in unserem Hause:

Alternativ ginge auch das wesentlich mühseligere Selbststudium:

Umgebung

So ein bisschen sensationell soll der Cluster schon sein, aber mit zunehmenden VMs wird es auch zunehmend eng auf meinem Arbeitsgerät. Wie praktisch, dass wir bei NWS einen OpenStack haben, dem ich mal schnell mit Terraform 14 VMs reindrücken kann (2 Master, 2 Satelliten und 10 Agents):

resource "openstack_compute_instance_v2" "aklimov-icinga2" {
	count = 14
	name = "aklimov-icinga2-${count.index}"
	image_name = "Centos 7"
	flavor_name = "s1.small"
	network { name = "${var.tenant_network}" }
	security_groups = [ "default", "Icinga" ]
	key_pair = "${var.openstack_keypair}"
}

Mit einem kleinen Skript in der Sprache meiner Wahl erstelle ich mir anhand der Terraform-Daten mehr oder weniger automatisch ein Ansible-Inventory (inventory.txt):

aklimov-icinga2-5 ansible_host=10.77.27.54 ansible_user=centos
aklimov-icinga2-4 ansible_host=10.77.27.45 ansible_user=centos
aklimov-icinga2-7 ansible_host=10.77.27.51 ansible_user=centos
aklimov-icinga2-9 ansible_host=10.77.27.40 ansible_user=centos
aklimov-icinga2-12 ansible_host=10.77.27.28 ansible_user=centos
aklimov-icinga2-13 ansible_host=10.77.27.18 ansible_user=centos
aklimov-icinga2-10 ansible_host=10.77.27.12 ansible_user=centos
aklimov-icinga2-1 ansible_host=10.77.27.34 ansible_user=centos
aklimov-icinga2-6 ansible_host=10.77.27.20 ansible_user=centos
aklimov-icinga2-3 ansible_host=10.77.27.49 ansible_user=centos
aklimov-icinga2-11 ansible_host=10.77.27.19 ansible_user=centos
aklimov-icinga2-0 ansible_host=10.77.27.21 ansible_user=centos
aklimov-icinga2-2 ansible_host=10.77.27.46 ansible_user=centos
aklimov-icinga2-8 ansible_host=10.77.27.50 ansible_user=centos

Auf die Plätze, fertig, Ansible!

Zunächst verifiziere ich die Funktionalität der VMs und sammle nebenbei deren öffentliche SSH-Schlüssel ein:

ansible all -i inventory.txt -m ping \
--ssh-common-args='-o StrictHostKeyChecking=no'

Ist das getan, geht es auch schon los mit dem Ansible-Playbook (playbook.yml):

---
- name: Icinga 2
  hosts: all
  become: yes
  become_method: sudo
  tasks:
  - name: EPEL repo
    yum:
      name: epel-release
  - name: Icinga repo key
    rpm_key:
      key: https://packages.icinga.com/icinga.key
  - name: Icinga repo
    yum:
      name: https://packages.icinga.com/epel/icinga-rpm-release-7-latest.noarch.rpm
  - name: Icinga 2 package
    yum:
      name: icinga2
  - name: Monitoring plugins
    yum:
      name: nagios-plugins-all
  - name: Icinga 2 service
    service:
      name: icinga2
      state: started
      enabled: yes
# (...)

Ein paar Repositories, ein paar Pakete – und Icinga ist auch schon einsatzbereit. Fehlt nur noch der eigentliche Cluster:

---
- name: Icinga 2
# (...)
- name: Icinga PKI master
  hosts: aklimov-icinga2-0
  become: yes
  become_method: sudo
  tasks:
  - name: Icinga 2 cluster setup
    shell: >
      icinga2 node setup
      --zone master
      --listen 0.0.0.0,5665
      --cn {{ inventory_hostname }}
      --master
      --disable-confd;
      rm -f /var/cache/icinga2/icinga2.vars
    args:
      creates: /var/lib/icinga2/certs/ca.crt
    notify: Restart Icinga 2
  - name: /var/cache/icinga2/icinga2.vars
    shell: icinga2 daemon -C
    args:
      creates: /var/cache/icinga2/icinga2.vars
  - name: Icinga 2 PKI ticket
    with_inventory_hostnames:
    - 'all:!{{ inventory_hostname }}'
    shell: >
      icinga2 pki ticket --cn {{ item }}
      >/var/cache/icinga2/{{ item }}.ticket
    args:
      creates: '/var/cache/icinga2/{{ item }}.ticket'
  - name: Fetch Icinga 2 PKI ticket
    with_inventory_hostnames:
    - 'all:!{{ inventory_hostname }}'
    fetch:
      dest: .tempfiles
      src: '/var/cache/icinga2/{{ item }}.ticket'
  - name: Fetch Icinga 2 master cert
    fetch:
      dest: .tempfiles
      src: '/var/lib/icinga2/certs/{{ inventory_hostname }}.crt'
  handlers:
  - name: Restart Icinga 2
    service:
      name: icinga2
      state: restarted
# (...)

Zuerst wird der Knoten eingerichtet, der allen anderen Tickets und später SSL/TLS Zertifikate ausstellt. Dann werden auch schon die Tickets ausgestellt, nachdem /var/cache/icinga2/icinga2.vars dafür neu erstellt wurde. Diese Tickets und das Zertifikat des Knotens werden danach in das Verzeichnis .tempfiles heruntergeladen. Die anderen Knoten brauchen diese Dateien, um sich automatisch an den Cluster anzuschließen:

---
- name: Icinga 2
# (...)
- name: Icinga PKI master
# (...)
- name: Icinga cluster nodes
  hosts: 'all:!aklimov-icinga2-0'
  become: yes
  become_method: sudo
  tasks:
  - name: Icinga master cert
    copy:
      dest: /var/cache/icinga2/trusted.crt
      owner: icinga
      group: icinga
      mode: '0644'
      src: .tempfiles/aklimov-icinga2-0/var/lib/icinga2/certs/aklimov-icinga2-0.crt
  - name: Icinga PKI ticket
    copy:
      dest: /var/cache/icinga2/my.ticket
      owner: icinga
      group: icinga
      mode: '0600'
      src: '.tempfiles/aklimov-icinga2-0/var/cache/icinga2/{{ inventory_hostname }}.ticket'
  - name: Icinga 2 cluster setup
    shell: >
      icinga2 node setup
      --zone {{ inventory_hostname }}
      --endpoint aklimov-icinga2-0,{{ hostvars['aklimov-icinga2-0'].ansible_all_ipv4_addresses[0] }},5665
      --parent_host {{ hostvars['aklimov-icinga2-0'].ansible_all_ipv4_addresses[0] }},5665
      --parent_zone master
      --listen 0.0.0.0,5665
      --ticket `cat /var/cache/icinga2/my.ticket`
      --trustedcert /var/cache/icinga2/trusted.crt
      --cn {{ inventory_hostname }}
      --accept-config
      --accept-commands
      --disable-confd
    args:
      creates: /var/lib/icinga2/certs/ca.crt
    notify: Restart Icinga 2
  handlers:
  - name: Restart Icinga 2
    service:
      name: icinga2
      state: restarted

Und ab dafür:

ansible-playbook -i inventory.txt playbook.yml

Voilà!

(...)

PLAY RECAP *******************************************************************************************************
aklimov-icinga2-0          : ok=14   changed=12   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-1          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-10         : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-11         : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-12         : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-13         : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-2          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-3          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-4          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-5          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-6          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-7          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-8          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
aklimov-icinga2-9          : ok=12   changed=10   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Jetzt fehlt nur noch die Icinga-Konfiguration. Aber diese überlasse ich keinem geringeren als dem Icinga Director.

Fazit

Was man nicht alles von A bis Z automatisieren kann!

Viel Spaß beim Nachmachen in der NWS Cloud!

Alexander Klimov
Alexander Klimov
Developer

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der...

Foreman’s 10th birthday – The party was a blast

Birthday Logo

I can still remember when Greg had the idea of celebrating the Foreman’s Birthday four years ago and I volunteered to organize the German one. After two editions and with Foreman being covered on the Open Source Camp last year I asked for others to run the party. And with ATIX doing a great job I asked them to team up on this. So we have grown a great community event with the annual Birthday party.

This year was different to the ones before because we had such a big support by Red Hat. The new Community Managers showed up to introduce them accompanied by Greg who had stepped down earlier this year. A group of Product managers and consultants made the last stop on their European tour. A technical writer came over to discuss the future of documentation. And with Evgeni and Ewoud we had some recurring attendees to give a talk later. ATIX also arrived with a bus full of people. Monika represented iRonin, a company doing custom development on Foreman and I hope to team up in the future, and Timo developing on Foreman for dmTech brought a colleague. So users were slightly under-represented and the prepared demos were mostly used to share knowledge and probably because of the heat instead of hacking many discussions took place. But I think everyone of the about thirty attendees made good use of the first session.

Birthday PartyDemoThe session ended when I brought in the cake. And thanks to our Events team the cake was as tasty as good looking. A nice touch by Ohad was to insist he can not blow off the candles alone as he could not have build Foreman without the community.

Birthday CakeHelmets

After the cake break we started with the talks and the first one was by the Community team giving us a recap of Foreman’s history, data from the community survey and other insights like a first look on the future documentation. This is really the next step to me that Red Hat is also making their Satellite documentation upstream adding a use case driven documentation to the manual which is way more technical. The second talk Quirin showcased the current state of Debian Support which will be fully functional with Errata support being added, but he already promised some usability and documentation improvements afterwards. The third speakers were Dana and Rich who showed Red Hat’s roadmap for features to add to Foreman so they will be pulled into Satellite afterwards. The roadmap will be presented in a community demo and uploaded to the community forum. Having the product managers easily available allowed the audience also to ask any question and I was excited to hear for almost all topics brought up that there is already ongoing work in the background. For example I asked about making subscription management also usable for other vendors and Rich told me he is part of a newly founded team which is evaluating exactly this.

Because of the heat we added a small ice break before starting the next talk and because of Lennart being ill Ohad entered the stage to show his work on containerizing Foreman. He explained that he started it mainly for testing but the interest showed him that expanding it to be fully functional to run Foreman and even Katello on Kubernetes could be a future way. Evgeni gave a shortened version of the talk on writing Ansible modules for Foreman and Katello he created for Froscon. It was a very technical one showing how much work is necessary to build a good base so later work is much easier. From this perspective I can really recommend this talk to all Froscon attendees. Last but not least Ewoud looked into the project’s social aspects which was a nice mixture of official history and personal moments. He also showed off the different swag the project created, ending with a t-shirt signed by as many team and community members as possible while traveling from Czech to US and back as suitable gift to Greg because “Once a foreman, always a foreman”. 😉

For dinner we had Pizza and Beer, but moved to the air-conditioned hotel bar after a short while to finish the evening. I heard people were enjoying conversation until two o’clock in the morning even when the bar closed one hour earlier. 😀

I would say the Party was a blast and I am already looking forward to next year when ATIX will be the host again. But until then there are several other Foreman related events with the Open Source Automation Day on 15. & 16.10.2019 in Munich including Workshops the day before and a Foreman hackday the day after organized by ATIX and the Open Source Camp on 07.11.2019 in Nuremberg right after OSMC by NETWAYS.

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Automatisierte Updates mit Foreman Distributed Lock Manager

Foreman Logo

Wer kennt das nicht am besten soll alle nervige, wiederkehrende Arbeit automatisiert werden, damit man mehr Zeit für spaßige, neue Projekte hat? Es gibt nach Backups wohl kein Thema, mit dem man so wenig Ruhm ernten kann, wie Updates, oder? Also ein klarer Fall für Automatisierung! Oder doch nicht weil zu viel schief gehen kann? Nun ja, diese Entscheidung kann ich euch nicht abnehmen. Aber zumindest für eine häufige Fehlerquelle kann ich eine Lösung anbieten und zwar das zeitgleiche Update eines Clusters, was dann doch wieder zum Ausfall des eigentlich hochverfügbaren Service führt.

Bevor ich aber nun zu der von mir vorgeschlagen Lösung komme, will ich kurz erklären wo die Inspiration hierfür herkommt, denn Foreman DLM (Distributed Lock Manager) wurde stark vom Updatemechanismus von CoreOS inspiriert. Hierbei bilden CoreOS-Systeme einen Cluster und über eine Policy wird eingestellt wie viele gleichzeitig ein Update durchführen dürfen. Sobald nun ein neues Update verfügbar ist, beginnt ein System mit dem Download und schreibt in einen zentralen Speicher ein Lock. Dieses Lock wird dann nach erfolgreichem Update wieder freigegeben. Sollte allerdings ein weitere System ein Lock anfordern um sich upzudaten und die maximalen gleichzeitigen Locks werden bereits von anderen Systemen gehalten, wird kein Update zu dem Zeitpunkt durchgeführt sondern später erneut angefragt. So wird sichergestellt, dass die Container-Plattform immer mit genug Ressourcen läuft. CoreOS hat dazu dann noch weitere Mechnismen wie einen einfachen Rollback auf den Stand vor dem Update und verschiedene Channel zum Testen der Software, welche so einfach nicht auf Linux zur Verfügung stehen. Aber einen Locking-Mechanismus zur Verfügung zu stellen sollte machbar sein, dachte sich dmTech. Dass die Wahl auf die Entwicklung als ein Foreman-Plugin fiel lässt sich leicht erklären, denn dieser dient dort als das zentrale Tool für die Administration.

Wie sieht nun die Lösung aus? Mit der Installation des Plugins bekommt Foreman einen neuen API-Endpunkt über den Locks geprüft, bezogen und auch wieder freigegeben werden können. Zur Authentifizierung werden die Puppet-Zertifikate (oder im Fall von Katello die des Subscription-Managers) genutzt, die verschiedenen HTTP-Methoden stehen für eine Abfrage (GET), Beziehen (PUT) oder Freigaben (DELETE) des Lock und die Antwort besteht aus einem HTTP-Status-Code und einem JSON-Body. Der Status-Code 200 OK für erfolgreiche Aktionen und 412 Precondition Failed wenn Beziehen und Freigeben des Locks nicht möglich ist sowie der Body können dann im eigenen Update-Skript ausgewertet werden. Ein einfaches Beispiel findet sich hierbei direkt im Quelltext-Repository. Ein etwas umfangreicheres Skript bzw. quasi ein Framework wurde von einem Nutzer in Python entwickelt und ebenfalls frei zur Verfügung gestellt.
(mehr …)

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.