Skip to content

Applikationen unter Linux am Beispiel CentOS

centos Aus CentOS 8 wird CentOS Stream.

Über die Meldung, dass CentOS 8 zugunsten von CentOS Stream einstellt, habe ich mich sehr geärgert. Ich war sogar richtig gehend angepisst.

CentOS war immer die Möglichkeit, eigene Dinge auf Red Hat Kompatibilität zu testen, ohne Subskriptionskosten (für das Patching) bezahlen zu müssen.

Leider hat es das CentOS-Team mit der Version 8 nicht geschafft, zeitnah auf Updates und Hotfixes durch Red Hat zu reagieren und ist aus diesem Grund auch nicht mehr meine Distribution der Wahl. Mein Kram wird im Lauf der nächsten Wochen und Monate auf Ubuntu LTS migriert.

Machen wir uns aber bitte nichts vor. CentOS ist keine "schöne" Linux-Distribution. Das Tooling ist nicht so berühmt. Durch die lange Unterstützung und die durch Red Hat versprochene API-Kompatibilität über die ganze Laufzeit veraltet Software in Red Hat Enterprise Linux (RHEL) und damit auch in CentOS sehr schnell. (Gilt übrigens für andere paketbasierte Distributionen im gleichen Mass, die helfen sich nur mit häufigeren Releases).

RHEL (CentOS) möchte man eigentlich nur aus genau einem Grund einsetzen, nämlich, dass nahezu jede Business-Software für RHEL zertifiziert wird. Und aufgrund der versprochenen Kompatibilität ist es nahezu garantiert, dass sie auch über die komplette Laufzeit das Major-Releases von zehn Jahren bzw. 13 Jahren mit extended Support auch lauffähig bleibt.

Wenn man aktuelle Open-Source-Software auf CentOS einsetzen möchte, so konnte man sich nur dadurch behelfen, dass man entweder darauf vertraut hat, dass die irgendwann in den Software-Kollektionen aufgeschlagen ist, da wurde sie dann "neben" der Basisinstallation installiert oder dass man externe Repositories verwendet hat. Bei meinen Servern habe ich beispielsweise PHP aus den Remi Repositories, sowie Docker und MariaDB direkt vom Hersteller bezogen.

Das hat auch Red Hat erkannt und mit Version 8, Modules oder "Application Streams" eingeführt. Hier gibt es eine sehr gute englischsprachige Erklärung dazu. Kurz zusammengefasst, lassen sich mit diesem Konzept mehrere Versionen der gleichen Software parallel installieren und auch benutzen.

Vermutlich hat dieses neue Konzept die Ressourcen vom CentOS-Projekt gesprengt, ich habe keinen Beweis für diese Vermutung. Für mich ist dieses Konzept aber nur ein Zwischenschritt auf dem Weg, das Basis-Betriebssystem komplett vom Applikationsteil zu trennen.

Im Grossen und Ganzen: Kernel, Netzwerk, Infrastruktur (Backup, Authentifizierung, ...) macht die Distribution und den ganzen Rest können Applikationen alleine besser.

Wenn wir die Distributionen nur als stabile Basis ansehen, auf der wir Dienste mit den Hersteller-Repositories (Docker, MariaDB, ...) oder Snaps, Flatpaks und AppImages oder Containern (Docker, Podman, ...) aufsetzen, dann würden wir allem gerecht werden.

Es entspricht einer Trennung von Applikation und Plattform, die in vielen Firmen trotz DevOps immer noch betrieben wird. DevOps bezieht sich im Grossen und Ganzen auch mehr auf Applikationsentwicklung und -betrieb. DevOps (oder EngOps) für die Plattformentwicklung ist davon getrennt.

Wenn wir diese Sichtweise weiterspinnen, werden paketbasierte Linuxdistributionen obsolet.

Wohin das in Summe führen kann, sehen wir mit Kubernetes (und OpenShift) oder durch den Einsatz von Containern (mit Docker oder Podman oder ...).

Kubernetes ist es egal, auf welchem linuxbasierten OS es läuft, wenn die Voraussetzungen gegeben sind. Den Leuten, die Kubernetes benutzen (nicht verwalten), ist die komplette Infrastruktur darunter egal, so lange das Cluster zur Verfügung steht.

Und, die alten erinnern sich, das hatten wir schon einmal, aber nicht ganz so ausgereift.

Java hat den Ruf (weitestgehend) plattformunabhängig zu sein. Klar, dafür muss man mit der Runtime (JRE) oder dem JDK auch ein halbes OS mitinstallieren. Darauf kann man Applikationsserver wie Tomcat, JBoss, Weblogic, Websphere, ... betreiben und auch da gab es das Versprechen, sich nicht um die darunter liegenden Schichten kümmern zu müssen.

Meiner Meinung nach wurde dieses Versprechen nie komplett eingelöst, obwohl sehr viele gute Konzepte vorhanden waren.

Mit Containern und Orchestrierungslösungen sind wir aber der Erfüllung dieses Versprechens einen Schritt näher gekommen.

Bin an Euren Meinungen und einer Diskussion darüber sehr interessiert.

Datenbankbackup mit MyDumper unter CentOS 7 ...

centos

Zum Backup meiner Datenbanken benutze ich schon seit Jahren MyDumper und das MyLoader-Tool. Der grosse Vorteil von MyDumper neben der Geschwindigkeit durch Parallelisierung ist, dass alle Datenbanktabellen in einzelnen Dateien vorliegen und so leicht modifiziert werden könnten.

Höhere Geschwindigkeit bedeutet auch, dass man öfter Backups machen kann (bei mir alle vier Stunden).

MyDumper muss selber übersetzt werden, wenn es nicht in der Distribution dabei ist. Den Anfang bildet dass Holen des Quelltextes:

$ git clone https://github.com/maxbube/mydumper.git mydumper.git

Danach setzen wir die Variablen für das Übersetzen des Quelltextes.

$ export CC=/home/dirk/workspace/sclgcc.bash
$ export CXX=/home/dirk/workspace/sclc++.bash
$ export MAKEFLAGS="-j $(lscpu | awk '/^CPU\(s\)/ {print $2}')"

Die ersten beiden Variablen habe ich im gestrigen Artikel erwähnt.

Die MAKEFLAGS sorgen dafür, dass make mit mehreren Threads arbeitet. Ich nehme dafür die Anzahl der CPUs, die mir das System meldet.

$ yum install glib2-devel mysql-devel zlib-devel pcre-devel openssl-devel

Nachdem wir neben dem C++ Compiler, Make und CMake die Vorbedingungen installiert haben, kann es auch schon losgehen.

$ cd /home/dirk/workspace/mydumper.git
$ git clean -dfx
$ cmake . -DMYSQL_LIBRARIES_mariadb:FILEPATH=/usr/lib64/libmariadbclient.a -DWITH_SSL=OFF -DBUILD_DOCS=off
$ make
$ sudo make install

Das "git clean" räumt unter anderem die Reste von alten Übersetzungsversuchen auf. Guckt Euch bitte die Parameter gut an, bevor Ihr das in Repos macht, in denen Ihr Schreibrechte besitzt.

Da auf meinen Servern die aktuelle stabile Version von MariaDB arbeitet und ich ebenfalls den MariaDB-Client installiert habe, muss cmake das auch mitteilen.

Der Backup-User benätigt in der Datenbank "nur" Select-, Reload und Lock Tables Berechtigungen.
CREATE USER 'b2'@'localhost' IDENTIFIED VIA mysql_native_password USING 'kryptisches Passwort';
GRANT SELECT, RELOAD, LOCK TABLES ON *.* TO 'backup'@'localhost' REQUIRE NONE WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0;

Nachdem jetzt alles fertig ist, kann das folgende Backupskript seinen Dienst tun.

#!/bin/bash
# db-backup.bash
set -o errexit

BACKUPDB_DIR="/srv/bak/dumps"
DB_USERNAME="backup"
DB_PASSWORD="kryptisches Passwort"
THREADS=$(lscpu | awk '/^CPU\(s\)/ {print $2}')

cd ${BACKUPDB_DIR}

/usr/local/bin/mydumper --user ${DB_USERNAME} --password ${DB_PASSWORD} --threads ${THREADS}

find ${BACKUPDB_DIR} -type d -name 'export*' -mtime +1 -exec xargs rm -r '{}' \+

WICHTIG: Am Ende des Skripts werden alle Backups gelöscht, die älter sind als ein Tag.

Aktueller C-Compiler auf CentOS 7 ...

centos

Spannend, ich hätte schwören können, dass ich das schon einmal im Blog hatte, kann einen entsprechenden Artikel aber leider nicht finden.

Ein Weg, einen aktuellen C-Compiler auf CentOS zu installieren sind die offiziell unterstützten SoftwareCollections, für unseren Fall insbesondere das Developer Toolset 7. Die achte Version gibt es schon für Red Hat Enterprise Linux 7, wird also in den nächsten Wochen auch in CentOS 7 verfügbar sein.

Zuerst werden die Software Collections aktiviert und aktualisiert

$ sudo yum install centos-release-scl
$ sudo yum update

Installation des entsprechenden Pakets mit allen Abhängigkeiten

$ sudo yum install devtoolset-7-gcc-c++
Welche Software Collections installiert sind, bekommt man übrigens mit dem Kommando scl --list heraus.

Eine Shell mit aktivierter Software Collection starten

$ gcc --version | head -1
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)

$ scl --list
devtoolset-7

$ scl enable devtoolset-7 bash

$ gcc --version | head -1
gcc (GCC) 7.2.1 20170829 (Red Hat 7.2.1-1)

Neuen Compiler per Default aktivieren

Da man nicht jedes Mal eine neue Shell nutzen möchte, hilft der folgende Weg, das zu verwirklichen.

Wrapper Skripte für GCC und C++

#!/bin/bash
# sclgcc.bash

COMMAND="gcc $@"
scl enable devtoolset-7 "$COMMAND"
#!/bin/bash
# sclc++.bash
COMMAND="c++ $@"
scl enable devtoolset-7 "$COMMAND"

Setzen der Environment-Variablen, die cmake und make benutzen

$ export CC=/home/dirk/bin/sclgcc.bash
$ export CXX=/home/dirk/bin/sclc++.bash

Supportzeiträume ...

linux Weil ich ab und zu mal danach gefragt werde, habe ich einmal die Supportzeiträume gängiger paketbasierter Linuxdistributionen zusammengesucht.

Kritik und Korrekturen sind ausdrücklich erwünscht.

Bei Korrekturen wäre ein offizieller Link sehr hilfreich

Eingeschränkter Support:

Eingeschränkter Support bedeutet insbesondere, dass nicht alle Pakete unterstützt werden.

Bei Debian LTS sind nicht alle Pakete enthalten. Bei Red Hat Enterprise Linux wird eine ELP (Extended Life Phase) Lizenz benötigt, um weiteren eingeschränkten Support zu bekommen, SUSE erfordert ein Extended Support Package. Bei Debian und OpenSUSE wird der langfristige Support über ein separates Team gewährleistet und nicht vom Securityteam der jeweiligen Distribution.

Überblick:




















Version: Release: Support: Limited Support:
Debian 7, Wheezy (oldstable) 04.05.2013 24.04.2016 05.2018
Debian 8, Jessie (stable) 25.04.2015 ca 04.2018 05.2020
Ubuntu 12.04 LTS, Precise Pangolin 26.04.2012 26.04.2017 ESM
Ubuntu 14.04 LTS, Trusty Tahr 17.04.2014 04.2019
Ubuntu 16.04 LTS, Xenial Xerus 21.04.2016 04.2021
Ubuntu 16.10, Yakkety Yak 13.10.2016 04.2017
CentOS 6 10.07.2011 30.11.2020
CentOS 7 07.07.2014 30.06.2024
Red Hat Enterprise Linux 5, Tikanga 14.03.2007 31.03.2017 31.03.2020
Red Hat Enterprise Linux 6, Tikanga 10.11.2010 30.11.2020 30.11.2023
Red Hat Enterprise Linux 7, Tikanga 10.06.2014 30.06.2024 30.06.2027
openSUSE Leap 42.1 04.11.2015 05.2017
openSUSE Leap 42.2 16.11.2016 ca 05.2018
SUSE Linux Enterprise Server 11 23.03.2009 31.03.2019 31.03.2022
SUSE Linux Enterprise Server 12 27.10.2014 31.10.2027 31.10.2027
Fedora 24 21.06.2016
Fedora 25 22.11.2016


Standard-Support-Zeiträume:

Debian supported bis "next stable + 1 Jahr", LTS bis fünf Jahre nach Erscheinen (Releasezyklus "fertig, wenn es fertig ist").

Ubuntu supported bis neun Monate nach Erscheinen, LTS fünf Jahre nach Erscheinen. Release alle sechs Monate, LTS-Versionen alle zwei Jahre. Seit neuestem bietet Ubuntu eine Extended Security Maintenance für LTS-Versionen (Link in der Tabelle oben), die käuflich erworben werden kann. Danke Mario!

CentOS bis zehn Jahre nach Erscheinen des korrespondierendes RHEL Releases.

RHEL bis zehn Jahre nach Erscheinen, ELP bis 13 Jahre nach Erscheinen.

openSUSE, Major Release soll mindestens 36 Monate unterstützt werden, Minor-Releases bis 18 Monate nach Erscheinen.

SLES analog RHEL.

Fedora, Support bis zum Erscheinen des zweiten Nachfolgreleases plus ein Monat, keinen Langzeitsupport, neue Releases alle sechs Monate.

GCC und Environment ...

centos Hier kommt noch ein kleiner Nachtrag zu dem Artikel gestern.

Da ich den aktuellen GCC insbesondere zum Bau von Taskwarrior nutzen und nicht jedes Mal eine neue Shell nutzen möchte, hilft der folgende Weg, das zu verwirklichen:

Wrapper Skript für GCC und C++:

#!/bin/bash
# sclgcc.bash

COMMAND="gcc $@"
scl enable devtoolset-6 "$COMMAND"


#!/bin/bash
# sclc++.bash
COMMAND="c++ $@"
scl enable devtoolset-6 "$COMMAND"


Setzen der Environment-Variablen, die cmake und make benutzen:
export CC=/home/flod2/bin/sclgcc.bash
export CXX=/home/flod2/bin/sclc++.bash


Fertig!

Neuen GCC auf CentOS installieren ...

centos ... und das auch noch von der Distribution supported.

Bei CentOS und RedHat Enterprise Linux wird aktuellere Software durch die Software Collections bereit gestellt. Der Grund dafür, das separat zu machen, ist (beispielsweise) im CentOS Wiki zu finden.

CentOS wird 10 Jahre unterstützt und für die 10 Jahre wird die Kompatibilität von ABIs und APIs garantiert.Um das nicht zu gefährden, werden aktuellere Versionen in einem anderen Verzeichnis installiert und situationsweise aktiviert.

Am Beispiel "neuerer GCC-C++" läuft das wie folgt. Zuerst werden die Software Collections aktiviert und aktualisiert.
$ sudo yum install centos-release-scl
$ sudo yum update


Installation des entsprechenden Pakets mit allen Abhängigkeiten:
$ sudo yum install devtoolset-6-gcc-c++


Welche Software Collections installiert sind, bekommt man mit scl --list heraus.

Anschliessend startet man eine Shell mit aktivierter Software Collection:
$ gcc --version | head -1
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)

$ scl ---list
devtoolset-6

$ scl enable devtoolset-6 bash

$ gcc --version | head -1
gcc (GCC) 6.2.1 20160916 (Red Hat 6.2.1-3)

Taskserver auf CentOS 6 ...

taskwarrior Weil ich danach gefragt wurde.

Wenn man den zu Taskwarrior passenden Taskserver übersetzen und benutzen möchte, sind folgende Schritte nötig:

Die sollten auch unter CentOS 7 funktionieren.

$ sudo yum install cmake # zum Bauen der Build-Konfiguration
$ sudo yum install gcc-c++ # der Compiler
$ sudo yum install gnutls-devel # für die Verschlüsselung der Verbindung
$ sudo yum install libuuid-devel # um eindeutige IDs bauen zu können


Gerade die letzte Bibliothek wird benötigt, wenn man einen älteren C++-Compiler - wie in CentOS 6 - einsetzt.

Gebaut wird dann mit
$ curl -O http://taskwarrior.org/download/taskd-latest.tar.gz
$ tar xzf taskd-latest.tar.gz
$ cd taskd-latest
$ cmake -DCMAKE_INSTALL_PREFIX=${HOME}/taskserver -DCMAKE_BUILD_TYPE=release .
$ make
$ make install


ACHTUNG: Das letzte Zeichen der Zeile, die cmake ausführt ist ein Punkt ".".

Der CMAKE_INSTALL_PREFIX kann wegfallen, wenn man den Taskerver unterhalb von /usr installieren möchte (dann muss man im letzten Schritt auch sudo make install ausführen.

Jetzt noch die Pfade konfigurieren und dann kann es losgehen:
$ export PATH=${PATH}:${HOME}/taskserver/bin
$ export MANPATH=${MANPATH}:${HOME}/taskserver/share/man


Testen mit
$ taskd diag
$ man taskd


Viel Spass!

Migration zu Hetzner ...

centos Man, was ist das nervig.

Aufgrund eines Irrtums, der sich durch Hören dieser Folge (ab 01:29:32) des empfehlenswerten Podcasts Rechtsbelehrung aufklärte, werde ich mit meinem root-Server wieder nach Deutschland umziehen. Ich hatte das hier schon mal angemerkt.

Mit Bekannten teile ich mir einen Backupserver bei Hetzner und da liegt es natürlich nahe mit dem Server auch zu Hetzner zu gehen. Das Preis-/Leistungsverhältnis für den EX40 ist einfach ungeschlagen. Der Server, wie auch der andere Server der Bekannten, läuft mit CentOS und sehr schnell, also so wie er soll.

Mein neuer Server stand in Rechenzentrum 20 und "fühlte" sich immer sehr langsam an, vor allem das Installieren dauerte ewig. Nun, EPEL-Repositories sind aktiviert und ich bekam den Server kurz vor dem Release von Fedora 23, daher dachte ich, es lag daran. - So war es aber nicht.

Ich habe einen nmap auf Port 22 eines Servers in einem anderen Rechenzentrum bei Hetzner gemacht und der dauerte 16.5 Sekunden, von einem anderen Server bei Hetzner (ebenfalls nicht im gleichen Rechenzentrum) dauerte es 0.07 Sekunden und von zu Hause 0.2 Sekunden.

Das spricht sehr stark dafür, dass etwas im Routing nicht sauber funktioniert und die Pakete den "falschen (langsamen) Weg nehmen". Der Hetzner-Support versuchte das Problem mit dem Rettungssystem (Debian) nach zustellen, aber da funktionierte alles zufriedenstellend. Sie verweigerten Support für das installierte System, was ich verstehe, bei einem root-Server ist man auf sich alleine gestellt.

Also habe ich den Server mit dem offiziellen CentOS-Image neu installiert und danach nichts anderes gemacht als nmap zu installieren. Das Problem war wieder da.

Jetzt ist für mich klar, dass da irgendetwas im Zusammenspiel von CentOS mit dem Routing Probleme bereitet.

Aber auch jetzt fand der Support kein Problem, ich gehe davon aus, dass es nie unter CentOS nachgestellt haben und sie boten mir an, einen Austauschserver zu bekommen. Aufgrund der Prozesse sollte ich den alten Server kündigen und den neuen bestellen, sie würden dann an der gleichen Stelle einen neuen Server bereitstellen. Das hätte das Problem meiner Ansicht nach nicht gelöst.

Glücklicherweise kann man einen Server innerhalb von zwei Wochen stornieren, das habe ich gemacht. Dann habe ich einen neuen Server bestellt und darum gebeten ihn nicht im gleichen Rechenzentrum 20 bereitzustellen. Das dauert knapp 24 Stunden und, was soll ich sagen, im Rechenzentrum 21 gibt es das gleiche Problem.

Man, das nervt.

Also wieder storniert und neu bestellt und jetzt darauf geachtet, dass der Server in ein Rechenzentrum kommt, wo ich weiss, dass es funktioniert.

Das ist halt der Nachteil, wenn man zu einem Grosshoster geht und dort wirklich Probleme hat. Die grosse Anzahl an Systemen können nur durch einen standardisierten Prozess verwaltet werden. Lösungen, die ausserhalb dieser Prozesse liegen, funktionieren halt nicht. Nicht falsch verstehen, das ist kein Vorwurf, es geht nicht anders. Aber es nervt.

Tuning ...

centos Wie bereits geschrieben, musste ich ein wenig tunen.

In der ersten Stufe habe ich einige Datenbankparameter angepasst und in der zweiten Stufe die Datenbankinhalte bereinigt.

Wenn man ein Monitoringsystem - in meinem Fall Bloonix (gibt es übrigens auch in der Open-Source-Variante zum selber hosten) - benutzt, kann man sehr schön den Erfolg feststellen (die Webseite wird von extern aufgerufen).

Limits für MariaDB auf CentOS ...

centos Erkan hat - nachdem er mir einen entscheidenden Tipp gab - es auch gleich selber verbloggt.

Die Limits für MariaDB (ich musste an den "open files" schrauben) werden nicht - wie bei SystemV üblich - in der Datei /etc/security/limits.conf gesetzt, sondern neu in der Datei /etc/systemd/system/mariadb.service.d/limits.conf, das passende Verzeichnis mariadb.service.d muss allerdings auch noch angelegt werden.

Die Einstellung der maximal offenen Dateien in der limits.conf, plus der Bereinigung der Logbuch-Datenbanken von Altlasten sollten jetzt zu einer annehmbaren Performance führen. (Grafik liefere ich nach).

Migration abgeschlossen ...

centos Ende letzter Woche habe ich meine Migration von Debian Squeeze LTS auf CentOS 7 und von Manitu zu Metanet abgeschlossen.

Es ist noch reichlich Performance-Tuning nötig, aber die Dienste laufen jetzt alle auf der neuen Hardware.

Ein Wort zu dem Wechsel:
Ich war mit Manitu nicht unzufrieden, ganz im Gegenteil, aber ich wollte die Dienste alle in der Schweiz haben, weil mir der Spagat zwischen dem Deutschen und dem Schweizer Rechtssystem nicht so gut gefällt.

Interessanterweise hat es bei dem Wechsel an Stellen geknallt, die ich nicht erwartet hatte.

Eine davon war die Apache-Konfiguration, bedingt durch den Wechsel von Apache 2.2 auf Apache 2.4 und einem Fehler in dem Upgrade-Guide.

Dort steht, dass man die 2.2er Konfiguration
Order allow,deny
Allow from all

Durch die folgende 2.4er Konfiguration
Require all granted
ersetzen soll.

Tatsächlich ist es aber so, dass man beides braucht:
Order allow,deny
Allow from all
Require all granted


Das hat mich viele Nerven gekostet.

Git-Server auf CentOS ...

centos Eigentlich ist "Git-Server" etwas hoch gegriffen, da als Server-Komponente SSH zum Einsatz kommt. Nichtsdestowenigertrotz ist das Endergebnis ein Git-Repository-Server, den man sehr bequem nutzen kann.

Für den Server habe ich einen User git (UserID 600) angelegt, mit dem die Repositories verwaltet werden sollen und das Homeverzeichnis soll unter /srv/git liegen:
groupadd -g 600 git
useradd -u 600          \
        -g 600          \
        -d /srv/git     \
        -m -s /bin/bash \
        git


Eine Besonderheit unter CentOS ist, dass dort SELinux läuft und wir dem System bekanntgeben müssen, dass es sich bei /srv/git um ein Homeverzeichnis handelt. Die einfachste Methode ist, den Kontext eines bestehenden Homeverzeichnisses auf das neue Verzeichnis zu übertragen.
semanage fcontext -a -e /home/dirk /srv/git
restorecon -R -v /srv/
ls -Zd /srv/git

Zu SELinux gibt es reichlich Dokumentation, ich verweise hier einmal auf den SELinux User's and Administrator's Guide bei RedHat. SELinux kann man auch abschalten, wenn einem der Aufwand zu hoch ist.

Der Rest ist relativ einfach und geht strikt nach der gitolite-Anleitung.

Den eigenen Public-Key (wird benötigt, um gitolite zu verwalten) in das Verzeichnis /srv/git kopieren, für mich hat sich dafür das Format user-host.pub bewährt (ich habe auf jedem Host einen separaten SSH-Key und nutze nicht überall den gleichen).
git clone git://github.com/sitaramc/gitolite
mkdir -p ${HOME}/bin
gitolite/install -to ${HOME}/bin
export PATH=${HOME}/bin:${PATH}
echo 'PATH=${HOME}/bin:${PATH}' >> ${HOME}/.bashrc
gitolite setup -pk user-host.pub


Fertig!

Die restliche Konfiguration läuft über das admin-Repository, das man auschecken muss und dann bearbeitet. Die neue Konfiguration ist direkt nach einem git push aktiv.
git clone git@host:gitolite-admin.git gitolite-admin-host.git


Dort finden sich im keydir-Verzeichnis alle Public Keys von Usern, die Zugriff auf irgendeines der Repositories haben sollen und im Verzeichnis conf liegt die gitolite.conf mit einem Beispiel-Repository.

Viel Spass!

Taskserver auf CentOS 7 ...

centos Im Rahmen meines privaten Migrationsprojektes habe ich natürlich mit Hürden gerechnet, manchmal tauchen die Herausforderungen allerdings an unerwarteten Stellen auf.

Taskserver lässt sich nach Dokumentation relativ leicht installieren. Allerdings läuft bei CentOS 7 ein firewalld mit, der eingehende Verbindungen blockt, was meiner Meinung nach sinnfrei ist, wenn es nur ein Netzwerkinterface hat, aber gut.

Mittels
firewall-cmd --zone=public --add-port=53589/tcp

lässt sich der firewalld überzeugen, eingehende Taskserver-Verbindungen zu akzeptieren.