Moin! Dass Du selbst gerne redest, wusste ich ja. Dass Du bei Schulung - MANCHMAL - ETWAS - ausschweifst auch... aber dass Du auch solche Fragenlisten stellst 😁 On 27.06.20 13:50, Martin Steigerwald wrote: > Danke Dir nochmal für den Vortrag, Sven! Gerne! > 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) Ich hatte noch einen OpenSSH-Server installiert, vermutlich deswegen. Soll es schmaler sein, dann nimm dropbear, gibt dann aber kein Ed25519. > [...] > 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. Entweder bind-mount. Oder als Hook im dehydrated nach einem neuen Cert per rsync kopieren. Oder Du nimmst auf einer Seite zum TESTEN die STAGING-API von Let's Encrypt. > [...] > 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. Im Host oder im Container? Muss ehrlich sagen, hab mich da auch schon länger nicht mehr drum gekümmert. Alpine ist soo klein 😎... > [Netz mit "none", "macvlan", Reverse Proxy] Lasso, wenn der Container als Netz "none" hat, hat er kompletten Zugriff auf das Host-Netzwerk, das stimmt schon - mit allen Vor- und Nachteilen. Allerdings MUSS er ja das Netz auch nicht dekonfigurieren beim Runterfahren. Aber ja, das hätte ich erwähnen sollen. Tjanu, Du wirst es nicht mehr vergessen 😁 "macvlan" ist im Prinzip der Modus, wie VMware Workstation, VirtualBox & Co. das ganze für ihre virtuellen Maschinen veranstalten. Ohne dass es im Host zu sehen ist, werden zusätzliche MAC-Adressen ins Netz geschoben bzw. angenommen. Vorteil: Keine Bridge im Host (und funktioniert mit VMware nach "außen"). Nachteil: Man "sieht" die Interfaces der Container nicht wirklich. > 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. Das war der dritte Weg, den ich vorgeschlagen hatte, ja. RevProxy im Containert (vs. im Host). Funktioniert auch, netzwerkt nur auf der internen Bridge rum. Oder man nimmt einen rinetd oder sowas... > Zu veth extern mit VMware ESX fand ich: > > https://www.claudiokuenzler.com/blog/556/network-connectivity-problem-lxc-in-vmware-vm-veth Jup. Und https://www.claudiokuenzler.com/blog/792/lxc-container-in-network-reachable-cannot-ping-between-host-and-container-veth-macvlan und ich dachte, es gibt sogar noch 'nen dritten Artikel dazu. > 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. Grundsätzlich funktioniert der Ansatz (zwei NICs, eine für den Host, die anderen für die "macvlan" der Container). Hab das bei Kunden (inzwischen) so laufen. Aber da war eben die Voraussetzung, dass die Container IPs aus dem LAN bekommen. Sonst würde ich auch auf die interne Bridge gehen. > 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. Kommt drauf an 😝 Meistens ist der Host per IPv6 erreichbar, der Rest via RevProxy und IPv4. Ansonsten statische IPv6-Vergabe, und dann einzelne IPs routen - das geht auch mit (offiziellen) IPv4. > 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. Ich hab 'nen syslogd drin (meistens rsyslogd) und konfiguriere mir dann per Ansible 💪 die Kernel-Messages da raus. > 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 Meistens läuft da ein Nullmailer, der die Mails einfach an einen (zentralen) MX, manchmal auf der selben Kiste, manchmal direkt wo anders hin, abliefert. Oder ein OpenSMTPd. > 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 :) Ansible 💪 😁 Ich hatte mal damit angefangen, dass ich mir eigene Images gebaut hab. Und dann ging's wieder mit Security-Updates & Co. los. Dann hab ich das sein lassen und mach nun echt so ziemlich alles per Ansible. Und für die Puristen unter Euch: Man KÖNNTE das auch mit einem Shell-Script machen. > 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. Ansible 💪 - Ja, ernsthaft. Bei mir sind's inzwischen einfach ZU viele (virtuelle) Maschinen und da alles von Hand zu machen wäre irrsinnig aufwändig. Wird spätestens alle 2 Tage aufgerufen und wenn dann mal wegen eines Updates was nicht (mehr) geht, weiß ich wenigstens, wann ich es kaputt gemacht habe (ja, KEINE unattended upgrades der Distri selbst). > 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. Uff, ich glaub, das ging irgendwie. Hab es aber auch wegen Einheitlichkeit jetzt immer da gelassen, eben zumindest als Link oder (Bind-)Mount. > TLS-Zertifikate: Nimmst Du dehydrated, Sven, oder mittlerweile was > Anderes? Wenn was anderes, warum? Dehydrated. Weil's rennt. Weil's unproblematisch ist. Weil es mit den Hooks steuerbar ist. Weil es FÜR MICH die sinnvollste Lösung ist. Weil ich in einem ACME-Tool keinen Web-Server brauche, WEIL DER JA EH AUF DER KISTE LÄUFT, WO ICH DAS CERT BRAUCHE. Ok, bis auf dem Mail-Server. Oh! Wait! Web-Mailer... also... doch überall 😉 Zum Spielen hab ich auch ein Setup mit haproxy und acme.sh - das tut auch. Finde es letztendlich aber komplizierter, als $HTTPD plus dehydrated. > 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? Ja (siehe letzten Abschnitt). Teils, teils - je nach Applikation. Und bevor die Frage kommt: RevProxy ist bei mir nach wie vor meistens ein Apache (mit mpm_event) - weil ich ständig seine weitergehenden Features verwende. Daneben hab ich (wegen Projekten) noch haproxy (mit acme.sh) und træfik (im Docker-Universum; macht ACME selbst) am laufen. Bye Sven -- Leukämie → http://de.wikipedia.org/wiki/Leuk%C3%A4mie Heilung → http://de.wikipedia.org/wiki/Knochenmark#Knochenmarkspende Typisierung → https://akb.de/online-registrierung/ https://zkrd.de/de/adressen/ Fragen? → sven@velt.de -- 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!