Tag - debian

Entries feed - Comments feed

Last entries

Thu 14 Jan 2010

Quick news: OCaml on Ubuntu Lucid and MapOSMatic

OCaml on Ubuntu Lucid

I have updated my scripts to compare Ubuntu OCaml packages to Debian ones. This time, I'm comparing Ubuntu Lucid against Debian testing, as for Lucid packages are imported from Debian testing (because Lucid is a Long Term Support release).

You'll find all the generated files here: http://bentobako.org/ubuntu-ocaml-status/raw/


As you have probably seen, we have done major improvements to MapOSMatic during Christmas, at both the web site level and the rendering level. I won't go into details, just read our initial announcement. Since then, we are continuing our improvements on maposmatic web front-end and ocitysmap back-end, with a new web site layout, translation of web site and maps in many languages (Arabic, Brazilian Portuguese, Catalan, Dutch, French, German, Italian and Russian). Many thanks to the numerous contributors!

We still have a lot of things to do or bugs to fix but the feedback is very positive and rewarding! Many thanks!

Thu 19 Nov 2009

OCaml on Ubuntu: looking for a new maintainer

HELP At some point I helped keeping the OCaml packages on Ubuntu in good shape, especially for the Karmic 9.10 release.

Unfortunately, I have much less free time those days and can no longer monitor OCaml packages on Ubuntu. Is anybody willing to work on this?

The main job is to look at the Debian packages and check if they are currently available in Ubuntu, and rebuild them if necessary. When the OCaml compiler changes (fortunately not so often), one needs to trigger a rebuild of all packages and that can be a bit difficult, mainly because LaunchPad does not provide an interface to rebuild several packages, taking into account their dependencies.

Of course, I would help anybody willing to do that job (explain the needed scripts, issues I had, etc.).

Mon 27 Jul 2009

Secure setup of DokuWiki with Lighttpd web server on Debian Lenny

Logo DokuWiki DokuWiki is a very nice wiki programmed in PHP that does not use any database. It is very simple to setup and use. As I am using the lighttpd web server instead of Apache, making a secure installation requires a configuration a bit different from the usual one.

Here is the configuration I am using. Contrary to our installation in Niadomo, I'm using the original source tarball and not the Debian package. It is heavily inspired by installation documentation and security documentation of DokuWiki. I strongly recommend to read this security documentation before doing any installation.

DokuWiki installation

We firstly download and configure DokuWiki so the installed wiki is available as example.com/mydoku, assuming example.com is the name of your web site. I am assuming /var/www is the root directory of your lighttpd server.

 $ cd /tmp
 $ wget http://www.splitbrain.org/_media/projects/dokuwiki/dokuwiki-2009-02-14b.tgz
 $ tar zxf dokuwiki-2009-02-14b.tgz
 $ sudo mv /tmp/dokuwiki-2009-02-14 /var/www/mydoku
 $ sudo chown -R www-data:www-data /var/www/mydoku

We then access the configuration script http://example.com/mydoku/install.php to configure it. I won't detail this part as it is up to you to choose a configuration that suites your needs. Refer to DokuWiki install.php instructions for further details.

Making DokuWiki secure

Firstly, we remove the installation script no longer necessary.

 $ sudo rm /var/www/mydoku/install.php

Secondly, we move data/ and bin/ dokuwiki's directories in a separated directory, /usr/local/installed/mydoku. You can choose any directory that suites your setting but it should be outside of the root directory of your web server, in my case /var/www.

 $ sudo mkdir -p /usr/local/installed/mydoku
 $ sudo mv /var/www/mydoku/bin /usr/local/installed/mydoku/
 $ sudo mv /var/www/mydoku/data /usr/local/installed/mydoku/
 $ sudo mv /var/www/mydoku/README /usr/local/installed/mydoku/
 $ sudo mv /var/www/mydoku/VERSION /usr/local/installed/mydoku/
 $ sudo mv /var/www/mydoku/COPYING /usr/local/installed/mydoku/

Then we configure conf/local.php so that the installed dokuwiki knows how to look for its data and binaries. We use for this the $conf['savedir'] functionnality[1]. We also configure allowdebug to 0, to avoid giving information to attackers in case of error.

 $ sudo vi /var/www/mydoku/conf/local.php

We add the following two lines:

 $conf['savedir'] = '/usr/local/installed/mydoku/data';
 $conf['allowdebug']  = 0;

We then configure lighttpd to avoid deny accesses to inc/ and conf/ directories. We use the very specific Debian way, creating a dedicated lighttpd configuration file and activating it.

$ cat > /etc/lighttpd/conf-available/11-dokuwiki.conf

Add following content:

  $HTTP["url"] =~ "^/mydoku/inc" {
    url.access-deny = ("")
  else $HTTP["url"] =~ "^/mydoku/conf" {
    url.access-deny = ("")

I am simply using regular expressions to deny access to the two directories.

We then enable this configuration and restart dokuwiki.

 $ sudo lighty-enable-mod dokuwiki
 $ sudo invoke-rc.d lighttpd restart

You can now check that the accesses to http://example.com/mydoku/conf/local.php or http://example.com/mydoku/inc/io.php are now denied.

Have fun with your new wiki!


[1] Some people would call that a hack. ;-)

Thu 23 Jul 2009

Transition to OCaml 3.11.1 has started in Karmic

OCaml I previously mentioned that Ubuntu Karmic currently ships with OCaml 3.11.0 and all associated libraries and programs. While it is nice to have a coherent set of OCaml packages, it would be much better to the latest coherent set of OCaml packages in Karmic! :-) Debian initiated its own transition to 3.11.1 about 4 weeks ago and this transition is nearly finished (and took in fact only 3 weeks).

I therefore raised the issue of such a transition for Karmic. After a few questions, it has been agreed upon to start a similar transition in Karmic. Moreover Andrea Gasparini, an Ubuntu's Master Of The Universe (aka MOTU), volunteered to help me. Se we opened the first bug initiating the transition. Overall, there are 124 source packages to synchronize or recompile in 6 successive rounds.

One can monitor the status of the transition of the Ubuntu OCaml transition monitor. A comparative list of source package versions between Debian unstable and Ubuntu karmic is also available.

Thu 25 Jun 2009

Transition to OCaml 3.11.1 has started in Debian

Debian The 24th of June, the Debian package for new upstream OCaml 3.11.1 has been uploaded. Thus upload marks the start of the transition to OCaml 3.11.1 in Debian Sid (aka unstable). Right now, the new package has been successfully built on most of Debian supported architectures.

Following this first round, other packages are being uploaded in successive rounds. You can follow this transition on Stéphane Glondu's dedicated OCaml transition monitor.[1]

The count-down has started. We will see how much time it will take to do this transition for the 138 source packages.

Thu 18 Jun 2009

Ubuntu 9.10 will ship with OCaml 3.11.0... for now

As I recently announced on caml-list@, all OCaml packages coming from Debian were correctly compiled against OCaml 3.11.0 in Ubuntu Karmic Koala 9.10 to be released in next October. That means that current Karmic has a coherent set of OCaml packages, which I consider a worthwhile property.

Unfortunately, OCaml 3.11.1 has just been released and Debian developers are starting a transition to OCaml 3.11.1 in Debian unstable. As until the 25th of June all packages are directly imported from Debian unstable to Ubuntu Karmic, that would break various OCaml packages in Karmic, certain packages being compiled with 3.11.0 while others with 3.11.1.

Consequently, after discussion with Debian and Ubuntu developers[1], I have decided:

  1. To block the automatic import of OCaml packages from Debian to Ubuntu[2]. This blocking is currently effective. So, from now, Karmic will ship with OCaml 3.11.0 and the current package versions;
  2. To monitor transition from 3.11.0 to 3.11.1 in Debian and, if done quickly enough, to trigger a similar transition in Karmic. The Feature Freeze is set to the 27th of August so this is the absolute limit date for such a transition to end.

I am also considering providing 3.11.1 packages through Ubuntu PPA (Personal Package Archive) system. But I first need to learn how to use it. :-) But even if Karmic does not ship with 3.11.1, Karmic+1 which is LTS (Long Term Support) will have it.

If you read this blog entry and have an issue with this decision, let me know either through the comments or by sending an email at: dmentre AT linux-france.org.


[1] Several Ubuntu people were in favor of also doing such a transition in Karmic, but I cannot commit to monitor and handle it during that time period.

[2] I have been pretty conservative and blocked all OCaml based packages (because an updated package might need in up-to-date version of OCaml). We might lift this constraint a bit and allows synchronization of certain packages. Right now, I have not seen any such need. You can monitor the status of out-of-sync package in Karmic on this page.

Mon 15 Jun 2009

Niadomo épisode 4 : installation du paquet dokuwiki sur une Debian Lenny

DokuWiki Dans notre projet d'auto-hébergement (cf. les précédents épisodes de la série), nous avons besoin d'un wiki pour mettre à jour nos documentations internes, le journal de bord de la machine, etc. Nous avons décidé d'installer DokuWiki, un excellent wiki en PHP, en utilisant le paquet Debian.[1]

La première partie de l'installation est simple :

 $ sudo aptitude install dokuwiki

On répond à quelques questions d'aptitude :

 Dokuwiki Emplacement Root : /notrewiki
 Select web server: Apache2
 Purging pages on removal : Non

Il est préférable de ne pas mettre dokuwiki à l'URL habituelle, histoire de déranger les script kiddies, d'où le choix de /notrewiki pour l'emplacement du wiki.

Une fois ceci fait, la configuration véritable commence, tout d'abord en re-configurant le paquet :

 $ sudo dpkg-reconfigure dokuwiki
 Dokuwiki Emplacement Root : /notrewiki
 Select web server: Apache2
 Access control : Sans restriction
 Purging pages on removal : Non

Le paquet Debian de dokuwiki a fortement modifié l'emplacement des fichiers originaux de dokuwiki, pour respecter les règles Debian et pour améliorer la sécurité du paquet.[2]

La plupart des fichiers sont maintenant installés dans /usr/share/dokuwiki/. En particulier, des informations pour configurer Apache sont disponibles dans le fichier /usr/share/dokuwiki/.htaccess.

Le fichier de configuration de dokuwiki pour Apache est /etc/dokuwiki/apache.conf. Ce fichier se retrouve également dans la configuration d'Apache, avec un lien symbolique de /etc/apache2/conf.d/apache.conf vers /etc/dokuwiki/apache.conf.

Nous éditons la configurations de ce fichier, en en faisant préalablement une copie.

 $ sudo mkdir -p /root/etc/dokuwiki/
 $ sudo cp /etc/dokuwiki/apache.conf /root/etc/dokuwiki/apache.conf.2009-06-10
 $ sudo vi /etc/dokuwiki/apache.conf

Nous ajoutons des règles permettant d'avoir des URL simples et lisibles. Le nouveau contenu ajouté provient de /usr/share/dokuwiki/.htaccess.

 RewriteEngine on
 RewriteRule ^_media/(.*)              lib/exe/fetch.php?media=$1  [QSA,L]
 RewriteRule ^_detail/(.*)             lib/exe/detail.php?media=$1  [QSA,L]
 RewriteRule ^_export/([^/]+)/(.*)     doku.php?do=export_$1&id=$2  [QSA,L]
 RewriteRule ^$                        doku.php  [L]
 RewriteCond %{REQUEST_FILENAME}       !-f
 RewriteCond %{REQUEST_FILENAME}       !-d
 RewriteRule (.*)                      doku.php?id=$1 [QSA,L]
 RewriteRule ^index.php$               doku.php

Nous passons ensuite à la configuration de dokuwiki proprement dit. Dans le répertoire /etc/dokuwiki/, les fichiers en *.dist sont des fichiers de référence, que l'on peut copier et éditer en une version sans le suffixe .dist pour changer la configuration.

Les fichiers suivants sont à configurer :

  • /etc/dokuwiki/acl.auth.php : les droits d'accès des utilisateurs ;
  • /etc/dokuwiki/users.auth.php : les comptes des utilisateurs du wiki ;
  • /etc/dokuwiki/local.php : notre configuration de dokuwiki. Il est recommandé de ne pas modifier /etc/dokuwki/dokuwiki.php car ce fichier pourra être modifié lors de la mise à jour du paquet.
 $ sudo cp /etc/dokuwiki/local.php.dist /root/etc/dokuwiki/local.php.2009-06-10
 $ sudo vi /etc/dokuwiki/local.php

Nous ajoutons le contenu suivant :

// Le titre du wiki affichée dans la barre de titre
 $conf['title']       = 'Notre wiki tiptop';  
 // On veut utiliser les contrôles d'accès
 $conf['useacl']      = 1; 
 // Est super-utilisateur (alias administrateur) tous les membres du groupe (le @) niadomo
 $conf['superuser']   = '@niadomo'; 
 // On ne peut pas créer de compte avec génération de mot de passe
 $conf['autopasswd']  = 0; 
 // Groupe par défaut pour les nouveaux utilisateurs : niadomo
 $conf['defaultgroup']= 'niadomo'; 
 // Actions interdites : enregistrement de nouveaux comptes et l'envoi de mots de passe par courriel
 $conf['disableactions']= 'register,resendpwd'; 
 // Le wiki est en français
 $conf['lang']= 'fr'; 
 // Le courriel de provenance des messages envoyés par le wiki
 $conf['mailfrom']= 'webmaster@niadomo.net'; 
 // Le nom de la page de démarrage[3]
 $conf['start']= 'accueil'; 
 // On n'affiche pas les messages indiquant qu'une mise à jour de sécurité est disponible.[4]
 $conf['updatecheck']= 0; 
 // On a configuré Apache pour utiliser la ré-écriture d'URL, nous permettant d'avoir des URL propres
 $conf['userewrite']= 1;

On configure ensuite les droits d'accès :

 $ sudo vi /etc/dokuwiki/acl.auth.php

Et on rajoute dans ce fichier la ligne qui interdit par défaut toute action :

 *  @ALL   0

Par défaut, personne n'a accès au wiki, il faut donc ajouter les utilisateurs à la main.

On génère l'encodage du mot de passe à utiliser dans le fichier de configuration grâce à l'utilitaire md5sum :

 $ md5sum
 totof71dbe52628a3f83a77ab494817525c6  -

La partie en gras est ce qu'on entre au clavier, la partie en italique est produite par le programme. Le mot de passe toto n'est pas terrible. Même s'il est temporaire, vous pouvez utiliser un mot de passe un peu plus sûr. ;-)

On recopie la partie après toto (71dbe52628a3f83a77ab494817525c6) dans le fichier des mots de passe de dokuwiki :

 $ sudo vi /etc/dokuwiki/users.auth.php

Et voilà, dokuwiki est configuré. Il ne reste plus qu'à relancer Apache et à créer les autres utilisateurs :

$ sudo invoke-rc.d apache2 reload

On accède ensuite à notre wiki à l'URL https://niadomo.net/notrewiki.

On se connecte par le bouton Connexion et on ajoute des nouveaux utilisateurs dans le panneau accessible par le bouton Admin.

 Identifiant : 	user2
 Mot de passe :  un-bon-mot-de-passe
 Nom : 	User 2
 Courriel :  user2@niadomo.net
 Groupes :  niadomo
 Notifier l'utilisateur : 	[ ] (décochée, on ne doit pas envoyer les mots de passe par email en clair)

Ne pas oublier de changer le mot de passe du premier utilisateur (user1) s'il est faible !!

Et voilà, votre wiki est configuré et vous pouvez vous empresser de mettre à jour vos documentations. ;-)

Un dernier petit truc : si vous voulez modifier la licence par défaut, vous devez modifier le fichier /usr/lib/dokuwiki/tpl/default/footer.html.


[1] Vu la complexité de l'installation et la maturité du paquet, c'est à mon avis pas super judicieux, mais je ne suis pas le seul à décider. :-)

[2] Je ne suis pas convaincu de ce dernier point.

[3] Oui, je sais, moi aussi je préférais start. ;-)

[4] Vu que la version Debian est toujours en retard et que normalement le paquet Debian doit être mis à jour en cas de faille de sécurité.

Thu 11 Jun 2009

OCaml 3.11.0 on Ubuntu Karmic Koala nearly complete

OCaml As I have previously stated, there is no OCaml developers on Ubuntu and all OCaml packages in Ubuntu are coming from Debian. So there is apparently no much work to do in order to have a large set of OCaml packages on Ubuntu. Except that there are synchronisation issues. :-)

Debian's OCaml packages are imported automatically from unstable repository a the beginning of each new development cycle of Ubuntu[1] until a Debian Import Freeze takes effect (the 25th of June according to Karmic release schedule). Once imported, packages are automatically build. But OCaml packages have a stringent need to be compiled in the right order and against the correct version of the OCaml tool chain. In case of change (e.g. going from 3.10.2 to 3.11.0) all packages should be recompiled.

Therefore, I have adapted original Debian's monitoring scripts to Ubuntu:

Ocaml transition monitor for Ubuntu

On the 124 of such OCaml packages in Ubuntu, only 3 have remaining issues:

Once done, all OCaml packages should be correctly rebuild for OCaml 3.11.0. \o/

Of course, OCaml 3.11.1 should be released Really Soon Now™ and all that work should be redone once again. "There is no such thing as a simple job".[2] ;-)


[1] One can monitor the import of new packages on page http://packages.ubuntu.com/karmic/n....

[2] Tim Daily, of Axiom's fame.

Mon 11 May 2009

Un client demexp pour Ubuntu 9.04 / amd64

J'ai compilé un client demexp (client de vote pour l'expérience démocratique) pour la version Ubuntu 9.04 Jaunty Jackalope en architecture amd64 (version 64 bits pour processeurs x86 d'Intel et d'AMD). Il est disponible dans cette archive.

J'ai aussi remis à jour le code et les notes de version dans les arbres Mercurial de la version de développement (la 0.9) et la dernière version stable 0.8.

Avec la doc fournie, il doit être relativement facile de compiler un client demexp stable 0.8 sur une Debian Lenny ou une Ubuntu 9.04, sur toutes les architectures x86, 32 ou 64 bits.

Thu 07 May 2009

Niadomo épisode 3 : installation d'un serveur web et d'un webmail

Ce billet est sous licence Art Libre 1.3.

Après le précédent épisode, nous continuons l'installation de notre serveur d'auto-hébergement. Au programme aujourd'hui :

  • un script pour enregistrer les commandes ;
  • l'installation du serveur web ;
  • l'installation d'un webmail ;
  • accéder à des applications graphiques sur le serveur.

Un ch'tit script pour enregistrer les commandes

Quand on gère à plusieurs un serveur, il est indispensable de garder une trace précise de ce que chacun fait. C'est pour cela que nous avons créé la commande nia-script, à appeler avant de faire toute manipulation sur la machine. Le principe de ce petit shell script est très simple : appeler la commande script en demandant l'enregistrement des commandes dans un fichier nommé d'après la date et l'heure courantes.

Nous créons donc le fichier /usr/local/bin/nia-script qui a le contenu suivant :


nom=$(date +%FT%T)
script -t -a 2>$chemin/$nom.time $chemin/$nom.typescript

Les enregistrements de commandes sont faites dans le répertoire /root/nia-scripts/ avec des fichiers de nom du style 2009-05-05T23:14:34.typescript. Nous créons donc ce répertoire de tel sorte que son contenu soit accessible en lecture/écriture uniquement par les membres du groupe adm, c'est à dire les gentils administrateurs bénévoles que nous sommes :

 $ sudo mkdir /root/nia-scripts
 $ sudo chown root:adm /root/nia-scripts
 $ sudo chmod 770 /root/nia-scripts

Après tout ça, avoir de faire quoi que ce soit sur la machine, il suffit de faire..

 $ nia-script

...et toutes les commandes sont maintenant enregistrées.

Installation du serveur web Apache 2

apache_feather.png Pour le serveur web de notre hébergement, nous utilisons très classiquement Apache 2. Nous aurions pu utiliser un autre serveur web plus performant, mais comme nous voulons que chaque hébergé puisse relativement facilement influencer la configuration du serveur relative à son espace personnel, nous pensons que Apache avec ses .htaccess convient bien.

L'installation est on ne peut plus simple :

 $ sudo aptitude install apache2

Petit rappel de la configuration d'Apache 2 dans une Debian :

  • les fichiers qui compose le site web sont dans /var/www/, avec en particulier le fichier /var/www/index.html qui est la page web affichée par le serveur fraichement installé ;
  • les fichiers de configuration spécifique d'Apache doivent être installés dans /etc/apache2/conf.d/ ;
  • les modules disponibles sont visibles dans /etc/apache2/mods-available/ alors que les modules effectivement utilisés par le serveur sont visibles dans /etc/apache2/mods-enabled/ (par des liens symboliques sur les fichiers du répertoire mods-available/) ;
  • de manière similaire, les sites web disponibles sont visibles dans /etc/apache2/sites-available/ alors que les sites web effectivement servis par le serveur sont visibles dans /etc/apache2/sites-enabled/ (par des liens symboliques sur les fichiers du répertoire sites-available/).

Pour activer ou désactiver un module on utilise les commandes a2enmod et a2dismod. De même, pour activer ou désactiver un site on utilise les commandes a2ensite et a2dissite.

Pour améliorer la sécurité de notre serveur, nous décidons de rendre le serveur Apache moins verbeux (il ne donnera plus son numéro de version) et de désactiver certaines commandes inutiles du protocoles HTTP en utilisation courante (TRACE qui peut être utilisé pour des attaques). Pour ce faire nous éditons le fichier de config' après en avoir fait une sauvegarde préalable[1] :

 $ mkdir -p /root/etc/apache2/conf.d/
 $ cp /etc/apache2/conf.d/security /root/etc/apache2/conf.d/security.2009-05-04
 $ sudo vi /etc/apache2/conf.d/security

Et nous modifions son contenu pour avoir la configuration suivante :

 ServerTokens Prod
 ServerSignature Off
 TraceEnable Off

Un petit redémarrage du serveur permet de prendre en compte la configuration :

 $ sudo invoke-rc.d apache2 reload

Une hiérarchie web par utilisateur

Pour faciliter la mise à jour de contenu de nos membres auto-hébergés, nous utilisons une configuration assez classique où le contenu du répertoire ~/public_html/ de l'utilisateur toto est accessible à l'URL http://niadomo.net/~toto/.

Pour réaliser cette configuration, il suffit juste d'activer le module Apache userdir !

 $ sudo /usr/sbin/a2enmod userdir
 $ sudo invoke-rc.d apache2 restart

Et voilà ! ;-)

Serveur web accessible en connexion sécurisée HTTPS

Nous voulons pouvoir accéder de manière sécurisée à notre serveur web, en particulier pour les données sensibles comme le webmail ou les authentification. Nous utilisons pour se faire le module Apache ssl et le site web default-ssl (inactif par défaut). Nous n'avons pas le temps de configurer les redirections de HTTP vers HTTPS (pour éviter les erreurs de manipulation) donc pour l'instant notre serveur web sera accessible uniquement en HTTPS (en désactivant le site web par défaut : default).

 $ sudo /usr/sbin/a2enmod ssl
 $ sudo /usr/sbin/a2ensite default-ssl
 $ sudo /usr/sbin/a2dissite default
 $ sudo invoke-rc.d apache2 restart

Nous vérifions que notre site web est toujours accessible à l'URL https://niadomo.net.

Configuration du webmail SquirrelMail

squirrelmail_logo.png Comme webmail, nous avons décidé d'installer SquirrelMail. Nous aurions préféré RoundCube ou un autre webmail plus moderne mais RoundCube n'est pas disponible comme paquet Debian dans Lenny. Donc nous avons choisi la voie de la facilité. ;-)

L'installation est simple :

 $ sudo aptitude install squirrelmail

La configuration est tout aussi simple :

 $ sudo squirrelmail-configure

Dans le menu de configuration qui apparait, nous choisissons :

  • la configuration pré-réglée pour Dovecot, notre serveur IMAP : choix « D » puis « dovecot », puis « R » pour revenir au menu principal ;
  • nous installons les plugins suivants par le menu « Plugins » :
    • mail_fetch
    • newmail
    • filters
    • message_details
    • squirrelspell
    • calendar
    • administrator
    • spamcop
  • nous configurons pour que le logiciel soit en Français par défaut par le menu « Languages »
    • Default Language: fr_FR
    • Default charset: iso-8859-1

Pour le reste, nous conservons la configuration par défaut. Un petit « S » pour sauvegarder la configuration et « Q » pour quitter l'utilitaire squirrelmail-configure.

Pour que la traduction française fonctionne, il faut que la locale ISO-8859-1 soit disponible. Nous l'ajoutons donc à notre configuration :

 $ sudo dpkg-reconfigure locales

On a choisit d'ajouter toutes les locales françaises :

  • fr_FR
  • fr_FR.UTF-8
  • fr_FR@euro

Il faut ensuite configurer Apache pour qu'il serve maintenant le site SquirrelMail, ce qui se fait avec un simple lien :

 $ sudo ln -s /etc/squirrelmail/apache.conf /etc/apache2/squirrelmail.conf

Une dernière modification de sécurité ! Par défaut, SquirrelMail est accessible à l'URL standard http://niadomo.net/squirrelmail. Pour éviter les attaques trop aisées, nous utilisons une autre URL par défaut, par exemple « monecureuil ». Pour se faire il faut modifier le fichier de configuration Apache de SquirrelMail :

 $ sudo vi /etc/squirrelmail/apache.conf

Et y modifier la première ligne en :

 Alias /monecureuil /usr/share/squirrelmail

Un petit coup de redémarrage d'Apache ...

$ sudo invoke-rc.d apache2 restart

... et normalement notre nouveau webmail est accessible à l'URL http://niadomo.net/monecureuil.

Vérification de la configuration de SquirrelMail

La documentation de SquirrelMail[2] nous indique que l'on peut vérifier en local (c.-à-d. sur le serveur) la configuration de SquirrelMail en accédant à l'URL src/configtest.php :

 $ lynx

Ce test nous indique que la configuration PHP5 magic_quotes_gpc doit être désactivée, ce que nous faisons :

 $ sudo vi /etc/php5/apache2/php.ini

Et nous modifions la ligne suivante en Off (au lieu de On) :

 magic_quotes_gpc = Off

Et voilà, nous avons maintenant un serveur web personnel et un webmail sécurisé à disposition ! Alors, c'est si difficile que ça l'auto-hébergement ? ;-)

Configuration pour utiliser une application graphique sur le serveur

Habituellement, sur un serveur, on ne met aucune application graphique et on utilise des éditeurs en mode texte comme vi ou nano pour éditer les fichiers de configuration. Quel que soit le système Unix que vous utiliserez, vous aurez toujours l'éditeur vi[3] à disposition donc il est recommandé de savoir au moins éditer trois lignes avec. ;-)

Mais bon, quand on débute, c'est parfois un peu compliqué donc voici les manipulations à faire pour pouvoir accéder à des applications graphiques (c.-à-d. utilisant le serveur X) sur votre serveur.

En premier lieu, installer le paquet xauth :

 $ sudo aptitude install xauth

Ensuite, lors de votre connexion en ssh sur le serveur, utilisez les options -X pour demander la propagation (forwarding) du terminal graphique X[4] et -C pour la compression :

 ssh -C -X toto@lumturo.niadomo.net

Et voilà, vous pouvez maintenant utiliser l'éditeur graphique qui vous convient, par exemple scite :

 $ sudo aptitude install scite
 $ sudo scite /etc/squirrelmail/apache.conf

Mais je le répète, c'est mieux d'apprendre les rudiments de vi et de se souvenir qu'il a deux modes : le mode qui bippe et le mode où l'on massacre son fichier. :-D

  • MàJ 2009-05-10: Ajout de la licence Art Libre pour ce billet.
  • MàJ 2009-08-18: correction typo.


[1] Nous utilisons pour l'instant une hiérarchie parallèle de fichiers de configuration dans /root/etc/... Une autre méthode plus robuste avec un gestionnaire de version sera utilisée par la suite.

[2] Documentation du paquet squirrelmail accessible dans /usr/share/doc/squirrelmail/README.Debian.gz.

[3] vi vient de Visual Editor. Ça peut vous surprendre mais vous n'avez jamais utilisé ed. ;-)

[4] Cela suppose que vous avez bien l'option X11Forwarding yes dans le fichier /etc/ssh/sshd_config de votre serveur.

page 2 / 3