Clement33 a écrit 40 commentaires

[^] # Re: udev, ses rules et les /dev/input

Posté par Clement33 le 29 novembre 2011 à 10:25. En réponse au message Multiseat : assigner un port USB à un siège. Évalué à 0.

Je le partagerai une fois qu'il sera un peu plus "propre" ;) .

Ah en effet, j'ai pas encore testé avec des logins un peu long, comme des logins de domaine... Je vais tester ;) .

Pour Nautilus, je n'ai que des RedHat + Gnome, ou Debian + Gnome, donc ce n'est pas génant pour ma part. Mais tu dois pouvoir faire la même chose avec Thunar par exemple. Tout ce que je fais, c'est un simple "DISPLAY=:0 nautilus /media/sdh1".

Pour /dev/sda, à priori non, car il est monté via fstab. La règle udev ne s'applique qu'aux nouveaux périphériques qui viennent d'être branchés, et comme sda est monté via fstab, cela ne s'applique pas à lui. En tout cas, mon script monte tout dans /media/, je l'aurais vu si j'avais un /media/sda1, /media/sda2, ...
[^] # Re: udev, ses rules et les /dev/input

Posté par Clement33 le 28 novembre 2011 à 13:11. En réponse au message Multiseat : assigner un port USB à un siège. Évalué à 1. Dernière modification le 28 novembre 2011 à 13:21.
Voilà ou j'en suis les amis.

J'ai une règle UDEV qui vérifie le périphérique entré (sd*), et qui lance un exécutable :

KERNEL=="sd*", PROGRAM="/usr/bin/who_owns_usb %k"

Ensuite, mon exécutable gère les choses suivantes :
- Récupération de l'id usb via "udevadm info -q path -n /dev/sdh1"
- Récupération de "quel user est sur quel siège" via la commande "w"
- Je compare l'id du port (1-5, 1-6) et je l'assigne à tel siège
- Si /media/sdh1 existe, c'est que la clé est branchée, donc je démonte et je vire /media/sdh1
- Si /media/sdh1 existe pas, c'est qu'on vient de brancher la clé, donc je créé /media/sdh1, et je monte (via pmount) /dev/sdh1 pour l'utilisateur associé.
- Dans la foulée, je lance aussi nautilus pour avoir l'effet "pluganplay".
Qu'en dites-vous ?
[^] # Re: udev, ses rules et les /dev/input

Posté par Clement33 le 25 novembre 2011 à 13:04. En réponse au message Multiseat : assigner un port USB à un siège. Évalué à 0.
Ouais, jouer avec gvfs, ça peut le faire.

Bon, j'ai identité mes périphériques usb comme suit :

J'ai exécuté cette commande :
```
lsusb -v | grep iSerial
```
Qui me renvoie ceci les ID usb il me semble :
```
  iSerial                 1 0000:00:1d.2
  iSerial                 1 0000:00:1d.1
  iSerial                 1 0000:00:1d.0
  iSerial                 1 0000:00:1a.2
  iSerial                 1 0000:00:1a.1
  iSerial                 1 0000:00:1a.0
  iSerial                 1 0000:00:1d.7
  iSerial                 1 0000:00:1a.7
```
Ce qui correspond bien à mes ports USB : 6 derrière, et 2 en facade.

J'ai attaqué ma règle udev :
```
BUS="usb", ATTR{ ...
```
J'ai bien trouvé comment prendre en référence le nom de ce qui va être monté (KERNEL="sdh1"), mais je vois pas comment utiliser mes ID usb dans mes règles udev.

Quelqu'un qui en a déjà fait peut-il me renseigner ?
[^] # Re: udev, ses rules et les /dev/input

Posté par Clement33 le 24 novembre 2011 à 13:14. En réponse au message Multiseat : assigner un port USB à un siège. Évalué à 1.

Bon, via lsusb j'ai réussi à identifier mes 9 ports USB. J'ai leur id du type "1d6b:0002". J'ai des doublons, mais si je compte uniquement les ID en écartant les doublons, j'ai bien 9 ID, donc 9 ports.

Maintenant, je dois créer des règles udev pour assigner un port USB à un /dev/usb1 par exemple. Là, ok, j'ai trouvé comment faire sur internet.

Maintenant, comme tu disais, je peux lier un clavier, une souris, ou encore un gamepad à mon seat via les sections "InputDevice", je l'ai déjà fait. Mais concernant les ports USB, ce n'est pas géré par Xorg il me semble.

Une autre solution consisterait à désactiver l'automount de Nautilus, et de mettre en place un script (via udev) de montage perso qui vérifierait l'ID du port USB et qui le monterait pour le bon utilisateur... Jouable ?
[^] # Re: udev, ses rules et les /dev/input

Posté par Clement33 le 24 novembre 2011 à 10:24. En réponse au message Multiseat : assigner un port USB à un siège. Évalué à 1.

Sytoka Modon a tout dit. L'objectif n'est pas d'identifier le fabricant ou n'importe quoi, mais de dire "tel port USB à gauche ira au siège A, et tel port USB sur la droite ira au siège B". Pour cela, je dois identifier les ports USB et pouvoir dire "toi, je t'assigne ce port, il n'y a que toi qui aura accès aux périphériques USB insérés sur ce port".

@NeoX : j'utilise bien les sections de Xorg, et j'ai déjà assigné 2 claviers et 2 souris dans mes sections, ça marche bien. Mais je pense pas pouvoir faire pareil pour les périphériques USB...
[^] # Re: udev, ses rules et les /dev/input

Posté par Clement33 le 23 novembre 2011 à 15:27. En réponse au message Multiseat : assigner un port USB à un siège. Évalué à 1.

C'est ce que je pensais faire, mais il y a 2 choses qui me turlupinent :

Comment reconnaître les ports USB ? Je vois pas comment préciser "tel port USB" dans mon 50-usb-seat.rules, je l'assigne à /dev/portusb1

Dans le Xorg, comment je précise que /dev/portusb1 n'appartient à mon seat0 ou mon seat1 ? Dans quelle section ? Car j'ai bien des "Section InputDevice", mais je vois pas quoi en faire hormis préciser que ce sont un clavier ou une souris...
[^] # Re: ckeck install

Posté par Clement33 le 14 septembre 2011 à 15:18. En réponse au message Packager nvidia.run en deb. Évalué à 1.

C'est ce que j'ai fait finalement, j'ai créé un Deb qui lance le .run via le fichier preinst.

L'ennui, c'est que la sortie ne se fait pas. Si le .run renvoie une erreur, dpkg me dit qu'il y'a eu une erreur de type 127 dans preinst.

Comment puis-je avoir directement la sortie du nvidia.run sur dpkg ? En cas d'erreur, la sortie de Nvidia.run sera très utile...
[^] # Re: ckeck install

Posté par Clement33 le 13 septembre 2011 à 14:44. En réponse au message Packager nvidia.run en deb. Évalué à 1.

En fait, je compile rien du tout.

Le .run s'occupe de tout, il modifie le kernel pour l'adapter au pilote, et installe ce dernier. De mon coté, je ne fais que lancer l'installeur.

Le .run dispose de commande quand je lance un -h. L'idée serait de lancer la commande adéquate pour lancer le run, et le tout dans un .deb...
[^] # Re: Non-free ?

Posté par Clement33 le 13 septembre 2011 à 14:24. En réponse au message Packager nvidia.run en deb. Évalué à 0.

Ouais je sais, mais dans tous les cas, Jeoffrey54 a raison, le but pour moi est d'en faire un deb =/.
[^] # Re: sed/grep sur le bon fichier

Posté par Clement33 le 05 septembre 2011 à 11:49. En réponse au message Forcer le verrouillage de l'écran de veille sous Gnome. Évalué à 0.

C'est ce que je viens de faire, j'ai activé l'option de protection par mot de passe à la sortie d'écran de veille, et j'ai affiché les fichiers modifiés au cours des 2 dernières minutes :

/home/clement33/.viminfo
/home/clement33/.gconfd/saved_state
/home/clement33/.xsession-errors

Dans saved_state, ce n'est pas exploitable, c'est bourré de numéros, lettres, ...
[^] # Re: sed/grep sur le bon fichier

Posté par Clement33 le 05 septembre 2011 à 11:15. En réponse au message Forcer le verrouillage de l'écran de veille sous Gnome. Évalué à -1.

Justement, je ne parviens pas à trouver dans quel fichier on règle cette option =/.
[^] # Re: pb résolution de nom côté client ?

Posté par Clement33 le 24 août 2011 à 11:44. En réponse au message Configuration du proxy Squid. Évalué à 0.

Non, même pas.

Problème résolu en farfouillant un peu partout, il suffit d'ajouter cette directive:

cache_peer 192.168.1.2 parent 8080 0 proxy-only no-query

Où 192.168.1.2 est le proxy parent à traverser.
[^] # Re: kernel.log, uptime

Posté par Clement33 le 08 juillet 2011 à 16:41. En réponse au message Serveur qui reboot : raison ?. Évalué à -2.

Ces disques sont montés en cciss...

J'ai Zabbix qui monitore mes serveurs, et il ne m'a juste indiqué que mon serveur était indisponible pendant 4 ou 5 minutes...

Aucun autre moyen de voir clairement ce qui s'est passé ? :S

[^] # Re: kernel.log, uptime

Posté par Clement33 le 08 juillet 2011 à 14:44. En réponse au message Serveur qui reboot : raison ?. Évalué à -1.

Comme je l'ai dit plus haut, l'uptime est de 21 heures, donc il a bien rebooté...

Et dans /var/log/kern.log, j'ai ceci :

    Jul  6 00:10:32 zimbra kernel: [  127.253773] NFSD: starting 90-second grace period
    Jul  6 00:10:34 zimbra kernel: [  128.977521] bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex
    Jul  6 00:10:34 zimbra kernel: [  128.979647] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    Jul  6 00:10:37 zimbra kernel: [  133.116122]  CIFS VFS: cifs_read_super: get root inode failed
    Jul  6 00:10:45 zimbra kernel: [  141.387369] eth0: no IPv6 routers present
    Jul  6 06:25:04 zimbra kernel: imklog 3.18.6, log source = /proc/kmsg started.
    Jul  7 06:25:03 zimbra kernel: imklog 3.18.6, log source = /proc/kmsg started.
    Jul  7 15:46:38 zimbra kernel: imklog 3.18.6, log source = /proc/kmsg started.
    Jul  7 15:46:38 zimbra kernel: [    0.000000] Initializing cgroup subsys cpuset
    Jul  7 15:46:38 zimbra kernel: [    0.000000] Initializing cgroup subsys cpu
    Jul  7 15:46:38 zimbra kernel: [    0.000000] Linux version 2.6.26-2-amd64 (Debian 2.6.26-19lenny2) (dannf@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Thu Nov 5 02:23:12 UTC 2009
    Jul  7 15:46:38 zimbra kernel: [    0.000000] Command line: root=/dev/cciss/c0d0p1 ro
    Jul  7 15:46:38 zimbra kernel: [    0.000000] BIOS-provided physical RAM map:
    Jul  7 15:46:38 zimbra kernel: [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
    Jul  7 15:46:38 zimbra kernel: [    0.000000]  BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
    Jul  7 15:46:38 zimbra kernel: [    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
    Jul  7 15:46:38 zimbra kernel: [    0.000000]  BIOS-e820: 0000000000100000 - 00000000df63f000 (usable)
    Jul  7 15:46:38 zimbra kernel: [    0.000000]  BIOS-e820: 00000000df63f000 - 00000000df64c000 (ACPI data)
    Jul  7 15:46:38 zimbra kernel: [    0.000000]  BIOS-e820: 00000000df64c000 - 00000000df64d000 (usable)
    Jul  7 15:46:38 zimbra kernel: [    0.000000]  BIOS-e820: 00000000df64d000 - 00000000e4000000 (reserved)
    Jul  7 15:46:38 zimbra kernel: [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fee10000 (reserved)

Bizarrement, je n'ai rien entre 06:25 et 15:48... Et le reste des logs, on dirait qu'il démarre non ?

Concernant une intervention humaine, non, cette possibilité est écartée :S.

# Uptime

Posté par Clement33 le 08 juillet 2011 à 14:07. En réponse au message Serveur qui reboot : raison ?. Évalué à 0.

@Lol Zimmerli : Dans les logs, il y a un trou entre 15h42 et 15h46 comme je l'ai précisé dans mon premier post...

Concernant l'uptime : 14:04:29 up 21:48, 1 user, load average: 0.24, 0.19, 0.16

Donc il a bien rebooté...

@nono14 : j'ai cherché sur google, et rien concernant Hang Check, je sais pas du tout ce que c'est.