Einen Telnet-Server unter Debian/Ubuntu-Linux installieren

Für eine bestimmte Anwendung brauche ich zur Zeit Telnet und da ja die SSH seit Ewigkeiten Telnet wegen des Sicherheitsaspektes abgelöst hat, muss man den Server manuell nach installieren.

sudo apt-get install telnetd

Da sowohl das aktuelle Debian- als auch Ubuntu-Linux auf systemd umgestiegen ist, so muss man mit

sudo /etc/init.d/openbsd-inetd  restart

diesen noch starten.

Auf die Diskussion, dass ja die SSH ja sicher ist, brauche ich mich hier jetzt nicht einlassen. Für die Anwendung wo Telnet eingesetzt wird, fallen keine Sicherheitsrelevanten Daten an. Im Gegenteil: Das Protokoll ist für die Client zu Server Kommunikation nach jetziger Implementierung eher besser geeignet. Für die eigentlichen Fernwartungsaufgaben steht ja nach wie vor die SSH auf dem Zielrechner zur Verfügung.

Autostart von irssi in einer screen-Session

Wenn man bestimmte Skripte oder andere Sachen automatisiert mit dem Systemstart zum rollen bringen will, so lassen sich diese in die Datei /etc/rc.local einbinden.

sudo -u $username screen -d -m -U -S irssi irssi

Egal ob Änderungen in der Datei vorgenommen werden oder auch nicht, am Ende muss in der letzten Zeile immer „exit 0“ stehen!

Da ich diese Konfiguration das erste Mal auf einem Raspbian zum starten bringen wollte, musste ich zu meinem Entsetzen feststellen, dass auf diesem standardmäßig erst einmal kein sudo installiert ist. Ist zwar kein Problem, weil lässt sich ja nach installieren, aber ich war schon erstaunt.

WLAN am Raspberry PI einrichten

Der Net-Installer des Debian-Port Raspbian für den Raspberry Pi ist recht übersichtlich und auf der Projektseite hier dokumentiert. Da ich in dem Fall zu Anfangs lediglich immer nur ein Grundsystem mit einem SSH-Server auf eine SD-Karte werfe, gibt es keine Möglichkeit, dass man sich mit dem Pi out of the Box via WiFi ins Netz verbinden kann. Leider fehlt bei einer Standart-Debian-Installation auch das Toolkit um WLAN-Adapter zu konfigurieren. Also muss dieses als erstes nach installiert werden:

apt-get install wireless-tools wpasupplicant

Da ich mich auch für den allgemein bei den Pi’s sehr beliebten Edimax EW7811Un USB-Adapter entschieden habe, hilft es auf folgende Weise zu verifizieren ob dieser vom System im eingesteckten Zustand ordentlich erkannt wurde.
Durch Eingabe von lsusb sollte das WLAN-Gerät über den USB-Host-Adapter mit seinen vollen Namen aufgelistet werden.
Mit lsmod kann man prüfen, ob das entsprechende Kernelmodul zu den Realtek-Chip mit geladen wurde. In diesem Fall heisst dies 8192cu.
Als finale Möglichkeit zu Überprüfen ob der Edimax einsatzbereit ist, kann man sich mit iwconfig mal die „aktuelle“ Konfiguration des WLAN-Interface anzeigen lassen. Entscheidend dabei ist, das es einen Eintrag mit wlan0 gibt.

Wenn das alles gegeben ist, kann man mit restlichen Konfiguration weiter machen.

Als erstes muss das WLAN-Gerät in die Datei /etc/network/interfaces hinzugefügt und die Konfigurationsparameter mitgegeben werden. In diesem Fall soll die IP-Adresse via DHCP bezogen werden und es wird in der letzten Zeile ein Verweis auf die Konfigurationsdatei wpa_supplicant.conf gesetzt.

/etc/network/interfaces:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary LAN-network interface
allow-hotplug eth0
iface eth0 inet dhcp

# The Edimax USB-WiFi interface
auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
        wpa-driver wext
        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Die eigentliche WLAN-Konfiguration mit den Parametern zum Aufbau der (verschlüsselten) Verbindung wird unter /etc/wpa_supplicant/wpa_supplicant.conf definiert. In dem Fall WPA/WPA2 verschlüsselt. Sollte die Datei noch nicht existieren, dann erstellt man sie einfach.

/etc/wpa_supplicant/wpa_supplicant.conf:

network={
        ssid="_Name_des_Netwerk_"
        scan_ssid=1
        proto=RSN
        key_mgmt=WPA-PSK
        pairwise=CCMP TKIP
        group=CCMP TKIP
        psk="_Absolut_sicheres_Passwort_"
}

Mit dem Befehl ifup wlan0 wird dann das Interface neu gestartet und soll eine IP-Adresse beziehen mit der es sich dann versucht ein zu wählen. Ein Neustart des gesamten Raspbian tut aber auch nicht weh. Wenn ein ifconfig wlan0 als Ausgabe plausible Adress- und Netzmaskenwerte gibt, dann wurde alles richtig gemacht.

Im Wiki des Ubuntu-Forum gibt es auch sehr hilfreiche Howtos und Erklärungen zu Thema, die einem weiter bringen.
http://wiki.ubuntuusers.de/WLAN/Installation
http://wiki.ubuntuusers.de/WLAN/wpa_supplicant

Saubere MacPorts

Nach Jahren der Updaterei und neues Mac OS X Betriebssystem hinüber bügeln, tut es einfach mal gut, alle Programme via MacPorts mal zu deinstallieren und wieder neu zu installieren. Dabei werden automatisch alle Versions-Leichen, welche nicht mehr benötigt werden und Bibliotheken die einst mal mit installiert wurden weil ich Programm XY mal kurz ausprobiert habe, mit gelöscht.
Anbei eine Liste von Programme, die ich standartmässig auf einem Mac installiere:

sudo port -v -fp uninstall installed && sudo port -v install erlang gnupg2 irssi mc minicom mtr py27-ipython py-pip py-serial py-py2app nmap rtmpdump simh tcpdump tcpflow tmux w3m watch wget

Danach klappt’s auch wieder mit den Verlinkungen sauber.

Update:

Anmerkung vom Clemens:

In diesem Kontext auch hilfreich: wiederholt sudo port uninstall leaves ausführen. Das gleiche mit ein bisschen mehr Toolchain drumrum: sudo port install port_cutleaves; port_cutleaves.

Programme unter Mac OS X deinstallieren

Einem Thema, welchen ich mich bisher verweigert habe, ist das Deinstallieren von Programmen unter Mac OS X. Es ist ja ganz praktisch, dass die meisten Programme dank ihres Application-Framework keine Routinen für das Installieren und wieder Deinstallieren benötigen. Es bleiben aber dennoch ja nach Programm in folgen Verzeichnen programmspezifische Daten zurück.

– Voreinstellungen in ~/Library/Preferences/
– Hilfsdaten und Cache in ~/Library/Application Support/
– gespeicherte Programme in ~/Library/Saved Application State/

Meistens habe ich diese Dateien von Hand aus den Verzeichnen heraus gefummelt. Aber vor einigen Tagen habe ich mal diverse Deinstallations-Programme ausprobiert, die es einem ermöglichen per ‚Drag & Drop‘ ein Programm auf dieses zu ziehen und die Meta-Daten gleich automatisch mit löschen. Unter diesen Lösungen gibt es allerdings auch Potenzial, mit der sich das ein wenig weiter automatisieren lässt. AppTrap ist eine kleine Erweiterung für die Systemsteuerung, die einen kleinen Hintergrundprozess startet und schaut, ob der Benutzer ein Programm aus den Applikationenordner löscht, und löscht damit auch alle anderen Programmspezifischen Daten. Man sollte vielleicht aber die Abfrage eingeschaltet lassen, da dieser Mechanismus auch greift, wenn die Programme sich selbst aktualisieren und man so Gefahr läuft, dass die Daten auch dann weg sind, wenn man es nicht möchte.

Ein anderes Thema sind aber Programme oder Betribessystemkomponenten, die eine Installationsroutine mitbringen. Sie befinden sich in einem .pkg oder .dpkg Paket. Hier reicht nicht das einfache verschieben des Programm-Icon in den Papierkorb – wenn es überhaupt eines gibt. Sondern man will unter Umständen wieder Teile aus dem systemweiten Ordnern /Library und /System entfernen. Seit Ewigkeiten gibt es mit dem Paketmanager OSXPM ein Tool, welches diese Funktion auch beherrscht. Problem ist aber, dass das Programm bei neueren Mac OS X Versionen als Snow Leopard (10.6.x) nicht mehr lauffähig ist, da es für die PowerPC-Architektur geschrieben wurde und die neuen Betriebssystemversionen keinen PowerPC-Code mehr ausführen können.
Abhilfe hierbei schafft hierfür endlich nach langer Zeit das Programm UninstallPKG welches vom corecode-Entwicklerteam für ca 7 € angeboten wird. Es listet ausschliesslich alle Programme und Komponenten auf, die mit einer Installationsroutine auf dem System installiert wurden und man kann diese – beziehungsweise dessen verwaisten Einträge – wieder löschen. Hintergrund ist: Das das Mac OS X einen eigenen ProperyList-Eintrag für jede Komponente führt, der so wieder heraus genommen werden kann.