Catégories
Open-source Planet-libre Reseau

Mesurer le débit dans son réseau avec NutTCP

NutTCP est un outil de plus pour les administrateurs réseaux afin de mesurer simplement les liaisons entre deux machines (ou vers votre serveur dédié ou VPS sous GNU/Linux|BSD).

Installation de NutTCP

Rien de plus simple sous Debian ou Ubuntu:

sudo aptitude install nuttcp

Le logiciel se présente sous la forme d’un unique exécutable (nuttcp) qui fait office de client et de serveur selon les options qui lui sont accolés.

Un premier test basée sur TCP

Nous allons donc tester le réseau se trouvant entre deux machines (A et B soyons originaux). Nous utiliserons dans ce premier exemple un test basé sur le protocole TCP.

Sur la machine A, on lance le « serveur »:

A# nuttcp -S –nofork

Puis sur la machine client on va générer un flux TCP dans le sens B vers A (l’équivalent d’un upload). NutTCP va utiliser les ports TCP/5000 (pour le contrôle) et TCP/5001 (pour le transfert proprement dit des données). Il faut donc bien vérifier que ces deux ports sont ouverts entre vos deux machines.

B# nuttcp -b -t @IP_A

0.5068 MB / 10.59 sec = 0.4013 Mbps 0 %TX 0 %RX 0 retrans 33.81 msRTT

Dans mon test, on obtient donc un débit de 401 Kbps (0.4013 Mbps).

Pour faire le même test mais dans le sens A vers B (c’est à dire un download):

B# nuttcp -b -r @IP_A

Il est possible d’ajouter certaines options:

-l : taille du buffer de lecture et d’écriture

-w : taille du buffer permettant de définir la taile de la fenêtre TCP

Un autre test basée sur UDP

Contrairement à TCP qui utilise la totalité de la bande passante disponible, le débit des flux UDP doit être fixé au niveau de l’application. On doit donc ajouter deux options:

-u : pour forcer NutTCP à travailler en UDP

-R <debit> : pour fixer le débit du flux UDP à <debit> Kbps

Sur la machine A, on lance le « serveur » comme pour le mode TCP:

A# nuttcp -S –nofork

Puis on lance la commande suivante:

B# nuttcp -b -u -R 256 -t @IP_A

0.3057 MB / 10.02 sec = 0.2560 Mbps 96 %TX 0 %RX 0 / 313 drop/pkt 0.00 %loss

Conclusion

Un outil bien pratique à comparer à Iperf, NetPerf ou NtTCP !

Catégories
Open-source Planet-libre Systeme

Mise à jour de Debian Lenny vers Squeeze

Après une trop longue attente la nouvelle version de Debian, LA distribution GNU/Linux de référence vient de sortir en version 6.0.  Son petit nom de scène est Squeeze.

Pour migrer ces machines de la version 5.0 (Lenny) vers cette nouvelle version 6.0 (Squeeze), il faut suivre une petite procédure assez simple que nous allons détailler dans ce billet.

On commence par ouvrir un terminal (ou a ce connecter en SSH sur son serveur) puis à passer en mode root:

su –

Ensuite on commence par vérifier que le système Lenny est à jour:

aptitude update && aptitude safe-upgrade

Ensuite on prépare la migration vers la version 6.0 (Squeeze):

cp /etc/apt/sources.list /etc/apt/sources.list-lenny

sed ‘s/lenny/squeeze/g’ /etc/apt/sources.list > /etc/apt/sources.list-squeeze

cp /etc/apt/sources.list-squeeze /etc/apt/sources.list

Si vous avez des fichiers présents dans le répertoire /etc/apt/sources.list.d/ il faut également faire la manipulation équivalente (c’est à dire changer toutes les occurrences de lenny vers squeeze).

Puis on effectue la  migration:

aptitude update && aptitude dist-upgrade

A la fin de la mise à jour, on repasse en mode non root:

exit

Et voili !

Catégories
Blog Open-source Web

Le panier du marché libre #6

Sixième édition du marché libre. On prends son petit panier et on va glaner les liens suivants:

Bon week-end à vous !

Catégories
Image Open-source Planet-libre Systeme

Mon desktop 201102

Comme chaque début de mois, un petit billet pour parler de mon desktop qui va m’accompagner pendant 28 jours.

C’est le desktop de mon PC fixe sous GNU/Linux Ubuntu 10.10 post configuré avec mon script ubuntupostinstall.sh.

Voici ce que cela donne:

Les principales caractéristiques

Fond d’écran: Une superbe photo de Marcus McAdam
GTKLook des fenêtre Equinox Glassicônes Faenza
Sur ce bureau: Awn +  Nautilus Elementary

Installer de la combo magique (Equinox Glass + Faenza + Nautilus Elementary)

Toujours la même chose depuis quelques mois maintenant mais je n’ai pas trouvé mieux !

Equinox Glass est clair, les icônes Faenza sont lisibles et facile à reconnaître et Elementary est pour moi devenu indispensable aux utilisateur de Nautilus:

sudo aptitude install gtk2-engines-equinox equinox-theme equinox-ubuntu-theme faenza-icon-theme

nautilus -q

Pour activer Equinox, il faut aller dans le menu: “Système > Préférences > Apparences > Thème > Equinox Glass“.

Installation de AWN

Si vous suivez cette rubrique, vous avez du vous rendre compte que je suis passé de Docky à AWN. Toutes les explications sont dans ce billet.

Dans mon dock il y a…:

  • Cairo menu
  • Lien vers mes répertoires
  • TodoList
  • Switch écran
  • Barre de lancement rapide (Terminator, Chromium,…)
  • Supervision du CPU
  • Supervision de la température de la carte mère
  • Supervision de la bande passante de mon interface Ethernet
  • La corbeille

En tout cas je ne regrette pas ce choix !

Configuration des menus

Comme vous pouvez le voir j’ai réduit la taille du tableau de bord se trouvant en haut à droite de mon écran afin de gagner des pixels pour placer mon navigateur Web. Cette manipulation est surtout utile pour des écrans de portables ou l’espace est cher…

A vous de nous montrer vos écrans !

Catégories
Open-source Planet-libre Reseau Systeme

Sauvegarde journalisée de votre machine avec RSnapShot

Suite à un commentaire de Xavier sur un de mes billets, je me suis penché sur l’utilisation de RSnapshot. Ce logiciel libre permet d’automatiser une sauvegarde journalisée de vos machines et ceci localement comme à distance.

RSnapShot est disponible dans la plupart des dépôts des distributions GNU/Linux et *BSD. Nous allons illustrer cet article avec une installation et une configuration de RSnapShot sur un serveur Gandi sous Ubuntu 10.04 LTS.

Installation de RSnapShot

On utilise la version disponible dans les dépôts officiel:

sudo aptitude install rsnapshot

Configuration de RSnapShot

L’ensemble de la configuration est centralisé dans le fichier /etc/rsnapshot.conf.

sudo vi /etc/rsnapshot.conf

Attention à la syntaxe dans ce fichier, RSnapShot est assez pointilleux. Il veut que tout les répertoires finissent par un / et des tabulations entre chaque variables.

Les variables importantes à configurer sont les suivantes:

snapshot_root   /.snapshots/

La variable snapshot_root permet de configurer le répertoire racine ou les sauvegardes seront stockées. Ce répertoire peut être sur le même disque que le disque système (c’est le cas de la configuration par défaut avec l’utilisation du répertoire /.snapshots/).

Je vous conseille pour ma part d’utiliser si possible un répertoire stocké sur un deuxième disque physique. Par exemple sur mon serveur Gandi, j’ai un deuxième disque qui est monté sur le répertoire /srv/backup. Je vais donc configurer la variable à /srv/backup/snapshots/ (noter le / à la fin du répertoire !).

Exemple: snapshot_root /srv/backup/snapshots/

cmd_ssh /path/to/ssh

Si vous voulez utiliser les fonctions de sauvegarde de serveur distant (en utilisant le protocole SSH), il faut dé-commenter la ligne précédente. Si vous avez besoin de passer des arguments spécifique à SSH, il faudra compléter la ligne ssh_args.

Exemple: cmd_ssh /usr/bin/ssh

interval monthly 3

Activation de la sauvegarde mensuelle (désactivé par défaut).

On passe ensuite aux variables permettant de configurer ce que l’on veut sauvegarder.

Sauvegardes locales

On parle ici d’une sauvegarde journalisée de répertoires de la machine ou RSnapShot est installé.

backup /home/ localhost/

Le répertoire /home/ sera sauvegardé dans le sous répertoire $snapshot_root/localhost/.

Exemple:

backup /home/ localhost/

backup /etc/ localhost/

backup /var/svn/ localhost/

Sauvegardes distantes

On peut également sauvegarder des répertoires de machines distantes. On utilise pour cela la configuration suivante:

backup root@example.com:/etc/  example.com/    +rsync_long_args=–bwlimit=1024,exclude=core

On va ainsi sauvegarder le répertoire /etc/ de la machine exemple.com en utilisant une connexion SSH avec l’utilisateur root (il faut bien sur que la connexion SSH entre votre machine exécutant RSnapShot et example.com soit automatisée). En bonus on demande à RSnapShot de ne pas sauvergarder les fichiers core (exclude=core) et de limiter la bande passante à 1 Mbps (–bwlimit=1024).

Sauvegardes en utilisant des scripts

Une autre fonctions intéressantes de RSnapShot est la possibilité d’utiliser des script shell pour automatiser des sauvegardes un peu plus complexes.

Par exemple imaginons que l’on veuillent sauvegarder les données de son serveur SVN. On commence par créer le script shell /usr/local/bin/backup-svn.sh:

#!/bin/sh

# Backup SVN


svnrepo= »/var/svn/ »

for i in `ls $svnrepo`

do

svnadmin -q dump $svnrepo/$i > $i.svndump

gzip -f $i.svndump

rm $i.svndump

done

Puis on le rend exécutable:

sudo chmod a+x  /usr/local/bin/backup-svn.sh

Enfin on configure RSnapShot:

backup_script /usr/local/bin/backup-svn.sh localhost/svn/

Le script backup-svn.sh va être lancé à partir du répertoire localhost/svn/

Il est bien sur possible de faire des scripts pour d’autres besoins: sauvegarde de bases de données MySQL par exemple.

Utilisation de RSnapShot

On commence par valider le fichier de configuration:

sudo rsnapshot configtest

Syntax OK

Simulation d’une sauvegarde journalière (cela va afficher ce que RSnapShot va faire mais sans le faire…):

sudo rsnapshot -t hourly

echo 3531 > /var/run/rsnapshot.pid

mkdir -m 0700 -p /srv/backup/snapshots/

mkdir -m 0755 -p /srv/backup/snapshots/hourly.0/

/usr/bin/rsync -a –delete –numeric-ids –relative –delete-excluded /home \

/srv/backup/snapshots/hourly.0/localhost/

mkdir -m 0755 -p /srv/backup/snapshots/hourly.0/

/usr/bin/rsync -a –delete –numeric-ids –relative –delete-excluded /etc \

/srv/backup/snapshots/hourly.0/localhost/

mkdir -m 0755 -p /srv/backup/snapshots/hourly.0/localhost/

mkdir -m 0755 -p /srv/backup/snapshots/tmp/

cd /srv/backup/snapshots/tmp/

/home/nicolargo/bin/backup-svn.sh

cd /home/nicolargo/

sync_if_different(« /srv/backup/snapshots/tmp/ », \

« /srv/backup/snapshots/hourly.0/localhost/svn/ »)

mkdir -m 0755 -p /srv/backup/snapshots/hourly.0/

/usr/bin/rsync -a –delete –numeric-ids –relative –delete-excluded \

–exclude=core –bwlimit=1024 –rsh=/usr/bin/ssh \

nicolargo@exemple.com:/home /srv/backup/snapshots/hourly.0/sam/

mkdir -m 0755 -p /srv/backup/snapshots/hourly.0/

/usr/bin/rsync -a –delete –numeric-ids –relative –delete-excluded \

–exclude=core –bwlimit=1024 –rsh=/usr/bin/ssh \

nicolargo@exemple.com:/etc /srv/backup/snapshots/hourly.0/sam/

touch /srv/backup/snapshots/hourly.0/

Test en ligne de commande:

sudo rsnapshot hourly

Le répertoire contenant la première sauvegarde devrait être créé sous /srv/backup/snapshots/hourly.0.

Enfin on automatise le lancement en éditant la crontab système (root):

sudo crontab -e -u root

0 */4 * * * /usr/bin/rsnapshot hourly

30 23 * * * /usr/bin/rsnapshot daily

0 23 * * 0 /usr/bin/rsnapshot weekly

30 22 28 * * /usr/bin/rsnapshot monthly

Pour une liste exhaustive des fonctions proposées par RSnapShot, je vous conseille la lecture de la documentation officielle (en Anglais).

Et voili, merci encore à Xavier pour cette belle découverte.

Catégories
Open-source Planet-libre Reseau Web

Installation automatique de NGinx, PHP-FPM, MemCached sous Debian

Au début du mois nous avons vu ensemble l’installation d’un serveur NGinx sous Ubuntu. Sous Debian,  il faut mettre un peu plus les mains dans le cambouis, en effet il est parfois utile de partir des sources plutôt que des dépôts officiels (notamment au niveau de la présence ou non d’un module).

J’ai donc développé un petit script shell pour automatiser l’installation (ou la mise à jour) d’un serveur Web rapide, léger et performant sous une Debian (Squeeze ou Lenny).

Ce script va effectuer les choses suivantes:

Il est bien sûr possible d’adapter ce script à vos besoins et de l’utiliser comme bon vous semble. Si vous rencontrez des erreurs ou que vous avez en tête des améliorations possibles, merci de laisser un commentaire en bas de ce billet.

Récupération du script

Le script est disponible dans mon GitHub:

NGinxAutoInstall.sh

Vous pouvez également faire ces actions en ligne de commande dans un terminal:

wget https://raw.github.com/nicolargo/debianpostinstall/master/nginxautoinstall.sh

Il faut ensuite le rendre exécutable:

chmod a+x ./nginxautoinstall.sh

Lancement du script

Il faut lancer le script en root (droit d’administration):

su - -c "$PWD/nginxautoinstall.sh"

Si tout se passe correctement, le script devrait afficher:

Validation et test de performances

Votre serveur est maintenant opérationnel, il vous reste à mettre vos page HTML et scripts PHP dans le répertoire /var/www et tester le tout en entrant l’URL suivante dans un navigateur Web: http://@devotreserveur/.

Vous pouvez également tester les performances brutes de votre serveur en utilisant HTTPerf (disponible dans les dépôts Debian). Sur mon serveur de test (VPS Gandi 1 part), j’obtiens les perfos suivantes:

httperf –client=0/1 –server=localhost –port=80 –uri=/ –send-buffer=4096 –recv-buffer=16384 –num-conns=5000 –num-calls=10

Request rate: 6833.4 req/s (0.1 ms/req)

Conclusion

Avec NGinx, on obtient rapidement de très bonnes performances et le couple PHP-FPM, MemCached permet d’avoir une bonne base pour héberger, par exemple, votre blog WordPress (lire l’article sur le sujet dans ce blog).

Je suis bien sur preneur de tous commentaires/remarques sur le script.

Catégories
Blog Open-source Planet-libre Reseau Systeme Web

Sécuriser son blog WordPress #3

WordPress n’a pas forcement bonne presse au niveau de la sécurité. Le coeur PHP du moteur WordPress est pourtant surveillé de très près et les corrections des failles sont assez rapides (voir par  exemple la publication de la version 3.0.4).

Par contre les plugins, qui sont un avantage indéniable de WordPress par rapport aux autres CMS, sont également un talon d’Achille… En effet, WordPress dispose d’une base de plugins impressionnante (plus de 12.700 au moment de l’écriture de ce billet) dont les développeurs sont plus ou moins sensibilisés à la problématique de la sécurité… Ajouter des plugins à votre blog, c’est multiplier les risques au niveau de la sécurité.

Dans ce billet, nous allons voir comment installer puis configurer WordPress pour compliquer la tache des personnes voulant attaquer votre blog.

Je vous rappelle que cet article est découpé en plusieurs billets (vous êtes en train de lire le #3):

Cette série de billets a été co-écrite avec Jérémie Marguerie étudiant à EPITA (merci à lui !).

Partir sur de bonnes bases

Nous allons détailler l’installation, la configuration initiale puis la gestion des mises à jours de WordPress.

    Installation de WordPress

    Personnellement j’utilise sur mon serveur deux versions de WordPress en parallèle.

    La première est celle du blog « de production » (celui que vous êtes en train de lire) utilise la version stable SVN (c’est à dire la 3.0.4 au jour d’aujourd’hui). J’utilise la commande suivante pour effectuer l’installation (dans le répertoire racine de mon serveur Web: /var/www/blog):

    svn co http://core.svn.wordpress.org/branches/3.0/

    La seconde, dite « de validation » me sert pour tester mon blog (thème et plugins) sur les futures versions de WordPress (3.1 par exemple). Elle n’est pas publique, seul les administrateurs peuvent y accéder. Pour installer cette version de WordPress, j’utilise la commande suivante dans un deuxième répertoire de mon serveur Web (/var/www/blogfutur):

    svn co http://core.svn.wordpress.org/trunk/

    Avant de suivre la fameuse installation en 5 minutes de WordPress, je vous conseille de changer le préfixe des tables MySQL en éditant la ligne suivante dans votre fichier de configuration wp-config.php et en remplacant wp_ par une chaine aléatoire (par exemple apvbty_):

    $table_prefix  = ‘apvbty_’;

    Attention, cette manipulation est à faire seulement sur un nouveau blog. En effet, si vous avez déjà une base de donnée SQL existante il faut d’abord changer le nom du préfixe des tables dans MySQL (voir hack en fin de billet) sous peine de ne plus pouvoir accéder à vos données.

    Une fois l’installation de WordPress finalisée, nous allons commencer par fixer les droits au niveau des fichiers dans ces répertoires. En partant sur l’hypothèse ou votre serveur Web tourne sous l’utilisateur www-data et dans le répertoire /var/www/blog, j’utilise les commandes suivantes:

    chown -R www-data:www-data /var/www/blog

    find /var/www/blog -type d -exec chmod 755 {} \;

    find /var/www/blog -type f -exec chmod 644 {} \;

    chmod 640 /var/www/blog/wp-config.php

    find /var/www/blog/wp-content/themes -type d -exec chmod 775 {} \;

    find /var/www/blog/wp-content/themes -type f -exec chmod 664 {} \;

    Pour vous simplifier la vie, je vous conseille de mettre ces commandes dans un script shell afin de pourvoir rapidement les appliquer sur votre arborescence.

    Mise à jour de WordPress

    Comme nous l’avons vu, les développeurs de WordPress sont assez réactifs sur la correction des failles de sécurité. Encore faut-il que vous pensiez à mettre à jour votre instance de WordPress…

    J’utilise un script shell pour mettre à jour WordPress à partir de SVN:

    #!/bin/bash

    # Simple script pour mettre a jour WordPress

    # Test que le script est lance en root

    if [ $EUID -ne 0 ]; then

    echo « Le script doit être lancé en root: # sudo $0″ 1>&2

    exit 1

    fi

    WPPATH= »/var/www/blog »

    echo « 1) Mise a jour de WordPress »

    cd $WPPATH 2>&1 /dev/null

    CURRENTVERSION=`svn info | grep « Revision:  » | awk ‘{ print $2 }’`

    svn update

    rm $WPPATH/wp-admin/install.php

    cd – 2>&1 /dev/null

    echo « 2) Verification des droits des fichiers »

    chown -R www-data:www-data $WPPATH

    find $WPPATH -type d -exec chmod 755 {} \;

    find $WPPATH -type f -exec chmod 644 {} \;

    chmod 640 $WPPATH/wp-config.php

    find $WPPATH/wp-content/themes -type d -exec chmod 775 {} \;

    find $WPPATH/wp-content/themes -type f -exec chmod 664 {} \;

    echo « 3) Fin de la mise a jour »

    echo « En cas de pb: svn update -r$CURRENTVERSION »

    Il est possible de lancer ce script toutes les nuits (par exemple par crontab) pour éviter de se retrouver avec un blog hacké quand vous partez en congés

    Le .htaccess

    Ce fichier qui doit se trouver à la racine de votre site Web, contient des entrées utiles à la sécurité de votre site. Le mien commence par:

    # MAIN

    RewriteEngine On

    ServerSignature Off

    Options All -Indexes

    Options +FollowSymLinks


    # SVN protect

    RewriteRule ^(.*/)?\.svn/ – [F,L]


    # Secure .htaccess

    <Files .htaccess>

    Order Allow,Deny

    Deny from all

    </Files>


    # Secure wp-config.php

    <Files wp-config.php>

    Order Deny,Allow

    Deny from all

    </Files>


    # FILTER REQUEST

    <IfModule mod_rewrite.c>

    RewriteBase /

    RewriteCond %{REQUEST_FILENAME} !-f

    RewriteCond %{REQUEST_FILENAME} !-d

    RewriteRule . /index.php [L]

    </IfModule>

    Certains plugins ajoutent pas mal de chose dans ce fichier (notamment W3 Total Cache, le plugin d’optimisation des performances que j’ai abordé dans ce billet).

    Un peu de bon sens…

    Vous avez donc entre les mains une installation toute propre et sécurisée de WordPress, c’est normalement à partir de ce moment là que les choses se gâtent…

    On commence par l’erreur de base: ne pas utiliser un mot de passe « strong » pour le compte admin. Encore mieux, créer un nouveau compte administrateur et supprimer le compte admin par défaut.

    L’installation des plugins apportent également son lot de failles de sécurité. C’est là qu’il faut se faire violence et n’installer que les plugins indispensables au bon fonctionnement de votre blog. Il faut également veiller à mettre à jour régulièrement vos plugins (l’interface d’administration de WordPress permet de faire cela très simplement).

    Enfin vos thèmes peuvent également fragiliser votre blog en insérant des codes PHP ou JS. Si vous avez les compétences il faut faire un audit de votre thème ou au minimum utiliser des thèmes connus et validés.

    Des plugins pour la sécurité

    Parmis ces plugins, j’en utile trois dédiés à la sécurisation:

    • Secure WordPress permet d’automatiser certaines actions pour sécuriser votre blog.

    • WordPress File Monitor: Surveille les fichiers du moteur WordPress et vous alerte (par mail et/ou directement dans l’interface d’administration de WordPress) en cas de modification.
    • On peut également citer WordPress Security Scan qui permet de faire un audit de votre blog en testant notamment les droits de vos fichiers, les mots de passes, la base de données…

    Quelques hacks en bonus

    Compliquer la tache des attaques par force brute en supprimant l’indicateur (« mauvais mot de passe ») lors d’une tentative de connexion à l’interface d’administration. Il faut juste ajouter la ligne suivante à votre fichier functions.php (thème):

    add_filter(‘login_errors’, create_function(‘$a’, « return null; »));

    Si vous avez une base de données MySQL existante avec le préfixe par défaut (wp_) et que vous souhaitez le changer, il est possible de faire celà directement à la main par une requête MySQL ou alors plus simplement en utilisant le plugin WP-Security-Scan.

    Tester votre WordPress

    Pour tester la sécurité de votre blog, rien ne vaut une simulation d’attaque. Pour celà vous pouvez utiliser le logiciel libre Nikto.

    On commence par installer Nikto sur un PC client sous Ubuntu (qui va simuler l’attaque):

    sudo aptitude install nikto

    Puis on lance le test (remplacer URL par l’URL de votre blog WordPress):

    nikto -h URL

    Le rapport devrait ensuite s’afficher.

    Sources:

    Catégories
    Hardware Open-source Planet-libre Reseau Systeme Web

    Cours d’introduction au « Cloud Computing »

    En début de semaine, j’ai été emmenée à donner un cours d’introduction aux technologies de Cloud Computing à l’école supérieure des ingénieurs de Luminy (ESIL à Marseille). Le sujet étant vaste pour les trois petites heures imparties, j’ai préféré axer mon cours sur certains aspects (notamment les architectures IAAS et l’utilisation de technologies ouvertes et libres).

    Pour ceux que cela intéresse, voici (sous licence « CC By:« ):

    Au passage un grand merci à Philippe Scoffoni pour sa relecture et ses remarques.

    Catégories
    Open-source Planet-libre Web

    Un serveur Jabber en 5 minutes chronos sous Debian/Ubuntu

    Oui je sais c’est un pompage en règle du billet de Cyrille Borne. Mais bon il faut dire que par les temps qui courent c’est une rudement bonne idée que de disposer de son propre serveur Jabber.

    Nous allons donc détailler les étapes d’installation et de configuration d’un serveur Prosody dans sa dernière version (0.7) avec un chiffrement SSL entre les clients et le serveur.

    Pourquoi Prosody et pas Jabber ? Tout simplement car il est bien plus simple et léger à installer (un peu trop usine à gaz). Et puis le titre du billet aurait été moins vendeur: « Un serveur Jabber en 3h45 chronos… ».

    Installation de Prosody

    L’installation de Prosody se fait en utilisant les commandes suivantes:

    echo « deb http://packages.prosody.im/debian stable main » | sudo tee -a /etc/apt/sources.list

    wget http://prosody.im/files/prosody-debian-packages.key -O- | sudo apt-key add –

    sudo aptitude update

    sudo aptitude install prosody

    Sous Ubuntu 10.04, j’ai du en plus installer à la main la librairie LibLua (pour le SSL):

    wget http://prosody.im/downloads/debian/liblua5.1-sec0_0.3.2-2prosody1_i386.deb

    sudo dpkg -i liblua5.1-sec0_0.3.2-2prosody1_i386.deb

    PS: la librairie LibLua est utilisé pour le chiffrement SSL. Le fichier liblua5.1-sec0_0.3.2-2prosody1_amd64.deb doit être utilisé pour les machines sous AMD 64 bits.

    On génère la clés et le certificat SSL:

    cd /etc/prosody/certs/

    sudo openssl req -new -x509 -days 365 -nodes -out « monbeaudomaine.com.cert » -keyout « monbeaudomaine.com.key »

    Configuration de Prosody

    Puis on configure en éditant le fichier /etc/prosody/prosody.cfg.lua:

    sudo vi /etc/prosody/prosody.cfg.lua

    VirtualHost « monbeaudomaine.com »

    ssl = {

    key = « /etc/prosody/certs/monbeaudomaine.com.key »;

    certificate = « /etc/prosody/certs/monbeaudomaine.com.cert »;

    }

    enabled = true;

    On relance Prosody pour prendre en compte la configuration:

    sudo /etc/init.d/prosody restart

    Si vous avez un Firewall sur votre serveur (ce qui est une bonne idée), il faut penser à ouvrir les ports TCP de Jabber en ajoutant les lignes suivantes dans votre script de configuration iptable (/etc/init.d/iptables.sh dans mon cas):

    iptables -A INPUT -p tcp –dport 5222 -j ACCEPT

    iptables -A INPUT -p tcp –dport 5269 -j ACCEPT

    iptables -A OUTPUT -p tcp –dport 5269 -j ACCEPT

    On relance ensuite le Firewall:

    sudo /etc/init.d/iptables.sh

    Puis on vérifie que les règles existent:

    sudo iptables -L | grep xmpp

    ACCEPT tcp — anywhere anywhere tcp dpt:xmpp-client

    ACCEPT tcp — anywhere anywhere tcp dpt:xmpp-server

    ACCEPT tcp — anywhere anywhere tcp dpt:xmpp-server

    Création d’un compte utilisateur Jabber dans Prosody

    On peut ensuite passer à la création d’un utilisateur Jabber:

    sudo prosodyctl adduser monbeauuser@monbeaudomaine.com

    Il faut saisir deux fois le même mot de passe…

    Configuration d’un client Jabber pour utiliser votre serveur Prosody

    Enfin, sur son/ses PC, on configure le client de chat (Pidgin dans mon cas).

    Il faut aller dans le menu Comptes > Gérer les comptes puis cliquer sur le bouton Ajouter:

    Et hop voili !

    Catégories
    Blog Open-source Web

    Le panier du marché libre #5

    Un très bon marché libre cette semaine, glané dans mon flux RSS, mon Twitter et un peu dans Quora que je teste depuis la fin de la semaine dernière.

    D’autres choses importantes de votre coté ?