Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2024-02-21T15:43:18+01:00https://gitlab.nic.cz/turris/os/packages/-/issues/591Mox: update rescue image2024-02-21T15:43:18+01:00Karel KociMox: update rescue imageFew issues were fixed when we were porting rescue image to Omnias 2019+. These fixes should be propagated to Mox as well.
Known fixes:
* select rescue mode directly from u-bootFew issues were fixed when we were porting rescue image to Omnias 2019+. These fixes should be propagated to Mox as well.
Known fixes:
* select rescue mode directly from u-bootTurris OS 7.1.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/918RFE: configure all Turris webapps to run under URL /turris/2024-01-08T11:27:03+01:00Glenn StraussRFE: configure all Turris webapps to run under URL /turris/RFE: configure all Turris webapps to run under URL /turris/
Would the Turris Team consider this idea?
/turris/login
/turris/login.json
/turris/logout
/turris/foris-ws
/turris/reforis/
/turris/diagnostics
/turris/snapshots
/baseauth/dia...RFE: configure all Turris webapps to run under URL /turris/
Would the Turris Team consider this idea?
/turris/login
/turris/login.json
/turris/logout
/turris/foris-ws
/turris/reforis/
/turris/diagnostics
/turris/snapshots
/baseauth/diagnostics
/baseauth/snapshots
/turris-api/ (instead of /api)
Doing the above could help improve the security of the system by simplifying the configuration, addressing #866
Everything under /turris/ would require turris-auth.
Everything under /baseauth/ would require PAM.
"Virtually" moving all of these services would make it easier to configure other *independent* services in lighttpd, without accidentally inheriting the settings which are currently in the global config and aimed at all the Turris-specific services. This would also make it easier for users to configure *independent* vhosts, e.g. #894
If the Turris Team is willing to consider this, I can mock up some changes to test, and can create a separate, optional file for /etc/lighttpd/conf.d/ to redirect the current Turris URLs to the ones above. Besides the above, a single, optional index.html would be created for the splash page at /, and could redirect to /turris/. Then, end-users could replace that splash page, if they like.Richard MuzikRichard Muzikhttps://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/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/927schnapps: soft dependencies2023-09-20T11:21:24+02:00Richard Muzikschnapps: soft dependenciesSchnapps uses some packages (gnupg, sshfs...), that are not necessary for it to work, but some functionalities won't be available. So we should make them soft (suggested) dependencies.Schnapps uses some packages (gnupg, sshfs...), that are not necessary for it to work, but some functionalities won't be available. So we should make them soft (suggested) dependencies.https://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#343https://gitlab.nic.cz/turris/os/packages/-/issues/487Utility for random delay start2023-06-26T14:09:19+02:00Vojtech MyslivecUtility for random delay startThere are several tools that communicates with Turris or other servers. It is practical to spread the startup time of these utilities a bit to prevent peak load on the servers.
Random delay (sleep) is used in several tools at the moment...There are several tools that communicates with Turris or other servers. It is practical to spread the startup time of these utilities a bit to prevent peak load on the servers.
Random delay (sleep) is used in several tools at the moment. It would be nice to prepare one common utility which would be used by our tools so this functionality would be unified and easy to use.
This utility can be used in
- Updater
- Netmetr
- HaaS(?)
- Server side backups
- Sentinel services
- Certgen/Proxy
- Firewall logs (Nikola)
- Surveyhttps://gitlab.nic.cz/turris/os/packages/-/issues/825Let user define own DNS server in the OpenVPN server configuration2023-06-15T18:54:18+02:00Jan BetikLet user define own DNS server in the OpenVPN server configurationSome users do not use the DNS server provided by the router but its own DNS server.
In this case, while being connected as a client to VPN and using option `Use DNS via VPN` the client cannot resolve the hostnames of machines behind the ...Some users do not use the DNS server provided by the router but its own DNS server.
In this case, while being connected as a client to VPN and using option `Use DNS via VPN` the client cannot resolve the hostnames of machines behind the VPN.
The user should be able to set its own DNS server to be passed as an option to VPN clients.https://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/805Guest network does not work while device is acting as VPN client2023-05-15T15:43:20+02:00Jan BetikGuest network does not work while device is acting as VPN clientWhile the Turris is connected as VPN client with default route tunneled through the VPN gateway, the guest network does not have access to the Internet.
The Internet connectivity is re-enabled when the VPN client disconnects.
https://fo...While the Turris is connected as VPN client with default route tunneled through the VPN gateway, the guest network does not have access to the Internet.
The Internet connectivity is re-enabled when the VPN client disconnects.
https://forum.turris.cz/t/vpn-client-muze-koexistovat-s-guest-wifi/16204https://gitlab.nic.cz/turris/os/packages/-/issues/851Unable to resolve hosts entered in /etc/hosts over DNS2023-03-24T16:07:23+01:00Robert LamontUnable to resolve hosts entered in /etc/hosts over DNSGoal:
Have jenkins.example.com and other internal services (*.example.com) resolve only when on the LANs (not on the wider internet).
Problem:
Entries in /etc/hosts are ignored by kresd despite LuCI's "Ignore /etc/hosts" option being un...Goal:
Have jenkins.example.com and other internal services (*.example.com) resolve only when on the LANs (not on the wider internet).
Problem:
Entries in /etc/hosts are ignored by kresd despite LuCI's "Ignore /etc/hosts" option being unticked.
More information:
In our setup, each LAN has a local domain like lan1.example.com. Moving jenkins.example.com to jenkins.lan1.example.com isn't good because it means we cannot use a wildcard TLS certificate like *.example.com because the certificate authorities don't sell subdomain wildcard certs.
After reading [the knot resolver's documentation](https://knot-resolver.readthedocs.io/en/v2.4.0/daemon.html) it seems that
`modules = {
hints = '/etc/hosts'
}` is needed in the config (/tmp/kresd.config) but this file is generated automatically by /etc/resolver/dhcp_host_domain_ng.py which does not add it.
I think my bug is that a UI option is not supported by /etc/resolver/dhcp_host_domain_ng.py.
Environment:
Black and a silver Turris Omnias.
LuCI (git-22.115.68448-712bc8e)
TurrisOS 5.4.3 83b0e20711ee4a927634b3c2a018c93527e84a2b r11431+100-83b0e20711https://gitlab.nic.cz/turris/os/packages/-/issues/916broadband provider defaults database2023-03-22T12:44:10+01:00Filip Hronbroadband provider defaults databaseIt is possible to read `MCC` and `MNC` from SIM card. We can automate some queries to make it easier (not to say flawless) to help user to set up his LTE broadband connection.
# Problems
- the source database is in `XML`, we'd rather us...It is possible to read `MCC` and `MNC` from SIM card. We can automate some queries to make it easier (not to say flawless) to help user to set up his LTE broadband connection.
# Problems
- the source database is in `XML`, we'd rather use `JSON` as **turris** devices have the library out of the box (python target)
- we need to do this in build process, we don't want to query some API in case the device is intended to use connection from `LTE` modem
# Solution steps
## Prepare
- narrow down properties to only what is required (filter the source)
- convert to `JSON` file
## Ship
- ship it to all routers
## GUI requirements
- make sure the license is visible on `LTE` **GUI** page
# Extras/question
- validate source `XML` before building against schema provided by source?
# Usage
- `foris-controller`
backref: https://gitlab.nic.cz/turris/project/-/issues/108
### resources:
https://wiki.gnome.org/Projects/NetworkManager/MobileBroadband/ServiceProviders
https://gitlab.gnome.org/GNOME/mobile-broadband-provider-info/-/blob/main/serviceproviders.xmlFilip HronFilip Hronhttps://gitlab.nic.cz/turris/os/packages/-/issues/574Nextcloud RAM usage [esp. on 1 GB RAM devices] disturbing `pkgupdate` to run ...2023-03-03T02:05:55+01:00ChrisPHLNextcloud RAM usage [esp. on 1 GB RAM devices] disturbing `pkgupdate` to run properly.This is kind of follow up of turris/updater/updater#291. I was able to workaround the issue using a workaround that stops the RAM consuming tasks of Nextcloud installation before and start them in reversed order after running the update....This is kind of follow up of turris/updater/updater#291. I was able to workaround the issue using a workaround that stops the RAM consuming tasks of Nextcloud installation before and start them in reversed order after running the update. This can be achieved by installing a pre update hook and post update hook with Nextcloud right away. [I described the fix on my website](https://chpohl.de/?url=projekte/turris_nextcloud_updater_fix/index.htm).
Maybe this could be (part of) an addition to the Nextcloud installation to be more kind in terms of RAM usage. This could be a user option too, I think. Downside: Nextcloud instance is down during update.
Kind regards
Christianhttps://gitlab.nic.cz/turris/os/packages/-/issues/42Add support for Luci configured remote log setting to syslog-ng2023-03-03T02:04:54+01:00Jan PavlinecAdd support for Luci configured remote log setting to syslog-ngMore info at
https://forum.turris.cz/t/remote-log-how-to-configure/992/6
https://github.com/CZ-NIC/turris-os/issues/32More info at
https://forum.turris.cz/t/remote-log-how-to-configure/992/6
https://github.com/CZ-NIC/turris-os/issues/32Turris OS 6.1.0https://gitlab.nic.cz/turris/os/packages/-/issues/742sentinel-certgen: Release with option to force regenerate mailpass2023-03-03T01:54:47+01:00Martin Prudeksentinel-certgen: Release with option to force regenerate mailpassBlocked by turris/sentinel/certgen#14Blocked by turris/sentinel/certgen#14https://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/908Lan ports aren’t accessible for WiFi client if VLAN’s enabled2023-02-15T08:36:45+01:00QuiCkSTaRLan ports aren’t accessible for WiFi client if VLAN’s enabledHi guys, I have a very weird issue which prevents the communication between WiFi clients and clients connected via LAN ports.
This only happens if `VLAN's` are enabled.
```
config interface 'loopback'
option device 'lo'
...Hi guys, I have a very weird issue which prevents the communication between WiFi clients and clients connected via LAN ports.
This only happens if `VLAN's` are enabled.
```
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdbb:d3bf:b681::/48'
config interface 'wan'
option device 'eth2'
option proto 'dhcp'
option ipv6 '1'
config interface 'wan6'
option device '@wan'
option proto 'dhcpv6'
config device 'dev_wan'
option name 'eth2'
config device
option type 'bridge'
option name 'br-devilan'
option ipv6 '0'
option igmp_snooping '1'
list ports 'lan0'
list ports 'lan1'
list ports 'lan2'
config interface 'DEVILAN'
option proto 'static'
option ipaddr '192.168.66.1'
option netmask '255.255.255.0'
option device 'br-devilan.66'
config bridge-vlan
option device 'br-devilan'
option vlan '66'
list ports 'lan0:t'
list ports 'lan1:u*'
list ports 'lan2:u*'
config device
option vid '66'
option ifname 'br-devilan'
option name 'br-devilan.66'
option ipv6 '0'
option type '8021q'
config device
option igmp_snooping '1'
option type 'bridge'
option name 'br-iot'
list ports 'lan3'
list ports 'lan4'
option ipv6 '0'
config interface 'iot'
option device 'br-iot'
option proto 'static'
option netmask '255.255.255.0'
option ipaddr '192.168.33.1'
```
I also have configured corresponding wifi networks.
```
config wifi-device 'radio0'
option type 'mac80211'
option path 'soc/soc:pcie/pci0000:00/0000:00:02.0/0000:02:00.0'
option channel '36'
option band '5g'
option country 'CH'
option cell_density '0'
option htmode 'HE160'
config wifi-device 'radio1'
option type 'mac80211'
option path 'soc/soc:pcie/pci0000:00/0000:00:03.0/0000:03:00.0'
option channel '1'
option band '2g'
option country 'CH'
option cell_density '0'
option htmode 'HT40'
config wifi-iface 'wifinet0'
option ssid 'House of Ping'
option encryption 'psk2'
option device 'radio0'
option mode 'ap'
option network 'DEVILAN'
option key '*******'
config wifi-iface 'wifinet1'
option ssid 'House of Ping'
option encryption 'psk2'
option device 'radio1'
option mode 'ap'
option network 'DEVILAN'
option key '*******'
config wifi-iface 'wifinet2'
option ssid 'iot'
option encryption 'psk2'
option device 'radio1'
option mode 'ap'
option network 'iot'
option key '********'
config wifi-iface 'wifinet3'
option ssid 'iot'
option encryption 'psk2'
option device 'radio0'
option mode 'ap'
option network 'iot'
option key '******'
```
Now here comes the strange part, as long as my clients are connected to the WiFi anything works like a charm, I can connect to clients within the respective vlan.
For example: My desktop is connect via wifi in the `DEVILAN` and gets the IP 192.168.66.54 and can ping my notebook, which is also connected via WiFi and got the IP 192.168.66.55.
If I connect my Notebook directly on port 1 (which untaggs `DEVILAN`) however, I'm unable to communicate with WiFi devices in the same VLAN. I successfully get an IP like 192.168.66.42 and can also access the internet. I can even communicate with other devices on on port 2 (which untaggs `DEVILAN`).
I'm quite sure this must be a bug and is probably somehow related to DSA, what did I miss? Any ideas?
My System:
![Screenshot_from_2023-02-14_23-30-51](/uploads/0d72a41918dc29d842ab7003ca76f29f/Screenshot_from_2023-02-14_23-30-51.png)https://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/885SERVFAIL when looking up some domains2023-01-10T17:29:08+01:00LinAGKarSERVFAIL when looking up some domainsI'm having problems looking up power.se since the update to TurrisOS 6 on my Turris Omnia. When I try to look it up from a PC, I get SERVFAIL, and I if log into the router and try to look it up, it just sits there and eventually times ou...I'm having problems looking up power.se since the update to TurrisOS 6 on my Turris Omnia. When I try to look it up from a PC, I get SERVFAIL, and I if log into the router and try to look it up, it just sits there and eventually times out. It starts working if I disable and reenable DNSSEC, but eventually it stops working again. I'm only seeing this problem for this particular address.Vladimír Čunátvladimir.cunat@nic.czVladimír Čunátvladimir.cunat@nic.czhttps://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.0