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

Über emerge -av mod_bw sollte nun die Version 0.8 installieren. Sobald diese installiert ist, muss man in /etc/conf.d/apache2 den mod_bw noch aktivieren. Dazu wird zu den APACHE2_OPTS einfach " -BW" hinzugefügt. Der mod_bw ist jetzt soweit installiert.

Es gibt verschiedene Konfigurationsoptionen für den mod_bw. Unterschied zwischen einer “globalen” und einer Vhost-spezifischen Konfiguration: Die “globale” Konfiguration gilt für alle Vhosts des Apachen. Diese wird in /etc/apache2/modules.d/11_mod_bw.conf gemacht. Darin stehen nach der Installation schon einige Vorschläge zur Konfiguration, allerdings sind diese noch stark ausbaufähig. Die Vhost-spezifische Konfiguration gilt nur für einen Vhost und kann diesen speziell begrenzen.

Die Direktiven in der Übersicht:

• Bandwidth
• BandWidthError
• BandwidthModule
• BandWidthPacket
• ForceBandWidthModule
• LargeFileLimit
• MaxConnection
• MinBandwidth

BandWidth

1

BandWidth [Quelle] [bytes/s]

“Quelle” kann verschieden angegeben werden:

• Voller Hostname
• Teil einer Domain
• IP-Adresse
• Adressbereich (z.B.: 192.168.0.0/24 oder 192.168.0.0/255.255.255.0)

Kommt diese Direktive mehrmals mit verschiedenen Quellen vor, so ist die Reihenfolge entscheidend. Die Reihenfolge ist die Priorität, wobei der erste Eintrag die höchste hat. Beispiel:

1

BandWidth 192.168.0.0/24 10240

Das Netz 192.168.0.0-192.168.0.255 kann maximal mit 10kb/s Daten vom Webserver empfangen

BandWidthError

1

BandWidthError [Error]

Wenn die Maximale Anzahl der Verbindungen (definiert durch MaxConnection) erreicht wird, so wird der HTTP-Error-Code 503 (HTTP_SERVICE_UNAVAILABLE) ausgegeben. Da die meistens Nutzer nicht wissen, aus welchem Grund dies geschieht, kann das nervig sein. Daher kann man hier den Fehlercode festlegen, der dann ausgegeben wird. Beispiel:

1
2

ErrorDocument 510 /errors/maxconexceeded.html
BandWidthError 510

Als ErrorCode wird 510 verwendet und dieser mit einer Fehlerseite versehen

BandwidthModule

1

BandWidthModule [On|Off]

Diese Direktive schaltet das Bandwidth-Modul an (On) oder aus (Off) Beispiel:

1

BandWidthModule On

Einschalten des Modules

BandWidthPacket

1

BandWidthPacket [Size]

Größe der Packete. Besser nicht ändern. Defaultwert: 8092, Werte zwischen 1024 und 131072 sind erlaubt. Zu kleine Werte machen mod_bw langsam (aufgrund des vielen Splittens). Beispiel:

1

BandWidthPacket 8092

Setzt 8092 als Packetgröße

ForceBandWidthModule

1

ForceBandWidthModule [On|Off]

In der Default-Konfiguration wird nicht jeder Request durch mod_bw geleitet. Dadurch kann die Bandbreitenregulation möglicherweise nicht korrekt durchgeführt werden. Diese Direktive piped jeden Request durch mod_bw. Beispiel:

1

ForceBandWidthModule On

Damit wird jeder Request durch mod_bw geleitet

LargeFileLimit

1

LargeFileLimit [Typ] [Minimale Grösse] [bytes/s]

Mit dieser Direktive kann die Dateiendung, sowie eine minimale Größe, aber der die Direktive greifen soll, angegeben werden. Beispiel:

1

LargeFileLimit .avi 500 10240

MaxConnection

1

MaxConnection [Quelle] [Max]

Mit dieser Direktive wird die maximale (Max) Anzahl von Verbindungen aus einer bestimmten Quelle angegeben. Werden mehr Verbindungen aufgebaut, bekommen diese einen HTTP-Status-Code 503 (Service Temporarily Unavailable) oder die in BandWidthError angelegte Fehlerdatei. Beispiel:

1
2

MaxConnection all 20
MaxConnection 192.168.0.0/24 50

Alle Clients aus dem Netz 192.168.0.0/24 erhalten 20b/s, alle anderen 50b/s

MinBandwidth

1

MinBandWidth [Quelle] [bytes/s]

Mit dieser Direktive wird die minimale Geschwindigkeit pro Quell-Host/Range festgelegt. Jeder Client bekommt die festgelegte Rate zugewiesen, egal, wieviel Gesamt-Bandwidth festgelegt wurde. Wenn [bytes/s] auf 0 gestellt, wird der Default-Wert von 256 bytes/s festgelegt. Wird [bytes/s] auf -1 festgelegt, so bekommt jeder Client die Maximal-Bandbreite zugewiesen. Beispiel:

1
2

BandWidth all 102400
MinBandWidth all 50000

Die Bandbreite wird auf 100kb/s festgelegt. Ist nur ein Client verbunden, so bekommt dieser 100kb/s. Verbindet sich ein zweiter, so wird diesem und dem ersten (wie auch allen weiteren) mindestens 50kB/s zugewiesen.

1
2

BandWidth all 50000
MinBandWidth all -1

Jeder Client bekommt eine maximale Bandbreite von 50kb/s zugewiesen

Beispiele befinden sich in der Readme von mod_bw , hier ein Auszug:

1
2
3
4
5
6
7

<Virtualhost *>
  BandwidthModule On
  ForceBandWidthModule On
  Bandwidth all 10240
  MinBandwidth all -1
  Servername test.wolf-u.li
</Virtualhost>

Erklärung: Limitiert alle Clients auf maximal 10kb/s

Ich beginne mit der Serverkonfiguration.Zunächst muss man das sogenannte TUN/TAP-Device im Kernel aktivieren, welches sich in der menuconfig unterhalb von “Device Drivers —>” im Menü “Network device support —>” unter dem Punkt “[]Network device support*” unter dem Punkt “Universal TUN/TAP device driver support” verbirgt. Anschließend muss man den Kernel natürlich einmal neu kompilieren und diesen starten, um die Änderungen zu übernehmen.

Weiter gehts mit der eigentlichen Installation von OpenVPN:

1

emerge openvpn

Nun gehen wir zur Erstellung der Zertifikate für die Authentifizierung weiter. Mit Hilfe der sogenannten Easy-RSA von OpenVPN erstellen wir die benötigten Dateien. Dazu wechseln wir in dessen Verzeichnis:

1

cd /usr/share/openvpn/easy-rsa/

Nun wird die Datei “vars” editiert und die folgenden Parameter gesetzt (Es darf keine leer bleiben):

• KEY_SIZE Erklärung: Verschlüsselungsstärke, ich habe 2048 gewählt
• KEY_COUNTRY Erklärung: Ländercode
• KEY_PROVINCE Erklärung: Bundesland
• KEY_CITY Erklärung: Stadt
• KEY_ORG Erklärung: Firma oder Organisation
• KEY_EMAIL Erklärung: Mailadresse des Ansprechpartners

Diese Variablen müssen nun geladen und anschließend im Verzeichnis aufgeräumt werden:

1
2

source ./vars
./clean-all

Weiter gehts mit der Erstellung der Public-Key-Infrastruktur ( PKI ) mittels einer Certificate Authority (CA):

1

./build-ca

Der Output sieht etwa so aus:

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

Generating a 2048 bit RSA private key
............++++++
...........++++++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [DE]:
State or Province Name (full name) [DeinBundesland]:
Locality Name (eg, city) [DeineStadt]:
Organization Name (eg, company) [Privat]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:**Irgendwas**
Email Address [mail@myhostname.tld]:

Wenn zuvor alles korrekt eingegeben wurde, muss man nur “Common Name” ausfüllen und mit einem beliebigen Wert (hier “Irgendwas”) füllen.

Weiter gehts mit dem Zertifikat für den Server, diesmal muss aber der Common Name mit “server” (bitte exakt so schreiben!) gefüllt werden. Zwei weitere Fragen müssen positiv (also mit “y”) beantwortet werden, die da lauten: “Sign the certificate? [y/n]” aund “1 out of 1 certificate requests certified, commit? [y/n]”. Jetzt zum Befehl:

1

./build-key-server server

Für jeden Client muss man nun ein Zertifikat erstellen. Auf keinen Fall sollte ein Zertifikat auf zwei Rechner eingesetzt werden. Der Grund dafür ist sehr einfach: Geht ein Rechner verloren oder wird gehackt und man muss das Zertifikat revoken, so sind alle Rechner mit diesem Zertifikat davon betroffen. Beim folgenden Befehl sollte im Common Name jeweils ein eindeutiger Name für den Rechner stehen, also z.B. ulilaptop oder ulimainframe

1
2

./build-key ulilaptop
./build-key ulimainframe

Jetzt brauchen wir noch den Diffie Hellman Parameter, der leider bei 2048 Bit recht lang zu generieren braucht (kann schon mal ein paar Minuten dauern).

1

./build-dh

Zuletzt generiere ich noch ein tls-auth key-file für die Authentifizierung am Server:

1

openvpn --genkey --secret keys/ta.key

Schützenswert sind vor allem nun im Verzeichnis “keys” die Dateien, welche auf *.key enden, da diese die privaten Teile der Zertifikate darstellen.

Wir kopieren nun die erstellten Dateien ins OpenVPN-Verzeichnis:

1
2
3

mkdir -p /etc/openvpn/securenet/
mv /usr/share/openvpn/easy-rsa/keys/* /etc/openvpn/securenet/
chmod 700 /etc/openvpn/securenet

Und ein Backup aller erstellten Keys (nur zur Sicherheit):

1
2

tar cfzp /root/openvpn-securenet.tar.gz /etc/openvpn/securenet/
chmod 700 /root/openvpn-securenet.tar.gz

Kommen wir zur Konfiguration des Servers. Zunächst muss die Datei “/etc/openvpn/openvpn.conf” editiert werden. Mein VPN-Netz bekommt den IP-Bereich 10.13.37.0 und wird maximal 5 Clients zulassen. Der VPN-Server lauscht auf Port 4242 (UDP) auf einem TUN-Device.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

port 4242
verb 3
proto udp
dev tun
ca /etc/openvpn/securenet/ca.crt
cert /etc/openvpn/securenet/server.crt
key /etc/openvpn/securenet/server.key
dh /etc/openvpn/securenet/dh2048.pem
server 10.13.37.0 255.255.255.0
ifconfig-pool-persist /etc/openvpn/ipp.txt
keepalive 10 120
cipher AES-256-CBC
comp-lzo
user openvpn
group openvpn
persist-key
persist-tun
resolv-retry infinite
status /etc/openvpn/openvpn-status.log
chroot /etc/openvpn/chroot
push "redirect-gateway"
client-to-client
max-clients 5
tls-auth /etc/openvpn/securenet/ta.key 0

Damit ist die Serverkonfiguration fast abgeschlossen. Nun muss man noch das chroot-Verzeichnis erstellen:

1

mkdir /etc/openvpn/chroot

Und die passende User-/Nutzergruppenkombination erstellen:

1

useradd -M -s /bin/false -U openvpn

Ab besten sollte man nun den Server einmal starten:

1

/etc/init.d/openvpn start

Wenn alles geklappt hat, sollte man die Änderungen permanent machen:

1

rc-update add openvpn default

Nun muss man das IP-Forwarding einschalten (Danke an Sven für den Hinweis!). Dazu öffnet man die Datei /etc/sysctl.conf und sucht folgende Zeilen:

1
2

# Disables packet forwarding
net.ipv4.ip_forward = 0

Diese ersetzt man durch (also v.a. 0 => 1):

1
2

# Enables packet forwarding
net.ipv4.ip_forward = 1

Dies funktioniert NUR, wenn im Kernel “Sysctl support” eingeschalten ist!

Damit der Server hinterher auch den Internet-Traffic durchroutet, muss man einige IPTables-Regeln festlegen:

1
2

iptables -t nat -F POSTROUTING
iptables -t nat -A POSTROUTING -o eth0 -s 10.13.37.0/24 -j MASQUERADE

Man will jedoch nicht, dass der Server den Netbios-Traffic auch ins Internet schickt, daher zusätzlich:

1
2
3
4
5

# Block outgoing NetBios
iptables -A FORWARD -p tcp --sport 137:139 -o eth0 -j DROP
iptables -A FORWARD -p udp --sport 137:139 -o eth0 -j DROP
iptables -A OUTPUT -p tcp --sport 137:139 -o eth0 -j DROP
iptables -A OUTPUT -p udp --sport 137:139 -o eth0 -j DROP

Damit diese Regeln beim Systemstart auch gesetzt werden, habe ich diese am Ende von /etc/rc.conf angefügt, welche bei jeden Systemstart aufgerufen wird.

Kommen wir zur Konfiguration der Clients. Unter Windows installiert man am Klügsten das Paket von openvpn.se, da dort eine graphische Oberfläche zur Benutzung von OpenVPN (inklusive eines Taskleistenprogramms) verfügbar ist. Nun müssen die Schlüssel zu den Clients transportiert werden. Die fünf Dateien sollten am besten über einen SICHEREN Weg transportiert werden (beispielsweise SCP ). Diese werden benötigt (hier beispielhaft für “ulilaptop”:

• dh2048.pem
• ulilaptop.crt
• ca.crt
• ulilaptop.key
• ta.key

Herunterladen und im Verzeichnis “config” der OpenVPN-Installation abgelegen. Im gleichen Verzeichnis muss eine Datei namens client.ovpn mit folgendem Inhalt angelegt werden:

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

client
dev tun
proto udp
remote YOURSERVER 4242
resolv-retry infinite
nobind
cipher AES-256-CBC
persist-key
persist-tun
ca ca.crt
cert ulilaptop.crt
key ulilaptop.key
comp-lzo
verb 3
mute 20
ns-cert-type server
tls-auth ta.key 1

Hierbei müsssen YOURSERVER mit dem Hostnamen des Servers und jeweils die Zertifikatsnamen mit deinen vergebenen Namen ausgetauscht werden.

Damit sollte Client-Configuration ageschlossen sein. Jetzt einfach mal versuchen zu verbinden. Wenn alles funktioniert hat und in der Taskleiste das Icon grün leuchtet, sollte man mal die eigene IP herausbekommen. Dazu gibt es viele verschiedene Seiten (Suchmaschine befragen), ich habe mir eine eigene in PHP schnell zusammengestrickt ;) Mit diesem Setup fahre ich momentan problemlos ;)

Heute morgen hats mich erwischt…der MySQL5-Server hatte ein kleines Problem… Aufgrund der gestiegenen Last auf dem neuen Server hat die Anzahl der Queries die Anzahl der max_connections erreicht. Was heisst das konkret? Queries, welche nach dem Überschreiten dieser Zahl gesetzt werden, werden nicht ausgeführt, sondern mit dem Fehler “Too many Connections (localhost)” abgewiesen.

Wie kann man nun den MySQL-Server ein wenig tunen?

Es gibt hierzu ein Skript von Day32 , welches bei mir hervorragende Dienste geleistet hat:

1
2
3

cd /usr/src/
wget http://www.day32.com/MySQL/tuning-primer.sh
sh tuning-primer.sh

Tuning primer gibt nun eine Menge Vorschläge und Ratschläge aus, um den MySQL-Server ein bisschen zu tunen. Bei mir wars vor allem die Variable max_connections, welche per Default auf 100 steht, die nun ein wenig zu niedrig war.

Um dies zu ändern öffnet man die Datei my.cnf (bei mir unter /etc/mysql/) und fügt in der Sektion [mysqld] folgenden Wert hinzu (Bitte Anzahl der gleichzeitigen Verbindungen selbst wählen, ich habe mal 500 eingetragen):

1

max_connections = 250

Achtung: Bei mir trat ein Fehler auf, wenn ich vor und nach dem ‘=’ keine Leerzeichen gesetzt hatte. Ausserdem wird für jede Connection Ram benötigt, tuning-primer meckert aber dann schon ;)

Nun kann man entweder den Server neu starten, oder man setzt es temporär bis zum Neustart mit einem Query in die Datenbank:

1

mysql -u root -p

1
2

set GLOBAL max_connections=250;
exit;

Man kann das schnell prüfen, in dem man vor dem exit; folgenden Befehl in die Datenbank absetzt:

1

show variables like 'max_connections';

Weitergehende Informationen bekommt man beim Hersteller  im Handbuch.

Danke an dieser Stelle an Alex  (dem ich den Fehler nicht glauben wollte) und PaGo  (für den Screenshot, ich hab da noch geschlafen :) )

Gleichzeitig sind aber die Rewrite-rules einfacher als beim lighttpd , da diese fast 1:1 vom Apache zu übernehmen sind (was den Umzug der Seiten deutlich einfacher gestaltet). Ich möchte direkt nativ alles über nginx und dessen FastCGI-Backend ausliefern, weshalb ein paar zusätzliche Artikel zu deren Rewrite-Rules oder Stolperfallen bei der Einrichtung kommen werden.

Dieser Artikel ist Teil einer Reihe zum Webserver nginx. Schau dir auch die anderen Artikel an: Zum Leitartikel

Los geht’s mit der Installation von Gentoo, welche ich nach Handbuch  durchführe. Hierzu verliere ich keine weiteren Worte, da das Handbuch wirklich umfangreich und ausreichend ist. Wichtig ist, dass Portage auf dem aktuellen Stand ist, das sollte aber nach der Installation der Fall sein.

Ich wollte den nginx mit den zusätzlichen Modulen FastCGI , PCRE, SSL , Stub_Status , WebDAV  und zlib , weshalb ich die folgenden USE-Flags hinzugefügt und anschließend den nginx installiert habe:

1
2

echo "www-servers/nginx fastcgi pcre ssl status webdav zlib" >> /etc/portage/package.use
emerge -av nginx

Zum Zeitpunkt des Schreibens wird Version 0.7.61 installiert.

Nach dem emergen von Nginx kommt bei mir die Konfiguration von PHP. Ich fahre schon seit Ewigkeiten mod_fcgid unter Apache, welcher die Verwaltung (Starten/Stoppen/Steuerung) der PHP-Prozesse selbst übernimmt. Bei nginx wird das etwas anders angesteuert, da die PHP-Prozesse schon existieren müssen und nginx diese nicht selbst erstellt. Um dies zu vereinfachen, gibt es das Project spawn-fcgi , welches aus dem Webserverprojekt lighttpd  ausgegliedert wurde.

Zum Zeitpunkt dieses Tutorials ist dieses Paket in Gentoo noch nicht als stable gekennzeichnet, weshalb man es vor der Installation möglicherweise erst freischalten muss:

1
2

echo "www-servers/spawn-fcgi" >> /etc/portage/package.keywords
emerge -av spawn-fcgi

Jetzt sollte man sich ein paar Gedanken zur Aufteilung der Webserverhosts über die PHP-Prozesse machen. Dazu muss man ein wenig Hintergrund zur FastCGI -Technologie kennen. Zur Verarbeitung der PHP-Seiten wird ein PHP-Interpreter gestartet mit dem der Webserver über einen Unix-Socket oder einen TCP-Port kommuniziert. Diese Interpreter kann man unter einem anderen Nutzer (als root) starten, wodurch ein wenig zusätzliche Sicherheit geschafft wird, wenn dieser Nutzer weniger Rechte hat. Im Idealfall sollte man also für jeden Vhost einen eigenen PHP-Interpreter und Nutzer haben, um die höchste Sicherheit zu erhalten. Leider benötigt jeder Interpreter ein wenig RAM, sodass man sich überlegen sollte, wieviele man davon gleichzeitig im RAM halten möchte. Ich habe für mich einen Mix aus Performance und Sicherheit gewählt. Ich zeige mal an einem Vhost, wie man diese PHP-Interpreter startet.

Startet man nun /etc/init.d/spawn-fcgi, so wird man ermahnt, dass das so nicht funktioniert:

• You are not supposed to run this script directly. Create a symlink
• for the FastCGI application you want to run as well as a copy
• of the configuration file and modify it appropriately like so…
• ln -s spawn-fcgi /etc/init.d/spawn-fcgi.trac
• cp /etc/conf.d/spawn-fcgi /etc/conf.d/spawn-fcgi.trac
• nano /etc/conf.d/spawn-fcgi.trac

Folglich führe ich diese Schritte für meinen ersten FastCGI-Server durch:

1
2

ln -s spawn-fcgi /etc/init.d/spawn-fcgi.wolfuli
cp /etc/conf.d/spawn-fcgi /etc/conf.d/spawn-fcgi.wolfuli

Jetzt muss man die Konfigurationsdatei /etc/conf.d/spawn-fcgi.wolfuli editieren:

FCGI_SOCKET= FCGI_ADDRESS=127.0.0.1 FCGI_PORT=1234 FCGI_PROGRAM=/usr/bin/php-cgi FCGI_CHILDREN=1 FCGI_CHROOT= FCGI_CHDIR= FCGI_USER=wolfuli FCGI_GROUP=wolfuli PHPRC="/var/www/php-ini/wolfuli/" PHP_FCGI_CHILDREN=10 PHP_FCGI_MAX_REQUESTS=1000 ALLOWED_ENV="PATH PHP_FCGI_CHILDREN PHP_FCGI_MAX_REQUESTS PHPRC"

Über die Variable PHPRC wurde ein Verzeichnis festgelegt, in dem man man eine, für den Vhost angepasste, php.ini hinterlegen kann.

Jetzt muss man noch den Nutzer wolfuli samt der gleichen Nutzergruppe anlegen:

1

useradd -s /bin/false -U wolfuli

Jetzt richten wir mal unsere Vhosts ein. Aus praktischen Gründen habe ich mich entschlossen ein “sites-available” und ein “sites-enabled”-Verzeichnis anzulegen.

1
2

mkdir /etc/nginx/sites-available
mkdir /etc/nginx/sites-enabled

So kann ich Vhosts im ordner sites-available konfigurieren und dann diese dann in sites-enabled softlinken, wenn sie aktiv sein sollen. So kann ich mal vhosts abschalten ohne diese gleich löschen zu müssen.

Die /etc/nginx/nginx.conf habe ich ebenfalls ein wenig abgeändert, sodass diese wie folgt aussieht:

 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

user nginx nginx;
worker_processes 2;
error_log /var/log/nginx/error_log info;
events {
 worker_connections 8192;
 use epoll;
}
http {
 include /etc/nginx/mime.types;
 default_type application/octet-stream;
 log_format main
 '$remote_addr - $remote_user [$time_local] '
 '"$request" $status $bytes_sent '
 '"$http_referer" "$http_user_agent" '
 '"$gzip_ratio"';

 client_header_timeout 10m;
 client_body_timeout 10m;
 send_timeout 10m;
 connection_pool_size 256;
 client_header_buffer_size 1k;
 large_client_header_buffers 4 2k;
 request_pool_size 4k;
 gzip on;
 gzip_min_length 1100;
 gzip_buffers 4 8k;
 gzip_types text/plain;
 output_buffers 1 32k;
 postpone_output 1460;
 sendfile on;
 tcp_nopush on;
 tcp_nodelay on;
 keepalive_timeout 75 20;
 ignore_invalid_headers on;
 index index.html;

 include /etc/nginx/sites-enabled/*;
}

Wie man sieht, ist nun in der letzten Zeile ein include aller Vhosts aus dem “sites-enabled"-Verzeichnis. Die Variable “worker_processes” sollte auf die Anzahl der CPU-Kerne gesetzt werden, was in meinem Falle zwei sind.

Damit ist die Installation abgeschlossen, jetzt kann man nun einen PHP-VHost anlegen. Dazu muss zunächst die Datei /etc/nginx/fastcgi_params angelegt bzw. modifiziert werden, sodass diese so aussieht:

 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

fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;

fastcgi_param SCRIPT_NAME $fastcgi_script_name;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
fastcgi_param SERVER_PROTOCOL $server_protocol;

fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE wolfuli/1337;

fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;

fastcgi_index index.php;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param REDIRECT_STATUS 200;

Diese Datei legt einige Parameter im Zusammenspiel von PHP (FastCGI) und nginx fest.

Hier der Beispielvhost example.com, welcher unter /etc/nginx/sites-available/example.com angelegt wird:

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

server {
 listen 80;
 server_name example.com;
 error_log /var/log/nginx/example.com.log warn;
 root /var/www/example.com/;

 location / {
 index index.php;
 }

 location ~ \.php$ {
 fastcgi_pass 127.0.0.1:1234;
 include /etc/nginx/fastcgi_params;
 }
}

Jetzt muss man den fertigen Vhost nur noch softlinken:

cd /etc/nginx/sites-enabled/ ln -s ../sites-available/example.com

Und nginx die neuen Konfigurationsdateien lesen lassen:

/etc/init.d/nginx reload

Das wars. Lies auch die anderen Artikel zu diesem Thema in diesem Leitartikel.

1

lspci

Blöderweise meinte Gentoo, dass es diesen Befehl nicht kennt. Nach kurzer Suche fand ich heraus, dass der Autor des Programms das ganze in ein Paket namens pciutils  verpackt hat.

Die Lösung war also die Installation von sys-apps/pciutils:

1

emerge -av pciutils

Und schon lief der Spaß :)

Installation

• Installation von nginx mit PHP auf Gentoo
• Installation von eAccelerator in Verbindung mit nginx unter Gentoo

Konfiguration

• Ausgabe der Server-Version auf Fehlerseiten und Header unterdrücken
• Rewrite Rules für das SimpleMachinesForum mit PrettyUrls-Plugin
• Rewrite-Rules für Mediawiki
• Rewrite-Rules für Question2Answer
• Rewrite-Rules zur umleitung von “www” auf “non-www”
• Rewrite-Rules zur Verweigerung des Zugriffs auf .svn-Verzeichnisse
• Bildercache mit statischer Auslieferung
• Umleitung von Shortlinks zu Wordpress-Beiträgen
• Betrieb von Piwik
• Aktivierung von IPv6

Fehlerlösungen

• worker_connections are more than open file resource limit
• PHP-FPM: “Invalid query name 1”

1
2

apache2: subversion/libsvn_subr/path.c:377: svn_path_basename: Assertion `is_canonical(path, len)' failed.
[notice] child pid 15181 exit signal Aborted (6)

Eingesetzte Software: Gentoo: Tagesaktuell Subversion: 1.4.4 Apache: 2.2.4

Die eingesetzte Config umfasste ein SVN-Repository, welches per SVNPath angesprochen wurde. Um den obenstehenden Fehler loszuwerden musste ich in der Config-Datei für den Vhost die Zeile mit AuthzSVNAccessFile auskommentieren. Man kann also keine AuthzSVNAccessFile für genauere Berechtigungen verwenden, wenn man ein einzelnes Repository über SVNPath benützen möchte (gibt ja auch irgendwo Sinn) Wenn man jedoch SVNParentPath für mehrere Repositorys nutzt, dann kann man auch wieder die AuthzSVNAccessFile nutzen.

Hat bei mir den Fehler erstmal behoben.

Unter Gentoo gestaltet sich die Installation wie immer extrem einfach:

1

emerge -av xdebug

Damit ist xdebug für alle Webhosts installiert! Es ist noch nicht aktiviert! Noch ein Hinweis: Xdebug verträgt sich nicht mit Zend Optimizer, man kann nur eines gleichzeitig einschalten! (Logmeldung: “Zend Optimizer 3.3.3 is incompatible with Xdebug 2.0.2” kam bei mir)

Ich fahre ein komplexes Setup mit mod_fcgid, was mir erlaubt für jeden Webhost einzelne php.ini-Files anzulegen. Daher habe ich zunächst die extension wieder deaktiviert:

1
2

rm /etc/php/cgi-php5/ext-active/xdebug.ini
rm /etc/php/cli-php5/ext-active/xdebug.ini

Und anschließend die relevanten Daten der Config in der php.ini meines Webhosts eingetragen:

1
2
3
4
5

zend_extension=/usr/lib/php5/lib/php/extensions/no-debug-non-zts-20060613/xdebug.so
xdebug.profiler_enable="1"
xdebug.profiler_output_dir="/tmp"
xdebug.profiler_output_name="cachegrind.out.%u.%p"
xdebug.profiler_enable_trigger="1"

Was heissen diese Werte?

• zend_extension: Lädt die Erweiterung
• xdebug.profiler_enable Schaltet den Profiler ein
• xdebug.profiler_output_dir In diesem Verzeichnis werden die Profiling-Log-Files abgelegt
• xdebug.profiler_output_name Name der Profiling-Log-Files, folgende Platzhalter existieren:
  • %p Process-Id
  • %r Zufallszahl
  • %u Zeitstempel in Microsekunden
  • %H Wert von $_SERVER[‘HTTP_HOST’]
  • %R Wert von $_SERVER[‘REQUEST_URI’]
  • %s Name des Script mit vollem Pfad, Slashes werden in Unterstriche konvertiert
• xdebug.profiler_enable_trigger Logfiles werden nur über das Auslösen eine Triggers geschrieben. Da diese Logfiles teilweise sehr groß sind, sollte man diesen Schalter einschalten, um nicht jeden Request eines jeden Besuchers aufzuzeichnen. Dieser Trigger lautet: http://url-des-webhosts/?XDEBUG_PROFILE

Welche weiteren Switches existieren?

• xdebug.profiler_append Kann genutzt werden, um nur ein Logfile mit allen Profiling-Daten zu bekommen (xdebug.profiler_append=1). Neue Einträge werden dann (wenn der xdebug.profiler_output_name immer der gleiche ist) bei der Ausgabedatei einfach angehängt

Jetzt erstellen wir ein solches Profiling-Logfile indem wir http://url-des-webhosts/?XDEBUG_PROFILE aufrufen. Dieses hat bei mir für einen Request eine Größe von 17MB.

Die Auswertung wird unter Windows mittels WinCacheGrind  gemacht. Nach der Installation öffnet man das Programm und lädt die soeben erstellte Datei.

Mein Tipp: Zuerstmal die schnellen Funktionen (d.h. <1ms) und die PHP-Funktionen ausschalten, denn an diesen hakt es meistens nicht. Das geht über das Menü “Profiler”.

Nun kann man sich einfach per Doppelklick durch die Funktionen hangeln.

Unter Linux existiert für die KDE-Umgebung ein Tool namens KCacheGrind , welches deutlich mehr als nur die Funktionalitäten von WinCacheGrind beinhaltet. Es kann auch die Profiling-Daten visualisieren und beispielsweise Aufrufe als Graphen zeichnen. Auf dieser Seite kann man das ein auch ansehen, ich habe es selbst nicht getestet ;)

Übrigens das Ergebnis des Abschaltens des Plugins: 2 Sekunden weniger fürs generieren der Seite! Jetzt könnte ich noch 400ms einsparen, wenn ich mein Template durchgehend auf Deutsch direkt übersetzen würde und keine Sprachdateien verwenden würde (Die Spracheengine ist nicht gerade nen Knaller…). Problem dabei ist, dass es häufige Updates für dieses Theme gibt und der Aufwand enorm ist…ne Sekunde für die Startseite ist tolerabel.

• APS: Der Application Packaging Standard hat seinen Weg in dieses Relelase gefunden. Kunden können nun Blogs, Gästebücher, Foren mit nur einem Klick installieren.
• Abrechnungs-Modul: Das Modul ermöglicht eine einfache Abrechnung von Kundendienstleistungen und bietet Unterstützung für diverse Vorlagen.
• Autoresponder: Abwesenheitsnotizen werden immer wichtiger in der Geschäftswelt. Dieses Feature wurde nun in SysCP integriert und bietet nun die Möglichkeit einfach solche automatischen Abwesenheitsnachrichten zu erstellen.
• Cronjob: Das Herz von SysCP wurde komplett neu geschrieben. Dabei flossen viele Verbesserungen und Fehlerbehebungen ein.
• Unterstützung für Dovecot.
• E-Mail-Kontingente: Jeder Benutzer kann nur eine bestimmte Menge an Speicherplatz pro Mailbox beanspruchen. Verfügbar für Courier und Dovecot.
• FCGID: PHP-Skripte können in ihrer eigenen Umgebung laufen - jeder Kunde hat seine eigene php.ini.
• IPv6 Verbesserung: SysCP kann nun vollständig mit IPv6-Adressen umgehen.
• Unterstützung für Lighttpd: Oft nachgefragt und nun endlich enthalten: Lighttpd Support für SysCP. Lighttpd ist ein schneller und einfach zu benutzender Webserver und damit eine wertvolle Alternative für Apache 2.
• Logging-System: Alle Aktivitäten im Überblick: Mit diesem Feature werden die Aktionen der Kunden, Reseller, Admins, des Updaters und des Cronjobs protokolliert.
• Sicherheit: Um die Einträge in der Datenbank sicher zu halten nutzt SysCP nun die PHP-Filter-Erweiterung um die eingegebenen Daten auf Gültigkeit zu überprüfen.
• Einstellungsseite: Die neue, überarbeitete Einstellungsseite wurde in verschiedene Kategorien unterteilt und bietet nun An-Aus-Schalter zum schnellen Deaktivieren von Features.
• Traffic-Überblick: Gibt Kunden einen graphischen Überblück über ihren Trafficverbrauch.
• Konfigurationsdateien für Ubuntu 8.04 (Hardy Heron)
• Usability: Viele Interface-Verbesserungen machen die Bedienung von SysCP noch einfacher und benutzerfreundlicher.
• Bugfixes: Sehr viele Bugs, die von Nutzern berichtet wurden

Insgesamt ein hervorragendes Release, ich freue mich auf das APS-System. Da es kein Security-Release war, ist ein Upgrade nicht sofort erforderlich. Gott sei Dank, denn es sind leider auch verdammt viele Änderungen :P Wird ein kompliziertes Upgrade…(Ich fahr ja FCGID nicht erst seit 1.2.19…). Momentan scheint es noch ein Problem mit doppelten Menüeinträgen zu geben, wofür momentan noch kein Fix verfügbar ist. Mittlerweile gibt es ein Update auf 1.4.2 mit folgenden Änderungen:

• Doppelte Menüeinträge für das Abrechnungs-Modul wurden entfernt
• APS-Menü wird wieder angezeigt
• PHPMyAdmin/WebMail/WebFTP-Links werden wieder angezeigt
• PHP Konfiguration ist wieder editierbar
• Einige Fehler in den Englischen Sprachdateien wurden behoben
• Geschützte Bereiche funktionieren wieder mit lighttpd
• Awstats-Konfigurationsseite zeigt alle Konfigurationen
• Fehlender Zeilenumbruch in der nss-mysql.cnf
• Database Query Error bei der Suche nach Tickets auf der Kategorienseite
• Resellers konnten Instanzen ihrer Kunden nicht mehr verwalten
• Autoresponder cron script lief nicht, wenn short-tags deaktiviert waren
• Autoresponder hat nicht das Lockfile deaktiviert, wenn er deaktiviert wurde

Möchte man für ein Paket bestimmte USE-Flags setzen, ohne dass es in der make.conf global gesetzt wird, kann man die Datei /etc/portage/package.use verwenden. Beispielsweise möchte ich für das Paket mysql die berkdb deaktivieren. Daher habe ich entsprechend:

1

dev-db/mysql -berkdb

in der obenstehenden Datei eingetragen. Möchte man jedoch USB-Support für apcupsd (Ein Programm zur Steuerung von USV’s) haben, so muss man folgendes eintragen:

1

sys-power/apcupsd usb

Jedes Paket beansprucht dabei eine Zeile.

Spezielle Pakete demaskieren

Oft kommt es vor, dass man bestimmte Pakete installieren möchte, es aber von Portage mit dem Hinweis “All ebuilds that could satisfy “XXXX” have been masked.”. Dies ist beispielsweise beim Paket “dev-php5/ZendOptimizer” der Fall. Dieses Paket wurde für die Plattform x86 leider noch nicht stabilized, was man aber selbst in der Datei /etc/portage/package.keywords lösen kann. Das sollte man sich natürlich gut überlegen, manche Pakete werden jedoch “nie” stabilisiert, weshalb man diesen Schritt schon mal gehen kann. Eine andere Möglichkeit ist beispielsweise bei Paketen, wo noch keine Version freigegeben wurde, eine Freigabe zu erzielen.

Dazu fügt man:

1

dev-php5/ZendOptimizer ~x86

hinzu, und schon wird die Maskierung für die Plattform x86 entfernt. Will man es für alle Plattformen freigeben, so genügt ein:

1

dev-php5/ZendOptimizer

Jedes Paket beansprucht dabei eine Zeile.

~# java-config –help

1
2
3
4

`Traceback (most recent call last):
File "/usr/bin/java-config-2", line 8, in
from java_config_2 import __version__
ImportError: No module named java_config_2`

Lösung: java-config neu emergen.

1
2
3
4

* Checking proftpd configuration ...
Checking syntax of configuration file
- Fatal: unknown configuration directive 'AuthUserFile' on line 44 of '/etc/proftpd/proftpd.conf'
* Configuration error: please fix your configuration file (/etc/proftpd/proftpd.conf). [ !! ]

Eine kurze Suche im Web brachte mich auf die Idee die USE-Flags zu überprüfen, was die Lösung brachte: Zu den USE-Flags muss authfile hinzugefügt werden.

`!!! The following installed packages are masked:

• dev-java/sun-jdk-1.6.0.17 (masked by: dlj-1.1 license(s)) A copy of the ‘dlj-1.1’ license is located at ‘/usr/portage/licenses/dlj-1.1’.

• dev-java/sun-jdk-1.5.0.22 (masked by: dlj-1.1 license(s)) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook.

!!! All ebuilds that could satisfy “dev-java/sun-jdk” have been masked. !!! One of the following masked packages is required to complete your request:

• dev-java/sun-jdk-1.6.0.18-r1 (masked by: dlj-1.1 license(s), ~x86 keyword) A copy of the ‘dlj-1.1’ license is located at ‘/usr/portage/licenses/dlj-1.1’.

• dev-java/sun-jdk-1.6.0.18 (masked by: dlj-1.1 license(s), ~x86 keyword)

• dev-java/sun-jdk-1.6.0.17 (masked by: dlj-1.1 license(s))

• dev-java/sun-jdk-1.5.0.22 (masked by: dlj-1.1 license(s))`

Die Lösung war das akzeptieren der Lizenz, wie bereits schon in der Meldung gesagt. Jedoch gibt es da verschiedene Möglichkeiten:

1. Systemweites akzeptieren aller Lizenzen: Füge in der Datei /etc/make.conf die folgende Zeile hinzu:
2. Systemweites akzeptieren einer oder mehrer spezifischer Lizenzen: Füge in der Datei /etc/make.conf die folgende Zeile hinzu:
3. Akzeptieren einer Lizenz für ein Paket: Füge in der Datei /etc/portage/package.license die folgende Zeile hinzu: dev-java/sun-jdk dlj-1.1

Ich habe mich für letzteres entschieden:

echo "dev-java/sun-jdk dlj-1.1" >> /etc/portage/package.license

Und schon war das Problem gelöst :)

sys-fs/device-mapper is blocking sys-fs/udev-146

auf einem Server beim emerge hoch. Lösung war einfach:

1
2

emerge --unmerge sys-fs/device-mapper
emerge -av sys-fs/lvm2

sys-fs/device-mapper ist nun in lvm2 integriert worden / übergegangen, weshalb es nicht mehr benötigt wird.