Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2023-10-23T10:15:16+02:00https://gitlab.nic.cz/turris/os/packages/-/issues/931rescue-mode-omnia: reflash from the internet is broken2023-10-23T10:15:16+02:00Aleksandr Gumroianrescue-mode-omnia: reflash from the internet is brokenIf `mode 6` is selected during reflash on my Omnia a.k.a `Flashing from the Cloud :-)` the following occurs:
- The reflash is stuck on step 1 - downloading the latest Omnia medkit, the serial console log:
<details>
<summary>Click to ex...If `mode 6` is selected during reflash on my Omnia a.k.a `Flashing from the Cloud :-)` the following occurs:
- The reflash is stuck on step 1 - downloading the latest Omnia medkit, the serial console log:
<details>
<summary>Click to expand</summary>
```
1s left
0s left
Mode 6 selected!
Flashing from the Cloud :-)
[ 9.101834] mvneta f1034000.ethernet eth2: PHY [f1072004.mdio-mii:01] driver [Marvell 88E1510]
[ 9.110598] mvneta f1034000.ethernet eth2: configuring for phy/sgmii link mode
[ 9.118241] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
udhcpc: started, v1.31.1
Setting IP address 0.0.0.0 on eth2
udhcpc: sending discover
udhcpc: sending discover
[ 12.311611] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control rx/tx
[ 12.319646] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
udhcpc: sending discover
udhcpc: sending select for 192.168.0.24
udhcpc: lease of 192.168.0.24 obtained, lease time 604800
Setting IP address 192.168.0.24 on eth2
Deleting routers
route: SIOCDELRT: No such process
Adding router 192.168.0.1
Recreating /etc/resolv.conf
Adding DNS server 192.168.0.1
Got IPv4!
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 532
link/ether d8:58:d7:00:55:13 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 532
link/ether d8:58:d7:00:55:11 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 532
link/ether d8:58:d7:00:55:12 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.24/24 brd 192.168.0.255 scope global eth2
valid_lft forever preferred_lft forever
inet6 2a02:8308:280:5d00:da58:d7ff:fe00:5512/64 scope global dynamic
valid_lft 3456000sec preferred_lft 2592000sec
inet6 fe80::da58:d7ff:fe00:5512/64 scope link
valid_lft forever preferred_lft forever
5: lan0@eth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether d8:58:d7:00:55:11 brd ff:ff:ff:ff:ff:ff
6: lan1@eth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether d8:58:d7:00:55:11 brd ff:ff:ff:ff:ff:ff
7: lan2@eth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether d8:58:d7:00:55:11 brd ff:ff:ff:ff:ff:ff
8: lan3@eth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether d8:58:d7:00:55:11 brd ff:ff:ff:ff:ff:ff
9: lan4@eth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether d8:58:d7:00:55:13 brd ff:ff:ff:ff:ff:ff
default via 192.168.0.1 dev eth2
192.168.0.0/24 dev eth2 scope link src 192.168.0.24
--2023-10-10 12:38:17-- https://repo.turris.cz/hbs/medkit/medkit-omnia-latest.tar.gz
```
</details>
- If you follow the [URL](https://repo.turris.cz/hbs/medkit/medkit-omnia-latest.tar.gz) from the log, you will get - `404 Not Found`
- https://repo.turris.cz/hbs/medkit/medkit-omnia-latest.tar.gz ❌
- https://repo.turris.cz/hbs/medkit/omnia-medkit-latest.tar.gz ✅
- The downloading of the image and the overall process of reflashing is stuck:
<details><summary>Click to expand</summary>
![telegram-cloud-photo-size-4-5848131056711089750-y](/uploads/72d7f6a843d0ece07f41b89b52afcd3f/telegram-cloud-photo-size-4-5848131056711089750-y.jpg)
</details>
There is obviously a problem somewhere in the [rescue script](https://gitlab.nic.cz/turris/os/packages/-/blob/master/hardware/rescue-image/files/helpers.sh#L112), but I could not find it.
Tested on Turris Omnia: Turris OS 6.3.2, HBS & Turris OS 6.4.2, HBS.https://gitlab.nic.cz/turris/os/packages/-/issues/929turris auth breaks lightppd2023-11-11T18:31:47+01:00Filip Hronturris auth breaks lightppd# outline
The "not-valid-json" error is probably caused by occasional breakdowns of turris auth
User refernce: https://forum.turris.cz/t/error-reforis-not-valid-json/19018/14?u=image
Target file: https://gitlab.nic.cz/turris/os/package...# outline
The "not-valid-json" error is probably caused by occasional breakdowns of turris auth
User refernce: https://forum.turris.cz/t/error-reforis-not-valid-json/19018/14?u=image
Target file: https://gitlab.nic.cz/turris/os/packages/-/blob/master/web/turris-auth/files/lighttpd.conf
# steps
- [ ] investigate logs when this occurs and find out why turris auth fails
- [ ] fix the problemMichal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/857Omnia LEDs migrate can not access new sysfs files in postinst2022-10-20T06:06:45+02:00Josef SchlehoferOmnia LEDs migrate can not access new sysfs files in postinst```
fix-omnia-leds-migrate/postinst: Command failed: Not found
/usr/libexec/rainbow/led_activity.sh: line 165: /sys/class/leds/rgb:wan/trigger: No such file or directory
grep: /sys/class/leds/rgb:wan/trigger: No such file or directory
Wa...```
fix-omnia-leds-migrate/postinst: Command failed: Not found
/usr/libexec/rainbow/led_activity.sh: line 165: /sys/class/leds/rgb:wan/trigger: No such file or directory
grep: /sys/class/leds/rgb:wan/trigger: No such file or directory
Warning: activity setup failed for: wan
/usr/libexec/rainbow/led_activity.sh: line 165: /sys/class/leds/rgb:wlan-1/trigger: No such file or directory
grep: /sys/class/leds/rgb:wlan-1/trigger: No such file or directory
Warning: activity setup failed for: wlan-1
/usr/libexec/rainbow/led_activity.sh: line 165: /sys/class/leds/rgb:wlan-2/trigger: No such file or directory
grep: /sys/class/leds/rgb:wlan-2/trigger: No such file or directory
Warning: activity setup failed for: wlan-2
/usr/libexec/rainbow/led_activity.sh: line 165: /sys/class/leds/rgb:wlan-3/trigger: No such file or directory
grep: /sys/class/leds/rgb:wlan-3/trigger: No such file or directory
Warning: activity setup failed
```Turris OS 6.0.1https://gitlab.nic.cz/turris/os/packages/-/issues/853turris-maintain: network-restart reload of network occurs too fast, which bre...2023-02-27T00:16:30+01:00Martin Matějekturris-maintain: network-restart reload of network occurs too fast, which breaks notifications about pending network restart`network-restart.py` script tries at first to send notification that network restart is pending ("restart in 2s", "1.8s", "1.6s", ...).
Then it proceeds to actually reload* network (`/etc/init.d/network reload`).
But what actually happe...`network-restart.py` script tries at first to send notification that network restart is pending ("restart in 2s", "1.8s", "1.6s", ...).
Then it proceeds to actually reload* network (`/etc/init.d/network reload`).
But what actually happens, is that network reload is executed while notifications are still being sent through mqtt.
<details><summary>Click to expand</summary>
![2022-10-06T22_01_19_900579698+02_00](/uploads/f7a30a80c0b6e951ee6e0b35def7d212/2022-10-06T22_01_19_900579698+02_00.png)
</details>
Therefore the reForis connection to the backend on the router disconnects, which breaks the WebSocket connection and all further notifications are effectively lost. Even thought they are being sent via the mqtt.
reForis expects to receive notification that basically says "now it is time to try to reconnect" (`{"remains": 0}` aka 0 seconds), but it never arrives, causing the spinner in reforis to keep spinning forever.
<details><summary>Click to expand</summary>
![2022-10-06T21_59_32_233382515+02_00](/uploads/47bcd2f7d94eb4619ea2a71ad5debe52/2022-10-06T21_59_32_233382515+02_00.png)
</details>
So we could
* either refactor the reconnect handling logic in reForis to be able to handle disconnects gracefully
* or somehow postpone the network reload a little bit, triggered in `network-restart.py` script, to make sure that notifications were sent and we can safely execute the network reload
On notice: @agumroian
---
* It is desirable to do reload instead restart, because it should reload only these interfaces that are related to change in config.https://gitlab.nic.cz/turris/os/packages/-/issues/850Rainbow: reconsider versioning for all three routers2022-09-16T14:03:23+02:00Josef SchlehoferRainbow: reconsider versioning for all three routersWhile reviewing https://gitlab.nic.cz/turris/os/packages/-/merge_requests/966, I noticed that we need to edit all three Makefiles if we bump rainbow-ng.
You should consider similar solution how it is done for shipping Turris u-boot pack...While reviewing https://gitlab.nic.cz/turris/os/packages/-/merge_requests/966, I noticed that we need to edit all three Makefiles if we bump rainbow-ng.
You should consider similar solution how it is done for shipping Turris u-boot packages in this repository or rather proposed solution, which I got on IRC #openwrt-devel:
```
20:23:24 <pepes> Guys, I am thinking. I would like to have dedicated U-boot package installable within opkg and I could copy the U-boot image from staging_dir and put it to whatever I want. Because right now, I compiling it twice. :-( Is there way, how can I use the same versioning from different package? So, I could know the version of U-boot by opkg. Any ideas?
20:24:05 <jow> pepes: there's no clean way
20:24:23 <jow> you could define a shared .mk file that just declares the version, then include that in both places
20:25:38 <jow> or you could use a construct like PKG_VERSION:=$(if $(DUMP),x,$(shell sed -ne 's#PKG_VERSION:=##p' $(topdir)/package/boot/u-boot-foo/Makefile))
20:28:04 <pepes> Thanks jow! I will try it, but it looks like it is going to help. THanks! I will let you know about it.
```
This means use shared .mk file.Turris OS 6.0.1https://gitlab.nic.cz/turris/os/packages/-/issues/837Rescue system in rescue-image_3.6.1-1 does not work2022-08-13T09:44:13+02:00Jan BetikRescue system in rescue-image_3.6.1-1 does not workSSL wget does not work. Flash from the cloud not possible.
```
~ # ping -s 1500 nic.cz
PING nic.cz (217.31.205.50): 1500 data bytes
1508 bytes from 217.31.205.50: seq=0 ttl=61 time=2.074 ms
1508 bytes from 217.31.205.50: seq=1 ttl=61 tim...SSL wget does not work. Flash from the cloud not possible.
```
~ # ping -s 1500 nic.cz
PING nic.cz (217.31.205.50): 1500 data bytes
1508 bytes from 217.31.205.50: seq=0 ttl=61 time=2.074 ms
1508 bytes from 217.31.205.50: seq=1 ttl=61 time=1.694 ms
1508 bytes from 217.31.205.50: seq=2 ttl=61 time=1.843 ms
1508 bytes from 217.31.205.50: seq=3 ttl=61 time=1.750 ms
1508 bytes from 217.31.205.50: seq=4 ttl=61 time=1.828 ms
^C
--- nic.cz ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 1.694/1.837/2.074 ms
~ # wget https://repo.turris.cz/hbs/medkit/omnia-medkit-latest.tar.gz
--2022-04-28 14:26:03-- https://repo.turris.cz/hbs/medkit/omnia-medkit-latest.tar.gz
^C
~ # wget -c http://www.nic.cz/
--2022-04-28 14:26:56-- http://www.nic.cz/
Resolving www.nic.cz... 2001:1488:0:3::2, 217.31.205.50
Connecting to www.nic.cz|2001:1488:0:3::2|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.nic.cz/ [following]
--2022-04-28 14:26:56-- https://www.nic.cz/
^C
~ # wget --version
GNU Wget 1.20.3 built on linux-gnu.
-cares +digest -gpgme +https +ipv6 -iri +large-file -metalink -nls
+ntlm +opie -psl +ssl/openssl
Wgetrc:
/etc/wgetrc (system)
Compile:
ccache_cc -DHAVE_CONFIG_H -DSYSTEM_WGETRC="/etc/wgetrc"
-DLOCALEDIR="/usr/share/locale" -I. -I../lib -I../lib
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/include
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/include
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/toolchain-arm_cortex-a9+vfpv3-d16_gcc-7.5.0_musl_eabi/usr/include
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/toolchain-arm_cortex-a9+vfpv3-d16_gcc-7.5.0_musl_eabi/include/fortify
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/toolchain-arm_cortex-a9+vfpv3-d16_gcc-7.5.0_musl_eabi/include
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/include
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/include
-DNDEBUG -Os -pipe -fno-caller-saves -fno-plt -fhonour-copts
-Wno-error=unused-but-set-variable -Wno-error=unused-result
-mfloat-abi=hard
-iremap/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/wget-ssl/wget-1.20.3:wget-1.20.3
-Wformat -Werror=format-security -fpic -fstack-protector-strong
-D_FORTIFY_SOURCE=2 -Wl,-z,now -Wl,-z,relro
Link:
ccache_cc
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/include
-I/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/include
-DNDEBUG -Os -pipe -fno-caller-saves -fno-plt -fhonour-copts
-Wno-error=unused-but-set-variable -Wno-error=unused-result
-mfloat-abi=hard
-iremap/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/wget-ssl/wget-1.20.3:wget-1.20.3
-Wformat -Werror=format-security -fpic -fstack-protector-strong
-D_FORTIFY_SOURCE=2 -Wl,-z,now -Wl,-z,relro
-L/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/lib
-L/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/lib
-L/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/toolchain-arm_cortex-a9+vfpv3-d16_gcc-7.5.0_musl_eabi/usr/lib
-L/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/toolchain-arm_cortex-a9+vfpv3-d16_gcc-7.5.0_musl_eabi/lib
-fpic
-specs=/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/include/hardened-ld-pie.specs
-znow -zrelro
-L/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/lib
-lpcre
/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/lib/libssl.so
/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/lib/libcrypto.so
-ldl
-L/home/beast/beast/workspace/turris-os-packages-lions-omnia/build/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/usr/lib
-lz ftp-opie.o openssl.o http-ntlm.o ../lib/libgnu.a
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://www.gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Originally written by Hrvoje Niksic <hniksic@xemacs.org>.
Please send bug reports and questions to <bug-wget@gnu.org>.
~ # wget -c http://repo.turris.cz/hbs/medkit/omnia-medkit-latest.tar.gz
--2022-04-28 14:30:50-- http://repo.turris.cz/hbs/medkit/omnia-medkit-latest.tar.gz
Resolving repo.turris.cz... 2001:1488:ac15:ff80::84, 217.31.192.84
Connecting to repo.turris.cz|2001:1488:ac15:ff80::84|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://repo.turris.cz/hbs/medkit/omnia-medkit-latest.tar.gz [following]
--2022-04-28 14:30:50-- https://repo.turris.cz/hbs/medkit/omnia-medkit-latest.tar.gz
^C
```Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/822Omnia: update rescue image2022-04-06T14:20:56+02:00Josef SchlehoferOmnia: update rescue imageTurris OS 6.1.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/769Error in syntax in rescue mode2021-08-03T09:17:49+02:00Jan BetikError in syntax in rescue modeI'm playing with MOX and its rescue modes and I have noticed this:
```
Now is your chance to change a mode from 1 to something else, press the button to do so
expr: syntax error
Waiting for s ...
6s left
5s left
Mode changed to 2
```
d...I'm playing with MOX and its rescue modes and I have noticed this:
```
Now is your chance to change a mode from 1 to something else, press the button to do so
expr: syntax error
Waiting for s ...
6s left
5s left
Mode changed to 2
```
do not know if it is normal or not but I definitely do not like it.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/759knot-resolver: add option to enable http module2023-01-11T14:18:00+01:00Jan Pavlinecknot-resolver: add option to enable http moduleDocumentation https://knot-resolver.readthedocs.io/en/latest/modules-http.html
CZ.NIC blogpost https://en.blog.nic.cz/2016/08/12/knot-dns-1-1-0/
Note:
Maybe we can then use /trace in resolver-debug etcDocumentation https://knot-resolver.readthedocs.io/en/latest/modules-http.html
CZ.NIC blogpost https://en.blog.nic.cz/2016/08/12/knot-dns-1-1-0/
Note:
Maybe we can then use /trace in resolver-debug etchttps://gitlab.nic.cz/turris/os/packages/-/issues/733sentinel-proxy: data sending indication (v1.5)2023-05-30T14:38:01+02:00Karel Kocisentinel-proxy: data sending indication (v1.5)The feature release that includes indication of connected collectors as well as connection to the Sentinel server.
- [ ] turris/sentinel/sentinel#26The feature release that includes indication of connected collectors as well as connection to the Sentinel server.
- [ ] turris/sentinel/sentinel#26Turris OS 6.2.0https://gitlab.nic.cz/turris/os/packages/-/issues/729foris-controller-openvpn-module: IPv6 fix listening on IPv62021-06-01T18:26:38+02:00Martin Matějekforis-controller-openvpn-module: IPv6 fix listening on IPv6Fix "listen on IPv6" feature.
- [ ] [foris-controller-openvpn-module: fix listening on IPv6](https://gitlab.nic.cz/turris/foris-controller/foris-controller-openvpn-module/-/milestones/1)Fix "listen on IPv6" feature.
- [ ] [foris-controller-openvpn-module: fix listening on IPv6](https://gitlab.nic.cz/turris/foris-controller/foris-controller-openvpn-module/-/milestones/1)Turris OS 6.1.0https://gitlab.nic.cz/turris/os/packages/-/issues/671Sentinel-firewall: move configuration from firewall section to sentinel2022-12-28T22:29:56+01:00Karel KociSentinel-firewall: move configuration from firewall section to sentinelAt the moment fw3 complains with following warnings:
```
Warning: Option @zone[1].sentinel_dynfw is unknown
Warning: Option @zone[1].sentinel_minipot is unknown
Warning: Option @zone[1].haas_proxy is unknown
Warning: Option @zone[1].sent...At the moment fw3 complains with following warnings:
```
Warning: Option @zone[1].sentinel_dynfw is unknown
Warning: Option @zone[1].sentinel_minipot is unknown
Warning: Option @zone[1].haas_proxy is unknown
Warning: Option @zone[1].sentinel_fwlogs is unknown
```
These are harmless and used by sentinel-firewall scripts but it can confuse users.
We should rather move it to sentinel config and rather link zone name from there. This requires:
* [ ] modification of code to expect config rather in sentinel configuration over firewall
* [ ] fix package to migrate existing configuration from firewall to sentinel configTurris OS 6.2.0https://gitlab.nic.cz/turris/os/packages/-/issues/627Nexcloud database error2022-12-12T15:09:32+01:00leoprosperiNexcloud database errorAfter a brand new installation of Nextcloud 17 on Turris Omnia with v5.0.3, I saw the following warning on /nextcloud/index.php/settings/admin/overview:
> Some columns in the database are missing a conversion to big int. Due to the fact...After a brand new installation of Nextcloud 17 on Turris Omnia with v5.0.3, I saw the following warning on /nextcloud/index.php/settings/admin/overview:
> Some columns in the database are missing a conversion to big int. Due to the fact that changing column types on big tables could take some time they were not changed automatically. By running 'occ db:convert-filecache-bigint' those pending changes could be applied manually. This operation needs to be made while the instance is offline. For further details read the documentation page about this.
> mounts.storage_id
> mounts.root_id
> mounts.mount_id
Running this command cleared the issues:
`sudo -u nobody php-cli /srv/www/nextcloud/occ db:convert-filecache-bigint`Turris OS 6.1.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/621[meta] DNS testing in reforis2021-07-15T14:10:13+02:00Jan Pavlinec[meta] DNS testing in reforisThis issue is related to our meeting about better DNS diagnostic
[check_connection](https://gitlab.labs.nic.cz/turris/turris-os-packages/-/blob/master/utils/turris-utils/files/check_connection) script should be replaced with python vers...This issue is related to our meeting about better DNS diagnostic
[check_connection](https://gitlab.labs.nic.cz/turris/turris-os-packages/-/blob/master/utils/turris-utils/files/check_connection) script should be replaced with python version which could test other DNS settings (forwarding not working, DNS hijack etc.)
This script can use some functionality from [resolver_rpcd](https://gitlab.labs.nic.cz/turris/turris-os-packages/-/blob/master/net/resolver-conf/files/resolver_rpcd.py) (see https://pypi.org/project/ubus/ and [README.md](https://gitlab.labs.nic.cz/turris/turris-os-packages/-/blob/master/net/resolver-conf/README.md)) and read setting from uci https://gitlab.labs.nic.cz/turris/pyuci [resolver configuration](https://gitlab.labs.nic.cz/turris/turris-os-packages/-/blob/master/net/resolver-conf/files/resolver-omnia-config)
Related issues/MR:
* [x] pytest-xdist MR https://gitlab.nic.cz/turris/turris-os-packages/-/issues/317 / https://github.com/openwrt/packages/pull/13010
* [ ] https://gitlab.nic.cz/turris/turris-os-packages/-/issues/620
* [ ] augeas MR https://github.com/openwrt/packages/pull/12913
* [ ] Deckard MR https://gitlab.nic.cz/turris/turris-os-packages/-/merge_requests/460
cc @pspacek @kkocihttps://gitlab.nic.cz/turris/os/packages/-/issues/524lxc: reconnect to network after host network restart2023-08-28T01:33:58+02:00Martin Matějeklxc: reconnect to network after host network restartIn case of network settings changes in LAN, bridge will be restarted and lxc guests will be detached from that bridge.
This could be partially fixed by lxc-hotplug (reattach network lxc interfaces to bridge), but it won't help if networ...In case of network settings changes in LAN, bridge will be restarted and lxc guests will be detached from that bridge.
This could be partially fixed by lxc-hotplug (reattach network lxc interfaces to bridge), but it won't help if network setting changes.
In that case we should somehow trigger network reload in lxc guests too to make sure that they will reconnect to newly configured network.
Complement issue to turris/os/packages#343