Hi Achim

achim:/etc # rcnamed start Starting name server BIND named: capset failed: Operation not permitted schaue in den logfiles nach

du kannst den auch mal im debugmodus starten named -f -c /<bindverzeichnis>/named.conf -g -d 1 bis denne Jerome

Andreas Koenecke schrieb:

...

achim:/etc # rcnamed start Starting name server BIND named: capset failed: Operation not permitted startproc: exit status of parent of /usr/sbin/named: 1

Sind die Kernel-Module "commoncap" und "capability" geladen?

Ein modprobe capability brachte dann die temporäre Lösung des Problem. Jetzt erzähl mir nur bitte noch wo ich da meine Konfiguration zerbeamt habe ? Mit anderen Worten, wo und wird dieses Modul automatisch geladen ? Cu Achim -- Am texanischen Wesen soll die Welt genesen. (c) by G.(W.) Bush 1992+2003

Hallo, Am Thu, 03 Feb 2005, Andreas Koenecke schrieb:

* Donnerstag, 03. Februar 2005 um 20:10 (+0100) schrieb Achim Theobald:

...

Andreas Koenecke schrieb:

...

Sind die Kernel-Module "commoncap" und "capability" geladen?

Ein modprobe capability brachte dann die temporäre Lösung des Problem. Jetzt erzähl mir nur bitte noch wo ich da meine Konfiguration zerbeamt habe ? Mit anderen Worten, wo und wird dieses Modul automatisch geladen ?

Das Modul wird nicht automatisch geladen. Ich habe hier eine SuSE 9.0 und würde in deinem Fall dem Modul-Namen in "/etc/sysconfig/kernel" unter "MODULES_LOADED_ON_BOOT="capability" eintragen. Ich weiss aber nicht, ob das bei der 9.2 auch noch geht...

*grummel* MODULES_LOADED_ON_BOOT ist boese![tm] Sowas sollte sich in der /etc/modprobe.conf{,.local} (bzw. /etc/modules.conf*) loesen lassen. Was spuckt denn ein strace -e file ... 2>&1 | grep '^/dev/' aus, wenn man fuer '...' etwas (aber nicht modprobe etc.) einsetzt, das das Modul capability verwendet? lsacl, lsusb oder sowas... Ich kann mir nicht vorstellen, dass man das Modul in einem init-script per modprobe laden muesste, was ueber o.g. boese sysconfig-Variable letztlich gemacht wird. -dnh -- Man kann sich auch einen Ring um beide Knie schmieden, und dann immer noch hoppeln. Oder ein Loch ins Knie bohren, warten, bis Milch fließt und darin Goldfische züchten. Oder Windows zum Arbeiten benutzen. -- B. Eggert

Hallo, Am Fri, 04 Feb 2005, Andreas Koenecke schrieb:

* Freitag, 04. Februar 2005 um 02:56 (+0100) schrieb David Haller:

...

Am Thu, 03 Feb 2005, Andreas Koenecke schrieb:

...

Ich habe hier eine SuSE 9.0 und würde in deinem Fall dem Modul-Namen in "/etc/sysconfig/kernel" unter "MODULES_LOADED_ON_BOOT="capability" eintragen. Ich weiss aber nicht, ob das bei der 9.2 auch noch geht...

*grummel*

MODULES_LOADED_ON_BOOT ist boese![tm]

Full ACK!

Du rennst bei mir offene Türen ein, aber ich befürchte, so etwas ist die Folge der "One fits all and everywhere"-Kernel.

Sollte aber dennoch eigentlich nicht der Fall sein. SuSE hat(te) ja gerne ggfs. 'ide-scsi sr_mod cdrom' in der Variablen, was aber eben nachweislich auch besser geht... Eigentlich[tm] sollte sich auch so ein one-fits-all Kernel per modprobe.conf (modules.conf) so konfigurieren lassen, dass man eben _kein_ manuelles modprobe braucht (und MODULES_LOADED_ON_BOOT ist letztlich ein manuelles modprobe). Aber...

...

Sowas sollte sich in der /etc/modprobe.conf{,.local} (bzw. /etc/modules.conf*) loesen lassen.

Was spuckt denn ein

strace -e file ... 2>&1 | grep '^/dev/'

IMHO nichts Verwertbares:

kocom:~ # strace named -t /var/lib/named -u named 2>&1 | grep '/dev/' connect(3, {sa_family=AF_UNIX, path="/dev/log"}, 16) = 0

Mist![tm]

Das "Problem" liegt wohl hier:

kocom:~ # strace named -t /var/lib/named -u named 2>&1 | grep -i 'cap' capset(0x19980330, 0, {CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|\ CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE, CAP_DAC_READ_SEARCH|\ CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|CAP_SYS_CHROOT|CAP_SYS_RESOURCE,\ CAP_DAC_READ_SEARCH|CAP_SETGID|CAP_SETUID|CAP_NET_BIND_SERVICE|\ CAP_SYS_CHROOT|CAP_SYS_RESOURCE}) = 0 capset(0x19980330, 0, {CAP_NET_BIND_SERVICE|CAP_SYS_RESOURCE,\ CAP_NET_BIND_SERVICE|CAP_SYS_RESOURCE, CAP_NET_BIND_SERVICE|\ CAP_SYS_RESOURCE}) = 0

Jep. Jetzt muesste man nur noch rausfinden, wie man capset (etc.) an das modprobe bindet, so wie das ja z.B. auch fuer binfmt* klappt... Ich kenne ich mit dem ganzen Zeug halt noch nicht aus und habe z.Z. auch nicht die Zeit mich da einzulesen und/oder es auszuprobieren.

...

aus, wenn man fuer '...' etwas (aber nicht modprobe etc.) einsetzt, das das Modul capability verwendet? lsacl, lsusb oder sowas...

Ich kann mir nicht vorstellen, dass man das Modul in einem init-script per modprobe laden muesste, was ueber o.g. boese sysconfig-Variable letztlich gemacht wird.

Ich sehe keinen anderen Weg -- ausser natürlich die "Default Linux Capabilities" fest in den Kernel zu bauen (Was ich bevorzuge.).

ACK. Und dann ist MODULES_LOADED_ON_BOOT natuerlich schon der sauberste Weg, um das haendische Laden der Module abzufeiern... -dnh, der endlich mal die binutils zum Laufen bekommen sollte, damit er mal Kernel 2.6 testen kann... --

...

Man sollte die Sprueche der MCSEs sammeln und als Witzbuch herausgeben. Das waere sicherlich ein Bestseller, meinst du nicht? Gibt's ein Beißholz gratis dazu? Nein, aber ein Schild mit der Aufschrift: "Die meinen das ernst" -- J. Ilse, MOW und Regina