Feuilles de calculs et outils libres

Le document suivant a été rédigé avec TexMacs et Maxima. Bien que n’étant pas encore finalisé, il démontre clairement les possibilités de ces logiciels qui, avec quelques tours de dextérité, peuvent très bien convenir a des usages professionnels.

Voici dans un premier temps la version PDF de mes premiers balbutiements avec ces logiciels…

Télécharger (test-macs.pdf,PDF, 159KB)

Comme il y a moyen de créer des modèles complexes et d’utiliser plusieurs sortes de consoles de calculs (maxima, scilab, Octave, Xcas, …), il n’y a pas de doute que l’on vienne à bout de pratiquement n’importe quel calcul, et d’en présenter correctement le déroulement et le résultat !

Monitoring serveur: traquer les zombies ou processus morts

Monitoring serveur: traquer les zombies ou processus morts

La problématique

Il arrive quelquefois qu’un processus ou service démarré à un moment donné sur un serveur finisse anormalement ou avant sa fin programmée et/ou ne récupère pas le code de fin des processus fils qu’il a engendré. Dans ce cas, les processus concernés disposent toujours encore de leur PID associé à leur bloc de contrôle. Lorsque ces cas se multiplient, il occupent des ressources qui vont manquer par ailleurs, provoquant des ralentissements voire un gel du système. C’est mieux de les détecter et de corriger le problème car il est souvent récurrent…

Les solutions

  1. Une première solution consiste à lancer un “ps aux” qui va prendre un instantané des processus en cours. Mais comme les processus varient en continu, il faudrait répéter l’opération très souvent pour tomber sur le coupable !
  2. Une seconde solution est offerte pas la commande “top ou htop qui fournit la même chose, mais en live. La commande prouve bien que les processus varient en continu et qu’il est important d’avoir une résolution suffisamment fine pour les détecter. C’est finalement cette commande avec ses filtres que l’on va utiliser pour une analyse en temps réel.
  3. Mais pour une détection sur un réseau qui contient plusieurs serveurs, mieux vaut disposer d’un automate associer à un moniteur centralisé comme Nagios par exemple.
    J’ai écris le script Perl ci-après pour que le moniteur Nagios se charge de ce travail. Ce dernier avertira si des processus zombies existent et alertera si leur nombre dépasse un seuil toléré.

Le script PERL sur le serveur

Afin d’augmenter la résolution du moniteur qui, au meilleur des cas, est d’une requête toute les 15s, et pour diminuer le temps de latence qui devrait inclure le temps d’éxécution de la commande, multipliée par x serveurs, mon astuce consiste à passer par une base de donnée SQLite installée sur le serveur et dont la taille est limitée (une autre astuce !).

Sans révéler tout le synoptique que j’ai mis en place pour l’analyse des processus, je peux affirmer avoir multiplié par 10 ou 20 la résolution des données récoltées par le moniteur Nagios tout en divisant par deux le temps de latence d’un cycle de requêtes. Je ne vais livrer ici que le script Perl qui stocke les données dans la base existante côté serveur.

  • L’authentification fonctionne-elle ?
  • Le temps de réponse est-il dans les limites acceptables ?
  • Le contenu de la page est-il conforme à celui attendu (même taille, même contenu, …) ?
  • Eventuellement la page est-elle identique sur le serveur mirroir ?

Principe :

Sans trop rentrer dans les détails techniques …

  • On se connecte à la page par l’authentification requise, c’est à dire en transmettant un nom d’utilisateur et un mot de passe. Il est préférable de définir pour cet accès un nouvel utilisateur spécifique à cette requête.
  • On doit alors également gérér un coockie de session pour la durée de celle-ci.
  • Pour accéder à la page voulue, il peut être nécessaire de cliquer sur des menus, des liens ou faire des choix dans un formulaire, dépendament de la configuration du site.
  • Lors d’une première connexion “manuelle”, on crée un fichier de référence (ou modèle) de la page à analyser. Evidemment celle-ci devra être vérifiée la première fois par le concepteur.
  • Lors des autres visites, on récupère la page pour la compiler dans un tableau. Dès lors, ce sont les fonctions de PERL qui se chargenet de ce travail.
  • On affiche le résultat de l’analyse sous une forme interpretable par le moniteur nagios pour qu’il puisse la transmettre par son interface et les courriels paramétrés.

Le script

Le script est anonymé ! Il conviendra donc de remplacer les adresses IP, le “login”, le “mdp” (mot de passe) et l'”user” par ceux voulus.

Il faudra également adapter la structure du script à celui du site, pour tenir compte du cheminement qui permet d’atteindre la page à analyser.

 

Une variante du script

Il se peut que le script précédent ne fonctionne pas correctement dans votre environnement. Ce fut d’ailleurs mon cas après des modifications survenues au niveau de l’authentification.
Vous pourrez alors essayer une autre méthode en remplaçant les modules de perl choisis.
A SUIVRE …

Reconstruction d’un mur de soutènement

Reconstruction d’un mur de soutènement

 

Localisation et données géométriques


Le mur se situe dans la municipalité de St-Irénée à 130 km au Nord de la ville de Québec (Canada). Il supporte la route 362 dans une côte au coeur du village.

Relevé de dommages


Vue d'ensemble

Vue d’ensemble



Façade du mur

Façade du mur


Le long de la côte montante, les deux tiers supérieurs du mur sont fissurés, fracturés et montrent une inclinaison notable vers l’arrière. Les réparations précédentes ont permis de contenir partiellement les fissures, mais pas l’inclinaison.

Principe de la reconstruction

Nous décidons de remplacer cette section par un mur de soutènement en “L” fait de béton coulé en place. La longueur de mur remplacé sera de 45 m et d’une hauteur variant de 3,50 m à 1,20 m. Il faudra tenir compte de la forte pente du nouveau mur qui devra être, d’après les relevés que j’ai effectué sur place avec un niveau optique, de 10% pour la moitié inférieure dans la côte, et de 12% pour la moitié supérieure. Le nouveau mur comportera donc un point d’inflexion en son milieu où il subira un changement d’angle horizontal (virage) et vertical (changement de pente).
Par ailleurs la conception doit tenir compte de l’importance de la route 362 pour le village. Pour cela, une voie de circulation par alternance devra être maintenue en permanence ainsi que les dispositifs de gestion pour celle-ci.
Compte-tenu de la forte pente, une attention particulière devra être portée pendant la mise en oeuvre concernant la caractéristique à l’affaissement du béton.

Eléments de conception

Le mur est conçu selon le dessin type, l’armature étant déduite d’un tableau en fonction de la hauteur du mur. Une membrane géodrain ainsi qu’une membrane d’étanchéité seront installées sur le coté interne (vers la route supportée). De plus, il sera équipé d’un drain en PVC perforé dans son coin inférieur pour empêcher l’accumulation d’eaux de ruissellement du terrain, ainsi que d’un drain en pierres nettes et barbacanes aux 2/3 environ de la hauteur pour les eaux d’infiltration de la surface. Une isolation supplémentaire en polystyrène devra protéger la fondation coté externe du gel.
 

Télécharger (CH-7103-154-15-0271_SC_F2.pdf,PDF, 3MB)


 

Télécharger (CH-7103-154-15-0271_SC_F3.pdf,PDF, 416KB)


 

Télécharger (CH-7103-154-15-0271_SC_F5.pdf,PDF, 1.17MB)


 

3D-drainage

Face interne : conception



Façade du mur

Façade du mur



 

Quelques moments charnières au chantier

Les photos ci-dessous illustrent tout le déroulement du chantier.

 
Démolition et préparation du sol


 
Fondation: coffrage et ferraillage

 
Mur: coffrage et ferraillage, détail des ancrages pour la glissière 210A

 
Mur: étanchéité et équipements

 
Mur: réparation des anciennes fissures

Remblais: compactage, drain de pierre nette, nivelage, glissière 201A

 
Route et glissière: pavage et dispositif d’extrémité

 
Fin des travaux : Nettoyage et engazonnement

Bilan

Une conception rigoureuse et exhaustive aura permis un déroulement rythmé au chantier. Les problèmes liés à la complexité de la situation, notamment la forte pente (10%, puis 12%), le point d’inflexion au centre du mur et le coin en retour ont tous été résolus à la conception grâce aux techniques 3D. Leur utilisation pour le design de la glissière 210A (avec des tubes carrés) a été d’un soutien indispensable.
 
La bonne volonté et la rigueur de l’entrepreneur au chantier que je félicite au passage pour être parvenu à maîtriser toutes les difficultés lors de l’exécution de l’ouvrage ont permis d’obtenir un résultat remarquable, fonctionnel et esthétique, au regard des défis liés au contexte.

Monitoring réseau : que fait votre imprimante réseau ?

Monitoring réseau : que fait votre imprimante réseau ?

La problématique

C’est pratique, une imprimante réseau, n’est-ce pas ? Elle peut être localisée dans votre bureau, dans un local du bâtiment, quelque part en ville … ou même sur un autre continent !
Comment s’assurer qu’elle est fonctionnelle, qu’elle dispose de suffisament de papier, que ses cartouches ne sont pas vides, ou qu’elle n’est pas bourrée ?
Bien sur, ce serait mieux si elle était accessible, mais elle ne peut pas l’être pour tout le monde.
“Allo, nous souhaitons imprimer en publipostage environ 1500 contrats d’une vingtaine de pages chacun et il ne reste que 6000 feuilles dans les tiroirs. Pourriez vous les recharger ce soir avant 19h00 ?”
çà sonne mieux que :
“Allô, nous avions lancé hier soir une impression en publipostage de 1500 contrats d’une vingtaine de pages chacun, mais il y a eu un manque de papier. Pourriez-vous recharger les tiroirs, nous allons devoir recommencer !”

La solution

La plupart des imprimantes réseau peuvent communiquer grâce au protocole SNMP. Par ailleurs, chacune des informations ou alertes qu’elles sont capables de transmettre sont stockées une base d’information MIB dont les contenus sont accessibles grâce à une adresse OID construite sur une arborescence de type “1.3.6.1.2.1.2.2.1.6”. En interrogeant cette adresse on a accès à la valeur qu’elle contient et éventuellement aux valeurs “enfants” selon la requête envoyée à l’imprimante.

La mise en oeuvre

L’arborescence ou les adresses OID des MIB n’est pas tout-à-fait standard, d’autant que toutes les imprimantes ne possèdent pas les mêmes fonctionnalités ni ne diffusent les mêmes informations.

Il faut donc d’abord trouver le pavé (livre) des adresses ou codes OID pour l’imprimante concernée :

  1. Certains fabricants les fournissent sur le CD d’installation des drivers, ou plus généralement sur leur site internet. Mais souvent ce n’est le cas que pour les modèles industriels.
  2. Il existe des petits programmes capables d’interroger directement l’imprimante en question et de révéler dans une liste ou un tableau les codes, leur description et leur contenu.
  3. Des commandes sous linux permettent également de les obtenir. Il faudra encore les filtrer et les formater, ce que proposent plusieurs tutoriels sur le web.

Commandes linux

la commande “snmpwalk” permet entre autre d’explorer l’aborescence d’une MIB. On l’installe sous Fedora (et sans doute toute distribution basée sur les paquets RPM) avec le paquet “net-snmp-utils”.

Exemple (adresse IP de l’imprimante : 192.168.0.146)

On obtient alors un défilement assez impressionnant qu’il faut maintenant analyser. En complétant la commande comme suit on récupère le résultat dans un fichier texte (*.txt) ce qui permet de faire des recherches de mots clés avec un éditeur de texte (ex.: gedit ou kate).

Dans mon cas, le fichier contient les lignes suivantes

Formatage des données : petite analyse

En parcourant les lignes, on s’aperçoit vite que leur structure ressemble à ceci :
NomDuChamp = Format : Contenu.

Exemples:

  • hrSystemUptime.0 = Timeticks: (282364664) 32 days, 16:20:46.64
    Cette ligne révèle que l’imprimante fonctionne depuis 32 jours, 16 heures, 20 minutes et 46,64 secondes.
  • Les lignes suivantes correspondent au taux de remplissage des cartouches d’encre :
    mib-2.43.11.1.1.9.1.1 = INTEGER: 97
    mib-2.43.11.1.1.9.1.2 = INTEGER: 70
    mib-2.43.11.1.1.9.1.3 = INTEGER: 82
    mib-2.43.11.1.1.9.1.4 = INTEGER: 77
    mib-2.43.14.1.1.2.1.1 = INTEGER: 11

Ainsi, en récupérant pour chaque ligne le NomDuChamp et le Contenu, on peut stocker la requête dans une table de hash dont l’interrogation sera non seulement simple à écrire, mais très universelle et adaptable à n’importe quel besoin. Pour cela on pourrait passer par l’étape du fichier texte, mais comme le langage Perl possède des modules pour le protocole SNMP, pourquoi s’en priver ?
En modifiant une option de la commande, on peut préciser certains résultats :

On obtient alors un contenu un peu différent :