Après installation d’Ubuntu 14.04 (Trusty), je me rappelle que wine a été supprimé du système lors de la mise à jour d’Ubuntu.
Qu’à cela ne tienne, on va le réinstaller.
En deux lignes, on ajoute le PPA et on installe wine1.7 :
sudo add-apt-repository ppa:ubuntu-wine/ppa -y && sudo apt-get update
sudo apt-get install wine1.7Code language: JavaScript (javascript)A ce stade, wine aurait dû s’installer normalement. Mais pas chez moi, non.
Après la mise à jour vers MySQL 5.6, certaines applications peuvent renvoyer l’avertissement PHP suivant :
PHP Warning: mysql_connect(): Headers and client library minor version mismatch. Headers:50535 Library:50617Code language: CSS (css)C’est le cas lorsqu’une application est liée à l’utilisation d’une version spécifique de libmysqlclient18 alors qu’elle est connectée à un serveur MySQL qui tourne sur une version différente.
C’est libmysqlclient18 qui renvoie cet avertissement mais dans certains cas, cela peut impacter l’application et tient plus de l’erreur que de l’avertissement.
La solution est toute simple : il suffit d’utiliser le pilote MySQL Native Driver php5-mysqlnd au lieu du paquet php5-mysql.
Les avantages de php5-mysqlnd sont multiples : il vient en remplacement de php5-mysql, n’est pas lié à la librairie libmysqlclient, ne renvoie pas d’avertissement “version mismatch” et possède pas mal d’autres caractéristiques intéressantes.
Suite à une mise à jour de Chromium, il y a quelques années, j’ai perdu la possibilité de lire les vidéos flash sous Chromium. Bon, étant utilisateur de FireFox, je ne trouvais pas vraiment cela gênant, sauf pour les vidéos YouTube et Dailymotion.
Et puis aujourd’hui, cela m’a un peu agacé alors je me suis un peu penché sur le problème.
Si on utilise Chrome, pas de souci, le plugin Pepper Flash comme le lecteur PDF natif sont inclus. Si on utilise Chromium par contre, le navigateur est nu et il faut installer Pepper Flash soi-même.
Si vous possédez Ubuntu 14.04+, un installeur Pepper Flash Player installer est disponible dans les dépôts, il suffit de l’installer avec :
sudo apt-get install pepperflashplugin-nonfree && sudo update-pepperflashplugin-nonfree --installCode language: JavaScript (javascript)
Aujourd’hui, j’ai mis à jour mon installation d’Ubuntu 12.04 LTS (precise) vers la version 14.04 LTS (trusty).
Vu qu’il y a quelques années entre les deux distributions, cela a pris quelques heures mais je trouve le système beaucoup plus réactif. J’ai quand même eu une petite erreur, histoire de justifier cet article.
Après l’installation, le nettoyage des paquets obsolètes et un petit redémarrage, apt-get m’a indiqué qu’il y avait un problème de dépendance avec ce message d’erreur :
/var/lib/dpkg/info/xulrunner-1.9.2.prerm: 8: /var/lib/dpkg/info/xulrunner-1.9.2.prerm: /usr/sbin/update-alternatives: not found
/usr/lib/xulrunner-1.9.2.9/xulrunner-bin: error while loading shared libraries: libhunspell-1.2.so.0: cannot open shared object file: No such file or directory
dpkg: error processing xulrunner-1.9.2 (--configure):
subprocess installed post-installation script returned error exit status 127
Errors were encountered while processing:
xulrunner-1.9.2
E: Sub-process /usr/bin/dpkg returned an error code (1)Code language: JavaScript (javascript)Après avoir essayé de réinstaller et supprimer libhunspell et xulrunner sans succès, je me suis dit qu’il fallait passer à autre chose.
En suivant à tâtons les liens du message d’erreur, il se trouve qu’il suffit d’éditer le fichier /var/lib/dpkg/info/xulrunner-1.9.2.prerm pour corriger le problème.
Aujourd’hui, on va s’atteler à sécuriser le serveur de mail, géré par Postfix et Courier, pour utiliser notre certificat SSL et en ajoutant le Perfect Forward Secrecy.
Ce tutoriel part du principe que votre serveur tourne sous Debian et que vous avez suivi le tutoriel précédent sur Postfix avec gestion d’utilisateurs virtuels, c’est-à-dire que le serveur de mail doit déjà être opérationnel.
On commence par vérifier que le serveur est capable d’envoyer des mails avec :
echo "test" | mail -s testsubject user@example.comCode language: PHP (php)Si le mail est reçu, passez à l’étape suivante.
Nous allons concaténer la clé et le certificat pour Courier :
cd /etc/ssl
cat skyminds.net.key skyminds_net.crt >> courier-key-crt-dh.pemet on va y inclure un échange de clés Diffie-Hellman :
openssl dhparam 2048 >> courier-key-crt-dh.pemCode language: CSS (css)On ajoute une autre clé DH en 2048 bits:
openssl gendh -out /etc/postfix/dh_2048.pem -2 2048L’échange de clés Diffie-Hellman – du nom de ses auteurs Whitfield Diffie et Martin Hellman – est une méthode par laquelle deux personnes nommées conventionnellement Alice et Bob peuvent se mettre d’accord sur un nombre (qu’ils peuvent utiliser comme clé pour chiffrer la conversation suivante) sans qu’une troisième personne appelée Ève puisse découvrir le nombre, même en ayant écouté tous leurs échanges. Cela sécurise un peu plus l’échange.
Au cours de mes errements avec le mode rescue, j’ai été obligé de m’identifier sur le serveur avec des identifiants temporaires différents de ceux que j’utilise habituellement.
J’ai retiré la clé habituelle, ajouté la nouvelle (celle du mode rescue), et maintenant, de retour sur ma session habituelle, SSH se plaint – à juste titre – que l’empreinte de la clé RSA du serveur a changé.
Dans ma précipitation à vouloir tout réparer, j’ai ajouté les identifiants temporaires de manière permanente au fichier /home/matt/.ssh/known_hosts.
Et, bien sûr, dès que j’ai voulu me connecter, j’ai obtenu ce message d’erreur :
Warning: the RSA host key for 'hostname' differs from the key for the IP address 'xxx.xxx.xxx.xxx'
Offending key for IP in /home/matt/.ssh/known_hosts:16
Matching host key in /home/matt/.ssh/known_hosts:11
Are you sure you want to continue connecting (yes/no)? Code language: JavaScript (javascript)
J’ai lamentablement fait planter le serveur en voulant mettre le kernel à jour…
Heureusement, il existe le mode rescue chez OVH qui permet d’installer un linux provisoire sur le serveur et d’initier une connexion SSH pour que l’on puisse réparer le système.
Si jamais cela vous arrive, voici la marche à suivre.
1. Aller sur le manager OVH > Dedicated > Infrastructure > clic sur votre serveur > clic sur l’onglet Server Status.
J’ai toujours rêvé d’une imprimante d’étiquettes – principalement parce que j’ai la flemme de toujours rechercher sur Google les mêmes adresses parce que je n’ai pas de carnet d’adresse à jour, mais aussi parce que cela fait plus professionnel pour les gens qui reçoivent mes missives.
Après une petite visite sur Amazon, je découvre l’imprimante d’étiquette Brother QL-710W, qui en plus bénéficie d’une offre de remboursement de 50 euros jusqu’à fin décembre 2014. Je me dis que cela pourrait être cool, surtout qu’elle est USB et WiFi.
Commandée, reçue le lendemain, déballée, branchée en USB, je me penche maintenant sur la configuration sous Linux.
Alors, sous Ubuntu, l’imprimante s’installe toute seule. Par contre, sous certaines versions Linux (Linux Mint ou Debian par exemple), il va falloir passer en manuel, en ligne de commandes dans le terminal.
On branche l’imprimante en USB et on l’allume.
On se rend sur la page des pilotes linux de la Brother QL-710W et on y télécharge les deux fichiers suivants : LPR printer driver et CUPSwrapper printer driver.
En voulant lancer l’installation des paquets comme indiqué sur la page du support Brother, j’ai été confronté aux erreurs suivantes :
mkdir: impossible de creer le repertoire "/var/spool/lpd/ql710w": Aucun fichier ou dossier de ce type chown: impossible d'acceder à "/var/spool/lpd/ql710w": Aucun fichier ou dossier de ce type chgrp: impossible d'acceder à "/var/spool/lpd/ql710w": Aucun fichier ou dossier de ce type chmod: impossible d'acceder à "/var/spool/lpd/ql710w": Aucun fichier ou dossier de ce type<Code language: JavaScript (javascript)Ce qui signifie tout simplement que le répertoire /var/spool/lpd n’existe pas. On s’en assure :
file /var/spool/lpdCode language: JavaScript (javascript)résultat :
/var/spool/lpd: ERROR: cannot open `/var/spool/lpd' (No such file or directory)Code language: PHP (php)donc on le crée :
sudo mkdir -p /var/spool/lpdCode language: JavaScript (javascript)Ensuite, on installe nos deux paquets :
sudo dpkg -i --force-architecture ql710wlpr-1.0.1-1.i386.deb
sudo dpkg -i --force-architecture ql710wcupswrapper-1.0.1-1.i386.debCode language: CSS (css)Plus d’erreurs, on continue et on vérifie que les pilotes ont été installés et chargés :
dpkg -l | grep Brotherqui nous retourne:
ii printer-driver-ptouch 1.3-3ubuntu0.1 printer driver Brother P-touch label printers
ii ql710wcupswrapper:i386 1.0.1-1 Brother CUPS PTouch Printer Definitions
ii ql710wlpr:i386 1.0.1-1 Brother lpr Ptouch Printer DefinitionsCode language: CSS (css)À ce stade l’imprimante est quasiment installée, il suffit de se rendre sur la page d’administration de CUPS, à l’adresse http://localhost:631 et de cliquer sur Admin > Add Printer > Local Printer et on se laisse guider.
Aujourd’hui, j’ai changé la manière dont Apache et PHP interagissent ensemble.
Concrètement, au lieu d’utiliser la configuration par défaut du serveur Apache, c’est-à-dire le module mod_php par défaut, le serveur utilisera dorénavant mod_fastcgi (fastcgi) avec PHP-FPM (FastCGI Process Manager).
La raison principale pour laquelle mod_php utilise plus de ressources réside dans le fait que le module est chargé par le serveur même lors de requêtes pour des fichiers autres que PHP, comme des fichiers HTML ou des fichiers JavaScript.
FastCGI Process Manager (PHP-FPM) aide à réduire l’addition des ressources système utilisées en forçant le serveur à agir comme un proxy et à ne passer que les fichiers portant l’extension php à PHP-FPM.
Ce tutoriel assume que vous avez une installation Apache/PHP sous Debian qui tourne sous mod_php, c’est-à-dire une installation standard. Les changements prennent moins de 15 minutes.
Objectifs : gagner en rapidité d’exécution et avoir une installation plus légère. On peut ainsi envisager un jour de changer Apache pour un autre serveur tout en gardant la même configuration PHP.
Cette semaine, j’ai décidé de mettre mon installation de Varnish à jour.
La version 3.0.5 date de décembre 2013 et il est temps de mettre le serveur à jour pour bénéficier des dernières nouveautés et corrections de bugs. Nous passons donc de Varnish 3 à Varnish 4.
Cela ne se fait pas sans peine car chez Varnish, ils renomment certaines directives d’une version à l’autre… ce qui fait planter le serveur Varnish puisqu’il ne reconnait plus les directives.
Résultat : le fichier de configuration de la version précédente plantera obligatoirement sous la dernière version !
Ce tutoriel en 3 étapes nous donnera l’occasion de mettre à jour Varnish et de scinder notre fichier de configuration en plusieurs modules de manière à en simplifier l’édition et la maintenance futures.
Pour mettre à jour Varnish, il suffit de pointer apt vers les derniers dépôts à jour. On édite donc /etc/apt/sources.list :
nano /etc/apt/sources.listCode language: PHP (php)et on y met à jour nos dépôts:
# varnish
deb http://repo.varnish-cache.org/debian/ wheezy varnish-4.0Code language: PHP (php)On rafraîchit la liste des paquets et on lance la mise à jour :
apt-get update && apt-get upgradeCode language: JavaScript (javascript)Varnish est maintenant mis à jour mais loin d’être fonctionnel étant donné que le format du fichier de configuration a changé.
Certaines directives ont changé de nom et, malgré avoir lu le guide de migration officiel, j’ai modifié mon fichier de configuration en corrigeant les erreurs une à une. Cela prend du temps mais au final, le fichier est plus clair qu’avant.
Aujourd’hui, je me suis encore amusé à mettre à jour mon portable Toshiba de 2005 : après lui avoir mis un SSD et Linux Mint, je lui ai offert une carte WiFi Broadcom 43222, en remplacement de l’Intel WM3B2200BG d’origine.
Je me suis aperçu que c’était difficile pour cette machine de capter le signal WiFi, que ce soit à la maison ou lorsque je suis à l’étranger : il n’y a rien de plus vexant que d’amener sa machine et de ne pas pouvoir se connecter au réseau.
Changer une carte réseau sur un ordinateur portable n’a rien de bien compliqué mais il m’a fallu du temps pour trouver une carte de remplacement compatible : toutes les nouvelles cartes sont en PCI-Express maintenant, or mon Toshiba n’accepte que du Mini-PCI Type III.
La carte Broadcom est la seule que j’ai trouvé qui fasse WiFi N et qui soit en Mini-PCI, je l’ai achetée pour une dizaine d’euros sur Ebay.
Par conséquent, voici un petit tutoriel qui montre comment changer une carte WiFi sur un Toshiba Satellite.
On commence par la base : on éteint la machine, on enlève le courant et on retire la batterie. Et on touche un objet métallique pour décharger l’électricité statique, on ne sait jamais.
Voici quelques images intéressantes pour le démontage du Toshiba Satellite.
1. Retourner le laptop pour avoir accès aux modules et enlever la batterie.
2. Retirer la vis du module WiFi.
3. Déconnecter les câbles de l’antenne de la carte. Le fil blanc va sur MAIN et le fil noir sur AUX.
4. Retirer la carte WiFi. Il suffit d’écarter simplement les deux pattes qui la retiennent : elle va se lever doucement et vous pourrez la retirer doucement. Il ne faut surtout pas utiliser la force : juste écarter les deux pattes et lever la carte.
5. Insérer la nouvelle carte. Elle est plus compacte donc aucun souci pour la placer. Remettre les deux fils d’antenne. Revisser le compartiment.
Une fois la carte changée, un reboot et vous vous apercevez que nous n’avez plus le WiFi ? C’est normal, la nouvelle carte nécessite des pilotes qui ne sont pas installés par défaut… il faut donc passer par une connexion Ethernet le temps de les installer.
Je n’avais pas anticipé cela quand j’avais commencé le tutoriel mais étant chez moi, cela n’a pas posé de souci. C’est une chose importante à souligner toutefois.
Notre nouvelle carte est normalement gérée par les pilotes b43. On peut le vérifier avec cette commande :
sudo lspci -vnn -d 14e4:qui retourne ceci :
06:02.0 Network controller [0280]: Broadcom Corporation BCM43222 Wireless Network Adapter [14e4:4350]Code language: CSS (css)La dernière partie entre crochet – 4350 – signifie que nous avons bien affaire à une carte Broadcom BCM43222, prise en charge depuis la version 3.8 des pilotes, et capable de WiFi a/b/g/n.
TLS est activé sur notre serveur Apache, WordPress sert désormais ses pages avec une connexion chiffrée et Webmin se sert de notre certificat SSL.
Aujourd’hui, je cherche à lancer le client bittorent Transmission et… je tombe sur un message d’erreur qui m’empêche d’accéder son interface web : “Error code: ssl_error_rx_record_too_long”.
Voici donc comment corriger le problème et afficher l’interface Web de Transmission en HTTPS. Ce tutoriel prend moins de 10 minutes à réaliser.
Le premier message d’erreur sur lequel je tombe est le suivant :
Secure Connection Failed
An error occurred during a connection to www.example.com:9091. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long)
Je commence par vérifier le fichier de configuration de Transmission et m’aperçoit assez rapidement qu’il ne sera d’aucun secours.
Une recherche sur le net m’informe qu’il faut probablement voir du côté de la configuration Apache – qui ne contenait jusqu’alors aucune référence à Transmission.
Plusieurs essais de configuration plus tard, l’erreur se transforme en erreur 409.
Le second message auquel je me heurte est le suivant :
409: Conflict
Your request had an invalid session-id header.
To fix this, follow these steps:
When reading a response, get its X-Transmission-Session-Id header and remember it
Add the updated header to your outgoing requests
When you get this 409 error message, resend your request with the updated headerThis requirement has been added to help prevent CSRF attacks.
C’est la première fois que je tombe sur une erreur 409, je suis plutôt content. Je continue donc de tester diverses directives Apache jusqu’à trouver la bonne recette pour faire fonctionner le client web UI de Transmission over SSL.