Webmin auf den Raspberry PI

Solltet ihr den Raspberry PI als Server im Einsatz haben ist eine grafische Oberfläche auf dem Raspi unnötig. Um ihn trotzdem bequem über eine GUI managen zu können installiert euch einfach Webmin.
Was ist Webmin?
Ein sehr nutzliches Tool wo ihr den Raspi und alle möglichen Dienste über eine Weboberfläche managen könnt. Infos hierzu findet ihr unter http://www.webmin.com/

Als Vorbereitung mal alle Paketquellen aktualisieren:

am besten gleich noch ein

hinterher. Das upgrade dauerte bei mir mit 117 Paketupdates ca. 3 Stunden.
Sollten sie noch nicht drauf sein installiert euch noch folgende Pakete nach:

Nach ein paar Minuten sollte auch dies erledigt sein.
Als nächstes besorgt ihr euch das Installationsfile mit:

und installiert es mit

Nach weiteren paar Minuten ist auch dies fertig und ihr könnt euch im Browser eurer Wahl auf den Raspi einloggen (Port 10000).

Viel Glück 🙂

SSH aktivieren via PowerCLI

Wer kennt es nicht? Es stehen Arbeiten auf den ESXi Hosts an welche nur über SSH erledigt werden können.

Bei wenigen oder vielleicht sogar nur 1 Host kein Problem in der GUI.  In meinen Fall sind es aber 26 Stück. Viel Zeit – Viel geklicke in der GUI -> kurzum eine nervige Arbeit.

Um dieses Problem zu lösen gibt es 2 Wege.

1. SSH aktiviert lassen und den Alarm ausstellen (Kategorie Quick&Dirty, unsicher, nicht zu empfehlen)

oder die elegante Nummer 2:
Wir aktivieren und deaktivieren SSH via PowerCLI.

Nach dem Öffnen der PowerCLI und einen erfolgreichen Login in das VC führen wir diesen Befehl aus:

Und voila, auf alles Host die in diesen VC hängen wird SSH aktiviert. Nach erfolgreichen Arbeiten deaktivieren wir das Service wieder mit:

Turbo für den Raspberry PI

Bisher galt immer folgendes:
Sollte der RasPi beim Overclocking defekt werden gab es keinen Ersatz.

Seit ein paar Tagen ist es nun offiziel:
Alle RasPi’s die mit Raspbian laufen dürfen ohne Garantieverlust auf 1Ghz hochgetaktet werden.
Diese Einstellungen könnt ihr wie üblich in der config.txt des Images vornehmen oder ganz bequem im Betrieb mittels raspi-config (als Root öffnen).

Sieht dann so aus:
Solltet ihr den Menüpunkt „overclocking“ nicht sehen dann zuerst mal ganz unten auf „update“ gehen.

Transparenter Proxy mit squid und DD-WRT

Ein Proxy ist nicht immer böße wie in der Arbeit wo ein Content-Filter aktiv ist.
Zuhause kann er ganz nützlich sein um z.b auf allen Endgeräte im Heimnetz automatisch die Werbung auzufiltern usw…

Wie ihr einen kleinen Proxy auf den Raspberry PI aufsetzt/konfiguriert haben wir schon im letzten Artikel gelernt.

Um dies möglichst komfortabel zu betreiben bietet die alternative Routerfirmware DD-WRT gute Möglichkeiten eigene iptables Regeln zu setzen um automatisch den gesamten HTTP Trafic zum Proxy zu leiten.

Zuerst müssen wir die squid.config auf den Proxy ein kleinwenig anpassen.
Der Wert http_port erhält den kleinen Zusatz transparent .
Sieht dann in etwa so aus:

Speichern -> squid neustarten -> fertig

Nun zur Konfiguration am Router:
DD-WRT bietet die Möglichkeit Scripts in der WebGUI auszuführen unter dem Menüpunkt „Administration-> Commands“
Diese Textbox befüllen wir mit folgenden Zeilen Code:

Die Wete wie IP und Port natürlich mit euren Daten ersetzen.
Mit einen Klick auf „Save Firewall“ ist die Arbeit schon getan.

Raspberry PI spielt Proxy

Heute widmen wir uns dem Thema „Wie erstelle ich einen Proxy mit den Raspberry PI“
Die Wahl fält in auf den in der Linux Welt recht beliebten Cache-Proxy squid3.

Bei den Besitzern eines Raspberry PI’s muss man glaub ich nicht mehr auf Grundlagen
„Wie verbinde ich mich zum RasPi via SSH“ eingehen, deswegen gehts gleich zur Sache.

Als Basisimage dient uns das „Soft-float Debian wheezy“ welches ihr ganz bequem von http://www.raspberrypi.org/downloads herunterladen könnt.

Zur Vereinfachung der Installation und Konfiguration wechsle ich gleich am Beginn mittels sudo -s dauerhaft zum root User. Wer sich das nicht traut: vor jeden Befehl ein sudo setzen.

Mittels folgenden Befehl wird dir automatisch die richtige Version heruntergeladen und installiert:

Nach ein paar Minuten warten können wir uns schon an die erste Konfiguration wagen.
Wir wechseln nun in das Verzeichnis wo sich die Konfigurationsdateien befinden:

In diesen Ordner finden wie die squid.conf Datei vor. Da ich mich persönlich nicht mit den überfüllten Beispieldateien anfreunden kann starte ich hier mit einer neuen leeren squid.conf .
Zuerst widmen wir und der Basiskonfiguration:

  • http_port
    definiert auf welcher IP/Port der Proxy hören muss.
  • cache_mem
    regelt wie viel der Proxy max. in den RAM cached
  • maximum_object_size
    wie der Name schon sagt: max. Größe cacheder Dateien
  • maximum_object_size_in_memory
    maximalste Größte einer Datei im RAM
  • cache_replacement_policy
    memory_replacement_policy
    Hier wird es komplex: Ich zitiere aus dem Ubuntuusers.de Wiki:

Wenn der Cache voll ist, muss entschieden werden, welche Daten gelöscht werden sollen und welche nicht. Dafür gibt es drei Strategien:

  • LRU behält die zuletzt angefragten Objekte im Cache, unabhängig von Größe und Alter der Objekte (wird als Standard verwendet, wenn man nichts angibt).
  • heap GDSF optimiert die Objekt-Hitrate. Kleine, häufig angefragte Objekte werden auf Kosten großer, weniger häufig angefragter Objekte im Cache gehalten. Damit wird die Wahrscheinlichkeit eines Objekt-Hit gesteigert.
  • heap LFUDA optimiert die Byte-Hitrate. Häufig angefragte Objekte werden im Cache gehalten, selten angefragte werden freigegeben, unabhängig von deren Größe. Damit wird ein häufiger angefragtes, großes Objekt ggf. auf Kosten vieler kleiner Objekte im Cache gehalten. Damit steigt die Byte-Hitrate auf Kosten der Objekt-Hitrate.

Man kann Strategien auch mischen. Es bietet sich an, für Objekte im Ram heap GDSF zu verwenden und für Objekte im Festplatten-Cache head LFUDA. So wird ein ausgewogener Kompromiss zwischen schnellen Reaktionszeiten und Traffic sparen erreicht:

Als nächstes widmen wir uns in der selben Datei der Anonymisierung der Clients

  • via
    Nach RFC2616 ist es vorgeschrieben das ein Proxy seine Version im Header mitsendet. via off und alles ist gut 🙂
  • forwarded_for
    Der Proxy sendet per default die IP des Clients im HTTP Header mit.
    Mittels forwarded_for off schalten wir dies ab.

Nun zum komplexesten Teil den wir hier nur kurz streifen : ACL

In der ersten Zeile definieren wir das alle Clients die über das Subnet 192.168.1.0/24 kommen ab jetzt im squid als silvercloud behandelt werden.
Als nächstes erlauben wir silvercloud den ganzen HTTP Traffic.
Die einfachste aller Regeln besagt nun das Clients aus 192.168.1.0 uneingeschränkt ins Internet dürfen. Weiter gehen wir hier nicht ein da dies den Artikel sprengen würden.

Die ganze Konfig zum kopieren:

Wagen wir uns an den ersten Start:

Nun auf einen Client den RasPi als PRoxy in den Verbindungseinstellungen des Browsers einrichten und wenn alles gut gegangen ist währe das Thema fürs erste erledigt.

Wer auch noch interessiert ist welche URL’s vom Browser aufgerufen werden findet diese in folgender Datei: einfach mit den Editor eurer Wahl öffnen .

In diesem Sinne viel Spaß mit euren Proxy und beim austesten verschiedenster Konfigurationen.

Gute Lektüre findet ihr unter:

http://wiki.ubuntuusers.de/Squid
http://www.squid-handbuch.de/hb/