Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2021-07-09T16:51:16+02:00https://gitlab.nic.cz/turris/os/packages/-/issues/698resolvers: add option for canary domain2021-07-09T16:51:16+02:00Jan Pavlinecresolvers: add option for canary domainIn case browser detects canary domain it should send DNS to router instead of DOH channel defined in browser.
https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnetIn case browser detects canary domain it should send DNS to router instead of DOH channel defined in browser.
https://support.mozilla.org/en-US/kb/canary-domain-use-application-dnsnethttps://gitlab.nic.cz/turris/os/packages/-/issues/694Initial snapshot after finishing guide2020-11-09T13:52:22+01:00Lukas JelinekInitial snapshot after finishing guideI think that an initial filesystem snapshot should be done after finishing (or leaving) the first setup guide. This snapshot would allow to get back a clean but configured system.I think that an initial filesystem snapshot should be done after finishing (or leaving) the first setup guide. This snapshot would allow to get back a clean but configured system.https://gitlab.nic.cz/turris/os/packages/-/issues/692Shield presented as Mox Board2021-04-14T16:10:19+02:00Lukas JelinekShield presented as Mox BoardTurris Shield is currently presented as _Mox Board_ on the **About** page. I think that it should display a string specific for Shield.Turris Shield is currently presented as _Mox Board_ on the **About** page. I think that it should display a string specific for Shield.https://gitlab.nic.cz/turris/os/packages/-/issues/689initial-config: Allow hashed passwords to be specified in config2020-10-31T02:57:21+01:00Karel Kociinitial-config: Allow hashed passwords to be specified in configInitial version of initial-config addressed only unsecure but simple configuration. It would be better to allows users to use hashed password even when generating of it is more complicated. It would be an option for advanced users having...Initial version of initial-config addressed only unsecure but simple configuration. It would be better to allows users to use hashed password even when generating of it is more complicated. It would be an option for advanced users having to do configuration without ethernet as well.
The following discussion from !560 should be addressed:
- [ ] @vmyslivec started a [discussion](https://gitlab.nic.cz/turris/turris-os-packages/-/merge_requests/560#note_178336): (+5 comments)
> follow-up from https://gitlab.nic.cz/turris/turris-os-packages/-/merge_requests/560#note_177635
>
> Is it intended to let users generate a config that would be left on some USB flash drive with cleartext (non-hashed) passwords?
>
> I know we can't get rid of Wi-Fi password in clear text but foris and system password can be prepared in their hashed form.
>
> This README can include steps to generate desired hash.https://gitlab.nic.cz/turris/os/packages/-/issues/681knot-resolver: refactor kresd.init2020-10-20T15:20:37+02:00Jan Pavlinecknot-resolver: refactor kresd.initkresd.init should folow our requirements for shell scripts.
- fix double-quotes in variables
- fix indentation
- other issues (shellcheck)kresd.init should folow our requirements for shell scripts.
- fix double-quotes in variables
- fix indentation
- other issues (shellcheck)https://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.0https://gitlab.nic.cz/turris/os/packages/-/issues/670Minipot: allow separate redirect for input and forward2020-09-21T12:09:51+02:00Karel KociMinipot: allow separate redirect for input and forwardIn general deployment it is different if you are redirecting to minipot input or/and forward. We should not automatically redirect both as we do now. We should somehow let users to choose. Right now user has only option and that is to di...In general deployment it is different if you are redirecting to minipot input or/and forward. We should not automatically redirect both as we do now. We should somehow let users to choose. Right now user has only option and that is to disable minipot or to have both input and forward redirected to router itself.https://gitlab.nic.cz/turris/os/packages/-/issues/663resolver configuration documentation2021-07-29T09:51:53+02:00Jan Pavlinecresolver configuration documentationWe should document /etc/config/resolverWe should document /etc/config/resolverhttps://gitlab.nic.cz/turris/os/packages/-/issues/655lxc: Failure to download images2020-09-18T09:29:21+02:00Lukas Jelineklxc: Failure to download imagesOriginated from here: https://forum.turris.cz/t/create-lxc-container/13560
### Steps to reproduce:
1. Run `lxc-create -t download -n <name>`
2. Select a distribution, release and archicture.
### Expected results:
The selected image i...Originated from here: https://forum.turris.cz/t/create-lxc-container/13560
### Steps to reproduce:
1. Run `lxc-create -t download -n <name>`
2. Select a distribution, release and archicture.
### Expected results:
The selected image is downloaded and used to create a container.
### Actual result:
It fails with the following error:
```
ERROR: Failed to download <IMAGE_URL>
lxc-create: <name>: lxccontainer.c: create_run_template: 1617 Failed to create container from template
lxc-create: <name>: tools/lxc_create.c: main: 327 Failed to create container <name>
```
Tested with `ArchLinux/latest/armv7l` and `Debian/Buster/armv7l` with the same results. As investigated by both capturing the communication and checking the webserver's log, it sends an HTTP request first which is redirected to HTTPS by 301 and then it repeats it with an HTTPS request (via TLS 1.3). The webserver logs these requests as successful and probably all data is transferred but at the client side it is treated as failure.https://gitlab.nic.cz/turris/os/packages/-/issues/650omnia ssd/usb boot - request for new package2021-06-24T13:48:24+02:00Jan Pavlinecomnia ssd/usb boot - request for new packageOmnia SSD/USB boot is a killer feature that significantly extends the service life of the device.
There should be a package that could make whole process much easier with fw_setenv etc.
https://wiki.turris.cz/doc/en/howto/omnia_booting...Omnia SSD/USB boot is a killer feature that significantly extends the service life of the device.
There should be a package that could make whole process much easier with fw_setenv etc.
https://wiki.turris.cz/doc/en/howto/omnia_booting_from_external_storage
related to https://gitlab.nic.cz/turris/user-docs/-/issues/66https://gitlab.nic.cz/turris/os/packages/-/issues/627Nexcloud database error2022-12-12T15:09:32+01:00leoprosperiNexcloud database errorAfter a brand new installation of Nextcloud 17 on Turris Omnia with v5.0.3, I saw the following warning on /nextcloud/index.php/settings/admin/overview:
> Some columns in the database are missing a conversion to big int. Due to the fact...After a brand new installation of Nextcloud 17 on Turris Omnia with v5.0.3, I saw the following warning on /nextcloud/index.php/settings/admin/overview:
> Some columns in the database are missing a conversion to big int. Due to the fact that changing column types on big tables could take some time they were not changed automatically. By running 'occ db:convert-filecache-bigint' those pending changes could be applied manually. This operation needs to be made while the instance is offline. For further details read the documentation page about this.
> mounts.storage_id
> mounts.root_id
> mounts.mount_id
Running this command cleared the issues:
`sudo -u nobody php-cli /srv/www/nextcloud/occ db:convert-filecache-bigint`Turris OS 6.1.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/623follectd package writing constantly lots of lines to syslog because of some e...2020-07-01T09:10:48+02:00Pavel Stanofollectd package writing constantly lots of lines to syslog because of some errorwhen i uninstall it it will install back with foris-controller-collectd-module
sample from logread:
```
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available wri...when i uninstall it it will install back with foris-controller-collectd-module
sample from logread:
```
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: Available write targets:: [none]
Jun 30 13:34:22 turris collectd[7939]: exec plugin: exec_read_one: error = exec plugin: Failed to execute ``/usr/libexec/follectd/neighbours.sh'': Exec format error
Jun 30 13:34:22 turris collectd[7939]: exec plugin: exec_read_one: error = exec plugin: Failed to execute ``/usr/libexec/follectd/neighbours.sh'': Exec format error
```Štěpán HenekŠtěpán Henekhttps://gitlab.nic.cz/turris/os/packages/-/issues/621[meta] DNS testing in reforis2021-07-15T14:10:13+02:00Jan Pavlinec[meta] DNS testing in reforisThis issue is related to our meeting about better DNS diagnostic
[check_connection](https://gitlab.labs.nic.cz/turris/turris-os-packages/-/blob/master/utils/turris-utils/files/check_connection) script should be replaced with python vers...This issue is related to our meeting about better DNS diagnostic
[check_connection](https://gitlab.labs.nic.cz/turris/turris-os-packages/-/blob/master/utils/turris-utils/files/check_connection) script should be replaced with python version which could test other DNS settings (forwarding not working, DNS hijack etc.)
This script can use some functionality from [resolver_rpcd](https://gitlab.labs.nic.cz/turris/turris-os-packages/-/blob/master/net/resolver-conf/files/resolver_rpcd.py) (see https://pypi.org/project/ubus/ and [README.md](https://gitlab.labs.nic.cz/turris/turris-os-packages/-/blob/master/net/resolver-conf/README.md)) and read setting from uci https://gitlab.labs.nic.cz/turris/pyuci [resolver configuration](https://gitlab.labs.nic.cz/turris/turris-os-packages/-/blob/master/net/resolver-conf/files/resolver-omnia-config)
Related issues/MR:
* [x] pytest-xdist MR https://gitlab.nic.cz/turris/turris-os-packages/-/issues/317 / https://github.com/openwrt/packages/pull/13010
* [ ] https://gitlab.nic.cz/turris/turris-os-packages/-/issues/620
* [ ] augeas MR https://github.com/openwrt/packages/pull/12913
* [ ] Deckard MR https://gitlab.nic.cz/turris/turris-os-packages/-/merge_requests/460
cc @pspacek @kkocihttps://gitlab.nic.cz/turris/os/packages/-/issues/595DynFW client: Handle server certificate update2021-03-29T12:09:17+02:00Vojtech MyslivecDynFW client: Handle server certificate updateWe should implement a method to update Sentinel:DynFW server certificate update. Currently, the init script will skip to download new certificate and if it changes, DynFW client will not workWe should implement a method to update Sentinel:DynFW server certificate update. Currently, the init script will skip to download new certificate and if it changes, DynFW client will not workhttps://gitlab.nic.cz/turris/os/packages/-/issues/592[Meta] knot-resolver/unbound: domain blocking for specific clients2021-08-31T15:42:01+02:00Jan Pavlinec[Meta] knot-resolver/unbound: domain blocking for specific clientsThis issue is related to the idea of how to use AdBlock only for specific clients.
**knot-resolver:**
It's possible to add custom rpz policy for specific subnet
https://knot-resolver.readthedocs.io/en/latest/modules-view.html#example...This issue is related to the idea of how to use AdBlock only for specific clients.
**knot-resolver:**
It's possible to add custom rpz policy for specific subnet
https://knot-resolver.readthedocs.io/en/latest/modules-view.html#example-configuration
```
-- RPZ for subset of clients
view:addr('192.168.1.0/24', policy.rpz(policy.PASS, 'whitelist.rpz'))
```
**unbound:**
The same feature could be done probably with access-control-tags
see https://medium.com/nlnetlabs/client-based-filtering-in-unbound-d7da3f1ef639 and
https://medium.com/nlnetlabs/response-policy-zones-in-unbound-5d453de75f26https://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/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/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/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/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.