jeudi 28 août 2014

Informaticien à tout faire

J'utilise ou j'ai utilisé CentOS, Debian, Fedora, Ubuntu, MS Windows, Mac OS X, FreeBSD, IOS (Cisco),iOS (Apple), Android, Solaris.

Je travaille la plupart du temps en ligne de commande, à distance des serveurs. 

Je sais lire les logs de la plupart des logiciels, je peux comprendre le code écrit dans les langages informatiques les plus courants, je sais compiler et installer des programmes dans ces langages. J'ai déjà débugué du Fortran, du C, du bash, du tcsh, du python, du perl, du PHP, du ruby.

J'ai accès à des serveurs qui feraient pâlir d'envie beaucoup d'informaticiens ( 800G de RAM, 40 coeurs, quelques To de disques sur une seule machine).

Je joue à la poupée pour gérer mes serveurs, des robots m'envoient des dizaines de mails quotidiennement. Je fais du réseau, du système, du stockage, de l'authentification, de la sécurité, de l'impression, de la téléphonie.

J'aime passer de la fraicheur climatisée à l'enfer brûlant dans la salle serveur, le bruit des ventilateur filtré par mon casque anti-bruit.

Je gère des plate-formes, des projets. Je fais du conseil à l'achat, du support utilisateur.

Je découvre le monde des appels d'offre, des CCTP et le formalisme juridique.

Je suis administrateur systèmes et réseaux

Alors, pourquoi, quand je lis une annonce sur un site d'offre d'emploi, je me sens nulle ? 

dimanche 25 mai 2014

Up and down

Hier, je parlais de femmes et d'open-source à l'Ubuntu Party. Hier, j'étais heureuse parce que j'avais eu beaucoup de retours positifs sur ce que j'avais dit. Parce que j'avais le sentiment que je pouvais, à mon petit niveau, pas après pas, faire changer les choses.

Hier, un homme a pris une arme et a tué 6 personnes et blessé 3 autres. Parce qu'il était puceau à 22 ans, parce que des femmes qui lui plaisaient avait refusé ces avances. Parce qu'il s'estimait lésé par ce refus. Parce que pour lui, il avait le droit au sexe. Cet homme n'était pas "juste" un malade mental. Ce n'était pas le premier à tuer des femmes uniquement à cause de leur sexe. Ce ne sera pas le dernier.

Notre corps nous appartient. Notre vie nous appartient. Une femme n'est pas un trophé, pas un prix.

http://cafaitgenre.org/2014/05/25/cest-lhistoire-dun-tueur-misogyne-qui-ninteressait-personne/

dimanche 9 mars 2014

Jouons avec systemd

Mon employeur utilise un outil propriétaire pour sauvegarder les postes de travail. Cet outil est écrit en java (point négatif) mais fonctionne avec les 3 OS utilisés couramment (MacOS, Linux et Windows).
Modulo quelques réglages (internes à l'appli) pour limiter l'utilisation de CPU et de la bande passante, le fonctionnement de l'application ne gêne absolument pas le fonctionnement normal de la machine et les backups sont fait de façon transparente.

Crashplan (puisque c'est le nom de ce logiciel) fonctionne sous la forme d'un service linux classique qui indexe les fichiers des répertoires à sauvegarder, surveille les modifications et envoie le différentiel par le réseau (sous forme chiffrée). Il y a aussi une interface graphique mais elle ne sert que pour la configuration et les restaurations.

Le problème

J'ai eu un seul problème avec cette application. Au démarrage du laptop, elle a besoin de beaucoup d'inotify pour repérer les fichiers modifiés par rapport à la dernière exécution et gnome-tracker aussi (pour des raisons similaires).

Qu'est-ce qui se passe quand un linux moderne (sous Gnome) n'a plus d'inotify disponible pendant le boot ? La charge monte, monte, monte pendant que les derniers services attendent de démarrer. L'ouverture de session peut bloquer (quand on clique sur son login, on obtient jamais d'invite pour taper son mot de passe) et même quand elle fonctionne, la session n'est pas utilisable avant quelques minutes.

Le problème, c'est qu'augmenter la quantité d'inotify disponibles pour le noyau n'est qu'un contournement et même si cela limite les problèmes, ils ne disparaissent pas complètement.

Systemd 1ère phase

Le second défaut de cette application est qu'elle est livrée avec un script d'init pour sa version linux. Et moi, mon laptop utilise Fedora et donc systemd. Même si systemd peut lancer des scripts d'init, ce n'est pas natif. Et l'écriture de service pour systemd est rapide et simple, même pour un non-programmeur (contrairement aux scripts d'init).

Voici donc ce que cela donne  :
[Unit]
Description=Crashplan Backup Service
After=local-fs.target network.target

[Service]
ExecStart=/usr/local/crashplan/bin/CrashPlanEngine start
ExecReload=/usr/local/crashplan/bin/CrashPlanEngine reload
ExecStop=/usr/local/crashplan/bin/CrashPlanEngine stop
Type=forking
PIDFile=/usr/local/crashplan/CrashPlanEngine.pid

[Install]
WantedBy=multi-user.target
Je me suis largement inspirée d'exemples trouvés sur internet mais le principe est assez simple, notamment pour les dépendances. 

Il faut ensuite activer le service, mais je laisse la recherche google à votre charge. 

Tout est une question de timing

Vous devez vous demander en quoi lancer le service avec systemd plutôt qu'avec le mode de compatibilité de sysinit V règle le problème de saturation des inotify. En rien.
Une deuxième étape est venue plus tard, lorsque j'ai découvert l'existence des timer dans systemd. Ils permettent de retarder le lancement d'un service d'un temps déterminé (et pas seulement de dire "lancement de NFS après le réseau").
J'ai donc pu ajouter l'unit systemd suivant :

[Unit]
Description=hold the launch of crashplan of 5 minutes

[Timer]
OnBootSec=5m
Unit=crashplan.service

[Install]
WantedBy=multi-user.target


Crashplan se lance 5 minutes après le boot, l'ouverture de ma session n'est plus ralentie et tout fonctionne parfaitement