Wie allesAktuell halten?? Welche Update´s etc??

[matt69]

root@debian85:# ls -l /usr/local/bin/topgrade

zeigt die Eigenschaften von der Datei topgrade in /usr/local/bin

Ja, war ein Schreibfehler. siehe einen Beitrag höher.

@ubu
Aber was kannst Du zu meinem Problem mit dem Remote-Update von topgrade sagen?
Das war ja eigentlich meine Frage.
Du nutzt es ja auch.
Was muss man da noch beachten?
Und warum tauchen im LXC-Contanier zwei sudo-Prozesse auf?
Ich starte topgrade nicht mit sudo sondern als root auf dem PVE-Host.

EDIT:
Per ssh komme ich ohne Anmeldung zum LXC-Container.
Also sollte topgrade doch auch per ssh hinkommen.

root@pve83:~ # ssh root@192.168.1.85
Linux debian85 6.5.11-8-pve #1 SMP PREEMPT_DYNAMIC PMX 6.5.11-8 (2024-01-30T12:27Z) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Feb 24 14:11:45 2024 from 192.168.23.27
root@debian85:~ #

 

[matt69]

Remote-Update auf LXC-Container funktioniert bei mir nicht.
Wo liegt das Problem?

topgrade wurde mit root auf dem PVE-Host gestartet, danach hängen im LXC-Container Prozesse.
Diese Prozesse im LXC-Container müssten mit topgrade gestartet worden sein:

5438 pts/3    00:00:00 topgrade
5765 ?        00:00:00 packagekitd
5784 pts/3    00:00:00 sudo
5785 pts/4    00:00:00 sudo
5786 pts/4    00:00:01 apt-get

Konfig auf dem PVE-Host:

root@pve83:~ # cat ~/.config/topgrade.toml
[misc]

# List of remote machines with Topgrade installed on them
remote_topgrades = ["192.168.1.85"]

# Do not set the terminal title (default: true)
set_title = false

# Don't ask for confirmations (no default value)
assume_yes = true

# Do not ask to retry failed steps (default: false)
no_retry = true

# Run inside tmux (default: false)
run_in_tmux = true

Ich habe die Ursache gefunden.
Jetzt läuft das Remote-Update auf dem LXC-Container.

Man darf tmux NICHT verwenden.
Ich habe in der topgrade.toml den Parameter run_in_tmux = true wieder auskommentiert.
Neue Konfig auf dem PVE-Host:

root@pve83:~ # cat ~/.config/topgrade.toml
[misc]

# List of remote machines with Topgrade installed on them
remote_topgrades = ["192.168.1.85"]

# Do not set the terminal title (default: true)
set_title = false

# Don't ask for confirmations (no default value)
assume_yes = true

# Do not ask to retry failed steps (default: false)
no_retry = true

# Run inside tmux (default: false)
#run_in_tmux = true

Leider ist aber remote kein unattended Upgrade möglich.
Der Parameter -y (Say yes to package manager's prompt) wird remote nicht durchgeschleust.

Der topgrade-Entwickler hat aber das Problem erkannt und will Parameter zum Remote-Host durchgeschleusen lassen.
Mal sehen, wann das kommt.

 

[CoolTux]

Hattest Du denn tmux überhaupt installiert gehabt in den Containern?

 

[matt69]

Hattest Du denn tmux überhaupt installiert gehabt in den Containern?

Nö, das hat bisher niemand gesagt.
Welche Auswirkung hat das?

EDIT:
Wenn ich aber tmux auch nur lokal nutze, kommt am Ende diese Meldung:

(R)eboot
(S)hell
(Q)uit

Ich fürchte, damit wird es dann unattended wohl nichts.

 

[CoolTux]

Wenn Du nicht weißt was es ist, wieso sagst Du dann in der konfig das es genommen werden soll? Ergibt doch keinen Sinn und kann zu Fehlern führen.
Aber nun scheint es ja zu laufen.
Ich persönlich hätte ja Unattended Upgrades installiert. Wäre eventuell einfacher.
https://wiki.debian.org/UnattendedUpgrades

 

[matt69]

Wenn Du nicht weißt was es ist, wieso sagst Du dann in der konfig das es genommen werden soll?

Weil es hier steht.

 

[CoolTux]

Weil es hier steht.

Ok

rm -rf /

 

[Falk R.]

Ok

rm -rf /

Vorsicht mit solchen Codezeilen, es soll Leute geben, die soetwas einfach kopieren und einfügen.

Auch wenn unser Mitleid sich dann in Grenzen hält, schreiben diese Leute dann Bullshit über dieses Forum.

 

[CoolTux]

Vorsicht mit solchen Codezeilen, es soll Leute geben, die soetwas einfach kopieren und einfügen.

Auch wenn unser Mitleid sich dann in Grenzen hält, schreiben diese Leute dann Bullshit über dieses Forum.

Weil es hier steht.

 

[matt69]

@CoolTux
Komiker?
Ich wollte eigentlich zu Deinem Code nichts schreiben.
Ist normal unter meiner Würde.

Nun aber trotzdem ganz kurz.
Wenn @ubu die Konfig so empfiehlt, dachte ich, er weiß wovon er spricht.
Da habe ich mich drauf verlassen, wie schon so oft auf Infos anderer User.
Nicht alle sind Komiker...

 

[BassT]

Vielleicht kann ich dir mit meinem "Ultimate-Updater for Proxmox VE" weiter helfen
GitHub

Grüße

 

[matt69]

Vielleicht kann ich dir mit meinem "Ultimate-Updater for Proxmox VE" weiter helfen

Auf das Tool wurde ich vor einigen Wochen schon drauf aufmerksam gemacht.
Kurz vorher hatte ich aber schon topgrade konfiguriert.
Das nutze ich seit dem.

Ich wäre aber auch gerne bereit zu wechseln.
Weiß aber nicht, welches Tool von beiden für Anfänger einfacher/sinnvoller ist.
Bzw. welches Tool was besser/schlechter erledigt.
Möchte nämlich vermeiden, immense Zeit in überflüssige Konfigs. zu investieren.

 

[BassT]

Weiß aber nicht, welches Tool von beiden für Anfänger einfacher/sinnvoller ist.
Bzw. welches Tool was besser/schlechter erledigt.

Da kann ich leider glaub keine objektive Antwort drauf geben Zudem habe ich topgrade nie probiert.

 

[ubu]

Der Vorteil von topgrade ist dass es nicht nur die apt pakete updated, sondern auch flatpak, snap, rust etc.
Allerding sind auf einem Proxmox host diese normal nicht installiert

 

[BassT]

Der Vorteil von topgrade ist dass es nicht nur die apt pakete updated, sondern auch flatpak, snap, rust etc.
Allerding sind auf einem Proxmox host diese normal nicht installiert

Ok, wenn ich dann ein wenig schwärmen darf; mein Script wird auch fast alleine von mir betreut und ist in bash geschrieben. Damit ist es extrem klein und effizient.
Topgrade hat eine echt große Community und ist in Rust geschrieben.

Snap wird meines Wissens nach auch mit apt geupdatet.

Bei meinem Script kann man nicht nur den host updaten, sondern alleine mit dem Kommando "update", werden bei nahezu alle nodes, vms und lxcs, vollautomatisch nacheinander ein snapshot/backup gemacht und geupdated.
Feintuning kann per config file angepasst werden.

Für Anregungen - Verbesserungs-Vorschläge und bei Kenntnissen von bash, bin ich um jede Hilfe dankbar

Grüße