Hi Sven, hi ihr! Danke Dir nochmal für den Vortrag, Sven! Sodele, das funktioniert ja alles schon recht fein: luna:~> lxc-ls -fF name,state,ipv4,ram NAME STATE IPV4 RAM interntestalpine RUNNING 10.0.0.200 1.97MB interntestdevuan RUNNING 10.0.0.201 16.98MB rproxy RUNNING 10.0.0.1, […] 352.42MB (keine Ahnung, warum die leeren Test-Container noch weniger RAM brauchen als bei Dir, Sven) Mitsamt ferm-basiertem Paketfilter für Masquerading. Der Reverse Proxy mit nginx-light – mal sehen ob das reicht – ist noch nicht fertig. Dem muss ich ja TLS-Zertifikate verpassen und mir irgendwie überlegen, Let's Encrypt nicht zu verwirren, wenn ich übergangsweise von zwei Hosts aus die gleichen Zertifikate anfordere… hmmm, ich könnte die temporär in den Container mit Bind-Mount einhängen. Naja, so oder so… erst mal ein bisschen überlegen, wie ich das alles angehe. Ich möchte Schritt für Schritt außer vielleicht SSH alle Dienste in Container verfrachten. Mir ist da ein weiterer Vorteil eingefallen, neben Sicherheitsaspekten, den das hat: Ich kann einige oder alle Container bei Bedarf ziemlich einfach auf eine andere Maschine verschieben. Was bei einem Wechsel des Hosters natürlich sehr praktisch ist. Okay, nur ein paar kleine Fragen, LOL – gerne auch im Rahmen eines Folge-Vortrags, das eilt ja alles nicht, mein bestehendes Setup funktioniert ja soweit: Was von den: Was von den empfohlenen Paketen arch-test bridge-utils busybox-static cgroupfs-mount cloud-image-utils debootstrap distro-info dnsmasq-base genisoimage libidn11 liblxc1 libpam-cgfs lxc lxc-templates lxcfs qemu-utils uidmap uuid-runtime ist tatsächlich erforderlich? Ich hab mal cloud-image-utils genisoimage qemu-utils uuid-runtime rausgeschmissen und vermisse bislang nichts. Reverse Proxy-Netzwerk-Konfiguration: Abwägung Netzwerk-Typ "none" versus externer Bridge oder MacVLAN im externen Bridge-Modus von der Sicherheit her. D.h. betrifft hauptsächlich die Sichtbarkeit von IP-Adressen und offenen Ports des Hosts. Ist das darüber hinaus unsicherer mit "none"? So oder so halte ich die Wahrscheinlichkeit, das jemand in einen gut konfigurierten Nginx-Reverseproxy einbricht für sehr unwahrscheinlich. "none" hat natürlich den Vorteil, dass es einfach ist. Ich dachte erst, dass ich mit "phys" nur eine bestimmte Host-Schnittstelle im Container sichtbar machen konnte. Allerdings steht in der Manpage was von "assign"… daher vermute ich, dass der Container die dann exklusiv bekommt, was ich in dem Fall nicht möchte. Ich erwäge MacVLAN zu erwähnen, da ich da in der /etc/network/interfaces, soweit ich das verstehe, keine externe Bridge drunter schieben muss. Das würde ich gerne vermeiden, da Out of Band-Zugriff für die VM eher schwierig ist. (Hab auch ferm zunächst mit --interactive laufen lassen :) Ich denke, ich hab die Frage gerade beantwortet: Nach lxc-stop auf den rproxy-Container ist die VM komplett offline. Alle IP-Adressen der VM. Alles weg. Das geht so nicht… Der Container darf den Host nicht offline nehmen. Niemals nie. Da war noch eth0 in der /etc/network/interfaces mit DHCP drin, das hatte ich aber vorher raus gemacht. Aber ifupdown hat ja auch einen State im RAM… also da muss dann ifupdown komplett raus aus einem solchen Container… aber das ist denke ich dass K.O.-Kriterium, dann muss auch iproute raus und dann kann jemand der einbricht den kompletten Host offline nehmen, in dem er iproute2 wieder installiert. Also solange das nicht in einer Art Modus geht, wo der Container *nichts* am Host-Netzwerk verändern kann, kommt der Netzwerk-Typ nicht in Frage. Okay, dann wird es wohl Mac VLAN mit IPv4/IPv6. Und das hab ich jetzt nicht hinbekommen, auch da ich nach 2-3 Stunden rumbasteln gerade nicht mehr genau verstehe, was ich da wo angeben soll. Das wird wohl besser sein, das mal live mit rein zu bringen. Oder…… hmmm, ich könnte mit Paketfilter mit HTTP/HTTPS einfach SNAT/DNAT auf einen internen Container machen. Das wäre möglicherweise am einfachsten, weil das ganze Geschwurbel mit $LINUX-NETZWERK- SUPERSPEZIAL-FEATURE weg fällt. Je weniger ich am Netzwerk des Hosts rumbasteln muss, desto lieber ist mir das. So hab ich mir auch schon das SPICE-Protokoll von einem Proxmox VE hinter einem Gateway-Host weitergegeben. Zu veth extern mit VMware ESX fand ich: https://www.claudiokuenzler.com/blog/556/network-connectivity-problem-lxc-in-vmware-vm-veth Und nach dem Lesen des Blogs habe ich entschlossen, da definitiv die Finger von zu lassen. PS: Da habe ich auch die Vorlage für meine nicht funktioniert MacVLAN-Konfiguration her. IPv6: Damit vielleicht etwas verbunden. Wie machst Du es mit IPv6? Wenn der Reverse Proxy Zugriff auf die IPv6-Adressen hat, dann dürfte es doch reichen, die internen Container mit IPv4 laufen zu lassen? Ich will natürlich, dass die Webseiten weiterhin ebenfalls über IPv6 erreichbar sind. Meine Idee ist, den Nginx auf einen anderem Port zunächst parallel hochzuziehen und auf die Seiten des bestehenden Apache-Webserver auf dem Host verweisen zu lassen. Dann kann ich das Zeug Schritt für Schritt in eigene Container umziehen. Syslog: Auf der Devuan-Vorlage ist kein rsyslog. Macht das Sinn keinen Syslog-Server im Container zu haben? Mit /proc/kmsg hat rsyslog im Container ja nix zu suchen. Hmmm, käme darauf an, inwiefern ich einen Dienst nutze, der auf Syslog zurückgreift. Aber OpenSSH, das dies standardmäßig tut, soll in die (meisten) Container ja eh nicht rein. Mail-Setup: Wie machst Du es, dass die Container Mail versenden können? Ich würde Postfix mit TLS und SMTP AUTH einrichten, aber geht das auch einfacher? Braucht es das? Ich lasse mir von meinen Servern via apticron, debsecan usw. Mails schicken. Ich denke, das würde ich auch gerne mit produktiven Containern so haben Eigene Vorlage bauen? Wie mache ich das… kann ich einfach einen Container als Vorlage erstellen und davon klonen? Hmmm, selbst beantwortet: wohl ja, lxc-clone. Das unterstützt vielleicht sogar BTRFS- Snapshots. Natürlich hab ich BTRFS auf der Server-VM :). Idealerweise möchte ich mit LXC eine Vorlage habe, wo ich direkt loslegen kann. Also alle Basis-Sachen wie Mail usw. fertig eingerichtet sind. Oder irgendwann mal Ansible :) Updates: Wie hältst Du die Container aktuell? Ich hab derzeit kein Monitoring für meine zwei virtuellen Maschinen. Da meine komplette Mail über die Maschine geht, wo jetzt auch LXC läuft, merke ich das schnell, wenn da mal was ist – bislang war da so gut wie nie was. Der andere ist eine reine Backup-VM, wo nur SSH und Borgbackup drauf laufen. Ort für Container: Ich hab die Container via Symlink auf /srv/containers verlegt, unter anderem da /var auf der virtuellen Disk für das Host- Betriebssystem liegt. Kann ich das Haupt-Verzeichnis auf das LXC zugreift, standardmäßig /var/lib/lxc auch irgendwo in der Konfiguration anpassen? In den Konfigurationsdateien einzelner Container habe ich das gefunden. Ich kann natürlich auch alles über den Symlink gehen lassen. Achja, hier noch ein Link, wer mal so einen Container umbenennen möchte. Geht einfach genug: https://www.bonusbits.com/wiki/HowTo:Rename_LXC_Container Und noch was Anderes: TLS-Zertifikate: Nimmst Du dehydrated, Sven, oder mittlerweile was Anderes? Wenn was anderes, warum? Die TLS-Zertifikate müssdten dann ja auf den Reverse Proxy. Verwendest Du von Reverse Proxy zu Backend-Webserver HTTPS oder belässt Du es bei HTTP? Ciao, -- Martin -- Mailing-Liste der Linux User Schwabach (LUSC) e.V. Vor und beim Posten bitte http://lusc.de/List-Netiquette < und http://lusc.de/List-Howto < beachten. Danke!