Turris OS packages issueshttps://gitlab.nic.cz/turris/os/packages/-/issues2019-10-10T12:51:02+02:00https://gitlab.nic.cz/turris/os/packages/-/issues/492[unbound] version bump 1.9.4 (fix for vulnerability CVE-2019-16866)2019-10-10T12:51:02+02:00Ghost User[unbound] version bump 1.9.4 (fix for vulnerability CVE-2019-16866)https://github.com/NLnetLabs/unbound/releases/tag/release-1.9.4
> This release is a fix for vulnerability CVE-2019-16866 that causes a failure when a specially crafted query is received.
>
> Bug Fixes:
> - Fix for the reported...https://github.com/NLnetLabs/unbound/releases/tag/release-1.9.4
> This release is a fix for vulnerability CVE-2019-16866 that causes a failure when a specially crafted query is received.
>
> Bug Fixes:
> - Fix for the reported vulnerability.
>
> The CVE number for this vulnerability is CVE-2019-16866
>
> == Summary
> Recent versions of Unbound contain a problem that may cause Unbound to
> crash after receiving a specially crafted query. This issue can only be
> triggered by queries received from addresses allowed by Unbound's ACL.
>
> == Affected products
> Unbound 1.7.1 up to and including 1.9.3.
>
> == Description
> Due to an error in parsing NOTIFY queries, it is possible for Unbound to
> continue processing malformed queries and may ultimately result in a
> pointer dereference in uninitialized memory. This results in a crash of
> the Unbound daemon.
>
> Whether this issue leads to a crash depends on the content of the
> uninitialized memory space and cannot be predicted. This issue can only
> be triggered by queries received from addresses that are allowed to send
> queries according to Unbound's ACL (access-control in the Unbound
> configuration).
>
> == Solution
> Download patched version of Unbound, or apply the patch manually.
>
> + Downloading patched version
> Unbound 1.9.4 is released with the patch
> https://nlnetlabs.nl/downloads/unbound/unbound-1.9.4.tar.gz
>
> + Applying the Patch manually
> For Unbound 1.7.1 up to and including 1.9.3 the patch is:
> https://nlnetlabs.nl/downloads/unbound/patch_cve_2019-16866.diff
>
> Apply the patch on Unbound source directory with:
> 'patch -p0 < patch_cve_2019-16866.diff'
> then run 'make install' to install Unboun d.Turris OS 3.11.8https://gitlab.nic.cz/turris/os/packages/-/issues/483nexcloud: install error2019-09-12T14:35:18+02:00Jan Pavlinecnexcloud: install errorNextcloud install ends with the following error (tested on 3.11.6 and 3.11.7 prerc)
```
Configuring php7-fpm.
Configuring php7-mod-xml.
Configuring php7-mod-zip.
Configuring php7-mod-gd.
Configuring nextcloud.
Configuring php7-mod-pdo....Nextcloud install ends with the following error (tested on 3.11.6 and 3.11.7 prerc)
```
Configuring php7-fpm.
Configuring php7-mod-xml.
Configuring php7-mod-zip.
Configuring php7-mod-gd.
Configuring nextcloud.
Configuring php7-mod-pdo.
Collected errors:
Collected errors:
* check_data_file_clashes: Package libmysqlclient wants to install file /usr/lib/libm6
But that file is already provided by package * libmariadbclient
* check_data_file_clashes: Package libmysqlclient wants to install file /usr/lib/libm0
But that file is already provided by package * libmariadbclient
* opkg_install_cmd: Cannot install package nextcloud-install.
```https://gitlab.nic.cz/turris/os/packages/-/issues/413kresd: Crashes after updating Turris OS 3.11.5 RC2020-07-23T14:00:45+02:00Lukas Jelinekkresd: Crashes after updating Turris OS 3.11.5 RCAfter a clean installation of Turris OS 3.11.5 RC onto Omnia everything around DNS resolving works fine. But after the first update and reboot the DNS resolver (kresd) crashes on start with the following message:
`Error relocating /usr/...After a clean installation of Turris OS 3.11.5 RC onto Omnia everything around DNS resolving works fine. But after the first update and reboot the DNS resolver (kresd) crashes on start with the following message:
`Error relocating /usr/lib/libdnssec.so.6: gnutls_privkey_sign_data2: symbol not found`
It means that DNS resolving does not work at all. Doesn't matter whether DNSSEC is enabled or disable, the same applies for DNS over TLS.
Steps to reproduce:
1. Install 3.11.5 RC onto Omnia.
2. Pass through the guided setup. Enable automatic updates at the appropriate screen.
3. Wait until the update process finishes.
4. Reboot the router.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/packages/-/issues/405[syslog-ng] stop | restart not working2019-06-10T13:17:06+02:00Ghost User[syslog-ng] stop | restart not working"4.14.123","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta2","revision":"a6dba1a","target":"mvebu\/cortexa9","d..."4.14.123","hostname":"to","system":"ARMv7 Processor rev 1 (v7l)","model":"Turris Omnia","board_name":"armada-385-turris-omnia","release":{"distribution":"TurrisOS","version":"4.0-beta2","revision":"a6dba1a","target":"mvebu\/cortexa9","description":"TurrisOS 4.0-beta2 a6dba1a"}}
___
`/etc/init.d/syslog-ng stop` does not kill the process and instead it remains running. Also its `upd` socket remains alive.
Looking at with `htop` is seems that one `syslog-ng` child instance of its parent `supervising syslog-ng` gets terminated whilst a secondary child instance stays alive and the parent also does not terminate.
similar `/etc/init.d/syslog-ng restart`, the PID remains the same after the command been executed and it can be tested also by adding another destination in the syslog-ng conf. After the command been executed there is no file at the added destination. However, killing and starting the process manually the new log file is appearing at the added destination.
As a causality train post-installation scripts that restart `syslog-ng` do not report a fail of the restart whilst an actual restart did not happen. Same for logrotate with
```
postrotate
/etc/init.d/syslog-ng restart
```
Enclosed the `strace` logs for both events. [restart](/uploads/51e771530f577a017689333155122913/restart) [stop](/uploads/263831a45cf003dc26fd5bb346ac666a/stop)https://gitlab.nic.cz/turris/os/packages/-/issues/377resolver/unbound not listening on ipv6 iface2019-05-14T18:38:53+02:00Ghost Userresolver/unbound not listening on ipv6 iface@jpavlinec
TOS 3.11.4 | unbound 1.9.1
/etc/config/resolver
```
config resolver 'common'
list interface '127.0.0.1'
list interface '192.168.112.12'
list interface '::1'
list interface 'fd30:d64c:1eed:4c3a::12'
option forward_upstre...@jpavlinec
TOS 3.11.4 | unbound 1.9.1
/etc/config/resolver
```
config resolver 'common'
list interface '127.0.0.1'
list interface '192.168.112.12'
list interface '::1'
list interface 'fd30:d64c:1eed:4c3a::12'
option forward_upstream '0'
option prefered_resolver 'unbound'
option ignore_root_key '0'
option static_domains '1'
option dynamic_domains '1'
option keyfile '/etc/root.keys'
config resolver 'kresd'
option rundir '/tmp/kresd'
option log_stderr '1'
option log_stdout '1'
option forks '1'
option keep_cache '1'
#option include_config '/tmp/kresd.custom.conf'
#list hostname_config '/etc/hosts'
#list rpz_file '/tmp/file.rpz'
config resolver 'unbound'
option dhcp_link 'odhcpd'
option root_hints '/etc/unbound/named.cache'
config resolver 'unbound_includes'
list include_path "/etc/unbound/unbound_srv.conf"
list include_path "/etc/unbound/unbound_ext.conf"
config resolver 'unbound_remote_control'
option control_enable 'yes'
option control_use_cert 'no'
list control_interface '::1'
list control_interface '127.0.0.1'
```
With the above config it is expected that the resolver/unbound would be listening on the respective ipv4/ipv6 ifaces/addresses but it is only listening on the listed ipv4 ifaces/addresses but not on the ipv6.
![listening_ports](/uploads/74f0d80b246c432d69b6956d7a25c11e/listening_ports.png)Jan PavlinecJan Pavlinechttps://gitlab.nic.cz/turris/os/packages/-/issues/364keepalived: requires kmod-nf-ipvs2023-08-16T14:57:32+02:00Jan Pavlineckeepalived: requires kmod-nf-ipvsThis requirement prevents new keepalived from installing
Related forum topic https://forum.turris.cz/t/keepalived-depends-on-kmod-nf-ipvs-which-is-not-available/10036This requirement prevents new keepalived from installing
Related forum topic https://forum.turris.cz/t/keepalived-depends-on-kmod-nf-ipvs-which-is-not-available/10036https://gitlab.nic.cz/turris/os/packages/-/issues/349resolver-conf: add option for multiple ipv4/ipv6 address2020-03-20T13:31:15+01:00Jan Pavlinecresolver-conf: add option for multiple ipv4/ipv6 addressSupport multiple ipv4/ipv6 address in dns_servers config filesSupport multiple ipv4/ipv6 address in dns_servers config filesTurris OS 3.11.6Jan PavlinecJan Pavlinechttps://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/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/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 20141012