Un gps libre avec Navit

26 mars 2012

Depuis un peu plus d'un an maintenant, j'ai choisi d'utiliser Navit comme logiciel de navigation. Dans ce billet, je propose de faire un petit retour d'expérience sur ce logiciel et la manière de l'utiliser pour calculer les trajets à l'aide d'un GPS.

Présentation

Navit est un logiciel de navigation, ce que l'on appelle souvent un « GPS ». Le logiciel fonctionne en mode déconnecté, c'est à dire qu'il à besoin de lire les cartes en local, mais ne nécessite aucune connexion réseau lors de la navigation. C'est un avantage qui lui permet de fonctionner sur des netbook sans clef 3G.

Et c'est là tout l'avantage par rapport à une solution de navigation intégrée : il permet de transformer n'importe quel netbook (voire smartphone) en une solution de navigation GPS gratuitement ! Par rapport aux GPS que l'on rencontre souvent en voiture, le coût est ridicule !

Fonctionnement

À partir d'une connexion GPS intégrée (comme sur les smartphone) ou externe (par USB), Navit va mettre à jour en temps réel l'affichage de la carte et le calcul du trajet. La connexion gps est réalisée avec gpsd, capable de réceptionner les données depuis la plupart des récepteurs gps. Je n'ai eu aucun problème pour réaliser la connexion entre navit et gpsd, la carte commençant à se déplacer toute seule une fois les leds du GPS indiquant qu'il s'était synchronisé.

Navit n'intègre aucune carte : par contre l'application a la possibilité d'utiliser les cartes dans les formats suivants :

Une caractéristique de navit est de ne pas présenter d'interface par défaut : tout passe par des modules que l'on vient rajouter dans l'interface et qui s'afficheront par dessus la carte. Par exemple :

  • Le nom de la rue sur laquelle on se trouve
  • L'heure d'arrivée
  • La vitesse
  • La distance avant le prochain changement de route
  • Une alerte quand on dépasse la vitesse autorisée
  • etc.

Des configurations déjà prêtes sont disponibles sur le wiki et peuvent être téléchargées. Cela permet d'adapter l'affichage en fonction du support sur lequel l'application est lancée : sur un smartphone on privilégiera un affichage en vertical avec moins de modules par rapport à un ordinateur.

Configuration

Navit se base sur gpsd pour récupérer les données en provenance du récepteur. Je ne rentre pas ici dans l'installation et la configuration de gpsd, et vous renvoie vers la documentation de votre distribution pour le configurer.

Note

Il n'est pas nécessaire de disposer d'un récepteur GPS pour utiliser Navit. C'est alors à l'utilisateur de déplacer la carte pour suivre son trajet, mais en dehors de ce point, l'application se comportera de la même manière.

Nous allons ensuite télécharger notre première carte, en passant par le Navit planet extractor, qui propose de télécharger son jeu de carte sur internet :

Note

Notez l'url, nous allons la réutiliser plus tard !

La configuration de navit est disponible dans le répertoire /etc/navit/ . Seulement, pour plus de commodité, nous allons la copier dans notre répertoire utilisateur :

1
cp -r /etc/navit/ ~/.navit/

Nous allons maintenant éditer le fichier XML est ajouter la carte dans la liste des cartes disponibles :

1
2
3
    <mapset enabled="yes">
<map type="binfile" enabled="yes" data="${VOTRE/CHEMIN/VERS/carte.bin}"/>
    </mapset>

Si l'on souhaite intégrer plusieurs cartes, il faut insérer plusieurs fois ce nœud XML.

Relançons maintenant navit, la carte devrait s'afficher ! (Il se peut que vous ne voyiez rien car Navit n'est pas forcément positionné chez vous : on va donc chercher dans les villes une proche de chez nous et choisir de l'afficher sur la carte.)

http://blog.chimrod.com/wp-content/uploads/2012/03/Capture-Navit-e1332787251467.png

On peut déjà commencer à calculer les trajets et essayer différents habillages. Sur le wiki vous pouvez télécharger des thèmes déjà préparés qu'il suffit d'installer.

Limitations

Même si le logiciel est utilisable au quotidien, il n'est pas parfait. (Il s'est cependant grandement amélioré dans ses dernières versions, je recommande d'utiliser la version 0.5 qui corrige de nombreux soucis dans l'interface et la consommation mémoire.)

  • Une fâcheuse tendance de navit et de ne pas prendre en compte les limites géographiques des villes. En conséquence, la sélection de la destination à partir de la ville et des noms de rues n'est pas fiable : certaines rues n'apparaissent pas alors qu'elles sont enregistrées sur la carte, ou (plus grave), peut se tromper de ville. Il m'est déjà arrivé de me rendre à destination, dans la bonne rue, mais pas dans la bonne ville !

    J'ai maintenant pris l'habitude de n'entrer les destinations qu'à partir de la carte, et non pas à partir de l'index des rues.

  • Par rapport aux solutions commerciales, capables d'afficher l'état du trafic, Navit est vraiment en retard. On peut résumer en disant qu'il s'agit davantage d'une carte interactive qu'une solution de guidage, il reste nécessaire de prévoir son trajet avant de partir.

  • Un autre regret est de ne pas pouvoir sélectionner des « points de passage », pour affiner le trajet. La seule solution est de choisir préparer à l'avance dan les favoris les destinations et les faire évoluer au fur du trajet.

  • Enfin, contrairement aux gps embarqués, on est dépendant de la qualité du support : si l'on dispose d'un portable avec écran brillant, on sera forcément gêné lors du suivi de la navigation.

http://blog.chimrod.com/wp-content/uploads/2012/03/Capture-Navit-1-e1332786990864.png

OpenstreetMap

Impossible de parler de navit sans aborder openstreetmap ! Pour faire une analogie, openstreetmap est à la cartographie ce que wikipédia est à l'encyclopédie : une plateforme donnant à chacun le moyen la possibilité de contribuer.

La navigation GPS est pour moi l'utilisation la plus pratique de ce service : d'une part parce que les cartes sont libres, et d'autre part parce que cela donne envie de contribuer à son tour : en rajoutant les feux aux carrefours, les parkings, en fonction des différents trajets que l'on réalise; on voit à l'utilisation les défaut sur les cartes, et une fois de retour chez soi, on corrige la carte en fonction.

OpenstreetMap change très vite, et les cartes sont mises à jour en continu. C'est pourquoi je vous propose d'automatiser le téléchargement de vos cartes. Rien de mieux pour ça qu'une tâche dans un cron !

Vous vous souvenez de l'url que je vous avais demander de noter dans un coin tout à l'heure ? C'est maintenant qu'elle va être réutilisée.

1
$ crontab -e

Dans l'éditeur de texte qui s'ouvre, on va entrer notre tâche planifiée :

1
25  3   *   *   1   wget -O ~/sync/.navit/carte.bin ${url} > /dev/null 2>&#038;1

Ainsi, la carte se mettra à jour automatiquement !

J'ai dit tout à l'heure qu'openstreetmap permettait à tout un chacun de modifier les cartes, cela signifie que, comme wikipédia, la qualité des cartes est inégale selon les endroits que vous visitez : il n'y a probablement pas de problème dans une grande ville, mais cela risque d'être plus compliqué pour retrouver le nom d'une rue dans un hameau ou un petit village. Dans ce cas, n'hésitez pas à mettre à jour la carte ! (Ça n'est pas l'objet de l'article ici, mais il existe de nombreux tutoriels pour vous expliquer comment faire.)

Conclusion

J'ai parlé du coût de la solution au début de l'article : il s'agit du coût du récepteur GPS. On peut en trouver par 30€ sur ebay, ce qui est investissement suffisant pour se lancer (si l'on compare aux gps tactiles qui sont vendus en supermarché).

Pour ma part, j'utilise un récepteur ND100 de globalsat.

Au final on dispose donc d'une aide à la navigation qui s'avère très pratique, et assez amusante ! On a l'avantage de disposer de cartes gratuites et mises à jour en permanence (même si la qualité laisse parfois à désirer), mais aussi de ne pas dépendre d'un système fermé (il est possible de modifier les cartes à l'aide de l'éditeur d'OpenstreetMap quand on rencontre des erreurs).

Scripter elinks

18 février 2012

elinks est un navigateur web, destiné à être utilisé en console. Il s'agit pour moi d'un très bon navigateur secondaire, en complément de firefox, qui à l'avantage de permettre une navigation légère, sans effets de javascript, publicités, idéale pour lire l'actualité, un peu moins pour faire une recherche sur un sujet.

La semaine dernière, j'ai envoyé un message sur la mailing list du projet pour indiquer que je souhaitai entreprendre quelques modifications dans le code dans le but de le rendre davantage modulaire. Il est nativement scriptable dans différents langages (lua, python, perl...) mais les possbilités de scripts restent très limitées et ne permettent pas de changer grand chose au comportement du navigateur. Quand on a prit l'habitude de pouvoir configurer ses applications comme on le souhaite, cela devient difficile de ne pas pouvoir le faire.

J'ai donc choisi de me pencher davantage sur le langage lua pour mettre en place les modifications voulues. J'ai déjà une expérience du lua comme scripts côté client, pour l'instant jamais du côté de l'API C. Après avoir lutté une petit peu, j'ai fini par comprendre et suis aujourd'hui en train de mettre les objets qui m'intéressent.

Le but est de permettre de scripter complètement la navigation : aujourd'hui, les seules interractions possibles permettent de modifier l'URL au moment où celle-ci est entrée, mais aucun accès au document n'est donné : impossible de récupérer les URLs, impossible de sélectionner un lien dans la page, ou de naviguer dans celle-ci. C'est tout cela que je souhaite mettre en place, en proposant une API orientée objet qui sera modulable et réutilisable par la suite.

Pour l'instant, les modifications ne sont pas encore visibles, je fait le commit sur mon propre serveur git, mais je rendrai public mon projet dès que j'aurai obtenu un résultat intéressant : je n'attendrai pas d'avoir fini pour tout publier; soyez patient !

Hadopi veut sauver l’inculture

9 juin 2011

Culture populaire contre culture financière

On oppose souvent la culture populaire à la culture légitime. La culture populaire représente la culture de rue, alors que la culture légitime est une culture institutionnalisée, celle que l'on retrouve dans les musées et les écoles.

La culture populaire, elle, fait peur. Ce n'est pas un fait nouveau elle a toujours fait peur : c'est celle que l'on ne contrôle pas, celle qui pointe du doigt les travers de la société, dans les bars hier, dans les cages d'escalier aujourd'hui, et sur internet demain.

Hadopi ne cherche pas à opposer ces deux visions. La question n'est pas d'interdire les rassemblements sur internet comme on interdit les raves sauvages dans les champs en friche. La question est de contrôler la commercialisation de la culture; d'empêcher non pas qu'elle sorte du cadre institutionnalisé, mais du cadre financier. Il ne s'agit pas de protéger les auteurs en tant que créateurs d'art, il s'agit de protéger les auteurs en tant que producteurs de richesses.

Les débats qui parlent actuellement de la culture ne sont plus des débats sur le contenu de ce qui fait la culture, mais des débats qui parlent de la culture en terme de revenus. Hadopi n'a pas pour vocation de protéger le hip-hop, la peinture, le slam, le théâtre.

On parle de piratage des œuvres culturelles, mais arrêtons nous un instant :

En quoi le fait de diffuser une œuvre (musicale, cinématographique…) nuit-elle à la culture ? Peut on contrefaire (puisqu'il s'agit bien du délit reproché aux pirates) de la culture ? Ça n'est pas la culture que l'on cherche à protéger, mais sa valeur marchande !

Le regain d'intérêt contre hadopi, à l'heure où celui-ci devient un outil de marchandising (qui dépense 3 millions d'euros en campagne publicitaire) nous montre bien que l'on ne veut pas de ce modèle que l'on nous propose, et la solution est déjà dans le message : pour ne pas voir la culture devenir uniquement un bien commercial, il suffit de refuser hadopi !!

Le réveil d'une autre forme de culture

Mais cette opposition nous fait oublier que la culture n'est pas uniquement artistique : bien que déconstruction pour faire de la culture de l'inculture soit en chantier depuis longtemps maintenant, il ne faut pas oublier que la culture est avant tout politique !

Les parodies des spots publicitaires sont autant des messages politiques qu'artistique, tout comme l'étaient ceux du logo hadopi. Mais la contestation qui est soulevée est avant tout une question de vivre ensemble : internet a ce pouvoir de laisser les individus s'exprimer hors du cadre qui est imposé, légitimement ou non. Et le comportement des internautes vis-à-vis du téléchargement oblige à se questionner : ce mouvement populaire peut-il être contrôlé par la répression ?

Parmi les solution proposée pour faire vivre les artistes, on retrouve la licence globale. Là encore arrêtons nous un instant :

  • il s'agit d'une solution collective (l'ensemble de la population participe aux frais, comme pour l'entretien des musées nationaux)
  • il ne s'agit pas d'une solution marchande (la licence globale entraine une prolifération des œuvres, et non pas une centralisation comme c'est le cas aujourd'hui)

Hors, ce sont justement ces deux points qui sont contestés par les partisans d'hadopi : la culture ne doit pas être partagée, elle doit rester entre les mains de ceux qui en vivent, pas de ceux qui la vivent !

Sauvons l'inculture, votons hadopi

Hadopi, en voulant protéger la Culture (celle avec un grand Cul), a réveillé les rancœurs et la colère des internautes. Pourquoi ? Tout simplement parce que cette culture que l'on nous présente à travers ce que l'on cherche à protéger n'a plus grand chose à voir avec la culture 'vécue', celle que l'on prend plaisir à découvrir et partager.

Si j'écris aujourd'hui, c'est parce que je ne prend conscience que maintenant que le terme de culture a été dévoyée. Il n'y a pas de culture dans les MP3 ou les AVI qui s'échangent sur le P2P. Il n'y a que du loisir. L'industrie culturelle que l'on nous présente dans les médias n'existe pas (plus); elle a été supplantée par l'industrie du divertissement, qui s'exporte très bien, mais qui n'a plus rien à voir avec une volonté de diffusion de la culture. Au contraire ! Et je ne souhaite pas que cet élan culturel soit également dévoyé ici, sur internet.

Et pour protéger cette culture, il faut de l'échange, il faut des opinions, des idées. Que l'on soit d'accord ou non, le débat doit être ouvert : il faut ramener du politique dans la culture.

Merci de m'avoir lu.

Mettre en place un environnement sftp chrooté (2)

7 juin 2011

Il y a quelques temps, j'avais publié un billet indiquant comment mettre en place un environnement sftp chrooté, dans lequel l'utilisateur ne peut pas sortir du répertoire qui lui est assigné.

La solution que j'avais proposé ( modifier la configuration de sshd ) était compliquée et lourde a mettre en place. Parmi les commentaires, le logiciel mysecureshell avait été évoqué.

Présentation

Mysecureshell est une commande qui se lance au login de l'utilisateur sur la machine. Il dispose de nombreuses possibilité de paramétrage (débit, droits), tout en restant très simple à administrer. De plus, il empêche l'utilisateur d'ouvrir une connexion sur la machine, il ne peut que se connecter en sftp.

Nous allons voir ici comment le mettre en place sur une machine Debian destinée à accueillir des connexions sftp.

La documentation en ligne est complète et accessible voici néanmoins une description qui reprend les principes de l'installation.

Installation

Mysecureshell n'est malheureusement pas disponible dans les dépôts debian. Il est donc nécessaire d'ajouter un dépôt externe pour l'installer. Le site web fournit des paquets d'installation pour la plupart des distributions (debian, fedora…)

Une fois que le dépôt est ajouté, il suffit de l'installer en lançant la commande suivante (toujours sous debian) :

1
# aptitude install mysecureshell

Configuration

Configuration de mysecureshell

La configuration se fait dans le fichier /etc/ssh/sftp-config

Voici les champs importants à noter :

Champs Signification
GlobalDownload Il s'agit du débit maximal qui sera utilisé quand le serveur uploadera des fichiers vers les clients
GlobalUpload La même chose pour l'upload
StayAtHome Empêcher l'utilisateur de naviguer hors de son répertoire personnel
VirtualChroot Met en place un faux home pour l'utilisateur
Home Défini le home que verra l'utilisateur lorsqu'il se connectera

Je conseille de séparer le home « unix » de l'utilisateur de son home « chrooté ». Cela permet de mettre en place des fichiers dans le fichier home de l'utilisateur, sans que celui-ci ne puisse les consulter :

Cela se fait tout simplement en mettant l'option VirtualChroot à True, et en définissant le Home mysecureshell vers un sous-répertoire du home unix :

1
2
3
StayAtHome              true
VirtualChroot           true
Home                    /home/$USER/sftp

Cela oblige à créer pour chaque utilisateur un répertoire sftp dans son home. Lorsque l'utilisateur se connectera, il accedera uniquement à répertoire sftp, mais ne pourra pas naviguer plus haut, ni consulter les autres répertoire des autres utilisateurs.

Gestion des comptes

La configuration est assez simple : pour chaque utilisateur nous allons indiquer que mysecureshell est la commande à exécuter lors du login de l'utilisateur. Cela se fait en modifiant le fichier /etc/passwd.

1
invite:x:1002:1002:,,,:/home/invite:/bin/bash

et le remplacer le dernier champs ainsi :

1
invite:x:1002:1002:,,,:/home/invite:/bin/Mysecureshell

Sauvegarder, et voilà, la configuration va s'appliquer lors de la prochaine connexion de l'utilisateur.

Mise à jour de la configuration

Lorsque les fichiers de configuration sont mis à jour, les connexions existantes ne sont affectées. Elles ne le deviennent qu'à partir de la prochaine reconnexion de l'utilisateur.

Il est tout à fait possibile de forcer mysecureshell à appliquer les modifications, mais cela oblige à reconnecter les utilisateurs

Au final

Il n'y a pas grand chose à faire finalement, et c'est agréable de voir la configuration se faire aussi rapidement ! Il est vrai que le site web de l'application peut sembler amateur, mais cela ne reflète en rien la qualité de l'application.

J'abandonne donc avec plaisir la méthode que j'avais mis en place dans mon précédent billet pour passer sur mysecureshell !

Photo infrarouge

29 avril 2011

Je me suis récemment essayé à la photo infrarouge; en mettant un filtre qui ne laisse passer que les rayons infrarouges devant l'objectif, il est possible de saisir des images que l'on ne verrait pas à l'œil nu.

Ce n'est plus les couleurs qui sont saisies, mais la température : généralement l'eau et le ciel seront sombre, alors que les feuilles et l'herbe seront très clairs.

Alors que les beaux jours reviennent, voici la photo d'un jardin d'enfants à midi :

http://blog.chimrod.com/wp-content/uploads/2011/04/2011avril23_120334.jpg

Décès de Paul Baran

29 mars 2011

Je n'ai pas vu l'information passer, j'ouvre donc un billet pour annoncer ici la mort de Paul Baran à 84 ans, le 27 mars, l'un des créateurs d'arpanet.

Arpanet était parti d'un besoin, celui de consituer un réseau décentralisé, capable de résister à la perte d'une partie de son architecture, les contraintes que cela à engendré ont eu pour conséquence de segmenter les données à envoyer en différents « blocs » , assez petits. Ces blocs seront par la suite renommé « paquets » et sont encore utilisé aujourd'hui…

Sa mort me pousse à m'interroger sur ce qu'est devenu internet aujourd'hui : où en sommes nous dans cette volonté de décentralisation ?

Le but initial, qui était d'empêcher à quiconque de contrôler le réseau n'a plus le vent en poupe. Au contraire, devant les arguments du terrorisme, de la pédophilie, ou autres menaces de propagandes extrémiste, les gouvernements cherchent à restreindre la liberté sur internet du mieux qu'ils peuvent.

Nous avons vu ce que cela pouvait donner durant les dernières révolutions en Tunisie et Egypte, quand le gouvernement décida de couper la connexion internet hors du pays…

  • Le peer2peer à poussé pendant un temps le concept de décentralisation, mais sans aller à l'extrême ( un réseau distribué ), et est aujourd'hui en recul face à des solutions centralisées de stockage et diffusion de données.
  • Le mail, est également aujourd'hui entre les mains de grand services de distribution qui imposent leur règles en matière de protection anti-spam qui rendent d'autant plus difficile la mise en place d'un service compatible à domicile.

Les seules solutions restantes se trouvent dans des sous réseaux d'internet, tel freenet (qui lui est pensé pour être décentralisé), ou dans des solutions universitaires (batman), qui ne verront probablement jamais le jour pour le grand public.

C'est pourquoi, il est plus que nécessaire aujourd'hui, de continuer le combat de l'auto-hébergement, de refuser de confier ses données à un tiers quand nous avons la possibilité de les avoir nous même. Les solutions telles la freedombox proposent des services tout intégrés,

Blogguer en rst sous wordpress

14 octobre 2010

Le format reStructuredText est un langage de balise (un peu comme le HTML, ou le laTex ), issu du monde de la programmation. Son but est de répondre au problème suivant : comment écrire du texte simplement et sans avoir besoin d'apprendre une syntaxe spécifique (ou du moins un minimum), tout en conservant des possibilité de formatage et d'export ?

Présentation de RST

Quand on écrit un article (par exemple ici cet article de blog), il est nécessaire d'indiquer des directives de mise en page : ceci est un paragraphe, ceci est un lien, inclure une image, une citation… Pour cela on ne passe pas par un logiciel de traitement de texte pour le faire (openOffice) : c'est lourd et cela n'apporte rien, mais la plupart du temps par un éditeur intégré au blog qui permet de formater notre texte.

Cet éditeur se charge pour nous de formater le texte en quelques clics. Le problème est que bien souvent ce texte ne pourra pas sortir du blog (par exemple pour prendre un extrait de l'article et l'utiliser ailleurs, nous sommes obligés de passer à nouveau par cette interface)

Une autre solution est de rédiger notre texte directement dans le format de sortie (par exemple HTML), mais cela nécessite de connaître la syntaxe, et ne rend pas la lecture du fichier source très lisible (essayez de lire un article de presse en HTML avec un éditeur de texte pour voir…)

Le format reStructuredText se veut être une réponse à ces problèmes : un fichier RST est lisible (le fichier source est compréhensible et peut être lu directement), ne nécessite pas de connaissances particulières (du moins peu), et à l'avantage de pouvoir être exporté dans de nombreux format de sortie (odt, pdf, latex, html…) On dispose donc d'un format unique pouvant servir à écrire des articles de blog, des documents de travail, ou encore de la documentation.

La syntaxe est très simple, et ne charge pas le document à la lecture. Par exemple pour voir le document ayant servi à générer cet article est disponible ici : on laisse des lignes blanches pour indiquer que l'on passe d'un paragraphe à un autre, ou « souligne » avec les caractères = _ ou - les titres et les sous-titres, et le résultat donne un document très aéré et agréable à travailler.

Plugin wordpress

Il existe un plugin wordpress qui permet d'utiliser ce format pour l'écriture de documents dans le blog. À chaque fois que l'on va publier un article, le plugin va tester si le fichier est au format rst, et dans ce cas, va en faire la conversion en html en passant par la commande rst2html.

Attention, pour le mettre en place, il est nécessaire d'avoir un accès à la machine pour y installer quelques applications.

Pré-requis

Python doit être disponible sur la machine, ainsi que le script rst2html (je ne pense pas que cela soit le cas pour les blogs hébergés et cela limite les possibilités).

1
$ sudo aptitude install python-docutils

Installation

Il s'agit juste d'un fichier à installer dans le répertoire des plugin de wordpress. Celui-ci est disponible sur launchpad et ne pose aucun problème de compatibilité.

Le fichier README explique comment l'installer et le paramétrage à faire; les options (comme le chemin vers rst2pdf) se font directement dans le fichier php.

1
2
3
4
5
// Set this to the prefix of your docutils installation.
$prefix = "/usr/local";

// Set this to the path of rst2html.py
$rst2html = "$prefix/bin/rst2html.py";

Un petit test devrait montrer le résultat tout de suite. Dans le cas où le contenu est vide, regardez les logs d'erreur du serveur web, vous devriez y trouver les causes de votre erreur.

Coloration syntaxique

Il est possible de disposer de la coloration syntaxique automatique du code :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
import os
# Standard hello world stuff
class Hello()
    def do_it(self)
        print "Hello world"

if __name__ == '__main__':
    Hello().do_it()

def main()
    print "Hello world"

Pour intégrer la coloration syntaxique, il faut passer par pygment (un programme python qui s'occupe de ça) :

1
# aptitude install python-pygments

Ensuite il va falloir modifier le script à lancer. En effet, par défaut, la commande rst2pdf n'intègre pas la coloration de code. Nous allons donc devoir modifier la commande à exécuter pour le faire (j'ai mis à disposition le script à télécharger). Assurez vous que le script peut être exécuté par l'utilisateur lancé par le service web.

La CSS n'est pas inclue dans le document et peut être définie à l'extérieur. Il est possible de définir son style à partir de pygment avec la commande suivante (pour appliquer le style tango) :

1
$ pygmentize -S tango -f html > style.css

Conclusion

Je cherchais depuis un petit moment une solution pour pouvoir écrire mes articles sans me connecter au blog. Les applications clientes ne me convenant pas tout à fait, le RST me permet d'utiliser une application totalement séparée du blog (par exemple VIM) et un format pérenne.

Je ne sais pas s'il existe une solution équivalente pour les autres moteurs de blog, le RST étant encore un format assez jeune, et n'est pas encore très répandu…

Sans être aussi complet que le latex, il est bien plus souple et beaucoup plus facile à utiliser. De plus il s'agit bien sûr d'un format ouvert, pouvant générer des documents sous openOffice, en PDF, voire en latex pour ceux qui veulent…

Édit (29/05/11)

Je reviens sur le plugin en constatant que par défaut, celui-ci met en cache le contenu de l'article, même si celui-ci est déjà en html. Une petite modification dans le code permet de ne sauvegarder le fichier que s'il s'agit d'un fichier rst :

Rechercher dans le script la chaîne suivante :

1
2
3
if ($pos === false) {
  // No modeline.
  $rval = wpautop($text);

Et rajouter la ligne suivante en dessous :

1
return $rval;

Présentation de Vala

11 juin 2010

J'ai découvert une présentation du langage dans GLMF n°127 qui l'utilisait pour se brancher sur le pare-feu. Cela ayant aiguisé ma curiosité, j'ai cherché à en savoir davantage sur le langage.

Le langage C m'a toujours paru difficile à aborder. Non pas au niveau de sa syntaxe, mais au sujet de l'accès à sa documentation et aux librairies disponibles. Pour moi qui suis habitué à Java ou à Python, j'ai regardé Vala comme un moyen de mettre un pied dans le C. Je vais essayé de présenter ma manière de le voir, après avoir fait une petite plongée dedans…

Présentation

Le langage Vala à été créé par les développeurs de Gnome pour qu'ils puissent disposer d'un langage de haut niveau. Gnome ayant eu pendant quelques temps un pied ( dansant ) dans mono, Vala en est très inspiré. ( Je ne connais pas mono et ne peux donc pas lancer de comparatif, je vous renvoie donc à celui présenté par Gnome par rapport à C#, et pour Java ). Le langage est ensuite compilé en C, et GCC est utilisé pour la compilation d'un exécutable.

On est donc dans un langage intermédiaire, qui reste très proche du C comme nous allons le voir par la suite.

Analyse

Langage objet haut niveau

Vala est tout d'abord un langage haut niveau : on y retrouve des interface ( pour pouvoir moduler le code facilement ), des delegate ( qui permettent de de définir un type de fonction pour un callback ), une gestion événementielle ( gérer le déclenchement de plusieurs méthodes dans le code par un appel unique ) … On dispose donc d'un langage objet assez riche pour éviter d'avoir passer du temps sur des détails et se concentrer sur le programme et son déroulement. Il est pensé objet et l'on retrouve vite ses marques, tout comme l'on sent qu'il est assez facile d'« abstraire » le code pour faire une application qui n'en reste pas un simple script…

Je n'ai pas envie de détailler la syntaxe du langage et tout ce qu'il intègre car vous pourrez trouver tout cela en ligne. Je vous renvoie au tutoriel qui explique la structure du langage en détail, qui présentent des exemples détaillés.

La GLib

Le langage est basé sur la GLib, la librairie standard utilisé dans les applications GTK. La plupart des types primitifs ( int… ) sont donc en réalités des types issus de cette librairie ( gint…). On accède ainsi à l'ensemble des méthodes de la GLib, diffusées sous formes de classes objets et bien documentées ( la valadoc ). Cela rejoint l'histoire de Vala puisque La GLib est tout utilisée par les développeurs Gnome ( on constate d'ailleurs que la plupart des composants Gnome ont une entrée dans cette Valadoc ).

Il ne faut cependant pas croire que l'on dispose avec cette bibliothèque standard d'un ensemble de routines aussi riche que dans le package standard d'un Java ou d'un Python : la GLib est avant tout destinée à des développeurs C, et beaucoup des méthodes standard du C n'y sont pas disponibles. Pour parer cela, Vala propose une classe POSIX[LIEN] proposant les méthodes standard du C, mais celle-ci n'est pas exhaustive et il nous arrive souvent de tomber sur une fonction qui ne nous est pas accessible via le langage haut niveau qu'est Vala.

Les Bindings

Pour répondre à cela, propose la possibilité de mettre en place un binding vers une libraire C de manière native. ( Normal me direz vous, le code en sortie de Vala est du C ! ) On peut donc très facilement utiliser n'importe quelle libraire existante. Vala étant un langage objet, il devient donc possible d'utiliser les librairies standard au sein d'un code objet de haut niveau. Cela ne demande que quelques lignes, demandant au minimum le fichier dans lequel se trouve la définition de la méthode, et sa signature.

Exemple du binding définissant la méthode execl ( issue du fichier /usr/share/vala/vapi/posix.vapi ) :

[CCode (cheader_filename = "unistd.h")]
public int execl (string path, params string[] arg);

et voici la signature de la méthode C correspondante :

extern int execl (__const char *__path, __const char *__arg, ...) __THROW __nonnull ((1));

Les types primitifs de la GLib étant basés sur les types primitifs C correspondant, il n'y a pas de problème de cast dans la plupart de cas. Toutefois, Vala utilise des char* pour définir ses string : il est parfois nécessaire de mettre en place faire un cast quand une méthode nous un char[] : même dans le code haut niveau, le C n'est jamais loin…

C'est souvent frustrant de devoir mettre en place un binding pour une fonction disponible en standard dans la libc. Je pense qu'il manque la possibilité d'inclure directement du code C dans le code vala, tout comme il est possible directement de l'assembleur dans du C. Cela permettrait un confort dans l'utilisation qui n'est pas disponible actuellement.

À noter qu'un outil permet de mettre en place ces bindings pour les composants basés sur GObjet ( Gnome toujours… ). De plus de nombreux bindings sont disponibles pour les composants Gnome. Attention, cela n'empêchera pas d'avoir à installer les headers C correspondants !

Les profils

Il est possible d'utiliser des profils de compilation. Cette option encore expérimentale a été mise en place pour répondre à des réclamations de la part des utilisateurs qui voulaient programmer en Vala sans avoir de dépendances envers la GLib. Ainsi, il est possible d'appeler le compilateur avec la syntaxe suivante :

valac --profile posix

ce qui a pour conséquence de réduire le jeu de bibliothèque par défaut à celles disponibles dans la classe POSIX. Cela permet de limiter les dépendances du programmes, mais beaucoup de types standard de Vala deviennent de ce fait indisponible; on sent bien que le langage n'a pas été pensé pour ça.

Conclusion

Pour résumer, je dirais que Vala correspond à ce qu'il annonce : un langage haut niveau pour faciliter la création d'applications Gnome. Dès que l'on cherche à sortir de ce cadre, on se retrouve confronté à des limitations ( qui ne sont bien sûr pas insurmontable ) :

  • Pour ceux qui ne cherche pas à travailler sur du code Gnome, embarquement de bibliothèques qui ne nous intéressent pas forcement. ( Bien que sur ce point, la GLib est plutôt standard sur les PCs ayant X d'installés )
  • Pour ceux qui cherchent un langage de haut niveau, le C est encore trop présent entre les lignes pour pouvoir l'oublier complètement. D'un autre côté, l'intégration du code C n'est pas toujours évidente puisqu'elle oblige à déclarer des bindings pour des fonctions standards.
  • Mais surtout, le fait que l'ensemble des fonctions de la libc ne soient pas encore disponibles oblige à mettre le doigt dans les bindings régulièrement.

Le langage est bien sûr encore amené à évoluer, et les points que je cite ici ne sont pas pour autant rédhibitoires. D'un point de vue totalement subjectif Je trouve le langage simple mais sans trop de saveur. Ça reste un langage objet qui n'est bien sûr pas révolutionnaire; on sent qu'il ne fait que reprendre les concepts des langages qui l'ont inspiré, mais le produit est cohérent, et d'après les benchs génère un code plutôt optimisé ( en rapport avec le temps que l'on pourrait passer à produire le même code en C ). Après, je ne prend pas le même plaisir à programmer en Vala qu'en python ( j'avais bien dit que j'étais subjectif ^^ ).

Cela dit, pour moi, qui ne suis pas un développeur Gnome, je suis plus intéressé par la possibilité d'avoir un langage haut niveau qui reste très proche du C, avec les performances qui vont avec; si le prix pour cela est une dépendance vers la GLib, ça reste un coût sommes toutes assez faible.

Un menu pour awesome

6 juin 2010

Awesome est un window manager (wm) en mode pavement ( les fenêtres se disposent de manière à ne jamais se chevaucher ). Cela permet de ne pas avoir à se soucier de la manière dont il faut gérer l'affichage des applications.

Awesome

Une des particularité est que sa configuration se fait par un fichier de script exécuté au lancement du bureau. Cela permet de paramétrer comme on le souhaite le bureau sans être limité par le WM. La contrepartie est que cela est plus difficile à prendre en main, et une erreur de code entraîne un écran gris au lieu du bureau que l'on souhaite obtenir... Le langage utilisé ( Lua ) est un langage connu pour sa légèreté. Pour l'instant, le projet étant encore assez jeune, il n'existe pas encore beaucoup de modules standardisés pour configurer le système, mais je pense que ceux-ci ne tarderont pas à venir...

Pour l'instant la configuration n'est pas encore stabilisée, certains composants changent au cours d'une version à une autre, ce qui casse parfois la mise à jour et oblige à retravailler les scripts de mise de configuration. Je pense cependant que tout cela suit la bonne direction et que ces soucis finiront par disparaître avec le temps et les versions suivantes

La plupart des actions peuvent être associées à un raccourci clavier, et si il est possible d'affiche une barre d'outil à chaque applications (« titlebar »), on prend vite l'habitude de s'en passer et de tout contrôler au clavier. On est d'autant plus aidé par cela par shifty une extension qui permet de « programmer » la manière dont on veut que les fenêtres s'affichent : sur quel écran, avec quels paramètres etc. Cela permet par exemple d'avoir une configuration pour des applications utilisant plusieurs fenêtres ( je pense par exemple à Gimp ) paramétrée comme on le souhaite…

On prend vite l'habitude également d'utiliser plusieurs « tags » ( l'équivalent de bureaux virtuels mais un peu plus étendus ) : ceux-ci peuvent être paramétrés pour afficher des applications sépicifiques ( j'ai par exemple adapté ma configuration pour que web affiche firefox, ou que news affiche le couple elinks/newsbeuter pour lire mes flux RSS…

Bien sûr le temps de paramétrage au début est un peu long, mais maintenant que l'API est stable, il n'est plus nécessaire de tout reprendre à chaque fois que l'on met à jour awesome.

Je trouvais qu'il manquait à Awesome un menu avec les actions disponibles sur les fenêtres : la faire passer au premier plan, la minimiser… Tout ceci est disponible avec des raccourcis claviers, mais il n'y a pas d'option centralisée pour les retrouver. J'ai donc décidé de me plonger un petit peu dans lua pour produire le menu que voilà :

Menu pour awesome

Le menu permet les actions suivantes :

  • On top : Pour mettre le client sélectionné au premier plan et le rendre flottant
  • Sticky : Faire apparaître le client sur tous les tags
  • Minimize : Réduire le client
  • Close : Fermer le client
  • Move To : Déplacer le client vers un autre tag

Le script fonctionne avec awesome 3.4.5, les versions antérieures ne sont pas forcement compatibles suite à un changement dans l'ABI du menu. J'essaierai également de le mettre à jour pour les versions suivantes ( du moins tant que je m'en servirai…)

Pour le faire fonctionner, il faut télécharger le script et le placer dans son répertoire ${HOME}/.config/awesome . Ensuite, éditer le fichier rc.lua et y ajouter la ligne suivante en en-tête :

require("mymenu")

et dans la partie Key Binding :

clientkeys = awful.util.table.join(
[…]
    awful.key({ modkey,           }, "Down",    function(c) menu_instance = newAppMenu(c)    end),

Le menu apparaîtra sur le raccourci Mod4 + Flèche du bas

Le fichier :
mymenu.lua

Mettre en place un environnement sftp chrooté

8 avril 2010

Note : Je propose une autre approche pour mettre en place cette solution : mettre-en-place-un-environnement-sftp-chroote-2/

La demande

Ma copine m'a demandé de trouver une solution simple pour échanger des fichier avec sa sœur, msn posant des problèmes… J'ai pensé à mon serveur ssh et mettre en place une connexion sftp pour ça. Sur le principe cela a été adopté avec une petite présentation de filezilla (je ne sais pas s'il existe des clients sftp intégrés sous windows ?), j'ai donc commencé à mettre en place le système.

De mon côté, la condition principale est de n'autoriser les connexions que par clef publique ( pas de mot de passe ),  ma copine a tenu à ce que sa sœur ne puisse pas accéder aux documents présents dans son home, et du mien à ce que l'on ne puisse pas pour autant se promener dans l'arborescence du serveur : il va donc falloir chrooter l'environnement.

Il existe pas mal de documentation la dessus sur internet, mais je me suis souvent retrouvé face à des exemples incorrects ou incompatible avec le fait de passer par une clef publique, je vais donc détailler les problèmes rencontrés.

Le compte + clef publique

La première étape est de créer le compte, cela se fait assez simplement :

# adduser ${user}

Création de la clef ssh avec puttygen
et en répondant aux questions par défaut… Vient ensuite la clef publique : filezilla gère les clefs privés au format ppk ( putty ) et je n'ai pas trouvé d'outil pour les générer sous windows. Je suis donc passé par wine + puttygen pour créer la clef. Une fois celle-ci crée, on enregistre la partie publique et la partie privée de la clef.

La clef publique va être enregistrée dans le fichier ${user}/.ssh/know_host sur le serveur pour autoriser le client à s'y connecter. La clef privée sera enregistrée de son côté au format ppk pour être utilisée par filezilla (il est possible à partir de ce fichier de générer une clef privée de type openssh ).

Intégrer la clef privée dans FileZilla

Il faut ensuite intégrer la clef privée dans filezilla en passant par les paramètres : elle sera automatiquement lue à la connexion ( il faut choisir «interactive» dans le type d'authentification ). ( Attention : sous windows j'ai rencontré des problèmes avec un répertoire contenant des accents, la clef semblait être lue, mais la connexion ne se faisait pas pour autant. )

Chrooter l'environnement

Aujourd'hui il est possible de chrooter nativement un environnement sftp avec openssh. Il faut pour cela mettre en place une condition sur l'utilisateur ( ou le groupe ) pour faire le chroot :

Match user ${user}
   ChrootDirectory /var/chroot/
   X11Forwarding no
   AllowTcpForwarding no
   ForceCommand internal-sftp

Dans cet exemple le chemin /var/chroot sera utilisé comme racine lors des connexions sftp. Ce répertoire doit être détenu par root:root et avoir les droits 755. Cela veut dire que si notre utilisateur à pour répertoire home /home/${user}, il se retrouvera dans /var/chroot/home/${user} lors des connexions sftp. Il est nécessaire de conserver le répertoire home de l'utilisateur pour que ssh accepte une connexion par clef. En effet, lorsque l'utilisateur va se connecter, ssh va lire dans son répertoire personnel pour lire le fichier .ssh/know_host et autoriser ou non la clef qui se présente. Ce qui signifie que si l'on modifie le répertoire personnel, il faut aussi déplacer cette arborescence ( hors de question dans ce cas de mettre / comme racine de l'utilisateur ).

À noter : j'ai préféré faire le match sur le nom de l'utilisateur plutôt que sur son groupe ( le groupe sera utilisé par ailleurs ). Dans le cas où nous avons plusieurs utilisateurs, il est possible de les mettre à la suite ( séparés par des virgules ).

J'ai vu de nombreux tutoriaux qui indiquent comme répertoire de chroot « /home/%u » ( le répertoire de l'utilisateur standard ), et qui demandent de changer le répertoire de login de l'utilisateur par « / ». Je pense que c'est une très mauvaise idée : d'une part parce que cela oblige à déposer les clefs à la racine du serveur, mais aussi à cause de la contrainte d'openssh demandant à ce que le répertoire root soit détenu par root : cela veut dire que l'utilisateur n'a pas le droit de déposer de fichiers ou de créer de répertoires dans son propre home !

Le plus simple est donc de prendre un autre répertoire pour l'échange, et laisser le home de l'utilisateur pour la configuration. ( Cela permet aussi d'être sûr que le répertoire .ssh ne sera pas effacé par erreur par l'utilisateur… ) J'ai donc mis un lien symbolique pour lier le /home de l'utilisateur avec son répertoire d'échange :

# mkdir /home/${user}/echanges
# ln -s /var/chroot/home/${user} /home/${user}/echanges

On retrouvera ainsi la possibilité de voir les fichiers déposés en passant par le /home de l'utilisateur ( même si ce dernier ne pourra pas y aller… )

Isoler l'environnement

Maintenant que nous avons empêché l'utilisateur de se balader sur l'ordinateur, nous allons l'empêcher de se balader dans les autres répertoires des utilisateurs : cela se fait en une ligne de commande (pour chacun des répertoires que nous allons ouvrir en sftp : )

# for fichier in /var/chroot/home/*; do chmod o-r ${fichier}; done

Et voilà ! Les utilisateurs peuvent voir qu'il existe d'autres comptes que le leur, mais ne peuvent pas y accéder.

Autoriser le partage

Maintenant que nous avons fermé les droits de manière générale il nous reste à autoriser le partage des fichiers ( après tout c'était le but de la demande !) de manière plus fine. Cela implique pour moi deux choses :

  1. permettre à un autre utilisateur d'accéder aux données présentes
  2. permettre à un autre utilisateur de déposer ( ou de supprimer des donnée )

Pour le premier point, c'est facile il suffit d'ajouter l'utilisateur A au groupe de l'utilisateur B :

# usermod -a -G ${user} ${un_autre_utilisateur}

Et l'utilsateur un_autre_utilisateur pourra donc accéder à l'ensemble des fichier pour les lire ( et éventuellement les rapatrier chez lui).

Pour le second point ( possibilité d'écrire et modifier ) c'est un peu plus compliqué; en gros nous voulons que les fichiers déposés par sftp dans le répertoire de l'utilisateur ait comme groupe d'appartenance celui du propriétaire du répertoire ( quel que soit l'utilisateur qui dépose ) et qu'ils soient modifiable par le groupe ( g+w ) du propriétaire.

Par exemple : l'utilisateur A dépose un fichier dans le répertoire d'échange de l'utilisateur B. Il faut que les droits de ce fichier se présentent ainsi une fois le transfert terminé :

$ ls -l fichier
-rw-rw----  1 utilisateurA utilisateurB

( ainsi l'un et l'autre pourront supprimer le fichier ).

Pour cela nous allons utiliser une « bidouille » de l'os : le sgid bit. Derrière ce nom barbare se trouve un marqueur qui permet de fixer le droit de tous les fichiers qui seront créés dans le répertoire ( plus d'info ici ). Pour le déterminer on passe par chmod :

# chmod g+s /var/chroot/${user}

Cela détermine bien quel est le groupe qui sera propriétaire du fichier, mais cela ne donne pas à ce groupe le droit de le modifier pour autant ! Sous linux, c'est la commande umask qui permet de déterminer les droits des fichiers. Le problème est qu'il s'agit d'une commande lié à l'environnement de l'utilisateur, et non pas aux répertoires sur lesquels nous travaillons ( à moins de passer par les ACLs mais cela est déjà assez compliqué comme ça… ). Ici, nous sommes dans un environnement sftp, sans shell de login, donc sans possibilité d'exécuter la commande directement, il faut que ce soit le serveur sftp qui le configure. J'ai trouvé énormément de documentations ( la plupart des bidouillages ) pour contourner le problème, mais la solution la plus simple vient de la dernière version d'OpenSSH (5.4 ) sortie le 8 mars dernier.

Exemple de configuration

Une nouvelle option sur le serveur sftp permet d'indiquer quel est l'umask qui sera appliqué ( dans notre cas 002) : dans le fichier/etc/ssh/sshd_config nous allons configurer les paramètres par défaut du serveur sftp :

Remplacer :

Subsystem sftp /usr/lib/openssh/sftp-server.sh

par :

Subsystem sftp /usr/lib/openssh/sftp-server -u 002

Pour définir les droits umask qui seront appliqués par défaut pour toutes les connexions sftp par défaut. Ce paramétrage est à redéfinir pour les paramétrages personnalisés ( bloc Match ) :

ForceCommand internal-sftp -u 002

Conclusion

Nous avons un environnement bien hermétique, pouvant gérer l'augmentation du nombre de compte ( il suffit de refaire les chmod dans notre environnement chrooté  à la création du compte ), et hermétique. Le paramétrage côté serveur est effectivement assez lourd au début, mais je pense que la mise à jour ne demande pas trop de travail, et on gère les droits de manière assez fine ( en passant par les groupes ce qui me semble être dans la mentalité unix ).

Pour le client, il n'y a pas grand chose à paramétrer ( récupérer la clef et l'intégrer ), et il n'y a aucun risque que celui-ci vienne casser son paramétrage. On peut même sauvegarder sa clef privée dans son home (le vrai ), au cas où il perdrait le fichier.