Plone 3.2.2 : l’installation avec Unified Installer

Ce billet est plus un aide mémoire pour moi même qu’autre chose, il vise à expliquer ce que fait l’Unified Installer de Plone et dans un second temps, d’aborder des problématiques de migrations d’instances non basées sur buildout vers des instances « buildoutisées ». Je dois dire que j’ai eu un peu de mal à me défaire des installations depuis les sources, à la mimine, j’aimais bien ça. Avec les nouvelles versions de Plone, ce n’est même plus possible, il est proposé sous forme d' »unified installer » qui compile tout bien comme il faut sans se prendre la tête, finit les galères en mode débug à tracké la librairie oubliée. L’installation et donc vos environnement de production s’affranchissent au plus possible du système pour proposer une sorte d’environnement virtualisé pour votre travail.
Ca part d’une bonne intention et les avantages de ce système sont évidents, soit, mais des fois, quand on a des instances Plone 3.xx pas forcément migrables en 3.2, c’est un peu lourd de trouver un source de produit installable simplement, en le décompressant dans le répertoire /Products de notre Plone.

On commence par récupérer notre installer qui fait le café :

$ wget http://launchpad.net/plone/3.2/3.2.2/+download/Plone-3.2.2-UnifiedInstaller.tgz

On le décompresse

$ tar -xvzf Plone-3.2.2-UnifiedInstaller.tgz

Pour notre exemple , on va faire un installation en mode non root (pas pour un environnement de production multi instances)
Je nomme dans cette exemple mon instance z35000, c’est le port sur lequel je vais la faire écouter.

$ cd Plone-3.2.2-UnifiedInstaller
$ ./install.sh standalone --instance=z35000

Si tout s’est passé correctement vous devez avoir un truc qui ressemble à ceci :

#####################################################################
######################  Installation Complete  ######################

Plone successfully installed at /home/bluetouff/Plone
See /home/bluetouff/Plone/z35000/README.txt
for startup instructions
(...)

Use the account information below to log into the Zope Management Interface
The account has full 'Manager' privileges.

Username: admin
Password: votrepassword

Voici ce que l’on trouve dans notre répertoire d’installation Plone en plus de notre instance:

~/Plone$ ls
buildout-cache  Python-2.4  z35000  Zope-2.10.7-final-py2.4

Et surtout voic ce que nous avons dasn notre instance :
buildout.cfg  fake-eggs  products    src  versions.cfg
bin                develop-eggs  parts      README.txt  var

Et ouai, un Plone « Buildout Ready » ! On va jeter un oeil sur le fichier buildout.cfg
$ emacs buildout.cfg

C’est dans ce fichier que lon configure notre port d’écoute du Zope, dans notre exemple on fait ecouter sur le 35000, on remplace donc la ligne :

http-address = 8080

par

http-address = 35000

On sauvegarde ce petit monde, mais je vous invite à lire ce fichier attentivement, c’est ici que l’on déclare les produits que l’on souhaite installer avant que buildout ne s’occupe du reste.

Une fois sorti, on lance une petite mise à jour de notre buildout qui ira chercher lui même les extensions qu’on lui demande.
On lance donc tout simplement un :

$ bin/buildout -n

Une fois les opérations achevées, on lance notre instance :

$ cd bin/
$ ./instance start

Il est recommandé au premier lancement de lancer l’instance en debug pour voir si tout va bien :

$ ./instance fg

Votre instance est maintenant disponible depuis votre navigateur sur :

http://vous:35000 (remplacez cette valeur au besoin par l’ip de votre machine de travail et le port d’écoute que vous lui avez affecté dans le buildout.cfg, ou 8080 pour celui par défaut).

Dedibox v2 et XL : des cartes réseau bien foireuses qui perdent le réseau

C’est le premier point vraiment négatif actuellement sur les dedibox … impossible de faire un transfert de fichier un peu lourd avec un scp sans que ça plante carrément le réseau … génial quand on fait des sauvegardes, perte de réseau en plein backup donc données altérées.

cat /var/log/syslog | grep eth0

kernel: NETDEV WATCHDOG: eth0: transmit timed out
kernel: eth0: Transmit timeout, status 00000005 00000000

… et c’est comme ca tous les jours… si vous avez comme moi 9 dedibox à gérer, il y a de quoi être excédé pour moins.

Le responsable à première vue est la carte sis qui équipe les dedibox qui ne sont à la base pas vraiment réputées pour leur fiabilité. Mais en grattant un peu dans le syslog, on s’apperçois que que l’outil de monitoring de la Dedibox, le Dedibox Monitoring Agent (DMA) a peut être un rapport de cause à effet avec ces plantages exaspérants .

Quelles solutions ?

  • Compiler son propre kernel en attendant un officiel qui vienne corriger le problème
  • Faire un script qui check le reseau toutes les n minutes et qui le restart ifconfig eth0 down puis ifconfig eth0 up au cas ou on a une réponse négative du probe.
  • passer sur BSD 🙂

Voilà c’est pas super joyeux pour l’instant mais l’offre des V2 et des XL est très récente et innovante … c’est le revers de la médaille.

Xname et ZoneEdit : gérez vos DNS en mode Zen

Depuis plusieurs années, je gère mes DNS moi même avec des services gratuits ou payants de type Xname ou ZoneEdit. J’ai toujours été très satisfait de leurs services respectifs, ce malgré quelques petites galères. Je suis particulièrement attaché au service de Xname qui propose une interface en français et en anglais permettant de gérer ses zones, ses sous domaines, ses mx (mail) etc … Simple efficace et clair, c’est une recette qui a fait la gloire de Google et que Xname pratique, c’est très appréciable.

Cette nuit, comme pas mal de monde j’ai eu des petits soucis avec mes DNS, une base de données de Xname semble avoir pété, et plus aucune zone n’étaient visibles dans la console de gestion, elles sont de nouveau visibles mais beaucoup de mes domaines se retrouvent en propagation et donc inaccessibles.

L’année dernière, Xname avait également essuyé une attaque par déni de service distribué qui avait paralysé le service plus de 48h. Les indisponibilités de Xname son rares, mais voilà, elles sont toujours gênantes. On ne peut pas blâmer le service de Xname qui apporte déjà ce service gratuitement, mais bon, personnellement, j’aimerai beaucoup avoir un service de type ZoneEdit (payant), avec une infrastructure peut être un peu plus évoluée (protection contre les DDOS). Toujours est il que pour l’instant, vous pouvez contribuer à faire en sorte que Xname perdure et s’améliore en apportant une petite contribution. Cette association permet a des professionnels de faire leur business ou a des particuliers de gérer leurs domaines et ceux des copains.

Quand on sait a quel point les DNS sont le maillon le plus faible de la chaîne, on se dit que XName avec l’aide de quelques SS2L pourrait devenir un service incontournable sur le net francophone et plus encore.

Une PME doit elle opter pour un abonnement internet professionnel ou 2 connexions grand public ?

Bonding Si vous gérez le réseau d’une PME, ou si vos connaissances n’excèdent pas le strict stade de la bureautique et que vous ne vous êtes même pas posé la question, ce post peut vous intéresser. Je m’interroge régulièrement depuis plus de trois ans maintenant, qu’y a t’il de plus fiable : une connexion professionnelle chez un opérateur compétent (comme Nerim ou Orange Pro) ? Ou bien deux connexions grand public sans garantie de fonctionnement ? J’ai personnellement opté pour le second choix. Je dispose d’une connexion Free dégroupée et d’une connexion Noos 30meg. J’ai en outre la chance d’habiter à moins de 1000m de mon DSLAM, ce qui fait de ma connexion Free une connexion plus performante et plus fiable.

Voici les avantages de ce choix :

  • En choisissant une connexion câble en plus d’une connexion DSL, on diminue les risques liées à la techno elle même : si le Noeud de Raccordement Abonnés (NRA) se prend un Airbus, une connexion câble fonctionne toujours car elle ne passe pas pas les paires de cuivre du téléphone et donc pas non plus par le NRA.
  • On bénéficie de deux adresses IP externes (IPV4) et si on est chez Free on bénéficie depuis peux de l’IPV6 permettant d’assigner des IP propres sur chaque bécanes… la classe.
  • Au lieu d’avoir une ligne spécialisée onéreuse avec peu de débit on en a 2 avec des débits confortables.
  • Et dernier argument … on peut faire copuler ces deux connexions !

Euh … montre moi ton gros tuyaux

Partant du constat simple que n’importe quel geek ferait aux périodes de noel, quand la pression du travail se fait moindre et qu’il faut beaucoup geeker pour supporter Tino Rossi à la TV :

24+30 = 54mb en download et 1+1 = 2MB d’upload… pas besoin d’être une brute en math jusque là.

Oui sauf que quand je suis sur une connexion, je ne suis pas sur l’autre donc c’est soit 24 soit 30 … ah moins que … à moins qu’en s’amusant un peu avec ces paquets magiques, je ne les fasse rentrer dans la banquise (une vieille bécane sous mélénusque réhabilitée pour l’occasion).

« Un seul pour les gouverner tous » : Melenusque r0x0r <3 #!@!#!@!#!@

On rentre un peu plus dans le vif du sujet : comment agréger 2 connexions pour bénéficier d’un gros tuyaux au lieu de 2 petits et qu’en cas de défaillance d’une des deux connexions, mon réseau soit assez « intelligent » pour continuer à assurer le service avec une seule de ces deux connexions. Cette pratique (non BDSM) se nomme le bonding, c’est super bien documenté de tous les côtés. Je vais donc vous épargner un fastidieux tutoriel sur ce blog mais si ça vous intéresse je vous pose ma configuration sur un wiki ou quelque chose de plus approprié que ce blog.Cette petite bidouille a pour vocation de rendre transparent un soucis de connexion sur un réseau local et d’en améliorer les performances brutes. Je pense que de nombreuses PME devraient se pencher sur cette solution avant d’investir des sommes considérables dans une ligne spécialisée … donc voilà 2 connexions qui copulent en faisant du bonding non BDSM.Seule contrepartie en dehors des deux heures de bidouilles et de saines lectures nécessaires, si vous avez une connexion Free, il va soit falloir abandonner l’idée de l’IPV6 si la connexion de l’autre FAI ne le supporte pas ou bien il vous faudra router le trafic IPV4 et IPV6 chacun de leur cotés (ce qui n’est pas forcement ce que l’on souhaite).

Vous ne pourrez pas passer a côté de cet excellent tuto pour Debian sur Developpez.com

Visualiser et comprendre le trafic internet mondial

Je me suis amusé à chercher un moyen de visualiser graphiquement le trafic internet mondial. J’ai trouvé pas mal d’outils proposés par des éditeurs antivirus ou des compagnies de transit ip… rien d’extraordinaire en fait mais j’étais juste curieux de visualiser un peu l’état du net mondial et surtout d’avoir un outil me permettant d’interpréter des flux, d’en déduire des activités.

Akamai en propose une petite panoplie ici mais rien d’extraordinaire ni de très lisible si ce n’est un calcul des routes, des temps de latence et des packet loss restitués graphiquement ou encore celle ci présentant les attaques sur le réseau. Globalement ces cartes ne sont pas de très bonne qualité et n’offrent pas d’indicateurs très fiables, en revanche, en les corrélant, on peut en déduire certaines choses. Sur une carte au nom un peu racoleur proposée par MacAffee j’ai la semaine dernière observé un trafic très conséquent en Alaska, les pingouins feraient ils du p2p sur la banquise ? Pas vraiment, il s’agit peut être de transit entre le continent américain et le continent asiatique.

Du coup je suis allé faire un tour sur google maps, et en regardant un peu mieux, on se rend compte qu’il y a comme qui dirait des installations un peu étranges dans les zones en question, en voici une qui présente très nettement une espèce d’énorme boule… Les installations autour ne ressemblent pas non plus à des installations civiles ou alors … elles sont l’oeuvre d’une communauté monastique ne souhaitant pas être trop dérangée. Cette énorme boule me fait penser aux installation utilisées par Echelon, le désormais célèbre système d’interception de communication de l’armée américaine déployé après la seconde guerre mondiale. Ce ne sont là encore que des suppositions, mais regardez un peu autour, la zone est désertique et la grosse artère en plein milieu ça ne doit pas être les Champs Elysées du coin. Une telle piste d’aviation, dans cette région, c’est quand même un peu surprenant et on se doute bien qui ne s’agit pas d’un aéroport commercial… d’ailleurs on ne voit pas non plus d’avion mais un petit bâtiment un peu discret et un relief, des routes, qui semblent indiquer que quelques troglodytes se trouvent peut être quelque part en dessous.

Bref ce Google maps c’est vraiment amusant, on y trouve des choses qui laissent un peu rêveur. En cherchant à trouver une zone avec des installations susceptibles de faire passer de la fibre optique et de générer un gros trafic, on tombe sur des choses assez étranges et qui laissent libre cour à l’imagination … ou pas.

Configuration express d’un serveur pour Zope / Plone sous Debian Etch

Voici en quelques mots les étapes d’installation et de configuration d’un serveur pour Zope / Plone :

– Installation de la distribution : Debian Etch, on choisira l’install via l’interface de dedibox. C’est ultra rapide, une fois terminée, l’installation reboot la dedibox, vous pouvez donc vous y connecter via ssh.
– Pour configurer la date et l’heure on utilise la commande Date : $ sudo date 090616302007 : ce qui définit la date suivante : 6 sept a 16H30 en 2007
– On installe le nécessaire : apt-get install emacs21 subversion irssi sudo vim …
– Zope et python via dpkg : apt-get install python2.4 zope2.9
– Attention installer PIL : apt-get install python-imaging
– Plone depuis les sources du site wget.
– Edition du etc/zope.conf pour mettre un port autre que 9673.
– L’instance se lance
– On ajoute ses products utiles à coup de wget dans le répertoire Products du Zope (en oubliant pas de les décompreser). Attention à PloneFormGen a besoin de TALESField (sinon on plante l’instance) que l’on peut trouver ici http://plone.org/products/scriptablefields/?searchterm=TALESField
– installation de Apache2 via dpkg : Au passage, Apache nous rappelle les petites commandes utiles.
– Installer les Modules Apache dont nous avons besoin avec a2enmod :
yakuza:/home/bluetouff# a2enmod proxyModule proxy installed; run /etc/init.d/apache2 force-reload to enable.yakuza:/home/bluetouff# a2enmod rewriteModule rewrite installed; run /etc/init.d/apache2 force-reload to enable.yakuza:/home/bluetouff#
– On pense à faire pointer le DNS sur la nouvelle machine
– Configuration des vhost apache et restart du serveur HTTP
… et voilà, on patiente tranquillement que le domaine pointe bien

2 serveurs dédiés en 20 minutes !

Ben oui, 20 minutes c’est le temps qui s’est écoulé entre la confirmation de ma commande de 2 dedibox.
du coup :


Linux yakuza 2.6.21.1dedibox-r7 #1 Mon Apr 30 17:25:38 CEST 2007 i686
Serveur : yakuza
IP : 88.191.xx.xx
Add MAC : 00:40:63:e8:xx:xx
OS : Debian GNU/Linux 4.0 installe le 2007-09-06 15:00:36

et


Linux vodka 2.6.21.1dedibox-r7 #1 Mon Apr 30 17:25:38 CEST 2007 i686
Serveur : vodka
IP : 88.191.xx.xx
Add MAC : 00:40:63:ea:xx:xx
OS : Debian GNU/Linux 4.0 installe le 2007-09-06 15:07:02

Et paff 2 nouvelles dedibox pour Toonux

Je viens de commander 2 nouvelles dedibox en plus de nos 2 précédentes et des 2 autres serveurs dont nous disposons. L’une de ces dedibox sera une machine dédiés pour l’un de nos clients, l’autre proposera des instances dédiées sur une machine mutualisée. Elles sont toutes deux équipées de l’option RAID. Ces machines serviront a installer Zope et Plone, plus éventuellement une ou deux applications PHP pour la machine mutualisée. Se pose en fait la question du choix de l’OS, j’ai actuellement du Debian et de l’OpenBSD pour les deux autres box. Pour ces deux nouvelles, j’hésite franchement entre Debian ces deux OS, les deux ont leur qualités et leur défaut.Le support du RAID fonctionne correctement sur OpenBSD depuis un moment, je présume qu’il en est de même sous Debian. Maintenant … sur une Dedibox, il faut prier pour ne pas avoir de surprise avec le matériel… en tout cas c’est commandé, wait and see, en espérant ne pas à avoir à attendre 6 semaines comme la dernière fois (c’est une affaire qui marche les dedibox).

Une faille de sécurité béante dans le process d’attribution de serveurs équipés de la solution Plesk

Un jeune homme de 19 ans, Théo Négri, révèle une faille de sécurité lui permettant de prendre le contrôle d’un serveur via l’infâme cliquodrome qu’est Plesk. Utilisé par de nombreux hébergeurs à travers le monde, Plesk s’est imposé comme une solution graphique d’administration de serveur simple et efficace. Il explique sa méthode sur son Blog et c’est tellement enfantin qu’il est étonnant que personne n’y ai pensé avant. Attention toutefois il est important de noter que la faille ne vient pas de Plesk directement mais plutôt du processus d’attribution des serveurs par les hébergeurs en question. Rappelons enfin qu’en France, OVH et Dedibox proposent de déployer cette solution.