Je l'ai mise dans un fichier 99-LS9000.rules sous /etc/udev/rules.d.
Le problème face auquel je suis est que le groupe "nikon" est bien pris en
compte, ainsi que le lien :
crw------- 1 nth nikon 21, 4 avr 30 16:04 /dev/sg4
lrwxrwxrwx 1 root root 3 avr 30 16:09 /dev/ls9000 -> sg4
mais pas le mode ce qui m'empêche de gérer à distance le scanner sous mon
compte.
Je me suis posé la question si le /dev/fw1 pouvait avoir une influence et
j'ai donc ajouté une règle pour que /dev/fw1 soit en 0660 root nikon et
celle-là marche ; cependant celà ne règle rien. (faut il éventuellement la
conserver ?)
Je l'ai mise dans un fichier 99-LS9000.rules sous /etc/udev/rules.d.
Le problème face auquel je suis est que le groupe "nikon" est bien pris en compte, ainsi que le lien : crw------- 1 nth nikon 21, 4 avr 30 16:04 /dev/sg4 lrwxrwxrwx 1 root root 3 avr 30 16:09 /dev/ls9000 -> sg4
mais pas le mode ce qui m'empêche de gérer à distance le scanner sous mon compte.
Que sort la commande :
udevtest /sys/class/scsi_generic/sg4
?
Stéphan Peccini wrote in message <k8ahg4-a8m.ln1@photonature.fr>:
Pour cela j'ai créé un compte nikon dans lequel j'ai mis les deux
utilisateurs qui se serviront du scanner et j'ai créé la règle udev
suivante :
Je l'ai mise dans un fichier 99-LS9000.rules sous /etc/udev/rules.d.
Le problème face auquel je suis est que le groupe "nikon" est bien pris en
compte, ainsi que le lien :
crw------- 1 nth nikon 21, 4 avr 30 16:04 /dev/sg4
lrwxrwxrwx 1 root root 3 avr 30 16:09 /dev/ls9000 -> sg4
mais pas le mode ce qui m'empêche de gérer à distance le scanner sous mon
compte.
Je l'ai mise dans un fichier 99-LS9000.rules sous /etc/udev/rules.d.
Le problème face auquel je suis est que le groupe "nikon" est bien pris en compte, ainsi que le lien : crw------- 1 nth nikon 21, 4 avr 30 16:04 /dev/sg4 lrwxrwxrwx 1 root root 3 avr 30 16:09 /dev/ls9000 -> sg4
mais pas le mode ce qui m'empêche de gérer à distance le scanner sous mon compte.
Que sort la commande :
udevtest /sys/class/scsi_generic/sg4
?
Stéphan Peccini
Sur fr.comp.os.linux.configuration, Nicolas George s'est exprimé ainsi :
Que sort la commande :
udevtest /sys/class/scsi_generic/sg4
J'ai essayé de passer ma carte Firewire sur mon PC sous FC6 (sg4 est devenu sg8) et je pense avoir trouvé le problème (enfin par rapport à ma compréhension) :
dans le fichier 50-udev.rules, j'ai la ligne suivante : ACTION=="add", KERNEL=="sg[0-9]*", BUS=="scsi", SYSFS{type}=="[36]", SYMLINK+="scanner scanner-%k", MODE="0660"
Si je transforme cette ligne en limitant sg[0-7], mon fichier sg8 prend bien les bons droits grâce à mon fichier 99-LS9000.rules. Par contre je dois forcer l'owner pour retrouver mon compte.
Tout cela n'est vraiment pas bien propre. Il doit exister une solution correcte pour arriver au résultat.
Sinon, la commande udevtest ne me donne rien : [ rules.d]# udevtest /sys/class/scsi_generic/sg8 main: unable to open '/sys/class/scsi_generic/sg8' [ rules.d]#
J'ai regardé dans le répertoire (sg8 est un répertoire) et je ne vois pas ce que je peux tester.
-- Stéphan Peccini <URL:http://photonature.fr>
Sur fr.comp.os.linux.configuration, Nicolas George s'est exprimé ainsi :
Que sort la commande :
udevtest /sys/class/scsi_generic/sg4
J'ai essayé de passer ma carte Firewire sur mon PC sous FC6 (sg4 est devenu
sg8) et je pense avoir trouvé le problème (enfin par rapport à ma
compréhension) :
dans le fichier 50-udev.rules, j'ai la ligne suivante :
ACTION=="add", KERNEL=="sg[0-9]*", BUS=="scsi", SYSFS{type}=="[36]",
SYMLINK+="scanner scanner-%k", MODE="0660"
Si je transforme cette ligne en limitant sg[0-7], mon fichier sg8 prend bien
les bons droits grâce à mon fichier 99-LS9000.rules. Par contre je dois
forcer l'owner pour retrouver mon compte.
Tout cela n'est vraiment pas bien propre. Il doit exister une solution
correcte pour arriver au résultat.
Sinon, la commande udevtest ne me donne rien :
[root@tesenca rules.d]# udevtest /sys/class/scsi_generic/sg8
main: unable to open '/sys/class/scsi_generic/sg8'
[root@tesenca rules.d]#
J'ai regardé dans le répertoire (sg8 est un répertoire) et je ne vois pas ce
que je peux tester.
Sur fr.comp.os.linux.configuration, Nicolas George s'est exprimé ainsi :
Que sort la commande :
udevtest /sys/class/scsi_generic/sg4
J'ai essayé de passer ma carte Firewire sur mon PC sous FC6 (sg4 est devenu sg8) et je pense avoir trouvé le problème (enfin par rapport à ma compréhension) :
dans le fichier 50-udev.rules, j'ai la ligne suivante : ACTION=="add", KERNEL=="sg[0-9]*", BUS=="scsi", SYSFS{type}=="[36]", SYMLINK+="scanner scanner-%k", MODE="0660"
Si je transforme cette ligne en limitant sg[0-7], mon fichier sg8 prend bien les bons droits grâce à mon fichier 99-LS9000.rules. Par contre je dois forcer l'owner pour retrouver mon compte.
Tout cela n'est vraiment pas bien propre. Il doit exister une solution correcte pour arriver au résultat.
Sinon, la commande udevtest ne me donne rien : [ rules.d]# udevtest /sys/class/scsi_generic/sg8 main: unable to open '/sys/class/scsi_generic/sg8' [ rules.d]#
J'ai regardé dans le répertoire (sg8 est un répertoire) et je ne vois pas ce que je peux tester.
-- Stéphan Peccini <URL:http://photonature.fr>
Nicolas George
Stéphan Peccini wrote in message :
J'ai essayé de passer ma carte Firewire sur mon PC sous FC6 (sg4 est devenu sg8) et je pense avoir trouvé le problème (enfin par rapport à ma compréhension) :
dans le fichier 50-udev.rules, j'ai la ligne suivante : ACTION=="add", KERNEL=="sg[0-9]*", BUS=="scsi", SYSFS{type}=="[36]", SYMLINK+="scanner scanner-%k", MODE="0660"
Si je transforme cette ligne en limitant sg[0-7], mon fichier sg8 prend bien les bons droits grâce à mon fichier 99-LS9000.rules. Par contre je dois forcer l'owner pour retrouver mon compte.
Que se passe-t-il si tu numérotes le fichier 00 plutôt que 99 ? J'ai l'impression que l'ordre de priorité des règles dépend de la version d'udev.
Sinon, la commande udevtest ne me donne rien : [ rules.d]# udevtest /sys/class/scsi_generic/sg8 main: unable to open '/sys/class/scsi_generic/sg8' [ rules.d]#
J'ai regardé dans le répertoire (sg8 est un répertoire) et je ne vois pas ce que je peux tester.
Il reste la solution strace pour savoir où ça échoue.
Tu peux aussi essayer « udevcontrol log_priorityÞbug » et regarder quelles règles udev applique.
Stéphan Peccini wrote in message <ktqhg4-qu9.ln1@photonature.fr>:
J'ai essayé de passer ma carte Firewire sur mon PC sous FC6 (sg4 est devenu
sg8) et je pense avoir trouvé le problème (enfin par rapport à ma
compréhension) :
dans le fichier 50-udev.rules, j'ai la ligne suivante :
ACTION=="add", KERNEL=="sg[0-9]*", BUS=="scsi", SYSFS{type}=="[36]",
SYMLINK+="scanner scanner-%k", MODE="0660"
Si je transforme cette ligne en limitant sg[0-7], mon fichier sg8 prend bien
les bons droits grâce à mon fichier 99-LS9000.rules. Par contre je dois
forcer l'owner pour retrouver mon compte.
Que se passe-t-il si tu numérotes le fichier 00 plutôt que 99 ? J'ai
l'impression que l'ordre de priorité des règles dépend de la version d'udev.
Sinon, la commande udevtest ne me donne rien :
[root@tesenca rules.d]# udevtest /sys/class/scsi_generic/sg8
main: unable to open '/sys/class/scsi_generic/sg8'
[root@tesenca rules.d]#
J'ai regardé dans le répertoire (sg8 est un répertoire) et je ne vois pas ce
que je peux tester.
Il reste la solution strace pour savoir où ça échoue.
Tu peux aussi essayer « udevcontrol log_priorityÞbug » et regarder quelles
règles udev applique.
J'ai essayé de passer ma carte Firewire sur mon PC sous FC6 (sg4 est devenu sg8) et je pense avoir trouvé le problème (enfin par rapport à ma compréhension) :
dans le fichier 50-udev.rules, j'ai la ligne suivante : ACTION=="add", KERNEL=="sg[0-9]*", BUS=="scsi", SYSFS{type}=="[36]", SYMLINK+="scanner scanner-%k", MODE="0660"
Si je transforme cette ligne en limitant sg[0-7], mon fichier sg8 prend bien les bons droits grâce à mon fichier 99-LS9000.rules. Par contre je dois forcer l'owner pour retrouver mon compte.
Que se passe-t-il si tu numérotes le fichier 00 plutôt que 99 ? J'ai l'impression que l'ordre de priorité des règles dépend de la version d'udev.
Sinon, la commande udevtest ne me donne rien : [ rules.d]# udevtest /sys/class/scsi_generic/sg8 main: unable to open '/sys/class/scsi_generic/sg8' [ rules.d]#
J'ai regardé dans le répertoire (sg8 est un répertoire) et je ne vois pas ce que je peux tester.
Il reste la solution strace pour savoir où ça échoue.
Tu peux aussi essayer « udevcontrol log_priorityÞbug » et regarder quelles règles udev applique.
Stéphan Peccini
Sur fr.comp.os.linux.configuration, Nicolas George s'est exprimé ainsi :
Que se passe-t-il si tu numérotes le fichier 00 plutôt que 99 ? J'ai l'impression que l'ordre de priorité des règles dépend de la version d'udev.
Il me semble avoir fait cet essai sous FC7 mais pas FC6. J'essaye demain.
Il reste la solution strace pour savoir où ça échoue.
Pourquoi pas :-)
Tu peux aussi essayer « udevcontrol log_priorityÞbug » et regarder quelles règles udev applique.
Pareil, demain je fais l'essai. Merci.
-- Stéphan Peccini <URL:http://photonature.fr>
Sur fr.comp.os.linux.configuration, Nicolas George s'est exprimé ainsi :
Que se passe-t-il si tu numérotes le fichier 00 plutôt que 99 ? J'ai
l'impression que l'ordre de priorité des règles dépend de la version
d'udev.
Il me semble avoir fait cet essai sous FC7 mais pas FC6. J'essaye demain.
Il reste la solution strace pour savoir où ça échoue.
Pourquoi pas :-)
Tu peux aussi essayer « udevcontrol log_priorityÞbug » et regarder
quelles règles udev applique.
Sur fr.comp.os.linux.configuration, Nicolas George s'est exprimé ainsi :
Que se passe-t-il si tu numérotes le fichier 00 plutôt que 99 ? J'ai l'impression que l'ordre de priorité des règles dépend de la version d'udev.
Il me semble avoir fait cet essai sous FC7 mais pas FC6. J'essaye demain.
Il reste la solution strace pour savoir où ça échoue.
Pourquoi pas :-)
Tu peux aussi essayer « udevcontrol log_priorityÞbug » et regarder quelles règles udev applique.
Pareil, demain je fais l'essai. Merci.
-- Stéphan Peccini <URL:http://photonature.fr>
Stéphan Peccini
Sur fr.comp.os.linux.configuration, Nicolas George s'est exprimé ainsi :
Que sort la commande : udevtest /sys/class/scsi_generic/sg4
En fait il fallait taper (après changement de sg4 en sg8): udevtest /class/scsi_generic/sg8
C'est ce qui m'a permis de trouver la solution. Merci.
Ce que j'obtiens permet de voir qu'à la fin des opérations, il est appliqué : /sbin/pam_console_apply /dev/sg8
C'est cette commande qui remet les droits à 0600 en se basant sur le fait que : /var/run/console.lock n'existe pas et en allant chercher les droits à appliquer dans /etc/security/console.perms, qui par défaut sont à 0600.
Il faut alors créer un fichier : /etc/security/console.perms.d/99-LS9000.perms contenant :
# device classes -- these are shell-style globs <scanner>=/dev/sg[0-9]* # permission definitions <console> 0660 <scanner> 0660
en plus du fichier : /etc/udev/rules.d/99-LS9000.rules contenant :
Avec cela, tout fonctionne bien à la détection du scanner :
[ ~]$ ls -l /dev/ls9000 lrwxrwxrwx 1 root root 3 mai 1 08:00 /dev/ls9000 -> sg8 [ ~]$ ls -l /dev/sg8 crw-rw---- 1 spc nikon 21, 8 mai 1 08:00 /dev/sg8
Je peux maintenant utiliser Vuescan en toute tranquilité et abandonner Windows pour la partie scanner ; il ne me reste plus que le GPS pour la partie carte GPS Topo qui ne marche que sous Windows (toute la partie utilisation des résultats se faisant avec GPS Manager que je préfère à Map Source).
-- Stéphan Peccini <URL:http://photonature.fr>
Sur fr.comp.os.linux.configuration, Nicolas George s'est exprimé ainsi :
Que sort la commande :
udevtest /sys/class/scsi_generic/sg4
En fait il fallait taper (après changement de sg4 en sg8):
udevtest /class/scsi_generic/sg8
C'est ce qui m'a permis de trouver la solution. Merci.
Ce que j'obtiens permet de voir qu'à la fin des opérations, il est
appliqué :
/sbin/pam_console_apply /dev/sg8
C'est cette commande qui remet les droits à 0600 en se basant sur le fait
que :
/var/run/console.lock n'existe pas
et en allant chercher les droits à appliquer
dans /etc/security/console.perms, qui par défaut sont à 0600.
Il faut alors créer un fichier :
/etc/security/console.perms.d/99-LS9000.perms
contenant :
# device classes -- these are shell-style globs
<scanner>=/dev/sg[0-9]*
# permission definitions
<console> 0660 <scanner> 0660
en plus du fichier :
/etc/udev/rules.d/99-LS9000.rules
contenant :
Avec cela, tout fonctionne bien à la détection du scanner :
[spc@tesenca ~]$ ls -l /dev/ls9000
lrwxrwxrwx 1 root root 3 mai 1 08:00 /dev/ls9000 -> sg8
[spc@tesenca ~]$ ls -l /dev/sg8
crw-rw---- 1 spc nikon 21, 8 mai 1 08:00 /dev/sg8
Je peux maintenant utiliser Vuescan en toute tranquilité et abandonner
Windows pour la partie scanner ; il ne me reste plus que le GPS pour la
partie carte GPS Topo qui ne marche que sous Windows (toute la partie
utilisation des résultats se faisant avec GPS Manager que je préfère à Map
Source).
Sur fr.comp.os.linux.configuration, Nicolas George s'est exprimé ainsi :
Que sort la commande : udevtest /sys/class/scsi_generic/sg4
En fait il fallait taper (après changement de sg4 en sg8): udevtest /class/scsi_generic/sg8
C'est ce qui m'a permis de trouver la solution. Merci.
Ce que j'obtiens permet de voir qu'à la fin des opérations, il est appliqué : /sbin/pam_console_apply /dev/sg8
C'est cette commande qui remet les droits à 0600 en se basant sur le fait que : /var/run/console.lock n'existe pas et en allant chercher les droits à appliquer dans /etc/security/console.perms, qui par défaut sont à 0600.
Il faut alors créer un fichier : /etc/security/console.perms.d/99-LS9000.perms contenant :
# device classes -- these are shell-style globs <scanner>=/dev/sg[0-9]* # permission definitions <console> 0660 <scanner> 0660
en plus du fichier : /etc/udev/rules.d/99-LS9000.rules contenant :
Avec cela, tout fonctionne bien à la détection du scanner :
[ ~]$ ls -l /dev/ls9000 lrwxrwxrwx 1 root root 3 mai 1 08:00 /dev/ls9000 -> sg8 [ ~]$ ls -l /dev/sg8 crw-rw---- 1 spc nikon 21, 8 mai 1 08:00 /dev/sg8
Je peux maintenant utiliser Vuescan en toute tranquilité et abandonner Windows pour la partie scanner ; il ne me reste plus que le GPS pour la partie carte GPS Topo qui ne marche que sous Windows (toute la partie utilisation des résultats se faisant avec GPS Manager que je préfère à Map Source).
