Unbekannte Ungereimtheiten beim Upgrade Stretch->Buster?

[dirk11]

Frohe Ostern alle miteinander!

Ich denke, es ist an der Zeit, dass ich meine Rechner jetzt mal von Debian 9 Stretch auf 10 Buster upgrade.
Das werden hier im Forum sicherlich schon eine Menge Leute vor mir gemacht haben.
Ich habe mir natürlich die Release Notes durchgelesen. Da das System auf meinem Heimserver bis auf mediatomb (welchen ich vorher deinstallieren kann) reines Stretch ist, erwarte ich diesbezüglich eigentlich keine großen Fallstricke. Außerdem läuft alles mit Standard-Sachen, d.h. ich nutze keinen selbstgebauten Kernel oder ähnliches. Allerdings, auch das muss ich erwähnen, ich nutze noch sysvinit-core und muss das auch weiterhin nutzen (sprich, systemd ist zwar vorhanden, aber gebootet wird mit "klassischem" sysvinit).

Auch muss ich erwähnen, dass mein System mit LUKS vollverschlüsselt ist und ich habe vor, das upgrade (wie beim letzten Mal auch) via ssh und screen durchzuführen, was von Jessie auf Stretch tadellos funktioniert hat (Bildschirm und Tastatur sind aber vorhanden, ich habe also im Notfall auch direkten physischen Zugriff).

Die Dinge, die ich bisher festgestellt habe, welche es zu beachten gilt für mich, sind wohl die Pfad-Änderung von /bin /sbin /lib nach /usr/*, der kann ich IMHO nach dem Upgrade Beachtung schenken und dann irgendwann auch usrmerge durchführen.
Außerdem muss ich mein System wohl sinnvollerweise vor dem Upgrade von eth0 nach enp5s0 migrieren.

Gibt es noch andere, mir nicht aufgefallene (d.h. die nicht in den Release-Notes stehen) Fallstricke, auf welche man achten sollte, oder ist das genug der Vorsorge?

LG

Dirk
P.S.: und gibt es vielleicht noch andere Quellen, die man sinnvollerweise vorher durchliest?

[KP97]

Aufruf von su
und
su -

Zum Unterschied gibt es hier im Forum mehrere Threads.
Der Netzwerkname wird wohl automatisch vom Kernel geändert, da braucht man vorher nichts machen, kann man aber.

[reox]

Außerdem muss ich mein System wohl sinnvollerweise vor dem Upgrade von eth0 nach enp5s0 migrieren.

Das brauchst du IMO nicht machen. Die alten Namen bleiben bestehen - das is ja im Grunde nur eine udev rule die da geschrieben wird.

Code: Alles auswählen

cat /etc/udev/rules.d/70-persistent-net.rules

sollte dir da weiterhelfen.

Ansonsten hatte ich beim Upgrade keine gröberen Probleme, nur ein paar Services haben zB neue Konfiguration oder verhalten sich etwas anders. Dovecot hat da das Verhalten geändert wie CA Certs mit ausgeliefert werden - bzw sie haben es jetzt nach der Dokumentation gemacht (also ich hatte es falsch konfiguriert )
Daher lohnt es sich auch die changelogs der Services durchzulesen, ob sich für dich was ändert.

[dirk11]

Aufruf von su
und
su -

Was heisst das? Der Unterschied ist mir so leidlich bekannt. Aber was ändert sich?

Das brauchst du IMO nicht machen. Die alten Namen bleiben bestehen - das is ja im Grunde nur eine udev rule die da geschrieben wird.

Code: Alles auswählen

cat /etc/udev/rules.d/70-persistent-net.rules

sollte dir da weiterhelfen.

Ja, die existiert und da steht eth0 drin. Ist sowieso die einzige physikalische Netzwerkschnittstell darin (nebst virtuellen tun-devices). Wenn ich das nicht zwingend umarbeiten muss, würde ich das in der Tat gerne lassen, aber dann muss ich dem System wohl mitteilen, daß es das auch so lassen soll, wenn ich die release-notes richtig verstanden habe. Über einen Kernel-Parameter.

Ansonsten hatte ich beim Upgrade keine gröberen Probleme, nur ein paar Services haben zB neue Konfiguration oder verhalten sich etwas anders. Dovecot hat da das Verhalten geändert wie CA Certs mit ausgeliefert werden - bzw sie haben es jetzt nach der Dokumentation gemacht (also ich hatte es falsch konfiguriert )
Daher lohnt es sich auch die changelogs der Services durchzulesen, ob sich für dich was ändert.

Ok, danke für den Hinweis!

[reox]

Wenn ich das nicht zwingend umarbeiten muss, würde ich das in der Tat gerne lassen, aber dann muss ich dem System wohl mitteilen, daß es das auch so lassen soll, wenn ich die release-notes richtig verstanden habe. Über einen Kernel-Parameter.

Das mit dem Kernel Parameter ist nur erforderlich, wenn du möchtest, dass neue Karten mit den alten Namen erkannt werden.
Alles was schon da war, wird auch weiterhin so heißen.
Heißt aber, wenn du den Parameter nicht setzt und dir noch eine Karte einbaust, die noch nicht in den udev rules erfasst wurde, dann heißt die jetzt enp... und nicht mehr eth.

[fischig]

Soweit ich weiß, musst du dem bootloader nur den Kernel-Parameter netifnames=0 mitgeben, damit die Netzwerkkarten nicht umbenannt werden sollen. Dann macht udev das auch nicht. Aber das ist, soweit ich sehe, eigentlich nichts Neues und seit dem Wechsel von wheezy auf Jessie so der Fall.

[dirk11]

Das mit dem Kernel Parameter ist nur erforderlich, wenn du möchtest, dass neue Karten mit den alten Namen erkannt werden.
Alles was schon da war, wird auch weiterhin so heißen.

Ok, danke. Da kommt sicherlich keine zusätzliche NIC in der nächsten Zeit rein, also kann ich mir diesen Schritt sparen.
Das mit der Änderung bei su habe ich dennoch nicht verstanden - was ändert sich da? Ich nutze immer schon "su -" und habe mir darauf einen Alias von "su" in profile und bash.bashrc gelegt - kann/muss ich den jetzt entfernen?

[reox]

Das mit der Änderung bei su habe ich dennoch nicht verstanden - was ändert sich da? Ich nutze immer schon "su -" und habe mir darauf einen Alias von "su" in profile und bash.bashrc gelegt - kann/muss ich den jetzt entfernen?

schau mal in die man page

Code: Alles auswählen

       -, -l, --login
              Start the shell as a login shell with an environment similar to a real login:

                 o      clears all the environment variables except TERM and variables specified by --whitelist-environment

                 o      initializes the environment variables HOME, SHELL, USER, LOGNAME, and PATH

                 o      changes to the target user's home directory

                 o      sets argv[0] of the shell to '-' in order to make the shell a login shell

früher war das normale su gleich wie su -. Das wurde jetzt geändert. dH wenn du nur su eingibst, hast du den PATH vom vorherigen user und nicht den richtigen vom neuen user.

[dirk11]

früher war das normale su gleich wie su -. Das wurde jetzt geändert. dH wenn du nur su eingibst, hast du den PATH vom vorherigen user und nicht den richtigen vom neuen user.

Das kann nicht sein, dann hätte es ja kein su - gegeben.

[reox]

früher war das normale su gleich wie su -. Das wurde jetzt geändert. dH wenn du nur su eingibst, hast du den PATH vom vorherigen user und nicht den richtigen vom neuen user.

Das kann nicht sein, dann hätte es ja kein su - gegeben.

Ja ok du hast recht - es wurde ein anderes su verwendet, das ein bisserl eine andere funktionalität hatte:

Code: Alles auswählen

The su command in buster is provided by the util-linux source package, instead of the shadow source package, and no longer alters the PATH variable by default. This means that after doing su, your PATH may not contain directories like /sbin, and many system administration commands will fail. There are several workarounds:

    Use su - instead; this launches a login shell, which forces PATH to be changed, but also changes everything else including the working directory.

    Use sudo instead. sudo still runs commands with an altered PATH variable.

        To get a regular root shell with the correct PATH, you may use sudo -s.

        To get a login shell as root (equivalent to su -), you may use sudo -i. 

    Put ALWAYS_SET_PATH yes in /etc/login.defs to get an approximation of the old behavior. This is documented in su(1) but not in login.defs(5). It may also cause a harmless error message to appear in some situations (see 905564).

    Put the system administration directories (/sbin, /usr/sbin, /usr/local/sbin) in your regular account's PATH (see EnvironmentVariables for help with this). 

Siehe https://wiki.debian.org/NewInBuster

[dirk11]

Danke für den Link mit den zusätzlichen Infos! Bedeutet auch, dass sich im Grunde gar nichts für mich ändert und die ursprügnliche Info bzgl. su falsch/unvollständig und so nicht hilfreich war.

[reox]

Danke für den Link mit den zusätzlichen Infos! Bedeutet auch, dass sich im Grunde gar nichts für mich ändert und die ursprügnliche Info bzgl. su falsch/unvollständig und so nicht hilfreich war.

Es ändert an der Kernaussage nichts. wenn du früher immer su verwendet hast, musst du jetzt su - verwenden, um zum gleichen Ergebnis zu kommen.
Also besser mal alle Scripte durchsehen, ob da nicht irgendwo ein su ohne - drin steht.
Wenn du eh schon immer su - verwendet hast, dann ist es dir natürlich egal.

[dirk11]

Eben. Ich schrieb ja schon, daß ich einen Alias von su auf su - gesetzt habe, u.A. deshalb, weil ich schon früher keinen Sinn in su gesehen habe.