Kategorie-Archive: Server & Hosting

Einzelne Datenbank/Tabelle aus MySQL-Dump wiederherstellen

Geschrieben von mrtnmueller am 6. Oktober 2011 Keine Kommentare

Auf meinem Rootserver läuft jeden Tag ein Backup mit fwbackups, welches meine Dateien und Datenbanken mittels externem Script sichert und, ebenfalls mit Hilfe eines externen Scripts, auf einen FTP-Backupspace lädt. Das ist – einmal eingerichtet – sehr komfortabel. Möchte ich nun aber an die Daten heran und nur eine Datenbank oder Tabelle zurückspielen so müsste ich eigentlich einen zweiten MySQL-Server starten, das Backup einspielen und dann nur das gewünschte exportieren. Das wäre extrem umständlich, daher habe ich nach einem einfacheren Weg gesucht und ihn auch gefunden:

Nur eine Datenbank zurücksichern:

sed -n '/^-- Current Database: `dbname`/,/^-- Current Database: `/p' dumpfile > dbname.sql 2>error

Nur eine Tabelle zurücksichern:

sed -n -e '/CREATE TABLE.*mytable/,/CREATE TABLE/p' mysql.dump > mytable.dump

Hat man mehrere Tabellen, die ähnlich heißen sollte man Backquotes für die Namen verwenden.

Danke an uloBasEI von stackoverflow.com und Prabhat Kumar von adminlinux.blogspot.com für diese Tipps.

“Can’t connect to X11 window server”-Error

Geschrieben von mrtnmueller am 11. August 2011 Keine Kommentare

Als ich letztens eine Serverwartungs-GUI über mein VNC lassen wollte bekam ich auf einmal eine komische Fehlermeldung:

Can't connect to X11 window server using ':1.0' as the value of the DISPLAY variable.

Nach etwas googeln hat mir dann stress_junkie vom Forum linuxquestions.org die Erklärung (inklusive Lösung) geliefert:

If the Java program is running under your own account then the problem comes from DISPLAY being incorrectly defined. Try this:

export DISPLAY=”:0.0″

If a different user account is running the program then the user account that “owns” the console must add permission for others to display on “their” X display. Try this:

xhost +local:all

If the program is being used on a different computer, say 192.168.3.5 then try this:
Code:

xhost +inet:192.168.3.5

Ich wollte die GUI nämlich über einen anderen User laufen lassen. Nachdem ich bei diesem den Befehl xhost +local:all ausgeführt hatte, konnte ich zurück zum ausführenden User wechseln und das Programm problemlos starten. Denn nun hatte es die Berechtigung, das X11 window des xterm-Besitzers benutzen zu dürfen.

Hosting absichern: Apache2 mit ITK-MPM

Geschrieben von mrtnmueller am 3. Juli 2011 Keine Kommentare

Für Multiuser-Environments wie eine Hosting-Umgebung stellt sich spätestens ab einer gewissen Userzahl die Frage nach der Absicherung bzw. Abschottung der einzelnen User voneinander. Dafür gibt es verschiedene Varianten, die allesamt unterschiedliche Vor- und Nachteile haben.

Stuart Herbert hat sich dankenswerter Weise schon vorher die Mühe gemacht, die 5 gängigsten Varianten (suphp, mpm-peruser, mpm-itk, PHP + FastCGI und suexec + PHP + FastCGI) einem Vergleich zu unterziehen. Zwar sind die durchgeführten Performance-Tests mit Vorsicht zu genießen (sie spiegeln in keiner Weise ein realitätsnahes Szenario wieder und übersteigern die Performanceverluste erheblich), aber die Artikel vermitteln dennoch ein sehr gutes Bild der jeweiligen Verfahren und ihrer Stärken und Schwächen.

Ich habe mich für meinen Server schlussendlich für mpm-itk entschieden, da es sehr flexibel ist, alle Vorteile von mod_php weiterhin genutzt werden können und der zusätzliche Speicher- und CPU-Bedarf nicht ganz so extrem ist wie bei mpm-peruser. Zudem setzt die Sicherung im Gegensatz zu den fcgi-Varianten hier bereits im Apachen – also an der richtigen Stelle – an. Die Performance-Einbußen sind, anders als der Test es vermuten lassen würde, im Praxisbetrieb sehr moderat.

Um Apache2 mit ITK-MPM einzurichten bedarf es – vorausgesetzt Apache2 ist bereits installiert – unter Ubuntu/Debian nur eines kurzen Befehls:

apt-get install apache2-mpm-itk

Ein vermutlich vorhandenes anderes MPM (Multi-Processing Module) (standardmäßig dürfte das apache2-mpm-prefork sein) wird bei der Installation automatisch entfernt. Es kann also immer nur ein MPM gleichzeitig tätig sein, was ja auch logisch ist.

Nach dem automatisch durchgeführten Apache-Neustart ist das Modul sofort einsatzbereit. Um Gebrauch davon zu machen fügt man in den VirtualHost-Eintrag folgendes ein:

<VirtualHost *:80>
  ServerName www.example.com
  ...
 
  <IfModule mpm_itk_module>
    AssignUserId username groupname
    MaxClientsVHost 50
    NiceValue 10
  </IfModule>
</VirtualHost>

Alle Angaben sind optional. Wird kein Username zugewiesen läuft die jeweilige Domain unter dem Standard-User und der Standard-Gruppe (normalerweise www-data). Der MaxClients-Eintrag ermöglicht es (wie der Name schon sagt), die maximale Anzahl Clients für diesen spezifischen VHost festzulegen. Mit dem nice-Parameter kann man schlussendlich die Prozesspriorität pro VHost regeln (negative Werte = Priorität niedriger als normal).

Update: Es ist wichtig, jedem vHost auch wirklich eine User-Id zuzuordnen. Anderenfalls wird die Id von Apache genommen, was idR dann root ist (“Note that if you do not assign a user ID, the default one from Apache will be used.” lautet der lapidare Hinweis auf der Projektwebsite).

Praktische Methode zum “Kopieren mit Ausschluss” unter Linux

Geschrieben von mrtnmueller am 3. Mai 2011 Keine Kommentare

Das Linux-Command cp enthält leider keine “–exclude”-Funktion. Daher kann man, wenn man rekursiv kopieren will, keine Verzeichnisse oder Dateien angeben, die ausgeschlossen werden sollen. In einem Forum habe ich diesen Tipp gelesen (und dann ausprobiert), der wirklich clever ist.

Das Programm tar enthält eine exclude-Funktion. Also nutzen wir doch einfach dieses:

1	tar -cvf - --exclude dir1 --exclude dir2 --exclude file1.ext --exclude file2.ext /path/to/source \| (cd /path/to/destination; tar -xvf -)

Danke für diesen Tipp an vsemaska von linuxforums.org.

Webhosting mit ACLs

Geschrieben von mrtnmueller am 5. April 2011 Keine Kommentare

Die bekannten Unix-Rechte 644 oder 755 mögen für das Hosting eines einzelnen Projekts oder mehrerer Projekte, auf die man Shell-Zugriff hat, ausreichen. Wenn man aber Usern anbietet, ihre Site zu hosten gelangt man damit schnell an einen Punkt, wo diese Rechte einfach nicht mehr ausreichen.

Wenn zum Beispiel das CMS Joomla eine Komponente oder ein Modul über das Webinterface installiert bekommt so haben die Dateien, die installiert werden, als “Owner” den User, unter dem der Webserver läuft (meist www-data). Andererseits hat ein manuell über FTP eingespieltes Template als “Owner” den Hosting-Nutzer. Auf den meisten Systemen kommt dazu eine default-umask von 022, die allen neu erstellten Dateien ausschließlich Schreibrechte für den Ersteller/Besitzer der Datei zugesteht. Das könnte man zwar theoretisch ändern, würde damit aber die Sicherheit bei mehreren Nutzern kompromittieren (z.B. indem man die Nutzer und www-data einer Gruppe zuordnet, die Schreibrechte hat).

Alles in allem eine sehr unbefriedigende Lösung. Aber es gibt Abhilfe: ACLs (Access Control Lists) erlauben die feingranulare Einstellung der Rechte auf Nutzerebene wie auch in Gruppen. Mit ihnen lassen sich Konstrukte schaffen wie “www-data und Hostingnutzer haben rwx-Rechte” – und das auch für neu erstellte Dateien. Doch der Reihe nach.

Für die Nutzung von ACLs unter Ubuntu/Debian braucht es einen einigermaßen modernen Kernel (>2.5.46, ob man diesen Kernel von 2002 noch “einigermaßen modern” nennen kann lasse ich jetzt mal dahingestellt ) und die Partitionen müssen mit ext2 oder höher formatiert sein. In der /etc/fstab muss bei den Mountoptions aller Partitionen, mit denen ACLs genutzt werden sollen, der Parameter acl hinzugefügt werden, z.B.:

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
UUID=c1234f7f-fb32-4199-342a-4a12342f9a9d       /               ext3    defaults,usrquota,acl   0       1
UUID=f12349d1-d7e1-4ce5-4f3w-ddf971234b7       /boot           ext2    defaults        0       2
UUID=a1234b2b-b6bb-4572-33df-9351234335a0       none            swap    sw              0       0

Für die Bootpartition und die Swap-Partition brauchen wir natürlich keine ACLs, daher erfolgt der Eintrag nur auf der ersten Festplatte. Nach einer Änderung an der fstab muss das System neu gestartet werden um die Mountoptions zu übernehmen. Alternativ kann man natürlich auch den entsprechenden Mountpoint aushängen und manuell mit dem zusätzlichen Parameter neu mounten.

Als nächstes gehen wir in das Verzeichnis, welches die neuen ACLs erhalten soll und vergeben sie entsprechend unseren Wünschen:

1
2
3

cd /var/www/vhosts/username/
setfacl -R -m u::rwX,u:www-data:rwX,u:username:rwX .
setfacl -R -d -m u::rwX,u:www-data:rwX,u:username:rwX .

Die Zeile 2 des Codeschnipsels sorgt dafür, dass die User www-data und username Lese-, Schreib- und Ausführungsrechte für bereits bestehende Dateien/Ordner im Verzeichnis und allen Unterverzeichnissen erhalten. Das groß geschriebene “X” sorgt dabei für eine automatische Berechnung der Maske, ohne die es zu Einschränkungen im Zugriff kommen kann. Zeile 3 macht das Gleiche wie Zeile 2, nur für neu erstellte Objekte (Parameter d = default). Mit Hilfe dieses Konstrukts hat man eine Umgebung geschaffen, in der der Nutzer sich mit FTP und PHP-Fileuploads austoben kann und doch die Sicherheit des Systems gewahrt bleibt. Zugleich haben andere Nutzer nach wie vor keinen Zugriff auf die Dateien und Ordner von Benutzer username.

Für den “Hausgebrauch” reichen diese Befehle schon aus, um ein komfortables Arbeiten zu ermöglichen. Wer aber noch mehr erfahren möchte, dem sei die Seite über ACLs im Ubuntu-Wiki empfohlen. Dort wird u.a. ausführlich erklärt, wie man mit Gruppenrechten hantiert, wie man erstellte ACLs wieder los wird und wie man ein Backup seiner Listen anlegen kann.

Postfix + Courier unter Debian/Ubuntu oder: einen Mailserver aufsetzen

Geschrieben von mrtnmueller am 31. August 2010 Keine Kommentare

Vor einigen Tagen habe ich mein Ubuntu-System wegen der vielen Neuerungen und Security-Updates auf die Version 10.04 (Lucid Lynx) gebracht. Vorher natürlich ein Vollbackup erstellt (stolze 16 GB, wusste garnicht dass so viel drauf ist *g*), aber glücklicherweise nicht benötigt. Das Upgrade ging einfach und schnell, ein paar Fragen zu Config-Dateien waren schnell beantwortet und nach einem Neustart mit frischem Kernel 2.6.32-22 lief auf den ersten Blick alles super. Auf den zweiten Blick dann ein (kleiner) Schock: Plesk ging nicht mehr. Es war garnicht mehr installiert. Auf der Website von Parallels findet sich nur der Hinweis, dass maximal Ubuntu 8.04 unterstützt wird (nicht mal 9.10 – schwach). Na ja im Grunde genommen waren mir Systeme wie Plesk schon immer suspekt, man hat manchmal mehr Ärger damit als Nutzen davon und so bin ich nicht zurück zu 8.04 gegangen sondern habe im Internet gesucht wie ich am besten einen Mailserver aufsetze – denn der funktionierte nichtmehr.

Eigentlich wollte ich ja das Courier-Gesamtpaket courier-mta + courier-pop und courier-imap einsetzen. Nach langem Herumprobieren inklusive zu Rate ziehen der Mailingliste von Courier (courier-users) musste ich aber leider zum Schluss kommen, dass die zur Zeit im Lucid Lynx vorhandene Version der courier-mta wohl einen Bug aufweist, der die MTA nicht mit dem Authentifizierungsdaemon kommunizieren lässt. So bekam ich immer beim Eingehen einer Mail den Fehler

courieresmtpd: authdaemon: s_connect() failed: Permission denied

Nachdem ich diesen Fehler also nicht lösen konnte (sogar die selbst kompilierte Variante bockte mit dem gleichen Fehler rum) habe ich mich schweren Herzens (ich hasse ungelöste Probleme^^) entschieden, Postfix als MTA einzusetzen und Courier für den IMAP- und POP-Zugriff.

Zuallererst müssen natürlich die erforderlichen Programme installiert werden (als root):

1	apt-get install postfix courier-authdaemon courier-authlib courier-authlib-userdb courier-base courier-imap courier-imap-ssl courier-pop courier-pop-ssl sasl2-bin libsasl2-2 libsasl2-modules

Bei der Installation von Postfix wählt man als Betriebsmodus Internet-Site aus.

adduser vmail einen neuen Benutzer an. Dabei wird auch ein Nutzerverzeichnis /home/vmail angelegt, in dem später alle Mails gespeichert werden. Die User- und Gruppenid merken wir uns für später. Jetzt wechseln wir zu dem angelegten Nutzer vmail, z.B. mit su vmail --preserve-environment (preserve-environment verhindert, dass die default-shell des Nutzers vmail zum Einsatz kommt, die ist normalerweise nämlich nicht was wir wollen). Als User vmail erstellen wir jetzt die Unterverzeichnisse für die einzelnen Domains und Nutzer, also z.B. für 2 Nutzer auf the-enlightened.de:

cd /home/vmail
mkdir -p the-enlightened.de/amras
maildirmake the-enlightened.de/amras/Maildir
mkdir -p the-enlightened.de/aerith
maildirmake the-enlightened.de/aerith/Maildir

Als Nächses kommt die Postfix-Config dran. Dafür muss man wieder als root angemeldet sein (neues Terminal oder exit als user vmail). Die Config befindet sich in /etc/postfix/main.cf. Hier muss überprüft werden, dass myhostname auf den Rechnernamen gesetzt ist, ansonsten muss das nachgeholt werden. Das Feld mydestination muss meist nicht geändert werden, hier sollten localhost und ebenfalls der Rechnername eingetragen sein. Schlussendlich sollte inet_interfaces auf all stehen, aber das sollte ebenfalls bereits so sein. Wir springen ans Ende des file und fügen folgende Zeilen ein (die Domains sowie die uid und die gid [die wir uns ja gemerkt haben] sind natürlich entsprechend anzupassen):

#virtual domains & smtp auth
virtual_mailbox_domains = the-enlightened.de domain2.tld domain3.tld
virtual_mailbox_base = /home/vmail
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_minimum_uid = 100
virtual_uid_maps = static:1006
virtual_gid_maps = static:1001
virtual_alias_maps = hash:/etc/postfix/virtual          
smtpd_sasl_path = smtpd
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous 
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options

Dann abspeichern und die in der config gerade angebenen files erzeugen:

1 2	touch /etc/postfix/vmailbox touch /etc/postfix/virtual

Jetzt wird /etc/postfix/vmailbox editiert. Für jede Adresse wird die virtuelle Mailbox, in dem die Mails später landen sollen, angegeben, bei mir also z.B.

1 2	amras@the-enlightened.de the-enlightened.de/amras/Maildir/ aerith@the-enlightened.de the-enlightened.de/aerith/Maildir/

Wichtig ist hier der abschließende Slash, dadurch wird Postfix veranlasst, die Maildir-Struktur statt seiner eigenen zu benutzen. Die Angabe erfolgt also als Mailadresse + Leerzeichen/Tab + Pfad zum Maildir unter /home/vmail. Jetzt speichern und folgende Befehle ausführen:

1
2
3

postmap /etc/postfix/virtual
postmap /etc/postfix/vmailbox 
/etc/init.d/postfix reload

Ankommende Mails werden jetzt schonmal richtig einsortiert. Kommen wir also zum 2. Teil des Tutorials, dem Zugriff auf die Mails via Courier.

Hier kommen zuerst die Nutzerpasswörter an die Reihe. Dafür muss man weiter als root angemeldet sein. Wir ändern den Eintrag authmodulelist in /etc/courier/authdaemonrc auf
authmodulelist="authuserdb"

und legen mittels der folgenden Befehle die Nutzerpasswörter an:

userdbpw -md5 | userdb -f /etc/courier/userdb/the-enlightened.de amras@the-enlightened.de set systempw
(Passwort 2x eingeben)
userdbpw -md5 | userdb -f /etc/courier/userdb/the-enlightened.de amras@the-enlightened.de set home=/home/vmail/the-enlightened.de/amras/ gid=1001 uid=1006
 
userdbpw -md5 | userdb -f /etc/courier/userdb/the-enlightened.de aerith@the-enlightened.de set systempw
(Passwort 2x eingeben)
userdbpw -md5 | userdb -f /etc/courier/userdb/the-enlightened.de aerith@the-enlightened.de set home=/home/vmail/the-enlightened.de/aerith/ gid=1001 uid=1006
 
makeuserdb

Nach einem Neustart von courier-authdaemon (kA ob das nötig ist, schädlich ist es aber keinesfalls)
/etc/init.d/courier-authdaemon restart
können sich die eingetragenen Nutzer per POP oder IMAP (ggf. mit SSL) anmelden.

Um Mails versenden zu können (nicht von localhost sondern mit Anmeldung) erfordert es ein paar weitere Schritte. So muss die Datei /etc/postfix/master.cf editiert werden (als root). Hier wird beim ersten Eintrag (smtp) für den Parameter chroot ein “n” festgelegt. Mit der chrooted-Umgebung habe ich es nach unzähligen Versuchen nämlich nicht zum Laufen bekommen.

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       n       -       -       smtpd

Als finaler Schritt editieren wir nun die /etc/postfix/sasl/smtpd.conf wie folgt:

pwcheck_method: authdaemond
mech_list: PLAIN LOGIN
authdaemond_path: /var/run/courier/authdaemon/socket
#autotransition: true

autotransition:true wird meiner Erfahrung nach nur bei der Benutzung von saslauthd benötigt, authdaemond kommt ohne aus. Bei wem es nicht funktioniert möge trotzdem den Parameter mal testweise anstellen (Mailserver scheinen die verschiedensten Macken zu haben, die sie nicht-deterministisch auf diveren Konfigurationen behindern).

Nach einem Neustart von Postfix und ggf. dem Start von courier-authdaemon via /etc/init.d/courier-authdaemon start sollte der Mailserver nun voll funktionstüchtig sein.

VPN-Tunnel mit pptpd

Geschrieben von mrtnmueller am 18. August 2010 1 Kommentar(e)

Wenn man in öffentlichen, nicht verschlüsselten Netzwerken unterwegs ist ist es immer eine gute Idee, den gesamten Internetverkehr zu verschlüsseln. Und wenn man schonmal einen Rootserver hat…

Also habe ich mich entschieden pptpd aufzusetzen, weil es nicht nur von Windows nativ unterstützt wird sondern auch von fast allen modernen Mobilgeräten und auch von Linux. Die Konfiguration ist eigentlich sehr simpel, der “Trick-Teil” kommt am Ende. Für den muss ich mich bei “Lord Gurke” aus dem Serversupportforum bedanken.

Also, los gehts:

apt-get install pptpd

Das war schon alles, was man installieren muss. Nun folgt die Config. Zunächst kommt /etc/pptpd.conf dran. Hier werden u.a. die IP-Adressen für das neue Netzwerk bestimmt.

option /etc/ppp/pptpd-options
logwtmp
localip 192.168.1.1
remoteip 192.168.1.200-253

Das heißt im Klartext, dass mein Rootserver die IP 192.168.1.1 erhält und alle Clients automatisch Adressen von 200 bis 253 zugewiesen bekommen. Sehr komfortabel

Als nächstes wird /etc/ppp/pptpd-options editiert:

name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
ms-dns 192.168.1.1
proxyarp
nodefaultroute
mtu 1490
mru 1490
noipx
lock
nobsdcomp

Neben einigen für das System wichtigen Einstellungen wird hier eingestellt, dass der Rootserver seine Adresse als DNS-Server an die Clients pusht und dass nur das (noch) als sicher geltende MS-CHAPv2 als Authentifizierungsverfahren zum Einsatz kommt.

Die Benutzerdaten liegen bei pptpd leider unverschlüsselt im Keyfile, insofern sollte man vorsichtshalber einen zufälligen Schlüssel nehmen, den man sonst nirgends verwendet. Das Keyfile ist /etc/ppp/chap-secrets und wie folgt aufgebaut:

Username<TAB>*<TAB>Passwort<TAB>*
Das letzte Sternchen kann man dabei auch durch eine IP-Adresse oder einen IP-Adressbereich ersetzen, dann kann man nur aus diesem Netz bzw. von dieser IP auf den Server zugreifen.

Soa, jetzt zum “Trick-Teil”
PPTPD leitet in der bis jetzt geschaffenen Umgebung keine Internetanfragen weiter. Dazu muss über iproute erst noch eine Route eingerichtet werden:

1
2
3

iptables -A FORWARD -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -P OUTPUT ACCEPT

Das packt man am besten direkt in ein rc-Script damit es beim Serverneustart geladen wird.
Als letztes dann noch die /etc/sysctl.conf bearbeitet werden und die Zeile

net.ipv4.ip_forward = 1

von ihrer Kommentar-Raute befreit werden. Und fertig.

Trafficbeschränkung mit mod_cband unter Debian/Ubuntu

Geschrieben von mrtnmueller am 6. April 2010 Keine Kommentare

Jeder, der auf seiner Website Downloads anbieten möchte kommt irgendwann zu der Frage “Wie beschränke ich den Traffic”. In Zeiten der Flatrates denk man auf Userseite nur selten an Traffic-Limits. Doch viele Server und vServer haben noch begrenzten Traffic. Und selbst wenn nicht möchte man vielleicht die gleichzeitigen Downloads beschränken oder verhindern, dass Download-Traffic andere (interaktive) Inhalte ausbremst.

Hier kann das Apache-Modul mod_cband (http://codee.pl/cband.html) zum Einsatz kommen. Es ist schlank, sehr performant und bietet eigentlich alles, was man braucht (u.a. VHost-abhängige Limitierung, Limit pro User, Limitierung maximal zugelassener Connections, Ausbremsen oder Umleiten nach Erreichen des Limits etc.).

Um mod_cband zu installieren geht man wie folgt vor:

Als Erstes wird das Paket apache2-prefork-dev (und ggf. noch weitere benötigte Pakete) installiert:

1	apt-get install apache2-prefork-dev gcc build-essential

Danach holt man sich von der Entwicklerwebsite die neueste Version (zzT. 0.9.7.5) von mod_cband, entpackt das heruntergeladene Archiv in ein beliebiges Verzeichnis und führt configure aus:

wget http://cband.linux.pl/download/mod-cband-0.9.7.5.tgz
tar xf mod-cband-0.9.7.5.tgz
cd mod-cband-0.9.7.5
./configure

Jetzt muss man eine Änderung am Makefile vornehmen, wenn man ein 64-Bit-System hat. Die Zeile
APXS_OPTS=-Wc,-Wall -Wc,-DDST_CLASS=3
muss um den Parameter lm erweitert werden:
APXS_OPTS=-lm -Wc,-Wall -Wc,-DDST_CLASS=3

Speichern und das Modul kompilieren und installieren:
make && make install

Wenn alles glatt gegangen ist hat man jetzt in /usr/lib/apache2/modules/ eine funktionsfähige mod_cband.so liegen. Diese muss nun noch geladen werden. Dazu nimmt man sich /etc/apache2/httpd.conf oder die /etc/apache2/apache2.conf vor und fügt folgende Zeilen ein:

1
2
3

LoadModule cband_module /usr/lib/apache2/modules/mod_cband.so
CBandScoreFlushPeriod 1
CBandRandomPulse On

Die Config-Parameter sind übrigens für eine gute Performace wichtig. Wer sich gut auskennt kann natürlich auch die Verzeichnisse mods-available und mods-enabled nutzen

Als Letztes kommen wir nun zu den Beschränkungseinstellungen selbst. Diese kann man sowohl serverübergreifend (in httpd.conf oder apache2.conf) als auch VirtualHost-basiert vornehmen. Ich habe mich für Variante 2 entschieden, weil ich für meine Downloads die extra Subdomain downloads eingerichtet habe.

<VirtualHost *:80>
  ServerName downloads.yourdomain.com
  ServerAdmin webmaster@yourdomain.com
  DocumentRoot /var/www/downloads
  CBandSpeed 50Mbps 10 30
  CBandLimit 100G
  CBandExceededSpeed 5Mbps 5 15
  CBandScoreboard /var/run/yourdomain.scoreboard
  CBandPeriod 4W
  <Location /cband-status>
    SetHandler cband-status
  </Location>
  <Location /cband-status-me>
    SetHandler cband-status-me
  </Location>
</VirtualHost>

Mit diesen Einstellungen beschränkt man das Download-Volumen auf 100GByte in 4 Wochen. Der Speed liegt für alle Downloads zusammen bei 50 MBit/s, es sind 10 Requests pro Sekunde und 30 offene Verbindungen erlaubt. Falls das Volumen überschritten wird drosselt mod_cband den Speed auf 5 MBit/s, die maximal offenen Verbindungen auf 15 und die Requests pro Sekunde auf 5. Die “History”-Daten werden unter /var/run/yourdomain.scoreboard (diese Datei muss mit touch angelegt werden!) gespeichert. Unter /cband-status und /cband-status-me können Server- bzw. Userstatisikdaten abgerufen werden.

Alle verfügbaren Optionen listet http://codee.pl/cband_documentation.html auf, zusammen bilden sie einen Pool, der für fast jede Serversitaution die richtigen Konfiguration ermöglichen sollte.

mod_rewrite für ein “MVC”-ähnliches Verhalten

Geschrieben von mrtnmueller am 19. März 2010 Keine Kommentare

mod_rewrite sollte jedem, der schon etwas Erfahrung im Bereich Webprogrammierung hat, ein Begriff sein. Es wird häuftig verwendet, um “SEO-friendly” – also suchmaschienenoptimierte – URLs für dynamische Websites zu erzeugen. Auch das MVC-Modell sollte als geläufiges Entwurfsmuster bekannt sein. Nun braucht man aber nicht bei jedem Projekt MVC, denn kleine Projekte werden dadurch schnell sperrig; oft reicht auch einfach ein Umschreiben auf bestimmte URLs und die Verwendung einer Template-Engine. Leider konnte ich nirgends im Web ein Beispiel finden wie man jetzt genau http://domain.com/user/add in http://domain.com/user.php?action=add umschreibt.

Daher nun hier mein Bespiel einer .htaccess, die genau das ermöglicht:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule   ^([^/]+)/?([^/]*)/?    /$1.php?action=$2

Die RewriteCond verhindert hier, dass Dateien, die wirklich über diese URL erreichbar sind, ebenfalls umgeschrieben werden (wäre schlecht für Bilder, CSS usw.). Wenn man das Muster ([^/]*)/? wiederholt anhängt kann das genutzt werden, um noch tiefere Pfade in weitere Parameter umzusetzen, z.B. würde

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule   ^([^/]+)/?([^/]*)/?([^/]*)/?    /$1.php?action=$2&param=$3

dafür sorgen, dass man auch http://domain.com/user/view/45 in http://domain.com/user.php?action=view&param=45 umsetzen kann. So sind beliebige Pfadtiefen nutzbar.

Zu beachten ist, dass man im verarbeitenden Script die Parameter in $_GET nicht auf Existenz sondern mit Hilfe der Funktion empty() testen sollte, da automatisch leere Strings als Parameter übergeben werden falls der Pfad nicht die maximale Tiefe erreicht.

Server via VNC einfach fernsteuern (Debian)

Geschrieben von mrtnmueller am 12. März 2010 2 Kommentar(e)

VNC ist vielen Admins bekannt – doch meist als zu sperrige ressourcenfressende Lösung angesehen. Zudem hängt VNC der Ruf an, schwer einzurichten zu sein. Dass das nicht so sein muss möchte ich mit diesem kleinen Tutorial zeigen. Das Tutorial ist für Debian, funktioniert aber natürlich wie gewohnt auf allen Debian-Derivaten und mit Nutzung der entsprechenden Paketmanager wahrscheinlich auch auf anderen Linux-Systemen.

Das Tool der Wahl für Debian heißt VNC4Server, es benötigt im Gegensatz zu den meisten anderen VNC-Servern kein installiertes X-System! Neben dem VNC-Server wird natürlich auch noch ein Window-Manager benötigt. Ich habe mich hier der Einfachheit halber und weil es sehr ressourcenschonend ist für Fluxbox entschieden.

Die benötigten Pakete installiert man (als root) also mit

1	apt-get install vnc4server fluxbox

Danach sollte man den root-Account wieder einmotten und per vnc4passwd ein Passwort für die Verbindung vergeben.
Achtung: die Verbindung ist von Haus aus trotzdem nicht verschlüsselt. Dafür nutzen wir später einen SSH-Tunnel. Daher im Startbefehl auch der Parameter localhost – damit wir uns nur per Tunnel verbinden können

Das Setzen des Passworts sollte bereits einen Ordner “.vnc” (per default ist dieser unsichtbar) im home-Ordner des Nutzers angelegt haben. Dort hinein kommt eine Datei mit dem Namen “xstartup” und folgendem Inhalt:

#!/bin/sh
 
# Uncomment the following two lines for normal desktop:
# unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc
 
[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
#twm &
fluxbox &

Das Script wird automatisch geladen sobald VNC4Server gestartet wird und sorgt dafür, dass fluxbox und ein xterm-Fenster zur Verfügung stehen. Natürlich kann man hier auch direkt beliebige weitere Programme starten lassen. Das Abspeichern der Datei “xstartup” nicht vergessen. Danach noch das executable-Recht vergeben:
chmod +x xstartup

Den Server können wir nun mittels

1	vnc4server -geometry 1024x768 -depth 24 -name "MyDesktop" -localhost

starten, die Startparameter sind selbsterklärend. Eine hohe Auflösung und Farbtiefe heißt in jedem Fall natürlich auch höherer Bandbreitenverbrauch. Mit dem obrigen Parameter -localhost wartet VNC4Server auf Verbindungen nur von der lokalen Maschine und zwar auf dem Port 5900+DisplayNummer. Das bedeutet im Normalfall wird das Programm einfach auf 5901 lauschen.

Über SSH können wir uns jetzt mit dem Server verbinden:

unter Linux:
vncviewer -via user@host localhost:0
host steht dabei für die IP-Adresse oder den Hostnamen des Servers, user für den Benutzernamen, mit dem die (SSH-)Anmeldung auf dem Server erfolgen soll.

unter Windows:
Hier muss man zunächst z.B. per Putty einen SSH-Tunnel anlegen (eine Anleitung findet sich zum Beispiel auf dieser Website SSH-Tunneling auf Windows-Computern unter dem Punkt “Einrichtung auf Client-Seite”) und sich dann z.B. mit der kostenlosen VNC Viewer Free Edition 4.1 for Windows zu 127.0.0.1:5901 verbinden.

Nächste Seite »

martin-mueller.info