Forum Programmation.autre Conky et condition (if)

Posté par voxdemonix le 26 août 2019 à 14:56. Licence CC By‑SA.

Étiquettes :

août

2019

Affiche "plop" dans un shell :

if [[ "1" == "1" ]]; then echo "plop";else echo "not good"; fi

Affiche "not good" dans le conky :

${execp if [[ "1" == "1" ]]; then echo "plop";else echo "not good"; fi  }

Pourquoi ?
Comment effectuer une comparaison de deux strings avec bash dans le conky ?

Le but est de faire tourner cette comparaison de deux signatures TLS dans le conky :

${alignc}${font :size=7}${execp certSecure=$( openssl s_client -connect 88.191.250.176:443 -servername linuxfr.org < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin ); certTor=$( torsocks openssl s_client -connect linuxfr.org:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin ); if [[ "$certSecure" == "$certTor" ]]; then echo '${color green}';echo "$certTor";echo '${color}';else  echo '${color red}';echo "$certSecure"; echo "$certTor";echo '${color}';fi }${font}

# bash vs. sh ?

Posté par Cyril Brulebois (site web personnel) le 26 août 2019 à 15:18. Évalué à 1.

Il se passe quoi si tu changes == en = ? Le premier n'est pas standard, le second si. Si ton shell système n'est pas bash mais par exemple dash, ça peut expliquer que le test renvoie une erreur…

Debian Consultant @ DEBAMAX
- [^] # Re: bash vs. sh ?
  
  Posté par voxdemonix le 26 août 2019 à 16:03. Évalué à 1.
```
${execp if [[ "1" = "1" ]]; then echo "plop";else echo "not good"; fi  }
```
  ===> Affiche not good.
  
  En suivant les moteurs de recherches j'ai aussi testé avec if_match comme expliqué ici : https://stackoverflow.com/questions/15692990/conky-with-if-match-and-and
  Mais cela ne fonctionne pas (le conky ne s'affiche même plus).
```
${execp certSecure=$( openssl s_client -connect 88.191.250.176:443 -servername linuxfr.org < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin ) }
${execp certTor=$( torsocks openssl s_client -connect linuxfr.org:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin ) }

${if_match  "$certSecure"=="$certTor"   }${execp echo '${color green}';echo "$certTor";echo '${color}'; }${else}{$execp echo '${color red}';echo "$certSecure"; echo "$certTor";echo '${color}'; }${endif}
```
  - [^] # Re: bash vs. sh ?
    
    Posté par Cyril Brulebois (site web personnel) le 26 août 2019 à 16:27. Évalué à 1.
    Et c'est encore mieux après un café… C'est la même chose avec [[ … ]] :
```
kibi@armor:~$ dash 
$ if [[ "1" = "1" ]]; then echo "plop"; else echo "not good"; fi 
dash: 1: [[: not found
not good
```
    Debian Consultant @ DEBAMAX
    - [^] # Re: bash vs. sh ?
      
      Posté par voxdemonix le 26 août 2019 à 16:43. Évalué à 1.
      bash -c aussi ne semble pas trop aimer cette condition non plus.
      
      └─ $ ▶ bash -c "if [[ "1" = "1" ]]; then echo "plop";else echo "not good"; fi" good; fi: -c: line 1: syntax error: unexpected end of file
      
      Pourtant si le else fonctionne, en toute logique, c'est que le if ne provoque pas d'erreur (si non le conky devrait crasher (et ne plus s'afficher) ou afficher des brides de retours d'erreurs)
      - [^] # Re: bash vs. sh ?
        
        Posté par Cyril Brulebois (site web personnel) le 26 août 2019 à 17:03. Évalué à 2.
        
        Si tu veux imbriquer des guillemets, il faut protéger ceux qui sont à l'intérieur. Ou plus simplement, utiliser des apostrophes autour…
        
        kibi@armor:~$ bash -c 'if [[ "1" = "1" ]]; then echo "plop"; else echo "not good"; fi' plop kibi@armor:~$ bash -c "if [[ \"1\" = \"1\" ]]; then echo \"plop\"; else echo \"not good\"; fi" plop
        
        Debian Consultant @ DEBAMAX
    - [^] # Re: bash vs. sh ?
      
      Posté par voxdemonix le 26 août 2019 à 19:21. Évalué à 1.
      
      Avec ou sans les [[ … ]] le conky réagit pareil (par contre dans le shell sans les ça plante).
  - [^] # Re: bash vs. sh ?
    
    Posté par voxdemonix le 26 août 2019 à 16:34. Évalué à 1. Dernière modification le 26 août 2019 à 16:36.
    Une petite faute s'est glissé dans la précédente commande.
    
    Donc la condition semble fonctionner avec le code suivant, mais les variables $certTor et $certSecure ne veulent plus s'afficher.
```
    # on enregistre les signatures dans les variables $certSecure et $certTor

${execp certSecure=$( openssl s_client -connect 88.191.250.176:443 -servername linuxfr.org < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin ); certTor=$( torsocks openssl s_client -connect linuxfr.org:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin ) }

    # on compare, si c'est bon on affiche une seule variable en vert, si non on affiche les deux en rouge

${if_match  "$certSecure"="$certTor"   }${execp echo '${color green}';echo $certTor;echo "good"; echo '${color}'; }${else}${execp echo '${color red}';echo "not good";echo $certSecure; echo $certTor;echo '${color}'; }${endif}
```
    - [^] # Re: timeout openssl
      
      Posté par voxdemonix le 26 août 2019 à 16:49. Évalué à 1. Dernière modification le 26 août 2019 à 16:51.
      
      J'en profite du thread ouvert : si quelqu'un sait comment rajouter un timeout sur la commande openssl se serait cool :) (j'ai déjà tenté en utilisant la commande timeout [temps] [commandes] mais elle ne semblait pas avoir d'effet se qui freeze la commande pendant un certains temps quand les hosts ne répondent pas).
      
      Man openssl ne semble pas indiquer de paramètre de timeout.
      - [^] # Re: timeout openssl
        
        Posté par Cyril Brulebois (site web personnel) le 26 août 2019 à 17:06. Évalué à 3.
        
        Cf. les options -s et -k ? Le signal par défaut peut avoir été ignoré, du coup c'est comme si timeout n'avait rien fait ?
        
        Debian Consultant @ DEBAMAX
        
        [^] # Re: timeout openssl
        
        Posté par voxdemonix le 26 août 2019 à 19:26. Évalué à 1. Dernière modification le 26 août 2019 à 19:26.
        
        Quand j'ajoute la commande devant openssl le shell répond
        
        unable to load certificate 140385179976128:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: TRUSTED CERTIFICATE
        
        Pour la commande :
        
        certSecure=$( timeout --kill-after=5 openssl s_client -connect 88.191.250.176:443 -servername linuxfr.org < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin ); certTor=$( torsocks openssl s_client -connect linuxfr.org:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin ); echo -n '${color green}'; echo -n $certSecure; echo '${color'}; echo -n '${color red}'; c=$(echo "$certTor" | sed "s/$certSecure//"); echo -n $c; echo -n '${color}';
        
        PS : merci pour tes réponses;)
        
        [^] # Re: timeout openssl
        
        Posté par Cyril Brulebois (site web personnel) le 27 août 2019 à 09:13. Évalué à 2.
        
        Parce que DURATION n'est pas facultatif quand tu appelles timeout :
        
        timeout [OPTION] DURATION COMMAND [ARG]...
        
        Si tu enlèves les redirections, tu verras l'erreur :
        
        kibi@armor:~$ timeout --kill-after=5 openssl s_client -connect 88.191.250.176:443 -servername linuxfr.org timeout: invalid time interval ‘openssl’ Try 'timeout --help' for more information.
        
        … ce qui explique que la commande de l'autre côté du pipe se plaigne. Au passage, tu pourrais t'épargner -in /dev/stdin.
        
        Debian Consultant @ DEBAMAX
        
        [^] # Re: timeout openssl
        
        Posté par voxdemonix le 27 août 2019 à 14:19. Évalué à 1.
        
        Merci, la commande suivante à l'air de bien tourner.
        
        timeout --kill-after=5 5 2>/dev/null openssl s_client -connect 10.8.0.69:443 -servername linuxfr.org < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout 2>/dev/null
        
        Soit elle ne renvoie rien au bout de 5s, soit elle renvoie la signature du certif.
    - [^] # Re: bash vs. sh ?
      
      Posté par Cyril Brulebois (site web personnel) le 26 août 2019 à 17:05. Évalué à 3.
      
      Au hasard, les variables disparaissent dès qu'on sort du bloc ${execp …} ? Du coup ton test « fonctionne » parce que tu compares deux chaînes vides, mais il n'y a rien à afficher ?
      
      Debian Consultant @ DEBAMAX
      - [^] # Re: bash vs. sh ?
        
        Posté par voxdemonix le 26 août 2019 à 17:14. Évalué à 1. Dernière modification le 26 août 2019 à 17:15.
        
        Je pense que tu as raison, quand les deux certificats sont différents la comparaison renvoie quand même true.
        
        Bref, cette méthode ne fonctionne pas, il faut continuer sur une oneline en bash.

# Solution temporaire

Posté par voxdemonix le 27 août 2019 à 14:31. Évalué à 1.

En attendant d'arriver à faire fonctionner les if dans les conky, la méthode de contournement utilisée est de passer par grep et sed. C'est dégueulasse, on consomme inutilement des ressources en sur-traitant les strings, mais à la guerre comme à la guerre.

${execp certSecure=$( timeout --kill-after=5 5 2>/dev/null openssl s_client -connect 88.191.250.176:443 -servername linuxfr.org < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout 2>/dev/null ); certTor=$( timeout --kill-after=5 5 2>/dev/null torsocks openssl s_client -connect linuxfr.org:443 < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout 2>/dev/null ); echo -n '${color green}'; echo -n $certSecure; echo '${color'}; c=$(echo -n '${color red}' "$certTor" '${color}' ); echo -n $c | sed "/$certSecure/d";   }

La version finale se trouvera ici : https://linuxfr.org/wiki/debian-ubuntu-health-check-de-services-grace-aux-conkys#toc-checker-le-certificat-tls-https

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.