KrISS feed 8.7 - Ein einfacher und schlauer (oder dummer) Feed-Reader. Von Tontof
  • Friday 30 June 2017 - 22:41

    Nous allons installer dans cet article la toute dernière version du serveur web NGINX qui sera couplé à PHP7 FPM.

    J'ai longtemps été un fan de Apache httpd que j'utilisais systématiquement en tant que serveur web.
    Mais depuis que j'ai essayé Nginx, je l'ai adopté : il est super performant et consomme beaucoup moins de ressources.

    Pour ce qui est de PHP 7.0, c'est le digne successeur de PHP5 (oui je sais, PHP 6 est passé à la trappe au milieu).

    Cette installation de base sera utilisée par la suite pour ajouter le support de HTTPS et du protocole HTTP/2.

     

    Ajout du dépôt nginx à votre config

    Nous allons installer la dernière version de Nginx. Et même si Debian 9 vient de sortir, il ne propose que Nginx 1.10.3.
    Sur nginx.org, la dernière version stable est la version 1.12.x et la version mainline est en 1.13.x (c'est cette version mainline que nous allons installer)

    Pour cela, nous devons au préalable ajouter le déport officiel de Nginx à notre configuration pour que apt-get puisse trouver cette version.

    Commençons donc par ouvrir le fichier sources.list utilisé par apt-get.

    sudo nano /etc/apt/sources.list

    Puis nous ajoutons la ligne suivante à la fin du fichier.

    deb http://nginx.org/packages/mainline/debian/ stretch nginx

    Les paquets du dépôt nginx sont signés, il faut donc télécharger puis d'installer la clé de chiffrage.

    cd /tmp
    
    wget http://nginx.org/keys/nginx_signing.key
    sudo apt-key add nginx_signing.key

    Enfin, on actualise la liste des paquets.

    sudo apt-get update

     

    Installation de nginx et PHP 7.0 FPM

    On installe en une fois, Nginx et PHP 7.0 FPM plus quelques modules PHP très utiles, voir indispensables yes

    sudo apt-get install nginx php7.0-fpm php7.0-gd php7.0-mysql php7.0-cli php7.0-common php7.0-curl php7.0-opcache php7.0-json php7.0-imap php7.0-mbstring php7.0-xml

    A la fin de l'installation, vous pouvez vérifier les versions installées avec les commandes suivantes :

    sudo php -v
    PHP 7.0.19-1 (cli) (built: May 11 2017 14:04:47) ( NTS )
    Copyright (c) 1997-2017 The PHP Group
    Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
        with Zend OPcache v7.0.19-1, Copyright (c) 1999-2017, by Zend Technologies
    
    sudo nginx -v
    nginx version: nginx/1.13.2

    Le service nginx n'est pas démarré après l'installation. Vous pouvez taper la commande ci-dessous pour le faire manuellement.
    Mais sachez qu'au prochain reboot de Debian, nginx démarrera automatiquement.

    sudo service nginx start

    Si vous ouvrez votre navigateur Internet à l'adresse IP de votre serveur, vous recevrez une réponse de Nginx

     

    Configuration de PHP 7.0 FPM

    Nous allons maintenant configurer PHP 7.0 FPM et Nginx pour qu'ils puissent dialoguer.

    Commençons par ouvrir le fichier de configuration de PHP 7.0 FPM

    sudo nano /etc/php/7.0/fpm/pool.d/www.conf

    Puis on s'assure que ce fichier contient la configuration suivante.
    En résumé, le mode de communication est un socket UNIX (/run/php/php7.0-fpm.sock) et c'est l'utilisateur www-data, du groupe www-data qui l'exécute.

    user = www-data
    group = www-data
    listen = /run/php/php7.0-fpm.sock
    listen.owner = www-data
    listen.group = www-data

    On ouvre ensuite le fichier de configuration de Nginx

    sudo nano /etc/nginx/nginx.conf

    Puis on s'assure que ce fichier contient la configuration suivante.
    Il y a de grande chance que l'utilisateur soit nginx par défaut, remplacez le par www-data

    user www-data;

    On doit maintenant indiquer à Nginx comment traiter les fichiers PHP.
    Pour cela, on ouvre la configuration du vHost par défaut.

    sudo nano /etc/nginx/conf.d/default.conf

    Et on ajoute la configuration suivante

        # pass the PHP scripts to FastCGI server listening on /run/php/php7.0-fpm.sock
        #
        location ~ \.php$ {
            root           /usr/share/nginx/html;
            try_files      $uri =404;
            fastcgi_pass   unix:/run/php/php7.0-fpm.sock;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
            include        fastcgi_params;
        }

    Reste à redémarrer les services PHP 7.0 FPM et Nginx pour activer les modifications.

    sudo service php7.0-fpm restart
    sudo service nginx restart

     

    Vérification du bon fonctionnement de PHP

    L'emplacement des fichiers web publiés par le vHost Nginx par défaut est /usr/share/nginx/html.
    On y va et on ajoute le petit fichier phpinfo.php

    cd /usr/share/nginx/html
    sudo nano phpinfo.php
    

    Puis on ajoute le code suivant dans le fichier phpinfo.php que l'on vient de créer

    <?php   phpinfo(); ?>

    Reste enfin à ouvrir cette page dans votre navigateur pour obtenir smiley

    Si vous souhaitez aller plus loin dans la configuration de Nginx et de PHP 7 FPM, rendez-vous sur l'article suivant.

  • Saturday 01 July 2017 - 10:03

    Dans la continuité de l'article sur l'installation de notre serveur web Nginx et de PHP 7 FPM, nous allons apporter quelques modifications à notre installation.

    Le but est de vous montrer comment procéder pour que vous puissiez ensuite modifier les paramètres qui vous intéressent.

     

    Configuration complémentaire de PHP 7.0 FPM

    Nous allons commencer par configurer PHP 7.0 FPM.

    Comencons par ouvrir le fichier de configuration de PHP 7.0 (après avoir fait une petite copie de sauvegarde...)

    sudo cp /etc/php/7.0/fpm/php.ini /etc/php/7.0/fpm/php.ini.orig
    sudo nano /etc/php/7.0/fpm/php.ini

    Puis vous pouvez modifier les variables ci-dessous.
    date.timezone permet de définir le fuseau horaire de notre serveur
    upload_max_filesize et post_max_size permettent d'augmenter à 32Mo la taille d'un fichier télécharger en POST via PHP.
    error_reporting permet de limiter les infos qui sont enregistrées par défaut dans le fichier de log /var/log/nginx/error.log

    upload_max_filesize = 32M
    post_max_size = 32M
    date.timezone = Europe/Paris
    error_reporting = E_ALL & ~E_WARNING & ~E_NOTICE & ~E_DEPRECATED & ~E_STRICT

    Il y a beaucoup d'autres variables que vous pouvez consulter ici http://php.net/manual/fr/ini.list.php

     

    Configuration complémentaire de Nginx

    On ouvre maintenant le fichier de configuration de Nginx

    sudo nano /etc/nginx/nginx.conf

    Dans ce fichier, localisez la zone http { qui contient les variables à modifier ou ajouter.
    Pour activer la compression des pages par défaut, on décommente la ligne gzip on; et on ajoute les options gzip_... supplémentaires indiquées ci-dessous.
    La commande server_tokens off; permet de masquer la version de Nginx à vos visiteurs (c'est mieux pour la sécurité de votre site).
    Et client_max_body_size 32M; autorise Nginx à uploader des fichiers de 32Mo (c'est en lien direct avec la modification PHP réalisée ci-dessus)

    ...
    http {
        gzip on;
        gzip_static on;
        gzip_http_version 1.1;
        gzip_vary on;
        gzip_comp_level 6;
        gzip_proxied any;
        gzip_types text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript text/x-js image/x-icon;
        gzip_buffers 16 8k;
    
        client_max_body_size 32M;
        server_tokens off;
    ...

    Pour optimiser les performances réseau, je vous conseille également les paramètres ci-dessous.
    Vous devez les copier juste après l'option sendfile on; déja présente dans la config par défaut, toujours dans la section http { du fichier /etc/nginx/nginx.conf 
    Pour les curieux, allez jeter un oeil sur le site suivant qui explique en détail ces paramètres réseau https://t37.net/optimisations-nginx-bien-comprendre-sendfile-tcp-nodelay-et-tcp-nopush.html

    ...
    http {
        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        types_hash_max_size 2048;
    
        keepalive_timeout  65;
    ...

    Pour ceux qui veulent allez plus loin, je vous oriente vers la page http://nginx.org/en/docs/http/ngx_http_core_module.html

     

    Vérification 

    Reste à redémarrer les services PHP 7.0 FPM et Nginx pour activer les modifications.

    sudo service php7.0-fpm restart
    sudo service nginx restart

    Enfin, afficher la page phpinfo() de PHP, vous constaterez la prise en compte de vos nouveaux paramètres.

  • Saturday 01 July 2017 - 10:37

    MariaDB est un système de gestion de base de données édité sous licence GPL.
    Il s'agit d'un fork communautaire de MySQL qui a été racheté par Oracle.

    La migration de MySQL vers MariaDB est très simple car MariaDB est basé sur le code source de MySQL (même si depuis, les 2 systèmes évoluent chacun de leur côté).
    MariaDB est également souvent meilleur que MySQL, grâce à l’amélioration de l’optimiseur de requêtes et au moteur de stockage Aria.

    Dans Debian 9 Stretch, MariaDB est la variante par défaut de MySQL proposée par la distribution.

     

    Installation de MariaDB

    Comme d'habitude, on utilise la commande apt-get pour installer les paquets de MariaDB

    sudo apt-get install mariadb-server

    Une fois que l'installation des composants est terminée, tapez la commande suivante pour finaliser la configuration.

    sudo mysql_secure_installation

    Comme demandé, tapez le mot de passe root de votre Debian.
    Puis répondez Y à toutes les questions suivantes.

    Vous commencerez ainsi par donner un mot de passe à l'utilisateur root de MariaDB différent de l'utilisateur root de votre Debian.
    Cet utilisateur root de la base de données aura tous les droits d'accès, pour des raisons évidentes de sécurité, je vous recommande d'utiliser un mot de passe complexe !

    Ensuite, les connexions anonymes seront désactivées, ainsi que les connexions root qui se font depuis un serveur autre que le votre...

    NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
          SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!
    
    In order to log into MariaDB to secure it, we'll need the current
    password for the root user.  If you've just installed MariaDB, and
    you haven't set the root password yet, the password will be blank,
    so you should just press enter here.
    
    Enter current password for root (enter for none):
    OK, successfully used password, moving on...
    
    Setting the root password ensures that nobody can log into the MariaDB
    root user without the proper authorisation.
    
    You already have a root password set, so you can safely answer 'n'.
    
    Change the root password? [Y/n] y
    New password:
    Re-enter new password:
    Password updated successfully!
    Reloading privilege tables..
     ... Success!
    
    By default, a MariaDB installation has an anonymous user, allowing anyone
    to log into MariaDB without having to have a user account created for
    them.  This is intended only for testing, and to make the installation
    go a bit smoother.  You should remove them before moving into a
    production environment.
    
    Remove anonymous users? [Y/n] y
     ... Success!
    
    Normally, root should only be allowed to connect from 'localhost'.  This
    ensures that someone cannot guess at the root password from the network.
    
    Disallow root login remotely? [Y/n] y
     ... Success!
    
    By default, MariaDB comes with a database named 'test' that anyone can
    access.  This is also intended only for testing, and should be removed
    before moving into a production environment.
    
    Remove test database and access to it? [Y/n] y
     - Dropping test database...
     ... Success!
     - Removing privileges on test database...
     ... Success!
    
    Reloading the privilege tables will ensure that all changes made so far
    will take effect immediately.
    
    Reload privilege tables now? [Y/n] y
     ... Success!
    
    Cleaning up...
    
    All done!  If you've completed all of the above steps, your MariaDB
    installation should now be secure.
    
    Thanks for using MariaDB!

    C'est terminé : MariaDB est installé !

     

    Configuration de MariaDB

    L'installation par défaut de MariaDB sous Debian 9 applique une restriction à l'utilisateur root.

    Lorsque vous essayerez de vous connecter à MariaDB avec la commande mysql -u root -p vous obtiendrez une erreur Access denied for user 'root'@'localhost'

    # mysql -u root -p
    Enter password:
    ERROR 1698 (28000): Access denied for user 'root'@'localhost'

    Pour remédier à ce problème, connectez vous à MariaDb avec sudo

    sudo mysql -u root -p

    Une fois que vous aurez taper le bon mot de passe, cette fois vous serez connecté.
    Tapez alors la commande USE mysql; qui vous connectera à la base de données mysql contenant la configuration du serveur.
    Puis tapez la requête SELECT plugin FROM user WHERE user='root';

    Enter password:
    Welcome to the MariaDB monitor.  Commands end with ; or \g.
    Your MariaDB connection id is 11
    Server version: 10.1.23-MariaDB-9+deb9u1 Debian 9.0
    
    Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
    
    Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
    
    MariaDB [(none)]> USE mysql;
    Reading table information for completion of table and column names
    You can turn off this feature to get a quicker startup with -A
    
    Database changed
    MariaDB [mysql]> SELECT plugin FROM user WHERE user='root';
    +-------------+
    | plugin      |
    +-------------+
    | unix_socket |
    +-------------+
    1 row in set (0.00 sec)

    C'est à cause de ce plugin unix_socket que la connexion root est refusée lorsqu'on se connecte à la base sans sudo.

    Pour remédier au problème, tapez la requête UPDATE user SET plugin='' WHERE User='root'; qui supprimera ce plugin pour l'utilisateur root.
    Recharger les privilèges utilisateurs avec la commande FLUSH PRIVILEGES; puis quitter MariaDb avec la commande EXIT;

    MariaDB [mysql]> UPDATE user SET plugin='' WHERE User='root';
    Query OK, 1 row affected (0.00 sec)
    Rows matched: 1  Changed: 1  Warnings: 0
    
    MariaDB [mysql]> FLUSH PRIVILEGES;
    Query OK, 0 rows affected (0.00 sec)
    
    MariaDB [mysql]> EXIT;
    Bye

    A présent, si vous essayez à nouveau de vous connecter au serveur sans sudo, avec mysql -u root -p, ca fonctionnera.

    mysql -u root -p
    	Enter password:
    	Welcome to the MariaDB monitor.  Commands end with ; or \g.
    	Your MariaDB connection id is 20
    	Server version: 10.1.23-MariaDB-9+deb9u1 Debian 9.0
    
    	Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
    
    	Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
    
    	MariaDB [(none)]>

     

    Connexion sur votre base de données

    Pour accéder/administrer notre serveur et nos base de données, nous allons utiliser Adminer.
    Adminer, c'est comme phpMyAdmin mais en beaucoup plus light : il se compose d'un seul fichier prêt à être déployer sur le serveur cible.

    En plus, Adminer est disponible pour MySQL, PostgreSQL, SQLite, MS SQL, Oracle, Firebird, SimpleDB, ElasticSearch et MongoDB.

    On se déplace donc dans la racine de notre vHost puis on télécharge Adminer pour mySQL (seuelement 426 ko dans cette version 4.3.1)

    cd /usr/share/nginx/html
    sudo wget https://github.com/vrana/adminer/releases/download/v4.3.1/adminer-4.3.1.php

    Ensuite, il suffit d'accéder au fichier PHP et vous arrivez sur une page de connexion sur serveur de base de données MariaDB.

    Une fois connecté, vous arrivez sur une interface très similaire à phpMyAdmin.
    Pour un seul fichier PHP de moins de 500ko, c'est quand même super impressionnant smiley.

     

  • Saturday 01 July 2017 - 15:32

    Introduction

    Si vous êtes ici, c'est que vous avez au moins un serveur et au moins un nom de domaine.
    Mais rien ne vous empêche de faire pointer plusieurs noms de domaine (ou des sous-domaine, images.geek17.com par exemple) sur un seul et même serveur.

    De même, votre serveur fait office de serveur web (nginx + MariaDB) mais il va certainement héberger d'autres services (serveur mail via postfix par exemple).

    Il est donc important d'identifier de manière unique votre serveur sur le web en spécifiant un hostname (nom d'hote) et en configurant vos DNS en conséquence.

    Prenons l'exemple concret de geek17.com

    • j'ai un serveur pour héberger le site web de geek17.com
    • j'héberge également d'autres sites : toto1.com et toto2.com
    • j'ai une seule adresse IP : 123.456.789.123
    • mon serveur héberge et réceptionne les mails des 3 domaines geek17.com, toto1.com et toto2.com

    J'ai décidé de nommer mon serveur server1.geek17.com

    Mais vous pouvez utiliser n'importe quel nom (en évitant les caractères spéciaux et accentués), suivi d'une de votre nom de domaine.

     

    Ajout de l'enregistrement CNAME dans vos DNS

    Rendez-vous dans l'interface de gestion de votre nom de domaine.

    Les données de votre zone DNS sont présentées sous la forme d'un tableau de 3 colonnes.

    Champ Type Cible
      A 123.456.789.123
    www CNAME geek17.com.
    server1 CNAME geek17.com.

    Vous devez à minima avoir une entrée de Type A, dont le Champ est vide et qui contient votre adresse IP en Cible.
    C'est grâce à cette entrée que quand vous tapez votre nom de domaine dans votre navigateur web, celui-ci contacte l'adresse IP de votre serveur pour charger les données.

    Mais vous avez peut-être également une entrée de Type CNAME et dont le Champ est www et la Cible est votre nom de domaine avec un . à la fin
    Cette entrée permet à votre navigateur de contacter la même adresse IP que pour geek17.com si vous taper www.geek17.com pour accéder au site.

    Enfin, vous comprenez logiquement que l'entrée Type CNAME et avec le Champ est server1 permet exactement la même chose qu'avec www.
    C'est mon IP qui est contacter en cas de contact sur server1.geek17.com

    A titre d'info, j'aurai également pu utiliser une entrée de Type A, en indiquant Champ = server1 et l'adresse IP de mon serveur en Cible 

    Champ Type Cible
    server1 A 123.456.789.123

    On utilise les entrées de type A pour pointer vers une adresse IP et les entrées de type CNAME pour pointer vers un domaine.

     

    Configuration du reverse DNS

    Rendez-vous à présent dans l'interface d'administration de votre serveur et localisez la fonction "Modifier le Reverse DNS", exemple ci-dessous pour mon VPS OVH.

    Il vous reste à indiquer le nom complet server1.geek17.com qui sera renvoyé lors des demandes de reverse DNS.

    C'est en fait le fonctionnement inverse du DNS, cette fois-ci on connait l'adresse IP mais on veut savoir à quel serveur elle correspond.
    Et c'est donc server1.geek17.com qui sera renvoyé lors des demandes de Reverse DNS sur mon adresse IP 123.456.789.123

    Configuration du serveur Debian

    Bon, nos DNS sont configurés, passons maintenant à la configuration du serveur.

    Commencez par taper les commandes hostname et hostname -f dans le shell de  votre serveur pour voir l'identification actuelle de votre serveur.
    Dans l'exemple ci-dessous, c'est la config de mon VPS OVH après installation.

    $ hostname
    vps123456
    $ hostname -f
    vps123456.ovh.net

    Commençons par changer le hostname, pour cela ouvrez le fichier /etc/hostname

    sudo nano /etc/hostname

    Dans mon cas, ce fichier contenani vps123456 que j'ai remplacé par server1
    Ne mettez pas le nom de domaine dans ce fichier !

    Reste le fichier /etc/hosts à mettre à jour, 

    sudo nano /etc/hosts

    Dans le cas de mon VPS OVH, le fichier contenait 

    # Your system has configured 'manage_etc_hosts' as True.
    # As a result, if you wish for changes to this file to persist
    # then you will need to either
    # a.) make changes to the master file in /etc/cloud/templates/hosts.tmpl
    # b.) change or remove the value of 'manage_etc_hosts' in
    #     /etc/cloud/cloud.cfg or cloud-config from user-data
    #
    127.0.1.1 vps123456.ovh.net vps123456
    127.0.0.1 localhost

    Et j'ai remplacé la ligne 127.0.1.1 vps123456.ovh.net vps123456

    #127.0.1.1 vps123456.ovh.net vps123456
    127.0.0.1 server1.geek17.com server1

    Reste à redémarrer le serveur et c'est bon !  Sauf si vous avez un VPS OVH comme moi wink

    sudo reboot

     

    OVH utilise en effet un service cloud installé sur mon VPS et qui écrase le fichier nano /etc/hosts avec les données provenant d'un fichier template.
    Du coup, après le reboot, je retrouvai la ligne 127.0.1.1 vps123456.ovh.net vps123456 active et plus de trace de mon server1

    Rien de bien compliqué en fait, il suffit de modifier la valeur du template utilisée par le service cloud.
    Elle se trouve dans le fichier /etc/cloud/cloud.cfg

    sudo nano /etc/cloud/cloud.cfg

    Au tout début de ce fichier, replacer l'entrée vps123456... par server1....

    #hostname: vps123456.ovh.net
    hostname: server1.geek17.com

    Et cette fois, après un reboot, c'est tout bon !

    Pensez à vérifier avec la commande hostname

    $ hostname
    server1
    $ hostname -f
    server1.geek17.com

     

  • Saturday 01 July 2017 - 16:31

    Je vous propose dans cet article de passer votre site, propulsé par nginx, en version sécurisé HTTPS, le tout gratuitement grace à Let’s Encrypt.
    Let’s Encrypt propose en effet des certificats gratuits et un outil de mise en oeuvre.

    L'HyperText Transfer Protocol Secure, plus connu sous l'abréviation HTTPS — littéralement « protocole de transfert hypertexte sécurisé » — est la combinaison du HTTP avec une couche de chiffrement comme SSL ou TLS.

    Les données transitant entre le site web et l'utilisateur sont ainsi chiffrées et ne sont plus transmissent en claire sur internet (comme les mots de passe sur un formulaire de connexion non sécurisé...).

     

    Installation du client Let’s Encrypt

    Le client Let’s Encrypt est disponible dans le dépôt Debian, il s'appelle cerbot et on lance son installation.

    sudo apt-get install certbot

    Une fois le client installé, vous pouvez afficher les options d'utilisation avec la commande certbot --help

    certbot --help
    
      certbot [SUBCOMMAND] [options] [-d DOMAIN] [-d DOMAIN] ...
    
    Certbot can obtain and install HTTPS/TLS/SSL certificates.  By default,
    it will attempt to use a webserver both for obtaining and installing the
    cert. The most common SUBCOMMANDS and flags are:
    
    obtain, install, and renew certificates:
        (default) run   Obtain & install a cert in your current webserver
        certonly        Obtain or renew a cert, but do not install it
        renew           Renew all previously obtained certs that are near expiry
       -d DOMAINS       Comma-separated list of domains to obtain a cert for
    
      (the cerbot apache plugin is not installed)
      --standalone      Run a standalone webserver for authentication
      (the certbot nginx plugin is not installed)
      --webroot         Place files in a server's webroot folder for authentication
      --manual          Obtain certs interactively, or using shell script hooks
    ...

     

    Génération du certificat SSL

    Nous allons générer un certificat SSL qui sera utilisable pour le domaine geek17.com ainsi que pour le sous-domaine www.geek17.com

    Pour cela, nous allons exécuter la commande suivante

    sudo certbot certonly --webroot -w /usr/share/nginx/geek17.com -d www.geek17.com -d geek17.com --email xxx@geek17.com --rsa-key-size 4096 --agree-tos

    Dans cet exemple, j'ai spécifié :

    • l'emplacement racine des fichiers de mon site web /usr/share/nginx/geek17.com avec l'option -w
    • 2 domaines : www.geek17.com et geek17.com avec l'option -d
    • une clé RSA 4096 bits est utilisée au lieu d'une clé 2048 bits par défaut
    • un email de contact. Il est très important de spécifier un adresse email valide car vous recevrez les infos d'expiration du certificat à cette adresse.

    Pour vérifier que vous êtes bien le propriétaire des domaines spécifiés, le client Let’s Encrypt va créer un fichier avec un contenu spécifique dans le dossier /.well-known/acme-challenge de votre site web.
    Donc dans /usr/share/nginx/geek17.com/.well-known/acme-challenge pour moi.

    Le serveur Let’s Encrypt tente ensuite d'accéder à ce fichier http://www.geek17.com/.well-known/acme-challenge/xxxxx pour valider que vous êtes bien le propriétaire du serveur.

    Vous obtiendrez le message ci-dessous si tout se passe bien pendant la vérification.

    IMPORTANT NOTES:
     - Congratulations! Your certificate and chain have been saved at
       /etc/letsencrypt/live/server1.geek17.com/fullchain.pem. Your
       cert will expire on 2017-09-25. To obtain a new or tweaked version
       of this certificate in the future, simply run certbot again. To
       non-interactively renew *all* of your certificates, run "certbot
       renew"
     - If you lose your account credentials, you can recover through
       e-mails sent to contact@interestuff.com.
     - Your account credentials have been saved in your Certbot
       configuration directory at /etc/letsencrypt. You should make a
       secure backup of this folder now. This configuration directory will
       also contain certificates and private keys obtained by Certbot so
       making regular backups of this folder is ideal.
     - If you like Certbot, please consider supporting our work by:
    
       Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
       Donating to EFF:                    https://eff.org/donate-le

     

    Configuration du vHost nginx

    Ouvrer la configuration de votre vhost

    sudo nano /etc/nginx/conf.d/www.geek17.com.conf

    Puis ajouter une entrée server qui écoute sur le port 443.
    J'ai ajouté en même temps l'option http2 à la chaine d'écoute. Et cela suffit pour que votre serveur web soit maintenant compatible HTTP/2 !
    Vous remarquerez que l'emplacement de nos certificats SSL est spécifiée avec les options ssl_certificate et  ssl_certificate_key

    ....
    
    server {
        listen 0.0.0.0:443 ssl http2;
        server_name  www.geek17.com geek17.com;
    
        root  /home/dev/www/www.geek17.com;
        index  index.php index.html index.htm;
    
        ssl on;
        ssl_certificate /etc/letsencrypt/live/www.geek17.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/www.geek17.com/privkey.pem;
    }

    Reste à redémarrer nginx pour activer la modification

    sudo service nginx restart

    Maintenant, si vous ouvrez l'adresse de votre site web en mettant https:// devant, le cadenas vert indique que vous avez un certificat valide smiley

     

    Expiration du certificat...

    Les certificats délivrés par Let’s Encrypt ne sont valides que 90 joursindecision.
    Mais la bonne nouvelle, c'est qu'ils vont se renouveler automatiquement !

    En effet, un job cron est automatiquement créé à l'installation de certbot (etc/cron.d/certbot) et il se charge de renouvelez automatiquement les certificats générés sur le serveur.
    Il utilisera les mêmes paramètres que ceux utilisés à la création du certificat et qui sont stockés dans /etc/letsencrypt/renewal

    Le job cron exécute la commande cerbot renew que vous pouvez aussi lancer à la main quand vous le souhaitez via sudo certbot renew
    Le certificat sera renouvelé que s'il est proche de la date d'expiration !

    Vous pouvez également simuler (sans aucune modification) le renouvellement avec la commande sudo certbot renew --dry-run

     

    Aller plus loin...

    Il est possible d'améliorer l'efficacité et la sécurité de votre site HTTPS : Nginx : améliorer la sécurité et la rapidité de votre site HTTPS

    Enfin, pour rediriger automatiquement vos visiteurs vers la version sécurisée HTTPS de votre site, suivez cet article Nginx : rediriger toutes vos url vers votre site HTTPS

    Tags: 
  • Sunday 09 July 2017 - 11:34

    Introduction

    iptables est une interface qui permet de configurer le firewall interne de votre Debian.

    La commande iptables -L vous permet d'afficher la configuration IP V4 de votre serveur

    sudo iptables -L

    Cette configuration par défaut ne filtre aucun traffic. Tout est authorisé : en entrée, en sortie et en transfert.

    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination
    
    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination
    
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination
    

    La commande ip6tables s'utilise de la même manière que iptables mais affiche les infos relatives à IP V6.

     

    Garder votre config après un reboot

    iptables fonctionne très bien mais son problème principal, c'est qu'après un reboot, toutes les règles sont perdues, il repart à 0.

    Pour pouvoir définir des règles persistantes après un reboot, j'utilise le paquet iptables-persistent.
    On commence donc par l'installer.

    sudo apt-get install iptables-persistent

    Pendant, l'installation du paquet, on vous est demande si vous souhaitez que les règles actuellement en cours d'utilisation soient enregistrées dans le fichier .

    Répondez Oui, pour IP V4 comme pour IP V6.

     

    Configuration des règles de votre firewall

    Comme vous l'avez compris pendant l'installation, il a y 2 fichiers de config :

    • pour IP V4 c'est /etc/iptables/rules.v4
    • pour IP V6 c'est /etc/iptables/rules.v6

    On va commencer par IP V6 pour lequel nous allons bloquer tout le trafic. On ouvre donc /etc/iptables/rules.v6

    sudo nano /etc/iptables/rules.v6

    La configuration par défaut est la suivante :

    # Generated by iptables-save v1.6.0 on Sun Jul  9 15:04:15 2017
    *filter
    :INPUT ACCEPT [0:0]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    COMMIT
    # Completed on Sun Jul  9 15:04:15 2017
    

    Et on va la remplacer par celle ci-dessous. J'ai juste remplacé ACCEPT par DROP sur les 3 traffcs réseau.

    # Generated by ip6tables-save v1.6.0 on Sun Jul  9 15:04:15 2017
    *filter
    :INPUT DROP [0:0]
    :FORWARD DROP [0:0]
    :OUTPUT DROP [0:0]
    COMMIT
    # Completed on Sun Jul  9 15:04:15 2017
    

     

    Passons maintenant à IP V4

    sudo nano /etc/iptables/rules.v4

    Il a la même config par défaut que IP V6.

    Dans la configuration que je vous propose :

    • je bloque tout le traffic transfert (FORWARD)
    • je laisse le traffic sortant non filtré
    • Je bloque le traffic entrant et j'applique des règles dessus

    Et on édite notre configuration.
    Vous pouvez bien sur l'adapter à vos besoins. J'ai commenté chaque ligne pour vous aider à comprendre

    # Generated by iptables-save v1.6.0 on Sat Jul  8 16:56:03 2017
    *filter
    :INPUT DROP [0:0]
    :FORWARD DROP [0:0]
    :OUTPUT ACCEPT [687:218631]
    
    # Allow internal traffic on the loopback device
    -A INPUT -i lo -j ACCEPT
    
    # Continue connections that are already established or related to an established connection
    -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    
    # Drop non-conforming packets, such as malformed headers, etc.
    -A INPUT -m conntrack --ctstate INVALID -j DROP
    
    # SSH
    -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
    
    # DHCP used by OVH
    -A INPUT -p udp --dport 67:68 --sport 67:68 -j ACCEPT
    
    # DNS (bind)
    -A OUTPUT -p tcp --dport 53 -j ACCEPT
    -A OUTPUT -p udp --dport 53 -j ACCEPT
    
    # HTTP + HTTPS
    -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT
    
    # Email (postfix + devecot)
    # 25 = smtp, 587 = submission and 993 = IMAPS
    -A INPUT -p tcp -m multiport --dports 25,587,993 -j ACCEPT
    
    # NTP
    -A INPUT -p udp --dport 123 -j ACCEPT
    
    # Chain for preventing ping flooding - up to 6 pings per second from a single
    # source, again with log limiting. Also prevents us from ICMP REPLY flooding
    # some victim when replying to ICMP ECHO from a spoofed source.
    -N ICMPFLOOD
    -A ICMPFLOOD -m recent --name ICMP --set --rsource
    -A ICMPFLOOD -m recent --name ICMP --update --seconds 1 --hitcount 6 --rsource --rttl -m limit --limit 1/sec --limit-burst 1 -j LOG --log-prefix "iptables[ICMP-flood]: "
    -A ICMPFLOOD -m recent --name ICMP --update --seconds 1 --hitcount 6 --rsource --rttl -j DROP
    -A ICMPFLOOD -j ACCEPT
    
    # Permit useful IMCP packet types.
    # Note: RFC 792 states that all hosts MUST respond to ICMP ECHO requests.
    # Blocking these can make diagnosing of even simple faults much more tricky.
    # Real security lies in locking down and hardening all services, not by hiding.
    -A INPUT -p icmp --icmp-type 0  -m conntrack --ctstate NEW -j ACCEPT
    -A INPUT -p icmp --icmp-type 3  -m conntrack --ctstate NEW -j ACCEPT
    -A INPUT -p icmp --icmp-type 8  -m conntrack --ctstate NEW -j ICMPFLOOD
    -A INPUT -p icmp --icmp-type 11 -m conntrack --ctstate NEW -j ACCEPT
    
    # Drop all incoming malformed NULL packets
    -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
    
    # Drop syn-flood attack packets
    -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j DROP
    
    # Drop incoming malformed XMAS packets
    -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
    
    COMMIT
    # Completed on Sat Jul  8 16:56:03 2017
    
    

    Enfin, on redémarre le service pour recharger et appliquer nos règles.
    Le service s'appele netfilter-persistent, pas iptables...

    sudo service netfilter-persistent restart

    Et on vérifie qu'elles ont bien été chargées.

    sudo iptables -L

    Ca donne

    Chain INPUT (policy DROP)
    target     prot opt source               destination
    ACCEPT     all  --  anywhere             anywhere
    ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
    DROP       all  --  anywhere             anywhere             ctstate INVALID
    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
    ACCEPT     udp  --  anywhere             anywhere             udp spts:bootps:bootpc dpts:bootps:bootpc
    ACCEPT     tcp  --  anywhere             anywhere             multiport dports http,https
    ACCEPT     tcp  --  anywhere             anywhere             multiport dports smtp,submission,imaps
    ACCEPT     udp  --  anywhere             anywhere             udp dpt:ntp
    ACCEPT     icmp --  anywhere             anywhere             icmp echo-reply ctstate NEW
    ACCEPT     icmp --  anywhere             anywhere             icmp destination-unreachable ctstate NEW
    ICMPFLOOD  icmp --  anywhere             anywhere             icmp echo-request ctstate NEW
    ACCEPT     icmp --  anywhere             anywhere             icmp time-exceeded ctstate NEW
    DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE
    DROP       tcp  --  anywhere             anywhere             tcp flags:!FIN,SYN,RST,ACK/SYN ctstate NEW
    DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
    
    Chain FORWARD (policy DROP)
    target     prot opt source               destination
    
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination
    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
    ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
    
    Chain ICMPFLOOD (1 references)
    target     prot opt source               destination
               all  --  anywhere             anywhere             recent: SET name: ICMP side: source mask: 255.255.255.255
    LOG        all  --  anywhere             anywhere             recent: UPDATE seconds: 1 hit_count: 6 TTL-Match name: ICMP side: source mask: 255.255.255.255 limit: avg 1/sec burst 1 LOG level warning prefix "iptables[ICMP-flood]: "
    DROP       all  --  anywhere             anywhere             recent: UPDATE seconds: 1 hit_count: 6 TTL-Match name: ICMP side: source mask: 255.255.255.255
    ACCEPT     all  --  anywhere             anywhere

     

    Sources

  • Sunday 09 July 2017 - 13:12

    C'est quoi Fail2ban ?

    Fail2ban lit des fichiers de log présents sur votre serveur pour détecter les adresses IP essayant d'accéder à vos services en générant de nombreux échecs lors de l'authentification.
    Fail2ban bannit ces adresses IP suspectes en mettant à jour les règles du pare-feu pour rejeter ces adresses.

    Ces règles peuvent être définies par l'utilisateur. Fail2ban peut lire plusieurs fichiers de log comme ceux de sshd ou du serveur nginx.

     

    Installation de Fail2ban

    On commence par installer le paquet.

    sudo apt-get install fail2ban

    Le fichier /etc/fail2ban/jail.conf contient l'ensemble des plugins que vous pouvez activer pour protéger les services de votre serveur.
    Mais vous ne devez pas modifier ce fichier directement. Car lors des mises à jour de votre Debian, il peut être remplacé à tout moment avec une version plus récente.

    nano /etc/fail2ban/jail.conf

    Fail2ban permet de surveiller et de protéger de nombreux services sur votre serveur : SSH, nginx, postfix, FTP...
    La configuration de chaque service est contenu dans une section spécifique [sshd] pour le service SSH qui est le seul actif par défaut.

    Pour activer la surveillance d'un service, il faut placer la variable enabled à true dans la section du service.
    Si vous avez modifier le port par défaut de SSH (pour ne pas utiliser 22), pensez de l'indiquer ici dans la variable port.

    Pour activer et configurer les plugins de votre choix, ça se passe donc dans /etc/fail2ban/jail.d/defaults-debian.conf

    sudo nano /etc/fail2ban/jail.d/defaults-debian.conf

    Par défaut, vous constaterez que le plugin sshd est activé. Grâce à la ligne

    [sshd]
    enabled = true

    Ce plugin surveille les tentatives de connexions SSH sur votre serveur.
    Si Fail2ban détecte 5 tentatives de connexion erronées durant les 600 dernières secondes (soit 10 minutes), l'IP ayant essayé de se connecter sera bloquée 600s (10 min).

    Ces constantes sont définies de manières globales pour tous les plugins.

    # "bantime" is the number of seconds that a host is banned.
    bantime  = 600
    
    # A host is banned if it has generated "maxretry" during the last "findtime"
    # seconds.
    findtime  = 600
    
    # "maxretry" is the number of failures before a host get banned.
    maxretry = 5
    

    Mais depuis votre fichier defaults-debian.conf, vous pouvez les sur-définir au niveau de la configuration d'un plugin.

    [sshd]
    enabled = true
    # 1 jour de bannissement
    bantime  = 86400

    Ou de manière globale pour tous les plugins

    [DEFAULT]
    # 1 jour de bannissement pour tous les plugins
    bantime = 86400

     

    Ne pas vous faire bannir de votre serveur !

    Je vous recommande d'exclure votre adresse IP personnelle du scope de Fail2ban. Ca vous évitera de vous faire bannir de votre propre serveur !
    Pour cela, ouvrez le fichier de configuration /etc/fail2ban/jail.d/defaults-debian.conf

    sudo nano /etc/fail2ban/jail.d/defaults-debian.conf

    Et ajouter la variable ignoreip  dans la section [DEFAULT] du fichier.
    Remplacez 123.456.789.123 par votre adresse IP (ou vos adresses).

    [DEFAULT]
    ignoreip = 127.0.0.1/8 123.456.789.123

     

    Ca fonctionne ?

    Après quelques jours de fonctionnement de Fail2ban, allez jeter un coup d'oeil dans son fichier de log

    sudo nano /var/log/fail2ban.log

    Vous serez très surpris de voir le nombre de connexions SSH bloquées par fail2ban...
    Il y a plein de robots sur Internet qui scannent les serveurs à la recherche de vulnérabilités

    2017-07-03 14:16:52,587 fail2ban.actions[698]: WARNING [ssh] Ban 181.22.18.162
    2017-07-03 14:22:09,770 fail2ban.actions[698]: WARNING [ssh] Unban 114.241.70.201
    2017-07-03 14:39:37,357 fail2ban.actions[698]: WARNING [ssh] Unban 103.89.88.102
    2017-07-03 14:41:59,442 fail2ban.actions[698]: WARNING [ssh] Ban 168.195.228.195
    2017-07-03 14:52:37,801 fail2ban.actions[698]: WARNING [ssh] Ban 31.162.87.148
    2017-07-03 15:20:51,747 fail2ban.actions[698]: WARNING [ssh] Ban 193.201.224.199
    2017-07-03 15:31:31,149 fail2ban.actions[698]: WARNING [ssh] Ban 119.29.237.54
    2017-07-03 16:33:25,275 fail2ban.actions[698]: WARNING [ssh] Unban 116.31.116.52
    2017-07-03 16:34:29,324 fail2ban.actions[698]: WARNING [ssh] Ban 116.31.116.52
    2017-07-03 16:44:47,672 fail2ban.actions[698]: WARNING [ssh] Unban 182.100.67.120
    2017-07-03 16:56:10,059 fail2ban.actions[698]: WARNING [ssh] Ban 119.193.140.168
    2017-07-03 17:21:58,888 fail2ban.actions[698]: WARNING [ssh] Ban 174.103.145.178

     

    Configuration de plugins additionnels

    Pour activer et configurer les plugins de votre choix, ça se passe donc dans /etc/fail2ban/jail.d/defaults-debian.conf

    sudo nano /etc/fail2ban/jail.d/defaults-debian.conf

    Voici un exemple de config qui protège postfix et dovecot

    [DEFAULT]
    # 1 jour de bannissement pour tous les plugins
    bantime = 86400
    
    [sshd]
    enabled = true
    # 3 mots de passe erronés consécutifs et c'est le bannissement direct pour SSH
    maxretry = 3
    
    [postfix]
    port = smtp,submission
    enabled = true
    
    [dovecot]
    port = imaps
    enabled = true
    

    N'oubliez pas de redémarrer le service Fail2ban pour activer vos modifications

    sudo service fail2ban restart

     

  • Sunday 09 July 2017 - 18:30

    Introduction

    Munin est un système de monitoring permettant de suivre l'utilisation des ressources et des services d'un serveur :

    • charge du processeur
    • utilisation de la mémoire RAM
    • utilisation des disques : temps d'accès, débit...
    • nombre de connexions sur une base MySQL
    • nombre de connexions simultanées sur votre serveur web : apache ou nginx
    • réseau...

    Munin est une application client/serveur, elle est donc décomposée en deux paquets principaux munin et munin-node :

    • munin (le serveur) : il récupère les données issues de la ou des machines surveillées, il génère les pages web de consultation et les graphiques associés.
    • munin-node (le client) : il collecte les mesures et les informations sur le serveur à surveiller.

    Dans cet article, nous installons installer les 2 paquets sur notre serveur.

     

    Installation des paquets

    Comme d'habitude, on utilise la commande apt-get qui va bien pour installer le serveur et le client.
    On installe également le paquet munin-plugins-extra qui ajoute quelques plugins supplémentaire que l'on verra par la suite.

    sudo apt-get install munin munin-node munin-plugins-extra

     

    Ajout de Munin dans la configuration du vHost par défaut de notre serveur

    Par défaut Munin génère le contenu HTML et les graphiques dans le répertoire /var/cache/munin/www.

    On ouvre donc le vHost par défaut 

    sudo nano /etc/nginx/conf.d/default.conf
    

    Et on ajoute

    server {
        ....
        # Munin -- Début
        location /munin {
            alias /var/cache/munin/www/;
            index index.html;
        }
    
        location /munin/static/ {
            alias /etc/munin/static/;
            expires modified +1w;
        }
        # Munin -- Fin
        ....
    }

    Puis on redémarre Nginx pour prendre en compte les modifications.

    sudo service nginx restart

     

    Consultation des données de monitoring

    Pour accéder à l'interface de Munin, il vous suffit d'ouvrir une page à l'adresse http://<IP de votre serveur>/munin

    Par défaut, une tache cron se lance toutes les 5 minutes pour lire les données à collecter et mettre à jour les graphiques.
    Les graphiques sont en réalités des images PNG qui sont générées après chaque lecture (toutes les 5 minutes donc).

    La charge CPU générée par la création des images est limitée si vous avez un seul serveur à monitorer et si vous n'avez pas trop de plugin installés...
    Mais il est possible de modifier ce fonctionnement par défaut de Munin en lui demandant de générer les images en live uniquement lorsqu'on souhaite les consulter (via FCGI).
    FCGI est également obligatoire (avec nginx) si vous souhaitez zoomer à l'intérieur des graphiques.

    Vous pouvez suivre la mise en place de FCGI dans le prochain article Configurer Munin avec Spawn-fgci sous nginx

     

  • Sunday 09 July 2017 - 18:37

    Nous avons vu dans l'article précédent comment installer Munin pour monitorer les performances de son serveur.

    Dans cet article, nous allons configurer Munin pour qu'il ne génère plus les images des graphiques à chaque lecture des données monitorées.
    Il utilisera à la place des scripts FCGI pour les générer en live lorsque l'on consultera les données.
    Cela permet de limiter la charge CPU du serveur qui ne sera plus sollicité toutes les 5 minutes pour rafraichir les graphiques.

     

    Installation de Spawn-fgci

    On installe tout d'abords le paquet Spawn-fgci
    J'installe aussi libcgi-fast-perl pour être certain que ce package soit installé. Sinon, vous aurez le message spawn-fcgi: child exited with: 2 au démarrage des sockets et vous chercherez longtemps pourquoi...

    sudo apt-get install spawn-fcgi libcgi-fast-perl

    Puis nous démarrons les 2 sockets FCGI qui se chargeront de générer les graphiques et les pages HTML de Munin, lors de la consultation.

    sudo spawn-fcgi -s /var/run/munin/fcgi-graph.sock -U www-data -u www-data -g www-data /usr/lib/munin/cgi/munin-cgi-graph
    sudo spawn-fcgi -s /var/run/munin/fcgi-html.sock -U www-data -u www-data -g www-data /usr/lib/munin/cgi/munin-cgi-html

    A titre d'info, si vous avez une erreur au démarrage du socket, ajoutez -n à la ligne de commande pour obtenir plus de détails sur les raisons de l'erreur smiley

     

    Création d'un service pour démarrer Spawn-fgci

    Nous allons maintenant ajouter un script qui lancera automatiquement ces 2 lignes de commandes au démarrage du serveur

     sudo nano /etc/init.d/munin-fastcgi

    Voici le contenu du script

    #! /bin/sh
    ### BEGIN INIT INFO
    # Provides:          munin-fastcgi
    # Required-Start:    $remote_fs $network
    # Required-Stop:     $remote_fs $network
    # Default-Start:     2 3 4 5
    # Default-Stop:      0 1 6
    # Short-Description: starts munin-fastcgi
    # Description:       Spawn Munin FCGI sockets for Graph an HTML
    ### END INIT INFO
    
    #
    # Sources:
    # https://www.geek17.com/fr/content/debian-9-stretch-configurer-munin-avec-spawn-fgci-sous-nginx-74
    #
    
    DAEMON=/usr/bin/spawn-fcgi
    FCGI_GRAPH_SOCK=/var/run/munin/fcgi-graph.sock
    FCGI_HTML_SOCK=/var/run/munin/fcgi-html.sock
    WWW_USER=www-data
    FCGI_USER=www-data
    FCGI_GROUP=www-data
    FCGI_SPAWN_GRAPH=/usr/lib/munin/cgi/munin-cgi-graph
    FCGI_SPAWN_HTML=/usr/lib/munin/cgi/munin-cgi-html
    PIDFILE_GRAPH=/var/run/munin/fastcgi-munin-graph.pid
    PIDFILE_HTML=/var/run/munin/fastcgi-munin-html.pid
    DESC="Munin FCGI for Graph an HTML"
    
    # Gracefully exit if the package has been removed.
    test -x $DAEMON || exit 0
    test -x $FCGI_SPAWN_GRAPH || exit 0
    test -x $FCGI_SPAWN_HTML || exit 0
    
    start() {
      $DAEMON -s $FCGI_GRAPH_SOCK -U $WWW_USER -u $FCGI_USER -g $FCGI_GROUP -P $PIDFILE_GRAPH $FCGI_SPAWN_GRAPH 2> /dev/null || echo "Graph Already running"
      $DAEMON -s $FCGI_HTML_SOCK -U $WWW_USER -u $FCGI_USER -g $FCGI_GROUP -P $PIDFILE_HTML $FCGI_SPAWN_HTML 2> /dev/null || echo "HTML Already running"
    }
    
    stop() {
      kill -QUIT `cat $PIDFILE_GRAPH` || echo "Graph not running"
      kill -QUIT `cat $PIDFILE_HTML` || echo "HTML Not running"
    }
    
    case "$1" in
      start)
        echo "Starting $DESC: "
        start
      ;;
      stop)
        echo "Stopping $DESC: "
        stop
      ;;
      restart|reload)
        echo "Restarting $DESC: "
        stop
        # Sleep 2s to let enough for the daemons to stop
        sleep 2
        start
      ;;
      status)
        if netstat -ln | grep "fcgi-graph"; then
          echo "Service running"
          exit 0
        else
          echo "Service stopped"
          exit 3
        fi
      ;;
      *)
        echo "Usage: $SCRIPTNAME {start|stop|restart|reload|status}" >&2
        exit 3
      ;;
    esac
    
    exit $?
    

    Si vous souhaitez plus d'info sur la création d'un script de démarrage, je vous invite à consulter http://sysadmin.tme520.net/creez-des-scripts-dinit-au-standard-lsb/

    On rend ce script exécutable

    sudo chmod +x /etc/init.d/munin-fastcgi

    Et on actualise les services

    sudo update-rc.d munin-fastcgi defaults

    Vous pouvez faire un sudo reboot pour vérifier que les 2 sockets sont bien activés au démarrage du serveur.

    sudo service munin-fastcgi start

    Voila, au prochain reboot : les 2 sockets seront automatiquement relancés.

     

    Modification de la configuration de Munin

    Il faut maintenant indiquer à Munin d'utiliser les sockets FCGI pour générer les graphiques et les pages HTML.

    On ouvre donc le fichier de configuration de Munin

    sudo nano /etc/munin/munin.conf

    Puis rechercher les lignes ci-dessous et adapter la valeur des variables comme indiqué ci-dessous

    graph_strategy cgi
    html_strategy cgi
    

     

    Ajustement de la configuration du vHost

    Il faut ensuite ajouter quelques lignes à la configuration du vHost Munin pour qu'il utilise les scripts FCGI.
    On ouvre la config de notre vHost Munin

    sudo nano /etc/nginx/conf.d/default.conf

    Pour corriger la partie dédiée à Munin pour qu'elle soit identique à ci-dessous

    server {
        ....
    
        # Munin --> Start
        location ^~ /munin-cgi/munin-cgi-graph/ {
            fastcgi_split_path_info ^(/munin-cgi/munin-cgi-graph)(.*);
            fastcgi_param PATH_INFO $fastcgi_path_info;
            fastcgi_pass unix:/var/run/munin/fcgi-graph.sock;
            include fastcgi_params;
        }
    
        location /munin/static/ {
            alias /etc/munin/static/;
            expires modified +1w;
        }
    
        # To fix a strange bug with the zoom pages!
        location /munin/localdomain/localhost.localdomain/static/ {
            alias /etc/munin/static/;
            expires modified +1w;
        }
    
        location /munin/ {
            fastcgi_split_path_info ^(/munin)(.*);
            fastcgi_param PATH_INFO $fastcgi_path_info;
            fastcgi_pass unix:/var/run/munin/fcgi-html.sock;
            include fastcgi_params;
        }
        # Munin --> End
    
        ....
    }

    Reste enfin à redémarrer les services Nginx et Munin

    sudo service nginx restart
    sudo service munin-node restart

    Vérifier que tout fonctionne correctement et vous pouvez constater dans les graphiques Munin que la charge de Munin est maintenant réduite.

    Dans l'article suivant, nous allons installer 2 plugins complémentaires pour minotorer les requêtes traitées par nginx et les nombre de connexion sur la base Mysql.
     

    Sources : http://guide.munin-monitoring.org/en/stable-2.0/example/webserver/nginx.html

  • Sunday 16 July 2017 - 18:11

    Dans la continuité des 2 articles précédents sur l'installation et l'optimisation de Munin, nous allons à présent configurer 2 plugins pour monitorer :

    • les trafics nginx
    • les transactions MySQL

     

    Affichage des Plugins et des dépendances

    Munin dispose d'une commande bien pratique qui permet d'afficher les plugins disponibles et/ou actifs ainsi que les dépendances de ceux-ci.

    sudo munin-node-configure --suggest

    Vous obtiendrez un résultat que j'ai résumé à quelques lignes ci-dessous.
    A priori, pour nginx et mysql, il manque des trucs...

    Plugin                     | Used | Suggestions
    ------                     | ---- | -----------
    ....
    cpu                        | yes  | yes
    diskstats                  | yes  | yes
    ....
    mysql_                     | no   | no [Missing dependency Cache::Cache]
    ....
    nginx_request              | no   | no [LWP::UserAgent not found]
    nginx_status               | no   | no [LWP::UserAgent not found]
    ....

     

    Installation des plugins Nginx

    Pour Nginx, le message [LWP::UserAgent not found] indique qu'une librairie est manquante, en l'occurrence : libwww-perl.

    On installe donc cette librairie 

    sudo apt-get install libwww-perl

    Puis on lance à nouveau sudo munin-node-configure --suggest pour voir si le problème est résolu.

    sudo munin-node-configure --suggest | grep nginx
    nginx_request              | no   | no [no nginx status on http://localhost/nginx_status]
    nginx_status               | no   | no [no nginx status on http://localhost/nginx_status]
    

    Gagné... sauf qu'il y a une autre erreur maintenant.
    C'est normal car il faut indiquer à Nginx de fournir des informations via l'url http://localhost/nginx_status

    Pour cela, on ouvre la configuration du vHost par défaut

    sudo nano /etc/nginx/conf.d/default.conf

    Et on ajoute la configuration suivante dans la partie server { }

        location /nginx_status {
            stub_status on;    # return basic status information
            access_log off;
            allow 127.0.0.1;   # restrict access to local only
            deny all;
        }

    Puis on redémarre Nginx pour activer la modification.

    sudo service nginx restart

    Si on relance à nouveau sudo munin-node-configure --suggest pour vérifier notre correction.

    sudo munin-node-configure --suggest | grep nginx

    Cette fois, c'est tout bon smiley

    nginx_request              | no   | yes
    nginx_status               | no   | yes

    On peut donc ajouter nos 2 plugins Nginx à la configuration de Munin.
    Pour cela, on crée un lien symbolique entre le dossier des plugins Munin en cours d'utilisation (/etc/munin/plugins/) et l'emplacement des plugins disponibles ( /usr/share/munin/plugins/)

    sudo ln -s /usr/share/munin/plugins/nginx_status /etc/munin/plugins/nginx_status
    sudo ln -s /usr/share/munin/plugins/nginx_request /etc/munin/plugins/nginx_request

    Et on redémarre Munin pour activer les nouveaux plugins.

    sudo service munin-node restart

    Attendez 5 minutes, pour que Munin rafraichisse ses données, et vous verrez apparaitre une nouvelle catégorie nginx.

     

    Installation des plugins MySQL

    Pour MySQL, nous avons le message qui indique lui aussi qu'une librairie est manquante : libcache-cache-perl

    On installe donc cette librairie, ainsi que la librairie libdbd-mysql-perl qui est nécessaire au bon fonctionnement du script MySQL de munin.

    sudo apt-get install libcache-cache-perl libdbd-mysql-perl

    Puis on lance à nouveau sudo munin-node-configure --suggest pour voir si le problème est résolu

    sudo munin-node-configure --suggest | grep mysql
    mysql_                     | no   | yes (+bin_relay_log +commands +connections +files_tables +innodb_bpool +innodb_bpool_act +innodb_insert_buf +innodb_io +innodb_io_pend +innodb_log +innodb_rows +innodb_semaphores +innodb_tnx +myisam_indexes +network_traffic +qcache +qcache_mem +replication +select_types +slow +sorts +table_locks +tmp_tables)

    Gagné... et on voit apparaitre pas mal de plugins complémentaires.

    Nous allons créer un utilisateurs MySQL qui sera utilisé par Munin pour obtenir des informations sur la base de données.
    Pour cela, comme d'habitude, on se connecte à MySQL en lignes de commande.

    mysql -u root -p

    Puis on exécute les requêtes suivantes pour créer notre utilisateur avec les droits d'accès associés. Pensez à remplacer le mot de passe MuninPassword01 par celui de votre choix.

    CREATE USER 'munin-user'@'localhost' IDENTIFIED BY 'MuninPassword01';
    GRANT SUPER, PROCESS ON *.* TO 'munin-user'@'localhost';
    GRANT SELECT ON mysql.* TO 'munin-user'@'localhost';
    FLUSH PRIVILEGES; 

    Il faut à présent modifier le fichier de configuration du script MySQL de Munin pour lui indiquer l'utilisateur à utiliser.

    sudo nano /etc/munin/plugin-conf.d/munin-node

    Puis ajouter les infos suivantes à la fin du fichier (n'oubliez pas d'ajuster le mot de passe à votre config)

    [mysql_*]
        env.mysqlconnection DBI:mysql:mysql;host=127.0.0.1;port=3306
        env.mysqluser munin-user
        env.mysqlpassword MuninPassword01

    Il nous reste maintenant à activer les plugins...
    Dans mon cas, c'est le plugin permettant de voir le nombre de connexions sur la base de données qui m'intéresse.
    Pour l'activer, son nom est mysql_connections : vous avez compris qu'il suffit d'indiquer le préfix mysql_ devant le plugin disponible pour l'activer.

    Comme pour les plugins nginx, on crée un lien symbolique entre le dossier des plugin Munin en cours d'utilisation (/etc/munin/plugins/) et l'emplacement des plugins disponibles ( /usr/share/munin/plugins/).

    Attention, le nom du Plugin source est toujours mysql_ mais la destination contient le nom du plugin en suffix mysql_connections

    sudo ln -s /usr/share/munin/plugins/mysql_ /etc/munin/plugins/mysql_connections

    Et on redémarre Munin pour activer le nouveau plugin

    sudo service munin-node restart

    Attendez 5 minutes, pour que Munin rafraichisse ses données, et vous verrez apparaitre une catégorie mysql2.