Discussion :

[erwannoo]

Bonjour,

Je cherche à comprendre pourquoi je n'arrive pas à lancer une commande python depuis un serveur nodejs. Je précise le schéma :

J'ai un serveur nodejs qui propose une petite interface avec des boutons qui permettent d'activer des commandes python.
Les commandes python ont toutes été testées manuellement et elles fonctionnent toutes. Ces commandes sont :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
os.system('sshpass -p\'gc\' ssh root@10.0.20.11 "reboot -f" &')
os.system('sshpass -p\'gc\' ssh root@10.2.10.11 "poweroff now" &')

Les codes sont tous bien paramétrés en terme de droits ( chmod +x code.py )

Le code nodejs semble bien paramétré car certains code python s'exécutent bien. Voici un extrait du code nodejs :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
		 if(name=="reboot"){
			if (state_reboot ==0 & state_stop ==0 & state_start ==0 & state_cleanup ==0){
			spawn('python', ['/home/radxa/server_alert/public/reboot.py']); 		//ici on lance le script reboot
			console.log("reboot : commande lancée")
			state_reboot=1;
			setTimeout(()=>{
				state_reboot=0
				io.emit('etatreboot',state_reboot);
				}, 25000)
			}
			io.emit('etatreboot',state_reboot);
		 }

Par ailleurs lorsque j'appuie sur le bouton (donc depuis nodejs), et en parallèle j'ai le htop qui tourne, je vois bien mon script qui apparaît dans la liste des taches, par contre les commandes contenues dans ce script os.system('sshpass ... ne se lancent pas --> pas visibles dans le htop, et la je ne comprends pas pourquoi.

Je ne sais pas si j'ai été assez explicite.

Merci pour votre aide.

[LittleWhite]

Bonjour,

Il pourrait que cela provienne d'un problème de droit (le serveur nodejs n'utilise pas l'utilisateur habituel et pourrait ne pas avoir les droit pour faire ça), ou un problème de chemin courant (le serveur nodejs n'exécute pas la commande depuis le dossier attendu et donc, la commande ne se lance pas).
Vous devriez faire en sorte de voir les erreurs des commandes lancées et d'ajouter des logs, pour savoir ce qui se passe.

[papajoker]

bonjour

Les commandes python ont toutes été testées manuellement et elles fonctionnent toutes. Ces commandes sont :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
os.system('sshpass -p\'gc\' ssh root@10.0.20.11 "reboot -f" &')
os.system('sshpass -p\'gc\' ssh root@10.2.10.11 "poweroff now" &')

Je ne sais pas si j'ai été assez explicite.

pas pour moi

Si j'ai compris…
Tu as testé en local ces 2 commandes MAIS en bash, elles fonctionnent : le serveur réagit bien.
OUI ? Donc, ici, ton seul problème et en local, ton code python os.system() qui ne fonctionne pas ?

Perso, je n'ai jamais utilisé os.system() mais plutôt subprocess (et popen() puisque tu ajoutes & qui sans doute ne fonctionne pas avec ta commande os.system())

Note: existe en python des bibliothèques ssh client comme paramiko

[erwannoo]

Bonjour,

Merci pour vos réponses.
Afin d'être plus explicite,

Quand je me connecte à ma carte, en SSH et que j'execute la commande :

python reboot.py

avec le code python :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
import os
import time
 
print(" reboot RTC ")
os.system('sshpass -p\'mdp\' ssh root@192.168.10.11 "reboot -f" &')
time.sleep(2)
os.system('sshpass -p\'mdp\' ssh root@192.168.10.12 "reboot -f" &')
time.sleep(2)

alors les 2 PC redémarrent. Donc à partir de ce constat je me dis que le code est plutôt correct. Je fait le même test avec un autre code qui permet de démarrer les PC, en utilisant le wake on lan et qui fonctionne aussi (et pareil avec un code d'arrêt). Tous ces codes en python.

Du coup j'intègre ces codes à mon interface qui utilise le nodejs. Et je teste. Les codes ne donnent rien pour les commande de reboot et d'arrêt, par contre, quand j'arrête manuellement les PC et que j'execute le code de démarrage, alors les PC démarrent. J'en conclus donc que mon utilisation du nodejs est plutôt bonne. Par ailleurs lorsque j'utilise le nodejs pour lancer la commande de reboot, et qu'en parallèle je regarde dans le htop, je vois bien le processus lié se lancer, donc cela confirme qu'il n'y a pas d'erreur d'adresse, ou autre, par contre les actions associées ( reboot ) ne s'effectuent pas.. et c'est bien ça mon problème..

Si effectivement c'est un problème de droits lié a l'utilisateur nodejs, ce qui pourrait effectivement être le cas, comment gérer cela ? Je lance automatiquement le nodejs via un service depuis systemctl :
Devrais-je y ajouter un utilisateur specifique ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
--------sudo nano nodejs.service :
 
[Unit]
Description=nodejs
Wants=network-online.target
After=network-online.target
 
[Service]
Type=simple
ExecStart= /home/radxa/server_alert/autostart_indexjs.sh
Restart=always
 
[Install]
WantedBy=multi-user.target

cela lance un script bash qui lance le nodejs- :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#!/bin/bash
cd /home/radxa/server_alert
node index.js

Merci pour vos réponses.

[erwannoo]

N'y aurait-t'il un moyen de définir sous quel utilisateur se lance l'application nodejs ? a partir de systemctl ? je ne sais pas.

Merci.

[erwannoo]

bonjour,

en recherchant, j'ai trouvé run truc intéressant : les cibles par défaut.

Mes différentes applications (services) sont lancées automatiquement au démarrage de la carte par systemctl. Il s'avère que quand je tape la commande : systemctl get-default cela me retourne "graphical.target" .

Est-ce que cela peut impacter l'exécution du service nodejs ?

J'ai donc redéfini la cible en tapant : sudo systemctel set-default multi-user.target

On verra ce que cela donne.
Si vous avez des idées, remarques, je suis preneur.

Merci.

[erwannoo]

Bah en fait le fait de modifier "systemctl get-default" ne règle pas mon soucis.

Cela supprime l'affichage du bureau au démarrage.

[binarygirl]

Je pense aussi que c'est un problème de droit lié au user qui tente d'exécuter les commandes.
Vous pouvez tester ça facilement.
Sous Linux on peut se logger en tant qu'autre utilisateur, même si cet utilisateur n'a pas de mot de passe.

Exemple: on se logge en tant que Apache ou Nginx pour ouvrir une session interactive, en spécifiant un shell précis (dans ce cas-ci: Bash).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sudo su -l www-data -s /bin/bash

La commande whoami vous confirmera que vous êtes bien le user demandé... et à partir de là testez toutes vos commandes et analysez les erreurs rencontrées.

Le remède habituel c'est d'ajouter l'utilisateur au groupe sudo, mais on peut agir de manière plus fine, et donner la permission d'exécuter des commandes bien précises.

[erwannoo]

Bonjour,

Merci pour la réponse, je suppose effectivement que c'est un problème de droit .. mais je me pose aussi une autre question :

Lorsqu'une carte (raspberry ou autre) démarre, qu'un serveur se lance automatiquement, puis qu'un utilisateur se connecte sur une page du serveur depuis un PC distant (pour exécuter des codes pythons), sous quel utilisateur sont exécutés les codes python ?

-> dans ce cas, aucun utilisateur n'est connecté directement sur la carte
-> existe-t'il un utilisateur par défaut dans ce cas ?
-> est-ce que le PC distant devient l'utilisateur ?

J'avoue ne vraiment pas connaitre cette gestion d'utilisateur, si vous avez des explications je suis preneur.

Merci beaucoup.

[binarygirl]

Ça dépend comment c'est fait.

Quand c'est un cron, il est lancé dans le contexte d'un utilisateur précis.

Quand c'est un service systemd, c'est pareil on trouve le user dans la définition du unit file correspondant (ou pas). Dans l'exemple que vous avez donné plus haut, il n'y a pas de user spécifié donc par défaut le service sera exécuté en tant que root (comme le dit la doc).
En général on évitera de donner des privilèges excessifs quand ça peut être évité. En revanche, on peut ajouter le user à certains groupes si nécessaire, par exemple pour l'accès aux GPIO ou ce genre de truc.

En gros vous avez au moins deux techniques disponibles pour débugger:

• se logger avec l'utilisateur du service et tester les commandes manuellement, comme je l'ai montré plus haut
• ajouter du logging à votre service, de sorte que la sortie de stdout et stderr soit écrite vers un fichier de log pour l'examiner

Et d'ailleurs vous pourriez aussi utiliser la commande journalctl -u suivie du nom de service + filtrer par date pour voir les messages d'erreurs éventuels.

[erwannoo]

Merci pour ce retour.

Je viens de lancer "journactl" sur une de mes cartes. Ce que cela retourne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
 
Jun 26 14:07:01 rock-pi-4b systemd[70228]: Queued start job for default target Main User Target.
Jun 26 14:07:01 rock-pi-4b systemd[70228]: Created slice User Application Slice.
Jun 26 14:07:01 rock-pi-4b systemd[70228]: Reached target Paths.
Jun 26 14:07:01 rock-pi-4b systemd[70228]: Reached target Timers.
Jun 26 14:07:01 rock-pi-4b systemd[70228]: Starting D-Bus User Message Bus Socket.
Jun 26 14:07:01 rock-pi-4b systemd[70228]: Listening on GnuPG network certificate management daemon.
Jun 26 14:07:01 rock-pi-4b systemd[70228]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Jun 26 14:07:01 rock-pi-4b systemd[70228]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Jun 26 14:07:01 rock-pi-4b systemd[70228]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Jun 26 14:07:01 rock-pi-4b systemd[70228]: Listening on GnuPG cryptographic agent and passphrase cache.
Jun 26 14:07:01 rock-pi-4b systemd[70228]: Listening on debconf communication socket.
Jun 26 14:07:01 rock-pi-4b systemd[70228]: Listening on Sound System.
Jun 26 14:07:01 rock-pi-4b systemd[70228]: Listening on D-Bus User Message Bus Socket.
Jun 26 14:07:01 rock-pi-4b systemd[70228]: Reached target Sockets.
Jun 26 14:07:01 rock-pi-4b systemd[70228]: Reached target Basic System.
Jun 26 14:07:01 rock-pi-4b systemd[70228]: Starting Sound Service...
Jun 26 14:07:02 rock-pi-4b systemd[70228]: Started D-Bus User Message Bus.
Jun 26 14:07:02 rock-pi-4b systemd[70228]: Started Sound Service.
Jun 26 14:07:02 rock-pi-4b systemd[70228]: Reached target Main User Target.
Jun 26 14:07:02 rock-pi-4b systemd[70228]: Startup finished in 939ms.

on observe que l'utilisateur est l'utilisateur par défaut : "default target Main User Target"

or je n'ai pas clairement identifié de user pour mon service "nodejs.service" lancé par systemctl au lancement de la carte. Voir la déclaration du service :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
 
 
[Unit]
Description=nodejs
Wants=network-online.target
After=network-online.target
 
[Service]
Type=simple
ExecStart= /home/radxa/server_alert/autostart_indexjs.sh
Restart=always
 
[Install]
WantedBy=multi-user.target

Par ailleurs on y retrouve dans le répertoire /etc/systemd/system les services :

bluetooth.target.wants dbus-org.freedesktop.timesync1.service graphical.target.wants prometheus.service sshd.service
dbus-fi.w1.wpa_supplicant1.service default.target.wants multi-user.target.wants pushgateway.service sysinit.target.wants
dbus-org.bluez.service display-manager.service network-online.target.wants rkisp_3A.service timers.target.wants
dbus-org.freedesktop.nm-dispatcher.service getty.target.wants pm2-radxa.service samba-ad-dc.service

ne faudrait-il pas remplacer : " WantedBy=multi-user.target " présent dans le nodejs.service par " WantedBy=default.target.wants " ??

Merci.

[binarygirl]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

journalctl -u <service name>

Soit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

journalctl -u nodejs

normalement.

Plus quelques filtres par exemple: --since todayLaissez cette histoire de target de côté pour l'instant. Ça peut être intéressant par exemple pour accélérer le démarrage: sur un système autonome vous pouvez faire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

systemctl set-default multi-user.target

pour éviter de charger l'interface graphique si vous vous connectez seulement en SSH.

Mais votre problème ne vient manifestement pas de là.

[erwannoo]

En executant la commande journalctl -u nodejs on observe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
 
 
-- Boot b80dfeb894e94c2ea912d75fcd9b32bb --
juin 23 16:37:09 raspberrypi systemd[1]: Started nodejs.
juin 23 16:37:13 raspberrypi autostart_indexjs.sh[493]: Alert Server Connected to port 5000
juin 23 16:38:00 raspberrypi autostart_indexjs.sh[493]: Connecté au client $(socket.id)
juin 23 16:38:02 raspberrypi autostart_indexjs.sh[493]: déconnecté
juin 23 16:38:13 raspberrypi systemd[1]: Stopping nodejs...
juin 23 16:38:13 raspberrypi systemd[1]: nodejs.service: Succeeded.
juin 23 16:38:13 raspberrypi systemd[1]: Stopped nodejs.
juin 23 16:38:13 raspberrypi systemd[1]: nodejs.service: Consumed 1.307s CPU time.
-- Boot 527ccba8a4104f8aa29b28c61a09b978 --
juin 23 16:38:18 raspberrypi systemd[1]: Started nodejs.
juin 23 16:38:22 raspberrypi autostart_indexjs.sh[495]: Alert Server Connected to port 5000
juin 23 16:54:15 raspberrypi autostart_indexjs.sh[495]: Connecté au client $(socket.id)
juin 23 16:56:50 raspberrypi autostart_indexjs.sh[495]: Connecté au client $(socket.id)
juin 23 16:57:05 raspberrypi autostart_indexjs.sh[495]: déconnecté
juin 23 17:10:46 raspberrypi autostart_indexjs.sh[495]: déconnecté
juin 23 17:10:58 raspberrypi systemd[1]: Stopping nodejs...
juin 23 17:10:58 raspberrypi systemd[1]: nodejs.service: Succeeded.
juin 23 17:10:58 raspberrypi systemd[1]: Stopped nodejs.
juin 23 17:10:58 raspberrypi systemd[1]: nodejs.service: Consumed 1.468s CPU time.
-- Boot 67a1fbe45f4d4b98836d4296601c2d81 --
juin 23 17:11:03 raspberrypi systemd[1]: Started nodejs.
juin 23 17:11:07 raspberrypi autostart_indexjs.sh[490]: Alert Server Connected to port 5000
juin 23 17:52:51 raspberrypi autostart_indexjs.sh[490]: Connecté au client $(socket.id)
juin 23 17:53:24 raspberrypi autostart_indexjs.sh[490]: reboot : commande lancée
juin 23 17:57:42 raspberrypi autostart_indexjs.sh[490]: déconnecté
lines 147-204/204 (END)

Je ne sais pas trop comment interpreter ça, mais ce qui est certain c'est que nodejs est lancé par un script bash (autostart_indexjs.sh) accessible dans le répertoire de l'utilisateur pi : /home/pi/server_alert/autostart_indexjs.sh.

Effectivement lorsque je lance les scripts en manuel, en lançant directement le nodejs comme ça : node index.js alors les scripts python s'executent bien. Mais pas lorsque ça se lance via autostart_indexjs.sh.

le script bash fait seulement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
cd /home/pi/server_alert
node index.js

y a t'il moyen de specifier un utilisateur (root par exemple) pour le lancement de index.js depuis le script bash ?


Merci pour l'aide.

[binarygirl]

Si vous utilisez un service systemd (et non un cron par exemple), alors il faut spécifier un utilisateur dans le unit file que vous avez posté plus haut. Sinon, par défaut le service est exécuté en tant que root.
Logiquement, l'utilisateur devrait être pi puisque le script est exécuté dans le répertoire de cet utilisateur.

Pour ce qui est du reboot, peut-être que tout ce qu'il manque est sudo:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sudo reboot

[erwannoo]

Merci pour l'aide,
ça ne fonctionne toujours pas. Je vais tenter par un autre moyen, je posterai un message plus tard si j'y arrive.