Forum Programmation.autre Conky et condition (if)

Posté par . Licence CC by-sa.
Tags :
0
26
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 (page perso) . Évalué à 1 (+1/-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 . Évalué à 1 (+0/-0).

      ${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 (page perso) . Évalué à 1 (+1/-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 . Évalué à 1 (+0/-0).

          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 (page perso) . Évalué à 2 (+1/-0).

            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 . Évalué à 1 (+0/-0).

          Avec ou sans les [[ … ]] le conky réagit pareil (par contre dans le shell sans les ça plante).

          🇪🇺

      • [^] # Re: bash vs. sh ?

        Posté par . Évalué à 1 (+0/-0). Dernière modification le 26/08/19 à 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 . Évalué à 1 (+0/-0). Dernière modification le 26/08/19 à 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 (page perso) . Évalué à 3 (+2/-0).

            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 . Évalué à 1 (+0/-0). Dernière modification le 26/08/19 à 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 (page perso) . Évalué à 2 (+1/-0).

                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 . Évalué à 1 (+0/-0).

                  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 (page perso) . Évalué à 3 (+2/-0).

          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 . Évalué à 1 (+0/-0). Dernière modification le 26/08/19 à 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 . Évalué à 1 (+0/-0).

    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

    🇪🇺

Envoyer un commentaire

Suivre le flux des commentaires

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