FHEM im LXC

Ranseyer · 30 Oktober 2017, 14:54:24

Ich fasse nochmals zusammen wie man FHEM im LXC betreiben kann.
Aus meiner Sicht empfiehlt es sich keine USB Geräte oder noch speziellere Schnittstellen wie GPIO für die Anbindung nach außen zu verwenden.
Ich versuche also möglichst alle I/Os per LAN anzusprechen ! (keinesfalls WLAN!!)

Ich beschreibe auch nicht den Weg mit Proxmox: Proxmox ist sehr innovativ, aber auch im Bezug auf die HW machmal wählerisch und man muss das Konzept mögen.
Eine weitere Alternative für den Heimgebrauch wäre VM-Ware ESXi. Aber auch hier sollte mal vorsichtig sein mit der HW.

Außerdem gibt es Xen und KVM. Bei beiden läuft allerdings immer ein eigener Kernel. (Xen nutze ich seit 5 Jahren nicht mehr und KVM würde ich einsetzen wenn auch Grafische Spielereien mittels Spice gewünscht werden)

So nun zum Thema:
LXC muss bei Debianoiden-Linuxen abweichend zu Proxmox konfiguriert werden. Ich nutze derzeit Ubuntu 16.04 auf einem realativ potenten Server.

Wichtig für LXC (als auch Xen+KVM) sind eigene Netzwerke für die virtuellen Umgebungen. Das ist für den Laien (also auch ich in dem Bereich) immer etwas tricky.
Wenn man einen Fehler macht muss man in den Keller laufen. (Die Remote-Steuerung meines Mainboards habe ich nie in Betrieb genommen)

Ich habe hier mal ein Beispiel mit 2-3 Kommentaren: /etc/network/interfaces

Zitat# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# Das war das originale Netzwerkdevice:
## The primary network interface
#auto enp0s31f6
#iface enp0s31f6 inet dhcp

auto lo
iface lo inet loopback

auto br0
iface br0 inet static
address 192.168.1.2
broadcast 192.168.1.255
gateway 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
dns-nameservers 192.168.1.1
dns-search 192.168.1.1
bridge_ports enp0s31f6 #hier das Standard LAN Device eintragen; früher meist eth0
bridge_fd 9
bridge_stp off
bridge_maxwait 0

Wenn man nun doch USB Geräte durchreichen will geht das so:

Zitatroot@SRV:/var/lib/lxc/fhem# cat config
# Template used to create this container: /usr/share/lxc/templates/lxc-ubuntu
# Parameters passed to the template:
# Template script checksum (SHA-1): 704a37e3ce689db94dd1c1a02eae680a00cb5a82
# For additional config options, please look at lxc.container.conf(5)

# Uncomment the following line to support nesting containers:
#lxc.include = /usr/share/lxc/config/nesting.conf
# (Be aware this has security implications)

# Common configuration
lxc.include = /usr/share/lxc/config/ubuntu.common.conf

# Container specific configuration
lxc.rootfs = /var/lib/lxc/fhem/rootfs
lxc.rootfs.backend = dir
lxc.utsname = fhem
lxc.arch = amd64

# Network configuration
lxc.network.type = veth
lxc.network.link = br0
lxc.network.flags = up
lxc.network.hwaddr = 00:16:3e:ad:77:b3

lxc.mount.entry = /dev/serial/by-id dev/serial/by-id none bind,optional,create=dir
lxc.mount.entry = /dev/ttyUSB3 dev/ttyUSB3 none bind,optional,create=file
lxc.mount.entry = /dev/ttyUSB2 dev/ttyUSB2 none bind,optional,create=file
lxc.mount.entry = /dev/ttyUSB1 dev/ttyUSB1 none bind,optional,create=file
lxc.mount.entry = /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file
#lxc.mount.entry = /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_1e0b1005-if00-port0 dev/serial/by-id/usb-FTDI_FT232R_USB_UART_1e0b1005-if00-port0 none bind,optional,create=file 0 0

lxc.cgroup.devices.allow = c 13:* rwm
lxc.cgroup.devices.allow = c 188:* rwm

lxc.start.auto = 1
lxc.start.delay = 2

Auskommetiert ist der Versuch ein bestimmtes Device bereitzustellen. Das macht aber bei mir keinen Sinn. Stattdessen kann man überlegen einfach alle Devices durchzureichen und erst später zu entscheiden welches genutzt werden soll.

Hotplug geht mit dieser Methode nicht. Also nach dem Einstecken eines neuen USB-Geräts ist der Container neu zu starten.
Hotplug bei LXC ist prinzipiell möglich aber aufwändiger umzusetzen als meine Methode.

Das Starten des LXC dauert weniger as eine Sekunde. Ein FHEM Backup auf SSD auch weniger als eine Sekunde bei mir.

Fazit: Wenig Overhead durch den Container. Etwas weniger Sicherheit als der Versuch per KVM oder Xen oder VM-Ware zu trennen. Aber auch diese sind nicht wirklich 100% sicher abgeschottet, und darum geht es mir auch nicht. Ich brauche keinen Kleinrechner weil der große eh läuft. Und das Ergebnis ist extrem schnell. Ausfälle hatte ich in einem Jahr bisher keine.

Hoffe ich konnte 1-2 Leute etwas inspirieren. Möglichweise sogar weg von dem murksigen Design des beliebtesten Single-Board-Computers mit der großartigen Community und der guten Doku zu einer robusteren Lösung.

PS: Backup könnte sein einfach den Ordner mit dem Root-Filesystem+Configdate zu kopieren wärend der LXC heruntergefahren ist.

Beta-User · 30 Oktober 2017, 15:27:19

Hallo @Ranseyer,

das ist natürlich auch ein interessanter Ansatz, um von der Minmimal-Lösung PI mit den bekannten Einschränkungen wegzukommen...

Jetzt verstehe ich auch, warum das Kabel undbedingt eine gewisse Intelligenz haben muß

.

Grundsätzliche Frage: bekommt man sowas auch als "interessierter Laie" hin?

Ansonsten noch:
- Wenn ich es richtig verstanden habe, reicht für ein vollständiges Backup der virtualisierten Umgebung im Prinzip eine Kopie des Containers, oder? Ein Umzug wäre dann: Kopie des Containers auf andere Maschine, die natürlich dafür vorbereitet sein muß (aufwändig?), Startbefehl in die Startroutine der HW, fertig...

- Interessehalber (ich werde jetzt so schnell - hoffentlich - nicht wieder die Hardware wechseln

): Was wäre eine geeignete HW-Basis, um so eine Lösung aufzubauen?
Würde dafür schon ein NUC reichen, oder braucht man mehr? (Ist schon klar, dass es auch darauf ankommt, was sonst noch so an Servern usw. darauf laufen soll, es geht also eigentlich eher darum, wieviel Overhead die Virtualisierung bedeutet, bzw. ob man gänzlich andere HW braucht als in den meisten Privathaushalten üblich).

Schöne Feiertage,

Beta-User

Ranseyer · 31 Oktober 2017, 08:51:29

Ja klar bekommst Du das hin ! (Eine TV Box mit Linux umzurüstenist ganz sicher schwieriger)

Nachdem alles nötige installiert ist legst du so einen fhem-test Container basierend auf ubuntu trusty:

Zitatsudo lxc-create -t ubuntu -n fhem-test -- -r xenial -a amd64

Das wars...

(Debian anschliessend in der Handhabung minimal komplizierter weil kein Netzwerk aktiviert ist und meist kein passwort für den Login eingerichtet ist. Auch das ist lösbar:
"lxc-attach -n <container> passwd" )

Hier mal ein How2: http://www.itzgeek.com/how-tos/linux/ubuntu-how-tos/setup-linux-container-with-lxc-on-ubuntu-16-04-14-04.html

Zitatsudo apt-get install lxc lxc-templates wget bridge-utils
sudo lxc-checkconfig

Und ggf. noch etwas Anpassung der der Netzwerkconfig für LXC siehe dem Artikel.

Also ganz easy.

Umzug eines Containers ist wie du herausgelesen hast ganz einfach.

Ich habe im Moment nur zwei LXCs dauerhaft laufen: VDR für TV-Aufnahmen / Live-TV bereitstellen im Netz. FHEM. Auf dem Server selbst laufen noch nativ: Fileserver, Webserver, Diverse Proxy-Dienste,DB.
Grund für die Trennung war dass mit zu vielen speziellen Diensten die Sache immer komplizierter wird und vor allem dann auch irgendwann mal verbastelt oder unwartbar wegen den Abhängigkeiten.

HW- Basis:
-Eine LXC an sich braucht wenn inaktiv keine Ressourcen außer Plattenplatz.
-Wenn der Container aktiv ist nur so viel RAM+CPU wie die Programme selbst brauchen.

Ich hätte mal gesagt dass ein normales FHEM locker auf einer Kiste mit 1-2GB laufen sollte. Kommt ja drauf an was man genau nutzt.
Aber auf deiner neuen Kiste mit 8GB sehe ich überhaupt kein Problem mit dem RAM. Du brauchst halt Plattenplatz für den Container.

Es ist ja KEINE Virtualisierung. Wenn ich also in der VM mal die Speicherauslastung und den Plattenplatz anschauen sehe ich den Host:

Zitatroot@fhem:~# free
gesamt benutzt frei gemns. Puffer/Cache verfügbar
Speicher: 15972208 470716 14703232 47064 798260 14703232
Auslagerungsspeicher: 16310268 98068 16212200

root@fhem:~# df
Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/mapper/SRV--vg-root 79934304 20310172 55540628 27% /
none 492 0 492 0% /dev
udev 7963956 0 7963956 0% /dev/ttyUSB3
tmpfs 7986104 0 7986104 0% /dev/shm
tmpfs 7986104 8308 7977796 1% /run
tmpfs 5120 0 5120 0% /run/lock
tmpfs 7986104 0 7986104 0% /sys/fs/cgroup

Mein FHEM Container mit Ubuntu-Trusty belegt 2,3GB auf der Platte. Ein Debian evtl. leicht weniger würde ich annehmen.

Somit würde ich zusammenfassen: Kein Overhead, außer der Plattenplatz und eventuelle Programme die doppelt laufen. (Wie z.B. apt muss natürlich beide Systeme aktualisieren: Den Host + Container). Wenn Du z.B. einen MAPLE-CUL hast

, kannst Du den direkt ohne tricksen an einen Test-LXC anbinden und daraus Sachen steuern. ODer ein RS485 Gateway wenns nicht am MAPLE-CUL hängt eben per USB hineinreichen. Beispielsweise wie oben beschrieben.

Ist also easy. Van der Abtrennung ist es noch unsicherer als XEN,KVM, VM-Ware. Der Level ist eher wie bei Virtuozzo. Docker könnte ähnlich sein. Allerdings gibt es das ganz andere Möglichkeiten und das Konzept ist mit allem anderen hier genannten nicht vergleichbar und kosten viel mehr Zeit und Nerven.

Beta-User · 31 Oktober 2017, 17:45:11

Danke für die ausführliche Rückmeldung, klingt wirklich so, als wäre das eine gute Sache, wenn man mehrere Serverdienste mit speziellen Konfigurationen nebeneinander betreibt.

Da auf meinem hp nix anderes (mehr) laufen soll, werde ich den schlicht als fhem-Server so beibehalten "as is" (er hat übrigens "nur" 2GB RAM+einen freien Slot für einen weiteren Riegel, die 8GB sind ROM, genauer gesagt ist es ein DOM). Und das Ding "from scratch" aus einer tar.gz-Sicherung des FHEM-Verzeichnisses wieder ans Laufen zu bekommen, dauert ca. eine Stunde... Allerdings werde ich wohl nochmal umbauen, um wirklich eine SSD zu verwenden: Das 8-GB-DOM scheint einen Hau zu haben, habe stattdessen eben die 2GB wieder eingebaut.

Aber am Rande: So eine TV-Box umzubohren ist auch kein großes Ding, wenn man die richtige Anleitung dazu hat. Das größere Problem dürfen Kernel-updates im laufenden Betrieb sein (neu geflasht ist auch wieder schnell, aber dann ist eben auch wieder alles weg). Ist halt bei den Teilen so, dass immer nur ein Kernel im uboot-sein kann. Funktioniert der nicht, ist Sense. Und für die Box waren die Jungs sehr am Kernel-Enwickeln, das war mir dann zu experimentell. Da ist ein klassisches Debian@i386 viel stressfreier. Wobei man ja andererseits auch nicht alle Tage einen neuen Kernel braucht...

Hans-Ulrich Tag · 21 März 2018, 12:38:11

Hallo Ranseyer,

ich habe das jetzt auch versucht, aber der ZWave-Stick wird in FHEM als "disconnected" angezeigt.
Ich habe über die Commandline im Host die folgenden Befehle ausgeführt:

Code Auswählen

lxc config device add fhem-neu zstick disk source=/dev/serial/by-id path=dev/serial/by-id
lxc config device add fhem-neu ttyACM0 disk source=/dev/ttyACM0 path=dev/ttyACM0

Die Verzeichnisse "serial" und dessen Unterverzeichnis "by-id" im Ordner /dev habe ich händisch angelegt und die entsprechenden Rechte vergeben.

Was könnte die Ursache sein, dass der Stick auf dem FHEM im LXC-Container nicht erkannt wird?

Ranseyer · 21 März 2018, 12:49:30

Zeigst du mal deine Config ? (Du hast das im Prinzip sauberer gemacht als ich, wobei ich jetzt nicht im Kopf hab ob "disk" in Deinen Kommandos auftauchen soll)
Kannst Du mal sinngemäß das Configfile des Containers zeigen ?

Zitatroot@SRV:/var/lib/lxc/fhem# cat config

Bei mir ist das recht brachial:

Zitatlxc.mount.entry = /dev/serial/by-id dev/serial/by-id none bind,optional,create=dir
lxc.mount.entry = /dev/ttyUSB3 dev/ttyUSB3 none bind,optional,create=file
lxc.mount.entry = /dev/ttyUSB2 dev/ttyUSB2 none bind,optional,create=file
lxc.mount.entry = /dev/ttyUSB1 dev/ttyUSB1 none bind,optional,create=file
lxc.mount.entry = /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file
#lxc.mount.entry = /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_1e0b1005-if00-port0 dev/serial/by-id/usb-FTDI_FT232R_USB_UART_1e0b1005-if00-port0 none bind,optional,create=file 0 0

lxc.cgroup.devices.allow = c 13:* rwm
lxc.cgroup.devices.allow = c 188:* rwm

Ich reiche A) die ersten vier USB Devices stumpf durch, sowie "B) by-id"
C) erst über Berechtigung der Control-Groups (cgroup) wird dann der Zugriff erlaubt !

...und damit ist kein Hotplug möglich, das USB Gerät muss vor dem Start des Containers erkannt worden sein !

Hans-Ulrich Tag · 21 März 2018, 19:58:51

Zitat von: Ranseyer am 21 März 2018, 12:49:30
Zeigst du mal deine Config ? (Du hast das im Prinzip sauberer gemacht als ich, wobei ich jetzt nicht im Kopf hab ob "disk" in Deinen Kommandos auftauchen soll)
Kannst Du mal sinngemäß das Configfile des Containers zeigen ?
Bei mir ist das recht brachial:
Ich reiche A) die ersten vier USB Devices stumpf durch, sowie "B) by-id"
C) erst über Berechtigung der Control-Groups (cgroup) wird dann der Zugriff erlaubt !

...und damit ist kein Hotplug möglich, das USB Gerät muss vor dem Start des Containers erkannt worden sein !

Dann könnte das Fehlen von "C)" bei mir die Ursache sein. Wie kommst Du auf

Code Auswählen

lxc.cgroup.devices.allow = c 13:* rwm
lxc.cgroup.devices.allow = c 188:* rwm

Also speziell die Zahlen 13 und 188?

Ranseyer · 21 März 2018, 20:12:40

Im Moment sieht das bei mir so aus:

Code Auswählen

root@SRV:/dev/serial/by-id# ls -lisa
insgesamt 0
18577 0 drwxr-xr-x 2 root root 80 Mär 18 19:48 .
18576 0 drwxr-xr-x 4 root root 80 Mär 18 19:48 ..
18588 0 lrwxrwxrwx 1 root root 13 Mär 18 19:48 usb-FTDI_FT232R_USB_UART_A9AD53B3-if00-port0 -> ../../ttyUSB0
18578 0 lrwxrwxrwx 1 root root 13 Mär 18 19:48 usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 -> ../../ttyUSB1

Code Auswählen

root@SRV:/dev# ls -la *ttyUS*
crw-rw---- 1 root dialout 188, 0 Mär 18 19:48 ttyUSB0
crw-rw-rw- 1 root dialout 188, 1 Mär 21 20:10 ttyUSB1

Die Berechtigungen die ich hier einräume sind recht breit und man könnte das sicher genauer machen (falls man Lust hat).

Quelle z.B. gerade gegoogelt: https://deviantengineer.com/2016/11/lxc-passthrough/

Spezialtrick · 03 Juni 2018, 12:36:20

Zitat von: Ranseyer am 21 März 2018, 12:49:30
Zeigst du mal deine Config ? (Du hast das im Prinzip sauberer gemacht als ich, wobei ich jetzt nicht im Kopf hab ob "disk" in Deinen Kommandos auftauchen soll)
Kannst Du mal sinngemäß das Configfile des Containers zeigen ?
Bei mir ist das recht brachial:
Ich reiche A) die ersten vier USB Devices stumpf durch, sowie "B) by-id"
C) erst über Berechtigung der Control-Groups (cgroup) wird dann der Zugriff erlaubt !

...und damit ist kein Hotplug möglich, das USB Gerät muss vor dem Start des Containers erkannt worden sein !

Ist es Dir auch gelungen ein USB Bluetooth Dongle an einen Container durchzureichen?

Ranseyer · 03 Juni 2018, 13:22:27

Nee ist mir nicht gelungen.

(Ich hab auch nicht versucht Bluetooth im Keller anzustöpseln

)

Du musst halt herausfinden was in der VM sichtbar gemacht werden muss.
Das muss ja wohl:

A) gemountet werden
B) Zugriffsrechte passen
-also die "cgroups" passend berechtigen
-oder evtl etwas schlampiger: den Container privillegiert laufen lassen. (das würde ich nicht machen falls du die Container wegen sicherer Trennung nutzst)

Wenns mit etwas forschen nicht geht würde ich notfalls in ein paar Tagen mal im Keller so nen Stick einstöpseln.

Spezialtrick · 03 Juni 2018, 16:43:16

Ich habe es bisher so in der Config des Containers versucht:

Code Auswählen

lxc.cgroup.devices.allow = c 189:* rwm
lxc.mount.entry =     /dev/bus/usb/001        dev/bus/usb/001          none bind,optional,create=dir
lxc.mount.entry:      /dev/bus/usb/001/002   dev/bus/usb/001/002   none bind,optional,create=file

Leider funktioniert das nicht. Einen MiniCul konnte ich wie folgt problemlos einbinden:

Code Auswählen

lxc.cgroup.devices.allow: c 188:* rwm
lxc.mount.entry:     /dev/serial/by-id               dev/serial/by-id         none bind,optional,create=dir
lxc.mount.entry:     /dev/ttyUSB0                    dev/ttyUSB0             none bind,optional,create=file

Meine Container laufen alle privilegiert.

Ranseyer · 03 Juni 2018, 19:51:57

Dann mach doch mal in /dev ein "ls -la >vorher.txt" und noch eins nach dem anstecken mit nachher.txt...
Nach einem "diff vor* nach*" kennst du die nötigen Sachen aus /dev...

PS: Wäre auch denkbar dass die Userspace Programme noch in /proc oder/sys stöbern, aber da macht der diff weniger Spaß

Thyraz · 04 Juni 2018, 08:50:48

Danke für diesen Thread, hab übers WE auch Proxmox auf meinem NUC aufgesetzt und bin begeistert wie schnell und einfach das ging als Laie in dem Bereich.

FHEM und MariaDB laufen jetzt schonmal in eigenen Containern und die USB Geräte habe ich mit den Infos hier auch durchgereicht bekommen.

le66ck · 09 Juni 2018, 12:21:53

Hallo

Ich habe es gestern mit einem Debian 9 lxc Image versucht und es hat nahezu auf Anhieb funktioniert!!!
In meine Config vom Container habe ich dieses eingefügt

Code Auswählen

lxc.cgroup.devices.allow = c 13:* rwm
lxc.cgroup.devices.allow = c 188:* rwm
lxc.mount.entry: /dev/ttyUSB0                    dev/ttyUSB0             none bind,optional,create=file

Danach natürlich rebooten!

Auf dem Host habe ich ein CSM Funkmodul von Buseware mit einem USB nach seriell Konverter.
Dort wird das CSM Funkmodul nach /dev/ttyUSB0 eingebunden. Was ich dann auch so gelassen habe.

In Debian 9 musste ich dann noch die Rechte anpassen

Code Auswählen

usermod -a -G tty fhem

Und ein

Code Auswählen

define CUL_0 CUL /dev/ttyUSB0@38400 XXXX

in Fhem und freuen!

Dann noch

Code Auswählen

dpkg-reconfigure locales
dpkg-reconfigure tzdata

und in

Code Auswählen

/etc/ssh/sshd_config

ein

Code Auswählen


PermitRootLogin yes

eingefügt, dass es mit Putty klappt.

Desweiteren läuft auf meinem "Proxmox-Server" noch ein MiniDVBLinux 5.4 testing, mit einer durch gereichten Dual DVBS2-PCIe-Karte zum Streamen.
Ein Fire TV Stick von Amazon mit Kodi ist dafür der Empfänger.
Ein Image von http://dietpi.com/ ist auch nicht zu verachten.

Ein Virtualisieren mit Proxmox hat was!!!

Für was sind überhaupt die Zahlen von z. B. c 13:* rwm c 188:* rwm

Christian

mark79 · 13 August 2018, 23:40:26

Falls mal jemand das selbe Problem hat und sich im Container nicht mehr per SSH einloggen kann:

Code Auswählen

PTY allocation request failed on channel 0
Ich hatte nur das Wirtssystem neuinstalliert und danach war in allen Containern kein SSH Login mehr Möglich.

Dann das hier in die Container config packen:

Code Auswählen

# required for lxc-console to work
lxc.tty = 4

# requires for interactive SSH to work
lxc.pts = 1024

https://newspaint.wordpress.com/2017/08/15/lxc-container-reports-pty-allocation-request-failed-on-channel-0-on-ssh-connection/

Da habe ich mir die letzten Tagen, die Finger nach Wund gesucht...