[Teranmoc]

Bonjour,

Il y a quelques temps, je suis parvenu à actionner une led via un port GPIO de la carte. J'ai voulu réitéré l'expérience mais rien ne marche !
J'utilise wiringPi pour utiliser la commande gpio dans le prompt de Raspbian en suivant ce tuto : http://blog.idleman.fr/raspberry-pi-06-u...onde-reel/

Est ce normal que les ports GPIO soient aussi capricieux ?

[sdelporte]

Non ce n'est pas logique, que te dis la commande de Wiring pi ? tu l'exécute bien en SUDO ?

[tchou]

Attention, le cablage des GPIO a changé entre le Rpi première version (la version "B" à 256Mo, fabriquée en Chine) et la seconde version ("B" aussi, mais fabriquée UK, la 512Mo).

Là, le topic que tu regarde date d'août 2012, c'était la première version de l'engin. Si tu as acheté ta carte récemment, tu as une 512Mo. Y'a pas énormément de différences, mais y'en a sur une paire de pins.

Après, si c'est un soucis sur le même code et le même cablage : multimeter to the rescue ! Ou vérifie que t'as pas cablé ta led à l'envers et qu'elle est pas en fait grillée !

[Teranmoc]

Ce qui est bizarre c'est que j'avais déjà fait un cablâge avec une led qui était contrôlée par une page web et ça marchait

edit : Bon, ça marche en root !

[Teranmoc]

Par contre, pour le faire fonctionner avec PHP, il faut mettre sudo dans la commande ?

[tchou]

Yep ! Si tu utilise déjà une commande exec() ou system(), c'est pas la mer à boire.

Oui, c'est bof. Apparemment, y'aurai moyen de tricher pour autoriser l'user courant à écrire dans les gpio. C'est étrange d'imposer cette "limitation" (tout est relatif vu que sudo ne te demande pas de passwd) sur raspbian pour un device qui t'expose ainsi ses gpio.

[Teranmoc]

Avec le sudo dans la commande ça ne marche pas alors qu'en la tapant dans le shell, ça marche.
Sinon comment faire pour les activer via PHP sans compromettre la sécurité ?

[Yaug]

Donc là c'est une question de droit des fichiers.

Va y bourrin, passe ton fichier en 777, puis retest.

Sur les tutoriels d'idleman, pas mal de monde à des problèmes dans ce genre.

[Jeoffrey]

Non, sudo ne peut pas marcher "en l'état" avec PHP.

Si vous regardez côté /etc/sudoers, vous verrez cette ligne :

Code :

pi ALL=(ALL) NOPASSWD: ALL

Cela signifie que seul l'utilisateur "pi" peut faire du sudo sans mot de passe. Si tu passes un "sudo tacommande" via PHP, ce sera exécuté en tant que www-data, et donc il te demandera un mot de passe.

Ce que je te propose, pour contourner cela, et d'autoriser www-data à faire certaines commandes en tant que root.

Par exemple, tu peux ajoutere cette ligne à /etc/sudoers :

Code :

www-data ALL= NOPASSWD: /bin/macommande monparametre

Cela autorisera www-data à lancer la commande "sudo /bin/macommande monparametre" en tant que root, et demander de mot de passe.

Remplaces www-data par l'user exécutant ta page Web (fait un exec('whoami'); en PHP dans ta page, et tu verras).

[Teranmoc]

Bizzarement, pourquoi ça ne passe pas avec sudo ?

[Jeoffrey]

Mais mais mais, tu as lu ce que j'ai mis juste au dessus ?

Dans la conf de sudo, c'est explicitement précisé que seul "pi" à le droit de lancer des commandes sudo sans mot de passe.

Vu que ton serveur n'est surement pas lancé avec l'utilisateur "pi" mais avec "www-data", c'est normal que sudo ne passe pas. Si tu ajoutes la ligne que je te donne au dessus, avec la bonne commande, tu pourras faire du sudo via ton serveur web.

[tchou]

Est-ce que forcer ton script à s'executer en tant que root ne serai pas une solution ? Via un setuid ?

[Teranmoc]

Mais mais mais, tu as lu ce que j'ai mis juste au dessus ?

Dans la conf de sudo, c'est explicitement précisé que seul "pi" à le droit de lancer des commandes sudo sans mot de passe.

Vu que ton serveur n'est surement pas lancé avec l'utilisateur "pi" mais avec "www-data", c'est normal que sudo ne passe pas. Si tu ajoutes la ligne que je te donne au dessus, avec la bonne commande, tu pourras faire du sudo via ton serveur web.

Ah d'accord tout s'explique alors (petite précision : le serveur web est NGINX ).

Par contre, j'ai dû reboot la carte hier soir, j'ai voulu testé le GPIO via la commande sudo gpio -g write 24 1 et ça ne commute pas :o alors que juste avant tout marchait.

Est ce possible qu'en rebootant, les modes (input ou output) de chaque port soient réinitialisé ?

[Jeoffrey]

Est-ce que forcer ton script à s'executer en tant que root ne serai pas une solution ? Via un setuid ?

Euh, c'est juste une "méga-faille" de sécurité ça ^^.

Autant faire les choses proprement et passer par sudo je pense...

[tchou]

Bah, globalement, si on autorise déjà un sudo sans mdp pour l'user courant "pi" et pour l'user www-data (pour ce script unique cependant et heureusement), globalement je vois mal où il peut y avoir un risque encore plus important. Les gpio sont soit branchées avec des trucs au bout, donc actionner ne va pas foutre le feu, soit avec rien au bout, donc balancer un peu de voltage pour rien alimenter, c'est pas la mort du petit cheval !

Par contre, ne pas avoir à taper sudo devant toutes les lignes de test, moi ça me dérange pas.

Notons tant que nous sommes sur le domaine de la sécurité, en parlant d'une machine hébergée sur un ndd qui commence par serveur et finit par athome (et globalement toute personne qui met un rasp' en serveur web ou whatever qui tournera h24) : songez à changer les mots de passe des users "pi" et "root", hein ! Même si l'accès ssh est désactivé depuis l'extérieur, on sait jamais !

[Teranmoc]

Tout les mots de passes ont été changé et le Raspberry est sécurisé (mon côté parano ressort )

[Uggy]

Tout les mots de passes ont été changé et le Raspberry est sécurisé (mon côté parano ressort )

Un serveur SSH "sécurisé" forcerais une authentification par clé
[email protected]'s password

[tchou]

Oh le vil ! J'avais pas tenté le coup du ssh vers cette machine !

[Jeoffrey]

Bah, globalement, si on autorise déjà un sudo sans mdp pour l'user courant "pi" et pour l'user www-data (pour ce script unique cependant et heureusement), globalement je vois mal où il peut y avoir un risque encore plus important. Les gpio sont soit branchées avec des trucs au bout, donc actionner ne va pas foutre le feu, soit avec rien au bout, donc balancer un peu de voltage pour rien alimenter, c'est pas la mort du petit cheval !

Par contre, ne pas avoir à taper sudo devant toutes les lignes de test, moi ça me dérange pas.

Notons tant que nous sommes sur le domaine de la sécurité, en parlant d'une machine hébergée sur un ndd qui commence par serveur et finit par athome (et globalement toute personne qui met un rasp' en serveur web ou whatever qui tournera h24) : songez à changer les mots de passe des users "pi" et "root", hein ! Même si l'accès ssh est désactivé depuis l'extérieur, on sait jamais !

Oui, comme tu dit, à condition que le sudo pour www-data n'autorise que ce script uniquement...

[Teranmoc]

Lorsqu'on reboote la carte, doit - on remettre les ports GPIO en in ou en out ?

[Uggy]

Lorsqu'on reboote la carte, doit - on remettre les ports GPIO en in ou en out ?

C'est a dire ?
Tu les passent en IN ou OUT suivant ton utilisation ...
Si tu ne t'en sert pas.. tu peux laisser l'état par défaut.

?

[tchou]

...mais oui, si tu redémarre ta carte alors que tu alimentait un dispositif via les gpio, c'est logique qu'il ne soit plus alimenté au reboot. Il suffit de relancer un script au démarrage (dans le init.d).

Par contre, si tu modifie dynamiquement via ton appli web, pour que les même gpio soient allumés (ou éteint) au démarrage, il faudra probablement que tu stocke ta data ailleurs qu'en SQL (ou additionnellement en plus du SQL) car ton serveur ne sera peut être pas dispo pendant le démarrage de la machine.

[Teranmoc]

J'ai deux relais connectés sur la carte, ils commutaient avant un reboot (en entrant gpio -g write 23 1). J'ai dû rebooté la Raspberry et la commande ne fonctionne plus. Je dois redéfinir les deux pins à OUT après chaque reboot ?

[tchou]

Hum ... j'aurais tendance à dire oui.

Et pour éviter d'avoir à le faire, comme dit précédemment, fais un petit script qui devra se lancer au démarrage. J'ai pas de Rpi sous la main, mais :
Dans /etc/init.d/ créer (en tant que root) un script contenant :
#! /bin/sh
gpio mode 23 out

(si c'est bien ce que tu dois faire à chaque reboot). Si le script appartient à root, tu ne devrai pas avoir besoin de sudoer.

Tu rend ce fichier executable (chmod +x).

Et tu le déclare au boot : update-rc.d [lenomdetonscript] defaults


Comme dit précédemment, si ton application nécessite de se souvenir de l'état pre-reboot, tu peux aussi le stocker dans un fichier et au reboot faire en sorte que ça soit transparent avec le même état. Ça par contre, c'est un poil plus de boulot de scripting !

[Teranmoc]

Je viens de les remettre dans l'état d'origine (donc OUT) et les sorties n'ont pas l'air de vouloir commuter
Pourtant, j'ai strictement rien changé niveau câblage 8)