Avant Vim 7.0, corriger les fautes d'orthographe d'un texte demandait de passer le buffer dans un programme externe comme aspell ou bien d'installer des scripts. Désormais, depuis la version 7.0, si vous voulez que Vim vous signale les fautes d'orthographe, et vous suggère d'autres mots pour vous aider à corriger vos erreurs, voici la démarche à suivre :

• pour activer ou désactiver la correction orthographique utilisez :

:set spell

et

:set nospell

• pour choisir la langue dans laquelle vous voulez effectuer la correction orthographique, utilisez l'affreuse commande

:setlocal spell spelllang=fr

que je vous recommande de la mettre dans votre .vimrc ou, si vous utilisez couramment plusieurs langues, associez leur des touches de raccourci.

• enfin la commande précédente suppose que vous ayez un dictionnaire français (ou autre) à votre disposition. Si vim râle en disant

Alerte: Liste de mots "fr.utf-8.spl" ou "fr.ascii.spl" introuvable

générez alors une liste de mots à partir d'un dictionnaire, par exemple ceux d'ispell. Sous Linux vous les trouverez dans /usr/share/dict :

:mkspell /tmp/fr /usr/share/dict/french

puis en root déplacez ce fichier dans

/usr/share/vim/vimcurrent/spell

Les commandes utilisables ensuite sur les mots mal orthographiés (soulignés en rouge ou affichés sur un fond rouge selon votre configuration) sont :

• En mode commande :

z= - pour proposer un liste de mots 
]s - pour aller au prochain mot mal orthographié
[s - pour aller au précédent mot mal orthographié

• En mode insertion, à la fin d'un mot mal orthographié

Ctrl+x s - pour proposer une liste de mots

Il existe bien sûr une infinité d'autres commandes (enregistrer un mot comme bien orthographié, annuler une correction, ...) je vous recommande de passer par

:help spell

si vous voulez tout savoir

Voilà, plus de souci de fautes d'orthographe pour vous qui utilisez mutt et vim pour écrire vos courriels :D

Je dispose d’une webcam TRUST 320 SPACECAM et ma distribution est toujours Debian (unstable).

Aucun site n’explique correctement l’installation du driver donc je vais le faire j’espère le plus clairement qu’il en soit.

Vous devez disposer des fichiers “linux-headers” de votre noyau :
# aptitude install linux-headers-`uname -r`
Ensuite nous allons installer le paquet qui nous intéresse :
# aptitude install ov51x-jpeg-source
# cd /usr/src
# bzip2 -d ov51x-jpeg.tar.bz2
# tar xvf ov51x-jpeg.tar
# cd ov51x-jpeg
# make
# make install
# modprobe ov51x-jpeg
# vim /etc/modules
Rajouter “ov51x-jpeg” à la fin.

Et voilà, vous pouvez utiliser un logiciel tel que amsn pour pouvoir utiliser la webcam sur Internet.

Nous sommes au début des années 90, SCUMM, une plateforme de script développée par LucasArts nous offre quelques petite merveilles du jeu vidéo : Day of the Tentacle, Indiana Jones and the Fate of Atlantis, Monkey Island 2: LeChuck's Revenge, ... la liste est bien longue.
A quelques exceptions près on retrouve dans tous ces jeux un scénario travaillé et intéressant (mais non ce n'est pas une critique directe envers les jeux vidéos actuels ), des puzzle ou des casse-tête parfois tordus, souvent difficiles, mais toujours amusants, et enfin un humour complètement décalé et très décapant.

Beneath a Steel Sky, sorti en 94 en est un parfait exemple. Pourquoi parler de ce jeu plutôt qu'un autre ? Car il est gratuit !!!

Gratuit il ne l'a pas toujours été^[1]. Depuis 2003, un peu près 10 ans après sa sortie, le jeu est devenu freeware, c'est à dire gratuit. Excellente initiative, et très bonne nouvelle pour le projet ScummVM qui est une ré-implémentation libre de SCUMM. (Mise à jour le 08/06/2008 : comme le signale omega dans les commentaires, Beneath a Steel Sky est basé sur VirtualTheatre, à l'époque un concurrent direct de SCUMM. ScummVM est donc compatible avec et compatible VirtualTheater.)

Il ne vous coûtera donc pas un sou pour jouer à ce jeu, que vous soyez sous Windows, sous Linux ou sous Mac (et même plein d'autres supports, Palm, PSP, Windows CE, iPhone... la liste est très longue). Si vous avez la chance d'être sous Debian, vous trouverez même Beneath a Steel Sky dans les dépôts :

apt-get install beneath-a-steel-sky scummvm

Sinon il faudra vous rendre sur le site officiel de ScummVM pour télécharger ScummVM et Beneath a Steel Sky.

Je vous recommande fortement de jouer à ce jeu si vous aimez les jeux du genre Point 'n Click.
Si vous ne vous y êtes jamais frottés, je vous recommande aussi fortement d'y passer quelques heures. Vous vous sentirez sûrement un peu perdu au début. N'hésitez pas à chercher une solution complète sur internet pour débuter ou pour vous débloquer quand vous serez à court d'idées. Gardez quand même à l'esprit que c'est une vrai joie de pouvoir finir le jeu "tout seul" en faisant travailler votre observation et vous méninges Essayez d'entrer dans la logique du jeu et attachez vous à passer un peu de temps sur chaque énigme avant de vous abandonner à la solution de facilité qu'est la solution complète.

Le jeu se finit en une petite dizaine d'heures de jeu pour les habitués du genre. Je pense que même en essayant de faire le tour complet des dialogues et en bloquant un peu, vous aurez du mal à dépasser une quinzaine d'heures ce qui est très honorable pour un jeu vidéo. Certains jeu qui sortent actuellement on à peine 6 heures de durée de vie !

Le début de Beneath a Steel Sky

Les décors sont sublimes même si focément depuis on a vu mieux Le jeu a quand même 15 ans !!!

Encore des décors. Notez la variété des environnements

L'interface est conviviale et finalement très intuitive

Les dialogues (ici en anglais, mais c'est paramétrable) sont doublés d'une piste audio (si vous téléchargez la version CD) qui ajoute beaucoup de charme au jeu

L'humour de Beneath a Steel Sky est très décalé mais m'a bien fait sourire

Le scénario est très travaillé, autour des thématiques proches de Blade Runner, Matrix et toute la clique

Profitez bien de ce jeu qu'un ami m'avait fait découvrir peu de temps après sa sortie et que je n'ai enfin pris le temps de jouer que très récemment. Aucun regret !

Les screenshots, c’est bien, les screencasts, c’est peut être mieux.

Vous souhaitez enregistrer en vidéo une manipulation que vous faîtes sur votre ordinateur, vous souhaitez présenter votre site/blog ou faire découvrir quoi que ce soit de votre système ?

Je ne m’étais jamais vraiment intéressé aux screencasts. Je veux dire, en tant que créateur. Pour illustrer un billet ou un article, j’ai toujours utilisé les captures d’écran. Mais dans certains cas et pour favoriser l’interaction avec vos lecteurs, il serait peut être plus judicieux de le faire en vidéo. D’ailleurs, j’adopterai dorénavant cette solution quand elle s’avèrera intéressante.

Pour cela, j’ai découvert un logiciel qui vous permettra d’enregistrer très facilement ce qu’il se passe sur votre bureau: recordMyDesktop.

Je l’ai testé sur Ubuntu Hardy Heron et ça fonctionne très bien:

$ sudo apt-get install recordmydesktop

Il faut ensuite installer l’interface graphique, disponible pour Gnome et KDE

$ sudo apt-get install gtk-recordmydesktop (interface gtk)

$ sudo apt-get install krecordmydesktop (interface KDE)

L’interface est dépouillée, simple et compréhensible (J’utilise l’interface GTK). Vous avez la possibilité de générer des screencasts au format .ogg en définissant:

- les qualités vidéo et sonores de l’enregistrement afin d’alléger la taille du screencast à la sortie
- les performances (nombre d’images par seconde, encodage à la volée…)
- l’utilisation d’une entrée audio externe pour commenter par exemple votre screencast à partir d’un micro
- quelques réglages divers

RecordMyDesktop est un bon petit logiciel qui, même si l’on en a pas forcément l’utilité tous les jours, saura vous être utile lorsque vous voudrez illustrer votre prochain billet !

N.B: Malheureusement, la connection internet dont je dispose au boulot limite tellement l’upload que je n’ai pas pu envoyer mon screencast sur Youtube, dommage…

Aussi sur Another Pinky Punky

• Sortie de Safari 3.1: pourquoi j’envie Mac… et Windows ! (14)
• Ressources système Debian Etch / Ubuntu Hardy Heron (3)
• KDE 4 Bêta 3 prêt pour les tests (1)
• Fluxbox sort en version 1.0: évènement (0)
• Agrégateur RSS : Liferea ou RSSOwl ? (14)

Comme chaque année, il faut déclarer ses impôts sur le revenu. Les années précédentes, j'avais réussi à le faire sans trop de problèmes. Cette année, ma machine étant passée en amd64, je soupçonnais des problèmes et j'avais raison : en une heure, je n'ai pas réussi à faire ma déclaration d'impôts, et j'ai mis moins de trois minutes sous MacOS X.

Je partais quand même avec une longueur d'avance : j'avais déjà un certificat valable jusqu'en 2010, qui a été reconnu d'office. J'ai ainsi pu remplir ma déclaration d'impôt (format PKCS 12, que j'ai pu exporter et mettre sur mon Mac pour finir la déclaration). Mais au moment de signer la déclaration, il faut exécuter une applet java, qui permettait la signature proprement-dite (au sens cryptographique du terme). Et là, plus possible.

• Sun n'a pas publié de plugin compatible amd64 et ne prévoit pas de le faire avant début 2009...
• openjdk-6 n'est pas fabriqué pour Debian
• Le plugin d'IcedTea ne fonctionne pas pour les impôts (fenêtre grise vide).
• Blackdown Java est introuvable... et avant ça, j'en avais une vieille copie qui fonctionnait à certains endroits mais faisait des segfaults systématiques sur cette applet-là.
• Monter un chroot pour iceweasel n'a pas l'air de fonctionner dans le temps imparti (même avec un xhost + il n'arrive pas à ouvrir de fenêtres graphiques)...

Enfin bref, conclusion : j'ai fait sur un Mac, et ces conneries m'emmerdent.

On fait tout un foin en ce moment d’Adobe Air et des clients Twitter développés pour cette plateforme: Twhirl, Alert Thingy ou encore Spaz.

Moué. Adobe Air est encore une comédie sous Linux et quand bien même, quand on s’évertue à avoir un système libre, je n’irai pas chercher de logiciels propriétaires pour faire tourner une usine à gaz pour simplement utiliser Twitter.

Quoi ? Mais non je ne suis pas énervé !

Je veux donc vous faire découvrir la simplicité pour une utilisation de Twitter intégrée à votre environnement de bureau Gnome. Look minimaliste et efficacité, voici le sobrement dénommé gTwitter.

L’installation sur votre système est très simple, en superutilisateur dans un terminal:

$ sudo apt-get install gtwitter

Pour une utilisation de base de Twitter, franchement restons simple, gTwitter est très suffisant.

Voir un billet intéressant chez Linux.com concernant les clients Twitter pour systèmes Linux.

Aussi sur Another Pinky Punky

• Sortie de Safari 3.1: pourquoi j’envie Mac… et Windows ! (14)
• Ressources système Debian Etch / Ubuntu Hardy Heron (3)
• Mon premier report de bug chez Bugzilla (0)
• Epiphany: le navigateur web de Gnome (8)
• Vos bookmarks de sites mobiles ? (0)

J’ai pu faire ce petit constat à propos de l’utilisation des ressources système entre Debian et Ubuntu, notamment au niveau de la mémoire vive:

Sur une même machine, avec les mêmes services activés au démarrage, Ubuntu Hardy Heron consomme plus de 120 Mo de mémoire vive contre à peine 60 pour la Debian Etch que j’utilisais.

La seule différence entre les deux systèmes est que d’un côté j’avais Gnome 2.20.3 sur la Debian et la version 2.22.1 sur Ubuntu. Aucun des systèmes n’utilise Compiz, les services Bluetooth, CUPS (serveur d’impression), SQL, Apache2 ne sont pas utilisés.

Néanmoins, il faut relativiser, Ubuntu est tout de même rapide, principalement grâce à l’utilisation d’Openbox à la place de Metacity.

Vous avez constaté une certaine gourmandise de votre système Ubuntu vous aussi ?

Aussi sur Another Pinky Punky

• Epiphany: le navigateur web de Gnome (8)
• 8 mois après, retour à Ubuntu Hardy Heron (6)
• Vimperator: l’extension firefox très geek (4)
• Mon premier report de bug chez Bugzilla (0)
• Debian sid/unstable: sources.list (0)

Un petit récapitulatif des nouvelles concernant la sécurité informatique intéressantes vues (plus ou moins) récemment sur la toile.

• Tout d'abord, une news très importante : la découverte que vos disques durs chiffrés ne sont pas aussi sûrs que vous (et moi !) ne le pensiez. En effet, une étude a démontré que la clé d'un disque dur chiffré reste encore quelques minutes dans la RAM après l'extinction d'un ordinateur, rendant celui-ci vulnérable. Cette nouvelle a fait le tour du web sécurité et voici donc quelques liens pour approfondir le sujet :
  • l'article d'origine sur Freedom to tinker [via lwn.net];
  • un article sur le blog de Russell Coker;
  • on en parle également sur écrans.fr;
  • ou sur... linuxfr;

• dans le même ordre d'idée : un outil permettant de voler un ordinateur sans l'éteindre [via Bruce Schneier et engadget];

• un article original expliquant comment l'OLPC pourrait être détourné de son but premier (l'utilisation par des enfants) et utilisé à des fins militaires;

• d'autres informations importantes si vous voyagez aux USA : il semble que les douanes puissent nous seulement vous demander de sortir votre ordinateur portable, de l'ouvrir et de l'allumer mais également de leur laisser accéder aux données voire de leur donner le mot de passe ou clé de chiffrement : c'est également chez Bruce Schneier. (pour d'autres infos concernant les douanes US sur le même blog, voyez ici et là);
• tiens, le magazine Wired nous fait un howto pour passer plus facilement les check-in d'aéroport, ça tombe bien...

• Un article très intéressant de Bruce Schneier sur wired.com concernant le respect de la vie privée ('privacy') et la surveillance généralisée. Il nous explique que l'éternel argument opposé aux réfractaires/résistants à la surveillance généralisée est celui de la surveillance mutuelle : vous savez ce que je fais, et moi je sais ce que vous faites. Malgré le fait que cette situation n'est pas idéale, elle semble tenir la route. Mais malheureusement, l'équilibre est rompu par un autre aspect, celui du pouvoir. En effet, par exemple, lorsqu'un officier de police vous demande vos papiers d'identité, même si il vous donne les siens, son pouvoir est considérablement supérieur au vôtre puisqu'il peut lui avec les informations chercher dans les bases de données de la police des informations sur vous, chose que vous ne pouvez faire. Je vous laisse lire l'article pour la suite de l'argumentation;
• Francis Pisani nous parle également des policiers via la présentation d'un site pour noter ceux de Los Angeles;

• un article en anglais expliquant comment protéger sa vie privée sur internet. Il est notamment destiné aux personnes risquant leur vie pour défendre leurs opinions mais certaines informations sont intéressantes pour tous [via grepgrrl.org];

• où l'on reparle des tags RFID et notamment des mifare et de leur (fausse) sécurité...

• un petit appel au troll : les délais concernant les mises à jour de sécurité pour les principales distributions Linux... on dirait bien que Debian est classée en tête, cool !;

• un billet concernant Tor nous rappelant que l'anonymat et la protection de la vie privée ('privacy'), ce n'est pas tout à fait la même chose même si les deux concepts sont liés;

des articles un peu plus techniques :

• utiliser une clé USB comme mot de passe;
• GPG c'est bien, mais à condition de sécuriser ses clés : une solution pour les protéger;
• une solution pour chiffrer tout son disque dur et utiliser une clé USB pour stocker la clé de chiffrement : Passwordless Encrypted Root in Debian;

Le contrôle d'accès est généralement fourni par l'application qui fournit un service. Pour le contrôle de l'identité cette application utilise en général pam, mais de nombreuses applications effectuent des contrôles sur d'autres éléments que l'identité de la personne et en particulier le réseau. Tout comme pam il existe une bibliothèque qui s'occupe de ceci pour éviter au développeur de mal faire plusieurs choses. Parlons de tcpwrappers.

Les bases

La bibliothèque tcpwrappers permet à une application de disposer d'un contrôle du client à moindre frais. Ses deux fichiers de configuration sont /etc/hosts.allow et /etc/hosts.deny. Sa méthode de fonctionnement est très simple. Si un client a une correspondance dans hosts.allow, il est autorisé à entrer, sinon s'il a une correspondance dans hosts.deny, il est refusé, et enfin s'il ne matche aucune règle, il est accepté.

Le format de ces fichiers est assez simple :

# service : client 
sshd : 127.0.0.1

Vous pouvez remplacer le nom du service (du démon) par ALL, qui matche tous les services utilisant tcpwrappers, ou par un numéro de port (22).

Pour le nom du client, le système de matching est assez évolué. Vous pouvez donner un nom de machine (machine.toto.fr), un nom de domaine (.toto.fr), un réseau (10.0.0.0/24), un netgroup NIS (@groupe), une IPv6 (1:2:3:4:5:6:7:8/64) ou même une liste en provenance d'un fichier un peu plus complet (/etc/deny). Les wildcards shell fonctionnent aussi dans ces règles (*.toto.fr). Notez que si le serveur dns est indisponible, les règles basées sur les noms ne matchent pas, donc en l'absence de règles sur l'ip, l'accès sera au final autorisé.

Des alias existent aussi pour les clients, les plus importants sont ALL (tout le monde), LOCAL (attention, il ne fait pas exactement ce à quoi on s'attend, il matche les machines dont le nom n'a pas de domaine), et PARANOID (on vérifie que le dns direct et reverse correspondent).

Une configuration un peu plus avancée

Mais je ne vous ai pas tout dit sur ces fichiers. Ils admettent en réalité une syntaxe un peu plus évoluée

# service : [user@]client [ : option [ : option  ... ] ] 
sshd : peck@127.0.0.1 : ALLOW

User permet de vérifier l'utilisateur grâce au protocole ident. Il n'y a plus guère qu'irc qui fasse ce genre de vérifications.

Les options permettent quelques petites astuces sympa : on peut par exemple utiliser allow et deny qui permettent de mettre toutes les règles dans un seul fichier.

On peut aussi lancer un script qui fera une vérification un peu plus poussée.

# autoriser les gens qui répondent au ping
sshd : ALL : aclexec  /bin/ping -n -W 1 -c 1 %a : ALLOW

La liste des substitutions %<X> possibles se trouve dans le man hosts_access.

Attention tcpwrappers ne gère pas proprement les substitutions d'ip lorsque votre système dispose d'ipv6. C'est pourquoi ce genre de règles risque de vous poser problème, évitez les si vous pouvez, et logguez ce que vous faîtes sinon, un debug risque d'être utile un jour.

Deux autres options avancées permettent de faire bien d'autres choses intéressantes. Vous pouvez lancer un script arbitraire à chaque connexion (vous vouliez recevoir un mail à chaque fois qu'un client se connecte chez vous ? ou faire un compteur ...), ceci grâce à l'option spawn. L'option twist permet quant à elle de remplacer le vrai serveur par une autre commande. Par exemple, vous pouvez écrire un message d'erreur particulier à tous les gens qui tentent de se connecter en http depuis l'ip de votre concurent.

Le man de hosts_options vous donnera un détail complet de ces options étendues.

Lorsque vous voulez tester une de vos règles, vous avez la chance d'avoir une commande qui vous dira tout de suite qui matche et qui ne matche pas :

$ tcpdmatch sshd 127.0.0.1

Malheureusement, tcpdmatch ne fait qu'un match sur les règles et ne lance aucun script des options étendues. Donc si vous avez des règles aclexec, cela ne correspondra pas nécessairement à la réalité.

Comment faire ?

Intéressons nous à un exemple ou deux de configuration.

Si vous voulez être restrictif (par exemple pour un accès ssh), commencez par interdire tout le monde ;

# /etc/hosts.deny
sshd : ALL

Puis autorisez au compte goutte dans le hosts.allow :

# /etc/hosts.allow
sshd : 127.0.0.1 , .mondomaine.com

S'il s'agit d'un service public, vous préférerez sûrement une solution de type blacklist, mettez dans le hosts.deny la liste des ip que vous voulez interdire. Pour un système de blacklist évolué (le greylist est aussi imaginable en ftp :-) pensez aux options aclexec et twist :

# /etc/hosts.deny
ftp : ALL : aclexec /usr/local/bin/greylist %a : twist /usr/local/bin/ftpdeny %a

Mais qui utilise vraiment tcpwrapper ?

Le problème dans le monde libre c'est que tant que le système ne force pas l'utilisation de quelque chose, c'est l'anarchie. Donc vous ne savez pas à l'avance quel service utilise ou n'utilise pas tcpwrappers. Pour le savoir vous avez plusieurs solutions : regarder la doc (bof), regarder la conf (mieux) ou regarder le binaire.

Supposons que votre service soit ssh, dans ce cas, nous allons regarder le binaire ssh :

$ ldd /usr/sbin/sshd | grep libwrap

Et en effet, ssh utilise tcpwrapper.

Pour les services qui ne tournent pas en démon (c'est à dire qu'ils sont lancés par inetd), la réponse est simple : s'ils passent par tcp, ils utilisent tcpwrapper; sinon non. Et cela se lit directement dans la ligne de configuration inetd dans la commande d'exécution :

# /etc/inetd.conf
ftp	stream	tcp	nowait	root	/usr/sbin/tcpd /usr/sbin/proftpd

Désolé pour le peu d'articles en ce moment, je suis très occupé. Et cela devrait durer tout le mois de mai.

Quoi qu'il en soit, n'oubliez pas que dans ce monde, vous ne trouverez que ce que vous y mettez. Avant que vous ne m'abandonniez, je vous propose donc d'écrire vous même quelques articles. Je sais que c'est la deuxième fois que je le propose, mais je vais en changer un peu la forme.

Étant donné que mon problème est un problème de temps et non pas d'idées, je vous propose une liste d'articles et si le sujet vous intéresse, dites-le moi, je vous enverrai les choses importantes à dire où à faire sur le sujet.

Donc imaginez vous tout savoir sur :

• l'utilisation de getopt, getopts et consorts dans vos programmes (ou scripts)
• le fonctionnement de memcached (partage de cache entre machines)
• le fonctionnement de l'anycast
• les des vpn avec vtun
• l'utilisation de tcpdump/wireshark pour mieux savoir sur ce qui se passe sur le réseau
• la différence entre archive et sauvegarde
• comment réduire votre distribution debian au plus léger possible
• utiliser des contrôles d'accès étendus sur votre système de fichier

Je laisse bien sûr place à vos idées, et il m'en reste environ 300 comme celles-là alors n'hésitez pas.

Et sinon je vous laisser patienter, il peut se passer un peu de temps avant mon prochain article.

Peck.

J'ai vu l'idée ici et je trouve ça assez marrant : voici mon top 10 des commandes bash :

history | awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
104 vim
70 cd
63 ls
44 ssh
28 svn
20 man
19 killall
15 grep
14 cat
12 ps

Je m'étonne de ne pas y trouver apt-get et apt-cache que je pensais utiliser bien plus.

Rien de bien étonnant sinon : vim est largement en tête C'est peut-être aussi killall qui m'étonne. Je pense que ça doit venir du fait que je fais au moins un killall firefox par jour Vivement FF3

Et vous alors, votre top 10 ?

Aujourd'hui, j'ai découvert quelque chose d'étrange en utilisant Mercurial.

J'ai donc un dépôt privé accessible via https (cf ce post), je le clone, je fais des modifications, je committe, puis je push sur le serveur

$ hg clone https://code.veiras.info/private_repo
$ vi...
$ hg commit -m "nouvelles modifs"
$ hg push
http authorization required
realm: code.veiras.info Mercurial repository
user: X
password: X
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 3 changes to 3 files

Jusque là tout va bien, c'est la façon normale de travailler et j'ai toujours fait comme ça. Sauf qu'aujourd'hui, j'étais également connecté sur mon serveur en ssh, je vais donc dans mon dépôt, un hg tip me dit bien que je viens de faire un commit, mais par contre quand je veux regarder mes fichiers... mes modifications n'y sont pas et là, je tombe des nues : qu'ai-je donc fait mal ? Encore une histoire de permissions sur les fichiers ?

<mode panique>ÇA VEUT DIRE QUE TOUT CE QUE J'AI COMMITTÉ DEPUIS TOUT CE TEMPS EST PERDU ???!!!</mode panique>

vite fait, je saute sur mon client IRC préféré^[1] et rebondit sur #mercurial (sur freenode) où l'on me rassure (?) en me disant que tout est normal.

Pour résumer :

• si je veux avoir les modifs également sur les fichiers en local sur le serveur, il faut que je fasse un hg update sur le serveur;
• si je veux automatiser cet update, il faut utiliser un 'hook' : plus d'informations sur le site officiel ou sur le guide non officiel;
• si on utilise pas sur le serveur le dépôt, on peut même effacer tout les fichiers à l'exception du répertoire .hg/, celui-ci contenant justement tout l'historique du dépôt.
• si on veut effacer ces fichiers, un rm * pouvant poser des problèmes plus tard, il est préférable d'utiliser hg update null qui permet de revenir à la révision 0
• si jamais on a à nouveau besoin de ces fichiers sur le serveur, un hg update fera l'affaire.

Piwik est le digne successeur de phpMyVisites (que j’utilise encore aujourd’hui), logiciel de suivi de statistiques et d’audience de sites web.

Il s’agit d’une alternative sérieuse à Google Analytics, et qui plus est open source.

Actuellement en fort développement depuis ses bégaiements il y a quelques mois, Piwik est esthétiquement très réussi et vous permettra de vous fournir des informations sur:

- vos visiteurs

- vos pages

- les moteurs de recherches

- les mots clés utilisés

chaque catégorie fournissant chacune des informations supplémentaires.

Le logiciel, en AJAX (pas de rechargement des pages), vous permet de définir vous même la disposition des informations à afficher sous forme de widgets. Vraiment très réussi.

Je m’étais décidé à y passer, mais malheureusement, le logiciel requiert PHP version 5.1 ou supérieur et j’en suis encore à la version 4. Dommage, j’étais vraiment enthousiaste à l’idée de l’adopter.

Vous pouvez vous faire une idée en passant par le site de démonstration ou vous pourrez juger de la qualité de Piwik.

et c’est par ici pour le télécharger.

Alors, vous en pensez quoi ? Moi je me sens vieux maintenant avec phpMyVisites !

Aussi sur Another Pinky Punky

• Wordpress 2.3 montre le bout de son nez (0)
• Je découvre : Bluefish, éditeur HTML (4)
• phpmyVisites disponible en version 2.3 ! (2)
• Installer phpMyVisites et suivre l’audience de son blog. (2)
• Gestion des commentaires avec Intense Debate (3)

Un nouvel exemple de migration (après [0],[1] et [2]) qui concerne cette fois un serveur de messagerie (Postfix/Courier-IMAP/OpenLDAP/Amavis/SpamAssassin/Horde) et d’un intranet (Apache/PHP/MySQL) pour plusieurs centaines d’utilisateurs. La migration a duré environ 3 heures (pizzas comprises) sans accroc majeur mais avec un bon nombre de remarques plus ou moins importantes :

- Les Release Notes dispensent de bons conseils : Backup any data, inform users in advance, etc. J’ajoute que je préconise de prévoir une période d’arrêt des services d’au moins une heure avec quelques heures de marge au cas où (dans pas mal de cas, cela peut correspondre à prévoir cela un soir et se réserver la possibilité de passer la nuit dessus !). Je dis bien que je conseille d’arrêter les services (par exemple, mettre en place des règles de firewall les rendant inaccessibles) : en effet prenons l’exemple d’un service SMTP, il est nécessaire de bien vérifier que le système mis-à-jour est fonctionnel avant d’autoriser à nouveau les mails entrants (car si un problème survient, on risque de perdre des mails). Bien sûr, si aucun arrêt n’est possible, une infrastructure permettant une tolérance de panne est sûrement place et l’arrêt des services sur une machine ne posera pas de problème.

- J’utilise en général un noyau Linux patché grsec sur les serveurs mail ou web. Et avant une mise-à-jour majeure, j’ai pris l’habitude redémarrer sur un noyau non-grsec, à savoir celui par défaut… sauf quand il ne contenait pas les pilotes du controleur RAID/SCSI. À retenir :-)
Toujours au sujet du noyau, après quelques installations/désinstallations de noyaux, le paquet module-init-tools a disparu, d’où d’inquiétants messages QM_MODULES: Function not implemented. Solution triviale : aptitude install module-init-tools.

- J’ai perdu mon périphérique /dev/megadev0 (correspondant au controleur RAID/SCSI) que j’ai du recréé via mknod /dev/megadev0 c 253 0 pour avoir un monitoring fonctionnel.

- Un problème de conflit entre les paquets libfam0 et libfam0c102 s’est posé, empêchant d’ailleurs de préparer la mise-à-jour avec un aptitude -d dist-upgrade pour télécharger d’avance tous les paquets à mettre à jour (j’ai finalement du le faire en précisant les paquets manuellement). Pour forcer la résolution de ce conflit : aptitude install libfam0.

- J’ai obtenu l’erreur suivante pendant la mise-à-jour : E: Internal Error, Could not perform immediate configuration (2) on debian-archive-keyring Ack! Something bad happened while installing packages. Pour la résoudre : aptitude install debian-archive-keyring.

- Parlons Apache/PHP/MySQL. En ce qui concerne la migration d’Apache, aucun problème. Pour MySQL 4 vers 5, rien à noter non plus mis à part de bien conserver les mots de passe compatibles avec la v4 (old_passwords=1) comme nous le propose debconf. Enfin pour PHP, je suis resté (pour le moment) sur la version 4 car l’Intranet tourne sous Typo3 et le module calendrier en place semble être incompatible avec PHP5. J’ai eu par contre une activation “surprise” du module eaccelerator dans le php.ini : PHP Warning: Unknown(): Unable to load dynamic library ‘/usr/lib/php4/20050606+lfs/eaccelerator.so’ - /usr/lib/php4/20050606+lfs/eaccelerator.so: cannot open shared object file: No such file or directory in Unknown on line 0

- Pour SpamAssassin, mettre à jour les require_version des règles sur mesure ! Et quelques adaptations mineures (ok_languages, use_dcc plus valables).

- Quelques petits coups de pioche à mettre :

freshclam: error while loading shared libraries: libgmp.so.3: cannot enable executable stack as shared object requires: Permission denied

Solution : execstack -c /usr/lib/libgmp.so.3.3.3

Uncaught exception from user code: Can’t load ‘/usr/lib/perl5/auto/Quota/Quota.so’ for module Quota: /usr/lib/perl5/auto/Quota/Quota.so: cannot enable executable stack as shared object requires: Permission denied at /usr/lib/perl/5.8/DynaLoader.pm line 225, <DATA> line 225. at ./add.pl line 26

Solution : execstack -c /usr/lib/perl5/auto/Quota/Quota.so

- Pour garder Vim en tant qu’éditeur par défaut (aucun troll n’est caché dans ce point…), ne pas oublier le fameux update-alternatives –config editor

- Pour Courier-LDAP, la syntaxe a apparemment changé :
authdaemond: You need to specify a ldap server in config file
authdaemond: authldaplib: error in LDAP configuration file, aborting

Il faut désormais préciser LDAP_URI (LDAP_SERVER et LDAP_PORT ne sont plus valables) :

#LDAP_SERVER 127.0.0.1
#LDAP_PORT 389 LDAP_URI ldap://127.0.0.1

- Postfix 2.3 génère maintenant par défaut des DSN (Delivery Status Notifications) qui peuvent s’avérer gênantes avec les demandes de confirmation de lecture d’Outlook. Pour désactiver les DSN, ajouter dans le main.cf : smtpd_discard_ehlo_keywords = silent-discard, dsn

Voilà, ce fut donc loin de passer comme une lettre à la poste, mais ça ne fut pas un calvaire non plus. Les services ont été réactivés en temps et en heure, et aucun soucis majeur ne s’est produit dans les jours suivants. Au serveur suivant !

Du 1er au 5 juillet 2008, je coordonnerai un thème sur le “développement communautaire”, dans lequel j’escompte bien qu’on parle de forges, entre autres choses.

Merci d’avance pour vos propositions d’interventions.

Voir déjà : un aperçu des thèmes pressentis.

Plus de détail sur les Rencontres Mondiales des Logiciels Libres (9ème édition) : http://2008.rmll.info/

Update 2008/05/07 : j’ai ajouté quelques liens vers plus d’infos sur le site des RMLL.

Je viens de découvrir que la saveur -k7 du noyau linux n’est plus maintenue par Debian. Les gens comme moi sont prié de basculer en -686. Perso, je ne me rends pas compte de la différence, mais bon.
Pour plus d’info, un article sur LinuxFr.

Le but de cet article est d'expliquer comment je mets en place un dépôt Subversion pour partager les sources d'un projet entre plusieurs utilisateurs sur un serveur privé.

J'aime créer un groupe du nom de mon projet dans lequel je mettrai toutes les personnes qui auront accès à ce projet :

addgroup mon_projet
adduser utilisateur1 mon_projet
adduser utilisateur2 mon_projet

Je crée ensuite un dépôt SVN dans le répertoire du projet (Je regroupe tous les dépôts SVN dans un même répertoire : /home/svn) :

cd /home/svn
svnadmin create mon_projet

Je modifie ensuite les droits sur le répertoire. En particulier, je le rends modifiable par le groupe mon_projet :

chown -R :mon_projet mon_projet
chmod -R g+w mon_projet
chmod g+s mon_projet/db

Ensuite, comme recommandé dans la documentation de ''Subversion'', je crée un fichier /usr/local/bin/svnserve :

#!/bin/bash
umask 002
/usr/bin/svnserve -r /home/svn/ "$@"

Si vous voulez empêcher complètement l'accès au sources aux personnes ne faisant pas partie du groupe mon_projet vous pouvez mettre umask 007.

Et voilà, les utilisateurs du groupe mon_projet peuvent dès à présent utiliser Subversion en svn+ssh:// sur mon serveur :

svn mkdir svn+ssh://mon_serveur/mon_projet/trunk
svn checkout svn+ssh://mon_serveur/mon_projet/trunk
...

Il est possible de faire mieux niveau sécurité, en particulier si votre serveur est public où que vous n'êtes pas convaincu des bonnes intentions de tous vos utilisateurs (qui se retrouvent avec quasiment tous les droits sur le dépôt)... mais c'est un début.

On n'a pas toujours une interface graphique pour créer des utilisateurs MySQL et leur attribuer des droits. Voici quelques commandes de base.

Création d'un utilisateur d'accès local uniquement :

CREATE USER myuser@localhost;

Mise à jour de son mot de passe :

UPDATE USER SET Password = PASSWORD('mypassword') WHERE user = 'myuser';

Création d'une base de données spécifique pour cet utilisateur :

CREATE DATABASE myuser;

On donne tous les privilèges à myuser sur sa base :

GRANT ALL on myuser.* TO 'myuser'@'localhost';

On recharge tous les privilèges :

FLUSH PRIVILEGES;

Youpi ! Ca y est, le WPA fonctionne sur ma carte Ralink. A force de fouiller sur le net, j’ai fini par trouver une piste.
(more…)

Autant pour ne pas oublier que pour en faire profiter les amis, voici une méthode rapide pour mettre en place l'IPv6 par la méthode de transition 6to4 sur une machine Linux.

Pré-requis : un ordinateur sous un noyau Linux un peu récent (pas d'inquiétude, ça marche même avec une Debian stable, que les mauvaises langues se plaisent pourtant à qualifier d'obsolète dès sa sortie). Avec une adresse IPv4 publique fixe.

Première étape : ajouter ce qui va bien dans le fichier /etc/network/interfaces. Pour pas s'embêter, on prend le script suivant qu'on appelle avec ./6to4.sh <adressev4>, et on copicolle le résultat.

#! /bin/sh
set -e

ip4=$1
echo "$ip4" | grep -q '^[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*$' || \
{ echo 'Syntax: $0 a.b.c.d'; exit 1; }

ip6=$(printf '2002:%02x%02x:%02x%02x::1' $(echo $ip4 | sed 's/\./ /g'))

sed s/IP6/$ip6/ << EOF
auto sit0
iface sit0 inet6 static
        address IP6
        netmask 64
        gateway ::192.88.99.1
EOF

Deuxième étape : activer cette interface, avec ifup sit0. Pouf, on a de l'IPv6.

Troisième étape, optionnelle : configurer un firewall pour cette interface (attention, c'est avec ip6tables et plus avec iptables).

Quatrième étape, optionnelle aussi : configurer une zone DNS reverse sur un serveur, et faire référencer ce serveur. Ça se passe sur 6to4.nro.net, et il suffit de remplir les champs du formulaire en faisant la requête depuis la machine concernée.

...et voilà. Évidemment ce mini-HOWTO devrait n'être utile que pendant une période limitée (juste le temps que tous les FAI fournissent de l'IPv6 natif), évidemment il ne couvre pas le routage automatique pour le réseau situé derrière la machine, il ne couvre pas les configurations compliquées, mais au moins, pour le prochain serveur dédié que le prendrai, j'aurai la manipulation prête et documentée.

Cool. phpGroupware is back in the “testing” Debian distribution (a.k.a “lenny”). The package uploaded to unstable has nicely made its way through the 10 days delays without major problems, so it’s back in testing.

I hope it will make its way to the future stable too.

Niveau :
Résumé : pam

Le contrôle d'accès est généralement fourni par l'application qui fournit un service. Pour le ftp, on effectue un contrôle des logins et mots de passe, il en va de même pour gdm et les applications qui nécessitent un utilisateur, Pour cela, la bibliothèque pam est toute indiquée.

PAM (Pluggable Authentication Module) est une bibliothèque servant exclusivement à l'authentification. Je vous en ai déjà parlé plusieurs fois ici et encore là. Comme quoi, c'est presque aussi utilisé que ssh.

La bibliothèque PAM

Pam assure une authentification sécurisée et le fait bien, dans la grande tradition unix, 'do only a single thing, but to do it well'. Il ne fournit que 4 fonctionnalités :

• auth : authentification, je m'appelle Obiwan et je peux le prouver
• account : accès au compte, j'ai le droit de rentrer dans Mos Eisley à 6h du matin
• password : gestion de l'authentification, je veux changer mon mot de passe en "Use the force Luke"
• session : sers moi un verre avant que j'entre dans le bar et fait le ménage quand j'en sors

Une application qui gère une authentification doit au moins appeler une de ces fonctions (généralement auth, account et session). Notez que pam étant une bibliothèque, l'appel est fait en tant que l'utilisateur sous lequel tourne l'application. Généralement, c'est root (il n'y a que root qui puisse devenir un autre utilisateur), par exemple dans le cas de su ou login, mais cela peut aussi être un simple utilisateur comme pour xscreensaver (il n'appelle que la fonctionnalité auth).

Ces fonctions ne sont pas rendues pas la bibliothèque pam elle-même, mais par des modules. Cette conception permet de faire fonctionner des authentifications spéciales sur des outils qui ne sont pas nécessairement conçus pour. En effet, tout le monde utilise le module pam_unix qui fournit les fonctionnalités d'authentification unix historiques, dont la gestion de /etc/shadow et /etc/passwd. Mais il existe bien d'autres modules aux fonctionnalités intéressantes que nous verrons par la suite.

La configuration de PAM

Chaque application utilisant pam est configurée séparément dans un fichier du répertoire /etc/pam.d. Bien sûr, pam autorise l'inclusion de fichiers communs pour vous faciliter la vie. Le format de ces fichiers est assez simple, il s'agit d'une succession de lignes :

# fonctionnalité   priorité   module       paramètres du module
auth               required   pam_unix.so  nullok_secure

Les priorités les plus courantes sont required et sufficient dont le sens est plutôt explicite. Vous pouvez obtenir un contrôle très fin en fonction des valeurs de retour de chaque module, tout ceci est expliqué en détail dans le man de pam.conf.

Les modules PAM

Nous avons donc fait appel à PAM pour savoir si cette personne dans son landspeeder est bien celle qu'elle prétend. La configuration associée au service stormtrooper nous indique qu'il faut contrôler ses papiers à travers le module "kivabien.so". C'est pam qui va se charger de lancer le module et faire appel à ses fonctions. Voyons donc les modules à notre disposition :

$ ls /lib/security/
pam_access.so     pam_filter.so         pam_listfile.so   pam_permit.so       pam_stress.so       pam_unix_session.so
pam_cracklib.so   pam_ftp.so            pam_localuser.so  pam_rhosts_auth.so  pam_succeed_if.so   pam_unix.so
pam_debug.so      pam_gnome_keyring.so  pam_loginuid.so   pam_rhosts.so       pam_tally.so        pam_userdb.so
pam_deny.so       pam_group.so          pam_mail.so       pam_rootok.so       pam_time.so         pam_warn.so
pam_echo.so       pam_issue.so          pam_mkhomedir.so  pam_securetty.so    pam_umask.so        pam_wheel.so
pam_env.so        pam_keyinit.so        pam_motd.so       pam_selinux.so      pam_unix_acct.so    pam_xauth.so
pam_exec.so       pam_lastlog.so        pam_namespace.so  pam_shells.so       pam_unix_auth.so
pam_faildelay.so  pam_limits.so         pam_nologin.so    pam_ssh.so          pam_unix_passwd.so

Wahoo il y a de quoi faire ! Et encore, on ne parle pas des modules non installés sur mon système dont on peut trouver une liste quasi exhaustive. Je vais vous en citer quelques uns particulièrement importants ou intéressants :

• pam_unix.so : l'indispensable, celui qui gère vos comptes
• pam_xauth.so : déjà présenté sur ce site il permet de faire fonctionner les application X après un su
• pam_cracklib.so : déjà présenté sur ce site permet de restreindre les mots de passe autorisés
• pam_ssh.so : déjà présenté sur ce site permet d'autoriser les connexions à partir de la passphrase ssh
• pam_ldap.so : pour s'authentifier sur un serveur ldap
• pam_time.so : limite les accès en fonction de la date et de l'heure
• pam_usbauth.so : pour s'authentifier avec une clé usb
• pam_chroot.so : pour chrooter l'utilisateur
• pam_mount.so : pour monter automatiquement un répertoire lors du login

Et maintenant, imaginez tout ce que vous pouvez faire en écrivant votre propre module pam : authentification par empreinte vocale, par webcam, par téléphone, par mail, par signature manuelle ou même pas la présence de votre portable a proximité.

Vous pouvez aussi à travers la partie session imaginer des actions spécifiques au login et logout d'un utilisateur comme monter un répertoire, lancer un avertissement sonore ou même lancer une machine virtuelle !

Amusez-vous bien, mais n'oubliez pas, une personne authentifiée n'existe pas pour autant pour tout le système. C'est à la bibliothèque nss de s'occuper de la liste des comptes ayant un nom dans le système. On en parle ici aussi.

On entend parfois parler dans les magazines d'information de l'arrivée imminente des connexions Internet par fibre optique, utilisant différentes techniques regroupées sous le nom de "FTTH" (fiber to the home, la fibre jusqu'à la maison). Enfin, imminente... apparemment les syndics de certains immeubles commenceraient à être contactés par les opérateurs. Mais ça reste assez limité, et réservé à quelques privilégiés. Pour les autres, ceux qui habitent dans les petites villes (moins de dix millions d'habitants), ça reste assez flou et on sait ni trop comment ça marche, ni quand ça sera réellement disponible.

C'est donc avec une certaine excitation que j'ai participé à une expérimentation pilote pour le déploiement de FTTH (dans sa variante FTTH-PY, pour ceux qui connaissent). Je n'ai pas pu tester en profondeur, faute de préparation préalable (mea culpa), je ne peux donc vous livrer que mes premières impressions.

D'abord, la disponibilité du matériel : impression très favorable de ce côté-là, on peut trouver les équipements d'émission/réception en grande surface sans problème (testé dans une seule grande surface, mais je ne pense pas que le Carrefour de chez moi soit plus spécialisé qu'un autre). Pour la fibre elle-même, c'est à peine plus compliqué, mais elle est elle aussi largement disponible dans les magasins spécialisés. Le prix est également très raisonnable, et le système est probablement parmi les moins chers du marché (il entre en concurrence directe avec les réseaux floppynet).

Pour la mise en place, c'est pas encore tout-à-fait plug and play, hélas. Les contraintes de courbure de la fibre imposées par le système de modulation font que la longueur de la fibre doit être calculée au millimètre près, et ne peut donc pas être connue à l'avance. Il faut donc prendre les mesures soi-même et couper la bonne longueur de fibre. De même, les terminaux étant génériques, ils peuvent s'adapter à plusieurs dimensions de fibre, et il faut les préparer à recevoir la bonne. Il faut également effectuer le raccordement proprement dit. Ça reste très accessible (pas besoin de pince à sertir ou d'outillage particulier), et le tout peut être réglé en quelques minutes, mais on espère que la standardisation aidant ça pourra être simplifié pour les versions finales.

Arrive le gros point noir : le FTTH-PY est censé, à terme, permettre de faire transiter plusieurs types de communications, que ce soit de la voix ou de la donnée, mais pour l'instant seule la voix est réellement opérationnelle. Il n'y a malheureusement pas encore de pilotes disponibles (ni sous Linux, ni a fortiori sous Windows ou Mac OS), et il faut donc passer par des systèmes de conversion des flux de données en signal sonore plus ou moins audible. L'avantage est que ce système de modulation-démodulation (oui oui, c'est un modem) peut être réalisé intégralement en logiciel, l'inconvénient est que les logiciels existants ne sont pas encore à un niveau de stabilité suffisant pour une utilisation réelle. Et même s'ils finissent par y arriver, les prévisions sont pessimistes quant aux performances. Je n'ai donc pas réussi à établir de connexion de données sur ma fibre, j'en suis très déçu. Je ne peux donc que vous transmettre les informations que l'on m'a données, à savoir que les performances attendues pour ce qui concerne les transmissions de données sont de l'ordre de celles obtenues en RFC1149 (IPoAC) pour ce qui concerne le débit et les taux d'erreur, mais sans les problèmes de latence variable. C'est prometteur, mais encore une fois, j'ai pas testé donc je peux pas confirmer.

J'ai donc principalement testé la voix, avec des résultats plutôt positifs. C'est un peu nasillard, mais on peut aisément reconnaître la voix de son interlocuteur. Et je n'ai à aucun moment rencontré les problèmes classiques des nouvelles solutions de téléphonie, notamment VOIP : pas d'écho, absolument aucun effet Larsen, pas de micro-coupure... Également, pour autant que ce soit réellement mesurable à l'oreille (je ne dispose pas de bancs de tests sérieux pour ce genre de mesures), il semble que le temps de propagation soit raisonnablement rapide, ce qui est particulièrement appréciable pour les conversations. En revanche, le signal semble perdre en puissance avec la distance. La longueur d'un brin de fibre sera donc calculée en conséquence. Pour les communications plus longues, il faudra mettre en place des répéteurs, mais la qualité du signal s'en ressent, la voix des interlocuteurs étant pas mal altérée voire rendue méconnaissable selon les répéteurs.

Je n'ai hélas pas pu pousser mes tests au-delà, et je ne peux donc vous donner que cet aperçu très partiel.

Mon verdict : de ce que j'ai pu en voir, le FTTH-PY me semble avoir encore du chemin à faire. Les applications de voix sont actuellement bien traitées, mais la transmission de données n'en est encore qu'à ses balbutiements, et je crains que les concurrents dans la course pour le marché FTTH n'aient déjà pris une avance trop importante. Ceci dit, il peut probablement subsister sur des marchés de niche, en raison de son très faible coût de mise en place et de maintenance. À titre d'exemple, un réseau point-à-point de deux postes peut être entièrement constitué pour le prix de deux pots de yaourt et de dix mètres de fil de pêche.

Pour terminer, je voudrais remercier Philippe, qui travaille chez l'opérateur télécom, pour m'avoir proposé de (et encouragé à) participer à cette expérimentation, et sans qui ce billet n'aurait pas été écrit.

Niveau :
Résumé : pam_tally

Aujourd'hui un conseil qu'il faut éviter de suivre. C'est pour vous éveiller l'esprit ;-) C'est aussi l'occasion de vous montrer qu'il ne faut pas prendre pour argent comptant ce qu'on trouve sur le net, il faut savoir faire correspondre à vos besoins réels les solutions toutes faites qu'on vous y propose (sauf ici bien sûr).

Nous allons donc étudier un module indispensable : pam_tally. Ce module est un module pam, c'est à dire générique à toute authentification sur unix (où presque, on me siffle dans l'oreille que slackware refuse l'utilisation de pam ...). Il permet de mettre en place une politique de limitation de tentatives d'accès.

Ça part d'une bonne idée, si vous faite 20 erreurs en tapant votre mot de passe, c'est probablement que vous êtes un méchant pirate qui tente de forcer la connexion. Par conséquent, on vous la coupe.

Comme tout plugin pam, il est presque facile a configurer :

# pam.d/common-auth
...
# deny=20 visons gros
# unlock_time=3600 si vous l'oubliez, vous risquez des ennuis
auth     required       pam_tally.so    deny=20 unlock_time=3600
...

Maintenant supposons que vous soyez vraiment un méchant pirate, quelle est la première chose que vous feriez ? 50 accès sur chaque compte que vous connaissez et hop, on rigole un coup devant Bob qui ne peut plus se connecter. Donc dans le cas de la connexion à distance c'est plutôt à l'application de faire un blocage par IP (et encore :-). Et dans le cas d'une application locale ("xscreensaver") ? Euh, vous n'avez jamais eu un ami qui vous a fait un blague sur votre poste ?

Finalement, ce plugin est-il inutile ?
Non : il a toujours son utilité, mais dans des cas très particuliers : dans votre carte de crédit, sur votre téléphone ... Son usage est en fait restreint aux applications dont on maîtrise (veut maîtriser) l'unique personne qui y a un accès physique.

Non : il peut aussi être légèrement détourné pour n'interdire que les tentatives de connexions en rafale sans vraiment bloquer l'utilisateur.

# pam.d/ssh
# lock_time=1 la fonctionnalité qui nous intéresse
auth     required       pam_tally.so   lock_time=1

Mais encore une fois, c'est à l'application de faire ceci en utilisant au mieux les données dont elle dispose (ip source, ...).

Yooooo,

Désolé pour ceux qui pensaient que ce site partait à l'abandon, ce n'est pas le cas, juste un ralentissement.

Tout d'abord, plusieurs personne m'ont rapporté une disparition de commentaires il y a une semaine ou deux. C'est probablement dû à une erreur de manipulation liée aux spams (hé oui, ils nous suivent à la trace). Donc pour information, j'ai désactivé totalement les trackbacks. Et si votre commentaire a disparu, repostez-le vous serez sympa.

Pour ceux qui ne seraient pas au courant, ce site a soufflé sa première bougie il y a quelques jours. Si vous vous ennuyez, relisez les premiers articles, je suis sûr que vous en avez oublié le contenu, et pourtant ils sont tout aussi intéressants que celui de la semaine dernière. En attendant un design plus adapté à la lecture linéaire des articles, vous devrez cliquer sur archives.

Ce site a aussi fêté son premier invité, vous l'aurez remarqué, le dernier article n'est pas de moi. J'aurais cru voir plus d'intérêt pour un post si passionnant ...

Et enfin, comme ne le veut pas la tradition, je vous dévoile le prochain sujet : un truc sur linux !

Iptables est un firewall très fiable remplaçant ipchains (avec le noyau 2.2) tournant sous Linux. Iptables permet de faire du firewalling stateful (à états), de la translation de port et d’adresse, du filtrage au niveau 3 et 4 du modèle OSI.

Iptables est l’interface d’administration et de configuration de Netfilter qui est le module intégré à Linux.

Iptables est donc intégré à Linux et sans doute il est déjà installé sur votre machine (noyau >= 2.4). Pour voir quelle version du noyau vous avez, faites un ‘uname -a’.

Avant tout,rappelons qu’un firewall est un dispositif de sécurité réseau qui se place en général au niveau des couches 3 et 4 du modèle OSI et il ne voit que ces couches, rien au dessus. Il est donc capable de savoir quel type de données il filtre (pages web, mails, streaming) en se basant sur les informations contenues dans les en-têtes de paquets IP.
Un firewall ne filtre donc pas les contenus réels des messages échangés, il ne fait donc pas la différence entre un mail contenant un virus et un mail normal, c’est le rôle d’un antivirus…

Tout d’abord, voici un peu de vocabulaire :

- Une règle est la brique de base permettant de fabriquer son firewall, en gros ce elle qui contient les descriptions et les actions… Le paquet est identifié (description) et il est analysé (actions) pour savoir si il peut continuer ou pas. Vous me suivez ?

- Une chaîne est une série de règles.
exemple de chaîne : INPUT : elle contient toutes les règles en entrée (up), c’est à dire tout ce qu’on m’envoie.

- Une table est un ensemble de chaînes
Il y a 3 tables principales :
-filter (contient les chaînes et règles de filtrage)
-nat (chaînes et règles NAT*)
-mangle (modifications arbitraires sur les paquets de tous les types)

*NAT : paquets qui veulent traverser une machine sans s’y arrêter (la machine filtrante n’est ni source ni destination)
Chaque règle que l’on créera contiendra une action :

Chaque règle contiendra une action :
- ACCEPT : le paquet filtré sera accepté
- REJECT : le paquet filtré sera rejeté, c’est à dire que la machine émettrice recevra de nous un paquet signifiant “port fermé”
- DROP : le paquet sera filtré “silencieusement”, la machine émettrice ne sait pas qu’il a été filtré par nous.

Voici les options principales de notre commande iptables :

-A chaîne : pour ajouter une règle en fin de chaîne
-I chaîne : pour insérer une règle en début de chaîne
-D n°chaîne : pour supprimer une chaîne n°
-P chaîne action : permet de donner la politique par défaut
-p : définit le protocole (tcp, udp, icmp…)
-dport : définit le port de destination (service que l’on émet)
-sport : définit le port source (service que l’on reçoit)
-s : @IP source
-d : @IP destination
-i : interface réseau empruntée par le paquet pour entrer sur la machine (seulement pour la chaîne INPUT)
-o : interface réseau de sortie (seulement pour la chaîne OUTPUT)
-m : utiliser le module spécial
-f : vider les règles
-x : vider les chaînes
-L : visualiser vos chaînes

Voici mon script iptables que je rend disponible librement ici, bien sûr, j’attends vos remarques et questions…

Plus de documentation sur ce site.

Qu'est-ce que c'est les backports ? Ce sont des programmes qui ne sont pas encore passés dans une version, mais qui seront inclus dans une prochaine version. Par exemple, le paquet mutt-patched n'est pas disponible sous Debian Etch mais il est disponible dans toutes les version suivantes de Debian. Activer les backports permet d'accéder à se paquet sans avoir à changer de version de Debian.

Éditez votre fichier /etc/apt/sources.list et ajoutez-y la ligne :

deb http://www.backports.org/debian etch-backports main contrib non-free

Faites ensuite :

apt-get update
apt-get install debian-backports-keyring
apt-get update

Le paquet debian-backports-keyring importe la signature du dépôt backports pour pouvoir garantir l'origine des paquets s'y trouvant.

Par défaut aucun programme des backports acceptera de s'intaller sans le demander explicitement avec l'option -t etch-backports. En reprenant l'exemple de mutt-patched plus haut :

apt-get -t etch-backports install mutt-patched

Vous pouvez (mais je ne vous le recommande pas) autoriser l'installation de tous les paquets des backports avec un fichier /etc/apt/preferences. Allez sur cette page pour plus de détails

J'espère que cela vous sera utile.

Il est assez facile d'installer Debian à partir d'une clef USB. C'est assez pratique pour installer un mini-PC qui n'a pas de lecteur de CD-ROM.

Les contraintes sont les suivantes :

• la machine doit devoir savoir booter depuis un disque USB,
• votre clef USB doit faire au moins 256Mo,
• vous devez avoir une machine vous permettant de manipuler votre clef USB.

Le principe est le suivant :

• vous allez rendre amorçable votre clef USB avec un mini système Linux,
• vous allez ajouter à la racine de votre clef USB une image d'installation de Debian.

C'est très bien expliqué sur la documentation de Debian à ce sujet mais je m'en vais résumer les opérations ici :

• téléchargez boot.img.gz,
• décompressez ce fichier sur votre clef USB (attention, cela va supprimer tous les fichiers sur la clef)
  Pour être sûr de connaître le bon périphérique (qui n'est pas focément /dev/sda), tapez dmesg | tail en console après avoir branché votre clef USB.

# zcat boot.img.gz > /dev/sda

• montez votre clef :

# mount /dev/sda /mnt

• copiez y à la racine une image ISO d'installation de Debian (par exemple la netinstall),
• démontez votre clef :

# umount /mnt

Si après ça votre machine cible refuse de démarrer depuis la clef USB, tentez la manipulation suivante :

# apt-get install mbr
# install-mbr /dev/sda

qui sert à réinitialiser le Master Boot Record de votre clef.

Bon courage !

Depuis la réinstallation de ma machine (depuis zéro), je n'avais pas remis en place de webmail. Avant, j'utilisais horde, bien connu des premiers utilisateurs de Free par exemple. C'est sûrement très puissant, mais j'utilise le webmail de façon extrêmement ponctuelle, quand je suis en déplacement dans un endroit qui ne laisse pas passer les connexions ssh. Il est aussi assez complexe à installer.

Mercredi, il y a deux semaines, je me suis retrouvé dans un tel endroit. Si j'ai un webmail fourni par mon travail, là, je voulais consulter une boîte à lettres spécifique de mon serveur ; ça n'allait plus du tout. J'ai rongé mon frein toute la journée, puis je suis revenu sur le problème ce matin. J'ai réussi à tout faire en moins de 30 minutes, tout compris, et sans avoir d'idée au préalable de ce qu'il fallait faire (je n'avais jamais lu la documentation du logiciel, à peine regardé les captures d'écran sur le site en question). Félicitations à Roundcube !

Au menu :

• La veille, préparer un petit nom de domaine spécifique pour ranger son webmail (par exemple, webmail.mondomaine.fr) en tapotant dans son navigateur préféré pour causer avec son gestionnaire de noms (on peut faire avec n'importe quoi d'autre, mais j'aime bien un nom pour un service). Laisser diffuser (toute la nuit).
• Créer un hôte virtuel. Recommencer parce qu'on se rend compte qu'on avait oublié de repasser super-utilisateur (jeter les morceaux non-utiles de la première tentative). J'ai un script qui me fait ça bien, en entrant le truc dans awstats, et me prépare tout ce qu'il faut.
• Éditer l'hôte virtuel pour qu'il agisse en SSL (https), parce que des mots de passe vont quand même être diffusés sur ce canal. Activer PHP5 pour cet hôte (j'ai une préférence pour l'activation avec FastCGI, me servant ponctuellement seulement de PHP ; moins d'encombrement mémoire quand je ne m'en sers pas, et possibilité d'utiliser les démons efficaces d'Apache).
• Générer un certificat qui accepte le nouveau nom webmail.mondomaine.fr en plus des autres.
• Redémarrer Apache. Vérifier qu'on obtient bien un fichier rangé dans la racine du nouveau domaine.
• sudo aptitude install roundcube et suivre les instructions. Il faut juste connaître le mot de passe de sa base de données (je le connaissais).
• Patauger cinq minutes pour être sûr de ce qu'il faut mettre. Se mettre dans la racine du nouveau domaine, et faire un for i in /var/lib/roundcube/*; do ln -s $i; done. Recopier un fichier de lancement de php5 depuis un autre répertoire.
• Pointer son navigateur sur https://webmail.mondomaine.fr/. Tester une première connexion. Tout marche. Constater que la connexion au serveur n'est pas en https, et qu'on ne peut pas du coup se connecter directement aux autres serveurs (celui de mon laboratoire, par exemple).
• Modifier une ligne de config/main.inc.php pour faire apparaître à la place $rcmail_config['default_host'] = array('ssl://monimap.mondomaine.fr','ssl://mail.monboulot.fr','ssl://monautreserveur.fr');. Laisser refroidir, c'est prêt.

Voici le fichier final dans /etc/apache2/sites-available/webmail.mondomaine.fr et juste derrière celui pour lancer FCGI :

<virtualHost *:443="">
DocumentRoot /var/www/webmail.mondomaine.fr/
ServerName webmail.mondomaine.fr
ErrorLog /var/log/apache2/webmail.mondomaine.fr/error.log
CustomLog /var/log/apache2/webmail.mondomaine.fr/access.log combined
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/oberon.mondomaine.fr.crt
SSLCertificateKeyFile /etc/apache2/ssl/oberon.mondomaine.fr.key
ServerAdmin monadresse@chezmoi.fr
AddDefaultCharset utf-8
DirectoryIndex index.html index.php
#  Uncomment to use PHP5
AddHandler fastcgi-script .fcgi
AddHandler php-fastcgi .php
AddHandler php5-fastcgi .php5
Action php-fastcgi /php5-wrapper.fcgi
Action php5-fastcgi /php5-wrapper.fcgi
</VirtualHost>

#!/bin/dash
PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=1000
export PHP_FCGI_MAX_REQUESTS
exec /usr/bin/php5-cgi

[Ajout] : J'ai dû aussi modifier une autre ligne, pour mettre $rcmail_config['create_default_folders'] = TRUE;. Sinon, je ne pouvais pas effacer les messages.

Comme c'est le calme plat en ce moment sur ce blog^[1], je vais suivre l'exemple de Grégory Colpart et retranscrire ici une migration Sarge -> Etch^[2].

Le serveur en question est un serveur dédié au logiciel libre d'inventaire OCSInventory-NG, c'est donc tout simplement une combinaison de serveur web Apache, de serveur de base de données MySQL, de PHP et de Perl. La vraie particularité (et seule ?) de ce serveur est celle d'être un serveur virtuel Xen.

Une fois le fichier /etc/apt/sources.list édité pour y ajouter les sources de etch, un

# aptitude update
# aptitude dist-upgrade

a suffi pour lancer la migration.

Quelques petits problèmes se sont néanmoins présentés :

• Apache ne voulait pas se lancer et j'avais une erreur

[Tue Mar 18 11:40:40 2008] [error] Can't locate Apache/compat.pm in @INC.....
[Tue Mar 18 11:40:40 2008] [error] Can't load Perl module Apache::Ocsinventory for server...

dans mes logs Apache. Il faut alors éditer le fichier de configuration OCS pour Apache (/etc/apache2/conf.d/ocsinventory.conf chez moi) et modifier la ligne

PerlSetEnv OCS_MODPERL_VERSION 2

Explication : la migration m'a fait passé de apache à apache2 et de libapache-mod-perl (version 1.x) à libapache2-mod-perl2 (version 2.x)

• j'ai eu quelques problèmes avec MySQL qui ne voulait pas redémarrer, j'en ai donc profité pour migrer de mysql-server-4.1 à mysql-server-5.0 sans problème (à part que le serveur phpmyadmin permettant de gérer les divers serveurs mysql n'a pas le paquet mysql-client-5.0... pour l'instant)

• je suis également passé de php4 à php5 sans problème non plus.

Rien de particulier donc. J'ai fait rebooter mon serveur virtuel au cas où, et j'avais, par sécurité, fait une copie de mon serveur virtuel (stocké sur LVM) avant la migration pour le cas où celle-ci se passerait mal. Au final, moins de 2h de maintenance, et moins d'une 1/2 heure - 1 heure je pense, pour ce serveur.