structure & meta

This commit is contained in:
Yax 2019-08-17 18:40:27 +02:00
parent da6d838193
commit b25ce65735
284 changed files with 461 additions and 1000 deletions

View file

@ -0,0 +1,78 @@
<!-- title: Marre des aquariums -->
<!-- category: Humeur -->
<!-- tag: planet -->
Deux expériences récentes m'ont conforté dans l'importance de supporter le
Libre et rappelé que la bataille ne se joue pas que dans la sphère
professionnelle, bien au contraire.<!-- more -->
Par confort (et la faiénantise n'est jamais loin), j'avais acheté un boitier
multimédia il y a 3 ans à l'époque ou le Media Player de mon fournisseur
Internet montrait ses limites à streamer certains formats vidéo du PC à la
TV. Le boitier a bien rempli son rôle, on l'allume en même temps que la TV, il
démarre en 3s et il décode quasiment tout. Simple comme un téléphone à
compote ;-) Seulement deux ans plus tard, on est passé de "il décode quasiment
tout" à "il décode pas mal de trucs". Confiant, je saute sur mon panda roux
pour naviguer sur la toile, me disant qu'il existe probablement des mise à jour
de firmware chez le constructeur ou mieux un firmwware alternatif développé
par des passionnés qui rajoute des fonctionnalités. Et bien choux blanc ! Le
constructeur préfère sortir des nouveaux modèles que rallonger la durée de
vie des anciens. Rien d'étrange à cela, il s'agit d'une société commerciale
dont l'objectif premier est de réaliser du chiffre d'affaire. Quant aux
passionnés, ils existent certainement mais soit le boitier multimédia est
très bien verrouillé, soit le challenge attire moins les foules que craquer la
dernière console à la mode. Au final, je me retrouve avec un boitier
multimédia en fin de vie car son logiciel n'a pas évolué depuis 2010.
Sanction méritée ! J'ai clairement manqué de nez en choississant un
constructeur qui ne déverrouille pas ses firmware, qui n'anime pas une
communauté de passionnés de ses produits. A refaire aujourd'hui, je miserai
sur un mini PC avec une GeeXboX ou un truc du genre, en tout cas une solution
plus pérenne où le logiciel n'est pas fermé.
La deuxième expérience ou plutôt désillusion concerne la nouvelle console
portable de Sony. C'est Noël et l'unique cadeau que désire mon fils c'est une
Vita. C'est cher mais toute la famille met la main à la poche et on achète le
fantasme. La console est offerte avec deux jeux. Première chose qui me fait
tiquer, pas de jeu dans le carton mais deux coupons pour les télécharger sur
le Store. Adieu donc la possibilité de les revendre à la boutique d'occasion
du coin quand on en sera lassé afin d'acheter un autre titre. Etant moi-même
un joueur occasionnel sur PC avec un compte Steam je digère l'info : on (et je
m'inclus) a tué le marché de l'occasion PC, celui des consoles va suivre et
nous crèverons avec nos identifiants en emportant nos téléchargements dans la
tombe (je vous renvoie à la chanson 'Société Anonyme' d'Eddy Mitchell). En
bon parent, nous suivons les règles établies : j'ai un compte principal car je
suis majeur et je crée un compte secondaire pour un enfant de 10 ans qui est
associé à la console. Et là, la blague commence. On peut autoriser de jouer
un titre interdit aux -18 ans dont on a la cartouche par l'application contrôle
parental de la console, mais on ne peut pas télécharger depuis le Store un des
deux jeux offerts interdit aux -12 ans. Pour cela il n'y a aucun paramètre. On
pourrait s'attendre à un système de notification du compte principal qui
pourrait approuver ou non, après tout ils ont nos emails, en plus de nos âges
et nos adresses :-( Mais visiblement, Sony s'est protégé à fond et a nivelé
par le bas en mettant en place une politique de sécurité dure et identique
pour tous les continents. Donc au final que fait-on ? Et bien on ment en
conséquence de cause. On crée un autre compte secondaire en augmentant l'âge
de son enfant afin qu'il puisse jouer à son jeu. Le constructeur de la console
est tranquille, il a rempli son devoir de garde chiourme et c'est le parent qui
prend la décision de tricher pour biaiser le système de protection mal pensé.
Que faut-il en conclure ? Et bien plusieurs choses je crois:
* Qu'il n'y a pas que des OS de la banquise chez moi. Par facilité, par manque
d'alternative et parce que, comme le disait récemment Cyrille on ne peut pas
imposer de force nos idées à nos proches, on fait entrer des objets connectés
non libres du 21ème siècle dans la maison.
* Avec le sourire et en tendant la carte bleue nous sommes en train de nous
enfermer volontairement dans des beaux aquariums multicolores, où nager est un
plaisir des yeux jusqu'à ce qu'on s'écrase le nez sur la vitre. C'est le point
le plus inquiétant pour moi : la multiplication des Store auquels on se soumet
avec la satisfaction imbécile d'appartenir à son siècle et de participer au
progrès.
* A chacun de balayer devant sa porte. Pour ma part, je vais engager l'année avec
l'esprit des deux dernières années : en restreignant les besoins artificiels,
en réfléchissant d'abord à l'adéquation entre le besoin et l'objet lors d'un
achat ainsi qu'à la pérennité de la solution. La sphère familiale et ludique
ne doit pas être sous-estimée c'est là que se jouent maintenant les batailles
qui définiront nos libertés demain.

View file

@ -0,0 +1,52 @@
<!-- title: Mise à jour de Fedora 17 vers Fedora 18 -->
<!-- category: GNU/Linux -->
<!-- tag: planet -->
15 Janvier 2013 : c'est la sortie officielle de la Fedora 18, très attendue car
sa sortie fût décalée plusieurs fois, ce qui est à l'honneur des
développeurs<!-- more --> : sortir quand le niveau de qualité est atteint malgré le fait
qu'on soit une distribution mainstream très attendue. Je vous renvoie à
[l'article très complet posté par Renault sur LinuxFR pour la liste des
nouveautés.](http://linuxfr.org/news/sortie-de-fedora-18-alias-spherical-cow).
Moi je faire un retour d'expérience rapide sur une mise à jour réussie depuis
le Spin XFCE de Fedora 17.
[FedUp](http://fedoraproject.org/wiki/FedUp) est le nouvel outil pour gérer
les mises à jour de Fedora 17 et ultérieur. Voici les étapes que j'ai suivi
pour mettre à jour ma distribution :
* s'assurer que le système est à jour : yum upgrade. Puis redémarrer la machine
si le Kernel a été mis à jour.
* installer FedUp : yum --enablerepo=updates-testing install fedup
* désactiver tous les dépôts tiers définis tels que RPM Fusion. En ligne de
commande, cela consiste à rajouter enabled=0 aux fichiers.repo que l'on trouve
sous /etc/yum.repos.d.
* se déconnecter graphiquement et lancer FedUp en tant que root ou avec sudo
depuis un VTY : fedup-cli --network 18 --debuglog fedupdebug.log
* s'armer de patience, les téléchargements des paquets F18 commencent. Quand
c'est terminé, FedUp demande de redémarrer la machine. C'est au redémarrage
que le processus de mise à jour est effectué. Je ne sais pas exactement
combien de temps cela prend, j'ai dormi ;-)
Si tout se passe bien, on se retrouve avec une Fedora 18 opérationnelle. La
commande **uname -r** indique qu'on est passé en kernel 3.7.2-201.fc18.x86_64.4
Pour être complet, on peut aussi mettre à jour Grub 2 manuellement [comme
indiqué sur la page Wiki de FedUp](http://fedoraproject.org/wiki/FedUp#How_Can_
I_Upgrade_My_System_with_FedUp.3F).
**[EDIT]** J'ai remarqué que le nouveau pare-feu ne fonctionnait plus même
après l'installation des paquets firewall-config et firewall-applet. Le service
démarre, on peut modifier la configuration mais elle n'est pas prise en compte.
Il semble qu'un coup de **yum -y distro-sync** finalise la mise à jour en
supprimant les paquets obsolètes. Le pare-feu est opérationnel au
redémarrage. Ce nouveau pare-feu mériterait d'ailleurs un article : plus
simple et plus clair à configurer, gestion de 2 configurations (la courante et
la stockée).
Certains paquets obsolètes peuvent rester. Les [conseils de
llaumgui](http://www.llaumgui.com/post/fedora-17-in-da-place) restent
d'actualité.
J'ai aussi eu un problème avec la gestion de l'énergie interceptée par
systemd avant XFCE. C'est résolu [dans ce
post.](http://comments.gmane.org/gmane.linux.redhat.fedora.general/423516)

View file

@ -0,0 +1,54 @@
<!-- title: Migration du blog sous Pelican -->
<!-- categories: Blog Hébergement -->
<!-- tag: planet -->
Et oui, un de plus à migrer son blog sous [Pelican](http://docs.getpelican.com) !<!-- more -->
J'ai lu plusieurs récits de migration depuis trois mois, ce qui dénote un
engouement certain pour ce moteur de blog par... essentiellement des développeurs.
La perspective de gérer ses articles comme du code, avec un
article par fichier, de construire le blog avec une commande 'make' et
publier dans un gestionnaire de source nous ramène en terrain familier.
Les points suivants ont achevé de me convaincre :
* l'écriture dans une syntaxe simplifiée (un markup langage) ; j'ai opté pour
[Markdown](http://daringfireball.net/projects/markdown/). Je peux commencer
l'écriture d'un article depuis n'importe quel équipement, même l'application mémo
de mon téléphone.
* la possibilité de tout gérer depuis un terminal en mode texte, de
l'écriture d'un article à sa publication. Ce qui me permet de travailler
facilement depuis n'importe où avec une connexion SSH sur mon serveur
* La génération de pages statiques. Adieu PHP, on peut héberger encore plus
facilement.
En fait c'est le prolongement du raisonnement qui m'avait fait passer de
WordPress à [PluXml](http://www.pluxml.org).
L'import depuis PluXml est faisable par l'import RSS mais la conversion en Markdown est
approximative. J'ai donc écrit un outil de migration dédié en langage Python. Ce
qu'il apporte c'est une mise en forme plus fidèle lors de la conversion en
Markdown, une gestion des catégories **et des tags**. Il ne couvre peut-être
pas tous les cas mais il m'a permis de migrer mes articles sans retouche
manuelle. Cet outil est disponible sur mon compte GitHub :
[PluXml2Pelican](http://github.com/kianby/pelican)
Pour les thèmes c'est selon les goûts de chacun. Pelican fournit un langage de
templating Python [Jinja 2](http://jinja.pocoo.org).
A chacun de voir s'il veut un thème simple ou un thème plus dynamique avec du
JavaScript. Quelques thèmes d'exemple sont fournis sur
[GitHub](http://github.com/getpelican/pelican-themes). Pour ma part, Je suis parti d'un thème
basé sur [Bootstrap](http://twitter.github.com/bootstrap), le kit CSS qui permet
facilement de faire du Responsive Design afin d'avoir un site qui s'adapte à
tous les périphériques Web (ordinateurs de bureau, tablettes, téléphones) et je
l'ai adapté à ma sauce.
En résumé, Pelican est un très beau projet. Sous le capot, on trouve un outil
bien pensé, dans l'esprit du langage Python. Il est possible de développer des
plugins qui effectueront des actions à différentes phases de la génération des
pages HTML. Le seul point manquant, c'est le support des commentaires.
Normal pour un outil qui génère des pages statiques. La solution proposée consiste
à déléguer cette tâche à Disqus, un service Web privé. Cela ne me convient pas du tout,
je me suis auto-hébergé pour garder la main sur mes données. J'ai gardé les
commentaires de tous les articles et je cogite à une solution alternative....
En attendant, j'ai ouvert un email pour le blog qu'on peut utiliser pour
échanger : <i class="icon-envelope"></i> blogduyax at madyanne.fr

View file

@ -0,0 +1,257 @@
<!-- title: Haute Disponibilité avec Corosync et Pacemaker -->
<!-- category: Cluster -->
<!-- tag: planet -->
La Haute Disponibilité désigne toutes les techniques permettant d'améliorer
la disponibilité d'un système ou de services et d'augmenter la tolérance aux pannes<!-- more --> :
la redondance matérielle, les clusters, la réplications des données à chaud
physiquement (RAID 1 et RAID 5) ou logiciellement (Snapshots, DRBD), les scénarios
de crise (mode dégradés, plan de secours). Dans une grande entreprise, cela
peut donner lieu à un poste à responsabilité à plein temps. Mon activité professionnelle
m'a amené à mettre en oeuvre une facette de cette problématique : un cluster
actif / passif qui assure la disponibilité d'un service applicatif.
Pour GNU/Linux, j'ai expérimenté deux logiciels permettant de gérer une infrastructure
de cluster :
* Heartbeat qui a fait ses preuves mais qui est limité : pas de cluster à plus de 2 noeuds,
pas de gestion très fine des ressources et des règles pour basculer d'un noeud sur l'autre.
* [Corosync](http://www.corosync.org) et [Pacemaker](http://clusterlabs.org/wiki/Main_Page) :
c'est le choix de la distribution Red Hat et celui que je vais détailler dans la suite de cet article.
J'ai monté une maquette assez représentative composée de deux machines virtuelles Debian Wheezy
(en version presque finale) avec 4 interfaces réseaux chacune qui font tourner un service Apache
qu'on accède par une adresse IP gérée par le cluster.
Voici un diagramme réseau de la maquette :
![maquette](/images/2013/maquette-cluster.png)
Les interfaces eth0 et eth1 font partie d'une agrégation logique de liens et
servent au cluster pour vérifier l'état des autres noeuds. Elles constituent un
réseau privé avec l'autre noeud dans le réseau 10.20.13.0/255.255.255.252.
Les interfaces eth2 et eth3 font partie d'une autre agrégation logique,
elles fournissent le service à l'extérieur dans le réseau 192.168.1.0/24.
L'agrégation logique (appelé aussi bonding) fournit une redondance supplémentaire. Si
l'adaptateur réseau eth0 grille, le trafic transite encore grâce à eth1. On
peut la configurer en mode actif/passif ou bien en mode load-balancing.
Voici la configuration des interfaces sur la machine vm-node1 dans **/etc/network/interfaces/** :
auto bond0
iface bond0 inet static
address 10.20.13.1
netmask 255.255.255.252
bond_mode active-backup
bond_miimon 100
bond_downdelay 200
bond_updelay 200
slaves eth0 eth1
auto bond1
iface bond1 inet static
address 192.168.1.61
netmask 255.255.255.0
gateway 192.168.1.1
bond_mode active-backup
bond_miimon 100
bond_downdelay 200
bond_updelay 200
slaves eth2 eth3
et la configuration du bonding dans **/etc/modprobe.d/bonding** :
alias bond0 bonding
alias bond1 bonding
La configuration réseau de la machine vm-node2 est symétrique avec bond0 en
10.20.13.2 et bond1 en 192.168.1.62.
Quand la configuration réseau est ok, on peut s'occuper du cluster. D'abord il faut installer
Corosync et Pacemaker, c'est trivial sous Debian :
apt-get install corosync pacemaker
Ensuite il faut configurer Corosync. Il gère l'infrastructure de cluster, c'est à dire l'état des noeuds et
leur fonctionnement en groupe. Pour cela, on doit générer une clef d'authenfication qui sera partagée par tous
les noeuds du cluster. L'utilitaire **corosync-keygen** permet de générer cette clef à partir d'entrées clavier
pseudo-aléatoires qu'il faut ensuite sécuriser et copier sur les autres noeuds.
``` shell
# génération de la clef depuis vm-node1
corosync-keygen
mv authkey /etc/corosync/authkey
chown root:root /etc/corosync/authkey
chmod 400 /etc/corosync/authkey
# copie de la clef sur vm-node2
scp /etc/corosync/authkey root@10.20.13.2:/etc/corosync/authkey
```
Corosync propose le concept d'anneaux de connexion pour assurer la communication entre noeuds. Dans le cadre de
la maquette je définis deux anneaux : **ring0**, l'anneau de communication par défaut qui utilise le réseau privé et
**ring1** un anneau de secours qui transite par l'intermédiaire des commutateurs (ou switchs) avec le reste du trafic.
C'est une sécurité de plus pour le cas improbable où les deux liens eth0 et eth1 soient cassés. Corosync
permet de définir les anneaux en terme de réseau IP / masque réseau plutôt que de définir les adresses IP.
C'est appréciable car le même fichier de configuration peut être déployé sur tous les noeuds sans rien changer.
totem {
version: 2
# How long before declaring a token lost (ms)
token: 3000
# How many token retransmits before forming a new configuration
token_retransmits_before_loss_const: 10
# How long to wait for join messages in the membership protocol (ms)
join: 60
# How long to wait for consensus to be achieved before starting
#a new round of membership configuration (ms)
consensus: 3600
# Turn off the virtual synchrony filter
vsftype: none
# Number of messages that may be sent by one processor on receipt of the token
max_messages: 20
# Limit generated nodeids to 31-bits (positive signed integers)
clear_node_high_bit: yes
# Disable encryption
secauth: off
# How many threads to use for encryption/decryption
threads: 0
# Optionally assign a fixed node id (integer)
# nodeid: 1234
# This specifies the mode of redundant ring, which may be none, active, or passive.
rrp_mode: passive
interface {
ringnumber: 0
bindnetaddr: 10.20.13.0
mcastaddr: 226.94.1.1
mcastport: 5405
}
interface {
ringnumber: 1
bindnetaddr: 192.168.1.0
mcastaddr: 226.94.1.1
mcastport: 5407
}
}
amf {
mode: disabled
}
service {
# Load the Pacemaker Cluster Resource Manager
ver: 0
name: pacemaker
}
aisexec {
user: root
group: root
}
logging {
fileline: off
to_stderr: yes
to_logfile: no
to_syslog: yes
syslog_facility: daemon
debug: off
timestamp: on
logger_subsys {
subsys: AMF
debug: off
tags: enter|leave|trace1|trace2|trace3|trace4|trace6
}
}
A ce stade, l'infrastructure de cluster est en place mais elle ne gère aucune ressource. Ca c'est le
rôle de Pacemaker.
On impose les contraintes de fonctionnement suivantes :
1. les ressources (le service Apache et l'adresse IP du cluster) tournent sur le serveur vm-node1 dans le cas normal.
2. le service Apache et l'adresse IP du cluster doivent tourner sur le même serveur sinon notre service est injoignable.
3. si le service Apache se crashe sur le serveur primaire, on bascule sur le serveur secondaire.
4. si le serveur primaire ne joint plus la passerelle Internet, on bascule sur le serveur secondaire.
Pacemaker fournit quelques utilitaires en mode texte pour interagir.
* **crm** permet de gérer tout l'aspect configuration.
* **crm_mon** affiche l'état du cluster.
D'abord on définit la configuration globale. On désactive le **STONITH** (Shoot The Other Node In The Head) et
le **quorum**. Le Stonith est la possibilité de *tuer* l'autre noeud s'il ne répond plus par l'infra de cluster.
C'est faisable sur des vrais serveurs par [IPMI](http://fr.wikipedia.org/wiki/IPMI) par exemple.
Quant au quorum, il n'a pas de sens sur un cluster à moins de 3 noeuds.
property stonith-enabled=false
property no-quorum-policy=ignore
On peut maintenant définir notre première ressource : l'adresse IP du cluster attaché au noeud actif.
primitive vip ocf:heartbeat:IPaddr2 params ip=192.168.1.60 cidr_netmask=24 nic="bond1" op monitor interval="10s"
Puis la ressource Apache, le service critique qu'on veut fournir dans cette maquette :
primitive httpd ocf:heartbeat:apache params configfile="/etc/apache2/apache2.conf" statusurl="http://localhost/server-status" op start timeout="60s" op stop timeout="60s" op monitor timeout="20s"
Le démarrage et l'arrêt d'Apache sont maintenant gérés par le cluster. Il faut fonc enlever le démarrage
automatique du service. Sous Debian c'est avec update-rc.d :
update-rc.d -f remove apache2
Vous remarquerez qu'on va plus loin que la définition d'une ressource Apache. L'attribut **statusurl** permet à
Pacemaker d'utiliser la page de statut d'Apache pour décider d'une bascule. Il ne faut donc pas oublier de
configurer cette URL dans Apache pour que cela fonctionne :
``` apache
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Location>
```
Comme on a construit la configuration pas à pas, **crm_mon** remonte peut-être des erreurs sur certaines
ressources car elle n'étaient pas opérationnelles. Il y a un compteur d'échec qui lève un message d'avertissement.
on peut remettre ce compteur à zéro comme ceci pour la ressource http :
crm resource cleanup httpd
A ce stade on a une adresse de cluster et une ressource HTTP, mais pas forcément sur le même noeud.
la ressource **vip** va basculer si le noeud tombe. La ressource **httpd** va basculer si le noeud tombe
ou si le service apache tombe (surveillance par l'URL /server-status).
C'est sympa mais pas très utile :-) On va aller plus loin et forcer les deux ressources à tourner sur le
même noeud C'est faisable grâce au concept de la colocation :
colocation httpd-with-vip inf: httpd vip
Et on voudrait que dans le cas normal, les ressources tournent sur vm-node1, notre noeud primaire :
location preferred-node vip 100: vm-node1
Enfin, on rajoute une condition de bascule. Si le noeud ne joint plus la passerelle Internet, on veut basculer les
ressources sur l'autre noeud Pour cela on définit une ressource de type *ping* qui tourne sur tous les noeuds
(grâce au concept de ressource clonée). Puis on rajoute une règle de location pour basculer si le noeud actif
ne voit plus la passerelle.
primitive ping-gateway ocf:pacemaker:ping params host_list="192.168.1.1" multiplier="1000" op monitor interval="10s"
clone cloned-ping-gateway ping-gateway
location vip-needs-gateway vip rule -inf: not_defined pingd or pingd lte 0
Voilà notre maquette est opérationnelle.

View file

@ -0,0 +1,96 @@
<!-- title: Enfin le silence -->
<!-- category: GNU/Linux -->
<!-- tag: planet -->
J'ai effectué la mise à jour de mon *véloce serveur* <i class="icon-smile"></i>
(un Dell latitude D610 sous Céléron) vers Debian Wheezy.<!-- more --> Ca s'est plutôt bien passé
en suivant [les conseils de Nicolargo](http://blog.nicolargo.com/2013/05/de-squeeze-a-wheezy.html).
J'ai seulement eu quelques problèmes avec l'interpréteur PERL, je me suis retrouvé
avec un mix : l'interpréteur 5.16.3 de Wheezy et d'anciens modules PERL.
Peut-être que j'avais installé ces librairies manuellement, je ne me souviens
pas trop. Ca c'est résolu avec un ménage à la mano des modules obsolètes et une
réinstallation propre avec CPAN. Désormais, tout est fonctionnel !
Jusqu'à aujourd'hui je limitais la charge processeur la nuit en stoppant
certains services pour éviter la nuisance sonore, typiquement, le serveur
Minecraft en JAVA qui consomme 3% de CPU quand personne n'est connecté.
J'utilise depuis longtemps le paquet **cpufrequtils** qui permet de moduler la
fréquence du processeur par un module du noyau selon une politique **on demand**
qui fait varier la fréquence du Celeron entre 800 Mhz et 1,6 Ghz. Mais j'ai
réalisé que malgré une charge minimale, la machine était souvent bruyante à cause du
ventilateur. Il devrait être régulé en fonction de la fréquence du
processeur, or ce n'est pas le cas.
En faisant des recherches sur le sujet, on
apprend que la partie régulation du processeur est souvent réalisée par ACPI,
une norme répandue de contrôle de la gestion de l'énergie par l'OS grâce à un
support ACPI dans le BIOS mais que la gestion du ventilateur n'est pas souvent
incluse. Cela va dépendre de l'implémentation ACPI d'un constructeur à l'autre.
[La documentation
ArchLinux](https://wiki.archlinux.org/index.php/Fan_Speed_Control) décrit
certaines méthodes qui vont dépendre du matériel et j'ai découvert **i8kmon** pour
mon petit Dell. Ca tourne en daemon dans le système et ça régule la vitesse du
ventilateur proportiennellement à la vitesse du processeur. Pour la
configuration, j'ai utilisé les seuils proposés dans le [post de ce
forum](http://forum.tinycorelinux.net/index.php?topic=10736.0) :
Fichier **/etc/i8kmon** :
```
# Kernel I8K status file
set config(proc_i8k) /proc/i8k
# Kernel APM status file
set config(proc_apm) /proc/apm
# Kernel ACPI status file
set config(proc_acpi) /proc/acpi/ac_adapter/0/status
# External program to control the fans
set config(i8kfan) /usr/bin/i8kfan
# Applet geometry, override with --geometry option
set config(geometry) {}
# Run as daemon, override with --daemon option
set config(daemon) 1
# Automatic fan control, override with --auto option
set config(auto) 1
# Report status on stdout, override with --verbose option
set config(verbose) 0
# Status check timeout (seconds), override with --timeout option
set config(timeout) 5
# Temperature display unit (C/F), override with --unit option
set config(unit) C
# Temperature threshold at which the temperature is displayed in red
set config(t_high) 80
# Minimum expected fan speed
set config(min_speed) 1800
# Temperature thresholds: {fan_speeds low_ac high_ac low_batt high_batt}
# These were tested on the I8000. If you have a different Dell laptop model
# you should check the BIOS temperature monitoring and set the appropriate
# thresholds here. In doubt start with low values and gradually rise them
# until the fans are not always on when the cpu is idle.
set config(0) { {- 0} -1 52 -1 52}
set config(1) { {- 1} 44 60 44 60}
set config(2) { {- 2} 60 80 60 80}
set config(3) { {- 2} 70 128 75 128}
```
Fichier **/etc/default/i8kmon**
```
# Change to one to enable i8kmon
ENABLED = 1
```
Le résultat est au rendez-vous. Quand la CPU est basse, le volume sonore de la
machine est inaudible. Il reste à vérifier que les seuils sont adaptés et que
le processeur ne fond pas dans les prochaines semaines <i class="icon-smile"></i>

View file

@ -0,0 +1,71 @@
<!-- title: Ma vie de sysadmin en semi-pro (1) -->
<!-- category: GNU/Linux -->
<!-- tag: planet -->
Par goût personnel et par nécessité professionnelle, je rajoute progressivement le rôle
d'administrateur système à mon métier de base qui est le développement de logiciels.<!-- more --> Doté de
bonnes bases UNIX et réseau, je découvre petit à petit les bon outils et les bonnes pratiques
pour faire le job, le simplifier voire l'automatiser. Et parfois j'enverrais volontiers une
caisse de bières à l'auteur d'un outil qui m'a sauvé plusieurs heures fastidieuses :-)
Dans cette série d'articles *ma vie de sysadmin en semi-pro* je parlerais épisodiquement de mes
avancées et de mes découvertes dans le domaine de l'administration système.
Tout d'abord la console est ta seule amie. Sur ton PC de bureau, la console est un choix. Dans
le monde des serveurs c'est un passage obligé car ils sont rarement installés avec une interface
graphique et on les accède généralement par SSH. Les outils de base sont connus mais il faut
apprendre à les maîtriser.
Ce qui propulse la console c'est un shell UNIX compatible Bourne Shell. Il y a plusieurs variantes :
le Bourne Shell d'origine (sh), le Bourne Again Shell (bash), Korn Shell (ksh), Z Shell (zsh). Des
experts sont capables de discuter de tel avantage de zsh par rapport à ksh. A mon niveau, maîtriser
**sh** et **Bash** qui est le choix par défaut d'un grand nombre de systèmes GNU/Linux est le choix
de la raison. On trouve beaucoup de littérature sur le sujet (le Bourne Shell existe depuis 1978 et
le Bourne Again Shell depuis 1989 ), ma référence est le guide **Advanced Bash-Scripting Guide** sur
[le site du Linux Document Project](http://www.tldp.org/guides.html). Ensuite il est bien sûr
important de connaître les programmes en ligne de commande nécessaires pour les tâches de tous les
jours : grep, find, locate, chmod, chown, cp, mv, mkdir, rm, rmdir, touch, top, kill, ps ... la
liste est loin d'être exhaustive.
Un autre élément important est éditeur de texte en mode console. Il doit être polyvalent, léger,
capable de traiter des fichiers de centaines de milliers de lignes. Deux candidats se détachent du
peloton : **Vim** et **Emacs**. Les deux sont beaucoup plus que de simples éditeurs de texte. Ayant
des rudiments de **Vi** depuis 20 ans, je me suis lancé à corps perdu dans l'apprentissage des
fonctions avancées de **Vim** Que du bonheur ! Voici quelques liens :
* [Vim FAQ](https://github.com/chrisbra/vim_faq)
* [Vimcasts - Vim podcasts](http://vimcasts.org)
* [Vundle - Vim Plugin manager](https://github.com/gmarik/vundle)
Quand on passe beaucoup de temps sur la console, on est à l'affut des manières de la rendre plus
attractive et plus puissante
* Le prompt du shell par défaut est minimaliste. Pourquoi ne pas l'enrichir avec des informations
utiles comme la charge processeur ou les infos de gestion de version (SVN, GIT) du répertoire
courant ? C'est ce que propose [le projet
LiquidPrompt](https://github.com/nojhan/liquidprompt).
* Le choix des couleurs est important quand on passe beaucoup d'heures devant une console. Je ne
parle pas de choisir une palette *cool* mais bien de préserver sa vue. J'ai fait le choix [du
schéma de couleur Solarized](https://github.com/altercation/solarized). Ca peut sembler un peu
pâlot au début mais je me suis vité habitué et je l'utilise dans chaque programme où c'est
possible. Dans le même registre, j'utilise [le projet RedShift](https://launchpad.net/redshift)
pour gérer la température des couleurs en fonction de l'heure de la journée et de votre
emplacement géographique. Les deux premiers jours, on a l'impression que la luminosité est trop
basse, ensuite on trouve cela normal. Et on se sent agressé quand on utilise une autre machine
que la sienne.
* On se retrouve vite à ouvrir quantité de terminaux et à jongler entre eux. J'ai utilisé
[Terminator](http://www.tenshu.net/p/terminator.html) un temps puis j'ai pris confiance et j'ai
eu besoin de multiplier les terminaux depuis une même session SSH et de lancer des traitements
qui tournent en tâche de fond. Du coup, j'ai pris le temps d'apprendre
[Tmux](http://tmux.sourceforge.net) et c'est un très bon investissement ! Un bon article pour
démarrer est [accessible
ici](http://blog.hawkhost.com/2010/06/28/tmux-the-terminal-multiplexer).
* Quand on *provisionne* des serveurs régulièrement, il est intéressant de déployer sa
configuration du shell, de l'éditeur de texte, ses outils afin de retrouver son environnement et
ses habitudes. On peut installer ses fichiers manuellement depuis un point central [comme son
GitHub](https://github.com/kianby/dotfiles), ou mieux on peut carrément automatiser cette partie
en utilisant un outil comme [Fabric](https://github.com/fabric/fabric).
Le choix des outils présentés dans cet articles est personnel. Ce qui est intéressant, c'est la
puissance de la console dans une utilisation quotidienne, la pléthore d'outils et le sentiment de
maîtrise de ce qu'on fait.

View file

@ -0,0 +1,52 @@
<!-- title: La rentrée 2013 -->
<!-- category: Humeur -->
<!-- tag: planet -->
Le blog n'est pas abandonné ! C'est drôle, j'ai annoncé la même chose il y a
un an après la période d'inactivité qui accompagne l'été.<!-- more --> Ce n'est pas un blog
d'humeurs ou d'actualité mais plutôt un bloc-note de mes expérimentations autour
de GNU/Linux et du Libre. Donc pour écrire, il me faut un sujet que j'ai approfondi,
mis en oeuvre, à raconter. J'ai écrit très peu de billets depuis l'année dernière
mais je suis satisfait de leur qualité : distribution Fedora, migration du blog
sous Pelican, administration système. On va tenter de rester sur la même voie
cette année...
Pour ceux qui lisent le blog directement depuis le site, vous avez peut-être
constaté de légers changements dans le thème graphique du blog. Quand [j'ai
migré le blog depuis PluXml vers Pelican](migration-du-blog-sous-pelican.html),
j'ai utilisé Bootstrap pour rapidement refaire un thème similaire à ce que
j'avais. Dernièrement j'ai réalisé que les pages HTML du blog sont plutôt
lourdes. Bootstrap est une librairie CSS / JS qui fait beaucoup de choses mais
qui pèse avec, en plus, une dépendance à JQuery. Ca ne cadre pas avec la philosophie
d'un blog statique qui se résume, pour moi, en plusieurs critères :
* possibilité de gérer les sources avec un gestionnaire de version : GIT
dans mon cas
* possibilité d'éditer les articles simplement. C'est le cas avec un
langage de markup qui simplifie HTML. Pelican propose RST et Markdown
pour lequel j'ai une préférence même s'il est plus limité.
* ouverture vers n'importe quel éditeur de texte : j'utilise VIM, GEdit, le
bloc-note de mon téléphone.
* contrôle fin du code HTML généré : c'est le cas par un contrôle totale des
CSS et des templates Jinja utilisés par Pelican pour générer les pages.
Donc l'idée d'avoir un thème CSS léger avec le minimum de JavaScript a fait son
chemin. La dernière contrainte c'était d'avoir un zeste de *responsive design*
pour basculer la barre latérale de droite en fin de page quand la largeur de l'écran
n'est pas suffisante (sur téléphone ou tablette). J'aurais pu l'écrire *from
scratch* en passant vraiment beaucoup de temps ou en ayant un vrai talent de Web
designer comme mon confrère [Badele](http://blog.jesuislibre.org) mais j'ai préféré
chercher une alternative à Bootstrap qui réponde à ces critères. Et j'ai trouvé la
perle rare : [Pure](http://purecss.io), un module CSS qui se concentre sur
l'essentiel tout en étant **HTML5-ready** et **responsive design**. C'est très
récent, développé par Yahoo (l'équipe qui s'occupe du fameux framework
Yui). La documentation est de très bonne qualité, le positionnement est clair :
ne pas *refaire* Bootstrap, rester léger. La documentation sur les bonnes
pratiques pour étendre la CSS est exemplaire. Ah j'oubliais... c'est sous licence
BSD :-)
Enfin, la dernière évolution sur le blog, c'est la migration des commentaires de l'époque PluXml
et à nouveau un formulaire pour soumettre des commentaires sur les articles.
Bonne rentrée.

View file

@ -0,0 +1,44 @@
<!-- title: De l'auto-hébergement au serveur dédié -->
<!-- category: Hébergement -->
<!-- tag: planet -->
Après deux ans en auto-hébergement j'envisage de louer un serveur dédié
physique ou virtuel (les fameux VPS)<!-- more --> pour plusieurs raisons :
- l'augmentation du prix de l'électricité : mon antique portable consomme quand même 90W,
- la baisse du prix des serveurs dédiés,
- l'avantage d'avoir une bande passante non limitée par son upload ADSL pour les services proposés à l'extérieur.
J'ai regardé du côté de Dédibox et de OVH, on peut
avoir son propre petit serveur qui consommera moins de 10W, c'est
toujours ça pour l'environnement. Au niveau des besoins, il y a d'un côté
l'hébergement du blog et de mes outils collaboratifs et de l'autre le
serveur Minecraft. Le serveur Minecraft, c'est pas green IT du tout : du
JAVA, de la CPU à fond, beaucoup de RAM. Prendre un serveur couvrant les deux
besoins m'obligerait à choisir une machine puissante et assez coûteuse
alors que la mode Minecraft peut passer d'ici quelques mois. J'ai donc
décidé de séparer les hébergements :
- un serveur dédié (physique ou virtuel) peu puissant pour le blog et tout ce qui me passe par la tête : un pied à terre sur la Toile,
- un serveur Minecraft mutualisé loué au mois chez un hébergeur spécialisé dans
le serveur de jeux.
Étonnamment je ne devrais pas éclater mon budget que je me suis fixé en dessous
de 10 euros TTC par mois car j'ai découvert, gràce à mon fils tout un monde que
je ne connaissais pas : celui des hébergeurs à prix cassé de serveurs de jeux
clef en main où l'on choisit la capacité en nombre de joueurs simultanés (slots),
où tout s'administre en 3 clics avec une interface d'administration Web, sans
engagement de longue durée. Sans volonté de faire de la pub, il s'agit des
hébergeurs du style de Myriapulse, Verygames, OMGServ. Pour quatre joueurs on
peut louer quelque chose entre 1 et 4 euros par mois. C'est un domaine où la
compétition semble encore plus rude que dans l'hébergement classique.
Pour l'autre serveur (le mien), j'attends de voir les nouvelles offres que OVH
devrait dévoiler cette semaine avant de fixer mon choix. J'ai raté le coche du
Kimsufi 2013 à 5 euros et des brouettes sorti cet été je crois. Depuis OVH a
gelé les locations et revoit en profondeur toutes ses offres pour mieux
adresser les différents marchés de sa clientèle (du particulier fauché au grand
compte) en étant rentable et en situation de monter en charge. Si le serveur
physique est inaccessible, je me rabattrais sur une offre VPS chez OVH ou
ailleurs, ce qui compte c'est d'avoir la latitude d'installer tout ce qu'on
veut dessus.

View file

@ -0,0 +1,81 @@
<!-- title: Ma vie de sysadmin en semi-pro (2) -->
<!-- categories: GNU/Linux BSD -->
<!-- tag: planet -->
Il y a deux logiciels que j'utilise quotidiennent dans mon activité de sysadmin
à temps partiel<!-- more --> :
* [Nas4Free](http://www.nas4free.org)
* [Proxmox](http://www.proxmox.com)
Le premier est une distribution NAS sous FreeBSD qui permet de mettre en place
facilement un serveur de stockage. Si on l'installe sur un vrai serveur avec
plusieurs disques dur, il pourra gérer du Raid 0 (agrégation des disques),
du Raid 1 (miroir d'un disque sur l'autre) voire du Raid 5 avec au moins 4 disques
pour améliorer la tolérance aux pannes. Ce qu'il apporte ensuite, c'est une
facilité de configuration par une interface Web et le support d'un large nombre
de protocoles : Samba, NFS, FTP, Rsync et d'autres plus rares. Comme tout bon logiciel,
on l'installe, on prend le temps de le configurer puis on l'oublie car ça fait le job !
Je l'ai mis en place pour sauvegarder quelques machines en nocturne par Rsync.
C'est de la sauvegarde miroir (pas assez de capacité disque pour faire des sauvegardes tournantes)
avec une copie différentielle de ce qui a changé depuis la veille. Pour GNU/Linux, le programme
rsync de toute distribution qui se respecte combiné avec un CRON fait l'affaire.
Pour Ms Windows, il a fallu tester quelques clients rsync avant de trouver celui qui n'est pas
bogué et qui supporte les noms de fichiers avec accents :
c'est [cwRsync](https://www.itefix.no/i2/content/cwrsync-free-edition). Une tâche programmée
avec Ms Windows permet de lancer la sauvegarde en nocturne. Il est de bon ton de prévoir l'envoi
d'un email avec un compte-rendu de la sauvegarde, pour se rassurer sur le bon fonctionnement et
avoir une trace des fichiers synchronisés. J'ai dégoté le programme [blat](http://www.blat.net)
pour l'envoi d'email facile depuis un batch, il y en a sûrement plein d'autres. Voici un
script batch assez proche de celui que j'utilise :
``` bat
REM ================================================================
REM Synchroniser les changements
REM ================================================================
SET SOURCE=(REPERTOIRE SOURCE)
SET IPNAS=(IP DU NAS4FREE)
SET NOMRSYNC=(NOM DU PARTAGE RSYNC)
rsync --recursive --stats --verbose --size-only --chmod=ugo=rwX --compress --delete
--delete-excluded --force --links --backup --backup-dir=backup
--exclude-from=exclude.txt "%SOURCE%" %IPNAS%::%NOMRSYNC% >rsync.log 2>rsync.err
copy rsync.err+mail.txt+rsync.log rsync.mail
REM ================================================================
REM Envoi de l'email
REM ================================================================
SET FROM=(EXPEDITEUR DE L'EMAIL)
SET TO=(DESTINATAIRE DE L'EMAIL)
SET SMTP=(SERVEUR SMTP)
SET USER=(COMPTE UTILISATEUR)
SET PWD=(MOT DE PASSE)
blat rsync.mail -f %FROM% -to %TO% -server %SMTP% -u %USER% -pw %PWD% -subject "Nightly backup"
```
Une autre utilisation de mon instance Nas4Free est de servir un volume réseau iScsi qui sert
de stockage partagé à un cluster Ms Windows virtualisé qui sert à des tests. Ce qui m'amène au
second logiciel : **Proxmox**. Il s'agit d'une solution de virtualisation du style de VMware ESX
qui tourne sur un serveur dédié, s'administre par une interface Web. En fonction des besoins,
on peut créer des machines virtuelles car Proxmox est un hyperviseur KVM ou bien créer des
containers openvz.
* Les containers sont indépendants comme une machine virtuelle mais c'est réalisé par isolation
des processus et isolation de la mémoire, une sorte de *super Chroot*. Ca ne s'applique donc
qu'aux système GNU/Linux avec la contrainte de ne pas pouvoir choisir le kernel ni le
modifier en rajoutant des modules. Si on n'a pas ces contraintes, les containers sont la
solution privilégiée car ils sont très légers.
* La création de machines virtuelles GNU/Linux ou Ms Windows est la solution pour tous les
autres cas.
Grâce à cette gestion mixte Containers / KVM, un hyperviseur Proxmox qui tourne sur un serveur
récent peut réellement monter en charge. Les formats de VM sont ceux de KVM, il est aisé de convertir
une machine virtuelle VMware ou VirtualBox vers Proxmox. L'interface d'administration est sobre
et fonctionnelle. Elle permet la gestion des machines, leur configuration, la visualisation de
la charge (processeur, mémoire, réseau) par machine ou globale. Une console (qui nécessite le
support de JAVA dans le navigateur Web) peut être démarrée pour prendre le contrôle d'une machine.
Proxmox est sous licence AGPL et une société propose un support pour une souscription annuelle
raisonnable. Je ne l'ai pas expérimenté mais il est possible de mettre en cluster plusieurs instances
de Proxmox ce qui apporte la possibilité de migrer facilement des machines virtuelle ou des containers
d'une instance Proxmox vers une autre.

View file

@ -0,0 +1,36 @@
<!-- title: Bilan de l'hébergement -->
<!-- category: Hébergement -->
<!-- tag: planet -->
C'est fait ! j'ai lâché l'auto-hébergement pour un hébergement chez OVH avec
l'offre VPS (Virtual Private Server) de base<!-- more -->, un container OpenVz dédié,
hébergé à Roubaix sur lequel j'ai choisi d'installer Debian Wheezy. Je gagne de
la bande passante et une bonne qualité de service. L'objectif reste le même,
avoir un serveur dédié à bidouiller qui me fournit quelques services :
- l'hébergement de ce blog,
- une instance de Shaarli pour les favoris [merci SEB Sauvage](http://sebsauvage.net/wiki/doku.php?id=php:shaarli),
- un lecteur de flux RSS : [Tiny Tiny RSS](http://tt-rss.org)
C'est le minimum vital que j'ai réinstallé depuis la migration de mon ancien
serveur auto-hébergé. J'ai encore beaucoup à faire pour automatiser certaines
tâches d'administration, puis pour étoffer les services : faire mon évaluation
annuelle de OwnCloud par exemple.
Au niveau budget je suis en dessous des 100 euros par an : 72 euros pour la
location du VPS, 14 euros pour le domaine et les boites email chez Gandi et 12
euros pour la location du modeste serveur Minecraft chez Nitroserv. Soit un
budget de **8 euros par mois**.
C'est une passion qui reste raisonnable :-)
Au niveau des distributions GNU/Linux, j'ai stabilisé mes usages :
- ArchLinux, ma distrib de coeur à la maison pour sa fraîcheur de paquets, sa
logithèque énorme, sa stabilité qui peut en remontrer à beaucoup d'autres
distributions classiques (qui ne fonctionnent pas en mode *rolling-release*),
- Debian (parfois CentOS) sur les serveurs personnels et professionnels que je
suis amené à installer,
- Fedora sur mon poste professionnel, la distribution *incubateur* de RedHat :
une bonne distribution, pas trop mouvante pour un poste de développement

View file

@ -0,0 +1,47 @@
<!-- title: Mes extensions Firefox -->
<!-- category: Mozilla -->
<!-- tag: planet -->
Malgré quelques tests de la concurrence, je reste fidèle à Firefox depuis la
version 0.5. Il y a eu des hauts et des bas<!-- more -->, je pense notamment à l'époque où
sa consommation mémoire était excessive. Aujourd'hui, c'est, pour moi, le
meilleur navigateur avec une feuille de route claire pour assoir et préserver
les standards ouverts du Web.
**Recherche**
- [Add to Search
Bar](https://addons.mozilla.org/en-US/firefox/addon/add-to-search-bar) :
ajouter facilement le formulaire de recherche d'un site aux moteurs de
recherche.
- [Quick Search
Bar](https://addons.mozilla.org/en-us/firefox/addon/quicksearch) : présenter
la barre de recherche sous forme de liste d'icônes pour changer facilement de
moteur.
**Lecture**
- [Reader](https://addons.mozilla.org/en-US/firefox/addon/reader) : formater la
page en cours pour la lecture avec une visibilité optimale.
**Protection de la vie privée**
- [Ghostery](https://addons.mozilla.org/en-US/firefox/addon/ghostery) : bloquer
les mouchards Web.
- [HTTPS Everywhere](https://www.eff.org/https-everywhere) : forcer
l'utilisation de HTTPS au lieu de HTTP.
- [ProfilePassword](https://freeshell.de/~kaosmos/profilepassword-en.html) : protéger l'accès au profile par un mot de passe au lancement de Firefox.
Utile en environnement professionnel où son navigateur est synchronisé avec son Firefox personnel.
- [Self-Destructing Cookies](https://addons.mozilla.org/en-US/firefox/addon/self-destructing-cookies) : suppression des cookies à la fermeture des onglets.
**Développement Web**
- [FireBreak](https://addons.mozilla.org/en-US/firefox/addon/firebreak) :
tester les *responsive design* avec différentes résolutions.
- [More Display Resolutions](https://addons.mozilla.org/ja/firefox/addon/more-display-resolutions) : idem que le précédent.
- [FireBug](https://getfirebug.com) : l'outil de référence pour le
développement Web, débogueur JavaScript, inspecteur CSS / HTML.
- [YSlow](https://addons.mozilla.org/en-US/firefox/addon/yslow) : un plugin pour FireBug orienté analyse de performance des pages Web.
- [View Dependencies](https://addons.mozilla.org/en-US/firefox/addon/view-dependencies) : ajout d'un onglet aux propriétés d'un site Web pour lister les dépendances
CSS / JS de la page.
- [Dust-me selectors](https://addons.mozilla.org/en-US/firefox/addon/dust-me-selectors) : analyse des sélecteurs CSS utilisés sur la page.