Mein neuer „Server“

Endlich fertig. Server ersetzt durch 1x Seagate Goflex Net mit Debian. Plus 1x Raspberry PI 2.
-> Gesamtverbrauch USV + Router + NAS + 2x 3,5″ Festplatten + PI + DVB-S2 USB Karte beläuft sich jetzt auf 24Watt.
Der alte Server alleine hat vorher etwa 55 Wat „verbraten“. +NAS + USV + Router warens etwas über 70 Watt !!

image

Die Leistungsaufnahme gliedert sich inetwa wie folgt :
USV 2 Watt
NAS 4 Watt
HDD1 3 Watt
HDD2 3 Watt
PI 3 Watt
DVB-S 6 Watt
Router 3 Watt


Die Angabenn sind natürlich nur ungefähr, weil z.B. Netzwerkanschlüsse auch „strom verbrauchen“, sobald was angesteckt ist.
Z.B. benötigt ein Gigabit Router etwa 0,5-1 Watt mehr, wenn ein Gigabit-Gerät angesteckt wird…

Besonders toll ist aber natürlich, dass dieses System wesentlich leistungsfähiger ist, als der Server.
Über LAN krieg ich vom und zum NAS etwa 35MBytes/Sekunde. Und die 100MBit des PI fallen auch kaum negativ ins Gewicht, weil der PI schließlich keine Freigaben bereitstellen muss.

Und für die „üblichen“ Aufgaben, d.h. VNC Server mit Mail (Icedove = Linux Thunderbird), Browser (Iceweasel = Linux Firefox), Libre Office reichts allemal…

-> Damit brauch ich auf meinem Laptop eigentlich nix mehr speichern, kann man alles „remote“ am PI machen (und am NAS redundant speichern). Ein OpenVPN Client und ein VNC Viewer am Laptop. Fertig.

12V Unterspannungsabschaltung

Einen Bleiakku mit einer Solarzelle zu laden ist keine grosse Sache. Dann noch einen Schalter und eine 12V LED Beleuchtung dran, schon hat man z.B. für den Außenbereich eine autarke Beleuchtung.
Soll allerdings z.B. ein Accesspoint rund um die Uhr betrieben werden, dann benötigt man unbedingt eine Unterspannungsabschaltung. Sonst ist der Blei Akku in Null Komma Nix kaputt. Diese sollte einen möglichst geringen Eigenverbrauch haben. Kleiner 1mA wäre toll…
Hab mittlerweile ein paar Datenblätter studiert. Vermutlich ist der 78l05 nicht optimal. Der braucht etwa 5mA. Evtl ist hier eine Bandgap Referenz besser geeignet. Manche davon laufen bereits mit 0,4mA.
Die nächste Überlegung ist halt noch, ob Power Mosfet oder bistabiles Relais…

Mein nächstes Spielzeug :

image

Sobald die Teile da sind, bau ich das auf.

Und wenn das ordentlich funktioniert, dann ist es ja recht universell einsetzbar; z.B. als USV für einen PI, ein NAS, eine Webcam; eigentlich alles, was halt mit Gleichspannung zu betreiben ist.
Ein 8AH Akku versorgt halt damit alles mögliche mehrere Stunden mit einem billigen Bleiaku, ohne dass der Schaden nimmt.

Update :

Habs mittlerweile aufgebaut. Funkt perfekt.
Ich hab aber statt dem Spannungsregler gleich 2 Badgaps genommen. Dadurch brauch ich keinen Spannungsteiler, und hab mit 1MOhm Vorwiderstand eine stabile 2,5V Referenz. Dadurch ergibt sich ein Ruhestrom von gerade einmal 0,4mA für die ganze Schaltung !!!

IMG_20151229_173859 IMG_20151229_173907 IMG_20151229_174245

 

OpenVPN Server mit wechselnder IP Adresse

Hab vor kurzem eine OpenVPN Verbindung zu einem Server mit wechselnder IP Adresse eingerichtet.
„Eh alles ganz einfach“ möchte man vielleicht meinen.
„Wozu gibt es Services wie DynDNS, NoIP u.ä.“.

Tja.

Geben tuts die schon. Allerdings sind die „free“ Zugänge alles andere als zuverlässig.
Und noch dazu wird man mit unnötigen „Login Notifications“ belästigt.
(Meisst muss man sich mindestens 1x pro Monat einloggen, sonst wird der Hostname gelöscht)

Die Bezahl-Zugänge sind vermutlich zuverlässiger, allerdings :
Wer will schon ein paar Euro/Monat nur dafür zahlen, damit zwischen 2 Standorten eine Verbindung aufgebaut werden kann ?!?
(Wenn es ein TopLevelDomain-DynDNS ist, auf welchem man Websites hostet, dann siehts nat. anders aus…)

Drum hab ich mir gedacht, da muss man ja auch selber was stricken können. Kann man…

Als erstes benötigt man dafür natürlich einen Webspace, der sehr zuverlässig funktioniert.
Da drauf kommen 2 php Scripts :
eintragen.php

<?php
 $ip=$_SERVER['REMOTE_ADDR'];
 $f=fopen("/tmp/ipvonwoswoasiwem.txt","w") or die("Unable to open file!");
 fwrite($f,$ip."\n");
 fclose($f);
?>

auslesen.php

<?php
 $f=fopen("/tmp/ipvonwoswoasiwem.txt","r") or die("Unable to open file!");
 $ip=fread($f,50);
 echo $ip;
 fclose($f);
?>

Damit ist schon mal die Möglichkeit geschaffen, dass der VPN-Server seine IP „bekannt“ machen kann, und der Client kann sie abholen.

Der Server muss, sobald er feststellt, dass sich seine IP geändert hat nur noch z.B. ein wget machen, das könnte etwa so aussehen :

wget -O- http://example.com/optionalesverzeichnisdamitsniemandsoleichtmanipulierenkann/eintragen.php

Damit der Server nicht unnötigerweise z.B. jede Minute bei einem exterenen Dienstleister (z.B. whatsmyip.com) nachfragen muss, kann man dazu auch ganz einfach abfragen, ob noch irgendein VPN Client eingewählt ist. (geht viel schneller, und verursacht keinen extra Internet-Traffic).

Soweit die Server-Seite. (der OpenVPN Server muss halt dort noch eingerichtet werden…)

Jetzt gehts weiter mit der Client Seite. Da wirds richtig „tricky“.

Das Problematische daran ist, dass es die OpenVPN Binary IMMER als „Service“ läuft. D.h. egal, ob Server oder Client, einmal gestartet, verbindet er sich mit der angegebenen Adresse (IP oder Hostname). Bricht die Verbindung ab, versucht er die gleiche Verbindung wieder aufzubauen. Ändert sich die öffentliche IP auf der Client-Seite, ist das überhaupt kein Problem; die Verbindung steht ca. 1-2 Sekunden nach der Internet Verbindung wieder. Ändert sich allerdings die IP auf der Server-Seite, dann wirds problematisch. Wie soll man das feststellen, ohne DynDNS zu verwenden ? Es gibt zwar „Hooks“, die etwas triggern können, allerdings einen „Error-Hook“ hab ich bisher noch nicht gefunden.

Also doch wieder DynDNS. Aber anders. Bei mir ist der OpenVPN Client ein Raspberry PI, der Internet-Router läuft auf OpenWRT. Damit kann man schon was anstellen. Aber es gibt – wie immer – mehrere Möglichkeiten :

*) die /etc/hosts Datei ändern

Das ist unpraktisch, kompliziert, und (weil man die Datei nicht so einfach auf die RAMDisk bekommt) führt möglicherweise auch zu Problemen beim Booten. Da sind Einträge drin, die u.U. für einen erfolgreichen Boot vermutlich notwendig sind (sowohl beim PI, als auch beim Router)

*) die /etc/dnsmasq.conf ändern

Das ist auch nicht viel besser. u.U. hat man da drin z.B. Werbeblocker u.a. drinnen.

*) DAS IST ES :

Es gibt in der /etc/dnsmasq.conf einmal die Möglichkeit, zusätzliche Config-Dateien einzubinden (mit conf-file=…) und dann aber noch die Option eine „künstliche“ hosts Datei zu verwenden. Der Eintrag dazu lautet :

addn-hosts=/tmp/dynhosts

Den einfach ganz am Ende einfügen; dann erhält man das gewünschte Ergebnis; dnsmasq kann AUCH OHNE diese Datei (z.B. beim Booten) hochfahren; die Datei kann man nach belieben unendlich oft wiederbeschreiben (weil sie in der RamDisk liegt).

Ein „Problemchen“ bleibt noch : im Gegensatz zur „echten“ hosts Datei werden die Änderungen nicht „on-the-fly“ übernommen. Aber auch dafür gibt es eine ganz simple Lösung : man sendet ein „kill -1“ (=sighup), dann lädt dnsmasq seine Config neu, ohne irgendeine sonstige Unterbrechung. Das Kommando dazu lautet :

kill -1 $(cat /var/run/dnsmasq/dnsmasq.pid)

Bzw. das komplette Script namens dyndns.sh :

#!/bin/sh
dyn=/tmp/dynhosts
soll=$(wget -O- -T 5 http://example.com//optionalesverzeichnisdamitsniemandsoleichtmanipulierenkann/auslesen.php 2>/dev/null)
if test "$soll" == ""
then
 soll=$(wget -O- -T 5 http://example_redundant.com//optionalesverzeichnisdamitsniemandsoleichtmanipulierenkann/auslesen.php 2>/dev/null)
fi
if test "$soll" != ""
then
 ist=$(cat $dyn 2>/dev/null | cut -d" " -f1)
 if test "$soll" != "$ist"
 then
  echo "Ziel IP alt = $ist, update auf $soll" >> /tmp/meineigenesdyndns.log
  echo "$soll zielserver" > $dyn
  kill -1 $(cat /var/run/dnsmasq/dnsmasq.pid)
 fi
fi

Ich hab auch gleich noch einen 2. Webspace (der die gleiche Information bereithält) eingebaut, somit ergibt sich sogar eine gewisse Redundanz, falls mal was nicht geht.

Wenn man das script (auf seinem Hauptrouter) aufruft, und dann z.B. ein „ping zielserver“ eingibt, dann sollte (zumindest versucht) werden, die entsprechende Gegenstelle anzupingen.

Aufgerufen wird das Script (bei mir) 1x pro Stunde, und, sobald mein „dauerping“ Script feststellt, dass zwar das Internet geht, aber die VPN Verbindung nicht.

Somit gibt es kaum extra Internetverkehr, aber die Verbindung sollte trotzdem in <1min wieder da sein, falls sich die Server-IP geändert hat.

Damit kann die „Domain“ auch problemlos in einer OpenVPN Konfigurationsdatei verwendet werden…. (Sogar auf einem Raspberry PI „hinter“ dem Router)

Update :
Was mir noch so aufgefallen ist : wenn statt zielserver ein Name mit Punkt verwendet werden soll, dann gibts zumindest mit .local Probleme.
D.h. zielserver.local -> geht nicht
zielserver.lo -> geht

WLAN Tunings

So manch einer fragt sich sicher :“Warum ist die Banane krumm ?!?“.
Aber darum geht es hier nicht. 🙂
Es soll allerdings die Frage beantwortet werden : „Warum ist mein WLAN so langsam…. ?!?“

Tja, dafuer gibt es viele Gruende….

1. Ein Kabel ist ein kabel.
Wenn es geht, ist natuerlich immer ein Kabel vorzuziehen. Aber in der heutigen Zeit sitzt ja keiner mehr
vor einem PC. Und ein Haendy oder ein Tablet hat halt kaum einen LAN Anschluss; fuer Laptops ist es auch eher unpraktisch.
2. Interferrenzen
Mein Nachbar betreibt ein WLAN auf Kanal 1.
Um keine gegenseitgen Stoerungen zu verursachen, verwende ich, schlau, wie ich bin -> Kanal 2.
-> Super Idee !!!
Nur: leider komplett falsch !
WLAN Kanaele sind mind. 20MHz breit, die einzelnen Kanaele sind aber nur 5MHz auseinander !!!
(Kanal = jeweils die Mitten-Frequenz, +- 10 MHz werden benötigt, beim nächsten AP ist natürlich das gleiche notwendig)
-> Um das WLAN Spektrum im 2,4 GHz Spektrum bestmoeglich auszunutzen, duerfen NUR FOLGENDE KANAELE benutzt werden :
1,5,9,13(*)
Allerdings kommt es noch viiiiel schlimmer :
Soll z.B. ein „300MHz“ WLAN Router verwendet werden, dann benoetigt man (weil man 40 MHz Bandbreite braucht)
natuerlich UNBEDINGT 2 solcher Kanaele.
D.h. es darf dann nur mehr :
1 und 9
verwendet werden !!!!
Hat man einen Nachbarn, der z.B. auf Kanal 6,7 oder 8 sendet, dann hat man verloren. -> max die Haelfte moeglich, weil keine 40 MHz durchgehend vorhanden sind !!!

3. Klingt alles voll super. Ich habe mehrere Accesspoints auf Kanal 1,6,11 laufen. Ist das falsch ?
Falsch ist es nicht.
Aber es nutzt halt nicht alle in Europa verfuegbaren Kanaele aus.
(In Amerika ist nur 1-11 erlaubt, in Europa 1-13)
Das bringt aber unweigerlich das Problem zum Vorschein, dass es in Amerika nur 1(!) Kanal im 2,4 GHz Bereich gibt,
der 40MHz Bandbreite bringt.

Das Schema „1-6-11“ war allerdings frueher auch in Europa ueblich.
Der Grund dafuer ist – ganz einfach – die höhere damals noetige Bandbreie im „alten“ 802.11b (=“11MBit WLAN“).
Die war naemlich 22MHz statt 20MHz.
Dabei galt allerdings das gleiche : Kanal 12,13 war damals nutzlos.

Sind Geraete im Einsatz, die nur fuer den amerikanischen Markt bestimmt sind, dann ist das Kanalschema
„1-6-11“ keine schlechte Option; die Nachbarn wirds aber sicher nicht freuen !!
-> besser auf 1-5-9(-13) bzw. noch besser : NUR 1 oder 9 einstellen !!!

Raspberry PI Basics

Muss man einen Raspberry PI neu aufsetzen, dann stellen sich sofort immer wieder ein paar grundlegende Fragen.
z.B.: „Brauch ich Monitor, Maus, etc. dafuer ?“

Antwort :
Nein. Braucht man nicht. Zumindest nicht ab Raspbian Jessie. (Bei Wheezy gehts braucht man Tastatur&Bildschirm !!) Es ist allerdings ein DHCP Server („Router“) notwendig, mit dem
man moeglichst einfach die IP des PIs herausfinden kann.

-> z.B. mit Win32DiskImager ein frisches Image auf die SD/microSD Karte schreiben, den PI mit
der Karte ans LAN+Strom anschliessen, und etwas warten.

Dann kann man sich per SSH (mit der IP, die man aus dem Router herausfinden muss) einloggen.
Username : pi
Passwort : raspberry

Als erstes mit „passwd“ gleich mal ein Passwort fuer den „pi“-User setzen.
Mit „sudo -i“ wechselt man zum Root-User. Beim ersten Mal wird gleich „rapsi-config“ aufgerufen.
Damit kann man so grundlegende Dinge machen, wie z.B. Dateisystem vergroessern, Hostname setzen, etc…
(Zumindest dann,) wenn das Dateisystem vergroesser werden soll, ist ein erstmaliger Reboot notwendig.

Um was vernuenftiges machen zu koennen, emfiehlt nach dem ersten reboot folgendes :

apt-get update
apt-get upgrade -y
apt-get install vim screen tightvncserver mc -y

Ist man sich nicht sicher, ob man vom DHCP jedes mal die gleiche IP bekommen wird (nachdem die lease-time abgelaufen ist),
dann sollte auf jeden Fall eine fixe IP eingestellt werden. (Ausserhalb des DHCP IP Ranges, ebenfalls im Router nachzuschaun) :
vi /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
gateway 192.168.1.1
#pre-up iptables-restore > /etc/resolv.conf
echo „nameserver 8.8.4.4“ >> /etc/resolv.conf
Das mit den Name-Servern ist aber leider nicht Reboot-Resisdent.
-> Am besten in die /etc/rc.local vor dem „exit 0“ einbauen.

Damit werden die am haeufigsten beschriebenen Verzeichnisse in eine RAMDisk gelegt :
echo „tmpfs /tmp tmpfs defaults,noatime,nosuid,size=100m 0 0“ >> /etc/fstab
echo „tmpfs /var/tmp tmpfs defaults,noatime,nosuid,size=30m 0 0“ >> /etc/fstab
echo „tmpfs /var/log tmpfs defaults,noatime,nosuid,mode=0755,size=100m 0 0“ >> /etc/fstab
echo „tmpfs /var/run tmpfs defaults,noatime,nosuid,mode=0755,size=2m 0 0“ >> /etc/fstab

Das hat nicht nur den Vorteil, dass die SD Karte kaum mehr verschleissen wird; ausserdem wird der PI
dadurch recht unempfindlich gegen Stromausfaelle, da ja kaum mehr Dateien schreibend geoeffnet sind.
(zumindes nicht auf der Karte). Log-Files sind halt dann weg… (!auch bei einem ordnungsgemaessen reboot!)

Anm.: hat man das gemacht, kommt es bei einigen Diensten zu Problemen.
z.B. apache startet nach einem reboot nicht mehr (obwohl man es ordnungsgemaess installiert hat, und es vor
dem Reboot auch problemlos funktioniert hat).
Der Grund dafuer ist ganz einfach :
Das Verzeichnis /var/log/apache2 wird bei der installation angelegt, aber NICHT bei einem Reboot.
Abhilfe :
vi /etc/init.d/apache2
/start)
und direkt danach :
mkdir -p /var/log/apache2

Dann kann man – ganz einfach – mit :
„service apache2 start“

testen, ob es wieder klappt.

Update !!!!!!

Beim Raspbian Jessie sind per default schon einige Verzeichnisse als RAMDisk gemountet.
Da darf nur mehr /var/log und /tmp in die fstab eingetragen werden !!!
Das ist natuerlich z.B. bei einem Upgrade unbedingt zu beachten !!

Random Number Generator

modprobe bcm2708-rng
echo „bcm2708-rng“ >> /etc/modules

ssh mit ROOT
Es ist zwar ein tolles Feature, dass man sich als „root“ per ssh nicht einloggen kann,
sondern erst nach dem Login z.B. via „sudo -i“ den user wechselt, allerdings hat das
(solange der PI sowieso nicht via oeffentlicher IP aus dem Inernet erreichbar ist)
und natuerlich, solange man den „pi“ – user weiterverwendet keinerlei Sicherheitsvorteile.
Das Schaltet man ab mit:

In der /etc/ssh/sshd_config

PermitRootLogin without-password
Aendern in :
PermitRootLogin yes

service ssh restart

ssh ohne DNS
Dauert es recht lange (ca. 5 Sekunden) zwischen Username und Passwort Abfrage beim Login via ssh,
dann liegt es meisst an einem DNS-Feature.
Um das abzustellen :

echo „UseDNS no“ >> /etc/ssh/sshd_config
service ssh restart

PI Nachteile :

*) Fehlende Echtzeit Uhr (da gaebe es allerdings was zum Basteln… evtl. auch mit DCF77 ?!?)
*) Fehlende SATA Anschluesse
*) LAN nur 100MBit (und intern nur via USB angeschlossen) -> hohe CPU Last !!
*) Stromversorgung via Micro-USB Netzteil (damit sind die 4 USB Anschluesse des B+ und B2 nur recht eingeschraenkt nutzbar)
*) KEIN GBitLAN/KEIN USB3 !!
*) MicroSD (geht aber trotzdem recht zuverlaessig) besser waere aber sicher ein int. 4 oder 8 GB Flash
oder alternativ : 2 Einschuebe, mit denen man ein RAID machen kann !!!
*) „Bootloader“ auf einer FAT (!!!!) Partition -> ging zumindest zu Anfangszeiten schon mal „kaputt“ !!
ist DAS im Jahre 2015 notwendig ?!?