Ceph Datastore, OpenNebula und Authentifizierung mit CephX

OpenNebula kann Ceph bereits seit Release 4.0 als Datastore einbinden. Wie man die beiden Systeme integriert wird in der OpenNebula Dokumentation beschrieben. Natürlich benötigt man einen laufenden Ceph Cluster und einen Hostsystem der kompatibel dazu ist. Im Augenblick eignet sich hier Ubuntu LTS, da die Kernelversionen neu genug sind um aktuelle Features von Ceph zu unterstützen und zudem ist auch eine aktuelle Version von Ceph in den Repositories.
Neben der gewohnten Installation und Konfiguration eines OpenNebula Nodes muss man noch das Paket ceph installieren, was in den Abhängigkeiten die Libraries für rados und rbd mit sich bringt. Damit man den Ceph Cluster vom Hostsystem ansprechen kann, muss man noch die ceph.conf und den Keyring des gewünschten Users kopieren. Der folgenden Befehl erstellt einen User one mit Zugriff auf den Pool one.

$ ceph auth get-or-create client.one mon 'allow r' osd 'allow class-read object_prefix rbd_children, allow rwx pool=one'
[client.one]
	key = aAaaaLaaKaaQaaRaaAaaYaaZaaBaaaaaaaaa==

Als Ausgabe sieht man den Key des Users. Dieser muss in der Datei /etc/ceph/ceph.client.one.keyring auf dem Hostsystem abgelegt werden. `rados -p one –id=one df` sollte jetzt den freien Speicherplatz im one Pool anzeigen. Der User oneadmin sollte lesend auf den Keyring zugreifen dürfen.
Bevor OpenNebula eine VM deployed, wird überprüft ob im Datastore genügend Speicherplatz frei ist. Dazu wird der Befehl `rados df` aufgerufen, komplett ohne Parameter, weshalb der Benutzer client.admin anstatt client.one verwendet wird. Ein Pull Request [1] welcher dies ändert hat es bisher leider nicht in das offizielle Repo geschafft.
Als Workaround kann man entweder zusätzlich den Keyring des client.admin auf dem Hostsystem ablegen oder im Monitor Skript [2] die Parameter des rados Aufrufs um “-p one –id=one” erweitern (angenommen der verwendete Ceph Pool heißt one).
Das alles nur um zu überprüfen ob genügend Speicherplatz im Datastore frei ist. Damit man VMs im Ceph Datastore erstellen kann muss sich auch libvirt gegen CephX authentifizieren. Dies ist aber bereits in der OpenNebula Dokumentation beschrieben.
[1] https://github.com/OpenNebula/one/pull/27
[2] src/datastore/ceph/monitor

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

Fog OpenNebula Provider im Upstream

Unser Fog Provider für OpenNebula ist mittlerweile auch im Upstream Master angekommen und ist somit im nächsten Release von Fog enthalten. Unsere aktuellen Erweiterungen des Providers sind weiterhin im Netways GitHub Repository zu finden und werden natürlich regelmäßig an den Upstream weitergereicht.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

OpenNebula Fog Provider

Letzte Woche habe ich unser Foreman OpenNebula Plugin vorgestellt. Die Kommunikation zwischen beiden Systemen übernimmt der OpenNebula Fog Provider. Natürlich kann man den Provider auch unabhängig von Foreman benutzen. Im kurzem Beispiel unten wird eine Verbindung zur One-RPC Schnittstelle aufgebaut, ein neues VM Gerüst erstelle und mit einem Template aus OpenNebula befüllt und erweitert. Und am Ende wird die VM natürlich noch gestartet.
Zuerst müssen wir aber natürlich die Source holen und die benötigten Ruby gems installieren. Das erledigt git und bundler für uns (apt-get install git bundler).

$ git clone https://github.com/netways/fog.git
$ cd fog
$ bundle install

Zum testen starten wir eine interaktive Ruby Konsole (irb) und binden die Fog Bibliothek mit ein.

$ irb
> require './lib/fog.rb'

Die folgenden Befehle werden alle in der irb Konsole ausgeführt!
Innerhalb der irb öffnen wir eine Verbindung zu OpenNebula und lassen uns die vorhanden Templates (Flavors) geben.

# connect to your one rpc
con = Fog::Compute.new(
    {
      :provider => 'OpenNebula',
      :opennebula_username => 'user',
      :opennebula_password => 'password',
      :opennebula_endpoint => 'http://oned.domain:2633/RPC2'
    }
  )

servers.new erstellt ein neues Gerüst einer VM. Dieses enthält die verschiedenen Attribute der VM.

# create a new vm (creates the object, the vm is not instantiated yet)
newvm = con.servers.new

Die VM enthält auch ein Attribut flavor, in dem ein OpenNebula Template gespeichert werden kann. In diesem Beispiel wir das Template mit der ID 4 verwendet.

# set the flavor of the vm
newvm.flavor = con.flavors.get 4
# set the name of the vm
newvm.name = "MyVM"

Attribute aus dem Template können überschrieben werden, bzw. müssen gesetzt werden, falls diese im Template nicht definiert wurden.

# set cores and memory (MB)
newvm.flavor.vcpu = 2
newvm.flavor.memory = 256

Im OpenNebula muss ein Interface einem Netzwerk zugewiesen werden. Zuerst wird ein vorhandenes OpenNebula Netzwerk geholt und an ein neu erstelltes Interface zugewiesen.

# create a new network interface attached to the network with id 1 and virtio as driver/model
network = client.networks.get(1)
nic = con.interfaces.new({ :vnet => network, :model => "virtio"})

Das neu erstellte Interface wird dem VM-Gerüst hinzugefügt und mit der Methode save wird die VM gespeichert, d.h. gestartet.

# Attach the new nic to our vm
newvm.flavor.nic = [ nic ]
# instantiate the new vm
newvm.save
Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

Foreman, Fog und OpenNebula

Jeder der hin und wieder einen Blick in unseren Blog wirft hat vermutlich festgestellt, dass Foreman das bevorzugte Tool zur Verwaltung unserer IT-Infrastruktur ist und uns in Sachen Provisionierung und Configuration Management viel Arbeit abnimmt. Zur Verwaltung unserer virtuellen Maschinen setzen wir auf OpenNebula, welches mit eigener Oberfläche, CLI und XML-RPC alle Möglichkeiten zum Erstellen und Verwalten von virtuelle Maschinen bietet. Schön wäre es natürlich wenn Foreman über die OpenNebula API virtuelle Maschinen anlegen und löschen kann, so dass man zur Provisionierung neuer VMs nur noch im Foreman klicken muss. Hier kommt Fog ins Spiel. Foreman verwendet die Fog Bibliothek um andere Provider wie libvirt, ovirt etc. anzusteuern. Für uns war das eine gute Ausgangslage um Foreman und OpenNebula zusammenzuführen und einen eigenen OpenNebula Fog Provider zu schreiben welcher dann von unserem Foreman-One Plugin verwendet.
Das Ergebnis habt ihr ja schon letzte Woche im VideoBlog gesehen. Aber wie installiert man das Ganze jetzt?
Als erstes holt man sich die aktuellen stabilen Foreman Sourcen, fügt noch unser foreman-one Plugin hinzu und installiert Foreman wie in der Doku beschrieben:

git clone https://github.com/theforeman/foreman.git
cd foreman
git co -b 1.5-stable origin/1.5-stable

Um im Foreman ein Plugin zu installieren fügt man seiner lokalen Gemfile folgende Zeile hinzu:

$ cat bundler.d/Gemfile.local.rb
gem 'foreman_one',  :git => "https://github.com/netways/foreman-one.git", :branch => "master"
gem "fog", :git => "https://github.com/fog/fog.git", :branch => "master"

Die zweite Zeile stellt sicher, dass unsere Fog Version verwendet wird. Dies ist solange nötig bis das Fog Projekt unseren OpenNebula Provider mit aufnimmt. Damit bundle beim nächsten Schritt keinen Konflikt erkennt muss man folgende Zeile aus bundler.d/fog.rb entfernen:

gem 'fog', '~> 1.21.0'

Von jetzt an folgt man nur noch der offiziellen Foreman Dokumentation zum installieren einer Testumgebung:

cp config/settings.yaml.example config/settings.yaml
cp config/database.yml.example config/database.yml
gem install bundler
bundle install
rake db:migrate
rake db:seed assets:precompile locale:pack
rails server

Auf http://localhost:3000 (admin/changeme) findet man jetzt die neue Foreman Version und unter Infrastruktur -> Computer Resources klickt man ohne große Mühen seine OpenNebula Instanz hinzu. Das seht ihr aber besser im VideoBlog.
Ich würde mich über Feedback jeder Art freuen! Bitte probiert den OpenNebula Provider aus und haltet euch mit Kritik nicht zurück! Auch würde uns interessieren wie ihr eure VMs mit OpenNebula und Foreman provisioniert und welche Features hier aktuell noch fehlen, die euch das Leben leichter machen würden!
Infos und den aktuellen Stand findet ihr an verschiedenen Stellen. Der Quelltext ist natürlich am einfachsten aus dem Netways GitHub Repo zu bekommen. Neuerungen und Beispiele wie man den Fog OpenNebula Provider verwendet gibt es natürlich hier im Blog und in den Readme Dateien.
Weiter Information findet ihr auch noch auf den Mailinglisten, Bugtrackern etc.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

Ceph Day in Frankfurt

Letzte Woche fand am Frankfurter Flughafen der erste Ceph Day in Deutschland statt. Neben der Möglichkeit die treibende Kräfte hinter Ceph kennen zu lernen war dies ein Tag voller spannender Vorträgen zu verschiedensten Einsatzgebieten, Best Practices und Fallbeispielen. Die dazugehörigen Vorträge werden laut den Veranstaltern noch auf Slideshare veröffentlicht.
Besonders interessant fand ich einen Vortrag von Patrick McGarry über die Ceph Community. Derzeit wird versucht diese zu vergrößern weshalb viele Möglichkeiten zur Interaktion und Kommunikation geboten werden. Neben den gängigen Möglichkeiten wie IRC und Mailingliste werden regelmäßig Ceph Development Summits veranstaltet die über mehrere Tage laufen und komplett online stattfinden. Gearbeitet wird unter anderem mit Wikis, Pads, Hangouts und Blueprints. Damit wird auch versucht Entwickler aus allen Zeitzonen abzuholen. Der Ceph Day selbst springt von Kontinent zu Kontinent und es gibt sogar die Möglichkeit an den wöchentlichen Standups der Hauptberuflichen Ceph-Entwickler teilzunehmen. Dass all diese Versuche fruchten bleibt natürlich zu hoffen, aber schön zu sehen, dass versucht wird Ceph offen und unabhängig zu platzieren.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

git filter-branch: Wie entfernt man Dateien aus der git Historie?

By Jason Long (http://git-scm.com/downloads/logos) [CC-BY-3.0 (http://creativecommons.org/licenses/by/3.0)], via Wikimedia CommonsEs kommt immer wieder mal vor, dass unachtsame Kollegen die Videos von der letzten Netways Feier in das git-Repository der Puppet Konfiguration pushen. Wie man sofort merkt, funktioniert der git-hook zur Erkennung und Verhinderung von push Befehlen unter Restalkohol noch nicht so ganz…
Spaß bei Seite… wie kann man ungewollte (große) Dateien wieder aus git entfernen, welche das Repository nur aufblähen aber eigentlich nicht benötigt werden? Ein einfaches git revert entfernt zwar die Datei wieder aus der aktuellen Revision, aber in der History findet man ja Gott sei Dank trotzdem noch immer alles. Auch die Größe des Repositories bleibt gleich und mit jedem neuem Klon werden die unnützen Daten auch kopiert.
Um Dateien wirklich komplett aus dem git-Repository zu entfernen wird git filter-branch benötigt. Hiermit kann man die Historie neu schreiben, aber Achtung, dies bedeutet auch, dass bereits geklonte Repositories nicht mehr fast-forward fähig sind.
filter-branch läuft über jede Revision des aktuellen Branch und kann Kommandos auf die einzelnen Revisionen ausführen, z.B. ein git rm um Dateien zu löschen. Man kann die verschiedenen Elemente der Historie einzeln bearbeiten, in unserem Fall wollen wir den Index bearbeiten. Mit anderen Optionen könnte man z.B. die Commit-Message bearbeiten.
Mit folgendem Befehl wird das Video TWUndDieWeihnachtsmaenner.mpg aus allen Zweigen des Repository entfernt:
git filter-branch --prune-empty --index-filter "git rm --cached -f \
--ignore-unmatch TWUndDieWeihnachtsmaenner.mpg" -- --all

Was machen die Optionen im einzelnen?

  • –index-filter <command>: Mit diesem Filter schreibt man den Index neu.
  • –prune-empty: Durch das Filtern kann es passieren, dass leere Commits entstehen. Dank diesem Parameter werden solche Commits entfernt.
  • –all: Es werden alle Zweige es Repositories bearbeitet.
  • <command>: Im unserem Fall ist das <command> ein git rm.
    • –ignore-unmatch sorgt einfach nur dafür, dass 0 zurück gegeben wird, auch wenn es keine Datei zum löschen gibt.
    • –cache sorgt dafür, dass der aktuelle Working Tree nicht angefasst wird.
    • -f steht natürlich für force.

Als Ergebnis bekommt man ein bereinigtes Repositorie mit einer neuen Historie. Von diesem kann jetzt wiederrum geklont werden.
Wie man sieht ist es relativ viel Arbeit ein git Repository zu bereinigen. Zudem muss man das ursprüngliche Repository ersetzen und die Kollegen müssen dieses auch neu klonen.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

tmux – eine Alternative zu screen

Ich habe bereits von mehreren Seiten gehört, dass die Entwicklung von screen bereits seit längerem stockt und dass mit tmux ein würdiger Nachfolger existiert. Grund genug um einen kurzen Blick darauf zu werfen.
Die Benutzung von tmux und screen ist auf den ersten Blick sehr ähnlich. Bekannte Befehle wie strg-a n, strg-a c, strg-a p und und strg-a d funktionieren in tmux fast identisch. Fast weil man strg-b anstatt strg-a benutzen muss. In der Konfigurationsdatei (.tmux.conf) ist dies aber auch schnell auf das gewohnte Shortcut umgebogen.

unbind C-b
set -g prefix C-a

Die Handhabung der Sessions ist in tmux etwas anders. tmux list-session listet alle Session auf und mit tmux attach -t <id>  nimmt man eine Session auf. Hier ist tmux etwas komfortabler als screen. Rufen mehrere User gleichzeitig eine Session auf geht tmux besser mit verschiedenen Fenstergrößen um.
Am besten gefällt mir aber der integrierte Tiling Modus von tmux. Ein strg-a % teilt das Terminal vertikal und strg-a “ teilt das Terminal horizontal. Mit strg-a <arrow> bzw. strg-a o kann man zwischen den verschiedenen Splits hin und her wechseln. Mit strg-a <space> wechselt man zwischen bestehenden default-Layouts und mit strg-a O rotiert man die Panels selbst.
Die Bindings sollte man natürlich in der .tmux.conf auf seine eigenen Gewohnheiten anpassen.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

Logs puffern mit rsyslog

Wie wichtig Logdateien sind weiß jeder Administrator und mit Logstash, Graylog und Elasticsearch hat das Thema auch einen kleinen Hype im Open Source Umfeld erfahren. Zur bequemen Analyse der Logs werden diese meist zentral auf einem Logserver gesammelt. Ein typisches Setup wäre z.B. Logstash mit Elasticsearch auf dem Logserver und rsyslog auf den Clients. Warum rsyslog? Es ist mittlerweile der Standard auf den bekannten Linux Distributionen und zudem schlank und zuverlässig. Natürlich macht es Sinn auf Seiten des Logservers Puffer einzubauen (z.B. mit Redis), aber ich will einen genaueren Blick auf die rsyslog-Konfiguration werfen.
Neben einer verschlüsselten Kommunikation erwarte ich von einem Log-Daemon Folgendes:

  • Puffern der Logs, falls der Logserver nicht erreichbar ist.
  • Andere Prozesse dürfen nicht beeinträchtigt oder blockiert werden, wenn der Logserver nicht verfügbar ist.
  • Der Log-Daemon sollte das System auch in extremen Fällen nicht vollschreiben.
  • Logs sollten in einem brauchbarem Format gesendet werden.

Kein Problem:

$WorkDirectory /var/spool/rsyslog
$template ForwardFormat,"<%PRI%>%TIMESTAMP:::date-rfc3339% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%"
$ActionQueueType LinkedList
$ActionQueueFileName logbuffer
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on
$ActionQueueMaxDiskSpace 200M
$ActionQueueDiscardSeverity 3
$ActionQueueTimeoutEnqueue 5
*.* @@logserver.example.com:4321;ForwardFormat

Ein brauchbares Format wird durch Zeile 2 und 10 erreicht. Vor allem der Timestamp nach RFC3339 ist nützlich. Zeile 2 definiert in dem Template ForwardFormat wie die Logs aussehen sollen und Zeile 10 sendet diese, entsprechend dem Template, per TCP (@@, wie intuitiv) an den Logserver.
Für das Puffern der Logs sind die Zeilen 3-5 zuständig. Als Datentyp soll eine verkettete Liste verwendet werden. Diese hat vor allem den Vorteil, dass nur so viel Speicher wie nötig belegt wird. Ab 8000 Logs im Speicher werden diese auf Platte in die Datei logbuffer gesynct ($ActionQueueHighWaterMark [1,2]). Zeile 7 sorgt dafür, dass maximal 200 MB Logs auf Platte in den Puffer wandern. Weitere Logs (die entweder keinen Platz mehr haben oder zu lange zum Annehmen brauchen) werden dank Zeile 9 verworfen und zwar nach 5 ms. Dies sorgt dafür, dass keine Prozesse blockieren, die versuchen Logs zu schreiben, aber keinen Platz mehr im Puffer kriegen. Zeile 8 bewirkt, dass bei vollen Puffern eher wichtige Logs (Severity 0-2) als unwichtige gepuffert werden. Temporäre Puffer werden auf Grund von Zeile 1 nach /var/spool/rsyslog geschrieben. Die Zeilen 3-9 werden auf die nächste Action angewendet, in diesem Fall Zeile 10.
Mit diesem Setup können Logs immer noch verloren gehen. Allerdings wird es im normalen Zustand wohl kaum passieren, dass der Puffer auf Platte benötigt wird. Sollte es wirklich zu Verbindungsabbrüchen kommen, können hier immer noch 200 MB gepuffert werden und ggf. kann der Wert noch angepasst werden. Mit diesem Setup entscheidet man sich auch für das Verwerfen von Logs, sobald der Puffer voll ist. Dies gewährleistet allerdings, dass andere Systemdienste (wie z.B. sshd) ohne Probleme weiter benutzbar bleiben.
Das Queueing Modell von rsyslog ist nicht so simpel wie oben dargestellt. Eine ausführlichere Beschreibung gibt es in der Dokumentation von rsyslog selbst [1,2].
Anmerkung:
Das oben verwendete Format der rsyslog-Konfiguration wird ab Version 6.3.3 als Legacy Format bezeichnet. In den aktuellen Versionen der bekannten Distributionen wird Version 5.x verwendet.
[1] http://www.rsyslog.com/doc/queues.html
[2] http://www.rsyslog.com/doc/rsyslog_conf_global.html

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

qcow2 mit Hilfe von libguestfs-tools mounten

libguestfs Logoqcow2 ist ein beliebtes Format für Image-Dateien von virtuellen Maschinen. Ist ja auch klar, im Vergleich zu einem RAW-Image bietet es mehrere Vorteile. Zum Beispiel die Möglichkeit, Snapshots zu machen oder dass bei einem Transfer durch das Netzwerk wirklich nur die genutzten Daten des Images kopiert werden müssen. Will man eine qcow2-Datei aber einfach nur mounten, kann man nicht mehr auf die üblichen Tools wie kpartx oder losetup zurückgreifen.
Abhilfe schafft hier das Toolset libguestfs-tools:
guestmount -a /path/to/qcow2-image -m /device/in/the/image /mountpoint
Im Falle einer VM in OpenNebula könnte dies konkret wie folgt aussehen:
guestmount -a /var/lib/one/datastores/1/35...56 -m /dev/VolGroup/lv_root /mnt
Und somit ist es auch kein Problem mehr qcow2-Images zu mounten!
Das Titelbild wurde unter der GPL-Lizenz auf wikipedia.org veröffentlicht.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.

Wie entferne ich nicht mehr benötigte Zweige?

Wer seinen Quelltexte und Konfigurationen mit git verwaltet, hat in der Regel schnell eine große Anzahl an Branches/Zweigen angelegt. Viele davon sind nutzlos und überflüssig, weil diese bereits in den Hauptzweig übernommen wurden. Hat man zudem noch viele fleißige Kollegen, kommt es schon vor, dass ein git branch -a mehrere Seiten Ausgabe produziert und man ohne grep & Co. keinen Überblick mehr hat.
git liefert natürlich ein Kommando, welches einem alle bereits zusammengeführte Zweige anzeigt, und somit kann man schnell und einfach alle nicht mehr benötigten Zweige löschen.
Lokal angelegte Zweige werden wie folgt gelöscht:

git branch --merged master | grep -vE "(\*|testing|development)" | xargs -n1 git branch -d

In diesem Beispiel werden einzelne Zweige mit grep ausgefiltert, da ich testing und development nicht löschen will. Zudem kann der aktuelle Zweig * nicht gelöscht werden, weshalb dieser ebenfalls aus der Liste entfernt wird.
Für remote-Zweige müssen die Befehle etwas angepasst werden:

git branch -r --merge master | grep -vE "(origin\/master|origin\/testing)" | sed 's/ *origin\///' | xargs -I% git push origin :%

Zwei Befehle und schon sind die git-Zweige aufgeräumt. Mit einem git-Hook an der richtigen Stelle kann man diese auch noch automatisch ausführen.

Achim Ledermüller
Achim Ledermüller
Lead Senior Systems Engineer

Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist unter anderem für die Automatisierung des RZ-Betriebs und der Evaluierung und Einführung neuer Technologien zuständig.