Hallo Liste, ich habe das Problem, das nach einem System Upgrde, leider mit noch laufendem inn dieser in neuem System nicht mehr startet (Fehlermeldung im Anhang). Fehlermeldung im Anhang. Habt Ihr eine Idee, wo man da drehen kann? Gruß Rainer -- Rainer Gubanski Hannover -- Rainer Gubanski Hannover
Rainer Gubanski schrieb:
Feb 04 16:07:50 squirrel innbind[1525]: cannot bind socket for 15,10,::,119: Permission denied
Mutmassung: Bei innbind fehlt das setuid-Bit und damit kann es keine Ports < 1024 allokieren. -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
Hallo Liste, ich habe inzwischen einmal einen Backup von 15.4 eigespielt, bei dem alles tut. Dann habe ich erneut ein Upgrade auf 15.5 gefahren, und diesmal explizit darsuf geavhtet, das der inn gestoppt ist während des updates. Leider mit demselben Ergebnis. Ein weiterer Rechner, der von 15.4 auf 15.5 gebracht wurde und auf dem der inn zwar istalliert aber disabled war, zeigte nach enablen des innn denselben Fehler. Ist der inn in 15.5 vielleicht kaputt? Ausgehend von der Bemerkung von Manfred unten schicke ich hier mal das ls -lr von /usr/lib/news/bin mit Gruß Rainer Am 04.02.24 um 18:09 schrieb Manfred Haertel, DB3HM:
Rainer Gubanski schrieb:
Feb 04 16:07:50 squirrel innbind[1525]: cannot bind socket for 15,10,::,119: Permission denied
Mutmassung: Bei innbind fehlt das setuid-Bit und damit kann es keine Ports < 1024 allokieren.
-- Rainer Gubanski Hannover -- Rainer Gubanski Hannover
rcinn status gibt dieses: Feb 19 10:37:32 linux.fritz.box innd[17244]: SERVER outgoing 1010 Feb 19 10:37:32 linux.fritz.box systemd[1]: inn.service: Can't open PID file /run/news/innd.pid (yet?) after start: Operation not permi> Feb 19 10:37:32 linux.fritz.box innd[17244]: SERVER ccsetup control:12 Feb 19 10:37:32 linux.fritz.box innd[17244]: SERVER lcsetup localconn:14 Feb 19 10:37:32 linux.fritz.box innd[17244]: innbind failed for 0.0.0.0, port 119 Feb 19 10:37:32 linux.fritz.box innd[17244]: innbind failed for ::, port 119 Feb 19 10:37:32 linux.fritz.box innd[17244]: SERVER cant listen on any sockets Feb 19 10:39:01 linux.fritz.box systemd[1]: inn.service: start operation timed out. Terminating. Feb 19 10:39:01 linux.fritz.box systemd[1]: inn.service: Failed with result 'timeout'. Feb 19 10:39:01 linux.fritz.box systemd[1]: Failed to start Inter Net News Server (INN). ~ Am 19.02.24 um 11:04 schrieb Rainer Gubanski:
Hallo Liste, ich habe inzwischen einmal einen Backup von 15.4 eigespielt, bei dem alles tut. Dann habe ich erneut ein Upgrade auf 15.5 gefahren, und diesmal explizit darsuf geavhtet, das der inn gestoppt ist während des updates. Leider mit demselben Ergebnis. Ein weiterer Rechner, der von 15.4 auf 15.5 gebracht wurde und auf dem der inn zwar istalliert aber disabled war, zeigte nach enablen des innn denselben Fehler. Ist der inn in 15.5 vielleicht kaputt? Ausgehend von der Bemerkung von Manfred unten schicke ich hier mal das ls -lr von /usr/lib/news/bin mit
Gruß Rainer
Am 04.02.24 um 18:09 schrieb Manfred Haertel, DB3HM:
Rainer Gubanski schrieb:
Feb 04 16:07:50 squirrel innbind[1525]: cannot bind socket for 15,10,::,119: Permission denied
Mutmassung: Bei innbind fehlt das setuid-Bit und damit kann es keine Ports < 1024 allokieren.
-- Rainer Gubanski Hannover
-- Rainer Gubanski Hannover
-- Rainer Gubanski Hannover
Hallo Ulf, so , dann referiere ich mal, wie ich Manfreds Beitrag verstande und interpretiert habe. Gefragt war nach dem s bit für innbind. Das sieht bei mir so aus: -r-sr-x--- 1 root news 67896 22. Mai 2023 innbind daraus entnehme ich, das dieses bit gesetzt ist. Wenn ich da falsch liege und die Permisions des innbind noch weiter manipuliert werden müssen, nehme ich euren Rat gern an. Gruß Rainer Am 19.02.24 um 11:44 schrieb Ulf Volmer:
Am 19.02.24 um 11:04 schrieb Rainer Gubanski:
Hallo Liste,
Möchtest Du evtl. wenigstens versuchen, den Beitrag von Manfred zu lesen und zu prüfen?
Viele Grüße Ulf
-- Rainer Gubanski Hannover -- Rainer Gubanski Hannover
Am 19.02.24 um 12:30 schrieb Rainer Gubanski:
Hallo Ulf, so , dann referiere ich mal, wie ich Manfreds Beitrag verstande und interpretiert habe. Gefragt war nach dem s bit für innbind. Das sieht bei mir so aus:
-r-sr-x--- 1 root news 67896 22. Mai 2023 innbind
daraus entnehme ich, das dieses bit gesetzt ist.
Jau. Das war aus Deiner vorherigen Mail nicht ganz klar geworden. Ich habe das mal durchgespielt, es sieht so aus, als ob Suse hier zu exessiv Hardening betrigen hat: ulf@leap155-p330:~> systemctl cat inn|grep 'added au' -A 12 # added automatically, for details please see # https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort ProtectSystem=full ProtectHome=true PrivateDevices=true ProtectHostname=true ProtectClock=true ProtectKernelTunables=true ProtectKernelModules=true ProtectKernelLogs=true ProtectControlGroups=true RestrictRealtime=true # end of automatic additions Wenn ich hier ein Override erstelle und das ganze deaktiviere (systemctl edit inn.service), startet der inn bei mir. Mir fehlt gerade die Muße, in der Doku zu suchen, welches dieser Settings der Übertäter ist. Es wäre schön, wenn Du das machst und anschließend einen passenden Bugreport erstellst. Viele Grüße Ulf
Hallo Ulf, ich habe mein Problem auch nur durch vollständiges Entfernen der "hardening" Regeln gelöst bekommen. meine, zugegebener Maßen nicht wirklich vollständigen Versuche, dort nur einige Regeln zu deaktivieren waren nicht zielführend und wurden abgebrochen, da ja irgendwann auch wieder ein produktives System da sein sollte. Thema Bugreport: Ich habe noch keinen Account in Bugzilla (kriegt man den "einfach so" durch Anmelden oder gibt es da Voraussetzungen?) und ich habe ja auch nicht mehr "herausgefunden" als Du. Danke nochmal für den Tipp Gruß Rainer Am 19.02.24 um 14:35 schrieb Ulf Volmer:
Am 19.02.24 um 12:30 schrieb Rainer Gubanski:
Hallo Ulf, so , dann referiere ich mal, wie ich Manfreds Beitrag verstande und interpretiert habe. Gefragt war nach dem s bit für innbind. Das sieht bei mir so aus:
-r-sr-x--- 1 root news 67896 22. Mai 2023 innbind
daraus entnehme ich, das dieses bit gesetzt ist.
Jau. Das war aus Deiner vorherigen Mail nicht ganz klar geworden.
Ich habe das mal durchgespielt, es sieht so aus, als ob Suse hier zu exessiv Hardening betrigen hat:
ulf@leap155-p330:~> systemctl cat inn|grep 'added au' -A 12 # added automatically, for details please see # https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort ProtectSystem=full ProtectHome=true PrivateDevices=true ProtectHostname=true ProtectClock=true ProtectKernelTunables=true ProtectKernelModules=true ProtectKernelLogs=true ProtectControlGroups=true RestrictRealtime=true # end of automatic additions
Wenn ich hier ein Override erstelle und das ganze deaktiviere (systemctl edit inn.service), startet der inn bei mir.
Mir fehlt gerade die Muße, in der Doku zu suchen, welches dieser Settings der Übertäter ist.
Es wäre schön, wenn Du das machst und anschließend einen passenden Bugreport erstellst.
Viele Grüße Ulf
-- Rainer Gubanski Hannover -- Rainer Gubanski Hannover
Hallo Rainer, um den Bugreport zu erstellen, wirst Du wohl eine Opensuse IDP Account brauchen, Der ist aber nicht so schwer zu erstellen: https://idp-portal.suse.com/univention/self-service/#page=createaccount Von dem Bugreport erwartet auch niemand von Dir, dass Du eine Lösung lieferst. Es geht eher darum, mit einer Fehlerberechreibung den Maitainer auf das Problem erstmal hinzuweisen. Viele Grüße Ulf
participants (3)
-
Manfred Haertel, DB3HM -
Rainer Gubanski -
Ulf Volmer