Je cherche un moyen d’appliquer des configurations “custom”. Lors d’une modification d’un fichier de configuration, le système prévient que ce fichier ne sera plus modifier par la suite même pour une mise à jour.
J’aimerai pouvoir appliquer ce genre de configuration: Tuto: Bloquer les requêtes selon le pays
Ou modifier quelques ligne dans la configuration du serveur ssh.
Je voulais donc me tourner vers la création de hook, mais je ne sais pas trop quels sont les bonnes pratiques.
qui est copié dans /usr/share/yunohost/hooks/conf_regen/90-ssh_cequetuveux pendant l’install de l’app
Le nom du fichier est important: le fait que ça s’apelle xx-ssh_xxxxx fait que le hook sera appliqué (en plus du hook par défault) pendant la regen-conf (yunohost tools regen-conf ssh)
Dans le hook montré dans le lien, tu vois qu’il rajoute juste des lignes en plus à la fin du fichier, mais tu peux aussi faire des manips + avancée avec sed etc…
Du coup de ce que je comprends, il suffit que je dépose dans le dossier /usr/share/yunohost/hooks/conf_regen/ un fichier par exemple xx-ssh-xxx pour faire les manipulations que je veux ?
Il n’est pas préférable d’utiliser le dossier /etc/yunohost/hooks.d/ ?
Arf oui normalement c’est dans /etc/yunohost/hooks.d mais d’expérience ça marchait pas … Ou alors il faut faire un sous-dossier intermédiaire qui s’apelle conf_regen sans doute … Je sais plus trop pourquoi j’avais fait ça mais bref, yep, faudrait réessayer …
Cela fonctionne parfaitement !
J’ai mis les hooks (scripts) dans le dossier /etc/yunohost/hooks.d/conf_regen et je peux effectuer les modifications de configuration !
C’est trop top
Je ne suis pas certain que mes scripts soient très propre mais ils font le travail.
Je peux fournir les hooks si cela peut intéresser certain
Oui ça m’intéresse @zulf , je gagnerai du temps.
Juste une question si tu sais (ou @Aleks) à quoi correspond pending_dir. Dans les 2 exemples, son positionnement est différent, $1 dans un cas et $4 dans un autre. J’ai pas eu le courage et pris le temps d’essayer de comprendre, un coup de main ne serait pas de refus.
J’avais essayé dans le passé et m’étais cassé les dents. Je plaçais les hooks dans /etc/yunohost/hooks.d au lieu de /etc/yunohost/hooks.d/conf_regen, du coup je n’y étais pas arrivé.
Mouarf oui ça c’est lié au fonctionnement de la regenconf. La regenconf à deux étapes : pre et post. Et une étape “intermédaire” gérée par le core.
pre: Les différents hooks génèrent les configurations “telles qu’elles devrait l’être” dans un dossier “en attente” (le pending dir). N.B. : les conf ne sont pas appliquées “pour de vrai” sur le système
(intermediaire): le coeur de yunohost applique les nouvelles configuration sur le système sauf si il détecte que la configuration sur le système a été manuellement modifée par l’admin, auquel cas il prévient juste l’admin que la conf ne sera pas modifiée
post: le hook réalise diverse opérations telle que reload/restart le service si la conf a été modifiée, etc
Lorsque tu fais un hook custom qui veut juste modifier la conf, tu te fiches un peu de l’étape post (le rechargement du service et autre bricoles sont déjà gérée par le hook par défaut)
Par contre il faut bel et bien faire les modifs sur le fichier dans le $pending_dir, faute de quoi si tu le fais sur le “vrai système” directement, ça équivaut à une modif manuelle par l’admin et ça pète tout le principe de la regenconf.
Mouarf alors ça c’est le fonctionnement du bash… Dans un cas, il s’agit de l’argument “global” du script ($4) mais dans l’autre il s’agit du fait que c’était le premier argument passé à la fonction do_pre_regen … d’ailleurs si tu regardes, la fonction do_pre_regen étaient appelée vers la fin avec do_pre_regen $4 (donc $4 devient le premier argument de la fonction, c’est-à-dire $1)
Tout ça car dans le script de my_webapp, j’ai simplifié les choses car ça n’a pas vraiment de sens de faire pleins de fonction alors qu’on veut juste faire des choses pendant l’étape “pre” … bref, la même chose pourrait être faite pour simplifier celui de mailman
Merci bien. Ben j’ai bien fait d’attendre tes explications plutôt que d’essayer de comprendre, ça m’a évité un mal de tête! Avec tes explications je comprends mieux comment fonctionne les hooks.
Mes essais étaient fait un peu au pif en copiant simplement un autre hook et en adaptant à mes besoins mais sans vraiment comprendre comment ça fonctionnait.
J’ai mis un certain temps à comprendre car ça ne fonctionnait pas, en fait le début du nom correspond à l’ordre de priorité.
Du coup je crois comprendre qu’il faut donner une priorité moins grande que pour les scripts de /usr/share/yunohost/hooks/conf_regen si on veut que nos modifs soient pris en compte, est-ce bien ça?
J’ai testé avec ssh pour changer le port par défaut…à moins que je m’y prenne mal? Voici mon script:
Si le script s’appelle 04-ssh_port ça fonctionne, si il s’appelle 03-ssh_port ou 02-ssh_port par exemple, ça ne fonctionne plus car /usr/share/hooks/conf_regen/03-ssh écrase les modifs persos dans ce cas.
Oui, il faut effectivement que le nombre soit + grand que le hook par défaut pour qu’il tourne après le hook par défaut (sinon le fichier “officiel” n’a pas encore été généré)
Note que pour cette histoire de port SSH, il y a un setting qui arrive dans la 4.2 pour gérer le port, et ce sera la manière recommandée de procéder (il faut aussi le propager sur la conf fail2ban et le firewall)
voici ce que j’ai fais de mon côté:
Création du dossier /etc/yunohost/hooks.d/conf_regen/
Dedans j’y place les scripts hooks. Je commence la numérotation après ceux présent dans /usr/share/hooks/conf_regen/. J’ai commencé la numérotation à partir de 90.
Une configuration pour ssh : /etc/yunohost/hooks.d/conf_regen/90-ssh_customhook
Un ajout pour Dovecot (qui pose problème sans cette conf): /etc/yunohost/hooks.d/conf_regen/91-dovecot_customhook
#!/bin/bash
action=$1
pending_dir=$4
dovecot_conf=$pending_dir/../dovecot/etc/dovecot/dovecot.conf
[[ $action == "pre" ]] || exit 0
[[ -e $dovecot_conf ]] || exit 0
echo "
service stats {
unix_listener stats-reader {
user = vmail
group = mail
mode = 0660
}
unix_listener stats-writer {
user = vmail
group = mail
mode = 0660
}
}
" >> $dovecot_conf
Configuration de restriction pour Nginx (GeoIP): /etc/yunohost/hooks.d/conf_regen/92-nginx_customhook
#!/bin/bash
# First install, add package: geoip-database-extra geoipupdate
# Download configuration on your Maxmind account and replace /etc/GeoIP.conf file
action=$1
pending_dir=$4
nginx_dir=$pending_dir/../nginx/etc/nginx
nginx_security_conf=$nginx_dir/conf.d/security.conf.inc
nginx_country_conf=$nginx_dir/conf.d/country.conf
#geoip_conf=/etc/GeoIP.conf
#geoip_crontab=/etc/cron.d/geoipupdate
[[ $action == "pre" ]] || exit 0
[[ -d $nginx_dir ]] || exit 0
[[ -e $nginx_security_conf ]] || exit 0
echo "
# GeoIP databases
geoip_country /usr/share/GeoIP/GeoIP.dat;
map \$geoip_country_code \$allowed_country {
default no;
# France
FR yes;
# Italie
#IT yes;
}
geo \$lan-ip {
default no;
192.168.10.0/24 yes;
10.10.10.0/24 yes;
}
" > $nginx_country_conf
echo "
# allow local ip
if (\$lan-ip = yes) {
set \$allowed_country yes;
}
# block the country
if (\$allowed_country = no) {
return 444;
}
" >> $nginx_security_conf
Attention cette configuration de Nginx est suceptible de changer. Pour le moment c’est encore en test chez moi. Les réseaux sont ceux configurés chez moi.
En plus j’ai installé les paquets geoip-database-extra et geoipupdate (le dernier met en place un fichier pour une tâche cron pour les mises à jour des IP par pays).
Dans mon cas j’ai un compte chez Maxmind et je génère un fichier de conf chez eux.
Il faut aussi penser à éditer les pays suivant le besoin de chacun.
Je pense qu’il faut que j’adapte encore ces configurations mais pour le moment cela focntionne plutôt bien.
Protip™: pour ne pas avoir à échapper les $ (\$), tu peux aussi utiliser des simples quotes (') à la place des doubles ("). C’est le comportement de bash:
echo "$TOTO" # affiche le contenu de la variable TOTO
echo '$TOTO' # affiche littéralement $TOTO
Merci pour le retour, j’ai corrigé avec des simples quotes.
Par contre cette configuration de Nginx semble poser problème lors de l’installation de nouvelles application.
Il faut bien penser à désactiver cette configuration lors d’installation pour le moment.
Il faut que je regarde plus en détail pourquoi ça bloque mais je pense à un curl sur un github ou un truc du genre (du coup restriction en France pas glop).
@Aleks : j’ai fais quelques hooks qui fonctionnent bien, merci, ça m’évite de le refaire à chaque mise à jour .
Par contre les hooks spécifiques à Yunohost fonctionnent mais les modifications restent considérées comme des modifications manuelles. Y-a-t-il un moyen de l’éviter? A défaut je l’ignore dans le diagnostique pour l’instant.
Autre chose à laquelle je pense, est-ce possible de faire également un hook lors de l’installation d’une application? Je pense par exemple à Jirafeau quand on utilise un thème perso, l’installation supprime les modifications du fichier de configuration. Un hook qui remettrait les modifs éviterait d’être obligé de recopier manuellement le fichier sauvegardé dans /home/yunohost.conf/backup à chaque mise à jour de l’application.
J’avais codé le chemin en dur dans le script hook c’est visiblement la raison pour laquelle j’ai eu cette erreur, du coup c’est normal que la modification soit vue comme manuelle. J’ai rectifié avec: dns_conf=$pending_dir/../yunohost/etc/cron.d/yunohost-dyndns
au lieu de dns_conf=/etc/cron.d/yunohost-dyndns,
mais maintenant la modification n’est plus appliquée. Ce n’est qu’avec la catégorie “yunohost” que les hooks ne fonctionnent pas, ça passe avec tout le reste (ssh, postfix, nginx, etc…)
Voici le hook en question si ça peux aider:
Le 1er sed permet de changer l’heure du diagnostique, le second de commenter le script yunohost-dyndns vu que je n’en ai pas besoin étant avec une ip fixe.
Dans ce cas fait tourner la regen-conf avec --debug pour voir quelle ligne fait qu’il ne passe pas dans le script, naivement je dirais qu’il tombe dans l’un des trois exit 0 …
Je ne vois pas ce qui cloche . Voici la partie du DEBUG qui concerne le hook si tu y vois quelque chose:
464 DEBUG Executing command '/bin/bash -x "./02-yunohost_diag" pre 0 0 /home/yunohost.conf/pending/yunohost_diag 7>&1'
471 DEBUG + action=pre
474 DEBUG Vérification de la configuration en attente qui aurait été appliquée pour la catégorie 'yunohost'…
498 DEBUG processing pending conf '/home/yunohost.conf/pending/yunohost/etc/cron.daily/yunohost-fetch-apps-catalog' to system conf '/etc/cron.daily/yunohost-fetch-apps-catalog'
498 DEBUG > system conf is already up-to-date
498 DEBUG processing pending conf '/home/yunohost.conf/pending/yunohost/etc/cron.daily/yunohost-certificate-renew' to system conf '/etc/cron.daily/yunohost-certificate-renew'
499 DEBUG > system conf is already up-to-date
499 DEBUG processing pending conf '/home/yunohost.conf/pending/yunohost/etc/systemd/system/nftables.service.d/ynh-override.conf' to system conf '/etc/systemd/system/nftables.service.d/ynh-override.conf'
500 DEBUG > system conf is already up-to-date
500 DEBUG processing pending conf '/home/yunohost.conf/pending/yunohost/etc/systemd/system/ntp.service.d/ynh-override.conf' to system conf '/etc/systemd/system/ntp.service.d/ynh-override.conf'
500 DEBUG > system conf is already up-to-date
501 DEBUG processing pending conf '/home/yunohost.conf/pending/yunohost/etc/cron.d/yunohost-diagnosis' to system conf '/etc/cron.d/yunohost-diagnosis'
501 DEBUG > system conf is already up-to-date
501 DEBUG processing pending conf '/home/yunohost.conf/pending/yunohost/etc/cron.d/yunohost-dyndns' to system conf '/etc/cron.d/yunohost-dyndns'
502 DEBUG > system conf is already up-to-date
502 DEBUG processing pending conf '/home/yunohost.conf/pending/yunohost/etc/etckeeper/etckeeper.conf' to system conf '/etc/etckeeper/etckeeper.conf'
502 DEBUG > system conf is already removed
503 DEBUG La configuration est déjà à jour pour la catégorie 'yunohost'
Ben j’ai bien fait d’attendre tes explications plutôt que d’essayer de comprendre, ça m’a évité un mal de tête! 
Avec tes explications je comprends mieux comment fonctionne les hooks.