• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

/dev/parport0 (nicht /dev/lp0) auf Client ansprechen?

Status
Für weitere Antworten geschlossen.
A

Anonymous

Gast
Hi,

zunächst mal ein dickes Lob für dieses Forum hier, habe u.a. anhand der Tips hier meinen LTSP Server mit einem Client innerhalb von nur zwei Tagen zum Laufen bekommen ;)

Jetzt gibt's aber eine Frage: Ich würde gerne am LTSP Client Hardware-Entwicklung betreiben, genauer gesagt einen per parport1 und/oder ttyS1 angeschlossenen Mikrocontroller über die entsprechende, auf dem Server installierte Software (PonyProg, AVR ISP...) programmieren. /dev/lp1 und dessen Weiterleitung über Port 9100 wird also wohl nicht in Frage kommen. [und bevor die Gegenfrage kommt: ttyS0 = Maus, parport0 = onboard, deaktiviert]

MODULE_01=parport und MODULE_02=parport_pc steht bereits in der ltsp.conf - nur, wo finde ich jetzt die /dev/parport1? Nach dem X-Login sehe ich unter /dev ja nur die Devices vom Server...

-Modi
 

schweer

Hacker
Modi schrieb:
MODULE_01=parport und MODULE_02=parport_pc steht bereits in der ltsp.conf - nur, wo finde ich jetzt die /dev/parport1? Nach dem X-Login sehe ich unter /dev ja nur die Devices vom Server...

-Modi
Den client im runlevel 3 starten. Ergibt automatisch eine root-shell auf dem Client. Dann lassen sich auch die devices anzeigen.
ltsp arbeitet mit dem devfs-daemon. Die Konfiguration erfolgt in den Dateien devfsd.conf und modules.devfs. Wenn dort die richtigen Einträge stehen, dann werden die entsprechenden Module beim Ansprechen eines devices geladen, die device-Einträge erzeugt und auch die Rechte der devices richtig gesetzt. Es ist überhaupt nicht notwendig, mit mknod und chown zu arbeiten (kann man aber natürlich tun, ist ja UNIX, da gibt es viele Wege).

wolfgang
 
OP
A

Anonymous

Gast
Okay, guter Tip mit devfsd.conf... Das brachte mich zum ersten Teil der Lösung meines Problems:

Habe daraufhin festgestellt, daß ppdev.o im Standard-LTSP3 Kernel gar nicht vorhanden ist, also:
- einen neuen 2.4.24er mit ppdev.o kompiliert
- MODULE_03=ppdev in die ltsp.conf
- RUNLEVEL=3 in die ltsp.conf hatte ich schon
- alias /dev/parport0 ppdev in die devfsd.conf
- von LTSP4 die glibc installiert für den AVRDude, diesen auf dem Server kopiert nach /opt/ltsp/i386/opt/cdk4avr/bin
- wenn ich jetzt am Client die /opt/cdk4avr/bin/avrdude aufrufe, kann ich auch tatsächlich per /dev/parport0 auf meinen AVR zugreifen.. *freu* :D

ABER: Der zweite Teil meines Problems ist, daß sobald ich auf runlevel 5 gehe (start_ws eingebe) und mich unter X am Terminalserver einlogge, keinen Zugriff mehr auf die lokalen /dev habe... gibt es eine Möglichkeit, über devfsd (oder per nfs-export? irgendwie?) den parport0 auf den Server zu forwarden?
 

schweer

Hacker
Anonymous schrieb:
ABER: Der zweite Teil meines Problems ist, daß sobald ich auf runlevel 5 gehe (start_ws eingebe) und mich unter X am Terminalserver einlogge, keinen Zugriff mehr auf die lokalen /dev habe... gibt es eine Möglichkeit, über devfsd (oder per nfs-export? irgendwie?) den parport0 auf den Server zu forwarden?
Sollte eigentlich mit rsh gehen. Dazu das Paket "local apps" installieren. Wenn der Zugriff nur als root erfolgen kann, hier im Forum noch mal den Thread zu "rsh als root" ansehen.

wolfgang
 

Modi

Newbie
Das Paket Local apps zu installieren, war keine so gute Idee, denn es hat mir die neueren Libraries von LTSP4 (die ich wegen glibc ja gebraucht habe) teilweise durch ältere Versionen ersetzt. Habe dann SSH und private-/public key pairs eingerichtet und kann jetzt per ssh als user oder root mit RSA Key mich einloggen und die Programmiersoftware starten (auch PonyProg mit seiner X-Oberfläche, wenn ich export DISPLAY=client_ip_adresse:0 nicht vergesse).

Ist wohl in diesem Fall tatsächlich einfacher, mit dem Programm zum Parport zu gehen, wenn schon der Parport nicht zum Programm kommt :)

Diese Anwendungen laufen dann natürlich auf der lokalen CPU, nicht auf dem Server, wie ich mir das ursprünglich vorgestellt hatte. Für den reinen Flashvorgang (nicht die Entwicklungsarbeit) ist der P133 aber auf jeden Fall schnell genug. Jetzt nur noch ein paar Skripte basteln, und irgendwie den NFS dazu bringen, ohne "Permission denied" nicht nur /home, sondern auch /opt auf den Client zu exportieren... na, das wird schon werden! [edit: /opt/ltsp/i386 auskommentieren!]

Also schonmal schweer Danke für die Hilfe!
 
Status
Für weitere Antworten geschlossen.
Oben