seeseekey.net - Invictus Deus Ex Machina

Counter-Strike 1.6 hat mittlerweile einige Jahre auf dem Buckel, gehört aber immer noch zu den beliebtesten Multiplayer-Spielen. Möchte man unter Ubuntu einen Server aufsetzen, so ist dies in wenigen Schritten erledigt. Im ersten Schritt müssen Abhängigkeiten installiert und ein Nutzer für den Server angelegt werden:

apt-get install lib32gcc1
adduser counterstrike

Nach dem Anlegen des Nutzers wird in dessen Kontext gewechselt und dort die Ordner-Infrastruktur angelegt:

su counterstrike
cd
mkdir steam
mkdir game

Nun steht die Installation des Steam-Kommandozeilen-Clients an:

cd steam
wget http://media.steampowered.com/installer/steamcmd_linux.tar.gz
tar -xvzf steamcmd_linux.tar.gz
rm steamcmd_linux.tar.gz

Danach kann der Steam-Client gestartet werden und der Counter-Strike-Server installiert werden:

./steamcmd.sh
login anonymous
force_install_dir /home/counterstrike/game/
app_update "90 -beta Beta" validate

Beim app_update kann es bei der Installation zu folgender Fehlermeldung kommen:

Error! App '90' state is 0x6 after update job.

Zur Lösung des Problems muss der Befehl:

app_update "90 -beta Beta" validate

so oft ausgeführt werden, bis der Vorgang schlussendlich erfolgreich beendet wird. Anschließend kann der Steam-Client mit dem Kommando exit beendet werden. Bevor man den Server startet, sollte man die server.cfg-Datei den Umständen entsprechend anpassen. Diese befindet sich im Ordner /home/counterstrike/game/cstrike/. Fertig konfiguriert könnte diese so aussehen:

// Use this file to configure your DEDICATED server. 
// This config file is executed on server start.

// server password
sv_password "geheim"
rcon_password "geheim"

// disable autoaim
sv_aim 0

// disable clients' ability to pause the server
pausable 0

// default server name. Change to "Bob's Server", etc.
hostname "Mein erster CS-Server"

// maximum client movement speed 
sv_maxspeed 320

// 20 minute timelimit
mp_timelimit 20

sv_cheats 0

// load ban files
// exec listip.cfg
// exec banned.cfg

Wenn man beim Start des Servers mittels:

./hlds_run -game cstrike +map de_dust2

folgende Ausgabe erhält:

dlopen failed trying to load:
/home/counterstrike/.steam/sdk32/steamclient.so
with error:
/home/counterstrike/.steam/sdk32/steamclient.so: cannot open shared object file: No such file or directory

muss ein symbolischer Link erstellt werden, welcher auf den linux32-Ordner der Steam-Installation zeigt:

cd
mkdir .steam
ln -s /home/counterstrike/steam/linux32 /home/counterstrike/.steam/sdk32

Anschließend kann der Server wieder gestartet werden. Alternativ kann der Server natürlich auch in einer screen-Umgebung gestartet werden, so das dieser im Hintergrund läuft.

Beim Update einer MediaWiki-Installation auf die Version 1.28.1 über das update.php-Skript erhielt ich folgende Fehlermeldung:

Error: your composer.lock file is not up to date. Run "composer update" to install newer dependencies

Hintergrund sind unerfüllte Abhängigkeiten, welche wohl nur für die Entwicklung benötigt werden. Um das Update trotzdem durchzuführen sollte folgendes Kommando im Terminal genutzt werden:

php ./update.php --skip-external-dependencies

Damit wird die Prüfung der externen Abhängigkeiten deaktiviert und die Aktualisierung kann erfolgreich durchgeführt werden.

Wenn man die LibreOffice-Version für macOS herunterlädt, so wird man feststellen, das diese zweigeteilt ist. Sie besteht aus dem LibreOffice-Paket, sowie dem Language Pack mit welchem die deutsche Lokalisierung installiert wird.

LibreOffice unter macOS

Wird LibreOffice nun installiert und anschließend das Sprachpaket installiert, so wird man feststellen das LibreOffice nicht startet, da es von macOS als defekt bemängelt wird. Trick 17 – die temporäre Abschaltung des Gatekeeper – funktioniert in neueren macOS Versionen nicht mehr ohne weiteres. Stattdessen muss bei der Installation anders vorgegangen werden. Im ersten Schritt muss das LibreOffice-Paket installiert und gestartet werden. Wenn dies erfolgreich geglückt ist, wird im zweiten Schritt das Sprachpaket installiert. Anschließend läuft das Gesamtpaket ohne Probleme.

Die freie Weltkarte OpenStreetMap ist über die Jahre immer größer, detailreicher und besser geworden. Wo Licht ist, ist allerdings auch Schatten zu finden. Beim OpenStreetMap sind dies – neben Edit-Wars und vielen (durchaus produktiven) Diskussionen – unbedachte Bearbeitungen, welche zu seltsamen Ergebnissen führen.

worstofosm.tumblr.com

worstofosm.tumblr.com

Eine Liste solcher Fehlschläge ist im Tumblr-Blog Worst of OSM zu finden. Von winzigen Häusern, interessant getaggten Imbissgelegenheiten bis zum Mißbrauch des freien Tag-Schemas ist dabei alles zu finden – damit findet der geneigte OpenStreetMap-Mapper seine tägliche Portion Grusel.

Wenn man längere Zeit mit Git arbeitet, wird einem die eine oder andere seltenere Fehlermeldung über den Weg laufen. Eine dieser Fehlermeldungen ist:

fatal: multiple stage entries for merged file 'DBAdapter.cs'

Hintergrund bei diesem Problem ist das der Index, welcher die Änderungen und Dateien enthält mit welchem der nächste Commit erstellt wird, für eine Datei mehrere Einträge vorhält; was per Definition nicht der Fall sein sollte. Der Workaround für diese Problem besteht darin, den Index (bzw. die sogenannte Staging area) zu löschen, die Dateien erneut hinzuzufügen und das ganze mit einem Commit in Stein gießen:

rm .git/index
git add -A
git commit -a

Anschließend kann das Git-Repository wieder ohne Probleme genutzt werden.

Vor einigen Tagen begegneten mir einige Dateien, deren Inhalts größtenteils aus der Zeichenfolge EF BF BD EF BF BD EF BF BD (hexadizimal) bestand. Eigentlich sollte in den entsprechenden Dateien binäre Daten enthalten sein. Damit stellte sich nun die Frage: Was war passiert?

EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD

Auf den ersten Blick sah das ganze so aus, als ob ein Großteil der Datei durch Datenmüll ersetzt wurde. Schaut man sich die Zeichenfolge allerdings genauer an, so wird man feststellen das sich die Folge EF BF BD immer und immer wieder wiederholt. Bei dieser Zeichenfolge handelt es sich um die hexadezimale Schreibweise des Unicode-Zeichens für den Replacement Character welcher meist durch eine Raute mit einem Fragezeichen (�) dargestellt wird.

Eindeutiger wäre das Problem gewesen, wenn die erzeugten Dateien mit der Zeichenfolge EF BB BF begonnen hätte. Dabei handelt es sich um das Byte Order Mark für eine UTF-8 kodierte Datei. Damit wäre gleich klar geworden, das die enthaltenen Daten nicht zu einer Datei mit binären Inhalten passen. Doch wie sind diese Dateien nun entstanden? Der Ursprung der Dateien ist in einer Java-Applikation zu finden, welche diese Dateien erstellt. Diese kopierte die Daten von A nach B, im Quelltext (man ignoriere das fehlende try with resources) könnte das so ausgesehen haben:

FileInputStream fileInputStream  = new FileInputStream("binary.dat");
FileWriter fileWriter = new FileWriter("binary-copied.dat");

int byteData;

while ((byteData = fileInputStream.read()) != -1) {
    fileWriter.write(byteData);
}

fileInputStream.close();
fileWriter.close();

Hier wird ein FileInputStream geöffnet und dieser Stück für Stück mit einem FileWriter in die Zieldatei geschrieben. Genau an dieser Stelle entsteht das Problem – der FileWriter ist nämlich ein zeichenbasierter Writer, das bedeutet das sämtliche Zeichen, die mit diesem geschrieben werden, kodiert werden. Wenn nun bei dieser Kodierung ein Zeichen gefunden wird, welches nicht im Unicode abgebildet werden kann, so erhält dieses Zeichen den Wert EF BF BD – besagter Replacement Character. Damit ist dann auch erklärt warum die binären Dateien hauptsächlich nur noch aus diesen Zeichen bestanden. Die echten Daten wurden beim Kopiervorgang größtenteils schlicht und ergreifend in den Replacement Character konvertiert, da sich für diese Daten keine Entsprechung im Unicode fand.

Wenn man Dateien mit dem Midnight Commander von A nach B kopiert kann es passieren das man mit der Fehlermeldung:

Cannot chown target directory

konfrontiert wird. Das Problem ist das beim Kopieren die Attribute der Dateien ebenfalls übernommen werden. Dazu kopiert der Midnight Commander die Datei zum Zielort und versucht anschließend die Attribute anzupassen. Hierbei kann es passieren, das das Ziel die Anpassung der Attribute nicht unterstützt – dies führt zu besagtem Fehler.

Der Midnight Commander beim kopieren

Der Midnight Commander beim kopieren

Umgehen lässt sich der Fehler in dem im Kopierdialog der Punkt Attribute sichern deaktiviert wird. Damit werden die Dateien nur noch kopiert; eine Attributänderung findet nicht mehr statt.

Unter Umständen kann es unter Ubuntu, oder anderen Distributionen basierend auf Debian passieren, das ein apt-get Vorgang fehlschlägt. Dies kann sich darin äußern das apt-get nicht mehr genutzt werden kann – stattdessen bekommt man folgende Meldung zu sehen:

E: Could not get lock /var/lib/dpkg/lock - open (11 Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/) is another process using it?

Hintergrund ist das dpkg Sperrdateien mit dem Name lock anlegt und sie nach getaner Arbeit wieder entfernt. Bei plötzlichen Unterbrechungen wie z.B. einem Stromausfall kann es passieren das die Dateien nicht mehr entfernt werden. Lösen kann man das Problem indem man die entsprechenden Sperrdateien entfernt:

rm /var/lib/dpkg/lock
rm /var/lib/apt/lists/lock
rm /var/cache/apt/archives/lock

Abschließend sollte dpkg bzw. apt-get wieder ohne Probleme funktionieren.

Vor einigen Tagen migrierte ich einen Minecraft-Server von einem Server mit Ubuntu 14.04 LTS auf einen Server mit Ubuntu 16.04 LTS. Der Minecraft-Server lief dabei auf dem alten als auch auf dem neuen Server jeweils in einer KVM-Gast-Maschine. Er startete ohne Probleme und wenn man sich das ganze von außen mit nmap anschaute, war der entsprechende Port auch offen gekennzeichnet. Allerdings konnte der Minecraft-Client keinerlei Verbindung mit dem Server aufnehmen. Lösen ließ sich das Problem mit der Änderung einer Einstellung in der server.properties Datei. Konkret ging es dabei um die Einstellung:

use-native-transport = true

welche auf false gesetzt werden musste. Mit diesem Flag wird das optimierte Senden und Empfangen von Paketen unter Linux deaktiviert. Damit funktionierte der Minecraft-Server wieder ohne Probleme.

Wenn man ein CentOS 7 in der Minimal-Installation installiert (und dabei nicht aufpasst), wird man nach der Installation feststellen das man über keine Konnektivität verfügt. Das ist bedingt dadurch das die entsprechende Netzwerkschnittstelle beim Booten nicht konfiguriert wird. Um die Schnittstelle zu konfigurieren, sollte im ersten Schritt in den entsprechenden Ordner gewechselt werden:

cd /etc/sysconfig/network-scripts/

In diesem Ordner befindet sich eine Datei ifcfg-eth0 (alternativ sind auch andere Schnittstellennamen wie ifcfg-enp0s3, em1 und ähnliche möglich). Die entsprechende Datei wird nun mittels vi geöffnet:

vi ifcfg-eth0

In dieser Datei gibt es eine Option mit dem Namen ONBOOT, deren Wert standardmäßig auf no gestellt ist. Dieser Wert muss in yes geändert werden und anschließend die Datei gespeichert werden (:w zum Speichern der Datei, :q um VIM zu schließen). Nach einem anschließenden Neustart, sollte die Netzwerkschnittstelle konfiguriert und funktionsfähig sein.