dnsmasq configuration via NETCONF using sysrepo & Netopeer 2
As an example of how sysrepo & Netopeer 2 can be used to make an existing Linux application remotely manageable via NECTONF in a few hours, we integrated it into dnsmasq DNS fowarder and DHCP server for Linux.
Wid did just a partial integration that allows remote configuration of following features (see the YANG model):
username & groupname dnsmasq will run as,
- dns-server: enabling/disabling the server, configuring the port that DNS serevr is bound to,
- dhcp-server: enabling/disabling the server, configuring list of DHCP pools and their lease-time.
The integration took us 6-8 hours of coding and the diff consists of about 200 lines of C code. The diff can be reviewed here:
Full code of this integration is avaliable here on the GitHub.
The demo of this integration can be played below:
Description of the demo:
- 00:05 - 00:20: We display initial startup config of dnsmasq that do not contain any DHCP configuration.
- 00:21 - 00:40: We start dnsmasq in debug mode so that you can see what it is doing. Dnsmasq starts with its initial startup config displayed before.
- 00:41 - 00:50: We spin a virtual machine running OpenWRT that is trying to connect to our DHCP server running dnsmasq. So far no DHCP pool is configured, so it won't recevie any DHCP offer.
- 00:51 - 01:10: We start a sysrepo daemon and netopeer2-server, so we can remotely connect to our NETCONF-enabled server.
- 01:11 - 01:23: We connect to the NETCONF server via SSH and send a hello message back to it.
- 01:24 - 01:28: We send a get-config request to running datastore to see what is the current config. No DHCP pool is configured yet.
- 01:29 - 01:35: We send an edit-config request with the new DHCP pool configuration. Immediately after it, we can see in the dnsmasq window that it has applied the new config and in the OpenWRT window that it has recieved a DHCP offer.
- 01:36 - 01:40: We verify that the new config has been also applied in the datastore by issuing a get-config request to the running datastore.
- 01:41 - 01:46: We send an edit-config request requesting delete of the current DHCP pool.
- 01:47 - 01:51: We verify that the config has been deleted in the datastore by issuing a get-config request to the running datastore.
- 01:52 - 01:58: We send an edit-config request with the new DHCP pool configuration (192.168.1.120 - 192.168.1.130). Immediately after it, we can see in the dnsmasq window that it has applied it.
- 01:59 - 02:04: From OpenWRT machine, we request a new DHCP offer. We recieve an IP address from the new pool.
- 02:05 - 02:10: We want to make this change permanent so we issue a copy-config request from running to startup datastore.
- 02:11 - 02:15: We verify that the new config has been copied to startup using a get-config request to startup datastore.
- 02:16 - 02:20: We restart the dnsmasq daemon to check that it correctly reads the new config by startup.