[Touch-packages] [Bug 1904166] Re: chpasswd can't change password with libpam-passwdqc enabled
The solution is to provide a dedicated pam configuration for chpasswd without the ask_oldauthtok option. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1904166 Title: chpasswd can't change password with libpam-passwdqc enabled Status in shadow package in Ubuntu: New Bug description: Hello. We are unable to change user password using chpasswd with libpam- passwdqc, it seems to miss detect old password: root@server:~# echo 'root:hearth=mirth-Double' | chpasswd […] Weak password: is the same as the old one. Try again. root@server:~# echo $? 1 I tried the following to make sure the old password was not the same: root@server:~# echo 'root:foo' | chpasswd -c SHA512 root@server:~# echo 'root:hearth=mirth-Double' | chpasswd […] Weak password: is the same as the old one. Try again. root@server:~# echo $? 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1904166/+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 1904166] Re: chpasswd can't change password with libpam-passwdqc enabled
To reproduce: apt install libpam-passwdqc sed -i -e 's/\(pam_passwdqc.so\)/\1 ask_oldauthtok/' /etc/pam.d/common-password echo 'root:hearth=mirth-Double' | chpasswd -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1904166 Title: chpasswd can't change password with libpam-passwdqc enabled Status in shadow package in Ubuntu: New Bug description: Hello. We are unable to change user password using chpasswd with libpam- passwdqc, it seems to miss detect old password: root@server:~# echo 'root:hearth=mirth-Double' | chpasswd […] Weak password: is the same as the old one. Try again. root@server:~# echo $? 1 I tried the following to make sure the old password was not the same: root@server:~# echo 'root:foo' | chpasswd -c SHA512 root@server:~# echo 'root:hearth=mirth-Double' | chpasswd […] Weak password: is the same as the old one. Try again. root@server:~# echo $? 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1904166/+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 1904166] Re: chpasswd can't change password with libpam-passwdqc enabled
It may be due to the libpam-passwdqc configuration using ask_oldauthtok and similar=deny. It was working fine on Bionic but fails with Focal. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1904166 Title: chpasswd can't change password with libpam-passwdqc enabled Status in shadow package in Ubuntu: New Bug description: Hello. We are unable to change user password using chpasswd with libpam- passwdqc, it seems to miss detect old password: root@server:~# echo 'root:hearth=mirth-Double' | chpasswd […] Weak password: is the same as the old one. Try again. root@server:~# echo $? 1 I tried the following to make sure the old password was not the same: root@server:~# echo 'root:foo' | chpasswd -c SHA512 root@server:~# echo 'root:hearth=mirth-Double' | chpasswd […] Weak password: is the same as the old one. Try again. root@server:~# echo $? 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1904166/+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 1904166] [NEW] chpasswd can't change password with libpam-passwdqc enabled
Public bug reported: Hello. We are unable to change user password using chpasswd with libpam- passwdqc, it seems to miss detect old password: root@server:~# echo 'root:hearth=mirth-Double' | chpasswd […] Weak password: is the same as the old one. Try again. root@server:~# echo $? 1 I tried the following to make sure the old password was not the same: root@server:~# echo 'root:foo' | chpasswd -c SHA512 root@server:~# echo 'root:hearth=mirth-Double' | chpasswd […] Weak password: is the same as the old one. Try again. root@server:~# echo $? 1 ** Affects: shadow (Ubuntu) Importance: Undecided Status: New ** Tags: focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1904166 Title: chpasswd can't change password with libpam-passwdqc enabled Status in shadow package in Ubuntu: New Bug description: Hello. We are unable to change user password using chpasswd with libpam- passwdqc, it seems to miss detect old password: root@server:~# echo 'root:hearth=mirth-Double' | chpasswd […] Weak password: is the same as the old one. Try again. root@server:~# echo $? 1 I tried the following to make sure the old password was not the same: root@server:~# echo 'root:foo' | chpasswd -c SHA512 root@server:~# echo 'root:hearth=mirth-Double' | chpasswd […] Weak password: is the same as the old one. Try again. root@server:~# echo $? 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1904166/+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 1794523] Re: lxc-net.service is not properly ordered with network-online.target
There is still a problem :-/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1794523 Title: lxc-net.service is not properly ordered with network-online.target Status in lxc package in Ubuntu: Expired Bug description: I made several tests and I figure out that the lxc-net.service is missing a Wants= directive to be properly ordered against network- online.target. As I understand the systemd.unit manpage, to be properly ordered a unit must define a Requires=/Wants= in addition to an After=/Before=. Regards. Distributor ID: Ubuntu Description: Ubuntu 18.04.1 LTS Release: 18.04 Codename: bionic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1794523/+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 1861880] Re: lxc-attach command does not return error exit code if the command is failed
OK for us with 1:4.0.1-0ubuntu2 package on focal : root@scribe:~# lxc-start --version 4.0.1 root@scribe:~# lxc-attach --logpriority=DEBUG --name=addc -- exit lxc-attach: addc: attach.c: lxc_attach_run_command: 1452 No such file or directory - Failed to exec "exit" root@scribe:~# echo $? 127 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1861880 Title: lxc-attach command does not return error exit code if the command is failed Status in lxc package in Ubuntu: Fix Released Status in lxc package in Debian: Fix Released Bug description: lxc-attach command does not return error exit code if the command is failed on Ubuntu Focal : root@scribe:~# lxc-start --version 3.0.4 root@scribe:~# lxc-attach --logpriority=DEBUG --name=addc -- exit lxc-attach: addc: attach.c: lxc_attach_run_command: 1489 No such file or directory - Failed to exec "exit" root@scribe:~# echo $? 0 The problem is fixed upstream : https://github.com/lxc/lxc/issues/3104 and by Debian : https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=934983 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: lxc-utils 3.0.4-0ubuntu2 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Tue Feb 4 16:01:30 2020 InstallationDate: Installed on 2020-01-10 (25 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Alpha amd64 (20200105) SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) defaults.conf: lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up lxc.net.0.hwaddr = 00:16:3e:xx:xx:xx lxc-net.default: USE_LXC_BRIDGE="true" LXC_BRIDGE="br0" LXC_ADDR="192.0.2.1" LXC_NETMASK="255.255.255.0" LXC_NETWORK="192.0.2.0/24" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1861880/+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 1794523] Re: lxc-net.service is not properly ordered with network-online.target
Hello. Only the Requires= will make it fail, no Wants= A weaker version of Requires=. Units listed in this option will be started if the configuring unit is. However, if the listed units fail to start or cannot be added to the transaction, this has no impact on the validity of the transaction as a whole. This is the recommended way to hook start-up of one unit to the start-up of another unit. https://manpages.ubuntu.com/manpages/bionic/en/man5/systemd.unit.5.html Regards. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1794523 Title: lxc-net.service is not properly ordered with network-online.target Status in lxc package in Ubuntu: Incomplete Bug description: I made several tests and I figure out that the lxc-net.service is missing a Wants= directive to be properly ordered against network- online.target. As I understand the systemd.unit manpage, to be properly ordered a unit must define a Requires=/Wants= in addition to an After=/Before=. Regards. Distributor ID: Ubuntu Description: Ubuntu 18.04.1 LTS Release: 18.04 Codename: bionic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1794523/+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 1861880] [NEW] lxc-attach command does not return error exit code if the command is failed
Public bug reported: lxc-attach command does not return error exit code if the command is failed on Ubuntu Focal : root@scribe:~# lxc-start --version 3.0.4 root@scribe:~# lxc-attach --logpriority=DEBUG --name=addc -- exit lxc-attach: addc: attach.c: lxc_attach_run_command: 1489 No such file or directory - Failed to exec "exit" root@scribe:~# echo $? 0 The problem is fixed upstream : https://github.com/lxc/lxc/issues/3104 and by Debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934983 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: lxc-utils 3.0.4-0ubuntu2 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Tue Feb 4 16:01:30 2020 InstallationDate: Installed on 2020-01-10 (25 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Alpha amd64 (20200105) SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) defaults.conf: lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up lxc.net.0.hwaddr = 00:16:3e:xx:xx:xx lxc-net.default: USE_LXC_BRIDGE="true" LXC_BRIDGE="br0" LXC_ADDR="192.0.2.1" LXC_NETMASK="255.255.255.0" LXC_NETWORK="192.0.2.0/24" ** Affects: lxc (Ubuntu) Importance: Undecided Status: New ** Affects: lxc (Debian) Importance: Unknown Status: Unknown ** Tags: amd64 apparmor apport-bug focal uec-images ** Bug watch added: Debian Bug tracker #934983 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934983 ** Also affects: lxc (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934983 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1861880 Title: lxc-attach command does not return error exit code if the command is failed Status in lxc package in Ubuntu: New Status in lxc package in Debian: Unknown Bug description: lxc-attach command does not return error exit code if the command is failed on Ubuntu Focal : root@scribe:~# lxc-start --version 3.0.4 root@scribe:~# lxc-attach --logpriority=DEBUG --name=addc -- exit lxc-attach: addc: attach.c: lxc_attach_run_command: 1489 No such file or directory - Failed to exec "exit" root@scribe:~# echo $? 0 The problem is fixed upstream : https://github.com/lxc/lxc/issues/3104 and by Debian : https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=934983 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: lxc-utils 3.0.4-0ubuntu2 ProcVersionSignature: Ubuntu 5.4.0-12.15-generic 5.4.8 Uname: Linux 5.4.0-12-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Tue Feb 4 16:01:30 2020 InstallationDate: Installed on 2020-01-10 (25 days ago) InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Alpha amd64 (20200105) SourcePackage: lxc UpgradeStatus: No upgrade log present (probably fresh install) defaults.conf: lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up lxc.net.0.hwaddr = 00:16:3e:xx:xx:xx lxc-net.default: USE_LXC_BRIDGE="true" LXC_BRIDGE="br0" LXC_ADDR="192.0.2.1" LXC_NETMASK="255.255.255.0" LXC_NETWORK="192.0.2.0/24" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1861880/+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 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
Thank @xnox, I just made the test and I have the same issue with rebuilt python3.6. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1797386 Title: [SRU] OpenSSL 1.1.1 to 18.04 LTS Status in openssl package in Ubuntu: In Progress Status in salt package in Ubuntu: New Status in libio-socket-ssl-perl source package in Bionic: New Status in libnet-ssleay-perl source package in Bionic: New Status in nova source package in Bionic: New Status in openssl source package in Bionic: Fix Committed Status in python-cryptography source package in Bionic: New Status in python2.7 source package in Bionic: New Status in python3.6 source package in Bionic: New Status in python3.7 source package in Bionic: New Status in r-cran-openssl source package in Bionic: Fix Committed Status in ruby-openssl source package in Bionic: Fix Committed Status in ruby2.5 source package in Bionic: New Status in salt source package in Bionic: New Bug description: [Impact] * OpenSSL 1.1.1 is an LTS release upstream, which will continue to receive security support for much longer than 1.1.0 series will. * OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to be rapidly adopted due to increased set of supported hashes & algoes, as well as improved handshake [re-]negotiation. * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities. * OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software is sensitive to the negotiation handshake and may either need patches/improvements or clamp-down to maximum v1.2. [Test Case] * Rebuild all reverse dependencies * Execute autopkg tests for all of them * Clamp down to TLS v1.2 software that does not support TLS v1.3 (e.g. mongodb) * Backport TLS v1.3 support patches, where applicable [Test cases for the python updates] python3.7 is a preview in bionic as a non-supported/non-default version of python3. Passing it's own autopkgtests is sufficient validation for python3.7. It includes a point release update, with OpenSSL 1.1.1 compat and features. python3.6 not only has OpenSSL 1.1.1 compat and features patches, but also includes a point release update to 3.6.8. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python3.6 and python3-defaults with regressions already fixed in the individual packages as appropriate. python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1 compat only. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python2.7 and python-defaults with regressions already fixed in the individual packages as appropriate. [Regression Potential] * Connectivity interop is the biggest issues which will be unavoidable with introducing TLS v1.3. However, tests on cosmic demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and negotiate TLS v1.3 without issues. * Mitigation of discovered connectivity issues will be possible by clamping down to TLS v1.2 in either server-side or client-side software or by backporting relevant support fixes * Notable changes are listed here https://wiki.openssl.org/index.php/TLS1.3 * Most common connectivity issues so far: - client verifies SNI in TLSv1.3 mode, yet client doesn't set hostname. Solution is client change to set hostname, or to clamp down the client to TLSv1.2. - session negotiation is different in TLSv1.3, existing client code may fail to create/negotiate/resume session. Clients need to learn how to use session callback. * This update bundles python 3.6 and 3.7 point releases [Other Info] * Previous FFe for OpenSSL in 18.10 is at https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1793092 * TLS v1.3 support in NSS is expected to make it to 18.04 via security updates * TLS v1.3 support in GnuTLS is expected to be available in 19.04 * Test OpenSSL is being prepared in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3473 [Autopkgtest Regressions] dovecot/armhf - flakey libnet-ssleay-perl - awaiting sru accept into proposed of libnet-ssleay-perl and libio-socket-ssl-perl due to fixes and versioned breaks. linux* - rebuild testcases passes (for some edge flavours the build fails in non-ssl portions of the build), ubuntu-regression-suite testcase fails for a few variants but should have been skipped (in progress to be fixed in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823056) openvswitch/i386 - extremely flakey, errors out or fails mostly To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to :
[Touch-packages] [Bug 1797386] Re: [SRU] OpenSSL 1.1.1 to 18.04 LTS
The libssl1.1 version 1.1.1-1ubuntu2.1~18.04.1 breaks salt package version 2017.7.4+dfsg1-1: root@server:~# salt-key -L Error: unknown error (_ssl.c:2788) root@server:~# salt --versions-report Traceback (most recent call last): File "/usr/bin/salt", line 10, in salt_main() File "/usr/lib/python3/dist-packages/salt/scripts.py", line 476, in salt_main client.run() File "/usr/lib/python3/dist-packages/salt/cli/salt.py", line 33, in run import salt.client File "/usr/lib/python3/dist-packages/salt/client/__init__.py", line 31, in import salt.cache File "/usr/lib/python3/dist-packages/salt/cache/__init__.py", line 18, in import salt.loader File "/usr/lib/python3/dist-packages/salt/loader.py", line 26, in import salt.utils.event File "/usr/lib/python3/dist-packages/salt/utils/event.py", line 70, in import tornado.iostream File "/usr/lib/python3/dist-packages/tornado/iostream.py", line 40, in from tornado.netutil import ssl_wrap_socket, ssl_match_hostname, SSLCertificateError, _client_ssl_defaults, _server_ssl_defaults File "/usr/lib/python3/dist-packages/tornado/netutil.py", line 57, in ssl.Purpose.SERVER_AUTH) File "/usr/lib/python3.6/ssl.py", line 502, in create_default_context context = SSLContext(PROTOCOL_TLS) File "/usr/lib/python3.6/ssl.py", line 391, in __new__ self = _SSLContext.__new__(cls, protocol) ssl.SSLError: unknown error (_ssl.c:2788) Seems to be python3.6 which is impacted. Regards. ** Also affects: salt (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1797386 Title: [SRU] OpenSSL 1.1.1 to 18.04 LTS Status in openssl package in Ubuntu: In Progress Status in salt package in Ubuntu: New Status in libio-socket-ssl-perl source package in Bionic: New Status in libnet-ssleay-perl source package in Bionic: New Status in nova source package in Bionic: New Status in openssl source package in Bionic: Fix Committed Status in python-cryptography source package in Bionic: New Status in python2.7 source package in Bionic: New Status in python3.6 source package in Bionic: New Status in python3.7 source package in Bionic: New Status in r-cran-openssl source package in Bionic: Fix Committed Status in ruby-openssl source package in Bionic: Fix Committed Status in ruby2.5 source package in Bionic: New Status in salt source package in Bionic: New Bug description: [Impact] * OpenSSL 1.1.1 is an LTS release upstream, which will continue to receive security support for much longer than 1.1.0 series will. * OpenSSL 1.1.1 comes with support for TLS v1.3 which is expected to be rapidly adopted due to increased set of supported hashes & algoes, as well as improved handshake [re-]negotiation. * OpenSSL 1.1.1 comes with improved hw-acceleration capabilities. * OpenSSL 1.1.1 is ABI/API compatible with 1.1.0, however some software is sensitive to the negotiation handshake and may either need patches/improvements or clamp-down to maximum v1.2. [Test Case] * Rebuild all reverse dependencies * Execute autopkg tests for all of them * Clamp down to TLS v1.2 software that does not support TLS v1.3 (e.g. mongodb) * Backport TLS v1.3 support patches, where applicable [Test cases for the python updates] python3.7 is a preview in bionic as a non-supported/non-default version of python3. Passing it's own autopkgtests is sufficient validation for python3.7. It includes a point release update, with OpenSSL 1.1.1 compat and features. python3.6 not only has OpenSSL 1.1.1 compat and features patches, but also includes a point release update to 3.6.8. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python3.6 and python3-defaults with regressions already fixed in the individual packages as appropriate. python2.7 has the update from .15~rc1 to .15 final, with OpenSSL 1.1.1 compat only. It has been part of the full-archive rebuild and regression analysis. Autopkgtests were triggered for python2.7 and python-defaults with regressions already fixed in the individual packages as appropriate. [Regression Potential] * Connectivity interop is the biggest issues which will be unavoidable with introducing TLS v1.3. However, tests on cosmic demonstrate that curl/nginx/google-chrome/mozilla-firefox connect and negotiate TLS v1.3 without issues. * Mitigation of discovered connectivity issues will be possible by clamping down to TLS v1.2 in either server-side or client-side software or by backporting relevant support fixes * Notable changes are listed here https://wiki.openssl.org/index.php/TLS1.3 * Most common connectivity issues so far: - client verifies SNI in TLSv1.3 mode, yet client doesn't set
[Touch-packages] [Bug 1814261] [NEW] gpm prevents loging to the console: spurious “Enter” events seems inserted
Public bug reported: Hello, When our servers boot, We can't login because of spurious “enter”. We have this problem on virtual and physical machines since: * kernel linux-image-4.15.0-44-generic on bionic * kernel linux-image-4.4.0-142-generic on xenial To reproduce: 1. start an ubuntu server with the specific kernel 2. install GPM 3. on a console 1. type the user name “root” 2. hit “enter” 3. wait few seconds => spurious “Enter” are send to the console 4. Stop gpm.service 5. retry to login on a console => no problem lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:Ubuntu 18.04.1 LTS Release:18.04 Codename: bionic ** Affects: gpm (Ubuntu) Importance: Undecided Status: New ** Tags: bionic xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gpm in Ubuntu. https://bugs.launchpad.net/bugs/1814261 Title: gpm prevents loging to the console: spurious “Enter” events seems inserted Status in gpm package in Ubuntu: New Bug description: Hello, When our servers boot, We can't login because of spurious “enter”. We have this problem on virtual and physical machines since: * kernel linux-image-4.15.0-44-generic on bionic * kernel linux-image-4.4.0-142-generic on xenial To reproduce: 1. start an ubuntu server with the specific kernel 2. install GPM 3. on a console 1. type the user name “root” 2. hit “enter” 3. wait few seconds => spurious “Enter” are send to the console 4. Stop gpm.service 5. retry to login on a console => no problem lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.1 LTS Release: 18.04 Codename: bionic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gpm/+bug/1814261/+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 1794523] [NEW] lxc-net.service is not properly ordered with network-online.target
Public bug reported: I made several tests and I figure out that the lxc-net.service is missing a Wants= directive to be properly ordered against network- online.target. As I understand the systemd.unit manpage, to be properly ordered a unit must define a Requires=/Wants= in addition to an After=/Before=. Regards. Distributor ID: Ubuntu Description:Ubuntu 18.04.1 LTS Release:18.04 Codename: bionic ** Affects: lxc (Ubuntu) Importance: Undecided Status: New ** Tags: bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lxc in Ubuntu. https://bugs.launchpad.net/bugs/1794523 Title: lxc-net.service is not properly ordered with network-online.target Status in lxc package in Ubuntu: New Bug description: I made several tests and I figure out that the lxc-net.service is missing a Wants= directive to be properly ordered against network- online.target. As I understand the systemd.unit manpage, to be properly ordered a unit must define a Requires=/Wants= in addition to an After=/Before=. Regards. Distributor ID: Ubuntu Description: Ubuntu 18.04.1 LTS Release: 18.04 Codename: bionic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1794523/+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 1757125] [NEW] DHCP relay doesn't work on boot when a lot of VLAN network interfaces
Public bug reported: 1) lsb_release -rd Description:Ubuntu 14.04.5 LTS Release:14.04 2) apt-cache policy isc-dhcp-relay isc-dhcp-relay: Installé : 4.2.4-7ubuntu12.13 Candidat : 4.2.4-7ubuntu12.13 We are using isc-dhcp package on Ubuntu trusty server. The server has 4 physical network interfaces and several VLAN on eth2 interface. dhcrelay is configured to relay dhcp requests from eth3 to VLAN interfaces. On boot, depending on hardware velocity, the DHCP relay doesn't work. In /etc/init/isc-dhcp-relay.conf, we can see "start on runlevel [2345]", but if all network interfaces are not ready, some errors appear in log file : "2018-03-20T10:58:45.229688+01:00 amon.etb1.lan dhcrelay: Error getting hardware address for "eth2.4": No such device" We must restart isc-dhcp-relay service once all network interfaces are ready. To resolve this problem, we added /etc/init/isc-dhcp-relay.override file containing "start on (runlevel [2345] and static-network-up)" to make sure that isc-dhcp-relay starts when all network interfaces are ready. Can we hope that you integrate this hotfix ? ** Affects: isc-dhcp (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1757125 Title: DHCP relay doesn't work on boot when a lot of VLAN network interfaces Status in isc-dhcp package in Ubuntu: New Bug description: 1) lsb_release -rd Description:Ubuntu 14.04.5 LTS Release:14.04 2) apt-cache policy isc-dhcp-relay isc-dhcp-relay: Installé : 4.2.4-7ubuntu12.13 Candidat : 4.2.4-7ubuntu12.13 We are using isc-dhcp package on Ubuntu trusty server. The server has 4 physical network interfaces and several VLAN on eth2 interface. dhcrelay is configured to relay dhcp requests from eth3 to VLAN interfaces. On boot, depending on hardware velocity, the DHCP relay doesn't work. In /etc/init/isc-dhcp-relay.conf, we can see "start on runlevel [2345]", but if all network interfaces are not ready, some errors appear in log file : "2018-03-20T10:58:45.229688+01:00 amon.etb1.lan dhcrelay: Error getting hardware address for "eth2.4": No such device" We must restart isc-dhcp-relay service once all network interfaces are ready. To resolve this problem, we added /etc/init/isc-dhcp-relay.override file containing "start on (runlevel [2345] and static-network-up)" to make sure that isc-dhcp-relay starts when all network interfaces are ready. Can we hope that you integrate this hotfix ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1757125/+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 798023] Re: apt-get update fails with error 416 Requested Range Not Satisfiable
Hello, Any news on this issue, we are facing it on Precise Pangolin some times. Regards. ** Tags added: precise -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/798023 Title: apt-get update fails with error 416 Requested Range Not Satisfiable Status in “apt” package in Ubuntu: Confirmed Bug description: Binary package hint: apt Err http://de.archive.ubuntu.com maverick-updates/main i386 Packages 416 Requested Range Not Satisfiable [IP: 141.30.13.30 80] Fetched 5,079B in 2s (2,296B/s) W: Failed to fetch http://de.archive.ubuntu.com/ubuntu/dists/maverick-updates/main/binary-i386/Packages.gz 416 Requested Range Not Satisfiable [IP: 141.30.13.30 80] E: Some index files failed to download, they have been ignored, or old ones used instead. ProblemType: Bug DistroRelease: Ubuntu 10.10 Package: apt 0.8.3ubuntu7.1 ProcVersionSignature: Ubuntu 2.6.35-28.50-generic 2.6.35.11 Uname: Linux 2.6.35-28-generic i686 Architecture: i386 Date: Thu Jun 16 07:56:13 2011 ExecutablePath: /usr/bin/apt-get InstallationMedia: Ubuntu 10.10 Maverick Meerkat - Release i386 (20101007) ProcEnviron: PATH=(custom, no user) LANG=en_US.utf8 SHELL=/bin/bash SourcePackage: apt To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/798023/+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
