Archives de
Catégorie : Auto-Hébergement

Nginx : récupérer les IP derrière haproxy

Nginx : récupérer les IP derrière haproxy

Depuis que j’utilise let’s encrypt pour mes certificats la gestion de nginx en reverse proxy devient de plus en plus fastidieuse. Tous mes certificats sont éparpillés sur différents container lxc ce qui m’oblige à réaliser des opérations manuelles à chaque renouvellement. De ce fait impossible d’utiliser un script de renouvellement automatique et cela implique d’autres problèmes. C’est pourquoi j’ai décidé de déployer un vrai reverse proxy avec Haproxy qui m’a été chaudement recommandé par un ami.

Lire la suite Lire la suite

Nextcloud s’offre une version à deux chiffres

Nextcloud s’offre une version à deux chiffres

La nouvelle est tombée hier après-midi nextcloud version 10 vient d’être mis à disposition. Cette nouvelle version majeure apporte un lot de nouveautés très appréciables. Mais avant toute chose passons à la mise à jour. De mon côté rien n’a changé je fais toujours les mises à jour à la main, finalement c’est celle qui me correspond le mieux. La procédure est simple et très rapide.

Une petite connexion pour vérifier que tout s’est bien passé et pour un rapide tour du propriétaire de cette version 10.

Tout d’abord, le monitoring, en effet il est toujours plaisant de voir comment se porte notre serveur bien aimé. Et bien c’est chose faite, je retrouve les principales infos sur l’état de santé du serveur. Dans cette section on retrouve les grands classiques :

  • l’utilisation du CPU
  • L’occupation Ram
  • Les utilisateurs connectés

Mais aussi des informations concernant PHP et MariaDB, comme le numéro de version et quelques points de configuration comme « Upload max size » et la taille de la base de données.

monitoring_nextcloud

Nextcloud fournit même de quoi interfacer les données issues du monitoring avec un logiciel de monitoring.

Autre nouveauté, le contrôle d’accès aux fichiers par mots-clefs. Cette fonction permet de réglementer l’accès aux données et donc à certains fichiers. Par exemple il possible de créer des règles pour limiter l’accès en fonction de la provenance géographique des utilisateurs, ou tout simplement de ne donner accès qu’à un certain type de fichier. Je ne compte pas l’utiliser sur mon cloud familial, mais comment passer à côté ? Pour plus d’informations je vous invite à lire cet article en anglais.

Dernier changement qui a attiré mon attention, le theming. Un petit ajout bien sympathique qui permet de modifier la page d’authentification de nextcloud. Moi qui commençais à me lasser des nuages bleus. Presque tout est paramétrable comme le montre ma capture d’écran.

theming_nextcloud1
je remets les pieds sur terre

theming_nextcloud

Voilà pour le rapide tour du propriétaire de nextcloud 10, je me laisse du temps pour approfondir et découvrir le reste de la mise à jour. En tout cas les pt’is gars de chez nextcloud bossent dur afin de respecter leur engagement de fournir une version communautaire complète, merci à eux !

Update app de nextcloud ne fonctionne pas

Update app de nextcloud ne fonctionne pas

Depuis ma migration sur nextcloud plusieurs mises à jour mineurs ont été publiées. Au niveau de mon instance aucune ne m’a été proposée. Sur ownCloud à chaque nouvelle mise à jour un bandeau apparaissait m’avertissant d’une nouvelle version, majeur ou mineur. J’ai commencé à inverstiguer sur le problème, mais en attendant de le résoudre je préfère réaliser les mises à jour manuellement. Petite particularité de mon installation le dossier data est hébergé sur un disque dur dédié 2to de stockage, ce qui simplifie la procédure, en effet celui-ci ne sera pas à déplacer lors de la mise à jour.

Premièrement je récupère la dernière version stable : https://nextcloud.com/install/#instructions-server

Ensuite, je sauvegarde l’ancien répertoire et j’extrais le nouveau.

Il ne reste plus qu’à attribuer les bons droits et migrer ma configuration qui contient le chemin vers le dossier data.

Nous arrivons enfin à la dernière étape, exécuter la mise à jour. Attention celle-ci doit être exécutée avec l’utilisateur web, sous debian il s’agit du compte www-data.

A noter que cette méthode évite de faire la mise à jour via l’interface web dont j’ai parfois subi les instabilités. Une petite connexion pour vérifier que le plan s’est déroulé sans accros et me voilà à jour. Cela me laisse le temps de résoudre le problème avec Update App.

LXC: mise en situation réelle

LXC: mise en situation réelle

Suite logique à mon installation de LXC le mois dernier, cette mise en situation me permet  d’aprécier le comportement de mon nouveau serveur hôte avant de prendre une décision définitive. Pour cette mise en situation j’ai décidé de migrer le serveur DNS, Courriels et MariaDB.

Le but de cette mise en situation sera de tester les points suivants :

  • Les performances (hôte et containers), analysées avec Munin
  • Les sauvegardes automatisées avec notifications
  • La restauration
  • Le fonctionnement en mode dégradé et retour à la normale
  • L’interface Web de LXC

J’ai configuré chaque container lxc en essayant d’être le plus proche possible de la configuration d’origine afin d’avoir un comparatif le plus juste possible. La seule différence notable sera le système d’exploitation chaque container lxc sera propulsé par une Debian Jessie contre un Wheezy pour OpenVZ.

Lire la suite Lire la suite

Cap sur LXC

Cap sur LXC

Rendez-vous à Farpoint

J’ai parcouru les quatre coins de la toile afin de me documenter sur la mise en place de LXC. Après huit mois de travail le projet commence à se concrétiser. Voici la configuration que j’ai installée afin de réaliser mes essais sur LXC. Mon cahier des charges étant très simple, exécuter mes différents serveurs (mails, dns, web, et autres) dans des containers et en faire une sauvegarde externalisée en cas de pépin. Ce sera l’occasion de faire une petite série d’articles sur mon utilisation de LXC.

 

Le serveur

Tout d’abord j’ai cherché un nouveau matériel, quelque-chose de peu encombrant, le moins énergivore possible et qui me permettrait de pouvoir exécuter des containers. Actuellement mon serveur hôte datant de 2010 abrite un vieil Athlon II dual-core accompagné de 8Go de ram et d’un disque dur de 500go de disque dur en sata. C’est largement suffisant pour héberger mes quatre containers Openvz et mes deux VM Kvm (qui seront amenées à disparaître avec la nouvelle solution) le tout orchestré par Proxmox. Ma démarche actuelle n’est pas de changer pour plus puissant, je n’utilise même pas la moitié de la RAM et le processeur ne vacille jamais au dessus de 15% d’utilisation. Ce que j’ai mis en place en 2010 n’est plus en adéquation avec ce que  j’aspire aujourd’hui. En effet ce serveur est en configuration moyen tour avec une alimentation de 450 watts et un ventilo de 120mm en façade. Au niveau encombrement il n’est pas facile de lui trouver une place loin du lieu de vie et à cause de sa ventilation vieillissante il a de plus en plus de mal à se faire oublier.
J’ai donc opté pour un petit Brix de chez gigabyte le GB-BXBT-2807. Équipé d’un intel dual-core qui ne consomme que 4w. J’y ai rajouté 8go de ram et un disque-dur de 500Go.  L’encombrement est minimal et je retrouve presque les mêmes performances que mon vieux serveur.

La bête mise à nue
La bête mise à nue

Voici le détail du matériel que j’utilise pour cette configuration :

  • BRIX GB-BXBT-2807
  • 8 Go de ram Corsair Value Select SO-DIMM 8 Go DDR3L 1333 MHz CL9
  • Disque dur Seagate Constellation 500 Go 7200 RPM 64 Mo Serial ATA 6Gb/s

Le choix du disque n’est pas encore arrêté, je me demande si au de niveau bruit il ne vaudrait pas mieux prendre un 5400 tours, mais d’un autre côté j’ai peur de perdre des performances. La vitesse du disque dur est-elle prépondérante dans le fonctionnement des containers ? Je planche encore sur la question. Je commence aussi à regarder du côté des SSD, mais j’avoue que la technologie me fait encore un peu peur.

Mise en place

Le choix du moteur de containers n’a pas était long à prendre, car d’un côté j’avais OpenVZ :

  • Vieux noyau
  • Incompatible avec systemd donc condamné à utiliser Wheezy
  • Silence complet sur le nouveau projet Virtuozzo 7(au moment où j’écris ses lignes)

et de l’autre LXC :

  • basé sur les outils noyau donc noyau plus récent
  • compatible systemd utilisable sur Jessie et supérieure
  • Projet très actif, la dernière mise à jours date de novembre 2015
  • Mon goût pour l’aventure, essayé quelque chose de nouveau, bousculer ma routine de geek.

C’est pourquoi j’ai souhaité migrer sous LXC, plutôt que de continuer dans la valeur sûr OpenVZ que j’utilise depuis quelque année déjà.

Pour mon système hôte j’ai donc choisi de partir sur :

  • Une Base Debian 8
  • Système de fichier BTRFS
  • Un point de montage NFS pour les sauvegardes

Voici comment sera organisé mon installation système.

Dans un premier temps l’intérêt du dispositif LXC+BTRFS réside dans la possibilité de créer très rapidement des instantanés et des clones. Pour les instantanés (snapshot) il faut que le dossier lxcsnaps soit intégré dans le système de fichier btrfs. Les instantanés sont utiles avant une mise à jour système par exemple pour un retour en arrière rapide en cas de problème ou sauvegarder le container en toute simplicité. Le clonage est aussi très intéressant il permet de gagner du temps lors de la création d’un nouveau container. Dans un second temps il s’agit d’une meilleure gestion de l’espace disque lorsque l’on fait plusieurs instantanés d’un même container il ne copie que la partie du conteneur qui a changé. La finalité étant de mettre la partition /var/lib/lxcsnaps sur mon Nas en évitant de sauvegarder les containers sur le serveur.

Pour bénéficier de ce système de fichiers je crée la partition mère lxc-data qui hébergera les différents sous-volumes

et de je la monte de façon permanente dans le fstab. Il est recommandé de monter les partitions et sous-volumes btrfs avec l’UUID. Ici l’UUID de sd4 est a69d9182-f4c7-4276-b35d-7d5f9bd50a57.

Ensuite je crée les deux sous-volumes,

et toujours pour que le montage soit permanent j’ajoute dans le fstab.

Voila l’environnement des containers est en place. A voir avec le temps si celui-ci viable pour mon utilisation de LXC, ça tombe bien cela fait parti du test.

Installation et configuration de LXC

Préparation du noyau :

LXC est en perpétuel évolution afin de bénéficier des récents changements, j’utilise un noyau plus récent que celui fournit avec Jessie. J’installe donc celui de la branche testing. Je crée un fichier préférence pour définir la priorité des dépôts :

Ensuite dans le fichier source.list d’apt j’ajoute :

Pour finir dans mon terminal :

Après un redémarrage me voilà en version 4.3 du noyau. En revanche, j’ai été obligé de désactiver la mise en veille de l’écran, car celui-ci ne se rallume pas une fois en mode veille.

Installation de LXC sous Debian 8.2 :

Souhaitant gérer la mémoire et le swap de mes containers je suis obligé d’activer le cgroup responsable de la mémoire qui est déactiver par défaut. Debian a choisi de ne pas activer par défaut ce cgroup afin de ne pas pénaliser les utilisateurs qui ne souhaitent pas les utiliser. Cela évite une trop grande consommation mémoire pour rien. Il me suffit d’ajouter l’instruction « cgroup_enable=memory » et pour le swap « swapaccount=1 » au démarrage de Grub.

Pour activer les changements sur grub.

Pour finir je redémarre mon hôte et vérifie l’installation de LXC

Tout est OK, je continue avec la configuration réseau de mon hôte. Pour plus de simplicité la configuration de l’interface réseau de mon hôte sera en mode bridge. L’activation du mode bridge sur le serveur hôte se fait dans le fichier interfaces. Attention toutefois à ce que le paquet bridge-utils soit installé sur l’hôte. Ce fichier régente la configuration des tous les périphériques réseau du système. Il se trouve dans /etc/network/interfaces.

Validation de la modification.

Sur le container qui me servira de base pour cloner les autres, j’applique la configuration réseau suivante.

LXC est maintenant en place, le gros du travail commence. Découvrir l’utilisation des containers, leur configuration, leur sauvegarde et bien d’autre. D’après mes premières manipulations, LXC est aussi facile d’utilisation qu’OpenVz. Il faut que je me familiarise avec les différentes commandes et la philosophie qui ne sont pas les mêmes.  J’ai encore pas mal des questions en suspend, c’est pour cela que je me lance dans ses essais grandeurs natures. Petit à petit je basculerai certains des mes serveurs sur cette nouvelle infrastructure en mode presque réel afin d’observer le comportement de tout ce petit monde. Suite au prochain épisode.

Merci à Deimos et au Wiki Debian qui m’ont beaucoup aidés à mettre en place cette plateforme de test.

 

 

Bloc-Notes : en octobre, régénère tes certificats

Bloc-Notes : en octobre, régénère tes certificats

Comme chaque année mes certificats arrivent à expiration, ne faisant cette procédure qu’une fois par an elle passe rapidement aux oubliettes. Voici un petit bloc-notes pour les prochaines années. Tous mes certificats SSL sont signés par Startssl que l’on ne présente plus.

Régénération des certificats

  1. Je supprime tous les certificats arrivant à expiration chez Startssl. Ensuite pour chaque sous-domaines je génère un fichier key et un fichier csr nécessaire pour la création du certificat chez Startssl.

Génération du fichier key

Le mot de passe (passphrase) est obligatoire sans quoi StartSSL va  refuser le fichier key et il doit contenir uniquement des chiffres et des lettres.

Génération du fichier csr en répondant aux question comme suit

Maintenant chaque sous-domaines possèdent un fichier key et un fichier csr, passons maintenant à création du certificat. A noter que le fichier key ne sera plus à générer l’année prochaine, je m’en servirai de nouveau pour générer mon fichier csr.

Lire la suite Lire la suite