Administrator's Blog

Eigenen Git-Server ala Github aufsetzen

nospam@example.com (Christoph Kretzschmar) — Sun, 24 Mar 2013 11:13:00 +0100

Eine Versionsverwaltung bestimmt den Alltag in größeren Projekten. Wo bisher SVN oder Merurical herhalten durfte, hat sich ein neuer Platzhirsch durchgesetzt, der aufgrund seiner Simplizität und Mächtigkeit überzeugt. Viele dürften es erraten haben, es handelt sich um Git.

Es gibt vielerlei Möglichkeiten mit Git eine Versionierung zu erreichen, sei es lokal oder auf github, bitbucket oder anderen Git-Repository Providern. Spätestens wenn es aber um Firmeninterne Projekte geht oder aber um allgemein nicht der Öffentlichkeit zugängliche Projekte muss man meist in die Tasche greifen und den Providern einen kleinen Obolus zahlen, damit diese die privaten Projekte Hosten und mehreren Teammitgleider ggf. Zugriff darauf gewähren.

Kostengünstiger wäre es da einen eigenen Git-Server zu haben, welcher die internen Projekte angemessen verwaltet. Theoretisch ist auch dies schnell von statten gegangen, kann man doch über SSH auf ein zentrales Bare-Repository tunneln und Änderungen pushen und pullen.

Wenn man jedoch auch gleichzeitig eine schöne Übersicht sämtlicher Commits haben möchte, samt Administration für Repoverwaltung, Benutzerverwaltung, etc. dann kommt man nicht umher sich diverse Webinterfaces anzuschauen, die einem diese Arbeit abnehmen können.

Eine begrenzte Auswahl wären die folgenden Verwaltungssysteme:

http://www.gitalist.com/ (Seit Mai 2012 scheinbar keine Entwicklung mehr?)

http://www.gitblit.com/ (Basiert auf Java und benötigt entsprechend einen Jetty o.ä.)

http://www.gitlabhq.com/ (Basiert auf Ruby und hat als Komplementärprojekt auch ein eigenen CI-Server mit Gitlab integration)

Für den Blogeintrag betrachten wir letzteres (Gitlab) genauer.

Gitlab bring viele Funktionen mit, wie man sie auch von öffentlichen Git-Repository Servern wie z.B. GitHub kennt. Man hat eine pro Benutzer Projektverwaltung, ein Wiki, Issuetracker mit Redmine Integrationsmöglichkeiten, einfache Möglichkeiten POST-Hooks bei einem push in das Repo auszulösen und das mitunter beste ist, dass das Gitlab Webinterface fast ausschließlich über die Gitlab eigene API aufbaut. Das bedeutet man kann alles was man im Webinterface klicken kann auch über automatisierte Skripte auslösen, abfragen und verarbeiten.

Die Installation die hier vorgestellt wird, nutzt abseits von dem empfohlenen Weg ein RVM (Ruby Virtual Environment), da man sich nicht unbedingt mit dem Betriebssystem über die installierte Rubyversion oder verschiedener Gems streiten möchte. Jedoch verlangt dies einige nachträgliche Anpassungen, welche aber so minimal gehalten sind, dass diese nicht ins Gewicht fallen. Zudem werden wir statt nginx den Apache2 nutzen um Gitlab auszuliefern. Die Schritte für nginx stehen auch im vorgestellten Skript, sind jedoch auskommentiert. (Es sei darauf hingewiesen das es kein richtiges Bash-Skript ist sondern mehr eine Anleitung was wann zu tun ist).

An den Stellen, wo zum bearbeiten der Konfigurationsdateien ,vim genutzt wird kann der persönlich bevorzugte Editor genutzt werden (emacs, nano, etc.)

Bevor es nun los geht weise ich noch darauf hin, dass wir hier Gitlab @master nutzen, bedeutet die aktuelle Entwickler Version. Dies wird entsprechend so gemacht, da ab der Version 5.0 (Zum Zeitpunkt dieses Posts @master) gitolite durch eine eigene Loginshell ersetzt wird. Da gitolite als Repositoryverwaltung im Zusammenspiel mit Gitlab sehr verbuggt war. Sollte es also irgendwann einmal ein 5-x-stable branch geben so wäre dieser zu bevorzugen. Das kann man enstprechend prüfen, indem man nach dem clone des gitlab repos ,git branch -a aufruft. Sollte da ein remotes/origin/5-x-stable existieren so kann man dies mit ,git checkout 5-x-stable auschecken und fortan nutzen. (x steht für eine beliebige Zahl) Die Loginshell wird nach einem Erfolgreichen authentifizieren gegenüber SSH für den Benutzer git gerufen. Das ganze kann man sich anschauen, wenn man sich die Datei ,/home/git/.ssh/authorized_keys anschaut. Hat man für einen Benutzer einen Key im Frontend importiert, so wird dieser in diese Datei geschrieben (zusammen mit dem command auf die gitlab-shell) und regelt den SSH Zugriff auf das Repository über die git-checkout URL eines Projekts.

Die genutzte Distribution, bei der die folgenden Anweisungen genutzt wurden, ist Debian 6 Squeeze. Der Benutzer mit dem installiert wird ist ,root aber keine Angst, Gitlab wird später unter dem Benutzer ,git in das System installiert, für die ersten Schritte wie apt-get ist root jedoch vorrausgesetzt. Der Name des Benutzers sollte nicht verändert werden, da sonst viele der Standard Skripte angepasst werden müssten, da diese ,git als Benutzer für sämtliche ,sudo Befehle hard-coded haben.

Zuerst aktivieren wir das Backports Repository damit wir einen Redis-Server >v2.0 installieren können. Dieser wird benötigt, da Gitlab BRPOP nutzt, welches erst seit v2.0.0 in Redis implementiert ist.

# Enable backports
echo "deb http://backports.debian.org/debian-backports squeeze-backports main" >> /etc/apt/sources.list

# System up-to-date
apt-get update && apt-get dist-upgrade

Als nächstes benötigen wir sudo und einige weitere Pakete um Ruby und dessen Gems entsprechend kompilieren zu können.

># Install all packages we need
apt-get install -y \
sudo \
vim \
build-essential \
checkinstall \
gcc \
make \
automake \
wget \
curl \
openssh-server \
git-core \
mysql-server \
mysql-client \
sqlite3 \
libsqlite3-dev \
zlib1g-dev \
libyaml-dev \
libssl-dev \
libgdbm-dev \
libreadline-dev \
libncurses5-dev \
libffi-dev \
libxml2-dev \
libxslt-dev \
libcurl4-openssl-dev \
libicu-dev \
libxml2-dev \
libxslt-dev \
libcurl4-openssl-dev \
libreadline6-dev \
libc6-dev \
libssl-dev \
libmysql++-dev \
zlib1g-dev \
libyaml-dev \
libpq-dev \
libmysqlclient-dev

# Redis from backports 2.x +
apt-get install -y -t squeeze-backports redis-server

Soll Gitlab auch Mails versenden können (z.B. Passwort vergessen-Mails), so wird auch ein postfix benötigt.

# Install Postfix for mail sending (optional)
apt-get install postfix

Als nächstes intallieren wir Python, dies wird von Gitlab auch noch benötigt.

# Install python (2.x preferable, if python --version is 3.x+ use python27)
apt-get install python

# Ensure python2 exists (needed by gitlab)
which python2 || ln -s /usr/bin/python /usr/bin/python2

Als nächstes legen wir die Datenbank an.

# Create Database
mysql -u root -p

CREATE USER 'gitlab'@'localhost' IDENTIFIED BY 'YOUR GITLAB PASSWORD';
CREATE DATABASE IF NOT EXISTS `gitlabhq_production` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `gitlabhq_production`.** TO 'gitlab'@'localhost';

# Test SQL (need to enter YOUR GITLAB PASSWORD)
mysql -u gitlab -p -D gitlabhq_production

Jetzt wechseln wir auf den Benutzer und installieren Gitlab in dessen HOME-Verzeichnis:

su git
# Set git username and email
git config --global user.name "GitLab"
git config --global user.email "gitlab@localhost"

# Install Ruby RVM with ruby1.9.3
\curl -L https://get.rvm.io | bash -s stable

echo "source /home/git/.rvm/scripts/rvm" >> .bashrc

source /home/git/.rvm/scripts/rvm
source ~/.profile

rvm get head
rvm reload
rvm install 1.9.3
rvm --default use 1.9.3
echo "source /home/git/.rvm/scripts/rvm" >> .bashrc
source /home/git/.rvm/scripts/rvm

# Install bundler
gem install bundler

# Clone & Install GitlabShell
git clone https://github.com/gitlabhq/gitlab-shell.git
cd gitlab-shell
cp config.yml.example config.yml
vim config.yml
./bin/install

# Adjust the shebang for RVM
# Nach einem frischen clone steht da: #!/usr/bin/env ruby
# Das muss geändert werden in: #!/usr/bin/env /home/git/.rvm/bin/ruby
vim bin/gitlab-shell

cd /home/git

# Clone gitlab
git clone https://github.com/gitlabhq/gitlabhq.git gitlab
cd /home/git/gitlab
cp config/gitlab.yml.example config/gitlab.yml
vim config/gitlab.yml

chmod -R u+rwX log/
chmod -R u+rwX tmp/

# Create directory for satellites
mkdir /home/git/gitlab-satellites

# Create temp and make sure its wirtable
mkdir tmp/pids/
chmod -R u+rwX tmp/pids/

# Copy config templates
cp config/unicorn.rb.example config/unicorn.rb
cp config/database.yml.mysql config/database.yml

# Enable TCP instead of socket listening as we use apache
# Use port 46660 on 127.0.0.1 and comment the socket, as we don't need it
# die # vor listen 127.0.0.1:8080 entfernen und 8080 in 46660 ändern.
# eine # vor listen "#{app_dir}/tmp/sockets/gitlab.socket" setzen.
# !Dieser Schritt fällt weg, wenn man Gitlab auf einem nginx laufen lassen möchte, da dieser mit UNIX-Sockets reden kann.
vim config/unicorn.rb

# Configure database
vim config/database.yml

# Setup gitlab dependencies and database
gem install charlock_holmes --version '0.6.9'
bundle install --deployment --without development test postgres

bundle exec rake db:setup RAILS_ENV=production
bundle exec rake db:seed_fu RAILS_ENV=production
bundle exec rake gitlab:setup RAILS_ENV=production

# Check configuration
bundle exec rake gitlab:env:info RAILS_ENV=production

exit

Nun haben wir Gitlab erfolgreich auf dem System installiert und müssen dies nur noch starten. Dazu kann man das vom Entwickler bereitgestellte init.d Skript nutzen.

# Install init.d-script and run gitlab's sidekiq and unicorn
curl --output /etc/init.d/gitlab https://raw.github.com/gitlabhq/gitlab-recipes/master/init.d/gitlab
chmod +x /etc/init.d/gitlab
update-rc.d gitlab defaults 21
/etc/init.d/gitlab start

Nun hat man 2 Möglichkeiten, einmal NGinx und einmal Apache2.

NGinx:

# Install nginx and install gitlab site-config
apt-get install nginx
curl --output /etc/nginx/sites-available/gitlab https://raw.github.com/gitlabhq/gitlab-recipes/master/nginx/gitlab
ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab
vim /etc/nginx/sites-available/gitlab
service nginx restart

Apache2:

apt-get install apache2 libapache2-mod-ssl libapache2-mod-proxy-html
vim /etc/apache2/sites-available/git.domain.tld
a2enmod ssl
a2enmod proxy_http
a2ensite git.domain.tld
/etc/init.d/apache2 restart

git.domain.tld-VHost Konfiguration:

# require apache module mod_proxy and mod_proxy_http
<IfModule mod_proxy_http.c>
<VirtualHost :80>
ServerName git.domain.tld
ServerAdmin support@domain.tld

<IfModule mod_ssl.c>
RewriteEngine on
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(.*)$ https://%{SERVER_NAME}$1 [L,R]
</IfModule>

# Server Gitlab over http as we don't have https/ssl
<IfModule !mod_ssl.c>
ProxyPass / http://127.0.0.1:46660/
ProxyPassReverse / http://127.0.0.1:46660/
ProxyPreserveHost On

# Entsprechend anpassen!
# Deny from all, but allow BasicAuth and skip BasicAuth for 192.168.0.30
# Satisfy Any will make sure that all paths are tested, before deny all will get triggered
<Location />
Order deny,allow
Deny from all

AuthType Basic
AuthName "Git Repository"
Require valid-user
AuthUserFile /etc/apache2/git_auth.passwd

#Allow from 192.168.0.30
Satisfy Any
</Location>

CustomLog /var/log/apache2/gitlab_access.log combined
ErrorLog /var/log/apache2/gitlab_error.log
</IfModule>

</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName git.domain.tld
ServerAdmin support@domain.tld

# Sollte man noch auf seine eigenen Zertifikate anpassen!
SSLEngine On
SSLCertificateFile /etc/ssl/domain/domain.crt
SSLCertificateKeyFile /etc/ssl/domain/domain.key
SSLCACertificateFile /etc/ssl/domain/root.pem

ProxyPass / http://127.0.0.1:46660/
ProxyPassReverse / http://127.0.0.1:46660/
ProxyPreserveHost On
RequestHeader set X-Forwarded-Ssl on

# Entsprechend anpassen!
# Deny from all, but allow BasicAuth and skip BasicAuth for 192.168.0.30
# Satisfy Any will make sure that all paths are tested, before deny all will get triggered
<Location />
Order deny,allow
Deny from all

AuthType Basic
AuthName "Git Repository"
Require valid-user
AuthUserFile /etc/apache2/git_auth.passwd

#Allow from 192.168.0.30
Satisfy Any
</Location>

CustomLog /var/log/apache2/gitlab_access.log combined
ErrorLog /var/log/apache2/gitlab_error.log
</VirtualHost>
</IfModule>
</IfModule>

Danach kann man prüfen ob alles läuft und funktionsfähig ist:

# Check if everything works
su git
cd /home/git/gitlab
bundle exec rake gitlab:check RAILS_ENV=production

Schon hat man seinen eigenen Git-Repository Server am laufen, welcher zudem große Ähnlichkeiten mit Github hat. Viele Entwickler im eigenen Team die schon einmal mit Github gearbeitet haben, werden sich da schnell zurechtfinden.

Der initiale Administratoren Login lautet dann admin@local.host mit dem Passwort: 5iveL!fe

Dieser Benutzer sollte nach dem anlegen des eigenen Admin-Benutzers am besten gelöscht werden.

Bei Fragen oder Kritiken können gern die Kommentare genutzt werden

Netzwerk-Konfiguration mit Proxmox VE

nospam@example.com (Robert Klikics) — Tue, 11 Dec 2012 08:39:00 +0100

Mit Proxmox VE kann man hervorragend virtualisieren und bekommt ein nettes Webinterface dazu, um die Konfiguration vorzunehmen. Deshalb kommt diese Lösung, vor Allem mit KVM, seit einiger Zeit auch bei den virtuellen managed Servern von RobHost erfolgreich zum Einsatz. Selbst Hochverfügbarkeit wird unterstützt - dazu in einem späteren Blogpost mehr.

Leider ist die Netzwerk-Config nicht immer ganz trivial, im Netz finden man haufenweise Fragen und Howto's zu diesem Thema. Zwar beschreibt das Proxmox-Wiki auch einige Szenarien, in der Praxis sind aber oft Host-IP und das Subnetz für die VM's verschiedene Netzbereiche.

Ein Problem bei vielen Rootservern ist, dass die Anbieter i.d.R. aus Sicherheitsgründen nicht zulassen, dass Netzwerk-Traffic über ein Interface von mehreren MAC-Adressen kommt. Dies hat zur Folge, das oft die normale Bridged-Lösung nicht funktioniert und eine etwas unschöne Routed-Konfiguration herhalten muss. Wir haben das Problem im Rechenzentrum zum Glück nicht, daher wird hier die Bridged-Variante vorgestellt.

Dennoch gibt es das "Problem", dass die IP des Proxmox-Host in einem anderen Netz liegt als das Subnetz für die virtuellen Maschinen. Daher klappt die ganz einfache Bridged-Konfiguration hier nicht, da wir ja keine IP verlieren wollen. Ansonsten könnte man natürlich dem Host die erste IP des Subnetzes geben. In Zeiten chronischer IPv4-Knappheit ist das aber wohl nicht im Sinne des Erfinders bzw. der RIPE

Also brauchen wir eine Point-to-Point Verbindung, so dass die VMs zum Gateway auch durchkommen und eine normal funktionierende Netzwerk-Config haben.

So sieht das Ganze dann unter Proxmox/Debian auf dem Host aus:

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
address 62.xxx.xxx.43
netmask 255.255.255.255
gateway 62.xxx.xxx.1
pointopoint 62.xxx.xxx.1
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0

Wichtig ist die Netzmaske von 255.255.255.255 sowie der pointopoint Eintrag (Achtung: nur mit einem "t"!). Mehr ist nicht nötig, d.h. es müssen keine expliziten Routen zu den VMs oder dem Subnetz gesetzt werden.

Innerhalb der VMS sieht das dann so aus (Debian/Ubuntu):

iface eth0 inet static
address 5.xxx.xxx.111
netmask 255.255.255.255
gateway 62.xxx.xxx.43 # VM Host
pointopoint 62.xxx.xxx.43 # VM Host

Bzw. so unter CentOS:

# File: /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE="eth0"
BOOTPROTO="static"
IPADDR="5.xxx.xxx.111"
NETMASK="255.255.255.255"
GATEWAY="62.xxx.xxx.43"
HWADDR="D6:68:xx:xx:93:0B"
ONBOOT="yes"

# File: /etc/sysconfig/network-scripts/route-eth0

62.xxx.xxx.43 dev eth0 scope link
default via 62.xxx.xxx.43

Das war es auch schon, damit sollten alle VMs problemlos an das Netz angebunden sein.

In Kürze stellen wir hier unser Auto-Deployment Script für Proxmox vor. Bei Fragen einfach die Kommentare nutzen

Datenbankstrukturen visualisieren

nospam@example.com (Robert Klikics) — Sun, 19 Aug 2012 12:17:00 +0200

Beim Entwickeln und Dokumentieren von Software mit Datenbankanbindung ist es unumgänglich, die Struktur der Daten zu visualisieren. Die Aktualisierung der Dokumentation erfordert allerdings viel Disziplin und Aufmerksamkeit. Im Termindruck kurz vor der Abgabe kommt es ab und zu vor, dass die Dokumentation auf die TODO-Liste gesetzt wird.

Auf der Suche nach einer automatisierteren Lösung sind wir an den ausgereiften Möglichkeiten der Graphviz community nicht vorbeigekommen. Eine einfache "DOT Language" ermöglicht es komplexe Grafiken und Strukturdiagramme mit unzähligen Einstellmöglichkeiten zu generieren.

In einem aktuellen Beispiel benutzen wir den dot-compiler um eine Datenbankstruktur als Anlage für ein Pflichtenheft zu visualisieren. Ein lediglich mit der Datenbankverbindung konfigurierbares Script erzeugt die DOT Datei. Tabellen, Spalten, Fremdschlüssel und Datentypen können ganz nach belieben in der einfach zu verstehenden DOT Language ausgezeichnet werden.

Das erwähnte Script in PHP findet ihr hier. Daraus wird ein Dotfile erzeugt, welches die hier dargestellte Grafik erzeugt.

Multiuser-GIT-Repos mit Gitolite (Debian Squeeze)

nospam@example.com (Uwe Gerdts) — Fri, 13 Jul 2012 13:06:00 +0200

Git als Versionsverwaltung wird immer beliebter und die Dienste gitorious.org oder github.com boomen. Wer dennoch Herr seiner Daten bleiben will oder wer die Kosten für einen Pro-Account bei diesen Diensten scheut kann sich leicht mit einer eigenen Repo-Verwaltung behelfen. Gitolite ist ein tolles Tool um genau dies zu ermöglichen.

Installation

Git und gitolite sind Bestandteil des Debian Squezze Repositories. Die Installation sollte also wieder ohne großen Aufwand erfolgen.

#apt-get install git-core gitolite

Falls noch nicht geschehen, genenrieren wir uns einen SSH-Key.

#ssh-keygen

Diesen Key benötigen wir für den initialen Zugang zur gitolite-Verwaltung. Wir kopieren ihn nach /tmp um ihn für unseren git-Systemuser verfügbar zu machen.

#cp .ssh/id_rsa.pub /tmp/gitolite_init.pub

Optional können wir noch ein paar globale git Konfigurationsvariablen setzen.

git config --global user.name "Dein Name"
git config --global user.email deine@email.de

Nun erstellen wir unser zentrales Repoverzeichniss und legen einen git-Systemuser an.

#/var/git-repos
#useradd -d /var/git-repos/ -s /bin/bash git
#chown git:git /var/git-repos/

Nun wechseln wir zu unserem git-Systemuser und starten das Setup von gitolite in seinem home-Verzeichniss. Wichtig ist die Übergabe des inititalen SSH-Keys den wir in /tmp abgelegt haben. Der Key in /tmp wird danach nicht mehr benötigt und kann gelöscht werden.

#su git
$cd /home/git-repos
$gl-setup /tmp/gitolite_init.pub
$exit
#rm /tmp/gitolite_init.pub

Dann können wir das administrative Repo auschecken und die Konfigurationen auf unsere Bedürfnisse anpassen.

git clone git@127.0.0.1:gitolite-admin.git

In ./gitolite-admin/conf/gitolite.conf werden die Repos und Berechtigungen verwaltet. im Verzeichniss ./gitolite-admin/keydir/ werden die public-ssh-keys der User abgelegt.
Die Änderungen werden erst wirksam wenn wir das repo auf den Server pushen.

#git add .
#git commit .
#git push

Falls wir in ./gitolite-admin/conf/gitolite.conf ein neues Repo konfiguriert haben wird dies nach einem push auch automatisch angelegt und steht sofort bereit.

Fazit

Gitolite bietet die Möglichkeit mehrere git-Repos für mehrere User komfortabel zu verwalten ohne dem User weitere Rechte auf dem System ermöglichen zu müssen. Gitolite setzt für die Authentifizierung von Benutzern ausschließlich auf SSH-Keys. Eine Authentifizierung via Passwort ist nicht möglich. Es sind sehr komplexe Berechtigungsstrukturen möglich die Dokumentation dazu findet man hier.
Wer ein schönes Web-Interface braucht sollte ein Blick auf gitlabhq.com werfen. Dies scheint ein interessantes Projekt zu sein und setzt direkt auf gitolite.

Synergy - Cleveres Software KVM

nospam@example.com (Christoph Kretzschmar) — Wed, 11 Jul 2012 16:17:00 +0200

Synergy ist interessant für jeden der 2 Monitore, 2 Rechner und nur 1 Set an HID`s besitzt.

Man könnte jetzt Maus und Tastatur über ein KVM Hardware Switch ständig zwischen beiden Rechnern hin-und-her wechseln. Jedoch besitzt nicht jeder ein solches Gerät, noch lohnt sich die Anschaffung des selbigen Aufgrund der doch sehr hohen Kosten von USB KVM Switches.

Eine mittlerweile sehr gute Softwarelösung ist Synergy, welches Maus und Tastatur über das Netzwerk mit beiden Rechnern verbindet. Dabei fungiert der Rechner mit angeschlossenen Geräten als Server und der Rechner, welche keine Maus und Tastatur angeschlossen hat als Client.

Dabei hat man die freie Wahl der Plattform, denn Synergy ist Plattformunabhängig. Ein weiterer Vorteil ist die synchronisierte Zwischenablage. Zuletzt sei erwähnt dass man durch die Software Lösung auch gerne schnell vergisst, dass man 2 verschiedene Rechner bedient, denn Synergy schaltet seamless zwischen beiden Systemen um, sobald man den Konfigurierten Randbereich mit der Maus überschreitet.

Konfiguration
Vorab: Ich empfehle euch unbedingt die Beta zu benutzen, da hier die Benutzerschittstelle um einiges ausgereifter ist.
Szenario: Rechner 1 ist ein Windows mit angeschlossenen Gerätschaften, Rechner 2 ist ein OSX Lion der diese Geräte nutzen möchte.

Zuerst installiert man auf beiden Systemen die Software. Dabei wählt man in der Installation für Rechner 1, Server aus und für Rechner 2 wählen wir Client. Die Frage nach dem Automatischen Start kann jeder so beantworten wie er es gerne mag, bei mir starten beide Rechner die Software im "Desktop" Level, bedeutet erst nachdem ich mich angemeldet habe.

Nun kann man auf Seite des Servers entsprechend "Configure Server..." wählen. Nun hat man eine Übersicht aller konfigurierten Rechner (im unkonfigurierten Fall entsprechend ein Monitor in der Mitte mit dem Netzwerknamen des eigenen Rechners).

Nun kann man von oben Rechts einen Monitor, via drag-and-drop an die Position ziehen, die der zweite physische Monitor hat, welcher an den 2. Rechner angeschlossen ist. Dadurch wird ein "Unnamed" Bildschirm erstellt.

Durch einen Doppelklick auf diesen gelangt man entsprechend in den Konfigurationsdialog. Dort gibt man diesem Bildschirm den Netzwerknamen/Hostname des 2. Rechners als "Screen name" an. In meinem Fall ist das "Christophs-MacBook-Pro.local". Jetzt kann man noch diverse "Key-Modifier" umsetzen, was bei OSX z.B. Praktisch ist, da sonst Super(Apfel) und Alt vertauscht sind. Daher mappe ich in meinem Fall "Alt auf Super" und "Super auf Alt". Damit ist auf Seiten des Servers alles fertig konfiguriert. Starten wir nun also den Server über die "Start" Schaltfläche und kümmern wir uns um den Client.

Beim Client muss man nun einfach nur den Namen des Servers eintragen. Dabei kann man den NetBios/DNS Namen oder aber die IP Adresse benutzen. Danach kann man auch hier auf "Start" drücken. Nun sollte bei beiden Rechnern in der Log von Synergy stehen, das eine Verbindung erfolgreich aufgebaut wurde.

Ab jetzt kann man den anderen Rechner von seinem Hauptsystem aus wie einen 2. Bildschirm verwenden. Einfach über den Randbereich hinweg gehen, je nachdem wie man den Monitor eingestellt hat links oder rechts, schon hat man Maus und Tastatur nutzbar auf dem 2. Rechner. Im selben Moment wird dann auch die Zwischenablage synchronisiert. Thats it.

Fazit
Der einzige Nachteil des ganzen ist, dass man den Monitor händisch an den 2. Rechner anschließen muss. Zudem werden auch Audiosignale nicht übertragen. Jedoch ist dies für den Office gebrauch nicht weiter tragisch. Für Audio könnte man die Software Airfoil nehmen, diese ist jedoch entsprechend kostenpflichtig und beim Monitor müsste man zwangsweise einen Hardware KVM Switch für Monitore besitzen.

Vorteil ist die ständige Weiterentwicklung dieses Projekts und dass es Open Source ist. Zudem sind, trotz Beta, während meiner Benutzung keinerlei Fehler aufgetreten. Einzig das Mapping von AltGr auf Command+Alt ist für OSX ziemlich nervig. Ein Patch scheint dafür schon in das Projekt eingeflossen zu sein, jedoch bietet die GUI noch keine Möglichkeit diese Einstellung vorzunehmen.

Git für Beginner - Teil 1

nospam@example.com (Christoph Kretzschmar) — Sat, 07 Jul 2012 13:24:00 +0200

In aller Munde ist das Versionierungssystem Git, da es unter Anderem von großen Projekten zur Versionsverwaltung genutzt wird. Entwickelt wurde es von Linus Torvalds, da alle anderen Versionierungssystem nicht dynamisch genug für die Kernel Entwicklung waren, vor allem sobald es um das 'mergen' von einzelnen 'branches' ging.

Doch wie funktioniert Git nun eigentlich? Zuerst sei die Architektur von Git erwähnenswert, da diese nicht zentralisiert, sondern eher verteilt ist. Das bedeutet, dass Jeder, der mit einer Kopie eines Git-Clones arbeitet, im Endeffekt das gesamte Repository mit allen Änderungen auf seinem Rechner lokal vorliegen hat. Daraus resultiert auch ein gewaltiger Vorteil von Git z.B. gegenüber SVN oder CVS. Die Verwaltung sämtlicher Änderungen findet komplett Offline im 'working directory' statt. Ist man z.B. gerade im Zug unterwegs, muss man daher nicht auf eine Versionsverwaltung für sein aktuell bearbeitetes Projekt verzichten.

Die Basics sind dabei relativ einfach erlernbar und nach wenigen Nutzungen muss man auch nicht mehr groß darüber nachdenken Anbei eine kleine Einführung:

Zuerst müssen wir die Versionierung für ein Projekt oder genauer für das aktuelle Verzeichnis erstellen:

 git init

Ab jetzt ist das Verzeichnis bereit, den Inhalt zu versionisieren. Welche Dateien oder Verzeichnisse man nun verwalten möchte, kann man über:

 git add <file|dir>

festlegen, ziemlich analog zu SVN. Dennoch gibt es einen Unterschied, denn es werden nur die Änderungen zum 'Stage' hinzugefügt, welche bis zu diesem Zeitpunkt gemacht wurden. Bearbeitet man die Datei erneut, so müsste man diese Änderungen auch wieder mit einem 'add' erneut hinzufügen (auch wenn man in der Datei die bereits versionisierten Änderungen gelöscht hat, so muss man diese erneut hinzufügen, damit diese gelöschten Änderungen hinzugefügt werden).

Doch was ist denn eine 'Stage'? Der Stage ist ähnlich wie eine Kiste. In dieser liegen alle Änderungen, die wir über den 'add' Befehl hinzufügen oder über den 'reset' Befehl löschen. Zusätzlich gibt es auch noch eine temporäre Kiste in der man Änderungen zwischenspeichern kann um z.B. externe Patches auf einen Quelltext anzuwenden und dann die eigenen Änderungen wieder anwenden zu lassen. Letzteres geht jedoch für Beginner erstmal zu weit, es sei aber am Rande erwähnt.

Möchte man die 'staged' Änderungen verwerfen, kann man Dies erreichen, indem man folgendes eingibt:

 git reset <file|dir>

Möchte man die Änderungen nun endgültig versionisieren, so kann man diese nun commiten:

 git commit

Dabei werden sämtliche Änderungen in das lokale Git-Repository geschrieben.

Was jedoch machen, wenn man dennoch etwas vergessen hat dem aktuellen Commit hinzuzufügen oder aber man noch einen Fehler gefunden hat, der direkt auf den Commit bezogen ist? Git ermöglicht es dem letzten Commit weitere Änderungen anzuhängen. im Jargon nennt man dies entsprechen 'Amend'. Dabei kann auch die Commit-Message umgeschrieben werden.

Hat man also weiter Änderungen über add hinzugefügt, dann kann man diese dem letzten Commit hinzufügen:

 git commit --amend

Damit hat man - grob - die Basics von Git umrissen.
Im nächstenTeil werde ich noch erklären, warum man immer auf einem Branch arbeiten sollte und die Änderungen entsprechend in den 'master' zurückfließen lassen sollte. In dem Zusammenhang werde ich auch noch erläutern, wie man sein lokales Repository auf github.com hochladen kann um eine 'globale' Version des Repositories zu haben.

multitail - Ein Auge auf den Logs

nospam@example.com (Uwe Gerdts) — Fri, 06 Jul 2012 11:46:15 +0200

Wer gleichzeitig mehr als ein Log-Datei im Auge behalten will kommt um das Tool multitail nicht herrum. Multitail erlaubt das gleichzeitige Betrachen mehrerer Log-Dateien.

Installation

Installation erfolgt in der Regel aus den Repos der Distribution.

#apt-get install multitail

Danach ist multitail schon vollständig einsatzbereit.

HowTo

Um Logdatei gleichzeit anzuschauen verwendet man:

#multitail datei01 datei02 datei03 ...

#multitail /var/log/syslog /var/log/messages

Mit dem Parameter -I kann man Dateien zusammenführen.
Im Beispiel werden die Dateien /var/log/mail.log und /var/log/auth.log in einen Fenster zusammengeführt dargestellt.

multitail /var/log/apache2/access.log /var/log/mail.log -I /var/log/auth.log

Der Parameter -l ermöglicht das Ausführen von Befehlen und Scripten. Mit -R wird der Refresh-Intervall bestimmt.
Im Beispiel wird netstat -tupan aller 2 Sekunden in einen Fester ausgeführt.

multitail /var/log/apache2/access.log /var/log/mail.log -I /var/log/auth.log -R 2 -l "netstat -tupan"

Falls man die Fenster auch noch vertikal teilen möchte geht das natürlich auch. Der Parameter -s gibt an wieviele vertikal Fenster erstellt werden sollen.

multitail -s 2 /var/log/apache2/access.log /var/log/mail.log -I /var/log/auth.log -R 2 -l "netstat -tupan"

Fazit

Multitail ist für mich eine bessere und komfortablere Variante mehrere Logfile zu betrachten. Multitail ist sehr gut an die persönlichen Bedürfnisse und Vorlieben anpassbar. Einstellungen können global in /etc/multitail.conf oder für jeden User in der .multitailrc angepasst werden. Eine sehr umfangreiche Dokumentation findet man auf der Projektseite von Multitail http://www.vanheusden.com/multitail/ oder in den Manpages.

Das Problem mit der Schaltsekunde

nospam@example.com (Robert Klikics) — Tue, 03 Jul 2012 14:13:00 +0200

Durch eine am Wochenden eingefügte Schaltsekunde gab es auf vielen Linux-Servern ein Problem mit der CPU-Load. Das ging von 100% CPU-Usage auf einem oder mehreren Cores bis zum kompletten Absturz. In der Verzweiflung haben viele Admins (so wie ich auch erstmal, bevor das Problem langsam klar wurde) mit Reboots die Rettung erzwungen. Inzwischen ist das Problem aber bekannt, so dass man zum Beispiel mit folgendem Befehl die Last wieder normalisieren kann:

date; date `date +"%m%d%H%M%C%y.%S"`; date;

Vor Allem betroffen waren Systeme mit MySQL und auf Java basierenden Applikationen (Tomcat etc.). Hoffen wir also, dass bis zur nächsten Schaltsekunde ein Fix direkt im Kernel integriert wird.

Der Webhoster Hetzner informierte seine Kunden sogar per Mail darüber, dass diese doch bitte mal ihre Server prüfen sollen. Durch den Anstieg der CPU-Load auf tausenden Servern ist dort der Stromverbrauch angeblich im 1 Megawatt (!) gestiegen.

Es lohnt also generell die Kontrolle des eigenen Servers.

Composer - Einfaches Dependency Management für PHP

nospam@example.com (Christoph Kretzschmar) — Sun, 01 Jul 2012 19:25:00 +0200

Dependency Management ist auch in PHP ein wichtiger Teil der Entwicklung, da man sich vor allem beim Ausrollen der Anwendung sicher sein muss, dass alles auf den - meist stabilen - Versionen läuft, für welche die Anwendung entwickelt wurde.

Hilfreich kann hierbei Composer werden. Das Projekt entspringt zum Teil der Entwicklung von Symfony2, wodurch auch so ziemlich alle Symfony2 Pakete dort gefunden werden können, sofern der Maintainer des Pakets sein Repository entsprechend Composer kompatibel gestaltet.

Zudem kann der Maintainer entsprechende Abhängigkeiten angeben, welche dann von Composer aufgelöst, heruntergeladen und installiert werden.

Die Nutzung von Composer wird sehr gut auf der Standard Repository Seite Packagist erklärt. Dort kann man dann auch entsprechend nach sämtlichen von Haus aus unterstützen, bzw. verwalteten Paketen suchen und sich deren Abhängigkeiten, etc. anschauen.

Geliefert wird die Composer im .phar Format, wodurch es ggf. nötig ist, die suhosin.ini für php-cli entsprechend anzupassen, falls Suhosin für PHP aktiviert ist (wie z.B. default unter Debian)

suhosin.executor.include.whitelist = phar

Hat man nun alle Einstellungen getätigt und sich seine composer.json erstellt, kann man sich nun die Abhängigkeiten bequem herunterladen via:

php composer.phar update

Dies erstellt zudem eine composer.lock Datei, welche die soeben heruntergeladenen Versionen dokumentiert. Rollt man die Anwendung nach der Entwicklung auf dem Produktivsystem aus, führt man einfach ein:

php composer.phar install

aus.

Dies installiert dann genau die Versionen, welche beim Aufruf von "update" festgesetzt wurden, selbst wenn in der Versionsverwaltung neuere Versionen existieren sollten.

Ein weiterer Vorteil ist die 'autoloader.php' im 'vendor' Verzeichnis, welches von Composer angelegt wird. Diese enthält das PSR-0 kompatible, automatische Laden von unbekannten PHP-Klassen anhand des Klassennamens und aktuellem Namespaces. Fügt man diese Datei in seinem Skript hinzu, kann man die Abhängigkeiten (bzw. deren Klassen) nutzen, ohne 100 Dateien inkludieren zu müssen.

Der initiale Konfigurationsaufwand scheint dabei groß zu sein, jedoch profitiert man umso mehr davon, je mehr Abhängigkeiten die Anwendung hat und je öfter man die Anwendung auf einem Produktivsystem ausrollen möchte.

owncloud - die eigene Wolke!

nospam@example.com (Uwe Gerdts) — Fri, 29 Jun 2012 11:07:01 +0200

Die Cloud Cloud Cloud kein Tag vergeht, keine Fachzeitschrift kann man aufschlagen, ohne über die "Cloud" zu stolpern. Da dachten wir uns "Wenn schon Cloud, dann wollen wir unsere eigene Cloud!".

In den nachfolgende Zeilen werde ich Euch durch die wirklich kinderleichte Installation der "owncloud" führen. Danach seid Ihr in der Lage Eure eigene "Cloud" zu betreiben.

Für den Familien-Betrieb der owncloud reicht ein mittlerer VServer aus. Auf einem minimalen Debian-System installiert man die benötigen Pakete.

apt-get install apache2 php5 php5-gd php5-sqlite curl libcurl3 libcurl3-dev php5-curl bzip2

Danach holen wir uns die aktuelle Version von der ownclound-Projektseite. Derzeit ist die 4.0.4 aktuell.

wget http://download.owncloud.org/releases/owncloud-x.x.x.tar.bz2

Wir entpacken das Archiv und kopieren es in unser Documentroot des Webservers.

tar -xjf owncloud-x.x.x.tar.bz2
cp -r owncloud /var/www/owncloud
chown -R www-data:www-data /var/www/owncloud/

Danach aktivieren wir noch ein paar Apache-module

a2enmod rewrite
a2enmod headers

und passen unsere Konfiguration an. (die einfachste Methode)

vi /etc/apache2/sites-available/default
...
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
...

Dann steht unsere owncloud unter http://unser.server/owncloud/ bereit. Beim Erstaufruf der Seite vergeben wir Name und Passwort des administrativen Benutzers. Nun können wir im Backend weitere Einstellungen tätigen und die Cloud für weitere User freigeben.

Derzeit läuft die Datenbank mit SQLite, falls ihr MySQL bevorzugt installiert Ihr einfach den MySQL-Server und könnt beim Erstaufruf von http://unser.server/owncloud/ unter dem Punkt erweitert auch die Zugangsdaten für den MySQL-server eingeben.

Fazit

Leider ist in der Community Edition keine HA/Replikation möglich. Eine Übersicht der Unterschiede zu den Pro-Versionen findet ihr hier. Die Community-Version der owncloud hat mich persönlich enttäuscht. Der gebotene Funktionsumfang ist sehr rudimentär und die fehlende Replikation konnten meine Erwartungen nicht erfüllen. Im Bereich Hobby/Familie dennoch ein interessantes Projekt. Was habt ihr für Erfahrungen mit der Owncloud?

Pakete vom Update aussschließen (Debian/Ubuntu)

nospam@example.com (Uwe Gerdts) — Tue, 26 Jun 2012 09:26:00 +0200

Oft ist es sinnvoll die Aktualisierung eines Paketes zu verhindern oder etwas zu verzögern. Um Trotzdem wie gewohnt den Paketmanager zu nutzen, müssen wir die Paket von der Aktualisierung ausschliessen. Das funktioniert, indem wir ihm den Status hold verpassen.

Ausgangssittuation

#apt-get upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Status-Informationen einlesen... Fertig
Die folgenden Pakete werden aktualisiert:
libgcrypt11
1 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 271kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 4.096B Plattenplatz freigegeben.
Möchten Sie fortfahren [J/n]? n

Wir wollen nun verhindern, dass libgcrypt11 zukünftig aktualisiert wird.

Pakete auf hold setzen

dpkg (apt-get)

#echo "libgcrypt11 hold"|dpkg --set-selections

aptitude

#aptitude hold libgcrypt11

Auflisten der Paket die auf hold gesetzt sind

Um eine Übersicht zu erhalten, welche Pakete wir ausgeschlossen haben, verwenden wir:

dpkg (apt-get)

#dpkg --get-selections |awk '$2 == "hold" { print $1 }'

aptitude

#aptitude search ~ahold

Kontrolle

Nun sollte bei einem upgrade das Paket libgcrypt11 ausgeschlossen werden.

#apt-get upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Status-Informationen einlesen... Fertig
Die folgenden Pakete sind zurückgehalten worden:
libgcrypt11
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 1 nicht aktualisiert.

Paket auf unhold setzen

Um das Paket wieder in das regelmäßige Update aufzunehmen setzen wir den Satus wieder in den Ausgangszustand.

dpkg (apt-get)

#echo "libgcrypt11 install"|dpkg --set-selections

aptitude

#aptitude unhold libgcrypt11

Kontrolle

Nun sollte das Paket wieder in den Aktualisierungen vorhanden sein.

#apt-get upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Status-Informationen einlesen... Fertig
Die folgenden Pakete werden aktualisiert:
libgcrypt11
1 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 271kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 4.096B Plattenplatz freigegeben.
Möchten Sie fortfahren [J/n]? j
...

Dieses Verfahren ist eher die Ausnahme als die Regel. Bitte denkt daran, Eure Systeme stets aktuell zu halten.

Eine Domain komplett via RewriteRule weiterleiten

nospam@example.com (Robert Klikics) — Mon, 25 Jun 2012 12:06:49 +0200

Aus aktuellem Anlass hier ein Rewrite-Rule zur Google-freundlichen 301-Weiterleitung einer bestehenden Domain auf eine neue Domain via .htaccess oder direkt im Apache vHost:

RewriteEngine On
RewriteRule (.*) http://www.neue-domain.de/$1 [R=301,L]

Das Admin-Blog.com ist seit heute unterhalb von RobHost.de zu Hause - am Inhalt ändert sich aber natürlich nichts. Allerdings soll das Blog wieder mit mehr Leben befüllt werden, wobei die Mitarbeiter von RobHost helfen sollen (und auch wollen, so wurde mir versichert..). Denn täglich testen wir neue Tools oder beheben Fehler, die für die Nachwelt interessant sein könnten - sowohl aus dem Linux-Umfeld aus der Serveradministration bei unseren Kunden als auch in der Programmierung.

US-Proxy für YouTube und Co. bei Server4You - das war wohl nix

nospam@example.com (Robert Klikics) — Wed, 16 Nov 2011 16:52:00 +0100

Die Idee schien einfach und gut zu sein. Einen vServer bei Server4You für weniger Euro im Monat mieten und dabei Serverstandort USA wählen. Dann über Squid (Proxy) entspannt Youtube und Hulu schauen. Soweit die Theorie.

In der Praxis stellt es sich allerdings so dar, dass offenbar die IP-Range (50.30.32.0 - 50.30.47.255) von Server4You bei YouTube auf Blacklist ist. Ich habe es nicht geschafft, ein hier gesperrtes Video über den Proxy zu schauen, stets werde ich als aus Deutschland kommend erkannt. Zuerst hatte ich die Browserkennung in Verdacht, aber selbst auf Konsole mit lynx kommt der Fehler:

Unfortunately, this video is not available in Germany because it may
contain music for which GEMA has not granted the respective music
rights.
Sorry about that.

Das Reverse-Lookup war der nächste Verdacht, denn das lautetet xxx.vserver.de - also wurde das auch fix auf eine .com Domain gelenkt - ebenfalls ohne Erfolg. Leider habe ich nirgends eine Info gefunden, warum das so ist. Bei einem anderen Anbieter, der direkt in den USA sitze, geht das Ganze problemlos.

Hat ein Leser vielleicht einen Hinweis dazu?

Iphone 4S gestohlen, Telekom hilft nicht

nospam@example.com (Robert Klikics) — Tue, 15 Nov 2011 23:00:00 +0100

Nachdem kürzlich leider mein nagelneues iPhone 4S 32GB bei einem Einbruch gestohlen wurde (Kripo ermittelt und hat auch die IMEI, womit sie die Täter orten will bzw. es vielleicht sogar bereits getan hat), musste schnellstens Ersatz her. Natürlich war die erste Idee, bei der Telekom nachzufragen, denn dort habe ich schließlich mehrere Verträge und auch das 4S bezogen.

Nachdem meine Mail an die Kundenbetreuung nach einer knappen Woche nicht beantwortet wurde und die Hotline wie so oft durch Unwissenheit, was in solch einem Spezialfall zu tun sei, auffiel, war guter Rat teuer. Der heisse Tipp des Hotline-Menschen war, ich solle doch eine Mail an die Kundenbetreuung schreiben mit Diebstahlanzeige etc. Das hatte ich ja aber vor einer Woche bereits getan, sogar der Polizeibericht hing als Scan dran.

Gut, also mal den "Web 2.0 Support" der Telekom in Form des Twitter-Accounts @Telekom_Hilft bemüht. Dort wechseln sich anscheinend diverse Mitarbeiter ab und lesen die vorherigen Tweets zum Thema nicht, trotz dass ich extra immer brav "Reply" genutzt habe. Erst wurde mir ein weiterer neuer Vertrag, dann ein plötzlich ein Netlocked-iPhone 4 (ohne S) angeboten. So richtige Infos zu Preisen etc. bekam ich aber über Twitter nicht. Einen Vertrag habe ich ja aber schon, ich will einfach nur ein neues iPhone 4S und bin natürlich auch bereit, dafür zu zahlen. Die Versicherung kommt ja immerhin für den Neupreis des entwendeten Gerätes auf.

Eine weitere Woche später - ein neues 4S war längst bei Apple bestellt - kam dann noch ein Brief von der Telekom. Darin wurde mir allen Ernstes als "Ersatz für mein entwendetes iPhone 4S" ein netlocked iPhone 4 mit 32 GB für 729 EUR angeboten. Hallo? Ich zahle doch nicht den vollen Originalpreis eines veralteten iPhone 4, welches auch noch netlocked ist, obwohl mir ein 4S geklaut wurde. Irgendwie ziemlich sinnlos, dieses Angebot. Das iPhone 4S ist aber, warum auch immer, als Ersatz bei Diebstählen nicht verfügbar.

Inzwischen ist mein 4S von Apple bereits eingetroffen und die Telekom kann mich mal gerne haben, vermutlich am Ende der Vertragslaufzeit auch als Kunden. Ein wenig mehr Entgegenkommen bei einem Diebstahl sollte bei einem langjährigen Kunden doch drin sein, oder?

Ob das natürlich jetzt bei Vodafone oder O2 besser gelaufen wäre, kann ich nicht sagen. Der Ablauf bei der Telekom war zumindest eine herbe Enttäuschung.

Schutz bei (D)DOS Angriffen mit Iptables

nospam@example.com (Robert Klikics) — Mon, 07 Nov 2011 21:41:00 +0100

Es soll ja vorkommen, dass ein Server von extern z.B. mit sehr vielen HTTP-Anfragen lahmgelegt werden soll. In so einem Fall ist guter Rat teuer, um Schaden vom Server und der darauf laufenden Websites bzw. Applikationen abzuwenden. Oft hilft einem auch der ISP dabei, verlassen kann man sich darauf freilich nicht. So wurde kürzlich bei einem Fall der Kunde zwar sogar von Hetzner über die DDOS-Attacke informiert Gegenmaßnahmen wurden aber nicht getroffen. Im schlimmsten Fall droht sogar die Sperrung der IP seitens Hetzner, was natürlich zum Teil auch nachvollziehbar ist.

Serverseitig kann man aber auch etwas tun, z.B. das kleine Shell-Script (D)DoS Deflate laufen lassen. Dieses kleine Script prüft ganz einfach per netstat, welche IP eine in der Config definierte Anzahl von Verbindungen überschreitet und sperrt diese wirksam direkt via iptables (diese Variante bevorzuge ich, es wird einfach DROP auf alle Pakete von der Quell-IP angewendet) oder via apf (Advanced Policy Firewall). Das Script hilft natürlich nur, wenn der Server noch erreichbar ist und arbeitet, d.h. wenn die Attacke nicht die die komplette Bandbreite verbraucht oder zu extrem ist.

Zur "Installation", die im Wesentlichen aus ein paar Downloads via wget und der Einrichtung eines Cronjobs funktioniert, holt man sich einfach wie auf der Website angegeben das Script install.sh von einem Server. Alternativ habe ich das Ganze hier nochmals als Mirror hinterlegt: ddos.tar (20 KByte). Den Tarball einfach z.B. nach /usr/local/ entpacken und es kann losgehen.

In der ddos.conf kann man via NO_OF_CONNECTIONS angeben, ab wievielen Verbindungen eine IP gesperrt wird. Das muss man einfach testen bzw. es kommt sehr darauf an, was auf dem Server normalerweise los ist. Bei zu niedrigen Werten läuft man natürlich Gefahr, auch "normale" User zu sperren. Mit BAN_PERIOD legt man dann fest, wie lange die IP gesperrt werden soll. Die eigene IP kann man übrigens mit einem Eintrag (neue Zeile) in der Datei ignore.ip.list whitelisten, 127.0.0.1 ist default auf der Whitelist

Jetzt kann man direkt ./ddos.sh ausführen und sieht auch direkt den Output den im Script ausgeführten netstat, das konkret so aussieht:

netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n

Alle IPs mit einer Connection-Anzahl > NO_OF_CONNECTIONS werden nun also für BAN_PERIOD Sekunden gesperrt. Ein Cronjob, der am besten im Abstand läuft, wie auch BAN_PERIOD gesetzt ist, rundet die Config ab.

Erfolge kann man dann ganz einfach z.B. via iptables -L -nv sehen. Diese recht rudimentäre Lösung kann bei kleineren Angriffen durchaus nützlich sein und hat sich schon mehrfach im Einsatz bewährt. Hilfreich sind übrigens auch weitere IP-Adressen und kurze TTL im DNS, um schnell reagieren zu können.

Sollte der Angriff nur auf einzelne Dienste wie z.B. Apache durchgeführt werden, lohnt auch ein Blick auf Fail2Ban.