Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2022-02-16T16:59:48+01:00https://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`https://gitlab.nic.cz/turris/os/packages/-/issues/341ddns: writes ever 10 min to emmc2019-05-06T17:21:48+02:00Jan Pavlinecddns: writes ever 10 min to emmcIt is probably related to usage of HSTS (affected 3.x TO)
https://forum.turris.cz/t/ddns-hsts-writes-to-mmcblk0p1-every-10-minutes/9745It is probably related to usage of HSTS (affected 3.x TO)
https://forum.turris.cz/t/ddns-hsts-writes-to-mmcblk0p1-every-10-minutes/9745Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/328luci-app-ddns: Update to upstream to improve LuCI performance2019-05-08T17:07:08+02:00David Beiteyluci-app-ddns: Update to upstream to improve LuCI performanceUpdating `luci-app-ddns` was originally mentioned in https://forum.turris.cz/t/set-persistent-nameserver-entries-in-etc-resolv-conf/8926/ where I dug into why LuCI was making 1000s of DNS requests.
The short answer to that is because of...Updating `luci-app-ddns` was originally mentioned in https://forum.turris.cz/t/set-persistent-nameserver-entries-in-etc-resolv-conf/8926/ where I dug into why LuCI was making 1000s of DNS requests.
The short answer to that is because of the `luci-app-ddns` package, because LuCI’s dispatcher imports all controllers for every request that gets made to LuCI. Turns out that the DDNS controller `ddns.lua` gets imported for every request which means its `has_nslookup` check got called each time. This made a DNS request for localhost, which by design, does not use `/etc/hosts`, thus querying the DNS server.
My PR to LuCI upstream at https://github.com/openwrt/luci/pull/2384 to fix this issue was merged a while ago and the app itself has had a significant restructuring for performance compared to its version on Turris OS (https://github.com/openwrt/luci/commits/master/applications/luci-app-ddns).
So, since the performance benefits of these changes actually affect _all_ of LuCI, can `luci-app-ddns` be updated in 3.11.x? Thanks.Turris OS 3.11.4https://gitlab.nic.cz/turris/os/packages/-/issues/313nut-driver-apcsmart is missing2022-02-16T17:00:28+01:00Josef Schlehofernut-driver-apcsmart is missingIn our latest releases (Turris OS 3.11.x), we don't have package nut-driver-apcsmart, which we had in past (Turris OS 3.10.x). This package is available in Turris OS 4.x.In our latest releases (Turris OS 3.11.x), we don't have package nut-driver-apcsmart, which we had in past (Turris OS 3.10.x). This package is available in Turris OS 4.x.https://gitlab.nic.cz/turris/os/packages/-/issues/312openssh client fails to listen on ipv6 socket at boot time2019-05-15T09:35:01+02:00Ghost Useropenssh client fails to listen on ipv6 socket at boot timeobserved on 3.11.2 & 3.11.3 RC | `dnsmasq` removed and `odchpd` acting as sole dhcp server for both ipv4 and ipv6
___
```
config interface 'foo'
option type 'bridge'
option proto 'static'
option ifname 'eth2.3'
option ipaddr '192.16...observed on 3.11.2 & 3.11.3 RC | `dnsmasq` removed and `odchpd` acting as sole dhcp server for both ipv4 and ipv6
___
```
config interface 'foo'
option type 'bridge'
option proto 'static'
option ifname 'eth2.3'
option ipaddr '192.168.112.12'
option netmask '255.255.255.0'
option macaddr 'd8:58:d7:00:87:5c'
list ip6addr 'fd30:d64c:1eed:4c3a::12'
```
```
config openssh
option AddressFamily any
list ListenAddress 192.168.112.12
list ListenAddress fd30:d64c:1eed:4c3a::12
```
___
upon system boot `sshd` has the ipv4 socket up but not the ipv6 socket. Once the system is fully booted the ipv6 socket for sshd becomes available *only after manually restarting/reloading* `sshd`
This likely being caused by `sshd` starting prior the releated ipv6 iface (foo) is fully up. Supposedly `sshd` should only start after the target iface is fully online.https://gitlab.nic.cz/turris/os/packages/-/issues/309ddns-scripts: ERROR : IP update not accepted by DDNS Provider2022-02-16T17:00:46+01:00Darshaka Pathiranaddns-scripts: ERROR : IP update not accepted by DDNS ProviderUpdating the IP reports an error, but the update itself is successful:
```
123228 : Waiting 600 seconds (Check Interval)
124228 : Detect registered/public IP
124228 : #> /bin/nslookup myexample.ddnss.org >/var/run/...Updating the IP reports an error, but the update itself is successful:
```
123228 : Waiting 600 seconds (Check Interval)
124228 : Detect registered/public IP
124228 : #> /bin/nslookup myexample.ddnss.org >/var/run/ddns/myddns_ipv4.dat 2>/var/run/ddns/myddns_ipv4.err
124228 : Registered IP '213.xx.xx.84' detected
124228 info : Rerun IP check at 2019-01-22 12:42
124228 : Detect local IP on 'network'
124228 : Local IP '213.xx.xx.84' detected on network 'wan'
124228 : Forced Update - L: '213.xx.xx.84' == R: '213.xx.xx.84'
124228 : #> /usr/bin/curl -RsS -o /var/run/ddns/myddns_ipv4.dat --stderr /var/run/ddns/myddns_ipv4.err --noproxy '*' 'http://ip4.ddnss.de/upd.php?user=myusername&pwd=***PW***&host=myexample.ddnss.org&ip=213.xx.xx.84'
124229 : DDNS Provider answered:
<head>
<meta name="robots" content="noindex">
<title>DDNSS - Kostenloser DynDNS Service : Re-ProutDNS v5.01v</title>
</head>
<body>
<p><font face="Verdana" size="2"></font></p>
<p><font face="Verdana" size="2">Updated 1 hostname.</font></p>
</body>
124229 ERROR : IP update not accepted by DDNS Provider
124229 : Waiting 600 seconds (Check Interval)
```
I've created an upstream issue: https://github.com/openwrt/packages/issues/8013
I am not sure, if this can be fixed on our side until it is fixed on upstream.https://gitlab.nic.cz/turris/os/packages/-/issues/308provide dependant for open-plc-utils-mdiogen2019-07-08T11:07:17+02:00Ghost Userprovide dependant for open-plc-utils-mdiogenWith `open-plc-utils-mdiogen` available in the TOS 3.11.2 repo its dependant is missing however
> ERROR:
> inconsistent: Package open-plc-utils-mdiogen *requires package open-plc-utils that is not available*.With `open-plc-utils-mdiogen` available in the TOS 3.11.2 repo its dependant is missing however
> ERROR:
> inconsistent: Package open-plc-utils-mdiogen *requires package open-plc-utils that is not available*.https://gitlab.nic.cz/turris/os/packages/-/issues/307logread wrapper for LuCI packages2019-07-22T19:59:57+02:00Josef Schlehoferlogread wrapper for LuCI packagesI'm in touch with @dibdot and he said that Turris OS 4.x still doesn't have a wrapper for logread, which means e.g. **System Log** tab in LuCI is empty. He sent me a small [wrapper](/uploads/d13fb9996193f517aca3cda69dd8f325/logread), whi...I'm in touch with @dibdot and he said that Turris OS 4.x still doesn't have a wrapper for logread, which means e.g. **System Log** tab in LuCI is empty. He sent me a small [wrapper](/uploads/d13fb9996193f517aca3cda69dd8f325/logread), which we can re-use and copy it to /sbin. :-)
For now, I'm thinking about these solutions:
* add a dependency for syslog-ng to logread
* add logread to files in sys-log and copy it to /sbin
* and maybe more coming later?
I think this could also solve issues like this:
https://forum.turris.cz/t/logread-broken/1181/ (reproducible on Turris Omnia, TOS 3.11.2)
https://forum.turris.cz/t/combination-of-syslog-ng-luci-system-logging-configuration-mwan3/5975Turris OS 3.11.3https://gitlab.nic.cz/turris/os/packages/-/issues/305nextcloud (15.0.2) occ command broken due to missing php on PATH2022-02-16T17:01:02+01:00cmacq2nextcloud (15.0.2) occ command broken due to missing php on PATHThe `occ` script to manage the nextcloud from the command line has the following shebang: `#!/usr/bin/env php`
Checking over SSH, `$PATH` is set to: `/usr/bin:/usr/sbin:/bin:/sbin` and `which php` cannot find a `php` executable.
A fix c...The `occ` script to manage the nextcloud from the command line has the following shebang: `#!/usr/bin/env php`
Checking over SSH, `$PATH` is set to: `/usr/bin:/usr/sbin:/bin:/sbin` and `which php` cannot find a `php` executable.
A fix could be to add symlink: `ln -s /usr/bin/php-cli /usr/bin/php`.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/304nextcloud (15.0.2) lighttpd configuration broken2021-11-08T09:26:29+01:00cmacq2nextcloud (15.0.2) lighttpd configuration brokenUpgraded nextcloud from 14.06 to 15.02. The security check now complains about a missing `Referrer-Policy` header when, in fact, two `Referrer-Policy` headers are sent by the server.
It looks like as of 15.02 the previous fix for `/etc/...Upgraded nextcloud from 14.06 to 15.02. The security check now complains about a missing `Referrer-Policy` header when, in fact, two `Referrer-Policy` headers are sent by the server.
It looks like as of 15.02 the previous fix for `/etc/lighttpd/conf.d/nextcloud` to add this header is no longer applicable:
```
alias.url += ( "/nextcloud" => "/srv/www/nextcloud" )
$HTTP["url"] =~ "^/nextcloud" {
# Add 'X-Frame-Options' header, making sure it the website is not embedded in a frame or iframe.
# This avoids clickjacking, and might be helpfull for HTTPS websites
# As frames are not used nowadays, this should be safe to enable at least SAMEORIGIN
# Other option might be DENY or ALLOW-FROM. DENY is not used as frame is used in some old LuCI modules
#setenv.add-response-header += ( "X-Frame-Options" => "SAMEORIGIN")
setenv.add-response-header += ( "Referrer-Policy" => "no-referrer")
}
$HTTP["url"] =~ "^/nextcloud/(build|tests|config|lib|3rdparty|templates|data)" {
url.access-deny = ("")
}
```
Should now probably be:
```
alias.url += ( "/nextcloud" => "/srv/www/nextcloud" )
$HTTP["url"] =~ "^/nextcloud/(build|tests|config|lib|3rdparty|templates|data)" {
url.access-deny = ("")
}
```https://gitlab.nic.cz/turris/os/packages/-/issues/293nextcloud installation failing due to missing dependant perlbase-utf82023-08-01T11:53:49+02:00Ghost Usernextcloud installation failing due to missing dependant perlbase-utf8Reported in [TO forum](https://forum.turris.cz/t/nextcloud-error-installation/8765) the NC installation fails apparently due to missing the dependant `perlbase-utf8`. Installing `perlbase-utf8` appears to resolve the issue.
![c8ae1b7dfa...Reported in [TO forum](https://forum.turris.cz/t/nextcloud-error-installation/8765) the NC installation fails apparently due to missing the dependant `perlbase-utf8`. Installing `perlbase-utf8` appears to resolve the issue.
![c8ae1b7dfaf4a3d01899081fbba946600486481e](/uploads/3eec960bf39467c8588553ed16913f0f/c8ae1b7dfaf4a3d01899081fbba946600486481e.png)Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/291static route not being applied when a four 8-bit octets ipv4 subnet mask is set2019-06-05T19:03:24+02:00Ghost Userstatic route not being applied when a four 8-bit octets ipv4 subnet mask is setTOS 3.11.1
Adding a static subnet route via LuCI or ssh file edit the route is not applied when a subnet mask is set via four 8-bit octets. The route however is applied if the netmask is omitted and 255.255.255.255 is assumed and thus m...TOS 3.11.1
Adding a static subnet route via LuCI or ssh file edit the route is not applied when a subnet mask is set via four 8-bit octets. The route however is applied if the netmask is omitted and 255.255.255.255 is assumed and thus makes the target subnet a host address instead of a subnet.
According to the [upstream documentation](https://openwrt.org/docs/guide-user/network/routes_configuration) the syntax for subnets in ipv4 and ipv6 differs and yet seems that the ipv4 subnet mask for the target network receives the same parsing treatment as ipv6, i.e not as four 8-bit octets but its equivalent integer.
Not working (though it would be expected)
```
config route
option interface 'foobar'
option target 'ip'
option gateway 'ip'
option netmask ‘255.255.255.0’
```
Working instead (which is rather unexpected)
```
config route
option interface 'foobar'
option target 'ip/24'
option gateway 'ip'
```
Not sure whether it is a bug or by design and latter not having made into the documentation.
TO forum cross reference https://forum.turris.cz/t/static-route-not-applied/8525https://gitlab.nic.cz/turris/os/packages/-/issues/290provide dependant for luci-app-wifischedule2019-05-14T18:50:05+02:00Ghost Userprovide dependant for luci-app-wifischeduleWith `luci-app-wifischedule` available in the TOS 3.11.1 repo [its dependant](https://github.com/openwrt/packages/tree/openwrt-18.06/net/wifischedule) is missing however
> ERROR:
> inconsistent: Package luci-app-wifischedule requires pa...With `luci-app-wifischedule` available in the TOS 3.11.1 repo [its dependant](https://github.com/openwrt/packages/tree/openwrt-18.06/net/wifischedule) is missing however
> ERROR:
> inconsistent: Package luci-app-wifischedule requires package wifischedule that is not available.Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/289ntpd package collision with busybox-ntpd2019-07-31T14:23:31+02:00Ghost Userntpd package collision with busybox-ntpdhappning since TOS 3.11
according to [upstream documentation](https://openwrt.org/docs/guide-user/services/ntp/client-server) and since both, upstream and downstream, repos featuring/serving the [ntpd package](https://downloads.openwrt....happning since TOS 3.11
according to [upstream documentation](https://openwrt.org/docs/guide-user/services/ntp/client-server) and since both, upstream and downstream, repos featuring/serving the [ntpd package](https://downloads.openwrt.org/releases/18.06.1/packages/arm_cortex-a9/packages/ntpd_4.2.8p11-1_arm_cortex-a9.ipk) it would be expected to be able to install said package. However, which worked prior to TOS 3.11 is now producing:
> INFO:Checking for file collisions between packages
> line not found
> line not found
> line not found
> line not found
> line not found
> line not found
> DIE:
> [string "transaction"]:323: [string "transaction"]:149: **Collisions**:
> • /sbin/ntpd: busybox (existing-file), ntpd (new-file)
> Aborted
[cross reference TO forum](https://forum.turris.cz/t/installing-ntpd-on-turrisos/8912/3)https://gitlab.nic.cz/turris/os/packages/-/issues/285provide package from upstream for running unpriviliged lxc containers on the TO2019-06-05T18:48:15+02:00Ghost Userprovide package from upstream for running unpriviliged lxc containers on the TOApparently [this package](https://downloads.openwrt.org/releases/18.06.1/packages/arm_cortex-a9/packages/lxc-unprivileged_2.1.1-2_arm_cortex-a9.ipk) being essential for running unprivilged containers on OpenWRT, however it appears absent...Apparently [this package](https://downloads.openwrt.org/releases/18.06.1/packages/arm_cortex-a9/packages/lxc-unprivileged_2.1.1-2_arm_cortex-a9.ipk) being essential for running unprivilged containers on OpenWRT, however it appears absent from the TO repo.
cross reference https://patchwork.ozlabs.org/patch/844848/
It would nessessitate an up to date shadow package https://patchwork.ozlabs.org/patch/837829/ for newgidmap and newuidmap mapping.https://gitlab.nic.cz/turris/os/packages/-/issues/283lxc.utsname not being parsed into container's hostname2019-05-06T17:21:52+02:00Ghost Userlxc.utsname not being parsed into container's hostnameWith the container's config `lxc.utsname = foobar` it would be expected that the container's hostname would be matching `foobar` (parsed into hostname file of the respective container).
However, having tested various container installat...With the container's config `lxc.utsname = foobar` it would be expected that the container's hostname would be matching `foobar` (parsed into hostname file of the respective container).
However, having tested various container installation the hostname ends up being the standard one of the respective distro, e.g. this one ArchLinux
https://forum.turris.cz/uploads/default/original/2X/8/824139afea2ab70c51fc45b12a92292fe3297e8b.png
TOS RC 3.11.1 |
liblxc 1.1.5-15 |
luci-app-lxc 20160616-1 |
lxc 1.1.5-15 |
lxc-attach 1.1.5-15 |
lxc-auto 1.1.5-15 |
lxc-autostart 1.1.5-15 |
lxc-cgroup 1.1.5-15 |
lxc-checkconfig 1.1.5-15 |
lxc-clone 1.1.5-15 |
lxc-common 1.1.5-15 |
lxc-config 1.1.5-15 |
lxc-configs 1.1.5-15 |
lxc-console 1.1.5-15 |
lxc-create 1.1.5-15 |
lxc-destroy 1.1.5-15 |
lxc-device 1.1.5-15 |
lxc-execute 1.1.5-15 |
lxc-freeze 1.1.5-15 |
lxc-hooks 1.1.5-15 |
lxc-info 1.1.5-15 |
lxc-init 1.1.5-15 |
lxc-ls 1.1.5-15 |
lxc-lua 1.1.5-15 |
lxc-monitor 1.1.5-15 |
lxc-monitord 1.1.5-15 |
lxc-snapshot 1.1.5-15 |
lxc-start 1.1.5-15 |
lxc-stop 1.1.5-15 |
lxc-templates 1.1.5-15 |
lxc-unfreeze 1.1.5-15 |
lxc-unshare 1.1.5-15 |
lxc-user-nic 1.1.5-15 |
lxc-usernsexec 1.1.5-15 |
lxc-wait 1.1.5-15 |
rpcd-mod-lxc 20141012https://gitlab.nic.cz/turris/os/packages/-/issues/282static DHCP lease times neglected2019-08-03T17:16:49+02:00Ghost Userstatic DHCP lease times neglectedTOS RC 3.11.1 | dnsmasq-full 2.78-3
"/etc/config/dhcp"
```
config dhcp 'lan'
option leasetime '1h'
config host
option leasetime '7d'
```
The lease time for the host does not exceed 1h from the lan setting. It would be expected that...TOS RC 3.11.1 | dnsmasq-full 2.78-3
"/etc/config/dhcp"
```
config dhcp 'lan'
option leasetime '1h'
config host
option leasetime '7d'
```
The lease time for the host does not exceed 1h from the lan setting. It would be expected that lease times set for hosts are honoured.https://gitlab.nic.cz/turris/os/packages/-/issues/280sfdisk build config2019-05-06T17:21:53+02:00Ghost Usersfdisk build configTOS 3.11 stable | sfdisk 2.29.2-1
`sfdisk`
```
/usr/sbin/sfdisk: line 143: /home/beast/beast/workspace/omnia-master/staging_dir/host/bin/sed: No such file or directory
/usr/sbin/sfdisk: line 147: /home/beast/beast/workspace/omnia-master...TOS 3.11 stable | sfdisk 2.29.2-1
`sfdisk`
```
/usr/sbin/sfdisk: line 143: /home/beast/beast/workspace/omnia-master/staging_dir/host/bin/sed: No such file or directory
/usr/sbin/sfdisk: line 147: /home/beast/beast/workspace/omnia-master/staging_dir/host/bin/sed: No such file or directory
/usr/sbin/sfdisk: line 199: cd: /home/beast/beast/workspace/omnia-master/build_dir/target-arm_cortex-a9+vfpv3_musl-1.1.15_eabi/util-linux-2.29.2: No such file or directory
/usr/sbin/sfdisk: line 199: ccache_cc: command not found
```Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/270wlan iface name convention clash2019-05-06T17:21:52+02:00Ghost Userwlan iface name convention clash@kkoci
Whilst the issue is not present with the `eth` iface name convention I noticed that there is a problem with the `wlan` iface names clashing and impeding the iface settings, at least their mtu but it might spread to other setting...@kkoci
Whilst the issue is not present with the `eth` iface name convention I noticed that there is a problem with the `wlan` iface names clashing and impeding the iface settings, at least their mtu but it might spread to other settings too and casuse some unintended issues and thus wanted to let you know at least.
test bed
```
/etc/config/wireless
config wifi-iface
option device 'radio0'
option ifname 'wlan1'
option network 'lan'
option mode 'ap'
option ieee80211w '1'
config wifi-iface
option device 'radio0'
option ifname 'wlan2'
option network 'guest'
option mode 'ap'
option ieee80211w '1'
config wifi-iface
option device 'radio1'
option ifname 'wlan3'
option network 'lan'
option mode 'ap'
option ieee80211w '1'
```
```
/etc/config/network/
config device
option name wlan1
option mtu 2304
config device
option name wlan2
option mtu 2304
config device
option name wlan3
option mtu 2304
```
After the network is restarted and all ifaces are fully up *only one out of the three* `wlan` ifaces has the correct mtu. Changing the name convention to the below and *all 3* `wlan` ifaces are showing the correct mtu.
```
/etc/config/wireless
config wifi-iface
option device 'radio0'
option ifname 'buffalo'
option network 'lan'
option mode 'ap'
option ieee80211w '1'
config wifi-iface
option device 'radio0'
option ifname 'elephant'
option network 'guest'
option mode 'ap'
option ieee80211w '1'
config wifi-iface
option device 'radio1'
option ifname 'tiger'
option network 'lan'
option mode 'ap'
option ieee80211w '1'
```
```
/etc/config/network/
config device
option name buffalo
option mtu 2304
config device
option name elephant
option mtu 2304
config device
option name tiger
option mtu 2304
```https://gitlab.nic.cz/turris/os/packages/-/issues/268Turris OS 3.11: miniupnpd no longer starts at router boot2019-05-06T17:21:51+02:00Tony QuanTurris OS 3.11: miniupnpd no longer starts at router bootStarting in Turris OS 3.11, miniupnpd isn't automatically started at router boot, even though it is configured in the init scripts as enabled/start on boot.
Problem seems to be with ``/etc/init.d/miniupnpd`` in particular how ``boot()``...Starting in Turris OS 3.11, miniupnpd isn't automatically started at router boot, even though it is configured in the init scripts as enabled/start on boot.
Problem seems to be with ``/etc/init.d/miniupnpd`` in particular how ``boot()`` is written
```
boot() {
return
}
```
Since boot does nothing, and boot() if present is run instead of start() at router boot up, this means miniupnpd is never started. I commented out this part of the script and now miniupnpd starts properly. The odd part though is that this init script seems to have no recent changes in the last 2 years. Possibly something else was starting miniupnpd before 3.11 and whatever that was is no longer doing so?Turris OS 3.11.1Jan PavlinecJan Pavlinec