Skip to content

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)

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.