Diese Dokumentation ist entstanden durch den ersten Test mit einem Raspberry PI Modell B rev.2 in der pi3g-Version1) mit vorinstalliertem Cooler-Kit.
Es handelt sich bei diesem Gerät um ein Test-System, mit dessen Hilfe die Einarbeitung für künftige Geräte bewerkstelligt werden soll.
Bei diesem Projekt geht es darum eine Grund-Installation für künftige Systeme, die auf dem Raspberry PI basieren, zu ermitteln. Das Vorgehen dazu soll dann hier beschrieben werden um möglichst schnell weitere Systeme installieren zu können.
Die Angaben von IPs, Hostnamen und FQDNs in diesem Artikel sind nur exemplarisch und bedienen sich einem imaginären Netzwerks für Dokumentationen, das in dem Beitrag Zusatz-Informationen zu IT-Beiträgen beschrieben ist.
Das ursprüngliche Problem, das zu diesem Schritt führt, war der doch recht hohe Strom-Verbrauch bei den steigenden Energie-Kosten. Somit wurde nach Lösungen gesucht diverse Systeme auf möglichst Strom-sparenderere Plattformen zu portieren. Der Raspberry PI bot sich dafür mit seinen max. 7,5 Watt recht gut an um zumindest diverse Netzwerk-Dienste und Applikationen, die nicht unbedingt einen Leistungsfähigen Prozessor benötigen, darauf zu betreiben anstatt einen bis zu 300 Watt und mehr verbrauchenden Server dafür einzusetzen.
Es wird hiermit versucht so viele Systeme wie möglich auf diese Energie-sparende Variante umzusetzen. Hiervon sind vor allem Netzwerk-Dienste wie DHCP und DNS betroffen, aber auch Webserver und das Netzwerk- und System-Monitoring.
Als zweites geht es dann darum, entsprechend leistungsarme Systeme erstellen zu können um damit Grund-Netzwerk-Dienste in Home-Netzen bereit stellen zu können. Gerade wenn VPN-Verbindungen zu anderen Netzen bestehen ist dieser Schritt von Nöten, sollte aber nicht gerade mit einem normalen Rechner bewerkstelligt werden um die Strom-Kosten in einem erträglichen Rahmen zu belassen.
Es wird in erster Linie auf den Raspberry PI von pi3g 2) gesetzt, da hier zumeist bereits ein Cooler-Kit mit geliefert, gar vorinstalliert ist. Darauf wird ein gewisser Wert gelegt, da die Systeme letztendlich im Dauereinsatz betrieben werden sollen.
Beim Einsatz der SD-Karten wird noch geschwankt. Bei einem ersten Versuch mit einer entsprechenden Adapter-Karte von SD zu microSD, um die Karte geschlossen im Geräte verbleiben lassen zu können, gab es Probleme mit dem Gehäuse. Hier wird noch eine Lösung gesucht. Eine Lösung dafür habe ich mittlerweile hier beschrieben.
Der Ablauf bei diesem Projekt ist eigentlich ganz simpel. Als erstes muss der Raspberry PI zusammen gesetzt werden, dann auf eine SD-Karte das Raspbian-Image drauf kopieren, diese in den Raspberry PI einlegen, eine Tastatur und Monitor an den Raspberry PI anschließen (zumindest am Anfang bis der SSHd über das Netzwerk läuft) und dann bereits Strom an den Micro-USB-Port um das Gerät in Betrieb zu nehmen. Nun kann dann die Installation durchlaufen werden und am Schluss vielleicht noch mal eine Sicherung der SD-Karte anfertigen … fertig.
Klingt doch schon mal ganz einfach.
Zunächst muss der Raspberry PI zusammen gesetzt werden. Mein erstes Gerät war in einer kleinen Transportbox, aber hatte bereits die Kühlkörper auf den entsprechenden Chips.
Es reichte somit aus, die Platine in ein richtiges Gehäuse zu verbauen. Bei dem zunächst von mir ausgewählten Gehäuse musste am Deckel noch Abdeckungen für die Aussparungen der Ports entfernt werden; danach konnte die Platine eingelegt werden und das Ganze mit vier Schrauben zusammen fest gemacht. Die kleine RasPI-Box war damit fertig.
Als nächstes wurde die RasPI-Box mit einem HDMI-SVGA-Adapter für die Bildschirmausgabe und via USB für Maus (unnötigerweise) & Tastatur ein Port an meiner Server-Konsole angeschlossen. Die eigentliche Inbetriebnahme erlangte das Gerät dann durch den Anschluss eines Micro-USB-Lade-Adapters an seinem entsprechenden Port.
Auch die Konsole lief erst mal reibungslos und es konnte mit dem nächsten Schritt, der eigentlichen Installation, begonnen werden. Später gab es mit der Konsole leichte Probleme, die mit einem entsprechenden Workaround aber in den Griff zu bekommen wurden.
Vor dem Starten des Raspberry PIs muss man nun noch eine SD-Karte vorbereiten. Dazu sollte man sich auf über die Download-Page von raspberrypi.org [1] die aktuelle Version herunter laden. Das entpackte Image muss dann mit einem entsprechenden Tool auf eine SD-Karte geschrieben werden. Unter Linux kann dies auf der Konsole mit dd of=/dev/<Device der SD-Karte> if=<Image-Datei> bs=1M
getätigt werden. (In dieser Dokumentation wurde das Image vom 25.09.2013 verwendet.)
Nach dem das Gerät mit dem Raspbian-Image das erste Mal gestartet wurde, erscheint nach der Boot-Sequenz das Menü des raspi-config
Tools. Es empfiehlt sich hier gleich mal ein paar Einstellungen vorzunehmen.
Der erste Punkt in dem Menü wird von mir am Schluss erledigt, bevor das System dann neu gebootet werden muss. Zuvor sollten die anderen benötigten Einstellungen getätigt und deren Änderungen in den Konfigurationsdateien ausgeführt werden.
Begonnen wird somit mit dem zweiten Menüpunkt um das Passwort des Superusers einzustellen. Hierbei wird zunächst eine Meldung ausgegeben, die die kommende Aktion ankündigt. Danach befindet man sich erst mal wieder auf der normalen Text-Konsole und wird aufgefordert ein neues Passwort einzugeben, das in einem zweiten Schritt bestätigt werden muss. Anschließend wird eine Meldung ausgegeben, die das Ergebnis der Aktion mitteilt.
Nach Abschluss dieser Aktion befindet man sich wieder im Hauptmenü des Konfigurations-Tools.
Der dritte Menüpunkt kann in diesem Fall ausgelassen werden, da der Standard-Wert bereits auf einen Boot-Modus eingestellt ist, der auf der Text-Konsole bleibt. Da hiermit eh Systeme für Netzwerkdienste vorbereitet werden sollen, ist dies so vollends ausreichend. Eine Änderung der Einstellung zu diesem Punkt wird erst benötigt, wenn man mit dem Raspberry PI einen Thin-Client o.ä. aufbauen will.
Beim vierten Menüpunkt geht es darum das System auf die lokale, länderspezifische Umgebung anzupassen. Durch die Auswahl dieses Punktes wird ein weiteres Menü mit drei Einstellungsmöglichkeiten angezeigt.
Hier wird im ersten Menüpunkt die sog. Locale eingestellt; also Sprache und Zeichensatz des Systems. Es entspricht einem Aufruf von dpkg-reconfigure locales
, wobei zunächst aber eine allgemeine Information dazu angezeigt wird. Danach wählt man die benötigten Zeichensätze in einer recht langen Listbox aus und legt anschließend den Standard-Zeichensatz für das System fest. Nach dem dann die Konfiguration im System gespeichert wurde, gelangt man wieder in das Hauptmenü des raspi-config Tools.
Sobald man wieder in das Menü zu den Optionen der Internationalisierung zurück gekehrt ist, kann man mit dem mittleren Menüpunkt die Zeitzone, in dem das System betrieben wird, einstellen; es entspricht dem Aufruf von dpkg-reconfigure tzdata
. Dabei wird man in zwei Stufen durch eine Auswahl geführt, in der man zuerst den entsprechenden Kontinent und danach die für das System passende Stadt, die für die Zeitzone steht, auswählt. Soblad dann wieder die Konfiguration geschrieben ist, gelangt man wieder in das Hauptmenü.
Beim letzten Punkt zu den Internationalisierungs-Optionen wird das Mapping für die verwendete Tastatur eingestellt. Ansich wird durch diesen Menüpunkt ein Aufruf entsprechend dpkg-reconfigure keyboard-configuration
generiert. Leider ist mir aufgefallen, dass dieser Aufruf zur Zeit (Stand 25.11.2013) nur ein mal gelingt. Bei einem zweiten Aufruf wird nur nochmals die Konfiguration geschrieben, aber man gelangt nicht mehr in das Konfigurationsmenü - egal ob man den Befehl auf der Konsole direkt eingibt oder man über das raspi-config Tool es versucht.
Zunächst wird hier nach der Tastatur selbst gefragt. Bei meiner KVM-Konsole handelt es sich hierbei ebenso um ein Tastenfeld, das einer Standard-Computer-Tastatur gleich kommt. Somit ist die Vorgabe-Einstellung mit „Generic 105-key (Intl) PC“ ausreichend.
Danach wird das länderspezifische Layout der Tastatur ausgewählt. Der Standard steht hier zunächst auf eine englische Tastatur und man muss zur Auswahl „Other“ gehen, um ein anderes Tastatur-Layout einstellen zu können. Hierbei wird als erstes wieder nach einer entsprechenden Sprache gefragt, bevor man dann in einem zweiten Schritt das eigentliche Layout auswählen kann.
Anschließend wird nach der Behandlung der AltGr-Tasten-Funktion gefragt, die bei gewissen Tastaturen ebenfalls unterschiedlich ausfallen kann. Bei vorhandener Taste sollte die Standard-Einstellung hier ebenfalls genügen.
Im nächsten Schritt wird nach einer sog. Compose key oder auch Multi key Taste gefragt. Diese Funktion wird manchmal benötigt um diverse Sonderzeichen darstellen zu können. Selber brauche ich diese Funktion bei der Administration auf der Konsole eh nicht und belasse es hier ebenfalls bei der Vorauswahl.
Der letzte Schritt in diesem Assistent (wenn man es gar so bezeichnen kann) ist dann noch die Einstellung zum Terminieren eines X-Servers. Da hier aber eh kein X-Server zum laufen gebracht werden soll, wird auch hier wieder die Vorgabe belassen. Danach wird die Konfiguration in das System geschrieben.
Die Bilder hier sind Ausschnitte von Fotografien, die während der ersten Installation entstanden als das System noch nicht über SSH erreichbar war. Die Bildqualität lässt dabei leider etwas zu wünschen übrig.
Der fünfte Punkt im Hauptmenü wird hier ausgelassen, da keine Kamera an das Gerät angeschlossen ist.
Auch der sechste Punkt wird ausgelassen. Hierbei handelt es sich um eine Karte, mit der eine Übersicht der „Verbreitung“ des Raspberry PIs angezeigt werden kann. Weitere Informationen sind unter http://rastrack.co.uk/ (wo auch die eigentliche Karte zu finden ist) oder unter http://www.raspberrypi.org/archives/1298 zu bekommen.
Als nächstes werden die erweiterten Optionen (Advanced Options) angegangen. Der erste Punkt dabei wird wieder ausgelassen, da diese Option zur Korrektur der Bildschirmanzeige dient, die hier aber einwandfrei funktioniert.
Beim zweiten Punkt kann ein neuer Hostname vergeben werden. Es werden aber hier nicht alle Konfigurationsdateien korrekt geändert und es muss gegebenenfalls (vor allem wenn kein DHCP zum Einsatz kommt) noch etwas nach-gearbeitet werden. Dazu aber mehr in den Kapiteln 2.2.2 Hostname und FQDN setzen in Verbindung mit 2.2.1 Netzwerk-Adresse einstellen. Dennoch wird hier dem System erst mal ein neuer Name vergeben. Dabei wird zunächst eine Information über die verwendbaren Zeichen angezeigt, bevor man dann in einem weiteren Dialog nach einem Rechnernamen gefragt wird. Die Vorauswahl hierbei ist zunächst der bereits existente Hostname.
Im Auswahlpunt „Memory Split“ in den Advanced Options geht es darum den Speicher für die GPU einzustellen. Dieser liegt standardmäßig bei 64 MB. Da es hierbei um sog. „shared memory“ handelt, also um RAM-Speicher, den sich das System mit der GPU teilen muss, und da hier keine grafischen Anforderungen z.B. mit einem X-Server zum Einsatz kommen soll, reicht es hier den geringst-möglichen Wert einzutragen - sprich den Speicherbedarf für die GPU auf 16 MB zu beschränken.
Der fünfte Menüpunkt wird hier wieder ausgelassen. Hierbei handelt es sich um das Laden diverser Erweiterungen für die SPI-Schnittstelle, die über die GPIO-Schnittstelle für weitere Hardware-Anbindungen zur Verfügung steht. Weitere Informationen hierzu sind z.B. bei Microcontroller.net in einem Artikel zum Raspberry PI zu finden. Dabei auch am Anfang des Artikels ein Link mit einer verständlichen allgemeinen Beschreibung dieser Schnittstelle.
Der letzte Menüpunkt bei den Advanced Options kann hier ebenfalls erst mal ausgelassen werden, da ein Update der Software später nach dem „Abspecken“ des Systems erst getätigt wird.
Nun sind noch zwei Punkte offen. Zunächst der Punkt 7 im Hauptmenü, der sich mit dem Übertakten (Overclock) des Raspberry PIs beschäftigt. Dabei wird zunächst eine Warnung ausgegeben, dass es durch diese Aktion einerseits die Lebenszeit eines Raspberry PIs verkürzen, aber auch die Stabilität beeinflussen kann. Danach kann zwischen fünf Modi ausgewählt werden. Selber beginne ich hier gerne mit „Modest“ und taste mich bei Bedarf auf einen „höheren“ Level der Übertaktung, wenn es der Einsatz gebietet. Nach getaner Auswahl erscheint eine Bestätigung bevor es dann wieder zum Hauptmenü zurück geht.
Die erst mal letzte vorzunehmende Einstellung in dem Tool ist nun die Erweiterung der Partition für das System, die mit dem ersten Punkt im Hauptmenü ausgeführt werden kann. Hierbei erscheint nach kurzer Zeit nur eine Meldung, die angibt dass die neue Partitionsgröße nach dem nächsten Reboot zur Verfügung steht.
Nach dem nun die ganzen Grundeinstellungen erst mal vorgenommen wurden, kann man das raspi-config Tool mit „Finish“ beenden. Dabei wird eine weitere Meldung ausgegeben, bei der man sich entscheiden kann nun einen Reboot zu tätigen. Dies ist in Anbetracht der letzten beiden Aktionen empfehlenswert. Wenn danach das System wieder verfügbar ist, können weitere Schritte zur Konfiguration, wie in den nächsten Kapiteln beschrieben, erfolgen.
Um das System mit einer festen IP versehen zu können - gerade wenn eben kein DHCP im Netz-Segment vorhanden ist - muss in erster Linie nur eine Datei editiert werden: /etc/network/interfaces
Hier werden zunächst die nicht benötigten Teile auskommentiert und der Bereich zum verwendeten Interface (eth0) ergänzt:
auto lo iface lo inet loopback #iface eth0 inet dhcp <-- auskommentierter Eintrag zur Adressen-Vergabe via DHCP # # neu erstellter Bereich mit fester IP # iface eth0 inet static address 192.168.0.100 netmask 255.255.255.0 gateway 192.168.0.1 # optionale Parameter network 192.168.0.0 broadcast 192.168.0.255 # DNS-Optionen, die eigentlich durch das resolvconf Paket gesetzt werden # Diese Optionen brauchen nur gesetzt werden, wenn keine resolv.conf # eingerichtet ist. #dns-nameservers 192.168.1.10 #dns-search domain.tld # # Da kein WLAN-Adapter angeschlossen und verwendet wird, kann # folgendes ebenfalls durch Auskommentieren deaktiviert werden: # #allow-hotplug wlan0 #iface wlan0 inet manual #wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf #iface default inet dhcp
Die IP 192.168.0.100 steht hier nur beispielhaft für die eigentliche IP im Netzwerk des Raspberry PI Systems. Auch sind die restlichen Angaben entsprechend dem tatsächlich vorhandenem Netz einzurichten.
Beim nächsten Boot-Vorgang wird das Gerät bereits mit der so eingestellten IP im Netzwerk präsent sein. Zuvor wäre es aber vorteilhaft auch die nächsten beiden Punkte noch anzugehen.
Durch das Tool raspi-config
wird der Hostname nicht in allen Bereichen korrekt gesetzt. Gerade der eigentliche FQDN, der für manche Dienste benötigt wird, bleibt unberücksichtigt.
Für diesen Zweck muss in der Datei /etc/hosts
ein Eintrag entsprechend dem folgendem hinmzu gefügt werden:
192.168.0.100 internhost.intern.example.com internhost
Die IP 192.168.0.100 steht hier nur beispielhaft für die eigentliche IP im Netzwerk des Raspberry PI Systems. Ebenso der Hostname und FQDN.
Eine vorherige Zeile ohne den FQDN kann auskommentiert oder gelöscht werden.
Das Ganze sollte dann ungefähr so aussehen:
127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters #127.0.1.1 internhost 192.168.0.100 internhost.intern.example.com internhost
Überprüfen kann man die Einstellungen dann mit hostname --fqdn
- hierbei sollte dann der FQDN des Systems ausgegeben werden.
Wenn ein System in einem Netzwerk betrieben wird, so will man es auch erreichen - und dies nicht nur über seine IP, sondern am besten über einen (passenden) Namen. Auch diverse Applikationen versuchen andere (entfernte) Dienste über entsprechende Namen zu erreichen. Dies wird gerade bei einem Update getätigt, damit das entsprechende Programm die benötigten Download-Server finden kann. Für diese Aktionen wird ein Nameserver in einem Netzwerk benötigt (der auch in einem „entfernten“ Netz, wie z.B. bei einem Provider, stehen kann).
Für Systeme, die nur wenige und sehr spezielle andere Systeme zu erreichen haben, ist es theoretisch möglich nur mit einer Pflege der /etc/hosts
ähnlich dem vorherigen Kapitel zu arbeiten, da auch hierüber eine Namensauflösung erreicht werden kann. Dies kann aber auf lange Sicht sehr unübersichtlich und arbeitsintensiv werden.
Im Raspbian ist für diesen Zweck (also um Nameserver abzufragen) das Paket resolvconf
bereits installiert. Falls DHCP zum Einsatz kommt, muss an diesem Punkt normalerweise sogar nichts weiteres Konfiguriert werden, da der DHCP-Client auf dem System entsprechende Informationen vom DHCP-Server erhält und die Konfiguration anpasst.
Anders sieht es aus, wenn man mit statischen IPs arbeitet. Hierzu muss die Konfiguration in /etc/resolv.conf
angepasst werden. Mit sudo vi /etc/resolv.conf
kann dabei ein Nameserver eingetragen werden und sollte ähnlich folgendem Beispiel aussehen:
nameserver 192.168.0.10 search intern.example.com
Hier sollte für jeden verwendeten Nameserver eine eigene Zeile stehen, aber in der Domain-Search-Liste können Leerzeichen-separiert mehrere Domains eingetragen werden.
Es sollte hier natürlich mindestens ein wahrhaft existenter Nameserver eingetragen werden. Eventuell kann man einen Nameserver überprüfen wenn das Paket dnsutils
installiert ist. Mit dem Befehl host www.google.com [IP eines Nameservers]
erfährt man, ob von dem System aus der ausgesuchte Nameserver auch agiert (also eine Antwort zurück gibt). (Anstatt „www.google.com“ kann natürlich auch jeder weitere existierende FQDN verwendet werden.)
Die Domain-Search-Liste ist für eine vereinfachte Namensauflösung zuständig. Hierbei wird bei einer Abfrage nur mit einem Hostnamen die entsprechende Domain aus der Liste angefügt um dann wiederum einen FQDN für eine Nameserver-Abfrage zu erhalten. Wenn hier also der Domain-Name des lokalen Netzwerks enthalten ist, so können die lokalen Systeme auch nur mit dem Hostnamen erreicht werden.
Für diverse Analysen sammle ich die Einträge des System-Meldungen auf einem expliziten Server. Auch zur Analyse von System-übergreifenden Problemen kann dies die Arbeit erleichtern, da man so nur auf einem System die Log durchgehen muss. Damit aber ein System seine Meldungen an den entsprechenden Server schickt, muss die Konfiguration angepasst werden.
Hierzu wird eine Datei für die Umleitungen der Meldungen zu einem Syslog-Server mit sudo vi /etc/rsyslog.d/01-logserver.conf
und folgendem Inhalt erstellt:
# Umleitung zu einem Log-Server *.* @192.168.0.20
Die IP steht hier nur beispielhaft für einen entfernten Syslog-Server und sollte mit einem wahrhaft existierenden Server ersetzt werden. Es kann hier auch ein FQDN statt der IP verwendet werden.
Durch einen Neustart des Syslog-Diensts mit sudo service rsyslog restart
wird die Weiterleitung der Syslog-Meldungen unverzüglich aktiv.
Nach dem der RasPI einen neuen Namen (wie auch FQDN) und eine neue IP erhalten hat, empfiehlt es sich das Gerät durchzubooten. Danach sollten dann die SSH-Schlüssel für den SSH-Server neu generiert werden, damit die Kennungen auch mit dem Namen und der IP zusammen passen.
Dies kann mit folgender Sequenz unter dem root-Account erreicht werden:
root@internhost:~# root@internhost:~# ssh-keygen -q -N '' -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key ... ... root@internhost:~# ssh-keygen -q -N '' -t dsa -f /etc/ssh/ssh_host_dsa_key ... ... root@internhost:~# ssh-keygen -q -N '' -t ecdsa -b 521 -f /etc/ssh/ssh_host_ecdsa_key ... ... root@internhost:~# ssh-keygen -q -N '' -t ed25519 -f /etc/ssh/ssh_host_ed25519_key ... ... root@internhost:~#
Da zunächst ein komplettes X-System im Image von Raspbian enthalten ist, dieses aber nicht benötigt wird, muss als nächstes der Software-Umfang auf das Nötigste reduziert werden … oder zumindest Einiges des Unnötigen gelöscht werden. Hierfür wird sich am der Informationen eines Artikels zur Erstellung eines Minimal-Images [2] orientiert.
Bei den apt
-Befehlen wird aus Sicherheitsgründen immer erst testweise mit dem -s
Parameter3) gearbeitet um nicht versehentlich zuviel zu deinstallieren.
Für die folgenden Aufgaben wird einfachheitshalber in den Superuser-Modus mit sudo su -
gewechselt um so als root
die benötigten Arbeiten zu erledigen.
Zunächst wird der Spiele-Ordner python_games mit rm -fr /home/pi/python_games
gelöscht.
Dann wird ansatzweise versucht das X-System zu deinstallieren. In dem bereits erwähnten Artikel [2] wird hierzu der Befehl apt-get remove x11-common midori lxde
angeführt, der nach einem Testlauf auch das wesentliche dazu macht.python3 python3-minimal
Um auch dazu nicht mehr benötigte Abhängigkeiten zu entfernen wird danach dann auch mit apt-get autoremove
weiterer Platz geschafft. Auch wird damit die Liste der installierten Pakete kleiner, die es später noch gilt zu durchforsten.
Nach diesen ersten Schritten sind von den ursprünglich belegten 1,8 GB nur noch 1,2 GB vorhanden.
Um weiteren Platz zu schaffen wird nun nach großen Dateien gesucht:
root@raspberry:~# find / -type f -size +10000k -exec ls -lh {} \; | awk '{ print $NF ": " $5 }' /var/lib/apt/lists/mirrordirector.raspbian.org_raspbian_dists_wheezy_main_binary-armhf_Packages: 34M /var/swap: 100M /var/cache/apt/pkgcache.bin: 18M /var/cache/apt/srcpkgcache.bin: 18M /usr/share/icons/gnome/icon-theme.cache: 60M /usr/share/icons/HighContrast/icon-theme.cache: 74M /usr/lib/gcc/arm-linux-gnueabihf/4.6/cc1plus: 9,8M /opt/vc/src/hello_pi/hello_video/test.h264: 30M root@raspberry:~#
Das Ergebnis verrät uns etwas: Einerseits sind immer noch diverse Dateien vom X-System vorhanden (die beiden Einträge unter /usr/share/icons
), ebenso scheinen Entwickler-Pakete installiert zu sein (am gcc
-Pfad erkennbar) und noch etwas unter /opt
, das wohl mit Videos zu tun hat.
Die dazu gehörigen Pakete werden dann wie folgt ermittelt:
root@raspberry:~# dpkg -S /opt/vc libraspberrypi0, libraspberrypi-bin, libraspberrypi-doc, libraspberrypi-dev: /opt/vc root@raspberry:~# root@raspberry:~# dpkg -S /usr/share/icons leafpad, lxde-icon-theme, xarchiver, gnome-accessibility-themes, gnome-icon-theme, hicolor-icon-theme, gnome-themes-standard-data, squeak-vm, scratch, desktop-base: /usr/share/icons root@raspberry:~# root@raspberry:~# dpkg -S /usr/lib/gcc cpp-4.6, gcc-4.6, gcc-4.5-base:armhf, gcc-4.6-base:armhf, gcc-4.7-base:armhf, libstdc++6-4.6-dev, g++-4.6: /usr/lib/gcc root@raspberry:~#
Die Pakete hierbei weiterhin existierenden Pakete vom X-System werden dann gleich mal mit apt-get remove leafpad lxde-icon-theme xarchiver gnome-accessibility-themes gnome-icon-theme hicolor-icon-theme gnome-themes-standard-data squeak-vm scratch desktop-base
entfernt und danach auch wieder weitere Abhängigkeiten mit apt-get autoremove
.
Durch ein paar Fehlermeldungen, dass diverse Dateien im desktop-base
Paket noch in Verwendung seien, kann davon ausgegangen werden, dass immer noch ein X-System läuft. Somit wird erst mal nach weiteren X-Paketen gesucht:
root@raspberry:~# dpkg -l | grep lxde ii lxde-common 0.5.5-6 all LXDE configuration data rc lxde-icon-theme 0.5.0-1 all LXDE standard icon theme root@hwzats02:~# dpkg -l | grep xserver rc x11-xserver-utils 7.7~3 armhf X server utilities rc xserver-xorg 1:7.7+3~deb7u1 armhf X.Org X server rc xserver-xorg-core 2:1.12.4-6 armhf Xorg X server - core server root@raspberry:~# dpkg -l | grep x11 ii dbus-x11 1.6.8-1+deb7u1 armhf simple interprocess messaging system (X11 deps) rc gsfonts-x11 0.22 all Make Ghostscript fonts available to X11 ii libx11-6:armhf 2:1.5.0-1+deb7u1+wheezy armhf X11 client-side library ii libx11-data 2:1.5.0-1+deb7u1+wheezy all X11 client-side library ii libx11-xcb1:armhf 2:1.5.0-1+deb7u1+wheezy armhf Xlib/XCB interface library rc x11-common 1:7.7+3~deb7u1 all X Window System (X.Org) infrastructure rc x11-utils 7.7~1 armhf X11 utilities rc x11-xserver-utils 7.7~3 armhf X server utilities root@raspberry:~#
Es reicht hier aus die Pakete für den nächsten Lösch-Vorgang zu wählen, die mit ii am Anfang der Zeile gekennzeichnet sind. Somit ergibt sich der folgende Befehl: apt-get remove lxde-common dbus-x11 libx11-6:armhf libx11-data libx11-xcb1:armhf
. Auch hier wird mit dem apt-get autoremove
wieder weitere Abhängigkeiten danach entfernt.
Des Weiteren wird nun nach medialen Programmen gesucht (Audio / Video), da hier ebenfalls nichts der Art verarbeitet wird:
root@raspberry:~# dpkg -l | grep media ii omxplayer 0.2.6~git20130427~fcfb7911 armhf Command line media player for Raspberry Pi ii udisks 1.0.4-7 armhf storage media interface root@raspberry:~# dpkg -l | grep audio rc libcdio-cdda1 0.83-4+b1 armhf library to read and control digital audio CDs rc libcdio-paranoia1 0.83-4+b1 armhf library to read digital audio CDs with error correction rc libmad0 0.15.1b-7 armhf MPEG audio decoder library rc libsndfile1:armhf 1.0.25-5 armhf Library for reading/writing audio files root@raspberry:~# dpkg -l | grep sound ii libasound2:armhf 1.0.25-4 armhf shared library for ALSA applications rc libmikmod2:armhf 3.1.12-5 armhf Portable sound library rc qjackctl 0.3.9-2 armhf User interface for controlling the JACK sound server root@raspberry:~# dpkg -l | grep video rc libxxf86vm1:armhf 1:1.1.2-1+deb7u1 armhf X11 XFree86 video mode extension library root@raspberry:~# dpkg -l | grep alsa ii alsa-base 1.0.25+3~deb7u1 all ALSA driver configuration files ii alsa-utils 1.0.25-4 armhf Utilities for configuring and using ALSA root@raspberry:~#
Bei der ersten Abfrage finden wir ein Paket (udisks
), das nicht gelöscht werden soll; der Rest kann aber wieder angegangen werden mit: apt-get remove omxplayer libasound2:armhf alsa-base alsa-utils
Jetzt noch eine Sache, die am Anfang dieser Aufräum-Aktion entdeckt wurde:
root@raspberry:~# dpkg -S /opt/vc libraspberrypi0, libraspberrypi-bin, libraspberrypi-doc, libraspberrypi-dev: /opt/vc root@raspberry:~#
Hierzu wird nun erst mal nachgesehen um was es sich dabei handelt:
root@raspberry:~# apt-cache show libraspberrypi0 libraspberrypi-bin libraspberrypi-doc libraspberrypi-dev Package: libraspberrypi0 Source: raspberrypi-firmware ... Depends: raspberrypi-bootloader (= 1.20130902-1) ... Description: EGL/GLES/OpenVG/etc. libraries for the Raspberry Pi's VideoCore IV This package contains implementations of EGL, OpenGL ES, OpenVG, OpenWF Composition, and others for the Raspberry Pi's VideoCore IV multimedia processor. Package: libraspberrypi-bin Source: raspberrypi-firmware ... ... Description: Miscellaneous Raspberry Pi utilities This package contains various utilities for interacting with the Raspberry Pi's VideoCore IV. Package: libraspberrypi-doc Source: raspberrypi-firmware ... ... Description: EGL/GLES/OpenVG/etc. libraries for the Raspberry Pi's VideoCore IV (headers) This package contains headers, example code, and other development files for implementations of EGL, OpenGL ES, OpenVG, OpenWF Composition, and others for the Raspberry Pi's VideoCore IV multimedia processor. Package: libraspberrypi-dev Source: raspberrypi-firmware ... ... Description: EGL/GLES/OpenVG/etc. libraries for the Raspberry Pi's VideoCore IV (headers) This package contains headers and other development files for implementations of EGL, OpenGL ES, OpenVG, OpenWF Composition, and others for the Raspberry Pi's VideoCore IV multimedia processor. root@raspberry:~#
(Die Anzeige ist gekürzt.)
Die Ausgabe zeigt uns, dass es sich um Teile der Raspberry-Firmware handelt. Deswegen lassen wir dies erst mal in Ruhe.
Die Entwickler-Pakete könnten noch (auf diesem Test-System) gebraucht werden. Falls nicht, so würde noch folgende Sequenz zu Anwendung kommen können:
apt-get remove `dpkg --get-selections | grep -v "deinstall" | grep python | sed s/install//` apt-get remove `dpkg --get-selections | grep -v "deinstall" | grep "\-dev" | sed s/install//` apt-get autoremove
Doch nun erst mal zum Abschluss noch ein apt-get clean
und apt-get autoclean
um das System soweit zu säubern.
Die Konsistenz des Systems wir dann noch mit apt-get -f install
überprüft, bzw. falls nötig wieder hergestellt.
Die Arbeit hat sich soweit gelohnt, denn nun sind von den ursprünglichen 1,8 GB nur noch 790 MB übrig.
Zum Test, ob auch nicht zu viel gelöscht wurde, wird dann der Raspberry PI erst mal durch gebootet.
Das System brauchte 45 Sekunden und es konnte wieder mit SSH darauf zugegriffen werden.
Da ein Betriebssystem wie Raspbian aus vielen verschiedenen Paketen besteht und hier laufend Korrekturen und Anpassungen vorgenommen werden, empfiehlt es sich das System nach diesen getanen Arbeiten auch mal auf den aktuellen Stand zu bringen.
Dazu sollte am Besten folgende Sequenz als Superuser (sudo su -
) ausgeführt werden:
apt-get update apt-get dist-upgrade # rpi-update apt-get autoremove apt-get clean apt-get autoclean
Das Ausführen von rpi-update wird nicht mehr benötigt wenn man nicht eigene Änderungen (z.B. um eigene Entwicklungen zu tätigen) am Kernel getätigt hat.
Leider ist bei meinem Test-System danach der belegte Speicherplatz wieder auf 919 MB angestiegen.
Aber dafür kann noch ein bisschen mehr aufräumen werden. Mit dpkg -P `dpkg -l | grep "^rc" | awk -F" " '{ print $2 }'`
werden die immer noch vorhandenen Konfigurations-Dateien der bereits gelöschten Pakete ebenfalls entfernt (soweit möglich).
Damit sich der Raspberry Pi entsprechend in meinem Netz wie alle anderen Systeme integrieren kann sind noch ein paar weitere Komponenten zu installieren, bzw. einzurichten.
Für die Überwachung im Monitoring wird auf SNMP gesetzt. Somit sind auch hier die entsprechenden Pakete dafür zu installieren. Dies geschieht mit sudo apt-get install snmpd
.
Die Konfiguration in /etc/snmp/
wird auf das Nötigste reduziert:
agentAddress udp:161 syslocation Rechnerraum Hauptwohnsitz, Schrank 2 Ablage 1 syscontact John Doe <john.doe@domain.tld> sysdescr Raspberry Test-Server view systemonly included .1.3.6.1.2.1.1 view systemonly included .1.3.6.1.2.1.25.1 rocommunity public default -V systemonly rocommunity monitor 192.168.0.30/32 sysServices 72
Hier kann als 192.168.0.30/32 (das als Synonym für ein Monitoring-System steht) auch ein Netzwerk angegeben werden, dass entsprechend auf die kompletten SNMP-Daten Zugriff haben soll.
Des Weiteren wird in der Datei /etc/default/snmpd
bei der Variable SNMPDOPTS
der erste Parameter -Lsd
entfernt, damit der SNMPd nicht die Logdateien zu müllt. Es wird mit dem Parameter ansonsten für jeden Zugriff auf eine OID ein Syslog-Eintrag generiert, was beim Einsatz eines Monitoring-Systems wie Nagios recht häufig und in entsprechender Anzahl ziemlich kontinuierlich die Logs vollschreibt.
Nach den Änderungen wird dann mit sudo service snmpd restart
der Daemon neu durch gestartet.
Gerade in einem Test-System kommt es mal vor, dass man etwas sucht und nicht genau weiß, wie die entsprechende Datei heißt und wo genau sie zu finden ist. Aus diesem Grund greife ich gerne auf den Midnight Commander zurück, da man hier auch auf der Konsole ein Tool hat um sich schnell mal durch Verzeichnisse hangeln zu können.
Installiert wird dieses nützliche Tool mit sudo apt-get install mc zip arj lynx
. Danach starte ich das Tool mit mc
und gehe mit der Taste F9
in die Menü-Leiste um dor mit den Pfeiltasten über „Optionen“ zur „Konfiguration…“ zu gelangen. Dort aktiviere ich dann gerne unter „Weitere Optionen“ den Punkt „Interner Editor verwenden“ - dies obligt aber jedem selbst nach seinen Gutdünken.
Es gibt im Netz der Netze bereits diverse „schmale“ Versionen eines Debian-basierten Betriebssystems für den Raspberry PI. Selber hatte ich aber des öfteren diverse Probleme bereits beim Boot-Vorgang alternativer Versionen gehabt, weswegen ich mich dann zu diesem Schritt entschieden habe.
Dies hier setzt auf eine offizielle Raspbian-Version für das Gerät auf. Mit dem Vorgehen hier ist immerhin ca. 50% des ursprünglich verwendeten Speicherplatzes frei geschaufelt worden. Dies vor allem auch auf Hinblick, dass eh keine grafische Benutzeroberfläche verwendet werden soll und somit auch die dadurch vorhandenen Pakete gelöscht wurden. Somit hab ich nun eine brauchbare Basis für RasPi-Boxen, mit denen „nur“ diverse Dienste in einem Netzwerk bereit gestellt werden sollen.
Ich hoffe auch mal, dass Leute, die sich erst noch in das Thema Raspberry PI und Raspbian einarbeiten, damit etwas anfangen können um ihre eigenen Systeme aufzubauen. Es soll zumindest eine kleine Hilfestellung sein.
Mittlerweile wird gerne auf das ..-Lite Image zurück gegriffen, wodurch man sich das hier beschriebene „Abspecken“ sparen kann, Diverse Einstellungenn gerade zum Netzwerk müssen dennoch getätigt werden.
Updates
01.01.2021 - Anpassungen bei diverser Einstellungen für später verwendedes Release (buster).