David's blog

To content | To menu | To search

Tag - debian

Entries feed - Comments feed

Monday, March 29 2010

Status of OCaml packages on Ubuntu Lucid Lynx (10.04 LTS): transition to OCaml 3.11.2 finished

I don't know who are responsible for this but the OCaml packages of Ubuntu Lucid Lynx 10.04 LTS have all transitioned to OCaml 3.11.2 on main architectures (amd64 and i386). A big thank to the mysterious developer(s)! Even for secondary architectures, all packages have transitioned to 3.11.2 except 3 packages on armel: coq, ssreflect and why.

Of course, having a source OCaml package compiled with the correct version of the OCaml compiler does not make it automatically working so I encourage you to test your preferred Ubuntu OCaml packages in Lucid.

If we now compare the set of source packages available respectively on Debian Unstable and Ubuntu Lucid, the situation is not so perfect. On the 145 OCaml packages available in Unstable, 21 are not at the same stage in Lucid.

There are 5 packages simply not available in Ubuntu:

  • clang 2.6-3
  • llvm 2.6-8
  • llvm-snapshot 20100312-1
  • obrowser 1.1+dfsg-4
  • unison2.27.57 2.27.57-2

There are 11 packages that have been updated in Unstable but not upgraded in Lucid:

  • Package Unstable-version Lucid-Version
  • approx 4.2-1 4.1-1
  • camlpdf 0.5-1 0.4-4
  • coccinelle 0.2.2.deb-1 0.2.0.deb-1ubuntu2
  • graphviz 2.26.3-3 2.20.2-8ubuntu3
  • ocaml-csv 1.2.0-1 1.1.7-2
  • ocaml-ssl 0.4.4-1 0.4.3-3
  • ocaml-text 0.3-1 0.2-3
  • ocsigen 1.3.0-4 1.2.2-1
  • pgocaml 1.4-1 1.3-3
  • postgresql-ocaml 1.12.4-1 1.12.1-2
  • unison 2.32.52-1 2.27.57-2ubuntu2

And lastly there are 5 packages that had minor updates or packaging bug fix in Unstable but not in Lucid:

  • Package Unstable-version Lucid-Version
  • nurpawiki 1.2.3-4 1.2.3-3
  • frama-c 20090902+beryllium+dfsg-5 20090902+beryllium+dfsg-4
  • ocamlgraph 1.3+debian-2 1.3+debian-1
  • sks 1.1.1-2 1.1.1-1ubuntu2
  • ssreflect 1.2+dfsg-4 1.2+dfsg-3

I don't know what to do about those packages or if I can even do anything. According to Ubuntu Lucid release schedule, we are reaching Beta 2 Freeze (on April the 1st) where uploads for packages in main and restricted are held in the queue and are subject to manual approval of the release team.

Do you have any advice?

Beside that, we still have 124 OCaml source packages in good shape in Lucid!

Thursday, March 18 2010

Looking for a C software for Formal Verification

As you probably know, I'm a huge fan of Formal Methods: use appropriate Mathematics and tools to ensure a program is correct in all possible situations. In other words, bug free software... well, sort of. :-)

The interesting side of this is that tools to apply Formal Methods have improved a lot and most of them are now Free Software. I'm maintaining a list of Free Software tools for Formal Methods (it is a wiki, you can update it!).

I would like to make an experiment with Frama-C and its plugins, especially Jessie. Frama-C is a framework for static analysis of C programs developed at CEA. Combined with the Why and Alt-Ergo tools, you can prove some properties on real C code (absence of integer underflow or overflow, absence of out-of-bound accesses, absence of NULL pointer de-referencing, program's specific properties, etc.). All those tools are Free Software and are developed in OCaml. And they now are available in Debian and Ubuntu!

I made a simple experiment last year but I would like to make a more elaborated one.

Therefore, I'm looking for a piece of C code with following criteria:

  • Free Software: I'm interested in improving software for the whole humankind; ;-)
  • Pure C code, no C++. If there is some assembly, I could work around for example by re-writting corresponding C function;
  • Code of moderate size, a few thousands line at most. It could be a sub-module or subset of a bigger code;
  • Code using mostly integers and pointers, few strings (aka char *)[1];
  • Verifying some properties on this code would be "interesting". Several possible reasons: for security or safety reasons, because the code is used in an embedded platform on which modifications are difficult once in production or simply because this code is used a lot.

If you know some software that fills those criteria, let me know through a comment or at dmentre@linux-france.org!

Notes

[1] Frama-C is a bit slow to handle strings and it can become cumbersome.

Thursday, January 14 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/

MapOSMatic

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!

Thursday, November 19 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.).

Monday, July 27 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. ;-)

Thursday, July 23 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.

Thursday, June 25 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.

Thursday, June 18 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.

Notes

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

Monday, June 15 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é.

Thursday, June 11 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] ;-)

Notes

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

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

- page 1 of 2