Tag

mise à jour

Browsing

Ce soir, on lance la mise à jour du serveur: nous passons notre version d’Ubuntu Server de Bionic Beaver (18.04 LTS) à Focal Fossa (20.04 LTS).

On commence par les précautions d’usage: faire ses sauvegardes et vérifier qu’elles sont bien intègres avant de commencer la mise à jour. C’est votre bouée en cas de soucis!

Étape 1: avoir l’installation d’Ubuntu actuelle à jour

Assurez-vous d’avoir une installation à jour avant de commencer:

apt update && apt dist-upgrade

On reboot ensuite pour appliquer les changements:

shutdown -r now

Étape 2: installation de screen et ouverture du port 1022 pour SSH

Comme nous allons lancer la mise à jour via un terminal SSH, il est possible que pour une raison ou un autre la connexion soit coupée. Cela arrive et cela peut être vraiment tendu à certaines étapes de la mise à jour (kernel anyone?).

Pour prévenir cela, on vérifie que screen est bien installé:

apt install screen

On peut lancer une session screen avec:

screen

et si la connexion SSH est interrompue lors de la mise à jour, on peut se raccrocher à la session de mise à jour avec la commande:

screen -Dr

Ensuite, au niveau du pare-feu, on ouvre le port 1022. C’est via ce port que l’on pourra reprendre la MAJ en cas de pépin. Suivant la configuration du serveur, on peut utiliser iptables:

iptables -I INPUT -p tcp --dport 1022 -j ACCEPT

ou alors ufw:

ufw allow 1022

Étape 3: installation des sources de mises à jour

Normalement, ces paquets sont installés d’office mais cela ne coûte rien de vérifier qu’ils sont bien présents avant de lancer toute commande:

apt install update-manager-core ubuntu-release-upgrader-core

On vérifie dans le fichier /etc/update-manager/release-upgrades que la variable Prompt et bien égale à LTS pour n’installer que les versions Long Time Support:

cat /etc/update-manager/release-upgrades

...
Prompt=LTS

Étape 4: lancement de l’installation

Vous avez bien fait vos sauvegardes? C’est parti, on lance la procédure de mise à jour:

do-release-upgrade -d

Il y a plusieurs écrans d’avertissement concernant SSH:

[...]
Continue running under SSH? 

This session appears to be running under ssh. It is not recommended 
to perform a upgrade over ssh currently because in case of failure it 
is harder to recover. 

If you continue, an additional ssh daemon will be started at port 
'1022'. 
Do you want to continue? 

Continue [yN] Y

On a bien ouvert le port 1022 donc validez. Vous tombez sur un autre écran qui vous informe que certains services auront besoin d’être redémarrés. Choisissez Yes pour que les services soient redémarrés automatiquement, sans intervention de votre part.

L’installation a pris entre 30 et 40 minutes sur le serveur. A la fin, on nous demande de rebooter le serveur pour appliquer tous les changements (avec mise à jour majeure du kernel):

[...]
System upgrade is complete.
Restart required.

To finish the upgrade, a restart is required.

If you select 'y' the system will be restarted.

Continue [yN] Y

Et voilà, après redémarrage de la machine, tous nos services sont opérationnels.

Dernière étape: réactivation des sources de dépôts pour notre nouvelle version d’Ubuntu

La mise à jour désactive les sources de dépôts qui se trouvent dans le dossier /etc/apt/sources.list.d/. Il faut donc éditer les fichiers et, dans notre cas, remplacer bionic par focal.

Quelques copiés/collés plus tard, nous pouvons nous assurer que tout est vraiment à jour avec un ultime:

apt update && apt upgrade 

Vérification de la version du serveur:

lsb_release -a

Résultats:

No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04 LTS
Release:	20.04
Codename:	focal

Mise à jour réussie, en moins d’une heure.

C’est Noël avant l’heure : PHP version 7.4 est désormais disponible! Ni une ni deux, elle est déjà installée sur le serveur.

Je vous conseille de jeter un petit coup d’oeil aux nouveautés de PHP 7.4, cela se modernise!

Si vous souhaitez sauter le pas, voici un petit tuto pour l’installation.

Étape 1 : installer le dépôt d’Ondrej

Dans le terminal, installez le dépôt d’Ondrej. Il est très souvent mis à jour et permet de bénéficier de pas mal de paquets à jour, même sur des distributions anciennes:

add-apt-repository ppa:ondrej/php

Étape 2 : installation de PHP 7.4

J’ai juste repris la liste des paquets PHP7.3 déjà installés puis changé le numéro de version.

Cela nous donne donc:

apt install php-igbinary php-imagick php-redis php7.4 php7.4-bcmath php7.4-cli php7.4-common php7.4-curl php7.4-fpm php7.4-gd php7.4-imap php7.4-intl php7.4-json php7.4-mbstring php7.4-mysql php7.4-opcache php7.4-readline php7.4-soap php7.4-xml php7.4-zip

Note: il vous reste ensuite à modifier php.iniainsi que votre pool PHP selon vos besoins.

Étape 3: modification du server block

L’étape finale est la modification de votre server block. Sous NginX, éditez le fichier de configuration de votre site pour pointer vers le socket de PHP7.4:

#fastcgi_pass unix:/run/php/php7.3-fpm.sock;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;

Il suffit ensuite de relancer NginX et PHP:

service php7.4-fpm start && service nginx restart

Et voilà! Bonnes mises à jour !

Mettre à jour WC avec wp-cli

Il existe certaines situations dans lesquelles le plugin WooCommerce est mis à jour mais la mise à jour de la base de données du plugin échoue.

Cet échec de la mise à jour de la base de données est généralement causé par le délai d’attente de PHP, en particulier sur l’environnement d’hébergement partagé, puisque PHP ne dispose que de 60 secondes pour s’exécuter via une requête Web.

La non-concordance de version entre la version de la base de données WooCommerce et celle du plugin WooCommerce peut être à l’origine de problèmes.

Mise à jour de la base WooCommerce en ligne de commande

Pour résoudre ces problèmes, nous pouvons mettre à jour la base de données WooCommerce via la ligne de commande, en utilisant wp-cli.

1. Connectez-vous au serveur en SSH.

2. Naviguez jusqu’à la racine du site via SSH et exécutez la commande de mise à jour de WooCommerce:

wp wc update

Pour une grosse base de données, cela peut prendre un certain temps. Voici le résultat que vous devriez obtenir une fois le processus de mise à jour de la base de données terminé :

wp wc update
Calling update function: wc_update_350_db_version
Success: 2 updates complete. Database version is 3.5.0

3. Vérifiez dans WooCommerce > Status que la version de la base de données correspond bien à la version du plugin WooCommerce.

Sur un serveur qui héberge plusieurs sites WordPress différents, il est fort probable qu’il y ait quelques plugins en commun sur chaque installation.

WordPress permet de mettre à jour les thèmes et plugins en quelques clics mais cela suppose de s’identifier sur chaque site ou alors de donner permission à une application tierce comme JetPack pour vous faciliter la tâche.

WorddPress : éviter d'avoir à mettre le même plugin à jour sur chaque site hébergé sur le serveur photo

Cela suppose toutefois de bien vouloir rassembler toutes les autorisations sur un seul compte, ce qui n’est pas optimal puisqu’il n’y a plus cloisonnement entre les sites hébergés.

Nous allons donc mettre en place un système de liens symboliques (symlink ou symbolic link en anglais) pour gagner pas mal de temps lors des mises à jour.

Principe d’optimisation de la mise à jour des plugins récurrents

Sur le serveur, j’utilise une petite astuce tout simple : j’utilise mon site comme master officiel du serveur. C’est lui que je mets à jour en premier et tous les autres sites « hériteront » des nouvelles mises à jour, automatiquement et sans manipulation de ma part.

Mise en place de liens symboliques

Comme le serveur tourne sous Linux, il nous suffit de faire un lien symbolique sur le site slave vers le dossier d’un plugin qui se trouve sur le site master.

Lorsque je mettrai certains plugins de SkyMinds à jour par exemple, ces plugins qui sont également installés sur le site du Centre de Kriya Yoga France seront également à jour. En fait, aucun fichier de ce plugin ne sera présent chez eux, seul un lien symbolique.

Concrètement, voici la marche à suivre :

  1. On se place dans le répertoire /wp-content/plugins du site slave (kriyayoga.fr dans cet exemple):
    cd /kriyayoga/wp-content/plugins
  2. On crée un lien symbolique qui va pointer vers le répertoire qui se trouve dans le répertoire de SkyMinds :
    ln -s /skyminds/wp-content/plugins/my-plugin my-plugin
  3. Et voilà !

Aujourd’hui, le serveur passe à PHP 7.2 !

Serveur dédié : script bash pour réparer les tables MySQL en cas de crash photo

PHP 7.2 accroît fortement les performances des versions précédentes, notamment au travers de plusieurs améliorations en matière de sécurité. Ainsi, l’algorithme Argon2 qui sert au hachage sécurisé des mots de passe corrige les défauts des algorithmes actuels. Celui-ci permet notamment un taux de remplissage plus élevé de la mémoire.

PHP 7.2 intègre désormais dans son noyau la bibliothèque de cryptographie Sodium, utilisée pour le chiffrement authentifié, est désormais une extension de base et les performances de la bibliothèque pour la cryptographie sur les courbes elliptiques ont été améliorées.

Niveau programmation

Au-delà de Sodium, PHP 7.2 vient avec des améliorations et nouvelles fonctionnalités comme :

  • la possibilité de convertir des clés numériques dans les objets et tableaux lors de cast.
  • les clés numériques sont maintenant mieux appréhendées lors de cast d’un tableau en objet et d’objet en tableau (cast explicite ou par la fonction settype()) ;
  • le comptage d’objets non dénombrables. Un E_WARNING sera émis lors de la tentative d’utilisation de la fonction count() sur un type non dénombrable ;
  • HashContext en tant qu’objet ;
  • ajout d’Argon2 à l’API pour le hachage de mot de passe ;
  • amélioration des constantes TLS ;
  • la suppression de l’extension Mcrypt. L’extension MCrypt a maintenant été déplacée du noyau vers PECL. Étant donné que la bibliothèque mcrypt n’a pas eu de mises à jour depuis 2007, son utilisation est fortement découragée. Au lieu de cette extension, soit OpenSSL ou l’extension sodium doit être utilisé.

Les fonctions Deprecated (déconseillées) et supprimées pour PHP 8.0:

__autoload
$php_errormsg
create_function()
mbstring.func_overload
(unset) cast
parse_str() sans le second argument
gmp_random()
each()
assert() avec un argument string(texte)
$errcontext

La conversion des clés numériques dans les distributions objet/tableau résout un problème rencontré avec le moteur open source Zend Engine qui fait tourner PHP 7. Dans certaines situations, les tables de hachage de tableaux pouvaient contenir des chaînes numériques alors que les tables de hachage d’objets pouvaient contenir des clés entières, ce qui empêchait le code PHP de retrouver les clés. Le correctif apporté par PHP 7.2 convertit les clés des tables de hashage des tableaux et des tables de hachage des objets sont converties dans les bons formats, de sorte que les chaînes de format numériques personnalisées sont traduites en clefs entières, résolvant le problème d’inaccessibilité.

Les typages explicites d’objets ou « type hints » corrigent une situation dans laquelle un développeur ne peut pas déclarer une fonction supposée recevoir un objet en tant que paramètre ou déclarer qu’une fonction doit retourner un objet. Le correctif utilise l’objet comme type de paramètre et type de retour. HashContext en tant qu’objet, migre l’extension de hachage pour utiliser une extension objet pour les contextes de hachage au lieu d’utiliser des ressources. A noter aussi une nouvelle alerte ajoutée pour l’appel de la fonction count avec un paramètre scalaire ou nul, ou un objet qui n’implémente pas l’interface « Countable »

Mise à jour vers PHP7.2

Cela n’a pris que quelques minutes :

apt update && apt upgrade

Résultat :

Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  php7.1-cli php7.1-curl php7.1-fpm php7.1-gd php7.1-json php7.1-mbstring php7.1-opcache
  php7.1-readline php7.1-xml php7.1-xmlrpc
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
  libargon2-0 libsodium23 php7.2-cli php7.2-common php7.2-curl php7.2-fpm php7.2-gd php7.2-json
  php7.2-mbstring php7.2-opcache php7.2-readline php7.2-xml php7.2-xmlrpc
The following packages will be upgraded:
  php-common php-curl php-fpm php-gd php-mbstring php-xml php-xmlrpc php7.1-cli php7.1-common
  php7.1-curl php7.1-fpm php7.1-gd php7.1-json php7.1-mbstring php7.1-mcrypt php7.1-mysql
  php7.1-opcache php7.1-readline php7.1-soap php7.1-xml php7.1-xmlrpc php7.1-zip
22 upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
Need to get 8,656 kB of archives.
After this operation, 19.7 MB of additional disk space will be used.

A ce stade, nous avons php7.1 et php7.2 installés séparément sur le serveur.

On installe les paquets manquants (toujours les deux mêmes):

apt install php7.2-mysql

On édite chacun des VirtualHosts sous Nginx, en éditant cette ligne:

fastcgi_pass unix:/run/php/php7.2-fpm.sock;

On relance NginX et PHP:

service php7.2-fpm restart && service nginx restart

Si tout va bien, il suffit de supprimer PHP7.1, ses dépendances et ses fichiers de configuration:

apt purge php7.1-*

Test de votre code sous PHP 7.2

Vous hésitez encore à sauter le pas ? Copiez-collez votre code sur le site d’3v4l, vous saurez immédiatement si cela produit des erreurs de type Notice.

Bonne mise à jour !

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur « fatal: www-data(33): message file too big »
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. J’ai planté le serveur… ou comment récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : ajout de mod_spdy pour accélérer la connexion TLS-SSL sous Apache
  43. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  44. Serveur dédié : activer l’IP canonique du serveur sous Apache
  45. Serveur dédié : mise à jour vers PHP 5.6
  46. MySQL : convertir les tables MyISAM au format InnoDB
  47. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  48. Serveur dédié : migration de MySQL vers MariaDB
  49. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  50. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  51. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  52. Serveur dédié : mise en place du protocole DANE
  53. 8 règles d’or pour bien déployer DNSSEC et DANE
  54. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  55. Serveur dédié : réduire les connexions TIME_WAIT des sockets et optimiser TCP
  56. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  57. Serveur dédié : mettre à jour Apache et configurer le mod_http2 pour HTTP/2
  58. Serveur dédié : ajouter le domaine à la liste HSTS preload
  59. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  60. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème « no space left on device »
  61. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian

Cette semaine, le système d’exploitation du serveur principal passe de Debian 8 Jessie à Debian 9 Stretch.

Serveur dédié : mise à jour vers Debian 9 Stretch photo

Mise à jour des paquets du système

La mise à jour s’est faite plutôt simplement pour la majeure partie des paquets :

apt update && apt upgrade

mais il a fallu s’y reprendre à plusieurs fois pour les paquets restants :

apt install 

Changements dans la configuration

Quelques changements notables sont à noter.

Configuration apt

On vérifie que tous nos dépôts pointent bien vers la version Stretch:

nano /etc/apt/sources.list

On sauvegarde et on lance les mises à jour:

apt update && apt upgrade

Configuration SSH

La configuration SSH a été modifiée et certaines directives ne sont plus valables. Avant de redémarrer le serveur SSH ou de rebooter et de perdre tout accès au serveur SSH, assurez-vous que la configuration est correcte :

sshd -t

Résultats :

/etc/ssh/sshd_config line 25: Deprecated option KeyRegenerationInterval
/etc/ssh/sshd_config line 26: Deprecated option ServerKeyBits
/etc/ssh/sshd_config line 44: Deprecated option RhostsRSAAuthentication

Il ne vous reste plus qu’à éditer le fichier de configuration SSH:

nano /etc/ssh/sshd_config

J’ai désactivé les lignes qui posaient problème et ai rajouté de nouveaux protocoles de clé :

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Sauvegardez le fichier puis lancez cette commande pour créer les couples de clés privées/publiques dans /etc/ssl:

ssh-keygen -A

Résultat:

ssh-keygen: generating new host keys: ECDSA ED25519

Vérifiez une dernière fois qu’il n’y a aucun problème avec le fichier de configuration SSH:

sshd -t

et redémarrez le service SSH:

service ssh restart

Configuration de Courier

C’est le bon moment de revoir la configuration IMAP et POP de Courier.

On commence par renouveler notre fichier Diffie-Hellman en 4096 bits:

cd /etc/courier
openssl dhparam -out dhparams4096.pem 4096

et on revoit la configuration de /etc/courier/imap-ssl :

SSLPORT=993

SSLADDRESS=0

SSLPIDFILE=/run/courier/imapd-ssl.pid

SSLLOGGEROPTS="-name=imapd-ssl"

IMAPDSSLSTART=YES

IMAPDSTARTTLS=YES

IMAP_TLS_REQUIRED=1

COURIERTLS=/usr/bin/couriertls

TLS_PROTOCOL=TLS1_2:TLS1_1:TLS1

TLS_STARTTLS_PROTOCOL=TLS1_2:TLS1_1:TLS1

TLS_CIPHER_LIST="ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS"

TLS_KX_LIST=ALL

TLS_COMPRESSION=ALL

TLS_CERTS=X509

TLS_DHCERTFILE=/etc/courier/dhparams4096.pem

TLS_CERTFILE=/etc/courier/skyminds-cert.pem

TLS_TRUSTCERTS=/etc/ssl/certs

TLS_VERIFYPEER=NONE

TLS_CACHEFILE=/var/lib/courier/couriersslcache
TLS_CACHESIZE=524288

MAILDIRPATH=Maildir

Le chemin de SSLPIDFILE a changé donc pensez à le vérifier.

Certificat TLS pour Courier

Depuis que j’utilise les certificats TLS de Let’s Encrypt, il y a une petite modification a exécuter pour que le certificat s’applique aussi à notre serveur de mail : créer automatiquement un certificat pour Courier dès que notre certificat principal est généré.

On crée un script bash pour compiler notre clé privée et notre certificat Let’s Encrypt :

nano /home/scripts/letsencrypt-skyminds-mailserver.sh

avec :

#!/bin/bash
cat /etc/letsencrypt/live/skyminds.net/privkey.pem /etc/letsencrypt/live/skyminds.net/fullchain.pem > /etc/courier/skyminds-cert.pem

et on édite notre fichier Let’s Encrypt pour le renouvellement :

nano /etc/letsencrypt/renewal/skyminds.net.conf

et on ajoute la directive renew_hook avec notre nouveau script:

[renewalparams]
account = ...
renew_hook = /home/scripts/letsencrypt-skyminds-mailserver.sh

Il ne reste plus qu’à éditer la configuration IMAP:

nano /etc/courier/imapd-ssl

et y mettre :

TLS_CERTFILE=/etc/courier/skyminds-cert.pem

puis redémarrez le service:

service courier-imap-ssl restart

Voilà, il me semble que ce sont les principales modifications que j’ai effectué lors de la mise à jour vers Debian 9.

Aujourd’hui, ma machine desktop – The Reaper – vient d’avoir une jolie petite mise à jour et passe d’Ubuntu 14.04 à 16.04, codename Xenial Xerus.

The Reaper : mise à jour vers Ubuntu 16.04 Xenial Xerus photo

Mise à jour d’Ubuntu

La mise à jour se fait assez simplement :

sudo apt update && sudo apt upgrade
sudo apt autoremove
sudo apt dist-upgrade

Comme je n’installe que des versions LTS (Long-Time Support) sur cette machine, il y avait plus de 2.3 Go de paquets à télécharger soit un sacré paquet de mises à jour.

Plusieurs erreurs sont apparues pendant l’installation, qui a laissé à peu près une trentaine de paquets non configurés et non des moindres : GRUB, initramfs-tools etc.

En regardant les messages d’erreurs, j’ai vu que le problème se situait au niveau de DPKG.

Lorsqu’un paquet obsolète bloque DPKG

Si cela vous arrive, pas de panique. Il faut juste régler le problème *avant* de redémarrer la machine.

On commence par relancer la configuration des paquets non configurés:

dpkg --configure -a

En résultat, vous obtenez une (très) longue liste de tous les paquets non configurés avec tous les messages d’erreurs associés. Ce qui importe, ce sont les premières lignes du résultat : le paquet qui bloque est toujours mentionné en premier.

Dans mon cas, il s’agissait d’un paquet obsolète depuis Ubuntu 12.04 (donc depuis 4 ans), virtuoso-nepomuk. Je l’ai donc totalement supprimé :

sudo apt purge virtuoso-nepomuk

On relance ensuite la configuration des paquets :

dpkg --configure -a

Puis une petite vérification des nouveaux paquets au cas où et la suppression des paquets obsolètes :

sudo apt update && sudo apt upgrade && sudo apt autoremove

Un reboot plus tard, Ubuntu 16.04 boote tranquillement. Je conseille de régler le problème des paquets non configurés avant le reboot, c’est bien plus galère autrement.

Réactiver les dépôts désactivés pendant la mise à niveau

Enfin, il reste à réactiver les dépôts APT qui ont été désactivés pendant la mise à niveau.

Pas de clé publique disponible pour vérifier l’authenticité des dépôts

[no_toc]

Linux : résoudre l'erreur APT "there is no public key available for the following key IDs" photo

Au lancement de la mise à jour des paquets du serveur, je suis tombé sur le message d’erreur suivant :

W: There is no public key available for the following key IDs:
8B48AD6246925553
W: There is no public key available for the following key IDs:
8B48AD6246925553
W: There is no public key available for the following key IDs:
8B48AD6246925553

Visiblement, APT a perdu ses petits et ne retrouve plus la clé publique GPG d’un des mes dépôts (webmin en l’occurence).

Voici comment remédier au problème.

Solution : demander et ajouter la clé au trousseau GPG

Un peu de ménage dans APT

On commence par faire un peu de ménage dans les fichiers APT avec un petit coup de balai:

apt-get clean

… avant de récréer le dossier lists/partial pour véritablement recréer le cache APT :

cd /var/lib/apt
mv lists lists.old
mkdir -p lists/partial
apt-get clean && apt-get autoremove && apt update

Import de la clé publique

Maintenant, il nous reste à importer la clé publique manquante dans notre trousseau.

On se place dans le dossier root pour travailler:

cd /root

On demande la clé publique:

gpg --recv-keys 8B48AD6246925553

On l’exporte et on l’ajoute à notre trousseau :

gpg --export 8B48AD6246925553 | apt-key add -

On peut alors relancer la mise à jour des paquets :

apt-get clean && apt-get autoremove
apt update && apt upgrade

Script bash pour automatiser la mise à jour des clés APT

Soyons plus fous, nous allons automatiser les deux commandes avec un petit script BASH. On crée notre script :

nano /home/scripts/renew-apt-key

et on y ajoute:

#!/bin/bash
# Author : Matt Biscay
# Author URI : https://www.skyminds.net/?p=8735
gpg --keyserver keyserver.ubuntu.com --recv-keys $1
gpg --armor --export $1 | sudo apt-key add -

On enregistre le fichier et on le rend executable :

chmod +x renew-apt-key

Il ne vous reste plus qu’à renouveler votre clé APT avec:

sudo ./renew-apt-key NUMERO-DE-CLE

Et voilà, plus d’erreur lors des mises à jour APT.

Aujourd’hui, on passe de PHP5 à PHP7 en moins de 20 minutes montre en main sur notre serveur dédié qui tourne sous la version stable de Debian.

Serveur dédié : installer PHP7 FPM avec FastCGI photo

Pré-requis : les dépôts Dotdeb

Avant toute chose, vous devez avoir les dépôts Dotdeb installés dans votre apt.

On édite donc la liste des dépôts:

nano /etc/apt/sources.list

puis on y ajoute :

# Dotdeb stable
deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

On installe la clé GPG de Dotdeb:

wget https://www.dotdeb.org/dotdeb.gpg
sudo apt-key add dotdeb.gpg

et on met notre liste de paquet à jour :

apt-get update && apt-get upgrade

Lorsque vous avez complété cette étape, vous êtes prêt à lancer la mise à jour de PHP.

Installation de PHP7

Je découpe volontairement cette installation en plusieurs sous-étapes, par souci de clarté.

Suppression des paquets PHP5

On commence par supprimer tous les paquets relatifs à PHP5 sur le serveur:

apt-get purge php5-*

Résultat:

The following packages will be REMOVED:
libapache2-mod-php5* php-pear* php5* php5-apc* php5-cli* php5-common* php5-curl* php5-dev* php5-fpm* php5-gd* php5-json* php5-mcrypt* php5-mysql* php5-mysqlnd* php5-pecl-http* php5-propro* php5-raphf* php5-ssh2*

On garde cette liste sous le coude en cas de problème.

Installation des paquets PHP7

On installe les paquets PHP7 qui nous sont nécessaires:

apt-get install php7.0 php7.0-fpm php7.0-gd php7.0-mysql php7.0-cli php7.0-common php7.0-curl php7.0-opcache php7.0-json

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur « fatal: www-data(33): message file too big »
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. J’ai planté le serveur… ou comment récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : ajout de mod_spdy pour accélérer la connexion TLS-SSL sous Apache
  43. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  44. Serveur dédié : activer l’IP canonique du serveur sous Apache
  45. Serveur dédié : mise à jour vers PHP 5.6
  46. MySQL : convertir les tables MyISAM au format InnoDB
  47. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  48. Serveur dédié : migration de MySQL vers MariaDB
  49. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  50. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  51. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  52. Serveur dédié : mise en place du protocole DANE
  53. 8 règles d’or pour bien déployer DNSSEC et DANE
  54. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  55. Serveur dédié : réduire les connexions TIME_WAIT des sockets et optimiser TCP
  56. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  57. Serveur dédié : mettre à jour Apache et configurer le mod_http2 pour HTTP/2
  58. Serveur dédié : ajouter le domaine à la liste HSTS preload
  59. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  60. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème « no space left on device »
  61. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian
wordpress-svn-logo

De temps en temps, je mets mes plugins WordPress sur le dépôt officiel mais j’utilise assez rarement subversion – connu également sous le doux nom svn – et j’ai tendance à en oublier la syntaxe.

Voici donc un petit aide-mémoire pour l’utilisation de subversion avec les plugins WordPress.

Ajouter un plugin sur le dépôt officiel WordPress

1. On crée un répertoire local sur notre machine pour y accueillir notre projet:

mkdir my-local-dir

2. On synchronise le dépôt avec un check-out en donnant le slug du plugin:

svn co https://plugins.svn.wordpress.org/your-plugin-name my-local-dir

Résultat:

> A	my-local-dir/trunk
> A	my-local-dir/branches
> A	my-local-dir/tags
> Checked out revision 1135625.

Subversion vient d’ajouter ( « A » signifie « add » ) tous les répertoires du dépôt central à notre copie locale.

3. On copie tous les fichiers du plugin dans le répertoire trunk/:

cd my-local-dir/
my-local-dir/$ cp ~/my-plugin.php trunk/my-plugin.php
my-local-dir/$ cp ~/readme.txt trunk/readme.txt

4. On prépare l’ajout des fichiers du plugin au dépôt central:

my-local-dir/$ svn add trunk/* assets/*
> A	trunk/my-plugin.php
> A	trunk/readme.txt

5. On donne un message à notre check-in et on envoie les fichiers au dépôt central :

my-local-dir/$ svn ci -m 'Adding first version of my plugin'
> Adding	trunk/my-plugin.php
> Adding	trunk/readme.txt
> Transmitting file data .
> Committed revision 1135626.

Voilà, vous venez d’ajouter votre plugin au dépôt officiel de WordPress !

Supprimer un fichier sur le dépôt

Pour supprimer un fichier sur le dépôt, il faut supprimer le fichier avec svn delete puis commettre les changements avec svn commit. C’est lors du commit que le fichier est supprimé du dépôt :

svn delete myfile
> D         myfile

svn commit -m "Deleted file 'myfile'."
> Deleting       myfile
> Transmitting file data .
> Committed revision 1135629.

Hier soir, j’ai mis à jour le serveur : nous passons de Debian 7.8 (wheezy) à 8.0 (jessie).

Tout s’est plutôt bien passé, il y a eu environ 10 minutes de downtime, le temps que je comprenne ce qui avait changé, notamment dans la configuration Apache et celle de Postfix.

Voici un petit compte-rendu de la mise à jour.

debian-8-jessie

Mise à jour des dépôts

On édite notre fichier source APT :

nano /etc/apt/sources.list

et on remplace toutes les occurences de wheezy par jessie.

Chez moi, cela donne :

# DEBIAN
deb http://mirror.ovh.net/debian/ stable main contrib non-free
deb-src http://mirror.ovh.net/debian/ stable main contrib non-free

deb http://security.debian.org/ stable/updates main contrib non-free
deb-src http://security.debian.org/ stable/updates main contrib non-free

# mod security
deb http://ftp.debian.org/debian/ jessie-backports main

Préparation à la mise à jour de Debian

J’ai commencé par vérifier qu’aucun paquet n’était à moitié installé :

dpkg --audit

ou en attente :

dpkg --get-selections | grep 'hold$'

Rien? Tout va bien, on continue et on simule une installation avec :

apt-get -o APT::Get::Trivial-Only=true dist-upgrade

Le résultat est une longue liste de paquets, suivie du message suivant:

439 upgraded, 192 newly installed, 5 to remove and 1 not upgraded.
Need to get 275 MB of archives.
After this operation, 259 MB of additional disk space will be used.
E: Trivial Only specified but this is not a trivial operation.

Nos sauvegardes sont faites, on se lance.

Mise à jour Debian

On rafraichit les dépôts et on lance l’installation:

apt-get update && apt-get upgrade

On obtient un laïus avec ce qui change. J’aperçois plusieurs pages sur Apache, on y reviendra. Cela dure à peu près une dizaine de minutes, bien que je n’ai pas vraiment minuté.

Une fois l’installation terminée, on résout les dépendances et les paquets manquants avec :

apt-get dist-upgrade

Je lance le site pour voir : paf, erreur 403.

php-logoJe viens de mettre à jour la version de PHP sur le serveur, histoire de tourner sur une version plus récente et bénéficiant des dernières nouveautés.

En moins de 3 minutes, je suis passé de PHP 5.4.39 à PHP 5.6.7 sur ma Debian, tout en douceur.

Voici la marche à suivre.

Ajout des dépôts Dotdeb

Si vous ne l’avez déjà fait, ajoutez les dépôts Dotdeb de Guillaume Plessis:

nano /etc/apt/sources.list

et ajoutez-y:

# Dotdeb default
deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all
# PHP 5.6 on Debian 7 (without Zend thread safety)
deb http://packages.dotdeb.org wheezy-php56 all
deb-src http://packages.dotdeb.org wheezy-php56 all

Mise à jour de PHP

On met à jour nos dépôts :

apt-get update

et on met à jour notre version de PHP-FPM avec:

apt-get install php5-fpm php5-ssh2 php-pear php5 php5-dev

Résultat :

The following packages will be REMOVED:
  libssh2-php
The following NEW packages will be installed:
  libvpx1 php5-ssh2
The following packages will be upgraded:
  php5-cli php5-common php5-curl php5-fpm php5-gd php5-mcrypt php5-mysqlnd php-pear php5 php5-dev

Cela met à jour les paquets PHP qui dépendent de la nouvelle version.

Bientôt PHP7!

Au passage, l’installation demande quoi faire avec les fichiers de configuration : j’ai choisi de garder les miens, pour ne pas avoir à tout reconfigurer.

Je pense que je partirai sur une configuration de base lorsque l’on passera à PHP7, qui devrait enfin faire décoller les performances et dont la sortie est prévue le 15 novembre 2015.

Il ne reste plus qu’à redémarrer Apache et PHP :

service apache2 restart && service php5-fpm restart

Et voilà! Une mise à jour toute en douceur et sans accrocs.

Sommaire de la série Monter un serveur dédié de A à Z

  1. Serveur dédié : installation d’Apache, PHP, MySQL et Webmin
  2. Serveur dédié : créer la base de données MySQL et importer WordPress
  3. Serveur dédié : créer et activer un Virtual Host sous Apache
  4. Serveur dédié : changer les DNS du nom de domaine et le faire pointer vers le serveur
  5. Serveur dédié : sécurisation des services avec iptables et fail2ban
  6. Serveur dédié : sécurisation de la couche TCP/IP
  7. Serveur dédié : création d’un serveur mail Postfix (sécurisé avec Saslauthd et certificat SSL) et Courier (accès POP et IMAP) utilisant une base MySQL d’utilisateurs/domaines virtuels
  8. Serveur dédié : sécuriser Apache 2 avec ModSecurity
  9. Serveur dédié : CHMOD récursif sur des fichiers ou répertoires en ligne de commande
  10. Serveur dédié : installer APC comme système de cache et configurer Varnish comme reverse-proxy pour Apache pour améliorer les performances
  11. Serveur dédié : afficher la véritable IP derrière un reverse-proxy comme Varnish
  12. Serveur dédié : intégrer SSH à WordPress pour mettre à jour le core, les plugins et les thèmes
  13. Serveur dédié : installer la dernière version d’APC par SVN
  14. Serveur dédié : analyse des performances du serveur
  15. Serveur dédié : mettre à jour le noyau Debian de la Kimsufi
  16. Serveur dédié : sauvegarde automatique des fichiers avec Backup Manager sur le serveur de sauvegarde OVH
  17. Serveur dédié : configurer la limite mémoire pour PHP et Suhosin
  18. Bash : supprimer tous les fichiers et sous-répertoires d’un répertoire
  19. Serveur dédié : impossible de se connecter à un port distant
  20. Rsync: rapatrier les fichiers du serveur à la maison
  21. Bash : réparer les tables MySQL en cas de crash
  22. Serveur dédié : création d’une seedbox avec Transmission
  23. Serveur dédié : des paquets LAMP à jour sous Debian
  24. Serveur dédié : mise à jour vers Debian 7 Wheezy
  25. Serveur dédié : activer X11 forwarding pour SSH
  26. Serveur dédié : optimiser toutes les images JPG et PNG avec OptiPNG et JpegOptim
  27. Postfix : résoudre l’erreur « fatal: www-data(33): message file too big »
  28. Serveur dédié : mise en place de l’IPv6
  29. WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod
  30. WordPress : héberger les images sur un sous-domaine
  31. Serveur dédié : ajouter l’authentification SPF, Sender-ID et DKIM à Postfix et Bind9 avec opendkim
  32. Apache : lorsque le domaine seul (sans WWW) renvoie une erreur 403
  33. Serveur dédié : sécuriser Apache avec HTTPS (HTTP avec la couche TLS/SSL) en Perfect Forward Secrecy
  34. Serveur dédié : passer WordPress en HTTPS (TLS/SSL)
  35. Serveur dédié : configurer Webmin en TLS avec un certificat SSL
  36. Serveur dédié : configurer Transmission pour accéder au WebUI via TLS-SSL
  37. Serveur dédié : installer et configurer Varnish 4
  38. Serveur dédié : passage au mod FastCGI et PHP-FPM avec Apache MPM Worker
  39. J’ai planté le serveur… ou comment récupérer un serveur Kimsufi après un plantage de kernel avec le mode rescue OVH
  40. Serveur dédié : configurer Postfix et Courier pour utiliser TLS-SSL en Perfect Forward Secrecy
  41. Serveur dédié : retirer Varnish, devenu inutile avec HTTPS
  42. Serveur dédié : ajout de mod_spdy pour accélérer la connexion TLS-SSL sous Apache
  43. Serveur dédié : installer la dernière version d’OpenSSL sous Debian
  44. Serveur dédié : activer l’IP canonique du serveur sous Apache
  45. Serveur dédié : mise à jour vers PHP 5.6
  46. MySQL : convertir les tables MyISAM au format InnoDB
  47. Serveur dédié : optimiser toutes les images GIF avec GIFsicle
  48. Serveur dédié : migration de MySQL vers MariaDB
  49. BASH : lister, bloquer et débloquer des adresses IP avec iptables
  50. Serveur dédié : produire une meilleure réserve d’entropie avec haveged
  51. Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine
  52. Serveur dédié : mise en place du protocole DANE
  53. 8 règles d’or pour bien déployer DNSSEC et DANE
  54. Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian
  55. Serveur dédié : réduire les connexions TIME_WAIT des sockets et optimiser TCP
  56. Fail2Ban: protéger Postfix contre les attaques DoS de types AUTH, UNKNOWN et EHLO
  57. Serveur dédié : mettre à jour Apache et configurer le mod_http2 pour HTTP/2
  58. Serveur dédié : ajouter le domaine à la liste HSTS preload
  59. Serveur dédié : ajouter l’authentification DMARC à Postfix et BIND
  60. Serveur dédié : à la recherche de l’inode perdue ou comment résoudre le problème « no space left on device »
  61. Serveur dédié : installer NginX avec support HTTP2 et certificat SSL, PHP, MariaDB sous Debian

Rapport de faute d’orthographe

Le texte suivant sera envoyé à nos rédacteurs :