Voilà un message d’erreur qui arrive lorsque l’utilisateur root n’a pas de Shell.
# cat /var/log/backup-rdiff
/bin/sh: 1: root: not found
/bin/sh: 1: root: not found
Comment y remédier ?
Plutôt que de refaire un tutoriel sur ce billet, je vais compléter un billet existant qui traite aussi bien de Rdiff-backup, les tâches Cron et MySqlDump.
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.
Je me suis lancé mais je dois vous l’avouer, ce qui m’a motivé est le commentaire de « ljf » sur le billet « Dotclear et Yunohost pas au point » et aussi la participation, in-situ, de Benzo, grande source de motivation !
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.
Contrairement à ce que je disais dans le précédent billet, je vais continuer mes publications puisque la migration sur le nouveau serveur ce n’est pas pour demain.
Contexte :
J’ai une vieille machine qui fait office de serveur, il est dans la salle à manger et Madame Sima ne supporte plus de voir et surtout d’entendre ce gros machin ronfler 24h/24h. J’ai depuis quelques mois une machine flambant neuf sans ventilateur qui dort dans son carton et comme tout bon procrastinateur que je suis, remettais au lendemain l’installation. La semaine dernière un ami est venu et il m’a motivé, je voulais un serveur avec Yunohost. C’est parti ! On installe Debian, puis la couche Yunohost. Pour les bases de données on y met l’application PhpMyAdmin (quitte à l’enlever plus tard), ça faisait looongtemps que je n’avais pas utilisé PhpMyAdmin, mais puisque Yunohost autant aller dans la simplicité.
Puis installer Dotclear pour y migrer mon blog, et là c’est le début des problèmes.
Je ne vais pas vous décrire tout dans le détail, ce sera déjà assez long ainsi, je vais essayer d’être le plus linéaire possible. Précision, à chaque fois que ça ne fonctionnais pas comme je le souhaitais, je suis reparti « from scratch«
Installation de l’app Dotclear pour Yunohost
Avant tout il faut créer dans Yunohost l’utilisateur qui sera admin du blog, c’est logique sinon on aura comme admi l’utilisateur par défaut de Yunoshost (si on en a créer qu’un). Donc créer l’utilisateur « sima78 », c’est simple c’est au clique.
Installation de l’app Doctlear
Il est demandé le nom de l’utilisateur qui sera admin, donc « sima78 » et où doit être installé Dotclear, par défaut « /dotclear2 » Etant donné que je devrais migrer 3 Dotclears appartenant à des personnes différentes, je mets donc « /sima78 »
Tout s’installe bien, je fais un diagnostique, tout est ok, je génère les certificats pour le blog, nickel, tout au clique et en toute simplicité, c’est magique ! C’est bluffant !
J’arrive sur Dotclear, tout beau, tout neuf ! Je me connecte en admi et je vois qu’il y a une mise à jour à faire. Premier clique et premier message d’erreur. Je ne l’ai pas noté mais en gros un fichier a été modifié pour l’app et ne permet pas la mise à jour automatique et nécessite une mise à jour manuelle. Je fais l’impasse sur la mise à jour.
Voyons deux problèmes « bases de données » et migration du blog (fichiers et dossiers).
Base de données : A l’installation de Dotclear, l’app crée une base de données appelé « dotclear2 » J’ai créé une base de donnée « sima78 », modifier le fichier inc/congif.php (via ssh et vim) et là je me rends compte d’un premier souci, Dotclear est dans var/www/dotclear2 et non dans /sima78 ? J’y reviendrai plus tard c’est un autre problème.
Créer sa base de données sous un autres nom et modifier le fichier de configuration ne fonctionne pas, j’ai plein de messages d’erreurs, pour que ça fonctionne un peu près correctement il faut importer sa base de données dans la base dotclear2. Bon, là je m’interroge déjà comment je vais faire pour les deux autres blogs. Bon j’ai une base de données qui fonctionne, pas au bon endroit, pas avec le nom que je souhaiterai, mais ça fait le boulot pour l’instant, pour un blog.
Importation du blog Vous vous souvenez, le répertoire « sima78 » ne s’est pas créé. Via ssh et mkdir je crée le répertoire « /sima78 » lui donne les mêmes droits que /dotclear2 et reparts « from scratch » (un parmi tant d’autres).
Mais non, rien n’y fait, il reste désespérément vide et il recrée un répertoire dotclear2 ou tout y est !
Je fais l’impasse et me contenterais pour mes tests du répertoire imposé.
Dans l’interface admi j’importe mon blog, tout semble bien se passer, je vais sur le blog, et là horreur, plus de thème, plus de plugin, un blog à la lynx, pas d’image, rien. Je repars de zéro et tente d’importer mon blog là via ftp, parfois comme un bourrin, d’autres fois plus finement, mais non, rien de satisfaisant.
Pour résumer : Au pire plein de messages d’erreurs et pas grand-chose qui fonctionne, au mieux un blog avec un thème, les liens entre articles qui fonctionnent, mais pas d’image (média) dans mes billets ni de plugin dans mon blog. Pour les plugins ce n’est pas un vrai problème, j’en ai peu, trois de mémoire (map du site, contact, et un captchat pour les commentaires), mais pour les images c’est un véritable problème car leurs liens relatifs est /sima78/public/etc
Les améliorations à apporter
Certains me dirons : bah sima ! Vas-y ! Yapuka ! Sauf que je ne sais pas faire, alors apporter mes critiques est déjà une contribution, d’autant plus que j’y ai passé du temps, pourtant dès que j’ai vu que le répertoire ne se créait pas et que l’on ne pouvait pas faire fonctionner avec plusieurs bases de données, chacune liée à un blog différent… dans l’immédiat, je savais déjà que je n’utiliserai pas Yunohost.
Donc les améliorations pour l’app Dotclear :
Faire en sorte que la mise-à-jour au clique fonctionne ! Car manuellement sous yunohost, je n’y crois pas.
Que Dotclear crée et s’installe sur le répertoire demandé !
Lors de l’installation, que soient posés les questions « nom de la base de données », « user de la base de données », « mot de passe de la base de données », comme c’est le cas lorsque l’on installe pour la première fois un dotclear, c’est implémenté dans le système d’installation de Dotclear alors pourquoi pas dans l’app. Et le top, serait que préalablement l’on nous demande de télécharger la base de données. Bref, la possibilité d’avoir plusieurs bases de données pour plusieurs blogs.
Et là il sera possible de migrer des blogs Dotclear dans Yunohost. Pour l’instant il est juste possible de se créer un blog Dotclear « from scratch » dont je ne suis pas certain qu’il soit facile de le migrer par la suite ailleurs.
Cela-dit je suis resté bluffé par Yunohost et j’ai vraiment apprécié, j’ai fait des tests en installant d’autres applications. Je pense que c’est vraiment une solution d’avenir… Mais sous prétexte de simplicité il ne faut pas perdre de vue que la maîtrise des données personnelles c’est aussi pouvoir les migrer où l’on souhaite par la suite.
Et quand ça ne va pas comme je le souhaite, comment faire un break, si ce n’est avec Kurtis Blow
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…).
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/
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.
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 :
Toute l’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.
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 »
/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) :
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.
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:
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.
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.
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…
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 »
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
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.
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.
→ « 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.
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
Tuto – Erreur cron – root: not found
Dotclear et Yunohost pas au point.
