Serveur dédié: passage à PHP 7.4 photo

Serveur dédié: passage à PHP 7.4

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-zipCode language: CSS (css)

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;Code language: PHP (php)

Il suffit ensuite de relancer NginX et PHP:

service php7.4-fpm start && service nginx restartCode language: CSS (css)

Et voilà! Bonnes mises à jour !

Obtenir le statut de toutes les jails fail2ban photo

Obtenir le statut de toutes les jails fail2ban

fail2ban jails 1280x853

Si vous utilisez fail2ban sur votre serveur dédié – et vous devriez! – il peut être vraiment utile de lister les statuts de toutes les jails fail2ban.

Cela permet de voir quelles sont les jails actives et de vérifier qu’il n’y a aucun problème de configuration.

On peut obtenir le statuts de toutes les jails fail2ban avec la commande suivante:

fail2ban-client status | sed -n 's/,//g;s/.*Jail list://p' | xargs -n1 fail2ban-client statusCode language: JavaScript (javascript)

Voici un exemple de résultat de la commande:

Status for the jail: pam-generic
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- File list:	/var/log/auth.log
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:
Status for the jail: postfix
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	4482
|  `- File list:	/var/log/mail.log
`- Actions
   |- Currently banned:	0
   |- Total banned:	223
   `- Banned IP list:
Status for the jail: sasl
|- Filter
|  |- Currently failed:	4
|  |- Total failed:	14126
|  `- File list:	/var/log/mail.log
`- Actions
   |- Currently banned:	4
   |- Total banned:	1927
   `- Banned IP list:	45.148.10.70 46.38.144.17 46.38.144.202 46.38.144.32
Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- File list:	/var/log/auth.log
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:Code language: PHP (php)

A garder dans sa trousse à outils!

MySQL: résoudre l'erreur

MySQL: résoudre l’erreur “Incorrect datetime value” lors d’opérations sur les tables

mysql logo compressor 1280x662

Depuis le passage du site sur le nouveau serveur, ORION, j’utilise MySQL 8 en lieu et place de MariaDB, histoire de tester les les gains de performance.

Or, avec la nouvelle configuration de MySQL par défaut, vous pouvez obtenir cette erreur lors de simples opération de maintenance comme l’optimisation des tables:

example.wp_comments: Table does not support optimize, doing recreate + analyze instead
example.wp_comments: Invalid default value for 'comment_date'
example.wp_comments: Operation failed
example.wp_et_social_stats: Incorrect datetime value: '0000-00-00 00:00:00' for column 'comment_date' at row 1
example.wp_et_social_stats: Invalid default value for 'comment_date'
example.wp_et_social_stats: Table does not support optimize, doing recreate + analyze instead
example.wp_et_social_stats: Invalid default value for 'sharing_date'
example.wp_et_social_stats: Operation failedCode language: JavaScript (javascript)

Cela est dû à un changement de configuration, notamment dans la directive sql_mode depuis MySQL 5.7.

Voyons-donc ce que contient la directive par défaut. Identifiez-vous sur le serveur MySQL:

mysql -u root -p

Puis vérifiez le contenu de la variable de configuration sql_mode:

show variables like 'sql_mode';Code language: JavaScript (javascript)

Résultat:

+---------------+-----------------------------------------------------------------------------------------------------------------------+
| Variable_name | Value                                                                                                                 |
+---------------+-----------------------------------------------------------------------------------------------------------------------+
| sql_mode      | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+---------------+-----------------------------------------------------------------------------------------------------------------------+
1 row in set (0.02 sec)Code language: JavaScript (javascript)

Ce qui pose problème, ce sont ces deux directives: NO_ZERO_IN_DATE et NO_ZERO_DATE.

Deux solutions s’offrent à nous : éditer la valeur directement depuis la console mysql ou alors depuis le fichier de configuration my.cnf.

Méthode 1 : éditer la valeur de sql_mode depuis la console MySQL

Si vous vous trouvez toujours dans la console mysql, vous pouvez lancer la reqête suivante, qui enlève les drapeaux NO_ZERO_IN_DATE et NO_ZERO_DATE à notre directive sql_mode:

SET sql_mode = 'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';Code language: JavaScript (javascript)

Relancez ensuite le serveur:

service mysql restart

Méthode 2 : éditer la valeur de sql_mode depuis le fichier de configuration MySQL (my.cnf)

Nous allons donc éditer notre fichier de configuration MySQL:

nano /etc/mysql/mysql.conf.d/mysqld.cnf

Et ajouter (ou modifier) la variable de configuration sql_mode en l’amputant des valeurs NO_ZERO_IN_DATE et NO_ZERO_DATE:

sql_mode=ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

Enregistrez le fichier puis redémarrez le serveur mysql:

service mysql restart

Vous pouvez désormais lancer des requêtes de maintenance ou de modification de la structure des tables de la base de données sans problèmes.

Activer SSH sous CPanel photo 4

Résoudre l’erreur SSH: Missing privilege separation directory: /run/sshd

Sur un nouveau serveur à base d’Ubuntu Server 18.04, j’obtiens cette erreur à la suite d’un test du service ssh:

sshd -t

Could not load host key: /etc/ssh/ssh_host_ed25519_key
Missing privilege separation directory: /run/sshdCode language: JavaScript (javascript)

Les solutions à ces deux problèmes sont triviales, cela se règle en deux petites commandes.

L’erreur Could not load host key

L’erreur Could not load host key survient lorsque certaines clés SSH n’ont pas été générées lors de l’installation du système d’exploitation du serveur.

Dans le cas du serveur qui nous occupe, il nous manque la clé de chiffrement ED25519 qui doit se trouver à l’adresse /etc/ssh/ssh_host_ed25519_key.

Pour générer toutes les clés de chiffrement SSH manquantes, une seule commande suffit:

ssh-keygen -A

L’argument -A signifie que l’on génère toutes les clés (All keys). Voici le résultat sur le serveur:

ssh-keygen: generating new host keys: ED25519Code language: JavaScript (javascript)

L’erreur Missing privilege separation directory: /run/sshd

Cette erreur apparaît lorsque le répertoire mentionné – ici /run/sshd – n’a pas été correctement créé. Il suffit de le créer:

mkdir -p /run/sshd

Vérifiez la configuration SSH:

sshd -t

S’il n’y a plus d’erreur, vous pouvez alors redémarrer le service ssh:

service ssh restart

Et voilà, problèmes réglés.

No hotlinking for images

NginX: éviter le hotlinking

Le hotlinking

Le hotlinking (ou liaison automatique ; aussi connu en anglais sous les noms de inline linking, leeching, piggy-backing, direct linking ou offsite image grabs) consiste à utiliser l’adresse d’un fichier publié sur un site web, le plus souvent une image, pour l’afficher sur un autre site, sur un blog, dans un forum, etc.

En d’autres termes, au lieu d’enregistrer l’image et de l’installer sur son propre serveur Web, le hotlinkeur crée un lien direct vers le serveur d’origine.

Si vous êtes sous Apache, voici comment supprimer le hotlinking sous Apache Server.

Désactiver le hotlinking sous NginX

Sous NginX, il peut être très utile d’éviter que des gens publient vos photos ou images depuis votre site sur le leur, en gardant les liens de votre serveur et en consommant toute votre bande passante (ce qui peut représenter un surcoût pour vous).

Il suffit d’éditer votre server block et d’y ajouter cette directive:

location ~ \.(gif|png|jpeg|jpg|svg|webp|avif)$ {
    # Define allowed referers - your own domain and specific external domains
    valid_referers none blocked 
                  ~\.google\. 
                  ~\.bing\. 
                  ~\.yahoo\. 
                  ~\.facebook\. 
                  ~\.pinterest\. 
                  ~\.twitter\. 
                  yourdomain.com 
                  *.yourdomain.com 
                  server_names;

    # Block requests with no or invalid referer
    if ($invalid_referer) {
        return 403;
    }
}
Code language: PHP (php)

N’hésitez pas à rajouter les domaines que vous souhaitez whitelister et qui sont autorisés à utiliser vos fichiers média.

Relancez ensuite NginX avec:

service nginx restart

Cela devrait quelque peu soulager votre serveur et garantir votre bande passante à vos visiteurs.

Activer SSH sous CPanel photo 4

Activer SSH sous CPanel

ssh logo

Il peut être extrêmement utile d’activer la connexion SSH chez certains hébergeurs qui la proposent, comme SiteGround. Cela permet de gagner pas mal de temps, notamment lorsque l’on utilise wp-cli.

Mais avant de pouvoir se connecter, il faut d’abord l’activer dans les options de CPanel.

Activation de la connection SSH dans CPanel

Rendez-vous dans CPanel > Security > SSH Shell Access :

cpanel ssh

Ensuite, cliquez sur le bouton Manage SSH Keys:

cpanel ssh manage

Nous avons ensuite le choix entre deux solutions : soit nous créons la paire de clés privées/publiques sur le serveur et nous les copions sur notre machine locale, soit nous la créons en locale et l’envoyons sur le serveur. Je suis plutôt pour la seconde solution.

Création des clés SSH

On se rend dans le répertoire SSH de notre utilisateur et on liste le répertoire:

cd ~/.ssh
ls

Si le fichier id_rsa.pub existe déjà, il suffit d’afficher son contenu:

cat id_rsa.pubCode language: CSS (css)

Si le fichier n’existe pas, il suffit de le créer:

ssh-keygen

Copiez le contenu du fichier, il s’agit de la clé publique que nous allons importer dans CPanel.

Import de notre clé SSH dans CPanel

Cliquez sur Import Key:

cpanel ssh import

Renommez la clé pour id_rsa puis collez le contenu de votre clé SSH publique:

cpanel ssh import ssh key

Il ne vous reste plus qu’à vous connecter en SSH au serveur. Suivant votre hébergeur, le numéro du port SSH peut changer pour des raisons de sécurité. Chez SiteGround, SSH tourne sur le port 18765:

ssh CPANEL_USER@CPANEL_SERVER -p18765Code language: CSS (css)

Bon ssh !

WordPress : résoudre le problème de la table wp_options à qui manquent une colonne Unique et une Primary Key photo

WordPress : résoudre le problème de la table wp_options à qui manquent une colonne Unique et une Primary Key

Chez Codeable, j’ai travaillé sur l’optimisation d’un site e-commerce propulsé par WooCommerce récemment, qui connaissait quelques problèmes de lenteur.

Sous phpMyAdmin, on trouvait également cette erreur:

Current selection does not contain a unique column

Si vous obtenez cette erreur, c’est que la structure de la table wp_options n’est pas à jour donc nous la vérifions avec wp-cli:

wp db query "DESCRIBE $(wp db prefix --allow-root)options" --allow-rootCode language: JavaScript (javascript)

Le résultat obtenu nous montre qu’il n’y a pas de clé primaire (primary key) qui est normalement option_id et qu’il n’y a pas de restriction unique imposée sur la colonne option_name:

+--------------+---------------------+------+-----+---------+-------+
| Field        | Type                | Null | Key | Default | Extra |
+--------------+---------------------+------+-----+---------+-------+
| option_id    | bigint(20) unsigned | NO   |     | NULL    |       |
| option_name  | varchar(191)        | YES  |     | NULL    |       |
| option_value | longtext            | NO   |     | NULL    |       |
| autoload     | varchar(20)         | NO   |     | yes     |       |
+--------------+---------------------+------+-----+---------+-------+Code language: PHP (php)

Et c’est là que le bât blesse – voici à quoi ressemble la structure standard de la table wp-options:

+--------------+---------------------+------+-----+---------+----------------+
| Field        | Type                | Null | Key | Default | Extra          |
+--------------+---------------------+------+-----+---------+----------------+
| option_id    | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| option_name  | varchar(191)        | NO   | UNI | NULL    |                |
| option_value | longtext            | NO   |     | NULL    |                |
| autoload     | varchar(20)         | NO   | MUL | yes     |                |
+--------------+---------------------+------+-----+---------+----------------+Code language: PHP (php)

Ajouter la Primary Key manquante à wp_options

On ajoute à la colonne option_id la clé primaire qui lui manque:

wp db query "ALTER TABLE $(wp db prefix --allow-root)options MODIFY option_id INT AUTO_INCREMENT PRIMARY KEY;" --allow-rootCode language: JavaScript (javascript)

Et on vérifie le résultat:

wp db query "DESCRIBE $(wp db prefix --allow-root)options" --allow-rootCode language: JavaScript (javascript)

Ajouter la contrainte Unique qui manque à wp_options

Pour ajouter la contrainte UNIQUE à la colonne option_name, on lance:

wp db query "ALTER TABLE $(wp db prefix --allow-root)options ADD UNIQUE (option_name);" --allow-rootCode language: JavaScript (javascript)

Là, il est possible que cela bloque, suivant ce qui se trouve dans votre table wp_options.

Résoudre le problème des doublons

Si vous obtenez une erreur comme :

ERROR 1062 (23000) at line 1: Duplicate entry 'jetpack_available_modules' for key 'option_name'Code language: JavaScript (javascript)

alors cela signifie qu’il existe des enregistrements option_name dupliqués, des doublons qui portent le même nom alors que chaque nom option_name devrait être unique.

On peut obtenir la liste des enregistrements option_name doublons avec cette requête:

wp db query "SELECT option_name, COUNT(*) optioncount FROM $(wp db prefix --allow-root)options GROUP BY option_name HAVING optioncount > 1 ORDER BY optioncount DESC;" --allow-rootCode language: JavaScript (javascript)

Par ordre ascendant, voici la liste des doublons:

+---------------------------------------------+-------------+
| option_name                                 | optioncount |
+---------------------------------------------+-------------+
| jetpack_callables_sync_checksum             |       47123 |
| jetpack_sync_full_config                    |          50 |
| jetpack_sync_full_enqueue_status            |          43 |
| jpsq_sync_checkout                          |          10 |
| jetpack_sync_full__params                   |           5 |
| jetpack_sync_settings_sync_via_cron         |           4 |
| jetpack_sync_full__started                  |           4 |
+---------------------------------------------+-------------+

On peut supprimer automatiquement tous les doublons option_name de deux manières différentes, soit en utilisant la plus vieille valeuroption_id(donc la plus petite valeur d’ID), soit en utilisant la valeuroption_id la plus récente (plus grande valeur d’ID).

Garder le doublon option_name le plus ancien

Voici la requête SQL qui montre uniquement le plus ancien enregistrement (MIN) option_id pour chaque doublon de valeur option_name:

SELECT *
FROM wp options
WHERE option_id NOT IN
    (SELECT *
     FROM
       (SELECT MIN(n.option_id)
        FROM wp_options
        GROUP BY n.option_name) x)Code language: CSS (css)

Une fois que vous avez vérifié le résultat, on peut passer à la suppression.

Cette requête SQL garde l’enregistrement (MIN) option_id le plus ancien de tous les doublonsoption_name et supprime tous les enregistrements plus récents que la valeur trouvée:

DELETE
FROM wp options
WHERE option_id NOT IN
    (SELECT *
     FROM
       (SELECT MIN(n.option_id)
        FROM wp_options n
        GROUP BY n.option_name) x)Code language: CSS (css)

Voici l’équivalent wp-cli:

wp db query "DELETE FROM $(wp db prefix --allow-root)options WHERE option_id NOT IN (SELECT * FROM (SELECT MIN(n.option_id) FROM $(wp db prefix --allow-root)options n GROUP BY n.option_name) x)" --allow-rootCode language: JavaScript (javascript)

Garder le doublon option_name le plus récent

Cette requête SQL ne montre que les enregistrements option_id les plus récents (MAX) pour tous les doublons option_name :

SELECT *
FROM wp_options
WHERE option_id NOT IN
    (SELECT *
     FROM
       (SELECT MAX(n.option_id)
        FROM wp_options n
        GROUP BY n.option_name) x)Code language: CSS (css)

Et voici la requête qui permet de garder les enregistrements option_id les plus récents (MAX) pour tous les doublons option_name en supprimant tous les doublons les plus anciens:

DELETE
FROM wp_options
WHERE option_id NOT IN
    (SELECT *
     FROM
       (SELECT MAX(n.option_id)
        FROM wp_options n
        GROUP BY n.option_name) x)Code language: CSS (css)

Voici l’équivalent wp-cli pour garder l’enregistrement option_name le plus récent:

wp db query "DELETE FROM $(wp db prefix --allow-root)options WHERE option_id NOT IN (SELECT * FROM (SELECT MAX(n.option_id) FROM $(wp db prefix --allow-root)options n GROUP BY n.option_name) x)" --allow-rootCode language: JavaScript (javascript)

Vérifier les clés et contraintes de la table wp_options

Ajoutons de nouveau la contrainte UNIQUE sur la colonne option_name :

wp db query "ALTER TABLE $(wp db prefix --allow-root)options ADD UNIQUE (option_name);" --allow-rootCode language: JavaScript (javascript)

Si vous n’obtenez pas d’erreur, vérifiez la table une nouvelle fois pour constater les changements:

wp db query "DESCRIBE $(wp db prefix --allow-root)options;" --allow-rootCode language: JavaScript (javascript)

Kaboom! Votre table wp_options possède maintenant une PRIMARY KEY sur la colonne option_id et la contrainte UNIQUE sur la colonne option_name:

+--------------+---------------------+------+-----+---------+----------------+
| Field        | Type                | Null | Key | Default | Extra          |
+--------------+---------------------+------+-----+---------+----------------+
| option_id    | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| option_name  | varchar(191)        | NO   | UNI |         |                |
| option_value | longtext            | NO   |     | NULL    |                |
| autoload     | varchar(20)         | NO   |     | yes     |                |
+--------------+---------------------+------+-----+---------+----------------+Code language: PHP (php)

Je vous conseille de vérifier la structure de la table de temps à autre, notamment si vous constatez une prise de poids anormale en très peu de temps

Ajouter un lien avec le nombre d'articles et le total du panier WooCommerce photo

Mettre à jour la base de données de WooCommerce 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.0Code language: CSS (css)

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

Et voilà votre base de données WooCommerce à jour!

Nouveau serveur : migration vers ORION photo

Nouveau serveur dédié : migration vers ORION

orion constellation hubble 1280x800
La nébuleuse d’Orion, prise par Hubble.

Vous lisez actuellement cet article depuis le nouveau serveur de SkyMinds, baptisé ORION.

De mail à ORION

Le serveur précédent a été le théâtre d’une multitude de tutoriels consacrés à la série Monter un serveur dédié de A à Z, tournait sous Debian (6, 7, 8, et 9) mais était un peu limité en termes de ressources (Intel Core2 Quad Q8300 @ 2.50GHz, 4 Go de RAM, 750 Go de disque). Tant qu’il n’y avait qu’un seul site à gérer, cela convenait mais avec près d’une dizaine de sites, on touchait les limites.

ORION est bien plus confortable : Intel Xeon W3530 @ 2.80GHz, 32 Go de RAM, 2 To de disque en RAID). De quoi pouvoir monter en charge tranquillement :)

Du changement dans notre stack

Qui dit nouveau serveur, dit refonte de la stack. Vu que nous partons d’un environnement vierge, autant partir du bon pied et utiliser toutes les dernières innovations. Le serveur précédent datait de 2012 et, même s’il tournait parfaitement, il a connu pas mal de mises à jour (parfois pas très stables).

J’ai donc décidé de changer d’OS pour ORION : même si j’adore travailler sous Debian, je me suis dit que j’allais tenter Ubuntu Server 18.04 LTS. Certains tutoriels ne sont pas exactement équivalents entre Debian et Ubuntu Server donc cela promet quelques nouveaux tutoriels !

Objectif performance

Le but du nouveau serveur est d’être un peu plus à l’aise au niveau des ressources, surtout si les sites lancés récemment prennent de l’ampleur. Cela donne également un peu plus d’oxygène au serveur de bases de données.

L’autre objectif est un objectif de performance : monter un serveur dédié de manière simple et efficace, en privilégiant la sécurité et la rapidité des sites hébergés.

Voilà, c’est tout pour la note de service. Les tutoriels sont en cours d’écriture, donc bientôt disponibles sur le site !

Désactiver les binary logs sous MySQL 8 photo

Désactiver les binary logs sous MySQL 8

mysql 8

J’ai récemment monté un nouveau serveur qui utilise MySQL 8 et après quelques jours d’utilisation, je me suis rendu compte que l’espace disque avait considérablement augmenté.

La cause ? Une multitude de fichiers logs binaires dans le répertoire d’exécution de MySQL 8 : il y en avait pour plus de 260 Go !

Les fichiers logs binaires enregistrent toutes les requêtes qui ont été effectuées par le serveur de bases de données. Inutile de dire qu’il est assez improbable que vous cherchiez à savoir quelles requêtes ont été lancées le mois dernier!

Désactivation des logs binaires

Sous MySQL 8, voici comment désactiver les logs binaires : éditez le fichier de configuration de MySQL:

nano /etc/mysql/mysql.conf.d/mysqld.cnf

et ajoutez cette ligne sous [mysqld] :

skip-log-bin

Vous pouvez également vous connecter au serveur MySQL en ligne de commande:

mysql -u root -p

et lancer la commande suivante dans l’invite de commande MySQL:

SET sql_log_bin = 0;
PURGE BINARY LOGS BEFORE '2019-03-31';Code language: JavaScript (javascript)

Relancez ensuite le serveur MySQL:

service mysql restart

Il ne vous reste plus qu’à vous rendre dans le dossier d’exécution de MySQL – /etc/mysql par défaut, sauf si vous l’avez modifié – et supprimer les fichiers binlog*.

The SEO Framework : résoudre l'erreur 404 du fichier sitemap.xml sous NginX photo

The SEO Framework : résoudre l’erreur 404 du fichier sitemap.xml sous NginX

Cela fait belle lurette que j’ai troqué Yoast SEO pour The SEO Framework, qui est bien mieux codé et plus performant.

Récemment, lors d’un changement de serveur, je me suis aperçu que l’un des sites avait son fichier sitemap.xml qui renvoyait une erreur 404 sous NginX.

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

Vérification du server block

Commencez d’abord par vérifier que votre serveur block contient les bonnes directives pour gérer les règles de WordPress:

location / {
        # This is cool because no php is touched for static content.
        # include the "?$args" part so non-default permalinks doesn't break when using query string
        try_files $uri $uri/ /index.php?$args;
}Code language: PHP (php)

Sauvez votre server block puis relancez NginX. Il est possible que cela ne soit pas suffisant, si c’est le cas, nous allons ajouter une directive supplémentaire.

Une directive dédiée pour sitemap.xml

Ajoutons une directive supplémentaire à notre server block, qui permettra de rediriger vers la sitemap générée par The SEO Framework :

# sitemap.xml directive
# Matt Biscay
# https://www.skyminds.net/?p=30771
location = /sitemap.xml {
	rewrite ^/sitemap.xml$ "/?the_seo_framework_sitemap=xml" permanent;
}Code language: PHP (php)

Sauvez les changements et rechargez NginX – boom, la sitemap est de retour!

Linux : supprimer les vieux kernels et libérer de la place sur la partition /boot photo

Ubuntu : supprimer les vieux kernels et libérer de la place sur la partition /boot

Voici un tutoriel qui vous permet de supprimer les kernels linux installés sur votre serveur qui ne sont pas actuellement utilisés.

Cela est utile pour faire un peu de ménage sur la partition /boot, idéalement avant qu’elle ne soit complètement saturée. Sinon, je vous donne aussi l’astuce pour faire le ménage manuellement et retrouver APT complètement opérationnel.

Ce tutoriel a été testé sous Ubuntu Server 18.04 LTS, il est complètement transférable sous Ubuntu et Debian.

Cas de figure 1: /boot n’est pas plein à 100% et apt est opérationnel

1. On vérifie la version actuelle du kernel

uname -r

Cela nous donne la version du noyau sous laquelle tourne notre machine:

4.15.0-46-genericCode language: CSS (css)

2. On supprime les vieux kernels

2.a. On liste les vieux kernels

sudo dpkg --list 'linux-image*'|awk '{ if ($1=="ii") print $2}'|grep -v `uname -r`Code language: JavaScript (javascript)

You will get the list of images something like below:

linux-image-4.15.0-45-genericCode language: CSS (css)

2.b. On supprime les vieux kernels (un par un)

sudo apt purge linux-image-4.15.0-45-genericCode language: CSS (css)

Une fois que les vieux kernels sont supprimés, on supprime également les paquets qui seront maintenant obsolètes:

sudo apt autoremove

Et on finit par la mise à jour de la liste des noyaux de GRUB:

sudo update-grub

Voilà, il ne vous reste plus qu’à rebooter votre machine ou votre serveur. Il ne reste que le dernier kernel.

Cas de figure 2 : apt est indisponible car /boot est plein à 100%

NOTE: cette partie du tutoriel n’est valable que si et seulement si vous ne pouvez utiliser APT parce que la partition /boot est pleine à 100%.

1. Listez les images de kernel

Obtenez la liste des images de kernels et faites la liste des kernels que vous pouvez supprimer car ils ne sont plus utilisés. Cette commande vous montre les kernels installés à l’exception de celui qui est en cours d’utilisation:

sudo dpkg --list 'linux-image*'|awk '{ if ($1=="ii") print $2}'|grep -v `uname -r`Code language: JavaScript (javascript)

Voici le résultat de la commande, la liste des kernels installés mais inutilisés:

linux-image-3.19.0-59-generic
linux-image-3.19.0-61-generic
linux-image-3.19.0-65-generic
linux-image-extra-3.19.0-59-generic
linux-image-extra-3.19.0-61-generic
linux-image-extra-3.19.0-65-genericCode language: CSS (css)

2. Préparez la suppression

Vous devez préparer la commande qui va supprimer tous les kernels inutilisés en utilisant la brace expansion pour vous simplifier la vie. Je vous conseille d’écrire la commande dans un éditeur de texte et de bien la vérifier avant de la lancer dans le terminal.

N’oubliez pas d’exclure le kernel actuel ainsi que les deux kernels les plus récents pour pallier tout problème:

sudo rm -rf /boot/*-3.19.0-{59,61,65}-*

3. Nettoyez APT et ses messages d’avertissement à propos d’une installation partielle

sudo apt-get -f installCode language: JavaScript (javascript)

4. Autoremove

Enfin, on lance la commande autoremove pour supprimer les paquets relatifs aux vieilles images de kernel qui ont été rendues orphelines par le nettoyage manuel de /boot :

sudo apt autoremove

5. Mise à jour de GRUB

sudo update-grub

6. APT est opérationnel

Vous pouvez de nouveau utiliser APT et mettre à jour, installer et supprimer les paquets de votre distribution:

sudo apt update