So kann ein schneller Bootvorgang aussehen:

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

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!

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

Nach dem dist-upgrade von Debian Etch auf Debian Lenny gab es bei mir das Problem, dass Kpowersave die CPU nicht mehr in die verschiedenen Frequenzvarianten (Leistung / Energiesparen etc.) setzen konnte.

Die Cpu-frequtils (Befehl cpu-info) bestätigte jedoch, dass die CPU Speedstepping unterstützte und im Moment im Energiesparmodus läuft.

Nach ein wenig Recherche im Internet (genauergesagt wiedermal auf www.debianforum.de ), stellte sich jedoch heraus, dass die Lösung des Problemes recht einfach war.

Man muss den User einfach nur der Gruppe powerdev zuweisen,  sich abmelden, erneut anmelden und siehe da – es läuft wieder!

Es ist soweit.  Debian Lenny wurde offiziell von den Entwicklern freigegeben und kann ab sofort heruntergeladen werden.

Informationen zu Lenny findet man auf der Debiannewsseite

Ebenso bietet Debian mehrere Downloadvarianten an.

Für allen, denen es nicht möglich ist Debian Lenny herunterzuladen,  gibt es auch die Möglichkeit Debian Lenny zu “kaufen”.

Viel Spass mit Debian Lenny! 

Ich habe mir angewöhnt, Debian immer über den Network-Installer zu installieren (Sofern ein entsprechend schneller Internetzugang vorhanden ist). Das Networkinstaller Image kann man unter http://www.debian.org/devel/debian-installer/ beziehen (aktuell RC1 von Debian Lenny).

Natürlich kann jede andre Installationsvariante ebenso gewählt werden.

Hardware des Notebook

• Intel Celeron Prozessor mit 2.13 Ghz
• 1024 GB Ram
• 120 GB HD
• DVD Brenner
• Intel GMA X3100
• Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01)

Die Installation verlief recht simpel. Über den Network-Installer wird nur das Basissystem (Standardsystem) intstalliert. Will man den Gnomedesktop gleich mitinstallieren, bietet sich die Möglichkeit, dies bei der Paketauswahl zu erledigen (Stichwort “Desktopumgebung”)

Wichtig ist der Punkt “Notebook”. Dieser sollte auf jeden Fall aktiviert sein, sodass notebookrelevante Utilities gleich mitinstalliert werden. (zum Beispiel das Paket wireless-tools).

Was läuft out-of-the box – also gleich nach der Installation

• Desktop-Umgebung (Korrekte Auflösung wird automatisch erkannt)
• Soundkarte
• integrierter Kartenlesen
• LAN

Also schon eine ganze Menge.

WLAN

Der integrierte WLAN Controller BCM4312 rev01 konnte trotz der Installation der notwendigen Firmware nicht mit Bordmitteln dazu gebracht werden, zu funktionieren. (Es kann natürlich auch sein, dass ich irgendetwas nicht korrekt installiert habe, denn eigentlich sollte dieser Broadcomchip unter Kernel 2.6.26 laufen (Modul b43)). Detaillierte Infos zu diesem Thema: http://wiki.debian.org/bcm43xx#b43

Schlussendlich bin ich auf ndiswrapper ausgewichen. In Verbindung mit dem Windows-Treiber hatte innerhalb kurzer Zeit ein mit WPA2 funktionierendes WLAN.

Installation von Ndiswrapper

Die Installation von ndiswrapper + utils lässt sich mittels:

• apt-get install ndiswrapper ndiswrapper-utils-1.9
• gefolgt von RETURN

sehr einfach bewerkstelligen.

Danach besorgt man sich den passenden Windowstreiber für den Wlan-Chip und extrahiert ihn unter Linux in ein beliebiges Verzeichnis. Über die Linuxkonsole (als root) wechselt man in das Verzeichnis, in das die Dateien extrahiert wurden (im Falle des Broadcomchip sollte man hier eine  bcmwl5.inf und bcmwl5.sys vorfinden) und tippt danach:

• ndiswrapper -i bcmwl5.sys
• gefolgt von RETURN

um den Treiber zu installieren.

Ist alles glatt gelaufen, sollte der Befehl:

• ndiswrapper -l
• und RETURN

folgendes auf dem Bildschirm ausgeben:

• bcmwl5 : driver installed
• device (14E4:43XX) present

XX hängt vom eingesetzten Type des Wlanchip ab.

Das Ndiswrapper-Modul erstellen

Nun gilt es noch das ndiswrapper – Modul zu erstellen. Hierfür gibt es den sogenannten module-assistant, der die Installation von Modulen sehr stark vereinfacht:

• apt-get install module-assistant
• gefolgt von RETURN

Der Aufruf zur Erstellung des ndiswrapper-modules sieht dann so aus:

• m-a a-i ndiswrapper
• gefolgt von RETURN

m-a = module-assistant, a-i = automatische Installation inkl. Download der notwendigen Paketquellen etc.

Das Modul für den ndiswrapper sollte nun erstellt sein, es wird aber normalerweise nicht automatisch geladen. Um zu überprüfen, ob ndiswrapper geladen ist, verwendet man den Befehl lsmod, der die geladenen Module auflistet. Mithilfe von grep kann eine Filterung der Ausgabe vorgenommen werden, sodass nur noch die gewünschte Zeichenfolge (im folgenden Fall ndiswrapper) angezeigt wird:

• lsmod |grep ndiswrapper
• gefolgt von RETURN

Wird der ndiswrapper angezeigt?

JA:  Sicherheitshalber sollte die Datei /etc/modules geprüft werden, um sicherzustellen, dass ndiswrapper hier als Modul eingetragen ist. Sollte ndiswrapper in /etc/modules nicht eingetragen sein, fügt man die Zeichenfolge (ndiswrapper) einfach in der nächsten leeren Zeile hinzu und speichert die Datei modules ab.

NEIN: Sollte lsmod ndiswrapper nicht aufführen, wird zuerst versucht das Modul manuell zu laden:

• modprobe ndiswrapper [RETURN]
• lsmod |grep ndiswrapper (um zu prüfen ob das Modul geladen ist) [RETURN]

Das sollte es gewesen sein!

Um das Wlan komfortabel konfigurieren zu können (über die Desktopumgebung) kann man sich zum Beispiel wicd, oder den networkmanager-kde bzw. networkmanager-gnome installieren.

Obwohl KDE 4 in Debian Lenny ofiziell nicht enthalten sein wird, besteht die Möglichkeit sich KDE4 über sogenannte “Backports” auf das eigene System zu holen. Dazu sind nur einige wenige Schritte möglich, die man auf der Seite: http://kde4.debian.net/ nachlesen kann.

Wichtig ist, KDE 3.5 zuvor zu deinstallieren!

Gestern versuchte ich Wine unter Debian Lenny zu installieren. Leider gibt es aber selbst unter Debian Lenny nur eine relative alte Version von Wine.

Falls  ihr auf der Suche nach einer aktuellen Wineversion seid und Debian Lenny benützt, dann solltet ihr einen Blick auf die Homepage: http://www.salnet.de/ werfen.

Genauer: http://www.salnet.de/2008/10/11/neuestes-wine-unter-debian/

Läuft übrigens bestens – Danke!

In welchem Umfang die Installation stattfindet, kann man sehr komfortabel mittels der Debian Installationsroutine auswählen.  (Es wird davon ausgegangen, dass man ein “Standardsystem” ohne “Desktopumgebung” mittels Debian-Netinstall CD installiert.)

Wenn die Installation des Grundsystems abgeschlossen ist, beginnen wir mit den manuellen Schritten zur weiteren Installation.

System auf aktuellen Stand bringen

An der Konsole findet der Login mit dem Rootuser “root” statt. (Von einer funktionierenden Internetverbindung wird ausgegangen!)

Als nächsten prüfen wir die Datei sources.list, die sich im Vereichnis /etc/apt befindet. Zu öffnen ist diese Datei mit einem Editor, den man frei wählen kann. (Ich greife auf “vim” zurück).

Die Sourceslist sollte folgenden Inhalt haben:

• deb http://ftp.at.debian.org/debian/ etch main contrib non-free
• deb-src http://ftp.at.debian.org/debian/ etch main contrib non-free
• deb http://security.debian.org/ etch/updates main contrib non-free
• deb-src http://security.debian.org/ etch/updates main contrib non-free

Repositories contrib und non-free greifen auf Pakete zurück, die nicht mit der Debianphilosophie harmonieren, da hier auf teiweise nicht freie bzw. generell auf nicht freie Repositories zurückgegriffen wird. (Dies stellt zwar keine Gefahr dar, jedoch weise ich an dieser Stelle einfach darauf hin. Wer sein System ausschließlich nach dem Debianway betreiben will, kann auf contrib bzw. non-free auch verzichten, hat dann aber nicht den vollen Paketumfang zur Verfügung.)

Nach Anpassung bzw. Kontrolle des Inhaltes sollte das System mit den Onlinerepositories synchronisiert werden:

• apt-get update
• und RETURN
• apt-get upgrade
• und RETURN

Apt-get update synchronisiert das System mit den Onlinequellen. Apt-get upgrade holt aktualisierte Pakete für die bereits installierten Pakete aus dem Internet und installiert die Updates.

Das System sollte also nun auf dem aktuellen Stand sein.

Pakete für den xserver-xorg, kdm und kde installieren

• apt-get install xserver-xorg (und die Installation der Pakete bestätigen)
• apt-get install xorg (Bei der Installation von “xorg” wird u.U. ein Installationsdialog zur Konfiguration der Grafikkarte / Monitor aufgerufen, dies einfach entsprechend der eingesetzten Hardware einstellen.) Bei Debian Lenny wird hier der Dialog zum Konfigurieren der Grafikkarte / Monitor NICHT mehr angezeigt. Der Xserver versucht alle nötigen Einstellungen selbst zu erkennen!
• apt-get install kdm
• apt-get install kdebase

Anmerkung: Bei der oben erwähnten Vorgangsweise werden ALLE Xserver für alle verfügbaren Grafikkarten installiert! Dies stellt angesichts der heutigen Festplattenkapazitäten zwar kein Problem dar, jedoch lässt sich hier natürlich auch explizit der notwendige Xserver installieren.

Den Xserver starten

Ist alles glatt gelaufen und wurden die korrekten Einstellungen während der menübasierten Installation des Xserver getätigt loggt man sich als User ein und startet den Xserver durch startx von der Konsole aus.

Wenn auch das klappt, besteht noch die Möglichkeit den K-Loginmanager (grafischer Loginmanager) automatisch beim Systemstart starten zu lassen.

Hierfür kann man das Paket rcconf nachinstallieren (apt-get install rcconf in einer Konsole) und dann starten, um zu kontrollieren, ob KDM in der erscheinenden Liste aktiviert ist. (Wenn nicht einfach aktivieren und rcconf beenden).