[Touch-packages] [Bug 1926964] [NEW] missing libapt-pkg4.12 dependency
Public bug reported: It seems python-apt from ubuntu precise ESM made it into the old precise-security repo. Unfortunately, it depends on libapt-pkg4.12 (>= 0.8.16~exp12ubuntu10.28), which is not available. The following packages have unmet dependencies: python-apt : Depends: libapt-pkg4.12 (>= 0.8.16~exp12ubuntu10.28) but 0.8.16~exp12ubuntu10.27 is to be installed ** Affects: python-apt (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1926964 Title: missing libapt-pkg4.12 dependency Status in python-apt package in Ubuntu: New Bug description: It seems python-apt from ubuntu precise ESM made it into the old precise-security repo. Unfortunately, it depends on libapt-pkg4.12 (>= 0.8.16~exp12ubuntu10.28), which is not available. The following packages have unmet dependencies: python-apt : Depends: libapt-pkg4.12 (>= 0.8.16~exp12ubuntu10.28) but 0.8.16~exp12ubuntu10.27 is to be installed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1926964/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1823053] Re: wpasupplicant 2.6 w/ openssl 1.1.1 triggers TLSv1.3 version intolerance on WPA2-Enterprise networks on Cosmic and Disco
It seems this is also applicable to ubuntu bionic since openssl 1.1.1 landed in bionic-updates. We have bionic clients that cannot connect to the enterprise wifi because they attempt TLS 1.3. Recompiling openssl with the "no-tls1_3" Configure option fixes the problem. See also https://github.com/FreeRADIUS/freeradius-server/issues/2385 ** Bug watch added: github.com/FreeRADIUS/freeradius-server/issues #2385 https://github.com/FreeRADIUS/freeradius-server/issues/2385 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wpa in Ubuntu. https://bugs.launchpad.net/bugs/1823053 Title: wpasupplicant 2.6 w/ openssl 1.1.1 triggers TLSv1.3 version intolerance on WPA2-Enterprise networks on Cosmic and Disco Status in wpa package in Ubuntu: New Bug description: Ubuntu 18.10 "Cosmic" and 19.04 "Disco" currently ship with both wpasupplicant 2.6 and openssl/libssl 1.1.1, although upstream only supports OpenSSL 1.1.1 starting with wpasupplicant 2.7. OpenSSL 1.1.1 introduced support for TLS 1.3, and introduced new APIs to configure the parameters governing TLS connections using TLS >= 1.3. OpenSSL also decided that it would enable TLS 1.3 by default even for software that had only been built for libssl <= 1.1.0 and hence couldn't "know" about the new APIs. This leads to a situation where software that was designed/built for OpenSSL 1.1.0 and TLS 1.2 will also offer TLS 1.3, without any possibility for end users to disable such behavior. One case where this causes problems is wpasupplicant: wpasupplicant 2.7 officially introduced support for OpenSSL 1.1.1, which mainly consists of disabling TLS 1.3 by default and adding a configuration flag allowing end users to selectively enable it for connections when they see fit. wpasupplicant 2.6, however, as shipped with Ubuntu 18.10 and 19.04, does not offer such a possibility, and hence tries negotiating TLS 1.3 (alongside with older versions all the way down to TLS 1.0). Sadly, there are RADIUS servers which suffer from TLS version intolerance and will refuse authentication when the client offers TLS 1.3. I know of such a case with a German university's eduroam wifi, but I doubt this is the only case where this causes problems. As a dirty stopgap measure, I've installed the wpasupplicant 2.7 package from Debian Buster (https://packages.debian.org/buster/wpasupplicant), and I've asked the NOC at the affected university to upgrade/reconfigure their RADIUS server to make the version intolerance go away - but still, this is a bug that should be fixed in Ubuntu, preferably by backporting wpasupplicant 2.7. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1823053/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1745463] Re: Disabling systemd-resolved breaks dhclient resolvconf integration
I quite agree with @GeekSmith here. We disabled systemd-resolved on bionic and install ifupdown instead since we install this on server that have a static configuration and we don't want systemd-resolved to modify anything in the resolv.conf file. Only during the initial installation time of the server we use dhclient to get an IP address. The result is that the resolv.conf file is not modified by dhclient despite systemd-resolved being disabled. To work around this issue, we simply deleted the /etc/dhcp/dhclient-enter- hooks.d/resolved file as we don't need it anyway. A cleaner way of course it to actually test in the file if systemd- resolved is used, as @GeekSmith's patch does. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1745463 Title: Disabling systemd-resolved breaks dhclient resolvconf integration Status in resolvconf package in Ubuntu: Expired Status in systemd package in Ubuntu: Invalid Bug description: To reproduce, mask resolved: sudo systemctl mask systemd-resolved.service ...then disable network-manager for ifupdown interfaces: $cat /etc/NetworkManager/NetworkManager.conf [main] plugins=ifupdown,keyfile dns=default rc-manager=resolvconf [ifupdown] managed=false [device] wifi.scan-rand-mac-address=no ...and reboot. You'll note that resolvconf integration with dhclient is now broken. Interfaces listed in /etc/network/interfaces or /etc/network/interfaces.d/* will not provide DNS configuration in /etc/resolv.conf and /run/resolvconf/interfaces/. This is because /etc/dhcp/dhclient-enter-hooks.d/resolvconf defines "make_resolv_conf()" as a valid function for the BOUND case, but /etc/dhcp/dhclient-enter-hooks.d/resolved undefines it (who's nasty now, eh?) even though resolved is masked. The file existence check in the beginning of /etc/dhcp/dhclient-enter- hooks.d/resolved should be more thorough, i.e. it should ensure that resolved is enabled, rather than simply look for the existence of /lib/systemd/systemd-resolved. This works for me: -if [ -x /lib/systemd/systemd-resolved ] ; then +if [ -x /lib/systemd/systemd-resolved ] && systemctl -q is-enabled systemd-resolved ; then Arguably, /etc/dhcp/dhclient-enter-hooks.d/resolvconf should implement a similar check, looking for /run/resolvconf/enable-updates as a condition for meddling with DNS settings. If desired, I'll file a separate bug for that package. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1745463/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1745463] Re: Disabling systemd-resolved breaks dhclient resolvconf integration
Just clarifying that we don't use the resolvconf package either, but just a plain static /etc/resolv.conf file. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1745463 Title: Disabling systemd-resolved breaks dhclient resolvconf integration Status in resolvconf package in Ubuntu: Expired Status in systemd package in Ubuntu: Invalid Bug description: To reproduce, mask resolved: sudo systemctl mask systemd-resolved.service ...then disable network-manager for ifupdown interfaces: $cat /etc/NetworkManager/NetworkManager.conf [main] plugins=ifupdown,keyfile dns=default rc-manager=resolvconf [ifupdown] managed=false [device] wifi.scan-rand-mac-address=no ...and reboot. You'll note that resolvconf integration with dhclient is now broken. Interfaces listed in /etc/network/interfaces or /etc/network/interfaces.d/* will not provide DNS configuration in /etc/resolv.conf and /run/resolvconf/interfaces/. This is because /etc/dhcp/dhclient-enter-hooks.d/resolvconf defines "make_resolv_conf()" as a valid function for the BOUND case, but /etc/dhcp/dhclient-enter-hooks.d/resolved undefines it (who's nasty now, eh?) even though resolved is masked. The file existence check in the beginning of /etc/dhcp/dhclient-enter- hooks.d/resolved should be more thorough, i.e. it should ensure that resolved is enabled, rather than simply look for the existence of /lib/systemd/systemd-resolved. This works for me: -if [ -x /lib/systemd/systemd-resolved ] ; then +if [ -x /lib/systemd/systemd-resolved ] && systemctl -q is-enabled systemd-resolved ; then Arguably, /etc/dhcp/dhclient-enter-hooks.d/resolvconf should implement a similar check, looking for /run/resolvconf/enable-updates as a condition for meddling with DNS settings. If desired, I'll file a separate bug for that package. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1745463/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1811861] Re: incorrect permissions on /var/log after debootstrap
Sorry for the noise, it seems this is not related to rsyslog after all. In our install process we are moving /var/log to another partition (mounted in /data/) and then symlink it to /var/log. Permissions are set up properly and work while the system is running. When the system is rebooted though there is an unknown process changing the permissions of /data/log, my best guess something related to systemd. When we bind mount /data/log in /var/log directory we don't have this issue though. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1811861 Title: incorrect permissions on /var/log after debootstrap Status in rsyslog package in Ubuntu: New Bug description: we are debootstrapping a full bionic distribution into a directory. After debootstrapping the permissions on /var/log are incorrect, causing rsyslog to fail because it cannot write into the directory to create the various files. Also, in the postinst of the rsyslog package I see that systemd-tmpfiles is attempted to be used to create the files defined in /usr/lib/tmpfiles.d/00rsyslog.conf, but from what I can tell this will never work because of the systemd-tmpfiles manpage: --create If this option is passed, all files and directories marked with f, F, w, d, D, v, p, L, c, b, m in the configuration files are created or written to. Files and directories marked with z, Z, t, T, a, and A have their ownership, access mode and security labels set. Since the files are configured with type "z" only ownership, access mode and security will be updated. # lsb_release -rd Description: Ubuntu 18.04.1 LTS Release: 18.04 # apt-cache policy rsyslog rsyslog: Installed: 8.32.0-1ubuntu4 Candidate: 8.32.0-1ubuntu4 Version table: *** 8.32.0-1ubuntu4 100 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1811861/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1811861] Re: incorrect permissions on /var/log after debootstrap
Actually, it looks like this is already fixed in cosmic. Can this be ported to bionic as well? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1811861 Title: incorrect permissions on /var/log after debootstrap Status in rsyslog package in Ubuntu: New Bug description: we are debootstrapping a full bionic distribution into a directory. After debootstrapping the permissions on /var/log are incorrect, causing rsyslog to fail because it cannot write into the directory to create the various files. Also, in the postinst of the rsyslog package I see that systemd-tmpfiles is attempted to be used to create the files defined in /usr/lib/tmpfiles.d/00rsyslog.conf, but from what I can tell this will never work because of the systemd-tmpfiles manpage: --create If this option is passed, all files and directories marked with f, F, w, d, D, v, p, L, c, b, m in the configuration files are created or written to. Files and directories marked with z, Z, t, T, a, and A have their ownership, access mode and security labels set. Since the files are configured with type "z" only ownership, access mode and security will be updated. # lsb_release -rd Description: Ubuntu 18.04.1 LTS Release: 18.04 # apt-cache policy rsyslog rsyslog: Installed: 8.32.0-1ubuntu4 Candidate: 8.32.0-1ubuntu4 Version table: *** 8.32.0-1ubuntu4 100 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1811861/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1811861] [NEW] incorrect permissions on /var/log after debootstrap
Public bug reported: we are debootstrapping a full bionic distribution into a directory. After debootstrapping the permissions on /var/log are incorrect, causing rsyslog to fail because it cannot write into the directory to create the various files. Also, in the postinst of the rsyslog package I see that systemd-tmpfiles is attempted to be used to create the files defined in /usr/lib/tmpfiles.d/00rsyslog.conf, but from what I can tell this will never work because of the systemd-tmpfiles manpage: --create If this option is passed, all files and directories marked with f, F, w, d, D, v, p, L, c, b, m in the configuration files are created or written to. Files and directories marked with z, Z, t, T, a, and A have their ownership, access mode and security labels set. Since the files are configured with type "z" only ownership, access mode and security will be updated. # lsb_release -rd Description:Ubuntu 18.04.1 LTS Release:18.04 # apt-cache policy rsyslog rsyslog: Installed: 8.32.0-1ubuntu4 Candidate: 8.32.0-1ubuntu4 Version table: *** 8.32.0-1ubuntu4 100 100 /var/lib/dpkg/status ** Affects: rsyslog (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1811861 Title: incorrect permissions on /var/log after debootstrap Status in rsyslog package in Ubuntu: New Bug description: we are debootstrapping a full bionic distribution into a directory. After debootstrapping the permissions on /var/log are incorrect, causing rsyslog to fail because it cannot write into the directory to create the various files. Also, in the postinst of the rsyslog package I see that systemd-tmpfiles is attempted to be used to create the files defined in /usr/lib/tmpfiles.d/00rsyslog.conf, but from what I can tell this will never work because of the systemd-tmpfiles manpage: --create If this option is passed, all files and directories marked with f, F, w, d, D, v, p, L, c, b, m in the configuration files are created or written to. Files and directories marked with z, Z, t, T, a, and A have their ownership, access mode and security labels set. Since the files are configured with type "z" only ownership, access mode and security will be updated. # lsb_release -rd Description: Ubuntu 18.04.1 LTS Release: 18.04 # apt-cache policy rsyslog rsyslog: Installed: 8.32.0-1ubuntu4 Candidate: 8.32.0-1ubuntu4 Version table: *** 8.32.0-1ubuntu4 100 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1811861/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
