Étiquette : Serveur

Geneweb – Raspberry – https – YunoHost

Tuto – Geneweb – Raspberry – https – YunoHost

Sur ce Tuto je vais tenter de vous expliquer comment avoir un accès https sur Geneweb en mode pur service et non en page web sur « /var/www » et sans script cgi-bin.

Je vais également vous expliquer les raisons de mes choix, le matériel utilisé, les problèmes rencontrés et solutions trouvées.

Alors pas un tuto traditionnel, linéaire où l’on y fait des copiés/collés sans réfléchir, mais mon objectif et mes doutes, interrogations avant de trouver la solution. Démontrer que tout n’est pas toujours limpide même si la solution est finalement plus simple mais autrement que nous l’avions pensé. Et que si ce tuto ne fonctionne pas in-texto pour vous, la solution existe certainement.

Du coup Sima tu ne fais pas vraiment pro !
Je ne suis pas pro mais éternel amateur dont je revendique le statut. Comme aux jeux d’échecs, on apprend beaucoup plus en analysant nos déboires que nos victoires !
Ouah sima en plus t’es philosophe !
Ouais !

  1. Matériels
  2. Explication de mes choix
  3. Rapsberry
  4. Geneweb
  5. Défi https et problème rencontrée.
  6. Appel à un ami !
  7. La solution via Yunohost
  8. Pour conclure

1 Matériels

– Rapsberry pi3 avec sd noobs et disque dur externe ssd pour les sauvegardes.
– Serveur avec couche YunoHost

2 Explication de mes choix

Je souhaitais que Geneweb soit séparé pour plusieurs raisons.

  • a – Des craintes dont certaines pas forcément fondées puisque pas testées mais je ne souhaitais pas prendre le risque. Mettre Geneweb sur le serveur sous Yunohost en mode service avec stunnel4 pour le https, seule solution que j’avais trouvé à une époque. Pas envie non plus de le mettre dans « /var/www/ » avec un cgi-bin qui m’aurait obligé à apporter des modifications que peut-être Yunohost aurait viré lors des mises à jours et aussi pour ne pas perturber la cohérence du serveur sous Yunohost.
  • b – Laisser la possibilité de donner la main en mode administrateur à ceux qui souhaiteraient parmi les membres de cette généalogie… Aller au-delà de compléter les informations généalogiques et pourquoi pas gérer la totalité en mode admin. On se doute que je ne souhaite pas donner des droits administrateurs sur mon serveur perso sous Yunohost. D’où l’idée de le séparer.
  • c – Je n’avais pas envie de gérer un ième serveur web avec Apache ou Nginx et le tutti-conti. Quelque chose qui soit le plus simple possible allant à l’essentiel.

3 Rapsberry

Un Rapsberry oppérationel, je ne vais pas faire un tuto sur le sujet pour peu que vous ayez une carte sd Noobs, vous avez juste à vous laisser guider, il existe plein de tutos sur le web.

Penser à changer le mot de passe par défaut, activer SSH, changer le numéro de port, mettre une IP fixe (moi je l’ai fait depuis ma freebox où j’attribue une ip au Raspberry). Pas d’Apache ou Nginx, ni base de données, on reste minimaliste.

4 Geneweb

Installer en mode service avec un simple apt. Du coup ce sera la version des dépôts, la version Geneweb 6.08 même s’il existe la version 7 sur un GitHub.

On peut juste faire :

apt install geneweb

et configurer certains fichiers à la main.

Le plus simple est de tout installer, ça reste très léger :

apt install geneweb geneweb-gui gwsetup gwtp

En allant sur localhost:2317 vous accédez à geneweb (vide).
En allant sur localhost:2316 vous accédez à gwsetup qui vous permettra de créer une base généalogique ou d’en charger une existante (ce que j’ai fait).

Vous retrouverez tout (l’essentiel) dans « /var/lib/geneweb/ »

J’ai modifié à la main le fichier ma_base.gwf car j’utilise des fonctions pas prévues dans l’outil gwsetup.

gwsetup vous propose de mettre un « Ami » (accès à tout l’arbre généalogique sans droit de modification) et un « Magicien » (droit de modification de l’arbre généalogique.
Or moi j’ai un fichier (file-friends.auth) où se trouvent tous les « Amis » et un autre (file-wizards.auth) où se trouvent tous les « Magiciens ». Ces fichiers se créent à la main, au fil du temps où vous ajoutez ou supprimez des « Amis » et/ou « Magiciens » et vous nommez vos fichiers comme vous voulez et les mettre dans « /var/lib/geneweb/ »

Il suffit dans « /var/lib/geneweb/ma_base.gwf » de mettre en commentaire deux lignes et en rajouter deux autres :

# friend_passwd=
# wizard_passwd=
friend_passwd_file=file-friends.auth
wizard_passwd_file=file-wizards.auth

Tout fonctionne bien en localhost:2317 et depuis un pc du réseau http://IpduRapsberry:2317 soit du genre : http://192.168.xx.xx:2317

Faire une redirection sur la freebox pour que tout ce qui vient sur le port 2317 arrive bien sur le Rapsberry et non sur l’autre serveur.

Test extérieur ça fonctionne mais en http et pas en https

Défi : que ça passe en https. Problème, difficulté rencontrée.

5 Défi https et problème rencontrée.

Donc dans mon idée il y avait

Sauf qu’à l’étape « a » ça se passe mal. « certbot » (qui permet de générer des certificats LetsEncrypt) me crie dessus me disant qu’il ne s’agit pas d’un serveur web qu’il n’y a ni Apache ou Nginx ou autre et que j’aille me faire foutre voir ailleurs, je n’aurais pas de certificats LetsEncrypt.

Là je reste interdit, que faire ? Des certificats auto-signés qui afficheraient des messages d’alerte sur les navigateurs ? Pas top…

Un petit tour chez mon fournisseur de nom de domaine (Gandi) et une solution possible… Je peux générer mes propres certificats et les soumettre à leur signature, solution possible, payante, sans certitude absolue mais une bonne piste…

Que faire ? Appel à un ami ?

6 Appel à un ami !

Quand on est confronté à un problème, on en fait parfois une fixette comme une poule ou un coq qui découvre un cure-dents.

Gros plan sur la tête d'une poule aux plumes brun-noir et à la crête rouge vif, l'œil jaune cerclé d'or fixant l'objectif avec curiosité
L’œil rond et pénétrant de cette poule brune capté à la faveur d’un portrait serré, quelque part entre curiosité et étonnement.

Appeler un ami c’est l’espoir d’avoir une solution, ou des pistes et au pire ça fait du bien de chialer sur l’épaule d’un autre.

La victime fût Benzo, Le pauvre… Pourquoi lui ? Déjà on s’entend bien, c’est un pro, et je sais qu’il connaît bien Yunohost et qu’il a des services en parallèle…

Il ne connaît pas Geneweb mais à bien identifié mon problème, pas de solution immédiate, mais plein d’échanges d’idées : (…) si tu crées un domaine sur yunohost et fait un script pour renvoyer les certificats, écrire une redirection (…).

Ça part dans tous les sens, ça fuse sans solution concrète… Mais, mais, mais ça fait du bien et de ma vision d’une poule face au cure-dents, j’ai une vision bien plus panoramique.

Dès qu’on raccroche, j’ai le déclic… domaine Yunohost, redirection !

7 La solution via Yunohost

Le domaine (sous domaine) YunoHost, j’en ai un inutilisé genre mon-arbre.MonNomDeDomaine.fr avec les certificats LestEncrypt générés et renouvelé automatiquement.

Si je ne l’avais pas ça se crée au simple clique sous Yunohost. Plus qu’à compléter deux lignes chez le fournisseur de nom de domaine, si vous ne savez pas quoi mettre, YunoHost vous le dit !

Bref, nom de domaine fait !

Je me souviens qu’il existe une app sous Yunohost pour les redirections.
J’installe sous Yunohost « Redirect » et le configure comme suit :

Capture d'écran du formulaire de paramètres d'installation d'une application Redirect sur YunoHost, avec les champs libellé, domaine, chemin URL, emplacement de destination et type de redirection en proxy NGINX
Configuration d’une redirection proxy sous YunoHost, permettant d’exposer une application locale (ici un Raspberry Pi) via un domaine public avec certificat SSL.

* Après vérification, c’est juste le / avec rien derrière.

Si vous mettez « /votre_base »    « votre base » étant une base généalogique existante ça fonctionne et vous arrivez directement sur la base. Le souci est que si vous avez plusieurs bases, ou souhaitez en créer d’autre, vous n’arriverez que sur la base que vous aurez mise derrière le « / ».

Il n’est pas possible de vérifier la configuration après installation de Redirect, ni la modifier, il faut faire « Supprimer » et installer de nouveau, comme je l’ai dit, ça prend moins d’une minute.

Lors de vos tests geneweb depuis le navigateur, pensez à bien vider votre cache avant chaque tentative, pas un simple rafraîchissement de la fenêtre, j’ai galéré un moment à cause de cela.

Dans « Emplacement de destination » mettez l’IP interne d’accès à votre geneweb, donc sur le port 2317 et en http, soit http://192.168.xx.xx:2317

Dans « Type de redirection » 4 choix : choisissez Proxy, invisible accessible à tout le monde comme sur l’image.
Bref vous arriverez directement sur la page d’accueil en tapant sur votre navigateur :
https://nomsousdomaine.nomdomaine.fr

Le mieux est d’arriver sur la page d’accueil et taper le nom de la base généalogique sur laquelle on souhaite aller:

Capture d'écran de l'interface d'accueil du logiciel GeneWeb version 6.08, accessible via le navigateur Firefox à l'adresse genea.chispa.fr, avec un champ de saisie pour ouvrir une base généalogique
L’interface web de GeneWeb 6.08, hébergée à l’adresse genea.chispa.fr, permet d’accéder à une base généalogique personnelle en saisissant son nom.

page accueil des bases geneweb

8 Pour conclure

Un Raspberry avec Raspbian sur lequel on installe Geneweb et rien de plus.

Sur le serveur YunoHost créer un domaine et générer les certificats LetsEncrypt (chez votre fournisseur de nom de domaine apporter les précisions « AAAA » et « CNAME » à votre nouvelle création (si vous ne savez pas quoi mettre, suivez les conseils YunoHost, vous aurez juste à faire des copiés/collés). Installer l’application « Redirect », la configurer… Et c’est terminé.

Un Grand merci et bravo aux développeurs et contributeurs de Yunohost et de ses applications.

Je pense donc qu’il est possible d’installer geneweb avec simple « apt » sur un serveur Yunohost avec la redirection qui va bien… Mais ça je n’ai pas testé.

Les utilisateurs pourrons se connecter en https sur le domaine que vous aurez créé genre : hppts://geneweb.nom_domane.fr

Sur votre Yunohost, ne vous connectez pas directement en cliquant sur la brique, vous ne pourrez pas vous connecter en  « Ami » ou « Magicien » car je pensez qu’il est attendu un identifiant enregistré sous Yunohost.

Hein sima, tout ce baratin pour une si courte conclusion !
Hé oui, c’est plus un retour d’expérience qu’un tutoriel !

J’envisage écrire un autre tutoriel, plus technique, factuel, sans y raconter ma vie pour le site officiel Geneweb

Le billet Geneweb – Raspberry – https – YunoHost est apparu en premier sur le blog de Sima78.

Blog – le retour de sima78

Le retour de Sima78

Ok, je ne suis jamais vraiment parti mais il y a eu des changements et d’autres à venir.

Un serveur avec YunoHost, et le blog est dessus. Alors, oui, il reste du travail à faire.

Premier changement, j’ai créé un sous domaine pour le blog, même si j’ai créé une redirection, le mieux pour ceux qui suivent le blog est de reprendre la nouvelle URL.
Donc sous Yunohost, mais reste du taf !

Le blog

  • Reprendre tous mes billets car les images ne s’affichent plus, ce n’est pas lié à YunoHost mais au fait d’avoir créé un sous domaine, en effet les images pointent sur « sima78/public/etc » alors qu’elles sont dans « public/etc ». Donc reprendre tous mes billets car si pour certains les images ont peu d’importance ce n’est pas le cas des tutoriels. Heureusement contrairement à Iceman qui a dû revoir plus de mille billets, j’ai l’avantage du paresseux qui publie peu.
  • En profiter pour refaire les catégories car je trouve que c’est un peu le bordel, le fouillis.
  • Revoir le thème.
  • Apparament la mise-à-jour de Dotclear ne se fait pas directement depuis l’interface admin du blog… ça ne fonctionne pas. Je pense que cela dois ce faire depuis YunoHost.

Nextcloud

  • Voir d’où vient le problème de synchronisation ! Pour l’instant je n’ai essayé que la synchronisation des contacts et de l’agenda avec mon ordiphone et ça ne fonctionne pas alors que je mets la bonne url, le bon « user » et bon mot de passe. Je n’ai pas encore essayé la synchronisation de « Carnet » ni des dossiers du cloud.
  • Après quelques tests et essais, toutes les synchronisations fonctionnent (contacts, agenda, carnet, et dossiers)

Grande interrogation ?

Geneweb !

J’utilise Geneweb 6.x, mais je teste depuis un certains temps Geneweb 7.x en localhost.

  • Dois-je installer Geneweb7.x à la main avec un « demons » qui se lance automatiquement à chaque redémarrage su serveur ?
  • Dois-je travailler sur un app Geneweb7.x pour YunoHost ? D’autres ont essayé avec la version 6.x, ce qui n’est pas une bonne idée, autant partir sur la version 7 qui est « responsive » à souhait et je pense plus facile à installer…

Les soucis :

  • je ne me vois pas ouvrir un GitHub, ni créer une machine virtuelle de test, donc déjà c’est mal parti, j’inspire de plus en plus au moindre effort, je veux bien contribuer aux scripts Yunohost, avec mes modestes connaissances.
  • Je pense qu’il faut revoir certaines parties de Geneweb pour une réelle convivialité administrative car s’il existe deux niveaux (ami pour consulter l’arbre généalogique et magicien pour pouvoir le modifier), le vrai administrateur est celui qui à la main sur le serveur pour ajouter (des amis avec mot de passe ou magiciens et autre configurations qui se font à la « mano ») et pour améliorer cela il faut voir avec ceux qui sont capable de développer/améliorer Geneweb.

En cours :

J’ai apporté pas mal de modification concernant les DNS chez Gandi, il m’en reste encore quelques-autres à faire. En fait j’ai encore pas mal de choses à voir comme installer d’autres blogs etc.

Voilà où j’en suis actuellement.

Iptables – insserv: warning: script ‘moniptables’ missing LSB tags and overrides

Ces derniers temps j’avais le message suivant:

insserv: warning: script 'moniptables' missing LSB tags and overrides

Ceci-dit, cela n’empêchait pas de fonctionner.
Je jette un oeil sur l’entête:

$ more /etc/init.d/moniptables | less
#!/bin/bash

## BEGIN INIT INFO
# Provides:          moniptables
# Required-Start:
# Required-Stop:
# Default-Start:
# Default-Stop:
### END INIT INFO

J’arrête le service:

# service moniptables stop

Avec un éditeur je le modifie ainsi:

#!/bin/bash
### BEGIN INIT INFO
# Provides:          moniptables
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Démarre les règles iptables
# Description:       Charge la configuration du pare-feu iptables
### END INIT INFO

Je relance le service

# service moniptables start

Je vérifie:

# service moniptables status
● moniptables.service
   Loaded: loaded
   Active: active (exited) since dim. 2019-07-07 17:59:10 CEST; 36s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 2048 ExecStart=/etc/init.d/moniptables start (code=exited, status=0/SUCCESS)

J’automatise le démarrage.

# update-rc.d -f moniptables default

Tout fonctionne correctement!

Petit clin d’oeil à Tutox pour son update-rc.d (on se comprend, c’est entre nous…).

Renouvellement des certificats LetsEncrypt et message d’erreur.

Arrive le moment du renouvellement de mes certificats Let’s Encrypt. Oui, je sais, il suffit de le faire de façon automatique par une tâche cron… Mais cela n’aurait pas empêché les messages d’erreurs.

Il faut dire que j’avais un peu « bricolé » mon serveur ses derniers temps et activé de nouveaux sites et autres bricoles.

Bref, je lance le renouvellement des certificats par:

# /opt/letsencrypt/letsencrypt-auto renew

Et là j’ai le message d’erreur suivant:

(...)
Attempting to renew cert (chispa.fr/) from /etc/letsencrypt/renewal/chispa.fr.conf produced an unexpected error: Unable to find a virtual host listening on port 80 which is currently needed for Certbot to prove to the CA that you control your domain. Please add a virtual host for port 80.. Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/livechispa.fr/fullchain.pem (failure)
(...)

Et plus d’accès en https…
Suite à cela, je vous fais grâce de toutes mes tentatives de réparation plus laborieuses les unes que les autres multipliant les messages d’erreur.

Il y a un moment où il faut savoir se lever de sa chaise, prendre un thé…

Il y a un moment où il faut savoir se lever de sa chaise, prendre un thé avec des biscuits pour prendre du recul et appréhender le problème la tête reposée.

Je décide donc de faire le ménage, sur le serveur, la maison ça attendra.

Je désactive tous les sites dans /etc/apache2/sites-enabled/ avec la commande a2dissite

# a2dissite nom-du-site.fr

Je refais le site 000-default.conf dans /etc/apache2/sites-available/

# nano /etc/apache2/sites-available/000-default.conf

Configuration au plus simple :

<VirtualHost *:80>
# Redirect permanent / https://sima78.chispa.fr/
        ServerName chispa.fr/
        ServerAdmin mon-mail@truc.fr
        DocumentRoot /var/www/
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Redémarrage d’Apaches2

# systemctl restart apache2

Je recrée des certificats tout neufs

# /opt/letsencrypt/letsencrypt-auto --apache --renew-by-default -d monsite.fr

Au message :

1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.

J’ai choisi l’option 2

Tout c’est bien passé, pas de message d’erreur.

Reste à modifier le fichier de configuration Stunnel, car j’ai Geneweb qui tourne en service en passant par Stunnel pour un accès en https à Geneweb.

# nano /etc/stunnel/stunnel.conf

Je modifie les lignes pour mettre le chemin des nouveaux certificats

cert=/etc/letsencrypt/livechispa.fr/-0002/fullchain.pem
key=/etc/letsencrypt/livechispa.fr/-0002/privkey.pem

Un « reboot » et tout fonctionne de nouveau jusqu’à la prochaine aventure.
Pour info, la configuration réécrite de 000-default.conf lors de la création des nouveaux certificats :

<VirtualHost *:80>
# Redirect permanent / https://sima78.chispa.fr/
        ServerName chispa.fr/
        ServerAdmin chispa.admin@free.fr
        DocumentRoot /var/www/
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =chispa.fr/
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noete

Pour automatiser le renouvellement de certificats, je vous invite à lire l’excellent billet de Tutox « Renouveler automatiquement son certif Let’s Encrypt (one shot)« 

Bien choisir son suffixe au nom de domaine

Toute notre attention sur le suffixe du nom de domaine.

Le suffixe du nom de domaine ne se choisi pas à la légère et ne sert pas qu’à faire joli, rigolo ou original.
Vous savez c’est le fameux « .truc » qui termine le nom de domaine, les .fr, .com, .net, .radio, bref, vous m’avez compris et je ne peux les lister ici tant il en existe.

Je ne vais pas non plus rentrer dans le détail de la façon dont est construit un nom de domaine, mais juste quelques précision sur le TLD le « .truc » qui termine un nom de domaine.

Le choix a toute son importance et je pense qu’il ne faut pas se focaliser sur la prétendue signification, si elle a son importance, elle ne se suffit pas à elle seule.

On lit sur de nombreux site que .org = organisation, .biz=Business, .com=commerce, etc., ceci-dit il faut être bien plus attentif à cette petite terminaison de nom de domaine car elle implique bien plus qu’on ne le pense.

Si j’écris ce billet c’est qu’avant avoir participé à la présentation de Stéphane Bortzmeyer, je ne m’étais jamais interrogé sur l’importance du TLD, pour le coup j’écris ce billet sans prétention mais qui j’espère sera utile à certains.

Pour faire court il y a les TLD Country-code spécifiques aux pays correspondants (.fr), les TLD génériques pour déterminer plutôt un champ thématique (.com), les TLD sponsorisés pour lesquels il faut remplir les conditions d’une charte établie par le sponsor (entreprise, organisme, etc.).
Et tous ces TLD dépendent de registres de noms de domaine « TLD Manager » dépendants de différentes juridictions en fonction de leur pays d’implantation.

Et, en prime, les TLD ICANN comme .pizza dépendent de l’ICANN et du contrat états-unien passé avec elle. Cela peut faire des conflits comme le .amsterdam qui a annoncé que, questions données personnelles, il respecterait la loi néerlandaise, et pas son contrat ICANN.

Citation que j’ai entièrement pompé sur une indication d’un certain S. B. 😉

Le TLD détermine la loi nationale applicable en cas de conflit.

Je m’explique: imaginons que mon blog est celui d’une organisation d’échange de matériel divers et pour signifier que je suis une organisation je mets à la suite de sima78 le .org

Voilà, je suis une organisation d’échange matériel, reste plus qu’à mettre du contenu pour montrer mes échanges… Mais imaginons que je propose un objet prohibé par la loi Étasunienne je peux me voir intenté un procès par ce dernier. En effet si le TLD manager de .org est chez Public Interest Registry, association sans but lucratif elle est domiciliée aux USA… Je peux même obtenir le pactole en proposant un objet répréhensible également par la loi Française et Étasunienne, deux procès puisque je suis auto-hébergé en France…

L’extension du nom de domaine ne se choisi pas à la légère et ne sert pas qu’à faire joli, rigolo ou original.

Il faut bien le penser!

Vous voulez en savoir plus sur comment bien nommer les différentes parties d’un nom de domaine c’est chez le spécialiste Bortzmeyer.

A lire également, l’excellent rapport EFF par Jeremy Malcolm.
Encore merci à Stéphane Bortzmeyer.

Voir aussi la « Root Zone Database » sur Iana

Sauvegardes au quotidien – Rdiff-Backup et MySqlDump

Rdiff-Backup et sauvegardes

J’avais déjà écrit un billet intitulé « Scripts de sauvegardes journalières et hebdomadaires » et un commentaire de Tetsumaki m’a donner à réfléchir.

Pourquoi je fais compliqué quand ont peut faire simple?

Soit, j’aime les scripts, et du coup il m’arrive de m’emballer et il fallait un disque de sauvegarde assez « gros »… Et j’ai décidé de regarder du côté de Rdiff-Backup. J’ai été séduit !

Je fais donc un nouveau billet sur le sujet de la sauvegarde sans pour autant supprimer l’autre…

Rdiff-Backup existe aussi pour Windows, je suppose qu’il doit exister une interface graphique , j’avoue ne pas avoir cherché puisque je m’en sert pour la sauvegarde d’un serveur, qui n’a pas d’interface graphique et de façon automatisée.

Bien entendu, une sauvegarde ne se fait pas sur une partition du disque dur, pas même sur un autre disque dur sur le même pc, mais sur un disque externe ou un pc distant…

Une modification à été apporté le 07/12/2023 concernant le message d’érreur :

/bin/sh: 1: root: not found

Lire la suite…

Sauvegarde avec Rdiff-Backup et MysqlDump.

Dans un premier temps j’ai défini les répertoires que je souhaitais sauvegarder, puis j’ai créé un fichier texte pour les regrouper.
Dans cet exemple, je décide de sauvegarder « /etc », « /home », « /var »

# nano /root/scripts/include-dir.txt

Copiez ce qu’il y a ci-dessous:

/etc
/home
/var

Maintenant nous allons créer le script dans la « cron.daily »

# nano /etc/cron.daily/backup

Copiez en adaptant ce qui suit.

#!/bin/bash
rdiff-backup --include-globbing-filelist /root/scripts/include-dir.txt --exclude '**' / /dir/de/sauvegarde/backup/

/dir/de/sauvegarde/backup/ est la destination de la sauvegarde, je vous laisse l’adapter selon vos choix.

Le rendre exécutable:

chmod +x /etc/cron.daily/backup

Je souhaite également sauvegarder des bases de données, on peut aussi le faire via Rdiff-backup, personnellement le préfère utiliser « mysqldump » (et oui, je suis un animal d’habitudes) :

# nano /etc/cron.daily/mysql-backup

Copiez en adaptant ce qui suit.

#!/bin/bash
mysqldump -u nextcloud -motdepasse nextcloud > /dir/de/sauvegarde/bd/nextcloud.sql
mysqldump -u dolibarr -motdepasse dolibarr > /dir/de/sauvegarde/bd/dolibarr.sql
mysqldump -u grr -motdepasse grr > /dir/de/sauvegarde/bd/grr.sql

Le rendre exécutable:

chmod +x /etc/cron.daily/mysql-backup

Pour que cela se fasse automatiquement et chaque jour, mettez le tout dans votre crontab:

# crontab -e

Copiez en adaptant ce qui suit.

PATH=/usr/sbin:/usr/bin:/sbin:/bin
SHELL=/bin/sh
MAILTO=""
# m h  dom mon dow   command
0 10 * * * root sh /etc/cron.daily/backup >/var/log/monbackup 2>&1 # JOB_BACKUP
0 15 * * * root sh /etc/cron.daily/mysql-backup >/var/log/monsav-bd 2>&1 # JOB_MYSQL-BACKUP

<Ajout du 07/12/2023>

J’ai le message d’erreur suivant : /bin/sh: 1: root: not found

Il arrive que root n’a pas de Shell et que l’user principal peut utiliser « sudo » sans confirmation de mot de passe, le cas par exemple de Raspberry, d’où un mot de passe fort pour cette user.

# nano /etc/cron.daily/backup

Copiez en adaptant ce qui suit.

#!/bin/bash
sudo rdiff-backup --include-globbing-filelist /root/scripts/include-dir.txt --exclude '**' / /dir/de/sauvegarde/backup/
# crontab -e

Copiez en adaptant ce qui suit.

PATH=/usr/sbin:/usr/bin:/sbin:/bin
SHELL=/bin/sh
MAILTO=""
# m h  dom mon dow   command
0 10 * * * /etc/cron.daily/backup >/var/log/monbackup 2>&1 # JOB_BACKUP
0 15 * * * /etc/cron.daily/mysql-backup >/var/log/monsav-bd 2>&1 # JOB_MYSQL-BACKUP

</Ajout du 07/12/2023>

Ceci-dit, il faut vérifier les sauvegardes, moi je simule une restauration dans un dossier de test, ici « test-sauv »

rdiff-backup --force -r now /dir/de/sauvegarde/backup/ /home/sima78/backup/rdiff-backup-data/test-sauv/

On peut voir les statistiques de la dernière sauvegarde

rdiff-backup-statistics /dir/de/sauvegarde/backup/

Ou la liste des incréments d’une sauvegarde

rdiff-backup -l /dir/de/sauvegarde/backup/

Vous pouvez aussi spécifier une durée de rétention des sauvegardes, dans le cas ci-dessous je supprime au-delà de 10 jours

rdiff-backup --remove-older-than 10D --force /dir/de/sauvegarde/backup/

Vous pouvez mettre D pour(Day), W pour(Week), M pour (Month) et Y pour (Year).
Donc voilà ma base, maintenant vous pouvez affiner comme par exemple avec mysqldump par lequel il est possible d’exporter plusieurs bases de données en une seule commande:

mysqldump --databases database1 database2 [...] > /home/sima78/my_databases.sql

Bref plein de possibilités il suffit de faire un « man » pour s’en rendre compte

man rdiff-backup
man mysqldump

Scripts de sauvegardes journalières et hebdomadaires

Bin-Bash, scripts, ligne de commande

J’avais pris cela sur un site, je ne sais plus où et ça a bien fonctionné un certain temps puis plus rien lorsque j’ai passé un des serveurs qui était sous Ubuntu serveur 12.04 sous Debian 8.7

J’ai donc repris en grande partie, même si les bases restent les mêmes. Voici donc la version fonctionnelle.

Sur Debian 8.7

Automatiser les sauvegardes.

Dans cet exemple, il s’agit de sauvegarder chaque jour de la semaine (samedi, dimanche, lundi, mardi, etc.), puis le vendredi soir, on sauvegarde sur le n° de la semaine. Puis on repart sur samedi, dimanche, etc.

Avant tout vous devez définir le « lieux » de sauvegarde, s’agit-il d’un disque dur supplémentaire, d’un disque externe, d’un lieu distant (par ssh ou autres)… Bref vous devrez adapter les scripts à vos choix et besoin.

Il s’agit là d’une idée sur le principe, à chacun de se l’approprier.

Ici je vais partir du principe que j’ai un disque dur chiffré supplémentaire monté sur /mnt/
Il est nommé « save » et le répertoire de sauvegarde est « s_server »

ce qui donne le chemin de sauvegarde « /mnt/save/s_server »

Avant tout, vous devez savoir en quelle langue sont vos jours de la semaine (anglais, français, etc.).

date +%A
vendredi

Le résultat est Français.
Connectez-vous en administrateur.

su root

Créer le script qui créera les répertoires des n° de semaine et les jours de la semaine.

#!/bin/bash
for x in lundi mardi mercredi jeudi vendredi samedi dimanche {01..52}
do
mkdir $x
done

Pourquoi {01..52} et non {1..52}? il suffit de lire le man date

man date
(...)
%V     ISO week number, with Monday as first day of week (01..53)
(...)

On voit donc qu’il faut numéroté de 01 à 52, car la 53ème semaine, lorsqu’elle existe est à cheval entre deux années et c’est donc pas dramatique de rater une semaine.

Rendre le script exécutable et on le place (dans notre exemple plus haut) dans « /mnt/save/s_server/ », puis on l’exécute…

./faire_mkdir.sh

Un petit « ls » pour vérifier que tout est ok.

Nous allons créer un fichier des dossiers à exclure. Si votre sauvegarde est locale, il faudra exclure le dossier de sauvegarde 😉 dans notre cas « /mnt/save/s_server/ » vous pouvez exclure tout ce qui ne vous semble pas judicieux, à vous de voir.

cd /etc/
nano rsync.exclude

On y met tout ce que l’on souhaite exclure.
Ci-dessous « /mnt/ » obligatoire dans l’exemple puisque la sauvegarde ce fait sur « /mnt/save/s_server/ », le reste en fonction de vos besoins.
Faites un copié/collé de ce qu’il y a ci-dessous.

# Mettez ici tous les dossiers que vous souhaitez exclure
# - /boot/
- /media/
- /lost+found/
- /mnt/
- /proc/
- /opt/
- /run/
- /srv/
- /tmp/
- /sys/

Créer les deux scripts ci dessous:

nano /etc/cron.daily/jour.sh

Copié/collé de ce qu’il y a ci-dessous

#!/bin/bash
# On va l'appeler "jour.sh"
# Sauvegarde quotidienne
jour=$(date +%A)
source="/"
destination="/mnt/save/s_server"
rsync -aurov -progress --delete --stats --exclude-from=/etc/rsync.exclude $source $destination/$jour

Ce qui donne le chemin /etc/cron.daily/jour.sh et rendez-le exécutable.

chmod +x /etc/cron.daily/jour.sh

Puis:

nano /etc/cron.weekly/semaine.sh

Copié/collé de ce qu’il y a ci-dessous

#!/bin/bash
# On va l'appeler "semaine.sh"
#  Sauvegarde hebdomadaire
semaine=$(date +%V)
source="/"
destination="/mnt/save/s_server"
rsync -aurov -progress --delete --stats --exclude-from=/etc/rsync.exclude $source $destination/$semaine

Ce qui donne le chemin /etc/cron.weekly/semaine.sh et rendez-le exécutable.

Chmod +x /etc/cron.weekly/semaine.sh

Maintenant il suffit juste de créer la crontab

crontab -e

Choisissez votre interprétateur texte « nano » ou « vi » et copiez les lignes ci-dessous:

PATH=/usr/sbin:/usr/bin:/sbin:/bin
SHELL=/bin/sh
MAILTO=""
# m h  dom mon dow   command
0 23 * * * /etc/cron.daily/jour.sh >/dev/null 2>&1 # JOB_1
30 23 * * 5 /etc/cron.weekly/semaine.sh >/dev/null 2>&1 # JOB_2

Pour Ubuntu ce devrait ressembler à cela:

PATH=/usr/sbin:/usr/bin:/sbin:/bin
SHELL=/bin/sh
MAILTO=""
# m h  dom mon dow   command
0 23 * * * sudo /etc/cron.daily/jour.sh >/dev/null 2>&1 # JOB_1
30 23 * * 5 sudo /etc/cron.weekly/semaine.sh >/dev/null 2>&1 # JOB_2

Ensuite vérifier le lendemain si la sauvegarde à bien fonctionné et revérifiez en fin de semaine.

https pour autres ports ou services ex Geneweb – stunnel4

geneweb https stunnel4

Si vous avez une application avec un protocole ne supportant pas SSL, la solution est de l’encapsuler dans un tunnel SSL.
Bien entendu, il s’agit là d’un exemple, qui fonctionne chez-moi, n’hésitez pas à améliorer.

Geneweb en https

Depuis que mon serveur est en https, geneweb restait en http. Geneweb se lance sur mon serveur en service (il est son propre serveur) sur un port dédié. Une des solutions aurait été de l’installer sur /var/www/ avec un script CGI… Ce que je ne souhaitais pas.
Donc mon exemple s’applique à Geneweb, mais en cherchant sur le web, vous trouverez comment encapsuler d’autres protocoles tels que smtp, pop, vpn, imap…
Habituellement, on se connecte sur Geneweb en mode service sur le port 2317 (http://leserveur.net:2317) donc pas en https…

Voyons comment procéder…

sur Ubuntu 16.04 server

Geneweb et Stunnel

Installer Stunnel4

sudo apt-get install stunnel4

On se place dans le répertoire et on se positionne en Root, sinon tapez « sudo » devant chaque ligne.

cd /etc/stunnel
sudo -s

On génère les clés. On peut faire simple avec:

openssl req -new -x509 -nodes -days 365 -out stunnel.pem -keyout stunnel.pem #dans ce cas il faudra en tenir compte lors de la création du fichier « stunnel.conf »

Personnellement, j’ai procédé comme suit:

openssl genrsa -out cle-serveur.key 2048

Signature de la demande de certificat CSR.

openssl req -new -key cle-serveur.key -out demande-certif.csr

Le certificat auto-signé pour un an.

openssl x509 -req -days 365 -in demande-certif.csr -signkey cle-serveur.key -out cert-server.crt

On combine le certificat et la clé dans un même fichier.

cat cleserveur.key > server.pem && cat certserver.crt >> server.pem

On modifie les permissions.

chmod 0600 cert-server.crt cle-serveur.key server.pem

Ensuite je crée le fichier de configuration « stunnel.conf » dans /etc/stunnel/

« ; » signifie que c’est en commentaire, vous pouvez donc « fignoler » la configuration. Je n’ai pas tout traduit par paresse, mais c’est assez transparent.
Utilisez VI, ou nano, ou autre, selon vos habitudes, ici je vais utiliser nano

nano stunnel.conf

Ci-dessous mon fichier stunnel.conf

; **************************************************************************
; * Options générales                                                         *
; **************************************************************************
; Il est recommandé de changer les privilèges utilisateur et groupe
;setuid = stunnel4
;setgid = stunnel4
; un chroot pour un peu plus de sécurité
;chroot = /var/lib/stunnel4/
; Le fichier PID sera créé dans le chroot
;pid = /var/run/stunnel.pid
; Utile de mettre dans les logs pour suivre en cas de bug
foreground = yes
debug = info
output = /var/log/stunnel4/stunnel.log
; Enable FIPS 140-2 mode if needed for compliance
;fips = yes
; **************************************************************************
; * Service defaults may also be specified in individual service sections  *
; **************************************************************************
; Enable support for the insecure SSLv3 protocol
options = -NO_SSLv3
; These options provide additional security at some performance degradation
options = SINGLE_ECDH_USE
options = SINGLE_DH_USE
; **************************************************************************
; * Include all configuration file fragments from the specified folder     *
; **************************************************************************
;include = /etc/stunnel/conf.d
; **************************************************************************
; * Service definitions (remove all services for inetd mode)               *
; **************************************************************************
[geneweb]
accept = 22317
connect = 2317
cert=/etc/stunnel/server.pem
key=/etc/stunnel/cle-serveur.key

On modifie l’utilisateur et le groupe.

cd ..
chown -Rf stunnel4:stunnel4 stunnel/

Maintenant nous allons activer stunnel

nano /etc/default/stunnel4

Modifiez l’option suivante comme ci-dessous :

ENABLED=1

On redémarre Stunnel

/etc/init.d/stunnel4 stop
/etc/init.d/stunnel4 start

ou plus simplement

/etc/init.d/stunnel4 restart

Connexion à Geneweb en https

Sur cette exemple vous pourrez vous connecter sur Geneweb en https avec l’adresse suivante sur votre navigateur:
https://www.votre-verveur.fr:22317

Si vous utilisez iptables ou autre pare-feux, n’oubliez pas de le modifier et/ou si vous êtes auto-hébergé modifiez aussi la redirection de ports sur votre box….

Si vous avez déjà des certificats Let’s Encrypt, je pense que vous pouvez les utiliser en modifiant le fichier stunnel.conf, j’avoue ne pas avoir creusé la question puisque j’informe ceux que j’autorise à se connecter qu’ils doivent accepter le certificat lors du message d’alerte de leur navigateur.

https sous Apache – Même à l’école je n’ai jamais eu un A

https sur serveur Ubuntu facile

Depuis fin décembre le blog est enfin en accès https… Je devais le faire aux vacances de Pâques 2016, j’avais repoussé à juillet, puis aux vacances de la Toussaint.

Oui, je suis un fervent adepte de la procrastination, je suis de ceux qui remettent au sur-lendemain dans l’espoir qu’un autre le fera demain. Mais là, je dois me rendre à l’évidence, jamais personne ne le fera à ma place. Je l’ai donc fait entre Noël et le Jour de l’An.

Une fois fini, je fais un petit test sur SSL Server Test… Et là, j’ai un A!
Certains diront, et à raison, Let’s Encrypt c’est pas non plus le top du top… Ok, mais m@rd@ alors! P#tain j’ai un A! Même à l’école j’ai jamais eu un A, alors laissez-moi savourer ce A.
Je vous mets la capture d’écran pour me la péter vous montrer et ensuite on passe à la configuration.

Résultat d'audit SSL affichant une note globale « A » avec des scores élevés pour le certificat, le support de protocole, l'échange de clés et la force de chiffrement.
Un serveur Apache sécurisé avec Let’s Encrypt obtient la note « A » au test SSL de Qualys SSL Labs.

Ubuntu server 16.04 sous apache

https sous apaches avec Let’s Encrypt

Je commence par installer « git » sur /opt/

sudo -s
apt-get install git
git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt --depth=1

→ « sudo -s » Je ne sais pas combien de sudo je vais devoir taper, sans doute plus de trois, alors « sudo -s »
→ « –depth=1 » Je ne souhaite pas récupérer tout l’historique du site.

Générer les certificats

/opt/letsencrypt/letsencrypt-auto --apache -d domaine.fr -d www.domaine.fr

Si vous avez plusieurs domaines, sinon vous pouvez faire simplement:

/opt/letsencrypt/letsencrypt-auto

Configurer le VirtualHost pour l’accès https

Allez dans /etc/apache2/sites-available et modifier les VirtualHost

cd /etc/apache2/sites-available
nano votredomaineSSL.fr

La configuration que j’ai mise

<VirtualHost *:443>
   ...
      SSLProtocol -ALL -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2
      SSLHonorCipherOrder On
      SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

      SSLEngine on
      SSLCertificateFile /etc/letsencrypt/live/domaine.fr /fullchain.pem
      SSLCertificateKeyFile /etc/letsencrypt/live/domaine.fr /privkey.pem
   ...
</VirtualHost>

Configurer le VirtualHost http pour une redirection https

cd /etc/apache2/sites-available
nano votredomaine.fr

La configuration que j’ai mise

<VirtualHost *:80>
...
      RewriteEngine on
      RewriteRule ^ https://www.chispa.fr%{REQUEST_URI} [L,QSA,R=permanent]
...
</VirtualHost>

Renouvellement du certificat

ATTENTION, le certificat n’est valable que 90 jours. On peut le renouveler avec la commande:

/opt/letsencrypt/letsencrypt-auto --apache --renew-by-default -d domaine.fr -d www.domaine.fr

Le mieux est de rendre automatique le renouvellement, heureusement Erika Heidi a créer un script pour nous, il s’agit de le-renew.sh
Je l’ai récupéré, rendu exécutable et mis dans la crontab

curl -L -o /usr/local/sbin/le-renew http://do.co/le-renew
chmod +x /usr/local/sbin/le-renew
crontab -e
0 6 * * 1 /usr/local/sbin/le-renew domaine.fr >> /var/log/le-renew.log

Chaque lundi à 6:00, la validité du certificat en question sera vérifié, s’il est toujours valable, au cas contraire il demandera le renouvellement.

Bon, normalement en bon « copiteur » vous aurez un A, et si en plus vous améliorez, je ne vous en parle même pas! Un A+ ou A++.

LVM et cryptsetup partitioner et chiffrer un disque dur

J’ai mis ce billet dans la catégorie serveur, mais en réalité cela s’applique à n’importe quel PC

Vous venez d’installer un disque supplémentaire sur votre pc.

Vous souhaitez le partitionner avec LVM (logical volume management ou gestion par volumes logiques) puis chiffrer les partitions avec Cryptsetup.

Prenons ici un disque dur de 1To et que l’on souhaite faire deux partitions qu’on nommera « donnees » et « save »

Vérifier les disques montés, et éviter de se tromper de disque. 🙂
Deux commandes utiles
sudo fdisk -l
sudo df -h

Avant tout, connaître sur quel « dev » se trouve le nouveau disque. 

sudo fdisk -l
(...)
Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 têtes, 63 secteurs/piste, 121601 cylindres, total 1953525168 secteurs
(...)
Le disque /dev/sdb ne contient pas une table de partitions valable
(...)

On commence par créer notre volume physique 

sudo pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created

Puis on crée le groupe de volume 

sudo vgcreate mvg /dev/sdb
  Volume group "mvg" successfully created

Maintenant on crée les volumes logiques (nos nouvelles partitions) :

sudo lvcreate -n donnees -L 700g mvg
  Logical volume "donnees" created
sudo lvcreate -n save -L 300g mvg
  Volume group "mvg" has insufficient free space (59267 extents): 76800 required.

Houps ! lors de la création du 2ème volume, il n’y a pas assez de place…
Solution et explication:
Il se trouve qu’il ne reste pas 300 Go de disponible mais, comme il l’indique seulement 59267 « extends ».
La taille d’un extend dépend des paramétrages utilisés lors de la création de la configuration LVM.
Par défaut, il fait des extends de 4 Mo.
Il indique donc très justement que pour créer un volume de 300 Go, il te faudrait 59267 « bouts » de 4 Mo.
Volume group « mvg » has insufficient free space (59267 extents): 76800
Pour utiliser tout l’espace restant, le plus simple est de lui indiquer une taille en extend, dans ce cas :

sudo lvcreate -n save -l 59267 mvg

Notez bien que ce n’est plus -L (taille) mais -l (extend), le petit l permet d’indiquer une taille directement en nombre d’extend, et pas en Mo/Go/To etc. »

Là le disque dur sous LVM est opérationnel…. Le chiffrage est un plus…

Maintenant je souhaite chiffrer les 2 partions créées, puis les monter respectivement dans « /mnt/donnees » et « /mnt/save »
Dans l’ordre: on se rend sur le répertoire /mnt, puis on crée les 2 répertoires (donnees et save).

cd /mnt
sudo mkdir donnees
sudo mkdir save

On chiffre les partitions avec cryptsetup, on y mets un type de fichier (là ext4) puis on les montes.

sudo cryptsetup -y --cipher=aes-xts-plain64 -s 512 create don /dev/mvg/donnees
sudo mkfs -t ext4 /dev/mapper/don
sudo mount /dev/mapper/don /mnt/donnees
sudo cryptsetup -y --cipher=aes-xts-plain64 -s 512 create sav /dev/mvg/save
sudo mkfs -t ext4 /dev/mapper/sav
sudo mount /dev/mapper/sav /mnt/save

Et voilà, c’est fini !

Pour « démonter » les volumes.

sudo umount /mnt/donnees
sudo cryptsetup remove don
sudo umount /mnt/save
sudo cryptsetup remove sav

Pour y accéder par la suite, à chaque démarrage il faudra taper les commandes suivantes:

sudo cryptsetup --cipher=aes-xts-plain64 -s 512 create don /dev/mvg/donnees
sudo mount /dev/mapper/don /mnt/donnees
sudo cryptsetup --cipher=aes-xts-plain64 -s 512 create sav /dev/mvg/save
sudo mount /dev/mapper/sav /mnt/save

Pour aller plus loin:
4 billets sur LVM et 2 sur le chiffrage sur le site Hoper sur l’onglet « Partage de connaissances »