Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2023-08-16T14:42:05+02:00https://gitlab.nic.cz/turris/os/packages/-/issues/572[Turris OS 3.x] Add new Sentinel (testing) CA2023-08-16T14:42:05+02:00Vojtech Myslivec[Turris OS 3.x] Add new Sentinel (testing) CAAdd new (prolonged) Sentinel CA. The current one will expire soonAdd new (prolonged) Sentinel CA. The current one will expire soonTurris OS 3.11.162020-05-04https://gitlab.nic.cz/turris/os/packages/-/issues/799[Turris OS 3.x] GnuTLS fails to verify Let's Encrypt certificates2022-02-16T16:59:27+01:00Vojtech Myslivec[Turris OS 3.x] GnuTLS fails to verify Let's Encrypt certificates### Cause
Let's Encrypt original cross-signed root CA *DST Root CA X3* expired at *Sep 30 14:01:15 2021 GMT* (today). LE' issued certificates are signed with *ISRG Root X1*, which is present in certificate store for a long time as a tru...### Cause
Let's Encrypt original cross-signed root CA *DST Root CA X3* expired at *Sep 30 14:01:15 2021 GMT* (today). LE' issued certificates are signed with *ISRG Root X1*, which is present in certificate store for a long time as a trusted root CA. However, GnuTLS fails to verify Let's Encrypt certificate, returning `Status: The certificate is NOT trusted. The certificate chain uses expired certificate.`
### Issue
As a result, `kresd` at Turris OS 3.x fails to verify TLS certificate on `odvr.nic.cz` server and returns `SERVFAIL` on every DNS query ~High ~Bug
### Further info
| Package | version in Turris OS 3.x | version in Turris OS 5.x |
|--|--|--|
| turris-version | 3.11.23 | 5.2.7 |
| knot-resolver | 5.2.0-1 | 5.3.2-2 |
| libgnutls | 3.6.7-4 | 3.6.15-2 |
Issue can be simply verified via command:
```
gnutls-cli -p 853 odvr.nic.cz
```
Which is successful on _TOS 5.x_ but unsuccessful on _TOS 3.x_:
```
- Status: The certificate is NOT trusted. The certificate chain uses expired certificate.
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
```
<details>
<summary>Certificate chain</summary>
```
+-------------------------------------------+
| subject=CN = odvr.nic.cz |
| issuer=C = US, O = Let's Encrypt, CN = R3 |
| notBefore=Aug 31 17:23:50 2021 GMT |
| notAfter=Nov 29 17:23:49 2021 GMT |
+-------------------------------------------+
\
\
\
+------------------------------------------------------------------------+
| subject=C = US, O = Let's Encrypt, CN = R3 |
| issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1 |
| notBefore=Sep 4 00:00:00 2020 GMT |
| notAfter=Sep 15 16:00:00 2025 GMT |
+------------------------------------------------------------------------+
\
\
\
+-------------------------------------------------------------------------+
| subject=C = US, O = Internet Security Research Group, CN = ISRG Root X1 |
| issuer=O = Digital Signature Trust Co., CN = DST Root CA X3 |
| notBefore=Jan 20 19:14:03 2021 GMT |
| notAfter=Sep 30 18:14:03 2024 GMT |
+-------------------------------------------------------------------------+
/ \
| \ |
| \ |
| \ |
| +-----------------------------------------------------------+ |
| | subject= /O=Digital Signature Trust Co./CN=DST Root CA X3 | |
| | issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3 | |
| | notBefore=Sep 30 21:12:19 2000 GMT | |
| | notAfter=Sep 30 14:01:15 2021 GMT | |
| +-----------------------------------------------------------+ |
\ /
```
</details>
<details>
<summary>/etc/ssl/certs/DST_Root_CA_X3.crt</summary>
Original and expired root CA that should be ignored now
```
subject= /O=Digital Signature Trust Co./CN=DST Root CA X3
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
notBefore=Sep 30 21:12:19 2000 GMT
notAfter=Sep 30 14:01:15 2021 GMT
```
</details>
<details>
<summary>/etc/ssl/certs/ISRG_Root_X1.crt</summary>
Current valid root CA
```
subject= /C=US/O=Internet Security Research Group/CN=ISRG Root X1
issuer= /C=US/O=Internet Security Research Group/CN=ISRG Root X1
notBefore=Jun 4 11:04:38 2015 GMT
notAfter=Jun 4 11:04:38 2035 GMT
```
</details>
<details>
<summary>/etc/resolver/dns_servers/00_odvr-cznic.conf</summary>
kresd DNS forwarding to DoT ODVR servers configuration:
```
name="00_odvr-cznic.conf"
description="CZ.NIC (TLS)"
enable_tls="1"
port="853"
ipv4="193.17.47.1 185.43.135.1"
ipv6="2001:148f:ffff::1 2001:148f:fffe::1"
ca_file="/etc/ssl/certs/ca-certificates.crt"
hostname="odvr.nic.cz"
```
</details>https://gitlab.nic.cz/turris/os/packages/-/issues/700Unbound CVE-2020-289352023-08-16T14:40:58+02:00Josef SchlehoferUnbound CVE-2020-28935More details here: https://bugzilla.redhat.com/show_bug.cgi?id=1878761 and here https://github.com/NLnetLabs/unbound/issues/303
Fixed by these commits: https://github.com/NLnetLabs/unbound/commit/ad387832979b6ce4c93f64fe706301cd7d034e8...More details here: https://bugzilla.redhat.com/show_bug.cgi?id=1878761 and here https://github.com/NLnetLabs/unbound/issues/303
Fixed by these commits: https://github.com/NLnetLabs/unbound/commit/ad387832979b6ce4c93f64fe706301cd7d034e87 and https://github.com/NLnetLabs/unbound/commit/19f8f4d9f99a44906ab9dcc46d44da299fde3506
Should be fixed in 1.13.0 (not yet released)Turris OS 5.1.5Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/582[Turris OS 3.x] Fix DynFW client2020-06-04T12:57:56+02:00Vojtech Myslivec[Turris OS 3.x] Fix DynFW clientWe need to backport turris/sentinel/dynfw-client!6 to %"Turris OS 3.11.17" as wellWe need to backport turris/sentinel/dynfw-client!6 to %"Turris OS 3.11.17" as wellTurris OS 3.11.17https://gitlab.nic.cz/turris/os/packages/-/issues/571Obfs4proxy is not compiled2020-07-31T10:19:59+02:00Josef SchlehoferObfs4proxy is not compiledTurris OS 3.11.19Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/564uCollect crashes in foris2023-08-16T14:56:59+02:00Stepan MocekuCollect crashes in forisThere is a problem with a bugged uCollect in 3.X - Foris crashes because of it. You need to do following to repair it:
/etc/init.d/ucollect disable
echo $?
ls -l /etc/rc.d/ | grep ucollect
/etc/init.d/ucollect enable
echo $?
ls -l /et...There is a problem with a bugged uCollect in 3.X - Foris crashes because of it. You need to do following to repair it:
/etc/init.d/ucollect disable
echo $?
ls -l /etc/rc.d/ | grep ucollect
/etc/init.d/ucollect enable
echo $?
ls -l /etc/rc.d/ | grep ucollecthttps://gitlab.nic.cz/turris/os/packages/-/issues/563msmtp: Update to version 1.8.72020-11-27T16:10:22+01:00Josef Schlehofermsmtp: Update to version 1.8.7Forum thread: https://forum.turris.cz/t/update-msmtp-1-8-4-for-oauthbearer-xoauth2-support/12434Forum thread: https://forum.turris.cz/t/update-msmtp-1-8-4-for-oauthbearer-xoauth2-support/12434Turris OS 3.11.16https://gitlab.nic.cz/turris/os/packages/-/issues/556Ludus fullfilling the /tmp2020-07-16T18:27:58+02:00Stepan MocekLudus fullfilling the /tmpLudus fullfilled /tmp folder in one hour.
Support ticket: #1068294
Forum link: https://forum.turris.cz/t/filled-folder-tmp/12380Ludus fullfilled /tmp folder in one hour.
Support ticket: #1068294
Forum link: https://forum.turris.cz/t/filled-folder-tmp/12380Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/538dev-detect repeatadly reports about same device2020-01-20T13:36:53+01:00Vojtech Myslivecdev-detect repeatadly reports about same deviceDevice detection repeatadly reports my laptop as a "new device appeared in the network".
It happened several times during last reboots.Device detection repeatadly reports my laptop as a "new device appeared in the network".
It happened several times during last reboots.Turris OS 3.11.14https://gitlab.nic.cz/turris/os/packages/-/issues/525kresd on 5.0-dev does not forward requests to the selected server2023-08-16T14:42:07+02:00Giuseppe Piscitellikresd on 5.0-dev does not forward requests to the selected serverI'm using Turris OS 5.0-dev on Omnia. Although it chooses a server from the list of those in Foris / DNS to forward my DNS queries, they continue to be resolved by my ISP's servers. I enclose two screenshots: in the first one we see that...I'm using Turris OS 5.0-dev on Omnia. Although it chooses a server from the list of those in Foris / DNS to forward my DNS queries, they continue to be resolved by my ISP's servers. I enclose two screenshots: in the first one we see that the configuration (in the example with Cloudflare) is correctly loaded in kresd; in the other, we see that by performing a test on dnsleaktest.com the server used is that of Telecom Italia (my ISP).
In addition, using reForis and opening the DNS tab, I see an error, which could be related to the bug above.![Schermata_del_2019-12-13_17-19-33](/uploads/7111745f00c20cc11b6d785b6bda4474/Schermata_del_2019-12-13_17-19-33.png)![Schermata_del_2019-12-13_17-20-15](/uploads/791ffe694c4f0d5adf8f6bb6dc5768d0/Schermata_del_2019-12-13_17-20-15.png)![Schermata_del_2019-12-13_15-47-50](/uploads/e4d8d90de74e45489be431fcc8bb04e9/Schermata_del_2019-12-13_15-47-50.png)Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/510[unbound] version bump 1.9.5 (fix for vulnerability CVE-2019-16866)2023-08-16T14:42:08+02:00Ghost User[unbound] version bump 1.9.5 (fix for vulnerability CVE-2019-16866)Unbound 1.9.5 is available:
https://nlnetlabs.nl/downloads/unbound/unbound-1.9.5.tar.gz
sha256 8a8d400f697c61d73d109c250743a1b6b79848297848026d82b43e831045db57
pgp https://nlnetlabs.nl/downloads/unbound/unbound-1.9.5.tar.gz
Thi...Unbound 1.9.5 is available:
https://nlnetlabs.nl/downloads/unbound/unbound-1.9.5.tar.gz
sha256 8a8d400f697c61d73d109c250743a1b6b79848297848026d82b43e831045db57
pgp https://nlnetlabs.nl/downloads/unbound/unbound-1.9.5.tar.gz
This release is a fix for vulnerability CVE-2019-18934, that can cause
shell execution in ipsecmod.
Bug Fixes:
- Fix for the reported vulnerability.
The CVE number for this vulnerability is CVE-2019-18934
== Summary
Recent versions of Unbound contain a vulnerability that can cause shell
code execution after receiving a specially crafted answer. This issue
can only be triggered if unbound was compiled with `--enable-ipsecmod`
support, and ipsecmod is enabled and used in the configuration.
== Affected products
Unbound 1.6.4 up to and including 1.9.4.
== Description
Due to unsanitized characters passed to the ipsecmod-hook shell command,
it is possible for Unbound to allow shell code execution from a
specially crafted IPSECKEY answer.
This issue can only be triggered when *all* of the below conditions are met:
* unbound was compiled with `--enable-ipsecmod` support, and
* ipsecmod is enabled and used in the configuration, and
* a domain is part of the ipsecmod-whitelist (if ipsecmod-whitelist is
used), and
* unbound receives an A/AAAA query for a domain that has an A/AAAA
record(s) *and* an IPSECKEY record(s) available.
The shell code execution can then happen if either the qname or the
gateway field of the IPSECKEY (when gateway type == 3) contain a
specially crafted domain name.
== Solution
Download patched version of Unbound, or apply the patch manually.
+ Downloading patched version
Unbound 1.9.5 is released with the patch
https://nlnetlabs.nl/downloads/unbound/unbound-1.9.5.tar.gz
+ Applying the Patch manually
For Unbound 1.6.4 up to and including 1.9.4 the patch is:
https://nlnetlabs.nl/downloads/unbound/patch_cve_2019-18934.diff
Apply the patch on the Unbound source directory with:
'patch -p1 < patch_cve_2019-18934.diff'
then run 'make install' to install Unbound.Turris OS 3.11.10Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/509[Turris OS 3.x] Upgrade pyuci2019-11-19T10:38:27+01:00Vojtech Myslivec[Turris OS 3.x] Upgrade pyuciUpgrade turris/pyuci> to most recent version (>= 0.6) in TOS 3.x
We can drop Python 2 compatibilityUpgrade turris/pyuci> to most recent version (>= 0.6) in TOS 3.x
We can drop Python 2 compatibilityTurris OS 3.11.10https://gitlab.nic.cz/turris/os/packages/-/issues/492[unbound] version bump 1.9.4 (fix for vulnerability CVE-2019-16866)2019-10-10T12:51:02+02:00Ghost User[unbound] version bump 1.9.4 (fix for vulnerability CVE-2019-16866)https://github.com/NLnetLabs/unbound/releases/tag/release-1.9.4
> This release is a fix for vulnerability CVE-2019-16866 that causes a failure when a specially crafted query is received.
>
> Bug Fixes:
> - Fix for the reported...https://github.com/NLnetLabs/unbound/releases/tag/release-1.9.4
> This release is a fix for vulnerability CVE-2019-16866 that causes a failure when a specially crafted query is received.
>
> Bug Fixes:
> - Fix for the reported vulnerability.
>
> The CVE number for this vulnerability is CVE-2019-16866
>
> == Summary
> Recent versions of Unbound contain a problem that may cause Unbound to
> crash after receiving a specially crafted query. This issue can only be
> triggered by queries received from addresses allowed by Unbound's ACL.
>
> == Affected products
> Unbound 1.7.1 up to and including 1.9.3.
>
> == Description
> Due to an error in parsing NOTIFY queries, it is possible for Unbound to
> continue processing malformed queries and may ultimately result in a
> pointer dereference in uninitialized memory. This results in a crash of
> the Unbound daemon.
>
> Whether this issue leads to a crash depends on the content of the
> uninitialized memory space and cannot be predicted. This issue can only
> be triggered by queries received from addresses that are allowed to send
> queries according to Unbound's ACL (access-control in the Unbound
> configuration).
>
> == Solution
> Download patched version of Unbound, or apply the patch manually.
>
> + Downloading patched version
> Unbound 1.9.4 is released with the patch
> https://nlnetlabs.nl/downloads/unbound/unbound-1.9.4.tar.gz
>
> + Applying the Patch manually
> For Unbound 1.7.1 up to and including 1.9.3 the patch is:
> https://nlnetlabs.nl/downloads/unbound/patch_cve_2019-16866.diff
>
> Apply the patch on Unbound source directory with:
> 'patch -p0 < patch_cve_2019-16866.diff'
> then run 'make install' to install Unboun d.Turris OS 3.11.8https://gitlab.nic.cz/turris/os/packages/-/issues/483nexcloud: install error2019-09-12T14:35:18+02:00Jan Pavlinecnexcloud: install errorNextcloud install ends with the following error (tested on 3.11.6 and 3.11.7 prerc)
```
Configuring php7-fpm.
Configuring php7-mod-xml.
Configuring php7-mod-zip.
Configuring php7-mod-gd.
Configuring nextcloud.
Configuring php7-mod-pdo....Nextcloud install ends with the following error (tested on 3.11.6 and 3.11.7 prerc)
```
Configuring php7-fpm.
Configuring php7-mod-xml.
Configuring php7-mod-zip.
Configuring php7-mod-gd.
Configuring nextcloud.
Configuring php7-mod-pdo.
Collected errors:
Collected errors:
* check_data_file_clashes: Package libmysqlclient wants to install file /usr/lib/libm6
But that file is already provided by package * libmariadbclient
* check_data_file_clashes: Package libmysqlclient wants to install file /usr/lib/libm0
But that file is already provided by package * libmariadbclient
* opkg_install_cmd: Cannot install package nextcloud-install.
```https://gitlab.nic.cz/turris/os/packages/-/issues/413kresd: Crashes after updating Turris OS 3.11.5 RC2020-07-23T14:00:45+02:00Lukas Jelinekkresd: Crashes after updating Turris OS 3.11.5 RCAfter a clean installation of Turris OS 3.11.5 RC onto Omnia everything around DNS resolving works fine. But after the first update and reboot the DNS resolver (kresd) crashes on start with the following message:
`Error relocating /usr/...After a clean installation of Turris OS 3.11.5 RC onto Omnia everything around DNS resolving works fine. But after the first update and reboot the DNS resolver (kresd) crashes on start with the following message:
`Error relocating /usr/lib/libdnssec.so.6: gnutls_privkey_sign_data2: symbol not found`
It means that DNS resolving does not work at all. Doesn't matter whether DNSSEC is enabled or disable, the same applies for DNS over TLS.
Steps to reproduce:
1. Install 3.11.5 RC onto Omnia.
2. Pass through the guided setup. Enable automatic updates at the appropriate screen.
3. Wait until the update process finishes.
4. Reboot the router.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/405[syslog-ng] stop | restart not working2019-06-10T13:17:06+02:00Ghost User[syslog-ng] stop | restart not working"4.14.123","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta2","revision":"a6dba1a","target":"mvebu\/cortexa9","d..."4.14.123","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta2","revision":"a6dba1a","target":"mvebu\/cortexa9","description":"TurrisOS 4.0-beta2 a6dba1a"}}
___
`/etc/init.d/syslog-ng stop` does not kill the process and instead it remains running. Also its `upd` socket remains alive.
Looking at with `htop` is seems that one `syslog-ng` child instance of its parent `supervising syslog-ng` gets terminated whilst a secondary child instance stays alive and the parent also does not terminate.
similar `/etc/init.d/syslog-ng restart`, the PID remains the same after the command been executed and it can be tested also by adding another destination in the syslog-ng conf. After the command been executed there is no file at the added destination. However, killing and starting the process manually the new log file is appearing at the added destination.
As a causality train post-installation scripts that restart `syslog-ng` do not report a fail of the restart whilst an actual restart did not happen. Same for logrotate with
```
postrotate
/etc/init.d/syslog-ng restart
```
Enclosed the `strace` logs for both events. [restart](/uploads/51e771530f577a017689333155122913/restart) [stop](/uploads/263831a45cf003dc26fd5bb346ac666a/stop)https://gitlab.nic.cz/turris/os/packages/-/issues/377resolver/unbound not listening on ipv6 iface2019-05-14T18:38:53+02:00Ghost Userresolver/unbound not listening on ipv6 iface@jpavlinec
TOS 3.11.4 | unbound 1.9.1
/etc/config/resolver
```
config resolver 'common'
list interface '127.0.0.1'
list interface '192.168.112.12'
list interface '::1'
list interface 'fd30:d64c:1eed:4c3a::12'
option forward_upstre...@jpavlinec
TOS 3.11.4 | unbound 1.9.1
/etc/config/resolver
```
config resolver 'common'
list interface '127.0.0.1'
list interface '192.168.112.12'
list interface '::1'
list interface 'fd30:d64c:1eed:4c3a::12'
option forward_upstream '0'
option prefered_resolver 'unbound'
option ignore_root_key '0'
option static_domains '1'
option dynamic_domains '1'
option keyfile '/etc/root.keys'
config resolver 'kresd'
option rundir '/tmp/kresd'
option log_stderr '1'
option log_stdout '1'
option forks '1'
option keep_cache '1'
#option include_config '/tmp/kresd.custom.conf'
#list hostname_config '/etc/hosts'
#list rpz_file '/tmp/file.rpz'
config resolver 'unbound'
option dhcp_link 'odhcpd'
option root_hints '/etc/unbound/named.cache'
config resolver 'unbound_includes'
list include_path "/etc/unbound/unbound_srv.conf"
list include_path "/etc/unbound/unbound_ext.conf"
config resolver 'unbound_remote_control'
option control_enable 'yes'
option control_use_cert 'no'
list control_interface '::1'
list control_interface '127.0.0.1'
```
With the above config it is expected that the resolver/unbound would be listening on the respective ipv4/ipv6 ifaces/addresses but it is only listening on the listed ipv4 ifaces/addresses but not on the ipv6.
![listening_ports](/uploads/74f0d80b246c432d69b6956d7a25c11e/listening_ports.png)Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/364keepalived: requires kmod-nf-ipvs2023-08-16T14:57:32+02:00Jan Pavlineckeepalived: requires kmod-nf-ipvsThis requirement prevents new keepalived from installing
Related forum topic https://forum.turris.cz/t/keepalived-depends-on-kmod-nf-ipvs-which-is-not-available/10036This requirement prevents new keepalived from installing
Related forum topic https://forum.turris.cz/t/keepalived-depends-on-kmod-nf-ipvs-which-is-not-available/10036https://gitlab.nic.cz/turris/os/packages/-/issues/349resolver-conf: add option for multiple ipv4/ipv6 address2020-03-20T13:31:15+01:00Jan Pavlinecresolver-conf: add option for multiple ipv4/ipv6 addressSupport multiple ipv4/ipv6 address in dns_servers config filesSupport multiple ipv4/ipv6 address in dns_servers config filesTurris OS 3.11.6Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/343turris-maintain: Network restart leaves net-related services in a broken state2023-08-16T14:38:04+02:00David Beiteyturris-maintain: Network restart leaves net-related services in a broken stateI noticed this a while back when attempting to change network-related settings within Foris — if you change any such settings, Foris will restart the networking stack via `/usr/bin/maintain-network-restart` which in turn calls `/etc/init...I noticed this a while back when attempting to change network-related settings within Foris — if you change any such settings, Foris will restart the networking stack via `/usr/bin/maintain-network-restart` which in turn calls `/etc/init.d/network restart`. Upon doing so, certain services on the router - at least OpenVPN and networking in LXC containers - are now non-functional, requiring different manual restart strategies to get them working again. This becomes a significant problem if you're relying on them when you make the change (eg you're connected via OpenVPN or your DNS served by process in LXC). Likewise, it's easily forgotten if you change wifi settings and forget that this restarts the whole networking stack, which then flows on.
Here's my breakdown so far:
* OpenVPN - the service remains up and connectable from a client, but traffic does not route. Looking into this, the `tun_turris` network interface on the router loses its IP addresses as shown in `ifconfig tun_turris` after the network restart occurs. OpenVPN requires a restart to bring it back online.
* LXC containers - the containers remain up but processes inside the container can't connect out (even to the the Turris Omnia host) and likewise nothing can connect in, even if the network is bridged. The state of the container shows interfaces still up with IP addresses but an empty routing table (eg output from `route` is empty) after the network restart occurs. A full restart of the container (eg `lxc-stop` & `lxc-start`) corrects the interface/routing problem.
In short, there should be some strategy in place for restarting services that depend on the network after it restarts. I'm unfamiliar with specifics of OpenWrt's init system, but that might be an option if it support dependencies. Otherwise, adding to `turris-maintain`'s scripts directly (if no other code is directly restarting the network) or else associating hook scripts to be trigged when `/etc/init.d/network` gets run.
As a workaround, I've amended `/usr/bin/maintain-network-restart` with the following at the end of the file (eg after [network restart](https://gitlab.labs.nic.cz/turris/turris-os-packages/blob/master/cznic/turris-maintain/files/network-restart.py#L86)):
```python
time.sleep(5) # Allow time for network to come online; OpenVPN needs this
subprocess.call(['/etc/init.d/openvpn', 'restart'])
subprocess.call(['/usr/bin/lxc-stop', '--name', 'mydnsserver'])
subprocess.call(['/usr/bin/lxc-start', '--name', 'mydnsserver'])
"
```
This way, at least when I make changes to LAN/WAN, OpenVPN or WiFi in Foris, all my services come back up okay and my network is functional.Turris OS 5.1