Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2021-09-08T16:18:48+02:00https://gitlab.nic.cz/turris/os/packages/-/issues/20resolver-conf: Please disable open resolver in the config2021-09-08T16:18:48+02:00Ondřej Caletkaresolver-conf: Please disable open resolver in the configIn current setup, the only thing that stops TurrisOS from being an open resolver is the default firewall config. Lot of inexperienced users unintentionally enable incoming udp/53 traffic, making the router act like an open resolver.
The...In current setup, the only thing that stops TurrisOS from being an open resolver is the default firewall config. Lot of inexperienced users unintentionally enable incoming udp/53 traffic, making the router act like an open resolver.
There should be safer default in the config of DNS recursors, that would allow recursive queries only from internal network, regardless of the state of the firewall.https://gitlab.nic.cz/turris/os/packages/-/issues/225Test wildcard records in the DNSSEC test2019-07-02T16:52:49+02:00Ghost UserTest wildcard records in the DNSSEC testWhen doing the connectivity test, perform some tests DNSSEC tests against wildcards or similar cornercases that are known to break from time to time.When doing the connectivity test, perform some tests DNSSEC tests against wildcards or similar cornercases that are known to break from time to time.https://gitlab.nic.cz/turris/os/packages/-/issues/27resolver: add support for ipv6 static leases2021-07-29T09:57:19+02:00Jan Pavlinecresolver: add support for ipv6 static leaseshttps://forum.turris.cz/t/kresd-ipv6-hints/3680https://forum.turris.cz/t/kresd-ipv6-hints/3680https://gitlab.nic.cz/turris/os/packages/-/issues/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/252Kresd responds from incorrect source IP2021-07-09T17:26:26+02:00Jan PavlinecKresd responds from incorrect source IPhttps://forum.turris.cz/t/kresd-responds-from-incorrect-source-ip/8620https://forum.turris.cz/t/kresd-responds-from-incorrect-source-ip/8620https://gitlab.nic.cz/turris/os/packages/-/issues/265Update hangs if Dynamic DNS updater active2021-11-30T21:34:15+01:00Tony QuanUpdate hangs if Dynamic DNS updater activeIf the Dynamic DNS updater is active/running, updates from 3.10.8 to 3.11 TurrisOS hang and never complete. pkgupdate log shows the following and nothing after this point in the log.
```
DEBUG:backend.lua:1021 (script_run):
DEBUG:backe...If the Dynamic DNS updater is active/running, updates from 3.10.8 to 3.11 TurrisOS hang and never complete. pkgupdate log shows the following and nothing after this point in the log.
```
DEBUG:backend.lua:1021 (script_run):
DEBUG:backend.lua:1009 (script_run):Running postinst of ddns-scripts
DEBUG:src/lib/interpreter.c:320 (lua_run_generic):Command: /usr/lib/opkg/info//ddns-scripts.postinst configure
TRACE:src/lib/events.c:542 (run_command_a):Running command /usr/lib/opkg/info//ddns-scripts.postinst
```
This bug seems to have occurred before in the upgrade to 3.10.1 as pointed out [in this forum post](https://forum.turris.cz/t/solved-pkgupdate-not-working-probably-after-update-3-10-1/7653/4). As the Dynamic DNS updater is a pretty common service, testing of updates should be performed with it in place and active.https://gitlab.nic.cz/turris/os/packages/-/issues/311add support for odhcpd & ipv6 in dhcp_host_domain_ng.py2022-09-03T15:38:50+02:00Ghost Useradd support for odhcpd & ipv6 in dhcp_host_domain_ng.pyas apparent from the current code `ipv6` is not supported and `odhcpd` settings are neglected, such as
```
option leasefile
option/list domain
```
This may cause some grievance for users making the transition to ipv6.as apparent from the current code `ipv6` is not supported and `odhcpd` settings are neglected, such as
```
option leasefile
option/list domain
```
This may cause some grievance for users making the transition to ipv6.https://gitlab.nic.cz/turris/os/packages/-/issues/397HaaS-proxy IPv6 support2020-03-10T09:17:42+01:00Karel KociHaaS-proxy IPv6 supportHaaS proxy currently does not support IPv6. There are two blockers for it:
* [ ] ipv6 nat support in fw3 (OpenWRT firewall)
* [ ] haas-proxy listening on ipv6 socket
Support in fw3 can be overcome witch nasty code that was already impl...HaaS proxy currently does not support IPv6. There are two blockers for it:
* [ ] ipv6 nat support in fw3 (OpenWRT firewall)
* [ ] haas-proxy listening on ipv6 socket
Support in fw3 can be overcome witch nasty code that was already implemented in https://gitlab.labs.nic.cz/turris/turris-os-packages/tree/haas-ipv6 but having direct support in fw3 would be much nicer.https://gitlab.nic.cz/turris/os/packages/-/issues/415fosquitto: investigate whether mosquitto is able to run using ECC2022-09-08T21:48:39+02:00Štěpán Henekfosquitto: investigate whether mosquitto is able to run using ECCŠtěpán HenekŠtěpán Henekhttps://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/503turris-cagen: more granural locking2021-08-16T16:38:14+02:00Štěpán Henekturris-cagen: more granural lockingRight now it locks by CA name. It should lock by locked by CA dirname (slugified).
Problem:
Netboot uses cagen to generate CA for the client and the new ca is always called remote.
e.g.
```sh
CA_DIR=transfering/0000000D30001605 /tmp/cag...Right now it locks by CA name. It should lock by locked by CA dirname (slugified).
Problem:
Netboot uses cagen to generate CA for the client and the new ca is always called remote.
e.g.
```sh
CA_DIR=transfering/0000000D30001605 /tmp/cagen.sh new_ca remote gen_ca gen_server turris gen_client 0000000A00000214-0000000D30001605
```
This will lock all `remote` CAs. => `/etc/ssl/remote` CA and `/srv/turris-neboot/clients/transfering/*` CAs can't be modified while the script is running, although it can safely run in parellel.https://gitlab.nic.cz/turris/os/packages/-/issues/507Write packages style guidelines to README.adoc2019-11-13T10:41:36+01:00Karel KociWrite packages style guidelines to README.adocWe should define how packages and mainly `Makefile` should look like and be formatted. This should serve as a rule book as well as example of packages creation.
The appropriate file is README.asciidoc.We should define how packages and mainly `Makefile` should look like and be formatted. This should serve as a rule book as well as example of packages creation.
The appropriate file is README.asciidoc.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/539Rust and Cargo support (upstream and TOS)2021-06-24T15:41:52+02:00Jan PavlinecRust and Cargo support (upstream and TOS)Mainly because of Suricata dependency on rust it is necessary to add support for rust lang. Inspiration could be ruby or golang packaging in OpenWrt.Mainly because of Suricata dependency on rust it is necessary to add support for rust lang. Inspiration could be ruby or golang packaging in OpenWrt.https://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/577Improve certgen hooks directory manipulation2022-01-04T14:57:18+01:00Vojtech MyslivecImprove certgen hooks directory manipulationFollow-up from https://gitlab.nic.cz/turris/diagnostics/-/merge_requests/6#note_147685
@vmyslivec:
> * Certgen itself is installed on base system due to `mailpass` feature
> * *hooks dir* is created and used by `sentinel-proxy` package
...Follow-up from https://gitlab.nic.cz/turris/diagnostics/-/merge_requests/6#note_147685
@vmyslivec:
> * Certgen itself is installed on base system due to `mailpass` feature
> * *hooks dir* is created and used by `sentinel-proxy` package
> * Hooks dir is possibly optional (you can issue a certificate without a proxy) and Certgen does not have a default value hardcoded
>
> This approach was introduced in turris/turris-os-packages!86
@kkoci:
> I think that is is just too complicated. That hook dir is not essential and default should be hardcodded.
>
> The point of hook directory is that program itself runs those hooks but won't fail if there is no such directory and or if hook fails. Both users and programs should be sure that when program is run that hook dir is used not just in case hooks are specified. This is at least how I see hooks.
>
> This means that:
>
> * hooks dir can be created by `certgen` package by putting file `.keep` in it or it doesn't have to be but then it should not fail if it is missing
> * hooks should always be called from expected location unless option is used to not call hooks (reverse implicit rule against current state)
>
> I know that I was reviewing that code but now when I see it used I see that it is flawed in this case. Hooks should be reliable in some sense and not some adhock thing. I feel like this implementation now has almost no difference over `certgen && for f in /hook/*; $f; done` in sense that user chooses what is executed and if he knows little then it breaks a lot potentially.https://gitlab.nic.cz/turris/os/packages/-/issues/586Regression: DHCP names not auto-updating in TurrisOS 5.x2021-07-29T12:49:49+02:00Leonardo Brondani SchenkelRegression: DHCP names not auto-updating in TurrisOS 5.xIn Turris OS 4.x, `dnsmasq` was updating `kresd` by:
1. invoking `/usr/lib/dnsmasq/dhcp-script.sh`
2. which invoked `/sbin/hotplug-call`
3. which invoked each script in `/etc/hotplug.d/dhcp`, one being `90-dhcp_host_domain_ng.py` (symlin...In Turris OS 4.x, `dnsmasq` was updating `kresd` by:
1. invoking `/usr/lib/dnsmasq/dhcp-script.sh`
2. which invoked `/sbin/hotplug-call`
3. which invoked each script in `/etc/hotplug.d/dhcp`, one being `90-dhcp_host_domain_ng.py` (symlink to `/etc/resolver/dhcp_host_domain.py`) which used to be installed by `resolver-conf`.
In TurrisOS 5.x the symlink is no longer installed. Creating it manually no longer works: `hotplug-call` fails because `dnsmasq` is now jailed.
Ever since I upgraded from 4.x to 5.x, (new) DHCP names no longer resolve. The updater script is only called during `kresd` initialization, but not when `dnsmasq` gives new leases.
```
# uci get resolver.common.dynamic_domains
1
```https://gitlab.nic.cz/turris/os/packages/-/issues/587Turris 1.x: Update U-boot2022-06-22T16:46:34+02:00Karel KociTurris 1.x: Update U-bootUpdate uboot to new version on Turris 1.x. Doing so should enable for example boot from USB.Update uboot to new version on Turris 1.x. Doing so should enable for example boot from USB.Turris OS 6.1.0https://gitlab.nic.cz/turris/os/packages/-/issues/589Mox: update u-boot to latest version2024-03-04T10:12:52+01:00Karel KociMox: update u-boot to latest versionUpdating U-boot in Moxes is highly needed to fix issues with BTRFS sparse blocks reading.Updating U-boot in Moxes is highly needed to fix issues with BTRFS sparse blocks reading.Turris OS 7.1.0Michal HruseckyMichal Hruseckyhttps://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 Hrusecky