Planète des utilisateurs Debian

Grégory Colpart: JCE non limitées sous Debian

jeu, 02 jui 2009 21:45:56 +0000

Les packages Debian de Java n’intègrent pas de mécanisme pour faciliter l’utilisation des versions non limitées des JCE (Java Cryptography Extension), utiles pour avoir des fonctions de chiffrement dites « fortes » (#466675). L’idée est de créer des diversions locales pour conserver les versions non limitées, même en cas de mise-à-jour :

# dpkg-divert --divert /usr/share/doc/sun-java6-jre/US_export_policy.jar.ori \
 --rename /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/security/US_export_policy.jar
Adding `local diversion of /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/security/US_export_policy.jar
 to /usr/share/doc/sun-java6-jre/US_export_policy.jar.ori'
# dpkg-divert --divert /usr/share/doc/sun-java6-jre/local_policy.jar.ori \
--rename /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/security/local_policy.jar
Adding `local diversion of /usr/lib/jvm/java-6-sun-1.6.0.12/jre/lib/security/local_policy.jar
to /usr/share/doc/sun-java6-jre/local_policy.jar.ori'

Attention, bien garder à l’esprit que si une faille de sécurité survient, il faudra mettre à jour manuellement ces fichiers.

Carl Chenet: Reportbug 4.5

mar, 30 jun 2009 17:15:34 +0000

En cette splendide fin de mois de juin, le Reportbug nouveau est arrivé.

La version 4.5 est sortie le 29 juin avec son lot de nouveautés. L’auto-configuration propose désormais d’ajouter un serveur mandataire et l’interface en GTK2 continue de s’améliorer. En coulisse, beaucoup d’améliorations pour rendre l’application plus robuste suivi des habituels corrections de bugs. Merci encore à Sandro Tosi pour son gros travail de triage de bugs et d’ajouts de nos patchs à Reportbug.

Reportbug est toujours dans une bonne dynamique et s’évertue à rendre à la fois plus simple la saisie d’un nouveau rapport de bug pour l’utilisateur et plus efficace l’identification du bug pour les développeurs qui traitent les rapports de bugs.

Nous sommes friands des rapports de bugs sur Reportbug lui-même, n’hésitez pas à nous faire parvenir vos rapports de bugs/demandes de nouvelles fonctionnalités.

Ne vous laissez pas décourager par la première saisie de bug qui peut être relativement longue (15-20mn), vous contribuez ainsi à améliorer Debian. Et les prochaines saisies seront beaucoup plus rapides

Benoit Peccatte: En vrac (24)

mar, 30 jun 2009 12:42:00 +0000

Niveau :
Résumé : perl -077pe ; ps kstart_time ; stty -echo ; expr ; bc -l ; tar c - | ssh tar x -

Petite pause.

Appliquer une expression régulière en une seule fois sur tout un fichier (comme s’il ne faisait qu’une ligne) :

$ perl -0777pe 's/expression/remplacement/'

Connaitre les processus qui sont lancés “en ce moment”, par exemple pendant un script d’installation :

# listes les processus par date de création toutes les 2s
$  watch "ps kstart_time aux |tail"

Éviter d’afficher les mots de passe lorsque vous les demandez à l’utilisateur dans vos scripts shell :

$ stty -echo
$ read password
$ stty echo

Faire un calcul en ligne de commande (installé partout, même sur les vieux unix) :

$ expr 1 + 5

Faire un calcul en ligne de commande, mais en mieux :

# à mettre dans votre bashrc de préférence
$ bcl() { echo "scale=2; $@" | bc -l ; }
$ bcl 1+2

Tar over ssh (rsync quoi) :

$ tar cf - /repertoire | ssh mamachine.net "cd /destination && tar xvf -"

Sylvain Derosiaux: Gérer ses templates pour Vim sans fichiers externes

jeu, 25 jun 2009 10:50:45 +0000

Suite à un billet posté sur le site Informatique et liberté évoquant une solution originale pour gérer ses templates avec Vim, j’ai décidé d’améliorer un peu la technique en utilisant la puissance de ce superbe éditeur combinée à celle de sed.

Habituellement, pour chaque template, nous créons un fichier externe placé dans notre dossier personnel ~/.vim. Prenons l’exemple d’un template HTML dans ~/.vim/templates/html que l’on appellerait de cette manière dans notre fichier de configuration ~/.vimrc :

autocmd BufNewFile *.html 0r ~/.vim/templates/html

Logiciels utilisés :

Vim 7.2
GNU Sed 4.2

Le but du jeu est de centraliser toute notre configuration dans notre ~/.vimrc et donc d’y inclure nos templates. Le seul moyen, à ma connaissance, est de mettre ceux-ci en commentaires afin qu’ils n’interfèrent pas avec le reste de la configuration, il ne restera plus alors qu’à trouver le template adéquat, pour cela on passera par des marqueurs de début et de fin de template, voici donc ma solution :

" BEGIN HTML
" <html>
"     <head>
"         <title>Hello gnusquad !</title>
"     </head>
" </html>
" END HTML

autocmd BufNewFile *.html call Template('HTML')

function! Template(type)
    exe "0r !sed -n '/^\"\\s*BEGIN " . a:type . "$/,/^\"\\s*END " . a:type . "$/ {s///;/^$/d;s/^\" //;p}' $MYVIMRC"
    echo '--> INFO : Template ' . a:type . ' charge  --'
endfunction

Nous retrouvons donc en première partie le template mis en commentaire et délimité par les marqueurs « BEGIN HTML » et « END HTML », la deuxième partie appelle la fonction « Template » avec en paramètre « HTML » lorsque l’on crée un nouveau fichier ayant son nom correspondant au motif « *.html », la troisième et dernière partie contient la fonction « Template » proprement dite qui prend donc un paramètre servant à délimiter le template, on y trouve une jolie ligne de sed qui paraît obscure à première vue mais qui est très simple : on localise et ne traite que la partie contenue entre « BEGIN xxx » et « END xxx », on supprime ces deux lignes puis les lignes vides puis on décommente le template, le tout étant inséré dans le buffer courant.

Vous aurez donc compris qu’il est très simple d’ajouter de nouveaux templates : il suffit juste que le paramètre passé à la fonction « Template » corresponde à la partie présente après « BEGIN » et « END » de votre template.

Erwan Briand: CodingTeam 0.9.1 est disponible !

mer, 24 jun 2009 22:33:00 +0000

J'ai publié aujourd'hui (enfin, hier, déjà) la troisième release de la forge CodingTeam, soit la version 0.9.1. CodingTeam est une forge logicielle libre écrite en PHP. Après un peu plus de 6 mois, donc, cette nouvelle version vient remplacer la précédente 0.9 en apportant pas mal de nouveautés, d'une réécriture complète de toutes les vues (pour intégrer un léger moteur de template basé sur la syntaxe alternative de PHP) à la possibilité de rendre un projet privé.

Parmi les choses attendues et bien au rendez-vous, on trouvera notamment les hooks post-commits permettant de marquer automatiquement un rapport de bug comme résolu, une nouvelle timeline, la possibilité pour les anonymes de rapporter un bug, l'ajout de la notion de milestone en plus de la notion de version (afin de séparer la notion de version dans laquelle sera corrigé le problème de celle qui est affectée par le problème) et donc nouvelle manière de générer la roadmap, les portes-documents des utilisateurs (afin d'uploader des fichiers comme des images qu'ils pourront utiliser dans la documentation de leurs projets), la possibilité de rendre une forge privée (obligation de s'identifier pour afficher une page) et pas mal de changements sur l'explorateur de sources Subversion.

On notera donc que tout ce que les utilisateurs ont demandé a été intégré dans cette nouvelle version. CodingTeam, désormais utilisée par plus d'un millier de personnes sur CodingTeam.net et en interne par quelques entreprises, est donc de plus en plus riche en fonctionnalités et reste toujours distribué sous la licence AGPL (dans sa version 3). J'insiste sur ce point car je remarque que les gens continuent d'utiliser des forges non-libres sans se rendre compte du problème. Avec CodingTeam (ou CodingTeam.net si vous ne voulez pas installer de forge chez vous !), vous avez une solution libre, ce que ne sont pas capables de vous offrir plusieurs forges pourtant très utilisées par les développeurs de logiciel libre. Développer un logiciel libre en utilisant des outils non-libres est bien entendu tout à fait possible, oui. Mais c'est surtout incohérent et proche de l'escroquerie intellectuelle.

Ensuite, et pour revenir dans le sujet initial, les adeptes de Jabber seront heureux de remarquer que l'authentification via XMPP (XEP-0070) est désormais possible. Plus qu'une réelle fonctionnalité, c'est une preuve de concept de la possibilité d'étendre la classe BaseSession afin de gérer l'authentification sur la forge autrement que par le couple identifiant/mot de passe habituel. Toutefois, cette fonctionnalité expérimentale peut être activée sur une forge basée sur CodingTeam dès maintenant. L'authentification via un compte Jabber, les salons de conversations Jabber, la présence et l'avatar du compte Jabber… On ne peut pas nier que CodingTeam intègre beaucoup de fonctionnalités liées à Jabber/XMPP. Et sûrement plus que les autres forges.

Toujours sur le point de vue développeur, la classe de gestion des erreurs a été étendue afin de gérer l'affichage d'un traceback, l'archivage des erreurs, la gestion de toutes les erreurs (même des erreurs fatales PHP)… Bref, elle aide bien en situation de développement (mais on peut plus ou moins lui fermer le clapet en situation de production).

L'interface d'administration a aussi été améliorée puisqu'on peut désormais vider le cache facilement ou même éditer toutes les données de base de la forge (liste des licences, catégories…).

Et bien entendu, CodingTeam.net a été mis à jour. N'hésitez pas à y ajouter votre projet ou à explorer la liste des 276 projets. Si vous voulez installer ou tester cette nouvelle version de la forge logicielle libre CodingTeam, c'est par ici que ça se passe.

Il n'y a donc pas grand chose à ajouter, si ce n'est que la 0.9.2 devrait suivre plus ou moins prochainement avec des choses vraiment très sympathiques. Et si vous ne le connaissez toujours pas, jetez un œil au site de CodingTeam : codingteam.org !

Benoit Peccatte: Comptes ldap (4)

mar, 23 jun 2009 21:43:00 +0000

Niveau :
Résumé :

Suite de la formidable série :

Et après les comptes ?

Il est aussi possible d’utiliser libnss-ldap pour autre chose que pour les comptes utilisateurs. La bibliothèque NSS étant une bibliothèque générique de résolution de nom, il est possible d’utiliser le ldap pour :

les groupes (attention pas de login pour newrp à travers pam de prévu)
les noms de machine
et d’autres qui ne pas très intéressants pour l’instant …

Pour cela, rien de plus facile, tout est déjà fait, il suffit de modifier la ligne correspondante dans /etc/nsswitch.conf et de commencer à peupler le LDAP.

Un groupe est définit comme suit :

objectClass: posixGroup
cn: mongroupe
description: goupe a moi
gidNumber: 1000
memberUid: peck
memberUid: amiami

Notez que la description est optionnelle et que les membres sont décrits par uid. Le userPassword est aussi disponible mais n’est pas utilisable actuellement pour les groupes du système.

Exemple de machine (plus besoin de DNS local ;-) :

objectClass: ipHost
cn: mamachine
ipNetworkNumber: 1.2.3.4

S’adapter à l’existant

Il est possible que vous ayez à gérer un serveur ldap existant avec ses comptes et son propre schéma (active directory ?). C’est pourquoi il existe des options de mapping dans la configuration de pam_ldap et nss_ldap.

Ces options sont assez simples, il s’agit de reparcourir votre schéma et pour chaque entrée nécessaire pour le système, expliquer au fichier de configuration quel est le nom de l’attribut ou de la classe que vous utilisez sur le ldap. Ceci est à faire une fois pour nss et une fois pour pam.

Les commandes sont :

nss_map_objectclass : changer une classe utilisée par libnss-ldap
nss_map_attribute : changer un attribut utilisé par libnss-ldap
nss_default_attribute_value : donner une valeur par défaut à un attribut (pratique pour le shell par exemple)
pam_login_attribute : change l’attribut servant à matcher le login pendant l’authentification
Il n’est pas possible de changer l’attribut utilisé par pam pour le mot de passe (normal c’est le serveur ldap qui gère).

Les classes modifiables (en restant dals le domaine utilisateur/groupe) sont

posixAccount : utilisateur ayant un compte unix
shadowAccount : utilisateur ayant un système avancé de gestion de mot de passe
posixGroup: groupe unix

Les attributs modifiables sont : uidNumber, gidNumber, gecos, homeDirectory, loginShell, shadowLastChange, shadowMin, shadowMax, shadowWarning, shadowInactive, shadowExpire, shadowFlag, memberUid

Plus de détails (et plus de clesses) dans la RFC 2307.

La configuration fournie avec le paquet donne des exemples pour les différents systèmes existants (aix, microsoft …)

libnss-ldapd

Maintenant vous pourriez avoir d’autres problèmes, comme la performance ou quelques hoquets du réseau qui coupent des connexions. La solution traditionnelle pour cela est d’installer nscd qui fera un cache et vous évitera ces problèmes (et peut en créer d’autres puisque c’est un cache).

Mais il existe une autre solution : libnss-ldapd, notez bien le ‘d’ final. C’est une version de libnss-ldap réécrite pour parler à un démon qui est le seul à parler avec le serveur ldap. Ça a l’avantage de mutualiser les requêtes dans une seule connexion et donc d’éviter pas mal de problèmes, surtout en cas de forte charge.

Petit inconvénient pour les puristes, ça ouvre une faille potentielle (inconnue à ce jour) pour un utilisateur qui voudrait devenir administrateur via le serveur ldap, puisque ce n’est plus le noyau qui vérifie les droits root d’administration mais le démon.

Le démon se configure dans /etc/nss-ldapd.conf. La syntaxe est la même que pour pam_ldap et libnss-ldap, le contenu ne doit pas changer.

Le démon est du coup assez important, il faut vérifier qu’il est lancé (monitorer toussa …). Il s’appelle nslcd.

Sécurité et performances

Si vous avez beaucoup d’utilisateurs vous pouvez vouloir restreindre les recherches.
Si vous avez des utilisateurs qui ne doivent pas tous avoir accès au système, vous pouvez vouloir restreindre les recherches.

C’est pourquoi nss et pam fournissent des directives pour réduire la taille des recherche et donc la liste des utilisateurs :

base : réduit l’accès à toutes les commandes LDAP à une seule branche
scope : indiquer si la recherche doit tester les sous branches ou non
nss_base_<map> : permet d’indiquer à ldap de se limiter à une requête pour un type donné de résolution, map peut valoir passwd, shadow ou group (ou hosts, services, networks, protocols, rpc, ethers, netmasks, bootparams, aliases ou netgroup). Exemple : nss_base_passwd ou=users,dc=linux-attitude,dc=fr?sub?uid>1000
pam_filter : permet de modifier la partir filtre pour pam (pas besoin de modifier le reste car il n’y a qu’une requête faite par pam). Exemple : pam_filter uid>1000

Benoit Peccatte: Comptes ldap (3)

dim, 21 jun 2009 15:08:00 +0000

Niveau :
Résumé : libmap-ldap ; passwd ; chsh ; chfn ; adduser

Désolé, j’ai oublié la suite de la série LDAP. On peut faire un peu mieux que la dernière fois.

Changer son mot de passe

Nous n’avons pas activé le changement de mot de passe. Pour cela, c’est assez simple, il suffit de modifier common-password (cela peut être ailleurs pour certaines distributions …) :

password   sufficient   pam_unix.so nullok obscure min=4 max=8 md5
password   sufficient   pam_ldap.so

Il faut aussi modifier /etc/pam_ldap.conf pour que pam ne modifie pas directement le mot de passe, mais utilise les fonctions de ldap prévues à cet effet. Cela permet qu’il ne soit pas stocké en clair, mais avec la méthode définie dans la configuration de ldap ({SSHA} par défaut).

# A ajouter dans /etc/pam_ldap.conf
pam_password exop

Et voilà vous pouvez tester la commande passwd. Mais vous constaterez qu’il y a quelque chose qui cloche. Si vous lancez la commande en root, l’ancien mot de passe vous est quand même demandé. C’est parce que vous n’avez pas les droits d’administrateur sur le ldap.

Pour remédier à cela, il vous faut un compte ldap qui a le droit de modifier le champ password des autres utilisateurs, par exemple l’administrateur ldap. Puis renseignez ce compte dans pam_ldap.conf :

# /etc/pam_ldap.conf
# Il faudra stocker le mot de passe correspondant en clair dans /etc/pam_ldap.secret
# Ce fichier doit appartenir à root et être en mode 600
rootbinddn cn=admin,dc=linux-attitude,dc=fr

Ça y est vous êtes prêts.

chsh, chfn, adduser

Les utilisateurs ont le droit de changer leur shell ainsi que leurs informations personnelles. Pour cela ils ont les commandes chsh et chfn.

Malheureusement ces commandes manipulent /etc/passwd. Le paquet libpam-ldap fournit des script pour remplacer ces commandes, mais ils sont un peu basiques et nécessitent libnet-ldap-perl (Net::LDAP). Vous pouvez vous baser dessus pour faire les votres si vous pensez que ces fonctionnalités sont indispensables pour vos utilisateurs. On les trouve dans /usr/share/doc/libpam-ldap/examples/ . un certain nombre de paramètres sont codés en dur et peu de vérifications d’erreur sont faites.

Si vous modifiez vos binaires dans /usr/bin sur debian, faites attention la prochaine mise à jour risque de les remplacer. Pour éviter ce problème, il existe la commande dpkg-divert :

# On fait croire aux paquets qu'ils installent /usr/bin/chfn alors qu'ils installent en réalité /usr/bin/chfn.old
$ dpkg-divert --add --rename --divert /usr/bin/chfn.old /usr/bin/chfn
# voila, vous pouvez maintenant remplacer /usr/bin/chfn

Autre problème, adduser ne comprend pas non plus le ldap. Ici le problème est le même mais la solution un peu meilleure. Un paquet ldapscripts est disponible et il contient des commandes comme ldapadduser pour vous faciliter la création d’utilisateurs ldap. Les commandes sont configurées dans /etc/ldapscripts/ .

Tout ceci pourrait s’améliorer dans de prochaines versions, un patch a l’air en cours de développement pour le paquet shadow (qui contient ces outils) qui utiliserait la libnss pour effectuer ces actions. Les commandes fonctionneraient donc directement.

Quelques remarques

Depuis que nous avons des vrais comptes systèmes basés sur le ldap nous sommes contents. Mais quelques petites choses tout de même :

Gardez le compte root sur le système, on ne sait jamais, si le ldap tombe, vous seriez bien embêtés
Faites attentions aux droits dans le ldap, ils impactent les fonctionnalités des commandes systèmes (droit de lister les autres utilisateurs par exemple)
Avec un serveur distant, le ldap devient une forme de NIS
Vous pouvez utilisez la réplication ldap pour résister aux crash
Vous pouvez toujours garder une mot de passe local au cas où le ldap ne marche pas (pam fait les 2)
Vous pouvez vous connecter à un controleur de domaine windows
Si vous avez de problèmes les logs d’authentification sont dans /var/log/auth.log
Vous pouvez vouloir ne mettre en place que l’authentification via pam et ne pas utiliser libnss. Ce cas correspond à des utilisateurs virtuels (comme pour le ftp) qui n’utiliseront pas alors de vrai compte sur le système.

Christophe Nowicki: Héberger son propre fournisseur d’identité OpenID

jeu, 11 jun 2009 06:31:37 +0000

Présentation d’OpenID

OpenID est un système d’authentification décentralisé qui permet l’authentification unique, ainsi que le partage d’attributs. Il permet à un utilisateur de s’authentifier auprès de plusieurs sites compatibles sans avoir à retenir un identifiant pour chacun d’eux mais en utilisant à chaque fois un unique identifiant OpenID.

Cette identifiant se presente sous forme d’URL, celle-ci contient l’adresse du serveur d’identification et le nom de l’utilisateur : http://id.csquad.org/identity/cscm

Je trouve ce système d’identification pratique, car je change de poste de travail ( portable, station de travail, etc…) et je n’ai pas trouvé de solution de synchronisation de mot de passe convaincante.

Pourquoi héberger son propre fournisseur d’identité?

Héberger son propre serveur d’identité vous permet de gérer votre identité numérique.
C’est à dire, déterminer les informations personnelles que vous fournissez au service que vous utilisez.
Héberger ce type de service sur son propre serveur vous garantit que vous avez la main sur vos données personnelles.
Cela vous garantit que :

les autres fournisseurs d’identité n’exploitent pas vos données personnelles ;
votre compte restera toujours actif, en effet rien ne vous garantit qu’un fournisseur d’identité ne cesse son activité ;
une liberté en matière de politique de mot de passe / choix de l’identifiant / nombre de comptes, etc…

Présentation de Community-ID

Community-ID est une application PHP, compatible avec les spécifications OpenID 2.0 sous licence BSD.
Il propose les fonctionnalités suivantes :

comptes d’utilisateurs ;
données personnelles ;
sites fédérés ;
historique ;

Configuration de Community-ID sur un serveur Debian GNU/Linux

Voici la procédure d’installation de la version 1.0 de Community-ID sur une distribution Debian GNU/Linux version “Lenny”.

Vous avez besoin :

d’un nom de domaine ;
d’un serveur Apache avec le support de PHP 5 et le module rewrite ;
d’une base de données MySQL avec phpMyAdmin ;

Configuration de MySQL

A l’aide de phpMyAdmin, créer un utilisateur communityid et créer une base portant le même nom en lui donnant tous les privilèges sur cette base.

Installation dépendances

Le programme nécessite les dépendances suivantes :
# apt-get install apache2-mpm-prefork libapache2-mod-php5 php5-mysql php5-gd php5-gmp

Installation du programme

Vous pouvez télécharger le programme sur SourceForge : Community-ID.
et extraire le fichier tar.gz dans le répertoire /var/www :

# cd /var/www # wget http://freefr.dl.sourceforge.net/sourceforge/communityid/cid-1.0.0.tar.gz # tar xzf cid-1.0.0.tar.gz # chown www-data: -R communityid

Vous devez ensuite configurer le site web pour Apache en mettant le contenu suivant dans le fichier /etc/apache2/sites-available/communityid :

<VirtualHost *:80> ServerName id.nom_de_domaine ErrorLog /var/log/apache2/id.nom_de_domaine/error.log CustomLog /var/log/apache2/id.nom_de_domaine/access.log common DocumentRoot /var/www/communityid/webdir </VirtualHost>
Il faut créer le répertoire pour les logs du site, activer le site et le module rewrite dans Apache :
# mkdir /var/log/apache2/id.nom_de_domaine/ # a2enmod rewrite Enabling module rewrite. Run '/etc/init.d/apache2 restart' to activate new configuration! # a2ensite communityid Enabling site communityid. Run '/etc/init.d/apache2 reload' to activate new configuration! # /etc/init.d/apache2 restart

Configuration

Vous pouvez ensuite pointer votre navigateur sur l’adresse de votre site : http://id.nom_de_domaine/
La procédure d’installation vous demande les informations de connexion à la base de données pour configurer celle-ci.
Une fois la base de données crée, vous pouvez vous connecter à l’interface à l’aide de l’utilisateur admin et du mot de passe admin, pour vous créer un compte.

Liste des services compatibles

Voici la liste des quelques services que j’utilise avec mon serveur OpenID :

Il existe de nombreux services compatibles avec ce système d’authentification, référencés par l’annuaire OpenID Directory.

Les principaux systèmes de blog proposent le support d’OpenID sous forme de plugin :

Si vous avez réussi à installer votre fournisseur d’identité, vous pouvez vous connecter sur mon blog pour me laisser un commentaire

Carl Chenet: RMLL 2009 et retour sur Pycon FR

lun, 08 jun 2009 17:26:52 +0000

Comme indiqué ci-dessus, je serai aux Rencontres Mondiales du Logiciel Libre (RMLL) à Nantes, le 9 juillet 2009 pour une conférence sous la forme d’un retour d’expérience sur mon projet Bélier, avec une large part accordée à la démarche qualité dans le développement d’un logiciel en Python. Sera également abordé l’importance de l’empaquetage qui me permettra de mettre en avant mes récents travaux au sein de Debian. Je serai également une grande partie de la journée sur le stand de l’Association Francophone Python (AFPY).

Si vous êtes un contributeur/DD/DM du projet Debian, n’hésitez pas à venir causer avec moi ! Et la même chose bien sûr pour toutes les personnes intéressées par Python.

Rapide retour sur Pycon FR 2009

Les journées Pycon FR 2009, conférences francophones autour du langage Python, ont eu lieu le dernier week-end de mai à la Cité des Sciences et de l’Industrie à Paris. Les conférences se sont enchaînées, abordant un large éventail de sujets. J’ai présenté moi-même une conférence sur la mise en place d’une démarche qualité au sein d’un développement en Python ainsi qu’un “lightning talk” sur mon projet Bélier. L’organisation a été parfaite et les feedbacks ont été très positifs.

Je pense présenter l’année prochaine une conférence sur Python et Debian abordant l’utilisation du langage Python dans Debian et comment un développeur utilisant Python peut contribuer à Debian.

à bientôt !

Erwan Briand: Patate \o/

lun, 08 jun 2009 15:39:00 +0000

Biquette et moi sommes heureux de vous présenter une nouvelle venue, la dénommée Patate !

Patate est un petit ordinateur portable MSI Wind U100 (027FR pour la référence exacte) tout noir et tout top cool. Pour ceux qui veulent savoir ce que la bête a sous le capot, c'est un processeur Intel Atom à 1.6GHz, un disque dur de 160Go, un gigot de RAM, un écran 10.2 pouces (avec donc une résolution de 1024x600), un lecteur de cartes qui marchera sans rien faire et une webcam (pratique pour les cam2cam coquines sur MSN, comme pensent sûrement actuellement plusieurs lecteurs)… L'ordinateur est aussi livré avec un CD de restauration et de sauvegarde de Windows XP (qui est d'ailleurs très utile sur un ordinateur sans lecteur CD) ainsi qu'une pré-installation d'XP. Le disque dur, après son formatage et son repartitionnement en bonne et due forme ne possède plus aucune trace de tout ça, donc le monde va bien et les oiseaux chantent (si si, tendez l'oreille). Comme il m'est arrivé quelques péripéties lors de la configuration de cette petite patate, je vais relater tout ça ici au cas où un autre que moi aurait un MSI Wind et ne s'en sortirait pas, il y aura donc des vrais bouts de technique dans ce billet ; désolé si ça choque.

L'installation en elle même s'est déroulée sans encombres via une clef usb contenant la netinstall de Debian testing (et d'ailleurs, j'écris ce billet depuis patate \o/). Par contre, au premier boot, il m'est arrivé un truc bizarre : /etc/fstab désignait le disque dur comme /dev/sdc alors que fdisk -l parlait bien de /dev/sda. J'ai dû être un peu distrait pendant l'installation parce que grub ne se lançait tout-bien que si je bootais sur la clef usb (/dev/sda, en l'occurrence ; je sais que c'est un peu confus mais il faut quand même suivre un minimum). Une réinstallation de grub et une modification du fichier /etc/fstab plus tard, la machine démarrait tranquillement.

Ensuite, vient le problème de la carte wifi. En effet, selon les modèles et lieux de commercialisation de l'ordinateur, la puce wifi n'est pas la même. La plus courante à l'air d'être une Realtek RTL8187SE et à ce qu'on peut lire sur le net, c'est aussi la plus chiante. Le mien est équipé d'une Ralink RT2860 (alors que le commerçant m'avait pourtant annoncé l'autre). Et il y aurait même des modèles avec un chipset Atheros (ça aurait été idéal). En tout cas, avec ma carte et Debian, y a pas 36 solutions, il faut le kernel 2.6.29 si on veut bénéficier du pilote fourni avec le noyau (rt2860sta) qui marche tout simplement super. Et puis, ça ne peut pas être un mal d'être à jour, c'est que le 2.6.26 commence se faire vieux quand même. Petit bémol, le driver dépendrait d'un firmware non-libre (comme le dit ce rapport de bug). Ralink, bouh ! Sinon, on peut aussi se l'installer via module-assistant, mais je ne vais pas détailler tout ça ici. Me voilà donc de nouveau obligé d'utiliser du non-libre pour mon matériel. /o\

Ensuite, j'ai opté pour m'installer un cocktail personnel avec du SLiM, du Openbox, du xfce4-terminal, du xfce4-panel… Mais tout ne s'arrête pas là. Il y a aussi moyen de s'amuser avec la carte graphique. En lançant glxgears, on obtient environ 400 FPS. Eh bien, on peut passer à environ 900 FPS en un claquement de doigt, satisfaisant par la même les gamerz nomades (chambre, salon, toilettes) que nous sommes tous (même toi, là bas, au fond). Pour cela, j'ai honteusement pompé sur le net (des tutos, des rapports de bugs, des sujets de forum) et j'ai fait un joli mix que voici.

D'abord, dans le xorg.conf :

Section "Device"
    Identifier	"Configured Video Device"
    Option		"AccelMethod"			"xaa"
    Option		"MigrationHeuristic"		"greedy"
    Option		"DRI"				"true"
    Option		"FramebufferCompression"	"on"
    Option		"UseFBDev"			"true"
    Option		"RenderAccel"			"true"
    Option		"XAANoOffscreenPixmaps"		"true"
    Option		"Tiling"			"on"
EndSection

Et puis au final, dans le .bashrc :

export INTEL_BATCH=1

Bon, par contre, rien de dingue, j'oscille entre 5 et 50 FPS selon les jeux et certains (comme gl-117) refusent tout simplement de se lancer. Les malpropres. Notons aussi que pour le coup, j'ai un peu copié sans chercher à comprendre, c'est que c'est bien obscur toutes ces bêtises d'accélération graphique.

Le portable vient aussi avec une interface Bluetooth. J'ai d'ailleurs trouvé sur le net une bien bonne astuce pour utiliser tout ça facilement, la voici. Avant toute chose, il faut installer le paquet gnome-bluetooth et ensuite créer le fichier ./local/share/Thunar/sendto/gnome-obex-send-generic.dekstop. Ce fichier doit juste contenir ça :

[Desktop Entry]
Type=Application
Version=1.0
Encoding=UTF-8
Name=Bluetooth OBEX Recipient
Exec=/usr/bin/gnome-obex-send %f

Et hop, il y aura une nouvelle entrée au menu « Envoyer vers » de Thunar. Et on utilisera gnome-obex-server pour récupérer des fichiers transmis par le Bluetooth (chez moi, il se lance à l'ouverture de ma session).

Pour pouvoir utiliser les touches de gestion du son, il faut faire une petite manipulation de rien du tout avec xmodmap. Quand on utilise Openbox, il suffit d'ajouter « xmodmap /chemin/vers/votre/xmap » dans ~/.config/openbox/autostart.sh. Ce fichier xmap contiendra :

keycode 176 = XF86AudioRaiseVolume
keycode 174 = XF86AudioLowerVolume
keycode 160 = XF86AudioMute

Et il n'y a plus qu'à mettre à jour le ~/.config/openbox/rc.xml :

    <keybind key="XF86AudioRaiseVolume">
      <action name="Execute">
        <command>aumix -v+4</command>
      </action>
    </keybind>

    <keybind key="XF86AudioLowerVolume">
      <action name="Execute">
        <command>aumix -v-4</command>
      </action>
    </keybind>

    <keybind key="XF86AudioMute">
      <action name="Execute">
        <command>aumix -v0</command>
      </action>
    </keybind>

Voilà qui n'est déjà pas mal. Maintenant, sans transition, on va passer de la bidouille du dimanche à quelque chose de bien plus intéressant.

Étant d'un naturel paranoïaque, il ne m'a pas fallu en parler longtemps sur le net avant de me décider à chiffrer ma partition /home. Et en plus, c'est vraiment pas si compliqué que ça. On commence par installer le paquet cryptsetup. Avant toute chose, il peut être sympa de se faire un petit backup, j'ai par exemple créé un dossier /var/homebackup dans lequel j'ai copié /home/xbright. Après, on attaque les choses sérieuses (vérifiez que le module dm-crypt est chargé pour la suite). Et si vous avez un avertissement à propos d'un certain udevsettle manquant, pas de panique, c'est un bug. Enfin, pour bien comprendre mon exemple, dans mon cas, /home est sur /dev/sda5.

On commence par démonter notre partition :

umount /dev/sda5

Ensuite, on lance la création du chiffrage sur cette partition :

cryptsetup luksFormat /dev/sda5

Et puis, on va ouvrir tout ça :

cryptsetup luksOpen /dev/sda5 home

Et on va maintenant créer un système de fichier ext3 :

mke2fs -j /dev/mapper/home

À ce moment là, moi, j'ai restauré ma sauvegarde en trois étapes toutes simples :

mount -t ext3 /dev/mapper/home /mnt
cp -av /var/homebackup/xbright /mnt
umount /mnt

Et ensuite, dernière étape, il faut modifier deux fichiers, le premier, /etc/fstab, il s'agit de modifier la ligne concernant notre partition afin qu'elle ressemble à ça :

/dev/mapper/home    /home    ext3    defaults    1    2

Le dernier fichier à modifier est /etc/crypttab, auquel il suffira d'ajouter cette ligne :

home    /dev/sda5    none    luks

Un petit reboot et c'est bon. Il faudra juste entrer le mot de passe à chaque boot pour que la partition puisse être lue. Et puis, ça rassure le paranoïaque qui sommeille au fond de nous.

Et maintenant, les traditionnels screenshots pour montrer un peu à quoi ressemble la bestiole (attention, la taille de la police pourrait faire peur à certains qui se balladent sur le web en 16 pixels, parce que là, c'est moins que la moitié).

Benoit Peccatte: Comptes ldap (2)

sam, 06 jun 2009 15:20:00 +0000

Niveau :
Résumé : libpam-ldap

Hier nous avons créé un compte sur le ldap. Bien, mais on ne pouvait pas en faire grand chose. Il faut maintenant pouvoir se connecter. Il est théoriquement possible de tout faire avec libnss mais c’est à la fois plus difficile et moins fonctionnel qu’avec pam.

Comme vous le savez l’authentification sous linux se fait avec PAM. Nous allons donc utiliser un module dédié : libpam-ldap (cool le paquet porte le même nom).

LDAP

Cette fois ne nous force à utiliser aucun objectClass, mais comme il sait utiliser les attributs de la classe shadowAccount, on peut utiliser celle-ci pour se simplifier la vie.

Ajoutons le mot de passe à notre utilisateur. On crée le mot de passe LDAP à la main, mais par la suite vous verrez que ce n’est pas indispensable.

$ slappasswd -s test
{SSHA}l5X6sBFomfk3tk02HEMWK4YLep7pqZDk

On ajoute ce mot de passe à l’utilisateur déjà créé :

$ ldapmodify -x -D "cn=admin,dc=linux-attitude,dc=fr" -W
dn: uid=peck,ou=people,dc=linux-attitude,dc=fr
changetype: modify
add: userPassword
userPassword: {SSHA}l5X6sBFomfk3tk02HEMWK4YLep7pqZDk

Un test de connexion avec ldapsearch vous montrera que le mot de passe est bien pris en compte :

$ ldapsearch -x -D "uid=peck,ou=people,dc=linux-attitude,dc=fr" -w test "uid=peck"

PAM

Maintenant il faut expliquer gentiment à PAM d’aller faire son authentification en utilisant LDAP. Pour cela hop, configuration dans /etc/pam.d/common-*. Certaines distributions devront peut-être configurer chaque élément un par un : su, login, ssh …

# common-auth
# attention, le pam_unix devient sufficient
auth    sufficient    pam_unix.so nullok_secure nodelay
# use_first pass permet de ne demander qu'une fois les mot de passe pour les 2 modules
auth    sufficient    pam_ldap.so use_first_pass

# common-account
account    required    pam_unix.so
account    sufficient   pam_ldap.so

# common-session
session    required    pam_unix.so
session    optional    pam_ldap.so

Maintenant attaquons-nous au fichier de configuration proprement dit : /etc/pam_ldap.conf. En voici l’essentiel :

# /etc/pam_ldap.conf
base ou=people,dc=linux-attitude,dc=fr
uri ldap://127.0.0.1/
ldap_version 3

Vous remarquerez que pam_ldap.conf et libnss-ldap.conf ne rentrent jamais en conflit. Vous pouvez faire un lien de l’un vers l’autre ou modifier la configuration pour que ce soient les mêmes fichiers. Cela peut vous éviter quelques désagréments.

Test

Maintenant tout marche, même l’authentification. Faites le test :

$ su - peck
Password:
$ id
peck

Youpi, ça marche même en ssh. Bon c’est bien gentil, mais c’est encore un peu léger. La prochaine fois , on voudrait pouvoir faire encore plus.

Carl Chenet: Pycallgraph

sam, 06 jun 2009 12:55:54 +0000

J’ai récemment adopté le paquet Debian du programme Pycallgraph. Excellente raison pour vous présenter rapidement ce programme.

Pycallgraph vous permet de générer une représentation graphique des appels aux différentes fonctions qui composent votre programme Python. Vous pouvez ainsi détecter une anomalie ou comprendre pourquoi votre programme n’est pas performant lors de son exécution.
Un exemple avec mon projet Bélier peut être consulté ici à cette adresse.

L’utilisation du programme est très simple. Pour Bélier, la commande a été la suivante :

$ pycallgraph bel -e ordres

Dans l’exemple ci-dessus, le fichier image au format PNG généré s’appellera pycallgraph.png. Pour l’appeler autrement, il aurait suffi d’appeler la commande suivante :

$ pycallgraph –output-file mon_graphe_belier.png bel -e ordres

Il peut être utile de rajouter certaines instructions dans votre code afin de faciliter l’intégration de Pycallgraph. Plus d’informations à l’adresse suivante : http://pycallgraph.slowchop.com/pycallgraph/wiki/documentation/0.5.1.

Cerise sur le gâteau, la version Debian est à jour par rapport à l’upstream

Shams Fantar: Tutoriel : apache et les vhosts

sam, 06 jun 2009 08:10:00 +0000

Des personnes m'ont demandé à plusieurs reprises de leur expliquer "comment faire un vhost avec apache ?", pour leur répondre, je vais expliquer ici comment le créer, c'est une configuration assez simple à mettre en place. Nous allons le faire donc avec apache, un sous-domaine (ou un nom de domaine, c'est la même conf). La configuration est réalisée sous debian.

I - Explications :

Pour rappel, les vhosts (virtual hosts) sont utilisées pour pouvoir héberger plusieurs sites web par exemple sur une même machine/même ip. En gros, on redirige un domaine/sous-domaine sur l'IP de la machine qui hébergera le site, et on indique à apache "si je tape ce sous-domaine, montre-moi le contenu de ce répertoire sur le serveur (sous-entendu du site web qui se trouve derrière)".

II - DNS :

Je ne vais pas entrer dans les détails au niveau de la conf DNS avec bind, mais voici ce que nous retiendrons pour rediriger un sous-domaine sur la bonne IP :

mon-sous.domaine.tld. A IP-du-serveur

Relancez ensuite bind à coup de /etc/init.d/bind9 reload.

III - Maintenant, les préparatifs :

Avant la configuration du vhost lui-même, il faut créer le répertoire (si il n'existe pas) où se trouvera tout le contenu, par habitude, je mets tout le contenu dans un public_html :

mkdir /home/monsite/public_html

IV - Et on passe au vhost :

Les vhosts sont à créer dans /etc/apache2/site-available/ sous debian. Ouvrez un nouveau fichier :

cd /etc/apache2/site-available/ && nano mon-sous.domaine.tld

Et copiez cette configuration de base :

<VirtualHost *>
ServerAdmin root@localhost # vous pouvez y mettre votre mail, il sera affiché aux visiteurs en cas de problèmes techniques avec apache.
ServerName mon-sous.domaine.tld # le sous-domaine ou le domaine
ServerAlias www.mon-sous.domaine.tld # vous pouvez mettre un second domaine/sous-domaine pour un même vhost

DocumentRoot /home/monsite/public_html # le chemin vers le contenu du site
<Directory />
Options FollowSymLinks
AllowOverride All
</Directory>
<Directory /home/monsite/public_html> # le chemin vers le contenu du site
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>

ErrorLog /var/log/apache2/error_mon-sous.domaine.tld # gestion des logs d'erreur

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

CustomLog /var/log/apache2/access_mon-sous.domaine.tld combined # gestion des logs d'accès
ServerSignature Off

</VirtualHost>

Les explications sont dans la configuration ci-dessus. La configuration est également disponible ici (pour des raisons de mise en page).

Comme je l'ai dit, la configuration est vraiment basique mais elle est suffisante pour un simple site web. Réfèrez-vous à Google pour d'autres paramètres possibles en fonction de vos besoins.

V - On indique tout ça à apache :

Il faut maintenant dire à apache d'utiliser le vhost :

a2ensite mon-sous.domaine.tld

Et le relancer pour lui indiquer cet ajout :

/etc/init.d/apache2 reload

Et voilà ! Apache est maintenant capable de diriger le sous-domaine vers le bon contenu.

VI - Et...

Pour supprimer un vhost :

a2dissite mon-sous.domaine.tld

Et il faut relancer apache.

Shams Fantar: Script PHP pour connaître le nombre de fois qu'un fichier est téléchargé

ven, 05 jun 2009 15:46:00 +0000

Ayant besoin et ne trouvant pas de script répondant à mes attentes, j'ai codé moi-même un script permettant de compter le nombre de fois qu'un fichier est téléchargé. Le script est assez court mais je pense qu'il pourra servir, il permet de gagner du temps !

Le script en PHP fonctionne avec MySQL pour ce qui est des données. Il ne nécessite rien d'autre. Vous avez également le droit à une petite interface d'administration.

Le fameux script en question est disponible dans une archive tar. Lisez le fichier read.me pour tous les détails concernant son utilisation. Les scripts sont accessibles ici aussi.

Une version 0.2 devrait voir le jour sous peu, il sera possible, pour avoir des stats plus vraies, de ne compter qu'un téléchargement par fichier par IP.

N'hésitez pas pour les feedbacks !

Carl Chenet: Reportbug : situation actuelle

jeu, 04 jun 2009 20:12:00 +0000

Suite à un billet de Sandro Tosi passé sur planet.debian.org qui résumait les avancées récentes de Reportbug que j’ai présenté dans un billet précédent, je vais me permettre d’entrer un peu plus dans le détail.

Développement de l’interface en GTK2 de reportbug par Luca Bruno qui fait un gros travail.
Renforcement de l’application (rajouts de contrôles)
Développement de nouvelles options
Réduction importante du nombre de bugs. Ce tableau généré par Sandro Tosi résume la situation.)

Si vous êtes sous Sid et que vous avez la possibilité de tester le dernier Reportbug, n’hésitez pas à envoyer un bug sur Reportbug lui-même. Nous ne garantissons pas un retour rapide sur votre rapport (excepté pour un bug considéré comme important) car les trois contributeurs principaux sont très occupés (j’essaie moi-même d’écluser de nombreux rapports présents depuis trop longtemps dans le BTS avant de me concentrer sur les nouveaux rapports). Mais quoiqu’il arrive, nous voyons passer le rapport et nous vous ferons un retour dessus dès que possible.

Un grand remerciement à Sandro Tosi qui clôt et corrige lui-même de très nombreux rapports, tout en intégrant les patchs que Luca et moi lui envoyons, sans parler de sa disponibilité sur IRC (ubiquité?).

En tous les cas Reportbug est très actif et les retours que nous avons dessus nous permettront d’avancer, merci à vous.

Benoit Peccatte: Comptes ldap (1)

jeu, 04 jun 2009 16:05:00 +0000

Niveau :
Résumé : nss-ldap

Il y a plusieurs façon de gérer ses comptes par ldap. Commençons par la plus simple. Plaçons-nous dans le cas d’une machine qui a des utilisateurs systèmes stockés sur le ldap.

Les utilisateurs sont gérés par la bibliothèque de nom nommée NSS (et là). Cette bibliothèque se configure dans /etc/nsswitch.conf. En supposant qu’on ait déjà un serveur ldap avec des utilisateurs, il suffit donc de modifier ce fichier ainsi que d’ajouter un fichier de configuration spécifique à nss-ldap.

Serveur LDAP

Supposons que vous ayez déjà un serveur installé (apt-get install slapd), avec un suffixe nommé dc=linux-attitude,dc=fr.

Si vous n’avez pas encore d’arborescence avec des utilisateurs, choisissez en une, par exemple ou=people,dc=linux-attitude,dc=fr.

Et peuplons d’utilisateurs notre arbre (je ne vais pas vous apprendre le LDAP). Attention, ici il faut utiliser la classe posixAccount pour les utilisateurs que nous allons créer. Il est possible de faire autrement, mais nous verrons ça plus tard.

Créons un utilisateur avec un uid qui ne rentrera pas en conflit avec les utilisateurs existants pour mieux tester. Utilisons un groupe non ldap pour simplifier le processus (attention, posixAccount est AUXILIARY, ce qui veut dire qu’il faut une autre classe pour l’utilisateur, inetOrgPerson par exemple) :

$ ldapadd -x -D "cn=admin,dc=linux-attitude,dc=fr" -W
dn: uid=peck,ou=people,dc=linux-attitude,dc=fr
uid: peck
objectClass: posixAccount
objectClass: inetOrgPerson
cn: peckname
sn: Peck Le bogoss
uidNumber: 2000
gidNumber: 1000
homeDirectory : /tmp

NSS

Il nous faut le paquet libnss-ldap. Pour que NSS le prenne en compte, il faut éditer /etc/nsswitch.conf :

# on donne la priorité à ldap
passwd:         ldap compat

Maintenant, il faut configurer libnss-ldap, c’est un peu plus compliqué, mais le fichier de config par défaut est plein de commentaires. Voici le minimum à configurer :

# /etc/libnss-ldap.conf
base ou=people,dc=nodomain
uri ldap://127.0.0.1/
ldap_version 3

Test

Ce test doit être fait en root car nous n’avons pas tout mis en place. Nous n’avons pour l’instant défini que l’existence de l’utilisateur.

$ su - peck
$ id
# Une autre façon de faire :
$ getent passwd peck

Youhou ça marche.
Demain nous ferons un peu mieux parce que là bon, c’est léger …

Eric Veiras Galisson: Mercurial : éditer l'historique d'un dépôt (les changesets) avec les MQ

mer, 03 jun 2009 13:48:00 +0000

J’ai toujours^[1] cru qu’on ne pouvait éditer l’historique des ‘changesets’ de Mercurial, mais en fait si ! Et c’est grâce à ce billet sur le blog de Jesper Noehr (un des gars derrière bitbucket) que j’ai découvert qu’en fait c’est tout à fait possible.

En utilisant les MQ (mercurial queues) dont je vous ai déjà parlé, il est donc tout à fait possible de rééditer des modifications déjà enregistrées (committées) dans votre dépôt Mercurial.

Bien évidemment, ce genre de manipulations n’est possible que si vous contrôlez votre dépôt et ses éventuels clones. Dès l’instant où celui-ci a pu être cloné, vous avez perdu la maîtrise de votre code et les modifications sur lesquelles vous voulez revenir sont déjà parties.

Nous sommes dans un dépôt test avec 3 changesets

$ hg log
changeset:   2:6a2d12a15cda
tag:         tip
summary:     modifications de a et b

changeset:   1:ca5faf3b4493
summary:     ajout de b

changeset:   0:66545c7be018
summary:     ajout de a

et nous souhaitons revenir sur les changesets 1 et 2.

Nous initialisons d’abord un dépôt de MQ si ce n’est pas déjà fait

$ hg qinit -c

^[2]

Puis nous importons les changesets que nous voulons modifier

$ hg qimport -r 2:1

Si on regarde maintenant le log

changeset:   2:6a2d12a15cda
tag:         qtip
tag:         2.diff
tag:         tip
summary:     modification de a et b

changeset:   1:ca5faf3b4493
tag:         1.diff
tag:         qbase
summary:     ajout de b

changeset:   0:66545c7be018
tag:         qparent
summary:     ajout de a

on retrouve bien nos 3 différents changesets sauf que les 2 derniers sont différents : ce sont maintenant des patchs sous forme MQ que nous pouvons alors manipuler de façon classique^[3]

On peut donc dépiler tous les patchs pour revenir dans l’état qu’on voulait avant les changesets 1 et 2

$ hg qpop -a
Patch queue now empty
$ hg log
changeset:   0:66545c7be018
tag:         tip
summary:     ajout de a

On peut alors à coup de hg qpush/hg qpop empiler/dépiler nos patchs afin de les modifier, les réorganiser ou ajouter des changesets, et donc revenir sur l’historique de notre dépôt.

J’ai découvert qu’en fait cette information est également disponible sur le site de Mercurial, voyez http://www.selenic.com/mercurial/wi…

Notes

[1] “toujours” est peut-être un trop grand mot, ça ne fait pas non plus si longtemps que ça que je connais Mercurial ;-)…

[2] tant qu’à faire nous ajoutons -c pour avoir un dépôt MQ ‘versionnable’

[3] je vous renvoie vers les chapitre 12 et 13 du hgbook pour plus d’infos

Shams Fantar: Note : PHP et les sessions

mar, 02 jun 2009 20:46:00 +0000

Petite note comme ça, ce n'est pas un cours, juste un mémo.

Les sessions en PHP :

Pour ouvrir une session :

session_start();

Pour détruire une variable spécifique dans une session :

unset($_SESSION['ma-variable'];

Ne pas oublier de détruite ma-variable si on doit lui réattribuer une autre valeur plus tard.

Pour détruire une session :

session_destroy();

Benoit Peccatte: Il fait chaud ici !

mar, 02 jun 2009 13:22:00 +0000

Niveau :
Résumé : sensors-detect ; sensors; hddtemp; fancontrol

Sensors

Comment connaître les différentes températures à l’intérieur de votre machine ? Il y a des capteurs, donc il y a bien une information quelque part. Linux a tous les drivers nécessaires, mais pour ceux qui se sont essayé à regarder, c’est difficile de savoir qui sert à quoi. Heureusement, il y a lm-sensors pour venir à notre secours.

Pour avoir la liste de tous les capteurs disponibles sur la machine ainsi que les driver linux associés à charger, il existe une commande toute simple une fois le paquet lm-sensors installé :

$ sensors-detect

Cette commande scanne le matériel, vous pose une question ou deux et termine en vous listant les modules noyau à charger pour pouvoir obtenir les valeurs. Deux choses à faire :

# On charge le(s) module(s)
$ modprobe lemodule
# Et on automatise ça pour le prochain reboot
$ echo lemodule >> /etc/modules

Et voilà, il ne vous reste plus qu’à lire les valeurs. Pour cela, vous avez plusieurs outils :

# lecture simple des valeurs en mode texte
$ sensors 
# lecture avec interface graphique (ne marche pas chez moi)
$ xsensors

Ou les traditionnelles applet qu’on peut trouver sur gnome, kde, gkrellm, windowmaker …

Hddtemp

Si vous voulez aussi lire la température de vos disque, il existe hddtemp du paquet éponyme. Celui-ci marche directement en ligne de commande :

# Il faut être root
$ hddtemp /dev/sda

Il existe aussi en mode démon, une fois installé, modifiez /etc/default/hddtemp (debian) et relancez le démon :

$ /etc/init.d/hddtemp restart
# vérifions qu'il marche
$ telnet localhost 7634

Et voila, il ne vous reste plus qu’a ajouter le disque dur dans l’applet.

Attention, l’applet de gnome nécessite d’être redémarrée pour détecter hddtemp.

Fancontrol

C’est la fête, passons maintenant aux ventilateurs. Vous avez déjà remarqué que vous pouvez avoir la vitesse de rotation dans vos applet. Ajoutez la au moins temporairement, ça peut vous être utile pour la suite.

En effet, nous n’allons pas seulement lire la vitesse des ventilateurs, mais nous allons la modifier. Pour ceux qui veulent regarder sous le capot, tout cela se trouve dans /sys/devices/platform/<sensordriver>/

Fancontrol est un paquet qui contient deux choses : un script permettant de régler automatiquement la vitesse de rotation des ventilateurs et un outil permettant de le configurer sans se forcer.

Pour utiliser fancontrol, il faut avoir des sensors opérationnels. Gardez de préférence un oeil sur votre applet pour éviter les débordements de température et pour savoir quoi répondre au script.

$ pwmconfig

Ce script vous pose plein de questions, arrête les ventilateurs, les relance, les ralentit … dans le but de savoir quel ventilateur fait quoi, à quel capteur de température on peut l’associer et comment il marche. Sachez au passage que les processeurs acceptent des températures assez élevées, pas besoin de les forcer à 40°C, vous économiserez du bruit. Regardez la doc de votre fabricant si vous voulez un avis sérieux.

Le script pose 2 questions difficiles à comprendre

MINSTART est la valeur de configuration au dessus de laquelle le ventilateur commence à tourner
MINSTOP est la valeur de configuration au dessous de laquelle le ventilateur s’arrête de tourner

De façon générale, MINSTOP doit être supérieur à MINSTART (hystérésis), mais les valeurs sont assez proches. Vous pouvez aussi choisir ces valeurs par rapport à ce que vous entendez plutôt qu’à la vitesse réelle de rotation.

Une fois le tout configuré :

$ /etc/init.d/fancontrol start

Et écoutez ce silence en provenance de votre ventilateur. Surtout lorsque vous faites des activités peu intensives.

Benoit Peccatte: Scripts nautilus

dim, 31 mai 2009 10:23:00 +0000

Niveau :
Résumé : ~/.gnome2/nautilus-scripts

Aujourd’hui parlons un peu d’interface utilisateur. Vous arrive-t-il souvent de lancer la même commande sur plein de fichiers ? Avez-vous une personne de votre famille qui perd son temps à ouvrir des fichiers un par un pour faire une modification dans chaque ?

Si ces opérations sont automatisables (calculs openoffice, modification d’image, ajout d’une ligne de texte …) alors il y a un moyen pour les rendre accessible directement depuis le navigateur de fichier. Pour cela, il suffit d’écrire un script et de le placer dans ~/.gnome2/nautilus-scripts. Essayer de bien le nommer car il apparaîtra tel quel dans le menu contextuel “Scripts” de nautilus.

Pour parler concrètement, nous allons faire un outil de réduction d’image disponible directement depuis le navigateur de fichier. Nous allons donc éditer le fichier ~/.gnome2/nautilus-scripts/ReductionPhotos qui nous permettra d’appeler imagemagick pour réduire la taille des photos sélectionnées (en ajoutant un préfixe pour ne rien perdre). Nous feront notre démo sur tous les fichiers sélectionnés à la souris pour bien montrer qu’on automatise un comportement d’utilisateur “normal”.

Le script reçoit ses informations dans des variables d’environnement. La plus importante dans notre cas est NAUTILUS_SCRIPT_SELECTED_FILE_PATHS qui contient la liste des fichiers sélectionnés séparés par des retours à la ligne. Donc une petite boucle pour les traiter tous d’un coup :

echo -n "$NAUTILUS_SCRIPT_SELECTED_FILE_PATHS" | while read in_file
do
        process_file $in_file
done

Alors il se peut que le script ait des questions à poser à l’utilisateur. C’est le moment d’utiliser zenity. Un petit outil sympa, équivalent de dialog, mais bien mieux intégré dans gnome. Petite exemple avec la sélection d’un nombre dans une intervalle de 0 à 100 :

$ percent=$(zenity --scale --title="Choix du pourcentage" --text "Pourcents : " --value="50" --min-value="0" --max-value="100" --step="1")

Simple non ?

Pour traiter les images en ligne de commande, vous connaissez imagemagick. Voici la commande à utiliser dans mon cas :

convert image1.jpg -quality 80 -resize 1200 image2.jpg

Voila, on a toutes les briques pour faire le script.

#!/bin/bash
#
# Name : ReductionPhoto
# Author : peck
# Licence : GPLv2
#

set -x

#################################################
#       FONCTIONS
ask_questions ()
{
        # question communes à tous les fichieirs
        quality=$(zenity --scale --title="Choix de qualite" --text "Qualite" --value="75" --min-value="0" --max-value="100" --step="1")
        width=$(zenity --entry --title="Largeur de l'ecran" --text "Largeur" --entry-text="1200")
}

reduct()
{
        # options de reduction
        options="-quality $quality -resize $width"
echo $options >> /tmp/debug

        # sauter les non-images
        if identify "$1" >/dev/null
        then
                # convertir
                convert "$1" $options "$2"
        fi
}

#################################################
#       PROGRAMME
if [ $# -eq 0 ]; then
        zenity --error --title="Erreur" --text="Pas de fichier selectionne pour la conversion"
        exit 1
fi
if which convert 2>/dev/null
then
        true
else
        zenity --error --title="Erreur" --text="ImageMagick n'est pas installe"
        exit 1
fi

# c'est parti
ask_questions
echo -n "$NAUTILUS_SCRIPT_SELECTED_FILE_PATHS" | while read in_file
do
        ibase=$(basename "$in_file")
        idir=$(dirname "$in_file")
        out_file="$idir/r_$ibase"

        # on fait gaffe aux fichiers qu'on ecrase
        if ls "$out_file"
        then
                if zenity --question --title="Fichier existant" --text="Remplacer r_$ibase ?"
                then
                        reduct "$in_file" "$out_file"
                fi
        else
                reduct "$in_file" "$out_file"
        fi
done

# et ouala
zenity --info "Reduction terminee"

À vous de faire tout ce qui vous intéresse, le reste de la doc se trouve dans la faq du site

Shams Fantar: Le blog en version anglaise

sam, 30 mai 2009 16:29:00 +0000

Voulant rendre mes articles lisibles par plus de monde, j'ai ouvert un autre blog, avec les articles que j'écris sur celui-ci (celui où vous vous trouvez actuellement). La différence réside dans le fait que sur cet autre blog, je traduis en anglais les articles disponibles ici.

Ceci permet donc que plus de monde soit en mesure de lire ce que je rédige. Le contenu est par conséquent le même.

Le blog en version anglaise est disponible ici : http://en.about-gnulinux.info/

Quelques articles du blog anglais seront publiés prochainement sur linux.com.

Benoit Peccatte: En vrac (23)

mer, 27 mai 2009 16:16:00 +0000

Niveau :
Résumé : pam_faildelay.so ; tail -F * ; dusort ;

Réduire le délai en cas d’erreur du mot de passe (très chiant pour su par exemple). Simple calcul, le délai par défaut de 2s donne 13243 ans pour bruteforcer un mot de passe de 8 lettres (26 possibilités). On peut donc se permettre de diviser ce délai par 4 pour apporter un peu de confort à l’usage :

$ vi /etc/pam.d/common-auth
# on annule le délay ajouté par pam_unix
auth    required        pam_unix.so nullok_secure nodelay
# on ajoute un délai en microsecondes
auth  optional  pam_faildelay.so  delay=500000

Attention, login vient avec son propre délai supplémentaire de 3 secondes chez debian (dans /etc/pam.d/login).

Il est possible de regarder les nouvelles lignes sur plusieurs fichiers en même temps :

$ tail -F /var/log/*

Alias pour connaître rapidement les 10 plus gros répertoire du répertoire en cours :

$ alias dusort='du --max-depth=1 | sort -rn | head -n 10'

Appeler une commande en évitant tous les alias possible (par exemple rm qui est aliasé rm -i):

# bash uniquement
$ \commande

Avancer / reculer d’un mot lors de l’édition de ligne (bash ou tout outil readline) Esc-fleche droite ou gauche.

Effacer les fichiers de plus de XX jours :

$ find . -not -ctime -XX -name "*.ncap" -exec rm {} ;

Carl Chenet: Bélier 0.8

ven, 22 mai 2009 23:09:32 +0000

La nouvelle version de mon programme Bélier est disponible depuis hier sur http://www.ohmytux.com/belier et sur mentors.debian.net Je recherche donc un sponsor.

http://mentors.debian.net/debian/pool/main/b/belier
http://mentors.debian.net/debian/pool/main/b/belier/belier_0.8-1.dsc

Bélier permet l’ouverture automatisée d’un terminal ou l’exécution de commandes sur un ordinateur distant via une connexion ssh. L’intérêt principal de Bélier réside dans sa capacité à traverser plusieurs machines intermédiaires avant d’accomplir la tâche assignée.

Un schéma vaut souvent mieux qu’un long discours :

Schéma de fonctionnement de Bélier

Permettant d’automatiser des connexion ssh avec plusieurs machines intermédiaires entre la source et la destination, Bélier réunit tous les éléments nécessaires pour qu’un administrateur, avec son seul poste de travail, puisse administrer son réseau de manière indépendante sans devoir/pouvoir modifier les serveurs dont il a la charge.

Bélier génère un script expect en sortie qu’il vous suffira d’exécuter pour atteindre votre machine.

Bélier n’est pas une alternative à l’échange de clés ssh ou à des solutions centralisées de déploiement de logiciels. Son rôle est de permettre à un administrateur système qui ne possède pas la maîtrise totale de son parc, qui ne peut pas mettre en place une solution centralisée d’administration, de travailler de manière productive sans perdre un temps considérable à atteindre ses machines.

Des exemples concrets d’utilisation sont disponibles ici :

http://www.ohmytux.com/belier/#toc8

Quelques fonctionnalités :

atteinte d’une machine cible à travers plusieurs machines intermédiaires
lancement d’une commande d’une machine source vers une machine cible à travers plusieurs machines intermédiaires
possibilité de changer de compte sur chaque machine du chemin (pour utiliser un échange de clé ou se conformer à une restriction d’accès)
possibilité de changer de port entre chaque connexion ssh du chemin
vous pouvez définir les mots de passe ou non (utilisation d’un échange de clé existant)

Bélier sera présenté dans un lightning talk au Pycon Fr http://pycon.fr le 31/05/09. Un retour d’expérience sur le développement de Bélier aura également lieu aux Rencontres Mondiales du Logiciel Libre à Nantes le 09/07/2009.

Comme annoncé au début du message, je recherche un sponsor Debian pour ce paquet. Tout retour sur l’empaquetage d’un mainteneur/DD me sera extrêmement profitable. Et bien sûr tous les retours d’éventuels testeurs en général.

Benoit Peccatte: Pas d'écran, pas de chocolat

ven, 22 mai 2009 16:16:00 +0000

Niveau :
Résumé : Xvnc

Supposons une machine sur laquelle vous n’avez pas d’écran. Vous voudriez tout de même pouvoir y accéder en mode graphique. Pour ma part, il s’agit de mettre en place une machine autonome, qui servirait à diffuser la musique sur mon ampli. Pas de place pour l’écran, le problème, il faut bien la commander un peu de temps en temps.

Pour cela il y a plusieurs solutions

Solution A

Dans le cas de diffusion de musique, il est possible de trouver un système purement serveur permettant d’être commandé par une interface web ou un client en ligne de commande. Je pense à des plugins spécifiques à des client habituels ou à des serveurs comme mpd sans interface graphique.

Inconvénient, l’interface est assez peu intuitive et nécessite une certaine bidouille pour être accessible par tous. De plus on passe du temps pour finalement ne faire que de la musique (si on veut que la machine fasse aussi alarme, il faut repartir dans la bidouille.

Solution B

Un solution très unixienne avec interface graphique serait de mettre en place XDMCP sur le service de connexion (gdm, kdm …). Bonne solution, même pour les clients windows puisque xming permet de faire serveur X sous windows.

Cette solution nous permettrait de disposer de tous les avantages d’un bureau intégré, par exemple, régler le son, configurer une radio … Par contre, cette solution a l’inconvénient de rendre la machine concernée non autonome. A la moindre déconnexion, pof, plus de musique. Mais expliquons quand même la solution brièvement.

Activez XDMCP sur votre *dm
- gdm : dans /etc/gdm/gdm.conf
- kdm : dans /etc/kde*/kdm/kdmrc

##########MACRO#0#

Connectez vous avec votre serveur X
- X86 ou Xorg :

##########MACRO#1#

** Xming : xlaunch / “One WIndow” / “Open session via XDMCP” / “Connect to Host”

Solution C

Pour pouvoir survivre aux déconnexions, il existe un protocole vnc. On peut utiliser vnc de deux façons :

sur un serveur X existant auquel on est connecté
sur un serveur X virtuel qui ne fait aucun affichage réel, juste serveur X et serveur vnc

Dans le premier cas on utilisera x11vnc, qu’il est possible de lancer une fois connecté en tant qu’utilisateur. Mais cela ne correspond pas trop à notre cas d’usage.

Dans le Deuxième cas, il suffit de dire à notre *dm de ne pas lancer de serveur X normal, mais un serveur vnc. Pour gdm, il suffit de modifier gdm.conf :

[daemon]
# pour éviter les paramètre incompris de Xvnc
VTAllocation=false

[servers]
# liste des serveur à lancer
0=vnc device=/dev/console

[server-vnc]
# définition d'un serveur X utilisant directement vnc
name=vnc server
command=/usr/bin/Xvnc -PasswordFile=/root/.vnc/passwd -audit 0
flexible=true

Notez que rien ne vous empêche de laisser gdm lancer un serveur X habituel en plus d’un serveur Xvnc (mettre un 1 à la place du 0).

Pour kdm, (attention, pas testé) :

[X-:*-Core]
ServerCmd=/usr/bin/Xvnc
ServerArgsLocal="-PasswordFile=/root/.vnc/passwd"

Notez le stockage du mot de passe dans /root/.vnc/passwd, vous le mettez où vous voulez, mais c’est la qu’il est créé par la commande servant à créer le fichier :

$ vncpasswd

Très bien, mais le serveur ne servant pas à plusieurs personnes et sachant qu’il n’est accessible que sur le réseau local, on voudrais ne pas avoir à passer l’étape de connexion.

Solution D

Le système D consiste donc à se passer du dm. Ma solution (spécifique à mon cas musical, mais simple à répéter) est de me faire un script qui lancera tout ça au démarrage (j’éteins gdm plutôt que de le configurer pour se connecter automatiquement).

Au passage, j’ai créé un utilisateur music, mais vous vous en foutez.

Chez mon nouvel utilisateur, j’ai créé le script suivant :

#!/bin/sh
# -geometry : un serveur X avec des dimensions satisfaisantes pour la plupart des utilisateurs
# -AlwaysShared : forcer le partage du serveur lorsque plusieurs utilisateur se connectent
# -PasswordFile=/home/music/.vnc/passwd : à remplacer par "-SecurityTypes None"
#                  pour les fous qui ne veulent aucun mot de passe
Xvnc  -geometry 1000x700 -AlwaysShared -SecurityTypes None -audit 0 :0 &
sleep 1
export DISPLAY=:0
# environnement de bureau à lancer
startxfce4  &
sleep 1
# on avertit le quidam dans la pièce qu'on est prêt (30ms, 600hz)
beep -l 300 -f 600

Pour trouver comment lancer l’environnement de bureau qui vous intéresse, il suffit de lire les répertoires /usr/share/xsessions et /etc/dm/Sessions, ils contiennent la liste des bureaux connus des *dm. Une fois le bon fichier trouvén repérez la ligne Exec= et vous aurez la commande.

Et astuce pour le polish, on met ce script dans un cron de l’utilisateur concerné pour qu’il se lance automatiquement au démarrage de la machine :

$ crontab -e
# m h  dom mon dow   command
# Notez le @reboot magique
@reboot /home/music/script.sh

Voila, il suffit de se connecter avec un client vnc. On peut trouver vncviewer sous linux et sous windows. On peut avoir plusieurs utilisateurs, et on peut avoir une utilisation simple du système.

Planète des utilisateurs Debian

Grégory Colpart: JCE non limitées sous Debian

Carl Chenet: Reportbug 4.5

Benoit Peccatte: En vrac (24)

Sylvain Derosiaux: Gérer ses templates pour Vim sans fichiers externes

Erwan Briand: CodingTeam 0.9.1 est disponible !

Benoit Peccatte: Comptes ldap (4)

Et après les comp­tes ?

S’adap­ter à l’exis­tant

libnss-ldapd

Sécu­rité et per­for­man­ces

Benoit Peccatte: Comptes ldap (3)

Chan­ger son mot de passe

chsh, chfn, addu­ser

Quel­ques remar­ques

Christophe Nowicki: Héberger son propre fournisseur d’identité OpenID

Présentation d’OpenID

Pourquoi héberger son propre fournisseur d’identité?

Présentation de Community-ID

Configuration de Community-ID sur un serveur Debian GNU/Linux

Configuration de MySQL

Installation dépendances

Installation du programme

Configuration

Liste des services compatibles

Carl Chenet: RMLL 2009 et retour sur Pycon FR

Erwan Briand: Patate \o/

Benoit Peccatte: Comptes ldap (2)

LDAP

PAM

Test

Carl Chenet: Pycallgraph

Shams Fantar: Tutoriel : apache et les vhosts

I - Explications :

II - DNS :

III - Maintenant, les préparatifs :

IV - Et on passe au vhost :

V - On indique tout ça à apache :

VI - Et...

Shams Fantar: Script PHP pour connaître le nombre de fois qu'un fichier est téléchargé

Carl Chenet: Reportbug : situation actuelle

Benoit Peccatte: Comptes ldap (1)

Ser­veur LDAP

NSS

Test

Eric Veiras Galisson: Mercurial : éditer l'historique d'un dépôt (les changesets) avec les MQ

Notes

Shams Fantar: Note : PHP et les sessions

Benoit Peccatte: Il fait chaud ici !

Sen­sors

Hdd­temp

Fan­con­trol

Benoit Peccatte: Scripts nautilus

Shams Fantar: Le blog en version anglaise

Benoit Peccatte: En vrac (23)

Carl Chenet: Bélier 0.8

Benoit Peccatte: Pas d'écran, pas de chocolat

Solu­tion A

Solu­tion B

Solu­tion C

Solu­tion D

Et après les comptes ?

S’adapter à l’existant

Sécurité et performances

Changer son mot de passe

chsh, chfn, adduser

Quelques remarques

Serveur LDAP

Sensors

Hddtemp

Fancontrol

Solution A

Solution B

Solution C

Solution D