Avec l'expansion pandémique de "services" comme Google Analytics, les moyens de se prémunir des SpyWebs prennent de plus à en plus d'importance. Et si des outils comme adBlock offre une très protection locale efficace, la protection d'un réseau dans son entier ne peut se passer de privoxy, un proxy filtrant aux possibilités étonnantes et disponible sur beaucoup de systèmes de Windows à Linux en passant par AmigaOS.

Dés que l'on veut partager un dossier sous UNIX, se pose le problème des droits. Car autant il est simple de coller tout le monde dans un groupe, autant cela se complique lorsque les utilisateurs créent leurs propres fichiers, qui par défaut leur appartiennent, et qui du coup ne sont plus modifiables par les autres. Ce petit tutoriel permet de se sortir de cette situation par une technique que je viens découvrir et qui est d'une telle simplicité que cela prouve une fois de plus qu'avec UNIX, on a jamais fini d'apprendre.

Cela fait maintenant longtemps que je bricole avec trois écrans. A l'origine il s'agissait "juste" de deux cartes vidéo collées dans la même bécane, puis ce fût deux machines différente histoire de "rentabiliser" la consommation électrique de mon serveur local. Aujourd'hui le serveur a disparu au sous-sol pour être remplacé par l'U810 sur sa station d'accueil. Dans tous les cas c'est la même problématique : deux bureaux différents qui doivent communiquer de manière suffisamment transparente pour donner l'illusions de former un seul et même espace.

Un problème récurent en PHP est de trouver le bon chemin qui mène à la bonne ressource. Qui ne s'est jamais demandé comment inclure le fichier toto.inc qui se trouve pourtant si près et pourquoi une fois que ça marche, tout se casse la figure dés que l'on touche à Apache... Et avec Drupal, le casse-tête prend une dimension de plus avec les modules, les thèmes, les fichiers attachés, les fichiers temporaires, etc. L'objectif de ce tutorial vise donc simplement à éviter de paumer ses petits.

Un domaine doté d'un nombre impressionnant d'outils libres est celui de la sauvegarde. Et pourtant, lorsque l'on fait tourner sa petite toutouille perso, des monstres comme Amanda font l'effet de massues à écraser les mouches. L'objectif de ce billet est donc le même que ça précèdent version : permettre de faire nos sauvegardes en tout simplicité, en mettant en oeuvre des concepts professionnels (synchronisation distante, mirroring, historisation) mais simplement armé des outils basiques que sont rdiff-backup, ssh.

Difficile de se passer d'un planificateur de tâche, que ce soit pour faire des sauvegardes, vérifier l'intégrité des systèmes, faire le ménage ou bêtement se réveiller le matin. Sous UNIX, le temps c'est le domaine du vénérable CRON.

Nagios est un formidable outil permettant de gérer d'immenses parcs de machine, d'afficher des plans d'architecture, des rapports d'erreurs, etc. Maintenant lorsque l'on a dans son "parc" personnel deux pauvres serveurs qui se battent en duel, passer des heures à paramétrer et maintenir un tel système n'est pas forcement rentable.

L'objectif de cet article n'est absolument pas de générer un peu plus de trollisme sur l'éternel débat Gnome vs KDE. Si vous êtes heureux avec KDE, nous sommes heureux pour vous car nous l'étions aussi il n'y a pas si longtemps. Nous ne sommes pas tous conçus pour tous porter des bottes rouges, ni pour tous utiliser la même distribution et encore moins le même bureau. Notre idée ici est simplement de permettre aux KDEistes qui le désirent de passer en douceur à Gnome. Et lorsque je dis Gnome, je devrais plutôt dire Gtk2 (vs Qt) car au fond, la majorité de ce qui est dit ici, fonctionnera aussi bien par exemple sous XFCE. Espérant donc que ce condensé d'expériences à quatre mains vous sera utile.

PAM, le système d'authentification centralisé de Linux même s'il n'est pas parfait, a le mérite de mettre d'accord la majorité des applications sur un mécanisme commun de gestion des crédits utilisateurs tout en restant étonnamment évolutif. L'objectif de ce billet est juste un premier dégrossissage de la manière dont PAM fonctionne et de ce qu'il est possible d'en faire.

La mise en oeuvre d'un kernel monolithique peut, à juste titre, rebuter par sa complexité. Et même si cette technique reste le meilleur moyen d'optimiser un kernel, il est malgré tout possible d'opter pour une approche plus douce en s'attaquant directement à initrd.