• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Wie usb serial adapter (d.h. /dev/cuaU0) für alle Nutzer freigeben

serie300

Well-Known Member
Themenstarter #1
Hallo

nachdem man in Zeiten wie diesen viel Zeit hat mit MCU Spielzeug zu basteln ...
wie gebe ich in FreeBSD (11 und 12) USB Serial Adapter (also die, die unter cuaU[1-9] erscheinen) automatisch beim Einstöpseln für alle Benutzer frei? Z.Z. sind sie für 'operator' freigegeben.

Serie300
 

turrican

Well-Known Member
#2
entweder alle in "operator" aufnehmen, oder....

... in /etc/devfs.conf die "perm" von 0660 auf 0666 ändern:

Code:
own    /dev/cuaU0   root:operator
perm   /dev/cuaU0   0666
 

Kamikaze

Warrior of Sunlight
#3
@turrican Das funktioniert aber nur wenn der Adapter schon beim booten Steckt. Besser ist es die Regeln in der devfs.rules festzulegen. Die devfs.conf sollte man IMHO nur noch benutzen um beim Booten irgendwelche Device Symlinks anzulegen.
 

serie300

Well-Known Member
Themenstarter #5
Guten Mittag

In meiner devfs.rules steht:

[localrules=11]
add path 'cuaU*' mode 0660 group operator

und in der rc.conf: 'devfs_system_ruleset="localrules"'

Soll ich auf 0666 ändern oder bei group z.B. noch 'user, wheel' etc. hinzufügen? Die man page zu devfs.rules ist leidre nicht sehr ergiebig.

Serie300
 

Kamikaze

Warrior of Sunlight
#6
Ich würde in der Regel meinen Benutzer zur operator group hinzufügen. Das ist die Gruppe für Leute die den Rechner abschalten/neu starten dürfen.
 

serie300

Well-Known Member
Themenstarter #7
Hallo Kamikaze

stehe gerade 'auf dem Schlauch'. Meintest du ich soll via passwd die Nutzer der 'operator' group hinzu fügen .EOR. meintest du ich soll hinter 0660 group operator' noch 'wheel' schreiben?

Serie300
 

Kamikaze

Warrior of Sunlight
#8
Nutzer die mit Hardware Dinge fummeln dürfen sollten in der Gruppe operator sein oder Du machst eine eigene Gruppe für Nutzer die die Schnittstelle nutzen dürfen. In die Wheel Gruppe gehören nur Administratoren. Also Leute die Updates durchführen und das System konfigurieren.
 

lme

FreeBSD Committer
#10
Aber Achtung: Wer in der Gruppe operator ist, darf das System mit shutdown(8) neu starten und herunterfahren!
 

serie300

Well-Known Member
Themenstarter #13
Hallo

<operator> ist vielleicht die falsche Gruppe für das m.E. harmlose Öffnen einer seriellen Schnitzstelle. Ich nehm mal die Gruppe <video> - also alle, die beschleunigtes X11 dürfen, da ich nicht noch eine Gruppe erstellen möchte.

Serie300
 

Zirias

Well-Known Member
#14
<operator> ist vielleicht die falsche Gruppe für das m.E. harmlose Öffnen einer seriellen Schnitzstelle. Ich nehm mal die Gruppe <video> - also alle, die beschleunigtes X11 dürfen, da ich nicht noch eine Gruppe erstellen möchte.
Das halte ich für eine ziemlich blöde Idee, erinnert mich an graue Vorzeit bei meinem Arbeitgeber, als ein System nur Datenfelder für das Unternehmen (der Gruppe) hatte, aber nicht für Länder -- da kam jemand auf die tolle Idee, dass man das einfach wiederverwenden kann, weil es ja pro Land genau ein Unternehmen gab. Ging nicht lange gut.

Auf manchen Linux-Distributionen habe ich schon die Gruppe "plugdev" gesehen, das schien mir für solche Dinge eine ganz gute Idee. Wenn keine der Standard-Systemgruppen für deinen Anwendungsfall passt, erstelle eine neue mit irgendwie selbstbeschreibendem Namen.
 

Crest

rm -rf /*
Mitarbeiter
#16
By default sollten cua[0-9]+ und cuaU[0-9]+ eh schon für die Gruppe dialer freigeben sein. Füg die entsprechenden Nutzer der Gruppe hinzu, wenn du ihnen den Zugriff auf alle seriellen Ports geben willst. Solltest du den Nutzern nur ein bestimmtes Device geben wollen würde ich über devd gehen. Der kann auch gegen die serial number, vendor und product id matchen. Das ist bei USB devices wichtig, weil die möglicherweise bei jedem Boot in einer anderen Reihenfolge hoch kommen. Du kannst auch gleich per devd Dienste starten lassen, die anschließend das Device nutzen sollen. Ein einfaches cat /var/run/devd.pipe reicht um zu devd dabei zuzusehen welche Events der Kernel auf /dev/devctl meldet.