[RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

BenjiBoy · Le 21/02/2024, à 15:14

Bonjour à tous,
me revoilà avec mes trucs bizarres.

J'ai un nouveau type de numériseur qui est destiné à être installé sur des sites isolés (=batteries + panneaux PV).
L'ensemble est composé d'un boitier qui numérise, et d'un autre boitier qui communique, les deux sont reliés en permanence.

Le fabricant a pris le parti de n'autoriser la communication extérieure qu'avec un VPN actif.
Comme j'en suis encore au stade expérimental, j'ai pour l'instant pris une solution gratuite chez OpenVPN, on a droit à 3 périphériques et un utilisateur, parfait pour moi.
Mieux encore, OpenVPN propose d'héberger le serveur VPN (CloudConnexa), ce qui me facilite beaucoup la vie. A terme, notre service info installera un serveur intramuros, mais il me faut valider pas mal de chose avant de leur envoyer cette pastille.

Donc, j'ai créé le compte, récupéré les fichiers de profils *.ovpn, le boitier de communication se connecte bien au réseau, j'arrive à le voir tout ça, c'est bien.
MAIS, sur le serveur CloudConnexa, je pense qu'il y a une option qui dégage les périphérique qui sont connectés mais pas actif (voir ceci, à "Session lifetime and expiration settings"), ce qui est bien sûr normal pour virer les zombies, mais dans mon cas c'est problématique car les périphériques risquent d'être souvent dans cet état.
Et du coup, le périphérique est viré un peu avant 24h de connexion.

J'ai fais un script qui, en gros, vérifie l'état de la connexion, et si le VPN est off, j’éteins proprement tous les services, et les rallume. Avec une condition si le script est freeze, qu'il se kill lui même.
Mais il y a quelque qui ne marche pas et ça fait des jours, semaines que j'y suis, je n'y arrive pas. Probablement une histoire d'environnement parce que je ne suis pas habitué à utiliser un compte root.
Parce que oui, l'ensemble des commandes doivent être exécutées en root (choix fabricant).

Est-ce que je peux coller mon long script (80 lignes) ici en vue que vous essayiez avec moi de le débugger ? Ou c'est inenvisageable ?

Dernière modification par BenjiBoy (Le 01/03/2024, à 16:54)

sputnick · Le 21/02/2024, à 15:43

Saut. Oui, c'est pas grand chose 80 lignes

jplemoine · Le 21/02/2024, à 16:08

entre balises code.. (le <> bleu dans la barre du dessus).

BenjiBoy · Le 21/02/2024, à 16:26

Notes utiles :
- Il y a beaucoup de "echo" c'est le temps que je l’exécute à la main, pour voir ou ça en est.
- Les commandes "/usr/bin/qmicli" sont des commande utilisant la puce GPRS intégrée.
- Je rempli un fichier log qui synthétise des info tel que les tension d'alim et si et quand le VPN s'est arrêté.

En gros le déroulé du code est :
- récupérer le PID
- voir l'état du VPN et l'inscrire dans un variable
- récupérer les valeurs de tension et l'inscrire dans une variable
- récupérer les valeurs de temperature de la board et l'inscrire dans une variable
- SI la variable contenant l'état du VPN est VIDE, alors tout va bien, SINON enclencher les différent processus d'éteignage
- attendre 10 secondes
- Relancer la carte telecom
- PENDANT que la carte calcul un RSRQ (je sais plus ce que ça veut dire mais en gros ça veut dire qu'elle a établi une liaison stable)
- SI le calcul RSRQ dure trop longtemps (>180s) kill le script.
- relancer l'interface WWAN0, puis le daemon VPN, puis la connexion VPN.
- marquer tout ça dans le log.

J'espère que c'est bitable.

#!/bin/bash
# -*- coding: utf-8 -*-
#set -x

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# recup PID script
MYPID=`echo $$`
echo "reco_vpn : $MYPID"

# si le daemon vpn ne peut pas resoudre l'adresse du serveur RESOLVE est non vide
RESOLVE=`systemctl status openvpn@client | grep -i RESOLVE | awk -F ':' '{print $3}'`
FAILED=`systemctl status openvpn@client | grep -i "Active: failed" | awk -F ' ' '{print $1, $2}'`
DATE=`date -u +%Y-%m-%dT%H:%M:%S` #2024-01-17T14:59:34

# recuperer la sortie du python ccube-sensors
/usr/bin/ccube-sensors voltage -m all 2> volt.log
VOLTSYS=`cat volt.log | awk -F '=' '{print $2}' | awk -F ' ' '{print $1}'`
VOLTBAT=`cat volt.log | awk -F '=' '{print $3}'`
rm -f volt.log

/usr/bin/ccube-sensors temperature -m board 2> temp.log
TEMP=`cat temp.log | awk -F '=' '{print $2}'`
rm -f temp.log

#/usr/bin/qmicli -d /dev/cdc-wdm0 --wds-get-current-settings --client-cid=${WDS_CID} --client-no-release-cid | sed -n '3,4p;5p;6p;7p;8p' >> reco_vpn.log # avoir les ip, gateway et dns et le MTU avec le FAI
#rm reco_vpn.log

# routine relance si VPN freeze
# si RSOLVE est null
if [ -z "$RESOLVE" ] && [ -z "$FAILED" ]
then
        # OK : connecte
        echo "reco_vpn : ${DATE},$VOLTSYS,$VOLTBAT,$TEMP,still connected"
        echo "${DATE},$VOLTSYS,$VOLTBAT,$TEMP,still connected" >> reco_vpn.log

else
        # NOK : VPN hors ligne
        echo "reco_vpn : $RESOLVE"
        echo "reco_vpn : $FAILED"
        echo "reco_vpn : ${DATE},$VOLTSYS,$VOLTBAT,$TEMP,disconnected"
        echo "${DATE},$VOLTSYS,$VOLTBAT,$TEMP,disconnected" >> reco_vpn.log
        ccube-network openvpn disable client.conf
        systemctl stop openvpn@client
        ifdown wwan0 #eteint tout
        echo "waiting 30s" && sleep 30 #cooldown des interfaces

        ccube-hardware mobile enable #relance le module LTE, mais pas la mise en reseau
        echo "waiting 10s" && sleep 10

        # ne pas faire un ifup tant que le reseau n'a pas etabli de mesure RSRQ (apres RSSI) sinon il bloquera sur "send discover" ad vitam
        # Tester cette condition et au dela de 3min tout arreter (l'interface s'est mal lancee).
        start=`date +%s` 
        NETWORK=""
        while  [[ "$NETWORK" != "RSRQ:" ]]
        do echo "reco_vpn : pas de RSRQ" && sleep 10 
        NAS_CID=`/usr/bin/qmicli -d /dev/cdc-wdm0 --nas-noop --client-no-release-cid | sed -n '3p' | awk -F ':' '{print $2}' | tr -d "'" | tr -d " "`
        echo "reco_vpn : NAS-CID number $NAS_CID"

        RSRQ=`/usr/bin/qmicli -d /dev/cdc-wdm0 --nas-get-signal-strength --client-cid=${NAS_CID} --client-no-release-cid | sed -n '10,11p' | tr -d "\n"`
        NETWORK=`echo $RSRQ | awk '{print $1}'`
        echo "reco_vpn : NETWORK = $NETWORK"
        /usr/bin/qmicli -d /dev/cdc-wdm0 --nas-noop --client-cid=${NAS_CID} # rendre le CID persistent
                if (( `date +%s`-start > 180 ))
                then 
                echo "reco_vpn : give up reconnexion for now"
                kill -9 $MYPID
                fi
        done
        echo "reco_vpn : $NETWORK"
        echo "reco_vpn : RSRQ established"
        /usr/bin/qmicli -d /dev/cdc-wdm0 --nas-noop --client-cid=${NAS_CID} # rendre le CID persistent
        ifup wwan0
        systemctl start openvpn@client
        ccube-network openvpn enable client.conf
        echo "${DATE},$VOLTSYS,$VOLTBAT,$TEMP,reconnected" >> reco_vpn.log
fi

sputnick · Le 21/02/2024, à 16:52

Passe ton script par https://shellcheck.net il va dejà faire une première passe de reco.

BenjiBoy · Le 21/02/2024, à 17:58

sputnick a écrit :

Passe ton script par https://shellcheck.net il va dejà faire une première passe de reco.

Oh c'est vachement bien ça, je vais regarder, merci !

Watael · Le 21/02/2024, à 19:45

MYPID=`echo $$`

ben non.
d'abord, pas de noms de variables tout en majuscules, c'est réservé aux variables d'environnement (HOME, PWD...)
ensuite, myPID=$$ tout simplement. KISS!
et puis, il serait temps de passer aux substitutions de commandes modernes :

resolve=$(systemctl...)

on continue : pas grep | awk, parce que awk sait faire ce que fait grep
et pas cat|awk|awk, d'abord pas cat (cf. UUOC), et il y a un awk de trop

etc

PS :

$ date -u +'%FT%T'
2024-02-21T17:48:11

Dernière modification par Watael (Le 21/02/2024, à 19:49)

sputnick · Le 21/02/2024, à 21:40

# -*- coding: utf-8 -*-

Ça ne sert à rien en shell et même en python, on n'utilise plus ça depuis la V3.

BenjiBoy · Le 22/02/2024, à 08:51

Salut tous,

merci pour vos retours, suggestions et remarques.
Mais alors, si je puis me permettre, humblement, je pense que vous êtes concentré sur la qualité de syntaxe, qui de mon côté est purement empirique et présente donc des lacunes évidentes, mais je parlais plutôt du fait que le script ne fonctionne pas, en tout cas pas lorsqu'il est exécuté en crontab root, mais il fonctionne très bien (=le résultat attendu est trouvé) lorsque je l’exécute à la main en tant que root.

Que ça ne m'empêche pas de bien appliquer vos recommandations, s'entend (j'ai modifié en conséquence), mais j'aurais surtout besoin de comprendre qu'est-ce qui bloque le déroulement de ce script dans son cron root (s'il est possible de savoir).
Est-ce que sur ce point vous auriez des idées ? Ou des retours commandes qui pourrait me l'indiquer ?

Astrolivier · Le 22/02/2024, à 10:51

salut,

si ton script plante avec cron, tu peux voir avec les timer de systemd. il y a eu une discussion à ce sujet il y a peu (#17 commence à parler des timer)
https://forum.ubuntu-fr.org/viewtopic.php?id=2083622

aussi tu utilises ifupdown qui est obsolette. tu as peut-être une bonne raison de la faire mais si ce n'est pas le cas regarde iproute2 (man ip) et network-manager (man nmcli)
exemple :

ip set wwan0 up

nmcli gère normalement bien ce genre de communication (jamais essayé perso)

man nmcli

RADIO TRANSMISSION CONTROL COMMANDS
       nmcli radio {all | wifi | wwan} [ARGUMENTS...]

       Show radio switches status, or enable and disable the switches.

       wifi [on | off]
           Show or set status of Wi-Fi in NetworkManager. If no arguments are supplied, Wi-Fi status is printed; on enables Wi-Fi; off disables Wi-Fi.

       wwan [on | off]
           Show or set status of WWAN (mobile broadband) in NetworkManager. If no arguments are supplied, mobile broadband status is printed; on enables mobile broadband, off disables it.

       all [on | off]
           Show or set all previously mentioned radio switches at the same time.

sputnick · Le 22/02/2024, à 14:24

BenjiBoy a écrit :

...
mais je parlais plutôt du fait que le script ne fonctionne pas, en tout cas pas lorsqu'il est exécuté en crontab root, mais il fonctionne très bien (=le résultat attendu est trouvé) lorsque je l’exécute à la main en tant que root.

Tu a surement un souci denvironnement.

Tente:

source ~/.bashrc

dans le script en deuxième ligne.

Si ça ne suffit pas, utilise

bash -x script

pour debug, redirigé dans un fichier de log:

* * * * * /chemin/script.sh > /tmp/log 2>&1

Et perso, j'utilise ça dans le cron pour avoir le plus possible le même environnement:

SHELL=/bin/bash
CRONARGS=-m/usr/bin/msmtp
PATH=/home/moi/bin:/usr/local/bin:/usr/bin:/bin:/bin

Watael · Le 22/02/2024, à 14:43

je ne suis pas d'accord pour le source du .bashrc : il y a trop de choses non pertinentes dedans.

mais je plussoie de décommenter du set -x dans le script pour comparer l'exécution dans le terminal et via cron

sputnick · Le 22/02/2024, à 15:10

Ça dépends du bashrc.

Le minimum vital, c'est de setter le PATH et ça règle souvent beaucoup de problèmes...

Watael · Le 22/02/2024, à 15:51

c'est quand même envoyer toute une miche de pain à l'eau, quand un croûton aurait suffit pour pêcher un canard.
pourvu qu'il y ait un canard ! et ça, c'est le set -x qui le dira.

jplemoine · Le 22/02/2024, à 16:02

Pour info :
set -x : à prononcer (set <tiret> x) permet d'avoir un sorte de mode verbose
L'inverse est set <tiret barré> x --> set +x.
Comme c'est la plupart du temps la valeur par défaut, on se contente de commenter le set -x

sputnick · Le 22/02/2024, à 16:05

Watael a écrit :

je ne suis pas d'accord pour le source du .bashrc : il y a trop de choses non pertinentes dedans.

Le PATH est variable d'un user à l'autre: par exemple $HOME/bin, donc plus simple de sourcer le bashrc.

Watael · Le 22/02/2024, à 16:10

pour avoir moins de choses inutiles, c'est plus simple de n'ajouter que le PATH au script : PATH=$HOME/bin:$PATH

Dernière modification par Watael (Le 22/02/2024, à 16:11)

jplemoine · Le 22/02/2024, à 16:47

sputnick a écrit :

donc plus simple de sourcer le bashrc.

Plus simple peut-être mais beaucoup moins "secure".
Les variables d'environnement du root sont volontairement épurées.
Sourcer le .bashrc pour faire un test, oui éventuellement mais ensuite, il ne faut prendre que le minimum.

C'est comme si tu ouvrais toutes les portes d'un immeuble dès qu'un habitant voulait rentrer chez lui.

BenjiBoy · Le 23/02/2024, à 11:50

Salut tous,

pour apporter quelques réponses :

@Astrolivier :
Je ne sais pas quelle version de linux j'ai sur le périphérique, mais il est très spartiate et je n'ai malheureusement aucun des outils que tu cites ... Et j'utilise ifup / ifdown parce que c'est dans le manuel utilisateur du périphérique (mais pourquoi eux l'utilisent, mystère)

@jplemoine :
merci pour cette info, je copiais ce "set -x" commenté sans savoir pourquoi ... (parce que je le voyais dans les script qu'écrivait mon chef, en fait).

@Watael et @sputnick : du coup voilà les modifications opérées :
J'ai décommenté "set -x" et ajouté "> /tmp/log 2>&1" à mon cron afin de bien voir ce qu'il se passe.
J'ai modifié MYPID="echo $$" en myPID=$$
J'ai viré # -*- coding: utf-8 -*-.

Et pour la suite du coup, j'ai suivi un peu le débat mais je n'ai pas vraiment d'opinion ... Dons je vais m'en tenir à ce modif et lancer le script.

BenjiBoy · Le 23/02/2024, à 15:54

Alors le script modifié fait la même chose : à la main, ça fonctionne parfaitement, si je programme un cron, rien ne se passe, MAIS j'ai trouvé un truc qui pourrait expliquer ça en faisant un "journalctl -r" :

Feb 23 13:50:01 CC249 CRON[4013]: pam_env(cron:session): Unable to open env file: /etc/default/locale: No such file or directory

kescecé ?

Watael · Le 23/02/2024, à 16:23

envoie un petit echo, toutes les minutes, une ou deux fois, pour voir si ça concerne toues les tâches cron, ou si c'est propre à ton script...
a priori, ce n'est rien qui empêche le fonctionnement de cron et de ton script.

et le /tmp/log, y dit quoi ?

Dernière modification par Watael (Le 23/02/2024, à 16:24)

BenjiBoy · Le 23/02/2024, à 16:41

Watael a écrit :

et le /tmp/log, y dit quoi ?

Oui point important aussi : il ne se créé pas du tout, il fichier n'existe pas.
Je vais essayer le echo.

EDIT : résultat d'un echo dans le crontab :

Feb 23 14:44:01 CC249 CRON[4283]: pam_unix(cron:session): session closed for user root
Feb 23 14:44:01 CC249 CRON[4287]: (root) CMD (/bin/echo "test echo" > /root/echo.log 2>&1)
Feb 23 14:44:01 CC249 CRON[4283]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb 23 14:44:01 CC249 CRON[4283]: pam_env(cron:session): Unable to open env file: /etc/default/locale: No such file or directory
Feb 23 14:44:01 CC249 cron[1131]: (root) RELOAD (crontabs/root)

Et le echo.log est bien créé lui.

Dernière modification par BenjiBoy (Le 23/02/2024, à 16:47)

BenjiBoy · Le 26/02/2024, à 15:51

Je viens de me rendre compte d'une chose absolument affreuse.

Voilà quel était ma ligne de crontab :

13 45 * * * /sbin/shurtdown -r now /dev/null

J'ai inversé minute et heure.
Donc ça ne pouvait jamais se lancer. Enfin si, une fois qu'il aurait été 45h13 de l'après-midi...

Je l'ai regardé mille fois cette ligne, je suis systématiquement passé à côté.
Le crontab fonctionne à présent parfaitement bien, et mon script aussi, je suis ravi, et dégouté.

Merci pour votre aide ...

lynn · Le 26/02/2024, à 20:28

Bonjour,

Tant mieux si ça fonctionne, c'est le principal. Par contre, si tu as utilisé la commande «crontab -e», tu n'aurais pas du pouvoir enregistrer ta crontab sous ce format...

"/tmp/crontab.WDm9lJ/crontab":0: bad hour
errors in crontab file, can't install.
Do you want to retry the same edit? (y/n)

BenjiBoy · Le 27/02/2024, à 10:08

J'ai bien utilisé

crontab -e

, et j'ai eu un moment cette erreur, mais c'était parce que j'avais placé un astérisque de trop. Une fois celui-ci enlevé, c'est passé sans accroc.
Peut-être que la valeur numérique n'est pas relevé, mais que la quantité de valeur l'est ?
Note : j'ai choisi nano en éditeur, je sais pas si ça joue.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 21/02/2024, à 15:14

[RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#2 Le 21/02/2024, à 15:43

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#3 Le 21/02/2024, à 16:08

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#4 Le 21/02/2024, à 16:26

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#5 Le 21/02/2024, à 16:52

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#6 Le 21/02/2024, à 17:58

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#7 Le 21/02/2024, à 19:45

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#8 Le 21/02/2024, à 21:40

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#9 Le 22/02/2024, à 08:51

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#10 Le 22/02/2024, à 10:51

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#11 Le 22/02/2024, à 14:24

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#12 Le 22/02/2024, à 14:43

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#13 Le 22/02/2024, à 15:10

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#14 Le 22/02/2024, à 15:51

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#15 Le 22/02/2024, à 16:02

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#16 Le 22/02/2024, à 16:05

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#17 Le 22/02/2024, à 16:10

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#18 Le 22/02/2024, à 16:47

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#19 Le 23/02/2024, à 11:50

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#20 Le 23/02/2024, à 15:54

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#21 Le 23/02/2024, à 16:23

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#22 Le 23/02/2024, à 16:41

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#23 Le 26/02/2024, à 15:51

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#24 Le 26/02/2024, à 20:28

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

#25 Le 27/02/2024, à 10:08

Re : [RESOLU] Bash reconnexion auto d'un périphérique en milieu isolé

Pied de page des forums