Dann das Raid zusammenbauen:

1

mdadm --assemble --scan --verbose

Dann RAID device raussuchen, bei mir war es md3:

1

cat /proc/mdstat

Temporäres Verzeichnis anlegen

1

mkdir /mnt/nvme_recover

Und einen mount versuchen:

1

mount /dev/md3 /mnt/nvme_recover

Wenn dort die folgende Meldung zurückkommt:

1

mount: /mnt/nvme_recover: unknown filesystem type 'LVM2_member'.

So hatte man damals eine Volume Group darüber gelegt (damals hattest du dann pvcreate /dev/md3 ausgeführt), dies kann man sich so ansehen:

1

vgdisplay

Und sieht dann in etwa so aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

  --- Volume group ---
  VG Name               vg1
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               889.75 GiB
  PE Size               4.00 MiB
  Total PE              227775
  Alloc PE / Size       227587 / 889.01 GiB
  Free  PE / Size       188 / 752.00 MiB
  [...]

  --- Volume group ---
  VG Name               vg1000
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               3.63 TiB
  PE Size               4.00 MiB
  Total PE              952682
  Alloc PE / Size       952682 / 3.63 TiB
  Free  PE / Size       0 / 0
  [...]

Dazu kann man sich die logical volumes angucken:

1

lvdisplay -v vg1

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

    Using volume group(s) on command line.
  --- Volume group ---
  VG Name               vg1
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               889.75 GiB
  PE Size               4.00 MiB
  Total PE              227775
  Alloc PE / Size       227587 / 889.01 GiB
  Free  PE / Size       188 / 752.00 MiB
  VG UUID               [...]

  --- Logical volume ---
  LV Path                /dev/vg1/syno_vg_reserved_area
  LV Name                syno_vg_reserved_area
  VG Name                vg1
  LV UUID                [...]
  LV Write Access        read/write
  LV Creation host, time ,
  LV Status              NOT available
  LV Size                12.00 MiB
  Current LE             3
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto

  --- Logical volume ---
  LV Path                /dev/vg1/volume_2
  LV Name                volume_2
  VG Name                vg1
  LV UUID                [...]
  LV Write Access        read/write
  LV Creation host, time ,
  LV Status              NOT available
  LV Size                889.00 GiB
  Current LE             227584
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto

  --- Physical volumes ---
  PV Name               /dev/md3
  PV UUID               [...]
  PV Status             allocatable
  Total PE / Free PE    227775 / 188

Nun sieht man unter “LV Status” schon ein “NOT available”. Dieses muss man ändern:

1

vgchange -ay vg1

was in 2 logical volume(s) in volume group "vg1" now active resultiert. Nun kann man via

1

mount /dev/vg1/volume_2 /mnt/nvme_recover

Wieder das Volume mounten und darauf zugreifen.

Bisher habe ich noch nicht rausgefunden, wie man manuelle Treiber in das Image injiziert. Bis ich das rausgefunden habe, bleibt es beim Betrieb via USB-Stick oder USB-Card Reader.

So einfach gehts:

1

amixer sset PCM,0 100%

Wobei 100% für die absolute Lautstärke steht.

Hierzu habe ich verschiedene Möglichkeiten genutzt.

Möchte man die Datei einfach nur leeren, so genügt:

1

:> logfile.log

Sollen hingegen die letzten 5 Zeilen behalten werden, so nutzt man am besten eine Zwischendatei:

1

tail -n 5 logfile.log > logfile.log.tmp && mv logfile.log.tmp logfile.log

Oder alternativ (ohne Zwischendatei, geht aber nicht immer):

1

echo "$(tail -5 logfile.log)" > logfile.log

Natürlich kann man nun alle möglichen Workarounds durchführen um den Unifi Controller hinzubiegen (aber bitte bitte niemals unter root starten!), ich habs easy auf meinem Ubuntu 18.04 LTS gelöst:

1
2

sudo iptables -t nat -I PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8443
sudo apt install iptables-persistent

Was machen diesen Kommandos? Zuerst wird eine Regel in den lokalen iptables, d.h. der “firewall” von Linux definiert um den Port 443 auf Port 8443 umzuleiten. Danach wird das Paket iptables-persistent installiert, was diese Regel auch nach einem Reboot wiederherstellt.

Damit ist der Controller dann unter 8443 und 443 verfügbar und das funktioniert problemlos … ;)

Der Aufruf lautet:

1

"C:\Program Files (x86)\VideoLAN\VLC\vlc.exe" --audio-filter=param_eq --param-eq-f1=233 --param-eq-f2=466 --param-eq-f3=932 --param-eq-gain1=-20 --param-eq-gain2=-20 --param-eq-gain3=-20 --param-eq-lowf=100 --param-eq-lowgain=15 --param-eq-q1=10 --param-eq-q2=10 --param-eq-q3=10 "rtp://@239.35.10.2:10000"

Download der BAT-Datei: vuvuzelastop_vlc_HD.zip Um das ZDF HD ohne Vuvuzela zu sehen. für die normale Auflösung lautet er:

1

"C:\Program Files (x86)\VideoLAN\VLC\vlc.exe" --audio-filter=param_eq --param-eq-f1=233 --param-eq-f2=466 --param-eq-f3=932 --param-eq-gain1=-20 --param-eq-gain2=-20 --param-eq-gain3=-20 --param-eq-lowf=100 --param-eq-lowgain=15 --param-eq-q1=10 --param-eq-q2=10 --param-eq-q3=10 "rtp://@1:10000

Download der BAT-Datei: vuvuzelastop_vlc_SD.zip

Ansonsten gibts noch die Möglichkeit, den Rechner nur als Durchgangstation zu nutzen. Dann werden die Vuvuzelas per Filter in VSTHost und Electri-Q ausgeblendet: PDF-File & Equalizer-File zum Download

Quelle 

Mein letztes Problem mit Gentoo war eine neue Netzwerkkarte, nachdem die alte ein paar Macken aufwies. Die alte Onboard-Netzwerkkarte wurde entfernt und stattdessen eine “Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 0c)” als PCI-Steckkarte installiert. Natürlich musste der Kernel neu gebaut werden, die Optionen “CONFIG_EEPRO100=y” und “CONFIG_E100=y” wurden so fest in den Kernel einkompiliert.

Nach einem Reboot meldete das Syslog jedoch folgende Fehlermeldung:

1
2
3

rc-scripts: network interface eth0 does not exist
rc-scripts: Please verify hardware or kernel module (driver)
rc-scripts: ERROR: cannot start sshd as net.eth0 could not start

was mich ein wenig erstaunte, denn dmesg meldete:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin  and others
ACPI: PCI Interrupt 0000:00:08.0[A] -> GSI 16 (level, low) -> IRQ 16
eth0: OEM i82557/i82558 10/100 Ethernet, 00:03:47:B0:ED:D3, IRQ 16.
Board assembly a29355-003, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0x3258698e).
e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation

Diese Meldungen kommen sowohl, wenn ich mir die IP über DHCP zuweisen lassen würde (in /etc/conf.d/net eingestellt) oder fest eintrage. Ich konnte jedoch ohne Probleme mit dieser Netzwerkkarte ein Rescue-System booten und darin arbeiten, was meine Erklärung dafür war, dass warum meines Erachtens die neue Karte nicht kaputt sein konnte

Ich habe die Karte natürlich über “rc-update add net.eth0 default” zum Starten angewiesen, der Link ist auch korrekt erstellt (und hat mit der alten Karte funktioniert).

Letztendlich wusste ich nicht mehr weiter und meldete mein Problem im offiziellen Gentoo-Forum, wo mir innerhalb von wenigen Minuten geholfen werden konnte. Das Problem hätte mir auffallen müssen, als folgende Einträge im Log aufgetaucht sind:

1
2

udevd-event[5100]: run_program: exec of program '/sbin/udev_run_hotplugd' failed
udevd-event[5101]: run_program: exec of program '/sbin/udev_run_devd' failed

Das Problem war relativ einfach in den Griff zu bekommen ( Quelle ):

In der Datei /etc/udev/rules.d/70-persistent-net.rules stand bei mir folgendes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.

# PCI device 0x1106:0x3065 (via-rhine)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0c:6e:92:02:aa", NAME="eth0"

# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:03:47:b0:ed:d3", NAME="eth1"

Man beachte hierbei: VIA Rhine war meine vorherige Netzwerkkarte, die e100 meine neue. Die neue Karte wurde von udev einfach als eth1 eingetragen und war daher auch nicht unter eth0 erkannt worden. Ich habe nun schlicht und einfach die alte rausgeworfen, bei e100 auch eth0 eingetragen und schon war das Problem behoben.

1
2

# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:03:47:b0:ed:d3", NAME="eth0"

Vielen Dank ans Gentoo-Forum  für den schnellen Support, vielleicht hilft dieser Post dem einen oder anderen verzweifelten Gentoo-Besitzer

Einen neuen Screen erstellt man mit:

1

screen -R name

wobei der name freiwillig ist. Nun können wir beliebige Befehle eingeben und dann mit CTRL+a d detachen und befinden uns wieder im ursprünglichen Terminal. Wollen wir wieder zurück in den screen, geben wir den obigen screen-Befehl nochmals ein. Wir können uns auch von mehreren Terminals (z.B. auch über ssh) gleichzeitig auf einen screen verbinden, und zwar mit dem Aufruf:

1

screen -x name

Sind wir im screen drinn, kann man mit CTRL+a c weitere Fenster erstellen. Mit CTRL+a " bekommt man ein Menü aller Fenster, und mit CTRL+a Space bzw. CTRL+a Backspace kann man zwischen den Fenstern wechseln.

Eine interessante Fähigkeit von screen ist auch, mehrere Fenster untereinander zu haben. Mit CTRL+a S splitten wir das aktuelle Fenster, wechseln ins neue Fenster mit CTRL+a Tabulator und können dort das neue Fenster mit z.B. CTRL+a " auswählen. Um nur noch das aktive Fenster zu sehen, drücken wir CTRL+a Q.

screen beherrscht auch Copy&Paste. Mit CTRL+a Escape oder CTRL+a [ wechseln wir in den Markierungs- und zugleich Scrollmodus. Mit den Pfeiltasten wählen wir den ersten Punkt der Markierung aus, drücken dann Space und wählen den letzten Punkt der Markierung aus und drücken schliesslich nochmal Space, damit der Text kopiert wird. Einfügen können wir mit CTRL+a ].

Verrückter gehts kaum noch ;)

Quelle: www.eggdrop.ch 

time wird einfach nur einer normalen Programmausführung vorgeschalten:

1

time wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.16.tar.bz2

und gibt dann einen output aus. Ich habe mal einen Kernel gebaut, was dann hier folgendes ergeben hat:

1
2
3

real 13m1.974s
user 9m9.226s
sys 1m24.309s

Im endeffekt hats also 13 Minuten und 1,9 sekunden gedauert.

Über “man time” bekommt man auch noch mehr Hilfe zu time, auch andere Formatierungen usw :)

Gruß Uli

• Debian 3.1
• Kernel 2.6
• AMD 3000+ (Kein 64-Bit, Kein Dual-Core)

Zunächst müssen ein paar Packete geholt werden, damit der Kernel überhaupt kompiliert werden kann.

1

apt-get install bzip2 libncurses5-dev kernel-package module-init-tools binutils

Es gibt ein paar vorbestimmte Dinge beim Kernelbauen, eins davon ist, dass alles in /usr/src/ stattfindet, wo wir nun erstmal hinwechseln:

1

cd /usr/src/

Anschließend brauchen wir einen aktuellen Kernel. Diesen bekommt man, wenn man auf Kernel.org  geht und dort in der obersten Zeile (“The latest stable version of the Linux kernel is:”) den link des Buchstaben “F” (Full Source) kopiert. Momentan ist Kernel 2.6.16.16 aktuell:

1

wget http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.16.tar.bz2

Anmerkung: Besser ist es hier  den Kernel rauszusuchen und herunterzuladen, der Speed ist deutlich besser. Dieser muss nun entpackt werden:

1

tar xvfj linux-2.6.16.16.tar.bz2

Je nach dem ob man schon mal einen Kernel gebaut hat befindet sich nun ein Symbolischer Link auf die Kernelquellen namens “linux” im Verzeichnis, welcher zunächst entfernt werden muss:

1

rm linux

Nun muss der aktuelle Link gelegt werden:

1

ln -s linux-2.6.16.16 linux

Damit sind zunächst die Vorarbeiten abgeschlossen.

Nachdem wir bereits im ersten Teil des Tutorials alle Vorarbeiten zum Kernelbau geleistet haben, können wir ihn nun konfigurieren und kompilieren. Wir wechseln in das Kernel-Verzeichnis:

1

cd /usr/src/linux/

Und räumen dort erst mal auf (Mr Proper ;) ) (Dies sollte auch gemacht werden, wenn man bereits kompiliert hatte und man den Vorgang auf sauberer Basis nochmals durchführen möchte)

1

make mrproper

Jetzt kommt ein wichtiger Schritt, das Einfügen der alten Kernel-Config in das Verzeichnis. Damit wir nicht alle Optionen für einen neuen Kernel nochmals manuell setzen müssen, können wir die alte Config verwenden. Diese findet man normalerweise unter /boot/ Bei mir heisst der Befehl dann:

1

cp /boot/config-2.6.15 .config

Nun startet man das Configurationsprogramm für den Kernel(wobei die alte Config berücksichtigt wird):

1

make menuconfig

Meine persönliche Erfahrung: So wenig wie nötig in den Kernel einbauen, jedoch so viel wie nötig. SCSI braucht man nicht einkompilieren, wenn man kein SCSI nutzt. Auch nicht als Modul. ACHTUNG SATA = SCSI, wer also S-ATA Festplatten hat, muss SCSI einschalten.Ich habe bei mir alles, was ich brauchte, fest einkompiliert, und Module abgeschalten.

Wenn alle Einstellungen getroffen sind, dann gibt man nicht den Vorschlag den der Kernel macht, ein, sondern den folgenden Befehl:

1

make-kpkg kernel_image --revision uli.0

Wobei das letzte “uli.0” nur zur unterscheidung zwischen verschiedenen Kernel-Versionen dient. Das wird später dem Debian-Paket angefügt und man hat dann den besseren Ãœberblick über verschiedene Kompilierungsversuche. Je nachdem wie schnell der Rechner ist, kann das eine Weile dauern. Bei mir dauerts auf einem AMD2500+ ca 20 Minuten, auf einem AMD3000+ ca 15 Minuten.

Wenn der Vorgang abgeschlossen ist, dann findet man den neuen Kernel in /usr/src, wohin wir nun wechseln und den Kernel anschließend installieren:

1
2

cd /usr/src/
dpkg -i kernel-image-2.6.16.16_uli.0_i386.deb

Wenn dies erfolgreich verlaufen ist, dann ist nun der Kernel eingebaut. Nach einem Reboot ist der Kernel dann auch aktiv, was man mit:

1

uname -r

überprüfen kann.

Normalerweise wird der Bootloader auch direkt konfiguriert, sodass man rein theoretisch nichts mehr machen müssen, sofern man direkten Rechnerzugang hat. Denn wenn der Rechner nicht hochkommen sollte, kann man ja bei physikalischen Zugriff den alten Kernel im Bootloader wieder auswählen. Wenn man jedoch so wie ich nur Serverkernel austauscht, sollte man ein paar arbeiten am Bootloader mehr vornehmen, was im dritten Teil des Tutorials erklärt wird.

Nachdem wir nun in den beiden ersten Teilen den Kernel kompiliert haben, führen wir nun einige Änderungen am Bootloader durch.

Normalerweise wird der Bootloader auch direkt konfiguriert, sodass man rein theoretisch nichts mehr machen müssen, sofern man direkten Rechnerzugang hat. Denn wenn der Rechner nicht hochkommen sollte, kann man ja bei physikalischen Zugriff den alten Kernel im Bootloader wieder auswählen.

Da ich aber ausschließlich mit Servern zu tun habe, sollte der folgende Vorgang durchgeführt werden, um ein “nicht-hochkommen” der Servers zu verhindern bzw ohne Rescue-System wieder zum laufen zu bekommen. Ich gehe dabei ausschließlich auf den Boot-Loader LILO ein! Zunächst wird die Konfiguration des Bootloaders editiert:

1

nano /etc/lilo.conf

Darin findet man die Konfigurationen die LILO benötigt, in meinem Fall sieht dies so aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

lba32
boot=/dev/sda
root=/dev/sda2
install=/boot/boot-menu.b
map=/boot/map
delay=5
vga=normal
append="noapic acpi=off"
default=Linux

image=/vmlinuz
 label=Linux
 read-only

image=/vmlinuz.old
 label=LinuxOLD
 read-only
 optional

Hierbei ist das schon die neue Konfiguration wie sie von Debian nach der Kernelinstallation geschrieben wurde. “Linux” ist hierbei Kernel 2.6.16.16 und “LinuxOLD” der alte, aber sicher funktionstüchtige Kernel. Nun ändert man die folgende Zeile:

1

default=Linux

in die Version des alten Kernels:

1

default=LinuxOLD

und speichert. Nun muss man noch einmal:

1

lilo

eingeben um dann folgendes zu sehen:

1
2
3

server:~# lilo
Added Linux
Added LinuxOLD *

Der Eintrag wo nun das Sternchen ist, ist hierbei dann der Default-Boot-Kernel. Nun fragen sie sich sicher schon, warum ich einen neuen Kernel baue und dann aber doch den alten booten möchte. Der Trick kommt nun:

1

lilo -R (NEUERKERNELEINTRAG)

wobei (NEUERKERNELEINTRAG) durch das Label, das verwendet wurde (hier: “label=Linux”, also “Linux”) ersetzt werden muss (also in diesem Fall: “lilo -R Linux”) Nun wird NUR beim nächsten Neustart der neue Kernel gebootet. Sollte dieser Boot fehlschlagen(server kommt nach Wartezeit nicht online), so kann mit einem Remote-Reset der Server neu gebootet werden, woraufhin dieser in den alten Kernel bootet. Wenn dies eintritt, so sollte der Fehler zunächst in der Network-Konfiguration gesucht werden(Aktivert mit dem korrekten Treiber?). Sollte der Start erfolgreich verlaufen sein, so muss nun die LILO-Config zurückgeändert werden, die Zeile “default=Linux” sollte wieder statt “default=LinuxOLD” eingesetzt werden. Nun nicht vergessen wieder “lilo” in der Kommandozeile einzugeben um dem Bootloader die neue Config bekannt zu geben. Die Ausgabe sollte dann wieder so aussehen:

1
2
3

server:~# lilo
Added Linux *
Added LinuxOLD

Gratulation, der Server-Kernel ist nun auf dem neuesten Stand!

Mit der folgenden Zeile:

1

du . -h --max-depth=1|sort -h

kann man sich im aktuellen Verzeichnis die erste Ebene inklusive des verbrauchten Speicherplatzes ausgeben lassen, wobei die Größe der jeweiligen Unterordner berücksichtigt wird.

Notiz: Das Flag -h gibt es bei sort erst ab GNU coreutils 7.5 (Release war im August 2009) und erlaubt einen Vergleich menschenlesbaren Größen (wie 2K oder 1G).

Meine bisherige Lösung funktioniert nur manchmal, aber liste ich mal der Vollständgkeit halber mit auf:

1

find . -maxdepth 1 -type d -print | xargs du -sk | sort -rn

Wenn man nun auf der Suche nach Verbrauchern von Speicherplatz ist, lohnt es sich oft auch, sich das in einer einfachen Oberfläche mit der Möglichkeit von Löschen etc. anzusehen. Hierfür nutze ich das Tool “ gdu ”, welches das wunderbar erlaubt.

Nach der Installation  habe ich zunächst konfiguriert, dass ich Löschen parallel im Hintergrund machen möchte. Dazu schreibe ich die Config in mein gdu config file wodurch diese auch für das nächste Mal direkt vorhanden ist:

1
2
3

mkdir -p $HOME/.config/gdu/
echo "delete-in-background: true" >> $HOME/.config/gdu/gdu.yaml
echo "delete-in-parallel: true" >> $HOME/.config/gdu/gdu.yaml

Anschließend rufe ich das tool auf (z.b. via /usr/bin/gdu) und sortiere nach Größe (s). Nun kann ich mittels der Pfeiltasten durch die verzeichnisse navigieren und via d einzelne Verzeichnisse oder Dateien löschen. Da dies dann im Hintergrund passiert kann ich direkt weitersehen, jedoch sollte man das tool erst beenden, wenn am unteren Bildschirmrand dann alle Prozesse abgearbeitet sind.

HLstats besteht aus einem Perl Script (die HLstats logging Daemon) und aus einem Set von PHP Scripts (welche die gewonnenen Daten als Webseite anzeigen). HLstats bietet Statistiken für den einzelnen Spieler sowie auch für den ganzen Clan.

Meine Ausgangslage

• “Blanker” Server (Keinerlei MySQL oder Apache2)
• Debian 3.1 Sarge Stable
• HLStats 1.34 

Folgende Packete werden zunächst in der Konsole installiert:

1

apt-get install apache2 libapache2-mod-php4 wget libdbi-perl libdbd-mysql-perl libdbd-mysql mysql-server mysql-common ncftp lynx php4-mysql

Nachdem das alles installiert ist, muss man Perl konfigurieren:

1

perl -MCPAN -e shell

Nun werden ein Haufen Fragen gestellt, eigentlich ist aber davon nur die Frage nach den Downloadservern am Ende wirklich wichtig. Am Ende öffnet sich ein CPAN-Prompt in dem man nun noch die Module initialisieren sollte:

1
2

cpan> install Bundle::DBI
cpan> install Bundle::DBD::mysql

Perl ist nun soweit fertig.

Nun brauchen wir zunächst HLStats. Ich installiere den Perl-Server von HLStats in /home/hlstats/, weshalb ich nun dort zunächst die Files entpacke(Ich sauge immer von Switch, die URL ist natürlich gegen andere Mirrors austauschbar ;)):

1
2
3
4
5
6

wget http://switch.dl.sourceforge.net/sourceforge/hlstats/hlstats-1.34.tar.gz
cd /home/
tar xzvf hlstats-1.34.tar.gz
mv hlstats-1.34 hlstats
rm hlstats-1.34.tar.gz
cd hlstats

HLStats loggt über einen Perl-Server, der normalerweise auf Port 27500 “lauscht”, in eine normale MySQL-Datenbank, was die nebenstehende Server-Struktur ermöglicht. Viele einzelne Gameserver können so auf einen einzigen MySQL-Server(dieser wäre über eine Datenbank-Replikation auch wieder einfach zu sichern) loggen, wodurch die Statistiken dann einfach über eine Seite abrufbar sind. Das Frontend ist wiederum in PHP mit einzelnen Templates geschrieben, was eine Anpassung nicht besonders schwer macht.

Nun muss HLStats noch in die MySQL-Datenbank eingefügt werden:

1
2
3

mysql admin create hlstats
mysql hlstats < hlstats.sql
mysql hlstats < gamesupport_XXYYXX.sql

Dies kann nur im Verzeichnis des entpackten Archives ausgeführt werden.

XXYYXX muss hierbei durch das Spiel, welches man benötigt ersetzt werden, also z.b.:

1

mysql hlstats < gamesupport_css.sql

Weitere Support-Files bekommen sie hier. (Hinweis: HLstats unterstuetzt nur Spiele mit dem Half-Life Log Format.)

Nachdem die Spieldaten und die Haupt-SQL-Files in der Datenbank gelandet sind, müssen wir nun noch die User anlegen, die auf diese Datenbank zugreifen dürfen

1

shell> mysql --user=root mysql

1

GRANT ALL PRIVILEGES ON hlstats.* TO 'hlstats'@'localhost' IDENTIFIED BY 'somepassword'

Das erste HLStats ist der Databasename und das zweite HLStats ist der Benutzername der erstellt wird. (Hinweis: ‘somepassword’ sollte natürlich durch ein anderes ersetzt werden, also z.b. ‘Mju5mkfOP5QCVlgY’)

Zur Absicherung des RooT-Users müssen wir dessen Passwort ändern(wird von MySQL übrigends als eine der ersten Aktionen empfohlen ). In der MySQL-Console muss daher folgendes eingegeben werden:

1
2
3

UPDATE user SET Password=PASSWORD('someotherpassword') WHERE user='root';
FLUSH PRIVILEGES;
quit;

(Hinweis: ‘someotherpassword’ sollte natürlich auch hier durch ein anderes ersetzt werden, also z.b. ‘5QCVlgYMju5mkfOP’)

Der folgende Abschnitt wurde in der Dokumentation als Kompatibilitäts-Sache angegeben, damit Perl korrekt mit dem Frontend arbeitet:

1

shell> mysql --user=root -p mysql

Nun werden sie nach dem oben vergebenen root-Passwort gefragt. Nach Eingabe dieses Passworts fügen sie die folgende Zeile ein. Hierbei muss ‘/hlstats/hlstats.php’ durch das Verzeichnis (relativ zum Webroot) ersetzt werden, in dem sich “hlstats.php” befindet. Wenn HLStats sich im ‘/stats’-Ordner befindet, muss man ‘/stats/hlstats/hlstats.php’ verwenden. Wenn sie hlstats über “ http://example.com/hlstats/hlstats.php"  erreichen, dann ist die folgende Angabe richtig.

1
2

INSERT INTO hlstats_Options (keyname, value) VALUES ('scripturl','/hlstats/hlstats.php');
quit

Nun ist die Datenbankseitige Installation soweit fertig. Wenden wir uns der Installation des Webfrontends zu. Ich gehe davon aus, dass auf dem Server nichts anderes ausser HLStats und die Gameserver laufen, daher ist bei mir das Webserver-Root-Verzeichnis (/var/www/) gleich dem hlstatsverzeichnis:

1
2
3

cd /home/hlstats/
mv hlstats.php /var/www/
mv hlstatsimg /var/www/

Nun gibts natürlich wie immer ein kleines Rechte-Problem, welches sind einfach lösen lässt:

1

useradd -s /bin/bash -p PASSWORD hlstats

PASSWORD muss natürlich wieder ersetzt werden! nun noch ein:

1
2
3

chown -R hlstats:users /home/hlstats/
chown -R hlstats:users /var/www/hlstats.php
chown -R hlstats:users /home/hlstatsinc/

und die Verzeichnisse gehören dem Nutzer.

Der Webserver leitet momentan beim Aufruf der IP noch direkt auf “apache2-default” weiter, was wir natürlich nicht wollen. Also müssen wir die Konfigurationsdatei ändern:

1

nano /etc/apache2/sites-enabled/000-default

Suche: RedirectMatch ^/$ /apache2-default/ Ersetze: # RedirectMatch ^/$ /apache2-default/

Damit ist nun sichergestellt, dass bei Aufruf der IP direkt die Dateien aus /var/www/ aufgerufen werden. Wenn man dies aber nun tut, dann stellt man fest, dass nur das Verzeichnis aufgelistet wird. Problem ist, dass Apache noch nicht weiss, dass er nun die hlstats.php aufrufen soll. Nun gibt es zwei Wege:

1. Umleitung via HTML/PHP-Datei
2. Umleitung via .htaccess

Ich habe mich für den ersten Weg entschieden und eine index.php erstellt, die folgenden Inhalt hat:

1

<? header("location: hlstats.php");exit(); ?>

Funktioniert perfekt.

Nun muss man die Datenbankverbindungen einrichten. Dazu editiert man die beiden Dateien, die damit überhaupt zu tun haben:

1

nano /home/hlstats/hlstats.conf

• Eintragen von Datenbankdaten
• Eventuelle weitere Änderungen anhand der Kommentare durchführen

1

nano /var/www/hlstats.php

• Eintragen von Datenbankdaten
• INCLUDE_PATH anpassen, in diesem Fall /home/hlstats/hlstatsinc
• Eventuelle weitere Änderungen anhand der Kommentare durchführen

Wenn dies alles erledigt ist, dann steht dem ersten Start des Servers nix mehr im Wege:

1
2
3
4
5

screen -R hlstats
su hlstats
cd /home/hlstats/
chmod 700 -R *
while true; do nohup ./hlstats.pl; sleep 5; done &

Nun sollte der Perl-Server gestartet sein, mit “STRG+ a” & anschließendem Druck von “D” bringen sie den Screen in den Hintergrund.

Sofern sie nix an der Port-Konfiguration geändert haben, sollte nun auf Port 27500 ein HLStats-Server lauschen.

PHP hat zunächst keine Ahnung davon, dass MySQL installiert ist, was wir nun schnell ändern:

1

nano /etc/php4/apache2/php.ini

Finde: ;extension=mysql.so Ersetze: extension=mysql.so Anschließend ein /etc/init.d/apache2 restart und PHP weiss, dass MySQL installiert ist.

Nun rufen wir mal das Webfrontend auf. Nach Eingabe der ServerIP / einer darauf zeigenden Domain sollte sich in etwa das nebenstehende Bild ergeben. (Ich habe schon ein paar Server konfiguriert und schon die Templates ein wenig geändert.) Nun klicken wir in der Mitte unten auf Admin und loggen uns das erste mal ein. Die Daten hierzu sind:

• User: admin
• Passwort: 123456

Sobald sie sich eingeloggt haben, gehen sie auf Admin Users und fügen sie einen neuen Admin hinzu. Löschen sie nun den User “admin” (Erst wenn sie den neuen Admin hinzugefügt haben!) und loggen sie sich mit ihrem neuen Admin ein.

Nun können sie nach belieben konfigurieren, neue Server fügt man unter Game Settings unter dem jeweiligen Spiel hinzu, was relativ intuitiv gemacht ist.

Auf den Gameservern muss man in der autoexec.cfg folgendes hinzufügen:

1
2

log on
logaddress 1.2.3.4 27500

wobei 1.2.3.4 für ihre Serveradresse steht. Anschließend den Gameserver restarten und mal drauf zocken. Wenn die Stats angezeigt werden ist alles korrekt gelaufen.

Da aber beides meines Erachtens nicht zutreffen sollte, machte ich mich also auf die Suche und traf in den error-Logs des Apache2-Webservers auf folgenden Fehler:

1

[Mon May 22 10:52:42 2006] [crit] [client 123.123.123.123] (13)Permission denied: /var/www/XXX/html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable

Einige Elemente dieser Fehlermeldung sind von mir gelöscht worden

Wie sich erkennen lässt, “mault” der Apache wegen einer .htaccess, die seines Erachtens nicht lesbar ist. Nun habe ich also eine solche überhaupt nicht in diesem Verzeichnis, was seltsam war. Ich habe dann eine .htaccess angelegt, die einfach mal testweise auf “chmod 777” gesetzt, der Fehler ist jedoch trotzdem nicht verschwunden.

Nach einer intensiven Befragung von Google bin ich schlussendlich darauf gekommen, dass es ein rechte Problem zu sein scheint. Apache hat nur schlicht und einfach keinen Zugriff auf das GANZE verzeichnis gehabt. Nach einem Vergleich mit dem Verzeichnis einer anderen Domain und der anschließenden neuen Rechtevergabe funktionierte wieder alles so, wie es sollte. Es waren wohl aus Versehen falsche Benutzerrechte gesetzt worden.

Ob der Apache auf ein Verzeichnis zugreifen kann, lässt sich sehr schnell und unkompliziert feststellen:

1

su - www-data -s /bin/bash -c "cd /var/www/XXX/html; ls -la"

Wenn der Befehl ein “Permission denied” ausgibt, dann hat der Webserver definitiv keinen Zugriff auf das Verzeichnis. “www-data” ist hierbei der Nutzer des Webservers, und “/var/www/XXX/html” das verzeichnis.

Vielleicht hilfts ja jemandem bei der Fehlersuche :)

Meine Ausgangslage:

• Debian 3.1 Sarge
• PHP4
• Apache2.0
• Commandozeilenzugriff

Die Installation gestaltet sich denkbar einfach, zunächst muss man OpenSSL installieren:

1

apt-get install openssl-dev openssl

Nachdem dies geschehen ist muss man nun die LibSSH2 installieren, für die es kein Debian-Package gibt. Daher muss man zunächst das neueste Packet von Sourceforge  holen und damit folgendes machen(hier am Beispiel der Version 2.0.13):

1
2
3

tar xfvz libssh2-0.13.tar.gz
cd libssh2-0.13
./configure && make all install

Nun ist libSSH2 zur Verwendung bereit. Jetzt kann man via PECL die extension ssh2 installieren. Da es derzeit keine stable Version des ssh2-Packet gibt, muss man die Beta installieren(Zusätzliche Informationen, wie neue Releases, Downloads Quelldateien, Maintainerinformation und ein CHANGELOG finden Sie hier: http://pecl.php.net/package/ssh2 ):

1

pecl install ssh2-beta

Nun sollte PECL sich melden wohin es SSH2 installiert hat (bei mir war es glaube ich /usr/share/php4/, aber das is von Installation zu Installation unterschiedlich). Dieses Verzeichnis sollte man mal besuchen, wenn man sich nicht sicher ist, ob es das in der PHP.ini angegebene “extension_dir”-Verzeichnis ist. Sollte sich darin nur eine ssh2.so finden lassen, so sollten sie mal die php.ini konsultieren(cat /etc/php4/apache2/php.ini | grep extension_dir), evtl liegt das extension_dir woanders. Entsprechen muss natürlich die ssh2.so woanders(also in extension_dir) hinkopiert werden.

Nun öffnet man die php.ini, welche sich bei debian unter /etc/php4/apache2/php.ini finden lässt und fügt folgende Zeile entweder am Ende, oder einer geeigneten anderen stelle hinzu:

1

extension=ssh2.so

Normalerweise sollte sich nun nach einem Restart des Webservers die SSH2-Extension in phpinfo(); finden lassen.

Und fertig ;)

Zend Optimizer ist eine Laufzeitumgebung, die PHP-Anwendungen laut Herstellerangaben um bis zu 40 % beschleunigen kann und des weiteren für die Ausführung von mit Zend Guard geschützten PHP-Dateien benötigt wird. Die Software optimiert den Quelltext vor der Kompilierung durch den PHP-Interpreter und vermindert so die Last des Servers. Der Zend Optimizer ist kostenlos verfügbar und bei den meisten Webhosting-Anbietern vorinstalliert.

Und da ich mein eigener Hoster bin, muss ich das eben selbst machen ;)

Die neueste Version muss man sich bei Zend herunterladen, wofür eine Anmeldung benötigt wird. Der folgende Artikel wurde mit der x86 Version des Zend Optimizers geschrieben, daher sind auch die URL’s und verzeichnisse auf x86 ausgelegt.

1
2
3
4
5

cd /usr/src
wget http://downloads.zend.com/optimizer/3.0.1/ZendOptimizer-3.0.1-linux-glibc21-i386.tar.gz
tar xvzf ZendOptimizer-3.0.1-linux-glibc21-i386.tar.gz
cd ZendOptimizer-3.0.1-linux-glibc21-i386
./install.sh

Nun kommen einige Anweisungen vom script, die man in der Regel mit OK beantworten kann, ausser bei der php.ini-Frage, da sollte man nochmal schauen, ob das so passt. Am Ende sollte der Apache neu gestartet werden.

Das wars erstmal, zum Überprüfen sollte man kurz die php.ini ansehen, bei der irgendwo folgendes stehen sollte:

1
2
3
4
5
6

[Zend]
zend_extension_manager.optimizer=/usr/local/Zend/lib/Optimizer-3.0.1
zend_extension_manager.optimizer_ts=/usr/local/Zend/lib/Optimizer_TS-3.0.1
zend_optimizer.version=3.0.1
zend_extension=/usr/local/Zend/lib/ZendExtensionManager.so
zend_extension_ts=/usr/local/Zend/lib/ZendExtensionManager_TS.so

Zum weiteren Ãœberprüfen sollte man mal die Ausgabe von phpinfo anschauen. Dazu schreibt man in eine PHP-Datei:

1
2
3

<?
phpinfo();
?>

und ruft diese dann auf. Die Ausgabe sollte unter dem ersten großen Kasten dann einen kleinen Kasten mit dem Zend-Logo und dem folgenden Text ausgeben:

This program makes use of the Zend Scripting Language Engine: Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies with Zend Extension Manager v1.0.10, Copyright (c) 2003-2006, by Zend Technologies with Zend Optimizer v3.0.1, Copyright (c) 1998-2006, by Zend Technologies

Das wars :)