Unkategorisiert – Seite 16

WordPress Installation

13. Oktober 200913. Oktober 2009 von Daniel

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

12. Oktober 2009 von Daniel

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.

VSFTP mit SSL Debian Lenny

8. Oktober 20098. Oktober 2009 von Daniel

Grundsätzliches

Im Zuge eines Umbaues und bedingt dadurch, dass der Support für ETCH in absehbarer Zeit ausläuft, muss mein alter Debian ETCH Server in naher Zukunft einem neuen Platz machen.

Ich bin daran gegangen mit Hilfe des Network-Installer (CD-Image) ein Grundsystem aufzusetzen.

In einem nächsten Schritt erfolgte die Installation von VSFTP:

apt-get install vsftpd
gefolgt von RETURN

Nun sollte der VSFTPD laufen und anonymen Usern Zugriff gewähren. Sollte das nicht der Fall sein, meldet VSFTPD meist beim Verbindungsversuch einen (aussagekräftigen) Fehler.

Weitere Informationen findet man u.a. noch in /var/log/messages, oder aber auch in den Logdateien von VSFTPD unter /var/log/xfer.log und /var/log/vsftpd.log. Es hängt von der Konfiguration ab, wohin VSFTPD loggt.

Bei meinem Setup fehlte der User „ftpsecure“ den VSFTPD unbedingt benötigt. Dieser User wurde ohne Loginshell manuell hinzugefügt.

Openssl

Um eine SSL Verbindung realisieren zu können und auch das Zertifikat selbst zu erstellen, wird das Paket openssl benötigt:

apt-get install openssl
gefolgt von RETURN

Die Konfiguration von VSFTP

Wie bei fast allen Diensten befindet sich die Konfigurationsdatei im Verzeichnis /etc. Sie hat den Namen vsftpd.conf und sollte für einen FTP Server, der über SSL kommuniziert und nur authentifizierten Usern Zugriff gewährt, ungefähr so aussehen:

write_enable=YES
dirmessage_enable=YES
nopriv_user=ftpsecure
ftpd_banner=“Welcome (logging activated)“
local_enable=YES
file_open_mode=0755
local_umask=000
userlist_deny=NO
userlist_enable=YES
chroot_local_user=YES
local_max_rate=50000
anonymous_enable=NO
anon_world_readable_only=NO
anon_upload_enable=NO
syslog_enable=NO
log_ftp_protocol=YES
xferlog_enable=YES
vsftpd_log_file=/var/log/vsftpd.log
xferlog_std_format=YES
xferlog_file=/var/log/xferlog
#SSL einschalten
ssl_enable=YES
allow_anon_ssl=NO
#Datentransfer verschlüsseln
force_local_data_ssl=YES
#Login verschlüsseln
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
#Angabe der Position des Zertifikates
rsa_cert_file=/usr/share/ssl-cert/vsftpd.pem
connect_from_port_20=YES
pam_service_name=vsftpd
listen=YES

Eine SSL Verbindung zum VSFTP Server funktioniert mit Hilfe von Filezilla nur, wenn ssl_tlsv2 und ssl_sslv3 auf NO gesetzt sind.

Natürlich ist -vor einem Testlauf- auch noch ein entsprechendes Zertifikat und Schlüssel zu erstellen, sonst funktioniert es nicht:

openssl req -new -x509 -days 365 -keyout vsftp.key -out vsftp.crt

Entfernen der Passphrase:

openssl rsa -in vsftp.key -out vsftp_clean.key

Beide (Key und Zertifikat) in eine Datei kopieren:

cat vsftp.crt vsftp_clean.key > /usr/share/ssl-cert/vsftpd.pem

Klar ist außerdem, dass entsprechende User für den Einstieg angelegt werden müssen. Diese User sollten als Homeverzeichnis, das Verzeichnis besitzen, in dem die Daten landen sollen. Wichtig ist auch noch, dass diese User keine Loginshell benötigen!

Wenn alles klappt, dann sollte ein Login über Filezilla (bei verstärkter Protokollierung) so aussehen:

Die Konfiguration von VSFTP SSL erfolgte auf Debian Lenny (netinstaller) unter teilweiser Einbeziehung des How-To auf: http://www.widhalm.or.at/node/122

Linux Mint KDE 4.2.4 -> KDE 4.3 Upgrade

10. August 2009 von Daniel

Grundinstallation

Aus Interesse habe ich mir auf eine noch leere Partition meiner Festplatte Linux Mint – KDE 4.2.4 installiert. Danach begab ich mich auf Recherche, ob es denn möglich ist, auf die neueste KDE Version 4.3 zu aktualisieren. Erste Anlaufstelle war http://forums.linuxmint.com/viewtopic.php?f=109&p=176948. Dort haben einige Mintuser versucht, ein Upgrade durchzuführen.

Unterschiedliches Feedback

Einige berichteten von Problemen: KDE funktionierte nicht mehr, oder aber es gab Probleme mit der Darstellung des Desktop, welcher erst nach nach der Neukonfiguration wieder verwendbar wurde.

Auf los gehts los!

Grund genug also, das selbst mal zu testen.

Basierend auf obigem Link habe ich folgendes gemacht.

Installation von Linux Mint KDE 4.2.4
Bearbeiten der Datei /etc/apt/sources.list (mit beliebigem Texteditor), am Ende folgende Repositories hinzufügen
deb http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu jaunty main
deb http://ppa.launchpad.net/kubuntu-ppa/staging/ubuntu jaunty main
Mit dem folgenden Befehl den Key der Server hinzufügen: sudo apt-key adv –keyserver keyserver.ubuntu.com –recv-keys 8AC93F7A
apt-get update
apt-get dist-upgrade

Nun sollte der Download etlicher Pakete starten. Ich habe das bei laufendem KDE Desktop gemacht. (Keine Probleme dabei). Nach dem Abschluß und der automatischen Konfiguration der Pakete (sämtliche Abfragen wurden mit den vorgegebenen Werten bestätigt) tippte ich schließlich: shutdown -r now was einen Neustart auslöst.

Auf alles gefasst musste ich feststellen, dass KDE 4.3 ohne Probleme startet und auch der Desktop erscheint. 🙂

Der Bootvorgang verläuft sehr zügig. Nun werd ich mich mal den Interna widmen. Ich bin überzeugt davon, dass das KDE-Team hervorragende Arbeit geleistet hat.

Treibersache

10. August 2009 von Daniel

„Geht ja unter Linux nicht… typisch Linux“

Tuz

…hab ich vor wenigen Tagen aus dem Mund eines IT-Kollegen gehört. Nun, genau solche Aussagen verursachen bei mir ein gewisses innerliches Bedürfnis, in rettender Art und Weise -pro Linux- verbal (nach aussen) aktiv zu werden. 🙂

Ich mag es einfach nicht, wenn Leute behaupten, dass Linux (bzw. Linuxdistris) mist sind, weil die und die Hardware nicht unterstützt wird.

Liebe Leute, es sei hier festgehalten, dass es NICHT die Aufgabe von „Linux“ ist, Hardware zu unterstützen, diese möglichst noch automatisch einzubinden und dann noch als funktionstüchtig zu präsentieren!

Genaugenommen sollte es hier eigentlich heißen: „Es ist NICHT die Aufgabe der Linux-/Kerneldeveloper, den Linuxkernel mit diversem Code vollzustopfen (oder eben auch Module mitzuliefern), damit „Hardware XY“ auch unter Linux läuft.

Dank der Entwicker wird heutzutage bereits einge große Masse an Hardware out-of-the-box erkannt, ohne auf die eigentlichen Hardwareherstellerfirmen zurückgreifen zu müssen.

Wieso?

…frage ich mich, wird in diversen Hardwaresparten Linux noch immer mehr als stiefkindlich behandelt? Ist es der (noch) geringe Marktanteil bezogen auf den Desktopbereich, oder kommt der Druck woanders her?

Vielleicht scheut man ja auch die zusätzlichen Entwicklungskosten für einen Linuxtreiber? Ich bin kein Entwickler und kann deshalb nicht wirklich beurteilen, wieviel Aufwand es wäre, für Hardware XY zusätzlich einen Linuxtreiber mitzuliefern.

Wieso schafft es dann aber Nvidia, Intel, AMD/ATI…?

Abbildung oben (Tuz): Durch Klick auf das Bild erhält man weitere Infos, was es mit TUX/TUZ auf sich hat.

Zitat-Wikipedia: „Durch diesen vorübergehenden Austausch des Maskottchens (es wurde TUX durch TUZ ersetzt) soll Aufmerksamkeit auf den ausschließlich auf Tasmanien lebenden Beutelteufel gelenkt werden, dessen natürlicher Fortbestand durch die Krankheit Devil Facial Tumour Disease (DFTD) bedroht ist.“