Ce petit tutoriel est fait sur une distribution CentOS et c’est la procèdure de sauvegarde que j’utilise pour mon compte Gmail (Google Apps). La boite aux lettres de destination est de type Maildir, c’est-à-dire que chaque courrier est dans un fichier unique contrairement à Mbox qui place tous les courriers dans un fichier unique.

Installation de getmail

Choisissez votre gestionnaire de paquets préféré, pour les habitués des distributions à base de Red Hat, ce sera yum :

# yum install getmail

Création des répertoires

Le script ne crée pas par lui-même les répertoires et fichiers nécessaires au bon fonctionnement de getmail, il faut donc les ajouter à la main. On commence par l’arborescence de type Maildir qui accueillera les emails :

$ mkdir -p ~/Maildir/{new,tmp,cur}

Je ne m’attarde pas sur les trois répertoires cur, tmp et new, c’est l’arborescence de fonctionnement de Maildir. Ensuite, il faut créer le répertoire qui contiendra le fichier de configuration et les logs de getmail :

$ mkdir ~/.getmail
$ vim ~/.getmail/gmailrc
$ chmod -R 700 ~/.getmail

Configuration

Voici mon fichier de configuration pour sauvegarder un compte Google Apps en utilisant IMAP :

[retriever]
type = SimpleIMAPSSLRetriever
server = imap.gmail.com
mailboxes = ("[Gmail]/All Mail",)
username = nom@domaine.net
password = mot_de_passe
 
[destination]
type = Maildir
path = ~/Maildir/
 
[options]
# Mode verbeux
# 0 : n'affiche que les warnings et les erreurs
# 1 : affiche les notifications de récupération et de suppression de messages
# 2 : toutes les actions
verbose = 2
message_log = ~/.getmail/gmail.log
 
# ne récupére que les nouveaux messages
# idéal pour de la sauvegarde régulière
read_all = false
 
# n'altère pas les messages
delivered_to = false
received = false

Lancement du script

$ getmail -r ~/.getmail/gmailrc

Le script commence le rapatriement des messages et les place dans l’arborescence Maildir.

Note : Google n’autorise le transfert que d’un nombre limité de messages à la fois, si votre boite aux lettres est assez importante il faut relancer cette commande plusieurs fois, car seuls les nouveaux messages sont récupérés, ou alors le faire de façon automatisée (voir ci-dessous).

Automatisation

Afin d’automatiser cette sauvegarde, un job peut être ajouté dans le cron. L’option -q rend l’opération silentieuse, sauf pour les erreurs :

# Le script est lancé à la 7ème minute de chaque heure ^.^
7 * * * * /usr/bin/getmail -q -r /home/fabien/.getmail/getmailrc

Cette article explique comment mettre en place un dépôt SVN pour les fichiers d’un site web. Le tutoriel est assez global, mais pour information il a été réalisé sur une Fedora 14.

Fonctionnement

Voici briévement comment fonctionne SVN. C’est un système de fichiers virtuels, on ajoute, édite, supprime des fichiers ou répertoires comme dans un système de fichiers traditionnel, mais tout se passe en interne, les différentes révisions des fichiers ne sont pas vraiment physiquement présentes. Pour mettre en pratique ce tutoriel, nous allons tout d’abord créer un dépôt (repository) où toute la gestion sera faite. Puis, dans un second temps nous allons importer un projet existant pour qu’il soit géré par SVN et c’est après que la magie s’opère ^.^

Création d’un dépôt local

Subversion possède deux commandes principales, l’une d’administration svnadmin et la commande de gestion svn. Pour créer un nouveau dépôt svn_projet, nous utilisons la première :

$ svnadmin create --fs-type fsfs /chemin/depot/svn_projet

Un nouveau dossier svn_projet est crée, voici son contenu :

$ ls -l svn_projet/
total 368
drwxr-xr-x  2 fabien subversion   4096 Apr  8 11:52 conf
drwxr-sr-x  6 fabien subversion   4096 Apr  8 11:52 db
-r--r--r--  1 fabien subversion      2 Apr  8 11:52 format
drwxr-xr-x  2 fabien subversion   4096 Apr  8 11:52 hooks
drwxr-xr-x  2 fabien subversion   4096 Apr  8 11:52 locks
-rw-r--r--  1 fabien subversion    229 Apr  8 11:52 README.txt

Il est rare d’aller voir les fichiers à l’intérieur du dépôt et il n’est pas recommandé d’y toucher. Voyons les informations sur notre nouveau dépôt :

$ svn info file:///chemin/depot/svn_projet/
Path: svn_projet
URL: file:///chemin/depot/svn_projet
Repository Root: file:///chemin/depot/svn_projet
Repository UUID: d9d451c0-72b9-4830-93bf-3f8829278afe
Revision: 0
Node Kind: directory
Last Changed Rev: 0
Last Changed Date: 2011-04-08 11:52:00 +0200 (Fri, 08 Apr 2011)

On peut voir que la syntaxe pour interroger ce dépôt commence par file:// pour une gestion locale. Ceci pourrait etre remplacé par http://, ssh://, svn:// ou svn+ssh:// pour un dépôt distant. Pour l’exemple, nous partons avec un projet tout simple composé d’un fichier index.html et d’un fichier style.css dans un répertoire css :

$ tree -a /chemin/projet/web
/chemin/projet/web/
├── css
│   └── style.css
└── index.html
 
1 directory, 2 files

Nous allons maintenant importer les fichiers non encore gérés par SVN dans le dépôt, ceci se fait avec la commande svn import. Je ne vais pas m’attarder là-dessus, mais par convention, il est bon de créer 3 répertoires dans notre dépôt : trunk, tags et branches. Le premier sera les fichiers du projet les plus récents, il s’agit de la version de travail la plus actuelle. tags contiendra en général les versions historisés (version 1, version 2, etc) et branches représente des dérivations dans le temps de l’évolution des éléments.
Assez de blabla, importons!

$ cd projet
$ svn import /chemin/projet/web file:///chemin/depot/svn_projet/trunk -m 'Initial import.'
Adding         web/css
Adding         web/css/style.css
Adding         web/index.html
 
Committed revision 1.

Le projet est importé, celui-ci existe désormais dans le dépôt, il s’agit de la version, plus précisément de la révision 1 et un commentaire est ajouté dans le log avec l’option -m, sans cette option l’éditeur par défaut s’ouvrirait et il serait demandé d’écrire une petite bafouille, sans quoi, pas de commit. L’action commit permet de figer un numéro de révision et ainsi de pouvoir y revenir plus tard. Chaque commit incrémente le compteur.

Nous pouvons vérifier notre log :

$ svn log file:///chemin/depot/svn_projet
------------------------------------------------------------------------
r1 | amannf | 2011-04-15 15:10:46 +0200 (Fri, 15 Apr 2011) | 1 line
 
Initial import.
------------------------------------------------------------------------

A ce stade, il faut comprendre que notre site web est géré par SVN, une première révision existe belle et bien, il est donc possible de supprimer les anciens fichiers non historisés :

$ rm -rf /chemin/projet/web

On se retrouve sans rien… ou presque. Le site est connu de SVN mais nous n’avons plus de fichiers de travail, il faut alors les (re)créer avec l’option checkout de la commande svn, celle-ci permet d’extraire une version qui servira de base au futur développement.

$ mkdir /chemin/travail/web
$ cd /chemin/travail/web
$ svn checkout file:///chemin/depot/svn_projet /chemin/travail/web
A    trunk
A    trunk/css
A    trunk/css/style.css
A    trunk/index.html
Checked out revision 1.

D’accord, mais pourquoi à l’étape précèdente nous avons supprimé nos fichiers pour maintenant les rajouter, car il s’agit des mêmes.. Simplement parce que désormais cette copie va être gérée par SVN, nous pouvons d’ailleurs voir qu’il y a un répertoire .svn à la racine de chaque répertoire et sous-répertoire de notre copie de travail. Attention à ne jamais les supprimer, au risque de passer un précieux temps à remettre sur pieds un dépôt bancal.
Au passage, on peut de nouveau vérifier l’état du dépôt :

$ svn info file:///chemin/depot/svn_projet/
Path: svn_projet
URL: file:///chemin/depot/svn_projet
Repository Root: file:///chemin/depot/svn_projet
Repository UUID: d9d451c0-72b9-4830-93bf-3f8829278afe
Revision: 1
Node Kind: directory
Last Changed Author: amannf
Last Changed Rev: 1
Last Changed Date: 2011-04-08 12:52:00 +0200 (Fri, 08 Apr 2011)

Faire des modifications de structure

Nous allons ajouter un répertoire js contenant un fichier fonctions.js :

$ cd /chemin/travail/web
$ mkdir trunk/js
$ touch trunk/js/fonction.js

Le répertoire doit être pris en compte par le dépôt maintenant. Ceci ne vas pas faire un commit mais juste indiquer au dépôt la présence de ce nouveau dossier (et de ce qu’il contient) :

$ svn add trunk/js
A         trunk/js
A         trunk/js/fonction.js

Notre version a évolué avec ce nouveau répertoire js, il est temps de faire notre premier commit, c’est-à-dire d’incrémenter le numéro de révision de notre site web :

$ svn commit -m 'First commit.'
Adding         trunk/js
Adding         trunk/js/fonction.js
Transmitting file data ..
Committed revision 2.

Voilà, nous sommes passés en révision 2 ^.^ Le principe est le même avec la suppression de fichiers/répertoires, le mot clé est – je vous le donne en mille – delete, par example :

$ svn delete trunk/js/fonctions.js
D         trunk/js/fonction.js

Pour valider le changement :

$ svn commit -m 'Delete fonctions.js file.'
Deleting       trunk/js/fonction.js
 
Committed revision 3.

Et voilà la révision 3. Nous estimons que ceci va correspondre à notre première version officielle, fini la beta! C’est là qu’entre le principe des tags, nous allons créer un tags pour la version 1, c’est-à-dire faire une copie à ce stade, et le développement normal continuera sur le trunk. Vous avez saisi le système du trunk et des branches maintenant. Alors, dans l’ordre cela donne :

$ mkdir tags
$ svn add tags
A         tags
$ svn copy trunk/ tags/version_1.0
A         tags/version_1.0

Voilà, notre version 1.0 est historisée. Presque. Il manque le commit :

$ svn commit -m 'Tagged version 1.0.' tags/
Adding         tags
Adding         tags/version_1.0
Adding         tags/version_1.0/js
Deleting       tags/version_1.0/js/fonction.js
Adding         tags/version_1.0/test
 
Committed revision 4.

Petite vérification du log :

$ svn log file:///chemin/depot/svn_projet/
------------------------------------------------------------------------
r4 | amannf | 2011-04-15 15:57:49 +0200 (Fri, 15 Apr 2011) | 1 line
 
Tagged version 1.0.
------------------------------------------------------------------------
r3 | amannf | 2011-04-15 15:48:30 +0200 (Fri, 15 Apr 2011) | 1 line
 
Delete fonctions.js file.
------------------------------------------------------------------------
r2 | amannf | 2011-04-15 15:41:28 +0200 (Fri, 15 Apr 2011) | 1 line
 
First commit.
------------------------------------------------------------------------
r1 | amannf | 2011-04-15 15:10:46 +0200 (Fri, 15 Apr 2011) | 1 line
 
Initial import.
------------------------------------------------------------------------

Revenir sur une ancienne version

C’est bien beau de gérer les révisions de projets, mais encore faut-il pouvoir au besoin revenir sur une ancienne version. Rien de plus simple. Le plus difficile étant de savoir où revenir, d’où la nécessité de bien documenter ses commits (option -m). Dans notre cas, je veux revenir à la version avec le fichier fonctions.js avant sa suppression donc, d’après notre log du point précédent, on voit qu’il faut revenir en r1 :

$ svn co -r 1 file:///chemin/depot/svn_projet/trunk /nouveau/chemin/
A    css
A    css/style.css
A    index.html
Checked out revision 1.

La révision 1 est désormais accessible sous /nouveau/chemin.

Conclusion

Voici une introduction par la pratique de Subversion, certe un peu rapide, mais les grands principes sont là et cela permet de se lancer dans l’aventure.

Le module SSL devrait être installé par défaut, sinon il faut l’ajouter :

# yum -y install mod_ssl

Création de la clé

Pour accepter les requêtes SSL, Apache a besoin d’une clé pour le serveur et d’un certificat signé. Les noms de ces fichiers n’ayant pas d’importance, dans ce tutoriel, elles seront respectivement nommées server.key et server.crt. Un certificat personnel – gratuit – va ainsi être crée, pour une utilisation professionnelle, il faudrait préférer un certificat – payant – délivré par une autorité comme Verisign. La seule différence avec une clé faîte maison sera un avertissement par le navigateur lors de l’accès à une ressource SSL. La sécurité est la même, que le certificat soit signé par vous même ou par un organisme. La clé va être ajoutée sous /etc/pki/tls/certs :

# cd /etc/pki/tls/certs
# make server.key
umask 77 ; \
/usr/bin/openssl genrsa -des3 1024 > server.key
Generating RSA private key, 1024 bit long modulus
......................................................++++++
.............++++++
e is 65537 (0x10001)
Enter pass phrase: // Entrer une pass phrase
Verifying - Enter pass phrase: // Vérification

Il est ennuyeux de toujours saisir la pass phrase, elle est donc retirée de la clé privée :

# openssl rsa -in server.key -out server.key

Ajout du certificat

Pour la création du certificat, plusieurs renseignements vont être demandés afin d’être incorporés dans celui-ci, certaines informations sont toutefois facultatives :

# make server.csr
umask 77 ; \
/usr/bin/openssl req -utf8 -new -key server.key -out server.csr
 
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]: FR
State or Province Name (full name) [Berkshire]: Lorraine
Locality Name (eg, city) [Newbury]: Ramonchamp // Yes! ;}
Organization Name (eg, company) [My Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your server's hostname) []: mondomaine.net
Email Address []: nom@mondomaine.net
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Création du certificat pour une durée de 10 ans :

# openssl x509 -in server.csr -out server.crt -req -signkey server.key -days 3650
Signature ok
subject=/C=FR/ST=Lorraine/L=Ramonchamp/O=mondomaine/OU=mondomaine/CN=mondomaine.net/emailAddress=nom@mondomaine.net Getting Private key

On change les droits sur ces fichiers désormais importants avant de passer à la suite :

# chmod 400 server.*

Directives Apache

Il ne reste plus qu’à ajouter les directives Apache pour prendre en compte le SSL. Comme Fedora fait bien le boulot, ce travail est pré-mâché dans un fichier de configuration sous /etc/httpd/conf.d/ssl.conf. Il faut dé-commenter les lignes suivantes dans ce fichier :

DocumentRoot "/var/www/html" // Environ ligne 84
ServerName www.mondomaine.net:443 // Environ ligne 85
SSLCertificateFile /etc/pki/tls/certs/server.crt // Environ ligne 112
SSLCertificateKeyFile /etc/pki/tls/certs/server.key // Environ ligne 119

Redémarrage d’httpd :

# service httpd restart

C’est terminé, les pages peuvent désormais être accédées par https://www.mon-domaine.net/.

Forcer la consultation des pages en https

Ce qui peut être intéressant, c’est de forcer l’accès aux pages en https uniquement, pour faire ceci on va utiliser le mode rewrite. Ajouter ce qui suit au fichier httpd.conf (préfèrable) ou dans un fichier .htaccess :

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^(.*)$  https://%{SERVER_NAME}/admin/? [R=301,L]

Après avoir redémarré Apache, on voit qu’en tapant http://www.mondonaine.net, on passe tout de suite en https://www.mondonaine.net ^.^

Comme beaucoup de démons sous OS X, le fichier de configuration se trouve sous /System/Library/LaunchDaemons et celui qui nous intéresse se nomme naturellement ssh.plist.

Lorsque l’on édite ce fichier de configuration, on peut trouver ces lignes qui renseignent sur le port du service ssh.

<key>SockServiceName</key>
<string>ssh</string>

Oui, mais cela ne ressemble pas à un numéro de port. Juste. En fait, pourquoi faire simple quand on peut compliquer un petit peu, la chaîne ssh renvoie au fichier /etc/services, et on trouve bien que SSH est sur le port standard 22 (en UDP et TCP).

ssh              22/udp     # SSH Remote Login Protocol
ssh              22/tcp     # SSH Remote Login Protocol

Il suffit donc de rajouter un nouveau nom avec le port correspondant, par exemple si l’on veut utiliser SSH sur le port 2222 au lieu de 22 :

ssh2              2222/udp     # SSH Remote Login Protocol
ssh2              2222/tcp     # SSH Remote Login Protocol

Et d’aller bien sur renommer la chaîne correspondant au SockServiceName dans le ssh.plist, comme ceci :

<key>SockServiceName</key>
<string>ssh2</string>

On relance le service :

# launchctl stop /System/Library/LaunchDaemons/ssh.plist
# launchctl start /System/Library/LaunchDaemons/ssh.plist

Et le tour est joué. Il suffit de bien penser à se connecter sur le bon port désormais : $ ssh -p 2222.

​

Cette article est la mise-à-jour d’un billet de juillet 2008.

Mac OS X (depuis Panther) possède un serveur de messagerie, le renommé Postfix. Nous allons voir comment le faire tourner grâce au daemon launchd.
Ce document décrit la mise en route de Postfix, mais ne traite pas de sa configuration, voir sa documentation pour aller plus loin.

Les opérations suivantes doivent être réalisées en tant que root. En ce qui me concerne, j’utiliserai l’éditeur VIM.

main.cf

La première chose à faire et d’éditer main.cf, le principal fichier de configuration de Postfix qui se trouve sous /etc/postfix/. Au préalable, il est bon de faire une copie du fichier présent.

# mv /etc/postfix/main.cf /etc/postfix/main.cf.fab
# vim /etc/postfix/main.cf

Les paramètres myhostname, mydomain, myorigin et mynetworks_style doivent être renseignés. Le premier myhostname désigne la machine sur lequel tourne Postfix, il est tout à fait possible de laisser la valeur générique localhost.localdomain, mais je vais renseigner le FQDN de mon iBook sur mon réseau, représenté par le nom de la machine et du nom de domaine :

myhostname = osgiliath.feub.net

Ensuite, mydomain comme son nom l’indique représente le (les) nom de domaine pour lequel Postfix officiera. En général, il s’agit de la partie domaine du myhostname :

mydomain = feub.net

myorigin est le nom de domaine qui apparait dans le courrier envoyé à partir de ma machine. Il est usuel de mettre myhostname voir mydomain :

myorigin = $myhostname

Postfix ne relaie le courrier que des clients autorisés, il est donc bon de lui dire de qui avec le paramètre
mynetworks_style. Dans mon mon cas, j’autorise les machines du sous-réseau :

mynetworks_style = subnet

A noter que mynetworks pourrait être utilisé en spécifiant une adresse de réseau autorisée à la place d’un style. Par exemple :

mynetworks = 192.168.1.0/24

C’est l’un ou l’autre, si les deux paramètres mynetworks_style et mynetworks sont renseignés, mynetworks sera pris en compte.
Voilà pour la configuration du main.cf.

Enfin, pour relayer les courriers sortants, le paramètre relayhost doit être renseigné avec un serveur SMTP valide sur internet, par exemple celui d’Orange :

relayhost = [smtp.orange.fr]

org.isc.named.plist

Nous allons maintenant éditer le fichier plist de lancement de Postfix. Par défaut, celui-ci n’est pas démarré, il est en mode on demand, et nous voulons qu’il tourne toujours. Nous allons donc éditer le fichier org.postfix.master.plist qui se situe sous /System/Library/LaunchDaemons/ (il est bon d’en faire une copie de sauvegarde avant de le modifier) :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>	
	<string>org.postfix.master</string>
	<key>Program</key>
	<string>/usr/libexec/postfix/master</string>
	<key>ProgramArguments</key>
	<array>
		<string>master</string>
		<string>-e</string>
		<string>60</string>
	</array>
	<key>QueueDirectories</key>
	<array>
	<string>/var/spool/postfix/maildrop</string>
	</array>
	<key>OnDemand</key>
	<true/>
</dict>
</plist>

Il faut supprimer les paramètres -e 60 et dire au daemon qu’on ne veut pas le démarrer OnDemand, mais en RunAtLoad, car on veut qu’il soit toujours en fonctionnement. Voici donc le fichier modifié :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
  	<string>org.postfix.master</string>
  	<key>Program</key>
  	<string>/usr/libexec/postfix/master</string>
  	<key>ProgramArguments</key>
  	<array>
  		<string>master</string>
  	</array>
  	<key>QueueDirectories</key>
  	<array>
  		<string>/var/spool/postfix/maildrop</string>
  	</array>
  	<key>RunAtLoad</key>
	<true/>
</dict>
</plist>

Il faut maintenant démarrer ou redémarrer Postfix à l’aide de launchd :

# launchctl stop org.postfix.master
# launchctl start org.postfix.master

Pour voir si Postfix fonctionne, envoyer un email comme ceci :

# date | mail -s test nom @ mon@adresse.net

Si cela ne fonctionne pas, voir les logs sous /var/log/mail.log.

Utiliser le serveur comme SMTP local

Il est maintenant possible d'utiliser Postfix comme serveur SMTP pour le courrier sortant. Pour ce faire, il faut mettre localhost comme serveur SMTP dans Mail.app ou tout autre client de messagerie.

Cette article est la mise-à-jour d'un billet du 22 juillet 2008.

Installation et configuration

J’avais originellement écrit cet article pour Archlinux, donc pour cette distro, rTorrent est dans les dépôts, pacman l’installe donc sans soucis, ainsi que screen le multiplexeur de terminaux :

# pacman -S rtorrent screen

Pour du Fedora :

# yum install rtorrent screen

Ensuite, il va falloir structurer les quelques répertoires nécessaires à son bon fonctionnement. J’ai ainsi crée quatre répertoires dans mon home sous ~/bt : data, completed, watch et sessions, qui respectivement serviront à stocker les fichiers en cours de téléchargement, stocker les fichiers completement téléchargés, fournir un répertoire pour les fichiers .torrent que rtorrent scrutera régulièrement et un répertoire pour les sessions en cours :

# mkdir -p ~/bt/{data,sessions,watch,completed}

Il faut maintenant créer le fichier de configuration ~/.rtorrent.rc, voici le mien :

# Limite en upload et download
upload_rate = 30
download_rate = 6000
 
# Répertoire de destination des fichiers téléchargés et des sessions
directory = /home/fabien/bt/data/
session = /home/fabien/bt/sessions
 
# Ports utilisés et diverses options
port_range = 6881-6999
port_random = no
check_hash = yes
max_memory_usage = 268435456
encryption = allow_incoming,enable_retry,prefer_plaintext
 
# Répertoire de dépôt des fichiers .torrent
schedule = watch_directory,15,15,load_start=/home/fabien/bt/watch/*.torrent
schedule = tied_directory,15,15,start_tied=
schedule = untied_directory,15,15,stop_untied=
 
# Répertoire où déplacer les fichiers lorsqu'ils sont complets
system.method.set_key = event.download.finished,move_complete,"execute=mv, \
-u,$d.get_base_path=,/home/fabien/bt/completed ; \
d.set_directory=/home/fabien/bt/completed"
 
# On envoie un email pour prévenir qu'un fichier est téléchargé
system.method.set_key = event.download.finished,notify_me, \
"execute=/home/fabien/bin/rtorrent_mail.sh,$d.get_name="
 
# Ferme le torrent lorsque l'espace disque est minimal
schedule = low_diskspace,5,60,close_low_diskspace=100M
 
# Ratio de 1:1 pour les fichiers inferieurs à 500Mo, sinon ratio de 2:1
ratio.min.set=100
ratio.upload.set=200M
ratio.max.set=200

Je passe sur son explication, c’est assez explicite. Pour plus d’informations, se reporter à la documentation du site de rTorrent.

Pour aider au lancement du programme, voici un script bash lançant rTorrent dans un screen :

#!/bin/bash
screen -dmS rtorrent nice -n 15 rtorrent

Ce deuxième script permet de visualiser le déroulement de rTorrent (en ré-attachant le screen) :

#!/bin/bash
stty stop undef
stty start undef
screen -rd bt

En ce qui me concerne, mes scripts sont sous ~/bin, ne pas oublier de leur attribuer les droits en exécution :

$ chmod +x ~/bin/btlaunch ~/bin/btview

Et voici un script rc qui permet de gérer rTorrent à la sauce Archlinux et de le démarrer en tant que daemon avec la machine, rtorrent :

#!/bin/bash
 
. /etc/rc.conf
. /etc/rc.d/functions
 
case "$1" in
start)
stat_busy "Starting rtorrent"
su fabien -c 'screen -d -m -S bt rtorrent' &> /dev/null
if [ $? -gt 0 ]; then
stat_fail
else
add_daemon rtorrent
stat_done
fi
;;
stop)
stat_busy "Stopping rtorrent"
killall -w -s 2 /usr/bin/rtorrent &> /dev/null
if [ $? -gt 0 ]; then
stat_fail
else
rm_daemon rtorrent
stat_done
fi
;;
restart)
$0 stop
sleep 1
$0 start
;;
*)
echo "usage: $0 {start|stop|restart}"
esac
exit 0

Et enfin le petit bash d’envoi de l’email en fin de téléchargement, rtorrent_mail.sh :

#!/bin/bash
echo "$(date) : $1 - Download completed." | mail -s "[rtorrent] - Download completed : $1" mon@adresse.net

Lancement et utilisation

Voilà, c’est terminé, il ne reste plus qu’à lancer le daemon et accessoirement de visualiser l’état avec les scripts :

$ ~/bin/btlaunch.sh
$ ~/bin/btview.sh

Lancement/arrêt/re-démarrage avec la commande rc :

# /etc/rc.d/rtorrent start
# /etc/rc.d/rtorrent stop
# /etc/rc.d/rtorrent restart

Mais pour voir l’évolution, il faut bien entendu ajouter des torrents, pour se faire, copier simplement les fichiers .torrent dans le répertoire watch. Et vous verrez les téléchargements débuter. Ensuite l’utilisation se fait par quelques commandes, en voici quelques unes :

CTRL+d         Stoppe un torrent (ou supprime un torrent arrêté)
CTRL+q         Quitte rTorrent (ferme le screen)
CTRL+s         Démarre un torrent arrêté
CTRL+a puis d     Détache le screen (rTorrent tourne toujours)
a ou s ou d ou     Augmente l’upload de 1Kb/s ou 5Kb/s ou 50Kb/s
z ou x ou c     Réduit l’upload de 1Kb/s ou 5Kb/s ou 50Kb/s
A ou S ou D ou     Augmente le download de 1Kb/s ou 5Kb/s ou 50Kb/s
Z ou X ou C     Réduit le download de 1Kb/s ou 5Kb/s ou 50Kb/s

​

Cet article fut publié pour la première fois le 18 février 2008.

Leonidas est dans la place

Après une tentative plutôt infructueuse par le biais de preupgrade – tout se passait bien, mais après la demande de redémarrage, j’étais toujours sous F10 – j’ai décidé de télécharger le DVD de Leonidas, ne serait-ce que pour l’avoir, et de faire la mise-à-jour.

Celle-ci s’est bien passée, mais les problèmes ont débuté avec YUM qui n’était plus là : no module named yum et un soucis de version du paquet rpm-python. J’ai vite vu que c’était toujours la version F10 du gestionnaire de paquets qui était présente, d’où le problème de dépendance relatif à python. J’ai donc installé le RPM de YUM pour F11 et tout est rentré dans l’ordre. J’ai pu mettre à jour cette F11 (pas vraiment) fraîchement installée.

Le gros du soucis a été du côté du serveur DHCP, celui-ci ne voulant absolument pas démarrer. Les logs m’indiquaient qu’il fallait spécifier l’interface réseau utilisée dans le dhcpd.conf comme j’ai deux cartes réseaux. J’ai retourné la doc d’ISC et les forums pendant une bonne heure et demi (je n’ose pas dire deux..) pour m’apercevoir que désormais le fichier de configuration se trouve sous /etc/dhcp et non plus directement sous /etc. L’adage « Petite cause, grands effets » est souvent de mise en informatique – genre pour les problèmes en séries – mais là c’était « Grand effet, petite cause« .

OS 3.0 pour iPhone

Le passage a F11 m’a permis la mise-à-jour de l’iPhone également. Petite étape en OS officiel avant le jailbreak dès qu’il sera disponible.
D’apparence aucun lien entre les deux sujets de ce billet si ce n’est que j’avais besoin d’edoras pour cette opération car ma bibliothèque iTunes est sur un volume NFS du serveur linux, donc pas d’iTunes, pas de mise-à-jour de l’iPhone.

Au menu des nouveautés en vrac donc : enfin le copier-coller-couper, dictaphone, MMS, mode paysage généralisé, Spotlight, synchro des notes, secouer l’appareil pour mélanger….

Utilisation

L’utilisation de la commande dig est la suivante :

dig @serveur nom type

@serveur : le serveur DNS utilisé pour la requête. nom : le nom du serveur DNS à interroger. type : le type d’enregistrement à vérifier. Mais la forme la plus simple est l’appel de la commande suivi du nom d’hôte à vérifier :

$ dig feub.net

Qui retourne quelque chose comme :

; <<>> DiG 9.5.1-P1-RedHat-9.5.1-1.P1.fc10 <<>> feub.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10503
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;feub.net.                      IN      A
;; ANSWER SECTION:
feub.net.               75788   IN      A       80.93.82.79
;; AUTHORITY SECTION:
feub.net.               75788   IN      NS      NS31B.HAISOFT.net.
feub.net.               75788   IN      NS      NS31A.HAISOFT.net.
;; ADDITIONAL SECTION:
NS31A.HAISOFT.net.      47403   IN      A       80.93.82.79
NS31B.HAISOFT.net.      41905   IN      A       80.93.82.217
;; Query time: 2 msec
;; SERVER: 192.168.75.1#53(192.168.75.1)
;; WHEN: Mon Feb  2 10:58:33 2009
;; MSG SIZE  rcvd: 122

Beaucoup d’informations sont retournées. Le première partie renseigne sur la version même de dig utilisée, suivi des options globales, dans cet exemple : printcmd qui peut ne pas être affiché en utilisant l’option +nocmd juste après le dig. La partie qui suit – Got answer – apporte des informations sur le serveur. Cette partie ne sera pas affichée en ajoutant l’option +nocomments, mais attention car elle supprime également les entêtes de sections.
Arrive la section QUESTION SECTION qui comme son nom l’indique affiche la question que vous avez posé au serveur DNS. Dans la forme simplifiée utilisée ici, la recherche est par défaut faite sur les enregistrements A. En général, vous savez ce que vous avez demandé, donc pour neutraliser cette partie dans le résultat, utiliser l’option +noquestion.
Pour terminer, la réponse est affichée dans la section ANSWER SECTION. L’IP de feub.net est 80.93.82.79. Même cette partie du résultat peut être neutralisée avec l’option +noanswer (mais je ne vois pas dans quel cas on demande quelque chose sans être intéressé par la réponse…).
La section AUTHORITY SECTION renseigne sur les serveurs DNS autoritaires du domaine. Pour ne pas afficher cette section, c’est l’option +noauthority.
La fin affiche la section ADDITIONAL SECTION qui donne les IP des serveurs DNS autoritaires utilisés pour la requête. On devine comment ne pas l’afficher : +noadditional
Et le résultat se termine par des statistiques sur la requête, que l’on désactive par l’option +nostats.

Quelques exemples

# Obtenir l'adresse du serveur hébergeant feub.net
$ dig feub.net A +noall +answer
# Obtenir la liste des serveurs de messagerie de Google
$ dig google.com MX +noall +answer
# Obtenir la liste des serveur DNS autoritaires pour Google
$ dig google.com NS +noall +answer
# Obtenir toutes les informations demandées ci-dessus
$ dig google.com ANY +noall +answer

Pour avoir un résultat court :

$ dig google.com +short

Beaucoup de possibilité avec toutes ces petites options.

Configuration d’Apache

Il faut s’assurer que le serveur web Apache puisse utiliser les fichiers .htaccess. Pour ce faire, il faut lui ajouter la directive AllowOverride AuthConfig. Ceci peut se faire directement dans le httpd.conf, mais il est recommandé – et plus clair – de ne pas y toucher et d’ajouter ses propres fichiers de configurations sous /etc/httpd/conf.d/. Il est en effet plus simple d’avoir plusieurs fichiers bien nommés qu’un énorme qu’il serait fastidieux d’éditer. Dans mon cas, j’ai détaché les directives concernant /var/www du httpd.conf dans un fichier fab_docroot.conf sous /etc/httpd/conf.d/ (petite entorse à ce qui est dit plus haut de ne pas toucher au fichier principal. Mais c’est pour la bonne cause ;} ). Attention, je ne fais ceci que parce que je n’héberge qu’un seul site qui est directement sous /var/www.

Voici donc la tête des directives en question pour accepter l’authentification par .htaccess :

<Directory /var/www>
Options Indexes Includes FollowSymLinks MultiViews
AllowOverride AuthConfig
Order allow,deny
Allow from all
</Directory>

Sauvegarder le fichier et redémarrer Apache :

# service httpd restart

Créer un fichier .htpasswd

Ce dernier ce crée avec la commande ….. htpasswd (sans le point bien sur), facile ;} Celle-ci génére un fichier texte contenant le (ou plusieurs) nom d’utilisateur et un hash du mot de passe associé pour l’authentification HTTP.

# htpasswd -c /chemin/vers/fichier/du/mot-de-passe fabien

L’option -c crée un nouveau fichier. Pour mettre à jour un mot de passe existant, il suffit de l’enlever.

Il est conseillé de créer ce fichier en dehors de la racine des documents Apache pour que seul celui-ci puisse y avoir accès et ainsi que personne (visiteur du site) puisse le voir.
Il faut s’assurer également que l’utilisateur Apache puisse le lire pour que l’authentification fonctionne. Normalement avec Fedora, cet utilisateur s’appelle Apache, le vérifier comme suit :

# grep -e '^User' /etc/httpd/conf/httpd.conf
User apache

Changer le propriétaire et les droits :

# chown apache:apache /chemin/vers/fichier/du/mot-de-passe
# chmod 0660 /chemin/vers/fichier/du/mot-de-passe

L’utilisateur fabien est désormais ajouté. La dernière étape consiste à configurer le serveur web pour qu’il demande de s’authentifier pour un répertoire donné. Pour l’exemple, le répertoire protégé sera sous /var/www/html/secured.

Création du répertoire :

# mkdir /var/www/html/secured

Création du fichier .htaccess avec ces directives :

AuthType Basic
AuthName "Zone sécurisée"
AuthUserFile /chemin/vers/fichier/du/mot-de-passe
Require user fabien

Tester la configuration

Il suffit de se rendre à l’URI sécurisée pour voir la boîte de dialogue de demande d’un utilisateur apparaître : http://www.mon-site.net/admin

Demande d’authentification

En cas de problème, vérifier les log d’erreurs Apache :

# tail -f /var/log/httpd/error_log