Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2023-08-16T14:35:25+02:00https://gitlab.nic.cz/turris/os/packages/-/issues/913Add ethtool dependency for turris-diagnostics2023-08-16T14:35:25+02:00Martin MatějekAdd ethtool dependency for turris-diagnostics## Description
In case SFP module is plugged into the SFP slot, then turris-diagnostics fails to fetch info about SFP, due to missing `ethtool`.
`turris-diagnostics` requires `ethtool` for its network module. See: https://gitlab.nic.cz...## Description
In case SFP module is plugged into the SFP slot, then turris-diagnostics fails to fetch info about SFP, due to missing `ethtool`.
`turris-diagnostics` requires `ethtool` for its network module. See: https://gitlab.nic.cz/turris/diagnostics/-/blob/master/modules/40_network.module#L58-62
## How to reproduce
On Turris OS 6.2.4, Turris Omnia, clean install from medkit. Turris SFP module is plugged in the SFP slot.
Run the network diagnostics
```sh
$ turris-diagnostics network
```
## Expected behavior
At least some output from ethtool should appear.
```
$ turris-diagnostics network
############## network
[...]
== SFP (eth2) ==
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x22 (RJ45)
[...]
************** network
```
## Actual behavior
`ethtool` is not found and we don't get any info about SFP.
```
$ turris-diagnostics network
############## network
[...]
== SFP (eth2) ==
modules/module.sh: line 61: ethtool: not found
************** network
```
## Proposed solution
Add `ethtool` dependency for `turris-diagnostics` and include `ethtool` in base TOS image/medkit.https://gitlab.nic.cz/turris/os/packages/-/issues/914Tvheadend routing not working with package from upstream due to different add...2023-08-16T14:35:24+02:00Filip HronTvheadend routing not working with package from upstream due to different address# Issue
We have a report on [support](https://rt.office.nic.cz/Ticket/Display.html?id=1512414) that frontend for tvheadend link does not work properly
## Probable cause
Having both locally (on our office computer) and on user's comput...# Issue
We have a report on [support](https://rt.office.nic.cz/Ticket/Display.html?id=1512414) that frontend for tvheadend link does not work properly
## Probable cause
Having both locally (on our office computer) and on user's computer the same error in `/var/log/lighttpd/error.log`:
```
2023-03-15 08:44:13: (../src/server.c.1588) server started (lighttpd/1.4.67)
2023-03-15 11:56:37: (../src/server.c.2097) server stopped by UID = 0 PID = 1
2023-03-15 11:56:38: (../src/server.c.1588) server started (lighttpd/1.4.67)
2023-03-15 11:57:23: (../src/gw_backend.c.283) establishing connection failed: socket: tcp:127.0.0.1:9981: Connection refused
2023-03-15 11:57:23: (../src/gw_backend.c.993) all handlers for /tvheadend/? on are down.
2023-03-15 11:57:25: (../src/gw_backend.c.360) gw-server re-enabled: tcp:127.0.0.1:9981 127.0.0.1 9981
```
## Task
- [x] Investigate why handler for `lighttpd` fails
- [x] Fix the issue
### credit goes to
@mmatejekFilip HronFilip Hronhttps://gitlab.nic.cz/turris/os/packages/-/issues/919foris-ws fails to start on TOS 7.02023-08-16T14:35:22+02:00Martin Matějekforis-ws fails to start on TOS 7.0'foris-ws' service fails to start and crashes with following error:
```
ImportError: cannot import name 'Iterable' from 'collections'
```
Resolved by: turris/foris-controller/foris-ws#11'foris-ws' service fails to start and crashes with following error:
```
ImportError: cannot import name 'Iterable' from 'collections'
```
Resolved by: turris/foris-controller/foris-ws#11Turris OS 7.0https://gitlab.nic.cz/turris/os/packages/-/issues/923Hotfix: add user lighttpd settings2023-08-15T06:27:41+02:00Filip HronHotfix: add user lighttpd settings# Problem
Commit https://gitlab.nic.cz/turris/webapps/-/commit/62b7c02e34a995459581f5b60f59594f2cc781ad that fixes changes from merge request !872 does not affect shield devices, as Shield does not have ``webapps`` package
# Solution
...# Problem
Commit https://gitlab.nic.cz/turris/webapps/-/commit/62b7c02e34a995459581f5b60f59594f2cc781ad that fixes changes from merge request !872 does not affect shield devices, as Shield does not have ``webapps`` package
# Solution
Add to (config that is to shield only) [lighttpd-reforis-only.conf](master/hardware/mox/mox-support/files/lighttpd-reforis-only.conf) following code:
```
server.username := ""
server.groupname := ""
```
@gstraussFilip HronFilip Hronhttps://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/790resolver-conf problem with both hotplug scripts and the wan6 interface2023-07-18T12:54:28+02:00Christoph Metzresolver-conf problem with both hotplug scripts and the wan6 interfaceI have two issues with the hotplug scripts restarting the resolver on every interface update. Currently there seems to be a bug / issue in OpenWrt in resulting in frequent interface updates on my wan6 interface, also there seems to be no...I have two issues with the hotplug scripts restarting the resolver on every interface update. Currently there seems to be a bug / issue in OpenWrt in resulting in frequent interface updates on my wan6 interface, also there seems to be no change in the ip addresses at all, even the temporary addresses are still the same, but i did not investigate this any further. I just added a simple nested if to it. Some similar issues where also mentioned in the forum https://forum.turris.cz/t/every-3-secs-in-log-kresd-hard-limit-for-number-of-file-descriptors-any-help:
**/etc/hotplug.d/iface/40-ip-resolver-reload**
```
if [ "$ACTION" = "ifupdate" -o "$ACTION" = "ifup" ]; then
if [ "$IFUPDATE_ADDRESSES" = "1" -o "$IFUPDATE_PREFIXES" = "1" ]; then
if [ "$INTERFACE" != "wan6" ]; then <------- added line
logger -t hotplug "Reload resolver because of interface address update"
/etc/init.d/resolver reload
fi
fi
fi
```
I also recognized that the second script /etc/hotplug.d/iface/40-resolver-reload is also triggerd, there is some matching against an previous md5, but which never got set on my box. So i added storing the md5 in the script as well, i'm not sure if some other script should set this:
**/etc/hotplug.d/iface/40-resolver-reload**
```
if /etc/init.d/resolver enabled && \
[ "$MD5" != "$PREVIOUS" ] && \
[ "$DO_FORWARD" = "1" ] ; then
/etc/init.d/resolver reload
echo "$MD5" > /tmp/resolv.conf.auto.last.md5 <-------- added line
fi
```
maybe this whole stuff could be refactored in a single script, i have no clue why there is a need for two different hotplug scripts at all.
**Update**:
i did some further investigations and it seems the "netifd" is doing a prefix update event also when only the preferred_until / valid_until values are modified.
**https://git.openwrt.org/?p=project/netifd.git;a=blob;f=interface-ip.c**
```
if (node_old && node_new) {
/* Move assignments and refresh addresses to update valid times */
list_splice(&prefix_old->assignments, &prefix_new->assignments);
list_for_each_entry(c, &prefix_new->assignments, head)
if ((iface = vlist_find(&interfaces, c->name, iface, node)))
interface_set_prefix_address(c, prefix_new, iface, true);
if (prefix_new->preferred_until != prefix_old->preferred_until ||
prefix_new->valid_until != prefix_old->valid_until)
ip->iface->updated |= IUF_PREFIX; <--- ALSO RESULTING IN AN PREFIX_UPDATE EVENT
```Turris OS 5.3.0https://gitlab.nic.cz/turris/os/packages/-/issues/754foris-controller fails on Turris OS 7.02023-05-11T14:42:08+02:00Jan Pavlinecforis-controller fails on Turris OS 7.0 Turris OS 7.0 = Crashlab (should be soon HBD)
```
Apr 21 13:44:43 turris foris-controller[16154]: File "/usr/bin/foris-controller", line 33, in <module>
Apr 21 13:44:43 turris foris-controller[16154]: sys.exit(load_entry_point('... Turris OS 7.0 = Crashlab (should be soon HBD)
```
Apr 21 13:44:43 turris foris-controller[16154]: File "/usr/bin/foris-controller", line 33, in <module>
Apr 21 13:44:43 turris foris-controller[16154]: sys.exit(load_entry_point('foris-controller==1.2', 'console_scripts', 'foris-controller')())
Apr 21 13:44:43 turris foris-controller[16154]: File "/usr/lib/python3.9/site-packages/foris_controller/controller/__main__.py", line 220, in main
Apr 21 13:44:43 turris foris-controller[16154]: File "/usr/lib/python3.9/site-packages/foris_controller/buses/mqtt.py", line 413, in __init__
Apr 21 13:44:43 turris foris-controller[16154]: File "/usr/lib/python3.9/site-packages/paho/mqtt/client.py", line 941, in connect
Apr 21 13:44:43 turris foris-controller[16154]: File "/usr/lib/python3.9/site-packages/paho/mqtt/client.py", line 1075, in reconnect
Apr 21 13:44:43 turris foris-controller[16154]: File "/usr/lib/python3.9/site-packages/paho/mqtt/client.py", line 3546, in _create_socket_connection
Apr 21 13:44:43 turris foris-controller[16154]: File "/usr/lib/python3.9/socket.py", line 843, in create_connection
Apr 21 13:44:43 turris foris-controller[16154]: File "/usr/lib/python3.9/socket.py", line 831, in create_connection
Apr 21 13:44:43 turris foris-controller[16154]: ConnectionRefusedError: [Errno 111] Connection refused
```https://gitlab.nic.cz/turris/os/packages/-/issues/264provide package travelmate2023-04-16T13:23:42+02:00Ghost Userprovide package travelmateWhilst `luci-app-travelmate` is available its dependecy package `travelmate` is absent
> ERROR:
> inconsistent: Package luci-app-travelmate requires package travelmate that is not available.
https://openwrt.org/packages/pkgdata/travelmateWhilst `luci-app-travelmate` is available its dependecy package `travelmate` is absent
> ERROR:
> inconsistent: Package luci-app-travelmate requires package travelmate that is not available.
https://openwrt.org/packages/pkgdata/travelmateTurris OS 3.11.1https://gitlab.nic.cz/turris/os/packages/-/issues/797Drop tvheadend from our repository2023-03-20T02:08:34+01:00Josef SchlehoferDrop tvheadend from our repositoryDue to the recent changes in OpenWrt:
- https://github.com/openwrt/packages/commit/326da3dbbc57b6c44bc0d0401529531c7d5dfb89#diff-1c715168bf7640e3599dc7e5f53a17d1d02113ee38fec52cef377c1d25b978cc
- https://github.com/openwrt/packages/commi...Due to the recent changes in OpenWrt:
- https://github.com/openwrt/packages/commit/326da3dbbc57b6c44bc0d0401529531c7d5dfb89#diff-1c715168bf7640e3599dc7e5f53a17d1d02113ee38fec52cef377c1d25b978cc
- https://github.com/openwrt/packages/commit/4a387bc568d25697c25575fdbd95d6d7d96bb9a8#diff-1c715168bf7640e3599dc7e5f53a17d1d02113ee38fec52cef377c1d25b978cc
We can drop tvheadend from our repository to use the upstream package.Turris OS 6.0https://gitlab.nic.cz/turris/os/packages/-/issues/911Request for kmod-usb-serial-ftdi package2023-03-05T10:31:58+01:00Willem TooropRequest for kmod-usb-serial-ftdi packageI have a smart energy meter for which I can monitor energy consumption. I can connect my turris to it with a so called P1 cable (USB to RJ11). It should create a /dev/ttyUSB* device, but I'm afraid the needed driver is not build.
```
roo...I have a smart energy meter for which I can monitor energy consumption. I can connect my turris to it with a so called P1 cable (USB to RJ11). It should create a /dev/ttyUSB* device, but I'm afraid the needed driver is not build.
```
root@turris:~# lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux 5.15.94 xhci-hcd xHCI Host Controller
Bus 004 Device 002: ID 0403:6001 FTDI FT232R USB UART
Bus 004 Device 001: ID 1d6b:0002 Linux 5.15.94 xhci-hcd xHCI Host Controller
Bus 001 Device 001: ID 1d6b:0002 Linux 5.15.94 ehci_hcd EHCI Host Controller
Bus 003 Device 001: ID 1d6b:0003 Linux 5.15.94 xhci-hcd xHCI Host Controller
Bus 005 Device 001: ID 1d6b:0003 Linux 5.15.94 xhci-hcd xHCI Host Controller
```
No kernel messages showed up when connecting the cable.
I believe I need the `ftdi_sio.ko` kernel module which is (with OperWRT) provided through the `kmod-usb-serial-ftdi` package.
Can I request to port that package to Turris OS Packages? Or is there something I can do myself to compile this module?
Thanks!https://gitlab.nic.cz/turris/os/packages/-/issues/909Refresh common-passwords2023-02-24T18:21:45+01:00Filip HronRefresh common-passwordsCommon-passwords seem outdated.
Please refreshCommon-passwords seem outdated.
Please refreshFilip HronFilip Hronhttps://gitlab.nic.cz/turris/os/packages/-/issues/897Adjust WebApps packages for Turris Auth2023-02-21T18:04:49+01:00Josef SchlehoferAdjust WebApps packages for Turris Auth- [ ] Syncthing
- [ ] Transmission
- [ ] and many more...- [ ] Syncthing
- [ ] Transmission
- [ ] and many more...Turris OS 6.3.0https://gitlab.nic.cz/turris/os/packages/-/issues/907syncthing: Webapp not working, still needs much manual config2023-02-16T09:43:03+01:00Martin Peckasyncthing: Webapp not working, still needs much manual configI'm on 6.2.3 HBT now and Syncthing webapp still doesn't work.
The link from the main page of router leads to 192.168.18.1/syncthing. I get 503 there. This might be because of some config trial/error I did before - I ended up setting `op...I'm on 6.2.3 HBT now and Syncthing webapp still doesn't work.
The link from the main page of router leads to 192.168.18.1/syncthing. I get 503 there. This might be because of some config trial/error I did before - I ended up setting `option gui_address https://192.168.18.1:8384`. This is the only way I can access syncthing at least directly via accesing the port. If I set gui_address back to localhost (which, I think, was the installed default), I no longer get 503 from the 192.168.18.1/syncthing URL, however it immediately redirects my browser to 127.0.0.1:8384, which also isn't what one would want (the service is not running on my laptop).
I can see the webapp tries to configure some proxy so probably the intended way was to let lighttpd translate requests from 192.168.18.1/syncthing to 127.0.0.1:8384 on the router, however it fails for some reason and the redirect happens on the client side instead of the server side.Glenn StraussGlenn Strausshttps://gitlab.nic.cz/turris/os/packages/-/issues/904rainbow migration script for TOS 5->6 on Turris 1.x could create an invalid ...2023-01-31T10:58:42+01:00Michal Vasilekrainbow migration script for TOS 5->6 on Turris 1.x could create an invalid config in some casesThe rainbow migration script for Turris 1.x could create an invalid configuration if lan* LEDs were set. These LED names were migrated to `lan-<num>` instead of the correct `lan_<num>` and UCI has issues with handling `-` in LED names. T...The rainbow migration script for Turris 1.x could create an invalid configuration if lan* LEDs were set. These LED names were migrated to `lan-<num>` instead of the correct `lan_<num>` and UCI has issues with handling `-` in LED names. This broke anything that tried to access the rainbow uci entries including rainbow.Turris OS 6.2.3https://gitlab.nic.cz/turris/os/packages/-/issues/903Syncthing webapp style looks out of place2023-01-25T11:33:18+01:00Michal VasilekSyncthing webapp style looks out of placeAll other icons are black and white, this one is an inverted version of the official blue icon. Also, all other webapps start with a capital letter, but Syncthing doesn't.
![image](/uploads/9cb4f1d96a18f45fd7d5249a676e29e4/image.png)All other icons are black and white, this one is an inverted version of the official blue icon. Also, all other webapps start with a capital letter, but Syncthing doesn't.
![image](/uploads/9cb4f1d96a18f45fd7d5249a676e29e4/image.png)Turris OS 6.2.3https://gitlab.nic.cz/turris/os/packages/-/issues/906netmetr runs daily even if autorun is disabled2023-01-24T11:23:20+01:00scott323netmetr runs daily even if autorun is disabledHello, using latest stable TurrisOS 6.2.2 on Turris Omnia, nothing fancy.
I've noticed that $TITLE. My /etc/config/netmetr is:
```
config settings 'settings'
option control_server 'control.netmetr.cz'
option max_history_...Hello, using latest stable TurrisOS 6.2.2 on Turris Omnia, nothing fancy.
I've noticed that $TITLE. My /etc/config/netmetr is:
```
config settings 'settings'
option control_server 'control.netmetr.cz'
option max_history_logs '10'
option client 'HW-PROBE'
option uuid '<obfuscated>'
option autostart_delay '391'
option protocol_mode 'prefer_6'
option autostart_enabled '0'
option sync_code '<obfuscated>'
list hours_to_run '5'
```
Value of autostart_enabled is ignored by netmetr, it will execute the measurement at 5am everyday.
Enable/disable netmetr in reForis does not fix this.
If I remove hours_to_run (using reForis, or manually), it is auto-added by netmetr, and message is logged:
```
Jan 23 09:00:01 turris crond[13992]: (root) CMD (netmetr --autostart --dwlhist --syslog &)
Jan 23 09:00:02 turris netmetr: INFO [root.info:58] Netmetr Python client v2.0.2 starting...
Jan 23 09:00:02 turris netmetr: WARNING [root.warning:67] Config option 'hours_to_run' not found, setting to '(5,)'
Jan 23 09:00:02 turris netmetr: INFO [root.info:58] Autostarted but autostart disabled or not time to run, exiting.
Jan 23 09:00:02 turris crond[13990]: (root) CMDEND (netmetr --autostart --dwlhist --syslog &)
```https://gitlab.nic.cz/turris/os/packages/-/issues/905logread fails to read logs2023-01-23T09:21:48+01:00LinAGKarlogread fails to read logsWhen trying to read logs with logread, it fails with "Error: logfile not found!". It starts working if you restart syslog-ng, but stops working again after reboot.
TurrisOS 6.2.2, Turris OmniaWhen trying to read logs with logread, it fails with "Error: logfile not found!". It starts working if you restart syslog-ng, but stops working again after reboot.
TurrisOS 6.2.2, Turris Omniahttps://gitlab.nic.cz/turris/os/packages/-/issues/900Transmission: webapp not installed and 404 not found2023-01-18T01:00:50+01:00Giuseppe PiscitelliTransmission: webapp not installed and 404 not foundIn HBK on Omnia when installing Transmission from the NAS group in reForis, the corresponding webapp is not installed along with the daemon and LuCI packages. Once the webapp is installed manually, selected from the available application...In HBK on Omnia when installing Transmission from the NAS group in reForis, the corresponding webapp is not installed along with the daemon and LuCI packages. Once the webapp is installed manually, selected from the available applications screen of Turris OS, it returns: 404 not found. Only after rebooting the router (what should be rebooted instead?) does everything work as expected.https://gitlab.nic.cz/turris/os/packages/-/issues/902Ripe Atlas Probe Software error2023-01-16T16:07:27+01:00Giuseppe PiscitelliRipe Atlas Probe Software errorAfter updating on HBK to the latest version of the atlas software, I see this message in the logs and my probe appears to be disconnected, although everything is working properly: Jan 16 14:43:04 turris ATLAS[15180]: /usr/libexec/atlas-p...After updating on HBK to the latest version of the atlas software, I see this message in the logs and my probe appears to be disconnected, although everything is working properly: Jan 16 14:43:04 turris ATLAS[15180]: /usr/libexec/atlas-probe-scripts/bin/ATLAS: source: line 23: can't open '/usr/libexec/atlas-probe-scripts/bin/support.lib.sh': No such file or directory
Update notifications
====================
Changes performed by updater at 2023-01-16T13:19:11+00:00
• Updated package atlas-sw-probe from version 5040-1 to version 5080-1https://gitlab.nic.cz/turris/os/packages/-/issues/880NextCloud conf webfinger and nodeinfo2023-01-13T23:30:54+01:00leoprosperiNextCloud conf webfinger and nodeinfoNextCloud update the webfinger redirect and added nodeinfo.
https://github.com/nextcloud/univention-app/issues/147
Nextcloud lighttpd configuration needs to be updated with the following redirect:
"^/.well-known/webfinger" => "/n...NextCloud update the webfinger redirect and added nodeinfo.
https://github.com/nextcloud/univention-app/issues/147
Nextcloud lighttpd configuration needs to be updated with the following redirect:
"^/.well-known/webfinger" => "/nextcloud/index.php/.well-known/webfinger",
"^/.well-known/nodeinfo" => "/nextcloud/index.php/.well-known/nodeinfo",
That will remove warnings on https://turris/nextcloud/index.php/settings/admin/overview