Hallo, nach einem tumbleweed upgrade gestern startete der Rechner nicht korrekt. Es gab Fehlermeldungen von systemd, dass mehrere Dienste nicht gestartet werden konnten. Der Stert von X blieb hängen. Für Alle die dieses Problem evtl auch haben: Erst versuchte ich die Dienste manuell zu starten, was fehlschlug. Dann startete ich zypper dup nochmal, das brach mit einem segfault ab. Mit strace fand ich dann die Ursache: /etc/services war nicht da. Lösung: Habe die Datei aus dem backup zurück kopiert und der Rechner läuft wieder. Nun hab ich noch ein bischen gesucht... -----8<------- rpmlocate /etc/services Searching for /etc/services in rpm db... netcfg-11.6-5.1: /usr/etc/services -----8<------- Tatsächlich, /usr/etc gibt es und es sind dort jetzt einige Dateien zu finden, die vorher nicht da waren: -----8<------- burdon:/usr/etc # ll insgesamt 912 drwxr-xr-x 2 root root 4096 6. Dez 18:43 default -rw-r--r-- 1 root root 605 30. Jan 09:45 ethers -rw-r--r-- 1 root root 1410 24. Dez 01:21 lesskey -rw-r--r-- 1 root root 589 24. Dez 01:21 lesskey.bin -rw-r--r-- 1 root root 9966 25. Jan 13:30 login.defs -rw-r--r-- 1 root root 225 30. Jan 09:45 networks drwxr-xr-x 2 root root 4096 27. Jan 12:14 pam.d -rw-r--r-- 1 root root 23259 30. Jan 09:45 protocols -rw-r--r-- 1 root root 161 6. Nov 14:41 securetty -rw-r--r-- 1 root root 868252 30. Jan 09:45 services burdon:/usr/etc # burdon:/media/Platinum500G/sysbackup/usr/etc # ll insgesamt 32 drwxr-xr-x 2 root root 4096 6. Dez 18:43 default -rw-r--r-- 1 root root 1410 24. Dez 01:21 lesskey -rw-r--r-- 1 root root 589 24. Dez 01:21 lesskey.bin -rw-r--r-- 1 root root 9966 25. Jan 13:30 login.defs drwxr-xr-x 2 root root 4096 27. Jan 12:14 pam.d -rw-r--r-- 1 root root 161 6. Nov 14:41 securetty -----8<------- Hat sich da was geändert? Oder ist das ein Fehler? Die services war immer schon in /etc und offensichtlich wird sie dort auch erwartet. Im Netz gibt es (noch) nichts dazu -- Gruss Bernd -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 07.02.20 um 08:51 schrieb Bernd Obermayr:
Hallo, nach einem tumbleweed upgrade gestern startete der Rechner nicht korrekt. Es gab Fehlermeldungen von systemd, dass mehrere Dienste nicht gestartet werden konnten. Der Stert von X blieb hängen.
Für Alle die dieses Problem evtl auch haben:
Erst versuchte ich die Dienste manuell zu starten, was fehlschlug. Dann startete ich zypper dup nochmal, das brach mit einem segfault ab.
Mit strace fand ich dann die Ursache: /etc/services war nicht da.
Lösung: Habe die Datei aus dem backup zurück kopiert und der Rechner läuft wieder.
Nun hab ich noch ein bischen gesucht... -----8<------- rpmlocate /etc/services Searching for /etc/services in rpm db...
netcfg-11.6-5.1: /usr/etc/services -----8<-------
Tatsächlich, /usr/etc gibt es und es sind dort jetzt einige Dateien zu finden, die vorher nicht da waren:
-----8<------- burdon:/usr/etc # ll insgesamt 912 drwxr-xr-x 2 root root 4096 6. Dez 18:43 default -rw-r--r-- 1 root root 605 30. Jan 09:45 ethers -rw-r--r-- 1 root root 1410 24. Dez 01:21 lesskey -rw-r--r-- 1 root root 589 24. Dez 01:21 lesskey.bin -rw-r--r-- 1 root root 9966 25. Jan 13:30 login.defs -rw-r--r-- 1 root root 225 30. Jan 09:45 networks drwxr-xr-x 2 root root 4096 27. Jan 12:14 pam.d -rw-r--r-- 1 root root 23259 30. Jan 09:45 protocols -rw-r--r-- 1 root root 161 6. Nov 14:41 securetty -rw-r--r-- 1 root root 868252 30. Jan 09:45 services burdon:/usr/etc # burdon:/media/Platinum500G/sysbackup/usr/etc # ll insgesamt 32 drwxr-xr-x 2 root root 4096 6. Dez 18:43 default -rw-r--r-- 1 root root 1410 24. Dez 01:21 lesskey -rw-r--r-- 1 root root 589 24. Dez 01:21 lesskey.bin -rw-r--r-- 1 root root 9966 25. Jan 13:30 login.defs drwxr-xr-x 2 root root 4096 27. Jan 12:14 pam.d -rw-r--r-- 1 root root 161 6. Nov 14:41 securetty -----8<-------
Hat sich da was geändert? Oder ist das ein Fehler?
Die services war immer schon in /etc und offensichtlich wird sie dort auch erwartet.
Im Netz gibt es (noch) nichts dazu
OK, hab doch noch was gefunden... dort wird das grad diskutiert: <https://lists.opensuse.org/opensuse-factory/2020-02/msg00057.html> -- Gruss Bernd -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Bernd, hallo zusammen, Am Freitag, 7. Februar 2020, 09:03:16 CET schrieb Bernd Obermayr:
OK, hab doch noch was gefunden... dort wird das grad diskutiert: <https://lists.opensuse.org/opensuse-factory/2020-02/msg00057.html>
Ich halte AppArmor für unschuldig ;-) - allerdings nur, wenn Du die aktuellen Profile und abstractions im Einsatz hast. Guck also mal in /etc/apparmor.d/ und dessen Unterverzeichnissen nach *.rpmnew-Dateien. Falls es welche gibt, ersetzte die eigentliche Datei mit der *.rpmnew (z. B. abstractions/nameservice.rpmnew -> abstractions/nameservice). Falls Du vorher etwas ergänzt hattest, darf das natürlich wieder rein. Danach "rcapparmor reload" aufrufen. Ein weiterer Kandidat ist /etc/nsswitch.conf.rpmnew - falls es die gibt, bitte zu /etc/nsswitch übernehmen. Wichtig sind hier insbesondere die "usrfiles"-Teile, weil ohne die nicht in /usr/etc/ nachgesehen wird. Generell ist ein Blick auf *.rpmnew und *.rpmsave nie verkehrt. Mit rpmconfigcheck bekommst Du eine Liste. Gruß Christian Boltz -- <sarnold> that in itself is actually intersting <sarnold> cboltz touches something and it -doesn't- break [from #apparmor] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 07.02.20 um 14:16 schrieb Christian Boltz:
Hallo Bernd, hallo zusammen,
Am Freitag, 7. Februar 2020, 09:03:16 CET schrieb Bernd Obermayr:
OK, hab doch noch was gefunden... dort wird das grad diskutiert: <https://lists.opensuse.org/opensuse-factory/2020-02/msg00057.html>
Ich halte AppArmor für unschuldig ;-) - allerdings nur, wenn Du die aktuellen Profile und abstractions im Einsatz hast. Guck also mal in /etc/apparmor.d/ und dessen Unterverzeichnissen nach *.rpmnew-Dateien. Falls es welche gibt, ersetzte die eigentliche Datei mit der *.rpmnew (z. B. abstractions/nameservice.rpmnew -> abstractions/nameservice). Falls Du vorher etwas ergänzt hattest, darf das natürlich wieder rein. Danach "rcapparmor reload" aufrufen.
Ein weiterer Kandidat ist /etc/nsswitch.conf.rpmnew - falls es die gibt, bitte zu /etc/nsswitch übernehmen. Wichtig sind hier insbesondere die "usrfiles"-Teile, weil ohne die nicht in /usr/etc/ nachgesehen wird.
Generell ist ein Blick auf *.rpmnew und *.rpmsave nie verkehrt. Mit rpmconfigcheck bekommst Du eine Liste.
Gruß
Christian Boltz
Hi, danke. apparmor verwende ich garnicht :) Ich habe schon lange nicht mehr die rpmnew files gecheckt :)) Sollte ich vielleicht mal wieder tun. So krass wie gestern hat das aber auch noch nie zugeschlagen. Nachdem auch andere Netzdienste (autofs,nfs etc) nicht funktionierten hab ich hilfsweise alle files aus /usr/etc nach /etc verlinkt Das half. Mit der neuen nsswitch.conf kann ich diese links wieder löschen? Welcher tiefere Sinn steckt denn hinter der Verlagerung nach /usr/etc? Jedenfalls danke nochmal für den Tip. -- Gruss Bernd -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Bernd, hallo zusammen, Am Freitag, 7. Februar 2020, 14:45:29 CET schrieb Bernd Obermayr:
apparmor verwende ich garnicht :)
Solange Du es nicht bewusst abgeschaltet hast: doch ;-) (ist standardmäßig aktiv, aber ich bemühe mich, es nerv-frei zu halten)
Ich habe schon lange nicht mehr die rpmnew files gecheckt :)) Sollte ich vielleicht mal wieder tun. So krass wie gestern hat das aber auch noch nie zugeschlagen.
Nachdem auch andere Netzdienste (autofs,nfs etc) nicht funktionierten hab ich hilfsweise alle files aus /usr/etc nach /etc verlinkt Das half.
Das spricht dann übrigens dafür, dass AppArmor unschuldig ist - das guckt immer aufs Ziel eines Symlinks.
Mit der neuen nsswitch.conf kann ich diese links wieder löschen?
Richtig. Falls wider Erwarten doch irgendwas streikt, ist das ein Bug und Bugzilla freut sich über etwas Futter ;-)
Welcher tiefere Sinn steckt denn hinter der Verlagerung nach /usr/etc?
Derzeit legen viele Pakete ihre (Default-)Config in /etc/ ab, und der Admin kann sie ändern. Das führt dann dazu, dass sich 10 geänderte Dateien zwischen 1000 unveränderten verstecken, und - noch schlimmer - dass in einer großen Datei eine einzige geänderte Zeile steckt und bei einem Update eine *.rpmnew oder *.rpmsave produziert. (Viel Spaß beim Mergen ;-) Daher wird die Default-Config nach und nach nach /usr/etc/ verschoben, sodass /etc/ nur noch Dateien enthält, die tatsächlich vom Admin angefasst / angelegt wurden. Das Grundprinzip ist (vereinfacht gesagt) ähnlich wie bei systemd-Dateien - die liegen in /usr/lib/systemd/, und wenn man etwas ändern will, kopiert man sie nach /etc/systemd/ und ändert sie da. Es gibt noch ein paar zusätzliche Varianten, dazu und für weitere Details guck bitte mal auf https://en.opensuse.org/openSUSE:Packaging_UsrEtc Die Umstellung auf /usr/etc/ ist leider manchmal etwas schmerzhaft, aber langfristig macht es die Sache IMHO angenehmer ;-) Gruß Christian Boltz -- "Does your computer ever crash?" "Oh definitely, believe me. We want to make a tool that we can use ourselves and we know from our own use we can make it a lot better and a lot more reliable." [Bill Gates in a BBC interview] -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 08.02.20 um 17:04 schrieb Christian Boltz:
Hallo Bernd, hallo zusammen,
Am Freitag, 7. Februar 2020, 14:45:29 CET schrieb Bernd Obermayr:
apparmor verwende ich garnicht :)
Solange Du es nicht bewusst abgeschaltet hast: doch ;-) (ist standardmäßig aktiv, aber ich bemühe mich, es nerv-frei zu halten)
Hab ich schon vor langer Zeit gelöscht :) Ist ja "nur" mein Privatrechner.
Ich habe schon lange nicht mehr die rpmnew files gecheckt :)) Sollte ich vielleicht mal wieder tun. So krass wie gestern hat das aber auch noch nie zugeschlagen.
Nachdem auch andere Netzdienste (autofs,nfs etc) nicht funktionierten hab ich hilfsweise alle files aus /usr/etc nach /etc verlinkt Das half.
Das spricht dann übrigens dafür, dass AppArmor unschuldig ist - das guckt immer aufs Ziel eines Symlinks.
Mit der neuen nsswitch.conf kann ich diese links wieder löschen?
Richtig.
Schon erledigt :)
Falls wider Erwarten doch irgendwas streikt, ist das ein Bug und Bugzilla freut sich über etwas Futter ;-)
Welcher tiefere Sinn steckt denn hinter der Verlagerung nach /usr/etc?
Derzeit legen viele Pakete ihre (Default-)Config in /etc/ ab, und der Admin kann sie ändern. Das führt dann dazu, dass sich 10 geänderte Dateien zwischen 1000 unveränderten verstecken, und - noch schlimmer - dass in einer großen Datei eine einzige geänderte Zeile steckt und bei einem Update eine *.rpmnew oder *.rpmsave produziert. (Viel Spaß beim Mergen ;-)
Hab ich gestern gemacht. Erstmal war ich etwas geschockt, es waren an die 60 Dateien. Die meisten waren aber uralt, die älteste von 2001 :)) Ich habe halt immer ein upgrade gemacht, /etc aus dem Backup kopiert und angepasst...
Daher wird die Default-Config nach und nach nach /usr/etc/ verschoben, sodass /etc/ nur noch Dateien enthält, die tatsächlich vom Admin angefasst / angelegt wurden. Das Grundprinzip ist (vereinfacht gesagt) ähnlich wie bei systemd-Dateien - die liegen in /usr/lib/systemd/, und wenn man etwas ändern will, kopiert man sie nach /etc/systemd/ und ändert sie da. Es gibt noch ein paar zusätzliche Varianten, dazu und für weitere Details guck bitte mal auf https://en.opensuse.org/openSUSE:Packaging_UsrEtc
Ja, ist nachvollziehbar. Gut zu wissen. Ich hab halt davon überhaupt nix mitgekriegt :)
Die Umstellung auf /usr/etc/ ist leider manchmal etwas schmerzhaft, aber langfristig macht es die Sache IMHO angenehmer ;-)
Ja, in diesem Fall war schon krass. Evtl. wäre es hilfreich, wenn die nsswitch.conf nach nsswitch.conf.rpmsave kopiert und durch die neue ersetzt würde. Dann wäre der Ausfall meistens vermutlich nicht so heftig. Wieder was gelernt.. Danke nochmal.
Gruß
Christian Boltz
-- Gruss Bernd -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 07.02.20 um 14:16 schrieb Christian Boltz:
Hallo Bernd, hallo zusammen,
Am Freitag, 7. Februar 2020, 09:03:16 CET schrieb Bernd Obermayr:
OK, hab doch noch was gefunden... dort wird das grad diskutiert: <https://lists.opensuse.org/opensuse-factory/2020-02/msg00057.html>
Ich halte AppArmor für unschuldig ;-) - allerdings nur, wenn Du die aktuellen Profile und abstractions im Einsatz hast. Guck also mal in /etc/apparmor.d/ und dessen Unterverzeichnissen nach *.rpmnew-Dateien. Falls es welche gibt, ersetzte die eigentliche Datei mit der *.rpmnew (z. B. abstractions/nameservice.rpmnew -> abstractions/nameservice). Falls Du vorher etwas ergänzt hattest, darf das natürlich wieder rein. Danach "rcapparmor reload" aufrufen.
Ein weiterer Kandidat ist /etc/nsswitch.conf.rpmnew - falls es die gibt, bitte zu /etc/nsswitch übernehmen. Wichtig sind hier insbesondere die "usrfiles"-Teile, weil ohne die nicht in /usr/etc/ nachgesehen wird.
Danke, das war es :)
Generell ist ein Blick auf *.rpmnew und *.rpmsave nie verkehrt. Mit rpmconfigcheck bekommst Du eine Liste.
Gruß
Christian Boltz
-- Gruss Bernd -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (2)
-
Bernd Obermayr -
Christian Boltz