Zwar unfair (weil SSD), aber dennoch… 🙂
So kann ein schneller Bootvorgang aussehen:
Debian Squeeze auf einem Oldtimer
Neue Software, uralte Hardware
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 Eckdaten
- PIII 800 Mhz
- 128MB Ram
- 10 GB Festplatte
- USB Wlan-Stick Zydas (genaue Bezeichnung hab ich grade nicht hier)
- Dlink PCMCIA Fast Ethernet Adapter DFE 650 TXD
- Installation über Squeeze Network Installer
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.
Das große Problem
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
Experimente mit Postfix Teil 1
Vorwort
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.
Mein Begleiter
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. 🙂
Zielsetzung
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!
Los gehts!
Postfix zu installieren, stellt mich vor kein großes Problem:
- apt-get install postfix (Return)
Die Konfigurationsdateien findet man im Verzeichnis /etc/postfix. Postfix hat grundsätzlich 2 „Konfigurationsdateien“:
- main.cf
- master.cf
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!
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
2 User / Mailboxen „bauen“
- useradd -m dummy1 -s /bin/false
- useradd -m dummy2 -s /bin/false
- Passwörter setzen mit: passwd dummy1 bzw. passwd dummy2
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:
- dummy1@linux.localhost
- dummy2@linux.localhost
An diese Adressen gesendete Emails sollten in /var/mail/<Benutzername> landen.
Test mit einem Emailclient
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.
Check per Konsole
- cd /var/mail
- ls
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!
Einfacher POP Abruf
Für den Anfang teste ich „qpopper“, den man mittels:
- apt-get install qpopper
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:
- /etc/init.d/postfix restart
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!
WordPress Installation
Die Testumgebung steht
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 😉
Was braucht man? (Kurzversion)
- Ausgangsbasis ist ein funktionierender LAMP-Server, der in der Standardinstallation vorliegt.
- Das Rootverzeichnis des Webserver (für die Webseiten) liegt auf /var/www
- Für die Testinstallation wird ein Verzeichnis /var/www/wordpress angelegt (Achtung Berechtigungen!)
- Auch notwendig ist eine leere Mysql-Datenbank, die relativ einfach per phpmyadmin anzulegen ist
- Ein nächster wichtiger Punkt ist die Anlage eines Mysql-User, der ausschließlich auf die WordPress-Datenbank zugreifen darf. Dies sollte nie der root User sein! (root darf bekanntlich alles). Die Anlage des User inkl. Rechtevergabe lässt sich mit phpmyadmin erledigen.
- Es erfolgt der Download der aktuellsten WordPressversion (wie immer von: http://wordpress-deutschland.org/)
- Die Zip-Datei wird entpackt und per FTP Client auf den Webspace kopiert. In der Testumgebung sind die Dateien in das Verzeichnis /var/www/wordpress zu kopieren.
- Fast schon am Ziel! Die WordPressinstallation wird per Webbrowser -> Adresse: localhost/wordpress gestartet, die wenigen Fragen (Benutzername, Passwort, Datenbankname…) beantwortet.
- Alles glatt gelaufen, WordPress teilt das momentane Passwort des WordPressstandarduser (admin) mit.
- Einloggen, Passwort ändern, los gehts
Detaillierter Installationsvorgang
Auf geht’s in den Konsole (Terminal). Diese Aktionen sind als root auszuführen:
- mkdir /var/www/wordpress (Return) (Erstellung WordPressverzeichnis unter /var/www)
- chgrp www-data /var/www/wordpress (Gruppe www-data als „Besitzer“ des WordPressverzeichnis setzen)
- chown <Username> /var/www/wordpress (Standarbenutzer als „Besitzer“ des WordPressverzeichnis setzen. Könnte z.B. ein vorhandener FTP User sein)
Datenbank und User anlegen
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.
WordPress download / Installation
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):
- cd /home/user/wp28 (Return)
- cp -a -r -v * /var/www/wordpress (Return)
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:
- am besten als User root!
- cd /var/www/wordpress (Return)
- chown -R -v user * (Return)
- chgrp -R -v www-data * (Return)
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…?
- wieder als User root!
- cd /var/www/wordpress (Return)
- chmod -> alle Verzeichnisse auf 755
- chmod -> alle Dateien auf 644 (Details siehe letzte Zeile des Artikels!)
Ab in den Browser
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.
LAMP@debian quick and dirty
Wie bastel ich mir schnell eine Testumgebung?
Mit folgenden Schritten ist es relativ schnell und ohne großen Zeitaufwand möglich, eine funktionierende LAMP Umgebung zu erhalten. Dabei wird auf Debian zurückgegriffen und es werden keine externen Dateiquellen verwendet:
- apt-get install phpmyadmin
- gefolgt von Return
installiert die weitverbreitete GUI zur Datenbankadministration und „zieht“ die notwendigen Pakete gleich hinterher (Apache2, PHP, mysql-client).
Während der Installation wird abgefragt, für welchen Webserver die Konfiguration vorgenommen werden soll. Wir wählen hier Apache! Desweiteren wird nachgefragt, ob eine entsprechende Mysql-Datenbank angelegt werden soll. Diesen Schritt überspringen wir und lassen nichts automatisch anlegen. Ohne mysql-server geht jedoch nichts.
Mysql-Server nachziehen
- apt-get install mysql-server
- gefolgt von Return
Es wird das Mysql-Passwort für den Mysql-User „root“ abgefragt, welches entsprechend zu vergeben und aus Überprüfungsgründen ein zweites mal einzugeben ist. Wichtig: Das root Passwort der Mysql-Datenbank ist NICHT identisch mit dem root Passwort des Users „root“, genausowenig sollte man hier das gleiche Passwort verwenden.
Fertig
Dies ist bereits alles gewesen! Man öffne einen Webbrowser und gebe localhost in selbigen ein. Was man sehen sollte ist:
über die Adresse: localhost/phpmyadmin landet man im GUI von phpmyadmin:
Anmerkung: Wichtig ist, dass dies nur eine Grundinstallation darstellt. Sollte das System dafür gedacht sein, in einer Produktivumgebung eingesetzt zu werden, gilt es noch einige Details betreffend Systemsicherheit zu beachten.