Wissenswertes zu Opensourcesoftware und IT
Hauptsächlich der Härtung der Version 2.8.4 widmet sich das neue Update von WordPress (2.8.5). Als Download ist es wie immer zu finden unter: http://wordpress-deutschland.org/
Da es von Version 2.8.4 auf Version 2.8.5 keine Datenbankänderungen gegeben hat, kann auch das Upgradepaket verwendet werden, welches ebenso von WordPress Deutschland zur Verfügung gestellt wird. Die Dateien können per FTP über eine bestehende Installation einfach „drüberkopiert“ werden.
Da ich zur Zeit offenbar in Experimentierlaune bin, habe ich heute mein uraltes Notebook hervor gekramt. Die Aufgabenstellung lautete: „Installation eines OS, um mit dem alten ‚Kastl‘ noch etwas anfangen zu können“.
Die Installation verlief relativ problemlos, da u.a. der PCMCIA Adapter out of the Box erkannt wurde. Bis zum Start von Xorg keine Auffälligkeiten.
Der Start von Xorg endete mit einem schwarzen Bildschirm. Es war nötig, per STRG ALT F2 in eine Konsole zu wechseln und eine manuelle xorg.conf zu erstellen. (Minimal um als Treiber „vesa“ einzustellen“). Xorg läuft.
Für Gnome war das Gerät dann doch zu lahm. Also installierte ich, nach einem Tip aus dem #debian-de Channel LXDE, einen sehr schlanken und dennoch hübschen „Desktop“ (Windowmanager).
Erste Gedanken: Oh, sieht gut aus… ist schnell… unglaublich!
Nach Aktivierung des non-free Repository war es mir dann noch möglich, die Firmware zur Verwendung des Zydas WLAN USB Stick, zu installieren. Wlan funktionierte.
Mangels der notwendigen Kompatibilität der Flashplayeralternativen mit aktuellen Flashinhalten, fand schließlich noch das Adobe Flashplugin den Weg auf die Platte.
Tja, irgendwas muss wohl immer „los sein“. Der Tridenttreiber hat seine Eigenheiten und führt, ohne Konfiguration über die xorg.conf, zu einem schwarzen Bildschirm. Ohne diesen Treiber (mit „vesa“) leidet die Grafikperformance.
Recherche im Internet: Beitrag Nr. 8 (xorg.conf copy and paste) des Ubuntuforum.org brachte die Lösung -> http://ubuntuforums.org/showthread.php?t=587668
Zu meiner Schande muss ich gleich mal festhalten, dass ich bislang noch nie dazu gekommen bin, mich mit Postfix auseinander zu setzen. Immerwiede hab ich angefangen, diesen funktionellen und sicheren Server (Dienst) zu installieren und dann ist mir -wie sooft- die Zeit davon gelaufen.
Natürlich befinde ich mich ausschließlich in einer Testumgebung! Es wäre unverantwortlich, würde ich meine zaghaften Versuche, mit dem noch unbekannten Wesen „postfix“, quasi „in the wild“ vom Zaun brechen.
Ich begebe mich nicht ganz ohne „Begleitschutz“ auf diese Reise. Nein! Das Buch „Linux-Server mit Debian GNU/Linux“ (ein meiner Meinung nach ausgezeichnetes Werk) begleitet mich. Deshab schildere ich hier, basierend auf den Schritten im Buch, meine Höhenflüge und wahrscheinlich auch Abstürze. 🙂
Was will ich überhaupt fürs erste erreichen? Ich will, dass lokale User von meiner fiktiven Domain linux.local Emails per SMTP an ebenso lokal verwaltete User schicken können. HIerfür kommt das SMTP Protokoll zum Einsatz. Desweiteren sollen die User die gesendeten Emails per POP-Postfach abrufen können. Naja, jeder fängt mal klein an!
Postfix zu installieren, stellt mich vor kein großes Problem:
Die Konfigurationsdateien findet man im Verzeichnis /etc/postfix. Postfix hat grundsätzlich 2 „Konfigurationsdateien“:
Die main.cf beinhaltet sämtliche Konfigurationsparameter, die master.cf definiert die Transportwege und einige sehr wichtige andere Parameter.
Erster Anlaufpunkt ist die Datei main.cf!
Sieht bei mir wie folgend aus. (Ich habe ausschließlich die fett geschriebenen „Variablen“ angepasst).
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name
biff = no
# appending .domain is the MUA’s job.
append_dot_mydomain = no
# Uncomment the next line to generate „delayed mail“ warnings
#delay_warning_time = 4h
readme_directory = no
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
myhostname = linux.local
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = linux.local,
localhost
relayhost =
mynetworks = 127.0.0.0/8 192.168.1.0/24
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = 127.0.0.1 192.168.1.235
default_transport = error
relay_transport = error
Diese Kommandos sind als root auszuführen. Der Parameter -s mit Wert /bin/false weist den Usern keine Loginshell zu, denn direkt am System, haben diese User nichts zu suchen.
Die User haben nun also folgende Mailadressen:
An diese Adressen gesendete Emails sollten in /var/mail/<Benutzername> landen.
Laut den erstellten Daten (oben) erfolgt die Clientkonfiguration:
Ich hab hier auch die POP Daten angegeben, jedoch läuft noch kein POP-Dienst, weshalb (logischerweise) ein POP Abruf zu einem Fehler führt. Dennoch sollte SMTP Versand funktionieren. Zu diesem Zwecke schick ich mir selbst (dummy1@linux.local) eine Email.
Wir haben an dummy1@linux.local gemailt. Siehe da! Es gibt eine Textdatei mit Namen „dummy1“. Was wird da wohl drinnen sein:
Bingo! Meine Email ist angekommen!
Für den Anfang teste ich „qpopper“, den man mittels:
installiert.
Das gute daran, das „Programm“ benötigt keinerlei Konfiguration, um zu funktionieren! Die Benutzerdaten sind beim Mailclient hinterlegt (Es sei nochmals festgehalten, dass als Passwort das Passwort des jeweils angelegten User verwendet wird!)
Der erste Versuch eine Abrufes scheitert… Keine Verbindung zum POP-Server… Die Fehlersuche bleibt erfolglos. Schließlich komme ich auf die Idee, Postfix zu restarten:
Erneuter Abrufversuch… Erfolg!
Anmerkung: In diesem Tutorial (besser gesagt Experiment) werden u.a. Plain-Text (Klartext) Passworter zur Authentifizierung verwendet. Für einen Produktiveinsatz ist diese Konfiguration nicht geeignet!
Gerade habe ich mir überlegt, ob ich hier noch ein paar Zeilen darüber „verlieren“ will, wie man auf dem -im vorhergehenden Artikel- installierten LAMP Server WordPress (Aktuell in Version 2.8.4) installiert. Einerseits ist die Installation des beliebten und sehr ausgereiften Blogging-Systems so einfach, dass man fast nichts falsch machen kann, andererseits hab ich mir nun so nen schönen LAMP-Server eingerichtet 😉
Auf geht’s in den Konsole (Terminal). Diese Aktionen sind als root auszuführen:
Per Webbrowser loggt man sich mit dem User root und dem gewählten MySql Passwort in phpmyadmin ein. (localhost/phpmyadmin):
Wie im Screenshot ersichtlich, soll die Datenbank „wordpress2“ heissen. Als Zeichensatz wähle ich hier „utf8_general_ci“. Ein Klick auf „Anlegen“ vollendet die Aktion und legt die leere Datenbank an.
Gut, weiter gehts. Es wird noch ein User benötigt. Ich erwähne hier abermals, dass man NIE mit dem User root diverse Datenbankverbindungen (egal welche Art der Website bzw. welches CMS, Bloggingsystem…) herstellen soll. In der lokalen Umgebung mag das ja egal sein, im Internet sieht das aber anders aus.
Durch einen Klick auf das Häuschensymbol (ganz links unter dem Schriftzug phpMyAdmin im GUI) gelangt man wieder auf die Startseite von phpmyadmin. Es folgt ein Klick auf den Reiter „Rechte“ (im rechten Bereich des Fensters):
Die Textfelder werden ausgefüllt. Bei Host ist Lokal zu wählen. Ein beliebiges Passwort für den User (hier dbuser) kann gewählt werden. Es wird keine Datenbank für den Benutzer erstellt. Ebenso wird bei Globale Rechte NICHTS angehakt. Durch Klick auf Ok, ist nun auch das erledigt. Der User ist angelegt.
Nun bekommt der User „dbuser“ seine Datenbank. Die Aktion läuft abermals über den Reiter „Rechte“. Wie man sieht, ist der user „dbuser“ angelegt und hat als Berechtigung noch „Usage“. Usage steht für keine Berechtigungen. Rechts in der Zeile des User „dbuser“ hat man die Möglchkeit, die Rechte durch Klick auf das Symbol zu bearbeiten (Klick auf das Bild um es zu vergrößern):
Auswahl der für WordPress erstellten Datenbank:
Häkchen wählen, um die Rechte zu setzen:
Ich habe hier bei Struktur alle Häkchen gesetzt, da sonst die WordPressinstallation nicht erfolgreich abgeschlossen werden kann. (Es muss ermöglicht werden, dass die Installationsprozedur Tabellen anlegt, befüllt verändert…)
Abschluss der Rechtevergabe durch Klick auf OK im Fenster Datenbankspezifische Rechte.
Wie ganz oben im Artikel erwähnt lade ich WordPress von WordPress-Deutschland herunter. Die Zipdatei wird entpackt und der entpackte Inhalt nach /var/www/wordpress kopiert. Beim Kopiervorgang muss beachtet werden, dass (wenn man als root kopiert) Die Berechtigungen eventuell auf Besitzer root Gruppe root geändert werden. Dies kann einerseits vermieden werden in dem dem Befehl cp der Parameter -a mitgegeben wird, andererseits kann man jedoch die Dateiberechtigungen auch nachträglich setzen.
Ein Kopiervorgang von Konsole könnte zb so aussehen (Quellverzeichnis: /home/user/wp28, Ziel /var/www/wordpress):
Dies hat zur Folge, dass die Daten zwar in /var/www/wordpress landen, jedoch der Besitzer der User „user“ ist und die Gruppe ebenso auf „user“ steht.
Ein Umsetzen des Besitzers (chown) der Gruppe (chgrp) erfolgt so:
Alle Dateien / Verzeichnisse besitzt nun „user“ als Gruppe ist „www-data“ eingetragen. Zuguter letzt setzen wir für alle Ordner und Dateien noch die Zugriffsrechte für user und www-data auf 670, was soviel heißt wie, dass der Benutzer „user“ lesen und schreiben darf, die Gruppe www-data lesen, schreiben und ausführen dürfen.
Entweder ist es schon zu spät, aber ich dachte, dass es eigentlich mit den Berechtigungen 660 auch gehen müsste. Dies führt jedoch zu einem Access Denied und die Error.log des Apache meldet ein Zugriffsproblem auf die index-Datei – wieso, entzieht sich zu später Stunde meiner Kenntnis…?
So nun gilts! Browser starten und als Adresse localhost/wordpress eingeben… und hoffen…
Die Datei wp-config.php scheint nicht vorhanden zu sein. Wir benötigen sie aber um mit der Installation zu beginnen….
Soweit so gut. Klick auf Weiter… Klick (ganz unten) auf den Button „…kann es jetzt losgehen„…
Befüllen der Felder mit den Userdaten des angelegten DB-User:
Klick auf Absenden… Im nächsten Fenster (welches erscheint, sofern die eingegebenen Daten ok waren) Starten wir die Installation wählen… Blogtitel eingeben, Mailaddi eingeben, angezeigtes Passwort merken(!), auf anmelden klicken.
Als Username admin verwenden, als Passwort das vorhin angezeigte und freuen. Wir landen am Dashboard.
Jedenfalls muss ich noch klären weshalb es mt anderen Berechtigungen (noch) nicht funktioniert. Das kann so nicht stehen bleiben 😉
Update: Folgende Info findet man auf wordpress-deutschland.org:Normal sollte 755 (Verzeichnisse) und 644 (Dateien) reichen. Eventuell noch das Uploads-Verzeichnis hochsetzen.
