HC2 Armbian und Logitech Media Server / OS auf HD

Hier beschreibe ich, wie man eine HC2 mit Armbian installiert und einem Logitech Media Server darauf betreibt.

HC2 Armbian Image & Installation HD

Die Installation von Armbian ist eigentlich “outofthebox”. Da die HC2 aber über eine SD Karte verfügt und die Lebensdauer entsprechend beschränkt ist, ist es von Vorteil, die in der HC2 eingebaute Disk als OS-Disk zu verwenden. Man kann leider die HC2 nicht über die HD Vollkommen boot-fähig machen. Fast nicht. Ich beschreibe hier, wie ich das gelöst habe:

Image / SD

  • Download (Focal-Image) & Installation: https://www.armbian.com/odroid-hc1/
  • SSH Standard Login: root  Password: 1234
    • Starte  das Dienstprogramm armbian-config und
    • gehe in den Bereich System -> DTB und
    • wähle die optimierte Kartenkonfiguration für Odroid HC1. Die gleiche Konfiguration gilt auch für HC2 und MC1.

Disc / HD

  • Erstelle auf der HD zwei Partitionen. Eine für das Betriebssystem (20G) und eine für die Daten (Rest)
  • HD identifizieren
sudo fdisk -l
  • Partitionen erstellen
sudo fdisk /dev/sda
d= delete partition
n= create partition
w=write partition
  • recheck
sudo fdisk -l
  • Erstelle Formatierung
sudo mkfs.ext4 -L os /dev/sda1
sudo mkfs.ext4 -L data /dev/sda2
  • Erstelle Mount-Verzeichnisse
sudo mkdir /osFiles
sudo mkdir /mnt/files
  • /etc/fstab anpassen: Mount Patitionen
#Mounts
/dev/sda1 /osFiles ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1
/dev/sda2 /mnt/files ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1
  • Reboot
  • Files auf neue OS-Partition (/osFiles) kopieren.
    Achtung: Alle Services (wie den logitechmediaserver) vorher beenden
sudo rsync -aAXHv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found","/osFiles"} / /osFiles
  • SDA uuid (UUID) herausfinden:
sudo blkid

/dev/sda1: LABEL="os" UUID="975a0396-5016-42b3-a66e-fe5276a36797" TYPE="ext4" PARTUUID="262deb28-e8fe-5d4d-b3a4-808b44571e85"
  • Im boot.ini die neue UUID setzen bzw. ersetzen:
sudo vi /boot/boot.ini
.
setenv rootdev "UUID=975a0396-5016-42b3-a66e-fe5276a36797"
.
  • reboot.
  • Wenn alles geklappt hat, sollte neu von sda1 gebootet werden. Check:
mount | grep '/ '
  • sollte folgendes ausgeben
/dev/sda1 on / type ext4 (rw,noatime,errors=remount-ro,commit=600,data=ordered)
  • Über armbian-config können neue U-boot Versionen eingespielt werden. Diese müssen weiterhin auf die SD-Karte gespiehlt werden. Deswegen soll das /boot Verzeichnis weiterhin auf die SD-Karte zeigen:
  • Microsd karte wieder einbinden.
  • erstelle  /mnt/microsd:
sudo mkdir /mnt/microsd
  • fstab erweitern
  • Editiere /etc/fstab, und füge hinzu:

/dev/mmcblk0p1 /mnt/microsd auto defaults 0 0 
/mnt/microsd/boot /boot none defaults,bind 0 0
  • Mount durchführen und prüfen ob korrekt gemountet wird
sudo mount /mnt/microsd && sudo mount /boot
  • Wenn alles ok ist

sudo reboot

Damit läuft das System nun (grösstenteils 😉 ) auf der HD anstelle der SD. Das entlastet die SD enorm und führt zu einem längeren Leben der SD Karte.

LMS Installation

LMS Download-Link: https://forums.slimdevices.com/showthread.php?98711-Logitech-Media-Server-Versions

Damit der LMS auf dem Armbian Focal läuft, müssen die Perl-Pakete selber kompiliert werden:

cd ~
sudo apt install nasm make gcc rsync patch g++ libc-bin zlib1g-dev libgd-dev libmodule-install-perl
git clone https://github.com/Logitech/slimserver-vendor.git
cd slimserver-vendor/CPAN/
./buildme.sh

Jetzt LMS downloaden und installieren

cd ~
wget http://downloads.slimdevices.com/nightly/8.1/lms/c9adb5f63e54ec0d72e6266e75fb73989f4be345/logitechmediaserver_8.1.2~1614990085_arm.deb
sudo dpkg -i logitechmediaserver_8.1.2~1614990085_arm.deb

Den LMS stoppen, da er noch nicht läuft. siehe

tail -f /var/log/squeezeboxserver/server.log
sudo service logitechmediaserver stop

Nun die compilierten Perl-Binaries nach LMS kopieren:

sudo cp -r ~/slimserver-vendor/CPAN/build/arch/5.30/arm-linux-gnueabihf-thread-multi-64int /usr/share/squeezeboxserver/CPAN/arch/5.30/

Und den Logitech Media Server wieder starten

sudo service logitechmediaserver start

Das wars. Damit rennt der LMS auf einer HC2. Brower starten und link aufrufen:

http://ip-adresse:9000

Links

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

ioBroker: Node.js Update / Reinstallation ioBroker

Ich betreibe seit einigen Jahren ioBroker, welches auf nodejs basiert. Heute war es an der Zeit die Nodejs Version von 8 auf 12 anzuheben, was leider nicht ganz ohne Probleme funktionierte. Hier fasse ich kurz zusammen, welche Schritte bei meiner Installation nötig waren. Die Schritte basieren auf diesem Howto.

Die einzige, im Howto beschriebenen und für mich funktionierende Lösung für das Update war, die komplette Reinstallation des ioBrokers. Dabei wird zuerst die neue Node.js Version installiert. Dann ein Backup des iobroker-data Verzeichnisses gezogen, die ioBroker-Installation gelöscht, neu installiert und dann das Backup wieder zurück gespielt:

Installation neue Node.js Version 12

cd /opt/iobroker
iobroker stop
cd

# install nodejs
curl -sLf https://deb.nodesource.com/setup_12.x | sudo -E bash -
sudo apt-get install -y nodejs

# install iobroker
curl -sLf https://iobroker.net/install.sh | bash -

Bei einer Aktualisierung von Node.js müssen bereits installierte JavaScript- Module im ioBroker-Ordner aktualisiert werden, da sonst Fehler bei deren Ausführung auftreten. Hier traten bei mir dann die Probleme auf. Die einzige bei mir funktionierende Lösung war, den ioBkoker neu zu installieren:

Backup und Neuinstallation ioBroker

  • Backup des iobroker-data Verzeichnisses nach “Home” ziehen
  • Die alte Installation löschen
  • ioBroker neu installieren
cp -r /opt/iobroker/iobroker-data ~/iobroker-data 
sudo rm -r /opt/iobroker/ 
sudo mkdir /opt/iobroker
cd /opt/iobroker
curl -sL https://iobroker.net/install.sh | bash -

ioBroker wird nach der Installation wieder gestartet. Wir stoppen ioBroker deswegen wieder:

iobroker stop

Nun löschen wir das neu erstellte iobroker-data Verzeichnis und kopieren das Backup

rm -r /opt/iobroker/iobroker-data
cp -r ~/iobroker-data /opt/iobroker/iobroker-data

Während meinen Installations-Bemühungen habe ich festgestellt, dass die Berechtigungen immer wieder durcheinander gehen. Es existiert deswegen ein korrektur-Script, welches die Berechtigungen des ioBrokers wieder gerade zieht. Es ist ratsam dieses jetzt durchzuführen:

cd /opt/iobroker
curl -sL https://iobroker.net/fix.sh | bash -

Jetzt den ioBroker neu starten

iobroker start

Der Start kann jetzt sehr lange dauern. Der ioBroker merkt jetzt, dass die Adapter (gem. Backup) fehlen und installiert diese neu nach.

Um zu schauen, wo die Installation steht, kann man das log konsultieren

tail -f /opt/iobroker/log/iobroker.current.log

Ein Adapter (zigbee) liess sich jetzt immer noch nicht installieren. Diesen habe ich dann noch manuell installiert:

cd /opt/iobroker
iobroker stop
sudo -H npm install iobroker.zigbee --unsafe-perm

Ganz zum Schluss dann nochmals die Berechitigungen gerade ziehen, um sicher zu gehen…

cd /opt/iobroker
curl -sL https://iobroker.net/fix.sh | bash -

Das wars. Jetzt den Raspi neu booten und sich über die neue ioBroker-Installation freuen 🙂

sudo reboot

 

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:

    1. Letsencrypt installieren
      sudo apt install letsencrypt python-letsencrypt-apache
    2. 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
    3. 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

     

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:

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

Sonos: Gut zu wissen

Dieser Beitrag ist “Deprecated”. Sonos ist dabei das schöne Upnp mit ihrer neuen API abzulösen (siehe https://developer.sonos.com/). Es wird wohl zwei API-Versionen geben. Eine für private Developer, für welche eine Cloud-API zur Verfügung gestellt wird und eine für Firmen, welche ein “lokales” API nutzen (und sich dafür zertifizieren) dürfen. Für Entwickler wie mich wäre also zukünftig das Ansteuern der Boxen nur noch über die Cloud möglich, was für mich nicht in Frage kommt. Ich hoffe Sonos bietet da dann doch noch etwas womit die Sonos Boxen über das LAN angesprochen werden können. Aktuell sieht es aber leider nicht so aus. Erste Funktionen, welche ich hier noch beschrieben habe, sind bereits durch Firmware-Updates herausgefallen (z.B. reboot). Wundert euch also nicht, wenn nicht mehr alle Upnp oder HTTP-Calls funktionieren.

Mittlerweile habe ich meine Sonos Boxen verkauft und bin auf eine OpenSource-Lösung, basierend auf Hifiberry und Max2Play umgestiegen. Damit ist es möglich, die gleiche Funktionalität von Sonos mit eigenen Boxen nachzubauen. Wie ich das gemacht habe, werde ich hier dokumentieren – sobald ich Zeit dafür habe.

Hints, Tips und Tricks rund um Sonos

Mein Sonos System umfasst insgesamt 7 Player (1 Sonos Soundbar und 6 Sonos Play:1). Sonos erstellt und unterhält sein eigenes Netz (Sonos-Net) selber. Grundsätzlich funktioniert das “out of the box”. Es kann aber doch manchmal nötig sein das Sonos-Net zu optimieren. Dazu anbei ein paar nützliche Infos:

Tools

Auf jeder Sonos-Box läuft ein Webserver, den man über den Browser ansprechen kann. Dabei können einige nützliche Infos eingesehen oder aber auch Einstellungen vorgenommen werden:

http://IP:1400/support/review Übersicht über die Sonos Box. Hier kann auch die Network-Matrix aufgerufen werden
http://IP:1400/advconfig.htm Einstellen der Root-Bridge (FirstZP und Priority auf „enabled“).
http://IP:1400/reboot Reboot der Sonos Box
http://IP:1400/region.htm WLAN Region sezten  (bei uns EU – Europa)
http://IP:1400/tools.htm Netzwerktools wie Ping, Traceroute, nslookup
http://IP:1400/status Status-Seite
http://IP:1400/wifictrl?wifi=off Stellt das WIFI bis zum nächsten Reboot ab
http://IP:1400/wifictrl?wifi=persist-off Stellt das WIFI Interface komplett ab. Wenn man nur über Kabel arbeiten möchte
http://IP:1400/status/scanresults Scanresults zeigt euch alle WLAN-Verbindungen an, welche von Sonos erreicht wurden. Kann je nachdem noch nützlich sein, für Android Smartphones gibt es da noch bessere Apps
http://<IP>:1400/status/tracks_summary Mit diesem Befehl kannst Du dir die Anzahl der Tracks anzeigen lassen
http://<IP>:1400/status/topology Zeigt die Sonos Topologie mit allen Sonos Playern und Media Servern

Nützliche Links: