M'intéressant de plus en plus à la sécurité informatique, je suis tombé sur cette distribution qui a fait mon bonheur : Damn Vulnerable Linux. Cette distribution a été créée dans le but de la pirater. Pas banal n'est-ce-pas ?

Allez, lisez la suite si vous voulez en savoir plus :)

I. Qu'est ce que c'est ?

Puisque c'est très bien expliqué sur le site officiel de la distribution, je vais me contenter de traduire la description qu'ils en font :)

Damn Vulnerable Linux (DVL) est tout ce qu'une bonne distribution Linux n'est pas. Ses développeurs ont passé des heures à la configurer avec des logiciels "cassés", mal configurés, non mis à jours, ce qui les rends donc exploitables et piratables. DVL n'est pas conçu pour tourner en tant que poste de travail, c'est un outil d'apprentissage de la sécurité informatique.

"L'idée principale de DVL était de faire un système d'entrainement utilisable pour mes cours à l'université. Mon but était de faire un système Linux le plus vulnérable possible, de manière à enseigner des cours tels que le code engineering, le buffer overflows, le développement de code, l'exploitation Web et l'injection SQL"

II. Qu'est-ce-qu'il contient ?

DVL est basée sur la distribution BackTrack 2.0, c'est un LiveCD disponible en ISO de 1,8 Go. Il contient des vieilles versions (facilement cassables) de Apache, MySQL, PHP, FTP et SSH ainsi que des outils disponibles pour vous aider à compiler, débugger et casser les applications utilisant ces services (GCC, GDB, NASM, strace, ELF Shell, DDD, LDasm, LIDa, etc.).

DVL a été créé par des pointures du hacking, telles que la communauté de www.Reverse-Engineering.net et Crackmes.de. Il contient également des tonnes de cours très détaillés incluant des exercices et leurs solutions si elles ont été trouvées par un membre de Crackmes.de

III. Exemple

Voici un petit exemple en vidéo qui montre DVL et plus précisément une attaque de type injection SQL sur un blog Wordpress.

IV. Téléchargement

Vous pouvez télécharger la dernière version (1.5) en ISO sur le site officiel (c'est un fichier torrent, donc faites comme moi, seedez :))

Bien entendu, je vous conseille d'utiliser une machine virtuelle pour faire tourner cette distribution. De cette manière, même si votre machine virtuelle est accessible depuis l'extérieur et est corrompue, seule cette dernière sera menacée, pas votre système hôte (avec vos données). Pour ma part, j'utilise VirtualBox.

N'hésitez pas à me dire si vous comptez utiliser cette distribution et si vous le faites, dites-moi ce que vous avez déjà réussi à faire avec ;) Pour ma part, je viens de finir de la télécharger, je m'y mets dès que j'ai 5 minutes (entre 2 cours de Java quoi) :)

See Ya folks !

Je suis actuellement en train de faire les épreuves de Newbie Contest, site que je vous conseille chaudement si vous voulez vous amuser à résoudre des énigmes de logiques ou à maitriser un peu plus la sécurité informatique :

Nous vous proposons une série de challenges regroupant plusieurs domaines allant de l'exploitation de failles aux crackmes, en passant par la stéganographie, la cryptographie, la programmation... et ceci dans la plus totale légalité !

Le staff NewbieContest

Bref, pour un challenge en particulier, il est nécessaire d'exécuter une applet Java dans notre navigateur web. Par défaut, Firefox ne sait pas interpréter cet applet et vous avez droit à une petite erreur.

Pour corriger cela, pour la version 10.04 d'Ubuntu, il vous suffit d'exécuter cette commande et de redémarrer Firefox :

sudo apt-get install icedtea6-plugin

Pour les versions antérieures, il faut utiliser cette commande :

sudo apt-get install sun-java6-plugin

=> Ce package est un plugin pour les navigateurs web basé sur OpenJDK et IcedTea pour exécuter les applets Java.

Enjoy !

Ajout de freechelmi (merci) :

Ça marche très bien l'installation auto, quand je visite ce lien, j'ai bien une invitation a installer le plugin et IcedTea est le seul choix donc plus simple qu'autrefois, plus de SunJava6 (mais IcedTea = Java 1.6 aussi)

pfSense est une distribution open source (licence BSD) gratuite pour transformer un pc en pare-feu. La base du système est FreeBSD, et pfSense est un fork de mOnOwall.

Cet article est juste une présentation de pfSense, je ne rentrerai pas dans les détails de l'installation et de l'utilisation.

J'ai découvert pfSense il y a quelques mois, au travail, et j'ai récemment mis en place une machine sous cette distribution pour fournir un pare-feu et des services réseaux (DHCP, port forward,...).

pfSense à été crée en 2004 comme un fork du projet mOnOwall, pour viser une installation sur un PC plutôt que sur du matériel embarqué. pfSense est basée sur FreeBSD, en visant les fonctions de firewall et routeur.

pfSense est puissante, en bonne partie car elle est basée sur FreeBSD, mais aussi assez simple d'accès, car elle fournit une interface web pour la configuration, (en plus de l'interface console). Je recommande quand même de connaitre les commandes basiques de FreeBSD en mode console, au moins pour  pouvoir récupérer la configuration en cas d'erreur (par exemple une mauvaise route qui vous empêche de joindre le firewall...). Cette interface web n'est accessible par défaut qu'à partir du LAN.

L'installation est relativement simple et entièrement en console. Après l'installation des questions sont posées pour créer une configuration rapide des interfaces réseaux à assigner.

pfSense ne fait pas seulement firewall, elle offre toute une panoplie de services réseaux. Je vais vous en présenter un partie, celles que j'ai utilisés ou qui me semblent intéressantes.

• Pare-feu : indispensable pour une distribution "firewall" ;). Le firewall est celui de FreeBSD, à savoir PacketFilter.
• Table d'état : La table d'état ("State Table") contient les informations sur les connexions réseaux. Cela permet d'avoir un aperçu des connexions et surtout de créer des régles par exemple sur le nombre de connexion maximum pour un hôte.
• Traduction d'adresses réseaux (NAT) : Permet de joindre une machine situé sur le LAN à partir de l'extérieur.                                  
• VPN : permet la création de VPN IpSec, OpenVPN ou PPTP.
• Serveur DHCP.
• Serveur DNS et DNS dynamiques.
• Portail Captif.
• Redondance et équilibrage de charge.
• Graphes pour la charge système et réseaux.

Les logiciels s'installent grâce à un système de paquet. Il sont configurés pour s'intégrer à l'interface web. Dans les paquets il y a par exemple nut (pour le monitoring des onduleurs) et FreeRADIUS.  Le nombre de paquets  augmente régulièrement. Il est aussi possible d'installer d'autres paquets que ceux proposés par l'interface, en ligne de commande.

J'apprécie beaucoup cette distribution pour sa mise en œuvre rapide, facile et efficace. Le développement est régulier et se base sur les avancées de FreeBSD. De plus elle permet une maintenance et des évolutions faciles.

Par contre une partie de la configuration est dans des fichiers propres à pfSense, ce qui rend plus délicat les modifications à partir de la console.

Site Officiel.

Screenshots.

Ce titre n'est peut-être pas très explicite, qu'est-ce que "dokuwiki", qu'est-ce qu'une "ferme", qu'est-ce que "créer" ?

Cet article va vous présenter ce qu'est dokuwiki, pourquoi je pense que c'est le meilleur moteur de wiki libre, ce qu'est une ferme de wikis et comment faire une ferme de dokuwikis.

I. Pourquoi Dokuwiki ?

DokuWiki est un moteur de wiki libre distribué sous licence GNU GPL créé par Andreas Gohr en juin 2004. Contrairement à la plupart des autres moteurs de wiki, Dokuwiki stocke ses données dans des fichiers textes sur la machine, aucune base de données n'est donc nécessaire (ce qui est, pour moi, un atout non négligeable et très appréciable) !

La dernière version de dokuwiki est disponible sur le site officiel.

Un autre gros avantage de Dokuwiki est sa grande communauté de contributeurs. En effet, dokuwiki est tellement souple que beaucoup de monde à décidé de développer dessus. Par exemple, si vous allez voir sur la page officielle des plugins, vous pourrez vous rendre compte qu'il y en a énormément (570 à l'heure où j'écris ces lignes), pour tous les goûts, du plus utile au plus futile :)
L'installation d'un plugin est également très pratique : tout est contenu dans un répertoire, donc pour supprimer un plugin, il vous suffit de supprimer ce répertoire. Rien ne reste, pas de configuration orpheline, pas de fichiers temporaires, pas d'inclusion dans d'autres fichiers, etc. De plus, tout est faisable via l'interface web d'administration de Dokuwiki.

Un autre avantage qui à été décisif pour l'adoption de Dokuwiki dans mon travail : ses très nombreux modes d'authentification. En effet, comme je vous l'ai dit, ce logiciel est tellement souple que la communauté à créé un grand nombre de modules d'authentification. Au programme, en plus des comptes locaux, vous pouvez vous identifier sur Dokuwiki via MySQL, LDAP, pgSQL, punbb, CAS, drupal, htaccess, radius, pam, shibboleth, imap, xmpp, etc. Vous pouvez coupler toutes ces authentifications, les utiliser séparément, et tout un tas d'autres méthodes.

Pour la petite histoire, dans mon travail (DSI de l'Université Nancy 2), j'ai mis en place une authentification qui peut-être différente en fonction des fermes parmi CAS, comptes locaux, shibboleth, le tout couplés ou séparément.

Bref, je pourrais m'étendre encore longtemps sur les vertus de ce moteur de wiki mais pour résumer, je peux dire qu'il s'agit d'une vraie mine d'or :)

II. Qu'est-ce qu'une ferme de wikis ?

Voici en l'arborescence simplifiée d'un répertoire Dokuwiki :

|_conf (répertoire de configuration du wiki)
|_data (contient les données du wiki comme les pages, les images, les documents joints, etc.)
|_lib (contient les plugins, les templates du wiki)
|_inc (contient les fichiers de langue, les modules d'authentification, etc.)

Admettons que vous souhaitez héberger plusieurs wikis sur une machine (par exemple 24 wikis). Avec un système de wiki "classique", il faudrait 24 répertoires avec 24 répertoires conf, data, lib, inc, etc., il faudrait installer 24 fois les mêmes plugins, 24 fois les mêmes modules d'authentification et faire 24 mises à jour si besoin est.
Bref, un vrai calvaire (surtout quand on dépasse les 50 wikis) !

Le principe des fermes est le suivant :

Il y a un répertoire maître qui contient tous les modules, tous les plugins, tous les templates et après, pour chaque nouveau wiki, il y a un répertoire contenant un sous-répertoire conf (qui contiendra la configuration de chaque wiki) et un sous répertoire data (qui contiendra les données de chaque wiki). C'est tout. Chaque wiki (appelé aussi animal) ira chercher des modules, ses templates, ses librairies dans le répertoire maître.

Au final, nous obtiendrons donc une arborescence de ce type :

|_master
  |_lib
  |_inc
|_wiki1
  |_conf
  |_data
|_wiki2
  |_conf
  |_data
|_wiki3
  |_conf
  |_data

Plusieurs gros avantages à cela :

• Limitation de la place occupée sur le disque dur : nous n'avons plus 50 fois le même répertoire lib/ ou inc/
• Facilité de maintenance : il suffit d'installer une seule fois un plugin sur le wiki master pour que tout le monde y ai accès, de même, il suffit de mettre à jour un plugin ou même l'intégralité de Dokuwiki uniquement sur le master pour que les changements soient appliqués à tous les animaux.
• Une création rapide : pour créer un nouveau wiki, on utilise un script (fourni ci-dessous) auquel on passe en paramètre le nom du wiki. En clair, dans un terminal on tape ./addanimal.sh wiki4 et tout est créé automatiquement !

III. Comment mettre en place une ferme de wikis avec DokuWiki ?

1. Introduction

Avant tout, il faut savoir qu'il existe deux "types"de fermes de wiki :

1. Une version avec des wikis accessibles via ce genre d'URL : monsite.fr/wiki1, monsite.fr/wiki2, etc. (c'est cette version que je présenterai ici)
2. Une version avec des URL du type cname (wiki1.monsite.fr, wiki2.monsite.fr, etc.)

Dans cet article, je vais parler de la première solution. Pourquoi ? Tout simplement parce que c'est cette solution que j'ai du mettre en place à mon travail et que je maîtrise donc le mieux.

De plus, sachez que je ne parlerai que d'une authentification via les comptes locaux de dokuwiki (afin de ne pas tout embrouiller). Pour info, dokuwiki est extrêmement complet au niveau des modules d'authentification. Par exemple, à mon travail, j'ai mis en place une authentification plain (compte locaux) ainsi que LDAP, CAS et Shibboleth.

2. Préparation

Rendez-vous sur la page de téléchargement officielle de dokuwiki et téléchargez la dernière version. Ensuite il faut extraire cette archive en tant que dossier master sur votre serveur.

Note : Ici, j'appelle mon répertoire principal "master" mais vous pouvez l'appeler autrement, il faut juste le renseigner dans les différents fichiers de configuration. De plus, je pars du principe que vous utilisez une arborescence comme celle-ci (avec, pour document root : /var/www/wiki/php):

|_var
  |_www
    |_wiki
      |_addanimal.sh
      |_php
        |_master
          |_lib
          |_inc
        |_wiki1
          |_conf
          |_data
        |_wiki2
          |_conf
          |_data

• Nous avons donc notre répertoire master, créez un fichier ./master/inc/preload.php et copiez-y ces lignes :

<?php
// the home directory for all animals and the farmer located in subdirectories
$farmdir = '/var/www/wiki/php/';
 
// don't do anything if the animal doesn't exist
if(isset($_REQUEST['animal'])) {
    if(!is_dir($farmdir . $_REQUEST['animal'])) {
        nice_die("Ce wiki n'existe pas !");
    }
    if($_REQUEST['animal']=="master") {//si on appelle le master
    nice_die("Interdit d'appeler le master");
    }
    if(!defined('DOKU_CONF')) {
        define('DOKU_CONF', $farmdir . $_REQUEST['animal'] . '/conf/');
    }
    //  correct paths according to animal and make nice looking in HTML source
    if(!defined('DOKU_URL')) define('DOKU_URL',preg_replace('/(.+)\/([^\/]+)\//','$1/'.$_REQUEST['animal'].'/',getBaseURL(true)));
    if(!defined('DOKU_REL')) define('DOKU_REL',preg_replace('/([^\/]+)\/\/([^\/]+)\/(.+)\//','/$3/',DOKU_URL));
 } else {
    // don't do anything on the farmer instance
    return;
}

• Ensuite, il faut créer un fichier .htaccess dans le répertoire wiki contenant ceci :

#Définition des règles de redirection
RewriteEngine On
RewriteRule index - [L]
RewriteRule ^([^/]+)/(.*) /home/www/wiki/php/master/$2?animal=$1 [QSA,L]
RewriteRule ^([^/]+)$ http://wiki.votre-site.fr/$1/ [QSA,L]

• Enfin, il vous faut créer un fichier addanimal.sh (ou n'importe quel autre nom) que vous placerez dans /var/www/wiki/ (pas dans le répertoire php, de manière à ce que le serveur apache n'ai pas accès à ce fichier). Voici le fichier addanimal.sh pour des comptes locaux :

#!/bin/bash
#
# Création d'animal pour une ferme dokuwiki
# benjamin@generation-linux.fr - 10/12/09
#
 
MASTER_DIR=/var/www/wiki/php/master
FARM_DIR=/var/www/wiki/php
 
if [ $# -ne 1 ]; then
    echo "Usage: $(basename $0) [animal_name]"
   exit 1
fi
 
if [ ! -d $MASTER_DIR ]; then
    echo "ERREUR : $DOKUWIKI n'existe pas !"
    exit 1
fi
 
if [ ! -d $FARM_DIR ]; then
    echo "ERREUR : $FARM_DIR n'existe pas !"
    exit 1
fi
 
 echo ">> Ajout de la ferme $1" 
  FARM=${FARM_DIR}/$1
  FARM_TITLE=$1
 
if [ -d $FARM ]; then
    echo "ERREUR : $FARM existe deja !"
    exit 1
fi
 
 echo ">> Creation des repertoires"
mkdir -p ${FARM}/{data,conf}
chmod 755 ${FARM}/{data,conf}
cp -a ${MASTER_DIR}/data/* ${FARM}/data
cp -a ${MASTER_DIR}/conf/* ${FARM}/conf
find ${FARM}/data -type d -exec chmod 755 {} \;
touch ${FARM}/conf/{local.php,local.protected.php,acl.auth.php,users.auth.php}
chmod 666 ${FARM}/conf/{local.php,acl.auth.php,users.auth.php}
 
 echo ">> Creation des fichiers de configuration"
  echo "<?php
  \$conf['title'] = '${FARM_TITLE}';
  \$conf['lang'] = 'fr';
  \$conf['savedir']     = '${FARM}/data';
  \$conf['useacl'] = 1;
  \$conf['template']    = 'nancy2';
  \$conf['plugin']['sidebar']['enable'] = 1;
  \$conf['authtype'] = 'plain';
  \$conf['superuser'] = '@admin';" > ${FARM}/conf/local.php
 
 echo ">> Creation des comptes admin"
  echo "# <?php exit()?>
  admin:d51ba34ef116c2cffacfa2125b87e6b5:Administrateur:votre@mail.fr:admin,user" > ${FARM}/conf/users.auth.php

 
echo ">> Mise en place des permissions"
echo "# <?php exit()?>
* @admin 255
* @ALL 1" > ${FARM}/conf/acl.auth.php
 
 
chown -R apache2:apache2 ${FARM}
echo ">> Ferme $1 installee !"
 
exit 0

Note : Attention à l'antépénultième ligne, j'ai mis apache:apache car je suis sous RedHat, sous Ubuntu et Debian cela doit être www-data:www-data et peut-être d'autres noms sous d'autres systèmes.

Il ne vous reste plus qu'à rendre ce fichier exécutable grâce à cette commande : chmod +x /var/www/wiki/addanimal.sh

Pour créer un nouvel animal, il suffit de taper : ./addanimal.sh nom_animal

Simple non ? :)

3. Personnalisation

Afin de supprimer les liens dans l'administration (gestion des plugins, gestion de la configuration, gestion des réversions, etc.), il faut créer des fichiers disabled dans chaque répertoires :

• touch /home/www/projets/wiki-dsi/php/master/lib/plugins/plugin/disabled
• touch /home/www/projets/wiki-dsi/php/master/lib/plugins/revert/disabled
• touch /home/www/projets/wiki-dsi/php/master/lib/plugins/config/disabled
• touch /home/www/projets/wiki-dsi/php/master/lib/plugins/popularity/disabled

4. Conclusion

Ainsi s'achève ce tutoriel sur la mise en place d'une ferme de wikis avec Dokuwiki. Comme vous avez pu vous en rendre compte, cela est très simple à mettre en œuvre et s'avère très pratique pour les fans de wikis (moi même j'en utilise plusieurs régulièrement).

Pour la petite anecdote, voici un screenshot de mon wiki au boulot (c'est moi qui ai fait le design à partir ce celui-ci) :

De plus, je vous met à disposition le (petit) diaporama de ma présentation de cette solution : presentation-DW.pdf.

Pour ceux que ça intéresse, je vais bientôt mettre en place ce système sur mon serveur pour offrir à qui le souhaite son ou ses wikis rapidement et gratuitement. Si cela vous intéresse, n'hésitez pas à me le faire savoir ;)

Pour tout ceux qui souhaitent avoir un agenda toujours à porté de main, voici un outil bien pratique qui fonctionne en ligne de commande. Vous aurez accès à un calendrier en moins de deux, avec vos événements de surplus ! Voyons tout cela de plus près ...

Rédigé par Plonstic (que j'ai contacté suite à son commentaire, merci à lui !)

Avant propos :
Cet article contient quelques lignes de code. En tant qu'auteur j'ai pris soin de les vérifier sur mon système. Cependant, dans votre cas, il se peut que certains résultats ne soient pas ceux escomptés.
De manière générale, il faut TOUJOURS vérifier les lignes de code que l'on vous fait exécuter (c'est la première faille des OS ;D). Les risques restent toutefois limités, car rien n'est fait en root ici.
Toutes les actions peuvent être effectuées graphiquement (décompression d'archive, édition de fichiers, etc.). Pour des raisons "d'universalité" j'ai préféré présenter les lignes de commandes (de toute façon c'est un calendrier en ligne de commandes !)
Bonne lecture...

Présentation

pal est un calendrier en ligne de commande qui affiche des événements à la manière de la commande cal des distributions UNIX, de gcal de GNU ou de calendar des distributions BSD.

Les avantages :

• Un calendrier avec mise en évidence des jours auxquels sont associés un/des événements
• Organisation des événements par type et couleurs
• Recherche d'événements par expressions régulières
• Prise en charge des événements officiels (vacances, saints, journées historiques, etc.)
• Les événements peuvent être ponctuels ou répétitifs (quotidiens, hebdomadaire, mensuels, annuels) avec date de début et date de fin
• Ajout des événements en ligne (option -m ) ou en externe (éditions de fichiers)
• Exportation en HTML ou LATeX.

Les inconvénients :

• Ne peut pas récupérer les événements sur internet
• N'est pas compatible vcal
• En ligne de commande (hum mais c'est l'intérêt ça, non ?!)

Mais ça peut se faire avec des scripts (ce n'est pas expliqué ici).

1. Installation

Pour les distributions Debian ou Ubuntu, on installera le paquet pal :
sudo aptitude install pal


Pour les autres, vous trouverez les sources ici.

2. Utilisation

2.1. Lancement

2.2. Édition

2.3. Recherche

2.4. Exportation

Note : l'option -c permet de spécifier le nombre de "lignes"
(exemple)

2.5. Autres

3. Configuration

Le dossier de configuration de pal pour les utilisateurs est .pal/ dans votre home ($HOME/.pal/).

3.1. Fichier de configuration pal.conf

Pour éditer les préférences de pal (nombre de lignes, jour du début de semaine, etc.), il faut éditer le fichier pal.conf

Avant tout, on part du fichier de configuration par défaut que l'on copie dans le dossier de configuration personnel :
cd
mkdir .pal
cp /etc/pal.conf ~/.pal/


Puis on l'édite avec un éditeur de textes (ici nano car il est fourni par défaut en général) :
nano ~/.pal/pal.conf


Le fichier étant très bien commenté, je vous laisse le parcourir et adapter pal comme bon vous semble.
Notons tout de même les lignes commençant par 'file'. Elles permettent d'ajouter des événements contenus dans des fichiers externes. Ces fichiers d'événements, par défaut, sont pour les États-Unis, commentez/supprimer toutes les lignes qui ne vous intéressent pas.

3.2. Fichiers d'événements

Les fichiers d'événements permettent de définir en externe des événements. Ils vont être plus pratiques que l'option -m pour ajouter un grand nombre d'événements au calendrier.
Pour vous montrer comment ça marche, on créera un fichier d'événements pour les jours notables en France (nouvel an, fêtes nationales, etc.).

Commençons par télécharger des définitions d'événements (bsdcalendar), ce qui nous facilitera la tâche :
cd /tmp #on se met dans le dossier temporaire
# téléchargement
wget http://downloads.sourceforge.net/project/bsdcalendar/bsdcalendar/0.9/bsdcalendar-0.9.tar.bz2?use_mirror=freefr
tar -xvjf bsdcalendar-0.9.tar.bz2 #décompression


Ainsi, le dossier /tmp/caledar/calendars/fr_FR.ISO-8859-1 contient des fichiers d'événements dont il nous faudra adapter le contenu pour pal.
Copions le fichier calendar.jferies dans le dossier de configuration de pal :
cp /tmp/calendar/calendars/fr_FR.ISO-8859-1/calendar.jferies ~/.pal/

Dans un premier temps, il faut changer les commentaires. En effet, les commentaires de pal sont des lignes commençant par #, tandis qu'ils sont délimités par /* ... */ dans le fichier que l'on a :
sed -i 's/^[ \t]*\/\?\*\/\?/#/' ~/.pal/calendar.jferies
sed -i 's/LANG/#LANG/' ~/.pal/calendar.jferies


Ensuite, pal définit les événements récursifs en mettant des zéros (0) pour les années (événement annuels) et pour les mois (événement mensuels) :
sed -i 's:\([0-9][0-9]\)/\([0-9][0-9]\)\*\?:0000\1\2:' ~/.pal/calendar.jferies


Continuons avec les événements référencés par rapport à Pâques (Easter). pal utilise le mot clé 'Easter' pour référencer par rapport à Pâques.  'Easter+nnn'  définit  un événement intervenant  nnn jours après Pâques (il faut mettre 3 chiffres) :
sed -i 's/Easter+\([0-9]\)[ \t]/Easter+00\1\t/' ~/.pal/calendar.jferies
sed -i 's/Easter+\([0-9][0-9]\)[ \t]/Easter+0\1\t/' ~/.pal/calendar.jferies


Occupons nous maintenant de la fête des mères (dernier dimanche de mai), celle des pères (troisième dimanche de juin) et les changements d'heures.
pal permet de définir un événement qui intervient le Nième jour d'un mois avec '*mmnd'. 'mm' est le mois (10 pour octobre), 'd' le jour (1=lundi, 7=dimanche).
Exemple : *0547  (06=mai; 4="quatrième";  7=dimanche  ==> dernier dimanche de mai).
On fait la modif avec :
sed -i 's/May Sun+2/*0547/' ~/.pal/calendar.jferies
sed -i 's/June Sun+2/*0637/' ~/.pal/calendar.jferies
sed -i 's:03/SundayLast:*0347:' ~/.pal/calendar.jferies
sed -i 's:10/SundayLast:*1047:' ~/.pal/calendar.jferies


Il faut aussi définir, en début du fichier, les caractères d'affichage des événements (de par et d'autre de la date) et leur type. Pour cela on ajoute en première ligne : 'FR France' où 'FR' sont les caractères d'affichage et 'France' le type :
sed -i '1i\FR France' ~/.pal/calendar.jferies


Pour que les caractères accentués soient acceptés par pal il est nécessaire de convertir le fichier en utf-8 avec iconv (paquet du même nom sous Débian et dérivés)
iconv -f ISO8859-1 -t utf-8 ~/.pal/calendar.jferies calendar.jferies >temp
mv temp ~/.pal/calendar.jferies


Enfin on ajoute le fichier d'événements dans pal.conf pour qu'il le prenne en compte :
sed -i '1i\file calendar.jferies (magenta)' pal.conf


Il ne vous reste plus qu'à créer vos propres fichiers d'événements (pour les anniversaires c'est bien pratique :D).
N'oubliez pas de regarder le manuel de pal pour plus d'information (je n'ai pas tout décrit ici).

4. Conclusion

Voili, voilou, vous connaissez un nouveau logiciel bien sympathique.
J'ai essayé de vous montrer l'essentiel des fonctionnalités et configurations. Il en reste encore donc n'hésitez pas à consulter le manuel (je sais, je me répète, mais il y a tout dedans, ça évite les questions inutiles ...).

Vous pouvez l'ajouter dans votre .bashrc pour l'avoir au démarrage des terminaux.
Je vous conseillerai de ne pas trop abuser des événements (les saints et autres proverbes), ça devient vite ennuyeux et on ne voit plus l'essentiel. Mais bon, je dis ça, c'est à vous de voir !

Il existe d'autres calendriers en ligne de commande (voir le haut de l'article) et graphiques (je vous laisse le plaisir de chercher avec votre moteur de recherche favori :D).

À plus ..!

Voici aujourd'hui une petite astuce que j'utilise très régulièrement et que je souhaitais partager avec vous : avoir, en une seconde, un calendrier entier dans votre terminal.

C'est un truc tout bête mais je sais que moi je ne peux plus m'en passer ! Vous voulez en savoir plus ? Dans ce cas, lisez la suite !

I. La commande

La commande pour faire apparaitre un calendrier dans votre termanal est toute simple :

cal

Si vous la tapez comme ça, sans option, vous verrez apparaitre le mois courant (avec le dimanche comme premier jour de la semaine) et la date d'aujourd'hui surlignée.

II. Les options intéressantes

Voici les option intéressantes de cette commande :

• cal -3 : affiche les 3 mois "en cours", c'est à dire le mois précédent, le mois ne cours et le mois suivant

• cal -y : affiche toute l'année en cours

• cal -m : affiche le calendrier avec les semaines commençant par le lundi

Vous pouvez bien entendu coupler ces paramètres. Par exemple, cal -ym :

III. Astuce

L'astuce que j'utilise sur mes machines : je créé un alias (voir cet article) caly qui est en fait la commande ci-dessus : cal -ym.

Voila, un petit article rapide mais, je pense, qui peut être très utile :)

À bientôt !

J'ai découvert il y a quelques temps un navigateur web léger et rapide. Il s'agit de Midori.

Midori est basé sur GTK+2 et WebkitGTK+ (un portage de Webkit pour GTK+). C'est d'ailleurs le navigateur web du projet XFCE.

La dernière version est la 0.2.1 sortie le 14 novembre 2009.

Pour ceux qui se le demande, ce logo représente une patte de chat verte stylisée.

C'est un navigateur encore jeune, mais il est déjà assez complet et performant. Personnellement j'utilise la version git, de développement, pour suivre les évolutions qui sont assez rapides, mais qui est quand même relativement stable, je dois avoir un crash toutes les quelques heures au maximum.

Un aperçu des fonctionnalités :

• Intégration avec GTK+2.
• Rendu rapide et respectueux des normes grâce à Webkit.
• Onglets et gestions des fenêtres et session.
• Gestion des signets (marques-pages).
• Scripts et styles utilisateur.
• Barre d'adresse "intelligente".
• Vérification orthographique.
• Interface configurable.
• Suppression des données personnelles (historiques, cookies, "cookies Flash") et gestionnaire de cookie.
• Page d'appel rapide (comme FastDial ou SpeedDial).
• Personnalisation des barres d'outils.

Utilisation et paramétrage:

Midori à une interface semblable à la plupart des navigateurs, vous ne serez pas trop surpris.

Midori à un tableau latéral qui permet d'afficher les extensions, l'historique, les télechargements...

• Les scripts utilisateurs permettent principalement d'agir sur les pages, comme Greasemonkey sous Firefox, d'ailleurs beaucoup de scripts Greasemonkey peuvent être utilisés avec Midori. Ces scripts sont à placer dans le répertoire ~/.local/share/midori/scripts, les styles dans le répertoire ~/.local/share/midori/styles. Un exemple : FlashBlock WannaBe. Les styles sont des feuilles de style (CSS) appliqués à certains/tous les sites. Pour en trouver : http://userstyles.org/.
• Parmi les extensions proposées avec Midori, il y a un bloqueur de pub, une fonction "cadre" pour afficher plusieurs pages en parallèle, la gestion des mouvements de souris ("mouse gesture"), un cache web,...
• Il faut préciser la langue pour le correcteur orthographique. Il doit être paramétré avec "fr_FR" pour le français.
• Il est possible de choisir son agrégateur de flux RSS, qu'il soit local ou en ligne. Pour les navigateurs en ligne, il suffit d'entrer  : « midori » suivi d'une espace et du lien de souscription terminé par les caractères « %s » (par exemple, pour Netvibes : midori http://www.netvibes.com/subscribe.php?url=%s).

En conclusion, je dirait que si vous cherchez un navigateur web léger, rapide, configurable et en GTK+2 je vous conseille fortement Midori. Il n'a peut être pas toutes les extensions de Firefox, mais grâces aux scripts et aux extensions présente par défaut , il présente les fonctions essentielles et d'autres très pratique.

Si vous préférez Qt je vous conseille aussi Arora. Je vous ferais aussi bientôt un article sur un navigateur un peu plus particulier : uzbl.

Site officiel.

La page de documentation pour ubuntu, pour les PPA de la versions de développement.

Maintenant que nous avons un serveur sécurisé avec SSL (voir Dépôt Mercurial sur CentOs, Part 1), nous allons mettre en place le dépôt mercurial.

La structure qui sera mise en place permettra la gestion de multiprojets.

Installation de mercurial :

Ici rien de plus simple étant donné que celui-ci est déjà packagé :

yum install mercurial

Pour afficher le numéro de version de Mercurial mais aussi vérifier que celui-ci fonctionne bien avant de continuer quoi que ce soit il vous faut taper:

hg --version

Il faut maintenant créer un dossier où les dépôt seront stockés :

mkdir -p /srv/hg/cgi-bin

Note: Libre à vous de le changer si celui-ci ne vous convient pas.

Dans le répertoire cgi-bin nous allons y copier le cgi de mercurial :

cp /usr/share/doc/mercurial-1.2/hgwebdir.cgi /srv/hg/cgi-bin/

Note: Il existe deux cgi un pour la gestion de projet unique (hgweb) et un pour la gestions de plusieurs projets (hgwebdir). C'e sont ces scripts qui vont se charger de tout !

Il faut maintenant créer le fichier de configuration hgweb.config dans /srv/hg/cgi-bin/ et y ajouter ces deux lignes :

[collections]
/srv/hg = /srv/hg

Voilà c'est à peu près tout pour la mise en place de Mercurial, reste la configuration d'Httpd.

Configuration d'Httpd

Il faut rajouter les éléments permettant d'indiquer l'emplacement du cgi de mercurial  dans /etc/httpd/conf.d/ssl.conf 


Alias /hg /srv/hg/cgi-bin
<Directory "/srv/hg/cgi-bin/">

DirectoryIndex hgwebdir.cgi
SetHandler cgi-script
AllowOverride All
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
ErrorLog /var/log/httpd/hg.log

Création d'un projet 

Nous allons créer notre premier dépot dans /srv/hg/MonProjet et donner les droits d'écriture dans le dépôt à apache:

sudo -u apache hg init /srv/hg/MonProjet

Rendez-vous sur https://serveur/hg/hgwebdir.cgi où vous retrouverez votre projet !

Permettre le push

 Avoir accès au dépôt ce n'est pas tout, il faut aussi pouvoir y écrire !

Pour celà il faut créer le fichier /srv/hg/MonProjet/.hg/hgrc et y mettre:

[web]
allow_push = *

L'étoile donne accès à n'importe qui, il faudra changer celle-ci par les noms d'utilisateurs devant avoir accès au dépôt. Il serait malencontreux que tout le monde puisse envoyer des données sur le dépôt.

Sécuriser le dépôt

Il est intéressant et même indispensable de protéger son répertoire pour éviter d'avoir des ennuis.

il faut tout d'abord commencer par créer un fichier qui contiendra les logins et password des personnes autorisées :

htpasswd -c /etc/mercurial/htpasswd remi

Note: Il est important de mettre le htpasswd en dehors des répertoires accessibles par les internautes.

Note: le '-c' n'est à mettre que si le fichier n'existe pas (afin de le créer). 

Pour rajouter un autre utilsateur à la liste il suffira de faire :

htpasswd /etc/mercurial/htpasswd remi

Il faut maintenant placer un fichier .htaccess dans /srv/hg/cgi-bin  :

AuthUserFile /etc/mercurial/htpasswd
AuthGroupFile /dev/null
AuthName "Identification"
AuthType Basic
<LimitExcept GET>
Require valid-user
</LimitExcept>

Désormais lors d'un push, un nom d'utilisateur et un mot de passe seront demandés !

Importation du dépot sur une machine de travail

Maintenant que notre repository est opérationnel, il faut l'importer sur les machines de travail !

Cela se fait très simplement au travers de la commande :

hg clone AdresseWebDuRepo RepertoireDeDestination

Conclusion

Et voilà, à vous les joies de Mercurial !

Améliorations

Un point intéressant serait de modifier le chemin d'accès actuel (https://serveur/hg/hgwebdir.cgi/MonProjet) par quelques chose de plus propre comme : https://hg.serveur/MonProjet.

N'ayant pas de certifs wildcard pour le moment pour mon domaine je ne l'ai pas encore fait. Cet article sera modifié quand je trouverai un peu de temps pour mettre ca en place ;)

L'authentification est ici de type 'Basic' ce qui signifie que les logins/mots de passes seront visibles sur le réseau si le SSL n'est pas activé (ce qui n'est pas notre cas).

Pour toutes remarques/observations n'hésitez pas à m'en faire part !

L'année dernière, comme certains le savent déjà, j'étais en licence professionnelle ASRALL : Administration des Systèmes, Réseaux et Application à base de Logiciels Libres (j'ai déjà présenté cette licence dans cet article).

Tout au long de cette année (au rythme d'une réunion par mois en moyenne), j'ai eu l'occasion de participer à l'élaboration d'un scénario pour un film de promotion de cette licence. Nous avons souhaité faire une présentation humoristique et décalée, je vous laisse admirer le résultat.

N'hésitez pas à commenter et à diffuser cette vidéo !

J'ai le plaisir de vous annoncer la sortie de la nouvelle version de GaCoMa, il s'agit de la version 0.6.

Rappel : GaCoMa est un gestionnaire de collection de jeux vidéos en ligne open source, que vous pouvez installer chez vous, sur un serveur web.

Voici les améliorations apportées sur cette version :

• Suppression du lien “Connexion” dans le formulaire de login
• Correction de la faille XSS dans les fiches des jeux, accessoires et consoles (interprétation des balises HTML)
• Mise en place d'un installeur automatique
• Optimisation du code du calendrier
• Ajout du module lightbox pour la visualisation des photos
• Affichage du mois en lettres pour les dates d'acquisition
• Ajout du filtrage des jeux, accessoires ou consoles en vente ou à l'échange dans les listes de collections

Je pense que cette version peut désormais être installée sur un serveur. Les trous de sécurité les plus importants ont été corrigés et je peux dire que cette version est désormais stable et prête pour une utilisation normale.

Comme toujours, si vous découvrez des bugs, si vous avez besoin d'aide (que ce soit pour l'installation ou pour l'utilisation) ou si vous voulez participer au projet, je vous invite à vous rendre sur notre forum !


Pour obtenir cette nouvelle version, rendez-vous sur la page des téléchargements de GaCoMa.