KrISS feed 8.7 - Ein einfacher und schlauer (oder dummer) Feed-Reader. Von Tontof
  • Wednesday 24 December 2014 - 18:20

    Après avoir installé NzbGet et NzbDrone (récemment renommé sonar), il ne reste plus qu’à les configurer et à en sécuriser l’accès. Pour ce faire, le principe de base consiste à utiliser Nginx en reverse proxy ssl devant ces deux applicatifs.

    Quel est l’intérêt ? Nginx va permettre de « masquer » NzbGet et NzbDrone en évitant de les rendre accessibles directement depuis Internet. Nginx est un serveur connu et fiable, est-ce que l’on peut en dire autant des deux autres ? Personnellement, j’éviterai de parier la sécurité de mon serveur là-dessus.

    * La version de Sonarr/NzbDrone 2.0.0.2663 a apporté pas mal de changements et la configuration nginx ci-dessous doit-être modifiée en conséquence. L’article reflète maintenant ces changements

    Environnement

    OS : Debian 7.7 stable (Wheezy) 64bits
    Nginx : nginx/1.6.2
    NzbDrone : 2.0.0.2500 2.0.0.2663
    Mono : 3.10
    NzbGet : 13.0

    Configuration Nginx

    Pour faire simple, j’ai rajouté les 3 « blocs locations » à la fin de la configuration du Nginx de ma seedbox. Je renvoie à l’article en question qui explique pas à pas la configuration complète avec la terminaison SSL. Mais fondamentalement, on a quelque chose qui ressemble à cela :

    server {
            listen                  443 ssl;
            server_name             www.mondomaine.com;
    
            access_log              /var/log/nginx/transmission_access.log;
            error_log               /var/log/nginx/transmission_error.log;
    
            # gere le controle d acces a l interface
            auth_basic              "Veuillez-vous authentifier";
            auth_basic_user_file    /etc/nginx/secu/password-transmission;
    
            # See https://wiki.mozilla.org/Security/Server_Side_TLS#Nginx
            ssl_certificate                 /etc/nginx/secu/transmission.crt;
            ssl_certificate_key             /etc/nginx/secu/transmission.key;
    
            ssl_session_timeout             5m;
    
            ssl_protocols                   TLSv1.1 TLSv1.2;
            ssl_ciphers                     ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!MD5:!DSS;
            ssl_prefer_server_ciphers       on;
            ssl_session_cache               shared:SSL:10m;
    
            # ici toute la configuration pour transmission ou autre ou rien
            [...]
    
            # configuration pour NzbGet
            location /nzbget/ {
                    include                 /etc/nginx/proxy_params;
                    proxy_pass              http://127.0.0.1:6789/;
    
                    proxy_http_version      1.1;
                    proxy_set_header        Accept-Encoding	"";
            }
    
            # configuration pour NzbDrone
            location /nzbdrone {
                    proxy_pass              http://127.0.0.1:8989/nzbdrone;
    
                    proxy_set_header        X-Real-IP	$remote_addr;
                    proxy_set_header        X-Forwarded-For	$proxy_add_x_forwarded_for;
    
                    proxy_http_version      1.1;
                    proxy_set_header        Accept-Encoding	"";
    
            }
    
            # configuration pour les backups de NzbDrone
            location /backup/ {
                    alias                   /var/lib/nzbdrone/.config/NzbDrone/Backups/;
            }
    }

    Il s’agit d’une configuration très classique de reverse proxy avec terminaison SSL et authentification. Seule bizarrerie, l’accès au répertoire contenant les backups de configuration de NzbDrone.

    Configuration de NzbGet

    Si vous avez suivi le tuto de NzbGet, le fichier de configuration se trouve /usr/local/etc/nzbget.conf. Pour peu que Nzbget ait accès en écriture à son fichier de configuration, on peut réaliser cette dernière à l’aide de l’interface graphique. Ce n’est pas le plus sécurisé, mais par contre le plus simple. Normalement, le « home directory » a déjà été créé et hébergera le « MainDir ».

    # pour donner à nzbget l'accès au fichier de conf
    root@server:~# chown nzbget. /usr/local/etc/nzbget.conf
    root@server:~# service nzbgetd start
    [ ok ] Starting NZBGet: nzbgetd.

    Il ne reste plus qu’à rentrer dans son navigateur préféré l’adresse https://www.mondomaine.com/nzbget. Je renvoie de manière éhontée à ce guide de configuration. Seuls 3 éléments sont importants dans notre cas.

    Configurer le MainDir

    Configurer le MainDir


    Passer le ControlIP sur le localhost et désactiver le ssl et l’authentification


    Configuration de NzbDrone

    Le principe de configuration de NzbDrone reste le même. A ceci près qu’il n’est pas possible, pour le moment, de forcer NzbDrone à écouter sur une adresse IP spécifique. C’est maintenant chose faite avec la version 2.0.0.2663.
    Les principaux éléments de configuration de NzbDrone se trouvent dans un fichier xml créé au premier démarrage. Le point principal est de bien configurer la balise UrlBase. Laissez, dans un premier temps, la balise BindAddress égale à * pour faciliter le debug.

    root@server:~# service nzbdrone start
    [ ok ] Starting NZBDrone: nzbdrone.
    root@server:~# cat  /var/lib/nzbdrone/.config/NzbDrone/config.xml
    <?xml version="1.0" encoding="utf-8" standalone="yes"?>
    <Config>
      <Port>8989</Port>
      <SslPort>9898</SslPort>
      <EnableSsl>False</EnableSsl>
      <LaunchBrowser>False</LaunchBrowser>
      <ApiKey>43e1b1caeb7a4bb6ad4f82b36360b332</ApiKey>
      <AuthenticationEnabled>False</AuthenticationEnabled>
      <Branch>master</Branch>
      <Username>
      </Username>
      <Password>
      </Password>
      <LogLevel>Info</LogLevel>
      <SslCertHash>
      </SslCertHash>
      <UrlBase>/nzbdrone/</UrlBase>
      <UpdateMechanism>BuiltIn</UpdateMechanism>
      <BindAddress>127.0.0.1</BindAddress>
    </Config>
    root@server:~# service nzbdrone restart
    [ ok ] Stopping NZBDrone: nzbdrone.
    [ ok ] Starting NZBDrone: nzbdrone.

    Une fois cette configuration initiale réalisée, on peut se connecter via Nginx avec https://www.mondomaine.com/nzbdrone. En cas de soucis, il est toujours possible de se connecter directement à l’interface graphique : http://www.mondomaine.com:8989.
    nzbdrone_config_ini
    Une fois que l’accès via Nginx fonctionne, on verrouille l’accès direct à NzbDrone depuis internet en passant la balise BindAddress à « 127.0.0.1 ».
    Une dernière chose à noter. NzbDrone permet une mise à jour depuis l’interface graphique. Il nécessite juste un accès en écriture au répertoire /opt/NzbDrone ce qui peut poser des problèmes de sécurité. En même temps, si la configuration SSL de Nginx est solide, cela ne devrait pas être gênant. Au choix donc :

    root@server:~# chown nzbdrone. /opt/NzbDrone/ -vR

    Il ne reste plus maintenant qu’à réaliser la configuration générale de NzbDrone à l’aide de ce tuto.

    Sécurité et Conclusion

    Toute la sécurisation du serveur repose sur le fait que les applicatifs NzbGet et NzbDrone ne sont accessibles que via Nginx, qui dispose d’un mécanisme d’authentification protégé par SSL. La sécurité est a donc priori solide, mais il faudra bien vérifier plusieurs points.

    NzbGet et NzbDrone ne sont accessibles uniquement sur le localhost

    • vérifier que NzbGet n’écoute que sur le localhost : netstat -ntpul | grep nzbget
    • vérifier que NzbDrone (via mono) n’écoute que sur le localhost : netstat -ntpul | grep mono

    Verrouiller les droits des fichiers en local
    Selon son degré de paranoïa, on peut restreindre les modifications sur les fichiers du système :

    • accès au fichier de conf de nzbget : chown root. /usr/local/etc/nzbget.conf
    • accès au fichier de conf de nzbdrone : chown root. /var/lib/nzbdrone/.config/NzbDrone/config.xml
    • accès à l’applicatif NzbDrone : chown root. /opt/NzbDrone -vR

    Bien sûr, ces restrictions empêchent les modifications de config ou les MAJ depuis la GUI.

    Configuration SSL et Autorisations
    Je renvoie vers ce tuto pour une bonne configuration SSL. Attention à bien remettre à jour sa config par rapport aux dernières recommandations. Bien évidemment, choisissez un mot de passe fort!

    La base de la configuration système est maintenant faite. Il ne reste plus qu’à finir la configuration depuis la GUI et commencer à télécharger des œuvres libres de droits! Encore une fois, le site htpcguides.com fourni de très bonnes explications pas à pas. A noter qu’il est possible de monter son propre indexeur privé de newsgroups, ce qui sera peut-être l’occasion de rédiger un prochain article.

    The post Configurer NzbDrone et NzbGet avec Nginx appeared first on Le Blog d'un Geek.

  • Wednesday 14 January 2015 - 01:49

    Cet article présente comment remplacer MySQL par MariaDB quand on utilise Dotdeb. En effet, Dotdeb propose déjà MySQL en version 5.6, apt refuse donc de remplacer MySQL 5.6 par une version de MariaDB « inférieure », c.a.d en 5.5 ou par une supérieure en 5.10.

    Pré-Requis

    Sauvegardez vos bases de données !! Voilà, c’est dit, normalement, la migration est transparente, dans les faits, on n’est jamais à l’abri de mauvaises surprises. Un dump avec MySQL comme présenté dans un script d’un précédent tuto fait l’affaire.
    On conserve aussi une copie du fichier de config de MySQL, /etc/mysql/my.cnf.

    Repo MariaDB

    On va simplement rajouter les repos de MariaDB aux sources du serveur en suivant les consignes fournies.

    root@server:~# cat /etc/apt/sources.list.d/mariadb.list
    # https://downloads.mariadb.org/mariadb/repositories/
    
    # MariaDB 10.0 repository list - created 2015-01-09 21:23 UTC
    # http://mariadb.org/mariadb/repositories/
    deb http://nwps.ws/pub/mariadb/repo/10.0/debian wheezy main
    deb-src http://nwps.ws/pub/mariadb/repo/10.0/debian wheezy main
    
    root@server:~# apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xcbcb082a1bb943db
    Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /tmp/tmp.glim2OsVxR --trustdb-name /etc/apt//trustdb.gpg --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-jessie-automatic.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-jessie-security-automatic.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-jessie-stable.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-squeeze-automatic.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-squeeze-stable.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-wheezy-automatic.gpg --keyring /etc/apt/trusted.gpg.d//debian-archive-wheezy-stable.gpg --recv-keys --keyserver keyserver.ubuntu.com 0xcbcb082a1bb943db
    gpg: requesting key 1BB943DB from hkp server keyserver.ubuntu.com
    gpg: key 1BB943DB: public key "MariaDB Package Signing Key <package-signing-key@mariadb.org>" imported
    gpg: no ultimately trusted keys found
    gpg: Total number processed: 1
    gpg:               imported: 1
    root@server:~# apt-get update

    Mise à Jour avec APT

    Comme expliqué, un simple apt-get install ne marche pas avec un message assez inquiétant.

    root@vps62429:~# apt-get install mariadb-server
    
    The following packages have unmet dependencies:
     mariadb-server : Depends: mariadb-server-10.0 (= 10.0.15+maria-1~wheezy) but it is not going to be installed
    E: Unable to correct problems, you have held broken packages.

    On va donc d’abord vérifier les packages mysql installés, surtout les modules MySQL de perl, php, python, etc.

    root@server:~# dpkg --get-selections | grep mysql
    libdbd-mysql-perl				install
    libmysqlclient-dev				install
    libmysqlclient18:amd64				install
    mysql-client-5.6				install
    mysql-client-core-5.6				install
    mysql-common					install
    mysql-common-5.6				install
    mysql-server					install
    mysql-server-5.6				install
    mysql-server-core-5.6				install
    php5-mysql					install
    python-mysqldb					install

    On supprime les packages mysql-server et mysql-common. Là l’opération est un peu brutale :

    root@server:~# apt-get remove mysql-common mysql-server
    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    The following packages will be REMOVED:
      libdbd-mysql-perl libmysqlclient-dev libmysqlclient18 mysql-client-5.6 mysql-common mysql-common-5.6 mysql-server mysql-server-5.6 php5-mysql python-mysqldb
    0 upgraded, 0 newly installed, 10 to remove and 0 not upgraded.
    After this operation, 114 MB disk space will be freed.
    Do you want to continue [Y/n]? Y

    Et on peut maintenant réinstaller MariaDB et php5-mysql qui saute avec la manip.

    class="lang: bash;" title="Installation de MariaDB"
    root@vps62429:~# apt-get install mariadb-server mariadb-common php5-mysql
    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    The following extra packages will be installed:
      libdbd-mysql-perl libmariadbclient18 libmysqlclient18 mariadb-client-10.0 mariadb-client-core-10.0 mariadb-server-10.0
      mariadb-server-core-10.0
    Suggested packages:
      tinyca mariadb-test
    The following NEW packages will be installed:
      libdbd-mysql-perl libmariadbclient18 libmysqlclient18 mariadb-client-10.0 mariadb-client-core-10.0 mariadb-common
      mariadb-server mariadb-server-10.0 mariadb-server-core-10.0 php5-mysql
    0 upgraded, 10 newly installed, 0 to remove and 0 not upgraded.
    Need to get 0 B/37,3 MB of archives.
    After this operation, 130 MB of additional disk space will be used.
    Do you want to continue [Y/n]? Y

    Vérifications

    Normalement, MariaDB a bien géré la conversion. Pour autant :

    • Vérifiez-bien qu’il ne manque aucun module (ex php5-mysql)
    • Vérifiez que les bases de données n’ont pas été corrompues !

    Notez bien que cette migration vers MariaDB 10.0 est un aller-simple. Il n’est plus possible ensuite de convertir les BDDs, sauf à revenir sur les dumps réalisés avant.

    Aussi, n’hésitez pas à regarder les fonctionnalités de TokuDB qui est maintenant packagé avec les dernières versions de MariaDB.

    The post Remplacer MySQL par MariaDB appeared first on Le Blog d'un Geek.

  • Tuesday 20 January 2015 - 23:48

    Soyons honnête, les versions de rar qui viennent avec debian sont problématiques. La version free n’arrive pas à extraire correctement beaucoup trop de packages. La version nonfree (shareware) est obsolète. Cet article va donc expliquer comment rapidement installer une version récente de rar.

    Récupération des binaires

    Les dernières versions sont disponibles sur le site de RarLab. Aujourd’hui, autant choisir la dernière version stable 5.20 en 64bits, sauf si l’OS est en 32 bits mais cela devient rare…

    root@server:~# wget http://www.rarlab.com/rar/rarlinux-x64-5.2.0.tar.gz
    root@server:~# tar xvf rarlinux-x64-5.2.0.tar.gz

    Installation

    Ici il ne s’agit que de binaires, l’installation est donc très rapide.

    root@server:~# cd rar/
    root@server:~/rar# make 
    mkdir -p /usr/local/bin
    mkdir -p /usr/local/lib
    cp rar unrar /usr/local/bin
    cp rarfiles.lst /etc
    cp default.sfx /usr/local/lib

    On va juste créer rapidement les liens symboliques.

    root@server:~# ln -s /usr/local/bin/rar /usr/bin/rar
    root@server:~# ln -s /usr/local/bin/unrar /usr/bin/unrar

    C’est tout !

    The post Installer RAR sur Debian appeared first on Le Blog d'un Geek.

  • Wednesday 12 August 2015 - 19:25

    Le spam devient de plus en plus problématique sur mon WordPress, je viens de dépasser les 150 000 pour le seul mois de Juillet ! J’ai beau utiliser Akismet qui accompli un très beau travail, il a le défaut de laisser les spams 15 jours dans la catégorie indésirable avant de les effacer.

    Bilan, ma base de données atteint la taille respectable de 350 Mo !!

    spam_wordpress
    Il est toujours possible de demander à WordPress de purger tous les commentaires indésirables, mais, via le moteur php, il n’en efface que 15 000 à la fois tout en laissant le serveur indisponible pendant un bon quart d’heure !

    Alors une autre méthode brutale, mais efficace. Pensez bien à faire un back-up de votre Base de Données avant !

    root@server:~# mysql -u root -p
    Enter password:
    Welcome to the MariaDB monitor.  Commands end with ; or \g.
    Your MariaDB connection id is 64670
    Server version: 10.0.21-MariaDB-1~wheezy mariadb.org binary distribution
    
    Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.
    
    Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
    
    MariaDB [(none)]&gt; show databases;
    +--------------------+
    | Database           |
    +--------------------+
    | information_schema |
    | mysql              |
    | performance_schema |
    | tmp                |
    | tokudb             |
    | wpdb               |
    | wpdbpb             |
    +--------------------+
    7 rows in set (0.00 sec)
    MariaDB [(none)]&gt; use wpdbpb;
    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 [wpdbpb]&gt; show tables;
    +---------------------------+
    | Tables_in_wpdbpb          |
    +---------------------------+
    | wp_commentmeta            |
    | wp_comments               |
    [...]
    +---------------------------+
    14 rows in set (0.00 sec)
    
    MariaDB [wpdbpb]&gt; DELETE from wp_comments WHERE comment_approved =  'spam';
    Query OK, 35010 rows affected (0.57 sec)

    Et voilà, 35 000 spams effacés en 0,57 sec !! Imbattable.

    La table à nettoyer est wp_comment, elle a peut être été renommée par un plugin à l’aide d’un préfixe pour sécuriser WordPress. Pour résumer quelques queries utiles :
    Si vous voulez nettoyer les commentaires en attente :

    DELETE from wp_comments WHERE comment_approved =  '0';

    Si vous voulez nettoyer les commentaires en corbeille :

    DELETE from wp_comments WHERE comment_approved =  'trash';

    Si vous voulez nettoyer les commentaires en indésirables :

    DELETE from wp_comments WHERE comment_approved =  'spam';

    Éventuellement, il ne reste plus qu’à scripter rapidement quelque chose en crontab pour nettoyer périodiquement le spam.

    The post Se Débarrasser du Spam sur WordPress appeared first on Le Blog d'un Geek.

  • Saturday 19 March 2016 - 14:14

    Google n’oublie rien ! Même deux ans après, un site visité 2 fois est retenu par Google. Précision importante, le disque système avait pourtant été reformaté entre temps. Mais c’était sans compter sur Gmail que j’utilise sans me déconnecter, à tort, du portail web.

    Soyez-donc prévenu, chaque site web parcouru, chaque vidéo youtube regardée, chaque photo stockée, chaque lieu géographique visité, etc. est retenu par Google via votre compte… et ce probablement à vie.

    Pas étonnant, dans ces conditions, que la NSA cherche à hacker Google et autres.

    google_fait_peur

    The post Google fait Peur appeared first on Le Blog d'un Geek.

  • Sunday 20 March 2016 - 19:46

    Ce post présente la mise à jour d’une Debian Wheezy vers Jessie. Il s’appuie sur la documentation officielle de Debian et en est une version raccourcie. Mais ce n’est pas pour autant une raison de ne pas aller la lire.

    Faites avant tout un backup des données du serveur et prévoyez 2 ou 3 heures en partant du principe que vous allez devoir tout réinstaller. Normalement, tout devrait bien se passer, mais on n’est jamais trop prudent…

    Ain’t broken, don’t fix it !

    Wheezy est une version stable dont la fin de support n’est pas encore annoncée. Même s’il est tentant d’avoir son serveur sous la toute dernière version, il est important de se rappeler qu’un Wheezy opérationnel est toujours plus performant qu’un Jessie vautré ! 🙄

    C’est aussi pour cette raison que j’ai attendu près d’un an avant de réaliser la mise à jour, mieux vaut laisser les autres essuyer les plâtres. Exemple typique, certains ont découvert après l’upgrade que le root-login avec mot de passe avait été désactivé automatiquement !
    upgrade_ssh_jessie_2
    Oups…

    Un Serveur Propre avant l’Upgrade

    C’est bien la moindre des choses !? Assurez-vous qu’il n’y a aucun problème, qu’il n’existe pas des paquets à moitié installés, ou autres problèmes de dépendances.

    root@server:~# dpkg --audit

    Préparer les Sources d’APT

    L’ancien fichier de sources devrait ressembler à ça :

    root@server:~# cat /etc/apt/sources.list
    deb http://debian.proxad.net/debian/ wheezy main non-free
    deb-src http://debian.proxad.net/debian/ wheezy main non-free
    
    deb http://security.debian.org/ wheezy/updates main
    deb-src http://security.debian.org/ wheezy/updates main

    Là il s’agit simplement de remplacer wheezy par jessie.

    root@server:~# cat /etc/apt/sources.list
    deb http://debian.proxad.net/debian/ jessie main non-free
    deb-src http://debian.proxad.net/debian/ jessie main non-free
    
    deb http://security.debian.org/ jessie/updates main
    deb-src http://security.debian.org/ jessie/updates main

    Ensuite, passez en commentaire toutes les autres sources Apt, normalement dans /etc/apt/sources.list.d/. Ici un exemple avec dotdeb.

    root@server:~# cat /etc/apt/sources.list.d/dotdeb.list
    # Dot deb Repository. See www.dotdeb.org
    #deb http://packages.dotdeb.org wheezy all
    #deb-src http://packages.dotdeb.org wheezy all
    
    # Dot deb Repository for PHP 5.5.0
    #deb http://packages.dotdeb.org wheezy-php55 all
    #deb-src http://packages.dotdeb.org wheezy-php55 all

    C’est important car la mise à niveau n’a pas été testée avec les sources non-debian. Bien sûr vous pourrez les réactiver après l’upgrade.

    Vérifier l’Espace Disque

    D’expérience, c’est déjà assez pénible de rattraper une simple mise à jour plantée à cause d’une saturation de la partition. Si en plus le système est au milieu d’un upgrade, la catastrophe est assurée…

    root@server:~# apt-get update
    [...]
    Fetched 19.3 MB in 1s (12.7 MB/s)
    Reading package lists... Done
    root@server:~# apt-get -o APT::Get::Trivial-Only=true dist-upgrade
    [...]
    399 upgraded, 164 newly installed, 7 to remove and 0 not upgraded.
    Need to get 299 MB of archives.
    After this operation, 436 MB of additional disk space will be used.
    E: Trivial Only specified but this is not a trivial operation.

    Maintenant, comparez avec un rapide df -h. Prévoyez au moins le double pour être tranquille.

    root@server:~# df -h
    Filesystem                   Size  Used Avail Use% Mounted on
    rootfs                        20G  3.9G   15G  22% /
    udev                          10M     0   10M   0% /dev
    tmpfs                        3.2G  356K  3.2G   1% /run
    /dev/md1                      20G  3.9G   15G  22% /
    tmpfs                        5.0M     0  5.0M   0% /run/lock
    tmpfs                        6.7G     0  6.7G   0% /dev/shm
    /dev/mapper/vg-vardata        39G  1.6G   35G   5% /var
    /dev/mapper/vg-logs          4.9G  383M  4.2G   9% /var/log
    /dev/mapper/vg-home           39G   19G   19G  51% /home
    
    /dev/mapper/vg-mysql         197G  656M  187G   1% /var/lib/mysql

    C’est Parti !

    Si vous avez le moindre doute, il est encore temps de tout arrêter !
    Debian recommande de procéder en deux étapes afin de limiter les risques de conflits.

    root@server:~# apt-get upgrade
    [...]
    254 upgraded, 0 newly installed, 0 to remove and 145 not upgraded.
    Need to get 94.9 MB of archives.
    After this operation, 48.6 MB of additional disk space will be used.
    Do you want to continue [Y/n]?

    root@server:~# apt-get dist-upgrade
    [...]
    145 upgraded, 164 newly installed, 7 to remove and 0 not upgraded.
    Need to get 204 MB of archives.
    After this operation, 387 MB of additional disk space will be used.
    Do you want to continue [Y/n]?

    Une fois le apt-get dist-upgrade terminé, la mise à niveau « formelle » est finie, ce qui doit normalement se vérifier ainsi :

    root@server:~# cat /etc/os-release
    PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
    NAME="Debian GNU/Linux"
    VERSION_ID="8"
    VERSION="8 (jessie)"
    ID=debian
    HOME_URL="http://www.debian.org/"
    SUPPORT_URL="http://www.debian.org/support"
    BUG_REPORT_URL="https://bugs.debian.org/"

    Normalement, surtout si vous n’avez pas trop customisé le système, tout devrait marcher du premier coup. Ceci dit…

    Éventuels Problèmes en Cours de Route

    Ce n’est pas en soit un message d’erreur, mais vous pouvez être sûr d’en voir plein pendant la mise à niveau.

    Configuration file '/etc/issue'
     ==> Modified (by you or by a script) since installation.
     ==> Package distributor has shipped an updated version.
       What would you like to do about it ?  Your options are:
        Y or I  : install the package maintainer's version
        N or O  : keep your currently-installed version
          D     : show the differences between the versions
          Z     : start a shell to examine the situation
     The default action is to keep your current version.
    *** issue (Y/I/N/O/D/Z) [default=N] ?

    Examinez systématiquement les différences (option D), mais dans le doute, utilisez la nouvelle version quitte à y réinjecter plus tard vos paramètres customisés. De toute façons, apt conserve toujours l’ancienne copie en y rajoutant l’extension « .dpkg-old ».

    Ensuite, un des nouveaux packages php5-json rentrait en conflit avec un ancien package php5-dev fourni par dotdeb… Bilan php5-json n’était pas installé et interrompait la mise à niveau.

    dpkg: error processing archive /var/cache/apt/archives/php5-json_1.3.6-1_amd64.deb (--unpack):
    trying to overwrite '/usr/include/php5/ext/json/php_json.h', which is also in package php5-dev 5.5.33-1~dotdeb+7.1

    J’ai réglé le problème en dégageant l’ancien php5-dev, en forçant la résolution des dépendances (apt-get -f) et en relançant la mise à niveau.

    root@server:~# dpkg -P php5-dev
    (Reading database ... 39361 files and directories currently installed.)
    Removing php5-dev (5.5.33-1~dotdeb+7.1) ...
    Processing triggers for man-db (2.7.0.2-5) ...
    [...]
    root@server:~# apt-get -f install
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done
    Correcting dependencies... Done
    [...]
    root@server:~# apt-get dist-upgrade
    [...]

    Vous allez probablement rencontrer d’autres erreurs différentes, mais au moins, j’espère que cela donnera quelques idées pour essayer de les résoudre.

    Nettoyage Post-installation

    Une fois tous les problèmes d’installation réglés, il ne reste plus qu’à nettoyer le système.
    La première commande va dégager les dépendances qui ne servent plus.

    root@server:~# apt-get autoremove

    La deuxième commande va purger les paquets qui ont été supprimés. Notamment, les anciens scripts init.d sont connus pour causer des problèmes.

    root@server:~# apt-get purge $(dpkg -l | awk '/^rc/ { print $2 }')

    Reconfigurer ses sources.list

    Pour revenir sur l’exemple des sources de Dotdeb désactivées avant la mise à niveau :

    root@server:~# cat /etc/apt/sources.list.d/dotdeb.list
    # Dot deb Repository. See www.dotdeb.org
    deb http://packages.dotdeb.org jessie all
    deb-src http://packages.dotdeb.org jessie all

    Suivi bien sûr d’un apt-get update && apt-get upgrade.

    Ultime Stress

    Maintenant il ne reste plus qu’à rebooter et prier pour que son serveur remonte bien. 🙂 Mais si tout s’est bien passé, vous êtes maintenant l’heureux propriétaire d’un serveur Debian Jessie.

    Normalement, toute la procédure décrite ici est assez fiable. Mais encore une fois, je ne peux que recommander de lire attentivement la documentation officielle de Debian avant de se lancer dedans. Vous êtes prévenus.

    The post Upgrader son Serveur Debian Wheezy appeared first on Le Blog d'un Geek.

  • Tuesday 29 March 2016 - 21:14

    PHP 7 vient de sortir en décembre dernier et promet des gains importants de performance. La tentation étant trop forte, j’ai upgradé mon serveur durant le week-end. Et effectivement, sur WordPress, pas besoin de tests pour sentir la différence.

    Ce post va donc expliquer comment migrer de manière assez « safe » son serveur Debian vers cette nouvelle version de PHP en s’appuyant sur les packages mis à disposition par Dotdeb.

    Quelques Précisions et Warning

    Le repository de dotdeb ne fournit PHP 7 que pour la dernière version de Debian Jessie. Il faudra donc faire une mise à niveau pour les serveurs sous Wheezy, ou utiliser une autre méthode.

    PHP 7 n’est pas encore si mature que ça. Le PHP Group en est déjà à la version 7.0.4 en 3 mois corrigeant essentiellement des failles de sécurité. Même chose pour le support des extensions PECL (memcache, etc.).

    Et tout les applicatifs PHP ne sont pas forcément 100% compatible avec PHP 7. WordPress marche très bien, c’est loin d’être le cas de tous les plug-ins. D’ailleurs, je recommande fortement de désactiver l’utilisation de memcache par W3TC.

    Ceci dit, utiliser un repository permet un retour arrière simple et rapide. 🙂 Pas de risque donc de casser quoique ce soit. Testez juste bien tous vos applicatifs après la mise à jour.

    Installer Dotdeb

    Pour installer Dotdeb, il suffit de rajouter le fichier suivant à vos sources :

    root@server:~# cat /etc/apt/sources.list.d/dotdeb.list
    # Dot deb Repository. See www.dotdeb.org
    deb http://packages.dotdeb.org jessie all
    deb-src http://packages.dotdeb.org jessie all

    Suivi d’une synchronisation de l’index des packages avec éventuelle mise à jour :

    root@server:~# apt-get update && apt-get upgrade

    Attention, Dotdeb fournit aussi des mises à jour pour Nginx, MySQL entre autre. Normalement pas de soucis, mais vérifiez bien quand même le bon fonctionnement après les mises-à-jour.

    Identifier ses packages PHP 5

    Ici, il s’agit juste d’identifier les packages PHP 5 utilisés par le système. On pourra alors les remplacer, normalement, par leur équivalent PHP 7.

    root@server:~# dpkg -l | grep php5
    ii  dh-php5                        0.2                       all          debhelper add-on to handle PHP PECL extensions
    ii  libapache2-mod-php5            5.6.17+dfsg-0+deb8u1      amd64        server-side, HTML-embedded scripting language (Apache 2 module)
    ii  php5                           5.6.17+dfsg-0+deb8u1      all          server-side, HTML-embedded scripting language (metapackage)
    ii  php5-cli                       5.6.17+dfsg-0+deb8u1      amd64        command-line interpreter for the php5 scripting language
    ii  php5-common                    5.6.17+dfsg-0+deb8u1      amd64        Common files for packages built from the php5 source
    ii  php5-curl                      5.6.17+dfsg-0+deb8u1      amd64        CURL module for php5
    ii  php5-dev                       5.6.17+dfsg-0+deb8u1      amd64        Files for PHP5 module development
    ii  php5-fpm                       5.6.17+dfsg-0+deb8u1      amd64        server-side, HTML-embedded scripting language (FPM-CGI binary)
    ii  php5-gd                        5.6.17+dfsg-0+deb8u1      amd64        GD module for php5
    ii  php5-intl                      5.6.17+dfsg-0+deb8u1      amd64        internationalisation module for php5
    ii  php5-json                      1.3.6-1                   amd64        JSON module for php5
    ii  php5-mcrypt                    5.6.17+dfsg-0+deb8u1      amd64        MCrypt module for php5
    ii  php5-memcache                  3.0.8-5                   amd64        memcache extension module for PHP5
    ii  php5-memcached                 2.2.0-2                   amd64        memcached extension module for PHP5, uses libmemcached
    ii  php5-mysql                     5.6.17+dfsg-0+deb8u1      amd64        MySQL module for php5
    ii  php5-readline                  5.6.17+dfsg-0+deb8u1      amd64        Readline module for php5
    ii  php5-tidy                      5.6.17+dfsg-0+deb8u1      amd64        tidy module for php5

    Désinstaller PHP 5

    Officiellement, les packages PHP 5 et PHP 7 sont maintenant co-installables. Mais dans le doute, il me semble mieux de les enlever avec un simple apt-get remove sur la liste des packages précédemment identifiés.
    Sur mon serveur cela donne :

    root@server:~# apt-get remove dh-php5 libapache2-mod-php5 php5 php5-cli php5-common php5-curl php5-dev php5-fpm php5-gd php5-intl php5-json php5-mcrypt php5-memcache php5-memcached php5-mysql php5-readline php5-tidy

    Évitez l’option purge afin de conserver les configurations en cas de retour arrière. Et bien évidemment, il s’agit ici de la liste des packages qui étaient présents sur mon serveur, adaptez la à votre environnement.

    Installer PHP 7

    root@server:~# apt-get install libapache2-mod-php7.0 php7.0 php7.0-cli php7.0-common php7.0-curl php7.0-dev php7.0-fpm php7.0-gd php7.0-intl php7.0-json php7.0-mcrypt php7.0-memcache php7.0-memcached php7.0-mysql php7.0-readline php7.0-tidy
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done
    Note, selecting 'php7.0-memcached' for regex 'php7.0-memcache'
    The following extra packages will be installed:
      php-pear php-readline php5-cli php5-common php5-json php5-readline php7.0-igbinary php7.0-msgpack php7.0-opcache pkg-php-tools
    Suggested packages:
      php5-dev php5-user-cache php-user-cache dh-make
    Recommended packages:
      dh-php7.0
    The following NEW packages will be installed:
      libapache2-mod-php7.0 php-pear php-readline php5-cli php5-common php5-json php5-readline php7.0 php7.0-cli php7.0-common php7.0-curl php7.0-dev php7.0-fpm php7.0-gd
      php7.0-igbinary php7.0-intl php7.0-json php7.0-mcrypt php7.0-memcached php7.0-msgpack php7.0-mysql php7.0-opcache php7.0-readline php7.0-tidy pkg-php-tools
    0 upgraded, 25 newly installed, 0 to remove and 0 not upgraded.
    Need to get 0 B/11.5 MB of archives.
    After this operation, 52.6 MB of additional disk space will be used.
    Do you want to continue? [Y/n]
    [...]

    Le package dh-php7.0 n’est pas oublié ! Il n’est tout simplement pas encore (?) disponible dans le repository. J’espère que vous n’aviez pas l’intention de compiler des packages php! 🙁

    root@server:~# apt-get install dh-php7.0
    [...]
    Package dh-php7.0 is not available, but is referred to by another package.
    This may mean that the package is missing, has been obsoleted, or
    is only available from another source

    Reconfigurer Nginx

    Si vous avez configuré Nginx pour utiliser php5-fpm avec un socket unix, il va falloir remplacer dans tous vos fichiers de config Nginx « unix:/var/run/php5-fpm.sock » par « unix:/var/run/php/php7.0-fpm.sock ».
    Si vous suivez la bonne pratique consistant à centraliser les éléments de config PHP dans un seul fichier php_params, c’est simple.

    root@server:~# cat /etc/nginx/php_params | grep fastcgi_pass
    #fastcgi_pass                           unix:/var/run/php5-fpm.sock;
    fastcgi_pass                            unix:/var/run/php/php7.0-fpm.sock;

    Si vous utilisez un socket tcp, par exemple « fastcgi_pass 127.0.0.1:9000 », normalement, il n’y a rien à changer.

    Il ne reste plus qu’à recharger la nouvelle configuration :

    root@server:~# nginx -t
    nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
    nginx: configuration file /etc/nginx/nginx.conf test is successful
    root@ns203445:~# service nginx reload

    Et pour Apache ? Honnêtement, je n’en sais rien comme je ne l’utilise plus. J’imagine que la librairie libapache2-mod-php7.0 suffit, mais je n’ai pas du tout testé.

    Quelques Vérifications

    Voilà, c’est fini ! Il ne reste plus qu’à vérifier que tous vos sites en PHP fonctionnent toujours correctement et à déboguer si ce n’est pas le cas.
    Au moins un premier test générique :

    root@server:~# php -version
    PHP 7.0.4-1~dotdeb+8.1 (cli) ( NTS )
    Copyright (c) 1997-2016 The PHP Group
    Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
        with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

    Ensuite, affichez la page classique de phpinfo(). Le fichier info.php suivant est à placer à la racine du serveur web.

    root@server:/var/www# cat info.php
    <?php
    // Affiche toutes les informations, comme le ferait INFO_ALL
    phpinfo();
    ?>

    Ce qui donne quelque chose comme cela :
    php_info
    N’oubliez pas d’enlever le fichier info.php après les tests pour des raisons de sécurité !

    Quelques Mots pour Conclure

    Comme mentionné initialement, toute cette procédure est complètement réversible. Peu de risque, surtout si vous n’utilisez pas d’obscurs plug-ins mal codés ou plus maintenus depuis 3 ans.

    Et si malheureusement vous rencontriez des problèmes, essayez d’identifier le code/plug-in PHP responsable. Ensuite, soit vous attendez une mise-à-jour, soit vous le remplacez par un équivalent.

    Mais si tout marche bien, « enjoy » ! 🙂

    The post Upgrader en PHP 7 sur Debian appeared first on Le Blog d'un Geek.

  • Saturday 25 June 2016 - 12:33

    Ce post va expliquer comment installer, sur le même serveur, deux instances de transmission en parallèle.
    Mais quel intérêt ? Chacun y trouvera le sien, pour moi il s’agissait de pouvoir disposer d’une 2ème instance cloisonnée de la première afin de mieux gérer contrôles d’accès et quotas. Transmission n’aime pas trop quand sa partition sature. 🙁
    Ceci dit, ce tuto sert tout aussi bien pour une compilation simple si vous souhaitez avoir la dernière version disponible par exemple.

    Environnement

    OS : Debian GNU/Linux 8 (jessie) (64bits)
    Ce tuto a été réaliser sur une Debian Jessie. Avec l’apparition du Systemd et les spécificité de chaque distro, je ne garantirai pas le bon fonctionnement sur un autre environnement !
    La première instance de Transmission sera supposée installée avec un simple apt-get install transmission-daemon.

    Pré-Requis à l’Installation

    On commence d’abord par installer les dépendances pour la compilation.

    root@server:~# apt-get install build-essential automake autoconf libtool pkg-config intltool libcurl4-openssl-dev libevent-dev zlib1g-dev libssl-dev

    Et on récupère les sources.

    root@server:~# cd /tmp/
    
    root@server:/tmp# wget https://download.transmissionbt.com/files/transmission-2.92.tar.xz
    [...]
    2016-06-21 22:07:56 (9.43 MB/s) - 'transmission-2.92.tar.xz' saved [3378116/3378116]
    
    root@server:/tmp# sha256sum transmission-2.92.tar.xz
    3a8d045c306ad9acb7bf81126939b9594553a388482efa0ec1bfb67b22acd35f  transmission-2.92.tar.xz
    
    root@server:/tmp# tar xvf ./transmission-2.92.tar.xz

    Compilation

    Là l’idée est de bien gérer les paramètres d’installation afin de ne pas percuter l’instance transmission installée avec apt. Toutes les options possibles sont détailles grâce à un ./configure --help. Ici l’installation est faite dans le répertoire /opt/transmission.

    root@server:/tmp/transmission-2.92# ./configure --help
    `configure' configures transmission 2.92 to adapt to many kinds of systems.
    [...]
    Program names:
      --program-prefix=PREFIX            prepend PREFIX to installed program names
      --program-suffix=SUFFIX            append SUFFIX to installed program names
      --program-transform-name=PROGRAM   run sed PROGRAM on installed program names
    [...]
    
    root@server:/tmp/transmission-2.92# ./configure --prefix=/opt/transmission/usr/local --exec-prefix=/opt/transmission --program-prefix=alt\- --enable-daemon --enable-cli --enable-utp
    
    root@server:/tmp/transmission-2.92# make
    
    root@server:/tmp/transmission-2.92# make install

    Le compilateur permet de rajouter un préfixe ou un suffixe au nom du programme, mais aussi de complètement changer le nom ! Dans mon cas, j’ai préféré « alt-transmission » pour bien marquer la différence avec l’instance « apt ». Mais l’appeler « bisous-hadopi » est tout à fait possible ! 🙂

    Configurer le Daemon

    On crée dans un premier temps un utilisateur et un groupe « alt-transmission ».

    root@server:~# groupadd -r alt-transmission
    root@server:~# useradd -r -g alt-transmission -s /sbin/nologin -m -c "alt-transmission user" alt-transmission

    Et on installe un script Systemd. Ici un seul piège, il faut que la description (ligne 3) soit différente de celle de l’instance Transmission « principale ».

    root@server:~# cat /lib/systemd/system/alt-transmission.service
    [Unit]
    Description=Alt Transmission BitTorrent Daemon
    After=network.target
    
    [Service]
    User=alt-transmission
    Type=simple
    ExecStart=/opt/transmission/bin/alt-transmission-daemon -f --log-error
    ExecReload=/bin/kill -s HUP $MAINPID
    
    [Install]
    WantedBy=multi-user.target

    On peut alors activer et démarrer le service « alt-transmission »… Ou presque.

    root@server:~# systemctl enable alt-transmission.service
    Created symlink from /etc/systemd/system/multi-user.target.wants/alt-transmission.service to /lib/systemd/system/alt-transmission.service.
    
    root@server:~# systemctl stop transmission-daemon
    
    root@server:~# systemctl start alt-transmission.service

    Il est préférable d’arrêter avant le Transmission fourni par apt avec un systemctl stop transmission-daemon.service. En effet, le premier lancement va créer un fichier de config settings.json avec les paramètres par défauts risquant de faire entrer en conflit les deux instances de Transmission.

    Éditez donc le fichier de config et assurez-vous que les deux instances utilisent des IPs et des ports différents. Profitez-en pour paramétrer la nouvelle instance Transmission selon vos besoins.

    root@server:~# ls /home/alt-transmission/.config/transmission-daemon/settings.json -alh
    -rw------- 1 alt-transmission alt-transmission 2.2K Jun 25 11:08 /home/alt-transmission/.config/transmission-daemon/settings.json

    Problème Fréquent

    Cette erreur vient de l’utilisation du protocole uTP.

    root@server:~# service alt-transmission status
    * alt-transmission.service - Alt Transmission BitTorrent Daemon
       Loaded: loaded (/etc/systemd/system/alt-transmission.service; enabled)
       Active: failed (Result: timeout) since Fri 2016-06-24 20:07:45 CEST; 14h ago
      Process: 14855 ExecStart=/opt/transmission/bin/alt-transmission-daemon -f --log-error (code=exited, status=0/SUCCESS)
     Main PID: 14855 (code=exited, status=0/SUCCESS)
    
    Jun 24 20:06:16 server alt-transmission-daemon[14855]: [2016-06-24 20:06:16.634] UDP Failed to set receive buffer: requested 4194304, got 266240 (tr-udp.c:84)
    Jun 24 20:06:16 server alt-transmission-daemon[14855]: [2016-06-24 20:06:16.634] UDP Failed to set send buffer: requested 1048576, got 266240 (tr-udp.c:95)
    Jun 24 20:06:16 server alt-transmission-daemon[14855]: [2016-06-24 20:06:16.634] UDP Failed to set receive buffer: requested 4194304, got 266240 (tr-udp.c:84)
    Jun 24 20:06:16 server alt-transmission-daemon[14855]: [2016-06-24 20:06:16.634] UDP Failed to set send buffer: requested 1048576, got 266240 (tr-udp.c:95)

    Vous pouvez au choix :

    1. ignorer l’erreur
    2. désactiver le protocole utp dans le fichier settings.json (paramètre « utp-enabled »)
    3. rajouter les lignes suivantes dans le fichier /etc/sysctl.conf
      • net.core.rmem_max = 4194304
        net.core.wmem_max = 1048576

    En Conclusion

    Si tout s’est bien passé, deux instances de transmission tournent maintenant en parallèle sur votre serveur. N’oubliez pas qu’il est possible de les protéger toutes les deux derrière un reverse proxy en SSL.

    The post Dual Transmission appeared first on Le Blog d'un Geek.

  • Friday 11 November 2016 - 18:09
  • Saturday 17 December 2016 - 23:45

    Avec les révélations Snowden, de plus en plus de sites sont en train de migrer en SSL. Google échaudé pousse maintenant à fond à l’encryption, voir le « https as ranking signal ». Mais d’autres organisations ne sont aps en reste avec la campagne « Encrypt All the Things ». Ce qui change maintenant est la possibilité d’obtenir gratuitement des certificats SSL grâce à Let’s Encrypt depuis le début de l’année !

    Croissance de Let's Encrypt en 2016
    Ce tutoriel va donc présenter comment paramétrer Nginx sous Debian/Jessie pour obtenir et utiliser des certificats SSL avec Let’s Encrypt.

    Installer le Client Certbot

    Let’s Encrypt fournit un client Certbot qui permet avec Nginx (mais aussi Apache, Haproxy, etc.) de générer automatiquement les certificats SSL.
    Il s’installe très simplement, vérifiez juste que vous avez bien rajouté le repo backport.

    root@server:~# cat /etc/apt/sources.list | grep backport
    deb http://ftp.debian.org/debian/ jessie-backports main
    root@server:~# apt-get install letsencrypt -t jessie-backports

    Configurer Nginx avec Certbot

    Certbot est relativement automatisé, ici, je préfère utiliser le mode « webroot » qui permet de ne pas arrêter Nginx pendant la récupération des certificats. Il suffit juste de créer un répertoire que Certbot va utiliser pour le « acme-challenge ». En gros, Certbot va y déposer un fichier le rendant accessible depuis votre serveur web pour permettre à Let’s Encrypt de confirmer la bonne propriété du domaine.

    root@server:~# mkdir /var/www/certs/phil.writesthisblog.com/ -p

    On rajoute le location bloc suivant dans la configuration Nginx du serveur web.

    location ^~ /.well-known {
    
                    auth_basic      off;
                    allow           all;
                    alias           /var/www/certs/phil.writesthisblog.com/.well-known;
    
            }

    On peut maintenant lancer la création du certificat SSL :

    root@server:~# nginx -t && service nginx reload
    nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
    nginx: configuration file /etc/nginx/nginx.conf test is successful
    root@server:~# certbot certonly --webroot -w /var/www/certs/phil.writesthisblog.com -d phil.writesthisblog.com --email xxxx@gmail.com
    [...]
    IMPORTANT NOTES:
     - Congratulations! Your certificate and chain have been saved at
       /etc/letsencrypt/live/phil.writesthisblog.com/fullchain.pem. Your
       cert will expire on 2017-03-17. 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 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
    
    root@server:~#

    N’hésitez pas à déposer à la main un fichier quelconque (test.html par ex) pour manuellement vérifier son accessibilité avec l’uri suivante /.well-known/test.html. Dans la pratique, l’erreur la plus fréquente est un retour 403 ou 404 du serveur web ! 🙁

    Utiliser son Certificat avec Nginx

    Il ne reste plus qu’à utiliser son nouveau certificat. Rien que du classique, notez juste qu’il faut bien conserver le bloc location correspondant à « /.well-known ».

    server {
    
            listen                  188.165.57.56:80 default_server;
            server_name             phil.writesthisblog.com;
            return         301      https://phil.writesthisblog.com$request_uri;
    
    }
    
    server {
    
            listen                  188.165.57.56:443 ssl http2;
            server_name             phil.writesthisblog.com;
    
    
            ssl_certificate         /etc/letsencrypt/live/phil.writesthisblog.com/fullchain.pem;
            ssl_certificate_key     /etc/letsencrypt/live/phil.writesthisblog.com/privkey.pem;
    
            include                 /etc/nginx/ssl_params;
    
            location ^~ /.well-known {
    
                    auth_basic      off;
                    allow           all;
                    alias           /var/www/certs/phil.writesthisblog.com/.well-known;
    
            }
    
            [...]
    
    }

    Et bien sûr, n’oubliez pas de relancer nginx avec un nginx -t && service nginx reload

    Automatiser le Renouvellement des Certificats

    La même méthode peut-être utilisée autant de fois que souhaitées sur le même OS. Par contre les certificats ne sont valables que 3 mois.
    Pour vérifier le bon fonctionnement, un essai à vide :

    root@server:~# certbot renew --dry-run
    Saving debug log to /var/log/letsencrypt/letsencrypt.log
    
    -------------------------------------------------------------------------------
    Processing /etc/letsencrypt/renewal/phil.writesthisblog.com.conf
    -------------------------------------------------------------------------------
    Cert not due for renewal, but simulating renewal for dry run
    Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
    Renewing an existing certificate
    Performing the following challenges:
    http-01 challenge for phil.writesthisblog.com
    Waiting for verification...
    Cleaning up challenges
    Generating key (2048 bits): /etc/letsencrypt/keys/0013_key-certbot.pem
    Creating CSR: /etc/letsencrypt/csr/0013_csr-certbot.pem

    Pour automatiser, on rajoute la ligne suivante à son crontab. La commande fonctionne quelque soit le nombre de certificats générés. Ces derniers ne seront réellement régénérés qu’à l’approche de leur expiration.

    root@server:~# cat /etc/crontab | grep certbot
    0 3     * * *   root    /usr/bin/certbot renew -q >/dev/null 2>&1 && /usr/sbin/nginx -t && service nginx reload

    C’est fini! Encryptez-bien 🙂

    The post Let’s Encrypt ! appeared first on Le Blog d'un Geek.