Share your "hooks" to apply custom configurations- Partagez vos "hooks" pour appliquer des configurations personnelles

,

:gb: English version

Translate with DeePL

A “hook” allows you to apply personal configurations to Yunohost files without the system detecting them as modified. Without a hook, Yunohost does not update these files and this is a real risk in terms of security and system stability. This is especially true with SSH by modifying sshd_config.
The solution without a hook is to run the following command after each update to see if there have been any changes:

yunohost tools regen-conf -n -d

If there are changes, you have to apply them with the command yunohost tools regen-conf --force (this command can be limited to the concerned service by adding it at the end of the command line like ssh, nginx for example), then redo your personal configurations. It becomes quickly heavy as soon as you have several modifications and forces you to be very rigorous, which is inevitably less and less with time for most of you, it’s human, you don’t work with a cron task embedded in your brain! :stuck_out_tongue:

The solution: The hook.
System updates will always take place and personal configurations will be automatically applied after them. This allows you to have a system that is always up to date while allowing some personal additions that will be automatically applied.
Here is a forum topic about how to make a “hook”.

I have created this page mainly to serve as a place to share your hooks. Share your good ideas, your personal configurations, there will always be someone with the same need to whom it can be useful. After that, it’s up to everyone to check the proposed hooks and adapt them to their hardware configuration, it’s always a matter of trust. We trust the devs of Yunohost, here it’s a little bit the same with the difference that not everyone has their skills!

Don’t forget, to activate the hooks, you must run after create them this command:

yunohost tools regen-conf --force

You can also restrict it to the service concerned as in the example below:

yunohost tools regen-conf ssh --force

:fr: Version française

Un “hook” permet d’appliquer des configurations personnelles aux fichiers de Yunohost sans que le système ne les détecte comme modifiés. Sans “hook” yunohost ne met pas à jour ces fichiers et c’est un réel risque en terme de sécurité et de stabilité du système. Ceci est particulièrement vrai avec SSH en modifiant sshd_config.
La solution sans “hook” est de passer la commande suivante après chaque mise à jour pour voir si il y a eu des changements:

yunohost tools regen-conf -n -d

Si il y a eu des changements, il faut les appliquer avec un la commande yunohost tools regen-conf --force (cette commande peut être limitée au service concerné en ajoutant celui-ci en fin de ligne de commande comme ssh, nginx par exemple), puis refaire ses configurations personnelles. Ça devient vite lourd dès qu’on a plusieurs modifications et oblige à être très rigoureux, ce qui inévitablement l’est de moins en moins avec le temps pour la plupart, c’est humain, on ne fonctionne pas avec une tâche cron imbriquée dans le cerveau! :stuck_out_tongue:

La solution: Le “hook”.
Les mises à jour du système auront toujours lieu et les configurations personnelles seront automatiquement appliquées après celles-ci. Ça permet d’avoir un système toujours à jour tout en s’autorisant quelques ajouts personnels qui seront automatiquement appliqués.
Voici un sujet du forum qui traite de comment faire un “hook”.

J’ai crée cette page principalement pour servir de lieu de partage de vos “hook”. Partagez vos bonnes idées, vos configurations personnelles, il y aura toujours quelqu’un avec le même besoin à qui ça pourra servir. Après à chacun de vérifier les hooks proposés et d’adapter à sa configuration matérielle, c’est toujours une histoire de confiance. On fait confiance aux devs de Yunohost, ici c’est un peu pareil à la différence que tous le monde n’a pas leurs compétences!

N’oubliez pas, pour activer les “hooks”, il faut passer la commande suivante:

yunohost tools regen-conf --force

On peut aussi restreindre au service concerné comme dans l’exemple ci-dessous:

yunohost tools regen-conf ssh --force
6 Likes

Voici les hooks que j’utilise:

  1. Changer l’heure du diagnostique automatique (le diagnostique échoue(échouait?) parfois avec l’heure par défaut sans doute dû à une surcharge côté infra yunohost) et désactiver la mise à jour DNS avec une Ip fixe (évite les mails intempestifs quand il y a un souci sur l’infra de Yunohost)
    Ces 2 modifications peuvent être dissociées, les 2 commandes sed étant séparées.

/etc/yunohost/hooks.d/conf_regen/02-yunohost_diag

#!/bin/bash

action=$1
pending_dir=$4
diag_conf=$pending_dir/../yunohost/etc/cron.d/yunohost-diagnosis
dns_conf=$pending_dir/../yunohost/etc/cron.d/yunohost-dyndns
[[ "$action" == "pre" ]] || exit 0
[[ -e $diag_conf ]] || exit 0
[[ -e $dns_conf ]] || exit 0
sed -e "s/7/9/" \
    -e "s/19/21/" \
    -i $diag_conf
sed -e "/#/! s/^/#/g" \
    -i $dns_conf
  1. Permettre le relevé de mails avec les versions antérieures à Android 4.1 en autorisant les protocoles à partir de TLSv1 et lutter de ce fait contre l’obsolescence programmée. Attention, ce hook entraîne un affaiblissement de la sécurité par défaut de Yunohost. Voici une discussion qui en parle:

/etc/yunohost/hooks.d/conf_regen/26-dovecot_ssl

#!/bin/bash

action=$1
pending_dir=$4
ssl_conf_dir=$pending_dir/../dovecot/etc/dovecot/yunohost.d
mkdir -p $ssl_conf_dir/post-ext.d
ssl_conf=$ssl_conf_dir/post-ext.d/10-ssl.conf

[[ "$action" == "pre" ]] || exit 0

echo 'ssl_min_protocol = TLSv1
ssl_cipher_list = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA
ssl_prefer_server_ciphers = yes' > $ssl_conf
  1. Pour ceux qui se connectent avec une clef ssh, il faut passer les valeurs de PasswordAuthentication et UsePAM à no:

Edit 21 january 2022: There’s a new setting to manage PasswordAuthentication, then you can now delete this line from the hook.

   -e "s/#PasswordAuthentication.*/PasswordAuthentication no/" \

More informations on this post:

/etc/yunohost/hooks.d/conf_regen/04-ssh_pwd

#!/bin/bash

action=$1
pending_dir=$4
ssh_conf=$pending_dir/../ssh/etc/ssh/sshd_config

[[ "$action" == "pre" ]] || exit 0
[[ -e "$ssh_conf" ]] || exit 0

sed -e "s/UsePAM.*/UsePAM no/" \
    -e "s/#PasswordAuthentication.*/PasswordAuthentication no/" \
    -i $ssh_conf
  1. Résoudre les erreurs et warning visibles dans les logs concernant dovecot. Plus d’infos dans ce lien et dans la discussion crée par @zulf.

/etc/yunohost/hooks.d/conf_regen/27-dovecot_error

#!/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
  1. Restreindre la Web admin de yunohost au réseau local:

/etc/yunohost/hooks.d/conf_regen/16-nginx_local

#!/bin/bash

##############################################
#Beware, i'm not sure this command is universal. You must test it before. If not, you can find the result with the command ip route, this one must be like 192.168.0.0/24 or similar. Then replace the variable $network_address with it.
#Attention, je ne suis pas certain que cette commande est universelle. Vous devez la tester au préalable. Si ce n'est pas le cas, vous pouvez trouver la réponse avec la commande ip route, celle-ci doit être de la forme 192.168.0.0/24 ou similaire. Remplacez alors la variable $network_address par celle-ci.

network_address=$(awk '{print $1}' <(grep src <(ip route)))
#############################################
action=$1
pending_dir=$4
nginx_dir=$pending_dir/../nginx/etc/nginx
nginx_ynh_admin=$nginx_dir/conf.d/yunohost_admin.conf.inc
nginx_ynh_api=$nginx_dir/conf.d/yunohost_api.conf.inc

[[ $action == "pre" ]] || exit 0
[[ -d $nginx_dir ]] || exit 0
[[ -e $nginx_ynh_admin ]] || exit 0
[[ -e $nginx_ynh_api ]] || exit 0
sed -i "/location/a\    allow $network_address;\n    deny all;" $nginx_ynh_admin
sed -i "0,/location/a\    allow $network_address;\n    deny all;" $nginx_ynh_api
  1. Restreindre l’accès Web du serveur par pays, voire cette discussion.

/etc/yunohost/hooks.d/conf_regen/18-nginx_geoip

#!/bin/bash

# if not present, add package geoip-database with apt install geoip-database

##############################################
#Beware, i'm not sure this command is universal. You must test it before. If not, you can find the result with the command ip route, this one must be like 192.168.0.0/24 or similar. Then replace the variable $network_address with it.
#Attention, je ne suis pas certain que cette commande est universelle. Vous devez la tester au préalable. Si ce n'est pas le cas, vous pouvez trouver la réponse avec la commande ip route, celle-ci doit être de la forme 192.168.0.0/24 ou similaire. Remplacez alors la variable $network_address par celle-ci.
network_address=$(awk '{print $1}' <(grep src <(ip route)))
################################################
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

[[ $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;
  $network_address 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

##############################################################


  1. Résoudre le warning concernant postfix compatibility mode visible dans les logs:

/etc/yunohost/hooks.d/conf_regen/20-postfix_compatible

#!/bin/bash

action=$1
pending_dir=$4
postfix_conf=$pending_dir/../postfix/etc/postfix/main.cf

[[ "$action" == "pre" ]] || exit 0
[[ -e $postfix_conf ]] || exit 0
echo '
compatibility_level = 2' >> $postfix_conf
8 Likes

Il y a apparemment une incompatibilité pour pouvoir utiliser l’application keeweb sur Nextcloud. Ce problème se résout en supprimant le carré de Yunohost qui permet de revenir sur le portail SSO :

Pour supprimer le carré Yunohost uniquement pour Nextcloud, voici le hook qu’il faut utiliser:
AVERTISSEMENT: Comme il n’y a pas de conf_regen à l’installation d’une application, il faut obligatoirement relancer la commande yunohost tools regen-conf nginx --force. Du coup il y a quand même très peu d’intérêt dans ce cas-ci.

/etc/yunohost/hooks.d/conf_regen/17-nginx_nextcloud

#!/bin/bash
action=$1
pending_dir=$4
nginx_dir=$pending_dir/../nginx/etc/nginx
nginx_nextcloud_conf=$(find /etc/nginx -name nextcloud.conf)
[[ $action == "pre" ]] || exit 0
[[ -d $nginx_dir ]] || exit 0
[[ -e $nginx_nextcloud_conf ]] || exit 0
sed -e "/^  #/! {/yunohost_panel/ s/^  /  #/}" \
    -i $nginx_nextcloud_conf

Ceux qui veulent supprimer ce carré sur toutes les applications doivent utiliser le hook suivant. Celui-ci reste intéressant car automatisé avec les mises à jour de Yunohost:

AVERTISSEMENT: il existe maintenant un paramètre de yunohost qui permet de faire la même chose avec la commande:

yunohost settings set ssowat.panel_overlay.enabled -v False

Il faut remplacer False par True pour rétablir le carré.

Je laisse le hook simplement pour exemple, son utilisation n’est donc plus recommandée avec ce nouveau paramètre.

/etc/yunohost/hooks.d/conf_regen/17-nginx_yunopanel

#!/bin/bash
action=$1
pending_dir=$4
nginx_dir=$pending_dir/../nginx/etc/nginx
yunohost_panel_conf=$nginx_dir/conf.d/yunohost_panel.conf.inc
[[ $action == "pre" ]] || exit 0
[[ -d $nginx_dir ]] || exit 0
[[ -e $yunohost_panel_conf ]] || exit 0
sed -e "/#/! s/^/#/g" \
    -i $yunohost_panel_conf
2 Likes

Here a small post_app_upgrade hooks to apply a specific change in the config file:

#!/bin/bash
if [ "$YNH_APP_ID" == "limesurvey" ] ; then
        source /usr/share/yunohost/helpers
        ynh_write_var_in_file --file=/var/www/limesurvey/application/config/config.php --key=urlFormat --value=path --after=urlManager
fi
2 Likes

There’s a new setting to manage PasswordAuthentication in sshd_config

yunohost settings set security.ssh.password_authentication -v no

Then the hook /etc/yunohost/hooks.d/conf_regen/04-ssh_pwd is partially obsolete and the use of this new setting is to be preffered.

It seems however that it is necessary to use UsePam = no and ChallengeResponseAuthentication = no. The default yunohost config ssh leaves UsePam = yes.
If anyone can complete this answer. Perhaps the new setting should also modify UsePam to No?

It has never been clear to me what UsePam corresponds to … isn’t this related to being able to use LDAP users to log in ? What makes you say that “it is necessary to set it to no” ?

it’s not clear for me too. I don’t say “it is necessary” but it seems it is necessary. The UsePAM = yes setting allow PAM authentication login/password. If we want disable login/password authentication, UsePAM is not necessary and i don’t know if it is a problem to set it to yes, but i understand it is not a problem to set it to No. In the first case, i’m not sure if authentication by login/password is possible though LDAP for example as you say, in the second i’m sure it’s not possible.
PAM means Pluggable Anthentication modules, it can be Ldap.
I only follow the recommendations that i often read. But i’m not sure if i understand correctly why it is recommended.
Excuse me if i’m not clear, i have difficulty to write in english. But DeepL translator is my friend to write this :slightly_smiling_face:

Je pense ajouter la configuration suivante qui est surtout utilisé pour la supervision via Zabbix:
/etc/yunohost/hooks.d/conf_regen/17-nginx_status

#!/bin/bash

action=$1
pending_dir=$4
nginx_dir=$pending_dir/../nginx/etc/nginx
nginx_status_conf=$nginx_dir/conf.d/default.d/stubstatus.conf

[[ $action == "pre" ]] || exit 0
[[ -d $nginx_dir ]] || exit 0
[[ -e $nginx_status_conf ]] || exit 0
echo '
location = /basic_status {
  stub_status;
  allow 127.0.0.1;
  allow ::1;
  deny all;
}' > $nginx_status_conf

Par contre pour le moment la génération de la configuration ne fonctionne pas je ne sais pas trop pourquoi.

1 Like

Hello @ljf ,

Could you give me more explanations, please?
I not really understand how to use the arguments --key and --value.
In example, you can take my previous post to explain me how i can comment the line “include conf.d/yunohost_panel.conf.inc;” like i do with sed.

ynh_write_var_in_file is built to replace a variable, so in your case you still need to use sed.

Here an example if you want to change the variable foo in this file:
/root/testfile

bar = "plop"
foo = 42
bam = "bim"
ynh_write_var_in_file --file=/root/testfile --key=foo --value=43
1 Like

There is also a new setting to restrict the webadmin access:

yunohost settings set security.webadmin.allowlist -v <comma-separated list of IP addesses>
yunohost settings set security.webadmin.allowlist.enabled -v True

Thanks a lot for describing and sharing your hooks!

I didn’t know about hooks before and had already modified some system configuration files (and documented the modifications to be able to redo them after system updates).

Using hooks instead makes these custom configurations much easier.

3 Likes

Thanks a bunch for your script, I had no idea how to enable the stub status for nginx for YunoHost, you made my day :slight_smile:

Nice thread !

For those who want to manage SSH security : Config ssh : utilisation de AllowUsers ou AllowGroups? - #4 by Kit

The hook manages :

  • users in groups ssh.app and ssh.main
  • SSH port modification
  • allowance of using password or only keys
  • TLS compatibility (TLS 1.2 & 1.3 or 1.3 only)

Any improvement welcome :slight_smile:

1 Like