Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2022-06-06T14:10:02+02:00https://gitlab.nic.cz/turris/os/packages/-/issues/746FW reload via LuCi makes sentinel traps unreachable2022-06-06T14:10:02+02:00Martin PrudekFW reload via LuCi makes sentinel traps unreachableAfter a FW change via LuCi - e.g. enabling/disabling some FW rule or adding a new one, FW reload is needed. It could be
applied using standard `Save & Apply` button.
![image](/uploads/3e793e5bb4bfa4e8eca6c8735e71c9c2/image.png)
Subse...After a FW change via LuCi - e.g. enabling/disabling some FW rule or adding a new one, FW reload is needed. It could be
applied using standard `Save & Apply` button.
![image](/uploads/3e793e5bb4bfa4e8eca6c8735e71c9c2/image.png)
Subsequent **firewall reload** causes sentinel traps like HaaS Proxy and minipots to be **unreachable** from WAN - resulting in "Connection refused".
This could be locally fixed by running one of the following commands:
* `sentinel-reload`
* `fw3 reload`
* `/etc/init.d/firewall restart`
* `service firewall restart`
Originally reported in: https://gitlab.nic.cz/turris/project/-/issues/116#note_204548
More research in: https://gitlab.nic.cz/turris/reforis/reforis/-/issues/316#note_205002Filip HronFilip Hronhttps://gitlab.nic.cz/turris/os/packages/-/issues/794Networking in TOS 6.0 on MOX doesn't work2022-04-14T12:19:06+02:00Lukas JelinekNetworking in TOS 6.0 on MOX doesn't workIn Turris OS 6.0 (HBD) on MOX, networking doesn't work at all after booting. It can be temporarily fixed by assigning an address to a port (the `br-lan` bridge respectively) but this assignment doesn't persist over disconnecting and reco...In Turris OS 6.0 (HBD) on MOX, networking doesn't work at all after booting. It can be temporarily fixed by assigning an address to a port (the `br-lan` bridge respectively) but this assignment doesn't persist over disconnecting and reconnecting the cable.https://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/819Kresd does not resolve DHCPv6 leases2022-01-18T10:18:01+01:00Jan BetikKresd does not resolve DHCPv6 leasesKresd does not resolve DHCPv6 leases, works for IPv4 only.
Workaround found on https://doc.turris.cz/doc/en/public/dns_knot_misc#local_resolution_of_a_fully_qualified_domain_name cannot be used with `/tmp/hosts/odhcpd` as this file is ...Kresd does not resolve DHCPv6 leases, works for IPv4 only.
Workaround found on https://doc.turris.cz/doc/en/public/dns_knot_misc#local_resolution_of_a_fully_qualified_domain_name cannot be used with `/tmp/hosts/odhcpd` as this file is dynamically generated and can get changed over the time, but kresd loads that file only during startup and is not able to detect the changes.https://gitlab.nic.cz/turris/os/packages/-/issues/577Improve certgen hooks directory manipulation2022-01-04T14:57:18+01:00Vojtech MyslivecImprove certgen hooks directory manipulationFollow-up from https://gitlab.nic.cz/turris/diagnostics/-/merge_requests/6#note_147685
@vmyslivec:
> * Certgen itself is installed on base system due to `mailpass` feature
> * *hooks dir* is created and used by `sentinel-proxy` package
...Follow-up from https://gitlab.nic.cz/turris/diagnostics/-/merge_requests/6#note_147685
@vmyslivec:
> * Certgen itself is installed on base system due to `mailpass` feature
> * *hooks dir* is created and used by `sentinel-proxy` package
> * Hooks dir is possibly optional (you can issue a certificate without a proxy) and Certgen does not have a default value hardcoded
>
> This approach was introduced in turris/turris-os-packages!86
@kkoci:
> I think that is is just too complicated. That hook dir is not essential and default should be hardcodded.
>
> The point of hook directory is that program itself runs those hooks but won't fail if there is no such directory and or if hook fails. Both users and programs should be sure that when program is run that hook dir is used not just in case hooks are specified. This is at least how I see hooks.
>
> This means that:
>
> * hooks dir can be created by `certgen` package by putting file `.keep` in it or it doesn't have to be but then it should not fail if it is missing
> * hooks should always be called from expected location unless option is used to not call hooks (reverse implicit rule against current state)
>
> I know that I was reviewing that code but now when I see it used I see that it is flawed in this case. Hooks should be reliable in some sense and not some adhock thing. I feel like this implementation now has almost no difference over `certgen && for f in /hook/*; $f; done` in sense that user chooses what is executed and if he knows little then it breaks a lot potentially.https://gitlab.nic.cz/turris/os/packages/-/issues/265Update hangs if Dynamic DNS updater active2021-11-30T21:34:15+01:00Tony QuanUpdate hangs if Dynamic DNS updater activeIf the Dynamic DNS updater is active/running, updates from 3.10.8 to 3.11 TurrisOS hang and never complete. pkgupdate log shows the following and nothing after this point in the log.
```
DEBUG:backend.lua:1021 (script_run):
DEBUG:backe...If the Dynamic DNS updater is active/running, updates from 3.10.8 to 3.11 TurrisOS hang and never complete. pkgupdate log shows the following and nothing after this point in the log.
```
DEBUG:backend.lua:1021 (script_run):
DEBUG:backend.lua:1009 (script_run):Running postinst of ddns-scripts
DEBUG:src/lib/interpreter.c:320 (lua_run_generic):Command: /usr/lib/opkg/info//ddns-scripts.postinst configure
TRACE:src/lib/events.c:542 (run_command_a):Running command /usr/lib/opkg/info//ddns-scripts.postinst
```
This bug seems to have occurred before in the upgrade to 3.10.1 as pointed out [in this forum post](https://forum.turris.cz/t/solved-pkgupdate-not-working-probably-after-update-3-10-1/7653/4). As the Dynamic DNS updater is a pretty common service, testing of updates should be performed with it in place and active.https://gitlab.nic.cz/turris/os/packages/-/issues/745schnapps rollback to factory on Shield print errors2021-11-13T01:06:26+01:00Vojtech Myslivecschnapps rollback to factory on Shield print errorsSample of factory rollback from Shield's console:
```
Current state saved as snapshot number 10
Rolled back to snapshot factory
/etc/schnapps/rollback.d/10_cert-backup.sh: line 2: cert-backup: not found
Everything done, rebooting!
```
E...Sample of factory rollback from Shield's console:
```
Current state saved as snapshot number 10
Rolled back to snapshot factory
/etc/schnapps/rollback.d/10_cert-backup.sh: line 2: cert-backup: not found
Everything done, rebooting!
```
Either `schnapps` should depends on `cert-backup` or `schnapps` should handle its missing quietly/systematically.https://gitlab.nic.cz/turris/os/packages/-/issues/765knot-resolver: remove duplicit /etc/kresd2021-10-06T14:07:51+02:00Jan Pavlinecknot-resolver: remove duplicit /etc/kresdIntroduced by https://gitlab.nic.cz/turris/os/packages/-/commit/e5bfc2c1d6cdfee3eada1ed461a90b557d147e9b#note_213178Introduced by https://gitlab.nic.cz/turris/os/packages/-/commit/e5bfc2c1d6cdfee3eada1ed461a90b557d147e9b#note_213178https://gitlab.nic.cz/turris/os/packages/-/issues/20resolver-conf: Please disable open resolver in the config2021-09-08T16:18:48+02:00Ondřej Caletkaresolver-conf: Please disable open resolver in the configIn current setup, the only thing that stops TurrisOS from being an open resolver is the default firewall config. Lot of inexperienced users unintentionally enable incoming udp/53 traffic, making the router act like an open resolver.
The...In current setup, the only thing that stops TurrisOS from being an open resolver is the default firewall config. Lot of inexperienced users unintentionally enable incoming udp/53 traffic, making the router act like an open resolver.
There should be safer default in the config of DNS recursors, that would allow recursive queries only from internal network, regardless of the state of the firewall.https://gitlab.nic.cz/turris/os/packages/-/issues/791Adblock package doesn't update unblock config2021-09-03T16:33:19+02:00Vlastimil ZimaAdblock package doesn't update unblock configTo make adblock work on Turris 1.X I had to append
```
config resolver 'unbound_includes'
list include_path "/var/lib/unbound/adb_list.overall"
```
to the `/etc/config/resolver`.
I suspect that adblock can update `unbound` config, but ...To make adblock work on Turris 1.X I had to append
```
config resolver 'unbound_includes'
list include_path "/var/lib/unbound/adb_list.overall"
```
to the `/etc/config/resolver`.
I suspect that adblock can update `unbound` config, but its overridden by the `resolver-conf` anyway and thus adblock stops working.Turris OS 6.2.0https://gitlab.nic.cz/turris/os/packages/-/issues/778WebApps missing after clean install of TOS 5.2.32021-09-03T11:11:18+02:00Lukas JelinekWebApps missing after clean install of TOS 5.2.3I've installed a clean Turris OS 5.2.3 from its medkit into my Omnia. When done and rebooted, I can login only to reForis. There are no WebApps. The web root redirects to reForis and there is no possibility how to go to Foris.I've installed a clean Turris OS 5.2.3 from its medkit into my Omnia. When done and rebooted, I can login only to reForis. There are no WebApps. The web root redirects to reForis and there is no possibility how to go to Foris.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/592[Meta] knot-resolver/unbound: domain blocking for specific clients2021-08-31T15:42:01+02:00Jan Pavlinec[Meta] knot-resolver/unbound: domain blocking for specific clientsThis issue is related to the idea of how to use AdBlock only for specific clients.
**knot-resolver:**
It's possible to add custom rpz policy for specific subnet
https://knot-resolver.readthedocs.io/en/latest/modules-view.html#example...This issue is related to the idea of how to use AdBlock only for specific clients.
**knot-resolver:**
It's possible to add custom rpz policy for specific subnet
https://knot-resolver.readthedocs.io/en/latest/modules-view.html#example-configuration
```
-- RPZ for subset of clients
view:addr('192.168.1.0/24', policy.rpz(policy.PASS, 'whitelist.rpz'))
```
**unbound:**
The same feature could be done probably with access-control-tags
see https://medium.com/nlnetlabs/client-based-filtering-in-unbound-d7da3f1ef639 and
https://medium.com/nlnetlabs/response-policy-zones-in-unbound-5d453de75f26https://gitlab.nic.cz/turris/os/packages/-/issues/731Improving NextCloud experience on the Omnia2021-08-18T00:52:55+02:00Amit ShahImproving NextCloud experience on the OmniaThe NextCloud version that is installed on a fresh install is quite outdated - 18.04. Even with the v18 series, it's not the latest. This is two major versions behind; and the v18 series has also seen its last release last month. Since...The NextCloud version that is installed on a fresh install is quite outdated - 18.04. Even with the v18 series, it's not the latest. This is two major versions behind; and the v18 series has also seen its last release last month. Since the NC install does not get any patch updates or security updates on TurrisOS, it goes against the philosophy of being a security-focused router.
I realize there are good reasons for not just updating the NC version installed by default. Referencing issue #680 here. But that also leads to long-standing bugs like issue #662.
I'd like to start a discussion to fix the situation, and also help improving it.
Here are the problems with the current setup:
a. TurrisOS updates (important, security updates for the core router functionality) should not interfere with NC updates. With the current setup, if an NC update was to be pushed, it'll have to compete with these core updates. How does one distinguish between an NC update, that does not need a reboot, vs an OS update, that does? What is a regular cadence for NC updates vs OS updates?
b. NC updates landing via OS package updates need to ensure to put the NC in maintenance mode before installing the package, otherwise there's risk of DB corruption. Currently, this is not taken care of.
c. NC updates may take a long time to activate due to DB upgrades. That is not desirable to happen asynchronously, without admin involvement. OS updates, on the other hand, are important to be pushed to routers, so that they are rebooted into the most secure state as soon as possible.
Suggestions to improve on the situation:
1. NextCloud should get its own opkg feed repository. It's currently packaged as part of the `turrispackages` repo; we should move to a separate `nextcloud` repo. Separating out the NC feeds into one, possibly multiple, helps us manage the upgrades from v18 -> v20 series.
2. OS updates and NC updates will not be tied together with this change in point 1. When the OS updates are being installed, the NC repository can be masked, so that NC updates are installed and checked for *after* OS updates are installed.
3. A separate configurations page in the ReForis UI for NC maintenance. This will include options to put NC in maint mode; upgrade NC
4. Optionally, take a snapshot of the /srv subvolume so that "bad" NC updates can be rolled back as well.
5. [Not sure completely of this point] Does NC have to be put in maintenance mode before reboot or update activities? To ensure consistency of data, that the sequence of events is: NC in maint mode -> mysql service stopped -> reboot. On the next bootup, NC will be put out of maint mode after /srv is mounted and after mysql has restarted.
I've previously suggested in https://forum.turris.cz/t/nextcloud-data-consistency-issues-and-suggested-workarounds/14835 to offer NC as an LXC image instead; but I think offering it in a separate feed/repo makes more sense.
I'd first like to discuss the problem and the solutions here; but it's clear we need to improve the situation w.r.t. NextCloud on TurrisOS.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/503turris-cagen: more granural locking2021-08-16T16:38:14+02:00Štěpán Henekturris-cagen: more granural lockingRight now it locks by CA name. It should lock by locked by CA dirname (slugified).
Problem:
Netboot uses cagen to generate CA for the client and the new ca is always called remote.
e.g.
```sh
CA_DIR=transfering/0000000D30001605 /tmp/cag...Right now it locks by CA name. It should lock by locked by CA dirname (slugified).
Problem:
Netboot uses cagen to generate CA for the client and the new ca is always called remote.
e.g.
```sh
CA_DIR=transfering/0000000D30001605 /tmp/cagen.sh new_ca remote gen_ca gen_server turris gen_client 0000000A00000214-0000000D30001605
```
This will lock all `remote` CAs. => `/etc/ssl/remote` CA and `/srv/turris-neboot/clients/transfering/*` CAs can't be modified while the script is running, although it can safely run in parellel.https://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/586Regression: DHCP names not auto-updating in TurrisOS 5.x2021-07-29T12:49:49+02:00Leonardo Brondani SchenkelRegression: DHCP names not auto-updating in TurrisOS 5.xIn Turris OS 4.x, `dnsmasq` was updating `kresd` by:
1. invoking `/usr/lib/dnsmasq/dhcp-script.sh`
2. which invoked `/sbin/hotplug-call`
3. which invoked each script in `/etc/hotplug.d/dhcp`, one being `90-dhcp_host_domain_ng.py` (symlin...In Turris OS 4.x, `dnsmasq` was updating `kresd` by:
1. invoking `/usr/lib/dnsmasq/dhcp-script.sh`
2. which invoked `/sbin/hotplug-call`
3. which invoked each script in `/etc/hotplug.d/dhcp`, one being `90-dhcp_host_domain_ng.py` (symlink to `/etc/resolver/dhcp_host_domain.py`) which used to be installed by `resolver-conf`.
In TurrisOS 5.x the symlink is no longer installed. Creating it manually no longer works: `hotplug-call` fails because `dnsmasq` is now jailed.
Ever since I upgraded from 4.x to 5.x, (new) DHCP names no longer resolve. The updater script is only called during `kresd` initialization, but not when `dnsmasq` gives new leases.
```
# uci get resolver.common.dynamic_domains
1
```https://gitlab.nic.cz/turris/os/packages/-/issues/27resolver: add support for ipv6 static leases2021-07-29T09:57:19+02:00Jan Pavlinecresolver: add support for ipv6 static leaseshttps://forum.turris.cz/t/kresd-ipv6-hints/3680https://forum.turris.cz/t/kresd-ipv6-hints/3680https://gitlab.nic.cz/turris/os/packages/-/issues/663resolver configuration documentation2021-07-29T09:51:53+02:00Jan Pavlinecresolver configuration documentationWe should document /etc/config/resolverWe should document /etc/config/resolverhttps://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/252Kresd responds from incorrect source IP2021-07-09T17:26:26+02:00Jan PavlinecKresd responds from incorrect source IPhttps://forum.turris.cz/t/kresd-responds-from-incorrect-source-ip/8620https://forum.turris.cz/t/kresd-responds-from-incorrect-source-ip/8620