LXC-Fragen

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!