Tag - dokuwiki

Entries feed - Comments feed

Last entries

Sun 27 Jan 2013

The failures of Debian (and its derivatives)

I am a long term Debian user. I have used Debian since probably the mid 90' up to now. I use latest Debian stable on my personal server or at work, and Ubuntu on my desktop and laptop machines at home. Using it does not mean I am entirely satisfied with it to say the least. I think the distribution is not making enough efforts for its users and I'll try to explain why. Of course, YYMV. ;-)

  • Debian packaging is made for developers, not users. Debian has too many packages. To take just one example, the OCaml compiler is packaged into the main compiler, its libraries, the native compiler and the byte code one, etc. Why so many packages? If I am an OCaml developer, I want all of them so why do I need to manually find (the naming is far from being obvious, at least for beginners) and install so many packages? I have heard of several reasons: it allows to factorise common parts between the different binary architectures, it allows to install the command line only parts without the graphics parts, it allows to install only what the user wants, etc. For me, those reasons are just plain wrong. We have more and more disk capacity on our machines so disk usage is no longer a limitation. The package should be able to dynamically activate the graphic parts automatically if the X server is available. And the factorisation of shared parts between Debian architectures should be done on the servers storing the packages, not trough the packaging system.
  • Debian has out-dated software. Debian Wheezy is about to be released and it will have GNOME 3.4. But GNOME 3.6 is already out and GNOME 3.8 is on its way. And I am taking GNOME as an example, it is the same issue for lot of software within Debian. I have heard this is for stability issues. But software packaged in Debian is already stable! It should take 10 or 15 days to integrate a new software into Debian stable, not months or even years (the time between successive stable releases). I acknowledge that some packages have complex interdependencies between each others. For example, when a new release of the OCaml compiler is out, one needs to recompile all OCaml packages. But this constraint is only for OCaml packages. Why should I wait for a new stable version of Debian to get the newly released OCaml compiler? For me this sounds just plain wrong.
  • Nobody uses plain Debian stable. Debian developers are using unstable. Debian users are using Debian stable, but enriched with backports because of out-dated software. Or derivatives like Ubuntu. The fact the Debian developers are not using what they recommend to users is bogus. I know they do that for technical reasons, but that should not be a good reason. Debian developers should use what they are providing to their users, except maybe for a few packages they are working on.
  • There are too many dependencies between packages. The dependency system of Debian is a nice piece of work, it was ahead of its time when it was created. But the use of dependencies has been perverted. The dependencies are manually computed (thus source of errors and bugs) and at the same time any software can write to about any part of the file system. Due to too many dependencies and lack of clean interfaces between sub-systems, the installation of a recent user software can trigger a ton of packages down to a new kernel or libc. Why is it so? I think the sub-systems of Debian (e.g. the X graphical infrastructure, the kernel and base C libraries, the OCaml system, ...) should be isolated the one from the others. It would allow them to be updated without waiting for the others. Having dependencies between 29,000 packages is just not scalable. It is even more true if those dependencies are manually computed.
  • Debian packaging is lacking automation. I am a developer. Debian packagers are developers. It always astonished me how much manual work should be done to make and maintain a Debian package. All developers know that if they want to be efficient, they need to automate their work as much as possible, so as to be able to focus their manpower on the complex parts. Everything should be automated in Debian packages, starting from a minimal description file. Automation should be the default (package creation, test, static analysis, ...), not the exception.
  • One cannot install simultaneously several versions of the same software. As a user or developer, I want to use the stable version of a piece of software and maybe the latest stable version that just have been released in order to do a few tests or check that my software still compiles with the new shiny compiler. Debian does not allow me to do that. And if I install a newer package, downgrading to the previous version is complex and error prone.
  • Debian is undocumented. I am not talking about the installation guide which is nice, I am talking about the modifications made to software by Debian developers. Doing modification on the "standard" (for the software) way of configuring or using it has always seemed suspect to me, even if I agree that having harmonized configuration is a real advantage (all configuration files in /etc for example). But all of those modifications should be documented in README.Debian file. To take an example, the last time I tried to install the dokuwiki Debian package, I was unable to configure it! The way to add new users had been changed compared to a regular dokuwiki (the web interface was disabled), and those changes were undocumented. It should be a release critical bug! Without proper documentation, the user cannot use the software. And, of course, the reason behind those changes should be questioned, even for security reasons (a very secure but unusable software is superfluous. Security is a trade-off).

So, why I am complaining? Why I do not become a Debian Developer, so I can fix it? Because a single developer is not going to change the root causes of those issues. They need a massive development effort, or at least a massive acknowledgement by the Debian Developers. And I don't have ready-made answers to those issues (even if I have some ideas to solve them).

Is the grass greener in the other fields? I don't think so, or at least I am not aware of it. I like Debian for is community approach, its focus on Free Software (even if it is sometimes imperfect) and the wide range of software packaged in it (the OCaml packages are numerous for example). I just hope that the whole Debian community will focus on more user related issues in the future.

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!

Notes

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

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
 toto^D^D
 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
 user1:71dbe52628a3f83a77ab494817525c6:User1:user1@niadomo.net:niadomo

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.

Notes

[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é.