Blog

Last modified by Clément Aubin on 2022/01/27 20:09

Automatiser la maison - Les bases

Pour 2022, je me suis donné pour objectif d'améliorer l'appartement dans lequel on vit avec ma copine. Plus particulièrement, j'aimerais profiter de cette occasion pour introduire de la domotique. Le but n'est pas de tout automatiser, mais de mettre en place des petites routines sympa, comme l'ouverture des volets à une certaine heure, ou le contrôle des lumières.

Une des grosse contraintes de ce projet, c'est qu'on ne souhaite pas utiliser un système permettant de contrôler sa maison depuis le cloud : l'organe de contrôle des équipements de la maison doit se trouver également dans l'appartement, et on doit pouvoir avoir la main dessus. De mon côté, je cherche également une solution qui demande un peu d'huile de coude à mettre en place, de manière à apprendre quelques trucs au passage …

Il existe quelques solutions Open Source qui permettent d'automatiser des tâches chez soi. Je me suis penché de mon côté sur Home Assistant, qui me semble être une solution assez mature et suffisamment extensible pour ce que je veux faire : ça s'installe rapidement et facilement sur une Raspberry Pi, et il y a tout un système de plugins basés sur des containers Docker, qui vont donc tourner dans leurs environnements sparés.

Dans les prochains posts, je vais tenter de raconter les différentes étapes de la mise en place de ce système et des automatisations qui vont bien. Je me suis donné une liste d'éléments à mettre en place dans une première phase du projet :

  • Contrôler les volets de l'appartement : on dispose de cinq fenètres, toutes avec des volets électriques. Trois volets sur cinq sont contrôlés par des télécommandes Well', et les deux autres volets (probablement plus anciens), sont contrôlés par des boutons au niveau des fenêtres. L'objectif est ici de pouvoir contrôler l'ouverture et la fermeture des volets directement depuis l'interface de Home Assistant. Ça nous permettrait d'ouvrir tous les volets de la maison en une fois par exemple, ou bien d'ouvrir tous les volets sauf ceux de la chambre à partir d'une certaine heure, …
  • Contrôler certaines lampes de la maison pour pouvoir les allumer et les éteindre soit par commande, soit automatiquement selon certaines conditions.
  • Contrôler notre vidéoprojecteur, pour pouvoir l'allumer et changer sa source via Home Assistant. C'est la dernière étape de cette première phase, car si les deux étapes précédentes sont remplies, cela devrait permettre de mettre en place une automatisation qui, en une commande, ferme les volets du salon, baisse la luminosité et allume le projecteur pour faire une soirée film.

 

DNS management with OpenVPN

Sometimes, setting up a proper VPN can be tedious. This article gives two advices related to DNS related VPN configuration that I found while implementing my own VPN using OpenVPN.

Pushing custom DNS server addresses through OpenVPN

When setting up a VPN using OpenVPN, you might need at some point to push DNS information from the VPN server to the client. The recommended way to do so is to use the following client configuration:

# Allow the client to receive pushed DHCP options
script-security 2

# Update the local resolv.conf file in order to apply any pushed DNS address
up <PATH_TO>/update-resolv-conf
down <PATH_TO>/update-resolv-conf

You can then use the directive push "dhcp-option DNS XXX.XXX.XXX.XXX" in the server configuration and send DNS server addresses to a client when it connects to the VPN, at least in theory.

In practice, this process needs a bit more work on the client side :

  • The client needs to have the update-resolv-conf script on its file system. Hopefully, the script is usually packaged on APT systems and available in /etc/openvpn.
  • The client should also have OpenResolv installed. This is used to merge DNS configurations coming from multiple sources (NetworkManager, OpenVPN, …) into /etc/resolv.conf.
  • Finally, the client configuration should not drop privileges when running, which means that you cannot use user nobody nor group nogroup in your configuration : if those options are used, OpenVPN will not be able to properly execute the update script when disconnecting from its server as the process has already dropped privileges.

Regarding this last point, two possible solutions could be done in order to keep the possibility to use update-resolv-conf while dropping privileges:

  • Use setuid in order to run the script as its owner (which might bring even more security issues).
  • Use OpenVPN down-root plugin to allow the execution of privileged commands even in this situation.

Prioritizing the VPN DNSs while renaming the client adapter name

In the client configuration, you can use the two following instructions in order to define a different network adapter name for your VPN:

# Set the type of adapter (tun or tap)
dev-type <DEV_TYPE>
# Set the custom adapter name
dev my-vpn

When doing so, you might note that for some cases, in your resolv.conf file, the DNS servers addresses provided by the VPN are not put before your local DNSs. This can create new problems as your VPN DNS might provide different resolutions from the ones that you get without your VPN or add new resolutions. As DNS addresses are taken in the order in which they are written in your resolv.conf when trying to resolve a host, having your VPN DNS in the end of the file might slow down the resolution and frustrate your users.

In order to fix this problem, you have to update the configuration of OpenResolv in order to change the processing order of the network interfaces when fetching locally available DNSs. You will have to use the dynamic_order configuration option ; here is its definition from resolvconf.conf (5):

dynamic_order
   These interfaces will be processed next, unless they have a metric.  If unset, defaults to the following:
   tap[0-9]* tun[0-9]* vpn vpn[0-9]* ppp[0-9]* ippp[0-9]*