Beiträge von anders noergler

  • Konfiguration des gpsd

    Ich habe angenommen, das Paket gpsd wäre bei openSUSE Leap 42.3 einigermaßen aktuell, wenn es eine aktuelle Versionsnummer trägt:

    Code
    # rpm -q gpsd
gpsd-3.17-98.2.x86_64


# zypper lr -uP
#  | Alias                                 | Name                                                                                           | Enabled | GPG Check | Refresh | Priority | URI                                                                               
---+---------------------------------------+------------------------------------------------------------------------------------------------+---------+-----------+---------+----------+-----------------------------------------------------------------------------------
 1 | Application_Geo                       | Applications related to the earth (GIS, Mapping, geodesy, GPS, astronomy) (openSUSE_Leap_42.3) | Yes     | (r ) Yes  | Yes     |   99     | http://download.opensuse.org/repositories/Application:/Geo/openSUSE_Leap_42.3/

    Die neuesten Sources (gpsd 3.17) von GPSd — Put your GPS on the net! überzeugen einem vom Gegenteil.


    Es gibt bereits auf den ersten Blick eine umfassendere Integration, mehr Informationen und z.B. troubleshooting guides.
    Ein Vergleich mit der Version 3.0 zeigt, dass die Integration von V3.0 neuer bzw. weniger verstümmelt ist als diejenige,
    die Leap 42.3 als gpsd-3.17-98.2.x86_64 anbietet - oder muss man die Versionsnummern rückwärts lesen?
    Überraschenderweise ist der eigentliche gpsd tatsächlich neueren Datums, vielleicht sogar wirklich 3.17 -
    ich konnte dessen Hilfetext (weicht von 3.16 ab), aber nicht den IPv6-Fehler mit einem Eigenkompilat reproduzieren.
    Niemand hat behauptet, openSUSE V3.17 ist die Original V3.17, aber ein Paket lebt aber auch von seiner Integration.



    Neugierig habe ich es unter Ubuntu installiert:
    - GPS-Empfänger anstecken und er geht
    - alle "eigenwilligen Vorschläge" aus Eintrag 11 sind dort fast genauso umgesetzt, und natürlich noch einiges mehr.
    - leider ist es wohl nur Version 3.15, die im Ubuntu 16.04.3 Repository liegt. - aber es sieht aus wie die richtige 3.15 und verhält sich aus so


    Code
    # dpkg -l gpsd
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name                                                           Version                              Architektur                          Beschreibung
+++-==============================================================-====================================-====================================-=================================================================================================================================
ii  gpsd                                                           3.15-2build1                         amd64                                Global Positioning System - daemon


    Ich hatte mich schon gewundert. So unpopulär schien mir das Paket nicht zu sein.


    Vor diesem Hintergrund mag jeder selbst die Aussagen zu Phantasien, Regeln und Subtilitäten beurteilen:

    Zitat von Berichtigung

    Du wählst einen anderen Weg.Erst das System puttspielen.
    Dann verzweifelt noch mehr subtile Fehler einbauen.
    Und hier nicht Infos nach Forenregeln posten, sondern hausgemachte Phantasien, wie etwas sein könnte.


    Ich habe meine Meinungen klar als solche gekennzeichnet und für das meiste Quellen genannt. Das halten hier aber nicht alle so.
    2 Abende meiner Lebenszeit für ein schlecht gepacktes Fake-Paket aufzuwenden, hinterlässt Spuren:
    Außer bei aufkommenden Interesse an Unterstellungen, Fakes und Troll-Bots werde ich wohl openSUSE und Anfänger künftig versuchen professionell zu meiden.
    Einige informative Sektionen sind hier durchaus zu finden, aber vergleicht die "Ratschläge" hier mit dem Original.


    Urteilt selbst und
    Orientiert Euch
    Anders
    ___
    Die deutsche Wikipedia-Seite zu Sokrates zitiert[Quelle 57] die Interpretation von „Ich weiß, dass ich nicht weiß“:
    ""Im Sokratischen Reden und Denken liegt erzwungener Verzicht, [...] und die Flucht in den Dialog [...]""

  • Konfiguration des gpsd

    Ihr wollt es aber heute genau wissen ...


    Boreas: Ich möchte WGS84-Information empfangen und relativ zu einem veränderlichen Standort darstellen.


    Berichtigung:
    Die Erstinstallation funktionierte bei mir nicht (so wie du es beschrieben hast). Also bat ich einen Freund mich zu unterstützen
    und seine letzte Konfig-Datei (bevor er aufgab) enthielt GPSD_PORT="-S 2999".
    Es war wohl eher eine Verzweiflungstat, aber hat mich etwas sensibilisiert. Insofern war diese Auswertung beabsichtigt.
    (Ich habe erst versucht das Ganze mit Shell-internen Konstruktionen zu erledigen, scheiterte aber immer an der Typenkonvertierung,
    wenn ich bei Strings mit Leerzeichen oder mehreren Einträgen mit test "$GPSD_PORT" -gt 0 prüfen wollte um ggf den Defaultwert 2947 zu verwenden.)
    Aber man kann nicht alles abfangen und ich habe auch eingestanden, dass ein Admin Fehlermeldungen lesen und verstehen können sollte.
    Andererseits waren in diesem Fall mehrere "Besonderheiten" zu finden, was es nicht einfacher machte.


    Dieses Paket ist übrigens aus der Distribution Application:Geo / openSUSE_Leap_42.3 - also nicht von U-Blox.


    Da das Paket und damit das Skript frei zugänglich sind (ich dachte im Hauptrepository), habe ich das Skript erst in Eintrag 3 gepostet.
    Mein Ziel ist es lediglich ein Paket zu haben, das dessen Beschreibung entspricht und es auch den anderen bereitzustellen.
    (Wenn schon nicht das Paket, dann zumindest die erforderlichen Korrekturen.)


    Aus meiner Sicht gibt der Eintrag 11 ca. 90% dessen wieder, das man bei dem Paket gpsd korrigieren muss.
    Klar gibt es andere Lösungswege (Sauerland hat auf einen hingewiesen), aber ich will das Modul einstecken und es läuft.
    Stellt Euch vor, ihr hättet diese Odyssee mit jeder neuen Tastatur oder Maus. (Der eine oder andere erinnert sich noch daran.)


    Jetzt setze ich mich an die "letzten 10%".

  • Konfiguration des gpsd

    Hallo Berichtigung,


    Wie teilt man Deiner Ansicht nach dem Service gpsd mit, welches Gerät er starten soll ?
    Hast Du mich nicht gebeten von den Dateien in file:///usr/lib/systemd/system/ die Finger zu lassen?
    Oder anders herum, warum brauche ich eine Konfigurationsdatei, wenn ich die Paket-Dateien modifizieren kann ? (Ich glaube, das war Dir auch nicht recht.)
    Übrigens hätte es DEVICES=/dev/ttyACM0 heißen müssen und die Suche nach dieser Variable bei knapp 300 Diensten ergibt:

    Vielleicht wird hierbei auch klar, was ich meine, wenn ich von Services (dt: Diensten) spreche,
    die Du vorzugsweise mit systemctl startest, von denen viele aber auch auf service reagieren.


    In der Datei file:///usr/lib/systemd/system/gpsd.service muss die "Requires"-Zeile auskommentiert werden, damit es funktioniert.
    Diese Zeile verursachte die Socket-Meldung, die unter anderem den Start nach Deinen Wünschen verhinderte. (Kann man leicht ausprobieren.)
    Der besagte Socket wird erst beim Start des gpsd für die Steuerung angelegt.


    Ohne -G hört der gpsd nicht auf IPv6 und beschwert sich (hier im Klartext und der Port war nicht belegt):
    gpsd:ERROR: can't bind to IPv6 port gpsd, Cannot assign requested address
    Setzt man die Option -G, so erlaubt der gpsd INADDR_ANY und startet fehlerfrei. Ob es sich wirklich um eine lokale Adresse
    (wie bei IPv4) oder stattdessen um einen der IPv6-Multicasts bzw. ähnliches handelt kann ich bei dieser Fehlermeldung erst
    nach einem Blick in die Quellen sagen.


    Der "Käse" macht übrigens genau das, was er soll. Ob man an dieser Stelle Admin-Fehler abfangen soll, kann man jedoch berechtigt bezweifeln.


    Danke für Deine Erklärung zum Konstrukt mit dem Netzwerk-Filesystem der Bash. Wieder was gelernt.


    Ich würde mich freuen, wenn wir jetzt in der uDev-Variante klären könnten, warum der bereits mit den korrekten Argumenten gestartete gpsd immer wieder mit SIGCHLD aufgibt.
    Eine mögliche Ursache wäre der ModemManager, den ich nicht kenne.
    ___
    Die deutsche Wikipedia-Seite zu Sokrates zitiert[Quelle 57] die Interpretation von „Ich weiß, dass ich nicht weiß“:
    ""Im Sokratischen Reden und Denken liegt erzwungener Verzicht, [...] und die Flucht in den Dialog [...]""

  • Konfiguration des gpsd

    Ich möchte meinen aktuellen Stand zusammenfassen:


    In file:///etc/sysconfig/gpsd fehlt die Definition von DEVICE=/dev/ttyACM0
    Diese Variable wird NUR beim Start über service ausgewertet, nicht beim Start über uDev.
    Die Variable GPSD_PORT wird dagegen NUR beim Start über uDev ausgewertet, nicht beim Start über service.
    Der uDev-Start funktioniert nur wenn der Parameter GPSD_STARTBYUDEV="yes" auf yes gesetzt ist.
    Dem service ist der Wert dieses Parameters bei meinen Tests egal gewesen.


    In file:///usr/lib/systemd/system/gpsd.service muss diese Zeile auskommentiert werden:
    #Requires=gpsd.socket
    Soweit ich sah wird der weiter unten dort sichtbare Parameter OPTIONS in keiner Konfigurationsdatei gesetzt.


    Aufgrund eines Programmierfehlers im Daemon /usr/sbin/gpsd funktioniert das Binden an eine lokale IPv6-Adresse nicht.
    Interaktiv wird eine Fehlermeldung geworfen, wo sie nicht stört. Beim Start mit beiden Diensten ( service und uDev ) führt das zum Abbruch des Startvorganges.
    Das kann derzeit vermieden werden, wenn in file:///etc/sysconfig/gpsd mindestens die Option GPSD_OPTIONS="-G" enthält.


    In der Datei file:///usr/lib/udev/rules.d/51-gpsd.rules musste ich für meine Zwecke die folgende Zeile einfügen:
    KERNEL=="ttyACM*", ATTRS{idVendor}=="1546", ATTRS{idProduct}=="01a7", RUN="gpsd.sh"


    Alle anderen Zeilen dieser Datei verwenden ATTR statt ATTRS. Ich kann mir nicht vorstellen, dass dies dann trotzdem funktioniert, wenn es bei meiner Definition ungeeignet war.



    In der Datei file:///usr/lib/udev/gpsd.sh verstehe ich noch immer nicht unter welchen Voraussetzungen dieser Pfad verfügbar ist file:///dev/tcp/localhost/$GPSD_PORT.


    Entsprechend habe ich diese viert-letzte Zeile auskommentiert. Auch wenn ich den Sinn noch nicht verstanden habe, könnte an dieser Stelle folgende Zeile helfen:


    (sleep 1 && echo "F=$TTYDEV" | telnet localhost $GPSD_PORT & (je nach Zweck dieser Übung kann statt telnet auch netcat / nc eingesetzt werden.)


    Außerdem würde ich mir eine Auswertung der gesetzten Variable GPSD_PORT wünschen. Vorschlag: GPSD_PORT=$(echo $GPSD_PORT | awk '{print $NF+0}') .


    Damit wäre zumindest sichergestellt, dass ein numerischer Wert übergeben wurde (Bei Null könnte man dies ggf noch durch den Default-Port ersetzen.)



    Ich habe zudem gelernt, dass die Dateien file:///var/run/gpsd.socket, file:///var/run/gpsd.device und file:///var/run/gpsd.sock bei allen Starts erwartungsgemäß uninteressant sind.


    Die letzte Datei entsteht durch den Start als service, die anderen beim Start mit uDev beim Abarbeiten von file:///usr/lib/udev/gpsd.sh .
    Die Datei file:///etc/default/gpsd wird bei den vordefinierten Services referenziert, fehlt aber (sie wäre ein guter Ort für die Definition von DEVICES).
    Auch die Fehlermeldungen bzgl. var--run.mount,etc. beim Starten des falsch konfigurierten Service sind falsche Fährten.


    Mit den genannten Modifikationen funktioniert folgende Start-Sequenz

    systemctl enable gpsd.service ; systemctl start gpsd.service
    bei dem das Setzen des Ports in file:///etc/sysconfig/gpsd ignoriert wird.


    Das Starten mittels uDev gelang mir bisher nicht. Ich konnte zwar beobachten, dass das korrekte Kommando aufgerufen wurde, dann aber der Start abbrach.
    Interaktiv hat die von uDev generierte Kommandozeile funktioniert, nicht aber beim Einstecken, obwohl die gleiche Zeile gestartet worden war.
    Ich halte es für möglich, dass der ModemManager hier seine Finger im Spiel hat. Falls dies jemand lösen könnte, wäre mir diese Art des Starts erheblich lieber.


    Vielen Dank an meine Sparringspartner Sauerland und Berichtigung, die mich immer wieder in die richtige Richtung geschubst haben.


    Ich würde es gerne sehen, wenn diese Erkenntnisse in das Paket einfließen könnten. Ich wäre bereit das Paket zu aktualisieren, falls dies gewünscht wird.
    Leider weiß ich nicht, wie ich mich da sinnvoll einbringe.


    Andersfalls müsst ihr jedes Mal hier nachlesen, welche Kleinigkeiten angepasst werden müssen.


    Alles
    Anders


    Tipp: Wer Tippfehler findet darf sie behalten. Aber vielleicht gibt einer die fehlenden Kommata wieder zurück. ;)

  • Konfiguration des gpsd

    Habe ich hier gemacht, was Du möchtest ?

  • Konfiguration des gpsd

    Du hast recht, es waren die falschen Seiten.


    Aber ich glaube, auch die Datei aus dem openSUSE Paket ist an dieser Stelle falsch. Die anderen bei mir installierten Pakete verwenden teilweise die alte Notation ATTR und teilweise die neue Notation ATTRS.
    Da diese Installation schon ein ordentliches Erbe habe (ich glaube das Image wurde als 8.x oder 9.x geboren), sind die anderen Zeilen mit ATTR möglicherweise ererbt und nutzlos.
    In diesem Fall ist die korrekte Syntax für mich sicher diese

    Code
    KERNEL=="ttyACM*", ATTRS{idVendor}=="1546", ATTRS{idProduct}=="01a7", RUN="gpsd.sh"




    (Die anderen Zeilen in dem Paket müssen eventuell auch entsprechend korrigiert werden.)
    Zur Fehlersuche verwendete ich udevadm test /sys/class/tty/ttyACM0. Das Script gpsd.sh wurde nur in der angegebenen Form, nicht in der alten registriert.
    Nun ist endlich der vollständige Satz der Dateien vorhanden, die ich nach dem Lesen des Skripts erwartet hätte:


    Code: /var/run/gpsd.*
    # ls -lstr /var/run/gpsd.*
0 srwxr-xr-x 1 root root  0 Feb 27 21:09 /var/run/gpsd.socket
4 -rw-r--r-- 1 root root 13 Feb 27 21:09 /var/run/gpsd.device
0 srw------- 1 root root  0 Feb 27 21:09 /var/run/gpsd.sock




    Danke für den Tipp mit dem Socket. Der richtige Socket wird nämlich nur generiert, während das Device angelegt wird.



    Sorry, aber mich bringt das nicht wirklich weiter ... aber vielleicht siehst Du das anders.




    Das gpsd.sh-Skript aus dem Paket soll den Dienst eigentlich starten (dachte ich). Jetzt möchte ich sehen, was wirklich passiert.
    dmesg ist zu knapp, also das system log ansehen während ich das USB-Gerät entferne und 5 Sekunden später wieder einstecke.
    Das Log passt leider nicht mehr hierher (Limit sind 10kB).

  • Konfiguration des gpsd

    Die korrekte Modifikation der oben genannten Zeile wäre

    Zitat von anders noergler

    KERNEL=="ttyACM*", ATTR{idVendor}=="1546", ATTR{idProduct}=="01a7", RUN="gpsd.sh"

    Dies entspricht der Dokumentation unter Writing udev rules
    Dort kann auch nachgelesen werden, dass diese Attribute nur bei erfolgreicher AND-Verknüpfung aktiv sind.

  • Konfiguration des gpsd

    OK, Paket gelöscht (keine der Dateien war mehr da) und neu installiert, dann nach Anleitung versucht:

    Code
    # systemctl enable gpsd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/gpsd.service to /usr/lib/systemd/system/gpsd.service.
Created symlink from /etc/systemd/system/sockets.target.wants/gpsd.socket to /usr/lib/systemd/system/gpsd.socket.
miyamoto:~ # systemctl start gpsd.service
A dependency job for gpsd.service failed. See 'journalctl -xe' for details.

    Die Unit-Files (es sind 3 Dateien des Pakets im file:///usr/lib/systemd/service/) habe ich gelesen. Deshalb diesen chronyd als mögliche Dependency gestartet.
    Ich habe aber hier KEIN Script geschrieben.



    Die Datei file:///usr/lib/udev/gpsd.sh ist Teil des Paketes gpsd.


    Warum geht das jetzt nicht ?
    Was bedeutet "The result is dependency", bzw. welche ?

  • Konfiguration des gpsd

    Hi,
    eigentlich ist alles ganz einfach:
    - U-Blox GPS Empfänger mit USB-Anschluss gekauft
    - angesteckt und Infos ausgelesen mit lsusb: ID 1546:01a7 U-Blox AG
    - nachsehen (und wer will etwas nachgetragen in file:///usr/share/usb.ids) (Referenz in man page von lsusb)
    - das Kernel-Modul cdc_acm wurde automatisch geladen (prüfe mit lsmod|grep acm)
    - und im dmesg finden sich die Zeilen:

    Code
    usb 9-5: New USB device found, idVendor=1546, idProduct=01a7
usb 9-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 9-5: Product: u-blox 7 - GPS/GNSS Receiver
usb 9-5: Manufacturer: u-blox AG - www.u-blox.com
[...]
cdc_acm 9-5:1.0: ttyACM0: USB ACM device
usbcore: registered new interface driver cdc_acm


    - Das Device file:///dev/ttyACM0 gibt es und es hat die richtigen Berechtigungen.
    - Bei den ersten Bearbeitungsversuchen war das USB-Modul sehr schweigsam.
    Nach einiger Zeit begann es munter grün zu blinken und auch zu texten: cat /dev/ttyACM0
    - Nächste Station auf dem Weg zum Netzwerkdienst zypper install gpsd
    - minimalistisches Starten des daemons gpsd /dev/ttyACM0
    - mit Kontroll-Socket und explizit angegebenem Default-port gpsd -F /var/run/gpsd.sock -S 2947 -G /dev/ttyACM0
    - Testen mit Anwendung xgps (im Paket "gpsd-clients")
    - Nachsehen wie der Start lief: netstat -tan und feststellen, dass der Daemon nur ohne {tt]-G[/tt] local und auf IPv4 läuft:
    tcp 0 0 127.0.0.1:2947 0.0.0.0:* LISTEN  
    und mit -G ist er auch von anderen Systemen abrufbar sowohl über IPv4 wie auch über IPv6:
    tcp 0 0 0.0.0.0:2947 0.0.0.0:* LISTEN  
    tcp 0 0 :::2947 :::* LISTEN
    - Konfigurieren wie man das seit 20 Jahren SuSE eben so macht in file:///etc/sysconfig/gpsd sind 3 Einträge (Kommentare gelöscht)

    Code
    GPSD_STARTBYUDEV="no"                                                                                                                                                                                                                                                         
GPSD_PORT=
GPSD_OPTIONS=""


    Hier beginnen meine Problemchen:
    - Ändern von no auf yes, ändert zwar die Datei, ergibt aber keinen Hotplug-Service. Das USB-Gerät wird erkannt, das Kernel-Modul und das tty geladen. Das war es.
    - Also mit rpm -ql gpsd die Dateien des Paketes erfragt:
    - Es gibt wohl den Dienst service mit Dateien unter file:///usr/lib/systemd/system/
    - und den mit "yes" vermeindlich aktivierten Hotplug-dienst uDev unter file:///usr/lib/udev/




    Erster Anlauf mit uDev:


    - in der Datei file:///usr/lib/udev/rules.d/51-gpsd.rules fehlt der passende Eintrag, also aus Unwissenheit, ob ttyUSB* wörtlich zu nehmen ist:

    Code
    # U-Blox AG
KERNEL=="ttyACM*", ATTR{idVendor}=="1546", ATTR{idProduct}=="01a7", RUN="gpsd.sh"
KERNEL=="ttyUSB*", ATTR{idVendor}=="1546", ATTR{idProduct}=="01a7", RUN="gpsd.sh"

    - in der vermutlich aufgerufenen Datei file:///usr/lib/udev/gpsd.sh


    + resultiert die Variable DEVNAME vermutlich aus der Übergabe


    + es kann wohl nur ein USB-Device damit gleichzeitig aktiv sein
    - Nach ein bisschen Lesen fällt das Kommando gpsdctl (mit 'd') im Paket auf:

    Code
    # ps ax | grep gps
  861 pts/5    S+     0:00 grep --color=auto gps
# gpsdctl add /dev/ttyACM0
# ps ax | grep gps
  864 ?        S<s    0:00 gpsd -F /var/run/gpsd.sock
  867 pts/5    S+     0:00 grep --color=auto gps
# gpsdctl remove /dev/ttyACM0
# ps ax | grep gps
  864 ?        S<s    0:00 gpsd -F /var/run/gpsd.sock
  867 pts/5    S+     0:00 grep --color=auto gps

    - Eher ein Streifschuss, denn egal ob in der file;///etc/sysconfig/gpsd auf yes oder no steht, es fehlt der "DEVNAME". Und beenden funktioniert auch nicht.
    - Auskommentieren der beiden Zeilen oben in file:///usr/lib/udev/rules.d/51-gpsd.rules ändert nichts am Ergebnis.



    Nun zum zweiten Anlauf mit service:


    Code
    # /usr/sbin/rcgpsd start
A dependency job for gpsd.service failed. See 'journalctl -xe' for details.
# service gpsd start
A dependency job for gpsd.service failed. See 'journalctl -xe' for details.
# service gpsd status
● gpsd.service - GPS (Global Positioning System) Daemon
   Loaded: loaded (/usr/lib/systemd/system/gpsd.service; disabled; vendor preset: disabled)
   Active: inactive (dead)

    Den in den Dateien erwähnten Dienst chronyd habe ich testweise installiert und gestartet, ohne Änderung am Ergebnis.


    Hier wäre mir eine Hilfestellung recht.


    Ich habe das Gefühl, je nach Distribution und Kalendermonat ändert sich dieser Konfigurationsteil recht stark,
    während die Qualität der Fehlereingrenzung aus meiner Sicht sub omni canone ist (unter jedem Standard/Kanon).


    Wie kann ich den gpsd als Systemdienst im Rahmen der Standard-Installation starten?
    Bitte: Erklären, was wo warum geändert werden muss. (Die Doku werde ich dann trotzdem noch lesen.)