Apache 2 après passage à Ubuntu 13.10

Pas mal de problèmes sur le serveur ces derniers jours. J’ai eu la bonne idée de faire la mise à jour depuis Ubuntu 13.04 à Ubuntu 13.10 sur le serveur. Du coup Apache a été mis à jour (bonne chose) mais beaucoup de choses ont changé (mauvaise chose).

La première chose à savoir si le problème vous arrive aussi c’est qu’apache, dans ses nouvelles configurations, n’accepte plus les fichiers de configuration de site qui ne finissent pas en « .conf« . Moi qui les avais tous nommés en fonction du nom du site(domaine/sous-domaine), j’ai dû renommer tous mes fichiers de config pour rajouter l’extension magique.

Une fois que ceci était fait, il m’a fallut supprimer les anciens lien symboliques rajoutés par apache lors des mes précédents a2ensite et présents dans /etc/apache2/sites-enabled/ en faisant :

cd /etc/apache2/sites-enabled/
rm *

De plus, mes fichiers de configuration possédaient des «  » lorsque je voulais désactiver une option mais jamais de « + » lorsque je voulais en ajouter une. Je me contentais par exemple de marquer

Options -Indexes FollowSymLinks MultiViews

Il faut donc reprendre tous les fichiers pour rajouter les « + » qui ont l’air d’être devenus obligatoires donnant donc :

Options -Indexes +FollowSymLinks +MultiViews

Voilà tous les fichiers de configuration de sites sont désormais valides il ne reste plus qu’à activer soit site par site ceux que l’on désire mettre en place soit d’un coup d’un seul tous ceux disponibles en faisant :

a2ensite *

La plupart du temps, les anciens fichiers de configurations ont été conservés et le nouveau fichier de configuration a été mis à côté avec pour extension « .dpkg-new« . Cependant l’ancien est toujours effectif. Dans le doute j’ai quand même refait mes configurations dans le nouveau fichier histoire de ne pas prendre de risques.

Cependant, si vous n’aviez jamais touché un fichier de config, il a été remplacé par la nouvelle version. Dans mon cas, ceci n’a pas été un franc succès puisque le dossier de base des fichiers de site du serveur était revenu à sa valeur par défaut à savoir /var/www/

J’ai donc changé dans le fichier /etc/apache2/apache2.conf les lignes

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride None
        Require all granted
</Directory>

par le bon dossier et les bonnes options.

J’ai aussi eu la désagréable surprise de voir que le module php5-json n’était plus installé. Mais pour régler le problème un petit

apt-get install php5-json

et le voilà installé. Plus qu’à faire

service apache2 restart

et voilà un apache qui refait ce qu’on attend de lui.

En conclusion, je dirais que là la solution était relativement simple donc même si ce n’était pas la meilleure des surprises, le problème se corrigeait rapidement. Cependant, pour ceux qui ne savent pas trop gérer les fichiers de config, la tâche aurait pu s’avérer compliquée. Ne faites donc les mises à jour de version d’Ubuntu sur votre serveur qu’en gardant en tête que bien des choses peuvent ne pas se passer comme prévu. Gardez vous quelques heures/jours devant vous quand vous réalisez ce genre d’opération.

EDIT : Une petite précision après quelques recherches. Ce tuto s’applique sur Ubuntu de fait car les versions intégrées entraîne ce problème mais la résolution peut être la même du moment qu’Apache passe d’une version 2.2.X à 2.4.X. (Dans mon cas 2.2.22 à 2.4.6)

Récupérer le résultat d’une commande dans une variable

On continue dans les astuces courtes que j’ai eu à utiliser dans ma conception de scripts. Afin de pouvoir utiliser le PID que j’ai récupéré, il me fallait le stocker dans un variable. Ceci est une notion élémentaire dans le scripting Bash (mais j’avais un peu oublié …)

Il faut procéder comme suit :

variable=$(<COMMANDE_DONT_SOUHAITE_RECUPERER_LE_RESULTAT>)

Vous pouvez maintenant réutiliser le résultat de n’importe quelle commande à l’intérieur d’une autre.

Récupérer le PID d’un processus

Pour une fois un article un peu plus court puisque je viens juste apporter la technique pour récupérer le PID d’un processus. J’ai eu à l’utiliser dans un script de lancement (beaucoup de mises en place de services serveur ces temps ci) donc vous en verrai une utilisation dans les semaines à venir quand je détaillerai ces installations.

Il est bien sûr possible de passer par ps -e (agrémenté de grep et de sed en tous genres) mais ce n’est pas le plus efficace. Voici donc la commande magique :

pidof -x <NOM_DU_PROCESSUS>

Problème d’extinction de la machine

Je suis tombé sur un problème découvert lors du passage de mes serveurs sur proxmox. Le problème est simple, la commande

halt

n’éteint pas la machine. Problème gênant dans certains cas puisque, par exemple, sans extinction, pas de démarrage en WOL. Ce problème se caractérise principalement par les lignes de fin :

Will now halt
[<TEMPS_DEPUIS_L_ALLUMAGE>] System halted

qui ne mènent à rien du tout. Caractérisé de bug depuis Ubuntu 11.04, celui ci n’est pas destiné à être corrigé car il relève plus d’une différence de compréhension de la commande à utiliser que de bug. Voici les différences qui existent entre les différentes commandes d’extinction :

  • shutdown : disponible en 3 options
    • -h : Arrêt ou mise hors tension
    • -H : Arrêt
    • -p : Mise hors tension
  • halt : appelle shutdown -h
  • poweroff : appelle shutdown -p

Le problème que l’on rencontre est donc que halt n’en arrive jamais à la mise hors tension de l’alimentation et qu’elle se contente d’arrêter le système d’exploitation. Ainsi, la commande correcte pour faire ce que l’on attend est en réalité poweroff. Les commandes suivantes contournent elles aussi le problème :

halt -p
shutdown -h now

En conclusion, il vaut mieux prendre la bonne habitude d’utiliser poweroff ou shutdown -p lorsque l’on souhaite éteindre entièrement et pas seulement le système.

Juste pour information si les commandes ci dessus ne changent pas le problème, il est aussi possible que ce soit le daemon ACPI qui ne soit pas présent. Par exemple, le problème m’est arrivé avec une autre distribution sous proxmox lorsque j’appuyais sur le bouton Shutdown. Il suffit d’installer ce daemon à l’aide de la commande

apt-get install acpid

PS : Cet article sur le site d’astuces de la société Absolacom complète bien le sujet avec notamment une astuce pour obtenir le comportement attendu même avec des programmes qui utilisent la commande halt.

Réduire la taille des icônes du menu Applications de Gnome 3

Voici un article que j’aurais dû écrire il y a longtemps (n’utilisant plus Gnome Shell) mais malgré tous si un jour Gnome redevient intéressant, il peut toujours être bon d’avoir l’information. Le thème de base livré avec Gnome 3 présente un menu d’application avec des icônes incroyablement grosses à mon goût.

Il est parfaitement possible de diminuer cette taille en modifiant les valeurs .icon-grid et .all-app .icon-grid dans le fichier /usr/share/gnome-shell/theme/gnome-shell.css.

On peut trouver un exemple de modification et bien d’autres astuces élémentaires sur Gnome 3 sur l’article dédié de Tux-planet.

Désactiver le TouchPad sous Linux Mint

Ma machine de travail est un Asus G73JH. Celle ci est parfaitement prise en charge par Linux Mint sur tous les plans à un détail prêt : le bouton de désactivation du TouchPad. Celui ci n’est pas reconnu automatiquement et le TouchPad apparaît systématiquement activé. Moi qui utilise une souris en permanence, un TouchPad activé ne sert qu’à procéder à des clics involontaires.

Heureusement, il est très simple de contrôler ce comportement à l’aide des commandes suivantes:

synclient TouchpadOff=1

pour désactiver le TouchPad et :

synclient TouchpadOff=0

pour activer le TouchPad. Il ne reste plus qu’à lancer cette commande au démarrage de l’ordinateur et les clics involontaires ne deviennent plus un problème.

Lister ses paquets installés pour les réinstaller

Il peut souvent être pratique de voir les paquets actuellement installé sur son système d’exploitation (ici basé sur Debian). On peut par exemple vouloir les exporter pour les réinstaller sur une autre distribution ou tout bêtement pour réinstaller sa machine.

La solution pour faire ça consiste à utiliser le gestionnaire de paquets dpkg à l’aide de la commande :

dpkg --get-selections

Ce qui permet par exemple d’exporter cette liste en l’inscrivant dans un fichier comme ceci :

dpkg --get-selections > packagesList

Un fois ce fichier plat importé sur le nouvel OS, on va importer la liste de paquets en faisant :

dpkg --set-selections < packagesList

Remarque : notez bien la différence entre le get et le set.
Il ne reste plus qu’à installer cette liste à l’aide de la commande :

apt-get dselect-upgrade

Si vous voulez simplement obtenir des informations détaillées sur les paquets que vous avez installés, vous pouvez utiliser :

dpkg -l

mais le détail des informations empêchera de réimporter ce fichier par la suite.

Remplacer la mise en veille par l’hibernation sous Linux Mint

On continue avec les problèmes de mise en veille et de pilotes graphiques mais de nouveau sous Linux Mint 15 Olivia. Le pilote legacy open-source a, comme je l’avais dit lors mon précédent article, la fâcheuse tendance de faire que toute mise en veille de l’ordinateur entraîne une mauvaise reprise et tout l’affichage en sort pixelisé. Les pixels sont d’ailleurs présents des icônes du bureau au curseur de la souris. Lors d’un Ctrl+Alt+F1, la console subit le même traitement. Le seul moyen que j’ai trouvé de réparer le problème est de redémarrer l’ordinateur. Même le logo Linux Mint durant l’extinction est pixelisé donc ceci affecte bien tout l’affichage.

Pour régler tous les paramètres de mise en veille sous Linux Mint 15 Olivia,il faut commencer par installer le remplaçant de gconf-editor à savoir dconf-tools :

apt-get install dconf-tools

Le lancer et se rendre dans : /org/gnome/settings-daemon/plugins/power. L’option qui m’intéressait pour ma part était de remplacer la mise en veille rapide pas entièrement supportée par une hibernation ne posant aucun soucis. Le réglage concernant mon ordinateur fixe, c’est l’option sleep-inactive-ac-type que j’ai ainsi passé à hibernate au lieu de suspend.

Juste pour information, dans les anciennes versions de Linux Mint, l’option à modifier se trouvait en utilisant gconf-editor et en se rendant dans /apps/gnome-power-manager/actions et remplacer la valeur sleep-type-ac par hibernate.

Pilote legacy ATI et fichier version.h

Pour la 1000ème fois, j’ai fait la bêtise de vouloir installer les pilotes propriétaires ATI de ma carte graphique Radeon HD 3870 sur Linux Mint 15 Olivia. Cette carte graphique n’est plus maintenue par ATI, au même titre que les carte 2000, 3000 et 4000 series, et donc il faut utiliser les pilotes legacy. Malheureusement, ceux ci ne sont compatible qu’avec Xorg jusqu’à sa version 1.12 et jusqu’à la version 3.4 du kernel. C’est une telle galère à mettre en place que je conserverai désormais les pilotes open source qui font très bien l’affaire (à quelques détails près mais ça finira bien par se corriger).

Ne connaissant pas encore l’incompatibilité du pilote legacy avec les derniers kernel, ma tentative s’est soldée par un échec. En cause, le fichier version.h qui ne trouvait pas à l’emplacement /usr/include/linux. Tous les kernels récents n’ont plus ce fichier de version à cet endroit mais on peut cependant le récupérer à son autre emplacement à l’aide d’un lien symbolique. On peut donc utiliser la commande :

ln -s /usr/include/linux/version.h /lib/modules/<VERSION_DU_KERNEL>/build/include/linux/version.h

Cependant, réessayer après ça ne suffit toujours pas à avoir un pilote convenablement installé (bien loin de là et le prochain redémarrage le prouvera (entendre par là qu’il ne faut pas s’amuser à redémarrer sans avoir correctement désinstallé ce pilote) par un magnifique mode de compatibilité).

Pour les plus hargneux qui veulent absolument leur pilote legacy sur leur OS dernier cri, il va falloir downgrader Xorg et le kernel par un compatible. Heureusement, des gens bien se sont chargé de simplifier le processus (et là encore ne pas entendre que c’est simple) comme Tomasz Makarewicz.

En tout cas le driver libre reste, selon moi, la meilleure solution.

Vidéos flash accélérées avec chrome sous Linux

Lorsque j’avais réinstallé Debian 7 avec Gnome 3 pour me faire une idée, j’ai rencontré un problème de taille qui aurait pu, à lui seul, me faire retirer l’OS de ma machine de détente.

Mon ordinateur fixe me sert en effet énormément pour aller sur internet, et, même si ceci est petit à petit amené à changer, le flash y est extrêmement présent. Or, tout les contenus flash étaient lus légèrement en accéléré. Les voix étaient donc légèrement plus aiguës et les vidéos passaient légèrement plus vite. On pourrait penser qu’une légère accélération ne change pas grand chose mais c’est un coup à devenir fou.

J’ai quand même fini par trouver comment résoudre le problème. Il est dû à l’utilisation du plugin flash installé par défaut dans chrome et à celui installé dans Debian. Pour désactiver celui des deux qui n’arrive pas à utiliser l’accélération matérielle, il faut se rendre à l’adresse chrome://plugins/ sous chrome et dans les Détails, désactiver le plugin Adobe Flash Player situé dans le dossier d’installation de Google chrome (De base : /opt/google/chrome/). Si le deuxième plugin n’est pas activé, penser à l’activer.

Après un redémarrage de Google chrome, pour être sûr que le plugin est bien pris en compte, lancer une des vidéo flash qui étaient lues en accéléré et accéder aux paramètres du plugin flash en cliquant droit dessus et en se rendant dans Paramètres.

Là, s’assurer que dans l’onglet Affichage, l’option Activer l’accélération matérielle soit bien cochée et fini les problèmes de vidéos accélérées et de sons déformés.