Was ist falsch in meiner devfs.rules

cabriofahrer

Well-Known Member
Ich kann neuerdings keine CD's als user mehr brennen, k3b erkennt kein Gerät. Ich weiß, daß es sich auf jeden Fall um ein Rechteproblem handelt, denn wenn ich mich in GDM als root einlogge und dann k3b aufrufe, wird der Brenner erkannt und es funktioniert. Als user klappt es hingegen nicht mehr. Kein Wunder, denn:

$ camcontrol devlist
camcontrol: couldn't open /dev/xpt0: Permission denied
$

und

$ groups
wheel operator
$

Ich hatte festgestellt, daß ich mich durch eine Zuweisung zur Gruppe cups aus der Gruppe operator rausgehauen hatte, also lag es wahrscheinlich daran, doch nach erneuter Zuweisung zur Gruppe operator klappt es immernoch nicht. Hier meine devfs.rules:

[localrules=10]
add path 'da*s*' mode 0660 group operator
#add path 'ulpt*' mode 0660 group operator
add path 'md*' mode 0660 group operator
#add path 'usb*' mode 0770 group cups
#add path 'ugen*' mode 660 group operator
#add path 'umass*' mode 660 group operator
add path 'msdosfs/*' mode 0666 group operator
add path 'cd*' mode 0666 group operator
add path 'pass*' mode 0666 group operator
add path 'xpt0' mode 0666 group operator
add path 'bpf*' mode 0666 group operator
add path dvb/adapter*/demux* mode 0660 group operator
add path dvb/adapter*/frontend* mode 0660 group operator
add path dvb/adapter*/dvr* mode 0660 group operator

[system=10]
#add path 'unlpt*' mode 0660 group cups
#add path 'ulpt*' mode 0660 group cups
#add path 'lpt*' mode 0660 group cups
add path 'usb*' mode 0770 group cups
add path 'ugen*' mode 0660 group cups
add path 'usb/1.2.*' mode 0660 group cups
$


Wo liegt also der Fehler? Und wie kann ich meinen user wieder in die Gruppe cups zuweisen, ohne wieder aus operator rauszufliegen? Ich komme mit "pw" nicht so ganz klar.
 
Zu pw:

Code:
# pw groupmod cups -m $deinuser

Zum eigentlichen Problem: Du lädst in der rc.conf wahrscheinlich nur die system rules?
 
Nein, localrules ist auch drin. Wie gesagt, es hatte schonmal funktioniert.

$ more /etc/rc.conf
hostname="elvis69.my.domain"
keymap="german.cp850.kbd"
sshd_enable="YES"
moused_enable="YES"
powerd_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="NO"
devd_enable="YES"
devfs_system_ruleset="localrules"
gnome_enable="YES"
#gdm_enable="NO"
dbus_enable="YES"
hald_enable="YES"
#local_startup="${local_startup} /usr/local/kde4/etc/rc.d"
#kdm4_enable="YES"
# -- sysinstall generated deltas -- # Thu Mar 15 18:37:07 2012
ifconfig_bge0="DHCP"
ifconfig_iwi0="up"
wlans_iwi0="wlan0"
ifconfig_wlan0="WPA DHCP"
#ifconfig_wlan0="inet 192.168.1.178 netmask 192.168.1.255"
webcamd_enable="YES"
clear_tmp_enable="YES"
linux_enable="YES"
fusefs_enable="YES"
apache22_enable="YES"
pbid_enable="YES"
ftpd_enable="YES"
cupsd_enable="YES"
devfs_system_ruleset="system"
 
Hallo,
ohne das genauer geprüft zu haben.
Code:
# grep devfs_system_ruleset /etc/defaults/rc.conf
devfs_system_ruleset="" # The name (NOT number) of a ruleset to apply to /dev
Da steht _ein_ Ruleset. Nicht mehrere.
Prüf doch mal, ob das wirklich mehrfach in die rc.conf rein darf.

hth
Mario
 
[localrules=10]
add path 'da*s*' mode 0660 group operator
#add path 'ulpt*' mode 0660 group operator
add path 'md*' mode 0660 group operator
#add path 'usb*' mode 0770 group cups
#add path 'ugen*' mode 660 group operator
#add path 'umass*' mode 660 group operator
add path 'msdosfs/*' mode 0666 group operator
add path 'cd*' mode 0666 group operator
add path 'pass*' mode 0666 group operator
add path 'xpt0' mode 0666 group operator
add path 'bpf*' mode 0666 group operator
add path dvb/adapter*/demux* mode 0660 group operator
add path dvb/adapter*/frontend* mode 0660 group operator
add path dvb/adapter*/dvr* mode 0660 group operator

[system=10]
#add path 'unlpt*' mode 0660 group cups
#add path 'ulpt*' mode 0660 group cups
#add path 'lpt*' mode 0660 group cups
add path 'usb*' mode 0770 group cups
add path 'ugen*' mode 0660 group cups
add path 'usb/1.2.*' mode 0660 group cups
$
Zweimal die Nummer 10? Hat das einen Grund?

Mario
 
OK, habe jetzt in der devfs.rules den Eintrag "[system=10]" entfernt und in rc.conf mit einem "'#" versehen. Nach einem '/etc/rc.d/devfs restart' erkennt k3b das Laufwerk nun wieder, Danke!

Trotzdem noch eine Frage: Ich hatte diese Einträge aufgrund der Befolgung der verschiedenen Wiki-Anleitungen gemacht. Es spielt also keine Rolle, ob alle Einträge in der devfs.rules unter [localrules=10] oder [system=10] stehen oder ob ich den Eintrag in de eckigen Klammern [sonstwie=beliebigezahl] nenne?
 
Hallo.
In der /etc/defaults/devfs.rules steht die Bedienungsanleitung für die Datei oben drin.
Die Nummern sind im Default devfs.rules auch inkrementierend. Daher habe ich mir nie Gedanken gemacht, eine Nummer doppelt zu vergeben, auch wenn es da nicht ausdrücklich steht.

Trotzdem noch eine Frage: Ich hatte diese Einträge aufgrund der Befolgung der verschiedenen Wiki-Anleitungen gemacht. Es spielt also keine Rolle, ob alle Einträge in der devfs.rules unter [localrules=10] oder [system=10] stehen oder ob ich den Eintrag in de eckigen Klammern [sonstwie=beliebigezahl] nenne?

Das Abarbeiten von Anleitungen bedeutet ja eigentlich, dass man den Inhalt versteht und dann umsetzt. Nicht einfach abschreiben... :) Nimm's nicht persönlich, auch wenn es vielleicht so rüber kommt. :)

Zu deiner Frage. Eine Rolle spielt das schon. Du machst Konfigurationseinstellungen in einer "Regel" und lädst die dann über den Namen oder die Nummer.
Wenn du die Regel anders nennst musst du sicherstellen, dass auch die entsprechende Regel geladen wird, damit sie aktiv ist uns zur Verfügung steht.
So richtig verstehe ich deine Frage offenbar nicht.


Mario
 
Bei mir lag nach einer Frischinstallation niemals bereits eine devfs.rules vor, die mußte ich immer erst selbst erstellen, folglich auch keine Anleitung. Natürlich kann ich die mit 'man devfs.rules' bekommen. Daraus ergibt sich aber auch nicht alles genau. Mir ist schon klar, daß eine Regel dann auch über die rc.conf geladen werden muß. Doch Du hast darauf hingewiesen, daß man über die rc.conf für devfs wohl nur eine laden kann. Deswegen konnte nach meiner Ergänzung für cups mein Laufwerk von den Brennprogrammen nicht mehr erkannt werden. Offenbar wurde zuerst die Regel "localrules=10 geladen" und sogleich wieder durch "service=10" wieder ersetzt. Korrekt?
Dem Ganzen entnehme ich jetzt, daß ich jetzt entweder alle Einträge zusammen unter [localrules=10] setze oder z.B. einige unter [localrules=10] und die für cups z.B. unter [localrules=20], falls ich es überhaupt trennen will?
Brauchen die Einträge für cups unbedingt die Bezeichnung [service=10] oder ist es nur ein Beispiel aus einer anzupassenden Anleitung? Meine Frage zielt letztendlich auf das komplette Verständnis der Angelegenheit ab.

Wie sieht z.B. Deine devfs.rules aus?
 
OK, jetzt wird es klarer.

Ich nehme auch an, dass die zweite die erste Einstellung einfach wieder überlagert hat.

Die Benennung z.B. [service=10] für CUPS ist frei.

Das erst mal keine Datei da ist liegt an der /etc/default Thematik. Dort ist eine Basis, die eventuell durch eigene Ergänzungen in /etc ergänzt oder ersetzt wird.
Zum Beispiel periodic.conf macht das ja auch so und einige andere Tools auch.

Ich habe mal geforscht. Ich habe nur eine Regel für devfs auf einem Jailhost, um dhcp ins Jail zu lassen. Ist wohl nicht wirklich vergleichbar, da diese Rule per
Code:
jail_infrasrv082_devfs_enable="YES"
jail_infrasrv082_devfs_ruleset="devfsrules_jail_dhcp"
eingeladen wird.

[devfsrules_jail_dhcp=5]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add path 'bpf*' unhide
add path net unhide
add path 'net/*' unhide

Aber eigentlich passt dieses Beispiel doch gut, da es zeigt, wie an anderen Stellen andere Regeln nachgeladen werden.

Mario
 
Das Beispiel ist sogar ganz exzellent.

Code:
add include $devfsrules_unhide_basic
könntest du ja auf deine K3B oder CUPS spezifischen Dinge adaptieren. :)

Grüße
Mario
 
das habe ich immer als Beispiel verstanden, also so gebraucht, dass dann, wenn ich noch keine Regeln habe, ich zum Beispiel eine für cups erstellen muss und die kann dann service 10 genannt werden.
Da ich immer schon eine Regel hatte, habe ich dann einfach das dort eingefügt, was cups wollte und nie weiter nachgedacht.
Mir ist diese ganze Konstruktion auch nie wirklich klar geworden und ich war einfach froh, wenn es funktioniert hat.
Wieso könnte man den zwei unterschiedliche Regelsätze brauchen? Es wird ja nicht konditionell abgefragt und geladen, oder?
Wenn ich alles in einem Regelsatz habe, könnte es dafür auch einen festen Namen geben, den das System schon vorgibt.
Wie gesagt, verstanden habe ich das nicht so richtig. Aber deine Erfahrung mit zwei unterschiedlichen Regeln und NO-GO, kann ich aus einem anderen Zusammenhang bestätigen.
 
Sehe ich auch so. Bin froh, daß es wieder funktioniert, egal ob die Regel system=10 oder localrules=10 heißt...Vielleicht kann irgend jemand darüber aufklären, welchen Hintergrund diese Bezeichnungen haben oder ob die einfach nur willkürlich für irgendwelche Anleitungen genommen wurden?
 
So wie ich mir das Denke, bedeutet localrules, dass die Regeln für eine bestimmte Umgebung bestimmt sind.

devfs rule showsets zeigt mir, dass es da noch mehrere Sets gibt. Wenn man sich die mit devfs rule -s1 show bis -s4 anzeigt, bekommt man eine Idee davon, das die Regeln während dem Bootprozess immer erweitert werden. Zum Schluss kommen halt noch die lokalen Regeln dazu.
 
Zurück
Oben