Update ubuntu-mantic / das geht nicht mehr :-(

[Ramalama]

Macht wie ihrs denkt, mir ist das egal.
Ich hab alles dazu bereits geschrieben.

 

[Johannes S]

Macht wie ihrs denkt, mir ist das egal.
Ich hab alles dazu bereits geschrieben.

Das war nicht böse gemeint, mich interessiert schlicht der technischer Hintergrund hinter deiner Aussage:

Der grund ist halt, das sich in nem LXC Container oft mehr ändert als nur die Packete, Packete werden auch grundsätzlich nie entfernt, nur upgedated/hinzugefügt.
(Entfernt auch aber nur wegen abhängigkeiten wenn ein Packet ein anderes ersetzt, nicht wenns nichtmehr gebraucht wird)

Also: Was sorgt bei den Containern dafür, dass das so ist? Ich dachte bislang immer, dass das nicht der Fall ist.

 

[Ramalama]

Das war nicht böse gemeint, mich interessiert schlicht der technischer Hintergrund hinter deiner Aussage:



Also: Was sorgt bei den Containern dafür, dass das so ist? Ich dachte bislang immer, dass das nicht der Fall ist.

LXC-Container sind Managed. Ein Upgrade der Distribution könnte Änderungen an systemd, init oder anderen Kernkomponenten führen, die mit der Art wie der Container verwaltet wird, in Konflikt stehen.

Hier ein teil aus ChatGPT was Managed Container bedeutet (Mann kann die auch natürlich auf Unmanaged stellen), aber hier die Beschreibung:

Ein „verwalteter Container“ bezeichnet eine Umgebung, in der die Konfiguration, Ressourcen und Interaktionen des Containers mit dem Host-System streng kontrolliert und durch eine Container-Laufzeitumgebung (wie LXC) verwaltet werden. Dies steht im Gegensatz zu nicht verwalteten Umgebungen, in denen man zwar mehr direkte Kontrolle hat, aber weniger Integration oder Überwachung.

Im Kontext von LXC-Containern bedeutet „verwaltet“ typischerweise:
    1.    Abhängigkeit vom Host:
    •    Der Container ist auf das Host-System für Kernel-Dienste und Ressourcenverwaltung (z. B. CPU, Speicher, Netzwerk) angewiesen.
    2.    Konfiguration über Tools:
    •    LXC stellt Tools bereit (lxc-create, lxc-start, lxc-stop usw.) sowie vordefinierte Profile, um Container zu verwalten und zu isolieren. Diese Profile legen fest, worauf der Container zugreifen kann und wie er sich verhält.
    3.    Isolierung mit Einschränkungen:
    •    Der Zugriff des Containers auf Ressourcen (z. B. Geräte, Systemaufrufe oder Netzwerk) wird verwaltet, um Isolierung, Stabilität und Sicherheit zu gewährleisten, entsprechend den Richtlinien des Hosts.
    4.    Vereinfachtes Ressourcenmanagement:
    •    Das Host-System übernimmt die Ressourcenzuweisung und -begrenzung (z. B. über cgroups für CPU und Speicher). Der Ressourcenverbrauch des Containers wird durch diese Limits gesteuert.
    5.    Automatische Updates/Anpassungen:
    •    Verwaltete Umgebungen können Updates für LXC selbst oder für Profile beinhalten, die möglicherweise mit der Konfiguration des Containers in Konflikt geraten oder diese ändern.

Zusammengefasst priorisiert ein „verwalteter Container“ eine strukturierte und vorhersehbare Arbeitsweise, schränkt jedoch bestimmte Konfigurationen ein, wodurch In-Place-Upgrades anfälliger für Konflikte sind als in stärker isolierten Umgebungen wie virtuellen Maschinen.

Im großen und ganzen wenn mann mehr wissen will, müsste ich auch erstmal googeln. Ich hatte aber halt schon Probleme mit Distro Upgrades in Containern.
Habs halt früher auch immer geupgraded, weils halt deutlich einfacher ist und mann meistens nach nem Jahr eh kein Bock hat sich mit der Materie (was mann migrieren muss) befassen will.
Aber seitdem bastel ich immer Scripte (Automatismen) oder Docker in LXC Containern, um das zukünftige migrieren halt maximal zu vereinfachen.
Ist nix besonderes, einfach simple Shell skripte im Container selbst....

Auch wichtig ist mir immer ein "Startscript" wenn ich mich einlogge um mich überhaupt zu erinnern was da drauf Läuft, ist halt ein super simples Script was halt anzeigt was Läuft:
Beispiel:


Hier das Script wer will:
Ist eins meiner selbstgeschriebenen, hat keine Abhängigkeiten, das hier heist einfach startscript.sh und ich habs einfach am ende der .bashrc vom root user hinzugefügt.

#!/bin/bash

# Color variables
RED='\033[0;31m'
GREEN='\033[0;32m'
NORMAL='\033[0m'
YELLOW='\033[1;33m'

# custom: Eigene Servicenames zum Anzeigen, min 1
custom_services=("asklepios" "asklepios_mail" "docker")
# docker: Ist Optional, kann leer gelassen werden, aber wenn dann einfach die Container Namen
docker_images=("mariadb" "nginx" "php-8")

format_service_ports() {
    ss -Htulpn4 | grep "$1" | awk '{print $5}' | sed -E 's/users:\(\(\"([^"]+).*/\1/' | sed 's/%lo//' | sed -E 's/127\.0\.0\.[0-9]+/local/' | sed 's/0\.0\.0\.0/public/' | uniq | tr '\n' ' '
    echo -e '\n'
}

check_services() {
    status=$(systemctl is-active "$1")
    if [ "$status" != "active" ]; then
        echo -e "${RED}$1: Not Running!${NORMAL}"
    else
        service_ports=$(format_service_ports "$1")
        if [ -z "$service_ports" ]; then
           echo -e "${GREEN}$1${NORMAL}: Running!"
        else
           echo -e "${GREEN}$1${NORMAL}: $(format_service_ports "$1")"
        fi
    fi
}
echo -e "\n --- ${YELLOW}Willkommen auf $(hostname -f)${NORMAL} ---"
echo "Network: $(hostname -I | awk '{print $1}') / $(hostname -f)"
echo "System: $(free -h | awk '/^Mem:/ {print $3 "/" $2 " Mem-Usage"}') | $(df -h / | awk '/\// {print $3 "/" $2 " Disk-Usage"}')"
echo -e "\n --- ${YELLOW}Dienste:${NORMAL}"
for service in "${custom_services[@]}"; do
    check_services "$service"
done

failed_services=$(systemctl --failed --plain --no-legend --no-pager)
if [ -z "$failed_services" ]; then
    echo -e "${GREEN}Other Services${NORMAL}: Alles funktioniert!"
else
    echo -e "${RED}Other Services${NORMAL}: $failed_services"
fi

if [[ " ${custom_services[*]} " =~ " docker " ]]; then
    echo -e "\n --- ${YELLOW}Docker Apps:${NORMAL}"
    running_containers=$(docker ps --format "{{.Names}}")

    for image in "${docker_images[@]}"; do
        if [[ ! "$running_containers" =~ "$image" ]]; then
            echo -e "${RED}$image: not running!${NORMAL}"
        else
            status=$(docker ps --filter "name=$image" --format "{{.Names}}: {{.Status}}")
            echo -e "${GREEN}$status${NORMAL}"
        fi
    done
    readarray -t running_containers_array <<<"$running_containers"
    for container in "${running_containers_array[@]}"; do
        if [[ ! "${docker_images[*]}" =~ "$container" ]]; then
            status=$(docker ps --filter "name=$container" --format "{{.Names}}: {{.Status}}")
            echo -e "${GREEN}$status${NORMAL}"
        fi
    done
fi

Ansonsten hab ich eigentlich für alles eine Art Script-Plugin System gebastelt das alles praktisch purged/neuinstalliert/neukonfiguriert usw..., das wird aber hier den rahmen sprengen....

LG

 

[Johannes S]

Danke für die Antwort, auch wenn ich Antworten von ChatGPT und co eher skeptisch sehe, das Argument mit verwaltet klingt einleuchtend und erklärt auch, warum es Probleme beim Updaten geben kann.
Dein Skript finde ich einen coolen Ansatz, wobei ich das eher als Anlass sehe, mich endlich mal mit ansible zu beschäftigen, um damit was Ähnliches zu bauen

 

[CoolTux]

Das ist ja alles ganz schön und gut. Hat aber rein gar nichts mit dem Packet- oder Repository management zu tun.
Alles was nicht Hardwae oder IPC nahe ist stellt somit beim Update kein Problem dar.
Ich selbst habe DB oder Nextcloud LX Container welche bereits seit Debian 10 bei mir nur ein Upgrade erhalten haben.

Aber ich denke mal das wird hier eh in eine endlose Diskussion aus arten. Jeder hat so seine Erfahrungen gemacht.

 

[Ramalama]

Ja deswegen wollte ich auch eigentlich nicht Antworten und geschrieben dass ihr machen sollt was ihr wollt. Hab ja auch keine Lust auf endlose Diskussionen.

Am ende ists eh egal. Wenns funkt ist super (viel Arbeit gespart) und wenn nicht kann mann halts fixen.

Ist ja Linux und mann hat auch evtl backups oder kann einfach das zfs dataset oder zvol mounten im Notfall...

 

[t.lamprecht]

Das ist ja alles ganz schön und gut. Hat aber rein gar nichts mit dem Packet- oder Repository management zu tun.
Alles was nicht Hardwae oder IPC nahe ist stellt somit beim Update kein Problem dar.

Ich will in diesen Thread jetzt nicht noch mehr abdriften, aber eine Sache: grundsätzlich sind Container schon recht Eng mit dem Host verzahnt, also Kernel und systemd hauptsächlich, denn der Container ist ja, vereinfacht gesagt, hauptsächlich durch Namespaces Features vom Host-Kernel abgebildet, und systemd, das verwendet wird, um ein paar Aspekte zu kontrollieren.
Es gab schon Fälle wo ein zu neuer, oder zu alter, systemd innerhalb des Containers nicht mehr, oder noch nicht, mit der Art wie Namespaces aufgesetzt sind, welche es gab, usw. klargekommen ist. Das prominenteste Beispiel hier war etwa der Wechsel von der CGroup v1 Hierarchie zur CGroup v2 Hierarchie.

Ein Distro Update kann daher schon Probleme bereiten, ist aber mittlerweile sehr selten geworden da CGroup Version sich stabilisiert hat und Namespaces auch nicht mehr so viele dazu kommen, also der Time-Namespace für eigene Zeitzone im CT ist der "neueste", was hier Linux 5.6 releast in 2020 heißt.

Was hier als potenziell verwirrend dazukommen kann sind die privileged Container. Diese waren früher das Default in Proxmox VE. Der Grund dafür war, vereinfacht gesagt, weil Kernel/Systemd/LXC und Co halt einfach noch nicht so weit waren und viele Dinge einfach damit besser liefen.
Mittlerweile des Öfteren mehr Probleme machen. In Proxmox VE sind deswegen schon seit Längerem die unprivileged Container der neue Default, zumindest am Web UI, weil die eben mittlerweile besser Funktionieren und auf alle Fälle etwas mehr Sicherheit bieten.
D.h., ein neu-erstellen des Containers kann wirklich Probleme mit einem neuer(em) Release einer Distro beheben, wenn etwa (unbewusst) der Container durchs neu-erstellen von einem privileged CT auf unprivileged CT gewechselt hat.

Aber ja, am Ende muss jeder den passenden Workflow für die Eigenheiten seiner Workload finden. Beizeiten diesen mal wieder zu hinterfragen, kann aber manchmal auch nützlich sein, recht sicher gibt es aber meistens mehr als einen "richtigen" Weg.