Par défaut c’est une distribution Suse d’installée, je n’ai rien contre cette distribution mais la première idée est de la remplacer par une Mandriva que je lui préfére, à noter au passage qu’on peut enfin acheter des machines avec des linux pré-installés et ce type d’engin est un terrain porteur pour Linux à mon sens.

Donc dés la réception de la bête, direction Google comment installer une distribution Linux sans CD-Rom ? La méthode qui me convient le mieux est celle basée sur l’utilisation d’une clef USB pour booter dessus, tombe bien j’en ai une qui traine dans un coin, donc formatage de celle-ci et copie d’une image de boot réseau Mandriva 2008.1 grâce à ce petit logiciel nommé UNetbootin.

Mais là grosse déception après plusieurs tentatives de boot, l’installeur Mandriva plante sur des erreurs Kernel, n’ayant pas le temps d’investiguer plus que ça je tombe sur le Wiki de msiwind.net.

Donc mon choix est vite fait, je teste avec une Kubuntu 8.04 (KDE power …) selon les explications basée sur une installation d’Ubuntu 8.04, là rien à dire tout s’installe au premier boot comme il se doit … On dirait que certain on pris un léger retard, lol … attendons le cru 2009 de la Mandriva, dommage …

Je reboot et me voilà devant un bureau KDE, tout est fonctionnel au niveau hardware, webcam, wifi (nécessite de compiler le driver quand même), carte son, etc … A moi les joies de l’Internet Mobile (navigation sous Firefox, conférences via Skype en mode vidéo, sessions SSH) avec un affichage en 1024X600 de n’importe où sur la planête grâce au Wifi et la 3G (nécessite une clef 3G ou un téléphone portable 3G).

Disposant donc d’un processeur Intel® Atom™ N270 (1.6GHz), de 1 G de mémoire, et d’une puce graphique intel 845G, je tente l’installation de compiz (bureau 3D) pour bénéficier de l’ergonomie des bureaux 3D et de ses effets, histoire de faire mousser un peu la polémique avec mes amis Mac users et leurs OSX lol … Après une optimisation des réglages de la carte graphique et surtout ce petit tweak, compiz est fluide, cool je garde.

J’en profite pour installer cairo-dock me permettant ainsi d’optimiser la place sur mon bureau en cachant la barre de taches KDE. Ensuite un petit coup de Look&Feel en passant sur kde-look.org pour adapter un univers (thème KDM, fond d’écran, thème KDE) qui me convienne, installation de Wicd pour découvrir les réseaux Wifi à portée et me connecter facilement, voilà les principales modifications apportées à l’installation de base d’une Kubuntu.

Les seuls désagrément que je rencontre pour le moment, c’est la sortie des mises en veille où la carte wifi ainsi que la carte son ne fonctionne plus et qu’il me faut les réinitialiser en mode console, ainsi qu’une autonomie de batterie (3 cellules) trop courte (entre 1H45 et 1H30 selon l’utilisation) mais des batteries 6 et 9 cellules sont en train d’arriver sur le marché.

Me voilà donc avec un netbook de 1,2 kg peu encombrant qui n’as rien à envier en terme de puissance et de fonctionnalité à mon ancien portable Dell de 3kg très encombrant, c’est mon dos qui me remercie ainsi qu’un joujou pour passer des heures à bidouiller sous Linux et essayer le nouveau KDE 4.1 au plus tôt …

Mon débugueur AS3 me sort la classique erreur des Sockets “Error #2048: Security sandbox violation“, malgré la présence sur le serveur qui me fournit les infos, d’un fichier de régulation, le fameux crossdomain.xml, qui jusqu’aux versions précédentes du player Flash ne me posait aucun problème, à moins que j’ai “zappé” une étape, qu’elle est donc cette nouvelle “fantaisie” de la part d’Adobe ?..

Après consultation de la raison de cette mise à jour, on apprends que c’est pour des raisons de sécurités, bon OK si c’est pour la sécurité … mais je fais quoi avec mes Sockets qui ne fonctionne plus ? (la prochaine fois je prendrais plus de temps pour lire les flux RSS d’Adobe, lol … )

On apprends donc que les fichiers crossdomain.xml ne suffisent plus pour autoriser les Sockets Flash à communiquer avec d’autres serveurs, les fameuses “Socket Policy file” ne sont plus accessible via des serveurs HTTP mais via des serveurs TCP (la nuance est subtil …), il nous faut donc implémenter un nouveau service TCP fournissant sur le port 843, un serveur de type “socket policy file server”.

Ce type de service n’est pas des plus compliqué à développer dans des languages de type Java, Python, Perl ou PHP, le plus compliqué à mon sens c’est leur mise en place sur les gros serveurs à cause des audits de sécurité et validation des services d”hébergement, ceux qui ont la chance d’administrer leur propres serveurs ne devrait pas avoir de mal à déployer ce type de service.

J’ai donc rapidement implémenter ce service sur un serveur de développement grâce aux exemples de l’article pré-cité et j’ai eu le plaisir de retrouver mes Sockets fonctionnels …

A savoir plusieurs choses, par défault le player Flash va chercher la “Socket Policy file” sur le port appellé et le port 843, par exemple si votre Socket se connecte sur le port 8080, le player va chercher par défaut sur le 8080 puis sur le 843, si au bout des 3 secondes de delay le player n’as pas la réponse souhaitée, il déclenche un événement de type “SecurityErrorEvent” qui provoque l’erreur :

#Error #2048: Security sandbox violation

On à toujours la possibilité de définir un port manuellement dans le code source pour définir un port spécifique ou pour des serveurs ayant un temps de réponse assez long, en utilisant l’instruction suivante avant l’appel du Socket :

loadPolicyFile("xmlsocket://monsiteamoi.com:8081");
mySocket = new Socket();

Voilà si mon retour d’expérience peut servir à d’autres c’est avec plaisir …

J’ai découvert Typo3 en 2004, à une époque ou je cherchais un outil me permettant de capitaliser mes développements et gérer un backoffice unique pour les sites de mes clients. Ne trouvant pas la réponse adéquate à mes besoins fonctionnels, c’est à cette période que j’ai initié le projet TeamZone.

Début 2007 j’ai recroisé Typo3 dans un projet ne nécessitant pas de développement particulier, étant concentré sur le développement de TeamZone, je n’ai pas prêter attention à son évolution.

Mai 2008, nouveau projet sous Typo3, cette fois ci du développement spécifique en extensions fut requis, j’ai donc fait connaissance avec l’API de Typo3 en version 4.2 et son fameux Typo Script.

Rien à redire j’ai put rapidement déployer mon projet, grâce aux nombreuses extensions et les bons conseils de la communauté Fr, particulièrement le forum typo3.fr ainsi que les conseils avisés de Cédric alias supertempete.

Typo3 est donc bel et bien un des leaders incontesté en termes de CMS Open Source, cela fait plaisir de voir un projet de logiciel libre qui à réussi à fédérer une réel communauté autour de lui et qui prouve la montée en puissance de l’Open Source dans les SSII et autres.

Après un début d’année sur eZ Publish, je peux constater pour l’instant que ces “gros” CMS restent “lourd” dans leurs déploiements et nécessitent pas mal de ressources pour leur bon fonctionnement, mais offre un environnement “avancé” pour le développement Web.

Dans notre métier de développeur Web, malgré tout nous n’avons pas que des sites aux fonctionnalités avancées à mettre en place, je me voit mal déployer un eZ Publish ou un Typo3 pour une site événementiel par exemple, qui nécessite peu de pages, peu de développement mais un besoin rapide d’intégrer une charte graphique et de déployer du contenu (articles, vidéos, etc).

C’est pour cela entre autres que des CMS léger tel que TeamZone existe aujourd’hui et que l’offre des CMS Open Source s’étoffe de jour en jour, il suffit de jetter un oeil sur cmsmatrix.org pour s’en rendre compte.

J’ai été confronté récemment a devoir faire des requêtes sur couche HTTPS … Le seul problème c’est que Flash aujourd’hui, n’as pas de fonction native pour travailler en HTTPS et pour des besoins fonctionnels spécifiques j’ai utilisé les sockets.

La seul librairie que nous avons trouvé pour répondre aux besoins, est celle-ci : as3httpclientlib, un client HTTP/HTTPS pour ActionScript 3, après une bonne phase de R&D sur le principe des échanges clients <-> serveurs (merci les RFC …), j’ai put mettre en place mes besoins à l’aide de cette librairie, donc si l’info peut servir à d’autre, c’est avec plaisir que je la transmet.

Nouveau défi à venir, faire passer mon socket HTTPS via un proxy et en plus avec gestion d’une authentification sur proxy en option …

Si quelqu’un à de l’expérience sur ce genre de chose, tous conseils et échange sera la bienvenue …

1. Installez les packages nécessaires.

Comme à notre habitude, on lance une console, on passe en root, on update nos sources et on télécharge les packages suivants :

apt-get update
apt-get install enscript python-docutils python-pkg-resources \
python-pysqlite2 python-setuptools libapache2-mod-python

2. Installez le logiciel Trac.

A la date de cette article, c’est la version 0.10.4.2 qui est proposée dans les dépôts Debian, la version sur le site de Trac est une 0.11rc1, cette version apportant pas mal de changements (voir les Release Notes) il me semble évident d’installer cette version.

Nous allons donc installer Trac via le “easy_install” de Python :

easy_install Trac==0.11rc1

3. Créer un répertoire pour le virtual host dédié à Trac.

Nous créons le répertoire dédié à l’hébergement de nos instances Trac et on règle les droits sur celui-ci de la manière suivante :

mkdir /home/trac
chmod 2770 /home/trac

4. Mettre en place les instances Trac.

Comme nous voulons une gestion multi-projets, il nous faut créer plusieurs instances pour l’exemple et affecter l’utilisateur et groupe Apache sur ceux-ci :

trac-admin /home/trac/projet_1 initenv
trac-admin /home/trac/projet_2 initenv
chown -R www-data:www-data /home/trac

trac-admin va vous demander une série de questions pour configurer son instance, parmi celles-ci on configure le nom du projet, par défaut on laisse SQLite comme gestionnaire de base de données, le path du repository SVN en rapport au projet et on valide le tout. Nous avons donc maintenant des instances de créé, il nous reste plus qu’à les configurer, pour cela il faut éditer le fichier :

vim /home/trac/projet_1/conf/trac.ini

Je vous laisse consulter la doc, pour configurer vos instances selon vos besoins.

5. Créer un répertoire pour les logs.

On crée un répertoire pour stocker les logs d’accès et d’erreurs de notre futur virtual host :

mkdir /home/trac/logs

6. Configurer Apache pour gestion des instances Trac.

vim /etc/apache2/sites-available/trac.exemple.com

Notre virtual host est en mode HTTPS mais vous êtes libre de le faire en port 80, à noter que nous mettons en place l’authentification Apache sur le même fichier d’autorisation que SVN.

<VirtualHost [IP address]:443>
  ServerName trac.example.com

  <Location />
    SetHandler mod_python
    PythonHandler trac.web.modpython_frontend
    PythonInterpreter main_interpreter
    PythonOption TracEnvParentDir /home/trac
    PythonOption TracUriRoot /

    AuthType Basic
    AuthName “Dépots Trac"
    AuthUserFile /home/svn/.passwd
    Require valid-user
  </Location>

  CustomLog /home/trac/logs/access.log combined
  ErrorLog /home/trac/logs/error.log

  SSLEngine on
  SSLCertificateFile /etc/ssl/server.pem
  SSLCertificateKeyFile /etc/ssl/server.key

</VirtualHost>

<VirtualHost [IP address]:80>
  ServerName trac.example.com
  Redirect / https://trac.example.com/
</VirtualHost>

7. On enclenche le virtual host pour Apache.

a2ensite trac.example.com

8. On relance notre serveur Apache.

/etc/init.d/apache2 restart

Et voilà nous avons Trac en mode multi-projets prêt à recevoir nos développements. Il ne vous reste plus qu’à consulter la doc pour aller plus loin dans votre installation.

Moi de mon côté je dispose d’un gestionnaire de projets tout neuf, parfait ça tombe bien, j’ai un projet en cours de réflexion qui commence à pointer le bout de son nez … muuummm

Le 13 mai, un message publié sur la liste de sécurité Debian identifiait une anomalie impactant le paquet openssl. Ce bug a été introduit par un mainteneur Debian, qui a eu la main lourde en voulant “corriger” des alertes remontées par Valgrind (un logiciel qui audite le code). Résultat des courses : le générateur de nombres aléatoires, composant critique de nombreux systèmes de chiffrements, n’est au final pas si aléatoire que ça, voire carrément prévisible.
En conséquence, tous les certificats et clefs SSL/SSH générés sur une Debian (ou dérivée) depuis 2006 l’ont été à partir d’un univers des possibles très restreint (environ 250 000 clefs, à confirmer) et présentent donc un niveau de sécurité largement inférieur à celui estimé.

Cette vulnérabilité touche Debian ainsi que toutes les distributions utilisant des paquets Debian (Ubuntu, Xandros…).

la suite de l’article …

Que cette faille impacte les Debians depuis 2006 à cause d’un “patch” sur un paquetage aussi sensible qu’OpenSSL, ca me laisse … comment dire … un gout amer aux premiers abords …

Puis travaillant dans le développement logiciel, l’erreur est humaine, c’est un fait … Mais pour ça, on met en place des cycles de validation …

Surtout sur le composant principal dans la cryptographie et donc OpenSSL, le générateur de nombres aléatoires !..

Le fait d’un développeur pas très consciencieux ?.. Pas de cycles de validation avant livraison ?.. Le “stress” d’un patch sous la pression du client ? lol je pense pas qu’on soit affecté par l’effet du “stress” dans la communauté Debian …

En tous cas la communauté réagi au mieux comme d’habitude, l’info et les mises à jour circulent vite … Au moment où j’écris cet article, je viens de recevoir un mail de mon hébergeur pour m’annoncer la faille !

Au final, on se remontent les manches pour :

1) Mettre à jour OpenSSL, et regénérer l’intégralité de nos clefs SSH, certificats …
Pour corriger la faille, la manipulation à effectuer est la suivante :

apt-get update
apt-get upgrade openssh-client openssh-server openssl
rm -f /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys

Dans la mise à jour, il existe des commandes pour vérifier si vos clefs SSH et certificats serveurs sont impactés … hummmm moyen je trouve …

Du coup on efface tout ! Nos autorités de certification, nos clefs SSH, nos certificats serveurs et on régénèrent l’ensemble sur nos plateformes LAMP.

(Tout mes encouragements aux administrateurs Debian ou dérivés qui sont en charge de centaines de serveurs et de milliers de clefs SSH …)

Du boulot en perspective donc … j’avais prévue autre chose moi ce weekend ! Mais bon j’en profiterais pour commencer un article sur la procédure à suivre dans l’installation d’une petite PKI maison.

2) Débattre le fait d’avoir choisi une Debian sur ses serveurs …

J’en connais qui rigolent dans leurs coins …

Comme je viens de migrer mes serveurs sous Debian il y a peu de temps et j’ai quitter une distribution qui n’est pas impactée par cette faille, y’a du débat dans l’air !

Dès Lundi voir le Marketing, pour rassurer tout le monde … , lol.

Bonne fin de soirée.

Suite à cette situation le livre “Pratique d’ActionScript 3″ par Thibault Imbert ne pourra jamais sortir aux éditions O’Reilly, mais l”auteur à décidé de le laisser en libre téléchargement pour la communauté Flash.

Récemment dans ma profession j’ai été confronté au développement de Widgets en Flash, cela faisait bientôt 2 ans que je n’avais pas fait de projets sérieux en Action Script, le développement AS3 m’a vraiment surpris dans son évolution et on sent bien le potentiel à venir via les frameworks de type Flex et Air.

Bravo donc à Thibault pour son initiative, la communauté Flash ne peut que le remercier et le soutenir …

Mon langage de prédilection étant le PHP, j’écris mes scripts console en mode php-cli. Pour effectuer des manipulations au niveau du shell en tant que root ou me connecter sur d’autres machines, j’utilise l’extension SSH2 de php, hélas sous Debian point de package disponible, il faut donc compiler cette extension pour en profiter, voici donc un sujet pour un nouveau article.

1. Installer les packages nécessaires.

Si vous en êtes à compiler la libSSH2 pour PHP, on suppose que vous avez déjà PHP d’installé, on installe donc que les packages de développement et de compilation. On lance donc une console, on se logue en root, on update nos sources et on télécharge les packages suivants :

apt-get update
apt-get install openssl php5-dev libssl-dev g++-3.4 make

2. Télécharger la libSSH2 et la compiler.

On se déplace dans un répertoire dédié à la compilation de nos sources.

cd compilation/
mkdir libssh2
cd libssh2/

On télécharge la libSSH2 en version 0.14, à la date de cet article la dernière version est la 0.18 mais je n’ai jamais réussi à la compiler correctement pour php.

wget http://kent.dl.sourceforge.net/\
sourceforge/libssh2/libssh2-0.14.tar.gz

On décompresse l’archive et on se déplace dans le répertoire.

tar -xzvf libssh2-0.14.tar.gz
cd libssh2-0.14

On lance la compilation.

./configure
make all install

3. Télécharger SSH2 de pecl et lancer la compilation.

On remonte d’un niveau dans les répertoires et on télécharge SSH2.

cd ../
wget http://pecl.php.net/get/ssh2-0.10.tgz

On décompresse l’archive et on se déplace dans le répertoire.

tar -xzvf ssh2-0.10.tgz
cd ssh2-0.10

On lance la compilation.

phpize
./configure
make

Si tout s’est bien passé, logiquement vous devez avoir dans le répertoire “compilation/libssh2/ssh2-0.10/modules”, un fichier nommé ssh2.so.

4. Installation de l’extension SSH2.

On copie ssh2.so dans le répertoire des extensions PHP et on l’active dans les fichiers php.ini d’apache et de php-cli.

cp modules/ssh2.so /usr/lib/php5/20060613+lfs
echo "extension=ssh2.so" >> /etc/php5/apache2/php.ini
echo "extension=ssh2.so" >> /etc/php5/cli/php.ini

On relance Apache pour la prise en compte.

/etc/init.d/apache2 restart

Il ne vous reste plus qu’à vérifier la présence de SSH2 dans votre PHP, à l’aide de la fonction “phpinfo ();” via un script php Apache et pour php-cli lancer cette commande via une console :

php -m

Et voilà, quel plaisir de disposer de SSH dans nos scripts PHP.

1. Installez les packages nécessaires.

On lance une console, on passe en root, on update nos sources et on télécharge les packages suivants :

apt-get update
apt-get install subversion subversion-tools libapache2-svn

2. Créer un répertoire pour le virtual host dédié à SVN.

Nous créons le répertoire dédié à l’hébergement de nos projets SVN et on règle les droits sur celui-ci de la manière suivante :

mkdir /home/svn
chmod 770 /home/svn

3. Mettre en place les référentiels.

Comme nous voulons une gestion multi-projets, il nous faut créer plusieurs projets pour l’exemple et affecter l’utilisateur et groupe Apache sur ceux-ci :

svnadmin create /home/svn/projet_1
svnadmin create /home/svn/projet_2
chown -R www-data:www-data /home/svn

4. Régler les autorisations d’accès aux référentiels.

Il nous faut créer un fichier qui va définir les autorisations d’accès à nos référentiels en mode lecture et écriture, la manière de procéder est décrite ici.

vim /home/svn/.authz

5. Créer un répertoire pour les logs.

On crée un répertoire pour stocker les logs d’accès et d’erreurs de notre virtual host :

mkdir /home/svn/logs

6. Configuration du virtual host.

vim /etc/apache2/sites-available/svn.exemple.com

Notre virtual host est en mode HTTPS mais vous êtes libre de le faire en port 80, à noter que nous mettons en place l’authentification Apache.

<VirtualHost [IP address]:443>
  ServerName svn.example.com

  <Location />
    DAV svn
    SVNParentPath /home/svn
    AuthzSVNAccessFile /home/svn/.authz

    AuthType Basic
    AuthName "Dépots Subversion"
    AuthUserFile /home/svn/.passwd
    Require valid-user
  </Location>

  CustomLog /home/svn/logs/access.log combined
  ErrorLog /home/svn/logs/error.log

  SSLEngine on
  SSLCertificateFile /etc/ssl/server.pem
  SSLCertificateKeyFile /etc/ssl/server.key

</VirtualHost>

<VirtualHost [IP address]:80>
  ServerName svn.example.com
  Redirect / https://svn.example.com/
</VirtualHost>

7. On enclenche le virtual host pour Apache.

a2ensite svn.example.com

8. On crée notre couple user/login pour l’authenfication Apache.

touch /home/svn/.passwd
htpasswd -m /home/svn/.passwd username

9. On relance notre serveur Apache.

/etc/init.d/apache2 restart

Et voilà nous avons un dépôt Subversion multi-projets prêt à recevoir nos développements, il nous reste à choisir un client SVN pour se connecter :

• TortoiseSVN (standalone windows)
• Subclipse (plugin eclipse donc multi-plateforme)
• eSvn (standalone multi-plateforme)
• Metissian (standalone mac os X)

Il ne me reste plus qu’à vous préparer un article sur l’installation de trac, une application web qui s’appuie sur SVN pour de la gestion de projets, en attendant je vais faire dodo …

On ouvre une console, on passe en root, on commence par updater nos sources et on télécharge la version dev de dpkg :

apt-get update
apt-get install dpkg-dev

On passe dans un répertoire dédié à la compilation de nos sources et on télécharge les sources d’apache :

cd compilation/
apt-get source apache2

Puis selon la version de votre apache on se déplace dans le répertoire suivant :

cd apache2-2.x.x/support/

Ensuite on édite le fichier suexec.h pour modifier les options suivantes :
On remplace :

#define AP_HTTPD_USER "www"

Par :

#define AP_HTTPD_USER "www-data"

On remplace :

#define AP_LOG_EXEC DEFAULT_EXP_LOGFILEDIR "/suexec_log"

Par :

#define AP_LOG_EXEC "/var/log/apache2/suexec.log"

On remplace :

#define AP_DOC_ROOT DEFAULT_EXP_HTDOCSDIR

Par :

#define AP_DOC_ROOT "/home/www"

Ensuite il nous faut lancer le “./configure” avant de compiler :

~/apache2-2.x.x/support# cd ..
~/apache2-2.x.x# ./configure

Il nous reste plus qu’a lancer le “make” pour compiler suexec :

~/apache2-2.x.x# cd support/
~/apache2-2.x.x/support# make suexec

Une fois compilé, il nous faut remplacer le suexec original :

~/apache2-2.x.x/support# cp suexec /usr/lib/apache2/suexec

Pour vérifier que notre modification à porter ses fruits, lancer cette commande :

/usr/lib/apache2/suexec -V

Le résultat devrait ressembler à celui-ci :

-D AP_DOC_ROOT="/home/www"
-D AP_GID_MIN=100
-D AP_HTTPD_USER="www-data"
-D AP_LOG_EXEC="/var/log/apache2/suexec.log"
-D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin"
-D AP_UID_MIN=100
-D AP_USERDIR_SUFFIX="public_html"

Il nous faut relancer apache pour prendre en compte notre nouveau suexec :

/etc/init.d/apache2 restart

J’ai eu ce besoin pour pouvoir faire une installation de PHP en mode “fastcgi”, je vous prépare un petit article sur le sujet pour très bientôt …