Installer Apache PHP et MySQL sur MacOS High Sierra

Si comme moi vous cherchez à installer le trio Apache, PHP et MySQL sur MacOS High Sierra (beta) vous êtes au bon endroit.

La version finale de MacOS High Sierra n’est pas encore sortie et les formules brew ne sont pas encore toutes prêtes.

Le principal problème c’est que le dépôt Apache n’est pas encore prêt pour High Sierra. Comme ils ont un switch sur la version de l’os pour savoir quelles sources télécharger et qu’ils n’ont pas encore rajouté High Sierra.

J’ai fait un fork de homebrew/homebrew-apache en attendant qu’ils rajoutent High Sierra à la liste. Il y a plusieurs PR en cours pour le même problème.

Du coup au lieu de faire brew tap homebrew/apache il suffit d’utiliser mon dépôt: brew tap ferjul17/apache

Malheureusement quand vous allez arriver à PHP, vous allez vous rendre compte qu’il y a une dépendance entre homebrew/homebrew-php et homebrew/homebrew-apache. J’ai donc également changé cette dépendance et il faut donc également utiliser mon fork pour homebrew/homebrew-php en tapant brew tap ferjul17/php.

Pour MySQL aucun problème. J’ai essayé MariaDB mais malheureusement ça ne marche pas encore et MySQL est acceptable pour moi.

Donc pour installer Apache, PHP et MySQL il faudra taper:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew tap homebrew/dupes
brew tap homebrew/versions
brew tap ferjul17/php
brew tap ferjul17/apache
brew install http24 --with-privileged-ports --with-http2
brew install mysql
brew install php70 --with-httpd24

Pensez à venir rajouter le

<FilesMatch \.php$>
SetHandler application/x-httpd-php
</FilesMatch>

dans votre fichier httpd.conf.

Mon passage à Docker et CoreOS

Depuis plusieurs mois / années, j’entends parler de Docker. Comme j’ai un serveur dédié avec plusieurs services indépendants, je m’intéresse un minimum aux solutions techniques envisageables.
Je n’ai pas tout de suite compris l’intérêt de Docker. À l’époque, j’utilisais Proxmox avec des containers LXC pour isoler mes services. Et pour moi c’était la solution idéale. Simplicité du déploiement, facilité de faire des sauvegardes, légèreté par rapport à des VM lourdes… Du coup quand j’ai considéré Docker, il fallait vraiment qu’il ait de bons arguments pour me convaincre.

Pourquoi migrer vers Docker

En dehors du faite d’apprendre quelque chose de nouveau bien entendu, ce qui m’a vraiment décidé à passer à docker c’est la quantité de templates disponible. Avec Docker, il est extrêmement facile de partager un environnement, et ils foisonnent sur github. Quand j’utilisais LXC, il fallait la majorité du temps que je configure moi-même tous l’os et les services à l’intérieur du container.
Prenant un exemple simple : ARK. ARK est un jeu en ligne multijoueur. Il est possible d’héberger soit même des serveurs et afin de jouer avec des amis, j’avais commencé à configurer un container pour jouer. Et ce fut un calvaire. Au moment oü j’ai commencé a regardé, il y avait encore très peut de retour d’expérience sur la mis en place se serveur sous Linux et auprès des heures de recherches et d’essaies, j’ai fini par abandonner. Avec docker, je trouve facilement sur Github des personnes qui ont pris le temps de fourni des templates pour installer rapidement un serveur ARK.

Un autre argument, c’est la maintenance. Avec LXC, si j’ai besoin de mettre moi-même à jour mes services au sein d’un container. Alors oui il est possible de mettre à jour automatiquement le système, mais comment mettre à jour automatiquement wordpress par exemple ? Ce n’est pas forcement un paquet et dans ce cas la mise à jour passe par la récupération et le remplacement des sources. Alors oui WordPress est bien pensé et il st possible de faire la mise a jour directement depuis le site, mais ça demande une action de notre part et chaque service qu’on installe aura son propre mécanisme. Ce que je cherchais, c’était un moyen de mettre à jour tous mes services installé sur mon serveur de manière automatique et transparente.
Avec docker, il suffit de récupérer la dernière image du service que l’on utilise pour le mettre à jour. Un simple docker pull et le tour est joué.

Pourquoi migrer vers CoreOS

La décision d’utiliser Docker ne fait pas tout. Il faut aussi choisir le système host qui hébergera les différents services. Proxmox me plaisait vraiment beaucoup pour LXC pour son interface web. J’ai donc cherché une interface web pour Docker. Et je cherche toujours…
J’en ai essayé des dizaines en passant de Panamax à Rancher et de Mist.io à Shipyard. Aucune ne m’a convaincu. C’est le principal frein que j’ai rencontré avant de sauter le pas. Mais j’ai fini par faire mon deuil.
Alors pourquoi CoreOS ? Pour plusieurs raisons plus ou moins bonnes. Tout d’abord il faut parti des OS qu’il est possible de préinstallé sur mon serveur dédié chez Online.net. Ensuite c’est un OS spécialisé pour utiliser Docker. CoreOS propose beaucoup de solutions que je n’utilise pas. Par exemple il est possible de faire communiquer des flottes de serveurs installés sur CoreOS pour se répartir la charge. CoreOS ne propose pas de gestionnaire de paquets. Mais alors, comment installer votre éditeur favori pour modifier un ficher ? En passant par un container ! Avec la commande toolbox, il est possible de démarrer un container tournant sous Fedora dans lequel vous pourrez installer tout ce qui vous fait plaisir sans polluer l’host !

Configuration des nouveaux services

J’ai commencé à chercher les templates docker des services dont j’avais besoin comme wordpress, ts3, ou encore plex.
J’ai ensuite démarré et configuré les containers en local en important les données de chaque service depuis mon serveur. J’ai bien entendu pris soin de m’assurer que chaque service mount un dossier depuis l’host pour stocker configuration et données.
Cette manière de faire le permet de n’avoir à backuper que les données / paramètres qui m’intéresse. Pour simplifier davantage, j’ai suivis une convention pour localiser les dossiers de l’host qui sont montés dans les guest. J’ai un dossier ~/to_backup/ qui doit être backuper et un ~/no_backup/ qui n’a pas besoin d’être backuper. Mais pourquoi monter des dossiers qui ne sont pas à sauvegarder ? Pour partager des données entre containers. Par exemple j’ai un container qui se charge de récupérer le contenu diffusé par Plex. Ce n’est pas pour autant que je souhaite sauvegarder ce contenu. Récemment j’ai appris une autre manière de faire des volumes partageables entre containers, mais la solution que j’ai retenue, même si ce n’est pas la meilleure, fonctionne.

Mise en place des services sur le dédié

Afin que les containers docker redémarrer automatiquement en cas de redémarrage du CoreOS (par exemple quand le Kernel est mis a jour), il faut créer des fichiers .service a positionné dans /etc/system/systemd/. Vous trouverez plus d’information sur comment écrire ces fichiers, mais c’est relativement simple :

[Unit]
Description=TS3
After=docker.service
Requires=docker.service

[Service]
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill ts3
ExecStartPre=-/usr/bin/docker rm ts3
ExecStartPre=-/usr/bin/docker pull linuxserver/gsm-ts3
ExecStart=/usr/bin/docker run –name ts3 –net=host -v /home/core/to_backup/ts3_config:/config linuxserver/gsm-ts3

[Install]
WantedBy=multi-user.target

Afin de ne pas perdre ces fichiers en cas de défaillance du disque de mon dédié, mais aussi pour simplifier le déploiement, je fais un lien hard dans ~/to_backup/.

Une fois que tous mes services fonctionnaient bien en local, j’ai fait un gros zip de ~/to_back/, que j’ai uploadé sur mon dédié. J’ai décompressé le tout et c’est parti !

En espérant avoir pu vous aider

Julien

Configuration réseau d’un serveur dédié Proxmox 4 et de ses containers chez Online.net

Après avoir pas mal pataugé pour configurer convenablement mon serveur Proxmox 4, voici les résultats de mes recherches.

Pourquoi

Après avoir expérimenté le serveur dédié sur lequel tournent 50 services, j’ai fini par choisir d’isoler chaque service. Pour ce faire j’ai choisi de virtualiser des machines sur lesquels un service (ou ensemble de services liés) tournerait. J’y vois plusieurs avantages et quelques inconvénients que je récapitule quelques lignes en dessous. Online.net propose Proxmox qui a le mérite d’être utilisable (pour un serveur perso) gratuitement. Plutôt que des VM, j’ai choisi des containers bien plus légers.

Avantages

  • Les containers s’allument et s’éteignent très rapidement (quelques secondes)
  • Ils consomment peu de ressources. Par exemple 1 container avec ce site, 1 avec un logiciel de téléchargement et 1 avec un serveur TeamSpeak le tout pour 5% d’utilisation CPU (Intel Xeon E3 1220) 95% du temps.
  • Le backup des containers est rapide et n’engendre aucun downtime. Vous trouverez plus d’informations ici: Proxmox: Backup and Restore
  • Il est très facile de changer d’environnement. Par exemple j’ai préparé mes containers en local dans une VM sur laquelle Proxmox était installé. Ensuite j’ai backup mes containers que j’ai upload sur un FTP. Une fois le serveur dédié installé, il m’a fallu quelques dizaines de minutes pour mettre en place mes 3 containers et refaire ma configuration réseau.
  • Si un container pose problème, il est possible de l’arrêter uniquement lui et de garder les autres services UP.

Inconvénients

  • La configuration réseau est plus compliquée.
  • Il faut installer chaque container séparément. Par exemple si vous avez besoin de p7zip sur plusieurs containers, il faut l’installer sur tous.
  • De par le fonctionnement intrinsèque des containers, il n’est pas possible de faire tourner n’importe quel OS.

Objectif

Donc le but est d’avoir un host sous Proxmox qui va rediriger les requêtes entrantes (et sortantes) vers les containers. Il est possible d’avoir un container qui s’occupe de ce routage, mais ça rajoute de la complexité qui ne m’est pas utile.

Configuration

Host

Voilà ce que j’ai besoin de faire:

Le host correspond donc à sd-xxx, et les containers ont pour id 100, 101 et 102. Le disque dur du host est représenté par local.
La configuration réseau requise:

Par défaut, eth0, eth1 et vmbr0 existent et sont bien configurés.

vmbr1 est vraiment très simple à configurer:

Quand vous l’aurez créé, il ne sera pas actif, pas d’inquiétude, au prochain redémarrage, il démarrera automatiquement.

Donc voilà pour la partie simple de la configuration du host. Maintenant il faut vous connecter sur host pour aller directement modifier /etc/network/interfaces.

Voici à quoi il doit ressembler:

auto lo
iface lo inet loopback

iface eth0 inet manual

iface eth1 inet manual

auto vmbr0
iface vmbr0 inet static
    address 195.xxx.xxx.xxx
    netmask 255.255.255.0
    gateway 195.xxx.xxx.1
    bridge_ports eth0
    bridge_stp off
    bridge_fd 0

    # Accept already established connections
    post-up   iptables -A INPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT
    post-down iptables -D INPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT
    post-up   iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    post-down iptables -D OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

    # By default, refuse incomming / outgoing connections
    post-up   iptables -P INPUT   DROP
    post-up   iptables -P FORWARD ACCEPT
    post-up   iptables -P OUTPUT  DROP

    # Allow DNS (53) HTTP/HTTPS (80/443) and NTP (123) outgoing requests HOST
    post-up   iptables -A OUTPUT -p udp --dport 53  -j ACCEPT
    post-down iptables -D OUTPUT -p udp --dport 53  -j ACCEPT
    post-up   iptables -A OUTPUT -p tcp --dport 80  -j ACCEPT
    post-down iptables -D OUTPUT -p tcp --dport 80  -j ACCEPT
    post-up   iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
    post-down iptables -D OUTPUT -p tcp --dport 443 -j ACCEPT
    post-up   iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
    post-down iptables -D OUTPUT -p udp --dport 123 -j ACCEPT

    # Allow loopback
    post-up   iptables -A INPUT  -i lo -j ACCEPT
    post-down iptables -D INPUT  -i lo -j ACCEPT
    post-up   iptables -A OUTPUT -o lo -j ACCEPT
    post-down iptables -D OUTPUT -o lo -j ACCEPT

    # Allow ping requests
    post-up   iptables -A INPUT  -p icmp -j ACCEPT
    post-down iptables -D INPUT  -p icmp -j ACCEPT
    post-up   iptables -A OUTPUT -p icmp -j ACCEPT
    post-down iptables -D OUTPUT -p icmp -j ACCEPT

    # Allow SSH
    post-up   iptables -A INPUT -p tcp --dport 22    -j ACCEPT
    post-down iptables -D INPUT -p tcp --dport 22    -j ACCEPT

    # Allow web interface
    post-up   iptables -A INPUT -p tcp --dport 8006 -j ACCEPT
    post-down iptables -D INPUT -p tcp --dport 8006 -j ACCEPT


auto vmbr1
iface vmbr1 inet static
    address  10.0.0.1
    netmask  255.255.255.0
    bridge_ports none
    bridge_stp off
    bridge_fd 0

    post-up echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up   iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o vmbr0 -j MASQUERADE
    post-down iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -o vmbr0 -j MASQUERADE

    # TS3
    post-up   iptables -t nat -A PREROUTING -i vmbr0 -p udp --dport 9987 -j DNAT --to 10.0.0.100:9987
    post-down iptables -t nat -D PREROUTING -i vmbr0 -p udp --dport 9987 -j DNAT --to 10.0.0.100:9987

    # Softweb.fr
    post-up   iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 80 -j DNAT --to 10.0.0.101:80
    post-down iptables -t nat -D PREROUTING -i vmbr0 -p tcp --dport 80 -j DNAT --to 10.0.0.101:80

    ...

Une fois la configuration faite, vous pouvez redémarrer votre serveur Proxmox.

Containers

Concernant la configuration de chaque container, c’est beaucoup plus simple. La configuration se fait à la création et il n’y a rien d’autre à faire.

Pour information, si vous voulez rajouter des templates en les téléchargeants directement depuis votre serveur, il faut les stocker dans /var/lib/vz/template/cache.

La partie qui nous intéresse est la partie réseau que voici:


Il faut bien noter que le Bridge se fait sur vmbr1 et non pas vmbr0.

Pour aller plus loin

La configuration que je vous montre là est un exemple. Mais je ne peux pas m’empêcher de vous inciter à l’adapter à vos besoins. Par exemple, une bonne partie est de changer le port d’écoute de SSH. Mais si vous changez le port sans adapter le firewall vous allez avoir un problème. En effet, le firewall est configuré actuellement, il fonctionne sur le principe d’une whitelist. Ainsi, j’ai autorisé explicitement le port 22. Si vous changez SSH pour écouter sur le port 32768 par exemple, pensez à changer le firewall en conséquence.

Tagged , , , ,

Erreur “: No such file or directory”

Si comme moi vous avez l’erreur “: No such file or directory” qui s’affiche quand vous essayez d’exécuter un script sous Linux, il est probable que j’ai la solution.

julien@VM-GS70-MINT $ cat generate-doc
#!/usr/bin/env sh
../vendor/bin/sami.php update --force ../sami.php
julien@VM-GS70-MINT $ ./generate-doc
: No such file or directory

À première vue, il est assez difficile de trouver l’origine du problème.
Seulement je travaille à la fois sous Linux et Windows et ce dernier n’a toujours pas abandonné le CRLF (\r\n) pour les sauts de lignes.
Or, Linux lui utilise uniquement LF (\n) et est perdu quand il rencontre un CRLF.

Du coup la solution est toute simple:

julien@VM-GS70-MINT $ dos2unix generate-doc
dos2unix: converting file generate-doc to Unix format ...
julien@VM-GS70-MINT $ ./generate-doc
Updating project

Version master
Parsing done
Rendering done

Version Updated C Removed C
master 138 0

Version Updated C Updated N Removed C Removed N
master 138 33 0 0

En espérant vous avoir fait gagner du temps 😉

Tagged , , , ,

Copier des fichiers d’un bucket S3 d’un compte Amazon à un autre

Aujourd’hui je me suis retrouvé dans un cas assez particulier. Je souhaitais copier l’intégralité d’un bucket Amazon S3 vers un autre bucket sachant que les deux étaient sur deux comptes différents.
Généralement j’utilise l’outil payant CloudBerry S3 Explorer PRO pour parcourir mes différents buckets S3. L’avantage de ce logiciel, qu’il partage avec d’autres d’ailleurs, est qu’il permet de travailler avec plusieurs threads pour démultiplier la vitesse d’exécution. En effet, lors d’une copie par exemple, le logiciel doit copier fichier par fichier et quand la quantité de fichiers devient importante, la latence du réseau et le temps de réponse du serveur ne sont plus négligeables. En utilisant plusieurs threads pour faire la copie, on divise le temps nécessaire pour copier l’ensemble des fichiers.

Une solution simple, mais coûteuse en bande passante (et qui peut donc avoir un impact financier important), reste de copier dans un premier temps les fichiers d’un bucket vers un PC, puis, du PC vers le bucket de destination. Mais cette solution n’est pas la plus efficace. Il existe la possibilité de copier directement des fichiers d’un bucket à l’autre, avec une seule requête S3, et sans gaspiller de la bande passante.

Le problème de cette solution c’est qu’elle renvoie l’erreur Access Denied et que pour le résoudre, il faut mettre en place une règle sur le bucket. Cependant après quelques recherches, j’ai fini par trouver les règles à appliquer.

Dans un premier temps, il faut donner l’accès en lecture au compte propriétaire du bucket de destination aux données du bucket de source. Pour se faire, il va vous falloir récupérer l’AWS Account ID du compte propriétaire du bucket de destination. Il est disponible sur la page Your Security Credentials dans la section Account Identifiers.
Ensuite il faut appliquer la règle suivante sur le bucket source :

{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam:::root"
      },
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::/*",
        "arn:aws:s3:::"
      ],
      "Condition": {}
    }
  ]
}

Quand vous remplacez il faut enlever les – qui séparer chaque groupe de chiffre pour avoir quelque chose qui ressemble à 123456789012.

Voilà qui devrait résoudre vos problèmes.

Tagged , , ,

Cygwin, Permissions are too open

Si comme moi, vous utilisez quotidiennement Windows, que ce soit au travail ou à la maison, vous connaissez surement Cygwin.

Néanmoins pour les curieux voici une très courte description :

Linux-like environment for Windows making it possible to port software running on POSIX systems (such as Linux, BSD, and Unix systems) to Windows.

Bien que rendant d’énormes services, Cygwin n’est pas pour autant parfait. Un de ses points faibles est notamment la gestion des droits pour les fichiers.
Ce billet n’a pas pour vocation de résoudre cette problématique, je ne sais même pas si c’est techniquement faisable étant donné que le système de droit de Windows et d’Unix n’est pas vraiment compatible.

Cependant, je vais vous aider à résoudre un des problèmes qui m’arrivent régulièrement : l’impossibilité de modifier les droits du groupe d’un fichier.

Pour introduire la problématique, je vous donne un exemple concret.

Il existe deux façon de se connecte en SSH à un serveur. La première est d’utiliser le classique couple nom d’utilisateur, mot de passe associé. Cependant, je n’aime pas spécialement cette approche, car elle implique de connaitre les différents mots de passe pour chaque serveur.
J’utilise donc l’autre solution qui consiste à utiliser une clé RSA pour se connecter.

La syntaxe et la suivante :

ssh username@hostname -i private_key_file

Problème, de base les fichiers sur on pour droits 666 avec Cygwin. Et quand on essaie d’utiliser une clé avec ces droits on obtient ce message d’erreur :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0666 for 'id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: id_rsa

Facile me direz-vous, il suffit de modifier les droits du fichier grâce à chmod. Oui, mais ça ne marche pas :

$ chmod 400 id_rsa
$ ls -l id_rsa
-r--r-----+ 1 Julien Aucun 1766 16 avr.   2012 id_rsa

Eh oui, il n’est pas possible de modifier les droits du groupe pour ce fichier, ils sont toujours identiques aux droits du propriétaire.

Vous remarquerez que le groupe pour ce fichier est Aucun. Le problème est là. Le fichier n’a pas de groupe. Hors, ce n’est pas possible sur un système POSIX, Cygwin pallie donc à ça en créant un groupe nommé Aucun.

La solution consiste à changer le groupe de ce fichier. Pour celà un petit coup d’oeil au fichier /etc/group vous aidera à choisir :

$ cat /etc/group
root:S-1-5-32-544:0:
Système:S-1-5-18:18:
TrustedInstaller:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464:4294967294:
Administrateurs:S-1-5-32-544:544:
Administrateurs Hyper-V:S-1-5-32-578:578:
Duplicateurs:S-1-5-32-552:552:
IIS_IUSRS:S-1-5-32-568:568:
Invités:S-1-5-32-546:546:
Lecteurs des journaux d’événements:S-1-5-32-573:573:
Opérateurs d'assistance de contrôle d'accès:S-1-5-32-579:579:
Opérateurs de chiffrement:S-1-5-32-569:569:
Opérateurs de configuration réseau:S-1-5-32-556:556:
Opérateurs de sauvegarde:S-1-5-32-551:551:
Utilisateurs:S-1-5-32-545:545:
Utilisateurs avec pouvoir:S-1-5-32-547:547:
Utilisateurs de gestion à distance:S-1-5-32-580:580:
Utilisateurs de l’Analyseur de performances:S-1-5-32-558:558:
Utilisateurs du Bureau à distance:S-1-5-32-555:555:
Utilisateurs du journal de performances:S-1-5-32-559:559:
Utilisateurs du modèle COM distribué:S-1-5-32-562:562:
HomeUsers:S-1-5-21-1022396269-1448771893-189778280-1002:1002:
WinRMRemoteWMIUsers__:S-1-5-21-1022396269-1448771893-189778280-1000:1000:
Aucun:S-1-5-21-1022396269-1448771893-189778280-513:513:
Julien:S-1-5-21-1022396269-1448771893-189778280-1001:11001:

Parmi les groupes, il y a en autres Utilisateurs. On va se servir de lui:

$ chown :Utilisateurs id_rsa
$ ls -l id_rsa
-r--r-----+ 1 Julien Utilisateurs 1766 16 avr.   2012 id_rsa

Et voilà, il ne reste plus qu’à modifier les droits d’accès pour le groupe et le tour est joué :

$ chmod 400 id_rsa
$ ls -l id_rsa
-r--------+ 1 Julien Utilisateurs 1766 16 avr.   2012 id_rsa
$ ssh me@myserver -i id_rsa
Enter passphrase for key 'id_rsa':
me@myserver:~$

Bienvenue chez vous !

Tagged , , , ,

PHP Module is not compiled to be threadsafe

Pour mon serveur, j’utilise Debian. J’aime beaucoup cette distribution pour plusieurs raisons. Premièrement elle est très stable et maintenue, deuxièmement j’aime bien le gestionnaire de paquet APT et pour terminer ils ne font pas de mise à jour tous les 6 mois.
Seulement, revers de la médaille, les paquets ne correspondent presque jamais à la dernière version majeure.

Prenons un serveur web, ce que je connais le mieux. Dessus, il y a 3 choses indispensables dues au caractère web du serveur: Apache, MySQL (ou autre) et PHP. Cependant, j’aime bien profiter des dernières nouveautés en ce qui concerne PHP. Et là, les choses coincent. Debian propose systématiquement l’avant-dernière version stable, et donc pas les toutes dernières innovations. Alors que faire ?

Et bien c’est très simple: deux solutions. La première, c’est tout simplement de compiler PHP soit-même. Seulement ça demande du temps, or du temps, c’est la ressource dont je dispose le mien actuellement. Vient donc la deuxième solution, se faire compiler PHP par quelqu’un d’autre. Et ça, c’est possible, et c’est même très utilisé. Ce sont les fameux paquets !

Alors oui, je viens de vous dire que justement les paquets ne sont pas disponibles, et je vous donne comme solution d’utiliser des paquets… Mais ce qu’il faut savoir, c’est qu’il est possible de rajouter d’autre fournisseur de paquets ! Et il y en a un bien connu, qui justement s’occupe pour vous de vous compiler les dernières versions d’Apache, MySQl et PHP ! J’ai nommé Dotdeb !

Je vous invite à visiter leur site pour plus d’information. Vous avez notamment la page Instructions qui vous des détails précise sur comment utiliser leur repo. Pour ma part, j’ai un petit script qui m’installe et me configure une bonne partie des services que je suis amené à installer sur mon serveur. En voici un extrait pour installer apache php et mysql en utilisant dotdeb:

echo $'
# dotdeb 
deb http://packages.dotdeb.org wheezy all
deb-src http://packages.dotdeb.org wheezy all

# dotdeb php
deb http://packages.dotdeb.org wheezy-php55 all
deb-src http://packages.dotdeb.org wheezy-php55 all
' >> /etc/apt/sources.list

wget http://www.dotdeb.org/dotdeb.gpg
cat dotdeb.gpg | apt-key add -

# install some lib
aptitude update
aptitude install php5 php5-mysql mysql-client mysql-server apache2 apache2-mpm-prefork

Si vous n’utilisez pas ce script, vous aller par contre être potentiellement confronter à un message d’erreur:

[Wed Aug 21 22:43:04 2013] [crit] Apache is running a threaded MPM, but your PHP Module is not compiled to be threadsafe.  You need to recompile PHP.
Pre-configuration failed
Action 'configtest' failed.
The Apache error log may have more information.
 failed!

Les symptômes sont très visibles: votre serveur Apache n’est pas capable d’exécuter du PHP, il se contente de l’affiche tel un vulgaire fichier texte !

La raison de ce message d’erreur n’est, je vous l’avoue, pas évidente pour moi. Je ne maîtrise pas les modules Apache, et quand je suis tombé sur ce message d’erreur je me suis senti quelque peu impuissant. J’ai même été amené à désinstaller les paquets et virer dotdeb de la liste des repos pour réinstaller un PHP 5.4. Jusqu’à ce que je décide de faire face au problème plutôt que de l’éviter.

C’est là qu’en voguant de site en site, de forum en forum, j’ai fini par trouver qu’il suffisait de remplacer le paquet apache2-mpm-worker (installé de base lors de l’installation d’Apache) par apache2-mpm-prefork.
Ainsi donc un simple

aptitude install apache2-mpm-prefork

résoudra votre problème.

PS: Si toi, lecteur, tu as les compétences pour expliquer à quoi ai dû cette erreur, et pour quelle raison le paquet apache-mpm-worker le résous, je me ferai un plaisir de compléter ce billet !

Tagged , , , ,