Bonjour,

J'ai tendance à utiliser régulièrement la recherche du site. Je trouve qu'il regorge d'informations intéressantes, aussi bien sur les nouveautés, les astuces sur l'utilisation de programmes, la programmation et le choix de logiciel (il y a toujours dans les commentaires les programmes équivalent à celui présenté).
Par contre il faut avouer que la recherche est très peu pratique: les résultats sont là mais il n'est pas possible de filtrer facilement, de voir la chaîne recherchée, connaître le nombre de résultat …

Il y a d'ailleurs deux entrées dans le suivi à ce sujet qui datent un peu et n'ont pas l'air d’intéresser grand monde. :

• Laisser la recherche visible et modifiable dans les pages de résultat
• Pouvoir annuler les filtres choisis

Je décide donc, ayant un peu de temps, de voir si je peux faire un ou deux petits patch pour corriger tout ça.
Je précise que je n'ai pas d’expérience dans l'utilisation de ROR mis à part l’installation de Redmine/ChiliProject et une petite correction de code dans Redmine (un pb dans le mailer pour les notifications).

Les commentaires que j'ai pu lire sur l'installation du site avaient tendance à dire que c'était plutôt compliqué.
Je cherche donc un peu partout sur le site, en particulier dans le wiki et le résultat est plutôt maigre (Organisation Code LinuxFr). Aucunes informations à première vu sur l'installation d'un environnement de développement.
Après un bon moment ou je galère à trouver des infos, j'ai l'idée (un peu tardive il faut avouer) de télécharger les sources du site, et là je trouve mon bonheur, un fichier readme bien complet !
Il serait intéressant de copier ce readme dans le wiki ou au moins de le mettre en lien.

Vu le nombre de truc à installer, je décide de faire ça dans une vm. Et puis on sait jamais cela pourrait peut être servir à d'autre.

Je crée donc une machine virtuelle sous VirtualBox et y installe une debian whezy standard (c'est l'iso que j'avais sous la main).
Ensuite on suit tout simplement le manuel.

1) First install some Debian packages:

    # aptitude install mysql-server mysql-client libmysql++-dev
    # aptitude install build-essential openssl libreadline6 libreadline6-dev
    # aptitude install curl git-core zlib1g zlib1g-dev libssl-dev libyaml-dev
    # aptitude install libsqlite3-0 libsqlite3-dev sqlite3 libxml2-dev bison
    # aptitude install libxslt-dev autoconf libc6-dev ncurses-dev automake libtool
    # aptitude install imagemagick hunspell hunspell-fr subversion
    # aptitude install openjdk-6-jdk

Pas de problèmes de ce coté la, tout se passe correctement. Il manque par contre une dépendance (tcl8.5) qui sera nécessaire plus tard.
 

2) Configure the database:

    # mysql -p -u root
    <enter your root password for mysql>
    > CREATE DATABASE linuxfr_rails;
    > GRANT ALL PRIVILEGES ON linuxfr_rails.* TO "linuxfr_rails"@"localhost";
    > QUIT;
    (return to user)

    Statistics need time zone at SQL level. You'll need to population time_zone* tables.
    # mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -p -u root mysql

Pas de problèmes là non plus.
 

3) Install and start redis:

    $ wget "http://redis.googlecode.com/files/redis-2.4.2.tar.gz"œ
    $ tar xzf redis-2.4.2.tar.gz
    $ cd redis-2.4.2
    $ make
    (optional, takes about ten minutes, $ make test )
    $ src/redis-server redis.conf

Les problèmes commencent :

• il manque tclsh, il faut installer le paquet tcl8.5

• J'ai un gros message où il m'indique de rajouter "vm.overcommit_memory = 1" au fichier /etc/sysctl.conf :
  WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
  Je m’exécute , plus de message d'erreur. Par contre je ne sais pas du tout à quoi cela correspond.

• Lors du lancement du serveur redis, on ne récupère pas la main et ça crache des lignes de log à tour de bras. Je regarde donc pour le mettre en service et enregistrer tout ça dans des log.
  En cherchant un peu je trouve cette page et crée un fichier d'init

#!/bin/sh

### BEGIN INIT INFO
# Provides:          redis
# Required-Start:    $all
# Required-Stop:     $all
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts redis database system
# Description:       starts redis using basic start scripts
### END INIT INFO

PATH=/opt/redis-2.4.2/src:/sbin:/bin:/usr/sbin:/usr/bin
NAME=redis
PIDFILE=/var/run/$NAME.pid

test -x $DAEMON || exit 0

set -e

case "$1" in
  start)
        echo -n "Starting $DESC: "

        start-stop-daemon --start --pidfile $PIDFILE \
            --startas /opt/redis-2.4.2/src/redis-server -- /opt/redis-2.4.2/redis.conf

        echo "$NAME."
        ;;
  stop)
        echo -n "Stopping $DESC: "

        start-stop-daemon --stop --exec /opt/redis-2.4.2/src/redis-server -- /opt/redis-2.4.2/redis.conf

        echo "$NAME."
        ;;
      *)    
            N=/etc/init.d/$NAME
            echo "Usage: $N {start|stop}" >&2
            exit 1
            ;;
    esac

    exit 0

J'apporte également quelques modifications au fichier de configuration de redis :

daemonize yes
bind 127.0.0.1
loglevel notice
logfile /var/log/redis.log

Le lien ci-dessus spécifie un utilisateur pour rédis, cela ne fonctionne pas chez moi, le serveur se lance bien mais ensuite il a un problème de droit lorsqu'il a besoin de sauvegarder. Je le laisse donc en root, installé dans /opt (je me dis que sur une vm, on s'en fout un peu … j'ai peut être tort! )
 

4) Install RVM (more details on https://rvm.beginrescueend.com/rvm/install/ ):

    $ bash < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)

   And follow the instructions.

Pas de soucis pour cette étape.
 

5) Install Ruby with RVM:

    $ rvm install 1.9.3
    $ rvm use --default 1.9.3

Pas de soucis non plus
 

6) Clone the repository, configure and install gems:

    $ git clone git://github.com/nono/linuxfr.org.git
    $ cd linuxfr.org
    $ cp config/database.yml{.sample,}
    $ cp config/secret.yml{.sample,}
    $ gem install bundler rake
    $ bundle install

Pas de soucis. il faut aller modifier le fichier database.yml pour mettre le bon utilisateur et mot de passe mysql.
 

7) Launch elasticsearch:

    $ desi install
    $ desi start

Pas de soucis, par contre cela ne rend pas la main. J'ai essayé de le mettre en service à l'aide de ce tutorial, cela lance bien elasticsearch mais ne fonctionne pas par la suite avec le site.
Completed 500 Internal Server Error in 39ms
Tire::Search::SearchRequestFailed (404 : {"error":"IndexMissingException[[diaries] missing]","status":404}):

Il manque à mon avis des variables d'environnement probablement liées au fichier de config elasticsearch.yml mais je n'ai pas trouvé de solution.
 

8) Finish to configure:

    $ rake db:setup
    (if you're updating, you'll need an other step: redis-cli flushdb)

La version de libhunspell n'est pas la bonne, il me demande la 1.2 et j'ai la 1.3 : je tente de faire un lien symbolique tout simplement : ln -s /usr/lib/x86_64-linux-gnu/libhunspell-1.3.so.0 /usr/lib/x86_64-linux-gnu/libhunspell-1.2.so.0
Cela fonctionne !
 

9) Let's run it:

    $ bundle exec rails server thin
    $ x-www-browser http://127.0.0.1:3000/

Cela fonctionne !! J'ai un beau site LinuxFr qui s'affiche, par contre il n'y a rien, le site est vide.
 

10) Create an admin account:

    * Create an account
    * Get confirmation link in the console and confirm the account
    * Get password in the console
    * Give admin role to this account with
      `mysql linuxfr_rails`
      `mysql> UPDATE accounts SET role='admin' WHERE login='xxxxxx';`
    * Reload the page on the site, you should be admin.

Le lien de confirmation affiché dans les logs ne fonctionne pas (pb d'encodage de l'url je pense), je le récupère directement dans la base de données (table accounts).
Je ne vois pas de mot de passe dans les logs, je vais sur "mot de passe oublié", récupère le lien dans les logs, puis le code dans la base (même problème que précédemment avec le lien) et je peux changer mon mot de passe.
Je passe mon compte en admin directement dans la base.
 
 

Voila c'est finit ! Le site fonctionne correctement et j'ai un utilisateur administrateur valide !
Il faut avouer que tout ça est un peu long et cela doit vraiment décourager les gens qui souhaitent contribuer.

J'aimerai partager cette VM, histoire de permettre à tout le monde de contribuer facilement.
Il me reste donc à faire (avec votre aide) :
- mettre elasticsearch en tant que service (desi start)
- mettre le lancement du site en service (bundle exec rails server thin) avec les logs au bon endroit
- générer un jeux de données de démonstration
- plein d'autres choses que j'ai pas du bien faire ou qu'il manque et que vous ne manquerez pas de m'indiquer
 
 

ps: le site fonctionne correctement, par contre j'ai une erreur (No route matches [POST] "/b/3d072a245074a27d64426f9fd81f6600de204893") qui revient tout le temps dans les logs, je ne vois vraiment pas d'où ça vient :

Started GET "/journaux" for 192.168.1.57 at 2012-11-07 06:42:09 +0100
Processing by DiariesController#index as HTML
  Account Load (0.9ms)  SELECT `accounts`.* FROM `accounts` WHERE `accounts`.`id` = 2 LIMIT 1
  Rendered shared/_order_navbar.html.haml (3.8ms)
   (1.6ms)  SELECT COUNT(*) FROM `nodes` WHERE `nodes`.`public` = 1 AND `nodes`.`content_type` = 'Diary'
  Node Load (1.0ms)  SELECT `nodes`.* FROM `nodes` WHERE `nodes`.`public` = 1 AND `nodes`.`content_type` = 'Diary' ORDER BY created_at DESC LIMIT 15 OFFSET 0
  Rendered collection (0.0ms)
  Rendered diaries/index.html.haml within layouts/application (33.0ms)
  Rendered layouts/_head.html.haml (7.3ms)
  Rendered layouts/_site.html.haml (2.9ms)
  User Load (0.3ms)  SELECT `users`.* FROM `users` WHERE `users`.`id` = 2 LIMIT 1
  News Load (0.3ms)  SELECT `news`.* FROM `news` WHERE `news`.`state` = 'draft' ORDER BY created_at DESC
  Rendered redaction/_box.html.haml (3.1ms)
   (0.4ms)  SELECT COUNT(*) FROM `news` WHERE `news`.`state` = 'candidate'
   (0.2ms)  SELECT COUNT(*) FROM `polls` WHERE `polls`.`state` = 'draft'
  Rendered boards/_form.html.haml (3.5ms)
  Rendered boards/_board.html.haml (0.0ms)
  Rendered boards/_boards.html.haml (8.7ms)
  Rendered moderation/_box.html.haml (16.2ms)
  Rendered admin/_box.html.haml (1.5ms)
  Rendered layouts/_sidebar.html.haml (36.1ms)
  Comment Load (0.3ms)  SELECT id, node_id, title FROM `comments` WHERE `comments`.`state` = 'published' ORDER BY created_at DESC LIMIT 12
  Tag Load (0.7ms)  SELECT name FROM `tags` INNER JOIN `taggings` ON `taggings`.`tag_id` = `tags`.`id` WHERE `tags`.`public` = 1 AND (created_at > '2012-10-07 04:42:09') GROUP BY tag_id ORDER BY COUNT(*) DESC LIMIT 12
  FriendSite Load (0.4ms)  SELECT url, title FROM `friend_sites` ORDER BY position ASC
  Rendered layouts/_footer.html.haml (10.8ms)
Completed 200 OK in 114ms (Views: 101.3ms | ActiveRecord: 6.1ms)


Started POST "/b/3d072a245074a27d64426f9fd81f6600de204893" for 192.168.1.57 at 2012-11-07 06:42:30 +0100

ActionController::RoutingError (No route matches [POST] "/b/3d072a245074a27d64426f9fd81f6600de204893"):
  actionpack (3.2.8) lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call'
  actionpack (3.2.8) lib/action_dispatch/middleware/show_exceptions.rb:56:in `call'
  railties (3.2.8) lib/rails/rack/logger.rb:26:in `call_app'
  railties (3.2.8) lib/rails/rack/logger.rb:16:in `call'
  quiet_assets (1.0.1) lib/quiet_assets.rb:20:in `call_with_quiet_assets'
  actionpack (3.2.8) lib/action_dispatch/middleware/request_id.rb:22:in `call'
  rack (1.4.1) lib/rack/methodoverride.rb:21:in `call'
  rack (1.4.1) lib/rack/runtime.rb:17:in `call'
  activesupport (3.2.8) lib/active_support/cache/strategy/local_cache.rb:72:in `call'
  rack (1.4.1) lib/rack/lock.rb:15:in `call'
  actionpack (3.2.8) lib/action_dispatch/middleware/static.rb:62:in `call'
  railties (3.2.8) lib/rails/engine.rb:479:in `call'
  railties (3.2.8) lib/rails/application.rb:223:in `call'
  rack (1.4.1) lib/rack/content_length.rb:14:in `call'
  railties (3.2.8) lib/rails/rack/log_tailer.rb:17:in `call'
  thin (1.5.0) lib/thin/connection.rb:81:in `block in pre_process'
  thin (1.5.0) lib/thin/connection.rb:79:in `catch'
  thin (1.5.0) lib/thin/connection.rb:79:in `pre_process'
  thin (1.5.0) lib/thin/connection.rb:54:in `process'
  thin (1.5.0) lib/thin/connection.rb:39:in `receive_data'
  eventmachine (1.0.0) lib/eventmachine.rb:187:in `run_machine'
  eventmachine (1.0.0) lib/eventmachine.rb:187:in `run'
  thin (1.5.0) lib/thin/backends/base.rb:63:in `start'
  thin (1.5.0) lib/thin/server.rb:159:in `start'
  rack (1.4.1) lib/rack/handler/thin.rb:13:in `run'
  rack (1.4.1) lib/rack/server.rb:265:in `start'
  railties (3.2.8) lib/rails/commands/server.rb:70:in `start'
  railties (3.2.8) lib/rails/commands.rb:55:in `block in <top (required)>'
  railties (3.2.8) lib/rails/commands.rb:50:in `tap'
  railties (3.2.8) lib/rails/commands.rb:50:in `<top (required)>'
  script/rails:6:in `require'
  script/rails:6:in `<main>'


  Rendered /usr/local/rvm/gems/ruby-1.9.3-p286/gems/actionpack-3.2.8/lib/action_dispatch/middleware/templates/rescues/routing_error.erb within rescues/layout (2.1ms)

Sommaire

• Le sophisme systemd

plop,

Pour commencer à préparer la progression vers vendredi en douceur, j'ai traduit ce post de Leszek Urbanski sur systemd, qui dissertait en mai 2011 en les problèmes qu'il peut poser sur serveurs. Posté en ces lieux avec l'aimable autorisation de l'auteur (de l'article, par la suite le mot auteur, au sein de la traduction, désignera l'auteur de systemd).

C'est parti :

Le sophisme systemd

(…) So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It’s quite relieving!
– Lennart Poettering @ fosdem.org

systemd est erroné sur tellement de points que je ne sais pas par où commencer. Son erreur de conception la plus importante est peut-être qu’il a été conçu avec un mépris flagrant pour les serveurs. Le manifeste de l’auteur ainsi que la série « systemd pour les admins » fournissent un bon aperçu de ses motivations pour la conception de systemd.

Il s’étend encore et encore sur la façon dont vous pouvez gagner quelques secondes ici et là par le démarrage des services en parallèle et en différé - systemd a d’ailleurs une fonction permettant de mesurer le temps de démarrage du système. La question est : qui s'en soucie ? Les utilisateurs de bureau, oui. Les utilisateurs d’embarqué, peut-être. Les utilisateurs de serveurs ? Non. Il importe peu qu’un serveur démarre en 96,3 secondes au lieu de 33,1. Ce qui compte c’est qu’il reste en fonctionnement et qu’il ne soit pas trop lourd à maintenir.

Alors, comment sont atteints les objectifs de systemd ? Simplement, en jetant les paradigmes bien éprouvés d’Unix par la fenêtre et en le revendiquant clairement. Oui, Unix a été conçu il y a 42 ans. Et non, il n’est pas cassé. Je ne suis pas un traditionaliste pur et dur et je ne suis même pas réticent à adopter de nouvelles solutions, mais Unix reste la conception d’OS pour serveur ayant le plus de succès au monde pour une raison – et est encore utilisé aujourd'hui sous des formes diverses, après ces 42 ans. C'est simple, élégant et ça marche. Le pilier de sa conception, c'est la simplicité et la modularité. Un programme pour une tâche ; une interconnexion facile entre les programmes. Et pourtant il faudrait que nous jetions tout cela pour quelque chose de neuf et qui brille.

Un des objectifs de conception de systemd est de se débarrasser de scripts shell dans le processus de démarrage et … de tout réécrire en C, vu que l'auteur ne semble pas être très friand que grep soit appelé 77 fois et awk 92 lors de son initialisation du système. Mais pourquoi avons-nous des scripts shell dans le processus de démarrage ? Ils sont simples. Ils sont faciles à lire. Tout admin Un*x un tant soit peu compétent connait au moins les bases du scripting shell. Cela permet un contrôle pratiquement total du processus de démarrage complet et n’importe quoi peut être changé en quelques secondes. Bien sûr, on peut affirmer que c'est presque aussi facile de changer le code C de systemd, recompiler et réinstaller. Je vais vous confier un petit secret : quand avez-vous typiquement besoin de changer quelque chose dans le processus de démarrage ? Quand quelque chose fonctionne mal. Peu importe que vous soyez confortablement installé à votre bureau devant 3 écrans 30" ou dans les tranchées au data center après une nuit horrible – vous devez corriger le problème au plus vite. La dernière chose que vous voulez et d’avoir à instrumenter, débugger, et reconstruire du code C au cœur de votre OS.

Le second objectif de conception semble être une complexité intentionnelle incroyable et injustifiée. Le processus le plus important dans l’espace utilisateur est censé être propre, petit et efficace. Jetons un coup d'œil à ce que systemd est censé superviser :

• le redémarrage des processus après leur crash. sysvinit ne le fait pas et nous n'avons pas restartd ou mille autres programmes pour cela !

• la collecte d'informations sur les plantages des démons. Aujourd'hui la plupart des démons possèdent leurs propres formats de rapport de crash, syslog, stderr, directement dans les fichiers journaux au format texte, des dumps binaires, etc. Bonne chance pour imposer aux auteurs de se conformer à une norme unique. Et bonne chance pour tous les cas aux limites.

• garder le contrôle (par l'intermédiaire cgroups) sur les processus détachés de leurs parents. Mais pour cela nous avons déjà, … cgroups ?

• démarrage du service à la demande / retardé (NDT : l’inspiration c’est services.msc ?). « Sur la plupart des machines où sshd peut être à l’écoute quelqu’un s’y connecte genre tous les deux mois » déclare l’auteur. Sur un poste de travail – peut-être. Combien de RAM allez-vous économiser en retardant le démarrage de quelques démons ? S’ils sont inutilisés, ils vont être swappés de toute façon. Afin de pourvoir à la demande de démarrage des services réseau, encore une autre fonctionnalité déjà disponible ailleurs a dû être mise en œuvre dans systemd : inetd.

• la gestion des dépendances entre services. Pour l'auteur, il y a de la redondance dans la gestion des dépendances entre services. Le problème est que tout processus de démarrage est basé sur des dépendances. Pensez aux services et non aux processus. Vos services dépendent de ce que leurs systèmes de fichiers aient été montés, les systèmes de fichiers dépendent de l’initialisation des périphériques sous-jacents, et ainsi de suite. Nous avions déjà une gestion rudimentaire des dépendances entre services dans System V ! S31fancyd et S31foobar dépendait de S30whatsit. Lors de l’arrêt, seulement lorsque K10foobar et K10fancyd étaient arrêtés le système pouvait procéder à K20whatsit. Contrairement aux ordinateurs de bureau, le temps de démarrage des serveurs se mesure entre le moment ou vous appuyez sur le gros bouton rouge et le moment où le serveur fournit réellement tous ses services. En d’autres termes, lorsque vous attendez, qui se soucie si c’est en parallèle ou en série ? Il importe peu si par exemple ftpd est autorisé à démarrer avant que /home/ftp ne soit monté et que des fichiers puissent être servis. En outre, un administrateur peut choisir de stopper S30whatsit sans stopper S31 fancyd – et il ou elle sait probablement ce qu’ils fabriquent. Il est plus difficile de forcer des actions sur les services avec systemd : on finit toujours par se battre contre ses décisions.

• systemd crée des points de montage autofs et démarre des démons avant que leurs systèmes de fichiers ne soient disponibles (évidemment, les opérations de fs vont de bloquer jusque-là). Cela semble horrible, non ? Cela va être un cauchemar d’administration. Il n'y a pas moyen de faire de l’autofs correctement. Si quelque chose va mal avec l’ES sous-jacent ou autofs proprement dit, vous vous retrouvez avec un système inutilisable. Même sous Solaris, qui a sans doute la mise en œuvre la plus robuste d’une implémentation d’automounter. Intégrer autofs dans le PID 1 et le processus de démarrage (et mettre les services en attente là-dessus) garantit des problèmes.

• l'écoute de modifications sur le matériel introduit des problèmes potentiels de stabilité et de sécurité – et il y a déjà des choses qui fonctionnent (plus ou moins) avec les événements matériels.

• la communication via D-Bus. D-Bus est très orienté bureautique. Il ne s'appelle pas « bus de bureau » (NDT : Desktop Bus) pour rien. Il est conçu pour la portabilité - et non la vitesse, la fiabilité ou la simplicité. Il existe des dizaines de protocole d’IPC et de passage de messages simples et robustes, mais D-Bus est de loin l’un des plus compliqués, peut-être uniquement après CORBA/IIOP. Au lieu de laisser cette abomination mourir, ou du moins la laisser confinée au bureau, D-Bus va être intégré au processus de démarrage. Les développeurs de démons sont incités à l’utiliser. Mettons le dans le noyau tant qu’on y est.

systemd est trop compliqué et farci de fonctionnalités inutiles, presque comme si quelqu'un essayait de mettre en œuvre un second noyau en espace utilisateur. On dirait qu'il a été conçu par quelqu'un qui n'a jamais vu autre chose que son propre poste de travail. C'est un exercice gentil dans les systèmes d’autogestion, avec son approche fourre-tout ça mérite sans doute d’y jeter un œil pour les fournisseurs de bureautique/embarqué en tant qu’alternative à SystemV ou à un système d’initialisation fait maison, mais c’est tout.

Le processus de démarrage de l’espace utilisateur de Linux devrait être passé en revue et nettoyé dans la plupart des distributions importantes, et peut-être même être normalisé (ou non – nous avons actuellement quatre système de démarrage majeurs pour l’espace utilisateur, tous dans des distributions majeures – un peu de diversité est en réalité bienvenue).

Toutefois, systemd n'est pas la voie à suivre. Il nous ferait reculer d’une décennie. Espérons que cela n'accroche pas - tout comme upstart ou la première mise en œuvre de devfs en 2000. Il n'est guère surprenant de voir combien les gens sont près à suivre aveuglement - systemd offre beaucoup de belles promesses. Avec le soutien financier de Red Hat et toute la propagande (je n'ose même pas appeler cela de la Relation Publique), cela va être un combat ardu, mais rappelez-vous: après tout, upstart a intégré Ubuntu; devfs est même entré dans le noyau. Tout espoir n'est pas perdu.

--> Post original en anglais