- Wenn Materialien in Sweethome3d verändert werden sollen, müssen die zu verändernden Bereiche als Komponente in Fusion360 vorhanden sein.
- Anschliessend in Funsion360 > Export > als STEP exportieren
- Dann das File in FREECAD importieren
- Ctrl – A (alles markieren)
- Nun FreeCAD > Exportieren > als Collada (dae) File
- Das File nun in Sweethome 3d importieren. Nun können die Farben der Komponenten angepasst werden.
LMS auf Raspberry Pi
Hier wird beschrieben, wie man den LMS Server auf einem Raspberry Pi 4 installiert.
Voraussetzung
- Raspberry Pi OS ist installiert
- SSH Zugang ist eingerichtet
Installation
OS aktualisieren
sudo apt-get update && sudo apt-get dist-upgrade
Audio-Formate installieren
sudo apt-get install libsox-fmt-all libflac-dev libfaad2 libmad0
Download LMS
Die Versionen gibt es hier. Für den Raspi 4 brauchen wir die ARM Verison.
cd wget http://downloads.slimdevices.com/nightly/8.3/lms/fe81659879fef1a51537fb579b8e57b6a7b987d9/logitechmediaserver_8.3.0~1630708871_arm.deb sudo apt install ./logitechmediaserver_8.3.0~1630708871_arm.deb
Log überprüfen, ob alles ok installiert wurde
tail -n 100 /var/log/squeezeboxserver/server.log
Links
- https://www.byteshark.de/index.php/computer/smarthome/382-logitech-media-server-und-clients-installieren
- https://homehack.nl/creating-a-raspberry-pi-squeezebox-server/
- https://homehack.nl/maintaining-the-raspberry-pi-squeezebox-server-aka-logitech-media-server/
- https://forums.slimdevices.com/showthread.php?98711-Logitech-Media-Server-Versions
Octopi über Spacelynk (lua) ausschalten
Ich betreibe meinen 3D Drucker über einen Octopi. Die ganze Printlandschaft kann ich über einen Shelly-Switch einschalten. Das ausschalten ist aber etwas kniffliger, weil Octopi zuerst sauber ausgeschaltet (shutdown) werden muss, bevor der Shelly-Switch den Strom komplett ausschalten kann.
Dazu verwende ich die API, welche von Octopi zu verfügung gestellt wird:
- API CORS muss aktiviert sein
- User muss über System rechte verfügen
- API-Key muss unter dem User erstellt werden. Dieser kann dann für den Post-Request verwendet werden
Folgender Postrequest restartet den server:
curl --location --request POST 'http://octopi.home.arpa/api/system/commands/core/reboot?Host=spacelynk.home.arpa' \ --header 'X-Api-Key: xxxxxxxxxx'
Opnsense: VPN Client wechseln
Ich betreibe auf der Opnsense einen OpnVPN Client, der sich mit einem VPN-Anbieter verbindet. Der VPN-Anbieter bietet mehrere Server an, auf welche man connecten kann. Diese können hier definiert werden:
Der VPN-Anbieter ist als Gateway konfiguriert. Um sicherzustellen, dass das Gateway den korrekten Client verwendet, muss dieser in den Assignments zugewiesen werden. Wobei das System pro konfigurierten Client automatisch ein “Network-Port” erstellt. In diesem Beispiel ist mit “ovpnc3” die “ExpressVPNClient Switzerland1” gemeit. Das muss man leider wissen:
- “ovpn” = es handelt sich um openvpn
- c = es handelt sich um einen client (s wäre server)
- 3 = fortlaufende Nummer.
SL SSH-Zugang
Hier beschreibe ich, wie man Root Zugriff auf einen SL bekommt:
- Auf dem SL läuft ein SSH-Server, basierend auf dropbear. Um Zugriff zu erlangen, kann die SD-Karte entnommen und in einem Linux gemountet werden.
- Anschliessend ein Zertifikat erstellen
-
ssh-keygen -b 4096
- Das Public-Zertifikat, welches gerade erstellt wurde, unter authorized_keys abspeichern
-
tee -a /media/ralwet/73a6c7bb-21a8-49e2-af43-04dd5942473e/etc/dropbear/authorized_keys < ~/.ssh/id_rsa.pub
- SD-Karte wieder einbauen
- nun über SSH zugreifen
-
ssh root@<IP>
Sinn und zweck war es, zusätzliche ipk-Pakete (luaMysql-IPK ) für eine mysql Verbindung per Lua zu installieren:
- Login auf SL
- Installieren der drei Pakete
-
opkg install zlib_1.2.11-1_imx6.ipk opkg install liblua-mysql_2.2.0-6_imx6.ipk opkg install libmysqlclient_5.1.73-1_imx6.ipk
Links
- https://oldwiki.archive.openwrt.org/doc/howto/dropbear.public-key.auth
- https://linux.die.net/man/8/dropbear
- https://www.systutorials.com/how-to-passwordless-ssh-to-an-openwrt-router/
- https://openwrt.org/docs/guide-user/additional-software/opkg
Let’s encrypt
letsencrypt ist eine Zertifizierungsstelle, welche es erlaubt Zertifikate vollautomatisch und GRATIS zu generieren. Damit entfällt endlich die müsahme manuelle Erstellung von Zertifikaten. Und so geht es:
Ich installiere letsencrypt auf einem Ubuntu 16.04 System mit installiertem Apache:
-
- Letsencrypt installieren
sudo apt install letsencrypt python-letsencrypt-apache
- Zertifikat generieren
Bevors mit dem Zertifikate erstellen losgeht, muss ich zuerst den Apache-Dienst stoppen, weil letsencryp einen standalone Server auf port 80 verwendet:sudo service apache2 stop
Nun generiere ich das Zertifikat mit “certonly”. Damit modifiziert mir letsencrypt nicht das Apache-Config File. Dieses möchte ich selber modifizieren… Für jede Domain kann dieser Befehl wiederholt werden:
sudo letsencrypt certonly --agree-tos --email postmaster@yourdomain.ch -d www.yourdomain.ch
Und voilà:
IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/nextcloud.domain.ch/fullchain.pem. Your cert will expire on 2017-01-23. To obtain a new version of the certificate in the future, simply run Let's Encrypt again. - Some rewrite rules copied from /etc/apache2/conf- enabled/nextcloud.conf were disabled in the vhost for your HTTPS site located at /etc/apache2/conf-enabled/nextcloud-le-ssl.conf because they have the potential to create redirection loops.
Nun den Apache wieder starten:
sudo service apache2 start
- Das Script erstellt vollautomatisch die benötigten Zertifikate und legt diese ab unter
/etc/letsencrypt/live/your.domain.zz/
Das Zertifikat kann nun am conf-File des Apachen eingetragen werden
SSLCertificateKeyFile /etc/letsencrypt/live/your.domain.zz/privkey.pem SSLCertificateFile /etc/letsencrypt/live/your.domain.zz/cert.pem SSLCertificateChainFile /etc/letsencrypt/live/your.domain.zz/chain.pem
Renewal
Letsencrypt stellt Zertifikate aus, welche 90 Tage gültig sind. Es wird empfohlen, dass alle 60 Tage ein renewal durchgeführt wird. Dies kann am einfachsten über einen cron-job erledigt werden, der monatlich ausgeführt wird:
sudo vi /etc/cron.monthly/letsencrypt-renew
#!/bin/bash echo "Stop Apache2 Service" service apache2 stop echo "Renew letsencrypt certificates" letsencrypt --standalone renew echo "Restart Apache2 Service" service apache2 start exit 0
sudo chmod +x /etc/cron.monthly/letsencrypt-renew
- Letsencrypt installieren
Löschen
Mal erstellte Zertifikate, welche nicht mehr benötigt werden, können gelöscht werden:
sudo letsencrypt delete -d xx.domain.xx
docker / docker-compose Befehle
Container stoppen
docker-compose down
Container aktualisieren
docker-compose down docker-compose pull docker-compose up -d
Volumes anzeigen / löschen
Achtung! Dies entfernt einerseits die Container, aber inklusive die statischen Files bzw. Volumes (wordpress_files & db_data)
docker volume ls # Listet alle Docker-Volumes auf docker-compose down ––volumes # löscht ein Container inkl. Volumes (!)
Aktive Containers anzeigen
docker container ls # Listet alle aktiven container auf
Bash eines Containers öffnen
Es ist möglich über den Docker-Host auf eine Container-Bash zuzugreifen.
Syntax:
docker exec -i -t <docker-id> /bin/bash
Docker Logs anzeigen
Wenn Docker-Containers im “detached-mode” (-d) laufen, werden keine Logs angezeigt. Die Logs können folgendermassen sichtbar gemacht werden:
# Zeigt das Log docker logs <ContainerName/ContainerID> # Zeigt das laufende Log (tail -f) docker logs --follow <ContainerName/ContainerID> # Zeigt die letzen 2500 Zeilen des Logs docker logs --tail 2500 <ContainerName/ContainerID> # Zeigt das Log seit dem 28.12.2018 10:00 docker logs --since 2018-12-28T10:00 ContainerName/ContainerID
Auch docker-compose bietet die Möglichkeit auf die Docker-Logs zuzugreifen:
docker-compose logs <service-name>
Entferne nicht benutzte Docker Images
Folgender Befehl entfernt alle aktuell nicht benutzen Images und Volumes
docker system prune
WordPress Container auf Docker
Dieser Blog-Eintrag beschreibt, wie man auf WordPress auf einem Docker-Host installieren und damit mehrere WordPress-Instanzen auf einem Host betreiben kann.
Ich betreibe die Docker-Container hinter einem Proxy-Server, der aber nicht als Container läuft. Der Proxy-Server leitet die HTTPS-Requests an die entsprechenden Docker-Container weiter.
Dieser Beitrag setzt ein vorinstalliertes Photon 3.0 inkl. Docker und Docker-Compose voraus. Siehe hier.
Die Docker-Container können über diverse Befehle gemanaged werden. Siehe dazu eine kleine Übersicht hier.
WordPress installieren
Wir installieren WordPress mit Hilfe von Docker Compose. Dazu erstellen wir ein template:
mkdir wordpress cd wordpress vi docker-compose.yml
Im yml-Script erstellen wir eine WordPress- inkl. DB-Instanz.
WordPress-Instanz
- Die WordPress-Instanz hat eine Abhängigkeit zur DB.
- Die WordPress-Files werden unter /var/www/html abgelegt
- der Host-Port 80 wird zur wordpress-Instanz port 80 weitergeleitet (“80:80”)
- Die DB ist über Port 3306 anzusprechen (WORDPRESS_DB_HOST: db:3306)
- Der DB-User ist wordpress (WORDPRESS_DB_USER: wordpress)
- Das DB-Passowort ist zu setzen: WORDPRESS_DB_PASSWORD: <wordpress_db_password>
DB-Instanz
- Die DB-Files werden hier abgelegt: db_data:/var/lib/mysql
- Passort setzen: MYSQL_ROOT_PASSWORD: <mysql root password>
- Datenbank definieren: MYSQL_DATABASE: wordpress
- User definieren: MYSQL_USER <wordpress>
- DB-Passwort setzen: MYSQL_PASSWORD: (wordpress db password)
version: '3.3' services: wordpress: depends_on: - db image: wordpress:latest volumes: - wordpress_files:/var/www/html ports: - "8080:80" restart: always environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: (wordpress_db_password) db: image: mysql:5.7 command: '--default-authentication-plugin=mysql_native_password' volumes: - db_data:/var/lib/mysql restart: always environment: MYSQL_ROOT_PASSWORD: (mysql root password) MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: (wordpress db password) volumes: wordpress_files: db_data:
Die letzten beiden Linien restellen lokale Verzeichnisse auf dem Photon-Host. Hier werden die WordPress- und SQL-Files abgespeichert. Diese Files überleben somit, wenn der container zerstört und neu generiert wird.
Die Volumes werden unter
cd /var/lib/docker/volumes
erstellt und bleiben bestehen. Dies solange bis die Volumes mittels
docker-compose down -v
zerstört werden.
WordPress Container starten
Nun kann der Container einfach gestartet werden. Dank Docker Compose braucht man nur noch einen Befehl. Docker Compose erkennt automatisch das YAML im aktuellen Verzeichnis, durchläuft die Konfiguration und startet die Container-Anwendung:
docker-compose up -d
Den Prozess kann man anzeigen lassen
docker ps
Nun ist über http://<ip>:8080 auf die WordPress-Instanz zugegriffen werden.
WordPress Container mit SSL erweitern
Das so bereitgestellte Container-Image bietet WordPress “out-of-the-Box” über Port 80 an. Port 443 ist nicht aktiviert. Man geht dabei davon aus, dass die Verschlüsselung (https) eine zusätzliche, neue Funktion darstellt und damit über einen weiteren Container abzubilden ist. Dazu kann ein Proxy-Container aufgebaut werden, für den es auch bereits fertige Docker-Images gibt. Architektonisch mag das Sinn machen.
Ich möchte das aber nicht so umsetzen. Ich betreibe bereits einen Proxy-Server und dieser soll auch so weiter beibehalten werden. Ich verzichte also auf einen Proxy-Container und erweitere das WordPress-Image durch die SSL-Funktionalität. Damit das geht, muss ich das docker-compose.yml bzw. die WordPress-Container Beschreibung erweitern.
Als erstes erstelle ich ein zusätzliches File
vi wordpress/wp-init.sh
!/usr/bin/env bash apt-get update apt-get install -y --no-install-recommends ssl-cert rm -r /var/lib/apt/lists/* a2enmod ssl a2dissite 000-default.conf a2ensite apache2-vhosts.conf docker-entrypoint.sh apache2-foreground
Dieses Bash-Script soll bei jedem Starten des Containers ausgeführt werden. Mittels diesem Script wird
– SSL nachinstalliert
– Die Default Konfig “000-default.conf” auf dem Apachen entfernt und stattdessen
– eine neue Konfig “apache2-vhosts.conf” installiert.
– Anschliessend wird der Apache neu gestartet.
Damit das Script funktioniert braucht es noch eine Apache-Config. Diese Config wird in den WordPress-Container gemappt und beim Container-Start aktiviert. Damit kann ich von ausserhalb des Containers, die Apache-Config manipulieren:
vi wordpress/apache2-vhosts.conf
NameVirtualHost * <VirtualHost *:443> ServerName domain.ch DocumentRoot /var/www/html/ DirectoryIndex index.php Options -Indexes SSLEngine On SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key SSLCACertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem </VirtualHost>
Nun ist das das docker-compose.yml zu erweitern (siehe die markierten Erweiterungen):
version: '3.3' services: wordpress: depends_on: - db_node image: wordpress:latest volumes: - wordpress_files:/var/www/html - ./wp-init.sh:/usr/local/bin/apache2-custom.sh - ./apache2-vhosts.conf:/etc/apache2/sites-available/apache2-vhosts.conf ports: - "8080:80" - "8443:443" restart: always environment: WORDPRESS_DB_HOST: db_node:3306 WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: (wordpress db password) container_name: wordpress_web command: "bash -c apache2-custom.sh" db_node: image: mysql:5.7 command: '--default-authentication-plugin=mysql_native_password' volumes: - db_data:/var/lib/mysql ports: - 6601:3306 restart: always environment: MYSQL_ROOT_PASSWORD: (wordpress root password) MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: (wordpress db password) container_name: wordpress_db volumes: wordpress_files: db_data:
Wie man sieht wird
– das wp-init.sh Skript in den Container gemappt
– Die Apache-Config apache2-vhosts.conf in den Container gemappt.
– Der Container um den Port 8443 erweitert, der Container-Intern auf 443 routet und
– Das Commando “bash -c apache2-custom.sh” bei starten ausgeführt.
Damit startet der Container ab sofort mit aktiviertem SSL und der Apache-Container kann über das File apache2-vhosts.conf konfiguriert werden.
Reverse Proxy
Auf dem Reverse-Proxy wird nun einfach eine Reverse-Rule für den Container eingeführt. Der Reverse-Proxy leitet die HTTPS-Anfragen intern an den Container-Host mit Port 8443 weiter. Diese kann so aussehen:
<VirtualHost serverIp:80> ServerAdmin info@domain.ch ServerName www.domain.ch ServerAlias domain.ch RewriteEngine on ReWriteCond %{SERVER_PORT} !^443$ RewriteRule ^/(.*) https://www.domain.ch/$1 [NC,R,L] </VirtualHost> <VirtualHost serverIp:443> ServerAdmin info@domain.ch ServerName www.domain.ch #aktiviert SSL Unterstuetzung SSLEngine On SSLProxyEngine on SSLProxyVerify none SSLProxyCheckPeerCN off SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off SSLCertificateKeyFile /etc/letsencrypt/live/www.domain.ch/privkey.pem SSLCertificateFile /etc/letsencrypt/live/www.domain.ch/cert.pem SSLCertificateChainFile /etc/letsencrypt/live/www.domain.ch/chain.pem # Regeln zum umleiten auf den internen Server ProxyPreserveHost On ProxyRequests Off ProxyPass / https://www.domain.ch:8443/ ProxyPassReverse / https://www.domain.ch:8443/ RequestHeader unset Accept-Encoding ErrorLog /var/log/apache2/error.log # Possible values include: debug, info, notice, warn, error, crit, # alert, emerg. LogLevel warn CustomLog /var/log/apache2/access.log combined ServerSignature On </VirtualHost>
SMTP auf WordPress-Container
Ich betreibe einen eigenen Mailserver. Ich stellte rasch fest, dass WordPress keine Mails über diesen Server versenden kann. Dies, weil das WordPress-Image einerseits grundsätzlich keinen SMTP-Agent mit dabei hat und andererseits mein Mailserver auch nicht aus dem Container heraus erreichbar war:
- https://github.com/docker-library/php/issues/135
- https://github.com/docker-library/wordpress/issues/30
Um das Problem zu lösen habe ich mir einfach das Plugin “WP Mail SMTP” installiert. Dieses erweitert WordPress um die Mailfunktion. Das Connectivity-Problem konnte ich mit einer einfach Erweiterung von /etc/hosts lösen:
192.168.xx.xx mx.domain.ch
Man beachte, dass ich die interne IP des Mailservers verwende.
Damit diese Erweiterung auch bei einem neuen Create des Containers übernommen wird, muss wordpress/wp-init.sh noch modifiziert werden:
#!/usr/bin/env bash # modify /etc/hosts with mx.intelli.ch cat >> /etc/hosts <<-EOF /* mx.intelli.ch */ 192.168.xx.xx mx.domain.ch EOF apt-get update apt-get install -y --no-install-recommends ssl-cert # SSL rm -r /var/lib/apt/lists/* a2enmod ssl a2dissite 000-default.conf a2ensite apache2-vhosts.conf # finally execute default command docker-entrypoint.sh apache2-foreground
Links
Nextcloud Sync mit Ftp-Server
Hier habe ich beschrieben, wie man auf Nextcloud einen FTP-Server als externen Speicher konfigurieren kann. Mit einem kleinen Hack ist es damit möglich Files von einem FTP-Server auf Nextcloud zu “pushen”. Wirklich funktioniert hat das bei mir nicht zufriedenstellend. – Das wird so von Nextcloud/Owncloud auch nicht offiziell supported. Zeit für einen zweiten Anlauf, der nun seit einem knappen Jahr für mich zufriedenstellend funktioniert:
Der Use-Case ist immer noch derselbe:
- Mein Drucker kann auf einen FTP-Server scannen, nicht aber in ein Webdav Verzeichnis
- Ich möchte die gescannten Dokumente aber direkt in Nextcloud haben und mich nicht noch zusätzlich mühsam auf den FTP-Server connecten um die Dokumente abzuholen.
Meine Lösung:
- Ich betreibe einen eigenen FTP Server.
- Statt in Nextcloud diesen FTP Server als externen Speicher hinzuzufügen, mounte ich auf dem FTP-Server selber das Nextcloud-Verzeichnis mittels davfs2 (also mit WebDav):
- Dazu richte ich auf Nextcloud einen speziellen User (Scan) ein, der nur für das Scanning verwendet wird. Dieser Nextcloud-User hält das Verzeichnis in welches gescannt wird.
- Dieses Verzeichnis wird dann mit allen Nextcloud-Usern geteilt, welche über das “Scan-Feature” verfügen möchten (über Verzeichnis teilen).
- Auf dem FTP Server mounte ich das Nextcloud Scan-Verzeichnis des Users “Scan” mittels davfs und konfiguriere das Ziel-Scanverzeichnis des FTP Servers auf eben dieses Verzeichnis des Scan-Users. Damit verwende ich das offiziell von Nextcloud unterstützte WebDav Protokoll um vom FTP Server nach Nextcloud zu speichern.
Und los geht’s:
davfs2 installieren
Auf dem FTP-Server “webdav” installieren:
sudo apt-get install davfs2
Nextcloud Webdav als root mounten
Der mount kann folgendermassen durchgeführt werden:
sudo mount -t davfs https://nextcloud/remote.php/webdav/ /home/user/nextcloudScan/ -o uid=<userid>,gid=<groupid>,file_mode=775,dir_mode=775
Damit dies automatisch beim Systemstart passiert, trage ich dies in /etc/fstab ein. Bitte beachten, dass ich zusätzlich die Option “noauto” hinzufüge. Ein direktes mounten beim booten (auto) schlägt fehl, weil das Netzwerk zu diesem Zeitpunkt noch nicht aufgebaut ist. Das automatische mounten kommt später.
https://nextcloud/remote.php/webdav/ /home/user/nextcloudScan/ davfs noauto,uid=<userid>,gid=<groupid>,file_mode=775,dir_mode=775 0 0
Nun wird jeweils noch der Webdav-User inkl. Passwort abgefragt. Diese Infos kann man im file /etc/davfs2/secrets hinterlegen:
/home/user/nextcloudScan <nextcloudUser> <nextcloudPasswort>
Nun sollte ein mount automatisch funktionierten:
sudo mount /home/user/nextcloudScan
Der Trick liegt nun dabei, dass das der FTP-Server in das Verzeichnis nextcloudScan schreibt. Meinen FTP Drucker konfiguriere ich entsprechend. Damit schreibt der Drucker indirekt nach Nextcloud.
Automatisch beim booten mounten
Das file /etc/rc.local
wird nach dem booten ausgeführt. Hier hinterlege ich nun noch meinen mount-Befehl:
vi /etc/rc.local mount /home/user/nextcloudScan
…Voilà, jetzt werden alle Einträge in der fstab gemounted.
Alternative: Das lokale FTP-Verzeichnis mit rsync nach nextcloud synchen
Ansonsten könnte man auch das FTP-Verzeichnis auf dem FTP-Server mit rsync synchronisieren. Das ist aber mit obiger Lösung so nicht mehr nötig.
rsync -rutv --inplace scan/ nextcloudScan/
Referenzen
FTP-Scanning nach Nextcloud
Dieser Beitrag ist deprecated. Siehe hier für neue Lösung.
Ich habe zuhause einen schönen Drucker/Scanner stehen. Dieser Drucker/Scanner kann Dokumente einscannen und direkt an einen FTP-Server senden. Tolle Sache. Nun möchte ich aber, dass der Drucker direkt nach Owncloud scant. Owncloud selber hat keinen integrierten FTP-Server. Aber man kann in Owncloud einen FTP-Server als externen Speicher hinzufügen (siehe hier). Continue reading