Archiv der Kategorie: tutorial

MySQL root-Passwort vergessen?

Passend zum heißesten Tag des Jahres, gibt es einen Kurztipp für eine Situation, in der es einem auch ganz schön warm werden kann.

MySQL Passwort vergessen

Mal gesetzt den Fall, man vergißt oder verbummelt sein MySQL root-Passwort. Passiert euch nicht? Ok, dann sagen wir einfach, $haustier hats gefressen ;). Was dann? Ganz einfach, Terminal auf, und los gehts:

  1. sudo /etc/init.d/mysql stop # Stoppen des MySQL-Server-Prozesses
  2.  
  3. sudo mysqld_safe --skip-grant-tables # MySQL-Server ohne Zugangsdatentabelle starten
  4.  
  5. # In einem neuen Terminal dann
  6. mysql --user=root mysql # Als root am MySQL-Server anmelden
  7.  
  8. update user set Password=PASSWORD('hier-neues-passwort-hin') where user='root'; # neues Passwort setzen
  9.  
  10. flush privileges; # neuladen der Benutzertabellen
  11.  
  12. exit; # MySQL Kommandozeile verlassen

Dann zurück ins alte Terminal und den MySQL-Prozeß stoppen und anschließend den Server inklusive Benutzertabellen neu starten

  1. sudo /etc/init.d/mysql start

Anschließend das neue Passwort nicht wieder vergessen und fertig...fast zu einfach, oder?

Was steht bei euch heute an? Schwitzen am Schreibtisch? Oder twittern aus dem Freibad? Ich "wähle" Tor 1 :/

Lighttpd mit vHosts unter Ubuntu Hardy

Seit einiger Zeit tendiere ich dazu Lighttpd dem guten alten Apachen vorzuziehen. Hauptgrund dafür ist aber weniger die immer wieder hervorgehobene bessere Performance (nicht umsonst setzen z.B. YouTube und MySpace auf den Ultraleichtflieger), sondern das mir die Konfiguration einfach etwas unkomplizierter erscheint als beim, vielleicht etwas mächtigeren, aber dafür auch unübersichtlicheren Apachen. Eigentlich auch egal, denn jeder sollte ja selbst entscheiden wem er den Vorzug gibt.

Eingerichtet wird Lighty hier mit PHP 5 und dem Modul 'simple_vhost', mit dem sehr einfach mehrere virtuelle Hosts angelegt werden können.

Wenn wir fertig sind, werden die Seiten unter folgender Ordner-/Dateistruktur organisiert sein:

/var/www/servers - quasi das Hauptverzeichnis des Webservers, hierin werden die virtuellen Hosts angelegt

/var/www/servers/example.com - Ein Beispiel für einen virtuellen Host

/var/www/servers/example.com/htdocs - Hier landen die Dateien, die beim Aufruf von "http://example.com" angezeigt werden sollen

/var/www/servers/example.com/logs - Hier werden die Logdateien gesammelt

/var/www/servers/example.com/server.conf - In dieser Datei wird die Konfiguration für den Host vorgenommen

So, aber nun direkt rein ins Getümmel und die Installation starten:

Installieren

  1. sudo apt-get install lighttpd php5-cgi

Module aktivieren

Danach werden die oben angesprochenen Module aktiviert ('fastcgi' wird für die Anbindung an PHP benötigt):

  1. sudo lighty-enable-mod fastcgi
  2. sudo lighty-enable-mod simple-vhost

Nach einem 'sudo /etc/init.d/lighttpd force-reload' sollte der der Webserver bereits unter http://localhost erreichbar sein.

Lighttpd Testseite

Konfiguration von mod_simple_vhost

Ausgegangen von der oben erklärten Ordnerstruktur müssen die drei Optionen des 'mod_simple_vost' in der Datei '/etc/lighttpd/conf-available/10-simple-vhost.conf' folgendermaßen konfiguriert werden:

  1. simple-vhost.server-root = "/var/www/servers/"
  2. simple-vhost.document-root = "/htdocs/"
  3. simple-vhost.default-host = "example.com"

Anstatt 'example.com' muss dort natürlich eure Standarddomain stehen!

Danach sollten die angelegten vHosts unter der jeweiligen Domain erreichbar sein.  Dazu ein kleines Beispiel:

Wenn im Browser die Adresse 'http://zeroathome.de/dingsbums.html' aufgerufen werden würde, würde das zur Anzeige der Datei '/var/www/servers/zeroathome.de/htdocs/dingsbums.html' führen.

Nach einem '/etc/init.d/lighttpd force-reload' können neue vHosts unterhalb von '/var/www/servers/' angelegt werden.

Konfiguration der einzelnen vHosts

Problem bei dieser Variante der vHost-Konfiguration ist, dass die Konfiguration der einzelnen Hosts nicht so einfach ist. Doch Opensource wäre nicht was es ist, wenn es nicht auch dafür eine relativ einfache Lösung gäbe. (Die Grundversion stammt übrigens von hier, wurde von mir nur leicht angepasst: http://redmine.lighttpd.net/projects/lighttpd/wiki/HowToSupportConfigurationPerVirtualHost)

Dazu wird die folgende Zeile in die Datei '/etc/lighttpd/conf-available/10-simple-vhost.conf' eingefügt, die dazu führt das ein kleines Skript ausgeführt wird:

  1. include_shell "/var/www/servers/config_servers"

Anschließend wird die Datei '/var/www/servers/config_servers' angelegt und mit diesem Inhalt befüllt:

  1. #!/bin/bash
  2.  
  3. for VHOST in `find /var/www/servers/ -mindepth 1 -maxdepth 1 \( -type d -or -type l \) -exec test -e "{}/server.conf" \; -exec basename "{}" \; 2>/dev/null` ; do {
  4. echo "\$HTTP[\"host\"] == \"$VHOST\" {"
  5. echo "var.vhost_name = \"$VHOST\""
  6. echo "var.vhost_path = \"/var/www/servers/$VHOST\""
  7. cat "/var/www/servers/$VHOST/server.conf"
  8. echo "server.errorlog = \"/var/www/servers/$VHOST/logs/error.log\"",
  9. echo "accesslog.filename = \"/var/www/servers/$VHOST/logs/access.log\""
  10. echo "}"
  11. } ; done

Zu guter Letzt wird die Datei noch ausführbar gemacht:

  1. sudo chown www-data:www-data /var/www/servers/config_servers
  2. sudo chmod u+x /var/www/servers/config_servers

Dann natürlich noch ein '/etc/init.d/lighttpd force-reload' und die neue Konfiguration ist übernommen.

Die Konfigurationsdatei muss dann, wie oben bereits erwähnt unter '/var/www/servers/example.com/server.conf' liegen um berücksichtigt zu werden. Nachdem eine neue Konfigurationsdatei hinzugefügt wurde oder eine vorhandene geändert wurde, muss immer ein '/etc/init.d/lighttpd force-reload' erfolgen, sonst ist die Konfiguration nicht wirksam!

Fertig!

So, das wars bereits. Ein Grundkonfigurierter Lighty fertig für die Arbeit als lokaler oder Internet-Webserver. Wenn gewünscht gibts demnächst noch einige Erweiterungen, wie zum Beispiel SSL oder WebDAV.

Alle Angaben natürlich wie immer ohne Gewähr und alles auf eigene Gefahr und so!

W-LAN der Uni-Marburg mit Wicd nutzen

Da meine schöne (noch) Uni in Marburg zwar (löblicherweise) Informationen bereit stellt wie man unter Linux mit Hilfe des Network-Managers oder wpa_supplicant in das per EAP-TTLS gesicherte W-Lan-Netzwerk kommt, aber meinem Lieblingsnetzwerkverwalter Wicd keine Anleitung gewidmet wurde, holen wir das schnell mal nach. Zum Glück bietet Wicd die großartige Möglichkeit eigene Templates anzulegen, um neue Verschlüsselungsarten hinzuzufügen (nicht falsch verstehen, die gängigen sind schon mit dabei). Diese Templates basieren auf den Konfigurationsdateien für wpa_supplicant und eine Anleitung zur Umsetzung eurer Lieblingsverschlüsselung findet ihr hier: http://wicd.sourceforge.net/templates.php

Doch nun ans Werk.

Zunächst muss das Root-Zertifikat von der Uni-Seite heruntergeladen werden, dieses befindet sich hier: http://www.uni-marburg.de/hrz/internet/wlan/deutsche-telekom-root-ca-2.pem. Gespeichert werden sollte es an dem dafür vorgesehenen Ort: '/etc/ssl/certs/'. Dies muss mittels sudo gemacht werden:


cd /etc/ssl/certs
sudo wget http://www.uni-marburg.de/hrz/internet/wlan/deutsche-telekom-root-ca-2.pem

Bin mir gerade nicht sicher ob das Tool 'wget' zur Standardinstallation gehört, zur Not halt einfach installieren 😉

Anschließend wird aus folgender wpa_supplicant Konfiguration:

network={
ssid="UMRnet_students"
identity="Username@students.uni-marburg.de"
password="MeinPasswort"
proto=WPA
group=TKIP
pairwise=TKIP
eap=TTLS
key_mgmt=WPA-EAP
ca_cert="/etc/ssl/certs/deutsche-telekom-root-ca-2.pem"
anonymous_identity="anonymous"
phase2="auth=PAP"
priority=2
}

wie durch Zauberhand dieses Template für Wicd:


name = EAP-TTLS
author = Benjamin Zimmer
version = 1
require identity *Identity password *Password ca_cert *Path_to_CA_Cert anonymous *Anonymous
-----
ctrl_interface=/var/run/wpa_supplicant
network={
ssid="$_ESSID"
scan_ssid="$_SCAN"
identity="$_IDENTITY"
password="$_PASSWORD"
proto=WPA
group=TKIP
pairwise=TKIP
eap=TTLS
key_mgmt=WPA-EAP
ca_cert="$_CA_CERT"
anonymous_identity="$_ANONYMOUS"
phase2="auth=PAP"
priority=2
}

Erklären werd ich den Spaß mal nicht, da das auf der Wicd Seite reichen sollte, falls doch Fragen sind, Finger heben und bitte nicht Schnipsen 😉

Diese Datei wird als '/etc/wicd/encryption/templates/eap-ttls' gespeichert und anschließend in die Datei '/etc/wicd/encryption/templates/active' folgende Zeile ganz unten eingetragen:

eap-ttls

Dann die Wicd Gui öffnen, oben auf Aktualisieren (Refresh) klicken und die erweiterten Einstellungen des UMR-Netzwerkes aufrufen:WLAN Uni Marburg mit Wicd

In diesen Dialog müsst ihr euren Benutzernamen, das Passwort, den Pfad zum heruntergeladenen Root-Zertifikat eintragen und in das letzte Feld 'anonymous' eintragen, fertig. Anschließend genügt ein Klick auf Verbinden (Connect) und die Geschichte läuft 🙂 (hoffentlich)

Getestet wurde das ganze von mir unter (K)Ubuntu Jaunty mit Wicd Version 1.5.9

Spam- und Virenfilter für den Mailserver mit Spamassassin und ClamAV

Mailboxes

Nachdem wir ja letztes Mal die Grundkonfiguration des Mailservers abgeschlossen haben, gibt es heute zwei Extras, die nicht fehlen sollten. Und zwar Spam- und Virusfilter. Ersteres wird bei uns Spamassassin erledigen, die Viren überlassen wir dem freien Virenscanner ClamAV.

Zur Tat. Erst natürlich die benötigte Software installieren:
sudo apt-get install spamassassin spamc clamav clamav-daemon mutt cpio arj zoo nomarch lzop cabextract pax unrar lha

Wie ihr seht werden auch einige Packer/Entpacker mit installiert, damit ClamAV auch zum Beispiel zip-Archive prüfen kann.

Spamassassin einrichten

Dazu bearbeiten wir die Datei '/etc/spamassassin/local.cf' wiefolgt:

rewrite_header Subject ***SPAM***
Wenn diese Zeile aktiv ist wird in jeder Spam-Mail '***SPAM***' am Ende der Betreffzeile angehängt.
Diese Zeile bestimmt ab welchem Wert Mails als Spam markiert werden:
required_score 6.31
Ebenfalls de-kommentieren und den Wert entsprechend ändern. Falls zu viel Spam durchkommt sollte dieser Wert gegebenenfalls nach unten korrigiert werden, bzw. anders herum wenn zu viele reguläre Mails das Spam-Tag erhalten.
Diese beiden Zeilen sorgen dafür das der Bayessche Filter zum erkennen von Spam benutzt wird und dieser automatisch trainiert wird:
use_bayes 1
bayes_auto_learn 1

Um unseren Bayes-Filter nicht durch Header zu verwirren, die von anderen Mailservern (z.B. dem des Providers) oder unserem getmail angefügt wurden, werden diese durch die folgenden Zeilen ignoriert:
bayes_ignore_header X-Bogosity
bayes_ignore_header X-Spam-Flag
bayes_ignore_header X-Spam-Status
bayes_ignore_header X-getmail-filter-classifier

Danach muss Spamassassin noch aktiviert werden, dazu wird in der Datei '/etc/default/spamassassin', die Zeile "ENABLED=0" in "ENABLED=1" umgeschrieben.

Dann kann Spamassassin gestartet werden:
sudo /etc/init.d/spamassassin start

Jetzt müssen wir nur noch getmail sagen, das es Spamassassin die Mails zur Prüfung geben soll. Dazu fügen wir folgenden Absatz in die 'getmailrc' des jeweiligen Benutzers ein:
[filter-spamassassin]
type = Filter_external
path = /usr/bin/spamc
arguments = ("--max-size=100000", )

Beim nächsten Aufruf von getmail sollte dieses die empfangenen Mails durch Spamassassin checken lassen. Prüfen kann man das wiefolgt:
Mail an die entsprechende Mail-Adresse schicken, dann getmail als Benutzer (nicht als root) aufrufen:
getmail
Dann den Posteingang checken:
mutt -f /home/benutzer/mail
Dort sollte dann eine E-Mail liegen, die mit Enter aufgerufen wird. Im oberen Bereich sollten dann Zeilen ähnlich dieser gefunden werden:
X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on server
Dann wurde alles richtig gemacht, ansonsten noch einmal alle Einstellungen checken, bzw das getmail-Log unter '/home/benutzer/.getmail/log'.

ClamAV einrichten

Da wir ClamAV oben schon mit installiert haben und er von sich aus schon eingerichtet ist, muss nur der folgende Abschnitt in die getmailrc des jeweiligen Benutzers eingefügt werden:
[filter-clamav]
type = Filter_classifier
path = /usr/bin/clamdscan
arguments = ("--stdout", "--no-summary", "-")
exitcodes_drop = (1, )

Damit werden Mails die Viren enthalten automatisch verworfen. Falls das nicht gewünscht ist und die Mails trotzdem zugestellt werden sollen (was ich nicht unbedingt empfehlen würde), muss die letzte Zeile so lauten:
exitcodes_keep = (0,1)

Damit wäre auch diese Einrichtung geschehen und es kann Spam- und Virenfrei ge-E-mailt werden.

Um die Mails in eurem Mail-Programm automatisch in den Spam-Ordner werfen zu lassen, müsst ihr dort einstellen das die Header von Spamassassin benutzt werden sollen. Wie das geht findet ihr in der Dokumentation eures jeweiligen Mailprogrammes.

Natürlich gilt auch hier wieder: Für etwaige Schäden, oder ähnliches was durch Benutzung dieses Tutorials geschehen sollte, übernehme ich keine Haftung. Das Setup habe ich selbst in Betrieb und es funktioniert. Schreibfehler sind aber natürlich nicht ausgeschlossen. Falls euch etwas auffällt bitte ich um eine kurze Nachricht, damit ich gegebenenfalls Korrekturen machen kann.

Ubuntu (8.04 LTS) Mailserver mit Postfix, Dovecot und Getmail

Mailboxes

Heute gibts mal wieder ein kleines Tutorial. Viele haben angefragt wann denn endlich das Mailserver-Tutorial auch für Hardy verfügbar ist, und was soll ich sagen...hier ist es: Heute richten wir einen Mailserver auf Ubuntu Hardy Heron (8.04 LTS) mit Hilfe von Postfix, Dovecot, Getmail. Doch zunächst eine kleine Übersicht wer im Konzert welches Instrument spielt:

Diagramm lokaler Mailserver

Um das Bild mal in einen alltäglichen Vorfall zu implementieren mal das folgende Beispiel:
Jemand schickt euch eine E-Mail an eure Adresse . Diese landet auf dem Server eures Providers (ProviderPOP3). Getmail, welches auf unserem Server installiert ist fragt die Mail ab und transferiert sie vom Provider-Server auf den lokalen Server und schiebt sie in das Mail-Verzeichnis des zugehörigen Benutzers. Der Benutzer fragt nun mit seinem Mail-Client (Thunderbird, Evolution, Outlook etc.) beim lokalen Server nach ob neue Mails für ihn gekommen sind und Dovecot liefert ihm die eingegangene Mail entweder per POP3 oder IMAP aus. Nachdem der Benutzer die Mail gelesen hat, will darauf antworten. Nach dem Klick auf "Senden" im Mail-Client empfängt Postfix die Mail und leitet sie an den Server beim Provider weiter (Provider-SMTP) der die Mail dann an sein endgültiges Ziel bringt.

Weiterlesen