Debian: abweichende Paketversionen finden

[Christian Garbs]

Mahlzeit!

Wenn auf einem Debian-System Pakete installiert sind, die nicht aus
den konfigurierten Sourcen stammen, dann kann ich die mit

$ aptitude search ~o

finden ("Match installed packages that cannot be downloaded.").
Das entspricht dem Ausklapper "Local and obsolete packages" in der
aptitude-UI.


Wie aber kann ich Pakete finden, die zwar installiert sind, aber in
einer anderen Version als in den Sourcen?


Wenn die installierte Versionsnummer kleiner als die "offizielle" ist,
sind das Updates - die finde ich ganz einfach ("aptitude search ~U",
"apt list --upgradable" etc.).

Aber was ist, wenn es sich um Downgrades handelt?

Beispiel: Installiert habe ich z.B. foo-bar-1.32-0, aber in den
Sourcen ist nur foo-bar-1.30-1 enthalten.

Wie kann ich diese Konstellation aufspüren?

Danke und Gruß
Christian


PS: Hintergrund ist, dass ich den hier schon öfter mal andiskutierten
Wechsel von Ubuntu zu Debian gerade stumpf durchziehe ;-) Ich möchte
die letzten Pakete finden, bei denen ich noch unerkannt Ubuntu-
Versionen installiert habe. Bisher habe ich schon mit "~o",
"~Vubuntu" und "~Vfocal" wohl schon den Großteil gefunden.

Wenn ich durch bin, berichte ich hier - das System selbst scheint noch
am Leben zu sein, ob z.B. mein Firefox-Profil das Downgrade überlebt
hat, weiß ich noch nicht.
--
....Christian.Garbs....................................https://www.cgarbs.de
Jetzt habe ich schon 5 Mal Linux installiert und immer wenn ich fertig bin,
stürzt es mit "login:" ab! (SuSE Installations-FAQ)

[Marc Haber]

Christian Garbs <mi...@cgarbs.de> wrote:
>Wie kann ich diese Konstellation aufspüren?

Hilft vielleicht apt-forktracer?

aptitude search '?narrow(?installed, ?not(?origin(Debian)))' liefert
Dir alle installierten Pakete, die nicht "Debian" als origin haben.
Wobei ich mir nicht sicher bin, woher diese Information kommt.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Marco Moock]

Am Montag, 12. September 2022, um 07:43:06 Uhr schrieb Christian Garbs:

> Wie aber kann ich Pakete finden, die zwar installiert sind, aber in
> einer anderen Version als in den Sourcen?

Du kannst nach 'lokal'
greppen bei apt list.

apt list |grep ',lokal'

Ich habe es eben getestet mit dem Mozillateam-PPA und Thunderbird, das
Paket 'thunderbird' ist in Ubuntu drin, aber das PPA wird bei mir
genutzt. Kommentiert man das PPA aus und macht apt update, wird das
installierte Paket als lokal angezeigt.

[Peter Scholz]

Christian Garbs schrieb am Mon, 12 Sep 2022 07:43:06 -0000 (UTC):

> PS: Hintergrund ist, dass ich den hier schon öfter mal andiskutierten
> Wechsel von Ubuntu zu Debian gerade stumpf durchziehe ;-)

Ich habe mal gelesen, dass man das auch mit apt-clone von Ubuntu (das
Binary-Paket gibt es auch dort) im Verhältnis zu Debian durchziehen
kann. Ob das tatsächlich funktioniert kann ich nicht sagen.

apt-clone habe ich bisher mit Erfolg in folgenden Szenarien genutzt:

a) auf 3 Debian-Rechnern 3 Arbeitsumgebungen von 32 bit auf 64 bit
umgestellt
b) meine Debian-Standard-Installation komplett auf einen neuen Rechner
geclont

> Ich möchte
> die letzten Pakete finden, bei denen ich noch unerkannt Ubuntu-
> Versionen installiert habe. Bisher habe ich schon mit "~o",
> "~Vubuntu" und "~Vfocal" wohl schon den Großteil gefunden.

a) 1. Möglichkeit:
Die Unterschiede eines mit apt-clone erstellten Archivs gegenüber den
aktuell auf dem System installierten Paketen erhält man mit:
apt-clone show-diff apt-clone-state-[RECHNERNAME].tar.gz

b) 2. Möglichkeit:
- alte Ubuntu-Paket-Liste in eine Text-Datei exportieren
- neue Debian-Paket-Liste in eine Text-Datei exportieren
- Unterschiede beider Text-Dateien mit einem Tool anzeigen/exportieren
- Unterschiede aus dem Tool nach und nach abarbeiten

> Wenn ich durch bin, berichte ich hier - das System selbst scheint noch
> am Leben zu sein, ob z.B. mein Firefox-Profil das Downgrade überlebt
> hat, weiß ich noch nicht.

Ja, ein Erfolgsbericht erfreut hier alle Debian-User :-)

--
Gruß Peter

[Marc Haber]

Peter Scholz <Peter_...@vodafonmail.de> wrote:
>Christian Garbs schrieb am Mon, 12 Sep 2022 07:43:06 -0000 (UTC):
>> PS: Hintergrund ist, dass ich den hier schon öfter mal andiskutierten
>> Wechsel von Ubuntu zu Debian gerade stumpf durchziehe ;-)
>
>Ich habe mal gelesen, dass man das auch mit apt-clone von Ubuntu (das
>Binary-Paket gibt es auch dort) im Verhältnis zu Debian durchziehen
>kann. Ob das tatsächlich funktioniert kann ich nicht sagen.

Für das Protokoll: Binärpakete von Ubuntu und Debian mischen führt zu
exakt denselben Problemen wie beim Mischen von Binärpaketen aus
verschiedenen Debian-Entwicklungszweigen.

[Christian Garbs]

Mahlzeit!

Peter Scholz <Peter_...@vodafonmail.de> wrote:
> Christian Garbs schrieb am Mon, 12 Sep 2022 07:43:06 -0000 (UTC):
>
>> PS: Hintergrund ist, dass ich den hier schon öfter mal andiskutierten
>> Wechsel von Ubuntu zu Debian gerade stumpf durchziehe ;-)
>
> Ich habe mal gelesen, dass man das auch mit apt-clone von Ubuntu (das
> Binary-Paket gibt es auch dort) im Verhältnis zu Debian durchziehen
> kann. Ob das tatsächlich funktioniert kann ich nicht sagen.

Ich habe mir mal https://wiki.ubuntuusers.de/apt-clone/ angeguckt:
Wenn ich das richtig verstehe, kann ich damit ein System auf ein
anderes umziehen.
Ich will ja aber kein neues System anlegen, ich möchte "in situ" mein
Ubuntu in ein Debian verwandeln. Aus dem laufenden System heraus.

Spoiler: Es hat geklappt :)

> apt-clone habe ich bisher mit Erfolg in folgenden Szenarien genutzt:
>
> a) auf 3 Debian-Rechnern 3 Arbeitsumgebungen von 32 bit auf 64 bit
> umgestellt

Ich habe $damals ein 32bit-Debian auf 64bit migriert, aber nur mit
Debian-Bordmitteln. Da zu ga e's damals Anleitungen, worauf man
achten sollte. Ich glaube, das war noch vor der Multi-Arch-Zeit,
heute ist das vermutlich einfacher :)

> b) meine Debian-Standard-Installation komplett auf einen neuen Rechner
> geclont

>> Ich möchte die letzten Pakete finden, bei denen ich noch unerkannt
>> Ubuntu- Versionen installiert habe. Bisher habe ich schon mit
>> "~o", "~Vubuntu" und "~Vfocal" wohl schon den Großteil gefunden.

> a) 1. Möglichkeit:
> Die Unterschiede eines mit apt-clone erstellten Archivs gegenüber den
> aktuell auf dem System installierten Paketen erhält man mit:
> apt-clone show-diff apt-clone-state-[RECHNERNAME].tar.gz
>
> b) 2. Möglichkeit:
> - alte Ubuntu-Paket-Liste in eine Text-Datei exportieren
> - neue Debian-Paket-Liste in eine Text-Datei exportieren
> - Unterschiede beider Text-Dateien mit einem Tool anzeigen/exportieren
> - Unterschiede aus dem Tool nach und nach abarbeiten

Das Problem bei beidem ist, dass ich die Debian-Paketliste erst
erstellen kann, nachdem ich das Ubuntu auf Debian migriert habe. Wenn
ich dann aber die Unterschiede abarbeite, bin ich wieder zurück auf
Ubuntu ;-)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
"Der Mayer verkauft jetzt Möbel", erzählt Schulze am Stammtisch.
"Interessant, und wie viele hat er schon verkauft?" - "Bis jetzt",
lächelt Schulze, "nur seine eigenen."

[Christian Garbs]

Mahlzeit!

Marc Haber <mh+usene...@zugschl.us> wrote:
> Christian Garbs <mi...@cgarbs.de> wrote:

>>Wie kann ich diese Konstellation aufspüren?
>
> Hilft vielleicht apt-forktracer?

Die Paketbeschreibung klingt gut, das werde ich hier jetzt noch einmal
im Nachgang laufen lassen.

> aptitude search '?narrow(?installed, ?not(?origin(Debian)))' liefert
> Dir alle installierten Pakete, die nicht "Debian" als origin haben.

Das ist praktisch! Da sind (natürlich) dann auch die Pakete aus
meinen zusätzlichen Paketquellen gelistet, aber das sind nur eine
Handvoll, die kann ich aussortieren.

Das hat mir noch einiges gefunden, danke. Erkenntnis: Mit aptitude
nicht nur nach ~Vubuntu suchen, sondern auch nach ~Vbuild.

> Wobei ich mir nicht sicher bin, woher diese Information kommt.

Ich vermute, dass er das Paket zu seiner Paketquelle verfolgt
(aptitude kann ja die Download-URL zu einem Paket anzeigen) und in der
Release-Datei des Repositories steht dann der Origin.
(so wie der Parameter o= in der Konfiguration von unattended-upgrades)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Wenn man etwas vom Leben wissen will, muss man offene Ohren haben
und selbst keinen Lärm machen. --Pär Fabian Lagerkvist

[Christian Garbs]

Mahlzeit!

Marco Moock <mo...@posteo.de> wrote:
> Am Montag, 12. September 2022, um 07:43:06 Uhr schrieb Christian Garbs:
>
>> Wie aber kann ich Pakete finden, die zwar installiert sind, aber in
>> einer anderen Version als in den Sourcen?
>
> Du kannst nach 'lokal'
> greppen bei apt list.
>
> apt list |grep ',lokal'

Cool, auch das funktioniert. Es lässt anders als der
aptitude-Suchausdruck von Marc auch alle "passend" installierten
Pakete aus Drittrepositories weg. Der interessante Teil (die
abweichenden Pakete) ist deckungsgleich.

Dafür ist das etwas wackeliger: apt meldet ja schon, dass sich die
Ausgabe des Tools ändert kann und nicht in Skripten benutzt werden
sollte, außerdem muss ich hier auf dem System nach ',local' suchen,
weil die Ausgabe Locale-abhängig ist.

Auch danke!
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Soziologie ist die Kunst, Gegenstände, die jeder versteht und die keinen
interessieren, so darzulegen, daß sie keiner versteht und daß sie jeden
interessieren.

[Marc Haber]

Christian Garbs <mi...@cgarbs.de> wrote:

>Marc Haber <mh+usene...@zugschl.us> wrote:
>> aptitude search '?narrow(?installed, ?not(?origin(Debian)))' liefert
>> Dir alle installierten Pakete, die nicht "Debian" als origin haben.
>
>Das ist praktisch! Da sind (natürlich) dann auch die Pakete aus
>meinen zusätzlichen Paketquellen gelistet, aber das sind nur eine
>Handvoll, die kann ich aussortieren.

Die beiden Tipps kommen übrigens aus den Release-Notes, die empfehlen,
vor einem Versionsupgrade die nicht zu Debian gehörenden Pakete damit
zu identifizieren. Das sind nämlich die, mit denen man dann Ärger (und
keinen Support) hat.

>Ich vermute, dass er das Paket zu seiner Paketquelle verfolgt
>(aptitude kann ja die Download-URL zu einem Paket anzeigen) und in der
>Release-Datei des Repositories steht dann der Origin.
>(so wie der Parameter o= in der Konfiguration von unattended-upgrades)

Das heißt das funktioniert nur wenn die Paketquelle noch da ist.

[Marc Haber]

Christian Garbs <mi...@cgarbs.de> wrote:
>Dafür ist das etwas wackeliger: apt meldet ja schon, dass sich die
>Ausgabe des Tools ändert kann und nicht in Skripten benutzt werden
>sollte, außerdem muss ich hier auf dem System nach ',local' suchen,
>weil die Ausgabe Locale-abhängig ist.

LANG=C ist überall dort zu empfehlen wo man die Ausgabe von Tools
parst.

[Marco Moock]

Am Dienstag, 13. September 2022, um 18:59:30 Uhr schrieb Christian
Garbs:

> Cool, auch das funktioniert. Es lässt anders als der
> aptitude-Suchausdruck von Marc auch alle "passend" installierten
> Pakete aus Drittrepositories weg. Der interessante Teil (die
> abweichenden Pakete) ist deckungsgleich.

Das listet alle Pakete, die nicht in den im System aktiven Paketquellen
gefunden werden können.

Dazu zählen: Nicht mehr in aktiven Quellen verfügbarer Pakete (oft nch
me Upgrade), Pakete, die nie in Quellen waren und manuell installiert
wurden und Pakete, die mal in Paketquellen waren, die aber
deaktiviert/entfernt wurden (auch beim Upgrade bei Ubuntu passiert
das!).

Meines Erachtens wird wie gesagt einfach geprüft, ob ein Paket in
irgendeiner Quelle vorhanden ist, falls nicht, gilt es als lokal.
Korrigiert mich gerne, wenn ich falsch liege.

[Peter Scholz]

Christian Garbs schrieb am Tue, 13 Sep 2022 18:52:05 -0000 (UTC):

> Ich habe mir mal https://wiki.ubuntuusers.de/apt-clone/ angeguckt:
> Wenn ich das richtig verstehe, kann ich damit ein System auf ein
> anderes umziehen.

Das ist aber nur ein UseCase. Sicherlich der wichtigste.

Die Wirkungsweise ist recht simpel und hat überhaupt nichts mit dem
Mischen von Systemen zu tun.

Du installierst dir einfach ein sauberes Debian-Grundsystem.

Du kopierst dir einfach eine Paketliste aller in deinem Ubuntu
installierter Pakete. Nur hierfür brauchst du das Ubuntu-Binär-Paket.

Dann überträgst du einfach deine komplette Ubuntu-Paket-Liste in dein
sauberes Debian-Grundsystem und lässt dir mit apt-clone quasi einen
absolut sauberen 1:1 Debian-Clone deines kompletten Ubuntu
installieren. Nur hierfür brauchst du das Debian-Binär-Paket.

Ok - wenn du dein altes Ubuntu bereits überschrieben hast, dann
ist es jetzt für die Nutzung von apt-clone zu spät.

Wenn du dir die Hilfe zu apt-clone ansiehst, wirst du feststellen, dass
es folgenden speziellen Command gibt:

restore-new-distro

Der von mir gelesene Artikel bezog sich genau darauf, weshalb ich es
für sehr wahrscheinlich halte, dass es grundsätzlich auch mit einem
Ubuntu-Quell-System und einem Debian-Ziel-System tatsächlich
funktioniert.

--
Gruß Peter

[Peter Scholz]

Christian Garbs schrieb am Tue, 13 Sep 2022 18:52:05 -0000 (UTC):

> Peter Scholz <Peter_...@vodafonmail.de> wrote:

>> b) 2. Möglichkeit:
>> - alte Ubuntu-Paket-Liste in eine Text-Datei exportieren
>> - neue Debian-Paket-Liste in eine Text-Datei exportieren
>> - Unterschiede beider Text-Dateien mit einem Tool anzeigen/exportieren
>> - Unterschiede aus dem Tool nach und nach abarbeiten
>
> Das Problem bei beidem ist, dass ich die Debian-Paketliste erst
> erstellen kann, nachdem ich das Ubuntu auf Debian migriert habe. Wenn
> ich dann aber die Unterschiede abarbeite, bin ich wieder zurück auf
> Ubuntu ;-)

Wenn du dein Ubuntu bereits überschrieben hast, ohne dir zuvor
eine Ubuntu-Paket-Liste zu erstellen, hast Du natürlich keine
Vergleichsmöglichkeit :-)

--
Gruß Peter

[Christian Garbs]

Mahlzeit!

Marc Haber <mh+usene...@zugschl.us> wrote:

> Christian Garbs <mi...@cgarbs.de> wrote:
>>Marc Haber <mh+usene...@zugschl.us> wrote:

>>> aptitude search '?narrow(?installed, ?not(?origin(Debian)))'

[…]

> Die beiden Tipps kommen übrigens aus den Release-Notes, die empfehlen,
> vor einem Versionsupgrade die nicht zu Debian gehörenden Pakete damit
> zu identifizieren. Das sind nämlich die, mit denen man dann Ärger (und
> keinen Support) hat.

Ich habe wohl zu oft problemfreie dist-upgrades gemacht und überfliege
das Kapitel nur noch… Mehr als 'externe Paketquellen temporär
deaktivieren' ist bei mir nicht hängengeblieben.

>>Ich vermute, dass er das Paket zu seiner Paketquelle verfolgt
>>(aptitude kann ja die Download-URL zu einem Paket anzeigen) und in der
>>Release-Datei des Repositories steht dann der Origin.
>>(so wie der Parameter o= in der Konfiguration von unattended-upgrades)
>
> Das heißt das funktioniert nur wenn die Paketquelle noch da ist.

Korrekt geschlussfolgert - ich hab's gerade mal ausprobiert.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Hey, Baby, ich möchte wissen, ob Du mein Mädchen sein willst.
Zwei, drei, vier, fünf, sechs, sieben, acht. (DJ Ötzi)

[Christian Garbs]

Mahlzeit!

Marco Moock <mo...@posteo.de> wrote:

> Am Dienstag, 13. September 2022, um 18:59:30 Uhr schrieb Christian
> Garbs:

>> Cool, auch das funktioniert. Es lässt anders als der
>> aptitude-Suchausdruck von Marc auch alle "passend" installierten
>> Pakete aus Drittrepositories weg. Der interessante Teil (die
>> abweichenden Pakete) ist deckungsgleich.
>
> Das listet alle Pakete, die nicht in den im System aktiven Paketquellen
> gefunden werden können.
>
> Dazu zählen: Nicht mehr in aktiven Quellen verfügbarer Pakete (oft nch
> me Upgrade), Pakete, die nie in Quellen waren und manuell installiert
> wurden und Pakete, die mal in Paketquellen waren, die aber
> deaktiviert/entfernt wurden (auch beim Upgrade bei Ubuntu passiert
> das!).

Und ganz wichtig: Das alles gilt nicht nur für "Pakete", sondern für
konkrete "Paketversionen" (Paketname + Version).

Wenn ich z.B. das Paket "foo-bar" in der Version "ubuntu1" installiert
habe, es in den Debian-Paketquellen aber nur noch "foo-bar" in Version
"deb1u2" gibt, dann

- listet "aptitude ~i~o" das Paket _nicht_ auf, weil es sich nur um
eine Versionabweichung handelt, das Paket selbst (in einer anderen
Version) aber noch in den Debian-Repositories enthalten ist

- listet 'apt list | grep ,local' das Paket auf, weil es sich jeweils
die Kombination "Paketname + Paketversion" anguckt

Genau das macht es für mich interessant, weil ich dann "da versteckt
sich noch eine Ubuntu-Version" entdecken kann.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

You die... more--
Do you want your possessions identified?

[Christian Garbs]

Mahlzeit!

Peter Scholz <Peter_...@vodafonmail.de> wrote:

Es ist, weil ich's nicht gemacht habe, rein theoretisch, aber ich
glaube, es würde mir bei der Suche nach "Paket ist noch in der
Ubuntu-Version vorhanden" nicht helfen:

Wenn ich

1. unter Ubuntu die Paketliste erstelle
2. nach Debian migriere
3. die Debian-Paketliste erstelle

und dann beide Paketlisten vergleiche, dann sehe ich:

- abweichende Pakete -> da hat sich also was geändert, da ist jetzt
ganz klar das Debian-Paket installiert

- übereinstimmende Pakete -> hier sehe ich, dass das Paket erhalten
geblieben ist, aber ich sehe _nicht_, ob das korrekt ist (weil
Ubuntu und Debian das exakt gleiche Paket enthalten) oder ob es da
noch Handlungsbedarf gibt (weil ich das Ubuntu-Paket z.B. noch
manuell downgraden müsste, um auf die Debian-Version zu kommen).

Und genau den letztgenannten Fall wollte ich entdecken :-)



Die generelle Nutzung von apt-clone deckt sich in ungefähr mit meinem
noch nie in echt getesteten Recovery-Szenario:

- Laptop oder Festplatte geht in Flammen auf
- ich kaufe neue Hardware
- ich installiere das Basis-Betriebssystem neu
- ich hole die Paketliste aus dem letzten Backup und spiele die
Pakete ein, die vorher drauf waren
- ich hole /etc aus dem Backup, damit die Konfiguration wieder da ist
- ich hole /home, /var usw. aus dem Backup (bzw. die Teile davon, die
ich für backuprelevant erachtet habe)
- dabei werde ich mindestens einmal fluchen und meine Definition von
'backuprelevant' aktualisieren

Genau so hätte ich auch das Crossgrade von Ubuntu nach Debian machen
können, aber das ist langweilig und da lernt man ja nichts ;-)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Experience is a hard teacher because she gives the test first, the lesson
afterwards. -- Vernon Law

[Peter Scholz]

Christian Garbs schrieb am Thu, 15 Sep 2022 19:30:22 -0000 (UTC):

> Die generelle Nutzung von apt-clone deckt sich in ungefähr mit meinem
> noch nie in echt getesteten Recovery-Szenario:
>
> - Laptop oder Festplatte geht in Flammen auf
> - ich kaufe neue Hardware
> - ich installiere das Basis-Betriebssystem neu
> - ich hole die Paketliste aus dem letzten Backup und spiele die
> Pakete ein, die vorher drauf waren
> - ich hole /etc aus dem Backup, damit die Konfiguration wieder da ist
> - ich hole /home, /var usw. aus dem Backup (bzw. die Teile davon, die
> ich für backuprelevant erachtet habe)
> - dabei werde ich mindestens einmal fluchen und meine Definition von
> 'backuprelevant' aktualisieren

Ja, wäre eventuell auch ein UseCase für Menschen, die gerne fluchen :-)

> Genau so hätte ich auch das Crossgrade von Ubuntu nach Debian machen
> können, aber das ist langweilig und da lernt man ja nichts ;-)

Oh, sag das nicht :-)

Es gibt da, selbst wenn es glatt durchlaufen sollte, immer noch jede
Menge von Hand nachzuarbeiten, insbesonder in /etc.

Der größte Vorteil den ich aber sehe, ist, dass alle Nacharbeitungen -
nach erfolgreichem Durchlauf - immer in Bezug zu den richtigen
Binär-Dateien und den richtigen Abhängigkeiten aus den richtigen
Repositories erfolgen.

Wenn du dir ein sauberes Debian-Grundsystem konfigurierst, müsste das
nicht zwingend Stable sein. Das geht dann auch mit Testing oder
Unstable. Apt-clone würde dann in der Folge höchst wahrscheinlich auch
für diese Zweige einen sauberen (nicht gemischten) Debian-Clone deines
individuellen Ubuntu-Systems erstellen können.

Jetzt hast du aber leider ein Debian/Ubuntu gemischtes System und musst
alle Restanten suchen und finden (ev. downgraden pp.). Und selbst, bei
Namensgleichheit, kannst du dir nicht sicher sein, dass die Inhalte
aller (nicht aufgespürten) Pakete wirklich immer deckungsgleich sind. Da
wüsste ich (bei deinen über 2000 installierten Pakten) nie, ob das
jemals 100%-tig ein sauberes Debian-System wird. Aber genau dieses
scheint dich ja irgendwie zu reizen :-)

Nee, nee - Debian und Ubuntu haben sich im Laufe der Zeit derart krass
auseinander entwickelt, dass mir das zu heikel wäre.

Im Vorfeld meiner Smartphone-Konfiguration hatte ich mir testweise
einmal ein aktuelles Ubuntu installiert, um mir diesen UBports-Installer
gemauer anzusehen. Schrecklich, was die Ubuntu-Entwickler sich da alles
für das Standard-Ubuntu haben einfallen lassen :-)

Deshalb wäre ich mir da auch nicht absolut sicher, ob der
restore-new-distro Command jetzt überhaupt noch in Bezug auf Ubuntu ->
Debian so funktioniert wie früher einmal, zumal ich den damals gelesen
Artikel im Internet jetzt nicht mehr finden kann. Die Sache liegt auch
schon einige Jahre zurück.

Wie Du siehst wäre das auch mit apt-clone bestimmt nicht langweilig
geworden, insbesondere dann wenn du nach dieser Methode ohne apt-clone
hättest migrieren müssen:

# Paketliste auf Rechner A erstellen...
$ dpkg --get-selections | awk '!/deinstall|purge|hold/ {print $1} >
packages.list
# Pakete aus der Liste auf Rechner B installieren
$ xargs -a "packages.list" sudo apt-get install

usw. usw. :-)

Ich wünsche dir weiterhin viel Erfolg und bin weiterhin gespannt auf
deine nächsten diesbezüglichen Postings ;-)

--
Gruß Peter

[Tim Landscheidt]

Christian Garbs <mi...@cgarbs.de> wrote:

> […]

> Die generelle Nutzung von apt-clone deckt sich in ungefähr mit meinem
> noch nie in echt getesteten Recovery-Szenario:

> - Laptop oder Festplatte geht in Flammen auf
> - ich kaufe neue Hardware
> - ich installiere das Basis-Betriebssystem neu
> - ich hole die Paketliste aus dem letzten Backup und spiele die
> Pakete ein, die vorher drauf waren
> - ich hole /etc aus dem Backup, damit die Konfiguration wieder da ist
> - ich hole /home, /var usw. aus dem Backup (bzw. die Teile davon, die
> ich für backuprelevant erachtet habe)
> - dabei werde ich mindestens einmal fluchen und meine Definition von
> 'backuprelevant' aktualisieren

> Genau so hätte ich auch das Crossgrade von Ubuntu nach Debian machen
> können, aber das ist langweilig und da lernt man ja nichts ;-)

Unabhängig von Deinem konkreten Anwendungsfall: Ich würde
auch einmal einen Blick auf Ansible und andere Konfigurati-
onsmanagementsysteme werfen. Es kann sehr hilfreich sein, ob
automatisiert oder auch nur als „Checkliste“, wenn man auf-
schreibt, „auf diesem/jedem System soll bash installiert
sein und der Shell-Prompt so aufgebaut sein“, statt diese
Information aus Paketlisten und Konfigurationsdateien, bei
denen man eventuell nicht mehr nachvollziehen kann, ob sie
nur den Default oder eine gewünschte Änderung darstellen,
rekonstruieren zu müssen.

Tim

[Peter Scholz]

Tim Landscheidt schrieb am Fri, 16 Sep 2022 11:11:06 +0000:

> Unabhängig von Deinem konkreten Anwendungsfall: Ich würde
> auch einmal einen Blick auf Ansible und andere Konfigurati-
> onsmanagementsysteme werfen.

Kennt jemand etckeeper, um Konfigurationsänderungen im
Verzeichnis /etc zu versionieren?

https://etckeeper.branchable.com/

--
Gruß Peter

[Ulli Horlacher]

Das muss man immer noch manuell aufrufen, wenn man was selber editiert.
So was vergisst man (zu) oft.
Besser ist daher eine vollautomatische Versionierung wo man sich um nichts
kuemmern muss (ausser einmalige Einrichtung).
Ich verwende dazu
https://fex.belwue.de/fstools/vv.html
Das hat den Vorteil, dass es mit beliebigen Dateien funktioniert, nicht
nur die in /etc
Hat mich beim Programmieren schon oefters gerettet.

--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

[Peter Scholz]

Ulli Horlacher schrieb am Sat, 17 Sep 2022 11:41:48 +0000 (UTC):

> Peter Scholz <Peter_...@vodafonmail.de> wrote:
>> Tim Landscheidt schrieb am Fri, 16 Sep 2022 11:11:06 +0000:
>>
>>> Unabhängig von Deinem konkreten Anwendungsfall: Ich würde
>>> auch einmal einen Blick auf Ansible und andere Konfigurati-
>>> onsmanagementsysteme werfen.
>>
>> Kennt jemand etckeeper, um Konfigurationsänderungen im
>> Verzeichnis /etc zu versionieren?
>>
>> https://etckeeper.branchable.com/
>
> Das muss man immer noch manuell aufrufen, wenn man was selber editiert.
> So was vergisst man (zu) oft.
> Besser ist daher eine vollautomatische Versionierung wo man sich um nichts
> kuemmern muss (ausser einmalige Einrichtung).
> Ich verwende dazu
> https://fex.belwue.de/fstools/vv.html
> Das hat den Vorteil, dass es mit beliebigen Dateien funktioniert, nicht
> nur die in /etc
> Hat mich beim Programmieren schon oefters gerettet.

Hab mir dein vv mal angesehen. Sehr gut - selbst gebastelt?

Ich werde mir auch selbst was basteln - möglichst einfach, möglichst
sicher - mit Linux-Werkzeugen, die ich schon an Bord habe.

Ansible, Pupped oder Cdist - alles viel zu überladen und zu überfrachtet
für mein kleines Heimnetzwerk.

Zum Aufspüren von Konfigurationsänderungen in /etc abweichend der
Default-Einstellungen, nehme ich einfach Meld. Hiermit kann man sich
nicht nur die gefunden Verzeichnis-Orte der geänderten
Konfigurations-Dateien anzeigen lassen, sondern auch die konkreten
Änderungen innerhalb der Dateien Zeile für Zeile vergleichen und
nötigenfalls editieren. Das Referenz-/etc-Verzeichnis werde ich sicher
auf einen USB-Stick ablegen. Eine Versionierung brauche ich nicht.
Alle Änderungen, ggf. auch durch ein externes Update, werden dann ohne
mein Zutun gespeichert. Die aktuellsten Modifizierungen lassen sich
dann bei Bedarf durch einen einfachen Aufruf von Meld darstellen.
Eine Sicherung der Ursprungsdatei mache ich sowieso.

--
Gruß Peter

[Christian Garbs]

Mahlzeit!

Tim Landscheidt <t...@tim-landscheidt.de> wrote:

> Unabhängig von Deinem konkreten Anwendungsfall: Ich würde
> auch einmal einen Blick auf Ansible und andere Konfigurati-
> onsmanagementsysteme werfen. Es kann sehr hilfreich sein, ob
> automatisiert oder auch nur als „Checkliste“, wenn man auf-
> schreibt, „auf diesem/jedem System soll bash installiert
> sein und der Shell-Prompt so aufgebaut sein“, statt diese
> Information aus Paketlisten und Konfigurationsdateien, bei
> denen man eventuell nicht mehr nachvollziehen kann, ob sie
> nur den Default oder eine gewünschte Änderung darstellen,
> rekonstruieren zu müssen.

Ich glaube, das wäre hier mit Kanonen auf Spatzen zu schießen:

- meine persönliche Config habe ich in einem git-Repo¹, lokale
Abweichungen sind als Branch oder "nicht eingecheckt" erkennbar

- was installiert sein soll und was nur Abhängigkeit ist zählen
apt/aptitude anhand der manual/automatic-Markierung mit

- dass die Datenbank auf meinem Server und nicht auf dem Laptop
installiert ist, weiß ich so ;-)

- wenn ich größere Umbauarbeiten mache, checke ich die Änderungen in
/etc tatsächlich mit Kommentar ein, bei Kleinkram bin ich dafür zu
faul. Für "letzte Woche lief es noch, was ist jetzt anders?"
reicht mir der daily autocommit von etckeeper.

Es gibt tatsächlich den Fall, dass ich bei Libraries manchmal nicht
weiß, _warum_ ich sie manuell installiert habe. Das kann sein, weil
ich mal irgendein C-Programm lokal übersetzen wollte oder irgendein
selbstgeschriebenes Perlskript ein bestimmtes Modul braucht. Welches
das war und ob die Library noch benötigt wird, kriege ich nur nur
umständlich raus.

Aktuelle Lösung: Deinstallieren und gucken, was knallt ;-) Cronjobs
findet man so schnell, niemals benutzte Skripte nicht, aber die werden
ja auch nicht benutzt.

Das Problem drängt nicht so stark, dass ich da eine Lösung suche.
Vermutlich würde ich erstmal mit einer einfachen Textdatei anfangen
("$DATUM: $X installiert für $Y").


Lohnt sich Ansible bei individuell konfigurierten Single-User-
Systemen? Ich hätte das in Betracht gezogen, wenn ich

- diverse Systeme gleichartig einrichten muss

- ein einzelnes System wiederholt neu aufsetzen muss (wir haben so
eine Laborumgebung auf der Arbeit gehabt)

- mir ein System mit anderen Administratoren teile und wir
nachvollziehen müssen, wer etwas warum gemacht hat


Oder zählen etckeeper und mein config-git bereits als
"Konfigurationsmanagementsystem"? Dann ziehe ich das Posting zurück ;-)

Gruß
Christian


¹ https://github.com/mmitch/mitchscripts/tree/master/config
--
....Christian.Garbs....................................https://www.cgarbs.de
Wer diese Signatur zitiert, ist doof.

[Christian Garbs]

Mahlzeit!

Peter Scholz <Peter_...@vodafonmail.de> wrote:

> Kennt jemand etckeeper, um Konfigurationsänderungen im
> Verzeichnis /etc zu versionieren?

Ist auf allen meiner Systeme installiert und sehr praktisch.

Ich mache eher selten manuelle Commits der Art "Port XYZ in Firewall
freigeschaltet".

Aber die täglichen automatischen Commits erlauben es mir, ohne
weiteres Zutun in die Vergangenheit zu blicken, ohne gleich die
Backups auszugraben - das ist sehr praktisch.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

"Ham Se ma ne Maak fürn Brötchen?"
"Aber natürlich. Hier ist Ihre Mark."
"Jau, danke. Hier is Ihr Brötchen..."

[Peter Scholz]

Christian Garbs schrieb am Sun, 18 Sep 2022 08:50:11 -0000 (UTC):

> Oder zählen etckeeper und mein config-git bereits als
> "Konfigurationsmanagementsystem"? Dann ziehe ich das Posting zurück ;-)

Die Arch-Linuxer sehen das offenbar so ;-)

https://wiki.archlinux.org/title/list_of_applications#Configuration_management

--
Gruß Peter

[Peter Scholz]

Christian Garbs schrieb am Sun, 18 Sep 2022 08:53:34 -0000 (UTC):

> Mahlzeit!
>
> Peter Scholz <Peter_...@vodafonmail.de> wrote:
>
>> Kennt jemand etckeeper, um Konfigurationsänderungen im
>> Verzeichnis /etc zu versionieren?
>
> Ist auf allen meiner Systeme installiert und sehr praktisch.
>
> Ich mache eher selten manuelle Commits der Art "Port XYZ in Firewall
> freigeschaltet".
>
> Aber die täglichen automatischen Commits erlauben es mir, ohne
> weiteres Zutun in die Vergangenheit zu blicken, ohne gleich die
> Backups auszugraben - das ist sehr praktisch.

Ja, ich habe da mit git keine Erfahrung und Angst, dass da mit
meinen /etc-Daten gefährliche Sachen passieren :-)

--
Gruß Peter

[Christian Garbs]

Mahlzeit!

Peter Scholz <Peter_...@vodafonmail.de> wrote:

> Zum Aufspüren von Konfigurationsänderungen in /etc abweichend der
> Default-Einstellungen, nehme ich einfach Meld. Hiermit kann man sich
> nicht nur die gefunden Verzeichnis-Orte der geänderten
> Konfigurations-Dateien anzeigen lassen, sondern auch die konkreten
> Änderungen innerhalb der Dateien Zeile für Zeile vergleichen und
> nötigenfalls editieren. Das Referenz-/etc-Verzeichnis werde ich sicher
> auf einen USB-Stick ablegen. Eine Versionierung brauche ich nicht.
> Alle Änderungen, ggf. auch durch ein externes Update, werden dann ohne
> mein Zutun gespeichert. Die aktuellsten Modifizierungen lassen sich
> dann bei Bedarf durch einen einfachen Aufruf von Meld darstellen.
> Eine Sicherung der Ursprungsdatei mache ich sowieso.

Wie kriegst Du bei der Installation eines neuen Paketes die neu
installierten Dateien aus /etc in Dein Sicherungsverzeichnis?
Schiebst Du die manuell dort rüber?

Kannst Du "große" Änderungen an Konfigurationsdateien (z.B. ein
Versionswechsel bei einem Paket von 1.x auf 2.x) erkennen und
aktualisiert sich dann der "Ursprungs"-Stand im Sicherungsverzeichnis?


Ich frage, weil ich mein conffile-Merge-Skript gerne zu einem
3-way-merge ("Ursprungsfassung" zusätzlich zu "alte Version" und "neue
Version") ausbauen würde, mir fehlt dafür aber die Datenbasis.

(Aktuell arbeitet das Skript mit Emacs als Merge-Tool, aber meld
sollte sich da auch einbinden lassen.)

Gruß
Chrstian
--
....Christian.Garbs....................................https://www.cgarbs.de
Sauron is alive in Argentina!

[Tim Landscheidt]

Christian Garbs <mi...@cgarbs.de> wrote:

> […]

> Lohnt sich Ansible bei individuell konfigurierten Single-User-
> Systemen? Ich hätte das in Betracht gezogen, wenn ich

> - diverse Systeme gleichartig einrichten muss

> - ein einzelnes System wiederholt neu aufsetzen muss (wir haben so
> eine Laborumgebung auf der Arbeit gehabt)

> - mir ein System mit anderen Administratoren teile und wir
> nachvollziehen müssen, wer etwas warum gemacht hat

> Oder zählen etckeeper und mein config-git bereits als
> "Konfigurationsmanagementsystem"? Dann ziehe ich das Posting zurück ;-)

„Lohnen“ ist ja immer relativ zu dem Aufwand und dem Nut-
zen :-). Ich finde es häufig sehr praktisch (auch wenn ich
die Ansible-„Sprache“ (YAML) überhaupt nicht mag).

Letztes Jahr musste ein neuer Laptop her. Aufgrund des Wech-
sels des Systemnamens und anderer Gerätenamen wäre eine ma-
nuelle Migration von /etc wahrscheinlich ein längeres Unter-
fangen geworden. So hatte ich mein „playbook“ und konnte den
Großteil der Einrichtung automatisch durchführen.

Ähnlich verhält es sich mit meinem Mietserver. Da hatte der
Provider vor einiger Zeit mein ursprüngliches Produkt abge-
kündigt; auch da fand ich es sehr vorteilhaft, dass ich bei
der Neuinstallation nicht eine „black box“ übertragen muss-
te, die irgendwie mit etwas Magie funktioniert, sondern et-
was Handfestes hatte, wo, maschinen- aber auch menschenles-
bar, vermerkt war, dass für diese und jene Funktionalität
Paket A mit der Konfigurationsänderung B und dem Service C
vorhanden sein muss.

Vielleicht ist das, was Du mit dem letzten Punkt meinst: Ich
habe häufig keine Erinnerung mehr, warum ich vor x Jahren
einmal ein Paket installiert habe oder eine Konfigurations-
datei geändert. Ansible (und andere Systeme) bietet da die
Möglichkeit, das in einer Form zu „protokollieren“, die man
in der Zukunft wiederverwenden kann.

Aber: YMMV.

Tim

[Peter Scholz]

Christian Garbs schrieb am Sun, 18 Sep 2022 11:01:00 -0000 (UTC):

> Mahlzeit!
>
> Peter Scholz <Peter_...@vodafonmail.de> wrote:
>
>> Zum Aufspüren von Konfigurationsänderungen in /etc abweichend der
>> Default-Einstellungen, nehme ich einfach Meld. Hiermit kann man sich
>> nicht nur die gefunden Verzeichnis-Orte der geänderten
>> Konfigurations-Dateien anzeigen lassen, sondern auch die konkreten
>> Änderungen innerhalb der Dateien Zeile für Zeile vergleichen und
>> nötigenfalls editieren. Das Referenz-/etc-Verzeichnis werde ich sicher
>> auf einen USB-Stick ablegen. Eine Versionierung brauche ich nicht.
>> Alle Änderungen, ggf. auch durch ein externes Update, werden dann ohne
>> mein Zutun gespeichert. Die aktuellsten Modifizierungen lassen sich
>> dann bei Bedarf durch einen einfachen Aufruf von Meld darstellen.
>> Eine Sicherung der Ursprungsdatei mache ich sowieso.
>
> Wie kriegst Du bei der Installation eines neuen Paketes die neu
> installierten Dateien aus /etc in Dein Sicherungsverzeichnis?

gar nicht - es gibt nur einen General-Snapshot - siehe unten -.

> Schiebst Du die manuell dort rüber?

nein

> Kannst Du "große" Änderungen an Konfigurationsdateien (z.B. ein
> Versionswechsel bei einem Paket von 1.x auf 2.x) erkennen

ja

> aktualisiert sich dann der "Ursprungs"-Stand im Sicherungsverzeichnis?

Nur, wenn ich dies Ausnahmsweise will - siehe unten -.

Debian kann auch über die reguläre Release-Laufzeit etliche Jahre
sicher und stable - ohne viel Update-Zauber - weiter genutzt werden ;-)

> Ich frage, weil ich mein conffile-Merge-Skript gerne zu einem
> 3-way-merge ("Ursprungsfassung" zusätzlich zu "alte Version" und "neue
> Version") ausbauen würde, mir fehlt dafür aber die Datenbasis.

ja, die Datenbasis fehlt mir auch; deshalb eine Krücke - siehe unten -.

> (Aktuell arbeitet das Skript mit Emacs als Merge-Tool, aber meld
> sollte sich da auch einbinden lassen.)

ja, welche Vergleichswerkzeuge, ggf. mit Editier-Möglichkeit oder Datei-
Manager-Tools, ich nutze, sollte gleichgültig sein.

--- --- ---

Eigentlich wollte ich das alles erst später umsetzen. Aber ich bin sehr
dankbar jetzt unerwartet jemanden gefunden zu haben, die theoretischen
Probleme im Zusammenhang mit diesem "neuen Projekt" mit jemanden
besprechen zu können, der sogar durch die praktische Nutzung von
etckeeper über praktische Erfahrungen zu dieser Thematik verfügt.

- meine (einfache) Grundidee:

Ich kopiere einfach mein /etc auf einen USB-Stick und das war es
eigentlich auch schon, was man an Arbeit investieren muss :-)

Man könnte hier natürlich auch professionelle Programme wie backintime
oder kbackup nehmen, um solche "Verzeichnis-Snapshots" zu erstellen,
aber ich mag es eigentlich lieber recht einfach.

Ein USB-Stick als Datenträger erscheint mir sicher, jedenfalls sicherer
als wenn ich meine sensiblen /etc-Daten irgendwo in die Weltgeschichte
uploade, obwohl ein solcher Upload mit etckeeper nicht zwingend sein
soll - wenn ich das richtig verstanden habe.

- das (einfache) aufspüren der Veränderungen:

Nun Veränderungen finden immer nur in dem richtigen /etc-Verzeichnis
statt, entweder indem ich selbst manuell z.B. mithilfe eines Editors
oder Datei-Managers Änderungen in /etc vornehme beziehungsweise
automatisch extern im Wege von Programm-Updates oder durch das
Paketierungssystem bei Programm-Installationen/-Deinstallationen/
-Erweiterungen.

Welche Werkzeuge ich nun nutze, diese Veränderungen (im Verhältnis /etc
-> USB-Stick) aufzuspüren und sichtbar zu machen, ist Geschmackssache
eines jeden Users. Ich werde hierfür rsync und meld verwenden.

Die Verwendung des USB-Sticks bietet mir in meinem kleinen Heimnetzwerk
zudem den Vorteil, dass mir auch durch einfaches Einstöpseln des
USB-Sticks, Veränderungen an meinen anderen Debian-Rechnern (die alle
mit meinem speziellen Window-Environment einheitlich bestückt sind)
immer in Bezug auf meinen einheitlichen "General-Snapshot" angezeigt
werden.

Überdies bin ich nicht daran gehindert in "komplizierten" Fällen z.B.
bei geclonten Betriebssystem-Varianten z.B. mit Testing-/Unstable-
Systemen schnell und einfach weitere "etc-Snapshots" zu erstellen, um
komplexere Veränderungen dieser Spezial-Systeme flexibel nachvollziehen
zu können. Das gilt natürlich auch für den von dir angesprochenen Fall
der "großen" Änderungen an den Konfigurationsdateien (z.B. bei
Release-Upgrades). Paket-Versionswechsel in Debian-Stable sind eher
selten und würde ich während der Release-Laufzeit eher tolerieren
wollen, da es sich nur um ganz wenige Fälle handeln sollte. Für
Desktop-User spielt die Musik eigentlich sowieso im Home-Verzeichnis.

Eine Versionierung aller etc-Veränderungen findet bei diesem Konstrukt
natürlich nicht statt, da ich immer nur die letzte (aktuellste)
Veränderung in Bezug auf meinen "etc-Snapshot" sehe. Nun, da ich kein
Profi bin, interessiert mich aber eigentlich auch nur dieses :-)

- Problem der (eigentlichen) Urspungsfassung

Da ich aber erst jetzt auf die Idee gekommen bin Veränderungen an
meinem /etc-Verzeichnis verfolgen zu wollen, habe ich alle bereits
statt gehabten Veränderungen verpasst und mein etc-Snapshot spiegelt
natürlich nur den aktuellen Stand wieder. Das Problem sollte sich aber
bei einer Neu-Installation von etckeeper in dieser Weise auch so
stellen.

Die einzige Möglichkeit, die ich da sehe, ist, der Rückgriff auf meine
vor der Modifikation bereits angelegten Sicherungskopien, die jetzt
natürlich auch Bestandteil meines etc-Snapshots sind. Ich werde also in
meinem Snapshot-Verzeichnis auf dem USB-Stick diese Sicherungskopien
suchen müssen und dann irgendwie kennzeichnen/verändern, um einen
"künstlichen" Unterschied zu meinen Original-Sicherungskopien auf den
Festplatten zu "provozieren". Nur so werden mir dann die
prähistorischen Veränderungen meines /etc-Verzeichnisses bei einem
Meld-Aufruf überhaupt erst gekennzeichnet angezeigt. Dann die aktuelle
Config-Datei mit der prähistorischen Sicherungs-Datei zeilenweise zu
vergleichen, ist mit Meld schließlich kein Problem mehr.

Aber ich sehe da noch ein (mögliches weiteres) Problem in diesem
Zusammenhang: Inwieweit ist meine prähistorische Sicherungskopie
überhaupt mit einer aktuelle Ursprungs-/Standardfassung identisch?

Bei einem Paket-Versionswechsel gibt es 2 Möglichkeiten. Die
Debian-Update-Routine hat festgestellt: Sie benutzen eine von der
Standardfassung abweichende Konfiguration - 1) beibehalten?
2) überschreiben?

Wenn der Maintainer gut ist, sollte es eigentlich so laufen:

1) beibehalten:
Meine Konfiguration bleibt unverändert und ich erhalte die neue
Standkonfiguration hinzu kopiert (z.B. config.new).

2) überschreiben:
Meine Konfiguration wird überschrieben und ich erhalte eine
Sicherungskopie der alten Konfiguration hinzu kopiert (z.B. config.old).

Wenn das immer so abläuft ist ja alles ok. Nur wenn das nicht immer so
mustergültig abläuft, wäre eine Versionierung eigentlich unerlässlich.

Wie sind da deine praktischen Erfahrungen mit deinen einzelnen
Versionierungen speziell an dieser Stelle mit etckeeper?

Sollte man vielleicht aus diesem Grund mit versionierten
Sicherungskopien arbeiten oder gleich etckeeper verwenden?

--
Gruß Peter

[Christian Garbs]

Mahlzeit!

Peter Scholz <Peter_...@vodafonmail.de> wrote:

> - meine (einfache) Grundidee:
>
> Ich kopiere einfach mein /etc auf einen USB-Stick und das war es
> eigentlich auch schon, was man an Arbeit investieren muss :-)
>
> Man könnte hier natürlich auch professionelle Programme wie backintime
> oder kbackup nehmen, um solche "Verzeichnis-Snapshots" zu erstellen,
> aber ich mag es eigentlich lieber recht einfach.

Was bedeutet in dem Fall "einfach"? Was für ein Dateisystem ist auf
dem USB-Stick?

Gerade unter /etc solltest Du die korrekten Dateiattribute und
-besitzer behalten, das kannst Du also nicht einfach auf eine
FAT32-Partition kopieren (da wäre z.B. ein tar-Archiv nötig).

Außerdem solltest Du den Inhalt des Sticks ggf. verschlüsseln,
da stehen ja durchaus auch Passwörter und ähnliches drin.

> Ein USB-Stick als Datenträger erscheint mir sicher, jedenfalls
> sicherer als wenn ich meine sensiblen /etc-Daten irgendwo in die
> Weltgeschichte uploade, obwohl ein solcher Upload mit etckeeper
> nicht zwingend sein soll - wenn ich das richtig verstanden habe.

etckeeper kann verschiedene Versionsverwaltungen nutzen, per se legt
es das dazugehörige Repository aber erstmal nur lokal an (für git weiß
ich das, bei den anderen gehe ich stark davon aus).

Ob und wie Du das ggf. remote verteilen willst, bleibt Dir überlassen.

Ich bin mir nicht ganz sicher, wie gut git sich Dateiattribute und
-owner merkt, aber etckeeper führt zur Sicherheit selber noch eine
Dateiliste mit genau diesen Informationen und legt die mit im
Repository ab. Außerdem speichert git keine leeren Verzeichnisse,
die merkt sich etckeeper auch in so einer Nebenbuchführung.

Du könntest also das Repository auf dem Stick ablegen (oder dahin
kopieren), dann ginge das auch mit FAT32 :-) Verschlüsselung fehlt
aber noch.

> - das (einfache) aufspüren der Veränderungen:
>
> Nun Veränderungen finden immer nur in dem richtigen /etc-Verzeichnis
> statt, entweder indem ich selbst manuell z.B. mithilfe eines Editors
> oder Datei-Managers Änderungen in /etc vornehme beziehungsweise
> automatisch extern im Wege von Programm-Updates oder durch das
> Paketierungssystem bei Programm-Installationen/-Deinstallationen/
> -Erweiterungen.
>
> Welche Werkzeuge ich nun nutze, diese Veränderungen (im Verhältnis /etc
> -> USB-Stick) aufzuspüren und sichtbar zu machen, ist Geschmackssache
> eines jeden Users. Ich werde hierfür rsync und meld verwenden.

Wenn Du das mit etckeeper machst und z.B. git nutzt, bist Du
hochflexibel:

Du kannst im Repository an jeden vergangenen Zeitpunkt zurückgehen
oder beliebige Zeitpunkte miteinander vergleichen bzw. die
Unterschiede dazwischen ermitteln.

Du kannst, genug Disziplin beim Protokollieren von Änderungen
vorausgesetzt, dann ganz einfach bestimmte Aktionen ("Anlage User
Hugo" oder "Wechsel von Exim auf Postfix") finden und ggf. gezielt
wieder Rückgängig machen oder - siehe nächster Absatz - auf anderen
Rechnern wiederholen.

Das ist deutlich flexibler als ein einmaliger manueller Sync auf den
USB-Stick und vor allen weniger manueller Aufwand - per Default läuft
etckeeper nach jeder Paket(de-)installation sowie einmal täglich und
schreibt den Stand ins Repository. Auf den Stick kopieren kannst Du
das Repository ja dann trotzdem von Zeit zu Zeit, so als Backup.

> Die Verwendung des USB-Sticks bietet mir in meinem kleinen Heimnetzwerk
> zudem den Vorteil, dass mir auch durch einfaches Einstöpseln des
> USB-Sticks, Veränderungen an meinen anderen Debian-Rechnern (die alle
> mit meinem speziellen Window-Environment einheitlich bestückt sind)
> immer in Bezug auf meinen einheitlichen "General-Snapshot" angezeigt
> werden.

Das wäre ein Use-Case, an den ich nicht mal gedacht hätte.

Hier ist jeder Rechner insoweit "unique", dass ich niemals das ganze
/etc von einem zum anderen Kopieren würde. Vielleicht mal Teile,
z.B. /etc/nftables (und dann editiere ich die Portliste) oder
vielleicht der cron.d-Eintrag für mein Backupscript.

Du kannst, falls Du mit etckeeper und z.B. git arbeitest, darüber auch
die Konfigurationen übers Netzwerk abgleichen. Es wäre sogar sowas
möglich wie "ich habe lokal diese drei Änderungen, die will ich
behalten, aber zusätzlich die neueste Änderung vom master-Server
reinziehen".

Stichworte: Upstream, Pull, Merge mit git

> Überdies bin ich nicht daran gehindert in "komplizierten" Fällen z.B.
> bei geclonten Betriebssystem-Varianten z.B. mit Testing-/Unstable-
> Systemen schnell und einfach weitere "etc-Snapshots" zu erstellen, um
> komplexere Veränderungen dieser Spezial-Systeme flexibel nachvollziehen
> zu können. Das gilt natürlich auch für den von dir angesprochenen Fall
> der "großen" Änderungen an den Konfigurationsdateien (z.B. bei
> Release-Upgrades). Paket-Versionswechsel in Debian-Stable sind eher
> selten und würde ich während der Release-Laufzeit eher tolerieren
> wollen, da es sich nur um ganz wenige Fälle handeln sollte. Für
> Desktop-User spielt die Musik eigentlich sowieso im Home-Verzeichnis.

Das wäre auch mit etckeeper kein Problem: Branches oder halt einzelne
Repositories (ein Rechner wird ja entweder stable oder testing sein,
nicht beides).

> - Problem der (eigentlichen) Urspungsfassung
>
> Da ich aber erst jetzt auf die Idee gekommen bin Veränderungen an
> meinem /etc-Verzeichnis verfolgen zu wollen, habe ich alle bereits
> statt gehabten Veränderungen verpasst und mein etc-Snapshot spiegelt
> natürlich nur den aktuellen Stand wieder. Das Problem sollte sich aber
> bei einer Neu-Installation von etckeeper in dieser Weise auch so
> stellen.

Genau. Das macht den ersten Commit, wenn es installiert wird, davor
gab es nichts™.

> Die einzige Möglichkeit, die ich da sehe, ist, der Rückgriff auf meine
> vor der Modifikation bereits angelegten Sicherungskopien, die jetzt
> natürlich auch Bestandteil meines etc-Snapshots sind. Ich werde also in
> meinem Snapshot-Verzeichnis auf dem USB-Stick diese Sicherungskopien
> suchen müssen und dann irgendwie kennzeichnen/verändern, um einen
> "künstlichen" Unterschied zu meinen Original-Sicherungskopien auf den
> Festplatten zu "provozieren". Nur so werden mir dann die
> prähistorischen Veränderungen meines /etc-Verzeichnisses bei einem
> Meld-Aufruf überhaupt erst gekennzeichnet angezeigt. Dann die aktuelle
> Config-Datei mit der prähistorischen Sicherungs-Datei zeilenweise zu
> vergleichen, ist mit Meld schließlich kein Problem mehr.

Das ginge mit einem etckeeper-git-Repository auch, wenn man das will -
da fehlt dann nur die Zusatzbuchführung für die Dateirechte und
-owner, die müsste man noch manuell ergänzen.

Aber lohnen tut sich das vermutlich auch nicht, weil da ja auch nicht
ganz sicher ist, ob das der Originalzustand der Dateien war. Da
müsstest Du ja mitten in der Basis-Installation des Systems ein Backup
gemacht haben, bevor Du die erste Frage nach Hostname oder
Rootpasswort beantwortet hast.

Solange es keinen Debian-Weg gibt, um an die "originalen" Dateien
heranzukommen, ist das mehr oder weniger ungenau (zumindest für meine
Zwecke). An eine Möglichkeit, diese Informationen zu kriegen, glaube
ich inzwischen immer weniger, da es ja z.B. auch conffiles gibt, die
dynamisch angelegt und mit Daten befüllt werden. Da gibt es keine
Vorlagendatei im .deb-Paket.

> Bei einem Paket-Versionswechsel gibt es 2 Möglichkeiten. Die
> Debian-Update-Routine hat festgestellt: Sie benutzen eine von der
> Standardfassung abweichende Konfiguration - 1) beibehalten?
> 2) überschreiben?
>
> Wenn der Maintainer gut ist, sollte es eigentlich so laufen:

Ich glaube, da kann der Maintainer wenig kaputtmachen, der Mechanismus
ist ganz weit unten in dpkg eingebaut. Wenn er eine Datei in /etc als
conffile markiert hat, kommt die Frage ganz von alleine und das
anlegen der .dpkg-new bzw. .dpkg-old passiert auch durch
Standard-Mechanismen.

> Wie sind da deine praktischen Erfahrungen mit deinen einzelnen
> Versionierungen speziell an dieser Stelle mit etckeeper?

Da habe ich tatsächlich eine: etckeeper ignoriert absichtlich
*.dpkg-new und *.dpkg-old. Das habe ich das erste Mal bemerkt, als
ich mein Skript zum Automatischen mergen dieser Dateien das erste Mal
habe laufen ließ. Dann habe ich was am Skript korrigiert, von /etc
die Vorgängerversion eingespielt, wollte das Skript nochmal laufen
lassen und habe in die Röhre geguckt, weil die *.dpkg-new und
*.dpkg-old nicht wie erwartet wieder da waren.

Ich finde das Verhalten unintuitiv, überraschend und nicht gut.
Ich habe die /etc/etckeeper/update-ignore.d/01update-ignore editiert
und innerhalb von writefile() unter dem dpkg-Zweig aus den beiden
ignore-Anweisungen für "*.dpkg-*" und "*.ucf-*" comments gemacht.

> Sollte man vielleicht aus diesem Grund mit versionierten
> Sicherungskopien arbeiten oder gleich etckeeper verwenden?

Dieser Grund wäre für mich klar eine Entscheidung für etckeeper:

Man kann bei Bedarf bequem im Repository "surfen" und zurückliegende
Änderungen nochmal nachvollziehen (und mit einer viel höheren
zeitlichen Auflösung, als wenn man z.B. seine monatlich angelegten
Backups rauskramt - die man dann ja auch erstmal entschlüsseln und
entpacken muss usw.)

Kostet ja auch nichts - einfach das Paket installieren und arbeiten
lassen, da muss man ja prinzipiell nichts weiter für tun, es schreibt
erstmal mit.

(das einzige, woran man vielleicht denken muss: wenn man ein
hochgeheimes Passwort irgendwo gelöscht hat, steht es weiterhin in
der Historie des Repositories. aber mit Backups ist das ja auch
nicht anders.)


Grundsätzlich würde ich aber immer auch zusätzlich versionierte
Sicherheitskopien machen. In meinem Fall sind das z.B. wöchentliche
Backups (mit Datum im Dateinamen) von _allen_ relevanten Daten (nicht
nur /etc). Mit PAR2-Absicherung bei Lesefehlern, verschlüsselt und
möglichst auf externen Systemen gelagert ;-)

Das hat dann nichts mehr mit "was hat sich an /etc gegenüber letzte
Woche geändert?" zu tun, sondern soll gegen "Festplatte kaputt" oder
"Rechner brennt/Haus brennt" helfen - in dem Fall bringt etckeeper ja
nichts.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Zur Unterhaltung einer Party trägt niemand so viel bei wie diejenigen,
die gar nicht da sind. (Audrey Hepburn, 1929-1993)

[Peter Scholz]

Christian Garbs schrieb am Sat, 24 Sep 2022 19:21:35 -0000 (UTC):

> Mahlzeit!
>
> Peter Scholz <Peter_...@vodafonmail.de> wrote:
>
>> - meine (einfache) Grundidee:
>>
>> Ich kopiere einfach mein /etc auf einen USB-Stick und das war es
>> eigentlich auch schon, was man an Arbeit investieren muss :-)
>>
>> Man könnte hier natürlich auch professionelle Programme wie backintime
>> oder kbackup nehmen, um solche "Verzeichnis-Snapshots" zu erstellen,
>> aber ich mag es eigentlich lieber recht einfach.
>
> Was bedeutet in dem Fall "einfach"? Was für ein Dateisystem ist auf
> dem USB-Stick?
>
> Gerade unter /etc solltest Du die korrekten Dateiattribute und
> -besitzer behalten, das kannst Du also nicht einfach auf eine
> FAT32-Partition kopieren (da wäre z.B. ein tar-Archiv nötig).

Ich habe meinen Etc-Usb-Stick mit dem selben Datei-System formatiert,
wie die Mutter-Partitionen der Betriebssysteme. Formatieren und
Kopieren auf einen Usb-Stick sind zwei einfache Arbeitsschritte. Die
Dateiattribute sind also kein Problem.

> Außerdem solltest Du den Inhalt des Sticks ggf. verschlüsseln,
> da stehen ja durchaus auch Passwörter und ähnliches drin.

Ja, verschlüsseln geht auch. Aber ich bin noch nicht am Ende meiner
Tests. Final kann man noch jede Menge anderer Komplizierungen einbauen.

>> Ein USB-Stick als Datenträger erscheint mir sicher, jedenfalls
>> sicherer als wenn ich meine sensiblen /etc-Daten irgendwo in die
>> Weltgeschichte uploade, obwohl ein solcher Upload mit etckeeper
>> nicht zwingend sein soll - wenn ich das richtig verstanden habe.
>
> etckeeper kann verschiedene Versionsverwaltungen nutzen, per se legt
> es das dazugehörige Repository aber erstmal nur lokal an (für git weiß
> ich das, bei den anderen gehe ich stark davon aus).

Ok, dann muss man nur die Git-Befehle lernen.

> Ob und wie Du das ggf. remote verteilen willst, bleibt Dir überlassen.

Lieber nicht.

> Ich bin mir nicht ganz sicher, wie gut git sich Dateiattribute und
> -owner merkt, aber etckeeper führt zur Sicherheit selber noch eine
> Dateiliste mit genau diesen Informationen und legt die mit im
> Repository ab. Außerdem speichert git keine leeren Verzeichnisse,
> die merkt sich etckeeper auch in so einer Nebenbuchführung.

Git kann wohl keine Dateiattribute, das erledigt wohl etckeeper.

Ok, was etckeeper so alles kann und ob ich das wirklich brauche, sehe
ich wohl nur, wenn ich es testweise installiere.

> Du könntest also das Repository auf dem Stick ablegen (oder dahin
> kopieren), dann ginge das auch mit FAT32 :-) Verschlüsselung fehlt
> aber noch.

Wenn ich es testweise installiere, sehe ich ja wie tief es ins System
eingreift und ob es sich sauber wieder deinstallieren lässt.

Ich habe einige Skripte rund um apt programmiert, die mir seit Jahren
das Leben sehr vereinfachen und sogar auf Derivaten (z.B. frugalen
Mx-Linux-Installationen) laufen und jetzt sogar teilweise auf meinem
Dual-Boot-Smartphone mit Ubuntu-Touch :-)

Etckeeper macht mir das möglicherweise alles kaputt.

Ja, das glaube ich gerne. Ich bin mir da aber nicht sicher, ob ich das
dann wirklich auch alles brauche. Eine konkrete Vorstellung davon
bekomme ich wohl nur wenn ich testweise installiere.

>> Die Verwendung des USB-Sticks bietet mir in meinem kleinen Heimnetzwerk
>> zudem den Vorteil, dass mir auch durch einfaches Einstöpseln des
>> USB-Sticks, Veränderungen an meinen anderen Debian-Rechnern (die alle
>> mit meinem speziellen Window-Environment einheitlich bestückt sind)
>> immer in Bezug auf meinen einheitlichen "General-Snapshot" angezeigt
>> werden.
>
> Das wäre ein Use-Case, an den ich nicht mal gedacht hätte.

Auf meinen Multi-Boot-Rechnern ist aber genau dieses wichtig.

> Hier ist jeder Rechner insoweit "unique", dass ich niemals das ganze
> /etc von einem zum anderen Kopieren würde. Vielleicht mal Teile,
> z.B. /etc/nftables (und dann editiere ich die Portliste) oder
> vielleicht der cron.d-Eintrag für mein Backupscript.

Meine Rechner sind hardware-mäßig alle sehr "unique", produktiv
software-mäßig aber alle "Debian-einheitlich". Einer der wesentlichen
Gründe, warum ich damals von Manjaro nach Debian migriert bin.

Die Migration hat damals (jedes Paket händisch und einzeln tageweise)
insgesamt mehre Monate gedauert und ich habe es im nach hinein nicht
bereut! Erst später habe ich erkannt (bei meinen 64bit-Migrationen und
der Portierung auf einen neuen Rechnen), was für eine enorme
Arbeitserleichertung apt-clone ist.

> Du kannst, falls Du mit etckeeper und z.B. git arbeitest, darüber auch
> die Konfigurationen übers Netzwerk abgleichen. Es wäre sogar sowas
> möglich wie "ich habe lokal diese drei Änderungen, die will ich
> behalten, aber zusätzlich die neueste Änderung vom master-Server
> reinziehen".
>
> Stichworte: Upstream, Pull, Merge mit git

Ich habe da im Augenblick leider keine konkrete Vorstellung davon.
Bei mir kämen da noch eventuell geclonte Test-Installationen hinzu. Ich
sollte mir das tatsächlich einmal testweise installieren.

>> Überdies bin ich nicht daran gehindert in "komplizierten" Fällen z.B.
>> bei geclonten Betriebssystem-Varianten z.B. mit Testing-/Unstable-
>> Systemen schnell und einfach weitere "etc-Snapshots" zu erstellen, um
>> komplexere Veränderungen dieser Spezial-Systeme flexibel nachvollziehen
>> zu können. Das gilt natürlich auch für den von dir angesprochenen Fall
>> der "großen" Änderungen an den Konfigurationsdateien (z.B. bei
>> Release-Upgrades). Paket-Versionswechsel in Debian-Stable sind eher
>> selten und würde ich während der Release-Laufzeit eher tolerieren
>> wollen, da es sich nur um ganz wenige Fälle handeln sollte. Für
>> Desktop-User spielt die Musik eigentlich sowieso im Home-Verzeichnis.
>
> Das wäre auch mit etckeeper kein Problem: Branches oder halt einzelne
> Repositories (ein Rechner wird ja entweder stable oder testing sein,
> nicht beides).

Nach dem ich jetzt gesehen habe, wie schön stabil auch Debian-Unstable
läuft, kann ich leider nicht ausschließen, dass ich neben Stable,
Stable-Dirty, Testing jetzt auch Unstable für meine Tests von diversen
Betriebssystem-Partitionen auf dem selben Rechner nutzen werde.

>> - Problem der (eigentlichen) Urspungsfassung
>>
>> Da ich aber erst jetzt auf die Idee gekommen bin Veränderungen an
>> meinem /etc-Verzeichnis verfolgen zu wollen, habe ich alle bereits
>> statt gehabten Veränderungen verpasst und mein etc-Snapshot spiegelt
>> natürlich nur den aktuellen Stand wieder. Das Problem sollte sich aber
>> bei einer Neu-Installation von etckeeper in dieser Weise auch so
>> stellen.
>
> Genau. Das macht den ersten Commit, wenn es installiert wird, davor
> gab es nichts™.

Dieser Initialisierungs-Zeitpunkt wäre dann möglicherweise auch bei
einem Clonen und Upgraden zu einer Test-Installation kein großes
Problem.

...oder hast bei deinem Release-Upgrades mit Ubuntu für jede neue
Release-Version deines Ubuntu auch immer eine neue Initialisierung
deines Etckeeper vorgenommen?

Ja, so eine "Release-Konfigurations-Vorlagedatei" je Paket wäre die
Lösung :-)

Ja, ich liebe immer diese hervorragenden Konfigurations-Dateien, mit so
verständlichen Kommentaren, dass man keine weitere Hilfen oder Manpages
mehr lesen muss.

>> Bei einem Paket-Versionswechsel gibt es 2 Möglichkeiten. Die
>> Debian-Update-Routine hat festgestellt: Sie benutzen eine von der
>> Standardfassung abweichende Konfiguration - 1) beibehalten?
>> 2) überschreiben?
>>
>> Wenn der Maintainer gut ist, sollte es eigentlich so laufen:
>
> Ich glaube, da kann der Maintainer wenig kaputtmachen, der Mechanismus
> ist ganz weit unten in dpkg eingebaut. Wenn er eine Datei in /etc als
> conffile markiert hat, kommt die Frage ganz von alleine und das
> anlegen der .dpkg-new bzw. .dpkg-old passiert auch durch
> Standard-Mechanismen.

Leider ist da wohl jedes Paket etwas anders konstruiert und wir sind -
zumindest bei Debian - von einer Standardisierung weit entfernt.

>> Wie sind da deine praktischen Erfahrungen mit deinen einzelnen
>> Versionierungen speziell an dieser Stelle mit etckeeper?
>
> Da habe ich tatsächlich eine: etckeeper ignoriert absichtlich
> *.dpkg-new und *.dpkg-old. Das habe ich das erste Mal bemerkt, als
> ich mein Skript zum Automatischen mergen dieser Dateien das erste Mal
> habe laufen ließ. Dann habe ich was am Skript korrigiert, von /etc
> die Vorgängerversion eingespielt, wollte das Skript nochmal laufen
> lassen und habe in die Röhre geguckt, weil die *.dpkg-new und
> *.dpkg-old nicht wie erwartet wieder da waren.

interessant, habe so was auch befürchtet.

> Ich finde das Verhalten unintuitiv, überraschend und nicht gut.
> Ich habe die /etc/etckeeper/update-ignore.d/01update-ignore editiert
> und innerhalb von writefile() unter dem dpkg-Zweig aus den beiden
> ignore-Anweisungen für "*.dpkg-*" und "*.ucf-*" comments gemacht.

Ich fürchte auch, dass das nicht gut ist und werde das in jedem Fall
weiter beobachten, insbesondere laufend in meinem derzeitigen Bookworm.

>> Sollte man vielleicht aus diesem Grund mit versionierten
>> Sicherungskopien arbeiten oder gleich etckeeper verwenden?
>
> Dieser Grund wäre für mich klar eine Entscheidung für etckeeper:

Ja, bleibt nur die Frage nach etwaigen unerwünschten Nebenwirkungen :-)

> Man kann bei Bedarf bequem im Repository "surfen" und zurückliegende
> Änderungen nochmal nachvollziehen (und mit einer viel höheren
> zeitlichen Auflösung, als wenn man z.B. seine monatlich angelegten
> Backups rauskramt - die man dann ja auch erstmal entschlüsseln und
> entpacken muss usw.)
>
> Kostet ja auch nichts - einfach das Paket installieren und arbeiten
> lassen, da muss man ja prinzipiell nichts weiter für tun, es schreibt
> erstmal mit.

Ich mache eine Etckeeper-Test-Installation - allein schon, um erst
einmal durch diese dahinter liegenden Problematiken besser durch zu
blicken :-)

> (das einzige, woran man vielleicht denken muss: wenn man ein
> hochgeheimes Passwort irgendwo gelöscht hat, steht es weiterhin in
> der Historie des Repositories. aber mit Backups ist das ja auch
> nicht anders.)

Auch aus solchen Gründen sind die einfachsten Lösungen immer die besten.

> Grundsätzlich würde ich aber immer auch zusätzlich versionierte
> Sicherheitskopien machen. In meinem Fall sind das z.B. wöchentliche
> Backups (mit Datum im Dateinamen) von _allen_ relevanten Daten (nicht
> nur /etc). Mit PAR2-Absicherung bei Lesefehlern, verschlüsselt und
> möglichst auf externen Systemen gelagert ;-)

Ohne eine neue vollständige "Release-Konfigurations-Update-
Vorlagedatei", die der Maintainer bei jedem Release-Update immer
mitliefern müsste, wären aber alle "neuen Release-Update-Features" für
eine komfortable Nach-Nutzung möglicherweise verloren. Auch zusätzliche
versionierte Sicherheitskopien alter Dateien helfen da nichts und man
müsste wieder umständlich in aktuellen Hilfetexten und aktuellen
Manpages zumindest nach den neuen Features suchen.

Grundsätzlich können zusätzliche versionierte Sicherheitskopien aber
sinnvoll sein. Genau wie das von Tim angesprochene Problem "Ich

habe häufig keine Erinnerung mehr, warum ich vor x Jahren
einmal ein Paket installiert habe oder eine Konfigurations-

datei geändert." Bisher habe ich mir hierfür immer Notizen gemacht,
weil man z.B. nach 10 Jahren oftmals tatsächlich nicht mehr nachvoll-
ziehen kann, warum, wo und wie man bestimmte Konfigurationen damals in
welchen Situationen geändert hat. Hier könnten an solchen Stellen des
Betriebssystem auch versionierte Readme-Dateien hilfreich sein.

> Das hat dann nichts mehr mit "was hat sich an /etc gegenüber letzte
> Woche geändert?" zu tun, sondern soll gegen "Festplatte kaputt" oder
> "Rechner brennt/Haus brennt" helfen - in dem Fall bringt etckeeper ja
> nichts.

Richtig, aber welche Daten brauche ich tatsächlich? Auch aus diesem
Grunde werde ich mir Etckeeper einmal näher ansehen.

Vielleicht reicht mir ja auch schon ein einfaches:
sudo cruft -d "/etc"

Auch das ließe sich ja einfach archivieren und als versionierter
Snapshot mit anderen Installationen oder nach Updates/Upgrades
vergleichen und um zum eigentlichen Thema zurückzukehren: für den Fall
der Migration des Betriebssystems.

--
Gruß Peter

[Christian Garbs]

Mahlzeit!

Peter Scholz <Peter_...@vodafonmail.de> wrote:
> Christian Garbs schrieb am Sat, 24 Sep 2022 19:21:35 -0000 (UTC):

>> Peter Scholz <Peter_...@vodafonmail.de> wrote:

[etckeeper]

> Wenn ich es testweise installiere, sehe ich ja wie tief es ins System
> eingreift und ob es sich sauber wieder deinstallieren lässt.
>
> Ich habe einige Skripte rund um apt programmiert, die mir seit Jahren
> das Leben sehr vereinfachen und sogar auf Derivaten (z.B. frugalen
> Mx-Linux-Installationen) laufen und jetzt sogar teilweise auf meinem
> Dual-Boot-Smartphone mit Ubuntu-Touch :-)
>
> Etckeeper macht mir das möglicherweise alles kaputt.

etckeeper führt nur Buch, das überschreibt keine Dateien. Es wird Dir
ein /etc/.git/ anlegen sowie seine eigenen Konfigurationsdateien nach
/etc/etckeeper/ schreiben und ist ab dann unbemerkt hinter den
Kulissen tätig.

Ich kann mir nicht vorstellen, dass das irgendwas kaputt machen
könnte.

> ...oder hast bei deinem Release-Upgrades mit Ubuntu für jede neue
> Release-Version deines Ubuntu auch immer eine neue Initialisierung
> deines Etckeeper vorgenommen?

Auf keinen Fall, denn dann wäre ja die Historie weg :)

Wenn ich schlau war, habe ich bei einem Distributions-Upgrade manuell
ein git-Tag wie z.B. 'debian_11' gesetzt, damit ich den Zeitpunkt
direkt in der Historie wiederfinden kann.

Das lässt sich zur Not aber auch aus den Änderungen an
/etc/debian_version rekonstruieren, wenn man sich kurz davor oder
danach nach dem großen Commit, bei dem >1000 Pakete aktualisiert worden
sind, umschaut.

>>> Bei einem Paket-Versionswechsel gibt es 2 Möglichkeiten. Die
>>> Debian-Update-Routine hat festgestellt: Sie benutzen eine von der
>>> Standardfassung abweichende Konfiguration - 1) beibehalten?
>>> 2) überschreiben?

>>> Wenn der Maintainer gut ist, sollte es eigentlich so laufen:

>> Ich glaube, da kann der Maintainer wenig kaputtmachen, der Mechanismus
>> ist ganz weit unten in dpkg eingebaut. Wenn er eine Datei in /etc als
>> conffile markiert hat, kommt die Frage ganz von alleine und das
>> anlegen der .dpkg-new bzw. .dpkg-old passiert auch durch
>> Standard-Mechanismen.

> Leider ist da wohl jedes Paket etwas anders konstruiert und wir sind -
> zumindest bei Debian - von einer Standardisierung weit entfernt.

Das ist Debian, natürlich ist das standardisiert ;-)
https://www.debian.org/doc/manuals/maint-guide/dother.en.html#conffiles

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Mars University - knowledge brings fear

[Marc Haber]

Christian Garbs <mi...@cgarbs.de> wrote:

>Peter Scholz <Peter_...@vodafonmail.de> wrote:
>> Leider ist da wohl jedes Paket etwas anders konstruiert und wir sind -
>> zumindest bei Debian - von einer Standardisierung weit entfernt.
>
>Das ist Debian, natürlich ist das standardisiert ;-)
>https://www.debian.org/doc/manuals/maint-guide/dother.en.html#conffiles

Es gibt dpkg-conffiles, es gibt ucf, und es gibt die Möglichkeit,
seine Konfigurationsfiles in seinen Maintainerscripts vollkommen
manuell zu managen. Benutzt man debconf, bleibt nur die dritte
Möglichkeit, und kaum einer macht das vollständig oder gar richtig.

Ich muss Peter mithin leider zustimmen.

[Peter Scholz]

Christian Garbs schrieb am Mon, 26 Sep 2022 07:39:31 -0000 (UTC):

> etckeeper führt nur Buch, das überschreibt keine Dateien. Es wird Dir
> ein /etc/.git/ anlegen sowie seine eigenen Konfigurationsdateien nach
> /etc/etckeeper/ schreiben und ist ab dann unbemerkt hinter den
> Kulissen tätig.
>
> Ich kann mir nicht vorstellen, dass das irgendwas kaputt machen
> könnte.

Habe gelesen: "... klinkt sich in Paketmanager wie Apt ein ..."

Hört sich so an, als ob das irgendwie gefährlich werden könnte :-)

--- --- ---

1) Auf den "großen Commit" will ich nicht warten:

Heute deshalb ein Bookworm auf meinem "großen Rechner" zu Testzwecken
eingerichtet.

2) Dort hinein etckeeper installiert:

etckeeper (1.18.18-1 Debian:testing [all])
git (1:2.35.1-1 Debian:testing [amd64])
git-man (1:2.35.1-1 Debian:testing [all])
liberror-perl (0.17029-1 Debian:testing [all]

3) Eine kleine Text-Änderung in /etc erzeugt.

4) Standard-Modus unverändert belassen:

Der automatische Modus soll Etckeeper veranlassen einmal täglich
ohne mein Zutun alle Änderungen in /etc zu sichern.

5) Dann git und etckeeper initialisiert.

6) Ersten Commit mit einer Beschreibung erstellt.

7) Überprüfung:

git log
git log /etc/hosts
git show [...]

--- --- ---

Scheint alles zu funktionieren :-)

Jetzt werde ich die nächsten Tage mein neues Bookworm täglich
updaten und abwarten, wie sich etckeeper verhält.

Dann werde ich mir mal die History ansehen und schaun, was man da sonst
noch eventuell dran rumschrauben kann :-)

--
Gruß Peter

[Christian Garbs]

Mahlzeit!

Peter Scholz <Peter_...@vodafonmail.de> wrote:

> Christian Garbs schrieb am Mon, 26 Sep 2022 07:39:31 -0000 (UTC):
>
>> etckeeper führt nur Buch, das überschreibt keine Dateien. Es wird Dir
>> ein /etc/.git/ anlegen sowie seine eigenen Konfigurationsdateien nach
>> /etc/etckeeper/ schreiben und ist ab dann unbemerkt hinter den
>> Kulissen tätig.
>>
>> Ich kann mir nicht vorstellen, dass das irgendwas kaputt machen
>> könnte.
>
> Habe gelesen: "... klinkt sich in Paketmanager wie Apt ein ..."
>
> Hört sich so an, als ob das irgendwie gefährlich werden könnte :-)

Das ist nichts wildes, weil apt/aptitude für genau sowas eine
Infrastruktur haben.

etckeeper hat einfach die Datei /etc/apt/apt.conf.d/05etckeeper
angelegt und das dort eingetragene wird jetzt automatisch vor und nach
der Paketinstallation aufgerufen.

Über diesen Mechanismus könntest Du ggf. auch Deine eigenen Skripte
dort einhängen, je nachdem, was die machen und wann die aufgerufen
werden sollen.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Eifersucht ist eine Leidenschaft, die mit Eifer sucht, was Leiden schafft.

[Christian Garbs]

Mahlzeit!

Marc Haber <mh+usene...@zugschl.us> wrote:

> Christian Garbs <mi...@cgarbs.de> wrote:
>>Peter Scholz <Peter_...@vodafonmail.de> wrote:

>>> Leider ist da wohl jedes Paket etwas anders konstruiert und wir sind -
>>> zumindest bei Debian - von einer Standardisierung weit entfernt.
>>
>>Das ist Debian, natürlich ist das standardisiert ;-)
>>https://www.debian.org/doc/manuals/maint-guide/dother.en.html#conffiles
>
> Es gibt dpkg-conffiles, es gibt ucf, und es gibt die Möglichkeit,
> seine Konfigurationsfiles in seinen Maintainerscripts vollkommen
> manuell zu managen. Benutzt man debconf, bleibt nur die dritte
> Möglichkeit, und kaum einer macht das vollständig oder gar richtig.

Böh :-(

Kann es sein, dass sowas wie "Dpkg::Options::=--force-confnew" von ucf
auch ignoriert wird? Ich hatte einzelne Pakete, die trotz "nimm alle
neuen Conffiles" nachgefragt haben. Das würde das erklären.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Nothing is as simple as it seems at first
Or as hopeless as it seems in the middle
Or as finished as it seems in the end.

[Marc Haber]

Christian Garbs <mi...@cgarbs.de> wrote:
>Kann es sein, dass sowas wie "Dpkg::Options::=--force-confnew" von ucf
>auch ignoriert wird?

Freilich. ucf hat eigene Konfiguration.

[Christian Garbs]

Mahlzeit!

Marc Haber <mh+usene...@zugschl.us> wrote:

> Christian Garbs <mi...@cgarbs.de> wrote:

>>Kann es sein, dass sowas wie "Dpkg::Options::=--force-confnew" von ucf
>>auch ignoriert wird?
>
> Freilich. ucf hat eigene Konfiguration.

Ich stöbere gerade in der ucf-Manpage. Hey, ein Three-Way-Merge,
warum kam mir der noch nie entgegen ;-)

| ENVIRONMENT VARIABLES
|
| The variable UCF_FORCE_CONFFNEW, if set, forces the new file
| to always overwrite the installed destination file, while the
| variable UCF_FORCE_CONFFOLD, if set silently retains the
| installed file.

Das klingt wie --force-confnew/confold, aber da steht nicht explizit
dabei, ob ucf dann die Datei *.ucf-dist bzw. *.ucf-new weiterhin
angelegt.

Hast Du eine Idee, wie ich in einem laufenden System am einfachsten
einen ucf-Prompt provozieren könnte, um das auszuprobieren?

Vorab eine Datei nach /etc schreiben und dann erstmalig ein Paket mit
ucf-Support installieren, das dann einen Konflikt erkennt, sollte
funktionieren, klingt aber etwas umständlich.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Wissen ist Macht!
Ich weiß nichts...
Macht nix!

[Marc Haber]

Christian Garbs <mi...@cgarbs.de> wrote:
>Hast Du eine Idee, wie ich in einem laufenden System am einfachsten
>einen ucf-Prompt provozieren könnte, um das auszuprobieren?
>
>Vorab eine Datei nach /etc schreiben und dann erstmalig ein Paket mit
>ucf-Support installieren, das dann einen Konflikt erkennt, sollte
>funktionieren, klingt aber etwas umständlich.

ucf ist ein langweiliges binary, das kann man einfach von der
Kommandozeile aufrufen. Beispiele müssten in der Manpage sein.

[Peter Scholz]

Christian Garbs schrieb am Mon, 26 Sep 2022 18:18:16 -0000 (UTC):

> etckeeper hat einfach die Datei /etc/apt/apt.conf.d/05etckeeper
> angelegt und das dort eingetragene wird jetzt automatisch vor und nach
> der Paketinstallation aufgerufen.

Danke für den Hinweis!

Wird ja immer besser :-)

> Über diesen Mechanismus könntest Du ggf. auch Deine eigenen Skripte
> dort einhängen, je nachdem, was die machen und wann die aufgerufen
> werden sollen.

Die dort verwendete Syntax:

{ "if [ $a = $b ]; then $c ; fi"; };

gilt ganz grundsätzlich?

Eine solche Syntax für Bedingungen suche ich nämlich schon lange auch in
anderen Zusammenhängen für einzeilige Befehlsketten.

--
Gruß Peter

[Peter Scholz]

Christian Garbs schrieb am Tue, 27 Sep 2022 07:25:45 -0000 (UTC):

> Ich stöbere gerade in der ucf-Manpage. Hey, ein Three-Way-Merge,
> warum kam mir der noch nie entgegen ;-)
>
> | ENVIRONMENT VARIABLES
> |
> | The variable UCF_FORCE_CONFFNEW, if set, forces the new file
> | to always overwrite the installed destination file, while the
> | variable UCF_FORCE_CONFFOLD, if set silently retains the
> | installed file.
>
> Das klingt wie --force-confnew/confold, aber da steht nicht explizit
> dabei, ob ucf dann die Datei *.ucf-dist bzw. *.ucf-new weiterhin
> angelegt.
>
> Hast Du eine Idee, wie ich in einem laufenden System am einfachsten
> einen ucf-Prompt provozieren könnte, um das auszuprobieren?

ev. in der /etc/ucf.conf konfigurieren

> Vorab eine Datei nach /etc schreiben und dann erstmalig ein Paket mit
> ucf-Support installieren, das dann einen Konflikt erkennt, sollte
> funktionieren, klingt aber etwas umständlich.

bei mir konnte ich nur finden:

/etc/ssh/sshd_config.ucf-dist
/etc/ssh/sshd_config
/etc/ssh/sshd_config_alt

--
Gruß Peter

[Peter Scholz]

Peter Scholz schrieb am Tue, 27 Sep 2022 18:49:48 +0200:

> bei mir konnte ich nur finden:
>
> /etc/ssh/sshd_config.ucf-dist

Höchst interessant ist jetzt natürlich:

sshd_config.ucf-dist

Ein Vergleich in a) Stable und b) Testing zeigt:

Modifikations:
a) Stabel - 22. Aug 2021
b) Testing - 26. Sep 09:43 (Einrichtung Bookworm gestern)

Ein Aufruf mit Meld zeigt:

Nicht nur das Modifikationsdatum ist unterschiedlich, auch die Inhalte
beider Dateien differieren, nicht nur in den Kommentierungen, sondern
auch in einigen Standard-Einstellungen.

> /etc/ssh/sshd_config

meine geänderterte Konfiguration (ist unverändert)

> /etc/ssh/sshd_config_alt

meine Sicherungskopie (ist unverändert)



Fazit:

Alles so wie es sein soll :-)
/etc/ucf.conf ist bei mir unverändert (kannte ich bisher nicht)

--
Gruß Peter

[Christian Garbs]

Mahlzeit!

Peter Scholz <Peter_...@vodafonmail.de> wrote:

[ Es geht um /etc/apt/apt.conf.d/05etckeeper ]

> Die dort verwendete Syntax:
>
> { "if [ $a = $b ]; then $c ; fi"; };
>
> gilt ganz grundsätzlich?

Der Teil

| { " "; };

ist apt.conf-spezifische Konfigurations-Syntax.

Der Teil

> if [ $a = $b ]; then $c ; fi

ist ganz normales POSIX-konformes Shellskript. Das lässt sich in der
Form überall nutzen, wo Shellskript möglich ist. Ganz grob gesagt
ersetzen die Semikolons die Zeilenumbrüche.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Jetzt habe ich schon 5 Mal Linux installiert und immer wenn ich fertig bin,
stürzt es mit "login:" ab! (SuSE Installations-FAQ)

[Patrick Rudin]

Peter Scholz wrote:
> Die dort verwendete Syntax:
>
> { "if [ $a = $b ]; then $c ; fi"; };

Wiewas? Dort darf man ein einzelnes Gleichheitszeichen als
Vergleichsoperator benutzen??

Warum ärgere ich BASIC-verdorbener Amateur mich mit dummen Vertippern in
R rum?

database %>% filter(p_number = 11200)
Fehler: Problem with `filter()` input `..1`.
✖ Input `..1` is named.
ℹ This usually means that you've used `=` instead of `==`.
ℹ Did you mean `p_number == 11200`?

Ehrlich, passiert mir täglich. Falls es einen Gott gibt, dann schmort
Sinclair(ja, der vom ZX-81) in der Hölle...


Erstaunt

Patrick

[Peter Scholz]

Patrick Rudin schrieb am Tue, 27 Sep 2022 23:04:31 +0200:

> Peter Scholz wrote:
>> Die dort verwendete Syntax:
>>
>> { "if [ $a = $b ]; then $c ; fi"; };
>
> Wiewas? Dort darf man ein einzelnes Gleichheitszeichen als
> Vergleichsoperator benutzen??

Als BASH-verdorbener Amateur würde ich sagen, dass das zumindest als
string comparison funktionieren sollte:

https://tldp.org/LDP/abs/html/comparison-ops.html

> Warum ärgere ich BASIC-verdorbener Amateur mich mit dummen Vertippern in
> R rum?
>
> database %>% filter(p_number = 11200)

Als Database nutze ich dann gerne einfache Text-Dateien oder
Verzeichnisinhalte mit Text-Dateien. Als Frontend gebrauche ich für
solche Datenbank-Skripte vorzugsweise smenu und fzf (CLI) oder dmenu und
rofi (GUI).

Solche Befehlsketten lassen sich dann als Datensätze (=Zeilen)
speichern und die Datensätze als Befehlsketten executieren, ohne sie
als Bash-Skript ausführen zu müssen. Man könnte so etwas einfach ins
Terminal eintippen und Enter-Taste: Läuft ab als Stapelverarbeitung,
wie ein Bash-Skript. Macht natürlich keiner, deshalb fzf oder rofi :-)

Jetzt war ich aber hocherfreut in /etc/apt/apt.conf.d/05etckeeper
u.a. dies zu lesen:

{ "if [ -x /usr/bin/etckeeper ]; then etckeeper pre-install; fi"; };

Diese Syntax habe ich bisher noch nirgendwo so gelesen.

Hiermit bin ich bisher immer gescheitert:

[...]; if [ $a = $b ]; then $c ; fi; [...];

Natürlich kann ich eine solche Zeile in ein Bash-Skript einfügen.
Als Bedingung in einer "reinen" einzeiligen Befehlskette - außerhalb
einer Bash-Datei - funktioniert es so aber nicht.

Entscheidend sind hier die Klammern und Anführungszeichen:

[...]; { "if [ $a = $b ]; then $c ; fi"; }; [...];

Der Joey Hess ist schon ziemlich pfiffig und ich vermute, es
funktioniert auch ganz grundsätzlich. Werde ich jedenfalls bei nächster
Gelegenheit ausprobieren...

--
Gruß Peter

[Peter Scholz]

Peter Scholz schrieb am Tue, 27 Sep 2022 18:49:48 +0200:

[ucf]

> bei mir konnte ich nur finden:
>
> /etc/ssh/sshd_config.ucf-dist
> /etc/ssh/sshd_config
> /etc/ssh/sshd_config_alt

Alles andere ist bei mir dpkg-konfiguriert.

Als geeignete Beispiele kann ich herauspicken:

/etc/fuse.conf.dpkg-dist
/etc/fuse.conf
/etc/fuse.conf_alt

/etc/udevil/udevil.conf.dpkg-dist
/etc/udevil/udevil.conf
/etc/udevil/udevil.conf_alt

Ein Vergleich in Stable und Testing zeigt aber keinerlei Unterschiede.

--- --- ---

Die entscheidende Zeile, mit der ich meine Regel-Updates hinsichtlich
dpkg fahre lautet:

| echo "* full-upgrade..." && sudo apt -o Dpkg::Options::="--force-confold" full-upgrade --no-install-recommends -y
#--force-confold: do not modify the current configuration file, the new version is installed with a .dpkg-dist suffix. With this option alone, even configuration files that you have not modified are left untouched.

Wie man oben sehen kann, wurde die Regel im Laufe der Jahre bei mir
immer richtig ausgeführt.

Fazit:

Alles so wie es sein soll :-)

Meine Konfigurationen und Sicherungskopien sind wohl alle über die
Jahre und auch in meinem neuen Testing unangetastet geblieben.

Die von mir so ersehnte vollständige "Release-Konfigurations-Update-
Vorlagedatei", ist immer in der letzten Version sowohl als dpkg und ucf
ausgeliefert worden.

--- --- ---

Wenn ich das jetzt richtig sehe, ist der Mehrwert, den ich durch eine
etckeeper-Neuinstallation erhalte, dass mir alte Versionen dieser
dpkg-/ucf-"Vorlagedateien" erhalten und für eine Rekonstruktion
zukünftig zur Verfügung stehen?

--
Gruß Peter

[Christian Garbs]

Mahlzeit!

Peter Scholz <Peter_...@vodafonmail.de> wrote:

> Jetzt war ich aber hocherfreut in /etc/apt/apt.conf.d/05etckeeper
> u.a. dies zu lesen:
>
> { "if [ -x /usr/bin/etckeeper ]; then etckeeper pre-install; fi"; };
>
> Diese Syntax habe ich bisher noch nirgendwo so gelesen.
>
> Hiermit bin ich bisher immer gescheitert:
>
> [...]; if [ $a = $b ]; then $c ; fi; [...];

Was für eine Shell benutzt Du, dass Du sowas wie

if [ foo = bar ]; then echo A; else echo B; fi

nicht einfach direkt am Prompt eintippen kannst?
Das sollte auf jeder Posix-kompatiblen Shell funktionieren.

> Natürlich kann ich eine solche Zeile in ein Bash-Skript einfügen.
> Als Bedingung in einer "reinen" einzeiligen Befehlskette - außerhalb
> einer Bash-Datei - funktioniert es so aber nicht.

Es gibt da erstmal keinen Unterschied, ob Du diese Zeile

a) in eine Datei schreibst und diese dann durch eine Shell ausführen
lasst, z.B. 'bash datei.txt'

b) in eine Datei schreibst und diese Datei dann der Shell auf stdin
zuführst, z.B. 'bash < datei.txt'

c) diese Zeile am interaktiven Prompt der Shell selber eintippst

> Entscheidend sind hier die Klammern und Anführungszeichen:
>
> [...]; { "if [ $a = $b ]; then $c ; fi"; }; [...];

Die Anführungszeichen gehören aber zu den Konfigurations-Direktiven
innerhalb der apt-Konfiguration, das hat mit dem Shellskript nichts
mehr zu tun.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

* Progress (n.): The process through which Usenet has evolved from
  smart people in front of dumb terminals to dumb people in front of
  smart terminals.

[Peter Scholz]

Christian Garbs schrieb am Wed, 28 Sep 2022 18:44:50 -0000 (UTC):

> Was für eine Shell benutzt Du, dass Du sowas wie
>
> if [ foo = bar ]; then echo A; else echo B; fi
>
> nicht einfach direkt am Prompt eintippen kannst?

bash

> Das sollte auf jeder Posix-kompatiblen Shell funktionieren.

Unverkettet macht dein Beispiel keinen Sinn, verkettet hat es bei mir
nicht funktioniert. Habe jetzt leider kein Beispiel; kann mir aber auch
keines aus den Fingern saugen.

Meine derzeit genutzten Verkettungen sind als Beispiel für diesen
Kontext hier auch ungeeignet, da zur allgemeinen Verständlichmachung,
eine Erklärung dieser komplexen Datenbank-Skripte den Rahmen dieses
Threads hier sprengen würden. Soviel zum UseCase: Es handelt sich u.a.
um einen selbst gebasteltes Bash-Skript als CLI- und GUI-Launcher
fürs Terminal oder ganz ohne x-Server u.a. z.B. mit einer
Import-Funktion aus der Bash-History und einer Export-Funktion ins
Primary/Clipbord oder einfach zur menügesteuerten Ausführung
(Debugging im Zusammenwirken mit der Bash-History) von Linux-Befehlen
aus einer oder mehreren Datenbanken, wozu auch die allgemeine Bash-
History zählt.

> Die Anführungszeichen gehören aber zu den Konfigurations-Direktiven
> innerhalb der apt-Konfiguration, das hat mit dem Shellskript nichts
> mehr zu tun.

Ja, dass ist so.

Entscheidend sind innerhalb der Verkettung [...]; ... ; [...]; die
Klammern und möglicherweise auch die Anführungszeichen, also nicht für
eine bloße Nutzung innerhalb von Shell-Skripten (als alleiniger
Stapelverarbeitungsprozess), sondern als separater Befehl außerhalb
des in Gang setzenden Skript-Prozesse als separater unabhängiger
(zweiter) (Hintergrund- oder Kind-)Prozess gespeist aus einer Database:

[...]; { "if [ $a = $b ]; then $c ; fi"; }; [...];

Aus dem von dir Gesagten lässt sich für mich nicht zwingend herleiten,
dass es allgemein nicht funktionieren könnte. Immerhin schließt die
geschweifte Klammer mit einem zusätzlichen Semikolon, wodurch die
If-Then-Bedingung als (einheitlicher) Command ausgeführt wird. Das
könnte nämlich genau der Grund sein, warum ein solches eingebettetes
Verkettungs-Konstrukt ohne geschweifete Klammern und zusätzliches
Semikolon bei mir bisher nicht funktioniert hat.

Es geht mir nicht ums recht haben wollen. Werde es bei nächster
Gelegenheit einfach ausprobieren, wenn sich das Problem noch einmal
stellen sollte. Wenn es weiterhin nicht funktioniert, habe ich eben
Pech gehabt und es funktioniert dann eben nicht :-)

--
Gruß Peter

[Christian Garbs]

Mahlzeit!
Peter Scholz <Peter_...@vodafonmail.de> wrote:

> Christian Garbs schrieb am Wed, 28 Sep 2022 18:44:50 -0000 (UTC):

>> Was für eine Shell benutzt Du, dass Du sowas wie
>>
>> if [ foo = bar ]; then echo A; else echo B; fi
>>
>> nicht einfach direkt am Prompt eintippen kannst?
>
> bash
>
>> Das sollte auf jeder Posix-kompatiblen Shell funktionieren.
>
> Unverkettet macht dein Beispiel keinen Sinn, verkettet hat es bei mir
> nicht funktioniert. Habe jetzt leider kein Beispiel; kann mir aber auch
> keines aus den Fingern saugen.

Ich weiß nicht, was Du mit verkettet meinst.

Mehrere Bedingungen in einem if verkettet man über && oder ||, z.B.

if [ 1 -gt 3 ] && [ 0 -ne 2 ]; then ...

Statt test (bzw. [ ) aufzurufen, kannst Du auch einfach den Returncode
eines anderen Kommandos abfragen:

if grep suche datei; then ...


Zur Sinnhaftigkeit des Beispiels: Dass 'foo' ungleich 'bar' ist, ist
klar, dafür brauche ich kein Skript - es ging um die Demonstration der
Syntax. Immerhin ließ es sich ja wohl eingeben und brachte das
erwartete Ergebnis ;-)

> Entscheidend sind innerhalb der Verkettung [...]; ... ; [...]; die
> Klammern und möglicherweise auch die Anführungszeichen, also nicht für
> eine bloße Nutzung innerhalb von Shell-Skripten (als alleiniger
> Stapelverarbeitungsprozess), sondern als separater Befehl außerhalb
> des in Gang setzenden Skript-Prozesse als separater unabhängiger
> (zweiter) (Hintergrund- oder Kind-)Prozess gespeist aus einer Database:

Ja, Klammern, Semikolons usw. sind wichtig für die Shell-Syntax.
Ansonsten kann ich Dir nur bedingt folgen. Vermutlich brauchst Du
irgendwo ein eval und hast ggf. Probleme mit verschachteltem Quoting.

Nimm ein konkretes Beispiel (idealerweise etwas vereinfacht), zeig es
in de.comp.os.unix.shell und Dir wird höchstwahrscheinlich geholfen
werden.

Ein "Ergebnis aus einer Datenbankabfrage" könntest Du ja z.B. durch
ein echo mit fester Ausgabe ersetzen.

Ich lese da auch mit und bin neugierig.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Wusstet Ihr, daß ein Hellseher durchaus auch ein Schwarzseher sein kann?

[Peter Scholz]

Christian Garbs schrieb am Thu, 29 Sep 2022 15:16:55 -0000 (UTC):

> [...] und bin neugierig.

Allein, weil du neugierig bist, versuche ich dir eine Vorstellung zu
vermitteln und antworte auf dein Posting. Ansonsten sind wir jetzt
ziemlich weit vom eigentlichen Thema entfernt. Macht ja nix :-)

> [...] zeig es in de.comp.os.unix.shell [...]

Nein, es existiert kein Problem. Ich werde die Syntax bei passender
Gelegenheit einfach ausprobieren und gut ist.

> Vermutlich brauchst Du irgendwo ein eval.

Genau, am Ende werden die enthaltenen Kommandos in der Shell als
Argumente dieser Zeichen- und Befehlsverkettungen mit 'eval' ausgeführt.

> Ich weiß nicht, was Du mit verkettet meinst.

Vorher kommt etwas (zumindest $a, $b und $c) müssen deklariert worden
sein und hinterher kommt etwas ($c muss eine erkennbare Auswirkung haben
oder nicht).

Genau wie in /etc/apt/apt.conf.d/05etckeeper: Pre-Invoke und Post-Invoke

Vermutlich ist es gleichgültig, ob der Datenstrom wie bei mir aus
einer Verkettung allgemeiner Befehle besteht, der Programme startet oder
einer Verkettung spezieller etckeeper-Befehle, die einen Commit
generieren.

Vermutlich hat Joey Hess bei seiner Programm-Entwicklung auch erkannt,
dass es nur funktioniert, die If-Then-Bedingung als ganzheitlichen
Command auszuführen (durch Verpackung in geschweifte Klammern und
Hinzufügung eines Semikolon).

> Nimm ein konkretes Beispiel (idealerweise etwas vereinfacht) [...]

In dem Thread '[aptitude] Suche nach direktem Programm' hatte ich
einmal ein einfaches Skript-Beispiel am Wed, 27 Jul 2022 12:52:09 +0200
beschrieben, welches durch Christoph 'Mehdorn' Weber am Sat, 6 Aug 2022
12:25:45 +0200 kommentiert wurde.

Es wird eine Variable deklariert: Hier sollte z.B. cal eingegeben
werden. Dann erfolgt die Treffer-Ausgabe unmittelbar im Firefox.

> #!/bin/bash
> read -e -p "Bitte einen Binary-Namen eingeben und Enter-Taste drücken >" var
> firefox --new-tab"https://packages.debian.org/search?mode=exactfilename&searchon=contents&keywords=$var" &

So etwas funktioniert natürlich auch ohne Bash-Skript als einfacher
Befehl (=Befehls-Verkettung) unmittelbar in einer Bash-Shell:

> read -e -p "Bitte einen Binary-Namen eingeben und Enter-Taste drücken >" var ; firefox --new-tab "https://packages.debian.org/search?mode=exactfilename&searchon=contents&keywords=$var" &

Ich hoffe, der Sylpheed hat jetzt beim Senden nicht umgebrochen. Wen es
interessiert, mag die Befehlsverkettung (ohne Zitatzeichen '> ')
kopieren, in einen Terminal (als ganzheitlichen, einzeiligen Befehl)
einfügen und zur Stabelverarbeitung die Enter-Taste drücken.

--- --- ---

So - nun glaube ich, wir haben das Teil-Thema jetzt endgültig
totgeritten :-)

--
Gruß Peter

[Sieghard Schicktanz]

Hallo Peter Scholz,

> [...]; { "if [ $a = $b ]; then $c ; fi"; }; [...];

Sag'mal, welche Programmiersprache soll das sein, in der es sowas gibt?
Wenn ich richtig verstaden haben sollte, kam mir das vor, als ob das
ein Shell-Ausdruck sein sollte.
Der kann so aber gleich aus mehreren Gründen nicht funktionieren.
Zunächst mal - ohne Berücksichtigung der Umgebung in den "[]", ist das
ein Shell-Befehl. Die "{}" übergeben den gleich mal einer Sub-Shell,
die dann den Inhalt der Klammern als ihren Befehl ausführt.
Dieser ist dann mit den Anführungszeichen ('""') zu _einem_ Shell-
"Wort" zusammengefasst und wird von der dzf., weil als erstes Wort des
Befehls, als aufzurufendes Programm oder eingebauter Befehl
interpretiert. Es _gibt_ aber kein aufrufbares Programm oder ingebauten
Befehl mit diesem Namen, also meldet die Shell nur diesen Umstand und
tut sonst nichts.
Würde irgendwie erreicht, daß aber der Inhalt der Anführungszeichen als
Shell-Befehl verarbeitet würde (könnte ggfs. per "eval" gehen), kann
das immer noch gehörig schiefgehen, wenn die Shell-Variablen a, b und c
nicht passend gesetzt sind. "Passend" bedeutet hier
Für a und b: es müssen _einfache_ Strings _ohne_ Leerzeichen sein, die
_nicht leer_ sein dürfen. Anderenfalls ist die Syntax des Vergleichs
verletzt, bei Leerzeichen im Inhalt einer der Variablen sind zuviele
Operanden vorhanden, bei einem Leerstring zuwenige.
Für c gilt, daß die Variable einen gültigen Shell-Befehl darstellt. Der
könnte da sogar Leerzeichen enthalten, wenn .B. dem Befehls-Wort am
Anfang Parameter mitgegeben werden sollen. c="ls *" könnte z.B. evtl.
funktionieren. Ein Leerstring an dieser Stelle ist aber auch ein
Syntax- Fehler, da der Inhalt des Ausführungsteils des "if"-Statements
nicht leer sein darf.

Ich weiß, lesen, und das noch von Handbüchern und ähnlichen
Beschreibungen gilt inzwischen als unfein und ist unüblich, wenn nicht
sogar schändlich. Aber es gilöt halt immer noch "Lesen bildet", und
zwar _aus_ und nicht ein wie die sonst oft üblichen Vorgehensweisen...

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[Christian Garbs]

Mahlzeit!

Patrick Rudin <tax...@gmx.ch> wrote:
> Peter Scholz wrote:

>> Die dort verwendete Syntax:
>>
>> { "if [ $a = $b ]; then $c ; fi"; };
>
> Wiewas? Dort darf man ein einzelnes Gleichheitszeichen als
> Vergleichsoperator benutzen??

Posix Shell, da ist das so.
Ist in dem Fall auch nicht gaaaanz so schlimm, weil test(1) keine
Zuweisungen machen kann ;-)

Aber grundsätzlich finde ich das auch komisch, ich bin da durch
diverse Programmiersprachen "versaut" ;-)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Don't dream your life, live your dream.

[Christian Garbs]

Mahlzeit!

Peter Scholz <Peter_...@vodafonmail.de> wrote:

> Christian Garbs schrieb am Thu, 29 Sep 2022 15:16:55 -0000 (UTC):

>> [...] zeig es in de.comp.os.unix.shell [...]
>
> Nein, es existiert kein Problem.

Dann habe ich das 'bei mir funktioniert das mit der Befehlsverkettung
nicht' falsch verstanden.

>> Ich weiß nicht, was Du mit verkettet meinst.
>
> Vorher kommt etwas (zumindest $a, $b und $c) müssen deklariert worden
> sein und hinterher kommt etwas ($c muss eine erkennbare Auswirkung haben
> oder nicht).
>
> Genau wie in /etc/apt/apt.conf.d/05etckeeper: Pre-Invoke und Post-Invoke
>
> Vermutlich ist es gleichgültig, ob der Datenstrom wie bei mir aus
> einer Verkettung allgemeiner Befehle besteht, der Programme startet oder
> einer Verkettung spezieller etckeeper-Befehle, die einen Commit
> generieren.
>
> Vermutlich hat Joey Hess bei seiner Programm-Entwicklung auch erkannt,
> dass es nur funktioniert, die If-Then-Bedingung als ganzheitlichen
> Command auszuführen (durch Verpackung in geschweifte Klammern und
> Hinzufügung eines Semikolon).

Ich habe eine Vermutung:

Du wolltest ein if-then-Shellkonstrukt auf Pre-Invoke und Post-Invoke
verteilen? Das kann nicht gehen, weil sowohl das eine als auch das
andere getrennt durch eine Shell ausgeführt werden. Dann würden beide
Shellaufrufe mit "das ist aber kein valides Skript" abbrechen.

Daskönnte theoretisch gehen, wenn ganz apt den gesamten von
Pre-Invoke und Post-Invoke umrahmten Code am Stück an eine Shell
übergibt - aber so wird das nicht implementiert sein, alleine schon
damit Pre-Invoke keine direkte Auswirkung (Shell-Variablen,
Environment-Variablen, Shell-Funktionen usw.) auf den Rest des
ausgeführten Codes haben kann.

Ich mag nicht erahnen, ob Joey Hess diesen Fall speziell erkannt hat
(hat er apt überhaupt geschrieben?), aber wenn man solche Callbacks
defensiv und vorsichtig implementiert, wird man vermutlich
(hoffentlich?) gar nicht auf die Idee kommen, alles zusammen innerhalb
eines Shellkontextes auszuführen.

>> Nimm ein konkretes Beispiel (idealerweise etwas vereinfacht) [...]

> read -e -p "Bitte einen Binary-Namen eingeben und Enter-Taste drücken >" var ; firefox --new-tab "https://packages.debian.org/search?mode=exactfilename&searchon=contents&keywords=$var" &

Ja, da erinnere ich mich an den Thread. Ich hätte schreiben sollen "nimm
ein Beispiel, wo etwas nicht funktioniert" ;-)
Das da oben sieht ja unproblematisch aus.

> So - nun glaube ich, wir haben das Teil-Thema jetzt endgültig
> totgeritten :-)

Wenn es gar kein Problem gibt, dann ist ja auch nichts mehr zu
ergründen :)

Alles gut.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Die Basis jeder gesunden Ordnung ist ein Papierkorb. (Kurt Tucholsky)

[Peter Scholz]

Christian Garbs schrieb am Thu, 29 Sep 2022 21:28:37 -0000 (UTC):

> Ja, da erinnere ich mich an den Thread. Ich hätte schreiben sollen "nimm
> ein Beispiel, wo etwas nicht funktioniert" ;-)

Joey Hess hat Recht: der apt-Stream ist ein Daten-Strom, wie jeder
andere:

| peter@x:~$ A="abc" ; { if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi ; };
| Bedingung ist wahr.

| peter@x:~$ A="abb" ; { if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi ; };
| Bedingung ist falsch.



Du hast auch Recht: die geschweiften Klammern mit dem zusätzlichen
Semikolon sind - zumindest in der Bash-Shell - überflüssig:

| peter@x:~$ A="abc" ; if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi
| Bedingung ist wahr.

| peter@x:~$ A="abb" ; if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi
| Bedingung ist falsch.



Probieren geht über studieren :-)

--
Gruß Peter

[Peter Scholz]

Sieghard Schicktanz schrieb am Thu, 29 Sep 2022 20:46:20 +0200:

> Wenn ich richtig verstanden haben sollte, kam mir das vor, als ob das
> ein Shell-Ausdruck sein sollte.

ja

--
Gruß Peter

[Claus Reibenstein]

Christian Garbs schrieb am 29.09.2022 um 23:13:

> Patrick Rudin <tax...@gmx.ch> wrote:
>
>> Peter Scholz wrote:
>>
>>> { "if [ $a = $b ]; then $c ; fi"; };
>>
>> Wiewas? Dort darf man ein einzelnes Gleichheitszeichen als
>> Vergleichsoperator benutzen??

Man darf nicht nur, man muss sogar.

> Posix Shell, da ist das so.

Das hat nix mit Posix zu tun. Das test-Kommando - "[ ausdruck ]" ist
nichts Anderes als eine andere Schreibweise für "test ausdruck" - gab es
schon lange vor Posix und kannte schon immer "=" als Vergleichsoperator.
"==" würde nicht als solcher interpretiert und unter Umständen zu einem
Syntaxfehler führen.

> Aber grundsätzlich finde ich das auch komisch, ich bin da durch
> diverse Programmiersprachen "versaut" ;-)

Sei froh, dass Du nicht in Fortran programmieren musst. Dort müsstest Du
".EQ." schreiben ;-)

Gruß
Claus

[Claus Reibenstein]

Claus Reibenstein schrieb am 30.09.2022 um 15:38:

>> Patrick Rudin <tax...@gmx.ch> wrote:
>>
>>> Peter Scholz wrote:
>>>
>>>> { "if [ $a = $b ]; then $c ; fi"; };
>>>
>>> Wiewas? Dort darf man ein einzelnes Gleichheitszeichen als
>>> Vergleichsoperator benutzen??
>
> Man darf nicht nur, man muss sogar.

Das gilt im Übrigen nur für das externe test-Kommando. Shells haben oft
eine interne Version, die auch "==" versteht. Das gilt z.B. für bash,
nicht aber für sh.

Gruß
Claus

[Thomas Dorner]

Das test der GNU core-utilities (hier coreutils 8.30) akzeptiert es, hat
es aber nur in der info und nicht in der man-page dokumentiert.

Viele Grüße, Thomas
--
Adresse gilt nur kurzzeitig!

[Christian Garbs]

Mahlzeit!

Claus Reibenstein <crei...@gmail.com> wrote:

> Sei froh, dass Du nicht in Fortran programmieren musst. Dort müsstest Du
> ".EQ." schreiben ;-)

test(1) hat doch auch ein -eq ;-)

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Alles was man will, kostet etwas mehr als es wert ist.
(Das zweite Gesetz der Thermodynamik)

[Christian Garbs]

Mahlzeit!

Peter Scholz <Peter_...@vodafonmail.de> wrote:

> Joey Hess hat Recht: der apt-Stream ist ein Daten-Strom, wie jeder
> andere:
>
> | peter@x:~$ A="abc" ; { if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi ; };
> | Bedingung ist wahr.
>
> | peter@x:~$ A="abb" ; { if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi ; };
> | Bedingung ist falsch.

Nur zur Sicherheit:

Wenn in der /etc/apt/apt.conf.d/05etckeeper diese Zeile steht,

| DPkg::Pre-Invoke { "if [ -x /usr/bin/etckeeper ]; then etckeeper pre-install; fi"; };

dann ist ist das aus apt-Sicht erst einmal nur dieses Konstrukt:

| Konfiguration::Option1 { "konfigurierter Wert"; };

Die geschweiften Klammern und die Anführungszeichen sind _nicht_ Teil
des Shellcodes, sondern reine apt.conf-Syntax.

Wenn ich mir die anderen Konfigurationsdateien in dem Verzeichnis
angucke, scheint es Strings und Listen von Strings zu geben:

| Einfacher::String "hallo";
| Liste::von::Werten { "ich"; "bin"; "ein"; "Frosch"; };

Und wenn ich in apt.conf(5) schaue, steht es da sogar erklärt.
D'oh ;-) Immerhin hab ich es korrekt reverse-engineered.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Er nahm sie beim Händel, führte sie über die Haydn zum Bach und
verBrahmste ihr eine mit Liszt... Und nun weiß er nicht woHindemith
dem Mendelssöhnchen.

[Claus Reibenstein]

Stimmt. In der info ist es hier ebenfalls drin, und es funktioniert
auch. Also war meine Info wohl etwas veraltet. Sorry & Danke für die
Richtigstellung.

Ich nehme somit alles zurück und behaupte das Gegenteil ;-)

Gruß
Claus

[Peter Scholz]

Christian Garbs schrieb am Fri, 30 Sep 2022 21:05:25 -0000 (UTC):

> Peter Scholz <Peter_...@vodafonmail.de> wrote:
>
>> Joey Hess hat Recht: der apt-Stream ist ein Daten-Strom, wie jeder
>> andere:
>>
>> | peter@x:~$ A="abc" ; { if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi ; };
>> | Bedingung ist wahr.
>>
>> | peter@x:~$ A="abb" ; { if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi ; };
>> | Bedingung ist falsch.
>
> Nur zur Sicherheit:

Nun, die Bash-Syntax ist jetzt immerhin geklärt [✔]

Ich habe für den von mir beschriebenen UseCase daraus gelernt, dass man
nach dem 'then' kein ';' setzen darf.

Die Bash ist an dieser Stelle vielleicht nicht konsequent, aber der
Shell-Code ist in diesem Zusammenhang zugegebenermaßen einfacher und
schöner :-)

> Wenn in der /etc/apt/apt.conf.d/05etckeeper diese Zeile steht,
>
> | DPkg::Pre-Invoke { "if [ -x /usr/bin/etckeeper ]; then etckeeper pre-install; fi"; };

Bei mir stehen da zwei Zeilen, die der Konvention entsprechen:

| DPkg::Pre-Install-Pkgs {"/usr/sbin/dpkg-preconfigure --apt";};

> Und wenn ich in apt.conf(5) schaue, steht es da sogar erklärt.
> D'oh ;-) Immerhin hab ich es korrekt reverse-engineered.

Nun, damit sollte jetzt auch die Syntax der "Apt-Konfigurationssprache"
geklärt sein [✔]

Ein neuer Geltungsbereich kann mit geschweiften Klammern geöffnet
werden, ev. mit eingefügten Zeilenumbrüchen, um es leserlicher zu
gestalten. Listen können erstellt werden, indem ein Geltungsbereich
geöffnet wird und eine einzelne, von Anführungszeichen, denen ein
Schrägstrich folgt, eingeschlossene Zeichenkette eingefügt werden. Es
können mehrere Einträge eingefügt werden, jeweils getrennt durch einen
Schrägstrich. Die Anführungszeichen und abschließenden Strichpunkte
werden benötigt. Der Wert muss in einer Zeile stehen und es gibt keine
Möglichkeit Zeichenketten aneinander zu hängen.

--- --- ---

Damit werde ich jetzt zu meiner ursprünglich aufgeworfenen Frage
zurückkehren, was es bedeutet, dass sich der etckeeper in APT einfach so
reinhängt. Bevor ich die interne Verarbeitungslogik nicht verstanden
habe, halte ich den etckeeper für potenziell gefährlich.

Ich werde da in den nächsten Woche einmal an einigen Schaltern drehen,
um zu sehen, was passiert.

Was der etckeeper bis jetzt in meiner Test-Installation veranstaltet
hat, kann mich so recht nicht überzeugen.

--
Gruß Peter

[Christian Garbs]

Mahlzeit!

Peter Scholz <Peter_...@vodafonmail.de> wrote:

> Christian Garbs schrieb am Fri, 30 Sep 2022 21:05:25 -0000 (UTC):
>
>> Peter Scholz <Peter_...@vodafonmail.de> wrote:

>>> | peter@x:~$ A="abb" ; { if [ "$A" = "abc" ] ; then echo "Bedingung ist wahr." ; else echo "Bedingung ist falsch." ; fi ; };
>>> | Bedingung ist falsch.
>>
>> Nur zur Sicherheit:
>
> Nun, die Bash-Syntax ist jetzt immerhin geklärt [✔]
>
> Ich habe für den von mir beschriebenen UseCase daraus gelernt, dass man
> nach dem 'then' kein ';' setzen darf.
>
> Die Bash ist an dieser Stelle vielleicht nicht konsequent

Das ist ziemlich konsequent:

| if BEFEHL; then BEFEHL; else BEFEHL; fi

Jeder BEFEHL (da könnten auch jeweils mehrere stehen) wird mit einem
Semikolon (oder Zeilenumbruch) beendet.

Das gesamte if/then/else-Konstrukt ebenfalls, das ist quasi auch ein
BEFEHL.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Winzer 1: Ich probier mal den Wein.
Winzer 2: Bist Du verrückt?
Winzer 1: Egal, ich riskier' mal ein Auge!

[Martin Vaeth]

Christian Garbs <mi...@cgarbs.de> schrieb:

>>>
>>> Nur zur Sicherheit:
>>
>> Nun, die Bash-Syntax ist jetzt immerhin geklärt [✔]

Diesbezüglich verhält sich die Bash gemäß POSIX.

>> Ich habe für den von mir beschriebenen UseCase daraus gelernt, dass
>> man nach dem 'then' kein ';' setzen darf.
>>
>> Die Bash ist an dieser Stelle vielleicht nicht konsequent
>
> Das ist ziemlich konsequent:

Nein, ist es nicht. Wie meist bei POSIX ist es nur historisch
bedingtes Kraut-und-Rüben.

>| if BEFEHL; then BEFEHL; else BEFEHL; fi
>
> Jeder BEFEHL (da könnten auch jeweils mehrere stehen) wird mit einem
> Semikolon (oder Zeilenumbruch) beendet.

Das erklärt nicht, weshalb woanders - z.B. nach dem "then"
(worum es hier ging; für "if" und "else" gilt aber Ähnliches)
*kein* Semikolon stehen darf, wohl aber ein Zeilenumbruch.
Und bei "for" muss das Semikolon vor dem "do" stehen, wo gar kein
BEFEHL endet.

Aber es kommt noch dicker: Bei einigen Fällen (im Zusammenhang
mit Umleitungen, Details habe ich vergessen; vielleicht gilt es
auch nur im Zusammenhang mit "for"), *muss* das Semikolon wiederum
durch einen Zeilenumbruch ersetzen werden.

Das folgende ist meine Interpretation für den Anachronismus:
Historisch war die Idee wohl die, dass man prinzipiell so schreiben
*muss*:

if U
then V
elif W
then X
else Y
fi

Dabei kann (wie sonst in der Bourne-shell oft üblich) das Zeilenende
*meist* auch durch ein ";" ersetzt werden (wie gesagt: von dem *meist*
gibt es in bestimmten Zusammenhängen hier Ausnahmen).
Und weil U, V, W, X, Y oft aus mehreren Teilen bestehen, sollte man
vermutlich auch so setzen können

if
U1
U2
then
V1
V2
elif
W1
W2
then
X1
X2
else
Y1
Y2
fi

Insbesondere darf man also nach "if", "then", usw. redundante
Zeilenumbrüche benutzen. Man hat aber "vergessen", dass es
konsequenterweise auch erlaubt sein müsste, diese durch
redundante ";" zu ersetzen.

[Peter Scholz]

Martin Vaeth schrieb am Sun, 2 Oct 2022 20:51:39 -0000 (UTC):

[ if BEFEHL; then BEFEHL; else BEFEHL; fi ]

Vielen Dank, dass du dir die Mühe gemacht hast, das Problem in
allgemeiner Form in dieser Weise geradezu lehrbuchmäßig und
hundertprozentig auf den Punkt brillant aus zu formulieren.

Alle Linux-User müssen mit diesen Ungereimtheiten leben.

--
Gruß Peter

[Peter Scholz]

Christian Garbs schrieb am Mon, 26 Sep 2022 18:20:46 -0000 (UTC):

> Böh :-(
>
> Kann es sein, dass sowas wie "Dpkg::Options::=--force-confnew" von ucf
> auch ignoriert wird? Ich hatte einzelne Pakete, die trotz "nimm alle
> neuen Conffiles" nachgefragt haben. Das würde das erklären.

ja, wird von ucf ignoriert: soeben getestet

--
Gruß Peter

[Peter Scholz]

Peter Scholz schrieb am Tue, 27 Sep 2022 18:49:48 +0200:

> Christian Garbs schrieb am Tue, 27 Sep 2022 07:25:45 -0000 (UTC):

>> Das klingt wie --force-confnew/confold, aber da steht nicht explizit
>> dabei, ob ucf dann die Datei *.ucf-dist bzw. *.ucf-new weiterhin
>> angelegt.
>>
>> Hast Du eine Idee, wie ich in einem laufenden System am einfachsten
>> einen ucf-Prompt provozieren könnte, um das auszuprobieren?
>
> ev. in der /etc/ucf.conf konfigurieren

ja, /etc/ucf.conf funktioniert: soeben getestet

Prompt = vorkonfiguriert und Standard
kein Prompt = conf_force_conffold=YES

--
Gruß Peter

[Peter Scholz]

Testergebnis soeben in alle Systeme eingepflegt [✔]

Skript für Debian-Release-Wechsel optimiert.

Ergebnis: Optimierung und Beschleunigung der Abläufe.
Keine dpkg-Prompts.

--
Gruß Peter

[Peter Scholz]

Testergebnis soeben in alle Systeme eingepflegt [✔]

a) Skript für Debian-Release-Wechsel optimiert.
b) Skript für tägliche System-Updates optimiert.

Ergebnis: Optimierung und Beschleunigung der Abläufe.

Keine ucf-Prompts.

UseCases für a):
Debian-Release-Wechsel:
1) von Stable nach Testing
2) von Stable nach Unstable
3) von Testing nach Unstable
4) von OldStable nach Stable

UseCases für b)
tägliche System-Updates für:
1) Stable
2) Testing
3) Unstable
jeweils mit:
1) automatisches Notitying nach jedem Hochfahren
(inspiriert durch: Manjaro, MxLinux, SparkyLinux)
2) händisch zu startendes Update
oder alternativ
3) automatisches Update vor jedem Herunterfahren
(inspiriert durch: MsWindows, DebianWayland)
jeweils einschließlich folgender Bereinigungen:
1) automatisches Autoremove, falls notwendig
2) automatisches Löschen weiterer Konfigurationsrückstände,
falls notwendig
3) fix-broken, falls notwendig
4) apt clean
5) rm -rf /var/lib/apt/lists/*
6) Bereinigung Ram-Cache
7) Bereinigung ZRam-Cache

--
Gruß Peter

[Peter Scholz]

Peter Scholz schrieb am Tue, 4 Oct 2022 09:49:21 +0200:

> Testergebnis soeben in alle Systeme eingepflegt [✔]
>
> a) Skript für Debian-Release-Wechsel optimiert.
> b) Skript für tägliche System-Updates optimiert.

Habe mir einen find-Befehl gebaut, der mir meine von mir geänderten
Konfigurationen in /etc (und nur diese) aufspürt und anzeigt. cruft ist
nicht einmal für das finden abweichender Paketversionen in Debian
erforderlich (u.a. Thema dieses Threads). Nicht nur im Falle der
Migration oder Portierung von Debian sind diese punktgenauen
Informationen aber wichtig.

Anhand der mir so erzeugten Liste(n) arbeite ich jetzt auf allen meinen
Systemen meine geänderten etc-Konfigurationen ab. Ich vergleiche, was
sich da im Laufe der Jahre angesammelt hat, mit den neuen Standards
(u.a. neue Features) der einzelnen Pakete. Vor dem Hintergrund dessen,
was ich jetzt aus meinen Tests gelernt habe, verschlanke ich die etc-
Konfigurationen und lösche von mir jetzt als überflüssig Erkanntes.

Gleichzeitig sehe ich, wie sich etckeeper dabei in meiner
Testkonfiguration verhält. Ich habe mir diesen find-Befehl bereits in
alle meine Systeme eingebaut und werde mich nach Abschluss dieser
Arbeiten und Tests wahrscheinlich gegen etckeeper entscheiden.

Etckeeper als Konfiguration-Management-System ist für mein kleines
Heimnetzwerk einfach overkill: zu viele Daten, zu unübersichtlich
aufbereitet, Konflikte mit meinen sonstigen (teilweise automatisch
ablaufenden) apt-Skripten.

--
Gruß Peter

[Christian Garbs]

Mahlzeit!

Marc Haber <mh+usene...@zugschl.us> wrote:

> Christian Garbs <mi...@cgarbs.de> wrote:

>>Hast Du eine Idee, wie ich in einem laufenden System am einfachsten
>>einen ucf-Prompt provozieren könnte, um das auszuprobieren?
>>

>>Vorab eine Datei nach /etc schreiben und dann erstmalig ein Paket mit
>>ucf-Support installieren, das dann einen Konflikt erkennt, sollte
>>funktionieren, klingt aber etwas umständlich.
>
> ucf ist ein langweiliges binary, das kann man einfach von der
> Kommandozeile aufrufen. Beispiele müssten in der Manpage sein.

Danke, das ist zu einfach :) Mit --state-dir kann ich das auch
losgelöst von der echten Paketverwaltung machen (nur besteht ucf
weiterhin darauf, als root zu laufen).

Ich kam jetzt endlich mal dazu, das zu testen:

- UCF_FORCE_CONFFOLD verhält sich wie erwartet und erhofft: Das
bestehende conffile wird nicht angerührt und das neue mit der Endung
.ucf-dist daneben gelegt.

- UCF_FORCE_CONFFNEW macht leider nur das, was der Name sagt: Das
bestehende conffile wird mit dem neuen überschrieben. Es wird dabei
_kein_ .ucf-old angelegt, die alte Konfiguration ist dann einfach
weg.

Damit lässt sich aus dem interaktiven Menü nur die Auswahl
"keep the local version currently installed" über UCF_FORCE_CONFFNEW
automatisieren.

Die manuelle Auswahl "install the package maintainer's version" legt
ein Backup als .ucf-old an, UCF_FORCE_CONFFNEW macht genau das nicht.

Schade.

/An dieser Stelle habe ich überlegt, ob das einen Bug wert ist und in
die Bugliste geschaut./

Sieheda: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925375

Wenn man zusätzlich zu UCF_FORCE_CONFFNEW noch RETAIN_OLD setzt, wird
eine .ucf-old angelegt. Steht nur leider nicht in der Manpage :/

Aber damit komme ich für meinen Anwendungsfall klar.

Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de

Sometime when you least expect it, Love will tap you on the shoulder...
and ask you to move out of the way because it still isn't your turn.
-- N.V. Plyter

[Marc Haber]

Christian Garbs <mi...@cgarbs.de> wrote:
>Marc Haber <mh+usene...@zugschl.us> wrote:
>> Christian Garbs <mi...@cgarbs.de> wrote:
>>>Hast Du eine Idee, wie ich in einem laufenden System am einfachsten
>>>einen ucf-Prompt provozieren könnte, um das auszuprobieren?
>>>
>>>Vorab eine Datei nach /etc schreiben und dann erstmalig ein Paket mit
>>>ucf-Support installieren, das dann einen Konflikt erkennt, sollte
>>>funktionieren, klingt aber etwas umständlich.
>>
>> ucf ist ein langweiliges binary, das kann man einfach von der
>> Kommandozeile aufrufen. Beispiele müssten in der Manpage sein.
>
>Danke, das ist zu einfach :) Mit --state-dir kann ich das auch
>losgelöst von der echten Paketverwaltung machen (nur besteht ucf
>weiterhin darauf, als root zu laufen).

Genau, zumindest wenn man ucf nicht im no-action-mode laufen lässt.
Auch ucf ist leider nicht so richtig fertig.

>Ich kam jetzt endlich mal dazu, das zu testen:
>
>- UCF_FORCE_CONFFOLD verhält sich wie erwartet und erhofft: Das
> bestehende conffile wird nicht angerührt und das neue mit der Endung
> .ucf-dist daneben gelegt.
>
>- UCF_FORCE_CONFFNEW macht leider nur das, was der Name sagt: Das
> bestehende conffile wird mit dem neuen überschrieben. Es wird dabei
> _kein_ .ucf-old angelegt, die alte Konfiguration ist dann einfach
> weg.

Oh, ucf-old erwarte ich aber eigentlich. Da würde ich einen Bugreport
machen. Die Manualpage sagt dass es diese Kopien "optional" anlegt, es
gibt aber keine Option um das einzuschalten. Das ist in der Tat
nichtmal eindeutig dokumentiert.

>Damit lässt sich aus dem interaktiven Menü nur die Auswahl
>"keep the local version currently installed" über UCF_FORCE_CONFFNEW
>automatisieren.
>
>Die manuelle Auswahl "install the package maintainer's version" legt
>ein Backup als .ucf-old an, UCF_FORCE_CONFFNEW macht genau das nicht.

Dass sich die Einstellung über das Environment anders verhält als das
Menü halte ich für einen bug.

>/An dieser Stelle habe ich überlegt, ob das einen Bug wert ist und in
>die Bugliste geschaut./
>
>Sieheda: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925375
>
>Wenn man zusätzlich zu UCF_FORCE_CONFFNEW noch RETAIN_OLD setzt, wird
>eine .ucf-old angelegt.

Und Du bist mir wieder einen Schritt voraus.

> Steht nur leider nicht in der Manpage :/

Das ist ein Bug. Bitte einreichen.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834