SkyMinds ~ by Matt - sysadmin, WordPress engineer, formateur

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.

Web/Tech

Solution pour l’erreur cURL error 7: Failed to connect to XXX port 443: Connection refused

Par Matt 23 juin 2020

Sur un serveur hébergé en Chine continentale, j’ai eu la surprise de ne pas être en mesure de mettre à jour wp-cli:

wp cli update

Error: Failed to get url 'https://api.github.com/repos/wp-cli/wp-cli/releases?per_page=100': cURL error 7: Failed to connect to api.github.com port 443: Connection refused.

Visiblement, certaines adresses sont injoignables, notamment lorsqu’elles utilisent le port 443 (https).

Evidemment, on peut télécharger wp-cli manuellement et le réinstaller mais si vous souhaitez une solution plus rapide, voilà comment j’ai procédé.

Première solution: édition de `/etc/hosts`

1. On récupère l’adresse IP de l’adresse api.github.com:

curl --ipv4 -v https://api.github.com

Résultat: 13.250.94.254 port 443

2. On édite le fichier /etc/hosts du serveur:

nano /etc/hosts

3. On y ajoute l’adresse IP correspondante à api.github.com:

13.250.94.254 api.github.com

Et voilà, le téléchargement depuis github est de nouveau accessible.

Deuxième solution: utiliser le drapeau –ipv4

S’il s’agit d’un téléchargement simple, par exemple pour installer wp-clipour la première fois, il suffit d’indiquer le drapeau --ipv4 dans votre commande curl:

curl --ipv4 -v -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

chmod +x wp-cli.phar
mv wp-cli.phar /usr/local/bin/wp

Troisième solution: configurer curl avec –ipv4

Histoire de ne pas avoir à éditer le fichier /etc/host pour chaque site distant, autant configurer curl pour utiliser IPv4 par défaut:

echo '--ipv4' >> ~/.curlrc

Notons que la configuration de ce VPS est très particulière, je n’ai jamais eu à faire ce genre de manipulation sur les autres serveurs dont je m’occupe. C’est très probablement dû au fait qu’il ne doit pas avoir IPv6 configuré. Au passage, le filtrage du Great Firewall of China rend également chaque opération/commande assez délicate.

Web/Tech

PHP: résoudre l’erreur « file_get_contents(): SSL operation failed with code 1 »

Par Matt 31 mai 2020

J’ai récemment joué avec l’API de YouTube pour pouvoir récupérer diverses informations sur les vidéos afin d’ajouter au site les données structurées idoines.

Il se trouve qu’en local, lorsque l’on utilise file_get_contents(), on peut obtenir une erreur de ce type lorsque le serveur n’est pas configuré avec le bundle de certificats OpenSSL:

Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in ...php on line 2

Warning: file_get_contents(): Failed to enable crypto in ...php on line 2

Warning: file_get_contents(https://........f=json): failed to open stream: operation failed in ...php on line 2

Si cela vous arrive, plusieurs solutions s’offrent à vous.

Méthode 1: configuration de PHP côté machine/serveur

1. Vérifiez qu’OpenSSL est bien installé sur votre machine (il devrait l’être sur le serveur!).

2. Ajoutez cette ligne à la configuration de PHP, dans votre php.ini:

openssl.cafile=/usr/local/etc/openssl/cert.pem

3. Redémarrez le service PHP.

Méthode 2 : une fonction qui utilise curl au lieu de file_get_contents()

Au lieu de m’embêter à configurer OpenSSL ou à toucher à PHP dans un conteneur docker (Local), il se trouve que l’on peut réécrire la fonction file_get_contents() avec une fonction maison qui utilise curl.

Voici la fonction en question:

/*
Custom CURL function that mimicks file_get_contents()
@returns false if no content is fetched
Matt Biscay (https://mattbiscay.com)
*/
function sky_curl_get_file_contents( $URL ){
	$c = curl_init();
	curl_setopt( $c, CURLOPT_RETURNTRANSFER, 1 );
	curl_setopt( $c, CURLOPT_URL, $URL );
	$contents = curl_exec( $c );
	curl_close( $c );
	if( $contents ) :
		return $contents;
	else:
		return false;
	endif;
}

La fonction retourne false si la requête échoue, ce qui est très utile pour éviter de faire des appels à des valeurs d’un tableau qui n’existe pas. On peut alors réfléchir à un autre moyen de peupler les champs de données structurées (mais c’est un sujet à aborder une autre fois).

Mise à jour du serveur vers Ubuntu Focal Fossa (20.04 LTS)

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

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

Étape 3: installation des sources de mises à jour

Étape 4: lancement de l’installation

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

Solution pour l’erreur cURL error 7: Failed to connect to XXX port 443: Connection refused

Première solution: édition de `/etc/hosts`

Deuxième solution: utiliser le drapeau –ipv4

Troisième solution: configurer curl avec –ipv4

PHP: résoudre l’erreur « file_get_contents(): SSL operation failed with code 1 »

Méthode 1: configuration de PHP côté machine/serveur

Méthode 2 : une fonction qui utilise curl au lieu de file_get_contents()

Rapport de faute d’orthographe

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

Votre commentaire (facultatif):

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

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

Étape 3: installation des sources de mises à jour

Étape 4: lancement de l’installation

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

Première solution: édition de /etc/hosts

Deuxième solution: utiliser le drapeau –ipv4

Troisième solution: configurer curl avec –ipv4

Méthode 1: configuration de PHP côté machine/serveur

Méthode 2 : une fonction qui utilise curl au lieu de file_get_contents()

Rapport de faute d’orthographe

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

Votre commentaire (facultatif):

Première solution: édition de `/etc/hosts`