Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2023-08-16T14:57:31+02:00https://gitlab.nic.cz/turris/os/packages/-/issues/389UTC time zone absent from Foris2023-08-16T14:57:31+02:00Ghost UserUTC time zone absent from Foris{"kernel":"4.14.113","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta1","revision":"0663455801","target":"mvebu/...{"kernel":"4.14.113","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta1","revision":"0663455801","target":"mvebu/cortexa9","description":"TurrisOS 4.0-beta1 0663455801"}}
___
Whilst available through LuCI the UTC time zone is absent from the Foris
UTC is a fixed time zone that never observes Daylight Saving Time and is not queal to what Foris offers
```
option timezone 'GMT0BST,M3.5.0/1,M10.5.0'
option _country 'GB'
option zonename 'Europe/London'
```Štěpán HenekŠtěpán Henekhttps://gitlab.nic.cz/turris/os/packages/-/issues/388logrotate - maxsize not an applicable option2019-05-15T01:04:31+02:00Ghost Userlogrotate - maxsize not an applicable option{"kernel":"4.14.113","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta1","revision":"0663455801","target":"mvebu\...{"kernel":"4.14.113","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta1","revision":"0663455801","target":"mvebu\/cortexa9","description":"TurrisOS 4.0-beta1 0663455801"}}
___
/etc/logrotate.d/syslog-ng.conf
`maxsize 1M`
does not seem a viable setting according the package documentation, which stipulates either `size` or `minsize` and I would trust that `size` is meant.https://gitlab.nic.cz/turris/os/packages/-/issues/387sysntpd working?2019-06-18T13:15:37+02:00Ghost Usersysntpd working?{"kernel":"4.14.113","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta1","revision":"0663455801","target":"mvebu/...{"kernel":"4.14.113","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta1","revision":"0663455801","target":"mvebu/cortexa9","description":"TurrisOS 4.0-beta1 0663455801"}}
- using `odhcpd` for ipv4 and ipv6
___
forum cross refrence https://forum.turris.cz/t/turris-os-4-0-beta1-is-released/10107/76
I am concerned that `sysntpd` is not working, both client and server.
With the client side, which is most important, there is no indication in the logs that the time is being synchronized with the specified upstream servers, e.g. via /foris/config/main/time/ > Update Time.
Is there any way via cli to run the client and see the output, could not find any pertaining documentation? Or any other way to know that client is working or when last sync happened?
___
With the server side up/running
`ss -tulpn | grep ntp`
> udp UNCONN 0 0 *:123 : users:((“ntpd”,pid=10918,fd=3))
`ntpq -p` is producing
> localhost: timed out, nothing received
> ***Request timed out
In addition the server should not be listening globally but on `dhcp_interface`, if `list interface` is omitted from /etc/config/system then on every interface or else on the specified interface. But apparently it does not.https://gitlab.nic.cz/turris/os/packages/-/issues/382weak password encryption algorithm2019-05-13T13:50:09+02:00Ghost Userweak password encryption algorithmTO | OS4.x beta 1
___
as outlined in https://gitlab.labs.nic.cz/turris/openwrt/issues/255
/etc/login.defs utilizes weak password encryption
> DES-based algorithm will be used for encrypting password (default)
Instead it should be
`E...TO | OS4.x beta 1
___
as outlined in https://gitlab.labs.nic.cz/turris/openwrt/issues/255
/etc/login.defs utilizes weak password encryption
> DES-based algorithm will be used for encrypting password (default)
Instead it should be
`ENCRYPT_METHOD SHA512`https://gitlab.nic.cz/turris/os/packages/-/issues/381ipv6 iface/address inaccessible wihen link state DOWN2019-07-08T11:07:23+02:00Ghost Useripv6 iface/address inaccessible wihen link state DOWNTO | OS4.x beta 1 | router mode installation with medkit
___
Whilst ipv4 ifaces are reachable (`ping` | `traceroute`) their equivalent ipv6 addresses are not when the iface's link status is DOWN (no client connected). Once a client is co...TO | OS4.x beta 1 | router mode installation with medkit
___
Whilst ipv4 ifaces are reachable (`ping` | `traceroute`) their equivalent ipv6 addresses are not when the iface's link status is DOWN (no client connected). Once a client is connected to the iface and the link status changes to UP the iface's ipv6 address becomes reachable - tried this many times and it reproduced the same result eacht time.
Since running most services (e.g. sshd, resolver, lighttpd) on a management iface rather than lan this makes it impossible to bind those services to the respective ipv6 address of the management iface.
connected to the TO via lan iface
`ip -o a show br-lan`
> 22: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000\ link/ether d8:58:d7:00:79:7a brd ff:ff:ff:ff:ff:ff
> 22: br-lan inet 192.168.84.23/24 brd 192.168.84.255 scope global br-lan\ valid_lft forever preferred_lft forever
> 22: br-lan inet6 xxxx:xxxx:6b29:c301:4fec:a3c8:3aac:8eb5/64 scope global dynamic \ valid_lft 78123sec preferred_lft 78123sec
> 22: br-lan inet6 fd30:d64c:1eed:9a9b:3f80:9f6b:48d:96f3/64 scope global \ valid_lft forever preferred_lft forever
> 22: br-lan inet6 fe80::da58:d7ff:fe00:797a/64 scope link \ valid_lft forever preferred_lft forever
and from there trying to reach the management iface
`ip -o a show br-mgt`
> 23: br-mgt: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue **state DOWN** qlen 1000\ link/ether d8:58:d7:00:79:7a brd ff:ff:ff:ff:ff:ff
> 23: br-mgt inet 192.168.112.12/24 brd 192.168.112.255 scope global br-mgt\ valid_lft forever preferred_lft forever
> 23: br-mgt inet6 xxxx:xxxx:6b29:c302:fadb:150a:99c6:deed/64 scope global tentative dynamic \ valid_lft 77865sec preferred_lft 77865sec
> 23: br-mgt inet6 fd30:d64c:1eed:4c3a:db0e:5fb6:97d9:f9e5/64 scope global tentative \ valid_lft forever preferred_lft forever
> 23: br-mgt inet6 fd30:d64c:1eed:4c3a::12/128 scope global tentative \ valid_lft forever preferred_lft forever
which works with *ipv4*
`traceroute 192.168.112.12`
> traceroute to 192.168.112.12 (192.168.112.12), 30 hops max, 38 byte packets
> 1 192.168.112.12 (192.168.112.12) 0.011 ms 0.009 ms 0.008 ms
but fails with ipv6
`traceroute fd30:d64c:1eed:4c3a::12`
> traceroute to fd30:d64c:1eed:4c3a::12 (fd30:d64c:1eed:4c3a::12), 30 hops max, 64 byte packets
> 1 fd30:d64c:1eed:9a9b:3f80:9f6b:48d:96f3 (fd30:d64c:1eed:9a9b:3f80:9f6b:48d:96f3) 3138.885 ms !H 3129.493 ms !H 3109.975 ms !H
___
The management iface appaears to be UP, indicated by the reachability over ipv4 and also running `ip l show up | grep mgt` or `ifstatus mgt` or `ubus list network.interface.*`.
However, `dmesg | grep mgt` produces
> [ 21.372098] IPv6: ADDRCONF(NETDEV_UP): br-mgt: link is not ready
> [ 21.402853] br-mgt: port 1(lan3) entered blocking state
> [ 21.408109] br-mgt: port 1(lan3) entered disabled state
This seems rather curious/odd, ipv4 netdev is reachable whilst ipv6 netdev is not, unless a client gets connected and the link state changes to UP.
The issue is not present in TOS3.11.4https://gitlab.nic.cz/turris/os/packages/-/issues/379sysctl.d redundant/conflicting net.netfilter.nf_conntrack entries2019-05-13T13:54:51+02:00Ghost Usersysctl.d redundant/conflicting net.netfilter.nf_conntrack entriesTO | OS4.x beta 1
compare /etc/sysctl.d/10-default.conf
```
net.nf_conntrack_max = **262144**
net.netfilter.nf_conntrack_tcp_timeout_established = **432000**
net.netfilter.nf_conntrack_udp_timeout=60
net.netfilter.nf_conntrack_udp_timeo...TO | OS4.x beta 1
compare /etc/sysctl.d/10-default.conf
```
net.nf_conntrack_max = **262144**
net.netfilter.nf_conntrack_tcp_timeout_established = **432000**
net.netfilter.nf_conntrack_udp_timeout=60
net.netfilter.nf_conntrack_udp_timeout_stream=180
net.netfilter.nf_conntrack_checksum=**1**
```
versus /etc/sysctl.d/11-nf-conntrack.conf
```
net.netfilter.nf_conntrack_checksum=**0**
net.netfilter.nf_conntrack_max=**16384**
net.netfilter.nf_conntrack_tcp_timeout_established=**7440**
net.netfilter.nf_conntrack_udp_timeout=60
net.netfilter.nf_conntrack_udp_timeout_stream=180
```
entries are redundant and values even conflicting (**)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/376odhcpd not listening on udp port 672019-05-13T10:02:43+02:00Ghost Userodhcpd not listening on udp port 67TOS 4 beta 1
with
/etc/config/dhcp
```
config odhcpd 'odhcpd'
option maindhcp '1'
```
it would be expected that `odhcpd` is listening on udp port 67 in order to serve ipv4 dhcp queries, with `dnsmasq` stopped/disabled/removed, but i...TOS 4 beta 1
with
/etc/config/dhcp
```
config odhcpd 'odhcpd'
option maindhcp '1'
```
it would be expected that `odhcpd` is listening on udp port 67 in order to serve ipv4 dhcp queries, with `dnsmasq` stopped/disabled/removed, but it does not.
The issue is not present however in TOS 3.11.4 and `odhcpd` is working expected, i.e. serving ipv4 dhcp queries on udp port 67.https://gitlab.nic.cz/turris/os/packages/-/issues/375dhcp (odhcp settings) file being deleted when uninstalling dnsmasq2019-05-04T20:41:15+02:00Ghost Userdhcp (odhcp settings) file being deleted when uninstalling dnsmasqTOS 4 beta 1
with:
/etc/updater/conf.d/user.lua
`Uninstall("dnsmasq-full")`
and then running `pkgupdate` the file /etc/config/dhcp is being wiped and thus also the settings pertaining to `odhcpd`.
This is not expected and should not ...TOS 4 beta 1
with:
/etc/updater/conf.d/user.lua
`Uninstall("dnsmasq-full")`
and then running `pkgupdate` the file /etc/config/dhcp is being wiped and thus also the settings pertaining to `odhcpd`.
This is not expected and should not happen in any event.https://gitlab.nic.cz/turris/os/packages/-/issues/372postinst of foris-controller-netmetr-module runs netmetr2019-05-21T15:33:47+02:00Vojtech Myslivecpostinst of foris-controller-netmetr-module runs netmetrnetmetr is run after installation of `foris-controller-netmetr-module` package which blocks and slows down an update process.netmetr is run after installation of `foris-controller-netmetr-module` package which blocks and slows down an update process.https://gitlab.nic.cz/turris/os/packages/-/issues/371deckard-gui: create deckart gui in foris2023-08-16T14:49:11+02:00Jan Pavlinecdeckard-gui: create deckart gui in foriscreate deckart GUI in foris.create deckart GUI in foris.Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/368emergingthreats: create new package for surricata2019-04-26T15:53:48+02:00Jan Pavlinecemergingthreats: create new package for surricataThis package should contain https://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz since it's used in ludus https://github.com/stratosphereips/Ludus/blob/master/install.py#L65
Related to issue https://gitlab.labs.nic.cz/t...This package should contain https://rules.emergingthreats.net/open/suricata/emerging.rules.tar.gz since it's used in ludus https://github.com/stratosphereips/Ludus/blob/master/install.py#L65
Related to issue https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/358Jan 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/361[note to dev] Unbound repositories moving to GitHub on 1 May 20192019-04-24T11:12:16+02:00Ghost User[note to dev] Unbound repositories moving to GitHub on 1 May 2019> We are excited to announce that on the 1st of May 2019, we will migrate
> the NSD and Unbound repositories to git and use GitHub for maintaining
> them. We are also going to use the GitHub infrastructure to manage tasks
> and community...> We are excited to announce that on the 1st of May 2019, we will migrate
> the NSD and Unbound repositories to git and use GitHub for maintaining
> them. We are also going to use the GitHub infrastructure to manage tasks
> and community contributions, collect user feedback and allow you to
> report software bugs.
>
> This means that on 1 May 2019, the following will happen for the NSD and
> Unbound projects:
>
> - Our SVN repositories will be made unavailable by replacing the
> contents of the SVN trunk with a single document pointing to GitHub
> - Bugzilla, our bug-tracking system, will be switched to read-only
> - We will accept contributions via a pull request on GitHub
> - Feature requests and bug reports should be submitted via GitHub issues
>
> This change is part of an ongoing effort to unify the experience for our
> community. Over the next weeks and months, all projects that NLnet Labs
> manages will be migrated. We are convinced that GitHub offers the best
> platform to cater to the needs of both our community and our developers.
>
> If you would like to get a head start, you can already start using
> GitHub for the NSD[0] and Unbound[1] projects today.
>
> Regards,
> Ralph
>
> [0] - https://github.com/nlnetlabs/nsd
> [1] - https://github.com/nlnetlabs/unboundhttps://gitlab.nic.cz/turris/os/packages/-/issues/354lxc: unable to run systemd container2019-12-10T16:03:58+01:00Karel Kocilxc: unable to run systemd containerSystemd based containers such as Debian are failing with following error:
```
lxc-start: debian: utils.c: safe_mount: 1707 No such file or directory - Failed to mount /usr/lib/lxc/rootfs/proc/tty onto /usr/lib/lxc/rootfs/proc/sys/net
...Systemd based containers such as Debian are failing with following error:
```
lxc-start: debian: utils.c: safe_mount: 1707 No such file or directory - Failed to mount /usr/lib/lxc/rootfs/proc/tty onto /usr/lib/lxc/rootfs/proc/sys/net
Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
```
```
lxc-start: opensuse: utils.c: safe_mount: 1707 No such file or directory - Failed to mount /usr/lib/lxc/rootfs/proc/tty onto /usr/lib/lxc/rootfs/proc/sys/net
Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
```
I suspect that we don;t have appropriate kernel configuration.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/352rescue-mode-omnia: set the bootable flag on created mmc partition2023-08-16T14:38:02+02:00Pierre Bourdonrescue-mode-omnia: set the bootable flag on created mmc partitionI have a dream: using a completely upstream u-boot on my Turris Omnia one day :-)
The standard u-boot distribution looks for the bootable flag on partitions to determine whether it should try to boot from there. Adding the bootable flag...I have a dream: using a completely upstream u-boot on my Turris Omnia one day :-)
The standard u-boot distribution looks for the bootable flag on partitions to determine whether it should try to boot from there. Adding the bootable flag when reflashing a medkit seems like a very low risk and easy change: just add an "a" before the "p" here: https://gitlab.labs.nic.cz/turris/turris-os-packages/blob/ef0c02b7f39c23c1ebffc6f04db1e7edd47cfb2e/cznic/rescue-mode-omnia/files/rescue.sh#L130
I would have sent a PR but can't figure out how to do that on your gitlab. Could someone take care of this? Any objections?https://gitlab.nic.cz/turris/os/packages/-/issues/350various vulnerabilities in hostapd2019-04-11T14:16:07+02:00Ghost Uservarious vulnerabilities in hostapdhttps://github.com/openwrt/openwrt/commit/262229e9248a5235844cdab6bb87fcb77b359b30
https://github.com/openwrt/openwrt/commit/57ab9e3add0f10795b7db5b1f3d1b2eb9b8f92c9
https://github.com/openwrt/openwrt/commit/8f17c019a19f1d0a50e649e...https://github.com/openwrt/openwrt/commit/262229e9248a5235844cdab6bb87fcb77b359b30
https://github.com/openwrt/openwrt/commit/57ab9e3add0f10795b7db5b1f3d1b2eb9b8f92c9
https://github.com/openwrt/openwrt/commit/8f17c019a19f1d0a50e649e81dab9d8f74ad7efbhttps://gitlab.nic.cz/turris/os/packages/-/issues/346unbound version bump 1.9.12019-04-05T09:47:11+02:00Ghost Userunbound version bump 1.9.1Unbound 1.9.1 is available:
https://www.nlnetlabs.nl/downloads/unbound/unbound-1.9.1.tar.gz
sha256 c3c0bf9b86ccba4ca64f93dd4fe7351308ab54293f297a67de5a8914c1dc59c5
pgp https://www.nlnetlabs.nl/downloads/unbound/unbound-1.9.1.tar...Unbound 1.9.1 is available:
https://www.nlnetlabs.nl/downloads/unbound/unbound-1.9.1.tar.gz
sha256 c3c0bf9b86ccba4ca64f93dd4fe7351308ab54293f297a67de5a8914c1dc59c5
pgp https://www.nlnetlabs.nl/downloads/unbound/unbound-1.9.1.tar.gz.asc
> This release contains bug fixes for two issues in the out of order
> processing introduced in 1.9.0, one where the wrong answer was returned
> and a crash bug in file descriptor handling.
>
> There is also a fix for qname minimisation, that could have skipped a
> label-fetch-step when it should not have. This was caused by certain
> recursion situations and the subsequent qname minimisation continuation.
> Qname minimisation in Unbound is designed to sometimes add several
> labels at a time, instead of just adding one label at a time and
> performing lookups until the full qname is reached, because certain
> names are very long, especially in the IPv6 reverse space. Unbound
> performs short steps near the top, in root and TLDs, but then makes
> longer label add steps when the name is very long, near the left side of
> the qname. This is to keep the lookup latency short.
>
> A new type of local-zone is added, inform_redirect, this acts like both
> type inform and type redirect are both used. The answer is logged and
> the content of the answer is like type redirect.
>
> For 0x20 capsforid, a canonical sort is used to compare faulty replies.
> This removes some cases where the fallback could not figure out the
> reply is genuine in several retries.
>
> To make ratelimiting easier, the ratelimit logs print the query name
> that triggered the ratelimit message. Not all query names are
> supposedly the same, but the query name of the query that made the
> ratelimit exceed is printed, and this gives (a single name of) insight
> into the nature of the traffic employed. Also the IP-address of the
> sender of the query that triggered the upstream ratelimit is printed.
> If a recursion exceeds ratelimit, it does not print the IP-address of
> the query ultimately responsible for the recursive lookup.
>
> Unbound has ratelimiting for both the clients (the downstream side) and
> for traffic sent by unbound to the wider internet (the upstream side).
> The ip-ratelimit options limit traffic in packets per client IP. The
> ratelimit options limit traffic towards a domain name. The new logging
> prints extra information with the log messages for both of them, so that
> an inkling of information on some of that traffic is visible straight away.
>
>
> Features
> - Add local-zone type inform_redirect, which logs like type inform,
> and redirects like type redirect.
> - Perform canonical sort for 0x20 capsforid compare of replies,
> this sorts rrsets in the authority and additional section before
> comparison, so that out of order rrsets do not cause failure.
> - Print query name with ip_ratelimit exceeded log lines.
> Spaces instead of tabs in that log message.
> - Print query name and IP address when domain rate limit exceeded.
>
> Bug Fixes
> - Fix #4224: auth_xfr_notify.rpl test broken due to typo
> - Fix locking for libunbound context setup with broken port config.
> - Fix case in which query timeout can result in marking delegation
> as edns_lame_known.
> - Set ub_ctx_set_tls call signature in ltrace config file for
> libunbound in contrib/libunbound.so.conf.
> - improve documentation for tls-service-key and forward-first.
> - #10: fixed pkg-config operations, PKG_PROG_PKG_CONFIG moved out of
> conditional section, fixes systemd builds, from Enrico Scholz.
> - #9: For openssl 1.0.2 use the CRYPTO_THREADID locking callbacks,
> still supports the set_id_callback previous API. And for 1.1.0
> no locking callbacks are needed.
> - #8: Fix OpenSSL without ENGINE support compilation.
> - Wipe TLS session key data from memory on exit.
> - Fix that log-replies prints the correct name for local-alias
> names, for names that have a CNAME in local-data configuration.
> It logs the original query name, not the target of the CNAME.
> - Fix #4206: OpenSSL 1.0.2 hostname verification for FreeBSD 11.2.
> - Fix that qname minimisation does not skip a label when missing
> nameserver targets need to be fetched.
> - Fix #4225: clients seem to erroneously receive no answer with
> DNS-over-TLS and qname-minimisation.
> - Note default for module-config in man page.
> - Fix #13: Remove left-over requirements on OpenSSL >= 1.1.0 for
> cert name matching, from man page.
> - Fix capsforid canonical sort qsort callback.
> - Fix pythonmod include and sockaddr_un ifdefs for compile on
> Windows, and for libunbound.
> - Fix the error for unknown module in module-config is understandable,
> and explains it was not compiled in and where to see the list.
> - In example.conf explain where to put cachedb module in module-config.
> - In man page and example config explain that most modules have to
> be listed at the start of module-config.
> - Fix #4227: pair event del and add for libevent for tcp_req_info.
> - Fix #4229: Unbound man pages lack information, about access-control
> order and local zone tags, and elements in views.
> - Fix #14: contrib/unbound.init: Fix wrong comparison judgment
> before copying.
> - Fix for python module on Windows, fix fopen.
> - Remove memory leak on pythonmod python2 script file init.
> - Remove swig gcc8 python function cast warnings, they are ignored.
> - Print correct module that failed when module-config is wrong.https://gitlab.nic.cz/turris/os/packages/-/issues/344Migration from 3.x to 5.x2023-08-16T14:49:13+02:00Karel KociMigration from 3.x to 5.xThere were some configuration changes in OpenWRT in meantime and we should implement script that migrates those primary settings
* [x] Switch configuration is now done using DSA and switch sections are obsolete. We have to migrate them....There were some configuration changes in OpenWRT in meantime and we should implement script that migrates those primary settings
* [x] Switch configuration is now done using DSA and switch sections are obsolete. We have to migrate them.
* [ ] ~~Create new bridge interface for VLANs without CPU port assigned.~~ (won't be implemented unless wide deployment with such config is discovered)
* [x] Updater configuration and userlists to pkglists
* [x] Wifi paths migration (`option path 'soc/soc:pcie-controller/pci0000:00/0000:00:01.0/0000:01:00.0'` vs `option macaddr '04:f0:21:1c:b7:52'`)
* [x] Detect and select sfp
Known problems:
* [x] update takes a long time because ubus seems to be timing out. I is enough to kill `ubusd` when new version is installed.
* [x] base-files with `/etc/services_wanted` is updated later in update and because of that some services (syslog-ng, dnsmasq, ...) are not activated. turris/turris-build@154d9217)
* [x] some services like lighttpd and mysql are ordered before ubus update do they postinst scripts are hanging (on procd timeout) (solution: turris/updater/updater#137)
* [x] services are still not enabled even with fix from previous line (solution: turris/updater/updater#273)
* [x] after migration Foris reports LAN and guest as to not contain any interface. This is because it expects `ifname` as list not option.
* [x] region country is not set in Foris. This is because of missing `system[0]._country` option but do we care? (this is because it wasn't set in 3.x. If set then it is correctly carried over)
* [x] nextcloud does not work after update. Website is empty. (turris/turris-os-packages#431)
* [x] single interface in network should be `option` not `list` otherwise wan dhcp proto does not work (turris/turris-os-packages@a9ec3c8b)
* [x] knot resolver is unreachable for some reason (problem was in loopback not having interface)
* [ ] `/etc/config/fstab` field `uuid` now really uses `UUID` and not `subuuid` (SUBUUID drives are not mounted. We should replace SUBUUIDs with UUIDs) (~Unconfirmed)
* [x] User installed packages that are no longer available in 4.0+ should be removed/disabled somehow or we should not initialize update. (turris/turris-build!59, turris/turris-build!107)
* [x] updater is unable to found localrepo repositories (turris/turris-os-packages!168)
* [x] localrepo contains invalid packages (we should just flush localrepo and inform user about it)
* [x] localrepo fix to move it away does not work sometimes (turris/turris-os-packages!374)
* [x] LXC is not reportedly migrated (but script itself works as users suggesting them self to run it manually) (turris/turris-os-packages!369)
* [x] Turris 1.x currently can't be migrated because of dependency loop on `updater-ng` package (turris/turris-build!183, turris/turris-build!187)
* [ ] Scary message about removal of `turris-btrfs` is send to users of Turris 1.x because of rename of that package (~Low probably won't fix)
* [x] Migration breaks (with broken libraries) because of turris/turris-os-packages!417 if package depending on `knot-libs` is installed (resolved by turris/turris-build!196)
* [x] Some swconfig configuration might stay in place (we might be ignoring it) and it can cause problems with system without swconfig (commands failing) (resolved by turris/turris-os-packages!383)
* [x] Notify users about finished migration (probably on tos3to4 package removal) (turris/turris-os-packages!380)
* [x] Wireguard `DEVICE_CLAIM_FAILED` error after migration (turris/turris-os-packages#696 turris/turris-os-packages#697)
* [x] Alternatives are not updated after migration as well as on Turris 1.x new version of kernel is not as well (turris/updater/updater#309 turris/turris-os-packages#678)
* [x] After migration router has no LAN as switch config is removed and DSA is not yet deployed (we have to do reboot) (turris/os/build!421)
* [x] Updater settings migration fails for some reason and we are with old version (turris/os/build!421)
* [x] Package lists are not migrated as format changed and fix script is not installed during migration (turris/os/build!421)
* [ ] When approvals are enabled the migration won't trigger right after installation of `tos3to4` but with next run (~Low and probably won't fix)
Test:
* [x] basic network configuration (switch, bridges, ..)
* [x] guest wifi and network configuration
* [x] firewall rules
* [x] DNS configuration
* [ ] openvpn
* [x] pakon
* [x] storage plugin
* [x] lxc
* [ ] haas (honeypot as a service)
* [x] netmetr
* [x] nextcloud
* [x] localrepo
* [ ] dev detect (migration from pakon-dev-detect to dev-detect)
* [ ] mwan
Things to notify users about:
* Updater approvals are disabled for this migration to mitigate possibility that because of link dependencies the approve would be impossible to give. Notification about it is send to notification system once user installs `tos3to4` on Turris OS 3.x.
* Updater is reported as disabled during update.Turris OS 3.x migrationhttps://gitlab.nic.cz/turris/os/packages/-/issues/342luci-app-wireguard: status fail to load; JavaScript error TypeError: String.f...2022-02-16T16:59:48+01:00David Beiteyluci-app-wireguard: status fail to load; JavaScript error TypeError: String.format is not a functionLoading the Wireguard status page in LuCI has worked at least once in the past, but now shows a screen stating "Collecting data...". In JavaScript, the page is making XHR requests but data processing is failing because of the following ...Loading the Wireguard status page in LuCI has worked at least once in the past, but now shows a screen stating "Collecting data...". In JavaScript, the page is making XHR requests but data processing is failing because of the following error:
```
TypeError: String.format is not a function wireguard:74:21
<anonymous> /cgi-bin/luci/admin/status/wireguard:74
onreadystatechange /luci-static/resources/xhr.js?v=git-18.328.59464-9636605:72
```
and this error occurs every few seconds as continued XHRs take place.
The issue appears to be that the JS function `String.format` from ` /www/luci-static/resources/cbi.js` isn't being loaded on this page and is thus null, causing the error. Looking into the JS that is loaded and only `xhr.js` (in the traceback above) and the inline JS on the HTML page are what's present.
I don't know the internals of LuCI or its pages, but manually defining that `String.format` function sees the rest of the page work as a test.
I'm on Turris Omnia `v3.11.2` with luci-app-wireguard version `git-18.328.59464-9636605-1`