Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2019-07-26T09:12:34+02:00https://gitlab.nic.cz/turris/os/packages/-/issues/444lxc: Missing CLI packages2019-07-26T09:12:34+02:00Lukas Jelineklxc: Missing CLI packagesPackages for some LXC tools are missing. For example, there is no possibility to destroy a container via CLI because `lxc-destroy` is missing. The same applies for `lxc-freeze`, `lxc-unfreeze`, `lxc-copy`...
In the current state, LXC is...Packages for some LXC tools are missing. For example, there is no possibility to destroy a container via CLI because `lxc-destroy` is missing. The same applies for `lxc-freeze`, `lxc-unfreeze`, `lxc-copy`...
In the current state, LXC is mostly unusable via CLI.
Version: 4.0-beta7https://gitlab.nic.cz/turris/os/packages/-/issues/445[fosquitto] /etc/fosquitto/bridges: No such file or directory2019-07-25T16:21:11+02:00Ghost User[fosquitto] /etc/fosquitto/bridges: No such file or directory> {"kernel":"4.14.133","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"TurrisOS","version":"5.0-dev","revision":"f4997e3","target":"mvebu/cortexa9...> {"kernel":"4.14.133","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"TurrisOS","version":"5.0-dev","revision":"f4997e3","target":"mvebu/cortexa9","description":"TurrisOS 5.0-dev f4997e3"}}
____
introduced with https://gitlab.labs.nic.cz/turris/turris-os-packages/commit/f8da4b901cfefa5cf7692a1efa1ecea386776eea#9a157d676600133b67d88fc6fe9e97bb65f9cc76_137_1414
> INFO:Running postinst of fosquitto
> Generating fosquitto config file in /var/etc/fosquitto.generated.conf
> Generating fosquitto config file in /var/etc/fosquitto.generated.conf
> **chown: /etc/fosquitto/bridges: No such file or directory**
Seems that .../bridges is not being generatedŠtěpán HenekŠtěpán Henekhttps://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/435[mozilla-iot-gateway-webapp] empty shell - missing server component (webthing...2019-07-20T21:52:10+02:00Ghost User[mozilla-iot-gateway-webapp] empty shell - missing server component (webthing-python)?> {"kernel":"4.14.132","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"TurrisOS","version":"5.0-dev","revision":"fef7937","target":"mvebu/cortexa9...> {"kernel":"4.14.132","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"TurrisOS","version":"5.0-dev","revision":"fef7937","target":"mvebu/cortexa9","description":"TurrisOS 5.0-dev fef7937"}}
`cat "/usr/lib/opkg/info/mozilla-iot-gateway-webapp.list"`
> /www/webapps-icons/mozilla-iot.png
> /usr/share/turris-webapps/30_mozilla-iot.conf
___
There is not server running at port 8080 (`URL="http://$SERVER_ADDR:8080/"`)
Could not trace the source in the GIT and thus wondering whether:
* this is just the current state of development and the server component/integration is to follow? or
* the 2 files are to suffice to integrate with `lighttpd` but does not work? or
* is the server component (`webthing-python` ?) missing? or
* am I the one missing something, e.g. need to install manually `iotivity`?https://gitlab.nic.cz/turris/os/packages/-/issues/437python3-werkzeug is not available2019-07-16T22:16:03+02:00Ghost Userpython3-werkzeug is not available> {"kernel":"4.14.133","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"TurrisOS","version":"5.0-dev","revision":"1dd690d","target":"mvebu/cortexa9...> {"kernel":"4.14.133","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"TurrisOS","version":"5.0-dev","revision":"1dd690d","target":"mvebu/cortexa9","description":"TurrisOS 5.0-dev 1dd690d"}}
___
started to show with HBD today's 18:35 build
> ERROR:
> inconsistent: Package foris-ws requires package python3-werkzeug that is not available.https://gitlab.nic.cz/turris/os/packages/-/issues/434[RFC] what are those cyclic dependencies?2019-07-10T04:49:32+02:00Ghost User[RFC] what are those cyclic dependencies?> TurrisOS 5.0-dev c111af0
observed when `pkgupdate`
> WARN:Package user-notify is in cyclic dependency. It might fail its post-install script.
> WARN:Package notification-system is in cyclic dependency. It might fail its post-insta...> TurrisOS 5.0-dev c111af0
observed when `pkgupdate`
> WARN:Package user-notify is in cyclic dependency. It might fail its post-install script.
> WARN:Package notification-system is in cyclic dependency. It might fail its post-install script.
> WARN:Package wpad-mesh-wolfssl is in cyclic dependency. It might fail its post-install script.
> WARN:Package hostapd is in cyclic dependency. It might fail its post-install script.https://gitlab.nic.cz/turris/os/packages/-/issues/32Update domoticz2019-07-08T15:26:16+02:00Jan PavlinecUpdate domoticzUpdate domoticzUpdate domoticzhttps://gitlab.nic.cz/turris/os/packages/-/issues/419LXC-Container from OS3.x didnt start in OS4x2019-07-08T13:09:31+02:00SOS aka BeCubeLXC-Container from OS3.x didnt start in OS4xlxc-start gives me the output in the logfile:
* 1st test-container: start - start.c:start:2028 - Exec format error - Failed to exec “/sbin/init”
* 2nd test-container: start - start.c:start:2028 - Permission denied - Failed to exec “/...lxc-start gives me the output in the logfile:
* 1st test-container: start - start.c:start:2028 - Exec format error - Failed to exec “/sbin/init”
* 2nd test-container: start - start.c:start:2028 - Permission denied - Failed to exec “/sbin/init”
(the first-container i make a permission-change to 777 before, to test the Things…)
I try different Tests with the config-files, but this should be not a config-file-problem.
Both are Ubuntu-Systems and created with LUCI before, both are placed on the internal 256GB SSD.
New created containers from LUCI starts without a problem.https://gitlab.nic.cz/turris/os/packages/-/issues/315Remove packages and use the upstream one or send it to upstream2019-07-08T11:21:44+02:00Josef SchlehoferRemove packages and use the upstream one or send it to upstream* [x] logrotate (We have slightly modified logrotate.conf and cron job.)
* [x] w_scan (It's available in our repo could be pretty useful for DVB scanning, but currently it's not compiled.)
* [x] dvb-apps (as a replacement for w_scan)
...* [x] logrotate (We have slightly modified logrotate.conf and cron job.)
* [x] w_scan (It's available in our repo could be pretty useful for DVB scanning, but currently it's not compiled.)
* [x] dvb-apps (as a replacement for w_scan)
* [x] tor (Would you please look to this @jpavlinec?)
* [ ] tvheadend (The upstream has an old version and there were some unsuccessful attempts to update.) and also upstream CZ DVB-T2 MUXes
* [x] poco (@jpavlinec is this needed? Couldn't we use the upstream one?)
* [x] rrdtool-1.0.x ~~(No longer in upstream)~~ https://gitlab.labs.nic.cz/turris/turris-os-packages/issues/315#note_96840
* [x] torsocks - https://github.com/openwrt/packages/pull/8099
* [x] hashdeep - https://github.com/openwrt/packages/pull/7792
* [x] ssdeep - https://github.com/openwrt/packages/pull/7982
* [x] czmq - https://github.com/openwrt/packages/pull/8014
* [x] dovecot - package in upstream is actively maintainedhttps://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/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/192luci-app-unbound is a no show2019-07-08T11:07:14+02:00Ghost Userluci-app-unbound is a no showmentioned here https://forum.turris.cz/t/luci-app-unbound-is-a-no-show/7308mentioned here https://forum.turris.cz/t/luci-app-unbound-is-a-no-show/7308https://gitlab.nic.cz/turris/os/packages/-/issues/432[syslog-ng] repeated timestamp during boot time2019-07-08T09:51:12+02:00Ghost User[syslog-ng] repeated timestamp during boot time> {"kernel":"4.14.131","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"TurrisOS","version":"5.0-dev","revision":"f2eec51","target":"mvebu/cortexa9...> {"kernel":"4.14.131","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"TurrisOS","version":"5.0-dev","revision":"f2eec51","target":"mvebu/cortexa9","description":"TurrisOS 5.0-dev f2eec51"}}
___
approx the first 9/10 (554 lines out of 619) of the boot process is displaying the exact same time stamp
[boot_log_2](/uploads/a5477f95709a68bf18b7fdff5fb25b6a/boot_log_2) [boot_log_1](/uploads/c4df26f1ae0b8743bdd979a53a65443e/boot_log_1)https://gitlab.nic.cz/turris/os/packages/-/issues/395[patch suggestion TOS4.x] wg version bump 0.0.201904062019-07-02T11:13:34+02:00Ghost User[patch suggestion TOS4.x] wg version bump 0.0.20190406the wg package (0.0.2019**0123**) in upstream trunk 18.06 appears to be scarce of maintenance, the maintainer incidently being the source developer.
On the other hand in upstream Master the said package is maintained by others and fea...the wg package (0.0.2019**0123**) in upstream trunk 18.06 appears to be scarce of maintenance, the maintainer incidently being the source developer.
On the other hand in upstream Master the said package is maintained by others and featuring wg current source version 0.0.2019**0406**
Since it is unclear when upstream Master will be branched of to 19.x, and subsequent TOS5.x, it would be appreciated if TOS4.x could feature the current wg source version and not trail behind for whatever unforeseeable period till TOS5.x is released.https://gitlab.nic.cz/turris/os/packages/-/issues/428[feature suggestion] enhance protection for WAN remote access with port knocking2019-07-01T07:29:44+02:00Ghost User[feature suggestion] enhance protection for WAN remote access with port knockingSurely it would introduce complexity (feature implementation server and client side) and I am not aware of the underlying security measures that ship with fosquitto wan access, just since it adds to the firewall
```
config rule 'wan_fos...Surely it would introduce complexity (feature implementation server and client side) and I am not aware of the underlying security measures that ship with fosquitto wan access, just since it adds to the firewall
```
config rule 'wan_fosquitto_turris_rule'
option name 'fosquitto_wan'
option target 'ACCEPT'
option proto 'tcp'
option src 'wan'
option enabled '1'
option dest_port ''
```
been wondering whether it might be worth considering to utilize port knocking as added security layer in order to obfuscate/mitigate port access?Štěpán HenekŠtěpán Henekhttps://gitlab.nic.cz/turris/os/packages/-/issues/426required package python3-cryptography not available2019-06-26T20:33:53+02:00Ghost Userrequired package python3-cryptography not available> {"kernel":"4.14.129","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"TurrisOS","version":"5.0-dev","revision":"08e8aeb","target":"mvebu/cortexa9...> {"kernel":"4.14.129","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"TurrisOS","version":"5.0-dev","revision":"08e8aeb","target":"mvebu/cortexa9","description":"TurrisOS 5.0-dev 08e8aeb"}}
___
started to appear with today's 09:45 hrs build
```
ERROR:
inconsistent: Package sentinel-certgen requires package python3-cryptography that is not available.
```https://gitlab.nic.cz/turris/os/packages/-/issues/383sentinel-proxy: Setup cron jobs to renew certificate periodically2019-06-25T17:13:46+02:00Vojtech Myslivecsentinel-proxy: Setup cron jobs to renew certificate periodically1. ~~*Sentinel:Certgen* should not run during start proccess of *Sentinel:Proxy* service (init script)~~
2. ~~First certificate should be issued during *postinst script*~~
3. *Sentinel:Certgen* must be run periodically to renew the certi...1. ~~*Sentinel:Certgen* should not run during start proccess of *Sentinel:Proxy* service (init script)~~
2. ~~First certificate should be issued during *postinst script*~~
3. *Sentinel:Certgen* must be run periodically to renew the certificate for *Sentinel:Proxy* in time
**UPDATE**: After an exhausting discussion, we agreed on following:
- [x] *Sentinel:Proxy* service will run *Sentinel:Certgen* before running *Sentinel:Proxy* itself however, it will run it in sh script so service start and boot potentially will not hang on Certgen call
- [x] *Sentinel:Certgen* must be run periodically to renew the certificate for *Sentinel:Proxy* in timeTurris OS 4.0https://gitlab.nic.cz/turris/os/packages/-/issues/408Nexcloud 16.0.1 (on Turris 4.0 beta2), php error `DateTimeZone::__construct()...2019-06-24T11:02:19+02:00Robert IvánekNexcloud 16.0.1 (on Turris 4.0 beta2), php error `DateTimeZone::__construct(): Unknown or bad timezone`The `nextloud` is full of php error messages:
```
Error PHP DateTimeZone::__construct(): Unknown or bad timezone (Europe/Zurich) at /srv/www/nextcloud/lib/private/DateTimeZone.php#66
```
I tried to set `date.timezone = "Europe/Zurich"`...The `nextloud` is full of php error messages:
```
Error PHP DateTimeZone::__construct(): Unknown or bad timezone (Europe/Zurich) at /srv/www/nextcloud/lib/private/DateTimeZone.php#66
```
I tried to set `date.timezone = "Europe/Zurich"` in `/etc/php.ini` but it did not help.
I also notice that `/etc/localtime` is a symlink to `/tmp/localtime` which does not exists on my system. Even if correcting the link to `/usr/share/zoneinfo/GMT+1` the php error still persists.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/422suricata-monitor 1.0-6 package is missing /usr/libexec/suricata-fill_dns.py a...2019-06-23T16:12:22+02:00martinlsuricata-monitor 1.0-6 package is missing /usr/libexec/suricata-fill_dns.py and /usr/libexec/suricata-squash_flows.py```
$ cat /etc/turris-version
3.11.5
$ opkg files suricata-monitor
Package suricata-monitor (1.0-6) is installed on root and has the following files:
/lib/upgrade/keep.d/suricata-monitor
/etc/config/suricata-monitor
/etc/suricata-monit...```
$ cat /etc/turris-version
3.11.5
$ opkg files suricata-monitor
Package suricata-monitor (1.0-6) is installed on root and has the following files:
/lib/upgrade/keep.d/suricata-monitor
/etc/config/suricata-monitor
/etc/suricata-monitor/alert.tmpl
/usr/bin/suricata-monitor
/etc/cron.d/suricata-monitor
/etc/suricata-pakon/output_conf.d/suricata-monitor.yaml
/etc/init.d/suricata-monitor
```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.