Update MySQL client and server versions using apt config.

Mettre à jour MySQL client, server et apt-config

Un an après mon article sur l’erreur APT : the following packages have been kept back, voici que cela recommence : impossible d’installer les mises à jour de mysql-client et mysql-server parce que mysql-apt-config n’est plus à jour.

J’ai tendance à oublier la solution parce que je n’y suis confronté que depuis peu donc j’ai écris un petit script bash que je pourrai lancer la prochaine fois, histoire de gagner du temps.

Pré-requis: installation de pup

pup est un outil en ligne de commande pour traiter le HTML. Il lit à partir de stdin, imprime vers stdout, et permet à l’utilisateur de filtrer des parties de la page en utilisant des sélecteurs CSS.

Nous téléchargeons pup depuis son repo sur Github, on extraie le binaire et on le déplace dans /usr/local/bin/ :

wget https://github.com/ericchiang/pup/releases/download/v0.4.0/pup_v0.4.0_linux_amd64.zip

unzip pup_v0.4.0_linux_amd64.zip

sudo mv pup /usr/local/bin/Code language: JavaScript (javascript)

Script bash pour mettre à jour MySQL avec mysql-apt-config

Nous créons notre nouveau script, et nous le rendons exécutable:

cd /home/scripts

nano install-latest-mysql-apt.sh

chmod +x install-latest-mysql-apt.sh

Et voici le contenu du script:

#!/bin/bash
# ----------------------------------------- #
# Script Name: install-latest-mysql-apt.sh  #
# Author: Matt Biscay                       #
# URL: https://www.skyminds.net/?p=613967   #
# ----------------------------------------- #

# Color codes
RED=$(tput bold; tput setaf 1)
GREEN=$(tput bold; tput setaf 2)
YELLOW=$(tput bold; tput setaf 3)
MAGENTA=$(tput bold; tput setaf 5)
NC=$(tput sgr0) # No Color

# Function to print the header
function print_header() {
  echo -e "${YELLOW}# ----------------------------------------- #${NC}"
  echo -e "${YELLOW}# Script Name: install-latest-mysql-apt.sh  #${NC}"
  echo -e "${YELLOW}# Author: Matt Biscay                       #${NC}"
  echo -e "${YELLOW}# URL: https://www.skyminds.net/?p=613967   #${NC}"
  echo -e "${YELLOW}# ----------------------------------------- #${NC}"
}

# Print the header
print_header

# Function to check if the command exists
function check_command() {
  command -v "$1" &> /dev/null || {
    echo -e "${RED}$1 is not installed. Please install it and try again.${NC}"
    exit 1
  }
}

# Check if wget, unzip are installed
check_command wget
check_command unzip

# Check if pup is installed
if ! command -v pup &> /dev/null; then
  read -p $"${MAGENTA}The \"pup\" tool is not installed, would you like to install it now? (Y/N) ${NC}" INSTALL_PUP
  case ${INSTALL_PUP:0:1} in
    [Yy]* )
      TMP_DIR=$(mktemp -d)
      wget https://github.com/ericchiang/pup/releases/download/v0.4.0/pup_v0.4.0_linux_amd64.zip -O "$TMP_DIR/pup.zip"
      unzip "$TMP_DIR/pup.zip" -d "$TMP_DIR"
      mv "$TMP_DIR/pup" /usr/local/bin/
      rm -r "$TMP_DIR"
      echo -e "${GREEN}Package pup has been installed.${NC}"
      ;;
    [Nn]* )
      echo "Exiting since pup is not installed."
      exit 1
      ;;
    * )
      echo -e "${RED}Invalid input. Please enter Y or N.${NC}"
      exit 1
      ;;
  esac
fi

BASE_URL="https://dev.mysql.com"
INITIAL_URL="${BASE_URL}/downloads/repo/apt/"

# Create temporary files
TMP_INITIAL=$(mktemp)
TMP_SECONDARY=$(mktemp)

echo "Fetching initial page... $INITIAL_URL"
wget -qO- "$INITIAL_URL" > "$TMP_INITIAL"

# Extract the secondary download page URL from the main page
echo "Extracting secondary page URL..."
SECONDARY_URL=$(cat "$TMP_INITIAL" | pup 'div.button03 a attr{href}')
echo "Secondary URL: ${BASE_URL}${SECONDARY_URL}"

# Fetch the secondary page and store its content for debugging
echo "Fetching secondary page..."
wget -qO- "${BASE_URL}${SECONDARY_URL}" > "$TMP_SECONDARY"

# Extract the download link from the secondary page
echo "Extracting download link..."
DOWNLOAD_URL=$(cat "$TMP_SECONDARY" | pup 'a:contains("No thanks, just start my download.") attr{href}')
echo "Download URL: ${BASE_URL}${DOWNLOAD_URL}"

# Ask user if they want to install mysql-apt-config
read -p $"${MAGENTA}Do you want to download and install the package? (Y/N) ${NC}" DOWNLOAD_MYSQL_APT_CONFIG
case ${DOWNLOAD_MYSQL_APT_CONFIG:0:1} in
    [Yy]* )
        wget "${BASE_URL}${DOWNLOAD_URL}" -O mysql-apt-config.deb
        dpkg -i mysql-apt-config.deb

        echo -e "${GREEN}Package mysql-apt-config has been updated.${NC}"

        read -p $"${MAGENTA}Are you ready to install updates with \"apt update && apt upgrade\"? (Y/N) ${NC}" UPDATE_UPGRADE
        case ${UPDATE_UPGRADE:0:1} in
            [Yy]* )
                apt update && apt upgrade
                ;;
            [Nn]* )
                echo "Exiting without installing updates."
                ;;
            * )
                echo -e "${RED}Invalid input. Please enter Y or N.${NC}"
                ;;
        esac
        ;;
    [Nn]* )
        echo "Exiting without installing."
        ;;
    * )
        echo -e "${RED}Invalid input. Please enter Y or N.${NC}"
        ;;
esac

# Trap to clean up temporary files
trap 'rm -f "$TMP_INITIAL" "$TMP_SECONDARY" mysql-apt-config.deb' EXITCode language: PHP (php)

Fonctionnement du script

Le script commence par vérifier que pup est installé. S’il ne l’est pas, on prompte l’utilisateur pour l’installer:

The "pup" tool is not installed, would you like to install it now? (Y/N) y

Connecting to objects.githubusercontent.com (objects.githubusercontent.com)|185.199.109.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1718186 (1.6M) [application/octet-stream]
Saving to: ‘/tmp/tmp.4buPXeejfo/pup.zip’

Archive:  /tmp/tmp.4buPXeejfo/pup.zip
  inflating: /tmp/tmp.4buPXeejfo/pup
Package pup has been installed.Code language: JavaScript (javascript)

Le script effectue deux requêtes sur le site de MySQL: lors de la première requête, il identifie le lien du bouton “Download”.

Lire la suite

WordPress Using WP CLI

wp-cli : importer et exporter les utilisateurs WP

Voici une méthode simple pour exporter tous les utilisateurs d’une base de données WordPress, pour les réimporter sur un autre site, à l’aide de l’excellent wp-cli.

Nous ferons référence à la base de données source en tant que source-db et à la base de données cible en tant que target-db et je supposerai que vous avez accès aux deux instances WordPress via wp-cli.

Étape 1 : exporter les utilisateurs WordPress

Cette étape fonctionnera avec la base de données source-db:

wp db export --tables = $(wp db tables 'wp_*_users') users.sqlCode language: JavaScript (javascript)
  • notez l’astérisque dans le nom de la table – utilisez-le pour éviter de taper le nom exact de la table pour votre base de données WordPress spécifique
  • notez le nom du fichier exporté, users.sql – cela permet d’identifier clairement le contenu de ce fichier.

Étape 2 : exporter la méta utilisateur WordPress

Cette étape fonctionnera avec la base source-db. Comme ci-dessus, notez le caractère générique et le nom de fichier:

wp db export --tables = $(wp db tables 'wp_*_usermeta') usermeta.sqlCode language: JavaScript (javascript)

Étape 3 : sauvegarde facultative des utilisateurs et usermeta

Cette étape fonctionnera avec la base target-db. Il s’agit d’une sauvegarde facultative des utilisateurs et des tables usermeta avant d’importer les nouvelles données:

  • répétez l’étape 1 (mais en travaillant avec target-db)
  • nommez le fichier backup-users.sql
  • répétez l’étape 2 (mais en travaillant avec target-db)
  • nommez le fichier backup-usermeta.sql

Cela nous donne donc:

wp db export --tables = $(wp db tables 'wp_*_users') backup-users.sql
wp db export --tables = $(wp db tables 'wp_*_usermeta') backup-usermeta.sqlCode language: JavaScript (javascript)

Lire la suite

WordPress : résoudre l'erreur

Lister tous les articles publiés sur un blog WordPress avec wp-cli

wordpress banner 1280x512

Lister les URLs de tous les articles publiés

J’ai récemment eu besoin de lister toutes les URLs des articles du site, pour les promouvoir sur les réseaux sociaux. L’un des services que j’utilise, SocialBee, permet de soumettre une liste de 100 URLs à chaque soumission du formulaire.

Il nous faut donc une liste d’adresse de 100 articles publiés, ce qui est très facile à obtenir grâce à wp-cli. Voici la commande que j’ai écrite:

wp post list --field=url --post_status=publish --allow-root --posts_per_page=100 --paged=1Code language: PHP (php)

Explications:

  • wp est un alias de wp-cli, installé sur le serveur
  • post indique l’on va interroger les articles
  • list: on va lister!
  • --field=url : on veut le champ URL
  • --post_status=publish : les articles publiés uniquement
  • --allow-root : parce que je suis en root
  • --posts_per_page=100: le nombre d’article à récupérer
  • --paged=1 : le numéro de la pagination de la requête

Il vous suffit ensuite d’incrémenter la valeur de --paged pour passer en revue toutes les pages de la requête.

Ou alors retirer totalement les arguments --posts_per_page=100 --paged=1 pour obtenir la liste complète des URLs de tous les articles publiés.

Linux et MacOS : lister tous les répertoires de plus de 500 Mo photo

Linux et MacOS : lister tous les répertoires de plus de 500 Mo

De temps en temps, il faut un peu faire le ménage sur nos disques durs et il est assez utile de chercher à savoir quels sont les dossiers qui prennent le plus d’espace disque.

Lister tous les répertoires de plus de 500 Mo

Sous Linux et MacOS, voici la commande que je lance pour trouver tous les répertoires de plus de 500 Mo, classés par ordre d’importance:

du -m ~/Downloads/* | awk '$1 > 500' | sort -nrCode language: JavaScript (javascript)

Voici le détail de la commande:

  • du signifie disk usage
  • -m signifie que l’on souhaite la taille en Mo
  • ~/Downloads/* est le chemin dans lequel se trouvent nos gros dossiers, là où se trouvent nos données
  • awk '$1 > 500' capture le chemin du dossier lorsqu’il dépasse 500 Mo
  • sort -nr permet de classer la liste du plus gros dossier au plus petit

Une petite commande à garder sous le coude, cela permet d’éviter de perdre trop de temps à trouver le dossier le plus gourmand du disque!

Utiliser Git pour envoyer du code versionné sur Github photo

Utiliser Git pour envoyer du code versionné sur Github

Git – et son homologue Github – permet de versionner votre code afin de pouvoir commenter les changements de code, revenir en arrière et annuler une modification en cas de problème, tenir une feuille de route, accepter des demandes de modifications venant d’autres développeurs (pull requests) et permettre la collaboration de plusieurs personnes sur un même projet.

Voici un petit tuto pour vous donner les commandes essentielles qui permettent de créer le dépôt, ajouter du code et l’envoyer sur Github.

Installation de Git

Commençons par l’étape obligatoire qui est l’installation de Git sur votre système d’exploitation:

MacOSX : résoudre l’erreur xcrun: error: invalid active developer path

Sous MacOSX, lorsque vous lancez une commande git, vous pouvez obtenir le message d’erreur suivant:

xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrunCode language: JavaScript (javascript)

Cela signifie qu’il vous manque les outils de développement XCode. Cela peut arriver après chaque mise à jour d’OSX donc vous pouvez les installer avec:

sudo rm /Library/Developer/CommandLineTools -rf
sudo xcode-select --install

Créer un nouveau dépôt Git et l’associer à votre dépôt GitHub

Placez-vous dans le répertoire qui contient votre code. On crée un nouveau dépôt Git avec:

git init

Cela initialise votre répertoire avec les dossiers cachés de git. On ajoute maintenant l’adresse de notre dépôt sur GitHub:

git remote add origin https://github.com/example/example-projectCode language: JavaScript (javascript)

Nous allons maintenant pouvoir ajouter notre code.

Ajouter et valider votre code

Pour ajouter des fichiers, on utilise la directive add:

git add *
git add <filename>Code language: HTML, XML (xml)

Ensuite, on valide avec un message qui explique la validation des changements:

git commit -m "Ajout des fichiers du projet"Code language: JavaScript (javascript)

A ce stade, le fichier est dans le HEAD de git, mais pas encore dans votre dépôt distant. On l’envoie donc sur GitHub avec:

git push origin master

Pour mettre à jour votre dépôt local vers les dernières validations qui se trouvent sur GitHub (attention, cela écrase les fichiers locaux!), exécutez la commande:

git pull

Voilà, c’est un petit mémo simple mais il permet déjà de se servir des principales fonctions de git.

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

PHP : ajouter les directives

PHP : ajouter les directives “HttpOnly” et “Secure” aux cookies de session

Les directives “HttpOnly” et “Secure”

A l’heure où la grande majorité des sites internet sont passés à HTTPS, il n’est pas rare de constater que PHP ne sert toujours pas les cookies de session avec les directives “HttpOnly” et “Secure”.

Pourtant, les directives sont bien disponibles dans le fichier php.ini, il suffit donc de les activer.

Edition de php.ini

On édite donc notre fichier php.ini:

nano /etc/php/7.2/fpm/php.ini

Et on modifie ces valeurs :

session.cookie_httponly 1
session.cookie_secure 1
session.use_only_cookies 1Code language: CSS (css)

Enregistrez le fichier et relancez PHP:

service php7.2-fpm restartCode language: CSS (css)

Testez votre site de nouveau : les cookies de session contiennent maintenant les deux nouvelles directives :

set-cookie: PHPSESSID=7d5h81tfiuna3p2p00o1v7b13q; path=/; secure; HttpOnlyCode language: JavaScript (javascript)

Cela ne s’applique pas à tous les cookies créés par les plugins ou applications du site.

Il faudrait pour cela que le serveur, nginx, possède nativement le module nginx_cookie_flag_module.

MariaDB : changer le répertoire des bases de données sous Debian photo

Serveur dédié : déplacer les bases de données MariaDB ou MySQL sur une autre partition

J’ai récemment installé un plugin qui met en cache les requêtes API Amazon mais dont la table SQL gonfle énormément – plus de 5 Go à l’heure où j’écris ces lignes.

Le problème, c’est que cela remplit la partition racine du serveur, qui est utilisée par défaut par MariaDB pour stocker les fichiers des bases de données.

Lorsque j’ai créé ce serveur, j’ai utilisé la configuration par défault d’OVH, ce qui est une erreur grossière : la partition racine (/) fait 10 Go alors que la partition /home fait 740 Go… même pour un desktop, on ne fait plus cela parce que cela laisse trop peu pour le système alors imaginez un peu pour un serveur !

Nous avons donc le choix entre re-partitionner le disque (autant vous dire que cela ne me tente que très moyennement) ou alors changer le dossier des bases SQL pour les mettre sous /home.

Ce tutoriel vous permet donc de délocaliser les bases de données MySQL/MariaDB sur une autre partition. Le serveur tourne sur la dernière version de Debian.

Vérification du chemin des bases MariaDB

Tout se passe via le terminal. Je vous conseille de faire une sauvegarde de vos bases avant de commencer.

Commençons par vérifier le dossier dans lequel se trouve nos bases de données:

mysql -u root -p

Entrez votre mot de passe root puis entrez la commande suivante:

select @@datadir;Code language: CSS (css)

Résultat:

+-----------------+
| @@datadir       |
+-----------------+
| /var/lib/mysql/ |
+-----------------+
1 row in set (0.00 sec)Code language: JavaScript (javascript)

Ajustement de systemd pour MariaDB

Ceci est une étape fondamentale du tutoriel. Si vous ne faites pas cela, MariaDB ne démarrera pas avec votre nouveau dossier car, par défaut, il n’a pas accès à /home.

Il faut donc que nous lui donnions explicitement l’accès :

systemctl edit mariadb

Dans le fichier qui s’ouvre, entrez le code suivant:

[Service]
ProtectHome = falseCode language: JavaScript (javascript)

Enregistrez le fichier tel quel, sans changer le nom. Le fichier que vous venez de créer est /etc/systemd/system/mariadb.service.d/override.conf

Appliquez maintenant les changements :

systemctl daemon-reload

Un nouveau répertoire pour nos bases de données

Nous pouvons maintenant créer le nouveau répertoire qui accueillera les fichiers de nos bases de données. Par simplicité, je choisis de tout mettre sous /home/mysql :

Lire la suite

Débloquer le démarrage de Meld sous MacOSX Mojave photo

Débloquer le démarrage de Meld sous MacOSX Mojave

Depuis la mise à jour de MacOSX Mojave, il est devenu impossible de lancer Meld, l’application multi-plateforme dont je me sers pour comparer plusieurs versions de fichiers afin de visualiser les différences dans du texte ou code.

Débloquer le démarrage de Meld sous MacOSX Mojave photo

L’application se lance mais ne présente pas la fenêtre habituelle qui permet de sélectionner les options de comparaison. Le menu apparait bien en haut de l’écran mais reste inutilisable.

On peut débloquer la situation très facilement – ouvrez une fenêtre de terminal et lancez les commandes suivantes:

cd ${HOME}
rm ./.local/share/meld -rf 
rm ./Library/Preferences/org.gnome.meld.plist -f
rm "./Library/Saved Application State/org.gnome.meld.savedState/" -rf Code language: JavaScript (javascript)

Ces commandes permettent de supprimer le fichier de préférence GNOME de l’application et de réinitialiser l’état de l’application.

Une fois que vous avez exécuté ces commandes, relancez Meld – il me semble plus lent qu’avant à démarrer mais il est tout à fait fonctionnel ensuite, ce qui est l’essentiel.

Linux : désactiver les emails de notification d'une tâche cron photo

Linux : désactiver les emails de notification d’une tâche cron

La plupart des tâches cron sont exécutées à un moment où elles n’empiètent pas sur les ressources du serveur (i.e. la nuit).

Or crontab envoie un email récapitulatif à chaque fois qu’une tâche est complétée, ce qui peut vite devenir pénible à gérer.

Heureusement, il existe plusieurs manières d’empêcher de recevoir ces emails de notification de tâches cron.

1. Méthode nucléaire : rendre la variable MAILTO nulle

Vous pouvez éditer le fichier /etc/crontab et rendre la variable MAILTO nulle, comme ceci:

MAILTO=""Code language: JavaScript (javascript)

Cela désactive effectivement tous les emails envoyés depuis crond. C’est par contre une méthode nucléaire : si vous voulez une notification, il faudra l’envoyer depuis le script et non cron.

Cela empêche également de recevoir toute notification en cas d’erreur de la tâche cron, ce qui est très gênant – ce n’est pas vraiment la méthode que je conseille.

2. Rediriger STDOUT et STDERR vers null pour supprimer toute sortie

Si vous supprimez la sortie du script, crond n’aura rien à envoyer.

Ajoutez ceci à l’entrée de votre crontab pour envoyer toute sortie (STDERR et STDOUT) vers /dev/null:

>/dev/null 2>&1Code language: JavaScript (javascript)

Voici un exemple qui lance un script toutes les 5 minutes, sans sortie:

*/5 * * * * /example/script >/dev/null 2>&1Code language: JavaScript (javascript)

Le principal inconvénient est que cela supprime également toutes les erreurs qui pourraient être utiles au débuggage du script.

3. Configurer crond pour envoyer la sortie du script vers les logs système et désactiver la notification de la sortie

Vous pouvez configurer crond en éditant le fichier /etc/sysconfig/crond pour y changer la ligne CRONDARGS.

L’argument -s envoie la sortie vers le log système et l’argument -m off désactive la notification email du résultat de la tâche.

Voici un exemple :

cat /etc/sysconfig/crond

Résultat:

# Settings for the CRON daemon.
# CRONDARGS= :  any extra command-line startup arguments for crond
CRONDARGS=-s -m offCode language: PHP (php)

Il faut ensuite relancer le service cron pour appliquer la nouvelle configuration avec les nouveaux arguments:

service cron restart

Conclusion

Toutes ces méthodes permettent de supprimer totalement les notifications emails du service cron lorsqu’une tâche est lancée.

Si vous souhaitez ne pas produire de sortie mais garder la possibilité de recevoir un email en cas d’erreur, pensez à rediriger STDOUT vers /dev/null:

*/5 * * * * /example/script > /dev/nullCode language: JavaScript (javascript)