Hallo zusammen,
ich möchte meine Netzwerksecurity etwas dicht machen und sich die Raspi's die Updates aus dem internen Netzwerk ziehen lassen.
Hat das von Euch schon jemand realisiert? Ich würde mich über ein paar Umsetzungserfahrungen/Ideen freuen.
Für die apt-Paketverwaltung habe ich dies bereits erfolgreich umgesetzt. Ein Haupt-Raspi agiert dabei als Paketproxy.
Jetzt muss aber noch das FHEM dran glauben, bevor ich die Firewall dicht machen kann.
Gruß
volschin
Der Aufwand duerfte ueberschaubar sein.
- master FHEM Installation "normal" per Update aktualisieren.
- controls_fhem.txt aus dem FHEM Verzeichnis eins hoeher kopieren, sie soll neben fhem.pl liegen.
- fhem.pl nach fhem.pl.txt kopieren, contrib/commandref_join.pl nach contrib/commandref_join.pl.txt
- diese master FHEM Installation per HTTP intern freigeben. Entweder per apache/nginx oder mit FHEMWEB, wenn man in www ein Symlink nach .. legt.
- in allen slave FHEM Installationen die Datei controls.txt bearbeiten, und http://fhem.de/fhemupdate gegen die Adresse der master FHEM Installation austauschen.
Achtung: das ist alles ungetestete Theorie.
Hallo Rudolf,
danke für die Anregung.
Warum machst Du die Kopieroperationen nach txt?
Ich bin jetzt mal wie folgt vorgegangen:
cd www
sudo -u fhem ln -s .. install
cd ..
sudo -u fhem ln -s ./FHEM/controls_fhem.txt controls_fhem.txt
sudo -u fhem ln -s ./contrib/commandref_join.pl commandref_join.pl
Die URL in der controls.txt habe ich ebenfalls angepasst. Leider liefert das update nur einen nichtssagenden Fehler.
http://ha:8083/fhem/install/controls_fhem.txt: Select timeout/error:
Unter der URL habe ich die Datei vom Desktop abrufen können und auch ein wget vom Raspi mit dem ich das testen wollte, funktionierte. Auch ein Download von .pm und der fhem.pl klappt manuell.
Hast Du eine Idee, wo mein Fehler liegen könnte?
Gruß
volschin
Du hast kein Fehler gemacht, FHEMWEB war als fhemupdate Server ungeeignet:
- CHANGED wurde mangels Extension nicht ausgeliefert, sondern ein Redirect erzeugt.
- HttpUtils ist nicht in der Lage keepalive und Transfer-Encoding:chunked zusammen zu verarbeiten.
Das erste Problem habe ich gefixed, fuer den zweiten nur Workaround eingebaut, da ein Fix mir zu riskant ist: falls das fhemupdate Verzeichnis (bei dir install) localUpdate genannt wird, dann setzt 98_update.pm das keepalive Flag nicht. Mit folgendem controls.txt file und einem aktuellen FHEM Installation kann ich das update von einem FHEMWEB Server ausfuehren:
Zitathttp://localhost:8083/fhem/localUpdate/controls_fhem.txt
Danke für's Draufschauen.
Nach intensiverer Prüfung meines FHEMWEB Ansatzes mit dem Symbolic Link von www nach .. muss ich diesen leider verwerfen. Der Link macht security-seitig alle Türen auf. er lässt sich ja nicht auf eine eingeschränkte FHEMWeb-Instanz beschränken, sondern schlägt auf alle durch. Damit sind alle Dateien in allen Instanzen lesend erreichbar.
Also muss ich nochmal neu nachdenken. ::)
noch eine Idee ...
einen FHEM Master in der "DMZ" anlegen und dann von dort die Daten via rsync holen, damit sollte es klappen und die Musterinstallation braucht ja gar keine Nutzdaten ...
oder Du leitest alles von Deiner Raps Farm via iptables auf einen Proxy, den Du dann auch entsprechend dicht machen kannst
Ich habe es jetzt mit nginx gemacht.
cd /opt/fhem
sudo -u fhem ln -s ./FHEM/controls_fhem.txt controls_fhem.txt
sudo -u fhem ln -s ./contrib/commandref_join.pl commandref_join.pl
Dann in der /etc/nginx/sites-enabled/default das root auf /opt/fhem.
Zusätzlich habe ich unter location auf die erlaubten IP-Adressen der Raspi's beschränkt.
Falls man angepasste Dateien verwendet, ist das Setzen des Attributs updateNoFileCheck wichtig, sonst bricht er mit Fehler ab.
Ich bin noch am Überlegen, ob ich auch
server {
...
auth_basic "closed website";
auth_basic_user_file conf/htpasswd;
}
noch einbaue.
Bin mir noch nicht sicher, ob das Update-Modul mit so etwas klar kommt. Die Doku zum Updatemodul schweigt dazu.