Rennes libère ses données publiques

Aldevar, 10/03/2010 | Source: Alain Devarieux (aldevar)

La ville de Rennes a décidé de mettre à la disposition de ses citoyens les données publiques de son réseau de transport. Ces données comportent les horaires et circuits des bus et métro ainsi que les points de regroupement des Vélos Star (le vélib rennais). Sont également concernés les coordonnées et horaires des associations de quartier. Toutes ces données sont disponibles sous licence Creative Commons.

Rennes métropole espère grâce à cela que les développeurs en herbe créent des applications pour smartphones afin de faciliter la vie dans la capitale bretonne. Selon Noël Philippe, directeur général des services urbains de Rennes Métropole « Le processus classique d’appel à projets pour une collectivité est très lourd. Il faut lancer un appel à candidatures, rédiger un cahier des charges, etc. Dans un an, nous aurions peut-être juste sélectionné nos partenaires. Grâce à l’open source, nous espérons que des applications seront disponibles d’ici quelques mois. »

Dans un premier temps, un usage commercial de ces données devrait être interdit. Il est envisagé d’autoriser par la suite l’usage commercial pour que les développeurs puissent vendre leurs applications.

Toutes les données de transport sont disponibles depuis le 1er Mars à l’adresse data.keolis-rennes.com. Elles seront complétées dans le courant de l’année 2010 par les données des organismes publics et des associations puis seront toutes regroupées sur le portail data.rennes.fr. Les documents seront proposés au format XML avec une API documentée afin de faciliter le développement.
Afin de lancer le projet, la ville de Rennes devrait organiser durant le printemps 2010 une concours d’applications dont les modalités et les lots sont encore à définir.

Ce projet est une première en France. Il a été inspiré par des initiatives similaire à l’étranger (Londre, San Francisco, Portland) et il est possible, suivant son impacte et sa réussite qu’il créé des émules dans d’autres ville française.

Source : http://www.rennes-metropole.fr/espace-presse,76701/

gyo, un archer, ouvre son blog

Nic0, 10/03/2010 | Source: Nic0

gyo gyo, un archer, ouvre son blogUne fois n’est vraiment pas de coutume par ici que de présenter un blog de quelqu’un d’autre, peut être par le fait que je ne suis ni trop « blog roll » ou « social network » (genre twitter, autre).

Et comme l’envie me prend de présenter un blog, je me dis, autant le faire au travers d’un billet, et je rassure, ni de kidnapping, ni acte de terrorisme ne m’oblige à le faire, c’est de bon cœur :þ

Une petite présentation quand même de gyo pour ceux ne connaissant pas la personne, utilisateur d’ArchLinux depuis de longue date, depuis avril 2007 au moins à en croire sa date d’inscription sur le forum, sur lequel il sera devenu modérateur, et également « op » sur le salon de freenode #archlinux-fr.

Il est indéniable qu’il est apprécié par les archers, et prend place sur #archlinux-fr, grâce à ses connaissances techniques, son humour fin, une écoute des autres, et une exigence de soi même.
C’est donc une bonne personne à connaître.

La bonne nouvelle est qu’il ouvre _enfin_ son blog ! Dont les sujets principaux seront GNU/Linux, Logiciels Libre et autre trucs de geek (pour reprendre ses mots)

Je pense qu’il a tout pour faire un bon blog, de la qualité rédactionnel à l’exigence de soi-même pour traiter des sujets comme de long tutoriel de façon précise et complète, ainsi que l’humour et l’inventivité pour nous écrire des billets plus léger et agréable à lire.

Ses deux premiers billets, Gestion multi-comptes des mails IMAP et Gestion multi-comptes des mails IMAP (2) : Imapfilter, sont un exemple de ce qu’il peut faire, en donnant une très belle approche de gestion de mutt avec Offlineimap et imapfilter, ce qu’y est une approche de configuration différente de la mienne. Et là, on ne s’y trompe pas ! La qualité est au rendez-vous !

J’espère juste qu’il persévèrera dans le temps pour sortir des billets « régulièrement » et ne pas abandonner trop vite, et n’hésitez pas à laisser un petit commentaire d’encouragement sur son billet d’introduction.

Une occasion pour moi de féliciter gyo pour l’ouverture de son blog et de l’encourager à continuer sur cette voix.

Parution de Arch Linux Magazine mars 2010

Nic0, 05/03/2010 | Source: Nic0

archfr Parution de Arch Linux Magazine mars 2010C’est un numéro un peu particulier ce mois-ci, bien que la sortie c’est fait dans les temps, c’est bien plus un appel à la contribution que Ghost1227, le rédacteur en chef, lance à la communauté.

Pas de PDF ce mois-ci donc, uniquement un format HTML (original), le retour à une parution « normal » devrait avoir lieu le mois prochain.

Peu de contenu donc, mais quand même un petit tour d’horizon du côté du développement, du forum et de contribution de la communauté.

Comme toujours, le magazine est traduit par quelques bénévoles, cette fois-ci catwell, gyo et moi.

Bien qu’il ne soit jamais facile de demander une contribution de la part de la communauté, personnellement, j’ai trouvé cette appel à la communauté a été fait en finesse.
Le retour en est pour le moment plutôt positif, puisque dans les 24h de la parution du magazine, une poignée de contributeurs potentiel ont débarqué sur le salon #archlinux-magazine de freenode (qui je dois dire est plutôt très calme et désert habituellement).

Pour toute personne voulant participer au magazine, c’est possible, en anglais bien sûr, il convient de suivre les indications mise en place sur cette page de wiki.
Pour information, ceux voulant rentrer en contact avec Ghost1227, vous pouvez le joindre tout les jours sur le salon #archlinux-magazine de freenode.
Toute contribution est bonne à prendre, donc n’hésitez pas.

En espérant d’être de retour le mois prochain pour un numéro plus conséquent.

Un serveur Jabber sous Debian

AddiKT1ve, 23/02/2010 | Source: AddiKT1ve

Pour mettre en place rapidement un serveur Jabber sous Debian, je préconise la solution ejabberd, codé en Erlang.

Installez le paquet ejabberd. Pour une configuration basique, il y a très peu de choses à modifier dans la configuration (/etc/ejabberd/ejabberd.cfg) :

  1. %% Admin user
  2. {acl, admin, {user, "admin", "votredomaine.org"}}.
  3.  
  4. %% Hostname
  5. {hosts, ["votredomaine.org"]}.

Puis ajoutez l’utilisateur admin avec ejabberdctl (en tant que root) :

  1. ejabberdctl register admin votredomaine.org pouet

Vous pouvez à présent vous connecter à l’interface d’administration de votre serveur à l’adresse suivante : http://votredomaine.org:5280/admin avec l’identifiant admin@votredomaine.org et le mot de passe pouet.

Je vous conseille de faire un tour par les Règles d’accès pour passer le paramètre register en allow all ; ainsi, n’importe qui pourra créer un compte sur votre serveur.

Amusez-vous comme des petits fous \o/ !

Miroir Arch Linux plug’n'play

AddiKT1ve, 23/02/2010 | Source: AddiKT1ve

Une clef USB 16 Go c’est bien, une clef USB 16 Go qui sert à quelque chose c’est mieux. D’où cette idée de miroir local Arch Linux, qui fonctionne plutôt… très bien !

Pour commencer, j’ai formaté la clef en ext2, avec « mirror » comme label pour la partition.
Maintenant l’idée, c’est d’avoir [core] et [extra] constamment à jour et à disposition. On va utiliser un script pour faire fonctionner rsync à ces fins. Notez l’intérêt du label pour la partition :

  1. #!/bin/bash
  2. #
  3. # The script to sync a local mirror of the Arch Linux repositories and ISOs
  4. #
  5. # Copyright (C) 2007 Woody Gilk <woody@archlinux.org>
  6. # Modifications by Dale Blount <dale@archlinux.org>
  7. # and Roman Kyrylych <roman@archlinux.org>
  8. # Licensed under the GNU GPL (version 2)
  9.  
  10. # Filesystem locations for the sync operations
  11. SYNC_HOME="/media/mirror"
  12. SYNC_LOGS="$SYNC_HOME/logs"
  13. SYNC_FILES="$SYNC_HOME/files"
  14. SYNC_LOCK="$SYNC_HOME/mirrorsync.lck"
  15.  
  16. # Select which repositories to sync
  17. # Valid options are: core, extra, testing, community, iso
  18. # Leave empty to sync a complete mirror
  19. SYNC_REPO=(core extra)
  20.  
  21. # Set the rsync server to use
  22. # Only official public mirrors are allowed to use rsync.archlinux.org
  23. SYNC_SERVER=distro.ibiblio.org::distros/archlinux
  24.  
  25. # Set the format of the log file name
  26. # This example will output something like this: sync_20070201-8.log
  27. LOG_FILE="pkgsync_$(date +%Y%m%d-%H).log"
  28.  
  29. # Do not edit the following lines, they protect the sync from running more than
  30. # one instance at a time
  31. if [ ! -d $SYNC_HOME ]; then
  32.   echo "$SYNC_HOME does not exist, please create it, then run this script again."
  33.   exit 1
  34. fi
  35.  
  36. [ -f $SYNC_LOCK ] && exit 1
  37. touch "$SYNC_LOCK"
  38. # End of non-editable lines
  39.  
  40. # Create the log file and insert a timestamp
  41. touch "$SYNC_LOGS/$LOG_FILE"
  42. echo "=============================================" >> "$SYNC_LOGS/$LOG_FILE"
  43. echo ">> Starting sync on $(date –rfc-3339=seconds)" >> "$SYNC_LOGS/$LOG_FILE"
  44. echo ">> —" >> "$SYNC_LOGS/$LOG_FILE"
  45.  
  46. if [ -z $SYNC_REPO ]; then
  47.   # Sync a complete mirror
  48.   rsync -rptlv –delete-after –delay-updates $SYNC_SERVER "$SYNC_FILES" >> "$SYNC_LOGS/$LOG_FILE"
  49. else
  50.   # Sync each of the repositories set in $SYNC_REPO
  51.   for repo in ${SYNC_REPO[@]}; do
  52.     repo=$(echo $repo | tr [:upper:] [:lower:])
  53.     echo ">> Syncing $repo to $SYNC_FILES/$repo" >> "$SYNC_LOGS/$LOG_FILE"
  54.  
  55.     # If you only want to mirror i686 packages, you can add
  56.     # " –exclude=os/x86_64" after "–delete-after"
  57.     #
  58.     # If you only want to mirror x86_64 packages, use "–exclude=os/i686"
  59.     # If you want both i686 and x86_64, leave the following line as it is
  60.     #
  61.     rsync -rptlv –delete-before –delay-updates $SYNC_SERVER/$repo "$SYNC_FILES" >> "$SYNC_LOGS/$LOG_FILE"
  62.  
  63.     # Create $repo.lastsync file with timestamp like "2007-05-02 03:41:08+03:00"
  64.     # which may be useful for users to know when the repository was last updated
  65.     # date –rfc-3339=seconds > "$SYNC_FILES/$repo.lastsync"
  66.  
  67.     # Sleep 5 seconds after each repository to avoid too many concurrent connections
  68.     # to rsync server if the TCP connection does not close in a timely manner
  69.     sleep 5
  70.   done
  71. fi
  72.  
  73. # Insert another timestamp and close the log file
  74. echo ">> —" >> "$SYNC_LOGS/$LOG_FILE"
  75. echo ">> Finished sync on $(date –rfc-3339=seconds)" >> "$SYNC_LOGS/$LOG_FILE"
  76. echo "=============================================" >> "$SYNC_LOGS/$LOG_FILE"
  77. echo "" >> "$SYNC_LOGS/$LOG_FILE"
  78.  
  79. # Remove the lock file and exit
  80. rm -f "$SYNC_LOCK"
  81. exit 0

Afin de l’utiliser de la manière la plus propre possible, on va modifier un peu notre /etc/pacman.conf. Le but est de faire comprendre à pacman qu’il doit d’abord regarder le miroir local, puis en cas d’échec un miroir distant :

[core]
Include = /etc/pacman.d/localmirror
Include = /etc/pacman.d/mirrorlist

[extra]
Include = /etc/pacman.d/localmirror
Include = /etc/pacman.d/mirrorlist

Et pour /etc/pacman.d/localmirror :

# Local mirror
Server = file:///media/mirror/files/$repo/os/i686 # i686 or x86_64

Si la partition mirror est montée, pacman ira donc voir si les paquets sont dispos sur votre miroir local ; sinon, il ira chercher sur votre miroir distant habituel.

Keep It Simple, Stupid ;) .

Les différentes mailing lists d’ArchLinux

Nic0, 22/02/2010 | Source: Nic0

communication Les différentes mailing lists dArchLinuxDès lors que l’on souhaite s’informer sur sa distribution favorite, plusieurs moyens sont à la disposition de l’utilisateur.
On peut s’informer au travers du site, de forums, de newsletters ou encore par les mailings lists.
Les mailings lists (ou listes de diffusion) sont une source d’information de choix. De plus, ces listes sont ouvertes au public, et chacun peut y prendre part s’il le souhaite.

Un petit tour d’horizon des différentes listes d’ArchLinux, de l’intérêt de chacune, et des outils mis à disposition pour y rechercher des informations.

Les différentes listes

Une liste de ces listes de diffusion peut être trouvée à cette adresse, on y retrouve une petite description de chacune, mais une explication plus détaillée pour les principales s’impose.

Arch-announce

Arch-announce n’est pas forcément une liste de diffusion à proprement parler, dans le sens où il n’y a pas de discussions, et la participation n’y est pas autorisée.
Cette liste fait doublon avec les articles d’annonces diffusés en page d’accueil du site officiel (archlinux.org). Cette liste ne correspond ni plus ni moins à un « flux RSS » de cette page.
La plupart des nouvelles diffusées sur ce site sont traduites en français, puis diffusées sur le site francophone (archlinux.fr).

Suivre les « gros titres » de sa distribution permet très souvent de répondre à d’éventuelles questions posées lors d’incompatibilité lors de mises à jour (surtout pour une rolling release comme l’est ArchLinux), et permet de suivre une actualité d’ArchLinux, dans un sens plus large.
Je conseille donc de suivre l’une ou l’autre (ou les deux), peu importe sous quel forme, que se soit en s’inscrivant à la liste de diffusion anglophone, ou en utilisant un agrégateur de flux RSS.

Arch-general

Arch-general est donc la liste principale d’ArchLinux.

Bien que parfois cette liste s’apparente à un forum, avec des questions/réponses qu’on pourrait retrouver sur notre forum d’ArchLinux.fr, elle n’est pas sans intérêt, et ce pour plusieurs raisons :

  • Une forte participation de la part des développeurs d’ArchLinux. Des noms comme Aaron Griffin, Pierre Schmitz, Allan McRae, Thomas Bächler… ne vous parle pas ? Ils font partie de l’équipe qui fait ce qu’ArchLinux est ce qu’il est.
  • On y assiste souvent à des suggestions et débats, parfois bien enflammés, que ce soit directement sur le développement d’ArchLinux, ou des questions annexes.
  • Tout le monde peut y prendre part, en respectant des règles de bases, souvent celle en rigueur pour Usenet, comme par exemple répondre aux mails en citant d’abord et écrivant après, et non l’inverse.

C’est, je pense, une liste intéressante à suivre.

Arch-dev-public

Arch-dev-public est selon moi une liste intéressante à suivre surtout si vous activez vos dépôts [testing] et [community-testing] car elle permet de résoudre rapidement des problèmes qu’on peut rencontrer lors de l’utilisation de ces dépôts.

On y retrouve différents types de discussions :

  • Les signoff : en gros, avant d’être intégrés dans les dépôts, les paquetages doivent être « signés » par les développeurs d’ArchLinux et cela pour les deux branches i686 et x86_64. Ce genre de « discussion », qui n’en est pas vraiment, n’offre que peu d’intérêt si ce n’est que de savoir ce qui va arriver dans les dépôts.
  • Les patchs : parfois des patchs sont soumis sur la liste, certainement intéressant pour ceux qui connaissent bien.
  • Les mises à jour pouvant être conflictuelles : une des parties intéressantes de la liste, lorsque des mises à jour peuvent être source de conflits ou nécessitant des attentions particulières pour les dépôts testing, celles-ci sont discutées sur la liste. Cela permet donc de savoir à quoi s’attendre, lorsque par exemple pacman annonce qu’il souhaite remplacer kerne26l-headers par linux-api-headers.
  • Les discussions plus générales : parfois les discussions sur le développement d’Arch-Linux peuvent y être traitées.

Une astuce pour repérer rapidement l’intérêt d’un fil est d’en regarder sa longueur, un [signoff] qui ne pose aucun problème ne dépassera pas les 2 ou 3 réponses, tandis qu’une discussion plus de fond peut atteindre des centaines de réponses. C’est une façon rapide de repérer les sujets importants.
De même un [signoff] comportant plus de réponses que de coutume présage soit un problème avec le paquetage en question ou des indications complémentaires.

Personnellement, c’est la liste que je préfère suivre, je la recommanderais surtout à ceux souhaitant aller un peu plus loin dans les explications d’ArchLinux et ceux souhaitant utiliser les dépôts testing en sachant ce qu’il s’y passe.

Ces deux listes, Arch-general et Arch-dev-public, sont les deux principales listes, et les plus intéressantes. (relativement à chacun je suppose)

Aur-general

Aur-general comme son nom l’indique ne concerne que AUR. L’intérêt de suivre cette liste est relativement réduit, mais elle est essentielle au bon fonctionnement d’AUR.
On trouve principalement deux choses :

  • Les demandes pour rendre un paquetage orphelin, parfois (souvent sûrement) d’anciens archers allant vers d’autres horizons, ou simplement n’ayant plus le temps de s’occuper de leur paquetages les laissent ainsi sans être maintenus. Lorsqu’une personne souhaitant mettre à jour ce paquetage, et n’arrivant pas à obtenir de réponse de son mainteneur, peut en faire une demande de placer « de force » ce paquetage comme orphelin, afin de le ré-adopter et le maintenir par ce nouveau mainteneur.
    C’est une procédure simple mais qui doit être faite « dans les règles ».
  • Inversement, certains contributeurs conscients qu’ils n’auront plus le temps de maintenir leurs paquetages pour diverses raisons allant des études, vie de familles, migration vers d’autres distributions… Ils peuvent faire donc une liste de leurs paquetages et proposer leurs adoptions, parfois proposant même une aide pour les paquetages difficiles à maintenir.

Les autres listes anglophones

Après les listes qu’on vient de voir, on trouve une série de listes d’importance moindre, bien sûr tout dépend de chacun et de son niveau.

  • Arch-commit : on retrouve les commits de différents outils de développement. C’est une liste assez spécifique qui n’a d’intérêt que si on est vraiment connaisseur.
  • Arch-events : une liste un peu délaissée concernant divers évènements.
  • On retrouve d’autres listes encore au trafic plutôt limité et d’intérêt très ciblé comme Aur-dev, pacman-dev, Arch-ports…

La liste francophone

Et pour finir, la liste d’ArchLinuxfr que je cite surtout pour faire le tour des listes, mais c’est malheureusement une liste avec un faible trafic, mais compensée par un forum qui lui est bien actif !

Les moyens pour consulter les listes

Maintenant qu’on a fait un tour des différentes listes, vu un peu les avantages et les informations contenues pour les principales, regardons comment y accéder.

Par souscription

Une façon très classique surtout si vous souhaitez suivre les listes sur le long terme. Il suffit donc de souscrire à une liste, gratuitement bien sûr, pour recevoir par mail à votre adresse, et ainsi lire tranquillement avec votre client mail favori.
L’inscription y est très simple et instantanée. On choisit la liste qu’on veut suivre sur cette page , il suffit de renseigner le mail, un mot de passe et le tour est joué. (difficile de faire plus simple)

Consulter les archives par mailman

On peut consulter les archives de chaque liste, un lien est présent sur chaque liste sur la même page que la souscription (voir ci-dessus).
Par exemple, pour arch-general :

To see the collection of prior postings to the list, visit the arch-general Archives.

La consultation de ces archives peut donner une idée de si l’on souhaite s’y inscrire ou pas à cette liste.
Par contre, il n’y a pas vraiment de fonctions de recherche, et ce n’est pas forcément le meilleur outil pour la consultation des archives.

Consulter les archives avec Gmane

gmane Les différentes mailing lists dArchLinux

Screenshot de l'application web Gmane lors de consultation d'une mailing list

Gmane regroupe beaucoup de listes de diffusion avec des possibilités de recherches avancées et son utilisation plutôt simple. Gmane n’est pas spécifique à ArchLinux, on y retrouve également bien d’autres listes de diffusion.
Pour retrouver les différentes listes de discussion d’ArchLinux, consultez cette page.
Une fois une liste choisie, on trouve plusieurs liens, avec différentes façons de lire les sujets.

Par exemple, pour une même liste :

using frames and threads : façon sympa et classique de suivre les sujets.
using a blog-like, flat interface : « façon blog » particulier, mais les goûts et les couleurs…
The Mail Archive (tout en bas) : très classique également.

Gmane offre la possibilité de poster sur la liste de diffusion, en sélectionnant « Post » en haut à droite.
C’est un moyen rapide de prendre part aux conversations.

On y trouve en plus de tout ça, des outils de recherches et bien d’autres utilitaires.

Google groupe

Google propose un service permettant de suivre les listes de discussions dont celle d’Arch-general.
Je ne suis pas fan de cette solution, mais comme toujours, les goûts et les couleurs…

Conclusion

Je me doute de ne pas avoir été totalement complet sur le sujet, mais ce billet devrait vous donner quelques indications.
En ce qui concerne les listes principales (j’entends par là, arch-announce, arch-general et arch-dev-public), elles sont très intéressantes, on y apprend des fois des détails et on y retrouve un peu l’ambiance UseNet qui peut différer des forums qu’on trouve sur le web.

J’espère que cela motivera quelques-uns à y jeter un œil. Et encore une fois, je trouve que l’approche de celles-ci sont différentes des forums (anglophones et francophones) et donc de s’informer sur ses listes est un complément.

parution de Arch Linux Magazine février 2010

Nic0, 14/02/2010 | Source: Nic0

archfrAvec la parution de ce dernier numéro, Arch Linux Magazine semble retourner dans une parution régulière et mensuelle ce qui est une bonne nouvelle.

L’équipe de traduction a tout de suite sauté sur l’occasion pour vous offrir une traduction dans la langue de Molière.

Remercions donc tuxce, catwell, gyo (et moi-même) pour avoir participé à la traduction et relecture.

Ce mois ci, le numéro est disponible sous deux format, un format PDF (fait avec scribus) et un autre HTML. (ou encore l’original)

Sans plus attendre, voici un sommaire de ce que vous y trouverez:

  • Éditorial
  • Côté Dev.
  • Arch Linux Schwag Report (boutiques en ligne)
  • Contributions de la communauté
  • Périphériques persistants
  • Gimp Grunge
  • Une moto avec un petit plus
  • Desk Shots

On peut noter l’article / tutoriel principal sur GIMP, qui est un petit how-to pour faire des fonds d’écrans bien sympathique, comme sur cette image.
Je l’ai même repris sur mon PC personnel.

J’espère que vous apprécierez la lecture tout comme j’ai apprécié de contribuer à sa traduction.

PyGitWeb v0.1 is released !

Julien, 13/02/2010 | Source: Julien Pecqueur

Ça y est la première release de PyGitWeb est sortie!

Il s’agit de la version 0.1.

Elle est stable mais ne propose qu’un nombre limité de fonctionalités.

Fonctionalités :

  • Vue principale :

On affiche la liste des dépôts du serveur avec leur dernier commit. Si on clique sur l’un des dépôt on ouvre la vue vue détaillée du dépôt.

  • Vue détaillé d’un dépôt :

On affiche un menu sous le dernier commit. Ce menu permet d’aller dans le répertoire du dépôt (pratique si c’est un site web), d’afficher la liste des commits et leurs détails, et d’afficher le diff s’il y a eu des modifications depuis le dernier commit.

Démo et download :

Si vous voulez le tester ou le télécharger (lien en bas de la page) : http://pygitweb.julienpecqueur.com.

PyGitWeb – relooking :)

Julien, 10/02/2010 | Source: Julien Pecqueur

Mise à jour du theme de PyGitWeb et de l’ergonomie…

L’index :

Liste des dépôts

Liste des dépôts

Le détail d’un dépôt Git :

Détails du dépôt

Détails du dépôt

L’historique des commits :

Liste de tous les commits

Liste de tous les commits

Trouver les capacités (capabilities) d’un programme

tuxce, 09/02/2010 | Source: tuxce

Suite à l’article précédent sur les capacités POSIX, il restait une question en suspens. Pouvoir trouver les capacités nécéssaire à un programme; pour cela, on peut utiliser la capacité qu’offre le noyau pour « court circuiter » des fonctions: Kernel Probes

Le principe est simple si on connaît la fonction appellée, on crée un module ayant une fonction similaire (même prototype) qui log les demandes de capacités selon un nom de programme passé en paramètre au module. Ce dernier nécessite que le noyau ait certaines options d’activées (CONFIG_KPROBES, CONFIG_KALLSYMS_ALL, CONFIG_KALLSYMS entre autres) ce qui n’est pas le cas par défaut sur Arch Linux par exemple, vous pouvez télécharger une version modifiée du PKGBUILD du paquet kernel26 version 2.6.32.7-1: kernel26-2.6.32.7-1.src.tar.gz

Le module est celui de l’article de Serge E. Hallyn [1], j’y ai juste rajouté le paramètre pour le nom du programme à surveiller ainsi qu’un tableau pour me sortir directement la capacité en texte.
Archive: capable_probe.tar.gz
capable_probe.c:

// Original taken from http://www.ibm.com/developerworks/library/l-posixcap.html
// By Serge E. Hallyn (sergeh at us.ibm.com)
//
// Modified by tuxce <tuxce.net at gmail.com>
//
 
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/kprobes.h>
#include <linux/sched.h>
 
 
 
static char progname[255];
module_param_string(progname, progname, sizeof(progname), 0644);
MODULE_PARM_DESC(progname, "Program name.");
 
static const char *probed_func = "cap_capable";
 
static char *cr_cap[] = { "CAP_CHOWN", "CAP_DAC_OVERRIDE", "CAP_DAC_READ_SEARCH", 
	"CAP_FOWNER", "CAP_FSETID", "CAP_KILL",
	"CAP_SETGID", "CAP_SETUID", "CAP_SETPCAP", 
	"CAP_LINUX_IMMUTABLE", "CAP_NET_BIND_SERVICE", 
	"CAP_NET_BROADCAST", "CAP_NET_ADMIN", "CAP_NET_RAW", 
	"CAP_IPC_LOCK", "CAP_IPC_OWNER", "CAP_SYS_MODULE", 
	"CAP_SYS_RAWIO", "CAP_SYS_CHROOT", "CAP_SYS_PTRACE", 
	"CAP_SYS_PACCT", "CAP_SYS_ADMIN", "CAP_SYS_BOOT", 
	"CAP_SYS_NICE", "CAP_SYS_RESOURCE", "CAP_SYS_TIME", 
	"CAP_SYS_TTY_CONFIG", "CAP_MKNOD", "CAP_LEASE", 
	"CAP_AUDIT_WRITE", "CAP_AUDIT_CONTROL", "CAP_SETFCAP", 
	"CAP_MAC_OVERRIDE", "CAP_MAC_ADMIN" };
 
int cr_capable (struct task_struct *tsk, const struct cred *cred, int cap, 
	int audit)
{
	if(strcmp(tsk->comm,progname) == 0)
		if (cap >=0 && cap <= 33)
		{
			printk(KERN_NOTICE "%s: asking for capability %s for %s\n",
				__FUNCTION__, cr_cap[cap], tsk->comm);
		}
		else
		{
			printk(KERN_NOTICE "%s: asking for capability %d for %s\n",
				__FUNCTION__, cap, tsk->comm);
		}
	jprobe_return();
	return 0;
}
 
static struct jprobe jp = {
	.entry = JPROBE_ENTRY(cr_capable)
};
 
static int __init kprobe_init(void)
{
	int ret;
	jp.kp.symbol_name = (char *)probed_func;
 
	if ((ret = register_jprobe(&jp)) < 0) {
		printk("%s: register_jprobe failed, returned %d\n",
			__FUNCTION__, ret);
		return -1;
	}
	return 0;
}
 
static void __exit kprobe_exit(void)
{
	unregister_jprobe(&jp);
	printk("capable kprobes unregistered\n");
}
 
module_init(kprobe_init);
module_exit(kprobe_exit);
 
MODULE_LICENSE("GPL");

Makefile:

# Taken from http://www.ibm.com/developerworks/library/l-posixcap.html
obj-m := capable_probe.o
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
	$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
install: default
	install -d /lib/modules/$(shell uname -r)/kernel/misc/
	install capable_probe.ko /lib/modules/$(shell uname -r)/kernel/misc/
	depmod -a
clean:
	rm -f *.mod.c *.ko *.o

On compile:

$ make
make -C /lib/modules/2.6.32-ARCH/build SUBDIRS=/home/tuxce/posix/capable modules
make[1]: entrant dans le répertoire « /usr/src/linux-2.6.32-ARCH »
  CC [M]  /home/tuxce/posix/capable/capable_probe.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /home/tuxce/posix/capable/capable_probe.mod.o
  LD [M]  /home/tuxce/posix/capable/capable_probe.ko
make[1]: quittant le répertoire « /usr/src/linux-2.6.32-ARCH »
$ sudo insmod capable_probe.ko progname=ping

Si tout se passe bien, vous devrez pouvoir récuperer les capacités demandées dans le log, /var/log/messages.log pour Arch Linux:

$ ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.064 ms
 
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.064/0.064/0.064/0.000 ms
$ tail -2 /var/log/messages.log
Feb  8 17:30:44 host kernel: cr_capable: asking for capability CAP_NET_RAW for ping
Feb  8 17:30:44 host kernel: cr_capable: asking for capability CAP_SETUID for ping

Dans le log, on voit que ping demande CAP_NET_RAW (qu’on a utilisé dans l’exemple de l’article précédent), de même que CAP_SETUID, cette dernière est utilisée pour passer de root à l’utilisateur exécutant la commande, mais comme on a supprimé le setuid, ce n’est plus nécessaire.

L’utilisation du module est assez simple, ou bien on le décharge puis charge avec le bon paramètre, ou on modifie le paramètre en cours de fonctionnement:

sudo cp /usr/bin/crontab{,.x}
echo -n crontab.x | sudo tee /sys/module/capable_probe/parameters/progname
crontab.x -e

Et voyons voir ce que demande crontab:

Feb  8 18:18:33 host kernel: cr_capable: asking for capability CAP_SETGID for crontab.x
Feb  8 18:18:33 host kernel: cr_capable: asking for capability CAP_DAC_OVERRIDE for crontab.x
Feb  8 18:18:33 host kernel: cr_capable: asking for capability CAP_DAC_OVERRIDE for crontab.x

Là, on a exécuté la commande "crontab -e" car elle demande plus de privilèges que par exemple "crontab -l".
Selon la sortie du log, pour se débarasser du setuid de crontab:

sudo setcap CAP_DAC_OVERRIDE,CAP_SETGID=ep crontab


Ressources:
POSIX file capabilities: Parceling the power of root

Posix Capabilities

tuxce, 09/02/2010 | Source: tuxce

Donner plus ou moins de privilèges à un utilisateur a et est toujours un casse tête sur un système d’exploitation. Autant, le fait que certaines actions nécessitent d’être root ne gène pas, autant certaines autres, la plupart du temps effectués par l’utilisateur, font paraître le passage en root comme une action supplémentaire superflue.

La méthode classique est d’avoir ces programmes en setuid root (+s):

$ ls -al /bin/ping
-rwsr-xr-x 1 root root 31020  4 oct.   2008 /bin/ping

Le souci, c’est qu’une vulnérabilité de ping peut devenir problèmatique, les Posix Capabilities permettent d’affiner un peu plus les droits donnés à un programme.

Installons tout d’abord le paquet fournissant les outils nécessaires, sous Arch Linux:

pacman -S libcap

Faisons un essai:
Copions l’exécutable (il perd son setuid lors de la copie):

sudo cp /bin/ping /bin/ping.x

Un test échouera au vu du manque de permission:

$ ping.x -c 1 127.0.0.1
ping: icmp open socket: Operation not permitted

Rajoutons à l’exécutable la capacité CAP_NET_RAW (en root)

sudo setcap cap_net_raw=ep /bin/ping.x

Un autre essai:

$ ping.x -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.064 ms
 
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.064/0.064/0.064/0.000 ms

Les capacités disponibles sont détaillées dans man capabilities.
Les capacités peuvent être assignées à un processus et/ou un fichier (exécutable) en trois ensembles:

  • Permises (p): Capacités pouvant être acquises
  • Héritées (i): Capacités léguées
  • Effectives (e): Capacités acquises

En partant de ces trois ensembles, les capacités sont calculées pour chaque processus selon la logique suivante:

'=capacités calculées
p=capacités du processus
f=capacités du fichier
I=héritées, P=permises, E=effectives
 
pI' = pI
pP' = fP | (fI & pI)
pE' = pP' & fE

Un processus ne peut utiliser une capacité que si elle existe dans l’ensemble permis et effectif (d’où le "ep" sur l’exemple du ping.x)

Imaginons qu’on veuille restreindre le ping à certains utilisateurs, on a besoin de la capacité "cap_net_raw=ep" mais seulement à l’exécution de ping. D’après la logique de calcul:

  • ping.x doit avoir "cap_net_raw=ie"
  • Le processus appelant ping.x doit avoir "cap_net_raw=i"

Ainsi, pP' et pE' auront tous deux cap_net_raw.

Un test:

$ sudo setcap -r /bin/ping.x
$ getcap -v /bin/ping.x
/bin/ping.x
$ sudo setcap cap_net_raw=ie /bin/ping.x
$ getpcaps $$
Capabilities for `6263': =
$ ping.x -c 1 127.0.0.1
ping: icmp open socket: Operation not permitted
$ sudo capsh --caps="cap_net_raw=i" -- -c "su - $USER"
$ getpcaps $$
Capabilities for `6350': = cap_net_raw+i
$ ping.x -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.048 ms
 
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.048/0.048/0.048/0.000 ms
$

Là, on a exécuté un shell en lui affectant une capacité (en utilisant le root), mais si on doit faire ceci à chaque fois, ça ne sert pas à grand chose… Ça tombe bien, c’était juste pour tester la faisabilité, voyons voir comment donner des permissions à un utilisateur.

Les capacités sont héritées par les processus fils, il suffit donc de doter le premier processus lancé par l’utilisateur des capactiés voulues, c’est là que rentre en action PAM [1] le module d’authentification sous linux.

Le paquet libcap sous Arch Linux apporte un module nommé pam_cap.so permettant de configurer ceci. Dans /etc/security/capability.conf:

cap_net_raw	tuxce
none *

Il faut aussi rajouter le module en question dans la configuration pam, /etc/pam.d/login:

auth		required	pam_cap.so

On teste en se loguant depuis une console texte:

host login: tuxce
Password: 
Last login: Tue Feb  9 14:08:55 CET 2010 on pts/2
[tuxce@host ~]$ getpcaps $$
Capabilities for `7601': = cap_net_raw+i
[tuxce@host ~]$ logout

Une alternative à pam_cap.so serait d’utiliser un soft comparable à sudo mais spécifique aux capacités, ça tombe bien, un des développeurs d’Arch Linux, Thomas Bächler alias brain0 a developpé l’outil capsudo qui permet en le configurant d’attribuer des droits à certains utilisateurs [2].

Vous pouvez télécharger le PKGBUILD suivant: capsudo-git-20100209-1.src.tar.gz
En prenant toujours l’exemple de ping, rajoutons ce qui suit à /etc/capsudoers:

[ping.x]
	command = /bin/ping.x
	allow_user_args = true
	caps = cap_net_raw
	users = tuxce

Assurons nous que /bin/ping.x ait "cap_net_raw+ei", puis:

$ capsudo ping.x -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.045 ms
 
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.045/0.045/0.045/0.000 ms

Voilà, avec un mélange de tout ceci, on devrait être capable de donner des droits plus restreints aux exécutables sans pour autant leur permettre de prendre l’identité du root.

Reste la difficulté de deviner les capacités qu’il faut pour les programmes, deux possibilités, écumer le net pour trouver les capacités utilisées par tel ou tel programme, ou bien utiliser un module (nécéssitant certaines options du noyau) qui permet de logguer les demandes d’autorisations, ça fera l’objet d’un autre article, vous pouvez vous référer au wiki anglophone sur les capacités pour une liste non exhaustive.



Ressources:
Petite introduction à PAM (Artisan Numérique)
POSIX file capabilities: Parceling the power of root
Linux kernel capabilities FAQ
Using POSIX capabilities in Linux, part two (brain0)

Ksplice Uptrack : mettre à jour son kernel Linux sans redémarrer

Aldevar, 09/02/2010 | Source: Alain Devarieux (aldevar)

Ksplice Uptrack est une technologie permettant de mettre son kernel Linux à jour sans avoir à redémarrer le système d’exploitation. Depuis peu, cette application est utilisable par le grand public. On peut ainsi télécharger une version d’essai pour 6 versions de Linux ou une version totalement gratuite pour Ubuntu 9.04 et 9.10 (ne me demandez pas ce qui a justifié ce choix…).

Cette version d’essai fonctionne avec les distributions suivantes :

  • Red Hat Entreprise Linux (RHEL) 4 et 5
  • CentOS 4 et 5
  • Debian 5.0 Lenny
  • Ubuntu LTS 8.04 Hardy
  • Parallels Virtuozzo Containers (3.0 et 4.0)
  • OpenVZ (El 5).

Une fois la version d’essai arrivée à échéance, les tarifs mensuels pour continuer à profiter de ses services vont de 3,95 à 9.95 $ US. D’après Ksplice, les différentes distributions GNU/Linux requièrent en moyenne 1 redémarrage par mois afin de profiter pleinement des mises à jour de sécurités du noyau. Leur service permettrai donc de sauver du temps et de diminuer les pertes de performances dues aux redémarrages.

Les sources sont également disponibles sur cette page.

ArchLinux, une distribution abordable pour les curieux

Nic0, 09/02/2010 | Source: Nic0

ArchLinuxUne petite approche de cette distribution de notoriété grandissante qu’est ArchLinux, de son état d’esprit, de sa communauté.

Bien sûr je me dois de préciser que c’est la distribution Linux que j’utilise, ce qui ne me place pas dans la position la plus facile pour en parler mais je vais rester le plus objectif que possible.

J’entends par distribution abordable non pas le coût/prix puisque c’est gratuit, mais le côté techniquement abordable.

On entend souvent qu’ArchLinux est une distribution de geek, qu’elle n’est pas facile.

Ok, ce n’est pas la distribution la plus ‘user-friendly’, il faut faire certaines configurations dans des fichiers texte, mais personnellement je ne trouve pas son approche si difficile, et je pense qu’un débutant, un peu curieux et attentif à ce qu’il fait, peut sans trop de difficulté installer, et maintenir cette distribution.

Il est d’ailleurs possible que cette réputation lui est dût à ses premières heures, où le système n’était pas aussi stable qu’aujourd’hui, et donc la maintenir plus ardus.
Il est néanmoins préférable d’avoir des connaissances GNU/Linux avant de se lancer dans son installation.

Le plus important étant encore savoir lire (correctement) le wiki, un peu de patience, ne pas avoir une peur bleu de la console, une dose de curiosité et de persistance.

Mais sûrement que le maitre mot est curiosité, car il faut aimer fouiner, comprendre et découvrir de soi-même pour être dans une approche positive de cette distribution.
La curiosité d’en apprendre un peu plus sur les applications de base d’un système GNU/Linux. Mais pas non plus dans le sens stricte de Linux.

Judd Vinet

Judd Vinet

Un peu d’histoire

L’histoire d’ArchLinux débute en 2001 à l’initiative de Judd Vinet (début 2001 à en croire cette interview de Judd Vinet) mais la première version d’ArchLinux (ArchLinux « Homer » 0.1) n’apparaît qu’en mars 2002, et inspiré par une autre distribution Linux appelée Crux Linux.

Judd Vinet sera aux commandes d’Archlinux jusqu’en 2007, et passa le flambeau à Aaron Griffin, comme le montre cette news de l’époque.

Principe KISS

On ne peut parler d’ArchLinux sans dire un mot sur le principe KISS (Keep It Simple, Stupid), qui en quelques mot signifie rester simple dans la conception (conception simple n’est pas forcément synonyme de conception de débutant), ainsi que le fait d’utiliser une application pour un but, en simplicité.

« Simplicity is the ultimate sophistication. » –Leonardo Da Vinci

ArchLinux veux donc proposer une distribution en toute simplicité, on le retrouve à l’installation:
Une fois l’installation de base terminé, on se retrouve devant une console et puis c’est tout ! :þ
Mais l’installation de tout un environnement graphique n’est qu’a quelques coup de pacman près (voir la partie gestionnaire de paquetage).

Il convient à chacun d’arranger son installation comme bon l’entend, brique par brique, rien d’imposé à l’utilisateur, il en reste maitre de ses choix.
Donc, pas de bureau imposé par défaut, ni aucune sorte de logiciels, juste l’essentiel, un noyau, de quoi se connecter à internet et c’est un peu près tout.

Si l’installation et la gestion des bibliothèques / logiciels est bien faite, on se retrouve vraiment avec un environnement très réactif (la réactivité d’ArchLinux est reconnu), et cela même pour les environnement bureau tel que Gnome/KDE.

ancien archlinux

Ancien logo d'Archlinux, remplacer en decembre 2007

Rolling release

Un des points vraiment appréciable d’ArchLinux c’est son côté rolling release, ArchLinux ne propose pas de sortie de version, comme Ubuntu (9.04, 9.10…) ou Debian (etch, lenny…) ou la plupart des distribution.
Lorsqu’un CD d’installation sort, les paquetages fournis sont ceux du moment, un peu comme un ’snapshot’ du dépôt, et après cela, les mises à jours de système et logiciels sont constantes, effectuer par l’utilisateur.

Les conséquences de cela, c’est que l’utilisateur à toujours un système à jour (dernier cri) même s’il à faite l’installation il y a plusieurs années. Il n’y a pas de changement de version brusque et dangereuses à faire.

On obtient généralement les derniers version de logiciels compilé rapidement. Pas besoin d’attendre une nouvelle sortie de version de la distribution pour profiter du dernier gnome, ou de la dernière mise à jour de son logiciels favori.

Un gestionnaire de paquet

ArchLinux est avant tout une distribution dites binaires, tout comme Ubuntu, Débian, Fédora et bien d’autre, la distribution fournit dans des dépôts un ensemble de paquetages (logiciels) qui sont précompilé.

C’est plus rapide lors de mises à jours, pas besoin de faire de longues compilations (surtout pour de gros logiciels).

Une des spécificité d’ArchLinux est également d’être optimisé pour les architectures i686 et x86_64, qui sont divisé en deux dépôts.
Ces deux architectures couvrent la majorité des ordinateurs utilisé à aujourd’hui.

Pour gérer cela, un gestionnaire de paquets, (tout comme l’est ‘aptitude’) un outil performant : pacman.
Pacman est plutôt simple d’utilisation, il gère les dépendances efficacement.

Pour donner un aperçu de son utilisation :
pacman -Syu met à jour la liste des paquets et votre système
pacman -S un-paquet pour installer un ou des paquets (donner les noms des paquets à la suite)
pacman -R un-paquet pour supprimer un paquet
pacman -Ss motclé pour rechercher un paquet en rapport avec le mot clé

Les trois dépôts binaires principaux sont [core], [extra], [community] auquel on peut rajouter le dépôt francophone [archlinuxfr].

AUR

À cela on rajoute l’utilisation d’une sorte de gros dépôt commun, mais quant à lui sources : AUR (Arch User Repository).
AUR rajoute ainsi une multitudes d’applications préparer par la communauté.

Pour gérer l’installation de ces paquetages sources, un outil existe, (français) du nom de Yaourt, et simplifie grandement l’utilisation d’AUR.

Une communauté francophone

Linux, c’est aussi et avant tout des personnes rattaché aux projets, la communauté francophone d’ArchLinux est plutôt réputé pour être sympa et réactive sur les forums. (Je dis ça en toute objectivité hein ! :þ)

Mais bien qu’une aide sera toujours apporté, il ne faut pas oublier de chercher un peu soi-même avant de poser des questions.
Les meilleurs réponses à une question sont celle qui vous font réfléchir car les connaissances solide viennent par la réflexions, et par la pratique, et non pas par une suite de commandes prête à l’emploi et copié-collé.

La communauté francophone fût divisé pendant un temps en deux partie, archlinuxfr.org et archlinux.fr, mais à aujourd’hui, il ne reste qu’archlinux.fr.

Petit aparté: On voit parfois sur le forum, des personnes s’offusquer par des réponses rapide et froide, ne citant qu’un lien, bref ne donnant qu’une piste et non une réponse ‘prête à l’emploi’. On en arrive parfois que la personne s’énerve en invoquant « l’esprit du libre ». Rappelons quand même que Linux n’a pas toujours été aussi accessible que Ubuntu (ce n’est qu’un exemple), qu’auparavant une installation de Linux était plus compliqué que d’installer même ArchLinux, et demandait réflexion. Bref, tout ça pour dire qu’historiquement je pense que l’esprit du Libre est une entre-aide pour pousser à la réflexion et à l’autonomie plutôt que du prêt-à-l’emploi.

Donc, vous pouvez retrouver la communauté française sur plusieurs endroit principalement :

  • Le wiki
  • Le forum
  • Et retrouvez également de l’aide sur Freenode, le salon irc #archlinux-fr.

D’autres moyens sont encore disponible, tel un salon sur jabber, ou encore les mailling-list, mais sont un peu moins active.

Les distributions dérivées

Avec l’intérêt grandissant pour la distribution ArchLinux, on a vu au fil du temps des distributions dériver de celle-ci :

  • Chakra: un liveCD proposant directement un environnement graphique sous KDE, et plus particulièrement kdemod, une version plus modulaire. Une partie du forum francophone lui est même dédié.
  • ArchHurd Un projet très récent (début janvier 2010), basé quant à lui sur le système GNU/Hurd, un projet comme on ce doute (avec Hurd) plutôt réservé pour les connaisseurs et aventureux, pas de stabilité, et installation plus compliqué… c’est Hurd quoi :þ
  • ArchServer Distribution visant la stabilité et clairement orienté pour les serveurs.
  • CTKarchLive: Un liveCD créée par CalimeroTecknik de la communauté française, un live qui se veux rapide et léger.
  • Kahel OS : basé quant à lui sur l’environnement de bureau Gnome.

Conclusion

J’espère surtout ne pas avoir été trop de parti pris pour cette présentation d’une distribution qui vaux vraiment le détour.
ArchLinux n’a certainement pas l’expérience d’une distribution tel que Debian, mais n’a pas acquit cette notoriété par hasard. Réactivité et simplicité sont maitre-mots.
Elle s’est fait une places en quelques années parmi les nombreuses déjà existantes.

Et pour conclure… hmm ? vous n’êtes pas déjà en train de télécharger Archlinux !?

Bon, ok un p’tit mot pour la fin faim:
Yaourt c’est bon, mangez-en :þ

PyGitWeb – news :)

Julien, 08/02/2010 | Source: Julien Pecqueur

Suite au précédent article sur PyGitWeb, j’ai continué de travailler dessus… Et ça commence à ressembler à quelque chose! :)

Dorénavant, PyGitWeb génère une page au format xHTML. Elle est générée à partir d’un template. Elle supporte les thèmes via une feuille CSS.

Sur la vue principale PyGitWeb affiche juste le dernier commit de tous les dépôts. Si des modifications non commitées existent, un lien vers le diff apparait.

PyGitWeb (diff masked)

PyGitWeb (diff masked)

Lorsque l’on clique sur le lien vers le diff, on affiche uniquement le dépôt concerné et en dessous le diff :

PyGitWeb (displaying diff)

PyGitWeb (displaying diff)

Il me reste quelques petites fonctionalités à ajouter et le code à nettoyer puis je poste la version 0.1… Ah j’oubliai il me faut aussi un logo!

Lien vers démo PyGitWeb : http://pygitweb.julienpecqueur.com.

Stay tuned for next episode ! :)

Manual upgrade of lighttpd on Debian Lenny

Julien, 08/02/2010 | Source: Julien Pecqueur

Debian c’est bien parce que c’est stable (encore que mon serveur s’est vautré ce weekend à cause de grub!) mais si vous utilisez Lighttpd, vous n’avez pas les mises à jour de sécurité! Même la version dans Sid est obsolète!!!

Cependant, comment installer une nouvelle version de Lighttpd sans chambouler votre Lenny et en gardant les scripts de démarrage et fichiers de configuration?

La solution propre :

On télécharge le tarball de Lighttpd :

> jpec@server:~$ wget http://download.lighttpd.net/lighttpd/releases-1.4.x/lighttpd-1.4.26.tar.gz

On le décompresse :

> jpec@server:~$ tar xzvf lighttpd-1.4.26.tar.gz
> jpec@server:~$ cd lighttpd-1.4.26/

On installe les dépendances :

> jpec@server:~$ sudo apt-get install libpcre3-dev  libbz2-dev

On compile et installe l’éxécutable :

> jpec@server:~$ ./configure
> jpec@server:~$ make
> jpec@server:~$ sudo make install

On modifie le fichier /etc/init.d/lighttpd pour mettre à jour le lien vers l’éxécutable :

PATH=/sbin:/bin:/usr/sbin:/usr/bin
#DAEMON=/usr/sbin/lighttpd      # JPEC -- Suppression version debian
DAEMON=/usr/local/sbin/lighttpd # JPEC ++ Utilisation version compilée
NAME=lighttpd

Et on relance le serveur web !

PyGitWeb – a python web git browser

Julien, 06/02/2010 | Source: Julien Pecqueur

Contexte

J’aime bien Git.

C’est le système de versionning/gestion de sources décentralisé créé par Linus Torvalds (le créateur de Linux pour les incultes!). Cependant, à l’inverse de Mercurial, il ne propose pas par défaut un serveur web pour naviguer dans les sources et les versions. Il y a bien des CGIs (gitweb et autres) pour combler ce manque mais ils sont tous trop lourds et complexes à mettre en oeuvre à mon goût.

Comme je désire avoir un moyen simple de naviguer (en lecture seule) dans plusieurs dépôts git sur mon serveur, j’ai décidé de coder mon propre outil : PyGitWeb.

Technologie

J’avais le choix de coder mon outil en PHP, Perl, Ruby ou Python et c’est ce dernier que j’ai choisit. Le serveur http est Lighttpd qui appelle l’interpréteur Python.

Fonctionnalités désirées

L’objectif d’avoir une page web (http://server/git/ par exemple) qui permet d’afficher tous les dépôts présents sur le serveur. On doit ensuite pouvoir aller consulter les commits, les versions, et les diffs/patchs. Pour finir, j’ajouterai une génération des tarballs pour chaque version.

Après 2 heures de réflexion, voici une ébauche (cliquez sur l’image pour agrandir) :

PyGitWeb

PyGitWeb

Sur cette ébauche, le programme va créer des instances Git pour chaque dépôts paramétrés. Il affiche une liste des dépôts et leur dernier commit. Je dois maintenant ajouter la gestion des liens et de la méthode GET pour le programme (pour passer les paramètres via l’URL). Aussi, la page est actuellement au format texte et il faut que je bascule au format xhtml.

QRQVB : Protocole TCP (1/2)

Aldevar, 02/02/2010 | Source: Alain Devarieux (aldevar)

Nouvelle QRQVB et pas des moindres, le protocole TCP (Transmission Control Protocol, Protocole de Contrôle de Transmission).  Comme son petit frère UDP, TCP se situe en couche 4 du modèle OSI.

Caractéristique de TCP

TCP est bien plus compliqué qu’UDP examiné au chapitre précédent. Il apporte en contrepartie des services beaucoup plus élaborés.

  • TCP contient un mécanisme pour assurer le bon acheminement des données. Cette possibilité est absolument indispensable dès lors que les applications doivent transmettre de gros volumes de données de façon fiable. Cette fonction est assurée par un mécanisme d’acquittement (ou accusé de réception). Les paquets de données sont acquittés de bout en bout et non de point à point. C’est à dire que ce sont les machines sources et machines de destinations qui s’occupent de cela et non les routeurs qui se situent entre les 2.
  • Le protocole TCP permet l’établissement d’un circuit virtuel entre les 2 machines qui échangent de l’information (Voir a ce propos le commentaire de Guizmo.7). On dit aussi que TCP  fonctionne en mode connecté (par opposition à UDP qui est en mode non connecté). En pratique, l’une des 2 machine doit effectuer un appel que l’autre doit accepter. S’en suit une discutions afin d’établir certains paramètres de communication. Une fois les préliminaires terminés, les protocoles informent les applications respectives que la connexion est établie et que le transfert peut débuter. Durant le transfert, le dialogue entre les protocoles continue, pour vérifier le bon acheminement des données.
  • TCP a la capacité de mémoriser les données. Les paquets pouvant prendre chacun un chemin différent pour arriver à destination, il arrive que ceux ci n’arrivent pas dans le bon ordre. Grâce à cette capacité de mémorisation, TCP garde les paquets un certains temps et les reconstitue lorsqu’ils sont tous arrivés afin de présenter les données à l’application.
  • TCP simule une connexion en « full duplex ». Pour chacune des 2 machines en connexion, l’opération qui consiste à lire des données peut s’effectuer indépendamment de celle qui consiste à en écrire.

Entête TCP

L’entête TCP est codé sur 20 octets hors options.

  • Port Source (16 bits): Port utilisé par l’application sur la machine source.
  • Port Destination (16 bits): Port de destination.
  • Numéro d’ordre (32 bits): Correspond au numéro du paquet. Cette valeur permet de situer à quel endroit du flux de données le paquet, qui est arrivé, doit se situer par rapport aux autres paquets.
  • Numéro d’accusé de réception (32 bits): Acquittement pour les paquets reçus. Cette valeur signale le prochain numéro de paquet attendu. Par exemple, si il vaut 1500, cela signifie que tous les datagrammes <1500 ont été reçus
  • Offset (4 bits): Le champ Offset est codé sur 4 bits et définit le nombre de mots de 32 bits dans l’entête TCP. Ce champ indique donc où les données commencent.
  • Réservé (6 bits): Champ inutilisé actuellement. Il était à l’origine prévu pour l’avenir. On peut dire aujourd’hui que ce champ restera vide.
  • Drapeaux (flags) (6×1 bit): Les drapeaux représentent des informations supplémentaires :
    URG: si ce drapeau est à 1 le paquet doit être traité de façon urgente.
    ACK: si ce drapeau est à 1 le paquet est un accusé de réception.
    PSH (PUSH): si ce drapeau est à 1, le paquet fonctionne suivant la méthode PUSH.
    RST: si ce drapeau est à 1, la connexion est réinitialisée.
    SYN: Le Flag TCP SYN indique une demande d’établissement de connexion.
    FIN: si ce drapeau est à 1 la connexion s’interrompt.
  • Fenêtre (16 bits): Champ permettant de connaître le nombre d’octets que le récepteur souhaite recevoir sans envoyer d’accusé de réception.
  • Somme de contrôle (Checksum ou CRC): La somme de contrôle est réalisée en faisant la somme des champs de données de l’en-tête, afin de pouvoir vérifier l’intégrité de l’en-tête
  • Pointeur d’urgence (16 bits): Indique le numéro d’ordre à partir duquel l’information devient urgente.

Établissement d’une connexion


Une ouverture de connexion TCP s’effectue en 3 temps.

L’émetteur du premier paquet doit avoir connaissance du couple IP : Port de l’application de la machine réceptrice (par exemple, on contact un serveur HTTP sur le port 80 qui lui est dédié). L’émetteur de ce premier paquet est à l’origine de l’établissement du circuit virtuel. C’est une attitude qualifiée de « cliente« .

Le récepteur du premier paquet accepte l’établissement de la connexion, ce qui suppose qu’il était prêt à le faire avant que le client en prenne l’initiative. C’est une attitude de « serveur« .

Le client envoie un segment comportant le drapeau SYN à 1. Le serveur répond avec sa propre séquence (SYN = 1) mais il doit aussi acquitter le paquet précédent, ce qu’il fait avec ACK. Le client répond alors avec un acquittement de la séquence du serveur (ACK = 1).

Une fois achevée cette phase appelée « Three-way handshake », les 2 applications sont en mesure d’échanger des données.

Conclusion

Voilà pour une première partie sur TCP. La seconde partie permettra de voir comment fonctionne la clôture d’une connexion ainsi que l’acquittement des paquets durant les transferts de données.  TCP est bien plus compliquer à aborder qu’UDP et c’est pourquoi je préfère le faire en 2 parties. J’essaierai d’ajouter dans la seconde partie quelques captures de trames afin d’illustrer ceci plus clairement. N’hésitez pas à laisser des commentaires si certaines notions vous paraissent mal expliquées ou trop survolées dans ce billet.

Au fait, bonne année 2010 !

Mathieu, 31/01/2010 | Source: mat2057

Il ne me reste que quelques heures pour vous souhaiter une très bonne année 2010 avant de passer pour un idiot ensuite… Comment ça, je passe déjà pour un idiot ? Tant pis. Autrement, je pense que le rythme de publication des billets ne va pas augmenter cette année. Entre ma thèse, l’enseignement et le blog [...]

Sonata : Recherche sur Wikipédia en français

WeedFast, 27/01/2010 | Source: UbunBloX

Utilisant depuis peu Sonata ( qui pour rappel est une interface graphique à MPD ), j’ai eu une désagréable surprise. Rien de bien grave mais la fonction de recherche d’informations sur les artistes pointe automatiquement vers le site anglophone de Wikipédia. Vous avez sûrement compris : Une recherche sur http://fr.wikipedia.org/ est bien plus adéquate !

Ayant un peu de temps à perdre, je me suis mis en tête de résoudre ce petit désagrément. Cette article n’a rien d’exceptionnel, il indique juste pas à pas la démarche effectuée par mes soins… Rien de bien difficile à vrai dire, mais cela prouve que les systèmes GNU/Linux possèdent bien des avantages :) .

How to :

Premièrement, il faut rechercher la location des fichiers concernant Sonata :

$ locate sonata
/home/gnu/.config/sonata
/home/gnu/.config/sonata/art_cache
/home/gnu/.config/sonata/sonatarc
/usr/bin/sonata
/usr/lib/python2.6/site-packages/sonata
/usr/lib/python2.6/site-packages/sonata/__init__.py
/usr/lib/python2.6/site-packages/sonata/__init__.pyc
/usr/lib/python2.6/site-packages/sonata/about.py
...

À priori, une recherche du terme “wikipédia” dans le répertoire /usr/lib/python2.6/site-packages/sonata doit suffire…

$ grep -r "wikipedia" /usr/lib/python2.6/site-packages/sonata
/usr/lib/python2.6/site-packages/sonata/main.py:            browser_not_loaded = not misc.browser_load("http://www.fr.wikipedia.org/wiki/Special:Search/" + urllib.quote(mpdh.get(self.songinfo, 'artist')), self.config.url_browser, self.window)
/usr/lib/python2.6/site-packages/sonata/main.py:            browser_not_loaded = not misc.browser_load("http://www.fr.wikipedia.org/wiki/Special:Search/" + urllib.quote(mpdh.get(self.songinfo, 'album')), self.config.url_browser, self.window)
...

Bingo ! Le terme “wikipedia” est bien présent dans le fichier main.py, il ne reste plus qu’à le modifier :

# nano /usr/lib/python2.6/site-packages/sonata/main.py
def on_link_click(self, type):
browser_not_loaded = False
if type == 'artist':
browser_not_loaded = not misc.browser_load("http://www.fr.wikipedia.org/wiki/Special:Search/" + urllib.quote(mpdh.get(self.songinfo, 'artist')), self.config.url_browser, self.window)
elif type == 'album':
browser_not_loaded = not misc.browser_load("http://www.fr.wikipedia.org/wiki/Special:Search/" + urllib.quote(mpdh.get(self.songinfo, 'album')), self.config.url_browser, self.window)

Astuce : Pour effectuer une recherche avec nano appuyez sur les touches Ctrl + H

Sauvegarde du fichier et un petit test : Ça fonctionne :) .

Pour finir, voici la version utilisée de Sonata sur mon Archlinux :

$ yaourt -Si sonata
Dépôt                 : extra
Nom                   : sonata
Version               : 1.6.2.1-1
URL                   : http://sonata.berlios.de/
Licences              : GPL3
Groupes               : --
Fournit               : --
Dépend de             : pygtk  python-mpd
Dépendances opt.      : gnome-python-extras: Enhanced system tray support
                        tagpy: Metadata editing support
                        zsi: Lyrics fetching support
                        dbus-python: Various extra functionality (e.g.
                        multimedia keys support)
Est en conflit avec   : --
Remplace              : --
A télécharger         : 503,11 K
Taille (installé)     : 1976,00 K
Paqueteur             : Andrea Scarpino
Architecture          : i686
Compilé le            : dim. 04 oct. 2009 15:24:15 CEST
somme MD5             : 3540c1c796a3457028fbe672c2e9f623
Description           : Elegant GTK+ music client for MPD

Liens :

Linuxmint-fr fait peau neuve

Aldevar, 24/01/2010 | Source: Alain Devarieux (aldevar)

Après une semaine de travaux, le site de la communauté francophone de LinuxMint réouvre avec une toute nouvelle interface. Dorénavant propulsé par Joomla, le site met en avant l’esprit communautaire et social avec notamment la possibilité d’ajouter des utilisateurs en tant qu’amis, ou encore de rejoindre des groupes d’utilisateurs comme les groupes KDE, Gnome, France, Belgique etc…

S’ajoute à ça un système permettant de donner des points aux utilisateurs sur le forum.

Je vous invite donc tous à vous y rendre, ne serait-ce que pour tester toutes ces nouvelles fonctionnalités peu communes sur les sites des communautés des différentes distributions.

www.linuxmint-fr.org