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,58 @@
<!-- title: Fin d'hivernation -->
<!-- category: Humeur -->
<!-- tag: planet -->
Trois mois sans écrire un billet, mon rythme anémique d'un billet par mois est
brisé. Plus d'inspiration, ni trop d'envie... J'essaie d'analyser la cause de
cette panne sèche<!-- more --> et j'entrevois quelques raisons.
D'abord l'évènement "Charlie Hebdo" m'a perturbé. En déplacement professionnel,
j'étais sur Reims le jour de la fusillade et sur Paris le lendemain pour
reprendre le TGV vers ma Provence d'adoption ; j'ai vu le déploiement de force
dans la capitale, je me suis indigné contre les barbares, j'ai compatis avec
les familles des victimes. Puis le matraquage médiatique, la récupération
politique puis la pseudo-canonisation des dessinateurs, ce qui les aurait fait
bien marrer de leur vivant, m'a écoeuré. Suite à cela je me suis un peu
recroquevillé sur mon quotidien ; j'ai arrêté de lire la presse écrite et au
niveau de la radio, en voiture le matin, je zappe entre Nova, Jazz radio et
Rires & Chansons. C'est très apaisant pour l'esprit, je vous le recommande ;-)
Ce repli aurait pu être prolifique pour le blog mais à contrario, j'ai réalisé
peu d'expérimentations méritant un article, pas mal fraggé (gaming quand tu
nous tiens), lu de la BD et gratté un certain nombre de sujets lié au dév
logiciel. Rare linuxerie, le recyclage de mon premier portable (un Toshiba
Portegee M800 core duo) en PC de déplacement malgré sa batterie quasi fichue.
J'ai installé dessus une [Funtoo](http://www.funtoo.org). Ça ne mérite pas un
article mais je suis ravi du résultat même si à première vue une
rolling-release à base de sources paraît irraisonnable sur un petit processeur.
Ah oui, j'ai aussi testé toutes les BSD... [Fredéric ! sors de ce
corps](http://frederic.bezies.free.fr/blog) pour élargir ma culture Unix. Et je
fais [quelques apparitions sur Diaspora](https://framasphere.org/u/yax) pour
suivre les sujets qui me tiennent à coeur.
Sur cette période ma blogsphère a subi quelques coups de Trafalgar :
dissolution du Blog Libre, départ de Tristan Nitot. Mais tout se modifie, rien
ne disparaît vraiment... Les acteurs du Blog Libre continuent à alimenter la
communauté d'articles de qualité et Tristan Nitot a rejoint [Cozy
Cloud](http://cozy.io) pour une nouvelle aventure, ce qui m'a décidé à tester
Cozy d'ailleurs. En tant que développeur, j'ai apprécié l'architecture
technique modulaire et le choix très *hype* du langage NodeJS (ça change du PHP
à Papa) auquel je m'intéresse dans mes projets personnels. J'ai installé Cozy
sur mon VPS (2 vCore, 2Go RAM) et mon impression est mitigée. J'ai apprécié
l'aspect soigné des applications, la cohérence visuelle. Certes des
fonctionnalités manquent si on compare avec OwnCloud mais le produit évolue,
s'enrichit régulièrement. Ce qui m'a gêné ce sont les performances, notamment
les bursts de CPU à l'installation des applications. Il faut que je l'utilise
plus pour voir si c'est aussi le cas dans le cadre d'une utilisation standard
mais je me suis posé la question de la pertinence de NodeJS si des traitements
lourds sont réalisés en backend pour un produit dont la cible est
principalement les Raspberry *like* hébergeant des clouds personnels. En tout
cas je ferais vivre l'installation pour suivre l'évolution du travail de Cozy
Cloud dont l'équipe semble bien sympathique.
Finalement, ce qui me branche le plus en ce moment c'est le code et
l'architecture logicielle. J'ai un certain nombre de technos en cours
d'acquisition et quelques projets en tête. Je ferais peut-être un plus de
sujets sur le code que sur le système cette année.
Bon printemps à tous.

View file

@ -0,0 +1,216 @@
<!-- title: Back to roots, BASH -->
<!-- category: GNU/Linux -->
<!-- tag: planet -->
Quand on utilise un système GNU/Linux ou BSD quotidiennement, même si on n'est
pas un accro de la ligne de commande, on n'échappe pas à l'utilisation du
terminal<!-- more --> pour certaines tâches non graphiques. Le choix du shell, comme le
choix d'une distribution est question de goût personnel : les deux principaux
shell, BASH et ZSH ont chacun leurs supporters. Si vous utilisez un terminal
occasionnellement (qui a dit sous la contrainte) il y a fort à parier que vous
utilisez le shell proposé par la distribution, probablement **BASH** dans une
configuration standard qui vous convient tout à fait. Néanmoins, il est
intéressant de personnaliser la configuration de son shell pour se l'approprier.
C'est *fun à réaliser* et cela donne envie de faire plus de choses depuis le
terminal.
<img src="/images/2015/stallman-code.jpg" alt="Un barbu" style="margin: 0px
20px; float:right;" /> Bon si dans quelques mois, les annonces de sortie du nouveau KDE ou
Gnome vous font ricaner, que vous ne jurez que par
[Awesome](http://awesome.naquadah.org),
[Rxvt](http://sourceforge.net/projects/rxvt) et
[Tmux](http://tmux.sourceforge.net), vous êtes au bout du chemin, peut-être un
peu trop loin d'ailleurs et vos contacts IRC ont tous une forte pilosité ;-)
### Le prompt PS1
Le prompt est l'invite répétée en début de ligne, entre chaque commande, un
truc du genre **bob@montux >**. Le prompt est porté par la variable PS1 dans le
fichier de config BASH de chaque utilisateur (~/.bashrc). En fonction des goûts
là encore, le prompt peut être synthétique et court ou afficher le maximum
d'informations et prendre une ligne entière. Le site
[Bashrcgenerator.com](http://bashrcgenerator.com) propose un générateur de
prompt par drag and drop qui couvre une petite partie de ce qui est possible.
On peut ajouter des codes ANSI pour coloriser certaines informations. [La doc
ArchLinux est exhaustive sur ces
codes](https://wiki.archlinux.org/index.php/Color_Bash_Prompt). Il ne faut pas
oublier de réinitialiser la couleur en fin de prompt pour que ça ne coule pas
sur le reste de la ligne avec un reset. je suis adepte des prompts concis :
``` shell
White='\e[0;37m' # White
Red='\e[0;31m' # Red
Reset=$(tput sgr0)
PS1="\[$White\]\u:\[$Red\]\w\[$White\] \$\[$Reset\] "
```
Pour des prompts plus sophistiqués, on peut utiliser des fonctions shell pour
ajouter des informations dynamiques en fonction du contexte, les infos GIT dans
le contexte d'un répertoire de source par exemple, la charge CPU, l'état de la
batterie. [Le projet LiquidPrompt](https://github.com/nojhan/liquidprompt) en
est un parfait exemple facile à configurer.
### Les alias et les fonctions
les alias sont des substitutions de commandes. On peut les utiliser pour éviter
de mémoriser des paramètres compliquées en définissant de nouvelles commandes :
``` shell
alias la='ll -A' # 'la' : voir les fichiers cachés
alias lk='ls -lSr' # 'lk' : trier par taille
```
Ou bien on peut redéfinir le comportement d'une commande en créant un alias du
même nom forçant des paramètres :
``` shell
# forcer une demande de confirmation pour éviter les boulettes
alias rm='rm --interactive --verbose'
alias mv='mv --interactive --verbose'
```
Quant aux fonctions, elles permettent de définir des commandes en langage shell
directement dans le fichier .bashrc. On peut facilement abuser de cette
possibilité et alourdir le fichier avec des commandes qu'on utilise une fois
l'an. Dans ce cas, il est préférable de les sortir et de créer des fichiers
exécutables accessibles dans le PATH (/usr/local/bin au hasard).
Voici les deux fonctions que j'utilise assez régulièrement :
``` shell
function bak() { cp "$1" "$1_`date +%Y-%m-%d_%H-%M-%S`" ; }
function extract() # Handy Extract Program
{
if [ -f $1 ] ; then
case $1 in
*.tar.bz2) tar xvjf $1 ;;
*.tar.gz) tar xvzf $1 ;;
*.bz2) bunzip2 $1 ;;
*.rar) unrar x $1 ;;
*.gz) gunzip $1 ;;
*.tar) tar xvf $1 ;;
*.tbz2) tar xvjf $1 ;;
*.tgz) tar xvzf $1 ;;
*.zip) unzip $1 ;;
*.Z) uncompress $1 ;;
*.7z) 7z x $1 ;;
*) echo "'$1' cannot be extracted via >extract<" ;;
esac
else
echo "'$1' is not a valid file!"
fi
}
```
### Les couleurs de LS
[dircolors](http://linux.die.net/man/1/dircolors) est une commande qui permet
d'afficher le résultat de la commande **ls** en couleur. La plupart des config
bashrc testent si dircolors est présent et l'utilise en rajoutant --color à
ls par le biais d'un... alias (bravo à ceux qui n'ont pas lâché). Généralement,
on a une section de ce genre dans notre .bashrc :
``` shell
# enable color support of ls
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
alias ls='ls --color=auto'
fi
```
Si vous avez une section de ce genre, vos commande ls sont déjà colorisées.
Mais le choix des couleurs et le style est configurable en exportant une
variable **LS_COLORS**. Son format est une liste séparée par des
':'. Chaque élément définit la couleur et l'effet d'un type de fichier ou d'une
extension.
Les types de fichiers :
- no NORMAL, NORM Global default, although everything should be something
- fi FILE Normal file
- di DIR Directory
- ln SYMLINK, LINK, LNK Symbolic link. If you set this to target instead of a numerical value, the color is as for the file pointed to.
- pi FIFO, PIPE Named pipe
- do DOOR Door
- bd BLOCK, BLK Block device
- cd CHAR, CHR Character device
- or ORPHAN Symbolic link pointing to a non-existent file
- so SOCK Socket
- su SETUID File that is setuid (u+s)
- sg SETGID File that is setgid (g+s)
- tw STICKY_OTHER_WRITABLE Directory that is sticky and other-writable (+t,o+w)
- ow OTHER_WRITABLE Directory that is other-writable (o+w) and not sticky
- st STICKY Directory with the sticky bit set (+t) and not other-writable
- ex EXEC Executable file (i.e. has x set in permissions)
- mi MISSING Non-existent file pointed to by a symbolic link (visible when you type ls -l)
- lc LEFTCODE, LEFT Opening terminal code
- rc RIGHTCODE, RIGHT Closing terminal code
- ec ENDCODE, END Non-filename text
- \*.extension Every file using this extension
les effets :
- 00 Default colour
- 01 Bold
- 04 Underlined
- 05 Flashing text
- 07 Reversetd
- 08 Concealed
Les couleurs :
- 30 Black
- 31 Red
- 32 Green
- 33 Orange
- 34 Blue
- 35 Purple
- 36 Cyan
- 37 Grey
les couleurs de fond :
- 40 Black background
- 41 Red background
- 42 Green background
- 43 Orange background
- 44 Blue background
- 45 Purple background
- 46 Cyan background
- 47 Grey background
Les couleurs suppplémentaires :
- 90 Dark grey
- 91 Light red
- 92 Light green
- 93 Yellow
- 94 Light blue
- 95 Light purple
- 96 Turquoise
- 97 White
- 100 Dark grey background
- 101 Light red background
- 102 Light green background
- 103 Yellow background
- 104 Light blue background
- 105 Light purple background
- 106 Turquoise background
Les couleurs par défaut de **dircolors** sont bien pensées mais je n'aime pas
l'utilisation abusive de l'empâtement gras. Je définis donc la couleur bleue
pour l'affichage des répertoire mais en style non gras, je mets par contre en
gras les répertoire ouverts à tous les vents (avec les droits d'écriture sur le
groupe *other*), et en rouge non gras les fichiers exécutables.
``` shell
export LS_COLORS="di=00;34:ow=01;34:ex=00;31"
```
J'espère que ces quelques exemples donnent envie de plonger dans les arcanes du
fichier .bashrc pour l'ajuster à sa sauce et utiliser un peu plus la ligne de
commande. De plus en plus de monde conserve ses fichiers de configuration sur
GIT pour avoir un référentiel rapidement installable sur ses systèmes. C'est
une habitude à laquelle j'ai aussi succombé : j'ai un projet [dotfiles sous
GitHub](https://github.com/kianby/dotfiles).

View file

@ -0,0 +1,48 @@
<!-- title: Hébergement en mouvance -->
<!-- category: Hébergement -->
<!-- tag: planet -->
Très satisfait de mon hébergeur actuel, je reste à l'écoute du marché. Ah
pardon on ne parle pas recrutement<!-- more --> j'ai confondu ;-) Je reprends : bien que
très satisfait de mon hébergement je me suis laissé tenter par
[FirstHeberg](https://www.firstheberg.com) qui propose une large gamme de VPS
répartie en trois familles :
- des containers légers OpenVz
- des machines virtuelles Qemu
- des machines virtuelles Qemu avec option de sauvegarde
Chaque famille se décline bien sûr en plusieurs puissances, plusieurs capacités
RAM et disque. Ce qui m'a intéressé c'est la possibilité de louer une machine
virtuelle pour le même prix que mon conteneur OpenVz actuel. J'ai donc souscrit
à l'offre GP1 cette semaine en choisissant un système Debian 8 (Jessie). La
livraison est classique avec l'envoi des informations de connexion adresse IP,
DNS en fhnet.fr et mot de passe du compte root. Le service SSH est activé en
standard. Je n'ai pas encore beaucoup joué avec les outils mais une interface
d'administration sobre fournit l'essentiel : un redémarrage forcé de la VM, la
possibilité de réinstaller avec l'OS de son choix et des graphes d'activité du
VPS pour la dernière heure : utilisation CPU, consommation mémoire, trafic
réseau et activité disque.
Mon objectif c'est de migrer progressivement les services d'un serveur à
l'autre. Alors plutôt que de réinstaller manuellement j'ai saisi l'opportunité
de me former à [Ansible](http://docs.ansible.com), un outil de déploiement et
des gestion des configurations. L'utilisation usuelle consiste à définir des
recettes d'installation (*playbook* dans la terminologie Ansible) et de
vérifier la conformité des cibles de déploiement avec ces recettes. C'est un
outil utilisé pour superviser des parcs de serveurs mais il a aussi de
l'intérêt dans mon cas d'utilisation : j'ai créé une machine virtuelle sous
Virtual Box avec les caractéristiques du serveur FirstHeberg et je mets au
point mes playbooks. L'idée c'est de valider systématiquement sur la machine
virtuelle locale avant de mettre en production et de formaliser le déploiement
du serveur à la sauce Ansible qui emploie un format textuel et compréhensible
afin de *versionner* les changements sous GIT et faciliter le changement
d'hébergement dans l'avenir, bref d'avoir une démarche un peu plus
professionnelle quant à la gestion des configurations du serveur.
Pour l'anecdote, Ansible est un outil Python (hé oui encore un) comme
[Fabric](http://www.fabfile.org) (que je connais et utilise déjà) et il ne
demande qu'un accès SSH pour interagir avec les serveurs. De bons articles ont
déjà été publiés sur le [Planet](http://www.planet-libre.org), je peux rajouter
l'excellent [tuto de leucos](https://github.com/leucos/ansible-tuto) qui
complète la documentation officielle déjà très complète par des exemples.

56
posts/2015/2015-06-09-srmail.md Executable file
View file

@ -0,0 +1,56 @@
<!-- title: SRmail -->
<!-- category: Développement -->
<!-- tag: planet -->
J'ai développé un petit bout de logiciel nommé, sans grande inspiration, SRmail
pour "Simple Rest Mail"<!-- more --> avec les technos que j'apprécie : le langage Python et
le framework Web Flask. Le but de SRmail est de fournir un service local de
récupération et d'envoi de courriels à d'autres applications. En gros, c'est
une brique logicielle à l'écoute sur l'interface **localhost** qui permet de
lire et d'envoyer des messages à travers une API Restful. J'insiste sur le
terme local car l'API n'est absolument pas sécurisée : un fichier de
configuration donne les pleins pouvoirs à SRmail pour gérer un compte par les
protocoles IMAP et SMTP. L'intérêt c'est de centraliser la complexité de
gestion des e-mails et de mutualiser un service entre plusieurs applications en
plaçant la barre au niveau applicatif et non pas système.
Le code et la documentation sont [sur mon
GitHub](https://github.com/kianby/srmail). Ça s'installe facilement à la sauce
Python dans un *virtualenv* de préférence, avec le gestionnaire de paquets
**pip** pour récupérer les dépendances.
Voici un exemple d'envoi d'e-mail en Python :
``` python
import requests
headers = {'Content-Type': 'application/json; charset=utf-8'}
msg = {
'to': 'bill@phoenix.com',
'subject': 'Got it',
'content': 'See you soon!\n\n-- John'
}
r = requests.post('http://localhost:8000/mbox', data=json.dumps(msg), headers=headers)
if r.status_code == 200:
logger.debug('Email for %s posted' % to_email)
else:
logger.warn('Cannot post email for %s' % to_email)
```
Et voici le même exemple en ligne de commande avec CURL :
``` shell
curl -X POST -H "Content-Type: application/json; charset=utf-8"
-d '{"to":"bill@phoenix.com", "subject":"Got it",
"content":"See you soon!\n\n-- John"}'
http://localhost:8000/mbox
```
Plutôt que de faire du *polling* pour voir si de nouveaux messages sont
arrivés, on peut définir la fréquence de polling au niveau de SRmail ainsi que
des URL de notification vers lesquelles seront postés les messages au format
JSON.
Pour le déploiement de mes applications Python j'utilise [Supervisor](/supervisor-gestion-de-processus.html) qui
permet de s'abstraire du système d'init (SysV, OpenRC, systemd).
Voilà c'est sans prétention un outil qui peut vous être utile.

View file

@ -0,0 +1,65 @@
<!-- title: Une semaine ordinaire -->
<!-- category: Humeur -->
<!-- tag: planet -->
Toute ressemblance avec des événements réels s'étant déroulés cette semaine
dans ma sphère professionnelle n'est pas fortuite.<!-- more --> La semaine a été riche en
péripéties système et réseau, ce qui me conforte dans l'idée que gérer un
réseau de centaines de machines ça doit pas être facile tous les jours. Fou le
temps qu'on peut déjà passer avec une trentaine en faisant cela en dilettante
puisque mon métier principal c'est développeur.
Orange fournit un service d'adresse de messagerie pour les professionnels avec
une sécurité renforcée. Pour lutter contre le SPAM, ils s'assurent notamment
que les e-mails sont envoyés depuis une machine de confiance. L'envoi d'e-mails
de ma société est devenu erratique depuis mardi. Un message un peu cryptique du
support Orange nous informe que notre IP publique est *sur liste noire* donc
tout le trafic Internet qui sort de nos machines est suspect. Cela explique le
blocage des e-mails par le serveur SMTP Orange Business. Comment en est-on
arrivé à cette situation et comment en sortir ? Un tour sur [ce genre de site
]( http://whatismyipaddress.com/blacklist-check) permet de consulter les sites
de référence des *listes noires* et sur certains de connaître la cause. Dans
notre cas, le trafic Internet d'un virus sortant de notre réseau a été détecté,
ce qui nous a promu au rang de site louche. Pour sortir de cette situation il
faut résoudre le problème (éradiquer les machines infectées) puis demander à
sortir de la liste noire sur sa bonne foi d'admin. Au bout de 24/48h tout
rentre dans l'ordre.
Dans un autre registre, je constate que le voisinage réseau des machines Ms
Windows (en Workgroup) est parfois incomplet, ne présentant qu'un sous-ensemble
des machines. Un test depuis différents OS (Windows 7, Windows 2003) me
confirme que ce n'est pas particulier à ma Fedora et sa configuration Samba.
Pour ce que j'en sais, dans un réseau modeste en WORKGROUP, sans controlleur de
domaine, les machines participent à une élection pour élire un *master
browser*, celle qui va fournir la liste du voisinage réseau. Je crains qu'avec
nos machines de test à droite à gauche, on élise parfois une machine qui n'a
pas de visibilité complète sur l'ensemble du réseau. La commande **nmblookup**
des outils SAMBA permet de connaître l'adresse IP du *master browser* en cours,
sachant qu'il change régulièrement :
nmblookup -S -M -- -.
Comme dans la vie réelle, une solution consiste à influer sur le résultat de
l'élection. C'est possible avec SAMBA et son paramétrage avancé qui lui permet
de concourir à l'élection du *Master Browser* avec une telle réputation qu'il
ne peut qu'être élu par ses pairs. J'ai utilisé un serveur NAS local (NAS4FREE
sous BSD, toujours en ligne) pour ce rôle d'élu. Le voisinage réseau est
désormais complet en toute circonstance.
Pour terminer la semaine en beauté, on me met le nez sur un problème de Wi-Fi
récurrent (et aléatoire sinon c'est pas drôle) : accroche du réseau mais pas
d'accès Internet. Le Wi-Fi n'est pas majoritairement utilisé dans la société
donc il impacte peu de monde et le problème traîne depuis un bail. J'avais
envisagé un dysfonctionnement des répéteurs sans fil et évacué le problème dans
ma tête. Mais vendredi, le problème est presque systématique je décide de le
prendre à bras le corps. Armé d'une tablette Lenovo (attention *placement de
produit* comme dirait mon fils) je regarde si je peux me connecter en DHCP mais
spécifier un autre serveur DNS quand l'adresse IP que le serveur m'a assigné
m'attire l'oeil : rien à voir avec notre réseau et non routable vers Internet.
Après recherche on découvre un petit routeur de test branché sur le réseau avec
la fonction "serveur DHCP" activée. Deux serveurs sur le même LAN : c'est le
plus rapide qui répond aux demandes, cela explique le côté aléatoire du
problème.
Ce qui me plaît dans l'administration système et réseau c'est la diversité des
problèmes et des solutions.

View file

@ -0,0 +1,130 @@
<!-- title: Déploiement et sauvegarde -->
<!-- category: Hébergement -->
<!-- tag: planet -->
J'ai terminé la migration de mon serveur.<!-- more --> [Comme
annoncé](http://blogduyax.madyanne.fr/hebergement-en-mouvance.html) j'ai
utilisé l'outil de déploiement
[Ansible](https://fr.wikipedia.org/wiki/Ansible_%28logiciel%29) pour :
- conserver l'historique d'installation du serveur,
- valider au préalable sur une machine virtuelle locale l'installation de
nouveaux services,
- être capable de rapidement redéployer un nouveau serveur.
J'ai d'abord écrit un playbook de base qui configure à mon goût une Debian
fraîchement installée : paquets supplémentaires, création des utilisateurs,
préférences de Bash, Tmux et Vim. Les préférences sont récupérées depuis [mon
projet dotfiles sur GitHub](https://github.com/kianby/dotfiles) et Ansible
s'occupe de leur installation. Si demain je modifie mon prompt Bash ou si
rajoute un plug-in à ma configuration Vim, je peux facilement synchroniser les
changements avec un *git pull*. Ce playbook m'a déjà resservi sur le plan
professionnel, c'est un investissement de temps déjà rentabilisé. Je l'ai
publié dans [un projet provisioning sur
GitHub](https://github.com/kianby/provisioning).
Le second playbook est beaucoup plus personnel puisqu'il déploie ce blog. En
cas de pépin il me permettra de me remettre en ligne rapidement. C'est un
playbook qui peut servir de tutorial, il n'est pas complexe mais mixe
différents types de tâches : installation de fichiers, manipulation de GIT,
enregistrement de tâches dans Cron.
Ceci dit, à contrario de mon idée initiale, je n'ai pas écrit de playbooks pour
l'intégralité des services à déployer car c'est très consommateur en temps (or
je suis fainéant : souvenez vous je suis développeur) et c'est peu intéressant
pour des services faciles à installer et périssables. Je prends pour exemple
[Piwik, l'outil de statistiques de site Web](https://piwik.org/) ; c'est une
application LAMP (Linux, Apache, MySQL, PHP) classique qui par la suite est
capable de se mettre à jour elle-même. Je n'ai pas vu d'intérêt à créer un
playbook pour installer une version de Piwik qui sera obsolète dans 2 mois et
de passer du temps à maintenir un playbook au lieu de maintenir mon serveur.
Mes autres services, soit moins critiques, soit mis à jour automatiquement ont
donc été installés manuellement : Piwik, Tiny Tiny RSS, Owncloud, Shaarli et
Roundcube.
L'installation est donc achevée, je suis à priori capable de remonter le blog
en moins de deux heures sur un nouveau serveur (ce qui prendra plus de temps
c'est de faire pointer les DNS vers la nouvelle adresse du site). Il me reste
à détailler le sujet des sauvegardes.
Mon besoin est modeste mais précis :
- les articles du blog sont déjà sauvegardés dans
[GitHub](https://github.com/kianby/blog) (merci les blogs statiques) mais je
dois sauvegarder les commentaires,
- sauvegarder la base de donnée MySQL de Tiny Tiny RSS n'a aucun intérêt mais
sauvegarder le fichier OPML qui contient mes abonnement RSS est important,
- sauvegarder mes favoris conservés par Shaarli est essentiel,
- peu m'importe mes fichiers synchronisés avec Owncloud puisque j'ai une copie
locale par contre il m'importe de sauvegarder mon calendrier.
- sauvegarder les configuration du serveur HTTP (NginX dans mon cas)
Ma solution est atypique et peut-être un mauvais exemple mais elle répond à mon
besoin et je n'avais aucune envie de sortir la grosse artillerie, de dumper
toutes mes bases et tout mon répertoire /var/www avec des centaines de fichiers
pour créer des grosses archives sauvegardées incrémentalement vers ... un FTP
distant ou autre. Je suis parti du principe qu'en cas de crash, je serais
capable de remonter le blog rapidement et que je prendrais plus de temps pour
remonter mes services donc je focalise sur les données de ces services. Ce qui
est important par contre, c'est d'avoir une sauvegarde avec rotation qui
conserve les 2 derniers jours, 2 dernières semaines et 2 derniers mois pour
avoir un historique et revenir en arrière en cas de problème. J'ai donc
personnalisé [un modeste shell
script](https://nicaw.wordpress.com/2013/04/18/bash-backup-rotation-script) qui
a le bon goût de gérer la rotation des sauvegardes, pour :
- d'abord récupérer toutes mes données à sauvegarder à droite à gauche par
différents moyens : copie, extraction avec les API proposées par les
applications,
- et ensuite envoyer la sauvegarde quelque part.
Sachant que je n'ai pas d'autre serveur ou d'espace FTP je me suis demandé où
serait ce *quelque part*. J'ai regardé un peu [la solution
Hubic](https://hubic.com/fr/) mais la complexité pour en détourner l'usage de
base qui est la synchronisation de fichiers et monter l'espace Hubic comme
stockage distant m'a peu motivé. Une sauvegarde c'est bien quand ça fait son
boulôt et qu'on l'oublie. J'ai moins de 2 Mo à sauvegarder par jour j'ai donc
eu une idée, tordue au premier abord et peut-être bien aussi au second (d'un
autre côté je suis le gars qui s'acharne à greffer des systèmes de commentaires
à des blogs statiques donc ça n'étonnera peut-être pas grand monde) : balancer
mes sauvegardes dans Owncloud ainsi elles seront synchronisées sur mes machines
locales et j'aurais une notification journalière que la sauvegarde s'est bien
déroulée.
Voici donc les grandes lignes de la partie **récupération des données** :
``` shell
# Les fichiers de configuration de NginX
cp -r /etc/nginx/* $TARGET_DIR/nginx/.
# Les favoris de Shaarli stockées dans des fichiers PHP
cp /var/www/shaarli/data/* $TARGET_DIR/shaarli/.
# Le fichier OPML de Tiny Tiny RSS par son URL publique
wget "http://ttreader.madyanne.fr/opml.php?op=publish&key=XYXYXYXYXYXYXYXYXYX" \
-O $TARGET_DIR/reader/reader.opml
# Le fichier ICS du calendrier Owncloud
OC_USER=owncloud_user
OC_PWD=owcloud_password
wget --no-check-certificate --auth-no-challenge --no-clobber \
--http-user=$OC_USER --http-password=$OC_PWD \
-O $TARGET_DIR/owncloud/cal.ics \
"https://owncloud.madyanne.fr/index.php/apps/calendar/export.php?calid=1"
```
Suite à cela, le script crée une belle archive et la copie dans un répertoire
*backup* de mes fichiers Owncloud. Ce n'est pas suffisant pour qu'elle soit
synchronisée par Owncloud car on l'a copié en douce. Il faut forcer Owncloud à
rescanner son répertoire avec la commande suivante exécutée en tant
qu'utilisateur *www-data*:
``` shell
su -c "/usr/bin/php /var/www/owncloud/console.php files:scan all" \
-s /bin/sh www-data
```
Il reste encore un peu de peaufinage mais ça semble faire le boulôt et je vois la
fin du tunnel de cette migration de serveur.
![Rabbit](/images/2015/rabbit_hole.jpg)

View file

@ -0,0 +1,183 @@
<!-- title: Configuration de Fail2Ban -->
<!-- category: Hébergement -->
<!-- tag: planet -->
Après [l'aspect de la
sauvegarde](http://blogduyax.madyanne.fr/deploiement-et-sauvegarde.html) je me
suis attaqué à la sécurisation du serveur.<!-- more --> C'est un vaste sujet et on n'est
jamais certain d'être parfaitement protégé : on se documente et on essaie de
parer à l'essentiel. Je recommande cet article publié sur [Mes potes
Geek](https://mespotesgeek.fr/debian-8-jessie-securisation/) qui dresse un
panorama des outils couramment utilisés et leur mise en oeuvre. Un des piliers
de la sécurisation d'un serveur GNU/Linux est l'outil
[Fail2Ban](http://www.fail2ban.org) qui va surveiller les logs du serveur pour
trouver des traces d'attaque et contre-attaquer en bannissant le malotru.
Techniquement, l'outil parse les logs systèmes ou applicatifs à grand coup
d'expressions régulières et bloque les attaques avec le pare-feu
[iptable](https://fr.wikipedia.org/wiki/Iptables). Les règles de bannissement
sont configurables : nombre de tentatives de connexions infructueuses, durée du
bannissement. On peut facilement étendre Fail2Ban pour ajouter la surveillance
d'une application *maison* pour peu qu'elle écrive dans un log les tentatives
ratées de connexion et on peut aussi personnaliser les notifications. En
standard, Fail2Ban envoie un e-mail à l'administrateur à chaque *ban*. En
pratique, un petit serveur comme le mien bannit une quinzaine d'adresses IP par
jour, essentiellement des tentatives ratées par SSH et c'est vite fastidieux de
recevoir autant d'e-mails. Fail2Ban propose un envoi groupé, c'est à dire qu'il
regroupe un nombre d'attaques paramétrable dans un seul e-mail. C'est mieux
mais je suis habitué à configurer mes outils pour recevoir des rapports à
fréquence fixe, journaliers ou hebdomadaires. N'ayant rien trouvé en standard,
j'ai décidé d'étendre Fail2Bane avec mon propre script de configuration pour
arriver au résultat voulu.
Sur Debian, la configuration est installée sous **/etc/fail2ban**. Dans ce
répertoire, on va trouver */etc/failban/filter.d/* qui contient les filtres de
détection et */etc/fail2ban/action.d/* qui contient les actions à appliquer.
Le fichier de configuration principal est *jail.conf* mais on ne le modifie
jamais (pour éviter de perdre les modifications lors des mises à jour de
fail2ban). On préfère redéfinir les parties de la configurations modifiées dans
un fichier *jail.local*. Pour rajouter une action personnalisée, on va donc
rajouter un fichier d'action dans */etc/fail2ban/action.d* et décrire quand et
comment l'appliquer dans *jail.local*.
J'ai donc dupliqué le fichier d'action *sendmail-buffered* et je l'ai adapté
pour créer *sendmail-cron*. Pourquoi CRON ? Et bien l'idée est la suivante :
chaque bannissement est écrit dans un fichier temporaire par
*sendmail-buffered* et quand le nombre de ligne configuré est atteint, ce
fichier est envoyé par e-mail. Je conserve ce fonctionnement mais je change le
déclencheur de l'envoi : ce n'est plus le nombre de lignes du fichier mais la
présence d'un fichier *mail.flag* dans un certain répertoire qui conditionne
l'envoi. Ce fichier *mail.flag* est créé par une tâche CRON. Ainsi, on délègue
à CRON la configuration de la fréquence d'envoi du rapport.
Quant au fichier d'action, il est simple : on conserve les IP bannies dans un
fichier temporaire avec le détail de l'opération (date de l'attaque, filtre
concerné, IP source) et on regarde si on a le feu vert pour créer le rapport en
testant la présence du fichier *mail.flag*. Si c'est le cas, on envoie le
rapport puis on supprime le fichier temporaire et le fichier *mail.flag*. Voici
le fichier */etc/fail2ban/action.d/sendmail-cron.conf* complet :
```
# Fail2Ban configuration file
#
# Author: Yannic Arnoux
# Based on sendmail-buffered written by Cyril Jaquier
#
#
[INCLUDES]
before = sendmail-common.conf
[Definition]
# Option: actionstart
# Notes.: command executed once at the start of Fail2Ban.
# Values: CMD
#
actionstart = printf %%b "Subject: [Fail2Ban] <name>: started on `uname -n`
From: <sendername> <<sender>>
To: <dest>\n
Hi,\n
The jail <name> has been started successfully.\n
Regards,\n
Fail2Ban" | /usr/sbin/sendmail -f <sender> <dest>
# Option: actionstop
# Notes.: command executed once at the end of Fail2Ban
# Values: CMD
#
actionstop = if [ -f <tmpfile> ]; then
printf %%b "Subject: [Fail2Ban] Report from `uname -n`
From: <sendername> <<sender>>
To: <dest>\n
Hi,\n
These hosts have been banned by Fail2Ban.\n
`cat <tmpfile>`
\n,Regards,\n
Fail2Ban" | /usr/sbin/sendmail -f <sender> <dest>
rm <tmpfile>
fi
printf %%b "Subject: [Fail2Ban] <name>: stopped on `uname -n`
From: Fail2Ban <<sender>>
To: <dest>\n
Hi,\n
The jail <name> has been stopped.\n
Regards,\n
Fail2Ban" | /usr/sbin/sendmail -f <sender> <dest>
# Option: actioncheck
# Notes.: command executed once before each actionban command
# Values: CMD
#
actioncheck =
# Option: actionban
# Notes.: command executed when banning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: See jail.conf(5) man page
# Values: CMD
#
actionban = printf %%b "`date`: <name> ban <ip> after <failures> failure(s)\n" >> <tmpfile>
if [ -f <mailflag> ]; then
printf %%b "Subject: [Fail2Ban] Report from `uname -n`
From: <sendername> <<sender>>
To: <dest>\n
Hi,\n
These hosts have been banned by Fail2Ban.\n
`cat <tmpfile>`
\n,Regards,\n
Fail2Ban" | /usr/sbin/sendmail -f <sender> <dest>
rm <tmpfile>
rm <mailflag>
fi
# Option: actionunban
# Notes.: command executed when unbanning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: See jail.conf(5) man page
# Values: CMD
#
actionunban =
[Init]
# Default name of the chain
#
name = default
# Default temporary file
#
tmpfile = /var/run/fail2ban/tmp-mail.txt
# Default flag file
#
mailflag = /var/run/fail2ban/mail.flag
```
Dans mon cas, la tâche CRON est journalière :
``` shell
# fail2ban report
@daily touch /var/run/fail2ban/mail.flag
```
Ceux qui suivent ont remarqué que mon rapport ne sera envoyé que sur un
bannissement donc potentiellement longtemps après que la tâche CRON ait créé le
fichier *mail.flag*. Je fais confiance à mes intrus et à leurs tentatives
soutenues pour que ce rapport soit bien envoyé à une fréquence journalière ;-)
Il reste à configurer fail2ban pour utiliser cette nouvelle action. J'ai
redéfini dans ma configuration *jail.local* les actions à appliquer sur
détection d'attaque : d'abord on bloque, ensuite on informe :
action_mwlc = %(banaction)s[name=%(__name__)s, port="%(port)s",
protocol="%(protocol)s", chain="%(chain)s"]%(mta)s-cron[name=%(__name__)s,
dest="%(destemail)s", logpath=%(logpath)s, chain="%(chain)s", sendername="%(sendername)s"]
action = %(action_mwlc)s
Il reste à redémarrer Fail2Ban et à attendre l'envoi du prochain rapport.
Au fait, je reviens à peine de vacances où j'ai rencontré un postulant au rôle de mascotte de ce blog :D
![poulet](/images/2015/poulet.jpg)

View file

@ -0,0 +1,66 @@
<!-- title: Le linuxien, le libriste et l'eco-citoyen cherchent un téléphone respectable -->
<!-- category: Mobilité -->
<!-- tag: planet -->
Ces trois tendances se mélangent, à des teneurs différentes, chez la
plupart d'entre nous.<!-- more -->
- linuxien car on l'aime beaucoup notre système (tout en se tenant au courant
des cousins BSD). On aime sa bidouillabilité, sa stabilité, la
logithèque illimitée, la foison des distributions et les débats sans fin qui en
decoulent.
- libriste : de même que les antibiotiques ne sont pas automatiques, le
linuxien n'est pas forcément un gladiateur du Libre. Libriste c'est un idéal
trop exigeant dans notre monde imparfait, on ne l'atteint pas mais on essaie de
s'en rapprocher et c'est déjà bien.
- éco-citoyen (cherchez l'intrus) : rien à voir avec les deux tendances
précédentes mais c'est un trait commun des linuxien que je connais. Sensibilisé
à l'écologie, au recyclage, aux énergies propres, on espère que l'Open Source
s'étende à tous les domaines pour favoriser l'émergence de solutions
désintéressées.
Le terme *respectable* va beaucoup varier d'une personne à l'autre.
Pour un linuxien, le téléphone *évident* est un Android. Si on rajoute une dose
plus ou moins forte de librisme à l'individu (une bonne injection d'hormone
RML), Android n'est plus acceptable ou alors nu, débarrassé des applications
Google avec F-Droid en remplacement du Play Store. D'autres alternatives
existent : la plus libriste (pour ceux qui ont eu une double injection de RML),
c'est Firefox OS. Le système mâture assez vite. Je suis intéressé, quand il y
aura la fonction hotspot 3G, Firefox OS ce sera une option viable pour moi.
Encore plus discret que Firefox OS, les premiers téléphones Ubuntu pointent
leur nez. L'attrait pour un linuxien c'est d'avoir un vrai GNU sous le capot et
l'annonce par Canonical de la Convergence (vers le mois d'octobre) est
alléchante : cela s'apparente au concept initial d'Ubuntu Edge, la possibilité
de transformer son téléphone en ordinateur. On peut voir quelques vidéos *buzz*
ou la connexion d'une souris bluetooth au téléphone passe les applications en
mode fenêtré. BQ a lancé deux téléphones à un tarif très abordable, de bonne
facture mais le système serait un peu lent (cela rapelle les premières versions
d'Android sur le G1). A voir si des optimisations à court terme du système
arrangeront le problème.
Une autre alternative de niche, c'est l'entreprise Jolla, fondée par des
anciens de Nokia. Jolla a poursuivi le projet Maemo pour en faire Sailfish OS,
un système esthétiquement très beau, basé sur un vrai GNU/Linux. Le hic c'était
les applications car s'il est, paraît-il, simple de porter des applications
existantes, comment motiver des développeurs à le faire ? Firefox OS, sorti
plus tard, et ses Web Apps est probablement plus connu par les développeurs. En
réponse, Jolla a joué la carte de la compatibilité avec les applications
Android (comme Blackberry OS 10) pour grossir le catalogue des applications.
Et l'eco-citoyen qui sommeille, que veux-t-il ?
- un téléphone avec une durée de vie plus longue : Firefox OS et ses builds
communautaires vont dans ce sens, ainsi que Ubuntu qui déploie ses mise à jour
régulièrement et en direct (sans validation de l'opérateur). Le projet ARA de
Google est une réponse matérielle ; un téléphone modulaire avec une durée de
vie plus longue.
- un téléphone équitable (fabriqué sans exploitation des travailleurs) : le
projet [FairPhone](https://www.fairphone.com) est une solution mais le prix de
l'équitable reste *prohibitif*.
Difficile de concilier toutes ces tendances, le mouton à 5 pattes n'existant
pas, on va forcément choisir un compromis acceptable qui satisfait notre
conscience de linuxien / libriste / éco-citoyen.

View file

@ -0,0 +1,94 @@
<!-- title: Rovio va mal et c'est mérité -->
<!-- categories: Humeur Android -->
<!-- tag: planet -->
En 2010 j'achetais [un Motorola Milestone sous Android 2.1
*Eclair*](http://blogduyax.madyanne.fr/hello-moto-droid.html). C'était mon
premier (et dernier à ce jour) téléphone sous ce système<!-- more --> et aussi mon premier
tactile. Un bel object de type *slider* avec un clavier physique qu'on pouvait
sortir en mode paysage. J'ai utilisé beaucoup d'applications sur ce téléphone
et aussi testé quelques jeux. Etant plutôt un joueur PC, les quelques jeux qui
me plaisaient étaient ceux réellement pensé pour le tactile et pas les
portages appauvris de jeux PC ou console existants, peu jouable en tactile sur
un écran de 4''.
**Angry Birds**, de l'éditeur Rovio faisait partie des réussites : simple,
coloré, humoristique et une gestuelle tactive intuitive (tendre un lance-
pierre et viser) qu'un enfant de 6 ans pouvait s'approprier en quelques
minutes. On devait lancer détruire un certain nombre de cibles avec un nombre
d'oiseux limité pour réussir un niveau. Si les munitions étaient épuisées, on
recommençait le niveau entièrement. Les programmeurs se rénuméraient en
faisant défiler des bandeaux de publicité en bas de l'écran et pour quelques
euros on pouvait acheter une version sans publicité. je trouve le système de
monétisation équitable.
Au Noël dernier, on m'a offert un bel object : une tablette Lenovo Yoga 8''.
Moi qui dépannait de temps en les téléphones ou tablettes des autres,
installant un Cyanogen par ci par là, je me suis retrouvé à redécouvrir le
système Android et constater les avancées de la version 5.0. La puissance du
matériel est sans commune mesure avec les équipements de 2010, les chipsets
graphiques ont des capacités 3D et le système s'est amélioré : plus stable,
plus abouti. On a évolué mais il n'y a vraiment pas de quoi se perdre : il y a
toujours une boutique d'applications, on pioche dedans en regardant d'un oeil
suspicieux les permissions demandées par l'application qu'on veut installer et
on refuse le cas échéant : il est exagéré de demander l'accès aux contacts
pour une application de Météo ? ;-)
Bref cette tablette a progressivement supplanté mon téléphone pour accéder à
Internet, lire mes flux RSS, me tenir au courant, voir des vidéos. Puis j'ai
testé quelques jeux et là c'est la désillusion. Beaucoup de jeux exigent un
compte Facebook ou Google+ pour sauvegarder ses parties sous couvert de
sociabilisation. Est-ce que je ne peux pas me faire une partie sans que le
reste de la planète soit au courant et sans comparer mon score avec mes *amis*
(une variation sur le thème de *qui pisse le plus loin*) ? Je n'ai pas de
compte Facebook ni de compte Google+ (et aucun projet d'en ouvrir un ce
siècle-ci) donc ces jeux ont été désinstallés directement.
J'ai lu que **Angry Birds 2** battait des records de téléchargement, la
nostalgie m'a étreint et j'ai vite téléchargé la version pour voir ce que la
licence est devenue. Je n'aurais pas dû me précipiter... Après avoir cliqué 2
fois sur annuler, j'ai pu esquiver la création du compte Google+ et démarrer
le jeu. Un tutorial explique comment tendre le lance-pierre et affiche la
trajectoire optimale des tirs en pointillé sur l'écran (on s'adresse
visiblement aux enfants de 3 ans). Au troisième niveau, les pointillés sont
toujours là. Peut-être que je suis en mode *très assisté* ou peut-être que le
tutorial est très long. Je n'aurais pas la réponse car je bute en essayant des
trajectoires de lancer loufoques et j'épuise mes munitions. J'ai échoué mais
je ne recommence pas le niveau, on me propose de regarder une vidéo pour
regagner un oiseau. Bon 30 secondes de publicité c'est long et ça coupe bien
la partie mais allons-y et supportons ! Pour tester, je gâche volontairement
ma munition. On me propose d'acheter des points parmi un choix de packs de 1
euro pour 80 points à 100 euros pour 11300 points. Ah ok, je vient de
découvrir **les achats In Apps** :-(
Je décline et je recommence au début avec 3 pauvres oiseaux. C'est insuffisant
pour réussir donc le plan B pour obtenir des munitions supplémentaires
c'est... attendre. Bonne idée, ça ne frustre pas du tout le joueur qui avait
juste 15 minutes pour... jouer justement ! Au passage vous aurez remarqué
qu'on ne peut plus jouer *offline*. Donc on ne joue plus quand on veut ; Rovio
décide de vous enlever la manette et vous envoie promener (à moins de sortir
le porte-monnaie). Je sais que les achats In Apps sont devenus la principale
source de revenus des éditeurs. Mais soyons sérieux : dans un jeu de style RPG
en *Free To Play*, qu'on puisse améliorer son personnage en mettant la main à
la poche car on est pressé ou pas très bon (rayez la mention inutile), je
comprends. Mais qu'on saucissonne les temps de jeu d'un Angry Birds, c'est un
mépris total des joueurs qu'on prend pour une pompe à fric. Et qu'on essaie de
se rattraper en abaissant la difficulté du jeu aggrave le sentiment d'être
pris pour une truffe.
Je me suis fait plaisir sur le titre **Rovio va mal et c'est mérité** mais le
problème ne concerne pas que Rovio, loin s'en faut. Le paysage du jeu vidéo
sur mobile a beaucoup changé en 5 ans. Au lieu d'avoir une relation équitable
avec des jeux de qualité, des développeurs correctement rénumérés et des
joueurs fidèles à une licence, des gros éditeurs ont décidé d'inonder le
marché avec des nouveaux titres en permanence mais peu d'innovation, et
beaucoup de monétisation qui gâche le plaisir du joueur. Au final, le joueur a
changé de comportement : il débourse peu et il zappe entre les nouveautés sans
réellement s'amuser. On peut lire [dans cet
article](http://www.frandroid.com/android/applications/jeux-android-
applications/305619_rovio-annonce-telechargements-record-angry-
birds-2-licenciements) que malgré les 50 millions de téléchargement du titre
Angry Birds 2, Rovio se porte mal et va licencier 260 personnes. Ils ont joué
la carte de grossir démesurément mais ils ont oublié que les joueurs sont
leurs clients. Et quand on méprise ses clients on mérite de mettre la clef
sous la porte.

View file

@ -0,0 +1,89 @@
<!-- title: Configuration de XFCE avec deux écrans -->
<!-- category: GNU/Linux -->
<!-- tag: planet -->
J'ai un portable fraîchement installé sous Debian Jessie avec l'environnement
de bureau XFCE<!-- more --> que j'utilise soit en itinérance, soit en poste fixe avec un
moniteur externe en configuration *double écran*. La configuration brute des
écrans sous GNU/Linux passe par l'utilisation de la commande **xrandr** pour
définir leur nombre, la résolution de chacun et leur position respective. Pour
se faciliter la vie, on peut installer **arand** qui fournit une interface
pour définir ces réglages et les sauvegarder sous forme de shell script dans
un fichier.
Voici une capture d'écran de arandr :
![alt text](/images/2015/arandr.png "Arandr")
Et un exemple de script généré pour une configuration en double écran avec le
moniteur externe à droite de l'écran LCD du portable :
xrandr --output HDMI1 --off --output LVDS1 --mode 1366x768 --pos 0x0 --rotate normal
--output DP1 --off --output VGA1 --mode 1920x1080 --pos 1366x0 --rotate normal
En utilisant arand je vais facilement générer les deux scripts dont j'ai besoin :
- une configuration simple avec l'écran du portable
- une configuration en double écran
Pour savoir lequel appliquer, on va tester si le moniteur externe est connecté
en analysant le résultat de la commande xrandr. Au démarrage du portable, le
gestionnaire de connexions **lightdm** clone l'affichage des deux moniteurs
connectés. On peut corriger cela en appliquant notre joli script qui teste si
le moniteur externe est connecté et applique la bonne commande xrandr. Pour
cela, on édite le fichier de configuration **/etc/lightdm/lightdm.conf** et on
ajoute la directive *display-setup-script* dans la section SeatDefaults :
[SeatDefaults]
...
display-setup-script=/usr/local/bin/lightdm-monitor.sh
et voici le script **lightdm-monitor.sh** :
``` shell
if (xrandr | grep "VGA1 disconnected"); then
xrandr --output HDMI1 --off --output LVDS1 --mode 1366x768 --pos 0x0 \
--rotate normal --output DP1 --off --output VGA1 --off
else
xrandr --output HDMI1 --off --output LVDS1 --mode 1366x768 --pos 0x0 \
--rotate normal --output DP1 --off --output VGA1 \
--mode 1920x1080 --pos 1366x0 --rotate normal
fi
```
Le réglage est valable pour lightdm mais quand on ouvre une session XFCE, il
est perdu et on revient à la configuration par défaut à savoir l'affichage
cloné sur les deux écrans. On pourrait appliquer le même script pour la
session, en utilisant la directive *session-setup-script* prévu par ligthdm ou
en mettant le script en démarrage automatique dans la configuration **Session
et démarrage** de XFCE. Dans mon cas, je souhaite ajouter quelque chose au
script de session : déplacer le tableau de bord XFCE sur le moniteur externe,
quand il connecté. C'est possible grâce à la commande **xfconf-query** (le
programme en ligne de commande de configurationde XFCE) adéquate.
Finalement, cela donne le script **xfce-monitor.sh** au démarrage de la session:
``` shell
sleep 3
if (xrandr | grep "VGA1 disconnected"); then
xrandr --output HDMI1 --off --output LVDS1 --mode 1366x768 --pos 0x0 \
--rotate normal --output DP1 --off --output VGA1 --off
xfconf-query -c xfce4-panel -p /panels/panel-1/output-name -s LVDS1
else
xrandr --output HDMI1 --off --output LVDS1 --mode 1366x768 --pos 0x0 \
--rotate normal --output DP1 --off --output VGA1 \
--mode 1920x1080 --pos 1366x0 --rotate normal
xfconf-query -c xfce4-panel -p /panels/panel-1/output-name -s VGA1
fi
```
Le *sleep* en début de script n'est pas élégant. Sans lui, l'exécution du
script intervient avant que la session XFCE soit initialisée et les commandes
xfconf-query ne sont pas appliquées. Si quelqu'un a une solution plus
élégante, je suis intéressé.
Si la connexion / déconnection des écrans a lieu pendant qu'une session est
ouverte, il suffit de relancer le script depuis un terminal pour reconfigurer
l'affichage.
![XFCE](/images/2015/xfce.png)

View file

@ -0,0 +1,218 @@
<!-- title: Jouons avec Awk, Bash et Owncloud -->
<!-- category: GNU/Linux -->
<!-- tag: planet -->
Un souci de synchronisation du calendrier entre Owncloud et mon téléphone a
été le prétexte à bidouiller une fonctionnalité de rappel des événements par
e-mail.<!-- more --> Pourquoi des e-mail ? Parce que je suis un fana de ce moyen de
communication, la preuve [ici](http://blogduyax.madyanne.fr/du-nouveau-sur-
pecosys.html) et [](http://blogduyax.madyanne.fr/srmail.html).
Donc ce que je veux c'est un joli e-mail le lundi matin qui résume mes rendez-
vous de la semaine (description, date et heure) et puis chaque matin au réveil
un e-mail par événement avec le fichier ICS en pièce jointe. [ICS
késako](https://fr.wikipedia.org/wiki/ICalendar) ? Un vieux mais très actuel
standard de description d'un événement reconnu par la plupart des calendriers.
L'intérêt d'avoir le fichier ICS c'est de pouvoir l'ajouter au calendrier
local du téléphone en un clic et de paramétrer le rappel en connaissance de
cause (le matin on a une petite idée de comment va se profiler sa journée).
Plutôt que de coder dans un langage évolué, je me suis amusé à réaliser cela
avec les outils présent en standard sur GNU/Linux (**Awk** et **Bash**) pour
le backend MySQL d'Owncloud. C'est didactique car il est toujours préférable
de privilégier l'accès aux données par une API qui sera plus ou moins bien
maintenue dans le temps par les développeurs que d'attaquer directement la
base de données. D'abord jetons un oeil à structure de la base de donnée
Owncloud.
La table *oc_clndr_calendars* permet de retrouver l'id de calendrier de notre
utilisateur.
mysql> SELECT * FROM oc_clndr_calendars;
+----+------------+-------------+-----------+--------+------+---------------+---------------+----------+-----------------------+
| id | userid | displayname | uri | active | ctag | calendarorder | calendarcolor | timezone | components |
+----+------------+-------------+-----------+--------+------+---------------+---------------+----------+-----------------------+
| 1 | yax | Personnel | personnel | 1 | 196 | 0 | NULL | NULL | VEVENT,VTODO,VJOURNAL |
+----+------------+-------------+-----------+--------+------+---------------+---------------+----------+-----------------------+
Et la table *oc_clndr_objects* contient les évènements :
mysql> DESC oc_clndr_objects;
+--------------+------------------+------+-----+---------------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+--------------+------------------+------+-----+---------------------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| calendarid | int(10) unsigned | NO | | 0 | |
| objecttype | varchar(40) | NO | | | |
| startdate | datetime | YES | | 1970-01-01 00:00:00 | |
| enddate | datetime | YES | | 1970-01-01 00:00:00 | |
| repeating | int(11) | YES | | 0 | |
| summary | varchar(255) | YES | | NULL | |
| calendardata | longtext | YES | | NULL | |
| uri | varchar(255) | YES | | NULL | |
| lastmodified | int(11) | YES | | 0 | |
+--------------+------------------+------+-----+---------------------+----------------+
On peut récupérer les évènements du jour courant avec la requête suivante :
mysql> SELECT startdate,summary,calendardata FROM oc_clndr_objects WHERE calendarid = 1 AND DATE(startdate) = DATE(NOW()) ORDER by startdate \G;
*************************** 1. row ***************************
startdate: 2015-09-14 10:30:00
summary: Déjeuner avec M.
calendardata: BEGIN:VCALENDAR
VERSION:2.0
PRODID:ownCloud Calendar
CALSCALE:GREGORIAN
BEGIN:VEVENT
UID:95d9221d97
DTSTAMP:20150914T103206Z
CREATED:20150913T170426Z
LAST-MODIFIED:20150914T103206Z
SUMMARY:Déjeuner avec M.
DTSTART;TZID=Europe/Paris:20150914T123000
DTEND;TZID=Europe/Paris:20150914T140000
LOCATION:
DESCRIPTION:
CATEGORIES:
CLASS:PUBLIC
END:VEVENT
END:VCALENDAR
*************************** 2. row ***************************
startdate: 2015-09-14 16:15:00
summary: RV dentiste
calendardata: BEGIN:VCALENDAR
VERSION:2.0
PRODID:ownCloud Calendar
CALSCALE:GREGORIAN
BEGIN:VEVENT
UID:1958bfe4a9
DTSTAMP:20150914T103134Z
CREATED:20150914T103134Z
LAST-MODIFIED:20150914T103134Z
SUMMARY:RV dentiste
DTSTART;TZID=Europe/Paris:20150914T181500
DTEND;TZID=Europe/Paris:20150914T183000
LOCATION:
DESCRIPTION:
CATEGORIES:
END:VEVENT
END:VCALENDAR
Les colonnes intéressantes sont :
- *calendarid* pour filtrer les évènements de notre utilisateur Owncloud
- *summary* : le libellé de l'évènement
- *startdate* : la date de début de l'évènement
- *calendardata* : l'évènement au format iCalendar
Ce qu'on veut c'est générer un shell script qui récupère les informations du
jour et envoie un e-mail par évènement avec le fichier ICS en pièce jointe.
L'envoi est réalisé par l'utilitaire **mpack**. Le résultat final espéré pour
notre exemple est ce script :
``` shell
#
STARTDATE="`date -d '2015-09-14 10:30:00-000' '+%a %e %b %R'`"
SUMMARY="Déjeuner avec M."
echo "BEGIN:VCALENDAR" >event.ics
echo "VERSION:2.0" >> event.ics
echo "PRODID:ownCloud Calendar" >> event.ics
echo "CALSCALE:GREGORIAN" >> event.ics
echo "BEGIN:VEVENT" >> event.ics
echo "UID:95d9221d97" >> event.ics
echo "DTSTAMP:20150914T103206Z" >> event.ics
echo "CREATED:20150913T170426Z" >> event.ics
echo "LAST-MODIFIED:20150914T103206Z" >> event.ics
echo "SUMMARY:Déjeuner avec M." >> event.ics
echo "DTSTART;TZID=Europe/Paris:20150914T123000" >> event.ics
echo "DTEND;TZID=Europe/Paris:20150914T140000" >> event.ics
echo "LOCATION:" >> event.ics
echo "DESCRIPTION:" >> event.ics
echo "CATEGORIES:" >> event.ics
echo "CLASS:PUBLIC" >> event.ics
echo "END:VEVENT" >> event.ics
echo "END:VCALENDAR" >>event.ics
mpack -s "$SUMMARY - $STARTDATE" event.ics $1
#
STARTDATE="`date -d '2015-09-14 16:15:00-000' '+%a %e %b %R'`"
SUMMARY="RV dentiste"
echo "BEGIN:VCALENDAR" >event.ics
echo "VERSION:2.0" >> event.ics
echo "PRODID:ownCloud Calendar" >> event.ics
echo "CALSCALE:GREGORIAN" >> event.ics
echo "BEGIN:VEVENT" >> event.ics
echo "UID:1958bfe4a9" >> event.ics
echo "DTSTAMP:20150914T103134Z" >> event.ics
echo "CREATED:20150914T103134Z" >> event.ics
echo "LAST-MODIFIED:20150914T103134Z" >> event.ics
echo "SUMMARY:RV dentiste" >> event.ics
echo "DTSTART;TZID=Europe/Paris:20150914T181500" >> event.ics
echo "DTEND;TZID=Europe/Paris:20150914T183000" >> event.ics
echo "LOCATION:" >> event.ics
echo "DESCRIPTION:" >> event.ics
echo "CATEGORIES:" >> event.ics
echo "END:VEVENT" >> event.ics
echo "END:VCALENDAR" >>event.ics
mpack -s "$SUMMARY - $STARTDATE" event.ics $1
```
Comment fait-on ? On exécute la requête SQL et on la donne à manger à un
script **awk** qui a pour objectif de générer le shell script ci-dessus. Awk a
été inventé pour ce genre de tâche : prendre un fichier en entrée et le
modifier pour créer un fichier en sortie. Le script est assez opaque si on n'a
jamais pratiqué mais l'idée c'est de décrire la structure du document en
entrée (comment distinguer les enregistrements) et de faire correspondre des
traitements à certains enregistrements qu'on identifie par une expression
régulière.
Voci le script awk complet :
``` awk
BEGIN {
FS="\n"
OFS=""
ORS="\n"
print "#!/bin/sh"
print " "
}
# blank lines
/^$/ { next }
# record header
$1 ~ /^\*\*\*\*/ {
next
}
# summary field
$1 ~ /^[ ]*summary\:/ {
idx = match($1, /summary\:(.*)/)
print "SUMMARY=\"" substr($1, idx + 9) "\""
next
}
# startdate field
$1 ~ /^[ ]*startdate\: / {
match($1, /startdate\: /)
print "STARTDATE=\"`date -d '" substr($1, RSTART + RLENGTH) "-000' '+%a %e %b %R'`\""
next
}
# vcalendar start tag
$1 ~ /^[ ]*calendardata\: / {
match($1, /calendardata\: /)
print "echo \"" substr($1, RSTART + RLENGTH) "\" >event.ics"
next
}
# vcalendar end tag
$1 ~ /^END\:VCALENDAR/ {
print "echo \"" $1 "\" >>event.ics"
print "mpack -s \"$SUMMARY - $STARTDATE\" event.ics $1"
print ""
next
}
# vcalendar body
{
print "echo \"" $0 "\" >> event.ics"
}
```
Il ne reste plus qu'à orchestrer tout cela dans un shell script et de
l'appeler par une tâche **cron**. Le script complet gère les rappels du jour
et les rappels pour la semaine à venir. Il est disponible [sur mon compte
GitHub](https://github.com/kianby/owncloud_calremind).

View file

@ -0,0 +1,50 @@
<!-- title: L'obsolescence repoussée -->
<!-- categories: Matériel Humeur -->
<!-- tag: planet -->
J'ai modifié ma façon de consommer depuis déjà quelques années : beaucoup moins
d'achats compulsifs, une réflexion plus longue pour acheter en adéquation avec
le besoin réel, tout en ignorant les sirènes du Marketing et des modes
éphémères. Mon banquier m'en remercie.<!-- more -->
Pour différer le recyclage, on peut privilégier l'occasion (à l'achat ou à la
vente) qui donne une seconde vie à un matériel. Je l'ai pratiqué pour plusieurs
smartphones avec succès ; je veux dire sans déception, du matériel en bon état
acquis à un prix correct. Dans mon cas, un smartphone est en dessous de la
barre des 200 euros et associé à un forfait sans engagement, ce qui permet de
zapper entre les offres les plus intéressantes régulièment. Pour un smartphone,
ce n'est pas toujours l'état du matériel qui va décider son propriétaire à s'en
débarrasser mais son obsolescence logicielle. Un système qui n'est plus
maintenu donne l'impression de rater le train des nouveautés. Dans le monde
Android, les ROMS Cyanogen sont une réponse à l'abandon d'un modèle par un
constructeur. Pour Firefox, les builds communautaires permettent de prolonger
la durée de vie du téléphone. L'équipe Ubuntu promet une mise à jour des
téléphones sans intermédiaire tant que le matériel sera suffisamment puissant
pour supporter les évolutions d'Ubuntu Touch.
<img src="/images/2015/poussiere.jpg" alt="poussiere" style="float:left; margin:
0px 25px 20px 25px;"/> Pour les PC, un coup de pouce peut rajeunir un matériel
vieillissant : une distribution GNU/Linux légère et l'investissement dans un
SSD. J'ai profité des soldes de l'été pour acheter un SSD de 64 Go pour ma
machine principale, un portable Toshiba de 2009 (processeur Core 2 Duo et 4 Go
de RAM) : pour 30 euros j'ai une machine bien plus pêchue qui démarre en 20s
chrono.
Mon second PC, le portable LDLC acquis en 2011 montrait des problèmes de
surchauffe depuis quelques temps. Étant aussi ma machine de *gaming* j'étais
assez attristé jusqu'à ce que je découvre la trappe de fond qui donne accès au
ventilateur et à l'aération bien obstruée par la poussière. Un peu de
nettoyage et le problème de chauffe est résolu. J'ai noté cette trappe comme un
critère très important dans l'hypothétique achat d'un futur portable.
Hypothétique, car vu [la vitesse à laquelle s'étoffe le catalogue de
SteamOS](http://www.numerama.com/magazine/34248-steam-passe-la-barre-des-1500-jeux-video-sous-linux.html),
il est peu probable que je rachète un portable avec autant de puissance. Je
vais sûrement dissocier le *gaming* de mes autres activités. Après tout, un
Core 2 duo est bien suffisant pour coder en Python et faire des expérimentation
système avec Tux.
Au delà, du combat contre l'obsolescence programmée je pense que chacun peut
oeuvrer à son niveau pour limiter le gaspillage en prolongeant la durée
d'utilisation de son matos par un peu de maintenance, en misant sur le bon
cheval de l'OS et en réfrénant un peu ses pulsions de consommation ;-)

View file

@ -0,0 +1,13 @@
<!-- title: Massacre à Paris -->
<!-- category: Humeur -->
<!-- tag: planet -->
Je pensais que la tuerie de Charlie Hebdo serait le pire évènement de l'année
2015 mais le massacre du vendredi 13 novembre a dépassé l'inimaginable.<!-- more -->
Après une nuit blanche à suivre les évènements, <!--more--> à trembler pour le
public du Bataclan avant l'assaut, il ne reste que les pleurs devant le nombre
de victimes et la douleur des familles dont certaines cherchent encore leurs proches.
![France qui pleure](/images/2015/benjamin_regnier.jpg "France qui pleure")
*Merci à Benjamin Regnier pour ce dessin*

View file

@ -0,0 +1,189 @@
<!-- title: Retour d'expérience Ubuntu Touch -->
<!-- category: Mobilité -->
<!-- tag: planet -->
L'article peut sembler opportuniste par rapport aux rumeurs d'abandon de
Firefox OS mais il n'en est rien<!-- more --> (je le jure votre honneur). C'est seulement
que j'ai eu la chance de toucher un Nexus 4 (merci Papa) et j'en ai profité
pour tester le système Ubuntu Touch pendant une semaine dans mon utilisation
quotidienne. En effet, ce téléphone est un des téléphones de référence pour la
société Canonical, toujours maintenu alors que leur OS, très discret, fêtera
bientôt sa 3ème bougie. Depuis le lancement de Ubuntu Touch, trois téléphones
ont été commercialisés : deux modèles du constructeur espagnol BQ qui semblent
très appréciés par la communauté Ubuntu et un modèle assez puissant, le MX4 du
constructeur chinois Meizu.
<img src="/images/2015/ubuntu-about.png" alt="A propos" style="margin: 0px 20px;
float:left;" />Ca commence donc par l'installation du système qui est assez
simple car d'une part le Nexus 4 a un booloader facile à déverrouiller et
Ubuntu Touch est basé sur un Android, on utilise donc des outils Android (adb,
fastreboot) pour flasher le système. Ensuite les outils Canonical
interviennent, la voie simple consiste donc à s'installer une version Desktop
de Ubuntu 14.04 ou supérieure sur un PC afin d'obtenir ces outils facilement.
Je me suis donc basé sur [la documentation officielle du Ubuntu
Developer](https://developer.ubuntu.com/en/start/ubuntu-for-devices/installing-ubuntu-for-devices)
et [sur cet
article](http://www.pcadvisor.co.uk/how-to/linux/how-install-ubuntu-touch-image-3531970)
qui apporte quelques précisions pour le Nexus 4. On a le choix entre deux
canaux de mise à jour système : stable ou développement. Pour me faire une
idée la plus juste du système et ne pas la fausser avec des bugs d'une version
en cours de développement, j'ai choisi la version stable. Ce qui est
intéressant avec Ubuntu Touch, c'est que la version mobile fait partie
intégrante du développement de Ubuntu, il ne s'agit d'un développement à part,
déconnecté de la version *Desktop*. Après une installation fraîche, on a donc
un téléphone en version 15.04 et on reçoit des OTA (mise à jour) régulièrement.
On devrait d'ailleurs bientôt basculer en version 15.10. Canonical a une vision
précise de ce qu'il veulent obtenir avec leur système et cela s'appelle
Convergence. Un système mobile qui, une fois connecté à un clavier / souris en
bluetooth et à un moniteur se transforme en *Ubuntu Desktop* capable d'exécuter
les applications usuelles comme Libre Office ou Gimp.
Pour moi, Convergence est un rêve de Geek et on a du mal à imaginer le quidam
moyen utiliser son téléphone comme ordinateur. Et pourtant c'est un des
principaux avantages de Touch : on n'a pas un système Unix-like castré mais un
système GNU/linux complet. Je me suis plusieurs fois surpris à buter sur la
manière de faire certaines choses parce que l'interface graphique n'est pas
encore complète sur certains point et qu'il faut raisonner ligne de commande
avec les outils usuels : du shell script (SH ou BASH) et des tâches CRON. Mais
je m'emballe, faisons d'abord un petit tour en images du système.
**L'écran de déverrouillage et ses statistiques amusantes :**
<img src="/images/2015/ubuntu-unlock1.png" alt="ubuntu unlock"/>
<img src="/images/2015/ubuntu-unlock2.png" alt="ubuntu unlock"/>
**L'écran principal avec ses applications en rang d'oignons:**
<img src="/images/2015/ubuntu-appli1.png" alt="ubuntu application"/>
<img src="/images/2015/ubuntu-appli2.png" alt="ubuntu application"/>
**Les applications favorites sur la gauche en faisant glisser le bord gauche de l'écran**
**et les applications lancées en faisant glisser le bord droit de l'écran :**
<img src="/images/2015/ubuntu-unity.png" alt="ubuntu unity"/>
<img src="/images/2015/ubuntu-tasks.png" alt="ubuntu tasks"/>
**Les paramètres système et un aperçu du magasin d'applications :**
<img src="/images/2015/ubuntu-settings.png" alt="ubuntu settings"/>
<img src="/images/2015/ubuntu-store.png" alt="ubuntu store"/>
A part la particularité du tirage des bords d'écran pour faire apparaître la
barre latérale ou passer d'une application à l'autre mais on pige vite le coup,
on est dans une interface classique, on n'est pas perdu. Les paramètres sont
similaires à ce qu'on peut trouver sur d'autres systèmes, le magasin Ubuntu
Store est plus conséquent que ce à quoi je m'attendais. De ce que j'ai lu sur
les forums de discussion Ubuntu, l'équipe Canonical a mis le focus sur le
système dans un 1er temps, les applications viendront ensuite. Voici une liste
de ce qui marche et de ce qui dysfonctionne sur le Nexus 4 en 15.04 OTA 8:
- la téléphonie fonctionne (oui c'est bien de l'écrire pour rassurer tout le
monde)
- l'envoi de SMS et de MMS fonctionne mais j'ai un doute sur la réception MMS
(je crois en avoir raté un)
- le bluetooth est présent mais je n'ai pas réussi à le faire fonctionner avec
mon main-libre Jabra malgré un appairage réussi.
- le GPS est capricieux
- le tethering USB fonctionne. la fonction Hotspot Wi-Fi est censée être
présente mais je ne l'ai pas vu dans mes paramètres.
- l'application e-mail officielle *Dekko* est fonctionnelle depuis peu. Elle est
agréable à utiliser.
- les applications *contact* et *calendrier* sont présentes et bien faîtes.
- les performances du systèmes sont acceptables mais perfectibles (on a une
patience d'1 à 2 secondes à chaque lancement d'application)
Deux sujets ont exigé de mettre le nez dans la ligne de commande car ils ne
sont pas (encore) configurables par l'interface graphique : les sonneries
personnalisées et la synchronisation des contacts et du calendrier.
D'abord il nous faut un accès SSH sur la bête. On active le mode *développeur*
depuis les paramètres du téléphone et on se connecte avec *adb shell* pour
activer le service SSH Ensuite on copie la clef publique de notre PC sous
GNU/Linux dans le téléphone. Ca donne en gros les étape suivantes lues sur
[AskUbuntu](http://askubuntu.com/questions/348714/how-can-i-access-my-ubuntu-phone-over-ssh)
adb shell android-gadget-service enable ssh
adb shell mkdir /home/phablet/.ssh
adb push ~/.ssh/id_rsa.pub /home/phablet/.ssh/authorized_keys
adb shell chown -R phablet.phablet /home/phablet/.ssh
adb shell chmod 700 /home/phablet/.ssh
adb shell chmod 600 /home/phablet/.ssh/authorized_keys
Partant de là, on peut se passer de *adb* et se connecter directement en SSH sur
le téléphone avec l'utilisateur phablet. Comme par défaut sur Ubuntu, le compte
root est désactivé et l'utilisateur phablet doit utiliser *sudo* pour obtenir
les super-pouvoirs. Ces pouvoirs ne permettent pas de modifier un fichier du
système qui est en dehors du répertoire */home/phablet* car par sécurité les
partitions sont montées en lecture seule. Donc on sera souvent amené à remonter
la partition en lecture-écriture avec la commande suivante :
sudo mount /dev/loop0 / -o remount,rw
On va configurer la synchronisation de nos contacts et du calendrier vers
Owncloud par les protocoles de sychronisation **cardav** et **caldav** en
s'inspirant de [cette
discussion](http://askubuntu.com/questions/360466/ubuntu-touch-officially-launched-version-how-to-sync-contacts)
sur AskUbuntu. D'abord on configure syncevolution :
``` shell
# les valeurs username, password et syncurl doivent être adaptées
syncevolution --keyring=no --configure --template webdav username=yax password=??? syncurl="mycloud.madyanne.fr" target-config@owncloud
syncevolution --configure --template SyncEvolution_Client sync=none syncURL=local://@owncloud username= password= peerIsClient=1 owncloud
# on configure la synchro des contacts
syncevolution --configure database=https://mycloud.madyanne.fr/remote.php/carddav/addressbooks/yax/contacts backend=carddav target-config@owncloud contacts
syncevolution --configure sync=two-way backend=contacts database="Personnel" owncloud contacts
# on configure la synchro du calendrier
syncevolution --configure database=https://mycloud.madyanne.fr/remote.php/caldav/calendars/yax/personnel backend=caldav target-config@owncloud calendar
syncevolution --configure sync=two-way backend=events database="Personnel" owncloud calendar
# on lance une 1ère synchro qui donne priorité au serveur Owncloud
syncevolution --sync slow owncloud contacts
syncevolution --sync slow owncloud calendar
```
Ce qui manque juste, c'est une
synchronisation périodique avec Owncloud par exemple une fois par heure.
D'abord j'ai naïvement ajouté deux lignes dans la CRONTAB :
syncevolution owncloud contacts
syncevolution owncloud calendar
Et bien ça ne marche pas car syncevolution utilise DBUS et qu'en lançant hors
shell utilisateur, les variables d'environnement *DISPLAY* et
*DBUS_SESSION_BUS_ADDRESS* ne sont pas initialisées. Il faut donc récupérer ces
valeurs dans le shell script qu'on va lancer en CRON, merci
[Alexandre](http://askubuntu.com/questions/611761/syncevolution-in-cronjob-to-sync-the-ubuntu-phone-via-caldav-arddav).
Donc finalement c'est ce script qu'on va mettre sous CRON :
``` shell
export DISPLAY=:0.0
export DBUS_SESSION_BUS_ADDRESS=$(ps -u phablet e | grep -Eo 'dbus-daemon.*address=unix:abstract=/tmp/dbus-[A-Za-z0-9]{10}' | tail -c35)
syncevolution owncloud contacts
syncevolution owncloud calendar
```
Amusant non ? J'ai joué pas mal avec la synchronisation des calendriers et des
contacts et je peux dire que *syncevolution* tient bien la route. Le dernier
détail indispensable pour moi, c'était de récupérer ma sonnerie habituelle ; il
n'y a pas encore la possibilité de télécharger une sonnerie personnalisée.
Après le chantier de la synchronisation, c'est un jeu d'enfant : il suffit de
la convertir au format OGG et de la placer dans le répertoire
*/usr/share/sounds/ubuntu/ringtones/*.
Après une semaine d'utilisation quotidienne, j'ai trouvé le système crédible et
agréable à utiliser. Qu'ils rajoutent un clavier physique et ce sera le
meilleur du monde (troll inside !). Ubuntu Touch s'améliore régulièrement. Les
développeurs se sont imposés un rythme de 6 semaines pour livrer une OTA.
L'inconnue pour moi c'est comment Canonical espère monétiser son système et
combien de temps ils réussiront à le pousser sans que ce soit rentable. En tout
cas techniquement, c'est un petit bijou qui fait du pied aux Unixiens, un bol
d'air frais quand les systèmes alternatifs au couple Android / IOS jettent
l'éponge ou déposent le bilan l'un après l'autre.

View file

@ -0,0 +1,101 @@
<!-- title: Quelques astuces pour VirtualBox -->
<!-- category: Virtualisation -->
<!-- tag: planet -->
VirtualBox est un produit de virtualisation porté par Oracle qui a l'avantage
d'être multi-plateforme (Ms Windows, OS/X, GNU/Linux)<!-- more --> et qui est orienté
*Desktop*, destiné à s'installer sur une machine de bureau (par opposition à un
hyperviseur dédié à la virtualisation). Le client cible de VirtualBox c'est
l'utilisateur lambda qui a besoin de tester occasionnellement une distribution,
l'utilisateur professionnel de GNU/linux (félicitations tu fais partie des 1%)
qui a besoin régulièrement d'une machine virtuelle Ms Windows pour certaines
applications (comme Ms Office), le développeur ou le testeur de logiciel qui
utilise intensivement la virtualisation pour déployer des environnements de
test. J'appartiens aux trois catégories. Je ne vais pas détailler la création
d'une machine virtuelle mais quelques astuces utiles, fruit de mon expérience
... bon ok de mes galères :-)
Dans le cadre professionnel, j'ai une machine virtuelle Ms Windows qui me sert
à éditer et créer des documents Office. Pour éviter de dupliquer les documents,
j'avais créé un partage Samba entre ma machine hôte et la machine virtuelle.
J'étais fier de moi, cela fonctionnait bien... jusqu'à que j'essaie d'accéder à
mes documents dans le TGV. La machine virtuelle était configurée en mode pont
(*bridge*) sur l'interface Ethernet et Ms Windows configuré en IP fixe sur le
réseau d'entreprise. L'interface Ethernet de la machine hôte étant KO, le
partage Samba n'était pas accessible par la VM.
Une solution consiste à utiliser la fonctionnalité "Dossiers partagés" de
VirtualBox. Au niveau de la configuration de la VM, les dossiers partagés
permettent de créer un partage Ms Windows qui pointe sur un répertoire du hôte
et qui sera accessible quelle que soit la configuration réseau de l'hôte ou de
la VM : réseau configuré en mode pont ou en NAT, que le réseau soit accessible
ou non.
**Configuration des dossiers partagés dans VirtualBox :**
![Shared Folders](/images/2015/virtualbox-shared-folder.png "Shared Folders")
**Navigation du partage depuis la VM Ms Windows :**
![Windows Share](/images/2015/virtualbox-windows-explorer.png "Windows Share")
Quand je déploie des VMs sur mon poste de développement pour des tests, je
configure le réseau de la machine virtuelle en mode NAT pour ne pas consommer
d'adresse IP du réseau d'entreprise et je configure le système d'exploitation
virtualisé (généralement un Linux) en DHCP. Dans cette configuration, c'est
VirtualBox qui attribue une adresse IP dynamique à la VM sur un réseau NAT
partagé entre le hôte et ses VMs. Du coup, la VM a accès au hôte, à son réseau
local du hôte (et même à Internet) mais elle est *invisible* pour les autres
machines du réseau local. L'avantage de cette configuration c'est qu'elle
fonctionne si la machine hôte n'a pas de réseau : la machine hôte et la VM
peuvent toujours communiquer. Pour que le hôte puisse se connecter à un service
de la VM, il faut configurer la redirection de port avec VirtualBox, c'est à
dire lier un port local de la machine hôte à un port de la VM. Par exemple, on
peut définir qu'on veut accéder à la VM en SSH en liant le port 2222 au port 22.
![Port forwarding](/images/2015/virtualbox-port-forwarding.png "Port forwarding")
Ainsi un *ssh -p 2222 user@localhost* se connecte à la VM et on peut copier des
fichiers par le même biais avec *scp*. La redirection du port Web (80) de la VM
vers le port 8080 de la machine hôte permet d'accéder à une éventuelle
application Web de la VM. Cela posera peut-être des soucis car cette application
ignore le NAT et elle risque de construire des liens vers des ressouces sur le
port 80 alors qu'on l'attaque sur le port 8080. Un moyen de contourner ce
problème si l'application n'est pas configurable, consiste à installer un NginX
sur la machine hôte pour faire office de proxy.
``` nginx
# Proxy
upstream vbox-vm {
server 127.0.0.1:8080;
}
##
# Virtual Host Config
##
server {
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
proxy_pass http://vbox-vm;
}
}
```
Ainsi, on peut attaquer le port HTTP de la machine locale et avoir ses requêtes
redirigées vers le port HTTP de la VM. On n'a plus de changement de port donc
les liens sont valides.
Ces deux astuces me permettent de travailler avec mes VMs sur mon laptop de
développement en mode déconnecté. Si vous en avez d'autres je suis preneur :-)