Opened 7 years ago
Closed 7 years ago
#3211 closed Defekt (erledigt)
Basic-Stamp-Editor funktioniert im neuen Image nicht
| Reported by: | Rüdiger Kupper | Owned by: | Rüdiger Kupper |
|---|---|---|---|
| Priority: | schnell erledigen | Milestone: | Image "Galanter Gerhard" |
| Component: | Software: Ubuntu | Severity: | beeinträchtigt den Unterricht vieler Lehrer |
| Keywords: | Cc: | bau |
Description
USB-Ports sind nicht erreichbar, Meldung bei allen Ports: "Port in use".
Für den µC-Kurs muss das laufen.
Change History (15)
comment:2 by , 7 years ago
Übrigens gibt es eine etwas aktuellere Version des Programms auf der Parallax-Seite.
comment:3 by , 7 years ago
Ja, Punkt 3 ist das Problem: Unsere Nutzer sind nicht in der Gruppe dialout. Anscheinend hatten wir im letzten Image das Device einfach für alle lesbar gemacht. Oder eben sämtliche Nutzer in die Gruppe dialout packen – da gab's doch eine einfache Möglichkeit, das automatisch zu tun …?
comment:4 by , 7 years ago
Ähm, anscheinend wird man schon dynamisch in die Gruppe "dialout" gepackt …? Warum klappt das dann nicht?
comment:5 by , 7 years ago
Die dynamischen Gruppen werden für die Dauer einer Sitzung von pam_groups vergeben.
Siehe /etc/security/group.conf und AdminClientAufsetzen#pam_groupaktivieren.
comment:6 by , 7 years ago
follow-up: 8 comment:7 by , 7 years ago
Häh? Wenn ich mich von zuhause per SSH auf rechner2-3-12 einlogge, läuft der BSE wie gewünscht. Ich bin dann auch in der Gruppe dialout.
Beim direkten Einloggen am Gerät hatte es aber nicht funktioniert?! Läuft da vielleicht etwas mit pam_groups schief?
Komisch, mal wieder …
comment:8 by , 7 years ago
Replying to kup:
Läuft da vielleicht etwas mit pam_groups schief?
Exakt das ist es:
- Loggt man sich über den graphischen Login ein, so werden die Gruppen von pam_groups *nicht* zugewiesen. Der Nutzer darf dann z.B. nicht auf die USB-Ports zugreifen und kein VirtualBox nutzen.
- macht man dann aber in einem Terminal ein `ssh -X localhost so bekommt man die Gruppen plötzlich zugewiesen.
comment:10 by , 7 years ago
Okay, hat wieder mal mit systemd und DBus zu tun und betrifft wohl das gnome-terminal (aber nicht andere Terminals). Das wird irgendwie über DBus gestartet und arbeitet die pam_groups nicht ab.
Mehr Infos: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1762391
Man beachte insbesondere Kommentar 6: Demnach ist pam_groups veraltet und sollte nicht mehr verwendet werden. Stattdessen soll logind benutzt werden (wie??)
comment:11 by , 7 years ago
| Cc: | added |
|---|---|
| Resolution: | → im Image |
| Status: | new → closed |
Derzeitiger schmutziger Workaround:
Das wine.sh-Skript setzt nun bei jedem Aufruf das Device /dev/ttyUSB0 auf weltlese- und schreibrechte. Das klappt allerdings nur, wenn das Device auch existiert. Da die dynamisch angelegt werden (udev?) muss der Nutzer den USB-Adapter bereits eingesteckt haben, wenn er den BSE startet. Ich denke, das ist den Schülern zuzumuten.
Eine umfassendere Lösung für das Lokale-Gruppen-Problem ist dennoch zu bevorzugen.
comment:12 by , 7 years ago
Verbesserte Lösung: Ich habe eine udev-Regel erstellt, die dafür sorgt, dass das Device /dev/ttyUSB0 Weltlese- und Schreibrechte erhält, wenn es angelegt wird.
Das chmod in wine.sh habe ich wieder entfernt.
So klappt der Zugriff auch, wenn die Schüler den USB-Adapter erst später einstecken oder zwischendurch abziehen.
Informationen zu den udev-Regeln:
https://unix.stackexchange.com/questions/111593/allow-non-root-user-to-read-write-dev-files
Natürlich wäre es noch immer besser, wir fänden einen zeitgemäßen weg, Nutzer in die lokale Gruppe dialout zu stecken.
comment:13 by , 7 years ago
| Resolution: | im Image |
|---|---|
| Status: | closed → reopened |
Ohmann, dieses Ticket ist echt hartnäckig! Weiteres Problem:
Die neue Wine-Version legt die Links in $WINEPREFIX/dosdevices beim Start jedes mal dynamisch an. Weil auf unseren Rechnern 32 serielle Devices (/dev/ttyS0–31) eingerichtet sind (vermutlich Linux-Standard, doch wofür eigentlich?), taucht der USB-Adapter dann hartnäckig als COM33: auf. BSE prüft aber nur COM1–5. Da nützt es auch nichts, den Link wie früher von Hand anzulegen, er wird beim nächsten Start wieder überschrieben.
Irgendwo habe ich gelesen, dass man Registry-Einträge in der Wine-Umgebung ändern muss, um die Reihenfolge festzulegen …
comment:14 by , 7 years ago
comment:15 by , 7 years ago
| Resolution: | → erledigt |
|---|---|
| Status: | reopened → closed |
Toll, es funktioniert! Der USB-Adapter wird jetzt als COM1 verlinkt.
Nun muss man also auch noch unter Linux mit der Windows-Registry kämpfen. Argh …
Das nötige Vorgehen ist in diesem sehr alten (aber noch immer funktionierenden) Forumshinweis angegeben:
https://ubuntuforums.org/showthread.php?t=1523814
bugs.winehq.org, nichtbugs2.winehq.org, wie im Thread angegeben.) Müsste in unserer Wine-Umgebung ja schon erledigt sein.$WINEPREFIX/dosdevices/nach/dev/ttyUSB0. War der USB-Adapter angesteckt, als die Wine-Umgebung angelegt wurde, hat wine den zwar erstellt, doch er taucht sehr weit hinten auf (bei mir als com33). Der Basic-Stam-Editor sucht aber nur an com1-com5. Der Link muss also von hand angelegt werden, z.B.:/dev/ttyUSB0haben. Hierzu muss er in der richtigen Gruppe sein (bei mir in der Gruppedialout).Danach läuft der Editor auf meinem Notebook. Anscheinend hat sich am letzten Punkt im neuen Image irgendwas geändert …