Lister les certificats

La commande pour lister les certificats présents sur un serveur est la suivante :

sudo certbot certificates

Ce qui donne une réponse de ce type :

Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: myserver.com-0001
    Serial Number: 42e6edbcc7e312e59ea7f09fc7f26ba958d
    Key Type: RSA
    Domains: myserver.com www.myserver.com dev.myserver.com
    Expiry Date: 2023-09-06 06:36:39+00:00 (VALID: 12 days)
    Certificate Path: /etc/letsencrypt/live/myserver.com-0001/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/myserver.com-0001/privkey.pem
  Certificate Name: mynewserver.net
    Serial Number: 47ec878999fbf7ac2324ea3d2c459c2bc84
    Key Type: RSA
    Domains: mynewserver.net dev.mynewserver.net
    Expiry Date: 2023-11-21 06:27:16+00:00 (VALID: 88 days)
    Certificate Path: /etc/letsencrypt/live/mynewserver.net/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/mynewserver.net/privkey.pem

Ici, je veux supprimer le certificats myserver.com-0001, j’utilise l’option delete de certbot :

sudo certbot delete --cert-name myserver.com-0001
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The following certificate(s) are selected for deletion:

  * myserver.com-0001

Are you sure you want to delete the above certificate(s)?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: Y
Deleted all files relating to certificate myserver.com-0001.

Voilà, le certificat est supprimé. Il faut bien sur vérifier qu’aucun site web n’utilise cet ancien certificat et le mettre jour si nécessaire.

L’article Certbot : supprimer un certificat est apparu en premier sur tech.feub.net.

Toujours avec le cas de Docker avec Magento 1.9 vu dans mon précédent article, je vais faire les modifications pour grandement accélérer les performances du serveur web et de MySQL en déplaçant leurs données vers le système de fichiers Linux et non Windows.

Sous-système WSL Ubuntu

Dans mon cas, je vais prendre Ubuntu (celui-ci doit être installé ainsi que WSL2 activé). Pour savoir où se situe l’arborescence du sous-système Ubuntu, il suffit dans l’Explorateur de fichiers de taper \\wsl$. On se retrouve alors avec des répertoires docker-desktop et docker-desktop-data qui sont propres à Docker pour Windows et également un répertoire Ubuntu ou se trouve le système de fichiers Ubuntu.

Je vais alors copier tout mon projet Docker – le répertoire projet_mage19 – sous \wsl$\Ubuntu\home\fabien\ et j’édite le docker-compose.yml pour refléter ces changements.

Maintenant il faut démarrer nos conteneurs sous l’environnement Ubuntu et non plus sous Windows. Dans une fenêtre PowerShell, j’ouvre une session WSL, je me place dans le répertoire de mon projet et je fais mon docker-compose :

$ wsl -d Ubuntu
$ cd /home/fabien/projet_mage19
$ docker-compose up -d

Et voilà, tout est 10 fois plus rapide.

L’article Volumes Docker Windows très lent est apparu en premier sur tech.feub.net.

Afin de me débarrasser d’un stack WAMP vieillissant et peu évolutif pour mes développements par Docker, je publie ci-dessous mon projet Magento 1.9, pour ceux, comme moi qui maintienne encore cet ancien CMS e-commerce.

Répertoire du projet

Il s’agit d’un stack LAMP classique : Apache, PHP 5.6, MySQL 5.7, PHPMyAdmin et memcached. Il y a 4 conteneurs. Niveau arborescence, mon projet Docker Magento 1.9 ressemble à ceci :

projet_mage19/
	confs/
	db_data/
	magento_data/
	mysql/
		conf.d/
	docker-compose.yml
	Dockerfile

• confs : php.ini
• db_data : les données MySQL
• magento_data : le site Magento
• mysql/conf.d : my.cnf

docker-compose.yml

La partie « command » du conteneur « db » permet d’avoir le my.cnf en lecture seule, sinon il est ignoré par MySQL.

version: "3.9"

services:
  db:
    image: mysql:5.7
    volumes:
      - ./db_data:/var/lib/mysql
      - ./mysql/conf.d/:/usr/local/mysqlconf
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: password_root_mysql
      MYSQL_DATABASE: nom_database
      MYSQL_USER: nom_utilisateur
      MYSQL_PASSWORD: password_utilisateur
    command: >
      bash -c "

      cp /usr/local/mysqlconf/*.cnf /etc/mysql/conf.d/ && chmod 644 /etc/mysql/conf.d/*.cnf && /entrypoint.sh mysqld
      "
    
  mage19:
    depends_on:
      - db
    build: .
    volumes:
      - ./magento_data:/var/www/html
    ports:
      - "80:80"
    restart: always
    stdin_open: true
    tty: true
    extra_hosts:
      - monsitemagento.local:127.0.0.1
    hostname: monsitemagento.local
    domainname: local
    
  phpmyadmin:
    image: phpmyadmin
    restart: always
    ports:
      - 8080:80
    environment:
      - PMA_ARBITRARY=1
      
  memcached:
    image: bitnami/memcached:latest
    ports:
      - 11211:11211
    environment:
      - MEMCACHED_CACHE_SIZE=512
      
volumes:
  db_data: {}
  magento_data: {}
  confs: {}

Dockerfile

FROM php:5.6-apache

EXPOSE 80

RUN apt-get update -qq && \
    apt-get install -qy \
	libmemcached-dev \
	zlib1g-dev \
    git \
    gnupg \
    unzip \
    zip \
	&& pecl install memcached-2.2.0 \
    && docker-php-ext-enable memcached

ADD https://github.com/mlocati/docker-php-extension-installer/releases/latest/download/install-php-extensions /usr/local/bin/

RUN chmod +x /usr/local/bin/install-php-extensions && \
    install-php-extensions \
	dom \
	hash \
	iconv \
	pcre \
	simplexml \
	mbstring \
	zip \
        gd \
	pdo \
	pdo_mysql \
	memcached
	
COPY confs/php.ini /usr/local/etc/php/conf.d/app.ini
	
RUN a2enmod rewrite
RUN service apache2 restart

my.cnf

[mysqld]
query_cache_type = 1
query_cache_size = 512M
query_cache_limit = 256M

tmp_table_size = 256M
max_heap_table_size = 256M
read_buffer_size = 128M
read_rnd_buffer_size = 128M
bulk_insert_buffer_size = 64M

myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 256M
myisam_repair_threads = 2

key_buffer_size = 256M
max_allowed_packet = 256M
table_open_cache = 1024
sort_buffer_size = 8M
thread_cache_size = 8

innodb_log_buffer_size = 32M
innodb_log_file_size = 32M
innodb_log_files_in_group = 2
innodb_flush_log_at_trx_commit = 0
innodb_buffer_pool_size = 1024M

php.ini

date.timezone = Europe/Paris

memory_limit = 1024M
max_execution_time=600

magic_quotes_gpc = off

opcache.enable = 1
opcache.enable_cli = 1
opcache.memory_consumption = 256M
opcache.revalidate_freq = 0
apc.enable_cli = On

upload_max_filesize = 16M
post_max_size = 16M

realpath_cache_size = 4096k
realpath_cache_ttl = 7200

display_errors = Off
display_startup_errors = Off

Démarrer les conteneurs avec docker-compose

Pour accéder au site via http://monsitemagento.local ne pas oublier d’ajouter une ligne dans le fichier hosts :

127.0.0.1       monsitemagento.local

Puis, dans un terminal, dans le répertoire projet_mage19 :

docker-compose up -d

Le résultat est (beaucoup) trop lent ? Allez lire l’article qui suit : Volumes Docker Windows très lent

L’article Docker projet Magento 1.9 sous Windows est apparu en premier sur tech.feub.net.

Ma configuration

Je suis donc parti sur un kit évolution MOBO + CPU + RAM, en AMD – Intel étant de plus en plus à la ramasse. Le reste, j’ai déjà et je garde pour l’instant.

Dans mes recherches j’étais parti sur une carte mère X570 pour le full support PCIe 4.0, mais au final je me suis rendu compte qu’un chipset B550 ferait amplement l’affaire.

Voici ma configuration actuelle :

• CPU : AMD Ryzen 7 3700X
• Carte mère : MSI MAG B550M Mortar
• Mémoire : 32 Gb – 4 x 8 Gb Corsair Vengeance LPX 3200 MHz CAS 16

Pour ce que je garde :

• GPU : MSI GTX 970 4Gb
• Storage :
  • Système : NVMe Seagate FireCuda 510 500 Gb
  • Données : SSD Kingston A400 960 Gb
  • Autre : SSD Samsung 860 EVO 128 Gb

L’article Kit évolution Ryzen 7 chipset B550 est apparu en premier sur tech.feub.net.

La partie HTTP authentication basic de base ressemble à ça :

<Directory "/var/www/html">
	AuthType Basic
	AuthName "Basic Authentication"
	AuthUserFile /etc/httpd/.htpasswd
	require valid-user
</Directory>

Pour ajouter un répertoire en liste blanche de cette authentification, dans mon cas le chemin /var/www/html/.well-known/acme-challenge/ il suffit d’ajouter une directive Directory avec l’option Satisfy Any :

<Directory "/var/www/html/.well-known/acme-challenge/">
	Satisfy Any
</Directory>

Et voilà.

L’article Exclure un répertoire de l’authentification HTTP est apparu en premier sur tech.feub.net.

J’ai installé la dernière version stable d’ES pour CentOS 7, soit la version 7.5, mais j’ai rencontré des problèmes avec Magento 2.3.3, car celui-ci ne prend en charge officiellement que la version 6 d’ES. J’ai donc downgradé ce dernier en version 6.8.6, mais un nouveau problème est survenu : impossible de démarrer le moteur de recherche.

Je n’ai plus le message d’erreur exact rencontré dans le fichier de log /var/log/elasticsearch/elasticsearch.log, mais c’était quelque chose comme :

failed to open /var/lib/elasticsearch/node/0

Après quelque recherche, il s’avère que lors de la mise à jour vers une version plus ancienne, le répertoire data doit être supprimé pour que la version 6 fonctionne et démarre correctement.

Ainsi après la suppression de la version 7.x avec yum remove elasticsearch, il faut supprimer le répertoire /var/lib/elasticsearch, puis installer la version 6.x. Et là, plus de problème, ES démarre et fonctionne.

Pour installer Elasticsearch sous CentOS ou tout autre distribution, c’est ici : https://www.elastic.co/guide/en/elastic-stack/current/index.html

L’article Impossible de démarrer Elasticsearch après un downgrade est apparu en premier sur tech.feub.net.

Ajouter PHP 7.3 à mon serveur

Sur mon serveur web Nginx, je possède plusieurs versions de PHP, notamment un vieux PHP 5.4 pour de vieux projets et PHP 7.0. Je veux mettre à jour mes sites en PHP 7.3 avec les SCL.

Installation de PHP 7.3

yum install php73

L’installation est maintenant faite dans le répertoire /opt/remi/php73, la configuration quant à elle est dans /etc/opt/remi/php73.

Pour installer d’autres modules PHP 7.3, il faut le faire en préfixant les paquets par php73-, comme ceci :

yum install php73-php-json php73-php-pecl-memcached php73-php-xml php73-php-fpm php73-php-mcrypt php73-php-mbstring php73-php-pecl-mysql php73-php-pdo php73-php-pecl-igbinary php73-php-mysqlnd php73-php-gd php73-php-tidy

Configuration du pool de PHP FPM

La configuration du pool se fait dans le fichier /etc/opt/remi/php73/php-fpm.d/www.conf. Par défaut FPM écoute sur un socket TCP, moi j’utilise un socket UNIX, voici le contenu des parties éditées du fichier www.conf, le reste ne change pas :

user = nginx
group = nginx
listen = /var/opt/remi/php73/run/php-fpm/www.sock
listen.owner = nginx
listen.group = nginx
listen.mode = 0666

Je démarre le service PHP FPM pour PHP 7.3 et je l’active au démarrage du serveur :

systemctl start php73-php-fpm
systemctl enable php73-php-fpm

Pour rappel, voici la partie relative à PHP FPM de la configuration d’un server Nginx :

location ~ \.php$ {
        include                         fastcgi_params;
        fastcgi_intercept_errors        on;
        fastcgi_read_timeout            240s;
        fastcgi_pass                    unix:/var/opt/remi/php73/run/php-fpm/www.sock;
        fastcgi_index                   index.php;
        fastcgi_param                   SCRIPT_FILENAME  $document_root	$fastcgi_script_name;
}

Tout site avec cette configuration fastCGI devrait désormais fonctionner avec PHP 7.3.

L’article Installer plusieurs versions de PHP avec les Software Collection sous CentOS 7 est apparu en premier sur tech.feub.net.

La requête ci-dessous retourne la taille à renseigner pour la valeur de la variable innodb_buffer_pool_size :

SELECT 
	CEILING(Total_InnoDB_Bytes*1.6/POWER(1024,3)) RIBPS 
FROM (
	SELECT 
		SUM(data_length+index_length) Total_InnoDB_Bytes
	FROM information_schema.tables 
	WHERE engine='InnoDB'
) A;

Il suffit alors de renseigner cette valeur dans le fichier de configuration /etc/my.cnf :

[mysqld]
innodb_buffer_pool_size=8G

Redémarrer MySQL/MariaDB :

$ sudo systemctl restart mariadb

L’article MySQL/MariaDB : Déterminer la taille recommandée de innodb_buffer_pool_size est apparu en premier sur tech.feub.net.

Il aura fallu une méchante attaque sur un serveur de production pour mettre celui-ci à genoux (et le site d’e-commerce sous Magento qu’il hébergeait) à cause d’un Memcached mal configuré.

Pour les détails techniques de ce type d’attaque par amplification visant Memcached, se reporter à cet article sur le blog de CloudFlare : Memcrashed – Major amplification attacks from UDP port 11211.

Sécuriser Memcached

Par défaut Memcached écoute sur toute les interfaces et sur le protocole UDP. Il faut donc désactiver UDP et le faire écouter seulement en localhost :

$ sudo vim /etc/sysconfig/memcached

Ajouter (ou adapter) ceci dans le champ OPTIONS :

OPTIONS="-l 127.0.0.1 -U 0"

Redémarrage de Memcached :

$ sudo systemctl restart memcached

Vérification que Memcached écoute bien seulement 127.0.0.1 en TCP :

$ sudo netstat -plunt
(...)
tcp 0 0 127.0.0.1:11211 0.0.0.0:* LISTEN 31938/memcached

L’article Sécuriser Memcached pour éviter des attaques par amplification est apparu en premier sur tech.feub.net.

L’exemple de base est de donner un accès au fichiers d’un serveur web qui seront situé sous /var/www, dans mon cas sous CentOS 7.

Configuration du SFTP

• Créer un groupe pour le SFTP :

  $ sudo groupadd sftp_users

• Ajouter un utilisateur (ici web) pour le SFTP :

  $ sudo useradd web

• Ajouter un mot de passe à l’utilisateur web :

  $ sudo passwd web

• Ajouter l’utilisateur web au groupe pour le SFTP et lui attribuer le répertoire par défaut :

  $ sudo usermod -g sftp_users web
  $ sudo usermod -d /var/www web

• Éditer le fichier de configuration du daemon SSH sous /etc/ssh/sshd_config.
  • Commenter la ligne suivante :

    #Subsystem sftp /usr/libexec/openssh/sftp-server

  • Ajouter ce qui suit :

    Subsystem sftp internal-sftp
    
    Match Group sftp_users
    	X11Forwarding no
    	AllowTcpForwarding no
    	ChrootDirectory %h
    	ForceCommand internal-sftp

• Redémarrer le service SSH :

  $ sudo systemctl restart sshd

• S’assurer que les permissions sont correctes pour le chroot, le répertoire /var/www doit appartenir à root et uniquement éditable par le propriétaire.

Test de l’accès SFTP

On teste l’accès en SFTP :

$ sftp web@mon-serveur
web@mon-serveur's password:
Connected to mon-serveur.
sftp> ls -l
drwxrwxr-x 2 0 48 4096 Oct 19 20:39 cgi-bin
drwxrwxr-x 2 0 48 4096 Mar 29 06:12 html
sftp> pwd
Remote working directory: /
sftp>

Test de l’accès SSH

L’accès ssh quant à lui est bien refusé :

$ ssh web@mon-serveur
web@mon-serveur's password:
This service allows sftp connections only.
Connection to mon-serveur closed.

L’article Mettre en place un accès SFTP en jail chroot pour un groupe spécifique est apparu en premier sur tech.feub.net.