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:

Apache2 it works

über die Adresse: localhost/phpmyadmin landet man im GUI von phpmyadmin:

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

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:

vsftpssl1

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

AMD Phenom II X3 -> X4 EC-Firmware

Ein letzter Versuch

Es ist interessant, wie besessen man von einer Idee sein kann, obwohl gar nicht sicher gestellt ist, dass die Aktivierung des vierten Kernes meiner AMD Phenom II X3 CPU einen „merkbaren“ Leistungsgewinn bringt. Ich glaube nämlich, dass man das gar nicht bemerkt.

Nun aber egal. Ich hatte das ganze eigentlich schon abgeschrieben und mich bislang eigentlich gar nicht mehr damit auseinander gesetzt. Gestern jedoch, nachdem ich meinem MSI-Mutterbrett ähm Motherboard ein neues Bios spendierte, stolperte ich über die Option EC-Firmware, die – oh Wunder – eine Option „Special“ anbietet.

Zu allererst mal Recherche im Internet. Diese ergab, dass EC-Firmware wohl extra als Zusatzoption zur Freischaltung deaktivierter Kerne bei AMD CPUs da war. In Verbindung mit der Option Advanced Clock Calibration (welche auf Auto zu stellen ist), erkennt das Mainboard meine X3 CPU als X4!

Wo viel Sonne scheint, gibts aber auch Schatten

Lange währte die Freude nicht. Als erstes stach mir gleich ins Auge, dass die CPU Als „AMD Phenom II X4 20“ erkannt wurde, es ist jedoch eigentlich ein „AMD Phenom II X3 720„.  Egal, vielleicht nur ein Anzeigeproblem. Der Boot in das Betriebsystem (in diesem Falle Windows Vista), gelang ohne Probleme.  Auffallend nur, die „Pixelfehler“ bei der Darstellung des Desktops. Dort wo eigentlich das Symbol „aufhört“ häufen sich violettfarbene Pixel. Die gehören da nicht hin!

Sehen wir mal drüber weg und starten eine Anwendung…. Es dauert… es dauert länger als sonst… es dauert viel zu lange!

Die Anwendungs „xyz“ funktioniert nicht mehr richtig und wird beendet!

Start der Systemsteuerung… Es tut sich nix!

Restart des Systems -> Es erscheint kurz der Splashscreen von Vista und dann… Reset.

Fazit

Auch wenn die Mainboardhersteller scheinbar teilweise Optionen implementieren, die die Freischaltung eines deaktivierten Kernes ermöglichen, ist das noch lange keine Garantie für den Erfolg. Es mag zwar CPUs geben, die mit einem intakten vierten Kern verkauft werden, jedoch scheint mir das alles ein Lotteriespiel zu sein.

Ich seh’s mal so, dass ich wohl „Pech“ hatte und mein vierter Kern „einen Klopfer“ hat. Mögen andre mehr Glück haben und das Experiment erfolgreich abschließen.

X3 ist eben doch nicht immer X4 🙂

Dennoch bleibt diese CPU ein leistungsfähiger Wegbegleiter durch Bits und Bytes.

Einen detaillierteren Bericht zu diesem Thema findet man u.a. auf: Tweakpc.de