[Touch-packages] [Bug 2073776] Re: nsswitch.conf "passwd" entry misses "systemd", breaking DynamicUser=yes systemd units
OK, thanks for confirming! ** Changed in: systemd (Ubuntu) Status: Incomplete => Invalid -- 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/2073776 Title: nsswitch.conf "passwd" entry misses "systemd", breaking DynamicUser=yes systemd units Status in systemd package in Ubuntu: Invalid Bug description: The 321-1~bpo22.04.1 version of cockpit-ws calls the cockpit user "cockpit-wsinstance": $ cat usr/lib/sysusers.d/cockpit-wsinstance.conf u cockpit-wsinstance - "User for cockpit-ws instances" - However the following systemd files still reference the old "cockpit-ws" username, so the service fails to start: $ grep -r cockpit-ws$ lib/systemd/system lib/systemd/system/cockpit-ws-user.service:Description=Dynamic user for cockpit-ws lib/systemd/system/cockpit-ws-user.service:User=cockpit-ws lib/systemd/system/cockpit-ws-user.service:Group=cockpit-ws lib/systemd/system/cockpit-wsinstance-https@.socket:SocketUser=cockpit-ws lib/systemd/system/cockpit-wsinstance-https-factory.socket:SocketUser=cockpit-ws lib/systemd/system/cockpit.service:User=cockpit-ws lib/systemd/system/cockpit.service:Group=cockpit-ws lib/systemd/system/cockpit-wsinstance-http.socket:SocketUser=cockpit-ws Can these systemd files be updated to use the new username? Thanks! To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2073776/+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 2061726] [NEW] rsyslog apparmor denial on reading /proc/sys/net/ipv6/conf/all/disable_ipv6
Public bug reported: One of our Cockpit integration tests [1] spotted an AppArmor regression in rsyslogd. This is coincidental, the test passes and it doesn't do anything with rsyslogd -- just something happens to happen in the background to trigger this (and I can actually reproduce it locally quite reliably). Mar 08 10:48:20 m1.cockpit.lan systemd[1]: dpkg-db-backup.service: Deactivated successfully. Mar 08 10:48:20 m1.cockpit.lan systemd[1]: Finished dpkg-db-backup.service - Daily dpkg database backup service. Mar 08 10:48:20 m1.cockpit.lan systemd[1]: rsyslog.service: Sent signal SIGHUP to main process 752 (rsyslogd) on client request. Mar 08 10:48:20 m1.cockpit.lan kernel: audit: type=1400 audit(1615200500.418:125): apparmor="DENIED" operation="open" class="file" profile="rsyslogd" name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=752 comm="rsyslogd" requested_mask="r" denied_mask="r" fsuid=102 ouid=0 Mar 08 10:48:20 m1.cockpit.lan kernel: audit: type=1400 audit(1615200500.418:126): apparmor="DENIED" operation="open" class="file" profile="rsyslogd" name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=752 comm="rsyslogd" requested_mask="r" denied_mask="r" fsuid=102 ouid=0 This happens on current Ubuntu 24.04 LTS noble devel, rsyslog 8.2312.0-3ubuntu8 and apparmor 4.0.0-beta3-0ubuntu3. [1] https://cockpit-logs.us-east-1.linodeobjects.com/pull-20317-ce39e07e-20240415-204952-ubuntu-stable-other/log.html#152 [2] https://cockpit-logs.us-east-1.linodeobjects.com/pull-20317-ce39e07e-20240415-204952-ubuntu-stable-other/TestHistoryMetrics-testEvents-ubuntu-stable-127.0.0.2-2901-FAIL.log.gz ** Affects: rsyslog (Ubuntu) Importance: Undecided Status: New ** Tags: apparmor noble -- 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/2061726 Title: rsyslog apparmor denial on reading /proc/sys/net/ipv6/conf/all/disable_ipv6 Status in rsyslog package in Ubuntu: New Bug description: One of our Cockpit integration tests [1] spotted an AppArmor regression in rsyslogd. This is coincidental, the test passes and it doesn't do anything with rsyslogd -- just something happens to happen in the background to trigger this (and I can actually reproduce it locally quite reliably). Mar 08 10:48:20 m1.cockpit.lan systemd[1]: dpkg-db-backup.service: Deactivated successfully. Mar 08 10:48:20 m1.cockpit.lan systemd[1]: Finished dpkg-db-backup.service - Daily dpkg database backup service. Mar 08 10:48:20 m1.cockpit.lan systemd[1]: rsyslog.service: Sent signal SIGHUP to main process 752 (rsyslogd) on client request. Mar 08 10:48:20 m1.cockpit.lan kernel: audit: type=1400 audit(1615200500.418:125): apparmor="DENIED" operation="open" class="file" profile="rsyslogd" name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=752 comm="rsyslogd" requested_mask="r" denied_mask="r" fsuid=102 ouid=0 Mar 08 10:48:20 m1.cockpit.lan kernel: audit: type=1400 audit(1615200500.418:126): apparmor="DENIED" operation="open" class="file" profile="rsyslogd" name="/proc/sys/net/ipv6/conf/all/disable_ipv6" pid=752 comm="rsyslogd" requested_mask="r" denied_mask="r" fsuid=102 ouid=0 This happens on current Ubuntu 24.04 LTS noble devel, rsyslog 8.2312.0-3ubuntu8 and apparmor 4.0.0-beta3-0ubuntu3. [1] https://cockpit-logs.us-east-1.linodeobjects.com/pull-20317-ce39e07e-20240415-204952-ubuntu-stable-other/log.html#152 [2] https://cockpit-logs.us-east-1.linodeobjects.com/pull-20317-ce39e07e-20240415-204952-ubuntu-stable-other/TestHistoryMetrics-testEvents-ubuntu-stable-127.0.0.2-2901-FAIL.log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2061726/+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 2061055] Re: Joining IPA domain does not restart ssh -- 'sshd.service' alias is not set up by default
Yeah, I could live with that -- but TBH I still consider this mostly a bug in openssh. querying the status of sshd.service really should work. Arch, RHEL, Fedora, OpenSUSE etc. all call this sshd.service. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2061055 Title: Joining IPA domain does not restart ssh -- 'sshd.service' alias is not set up by default Status in freeipa package in Ubuntu: New Status in openssh package in Ubuntu: New Bug description: Joining a FreeIPA domain reconfigures SSH. E.g. it enables GSSAPI authentication in /etc/ssh/sshd_config.d/04-ipa.conf . After that, it tries to restart sshd, but that fails as "sshd.service" is not a thing on Ubuntu: 2024-04-12T03:10:57Z DEBUG args=['/bin/systemctl', 'is-active', 'sshd.service'] 2024-04-12T03:10:57Z DEBUG Process finished, return code=4 (in /var/log/ipaclient-install.log) While that could be changed in freeipa, I'd argue that this is really a bug in Ubuntu's openssh package. Many upstream software, Ansible scripts etc. assume that the service is "sshd.service". In Debian/Ubuntu the primary unit is "ssh.service", but it has an `[Install] Alias=sshd.service`. That works in Debian because there sshd.service *actually* gets enabled by default, and ssh.socket isn't. But Ubuntu moved to socket activation (which is good!), so that ssh.socket is running by default. But that means that ssh.service never gets "systemctl enable"d, and hence the alias never gets set up: # systemctl status sshd.service Unit sshd.service could not be found. So if ssh.service is already running, it never gets restarted by "ipa- client-install". It would be really good to make that alias work by default -- if nothing else, just ship the symlink in the .deb, or create the symlink manually in the postinst? freeipa-client 4.10.2-2ubuntu3 openssh-server 1:9.6p1-3ubuntu12 Note: we have tested this functionality in Cockpit on Ubuntu for a long time already. But until very recently we had a workaround to force the creation of that alias: https://github.com/cockpit-project/bots/commit/3bf1b20f3fa5fe202b9710b3fe78d2133ba03f5d We dropped it because it broke image builds due to some bugs in openssh's postinst, but it was a bad one anyway: actual users don't have that hack, and it hides bugs like this. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/freeipa/+bug/2061055/+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 2061055] Re: Joining IPA domain does not restart ssh -- 'sshd.service' alias is not set up by default
Timo: It doesn't fail on Debian. See the "That works in Debian because.." in the description (TL/DR: Debian doesn't enable ssh.socket, but ssh.service, which sets up the symlink) ** Description changed: Joining a FreeIPA domain reconfigures SSH. E.g. it enables GSSAPI authentication in /etc/ssh/sshd_config.d/04-ipa.conf . After that, it tries to restart sshd, but that fails as "sshd.service" is not a thing on Ubuntu: 2024-04-12T03:10:57Z DEBUG args=['/bin/systemctl', 'is-active', 'sshd.service'] 2024-04-12T03:10:57Z DEBUG Process finished, return code=4 (in /var/log/ipaclient-install.log) While that could be changed in freeipa, I'd argue that this is really a bug in Ubuntu's openssh package. Many upstream software, Ansible scripts etc. assume that the service is "sshd.service". In Debian/Ubuntu the primary unit is "ssh.service", but it has an `[Install] Alias=sshd.service`. That works in Debian because there sshd.service *actually* gets enabled by default, and ssh.socket isn't. But Ubuntu moved to socket activation (which is good!), so that ssh.socket is running by default. But that means that ssh.service never gets "systemctl enable"d, and hence the alias never gets set up: # systemctl status sshd.service Unit sshd.service could not be found. So if ssh.service is already running, it never gets restarted by "ipa- client-install". It would be really good to make that alias work by default -- if nothing - else, just create the symlink manually in the postinst? + else, just ship the symlink in the .deb, or create the symlink manually + in the postinst? freeipa-client 4.10.2-2ubuntu3 openssh-server 1:9.6p1-3ubuntu12 - Note: we have tested this functionality in Cockpit on Ubuntu for a long time already. But until very recently we had a workaround to force the creation of that alias: https://github.com/cockpit-project/bots/commit/3bf1b20f3fa5fe202b9710b3fe78d2133ba03f5d We dropped it because it broke image builds due to some bugs in openssh's postinst, but it was a bad one anyway: actual users don't have that hack, and it hides bugs like this. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2061055 Title: Joining IPA domain does not restart ssh -- 'sshd.service' alias is not set up by default Status in freeipa package in Ubuntu: New Status in openssh package in Ubuntu: New Bug description: Joining a FreeIPA domain reconfigures SSH. E.g. it enables GSSAPI authentication in /etc/ssh/sshd_config.d/04-ipa.conf . After that, it tries to restart sshd, but that fails as "sshd.service" is not a thing on Ubuntu: 2024-04-12T03:10:57Z DEBUG args=['/bin/systemctl', 'is-active', 'sshd.service'] 2024-04-12T03:10:57Z DEBUG Process finished, return code=4 (in /var/log/ipaclient-install.log) While that could be changed in freeipa, I'd argue that this is really a bug in Ubuntu's openssh package. Many upstream software, Ansible scripts etc. assume that the service is "sshd.service". In Debian/Ubuntu the primary unit is "ssh.service", but it has an `[Install] Alias=sshd.service`. That works in Debian because there sshd.service *actually* gets enabled by default, and ssh.socket isn't. But Ubuntu moved to socket activation (which is good!), so that ssh.socket is running by default. But that means that ssh.service never gets "systemctl enable"d, and hence the alias never gets set up: # systemctl status sshd.service Unit sshd.service could not be found. So if ssh.service is already running, it never gets restarted by "ipa- client-install". It would be really good to make that alias work by default -- if nothing else, just ship the symlink in the .deb, or create the symlink manually in the postinst? freeipa-client 4.10.2-2ubuntu3 openssh-server 1:9.6p1-3ubuntu12 Note: we have tested this functionality in Cockpit on Ubuntu for a long time already. But until very recently we had a workaround to force the creation of that alias: https://github.com/cockpit-project/bots/commit/3bf1b20f3fa5fe202b9710b3fe78d2133ba03f5d We dropped it because it broke image builds due to some bugs in openssh's postinst, but it was a bad one anyway: actual users don't have that hack, and it hides bugs like this. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/freeipa/+bug/2061055/+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 2061055] [NEW] Joining IPA domain does not restart ssh -- 'sshd.service' alias is not set up by default
Public bug reported: Joining a FreeIPA domain reconfigures SSH. E.g. it enables GSSAPI authentication in /etc/ssh/sshd_config.d/04-ipa.conf . After that, it tries to restart sshd, but that fails as "sshd.service" is not a thing on Ubuntu: 2024-04-12T03:10:57Z DEBUG args=['/bin/systemctl', 'is-active', 'sshd.service'] 2024-04-12T03:10:57Z DEBUG Process finished, return code=4 (in /var/log/ipaclient-install.log) While that could be changed in freeipa, I'd argue that this is really a bug in Ubuntu's openssh package. Many upstream software, Ansible scripts etc. assume that the service is "sshd.service". In Debian/Ubuntu the primary unit is "ssh.service", but it has an `[Install] Alias=sshd.service`. That works in Debian because there sshd.service *actually* gets enabled by default, and ssh.socket isn't. But Ubuntu moved to socket activation (which is good!), so that ssh.socket is running by default. But that means that ssh.service never gets "systemctl enable"d, and hence the alias never gets set up: # systemctl status sshd.service Unit sshd.service could not be found. So if ssh.service is already running, it never gets restarted by "ipa- client-install". It would be really good to make that alias work by default -- if nothing else, just create the symlink manually in the postinst? freeipa-client 4.10.2-2ubuntu3 openssh-server 1:9.6p1-3ubuntu12 Note: we have tested this functionality in Cockpit on Ubuntu for a long time already. But until very recently we had a workaround to force the creation of that alias: https://github.com/cockpit-project/bots/commit/3bf1b20f3fa5fe202b9710b3fe78d2133ba03f5d We dropped it because it broke image builds due to some bugs in openssh's postinst, but it was a bad one anyway: actual users don't have that hack, and it hides bugs like this. ** Affects: freeipa (Ubuntu) Importance: Undecided Status: New ** Affects: openssh (Ubuntu) Importance: Undecided Status: New ** Also affects: openssh (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2061055 Title: Joining IPA domain does not restart ssh -- 'sshd.service' alias is not set up by default Status in freeipa package in Ubuntu: New Status in openssh package in Ubuntu: New Bug description: Joining a FreeIPA domain reconfigures SSH. E.g. it enables GSSAPI authentication in /etc/ssh/sshd_config.d/04-ipa.conf . After that, it tries to restart sshd, but that fails as "sshd.service" is not a thing on Ubuntu: 2024-04-12T03:10:57Z DEBUG args=['/bin/systemctl', 'is-active', 'sshd.service'] 2024-04-12T03:10:57Z DEBUG Process finished, return code=4 (in /var/log/ipaclient-install.log) While that could be changed in freeipa, I'd argue that this is really a bug in Ubuntu's openssh package. Many upstream software, Ansible scripts etc. assume that the service is "sshd.service". In Debian/Ubuntu the primary unit is "ssh.service", but it has an `[Install] Alias=sshd.service`. That works in Debian because there sshd.service *actually* gets enabled by default, and ssh.socket isn't. But Ubuntu moved to socket activation (which is good!), so that ssh.socket is running by default. But that means that ssh.service never gets "systemctl enable"d, and hence the alias never gets set up: # systemctl status sshd.service Unit sshd.service could not be found. So if ssh.service is already running, it never gets restarted by "ipa- client-install". It would be really good to make that alias work by default -- if nothing else, just create the symlink manually in the postinst? freeipa-client 4.10.2-2ubuntu3 openssh-server 1:9.6p1-3ubuntu12 Note: we have tested this functionality in Cockpit on Ubuntu for a long time already. But until very recently we had a workaround to force the creation of that alias: https://github.com/cockpit-project/bots/commit/3bf1b20f3fa5fe202b9710b3fe78d2133ba03f5d We dropped it because it broke image builds due to some bugs in openssh's postinst, but it was a bad one anyway: actual users don't have that hack, and it hides bugs like this. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/freeipa/+bug/2061055/+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 2060615] Re: [noble] two versions of perl-modules are published, breaking pbuilder/debootstrap
Yay, today this is finally fixed, pbuilder creation and building a noble VM image finally works again \o/ Thanks! ** Changed in: perl (Ubuntu Noble) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to perl in Ubuntu. https://bugs.launchpad.net/bugs/2060615 Title: [noble] two versions of perl-modules are published, breaking pbuilder/debootstrap Status in perl package in Ubuntu: Fix Released Status in perl source package in Noble: Fix Released Bug description: For the last two weeks, building noble VM images for our CI has been broken. Most of it was uninstallability due to the xz reset, but for the last three days, `pbuilder --create` has failed [2] because it gets perl and perl-modules-5.38 in two different versions: 2024-04-08 08:47:08 URL:http://archive.ubuntu.com/ubuntu/pool/main/p/perl/perl-base_5.38.2-3.2build2_amd64.deb [1822564/1822564] -> "/var/cache/pbuilder/aptcache//perl-base_5.38.2-3.2build2_amd64.deb" [1] 2024-04-08 08:47:09 URL:http://archive.ubuntu.com/ubuntu/pool/main/p/perl/perl-modules-5.38_5.38.2-3_all.deb [3110080/3110080] -> "/var/cache/pbuilder/aptcache//perl-modules-5.38_5.38.2-3_all.deb" [1] and then trying to configure the packages blows up. The root cause is that perl-modules has *two* versions published: # curl -s http://archive.ubuntu.com/ubuntu/dists/noble/main/binary-amd64/Packages.xz|xzgrep -A5 'Package: perl-modules-' Package: perl-modules-5.38 Architecture: all Version: 5.38.2-3.2build2 Multi-Arch: foreign Priority: optional Build-Essential: yes -- Package: perl-modules-5.38 Architecture: all Version: 5.38.2-3 Multi-Arch: foreign Priority: optional Build-Essential: yes While apt is clever enough to pick the right one, debootstrap isn't. Can you please remove the old perl-modules-5.38 5.38.2-3 from noble? Thanks! [1] https://github.com/cockpit-project/bots/issues/6147 [2] https://cockpit-logs.us-east-1.linodeobjects.com/image-refresh-ubuntu-stable-02cafde3-20240407-074108/log.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/perl/+bug/2060615/+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 2060615] Re: [noble] two versions of perl-modules are published, breaking debootstrap
Aside from curl this can be reproduced most quickly with sudo /usr/sbin/debootstrap --include=build-essential noble /tmp/n http://archive.ubuntu.com/ubuntu Errors were encountered while processing: perl libdpkg-perl libperl5.38t64:amd64 dpkg-dev build-essential These are all ultimately due to dpkg: dependency problems prevent configuration of perl: perl depends on perl-modules-5.38 (>= 5.38.2-3.2build2); however: Version of perl-modules-5.38 on system is 5.38.2-3. dpkg: error processing package perl (--configure): dependency problems - leaving unconfigured ** Tags added: debootstrap noble -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to perl in Ubuntu. https://bugs.launchpad.net/bugs/2060615 Title: [noble] two versions of perl-modules are published, breaking pbuilder/debootstrap Status in perl package in Ubuntu: New Status in perl source package in Noble: New Bug description: For the last two weeks, building noble VM images for our CI has been broken. Most of it was uninstallability due to the xz reset, but for the last three days, `pbuilder --create` has failed [2] because it gets perl and perl-modules-5.38 in two different versions: 2024-04-08 08:47:08 URL:http://archive.ubuntu.com/ubuntu/pool/main/p/perl/perl-base_5.38.2-3.2build2_amd64.deb [1822564/1822564] -> "/var/cache/pbuilder/aptcache//perl-base_5.38.2-3.2build2_amd64.deb" [1] 2024-04-08 08:47:09 URL:http://archive.ubuntu.com/ubuntu/pool/main/p/perl/perl-modules-5.38_5.38.2-3_all.deb [3110080/3110080] -> "/var/cache/pbuilder/aptcache//perl-modules-5.38_5.38.2-3_all.deb" [1] and then trying to configure the packages blows up. The root cause is that perl-modules has *two* versions published: # curl -s http://archive.ubuntu.com/ubuntu/dists/noble/main/binary-amd64/Packages.xz|xzgrep -A5 'Package: perl-modules-' Package: perl-modules-5.38 Architecture: all Version: 5.38.2-3.2build2 Multi-Arch: foreign Priority: optional Build-Essential: yes -- Package: perl-modules-5.38 Architecture: all Version: 5.38.2-3 Multi-Arch: foreign Priority: optional Build-Essential: yes While apt is clever enough to pick the right one, debootstrap isn't. Can you please remove the old perl-modules-5.38 5.38.2-3 from noble? Thanks! [1] https://github.com/cockpit-project/bots/issues/6147 [2] https://cockpit-logs.us-east-1.linodeobjects.com/image-refresh-ubuntu-stable-02cafde3-20240407-074108/log.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/perl/+bug/2060615/+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 2060615] Re: [noble] two versions of perl-modules are published, breaking debootstrap
I wonder where that comes from -- https://launchpad.net/ubuntu/+source/perl/+publishinghistory says that 5.38.2-3 was deleted, but only from noble-updates. In noble proper it is merely "superseded". https://launchpad.net/ubuntu/+source/perl/5.38.2-3 doesn't show it being published anyway, and it's not in https://ubuntu- archive-team.ubuntu.com/nbs.html either. ** Summary changed: - [noble] two versions of perl-modules are published, breaking debootstrap + [noble] two versions of perl-modules are published, breaking pbuilder/debootstrap -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to perl in Ubuntu. https://bugs.launchpad.net/bugs/2060615 Title: [noble] two versions of perl-modules are published, breaking pbuilder/debootstrap Status in perl package in Ubuntu: New Status in perl source package in Noble: New Bug description: For the last two weeks, building noble VM images for our CI has been broken. Most of it was uninstallability due to the xz reset, but for the last three days, `pbuilder --create` has failed [2] because it gets perl and perl-modules-5.38 in two different versions: 2024-04-08 08:47:08 URL:http://archive.ubuntu.com/ubuntu/pool/main/p/perl/perl-base_5.38.2-3.2build2_amd64.deb [1822564/1822564] -> "/var/cache/pbuilder/aptcache//perl-base_5.38.2-3.2build2_amd64.deb" [1] 2024-04-08 08:47:09 URL:http://archive.ubuntu.com/ubuntu/pool/main/p/perl/perl-modules-5.38_5.38.2-3_all.deb [3110080/3110080] -> "/var/cache/pbuilder/aptcache//perl-modules-5.38_5.38.2-3_all.deb" [1] and then trying to configure the packages blows up. The root cause is that perl-modules has *two* versions published: # curl -s http://archive.ubuntu.com/ubuntu/dists/noble/main/binary-amd64/Packages.xz|xzgrep -A5 'Package: perl-modules-' Package: perl-modules-5.38 Architecture: all Version: 5.38.2-3.2build2 Multi-Arch: foreign Priority: optional Build-Essential: yes -- Package: perl-modules-5.38 Architecture: all Version: 5.38.2-3 Multi-Arch: foreign Priority: optional Build-Essential: yes While apt is clever enough to pick the right one, debootstrap isn't. Can you please remove the old perl-modules-5.38 5.38.2-3 from noble? Thanks! [1] https://github.com/cockpit-project/bots/issues/6147 [2] https://cockpit-logs.us-east-1.linodeobjects.com/image-refresh-ubuntu-stable-02cafde3-20240407-074108/log.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/perl/+bug/2060615/+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 2060615] [NEW] [noble] two versions of perl-modules are published, breaking pbuilder/debootstrap
Public bug reported: For the last two weeks, building noble VM images for our CI has been broken. Most of it was uninstallability due to the xz reset, but for the last three days, `pbuilder --create` has failed [2] because it gets perl and perl-modules-5.38 in two different versions: 2024-04-08 08:47:08 URL:http://archive.ubuntu.com/ubuntu/pool/main/p/perl/perl-base_5.38.2-3.2build2_amd64.deb [1822564/1822564] -> "/var/cache/pbuilder/aptcache//perl-base_5.38.2-3.2build2_amd64.deb" [1] 2024-04-08 08:47:09 URL:http://archive.ubuntu.com/ubuntu/pool/main/p/perl/perl-modules-5.38_5.38.2-3_all.deb [3110080/3110080] -> "/var/cache/pbuilder/aptcache//perl-modules-5.38_5.38.2-3_all.deb" [1] and then trying to configure the packages blows up. The root cause is that perl-modules has *two* versions published: # curl -s http://archive.ubuntu.com/ubuntu/dists/noble/main/binary-amd64/Packages.xz|xzgrep -A5 'Package: perl-modules-' Package: perl-modules-5.38 Architecture: all Version: 5.38.2-3.2build2 Multi-Arch: foreign Priority: optional Build-Essential: yes -- Package: perl-modules-5.38 Architecture: all Version: 5.38.2-3 Multi-Arch: foreign Priority: optional Build-Essential: yes While apt is clever enough to pick the right one, debootstrap isn't. Can you please remove the old perl-modules-5.38 5.38.2-3 from noble? Thanks! [1] https://github.com/cockpit-project/bots/issues/6147 [2] https://cockpit-logs.us-east-1.linodeobjects.com/image-refresh-ubuntu-stable-02cafde3-20240407-074108/log.html ** Affects: perl (Ubuntu) Importance: Undecided Status: New ** Affects: perl (Ubuntu Noble) Importance: Undecided Status: New ** Tags: debootstrap noble ** Also affects: perl (Ubuntu Noble) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to perl in Ubuntu. https://bugs.launchpad.net/bugs/2060615 Title: [noble] two versions of perl-modules are published, breaking pbuilder/debootstrap Status in perl package in Ubuntu: New Status in perl source package in Noble: New Bug description: For the last two weeks, building noble VM images for our CI has been broken. Most of it was uninstallability due to the xz reset, but for the last three days, `pbuilder --create` has failed [2] because it gets perl and perl-modules-5.38 in two different versions: 2024-04-08 08:47:08 URL:http://archive.ubuntu.com/ubuntu/pool/main/p/perl/perl-base_5.38.2-3.2build2_amd64.deb [1822564/1822564] -> "/var/cache/pbuilder/aptcache//perl-base_5.38.2-3.2build2_amd64.deb" [1] 2024-04-08 08:47:09 URL:http://archive.ubuntu.com/ubuntu/pool/main/p/perl/perl-modules-5.38_5.38.2-3_all.deb [3110080/3110080] -> "/var/cache/pbuilder/aptcache//perl-modules-5.38_5.38.2-3_all.deb" [1] and then trying to configure the packages blows up. The root cause is that perl-modules has *two* versions published: # curl -s http://archive.ubuntu.com/ubuntu/dists/noble/main/binary-amd64/Packages.xz|xzgrep -A5 'Package: perl-modules-' Package: perl-modules-5.38 Architecture: all Version: 5.38.2-3.2build2 Multi-Arch: foreign Priority: optional Build-Essential: yes -- Package: perl-modules-5.38 Architecture: all Version: 5.38.2-3 Multi-Arch: foreign Priority: optional Build-Essential: yes While apt is clever enough to pick the right one, debootstrap isn't. Can you please remove the old perl-modules-5.38 5.38.2-3 from noble? Thanks! [1] https://github.com/cockpit-project/bots/issues/6147 [2] https://cockpit-logs.us-east-1.linodeobjects.com/image-refresh-ubuntu-stable-02cafde3-20240407-074108/log.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/perl/+bug/2060615/+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 2056739] Re: apparmor="DENIED" operation="open" class="file" profile="virt-aa-helper" name="/etc/gnutls/config"
** Changed in: chrony (Ubuntu) Status: New => Won't Fix ** Changed in: gnutls28 (Ubuntu) Status: New => Won't Fix ** Changed in: libvirt (Ubuntu) Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2056739 Title: apparmor="DENIED" operation="open" class="file" profile="virt-aa- helper" name="/etc/gnutls/config" Status in apparmor package in Ubuntu: In Progress Status in chrony package in Ubuntu: Won't Fix Status in gnutls28 package in Ubuntu: Won't Fix Status in libvirt package in Ubuntu: Won't Fix Status in apparmor source package in Noble: In Progress Status in chrony source package in Noble: Won't Fix Status in gnutls28 source package in Noble: Won't Fix Status in libvirt source package in Noble: Won't Fix Bug description: Christian summarizes this after the great reports by Martin: gnutls started to ship forceful disables in pkg/import/3.8.1-4ubuntu3 and added more later. Due to that anything linked against gnutls while being apparmor isolated now hits similar denials, preventing the desired effect of the config change BTW. I think for safety we WANT to always allow this access, otherwise people will subtly not have crypto control about the more important (those isolated) software. Because after the denial I'd expect this to not really disable it in the program linked to gnutls (details might vary depending what they really use gnutls for). I do not nkow of a gnutls abstraction to use, but TBH I'm afraid now fixing a few but leaving this open in some others not spotted. I'd therefore suggest, but we need to discuss, to therefore change it in /etc/apparmor.d/abstractions/base. Therefore I'm adding gnutls (and Adrien) as well as apparmor to the bug tasks. --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Merely booting current noble cloud image with "chrony" installed causes this: audit: type=1400 audit(1710152842.540:107): apparmor="DENIED" operation="open" class="file" profile="/usr/sbin/chronyd" name="/etc/gnutls/config" pid=878 comm="chronyd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- Running any VM in libvirt causes a new AppArmor violation in current noble. This is a regression, this didn't happen in any previous release. Reproducer: virt-install --memory 50 --pxe --virt-type qemu --os-variant alpinelinux3.8 --disk none --wait 0 --name test1 (This is the simplest way to create a test VM. But it's form or shape doesn't matter at all). Results in lots of audit: type=1400 audit(1710146677.570:108): apparmor="DENIED" operation="open" class="file" profile="virt-aa-helper" name="/etc/gnutls/config" pid=1480 comm="virt-aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 libvirt-daemon 10.0.0-2ubuntu1 apparmor 4.0.0~alpha4-0ubuntu1 libgnutls30:amd64 3.8.3-1ubuntu1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2056739/+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 2046477] Re: Enable unprivileged user namespace restrictions by default
Just to make sure that we really talk about the same thing: This bug
sounds like it is *intended* that
unshare --user --map-root-user /bin/bash -c whoami
(as unpriv user) now fails in current Ubuntu 24.04 noble. That still
worked in released 23.10.
I am starting to test Cockpit on the current noble dailies [1] to make
sure everything is ready for 24.04 LTS (as 23.10 was a bit of a
disaster..), and aside from some non-fatal AppAmor noise this is the
most important issue. This breaks /usr/lib/cockpit/cockpit-desktop ,
which uses an user namespace to isolate cockpit's web server + a
browser, and that isolation is absolutely crucial for its security.
I can update cockpit-ws.deb to ship a new file /etc/apparmor.d/cockpit-
desktop with
-- 8< ---
abi ,
include
profile cockpit-desktop /usr/lib/cockpit/cockpit-desktop flags=(unconfined) {
userns,
# Site-specific additions and overrides. See local/README for details.
include if exists
}
-- 8< ---
I confirmed that this works fine. I just wanted to check that this is
intended, and not circumventing your intentions here?
Thanks!
[1] https://github.com/cockpit-project/bots/pull/6048
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/2046477
Title:
Enable unprivileged user namespace restrictions by default
Status in apparmor package in Ubuntu:
Triaged
Bug description:
As per https://discourse.ubuntu.com/t/spec-unprivileged-user-
namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626,
unprivileged user namespace restrictions for Ubuntu 23.10 are to be
enabled by default via a sysctl.d conf file in apparmor, and for that
to happen, the restrictions need to be enabled for 24.04
When the unprivileged user namespace restrictions are enabled, various
applications within and outside the Ubuntu archive fail to function,
as they use unprivileged user namespaces as part of their normal
operation.
A search of the Ubuntu archive for the 23.10 release was performed
looking for all applications that make legitimate use of the
CLONE_NEWUSER argument, the details of which can be seen in
https://docs.google.com/spreadsheets/d/1MOPVoTW0BROF1TxYqoWeJ3c6w2xKElI4w-VjdCG0m9s/edit#gid=2102562502
For each package identified in that list, an investigation was made to
determine if the application actually used this as an unprivileged
user, and if so which of the binaries within the package were
affected.
The full investigation can be seen in
https://warthogs.atlassian.net/browse/SEC-1898 (which is unfortunately
private) but is summarised to the following list of Ubuntu source
packages, as well as some out-of-archive applications that are known
to use unprivileged user namespaces.
For each of these binaries, an apparmor profile is required so that
the binary can be granted use of unprivileged user namespaces - an
example profile for the ch-run binary within the charliecloud package
is shown:
$ cat /etc/apparmor.d/ch-run
abi ,
include
profile ch-run /usr/bin/ch-run flags=(unconfined) {
userns,
# Site-specific additions and overrides. See local/README for details.
include if exists
}
However, in a few select cases, it has been decided not to ship an apparmor
profile, since this would effectively allow this mitigation to be bypassed. In
particular, the unshare and setns binaries within the util-linux package are
installed on every Ubuntu system, and allow an unprivileged user the ability to
launch an arbitrary application within a new user namespace. Any malicious
application then that wished to exploit an unprivileged user namespace to
conduct an attack on the kernel would simply need to spawn itself via `unshare
-U` or similar to be granted this permission. Therefore, due to the ubiquitous
nature of the unshare (and setns) binaries, profiles are not planned to be
provided for these by default.
Similarly, the bwrap binary within bubblewrap is also installed by default on
Ubuntu Desktop 24.04 and can also be used to launch arbitrary binaries within a
new user namespace and so no profile is planned to be provided for this either.
In Bug 2035315 new apparmor profiles were added to the apparmor
package for various applications which require unprivileged user
namespaces, using a new unconfined profile mode. They were also added
in the AppArmor upstream project.
As well as enabling the sysctl via the sysctl.d conf file, it is
proposed to add logic into the apparmor.service systemd unit to check
that the kernel supports the unconfined profile mode and that it is
enabled - and if not then to force disable the userns restrictions
sysctl via the following logic:
userns_restricted=$(sysctl -n kernel.apparmor_restrict_unprivileged_userns)
unconfined_userns=$([ -f
/sys/kernel/security/apparmor/features/policy
[Touch-packages] [Bug 2056768] [NEW] apparmor="DENIED" operation="open" class="file" profile="rsyslogd" name="/run/systemd/sessions/"
Public bug reported: There is an AppArmor regression in current noble. In cockpit we recently started to test on noble (to prevent the "major regressions after release" fiasco from 23.10 again). For some weird reason, rsyslog is installed *by default* [1] in the cloud images. That is a rather pointless waste of CPU and disk space, as it's an unnecessary running daemon and duplicates all the written logs. But more specifically, we noticed [2] an AppArmor rejection. Reproducer is simple: logger -p user.emerg --tag check-journal EMERGENCY_MESSAGE this causes type=1400 audit(1710168739.345:108): apparmor="DENIED" operation="open" class="file" profile="rsyslogd" name="/run/systemd/sessions/" pid=714 comm=72733A6D61696E20513A526567 requested_mask="r" denied_mask="r" fsuid=102 ouid=0 Note that it doesn't actually fail, the "EMERGENCY_MESSAGE" does appear in the journal and also in /var/log/syslog. But it's some noise that triggers our (and presumbly other admin's) log detectors. rsyslog 8.2312.0-3ubuntu3 apparmor 4.0.0~alpha4-0ubuntu1 [1] https://cloud-images.ubuntu.com/daily/server/noble/current/noble-server-cloudimg-amd64.manifest [2] https://cockpit-logs.us-east-1.linodeobjects.com/pull-6048-20240311-125838-b465e9b2-ubuntu-stable-other-cockpit-project-cockpit/log.html#118 ** Affects: rsyslog (Ubuntu) Importance: Undecided Status: New ** Affects: rsyslog (Ubuntu Noble) Importance: Undecided Status: New ** Tags: apparmor cockpit-test noble regression-release ** Also affects: rsyslog (Ubuntu Noble) 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/2056768 Title: apparmor="DENIED" operation="open" class="file" profile="rsyslogd" name="/run/systemd/sessions/" Status in rsyslog package in Ubuntu: New Status in rsyslog source package in Noble: New Bug description: There is an AppArmor regression in current noble. In cockpit we recently started to test on noble (to prevent the "major regressions after release" fiasco from 23.10 again). For some weird reason, rsyslog is installed *by default* [1] in the cloud images. That is a rather pointless waste of CPU and disk space, as it's an unnecessary running daemon and duplicates all the written logs. But more specifically, we noticed [2] an AppArmor rejection. Reproducer is simple: logger -p user.emerg --tag check-journal EMERGENCY_MESSAGE this causes type=1400 audit(1710168739.345:108): apparmor="DENIED" operation="open" class="file" profile="rsyslogd" name="/run/systemd/sessions/" pid=714 comm=72733A6D61696E20513A526567 requested_mask="r" denied_mask="r" fsuid=102 ouid=0 Note that it doesn't actually fail, the "EMERGENCY_MESSAGE" does appear in the journal and also in /var/log/syslog. But it's some noise that triggers our (and presumbly other admin's) log detectors. rsyslog 8.2312.0-3ubuntu3 apparmor 4.0.0~alpha4-0ubuntu1 [1] https://cloud-images.ubuntu.com/daily/server/noble/current/noble-server-cloudimg-amd64.manifest [2] https://cockpit-logs.us-east-1.linodeobjects.com/pull-6048-20240311-125838-b465e9b2-ubuntu-stable-other-cockpit-project-cockpit/log.html#118 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/2056768/+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 2047082] Re: upgrading openssh-server failed: rescue-ssh.target is a disabled or a static unit not running, not starting it.
Fun, this isn't even reliable. The first atttempt failed: https://cockpit-logs.us-east-1.linodeobjects.com/image-refresh- logs/ubuntu-stable-20231219-223939.log I retried the build now, no package or environment changes. Only daytime and timing (race conditions). Perhaps some interaction with cloud-init? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2047082 Title: upgrading openssh-server always shows error: rescue-ssh.target is a disabled or a static unit not running, not starting it. Status in openssh package in Ubuntu: New Bug description: In our project we regularly build Ubuntu VM images for current 23.10 (stable). In https://github.com/cockpit-project/bots/issues/5691 we ran into an upgrade failure of openssh-server. It starts with the current cloud image and then apt upgrades it, with "DEBIAN_FRONTEND=noninteractive". openssh was updated a few days ago indeed: Setting up openssh-server (1:9.3p1-1ubuntu3.1) ... Creating SSH2 ECDSA key; this may take some time ... 256 SHA256:UqrRSpQNM7SIixVivYP/WwZRjt7Sv89P31W/Gxaf+Z8 root@ubuntu (ECDSA) Creating SSH2 ED25519 key; this may take some time ... 256 SHA256:hy9AEDydfnZeY9nf9P4Sb90kx39Oqr101A6tz5j4RQw root@ubuntu (ED25519) rescue-ssh.target is a disabled or a static unit not running, not starting it. Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 145. dpkg: error processing package openssh-server (--configure): installed openssh-server package post-installation script subprocess returned error exit status 1 I.e. of course that security update itself [1] didn't introduce the regression, but earlier VM builds just didn't have a pending openssh update -- looks like this has been a luring upgrade trap in the release already. As a first naïve reproducer I tried apt update DEBIAN_FRONTEND=noninteractive apt update openssh-server on our current VM (with the release version 1:9.3p1-1ubuntu3), and that worked fine. Same with installing all 9 available packages. rescue.target is loaded/inactive/static, as it should be. Updating without DEBIAN_FRONTEND does show me a conffile prompt about /etc/ssh/sshd_config, which is justified as we do modify the config: # Allow root login with password sed -i 's/^[# ]*PermitRootLogin .*/PermitRootLogin yes/' /etc/ssh/sshd_config # Prevent SSH from hanging for a long time when no external network access echo 'UseDNS no' >> /etc/ssh/sshd_config this also leads to a merge conflict. However, I suppose all of that is tangential to the rescue-ssh.target issue. In all my interactive upgrades, it seemed to handle that just fine: Setting up openssh-server (1:9.3p1-1ubuntu3.1) ... rescue-ssh.target is a disabled or a static unit not running, not starting it. So this seems to be related to the first-time installation of openssh- server -- it is part of the cloud image, but it does the host key generation during our image builds. So reproducing this is a bit tricky, but aside from that: Why does it even do this in the first place? # Automatically added by dh_installsystemd/13.11.6ubuntu1 if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then if [ -d /run/systemd/system ]; then systemctl --system daemon-reload >/dev/null || true if [ -n "$2" ]; then _dh_action=restart else _dh_action=start fi deb-systemd-invoke $_dh_action 'rescue-ssh.target' >/dev/null || true fi fi It feels like the postinst should *never* try to start rescue- ssh.target. That's an alternative boot mode, and should never run un multi-user.target, isn't it? [1] https://launchpad.net/ubuntu/+source/openssh/1:9.3p1-1ubuntu3.1 DistroRelease: Ubuntu 23.10 PackageVersion: openssh-server 1:9.3p1-1ubuntu3.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2047082/+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 2047082] Re: upgrading openssh-server failed: rescue-ssh.target is a disabled or a static unit not running, not starting it.
Argh -- I missed the alternative truth in that rescue-ssh.target shell code. So this message should pretty much *always* appear -- it's nonsense to actually try and restart rescue-ssh.target in the postinst, *always*. But it is a red herring due to the || true. The upgrade failed on something else but didn't print any error message. So there is no remaining evidence what happens. So let's dedicate this bug report to dropping that deb-system-invoke for rescue-ssh.target. ** Summary changed: - upgrading openssh-server failed: rescue-ssh.target is a disabled or a static unit not running, not starting it. + upgrading openssh-server always shows error: rescue-ssh.target is a disabled or a static unit not running, not starting it. ** Changed in: openssh (Ubuntu) Importance: Undecided => Low -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2047082 Title: upgrading openssh-server always shows error: rescue-ssh.target is a disabled or a static unit not running, not starting it. Status in openssh package in Ubuntu: New Bug description: In our project we regularly build Ubuntu VM images for current 23.10 (stable). In https://github.com/cockpit-project/bots/issues/5691 we ran into an upgrade failure of openssh-server. It starts with the current cloud image and then apt upgrades it, with "DEBIAN_FRONTEND=noninteractive". openssh was updated a few days ago indeed: Setting up openssh-server (1:9.3p1-1ubuntu3.1) ... Creating SSH2 ECDSA key; this may take some time ... 256 SHA256:UqrRSpQNM7SIixVivYP/WwZRjt7Sv89P31W/Gxaf+Z8 root@ubuntu (ECDSA) Creating SSH2 ED25519 key; this may take some time ... 256 SHA256:hy9AEDydfnZeY9nf9P4Sb90kx39Oqr101A6tz5j4RQw root@ubuntu (ED25519) rescue-ssh.target is a disabled or a static unit not running, not starting it. Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 145. dpkg: error processing package openssh-server (--configure): installed openssh-server package post-installation script subprocess returned error exit status 1 I.e. of course that security update itself [1] didn't introduce the regression, but earlier VM builds just didn't have a pending openssh update -- looks like this has been a luring upgrade trap in the release already. As a first naïve reproducer I tried apt update DEBIAN_FRONTEND=noninteractive apt update openssh-server on our current VM (with the release version 1:9.3p1-1ubuntu3), and that worked fine. Same with installing all 9 available packages. rescue.target is loaded/inactive/static, as it should be. Updating without DEBIAN_FRONTEND does show me a conffile prompt about /etc/ssh/sshd_config, which is justified as we do modify the config: # Allow root login with password sed -i 's/^[# ]*PermitRootLogin .*/PermitRootLogin yes/' /etc/ssh/sshd_config # Prevent SSH from hanging for a long time when no external network access echo 'UseDNS no' >> /etc/ssh/sshd_config this also leads to a merge conflict. However, I suppose all of that is tangential to the rescue-ssh.target issue. In all my interactive upgrades, it seemed to handle that just fine: Setting up openssh-server (1:9.3p1-1ubuntu3.1) ... rescue-ssh.target is a disabled or a static unit not running, not starting it. So this seems to be related to the first-time installation of openssh- server -- it is part of the cloud image, but it does the host key generation during our image builds. So reproducing this is a bit tricky, but aside from that: Why does it even do this in the first place? # Automatically added by dh_installsystemd/13.11.6ubuntu1 if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then if [ -d /run/systemd/system ]; then systemctl --system daemon-reload >/dev/null || true if [ -n "$2" ]; then _dh_action=restart else _dh_action=start fi deb-systemd-invoke $_dh_action 'rescue-ssh.target' >/dev/null || true fi fi It feels like the postinst should *never* try to start rescue- ssh.target. That's an alternative boot mode, and should never run un multi-user.target, isn't it? [1] https://launchpad.net/ubuntu/+source/openssh/1:9.3p1-1ubuntu3.1 DistroRelease: Ubuntu 23.10 PackageVersion: openssh-server 1:9.3p1-1ubuntu3.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2047082/+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 2047082] [NEW] upgrading openssh-server always shows error: rescue-ssh.target is a disabled or a static unit not running, not starting it.
Public bug reported: In our project we regularly build Ubuntu VM images for current 23.10 (stable). In https://github.com/cockpit-project/bots/issues/5691 we ran into an upgrade failure of openssh-server. It starts with the current cloud image and then apt upgrades it, with "DEBIAN_FRONTEND=noninteractive". openssh was updated a few days ago indeed: Setting up openssh-server (1:9.3p1-1ubuntu3.1) ... Creating SSH2 ECDSA key; this may take some time ... 256 SHA256:UqrRSpQNM7SIixVivYP/WwZRjt7Sv89P31W/Gxaf+Z8 root@ubuntu (ECDSA) Creating SSH2 ED25519 key; this may take some time ... 256 SHA256:hy9AEDydfnZeY9nf9P4Sb90kx39Oqr101A6tz5j4RQw root@ubuntu (ED25519) rescue-ssh.target is a disabled or a static unit not running, not starting it. Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 145. dpkg: error processing package openssh-server (--configure): installed openssh-server package post-installation script subprocess returned error exit status 1 I.e. of course that security update itself [1] didn't introduce the regression, but earlier VM builds just didn't have a pending openssh update -- looks like this has been a luring upgrade trap in the release already. As a first naïve reproducer I tried apt update DEBIAN_FRONTEND=noninteractive apt update openssh-server on our current VM (with the release version 1:9.3p1-1ubuntu3), and that worked fine. Same with installing all 9 available packages. rescue.target is loaded/inactive/static, as it should be. Updating without DEBIAN_FRONTEND does show me a conffile prompt about /etc/ssh/sshd_config, which is justified as we do modify the config: # Allow root login with password sed -i 's/^[# ]*PermitRootLogin .*/PermitRootLogin yes/' /etc/ssh/sshd_config # Prevent SSH from hanging for a long time when no external network access echo 'UseDNS no' >> /etc/ssh/sshd_config this also leads to a merge conflict. However, I suppose all of that is tangential to the rescue-ssh.target issue. In all my interactive upgrades, it seemed to handle that just fine: Setting up openssh-server (1:9.3p1-1ubuntu3.1) ... rescue-ssh.target is a disabled or a static unit not running, not starting it. So this seems to be related to the first-time installation of openssh- server -- it is part of the cloud image, but it does the host key generation during our image builds. So reproducing this is a bit tricky, but aside from that: Why does it even do this in the first place? # Automatically added by dh_installsystemd/13.11.6ubuntu1 if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then if [ -d /run/systemd/system ]; then systemctl --system daemon-reload >/dev/null || true if [ -n "$2" ]; then _dh_action=restart else _dh_action=start fi deb-systemd-invoke $_dh_action 'rescue-ssh.target' >/dev/null || true fi fi It feels like the postinst should *never* try to start rescue- ssh.target. That's an alternative boot mode, and should never run un multi-user.target, isn't it? [1] https://launchpad.net/ubuntu/+source/openssh/1:9.3p1-1ubuntu3.1 DistroRelease: Ubuntu 23.10 PackageVersion: openssh-server 1:9.3p1-1ubuntu3.1 ** Affects: openssh (Ubuntu) Importance: Low Status: New ** Tags: mantic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2047082 Title: upgrading openssh-server always shows error: rescue-ssh.target is a disabled or a static unit not running, not starting it. Status in openssh package in Ubuntu: New Bug description: In our project we regularly build Ubuntu VM images for current 23.10 (stable). In https://github.com/cockpit-project/bots/issues/5691 we ran into an upgrade failure of openssh-server. It starts with the current cloud image and then apt upgrades it, with "DEBIAN_FRONTEND=noninteractive". openssh was updated a few days ago indeed: Setting up openssh-server (1:9.3p1-1ubuntu3.1) ... Creating SSH2 ECDSA key; this may take some time ... 256 SHA256:UqrRSpQNM7SIixVivYP/WwZRjt7Sv89P31W/Gxaf+Z8 root@ubuntu (ECDSA) Creating SSH2 ED25519 key; this may take some time ... 256 SHA256:hy9AEDydfnZeY9nf9P4Sb90kx39Oqr101A6tz5j4RQw root@ubuntu (ED25519) rescue-ssh.target is a disabled or a static unit not running, not starting it. Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 145. dpkg: error processing package openssh-server (--configure): installed openssh-server package post-installation script subprocess returned error exit status 1 I.e. of course that security update itself [1] didn't introduce the regression, but earlier VM builds just didn't have a pending openssh update -- looks like this has b
[Touch-packages] [Bug 2037703] Re: dpkg-reconfigure openssh-server doesn't ask questions again
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2037703 Title: dpkg-reconfigure openssh-server doesn't ask questions again Status in openssh package in Ubuntu: New Bug description: openssh-server does provide a couple of configuration options: [~]$ sudo debconf-get-selections |grep openssh-server openssh-serveropenssh-server/listenstream-may-failerror openssh-serveropenssh-server/password-authentication boolean true openssh-serveropenssh-server/permit-root-loginboolean true I want to change those options now interactively but nothing I tried worked and showed a dialog: [~]$ sudo dpkg-reconfigure -p low openssh-server Warning: Stopping ssh.service, but it can still be activated by: ssh.socket rescue-ssh.target is a disabled or a static unit not running, not starting it. [~]$ sudo dpkg-reconfigure -p low --force --frontend dialog openssh-server Warning: Stopping ssh.service, but it can still be activated by: ssh.socket rescue-ssh.target is a disabled or a static unit not running, not starting it. But the documentation (https://manpages.debian.org/testing/debconf- doc/debconf.7.en.html#Reconfiguring_packages) does state that those commands should ask those questions again. p.s. also tried with a lxc debian-sid container and had the same problem there. ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: openssh-server 1:9.3p1-1ubuntu3 ProcVersionSignature: Ubuntu 6.5.0-5.5-generic 6.5.0 Uname: Linux 6.5.0-5-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.27.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Fri Sep 29 10:35:33 2023 InstallationDate: Installed on 2023-05-10 (142 days ago) InstallationMedia: Ubuntu 23.04 "Lunar Lobster" - Release amd64 (20230418) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/usr/bin/zsh TERM=xterm-256color XDG_RUNTIME_DIR= SourcePackage: openssh UpgradeStatus: Upgraded to mantic on 2023-07-19 (71 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2037703/+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 2037703] Re: dpkg-reconfigure openssh-server doesn't ask questions again
We just ran into this in https://github.com/cockpit- project/bots/issues/5691 when trying to refresh our Ubuntu 23.10 mantic VM image. It starts with the current cloud image and then apt upgrades it, with "DEBIAN_FRONTEND=noninteractive". openssh was updated a few days ago indeed: Setting up openssh-server (1:9.3p1-1ubuntu3.1) ... Creating SSH2 ECDSA key; this may take some time ... 256 SHA256:UqrRSpQNM7SIixVivYP/WwZRjt7Sv89P31W/Gxaf+Z8 root@ubuntu (ECDSA) Creating SSH2 ED25519 key; this may take some time ... 256 SHA256:hy9AEDydfnZeY9nf9P4Sb90kx39Oqr101A6tz5j4RQw root@ubuntu (ED25519) rescue-ssh.target is a disabled or a static unit not running, not starting it. Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 145. dpkg: error processing package openssh-server (--configure): installed openssh-server package post-installation script subprocess returned error exit status 1 I.e. of course that security update itself didn't introduce the regression, but earlier VM builds just didn't have a pending openssh update -- looks like this has been a luring upgrade trap in the release already. However, as a first naïve reproducer I tried apt update DEBIAN_FRONTEND=noninteractive apt update openssh-server on our current VM (with the release version 1:9.3p1-1ubuntu3), and that worked fine. Same with installing all 9 available packages. rescue.target is loaded/inactive/static, as it should be. Updating without DEBIAN_FRONTEND does show me a conffile prompt about /etc/ssh/sshd_config, which is justified as we do modify the config: # Allow root login with password sed -i 's/^[# ]*PermitRootLogin .*/PermitRootLogin yes/' /etc/ssh/sshd_config # Prevent SSH from hanging for a long time when no external network access echo 'UseDNS no' >> /etc/ssh/sshd_config this also leads to a merge conflict. However, I suppose all of that is tangential to the rescue-ssh.target issue. In all my interactive upgrades, it seemed to handle that just fine: Setting up openssh-server (1:9.3p1-1ubuntu3.1) ... rescue-ssh.target is a disabled or a static unit not running, not starting it. So this seems to be related to the first-time installation of openssh- server -- it is part of the cloud image, but it does the host key generation during our image builds. So reproducing this is a bit tricky, but aside from that: Why does it even do this in the first place? # Automatically added by dh_installsystemd/13.11.6ubuntu1 if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then if [ -d /run/systemd/system ]; then systemctl --system daemon-reload >/dev/null || true if [ -n "$2" ]; then _dh_action=restart else _dh_action=start fi deb-systemd-invoke $_dh_action 'rescue-ssh.target' >/dev/null || true fi fi It feels like the postinst should *never* try to start rescue- ssh.target. That's an alternative boot mode, and should never run un multi-user.target, isn't it? [1] https://launchpad.net/ubuntu/+source/openssh/1:9.3p1-1ubuntu3.1 ** Bug watch added: github.com/cockpit-project/bots/issues #5691 https://github.com/cockpit-project/bots/issues/5691 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/2037703 Title: dpkg-reconfigure openssh-server doesn't ask questions again Status in openssh package in Ubuntu: New Bug description: openssh-server does provide a couple of configuration options: [~]$ sudo debconf-get-selections |grep openssh-server openssh-serveropenssh-server/listenstream-may-failerror openssh-serveropenssh-server/password-authentication boolean true openssh-serveropenssh-server/permit-root-loginboolean true I want to change those options now interactively but nothing I tried worked and showed a dialog: [~]$ sudo dpkg-reconfigure -p low openssh-server Warning: Stopping ssh.service, but it can still be activated by: ssh.socket rescue-ssh.target is a disabled or a static unit not running, not starting it. [~]$ sudo dpkg-reconfigure -p low --force --frontend dialog openssh-server Warning: Stopping ssh.service, but it can still be activated by: ssh.socket rescue-ssh.target is a disabled or a static unit not running, not starting it. But the documentation (https://manpages.debian.org/testing/debconf- doc/debconf.7.en.html#Reconfiguring_packages) does state that those commands should ask those questions again. p.s. also tried with a lxc debian-sid container and had the same problem there. ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: openssh-server 1:9.3p1-1ubuntu3 ProcVersionSignature: Ubuntu 6.5.0-5.5-generic 6.5.0 Uname: Lin
[Touch-packages] [Bug 2046158] Re: Updating wireguard-peer.allowed-ips gets wrong default netmask for IPv6 addresses
Excellent, thanks Danilo for the super fast fix! ⭐
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2046158
Title:
Updating wireguard-peer.allowed-ips gets wrong default netmask for
IPv6 addresses
Status in netplan.io package in Ubuntu:
Confirmed
Status in network-manager package in Ubuntu:
Invalid
Bug description:
In https://cockpit-project.org/ we have an integration test for
NM+wireguard integration. That test starts with an IPv4-only
connection:
# cat /etc/netplan/90-NM-b5edee2d-c736-4827-bae3-c95e349cb73b.yaml
network:
version: 2
tunnels:
wg0:
renderer: NetworkManager
addresses:
- "10.0.0.2/24"
mode: "wireguard"
port: 51820
keys:
private: "KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E="
peers:
- keys:
public: "RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI="
allowed-ips:
- "10.0.0.1/32"
networkmanager:
uuid: "b5edee2d-c736-4827-bae3-c95e349cb73b"
name: "con-wg0"
passthrough:
ipv6.addr-gen-mode: "default"
ipv6.method: "disabled"
ipv6.ip6-privacy: "-1"
proxy._: ""
which gets rendered as
# cat /run/NetworkManager/system-connections/netplan-wg0.nmconnection
[connection]
id=con-wg0
type=wireguard
uuid=b5edee2d-c736-4827-bae3-c95e349cb73b
interface-name=wg0
[wireguard]
private-key=KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E=
listen-port=51820
[wireguard-peer.RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI=]
allowed-ips=10.0.0.1/32;
[ipv4]
method=manual
address1=10.0.0.2/24
[ipv6]
#Netplan: passthrough override
method=disabled
#Netplan: passthrough setting
addr-gen-mode=default
[proxy]
Now the UI modifies the "allowed-ips" setting to ["10.0.0.1",
"2001::1"]. Notably the addresses do *not* have a netmask, neither in
the original config nor that update. Unfortunately that update cannot
be done on the CLI:
# nmcli con modify con-wg0
"wireguard-peer.RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI=.allowed-ips"
"2001::1"
Error: invalid or not allowed setting 'wireguard-peer': 'wireguard-peer' not
among [connection, wireguard, match, ipv4, ipv6, hostname, link, tc, proxy].
So it has to happen via D-Bus:
"/org/freedesktop/NetworkManager/Settings/5","org.freedesktop.NetworkManager.Settings.Connection","Update",[{"connection":{"id":{"v":"con-
wg0","t":"s"},"interface-
name":{"v":"wg0","t":"s"},"permissions":{"t":"as","v":[]},"timestamp":{"t":"t","v":1702299778},"type":{"v":"wireguard","t":"s"},"uuid":{"v":"04237010-9663-4064-aa06-bcde279b67da","t":"s"},"autoconnect":{"v":true,"t":"b"},"autoconnect-
slaves":{"v":-1,"t":"i"}},"wireguard":{"listen-
port":{"v":51820,"t":"u"},"peers":{"v":[{"public-
key":{"t":"s","v":"2CvDKtc8k94LLpabq6rZdYh1Co8fzjhoAD61ESMfjSc="},"allowed-
ips":{"t":"as","v":["10.0.0.1/32","2001::1"]}}],"t":"aa{sv}"},"private-
key":{"v":"iDM1BknhsROJt8TpJnBNNHVCAqWnfqZEkL20+sVfXlA=","t":"s"}},"ipv4":{"address-
data":{"t":"aa{sv}","v":[{"address":{"t":"s","v":"10.0.0.2"},"prefix":{"t":"u","v":24}}]},"addresses":{"v":[[33554442,24,0]],"t":"aau"},"dns-
search":{"v":[],"t":"as"},"method":{"v":"manual","t":"s"},"route-
data":{"t":"aa{sv}","v":[]},"routes":{"t":"aau","v":[]},"dns":{"v":[],"t":"au"}},"ipv6":{"address-
data":{"t":"aa{sv}","v":[]},"addresses":{"v":[],"t":"a(ayuay)"},"dns-
search":{"v":[],"t":"as"},"method":{"v":"disabled","t":"s"},"route-
data":{"t":"aa{sv}","v":[]},"routes":{"v":[],"t":"a(ayuayu)"},"ignore-
auto-dns":{"v":false,"t":"b"},"ignore-auto-
routes":{"v":false,"t":"b"},"dns":{"v":[],"t":"aay"}},"proxy":{}}]]
But this generates a wrong "/32" default netmask in the netplan config
for the IPv6 address:
allowed-ips:
- "10.0.0.1/32"
- "2001::1/32"
On Fedora, with NM's default .nmconnection files, such a netmask is
not added on this call. The netplan backend should do that (not
second-guessing NM) or at least default to /128 for an IPv6 address.
Doing this D-Bus call with `busctl` is a nuisance. If you need a
reproducer at this level, I can spend an hour or so trying to stitch
it together, but I hope your unit tests make this easier somehow.
This was fine until 22.10, but with NM's new "netplan by default"
backend this regressed.
DistroRelease: Ubuntu 23.10
Package: network-manager 1.44.2-1ubuntu1.2
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2046158/+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 2046158] Re: Updating wireguard-peer.allowed-ips gets wrong default netmask for IPv6 addresses
** Description changed:
In https://cockpit-project.org/ we have an integration test for
NM+wireguard integration. That test starts with an IPv4-only connection:
# cat /etc/netplan/90-NM-b5edee2d-c736-4827-bae3-c95e349cb73b.yaml
network:
- version: 2
- tunnels:
- wg0:
- renderer: NetworkManager
- addresses:
- - "10.0.0.2/24"
- mode: "wireguard"
- port: 51820
- keys:
- private: "KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E="
- peers:
- - keys:
- public: "RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI="
- allowed-ips:
- - "10.0.0.1/32"
- networkmanager:
- uuid: "b5edee2d-c736-4827-bae3-c95e349cb73b"
- name: "con-wg0"
- passthrough:
- ipv6.addr-gen-mode: "default"
- ipv6.method: "disabled"
- ipv6.ip6-privacy: "-1"
- proxy._: ""
-
+ version: 2
+ tunnels:
+ wg0:
+ renderer: NetworkManager
+ addresses:
+ - "10.0.0.2/24"
+ mode: "wireguard"
+ port: 51820
+ keys:
+ private: "KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E="
+ peers:
+ - keys:
+ public: "RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI="
+ allowed-ips:
+ - "10.0.0.1/32"
+ networkmanager:
+ uuid: "b5edee2d-c736-4827-bae3-c95e349cb73b"
+ name: "con-wg0"
+ passthrough:
+ ipv6.addr-gen-mode: "default"
+ ipv6.method: "disabled"
+ ipv6.ip6-privacy: "-1"
+ proxy._: ""
which gets rendered as
# cat /run/NetworkManager/system-connections/netplan-wg0.nmconnection
[connection]
id=con-wg0
type=wireguard
uuid=b5edee2d-c736-4827-bae3-c95e349cb73b
interface-name=wg0
[wireguard]
private-key=KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E=
listen-port=51820
[wireguard-peer.RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI=]
allowed-ips=10.0.0.1/32;
[ipv4]
method=manual
address1=10.0.0.2/24
[ipv6]
#Netplan: passthrough override
method=disabled
#Netplan: passthrough setting
addr-gen-mode=default
[proxy]
-
- Now the UI modifies the "allowed-ips" setting to ["10.0.0.1", "2001::1"].
Notably the addresses do *not* have a netmask, neither in the original config
nor that update. Unfortunately that update cannot be done on the CLI:
+ Now the UI modifies the "allowed-ips" setting to ["10.0.0.1",
+ "2001::1"]. Notably the addresses do *not* have a netmask, neither in
+ the original config nor that update. Unfortunately that update cannot be
+ done on the CLI:
# nmcli con modify con-wg0
"wireguard-peer.RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI=.allowed-ips"
"2001::1"
Error: invalid or not allowed setting 'wireguard-peer': 'wireguard-peer' not
among [connection, wireguard, match, ipv4, ipv6, hostname, link, tc, proxy].
-
So it has to happen via D-Bus:
"/org/freedesktop/NetworkManager/Settings/5","org.freedesktop.NetworkManager.Settings.Connection","Update",[{"connection":{"id":{"v":"con-
wg0","t":"s"},"interface-
name":{"v":"wg0","t":"s"},"permissions":{"t":"as","v":[]},"timestamp":{"t":"t","v":1702299778},"type":{"v":"wireguard","t":"s"},"uuid":{"v":"04237010-9663-4064-aa06-bcde279b67da","t":"s"},"autoconnect":{"v":true,"t":"b"},"autoconnect-
slaves":{"v":-1,"t":"i"}},"wireguard":{"listen-
port":{"v":51820,"t":"u"},"peers":{"v":[{"public-
key":{"t":"s","v":"2CvDKtc8k94LLpabq6rZdYh1Co8fzjhoAD61ESMfjSc="},"allowed-
ips":{"t":"as","v":["10.0.0.1/32","2001::1"]}}],"t":"aa{sv}"},"private-
key":{"v":"iDM1BknhsROJt8TpJnBNNHVCAqWnfqZEkL20+sVfXlA=","t":"s"}},"ipv4":{"address-
data":{"t":"aa{sv}","v":[{"address":{"t":"s","v":"10.0.0.2"},"prefix":{"t":"u","v":24}}]},"addresses":{"v":[[33554442,24,0]],"t":"aau"},"dns-
search":{"v":[],"t":"as"},"method":{"v":"manual","t":"s"},"route-
data":{"t":"aa{sv}","v":[]},"routes":{"t":"aau","v":[]},"dns":{"v":[],"t":"au"}},"ipv6":{"address-
data":{"t":"aa{sv}","v":[]},"addresses":{"v":[],"t":"a(ayuay)"},"dns-
search":{"v":[],"t":"as"},"method":{"v":"disabled","t":"s"},"route-
data":{"t":"aa{sv}","v":[]},"routes":{"v":[],"t":"a(ayuayu)"},"ignore-
auto-dns":{"v":false,"t":"b"},"ignore-auto-
routes":{"v":false,"t":"b"},"dns":{"v":[],"t":"aay"}},"proxy":{}}]]
+ But this generates a wrong "/32" default netmask in the netplan config
+ for the IPv6 address:
- But this generates a wrong "/32" default netmask in the netplan config for
the IPv6 address:
-
- allowed-ips:
- - "10.0.0.1/32"
- - "2001::1/32"
+ allowed-ips:
+ - "10.0.0.1/32"
+ - "2001::1/32"
On Fedora, with NM's default .nmconnection files, such a netmask is not
added on this call. The netplan backend should do that (not second-
guessing NM) or at least default to /128 for an IPv6 address.
Doing this D-Bus call with `busctl` is a nuisance. If you need a
reproducer at this level, I can spend an hour o
[Touch-packages] [Bug 2046158] [NEW] Updating wireguard-peer.allowed-ips gets wrong default netmask for IPv6 addresses
Public bug reported:
In https://cockpit-project.org/ we have an integration test for
NM+wireguard integration. That test starts with an IPv4-only connection:
# cat /etc/netplan/90-NM-b5edee2d-c736-4827-bae3-c95e349cb73b.yaml
network:
version: 2
tunnels:
wg0:
renderer: NetworkManager
addresses:
- "10.0.0.2/24"
mode: "wireguard"
port: 51820
keys:
private: "KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E="
peers:
- keys:
public: "RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI="
allowed-ips:
- "10.0.0.1/32"
networkmanager:
uuid: "b5edee2d-c736-4827-bae3-c95e349cb73b"
name: "con-wg0"
passthrough:
ipv6.addr-gen-mode: "default"
ipv6.method: "disabled"
ipv6.ip6-privacy: "-1"
proxy._: ""
which gets rendered as
# cat /run/NetworkManager/system-connections/netplan-wg0.nmconnection
[connection]
id=con-wg0
type=wireguard
uuid=b5edee2d-c736-4827-bae3-c95e349cb73b
interface-name=wg0
[wireguard]
private-key=KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E=
listen-port=51820
[wireguard-peer.RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI=]
allowed-ips=10.0.0.1/32;
[ipv4]
method=manual
address1=10.0.0.2/24
[ipv6]
#Netplan: passthrough override
method=disabled
#Netplan: passthrough setting
addr-gen-mode=default
[proxy]
Now the UI modifies the "allowed-ips" setting to ["10.0.0.1", "2001::1"].
Notably the addresses do *not* have a netmask, neither in the original config
nor that update. Unfortunately that update cannot be done on the CLI:
# nmcli con modify con-wg0
"wireguard-peer.RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI=.allowed-ips"
"2001::1"
Error: invalid or not allowed setting 'wireguard-peer': 'wireguard-peer' not
among [connection, wireguard, match, ipv4, ipv6, hostname, link, tc, proxy].
So it has to happen via D-Bus:
"/org/freedesktop/NetworkManager/Settings/5","org.freedesktop.NetworkManager.Settings.Connection","Update",[{"connection":{"id":{"v":"con-
wg0","t":"s"},"interface-
name":{"v":"wg0","t":"s"},"permissions":{"t":"as","v":[]},"timestamp":{"t":"t","v":1702299778},"type":{"v":"wireguard","t":"s"},"uuid":{"v":"04237010-9663-4064-aa06-bcde279b67da","t":"s"},"autoconnect":{"v":true,"t":"b"},"autoconnect-
slaves":{"v":-1,"t":"i"}},"wireguard":{"listen-
port":{"v":51820,"t":"u"},"peers":{"v":[{"public-
key":{"t":"s","v":"2CvDKtc8k94LLpabq6rZdYh1Co8fzjhoAD61ESMfjSc="},"allowed-
ips":{"t":"as","v":["10.0.0.1/32","2001::1"]}}],"t":"aa{sv}"},"private-
key":{"v":"iDM1BknhsROJt8TpJnBNNHVCAqWnfqZEkL20+sVfXlA=","t":"s"}},"ipv4":{"address-
data":{"t":"aa{sv}","v":[{"address":{"t":"s","v":"10.0.0.2"},"prefix":{"t":"u","v":24}}]},"addresses":{"v":[[33554442,24,0]],"t":"aau"},"dns-
search":{"v":[],"t":"as"},"method":{"v":"manual","t":"s"},"route-
data":{"t":"aa{sv}","v":[]},"routes":{"t":"aau","v":[]},"dns":{"v":[],"t":"au"}},"ipv6":{"address-
data":{"t":"aa{sv}","v":[]},"addresses":{"v":[],"t":"a(ayuay)"},"dns-
search":{"v":[],"t":"as"},"method":{"v":"disabled","t":"s"},"route-
data":{"t":"aa{sv}","v":[]},"routes":{"v":[],"t":"a(ayuayu)"},"ignore-
auto-dns":{"v":false,"t":"b"},"ignore-auto-
routes":{"v":false,"t":"b"},"dns":{"v":[],"t":"aay"}},"proxy":{}}]]
But this generates a wrong "/32" default netmask in the netplan config for the
IPv6 address:
allowed-ips:
- "10.0.0.1/32"
- "2001::1/32"
On Fedora, with NM's default .nmconnection files, such a netmask is not
added on this call. The netplan backend should do that (not second-
guessing NM) or at least default to /128 for an IPv6 address.
Doing this D-Bus call with `busctl` is a nuisance. If you need a
reproducer at this level, I can spend an hour or so trying to stitch it
together, but I hope your unit tests make this easier somehow.
This was fine until 22.10, but with NM's new "netplan by default"
backend this regressed.
DistroRelease: Ubuntu 23.04
Package: network-manager 1.44.2-1ubuntu1.2
** Affects: network-manager (Ubuntu)
Importance: Undecided
Status: New
** Tags: mantic regression-release
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2046158
Title:
Updating wireguard-peer.allowed-ips gets wrong default netmask for
IPv6 addresses
Status in network-manager package in Ubuntu:
New
Bug description:
In https://cockpit-project.org/ we have an integration test for
NM+wireguard integration. That test starts with an IPv4-only
connection:
# cat /etc/netplan/90-NM-b5edee2d-c736-4827-bae3-c95e349cb73b.yaml
network:
version: 2
tunnels:
wg0:
renderer: NetworkManager
addresses:
- "10.0.0.2/24"
mode: "wireguard"
port: 51820
keys:
private: "KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E="
peers:
- keys:
public: "RsfKtJHMIAYs/
[Touch-packages] [Bug 2040483] Re: AppArmor denies crun sending signals to containers (stop, kill)
I also tried aa-disable usr.bin.crun but that doesn't work either. I guess it's not really crun, but profile="containers-default-0.50.1", but that is created dynamically -- it's not anywhere in /etc/apparmor.d/. I grepped the whole file system for that: grep: /usr/lib/podman/rootlessport: binary file matches grep: /usr/bin/podman: binary file matches grep: /usr/bin/buildah: binary file matches Running an individual container with --security-opt=label=disable also doesn't work, same DENIED and failure. "man containers.conf" points at apparmor_profile="container‐default", but not how to disable it. I naively tried apparmor_profile="none" but Error: AppArmor profile "none" specified but not loaded But curiously an empty string works. 🎉 So, my official workaround: mkdir -p /etc/containers/containers.conf.d printf '[CONTAINERS]\napparmor_profile=""\n' > /etc/containers/containers.conf.d/disable-apparmor.conf ** No longer affects: apparmor (Ubuntu) ** No longer affects: apparmor (Ubuntu Mantic) ** No longer affects: apparmor (Ubuntu Noble) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2040483 Title: AppArmor denies crun sending signals to containers (stop, kill) Status in libpod package in Ubuntu: Confirmed Status in libpod source package in Mantic: New Status in libpod source package in Noble: Confirmed Bug description: Mantic's system podman containers are completely broken due to bug 2040082. However, after fixing that (rebuilding with the patch, or a *shht don't try this at home* hack [1]), the AppArmor policy still causes bugs: podman run -it --rm docker.io/busybox Then podman stop -l fails with 2023-10-25T11:06:33.873998Z: send signal to pidfd: Permission denied and journal shows audit: type=1400 audit(1698231993.870:92): apparmor="DENIED" operation="signal" class="signal" profile="containers-default-0.50.1" pid=4713 comm="3" requested_mask="receive" denied_mask="receive" signal=term peer="/usr/bin/crun" This leaves the container in a broken state: # podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 61749260f9c4 docker.io/library/busybox:latest sh 40 seconds ago Exited (-1) 29 seconds ago confident_bouman # podman rm --all 2023-10-25T11:07:21.428701Z: send signal to pidfd: Permission denied Error: cleaning up container 61749260f9c4c96a51dc27fdd9cb8a86d80e4f2aa14eb7ed5b271791ff8008ae: removing container 61749260f9c4c96a51dc27fdd9cb8a86d80e4f2aa14eb7ed5b271791ff8008ae from runtime: `/usr/bin/crun delete --force 61749260f9c4c96a51dc27fdd9cb8a86d80e4f2aa14eb7ed5b271791ff8008ae` failed: exit status 1 audit: type=1400 audit(1698232041.422:93): apparmor="DENIED" operation="signal" class="signal" profile="containers-default-0.50.1" pid=4839 comm="3" requested_mask="receive" denied_mask="receive" signal=kill peer="/usr/bin/crun" [1] sed -i 's/~alpha2/000/' /usr/sbin/apparmor_parser Ubuntu 23.10 ii apparmor4.0.0~alpha2-0ubuntu5 amd64 user-space parser utility for AppArmor ii golang-github-containers-common 0.50.1+ds1-4 all Common files for github.com/containers repositories ii podman 4.3.1+ds1-8 amd64engine to run OCI-based containers in Pods To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/2040483/+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 2040483] Re: AppArmor denies crun sending signals to containers (stop, kill)
I tried a more targeted workaround, with aa-complain /etc/apparmor.d/usr.bin.crun or alternatively (without apparmor-utils, which isn't on the default cloud image): sed -i '/flags=/ s/unconfined/complain/' /etc/apparmor.d/usr.bin.crun but for some reason that breaks podman entirely: # podman run -it --rm docker.io/busybox Failed to re-execute libcrun via memory file descriptor ERRO[] Removing container 7c3c938f8e356a9834de6a114ad8b8353ffac7508c8aac131d588e1358ba2f30 from runtime after creation failed Error: OCI runtime error: crun: Failed to re-execute libcrun via memory file descriptor I just noticed that neither podman nor crun ship their own AppArmor profiles, /etc/apparmor.d/usr.bin.crun is shipped by apparmor. So adding a package task, but leaving libpod as "affected", so that it is easier to find. ** Also affects: apparmor (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/2040483 Title: AppArmor denies crun sending signals to containers (stop, kill) Status in apparmor package in Ubuntu: New Status in libpod package in Ubuntu: Confirmed Status in apparmor source package in Mantic: New Status in libpod source package in Mantic: New Status in apparmor source package in Noble: New Status in libpod source package in Noble: Confirmed Bug description: Mantic's system podman containers are completely broken due to bug 2040082. However, after fixing that (rebuilding with the patch, or a *shht don't try this at home* hack [1]), the AppArmor policy still causes bugs: podman run -it --rm docker.io/busybox Then podman stop -l fails with 2023-10-25T11:06:33.873998Z: send signal to pidfd: Permission denied and journal shows audit: type=1400 audit(1698231993.870:92): apparmor="DENIED" operation="signal" class="signal" profile="containers-default-0.50.1" pid=4713 comm="3" requested_mask="receive" denied_mask="receive" signal=term peer="/usr/bin/crun" This leaves the container in a broken state: # podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 61749260f9c4 docker.io/library/busybox:latest sh 40 seconds ago Exited (-1) 29 seconds ago confident_bouman # podman rm --all 2023-10-25T11:07:21.428701Z: send signal to pidfd: Permission denied Error: cleaning up container 61749260f9c4c96a51dc27fdd9cb8a86d80e4f2aa14eb7ed5b271791ff8008ae: removing container 61749260f9c4c96a51dc27fdd9cb8a86d80e4f2aa14eb7ed5b271791ff8008ae from runtime: `/usr/bin/crun delete --force 61749260f9c4c96a51dc27fdd9cb8a86d80e4f2aa14eb7ed5b271791ff8008ae` failed: exit status 1 audit: type=1400 audit(1698232041.422:93): apparmor="DENIED" operation="signal" class="signal" profile="containers-default-0.50.1" pid=4839 comm="3" requested_mask="receive" denied_mask="receive" signal=kill peer="/usr/bin/crun" [1] sed -i 's/~alpha2/000/' /usr/sbin/apparmor_parser Ubuntu 23.10 ii apparmor4.0.0~alpha2-0ubuntu5 amd64 user-space parser utility for AppArmor ii golang-github-containers-common 0.50.1+ds1-4 all Common files for github.com/containers repositories ii podman 4.3.1+ds1-8 amd64engine to run OCI-based containers in Pods To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2040483/+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 1989073] Re: AppArmor DENIES reading of /sys/devices/system/cpu/possible
Similar issue: https://gitlab.com/libvirt/libvirt/-/issues/548 . These two may want a common fix with "allow qemu to read sysfs"? ** Bug watch added: gitlab.com/libvirt/libvirt/-/issues #548 https://gitlab.com/libvirt/libvirt/-/issues/548 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1989073 Title: AppArmor DENIES reading of /sys/devices/system/cpu/possible Status in apparmor package in Ubuntu: Confirmed Status in apparmor source package in Kinetic: Won't Fix Bug description: libvirt 8.6.0-0ubuntu1 apparmor 3.0.7-1ubuntu1 Creating a VM with virt-install produces this AppAmore denial: AVC apparmor="DENIED" operation="open" profile="libvirt-974c9859-e682-4f5d-b0cb-dcf3d60185fc" name="/sys/devices/system/cpu/possible" pid=2522 comm="qemu- system-x86" requested_mask="r" denied_mask="r" fsuid=64055 ouid=0 Creation of the VM is successful. This is with nested virtualization. This did not happen with libvirt 8.0.0-1ubuntu8 and apparmor 3.0.7-1ubuntu1. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1989073/+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 2019122] Re: Autopkgtest failure
https://github.com/martinpitt/umockdev/issues/208
Thanks Heinrich!
** Bug watch added: github.com/martinpitt/umockdev/issues #208
https://github.com/martinpitt/umockdev/issues/208
** Changed in: umockdev (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to umockdev in Ubuntu.
https://bugs.launchpad.net/bugs/2019122
Title:
Autopkgtest failure
Status in umockdev package in Ubuntu:
In Progress
Bug description:
Autopkgtests fail when trying to delete a missing file.
tests/test-umockdev-run.vala:596:
checked_remove ("/tmp/.X11-unix/X5");
Upstream has a patch for a similar problem:
a2953b1122f4 ("test: Allow missing /tmp/.X5-lock files”)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/umockdev/+bug/2019122/+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 1982482] Re: SSH password login not attempted/denied
D'oh! # cat /etc/ssh/sshd_config.d/10-cloudimg-settings.conf PasswordAuthentication no rm + restart sshd, everything is hunky-dory. Sorry for the noise! ** Changed in: openssh (Ubuntu Kinetic) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1982482 Title: SSH password login not attempted/denied Status in openssh package in Ubuntu: Invalid Status in openssh source package in Kinetic: Invalid Bug description: I am in the process of updating our CI for Cockpit to kinetic [1]. I get a lot of test failures because SSH password login is broken. This can be replicated with a clean cloud instance, so it's not something that our VM build scripts do: curl -L -O https://cloud-images.ubuntu.com/daily/server/kinetic/current/kinetic-server-cloudimg-amd64.img # nothing fancy, just admin:foobar and root:foobar curl -L -O https://github.com/cockpit-project/bots/raw/main/machine/cloud-init.iso Boot the image: qemu-system-x86_64 -cpu host -enable-kvm -nographic -m 2048 -drive file=kinetic-server-cloudimg-amd64.img,if=virtio -snapshot -cdrom cloud-init.iso -net nic,model=virtio -net user,hostfwd=tcp::22001-:22 For some reason that doesn't create an "admin" user. So log into VT as root:foobar and create a user: adduser test1 Now, inside the VM VT: root@ubuntu:~# ssh user1@localhost user1@localhost: Permission denied (publickey). The same happens when trying to ssh from outside: ❱❱❱ ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o CheckHostIP=no -p 22001 user1@localhost user1@localhost: Permission denied (publickey). It does not seem to even *attempt* password auth: ❱❱❱ ssh -vv -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o CheckHostIP=no -p 22001 user1@localhost 2>&1|grep -i method debug1: Next authentication method: publickey debug2: we did not send a packet, disable method debug1: No more authentication methods to try. ... like it would to other OSes: debug1: Next authentication method: keyboard-interactive Password authentication is enabled by default: $ grep -i password /etc/ssh/sshd_config #PermitRootLogin prohibit-password # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # PasswordAuthentication. Depending on your PAM configuration, # the setting of "PermitRootLogin without-password". # PAM authentication, then enable this but set PasswordAuthentication PasswordAuthentication yes [1] https://github.com/cockpit-project/bots/pull/3641 and https://github.com/cockpit-project/cockpit/pull/17582 ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: openssh-server 1:9.0p1-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1982482/+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 1982482] Re: SSH password login not attempted/denied
I set LogLevel=DEBUG in /etc/ssh/sshd_config, systemctl restart sshd, and I'm none the wiser: debug1: Forked child 1652. debug1: Set /proc/self/oom_score_adj to 0 debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8 debug1: inetd sockets after dupping: 4, 4 Connection from 127.0.0.1 port 45396 on 127.0.0.1 port 22 rdomain "" debug1: Local version string SSH-2.0-OpenSSH_9.0p1 Ubuntu-1 debug1: Remote protocol version 2.0, remote software version OpenSSH_9.0p1 Ubuntu-1 debug1: compat_banner: match: OpenSSH_9.0p1 Ubuntu-1 pat OpenSSH* compat 0x0400 debug1: permanently_set_uid: 109/65534 [preauth] debug1: list_hostkey_types: rsa-sha2-512,rsa-sha2-256 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug1: kex: algorithm: sntrup761x25519-sha...@openssh.com [preauth] debug1: kex: host key algorithm: rsa-sha2-512 [preauth] debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: compression: none [preauth] debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: compression: none [preauth] debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth] debug1: SSH2_MSG_KEX_ECDH_INIT received [preauth] debug1: rekey out after 134217728 blocks [preauth] debug1: SSH2_MSG_NEWKEYS sent [preauth] debug1: Sending SSH2_MSG_EXT_INFO [preauth] debug1: expecting SSH2_MSG_NEWKEYS [preauth] debug1: SSH2_MSG_NEWKEYS received [preauth] debug1: rekey in after 134217728 blocks [preauth] debug1: KEX done [preauth] debug1: userauth-request for user user1 service ssh-connection method none [preauth] debug1: attempt 0 failures 0 [preauth] debug1: PAM: initializing for "user1" debug1: PAM: setting PAM_RHOST to "127.0.0.1" debug1: PAM: setting PAM_TTY to "ssh" Connection closed by authenticating user user1 127.0.0.1 port 45396 [preauth] debug1: do_cleanup [preauth] debug1: monitor_read_log: child log fd closed debug1: do_cleanup debug1: PAM: cleanup debug1: Killing privsep child 1653 debug1: audit_event: unhandled event 12 again, no trace of password/keyboard authentication. Note that this is the same openssh package version that we've had in Debian testing for three months, and that works just fine. So possibly some broken PAM config? ** Description changed: I am in the process of updating our CI for Cockpit to kinetic [1]. I get a lot of test failures because SSH password login is broken. This can be replicated with a clean cloud instance, so it's not something that our VM build scripts do: - curl -L -O https://cloud-images.ubuntu.com/daily/server/kinetic/current/kinetic-server-cloudimg-amd64.img - # nothing fancy, just admin:foobar and root:foobar - curl -L -O https://github.com/cockpit-project/bots/raw/main/machine/cloud-init.iso + curl -L -O https://cloud-images.ubuntu.com/daily/server/kinetic/current/kinetic-server-cloudimg-amd64.img + # nothing fancy, just admin:foobar and root:foobar + curl -L -O https://github.com/cockpit-project/bots/raw/main/machine/cloud-init.iso Boot the image: - qemu-system-x86_64 -cpu host -enable-kvm -nographic -m 2048 -drive file=kinetic-server-cloudimg-amd64.img,if=virtio -snapshot -cdrom cloud-init.iso -net nic,model=virtio -net user,hostfwd=tcp::22001-:22 + qemu-system-x86_64 -cpu host -enable-kvm -nographic -m 2048 -drive file=kinetic-server-cloudimg-amd64.img,if=virtio -snapshot -cdrom cloud-init.iso -net nic,model=virtio -net user,hostfwd=tcp::22001-:22 For some reason that doesn't create an "admin" user. So log into VT as root:foobar and create a user: - adduser test1 + adduser test1 Now, inside the VM VT: - root@ubuntu:~# ssh user1@localhost - user1@localhost: Permission denied (publickey). + root@ubuntu:~# ssh user1@localhost + user1@localhost: Permission denied (publickey). The same happens when trying to ssh from outside: - ❱❱❱ ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o CheckHostIP=no -p 22001 user1@localhost - user1@localhost: Permission denied (publickey). + ❱❱❱ ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o CheckHostIP=no -p 22001 user1@localhost + user1@localhost: Permission denied (publickey). It does not seem to even *attempt* password auth: - ❱❱❱ ssh -vv -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o CheckHostIP=no -p 22001 user1@localhost 2>&1|grep -i method - debug1: Next authentication method: publickey - debug2: we did not send a packet, disable method - debug1: No more authentication methods to try. + ❱❱❱ ssh -vv -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o CheckHostIP=no -p 22001 user1@localhost 2>&1|grep -i method + debug1: Next authentication method: publickey + debug2: we did not send a packet, disable method + debug1: No more authentication methods to try. ... like it would to other OSes: - debug1: Next authentication method: keyboard-interactive + debug1: Next authentication method: keyboard
[Touch-packages] [Bug 1982482] [NEW] SSH password login not attempted/denied
Public bug reported: I am in the process of updating our CI for Cockpit to kinetic [1]. I get a lot of test failures because SSH password login is broken. This can be replicated with a clean cloud instance, so it's not something that our VM build scripts do: curl -L -O https://cloud-images.ubuntu.com/daily/server/kinetic/current/kinetic-server-cloudimg-amd64.img # nothing fancy, just admin:foobar and root:foobar curl -L -O https://github.com/cockpit-project/bots/raw/main/machine/cloud-init.iso Boot the image: qemu-system-x86_64 -cpu host -enable-kvm -nographic -m 2048 -drive file=kinetic-server-cloudimg-amd64.img,if=virtio -snapshot -cdrom cloud-init.iso -net nic,model=virtio -net user,hostfwd=tcp::22001-:22 For some reason that doesn't create an "admin" user. So log into VT as root:foobar and create a user: adduser test1 Now, inside the VM VT: root@ubuntu:~# ssh user1@localhost user1@localhost: Permission denied (publickey). The same happens when trying to ssh from outside: ❱❱❱ ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o CheckHostIP=no -p 22001 user1@localhost user1@localhost: Permission denied (publickey). It does not seem to even *attempt* password auth: ❱❱❱ ssh -vv -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o CheckHostIP=no -p 22001 user1@localhost 2>&1|grep -i method debug1: Next authentication method: publickey debug2: we did not send a packet, disable method debug1: No more authentication methods to try. ... like it would to other OSes: debug1: Next authentication method: keyboard-interactive Password authentication is enabled by default: $ grep -i password /etc/ssh/sshd_config #PermitRootLogin prohibit-password # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # PasswordAuthentication. Depending on your PAM configuration, # the setting of "PermitRootLogin without-password". # PAM authentication, then enable this but set PasswordAuthentication PasswordAuthentication yes [1] https://github.com/cockpit-project/bots/pull/3641 and https://github.com/cockpit-project/cockpit/pull/17582 ProblemType: Bug DistroRelease: Ubuntu 22.10 Package: openssh-server 1:9.0p1-1 ** Affects: openssh (Ubuntu) Importance: High Status: New ** Affects: openssh (Ubuntu Kinetic) Importance: High Status: New ** Tags: kinetic regression-release -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1982482 Title: SSH password login not attempted/denied Status in openssh package in Ubuntu: New Status in openssh source package in Kinetic: New Bug description: I am in the process of updating our CI for Cockpit to kinetic [1]. I get a lot of test failures because SSH password login is broken. This can be replicated with a clean cloud instance, so it's not something that our VM build scripts do: curl -L -O https://cloud-images.ubuntu.com/daily/server/kinetic/current/kinetic-server-cloudimg-amd64.img # nothing fancy, just admin:foobar and root:foobar curl -L -O https://github.com/cockpit-project/bots/raw/main/machine/cloud-init.iso Boot the image: qemu-system-x86_64 -cpu host -enable-kvm -nographic -m 2048 -drive file=kinetic-server-cloudimg-amd64.img,if=virtio -snapshot -cdrom cloud-init.iso -net nic,model=virtio -net user,hostfwd=tcp::22001-:22 For some reason that doesn't create an "admin" user. So log into VT as root:foobar and create a user: adduser test1 Now, inside the VM VT: root@ubuntu:~# ssh user1@localhost user1@localhost: Permission denied (publickey). The same happens when trying to ssh from outside: ❱❱❱ ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o CheckHostIP=no -p 22001 user1@localhost user1@localhost: Permission denied (publickey). It does not seem to even *attempt* password auth: ❱❱❱ ssh -vv -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o CheckHostIP=no -p 22001 user1@localhost 2>&1|grep -i method debug1: Next authentication method: publickey debug2: we did not send a packet, disable method debug1: No more authentication methods to try. ... like it would to other OSes: debug1: Next authentication method: keyboard-interactive Password authentication is enabled by default: $ grep -i password /etc/ssh/sshd_config #PermitRootLogin prohibit-password # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # PasswordAuthentication. Depending on your PAM configuration, # the setting of "PermitRootLogin without-passwo
[Touch-packages] [Bug 1966416] Re: pam_faillock does not actually deny login after given number of failures
Ouch, thanks Marc! Indeed our previous seddery was broken, it should
have left the pam_deny/pam_permit lines. With this it works just fine:
--- /tmp/common-auth.orig 2022-04-01 07:16:26.072608984 +0200
+++ /tmp/common-auth.faillock 2022-04-01 07:14:20.246707861 +0200
@@ -16,6 +16,8 @@
# here are the per-package modules (the "Primary" block)
auth [success=2 default=ignore] pam_unix.so nullok
auth [success=1 default=ignore] pam_sss.so use_first_pass
+auth [default=die] pam_faillock.so authfail deny=4
+auth sufficient pam_faillock.so authsucc deny=4
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
Sorry for the noise!
** Changed in: pam (Ubuntu Jammy)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/1966416
Title:
pam_faillock does not actually deny login after given number of
failures
Status in pam package in Ubuntu:
Invalid
Status in pam source package in Jammy:
Invalid
Bug description:
ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: libpam-modules 1.4.0-11ubuntu1
I just noticed that Ubuntu 22.04 changed from the old pam_tally2
module to the more widespread pam_faillock one. \o/
However, locking (denying logins) does not actually seem to work.
According to pam_faillock(8) I changed the config like this:
# diff -u /etc/pam.d/common-auth{.orig,}
--- /etc/pam.d/common-auth.orig 2022-03-25 10:41:29.08800 +
+++ /etc/pam.d/common-auth2022-03-25 10:48:48.913419254 +
@@ -17,11 +17,11 @@
auth [success=2 default=ignore] pam_unix.so nullok
auth [success=1 default=ignore] pam_sss.so use_first_pass
# here's the fallback if no module succeeds
-auth requisite pam_deny.so
+auth [default=die] pam_faillock.so authfail
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
-auth requiredpam_permit.so
+auth sufficient pam_faillock.so authsucc
# and here are more per-package modules (the "Additional" block)
auth optionalpam_cap.so
# end of pam-auth-update config
This config works fine on both Debian 11 and Debian testing, and it agrees
with the example in the manpage -- so I don't think it's that broken.
Start from a blank slate:
# faillock --user admin --reset
# faillock --user admin
admin:
WhenType Source
Valid
Now I log in as user "admin" with a wrong password four times (one
more than the default "deny=3", just to make sure):
sshd[3841]: pam_unix(sshd:auth): authentication failure; logname= uid=0
euid=0 tty=ssh ruser= rhost=172.27.0.2 user=admin
sshd[3841]: Failed password for admin from 172.27.0.2 port 39446 ssh2
After the third time, I even see this in the journal:
sshd[3841]: Failed password for admin from 172.27.0.2 port 39446 ssh2
pam_faillock(sshd:auth): Consecutive login failures for user admin account
temporarily locked
Failed password for admin from 172.27.0.2 port 39446 ssh2
But if I then log in with the correct password, it succeeds:
sshd[4492]: Accepted password for admin from 172.27.0.2 port 39450 ssh2
sshd[4492]: pam_unix(sshd:session): session opened for user admin(uid=1000)
by (uid=0)
That's buggy -- "admin" should be denied access for ten minutes
("unlock_time = 600" in /etc/security/faillock.conf).
It did record the failed logins alright:
# faillock --user admin
admin:
WhenType Source
Valid
2022-03-25 10:54:02 RHOST 172.27.0.2
V
2022-03-25 10:54:27 RHOST 172.27.0.2
V
2022-03-25 10:54:30 RHOST 172.27.0.2
V
But the actual denial doesn't seem to work.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1966416/+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 1966416] [NEW] pam_faillock does not actually deny login after given number of failures
Public bug reported:
ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: libpam-modules 1.4.0-11ubuntu1
I just noticed that Ubuntu 22.04 changed from the old pam_tally2 module
to the more widespread pam_faillock one. \o/
However, locking (denying logins) does not actually seem to work.
According to pam_faillock(8) I changed the config like this:
# diff -u /etc/pam.d/common-auth{.orig,}
--- /etc/pam.d/common-auth.orig 2022-03-25 10:41:29.08800 +
+++ /etc/pam.d/common-auth 2022-03-25 10:48:48.913419254 +
@@ -17,11 +17,11 @@
auth [success=2 default=ignore] pam_unix.so nullok
auth [success=1 default=ignore] pam_sss.so use_first_pass
# here's the fallback if no module succeeds
-auth requisite pam_deny.so
+auth [default=die] pam_faillock.so authfail
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
-auth requiredpam_permit.so
+auth sufficient pam_faillock.so authsucc
# and here are more per-package modules (the "Additional" block)
auth optionalpam_cap.so
# end of pam-auth-update config
This config works fine on both Debian 11 and Debian testing, and it agrees with
the example in the manpage -- so I don't think it's that broken.
Start from a blank slate:
# faillock --user admin --reset
# faillock --user admin
admin:
WhenType Source Valid
Now I log in as user "admin" with a wrong password four times (one more
than the default "deny=3", just to make sure):
sshd[3841]: pam_unix(sshd:auth): authentication failure; logname= uid=0
euid=0 tty=ssh ruser= rhost=172.27.0.2 user=admin
sshd[3841]: Failed password for admin from 172.27.0.2 port 39446 ssh2
After the third time, I even see this in the journal:
sshd[3841]: Failed password for admin from 172.27.0.2 port 39446 ssh2
pam_faillock(sshd:auth): Consecutive login failures for user admin account
temporarily locked
Failed password for admin from 172.27.0.2 port 39446 ssh2
But if I then log in with the correct password, it succeeds:
sshd[4492]: Accepted password for admin from 172.27.0.2 port 39450 ssh2
sshd[4492]: pam_unix(sshd:session): session opened for user admin(uid=1000) by
(uid=0)
That's buggy -- "admin" should be denied access for ten minutes
("unlock_time = 600" in /etc/security/faillock.conf).
It did record the failed logins alright:
# faillock --user admin
admin:
WhenType Source Valid
2022-03-25 10:54:02 RHOST 172.27.0.2 V
2022-03-25 10:54:27 RHOST 172.27.0.2 V
2022-03-25 10:54:30 RHOST 172.27.0.2 V
But the actual denial doesn't seem to work.
** Affects: pam (Ubuntu)
Importance: Undecided
Status: New
** Tags: jammy regression-release
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pam in Ubuntu.
https://bugs.launchpad.net/bugs/1966416
Title:
pam_faillock does not actually deny login after given number of
failures
Status in pam package in Ubuntu:
New
Bug description:
ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: libpam-modules 1.4.0-11ubuntu1
I just noticed that Ubuntu 22.04 changed from the old pam_tally2
module to the more widespread pam_faillock one. \o/
However, locking (denying logins) does not actually seem to work.
According to pam_faillock(8) I changed the config like this:
# diff -u /etc/pam.d/common-auth{.orig,}
--- /etc/pam.d/common-auth.orig 2022-03-25 10:41:29.08800 +
+++ /etc/pam.d/common-auth2022-03-25 10:48:48.913419254 +
@@ -17,11 +17,11 @@
auth [success=2 default=ignore] pam_unix.so nullok
auth [success=1 default=ignore] pam_sss.so use_first_pass
# here's the fallback if no module succeeds
-auth requisite pam_deny.so
+auth [default=die] pam_faillock.so authfail
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
-auth requiredpam_permit.so
+auth sufficient pam_faillock.so authsucc
# and here are more per-package modules (the "Additional" block)
auth optionalpam_cap.so
# end of pam-auth-update config
This config works fine on both Debian 11 and Debian testing, and it agrees
with the example in the manpage -- so I don't think it's that broken.
Start from a blank slate:
# faillock --user admin --reset
# faillock --user admin
admin:
WhenType S
[Touch-packages] [Bug 1962035] Re: apparmor blocks VM installation when automatic UEFI firmware is set
/etc/apparmor.d/abstractions/libvirt-qemu is shipped by libvirt-daemon-
system, reassigning. I can reproduce this, and I'll attempt to work on a
fix. I'll update the Debian bug as well.
Complete copy&paste-able reproducer:
virt-install --connect qemu:///system --quiet --os-variant fedora28 --memory
128 --name test --wait -1 --disk size=0.125,format=qcow2 --graphics
vnc,listen=127.0.0.1 --graphics spice,listen=127.0.0.1 --print-xml 1 | sed
"s/ /tmp/test1.xml
virsh define /tmp/test1.xml
touch /var/lib/libvirt/novell.iso
virt-install --connect qemu:///system --reinstall test --wait -1
--noautoconsole --cdrom /var/lib/libvirt/novell.iso --autostart
** Package changed: apparmor (Ubuntu) => libvirt (Ubuntu)
** Changed in: libvirt (Ubuntu)
Status: New => Triaged
** Changed in: libvirt (Ubuntu)
Assignee: (unassigned) => Martin Pitt (pitti)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1962035
Title:
apparmor blocks VM installation when automatic UEFI firmware is set
Status in libvirt package in Ubuntu:
Triaged
Status in apparmor package in Debian:
New
Bug description:
# lsb_release -rd
Description: Ubuntu 21.10
Release: 21.10
Package: apparmor
Version: 3.0.3-0ubuntu1
Package: virtinst
Version: 1:3.2.0-3
When trying to re-install an existing VM with uefi boot set up using the
recently introduced `--reinstall` option apparmor makes the installation
fail with the following error:
Could not open '/var/lib/libvirt/qemu/nvram/test_VARS.fd': Permission
denied
Steps to reproduce:
Create a VM:
root@ubuntu:~# virt-install --connect qemu:///system --quiet --os-variant
fedora28 --memory 1024 --name test --wait -1 --disk size=1,format=qcow2
--print-xml 1 > /tmp/test1.xml
Edit the VM configuration to enable automatic UEFI boot by changing the
like follows:
-
+
Define the VM:
root@ubuntu:~# virsh define /tmp/test1.xml
Start VM installation:
root@ubuntu:~# virt-install --connect qemu:///system --reinstall test --wait
-1 --noautoconsole --cdrom /var/lib/libvirt/novell.iso --autostart
WARNING No operating system detected, VM performance may suffer. Specify an
OS with --os-variant for optimal results.
Starting install...
ERRORinternal error: process exited while connecting to monitor:
2022-02-23T18:56:54.738510Z qemu-system-x86_64: -blockdev
{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/test_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}:
Could not open '/var/lib/libvirt/qemu/nvram/test_VARS.fd': Permission denied
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
virsh --connect qemu:///system start test
otherwise, please restart your installation.
Expected behavior:
VM installation will start without apparmor error.
Actual behavior:
The above denial happens:
Feb 23 18:56:54 ubuntu audit[4420]: AVC apparmor="DENIED"
operation="open" profile="libvirt-
bdd92fa6-6030-4980-951c-2a52ec7e406c"
name="/var/lib/libvirt/qemu/nvram/test_VARS.fd" pid=4420 comm="qemu-
system-x86" requested_mask="r" denied_m>
and stop the installation.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1962035/+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 1962035] Re: apparmor blocks VM installation when automatic UEFI firmware is set
** Bug watch added: Debian Bug tracker #1006324
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006324
** Also affects: apparmor (Debian) via
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006324
Importance: Unknown
Status: Unknown
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1962035
Title:
apparmor blocks VM installation when automatic UEFI firmware is set
Status in apparmor package in Ubuntu:
New
Status in apparmor package in Debian:
Unknown
Bug description:
# lsb_release -rd
Description: Ubuntu 21.10
Release: 21.10
Package: apparmor
Version: 3.0.3-0ubuntu1
Package: virtinst
Version: 1:3.2.0-3
When trying to re-install an existing VM with uefi boot set up using the
recently introduced `--reinstall` option apparmor makes the installation
fail with the following error:
Could not open '/var/lib/libvirt/qemu/nvram/test_VARS.fd': Permission
denied
Steps to reproduce:
Create a VM:
root@ubuntu:~# virt-install --connect qemu:///system --quiet --os-variant
fedora28 --memory 1024 --name test --wait -1 --disk size=1,format=qcow2
--print-xml 1 > /tmp/test1.xml
Edit the VM configuration to enable automatic UEFI boot by changing the
like follows:
-
+
Define the VM:
root@ubuntu:~# virsh define /tmp/test1.xml
Start VM installation:
root@ubuntu:~# virt-install --connect qemu:///system --reinstall test --wait
-1 --noautoconsole --cdrom /var/lib/libvirt/novell.iso --autostart
WARNING No operating system detected, VM performance may suffer. Specify an
OS with --os-variant for optimal results.
Starting install...
ERRORinternal error: process exited while connecting to monitor:
2022-02-23T18:56:54.738510Z qemu-system-x86_64: -blockdev
{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/test_VARS.fd","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}:
Could not open '/var/lib/libvirt/qemu/nvram/test_VARS.fd': Permission denied
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
virsh --connect qemu:///system start test
otherwise, please restart your installation.
Expected behavior:
VM installation will start without apparmor error.
Actual behavior:
The above denial happens:
Feb 23 18:56:54 ubuntu audit[4420]: AVC apparmor="DENIED"
operation="open" profile="libvirt-
bdd92fa6-6030-4980-951c-2a52ec7e406c"
name="/var/lib/libvirt/qemu/nvram/test_VARS.fd" pid=4420 comm="qemu-
system-x86" requested_mask="r" denied_m>
and stop the installation.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1962035/+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 1945321] Re: umockdev 0.16.3-1 breaks autopkgtest of bolt
> I am in contact with Christian now, and hope to sort this out soon.
Sorry -- I meant Christian Kellner, bolt's upstream, not you :-)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to umockdev in Ubuntu.
https://bugs.launchpad.net/bugs/1945321
Title:
umockdev 0.16.3-1 breaks autopkgtest of bolt
Status in bolt package in Ubuntu:
In Progress
Status in umockdev package in Ubuntu:
Invalid
Status in umockdev package in Debian:
Unknown
Bug description:
The test of bolt fails with the new version due to a crash:
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/b/bolt/20210917_063952_c9336@/log.gz
...
Trace/breakpoint trap (core dumped)
The bolt test really uses umockdev, d/t/control has gir1.2-umockdev-1.0 and
python3-dbusmock and the new version causes this.
Retrying autopkgtest locally with no, all and just umockdev from proposed
and it seems reproducible.
- impish-release - works
- impish-all-proposed - crashes
- impish-release + umockdev+libc6 from proposed - crashes
Repro:
$ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power
FYI:
Downgrading to umockdev 0.16.2-1 in the same environment does not
eliminate the issue. So it might happen at the bolt test-build time.
Debian has the same issue in:
https://ci.debian.net/data/autopkgtest/testing/amd64/b/bolt/15587717/log.gz
The new mockdev fails to create /sys/bus which is requested by the test.
From there the error path is what crashes, but the root cause is why we enter
the error-path in the first place.
One should be aware, this fail is "normal" if the environment is not mocked.
Even in the good case the different calls with/without umockdev lead to
exactly the same crash.
# good
$ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power
# same crash as the new version has with umockdev-wrapper
$ gdb /usr/libexec/installed-tests/bolt/test-power
This is based on ldpreload.
$ cat /usr/bin/umockdev-wrapper
#!/bin/sh
# Wrapper program to preload the libumockdev library, so that test programs
can
# set $UMOCKDEV_DIR for redirecting sysfs and other queries to a test bed.
exec env LD_PRELOAD=libumockdev-preload.so.0:$LD_PRELOAD "$@"
Gut feeling: it seems the mocking no more happens, and due to that
it runs into the non-mocked crash
Debugging with that:
$ pull-lp-source bolt
$ cd bolt-0.9.1/tests
$ gdb /usr/libexec/installed-tests/bolt/test-power
(gdb) set environment LD_PRELOAD libumockdev-preload.so.0
(gdb) b mock_sysfs_init
(gdb) run
With that we can see that while the crash is somewhere inside g_warning the
reason is in the g_mkdir failing with the new umockdev.
Good-case
Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
165 {
(gdb) n
171 ms->bed = umockdev_testbed_new ();
(gdb)
[New Thread 0x76e65640 (LWP 11444)]
# GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used
after threads are created
# DEBUG: umockdev.vala:104: Created udev test bed /tmp/umockdev.RQBNA1
172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
(gdb)
[New Thread 0x76664640 (LWP 11445)]
175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
(gdb)
180 sys = umockdev_testbed_get_sys_dir (ms->bed);
(gdb)
182 bus = g_build_filename (sys, "bus", NULL);
(gdb) p sys
$1 = 0x555b99a0 "/tmp/umockdev.RQBNA1/sys"
(gdb) n
183 r = g_mkdir (bus, 0744);
(gdb) p bus
$2 = 0x555be330 "/tmp/umockdev.RQBNA1/sys/bus"
(gdb) n
185 if (r < 0)
(gdb) p r
$3 = 0
(gdb) n
188 cls = g_build_filename (sys, "class", NULL);
Bad-Case
Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
165 {
(gdb) n
171 ms->bed = umockdev_testbed_new ();
(gdb)
[New Thread 0x76e65640 (LWP 17082)]
# GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used
after threads are created
# DEBUG: umockdev.vala:110: Created udev test bed /tmp/umockdev.TK2VA1
172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
(gdb)
[New Thread 0x76664640 (LWP 17083)]
175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
(gdb)
180 sys = umockdev_testbed_get_sys_dir (ms->bed);
(gdb)
182 bus = g_build_filename (sys, "bus", NULL);
(gdb) p sys
$1 = 0x555a98b0 "/tmp/umockdev.TK2VA1/sys"
(gdb) n
183 r = g_mkdir (bus, 0744);
(gdb) p bus
$2 = 0x555be560 "/tmp/umockdev.TK2VA1/sys/bus"
(gdb) n
185 if (r < 0)
(gdb) p r
$3 = -1
(gdb) n
186 g_warning ("could not create %s", bus);
(gdb) n
** (/usr/libexec/installed-tests/bolt/test-power:17078): WARNING **:
15:11:06.614: could not create /tmp/umockdev.TK2VA1/sys/bus
Thread 1 "test-power" received signal SIGTRAP, Trace/breakpoint trap.
I'
[Touch-packages] [Bug 1945321] Re: umockdev 0.16.3-1 breaks autopkgtest of bolt
Christian, as I write above I believe this really needs to be fixed in
bolt's tests. The umockdev change was a bug fix which bolt's tests
(incorrectly) worked around. So I hope you don't mind that I flipped the
affected package around? I am in contact with Christian now, and hope to
sort this out soon.
** Changed in: bolt (Ubuntu)
Status: Invalid => In Progress
** Changed in: umockdev (Ubuntu)
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to umockdev in Ubuntu.
https://bugs.launchpad.net/bugs/1945321
Title:
umockdev 0.16.3-1 breaks autopkgtest of bolt
Status in bolt package in Ubuntu:
In Progress
Status in umockdev package in Ubuntu:
Invalid
Status in umockdev package in Debian:
Unknown
Bug description:
The test of bolt fails with the new version due to a crash:
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/b/bolt/20210917_063952_c9336@/log.gz
...
Trace/breakpoint trap (core dumped)
The bolt test really uses umockdev, d/t/control has gir1.2-umockdev-1.0 and
python3-dbusmock and the new version causes this.
Retrying autopkgtest locally with no, all and just umockdev from proposed
and it seems reproducible.
- impish-release - works
- impish-all-proposed - crashes
- impish-release + umockdev+libc6 from proposed - crashes
Repro:
$ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power
FYI:
Downgrading to umockdev 0.16.2-1 in the same environment does not
eliminate the issue. So it might happen at the bolt test-build time.
Debian has the same issue in:
https://ci.debian.net/data/autopkgtest/testing/amd64/b/bolt/15587717/log.gz
The new mockdev fails to create /sys/bus which is requested by the test.
From there the error path is what crashes, but the root cause is why we enter
the error-path in the first place.
One should be aware, this fail is "normal" if the environment is not mocked.
Even in the good case the different calls with/without umockdev lead to
exactly the same crash.
# good
$ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power
# same crash as the new version has with umockdev-wrapper
$ gdb /usr/libexec/installed-tests/bolt/test-power
This is based on ldpreload.
$ cat /usr/bin/umockdev-wrapper
#!/bin/sh
# Wrapper program to preload the libumockdev library, so that test programs
can
# set $UMOCKDEV_DIR for redirecting sysfs and other queries to a test bed.
exec env LD_PRELOAD=libumockdev-preload.so.0:$LD_PRELOAD "$@"
Gut feeling: it seems the mocking no more happens, and due to that
it runs into the non-mocked crash
Debugging with that:
$ pull-lp-source bolt
$ cd bolt-0.9.1/tests
$ gdb /usr/libexec/installed-tests/bolt/test-power
(gdb) set environment LD_PRELOAD libumockdev-preload.so.0
(gdb) b mock_sysfs_init
(gdb) run
With that we can see that while the crash is somewhere inside g_warning the
reason is in the g_mkdir failing with the new umockdev.
Good-case
Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
165 {
(gdb) n
171 ms->bed = umockdev_testbed_new ();
(gdb)
[New Thread 0x76e65640 (LWP 11444)]
# GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used
after threads are created
# DEBUG: umockdev.vala:104: Created udev test bed /tmp/umockdev.RQBNA1
172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
(gdb)
[New Thread 0x76664640 (LWP 11445)]
175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
(gdb)
180 sys = umockdev_testbed_get_sys_dir (ms->bed);
(gdb)
182 bus = g_build_filename (sys, "bus", NULL);
(gdb) p sys
$1 = 0x555b99a0 "/tmp/umockdev.RQBNA1/sys"
(gdb) n
183 r = g_mkdir (bus, 0744);
(gdb) p bus
$2 = 0x555be330 "/tmp/umockdev.RQBNA1/sys/bus"
(gdb) n
185 if (r < 0)
(gdb) p r
$3 = 0
(gdb) n
188 cls = g_build_filename (sys, "class", NULL);
Bad-Case
Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
165 {
(gdb) n
171 ms->bed = umockdev_testbed_new ();
(gdb)
[New Thread 0x76e65640 (LWP 17082)]
# GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used
after threads are created
# DEBUG: umockdev.vala:110: Created udev test bed /tmp/umockdev.TK2VA1
172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
(gdb)
[New Thread 0x76664640 (LWP 17083)]
175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
(gdb)
180 sys = umockdev_testbed_get_sys_dir (ms->bed);
(gdb)
182 bus = g_build_filename (sys, "bus", NULL);
(gdb) p sys
$1 = 0x555a98b0 "/tmp/umockdev.TK2VA1/sys"
(gdb) n
183 r = g_mkdir (bus, 0744);
(gdb) p bus
$2 = 0x555be560 "/tmp/umockdev.TK2VA1/sys/bus"
(gdb) n
185 if (r < 0)
[Touch-packages] [Bug 1945321] Re: umockdev 0.16.3-1 breaks autopkgtest of bolt
Thanks Christian -- Indeed I noticed that, and set
https://gitlab.freedesktop.org/bolt/bolt/-/merge_requests/246 the day
after to fix this. Unfortunately I didn't get a reaction yet, and
Christian also didn't respond on IRC yet. I'll do some more prodding.
** Changed in: bolt (Ubuntu)
Status: New => In Progress
** Changed in: bolt (Ubuntu)
Assignee: (unassigned) => Martin Pitt (pitti)
** Changed in: umockdev (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to umockdev in Ubuntu.
https://bugs.launchpad.net/bugs/1945321
Title:
umockdev 0.16.3-1 breaks autopkgtest of bolt
Status in bolt package in Ubuntu:
Invalid
Status in umockdev package in Ubuntu:
In Progress
Bug description:
The test of bolt fails with the new version due to a crash:
https://autopkgtest.ubuntu.com/results/autopkgtest-impish/impish/amd64/b/bolt/20210917_063952_c9336@/log.gz
...
Trace/breakpoint trap (core dumped)
The bolt test really uses umockdev, d/t/control has gir1.2-umockdev-1.0 and
python3-dbusmock and the new version causes this.
Retrying autopkgtest locally with no, all and just umockdev from proposed
and it seems reproducible.
- impish-release - works
- impish-all-proposed - crashes
- impish-release + umockdev+libc6 from proposed - crashes
Repro:
$ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power
FYI:
Downgrading to umockdev 0.16.2-1 in the same environment does not
eliminate the issue. So it might happen at the bolt test-build time.
Debian has the same issue in:
https://ci.debian.net/data/autopkgtest/testing/amd64/b/bolt/15587717/log.gz
The new mockdev fails to create /sys/bus which is requested by the test.
From there the error path is what crashes, but the root cause is why we enter
the error-path in the first place.
One should be aware, this fail is "normal" if the environment is not mocked.
Even in the good case the different calls with/without umockdev lead to
exactly the same crash.
# good
$ umockdev-wrapper /usr/libexec/installed-tests/bolt/test-power
# same crash as the new version has with umockdev-wrapper
$ gdb /usr/libexec/installed-tests/bolt/test-power
This is based on ldpreload.
$ cat /usr/bin/umockdev-wrapper
#!/bin/sh
# Wrapper program to preload the libumockdev library, so that test programs
can
# set $UMOCKDEV_DIR for redirecting sysfs and other queries to a test bed.
exec env LD_PRELOAD=libumockdev-preload.so.0:$LD_PRELOAD "$@"
Gut feeling: it seems the mocking no more happens, and due to that
it runs into the non-mocked crash
Debugging with that:
$ pull-lp-source bolt
$ cd bolt-0.9.1/tests
$ gdb /usr/libexec/installed-tests/bolt/test-power
(gdb) set environment LD_PRELOAD libumockdev-preload.so.0
(gdb) b mock_sysfs_init
(gdb) run
With that we can see that while the crash is somewhere inside g_warning the
reason is in the g_mkdir failing with the new umockdev.
Good-case
Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
165 {
(gdb) n
171 ms->bed = umockdev_testbed_new ();
(gdb)
[New Thread 0x76e65640 (LWP 11444)]
# GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used
after threads are created
# DEBUG: umockdev.vala:104: Created udev test bed /tmp/umockdev.RQBNA1
172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
(gdb)
[New Thread 0x76664640 (LWP 11445)]
175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
(gdb)
180 sys = umockdev_testbed_get_sys_dir (ms->bed);
(gdb)
182 bus = g_build_filename (sys, "bus", NULL);
(gdb) p sys
$1 = 0x555b99a0 "/tmp/umockdev.RQBNA1/sys"
(gdb) n
183 r = g_mkdir (bus, 0744);
(gdb) p bus
$2 = 0x555be330 "/tmp/umockdev.RQBNA1/sys/bus"
(gdb) n
185 if (r < 0)
(gdb) p r
$3 = 0
(gdb) n
188 cls = g_build_filename (sys, "class", NULL);
Bad-Case
Breakpoint 1, mock_sysfs_init (ms=0x555b6400) at ../tests/mock-sysfs.c:165
165 {
(gdb) n
171 ms->bed = umockdev_testbed_new ();
(gdb)
[New Thread 0x76e65640 (LWP 17082)]
# GLib-DEBUG: setenv()/putenv() are not thread-safe and should not be used
after threads are created
# DEBUG: umockdev.vala:110: Created udev test bed /tmp/umockdev.TK2VA1
172 ms->domains = g_hash_table_new_full (g_str_hash, g_str_equal,
(gdb)
[New Thread 0x76664640 (LWP 17083)]
175 ms->devices = g_hash_table_new (g_str_hash, g_str_equal);
(gdb)
180 sys = umockdev_testbed_get_sys_dir (ms->bed);
(gdb)
182 bus = g_build_filename (sys, "bus", NULL);
(gdb) p sys
$1 = 0x555a98b0 "/tmp/umockdev.TK2VA1/sys"
(gdb) n
183 r = g_mkdir (
[Touch-packages] [Bug 1934995] Re: Broken on ppc64el (toolchain bug?)
Indeed the open(2) manpage is misleading in that regard. The actual definition in fcntl.h is like this: extern int open (const char *__file, int __oflag, ...) __nonnull ((1)); (with a few variants, but they all use varargs). So I did the same in umockdev for full header compatibility. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to umockdev in Ubuntu. https://bugs.launchpad.net/bugs/1934995 Title: Broken on ppc64el (toolchain bug?) Status in umockdev package in Ubuntu: New Bug description: umockdev appears to be broken on ppc64el in impish. Running it on one of Mir's umockdev-using tests results in: (impish-ppc64el)root@juju-deb017-porterbox-1:/build/mir-Xn1VqE/umockdev# umockdev-run ../mir-2.4.1/build-ppc64el/bin/mir_umock_unit_tests MIR_CLIENT_PLATFORM_PATH=../mir-2.4.1/build-ppc64el/bin/../lib/client-modules/ MIR_SERVER_PLATFORM_PATH=../mir-2.4.1/build-ppc64el/bin/../lib/server-modules/ LD_LIBRARY_PATH=../mir-2.4.1/build-ppc64el/bin/../lib exec=../mir-2.4.1/build-ppc64el/bin/mir_umock_unit_tests.bin *** stack smashing detected ***: terminated umockdev-run: unable to propagate signal 6 to child 15833: No such process (You can also see this in the Mir 2.4.1-0ubuntu1 build log: https://launchpadlibrarian.net/546972958/buildlog_ubuntu-impish- ppc64el.mir_2.4.1-0ubuntu1_BUILDING.txt.gz ) Installing umockdev 0.15.4-1 and libumockdev0 0.15.4-1 from hirsute results in those tests passing. Strangely, rebuilding umockdev 0.15.4-1 in a hirsute sbuild environment results in packages that do *not* pass those tests, suggesting a toolchain change might be responsible. Unfortunately, I've tried rebuilding umockdev with gcc-9, gcc-11, and vala 0.48.12-1 in Impish and none of these appear to work. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: umockdev 0.16.1-1 ProcVersionSignature: Ubuntu 5.11.0-20.21+21.10.1-generic 5.11.21 Uname: Linux 5.11.0-20-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu67 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu Jul 8 16:04:15 2021 InstallationDate: Installed on 2021-06-26 (11 days ago) InstallationMedia: Ubuntu 21.10.0 2021.05.28 amd64 "bcachefs" (20210622) SourcePackage: umockdev UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/umockdev/+bug/1934995/+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 1934995] Re: Broken on ppc64el (toolchain bug?)
Dang, we already found a ppc64el SIGBUS issue in 0.16.0, which got fixed in https://github.com/martinpitt/umockdev/commit/277c80243a . But this is reported against 0.16.1 already. There is a tiny chance that https://github.com/martinpitt/umockdev/commit/264cabbb will magically fix this, but otherwise this needs some investigation. I.e. not known upstream yet. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to umockdev in Ubuntu. https://bugs.launchpad.net/bugs/1934995 Title: Broken on ppc64el (toolchain bug?) Status in umockdev package in Ubuntu: New Bug description: umockdev appears to be broken on ppc64el in impish. Running it on one of Mir's umockdev-using tests results in: (impish-ppc64el)root@juju-deb017-porterbox-1:/build/mir-Xn1VqE/umockdev# umockdev-run ../mir-2.4.1/build-ppc64el/bin/mir_umock_unit_tests MIR_CLIENT_PLATFORM_PATH=../mir-2.4.1/build-ppc64el/bin/../lib/client-modules/ MIR_SERVER_PLATFORM_PATH=../mir-2.4.1/build-ppc64el/bin/../lib/server-modules/ LD_LIBRARY_PATH=../mir-2.4.1/build-ppc64el/bin/../lib exec=../mir-2.4.1/build-ppc64el/bin/mir_umock_unit_tests.bin *** stack smashing detected ***: terminated umockdev-run: unable to propagate signal 6 to child 15833: No such process (You can also see this in the Mir 2.4.1-0ubuntu1 build log: https://launchpadlibrarian.net/546972958/buildlog_ubuntu-impish- ppc64el.mir_2.4.1-0ubuntu1_BUILDING.txt.gz ) Installing umockdev 0.15.4-1 and libumockdev0 0.15.4-1 from hirsute results in those tests passing. Strangely, rebuilding umockdev 0.15.4-1 in a hirsute sbuild environment results in packages that do *not* pass those tests, suggesting a toolchain change might be responsible. Unfortunately, I've tried rebuilding umockdev with gcc-9, gcc-11, and vala 0.48.12-1 in Impish and none of these appear to work. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: umockdev 0.16.1-1 ProcVersionSignature: Ubuntu 5.11.0-20.21+21.10.1-generic 5.11.21 Uname: Linux 5.11.0-20-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu67 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu Jul 8 16:04:15 2021 InstallationDate: Installed on 2021-06-26 (11 days ago) InstallationMedia: Ubuntu 21.10.0 2021.05.28 amd64 "bcachefs" (20210622) SourcePackage: umockdev UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/umockdev/+bug/1934995/+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 1916485] Re: test -x fails inside shell scripts in containers
I've been scratching my head over this regression [1] for a while now, in the context of running a hirsute container on a 20.04 host (in particular, a GitHub workflow machine) In my case, the symptom is that after upgrading glibc, `which` is broken; that of course also uses faccessat(), similar to test -x. I tried all sorts of the "usual" workarounds, as seccomp has been giving trouble for a while now [2]. But this failure is robust against fuse- overlayfs vs. vfs (inefficient full copies of the file system), root vs. user podman, podman vs. docker, and, relevant for this bug, it *also happens* with --security-opt=seccomp=unconfined and/org --privileged, both of which should disable seccomp. Hence I believe this bug can't at least only be in libseccomp. [1] https://github.com/martinpitt/umockdev/runs/1984769591?check_suite_focus=true#step:3:1019 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1900021 ** Bug watch added: Red Hat Bugzilla #1900021 https://bugzilla.redhat.com/show_bug.cgi?id=1900021 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1916485 Title: test -x fails inside shell scripts in containers Status in glibc package in Ubuntu: Triaged Status in libseccomp package in Ubuntu: Fix Committed Status in glibc source package in Hirsute: Triaged Status in libseccomp source package in Hirsute: Fix Committed Bug description: glibc regression causes test -x to fail inside scripts inside docker/podman, dash and bash are broken, mksh and zsh are fine: root@0df2ce5d7a46:/# test -x /usr/bin/gpg || echo Fail root@0df2ce5d7a46:/# dash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "test -x /usr/bin/gpg || echo Fail" Fail root@0df2ce5d7a46:/# mksh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# zsh -c "test -x /usr/bin/gpg || echo Fail" root@0df2ce5d7a46:/# root@0df2ce5d7a46:/# zsh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# mksh -c "[ -x /usr/bin/gpg ] || echo Fail" root@0df2ce5d7a46:/# dash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail root@0df2ce5d7a46:/# bash -c "[ -x /usr/bin/gpg ] || echo Fail" Fail The -f flag works, as does /usr/bin/test: # bash -c "test -f /usr/bin/gpg || echo Fail" # bash -c "/usr/bin/test -x /usr/bin/gpg || echo Fail" # [Original bug report] root@84b750e443f8:/# lsb_release -rd Description: Ubuntu Hirsute Hippo (development branch) Release: 21.04 root@84b750e443f8:/# dpkg -l gnupg apt Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==-===--== ii apt2.1.20 amd64commandline package manager ii gnupg 2.2.20-1ubuntu2 all GNU privacy guard - a free PGP replacement Hi, for 3 days our CI pipelines to recreate Docker images fails for the Hirsute images. From comparison this seems to be caused by apt 2.1.20. The build fails with: 0E: gnupg, gnupg2 and unupg1 do not seem to be installed, but one of them is required for this operation The simple Dockerfile to reproduce the error - "docker build -t foo ." FROM amd64/ubuntu:hirsute MAINTAINER Florian Lohoff USER root RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get -y install curl gnupg apt \ && curl https://syncthing.net/release-key.txt | apt-key add - Breaking it down it this seems to be an issue that there is new functionality in apt/apt-key e.g. security hardening that docker prohibits in its containers. Running this manually works only in an --privileged container. So adding keys in unpriviledged container or possibly kubernetes will not work anymore. Flo To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1916485/+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 1831467] Re: test-umockdev tests flaky on armhf (and sometimes other archs)
https://salsa.debian.org/debian/umockdev/-/commit/87b476aee2 should hopefully help. I uploaded 0.14.2 to Debian unstable now, it should auto-sync into Groovy soon. Thanks Dan for tackling this! ** Changed in: umockdev (Ubuntu Groovy) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to umockdev in Ubuntu. https://bugs.launchpad.net/bugs/1831467 Title: test-umockdev tests flaky on armhf (and sometimes other archs) Status in umockdev package in Ubuntu: Fix Committed Status in umockdev source package in Xenial: In Progress Status in umockdev source package in Bionic: In Progress Status in umockdev source package in Focal: In Progress Status in umockdev source package in Groovy: Fix Committed Bug description: [impact] these tests fail intermittently, due to various timing issues, as well as an actual code bug in how data fuzz is calculated. it looks like the failures are mostly on armhf, but do happen less often on other archs. [test case] check the previous autopkgtest logs, e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/armhf/u/umockdev/20190601_015323_8f795@/log.gz [regression potential] any regression would likely result in incorrectly failing/passing autopkgtests, or in a incorrect pass or incorrect fail of the ScriptRunner to verify the data's level of fuzz. [scope] as the tests are flaky on armhf all the way back to trusty, this is needed for all releases. [other info] Fixed upstream in PR https://github.com/martinpitt/umockdev/pull/103 Most of the changes are test case fixes, but there is one fix to source code to fix the ScriptRunning function that validates the level of fuzz in data, so this is not *only* a testcase fix. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/umockdev/+bug/1831467/+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 1837233] Re: [bionic] Manual IPv6 routes are not set
Nevermind then, this is working well enough for a stable release.
** Changed in: network-manager (Ubuntu Bionic)
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1837233
Title:
[bionic] Manual IPv6 routes are not set
Status in network-manager package in Ubuntu:
Fix Released
Status in network-manager source package in Bionic:
Won't Fix
Bug description:
I have a system connection like this:
-- /etc/NetworkManager/system-connections/eth2 ---
[connection]
id=eth2
uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
type=ethernet
gateway-ping-timeout=12
interface-name=eth2
permissions=
timestamp=1563551266
[ethernet]
mac-address-blacklist=
[ipv4]
dns-search=
method=shared
[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ignore-auto-routes=true
method=auto
route1=1:2::/60,1:2::3,42
-- 8< -
In particular, the last line (route1=) which sets a manual IPv6 route.
Of course this is rather bogus, I'm just using this to test cockpit's
web UI.
On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:
# nmcli c show eth2
ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42
}
IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 101
IP6.ROUTE[2]: dst = ff00::/8, nh = ::, mt = 256,
table=255
IP6.ROUTE[3]: dst = 1:2::3/128, nh = ::, mt = 42
IP6.ROUTE[4]: dst = 1:2::/60, nh = 1:2::3, mt = 42
[...]
# ip -6 route show dev eth2
1:2::3 proto static metric 42 pref medium
1:2::/60 via 1:2::3 proto static metric 42 pref medium
fe80::/64 proto kernel metric 101 pref medium
(There, the file is called eth2.nmconnection, but same difference)
On Ubuntu 18.04 however, the route manual is ignored, and only the
automatic link-local one exists:
# nmcli c show eth2
ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42
}
IP6.ROUTE[1]: dst = ff00::/8, nh = ::, mt = 256,
table=255
IP6.ROUTE[2]: dst = fe80::/64, nh = ::, mt = 256
IP6.ROUTE[3]: dst = fe80::/64, nh = ::, mt = 101
# ip -6 route show dev eth2
fe80::/64 proto kernel metric 101 pref medium
fe80::/64 proto kernel metric 256 pref medium
Restarting NetworkManager does not help, nor does rebooting.
DistroRelease: Ubuntu 18.04
Package: 1.10.6-2ubuntu1.1
Architecture: amd64
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1837233/+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 1837233] Re: [bionic] Manual IPv6 routes are not set
I confirm that using a valid IP works better:
In the config:
route1=fe80:2::/60,fe80::99,42
# ip -6 route show dev eth2
fe80::/64 proto kernel metric 101 pref medium
fe80::/64 proto kernel metric 256 pref medium
fe80:2::/60 via fe80::99 proto static metric 42 pref medium
It's still missing the route to fe80:2:: itself, though.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1837233
Title:
[bionic] Manual IPv6 routes are not set
Status in network-manager package in Ubuntu:
Fix Released
Status in network-manager source package in Bionic:
Won't Fix
Bug description:
I have a system connection like this:
-- /etc/NetworkManager/system-connections/eth2 ---
[connection]
id=eth2
uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
type=ethernet
gateway-ping-timeout=12
interface-name=eth2
permissions=
timestamp=1563551266
[ethernet]
mac-address-blacklist=
[ipv4]
dns-search=
method=shared
[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ignore-auto-routes=true
method=auto
route1=1:2::/60,1:2::3,42
-- 8< -
In particular, the last line (route1=) which sets a manual IPv6 route.
Of course this is rather bogus, I'm just using this to test cockpit's
web UI.
On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:
# nmcli c show eth2
ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42
}
IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 101
IP6.ROUTE[2]: dst = ff00::/8, nh = ::, mt = 256,
table=255
IP6.ROUTE[3]: dst = 1:2::3/128, nh = ::, mt = 42
IP6.ROUTE[4]: dst = 1:2::/60, nh = 1:2::3, mt = 42
[...]
# ip -6 route show dev eth2
1:2::3 proto static metric 42 pref medium
1:2::/60 via 1:2::3 proto static metric 42 pref medium
fe80::/64 proto kernel metric 101 pref medium
(There, the file is called eth2.nmconnection, but same difference)
On Ubuntu 18.04 however, the route manual is ignored, and only the
automatic link-local one exists:
# nmcli c show eth2
ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42
}
IP6.ROUTE[1]: dst = ff00::/8, nh = ::, mt = 256,
table=255
IP6.ROUTE[2]: dst = fe80::/64, nh = ::, mt = 256
IP6.ROUTE[3]: dst = fe80::/64, nh = ::, mt = 101
# ip -6 route show dev eth2
fe80::/64 proto kernel metric 101 pref medium
fe80::/64 proto kernel metric 256 pref medium
Restarting NetworkManager does not help, nor does rebooting.
DistroRelease: Ubuntu 18.04
Package: 1.10.6-2ubuntu1.1
Architecture: amd64
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1837233/+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 1837233] Re: [bionic] Manual IPv6 routes are not set
The journal says why:
NetworkManager[1295]: [1563552648.1667] platform: route-sync: failure
to add IPv6 route: 1:2::/60 via 1:2::3 dev 6 metric 42 mss 0 rt-src user: No
route to host (113)
NetworkManager[1295]: [1563552648.1672] device (eth2): failed to apply
manual IPv6 configuration
Apparently later versions ignore non-reachable hosts and set the route
anyway?
** Description changed:
I have a system connection like this:
-- /etc/NetworkManager/system-connections/eth2 ---
[connection]
id=eth2
uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
type=ethernet
gateway-ping-timeout=12
interface-name=eth2
permissions=
timestamp=1563551266
[ethernet]
mac-address-blacklist=
[ipv4]
dns-search=
method=shared
[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ignore-auto-routes=true
method=auto
route1=1:2::/60,1:2::3,42
-- 8< -
In particular, the last line (route1=) which sets a manual IPv6 route.
Of course this is rather bogus, I'm just using this to test cockpit's
web UI.
On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:
# nmcli c show eth2
ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42
}
IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 101
IP6.ROUTE[2]: dst = ff00::/8, nh = ::, mt = 256,
table=255
IP6.ROUTE[3]: dst = 1:2::3/128, nh = ::, mt = 42
IP6.ROUTE[4]: dst = 1:2::/60, nh = 1:2::3, mt = 42
[...]
# ip -6 route show dev eth2
1:2::3 proto static metric 42 pref medium
1:2::/60 via 1:2::3 proto static metric 42 pref medium
fe80::/64 proto kernel metric 101 pref medium
(There, the file is called eth2.nmconnection, but same difference)
On Ubuntu 18.04 however, the route manual is ignored, and only the
automatic link-local one exists:
# nmcli c show eth2
ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42
}
IP6.ROUTE[1]: dst = ff00::/8, nh = ::, mt = 256,
table=255
IP6.ROUTE[2]: dst = fe80::/64, nh = ::, mt = 256
IP6.ROUTE[3]: dst = fe80::/64, nh = ::, mt = 101
# ip -6 route show dev eth2
fe80::/64 proto kernel metric 101 pref medium
fe80::/64 proto kernel metric 256 pref medium
Restarting NetworkManager does not help, nor does rebooting.
+
+ DistroRelease: Ubuntu 18.04
+ Package: 1.10.6-2ubuntu1.1
+ Architecture: amd64
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1837233
Title:
[bionic] Manual IPv6 routes are not set
Status in network-manager package in Ubuntu:
Fix Released
Status in network-manager source package in Bionic:
Won't Fix
Bug description:
I have a system connection like this:
-- /etc/NetworkManager/system-connections/eth2 ---
[connection]
id=eth2
uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
type=ethernet
gateway-ping-timeout=12
interface-name=eth2
permissions=
timestamp=1563551266
[ethernet]
mac-address-blacklist=
[ipv4]
dns-search=
method=shared
[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ignore-auto-routes=true
method=auto
route1=1:2::/60,1:2::3,42
-- 8< -
In particular, the last line (route1=) which sets a manual IPv6 route.
Of course this is rather bogus, I'm just using this to test cockpit's
web UI.
On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:
# nmcli c show eth2
ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42
}
IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 101
IP6.ROUTE[2]: dst = ff00::/8, nh = ::, mt = 256,
table=255
IP6.ROUTE[3]: dst = 1:2::3/128, nh = ::, mt = 42
IP6.ROUTE[4]: dst = 1:2::/60, nh = 1:2::3, mt = 42
[...]
# ip -6 route show dev eth2
1:2::3 proto static metric 42 pref medium
1:2::/60 via 1:2::3 proto static metric 42 pref medium
fe80::/64 proto kernel metric 101 pref medium
(There, the file is called eth2.nmconnection, but same difference)
On Ubuntu 18.04 however, the route manual is ignored, and only the
automatic link-local one exists:
# nmcli c show eth2
ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42
}
IP6.ROUTE[1]: dst = ff00::/8, nh = ::, mt = 256,
table=255
IP6.ROUTE[2]: dst = fe80::/64, nh = ::, mt = 256
IP6.ROUTE[3]: dst = fe80::/64, nh = ::, mt = 101
# ip -6 route show dev eth2
fe80::/64 proto kernel metric 101 pref medium
fe80::/64 proto kernel metric 256 pref medium
[Touch-packages] [Bug 1837233] [NEW] [bionic] Manual IPv6 routes are not set
Public bug reported:
I have a system connection like this:
-- /etc/NetworkManager/system-connections/eth2 ---
[connection]
id=eth2
uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
type=ethernet
gateway-ping-timeout=12
interface-name=eth2
permissions=
timestamp=1563551266
[ethernet]
mac-address-blacklist=
[ipv4]
dns-search=
method=shared
[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ignore-auto-routes=true
method=auto
route1=1:2::/60,1:2::3,42
-- 8< -
In particular, the last line (route1=) which sets a manual IPv6 route.
Of course this is rather bogus, I'm just using this to test cockpit's
web UI.
On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:
# nmcli c show eth2
ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 }
IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 101
IP6.ROUTE[2]: dst = ff00::/8, nh = ::, mt = 256,
table=255
IP6.ROUTE[3]: dst = 1:2::3/128, nh = ::, mt = 42
IP6.ROUTE[4]: dst = 1:2::/60, nh = 1:2::3, mt = 42
[...]
# ip -6 route show dev eth2
1:2::3 proto static metric 42 pref medium
1:2::/60 via 1:2::3 proto static metric 42 pref medium
fe80::/64 proto kernel metric 101 pref medium
(There, the file is called eth2.nmconnection, but same difference)
On Ubuntu 18.04 however, the route manual is ignored, and only the
automatic link-local one exists:
# nmcli c show eth2
ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42 }
IP6.ROUTE[1]: dst = ff00::/8, nh = ::, mt = 256,
table=255
IP6.ROUTE[2]: dst = fe80::/64, nh = ::, mt = 256
IP6.ROUTE[3]: dst = fe80::/64, nh = ::, mt = 101
# ip -6 route show dev eth2
fe80::/64 proto kernel metric 101 pref medium
fe80::/64 proto kernel metric 256 pref medium
Restarting NetworkManager does not help, nor does rebooting.
DistroRelease: Ubuntu 18.04
Package: 1.10.6-2ubuntu1.1
Architecture: amd64
** Affects: network-manager (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: network-manager (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: network-manager (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: network-manager (Ubuntu)
Status: New => Fix Released
** Description changed:
I have a system connection like this:
-- /etc/NetworkManager/system-connections/eth2 ---
[connection]
id=eth2
uuid=c73fb4d2-8383-4d03-a87c-04c8251961bd
type=ethernet
gateway-ping-timeout=12
interface-name=eth2
permissions=
timestamp=1563551266
[ethernet]
mac-address-blacklist=
[ipv4]
dns-search=
method=shared
[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ignore-auto-routes=true
method=auto
route1=1:2::/60,1:2::3,42
-- 8< -
In particular, the last line (route1=) which sets a manual IPv6 route.
Of course this is rather bogus, I'm just using this to test cockpit's
web UI.
On Ubuntu 19.04, Debian 10, and Debian testing this works just fine:
# nmcli c show eth2
ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42
}
IP6.ROUTE[1]: dst = fe80::/64, nh = ::, mt = 101
IP6.ROUTE[2]: dst = ff00::/8, nh = ::, mt = 256,
table=255
IP6.ROUTE[3]: dst = 1:2::3/128, nh = ::, mt = 42
IP6.ROUTE[4]: dst = 1:2::/60, nh = 1:2::3, mt = 42
[...]
- ip -6 route show dev eth2
+ # ip -6 route show dev eth2
1:2::3 proto static metric 42 pref medium
1:2::/60 via 1:2::3 proto static metric 42 pref medium
fe80::/64 proto kernel metric 101 pref medium
(There, the file is called eth2.nmconnection, but same difference)
On Ubuntu 18.04 however, the route manual is ignored, and only the
automatic link-local one exists:
# nmcli c show eth2
ipv6.routes:{ ip = 1:2::/60, nh = 1:2::3, mt = 42
}
IP6.ROUTE[1]: dst = ff00::/8, nh = ::, mt = 256,
table=255
IP6.ROUTE[2]: dst = fe80::/64, nh = ::, mt = 256
IP6.ROUTE[3]: dst = fe80::/64, nh = ::, mt = 101
# ip -6 route show dev eth2
fe80::/64 proto kernel metric 101 pref medium
fe80::/64 proto kernel metric 256 pref medium
Restarting NetworkManager does not help, nor does rebooting.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1837233
Title:
[bionic] Manual IPv6 routes are not set
Status in network-manager package in Ubuntu:
Fix Released
Status in network-manager source package in Bionic:
New
Bug description:
I have a syst
[Touch-packages] [Bug 1831296] Re: __main__.SeccompTest is failing on Ubuntu CI
Thanks Dan! I landed your PR, so it should apply to the next upstream CI run. ** Changed in: systemd (Ubuntu Eoan) Status: In Progress => Fix Committed -- 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/1831296 Title: __main__.SeccompTest is failing on Ubuntu CI Status in systemd package in Ubuntu: Fix Committed Status in systemd source package in Eoan: Fix Committed Bug description: Since https://github.com/systemd/systemd/pull/12430 was merged and libsecomp was updated the test has been failing on Ubuntu CI: https://github.com/systemd/systemd/issues/12709. By analogy with https://github.com/systemd/systemd/pull/12430/commits/c3ab2c389ee60d92fb8d7fe779ae9c4e3c092e4c, the test should look for either "killed" or "dumped". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1831296/+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 1829829] Re: Ubuntu CI has been flaky for a week
Indeed the downstream tests fail like this as well:
http://autopkgtest.ubuntu.com/packages/systemd/eoan/amd64
--
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/1829829
Title:
Ubuntu CI has been flaky for a week
Status in systemd package in Ubuntu:
New
Bug description:
It was originally reported in
https://github.com/systemd/systemd/pull/12583#issuecomment-492949206 5 days
ago. To judge from the logs VMs can't be rebooted there:
```
Ubuntu 18.04.2 LTS autopkgtest ttyS0
autopkgtest login:
---
--- nova show 91e76a78-d05c-412a-b383-55a26010ae69
(adt-bionic-amd64-systemd-upstream-20190516-051604) --
+--++
| Property | Value
|
+--++
| OS-DCF:diskConfig| MANUAL
|
| OS-EXT-AZ:availability_zone | nova
|
| OS-EXT-SRV-ATTR:host | euler
|
| OS-EXT-SRV-ATTR:hypervisor_hostname | euler.lcy01.scalingstack
|
| OS-EXT-SRV-ATTR:instance_name| instance-003d216a
|
| OS-EXT-STS:power_state | 1
|
| OS-EXT-STS:task_state| -
|
| OS-EXT-STS:vm_state | active
|
| OS-SRV-USG:launched_at | 2019-05-16T07:00:42.00
|
| OS-SRV-USG:terminated_at | -
|
| accessIPv4 |
|
| accessIPv6 |
|
| config_drive |
|
| created | 2019-05-16T07:00:33Z
|
| flavor | autopkgtest
(f878e70e-9991-46e0-ba02-8ea159a71656) |
| hostId |
1722c5f2face86c3fc9f338ae96835924721512372342f664e6941bd
|
| id | 91e76a78-d05c-412a-b383-55a26010ae69
|
| image|
adt/ubuntu-bionic-amd64-server-20190516.img
(d00bf12c-467e-433f-a4f5-15720f13bff1) |
| key_name |
testbed-juju-prod-ues-proposed-migration-machine-11
|
| metadata | {}
|
| name |
adt-bionic-amd64-systemd-upstream-20190516-051604
|
| net_ues_proposed_migration network | 10.42.40.13
|
| os-extended-volumes:volumes_attached | []
|
| progress | 0
|
| security_groups | autopkgtest@lcy01-27.secgroup
|
| status | ACTIVE
|
| tenant_id| afaef86b96dd4828a1ed5ee395ea1421
|
| updated | 2019-05-16T07:00:42Z
|
| user_id | 8524250971084851b3792a68fbc398dd
|
+--+-
[Touch-packages] [Bug 1819589] Re: Ubuntu CI is broken
That worked. ** Changed in: systemd (Ubuntu) Status: Fix Committed => Fix Released -- 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/1819589 Title: Ubuntu CI is broken Status in systemd package in Ubuntu: Fix Released Bug description: Since https://salsa.debian.org/systemd-team/systemd/commit/8d810fda9a640a932d6e7b32afd958fe75e36f5b was merged Ubuntu CI has been failing with ``` Investigating (0) udev:amd64 < 237-3ubuntu10.13 -> 241-608-gfd541a5f08-0 @ii pumU Ib > Broken udev:amd64 Depends on dpkg:amd64 < 1.19.0.5ubuntu2.1 @ii mK > (>= 1.19.3) Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: udev : Depends: dpkg (>= 1.19.3) but 1.19.0.5ubuntu2.1 is to be installed W: --force-yes is deprecated, use one of the options starting with --allow instead. E: Unable to correct problems, you have held broken packages. blame: https://salsa.debian.org/systemd-team/systemd.git badpkg: installation of basic binaries failed, exit code 100 autopkgtest [18:37:50]: ERROR: erroneous package: installation of basic binaries failed, exit code 100 Exit request sent.^M Creating nova instance adt-bionic-amd64-systemd-upstream-20190311-180219 from image adt/ubuntu-bionic-amd64-server-20190311.img (UUID 2bf5f055-214b-4fcf-aadc-dd60a3a1a9d1)... Creating nova instance adt-bionic-amd64-systemd-upstream-20190311-180219 from image adt/ubuntu-bionic-amd64-server-20190311.img (UUID 2bf5f055-214b-4fcf-aadc-dd60a3a1a9d1)... ``` It's also being discussed in https://github.com/systemd/systemd/pull/11963. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819589/+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 1819589] Re: Ubuntu CI is broken
Should be fixed with https://salsa.debian.org/systemd- team/systemd/commit/bd89a706b18796074d50bcf2a0cbd29de56ac542 . I'll close this once the retried PRs go green. ** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Martin Pitt (pitti) ** Changed in: systemd (Ubuntu) Status: New => Fix Committed ** Changed in: systemd (Ubuntu) Importance: Undecided => High -- 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/1819589 Title: Ubuntu CI is broken Status in systemd package in Ubuntu: Fix Committed Bug description: Since https://salsa.debian.org/systemd-team/systemd/commit/8d810fda9a640a932d6e7b32afd958fe75e36f5b was merged Ubuntu CI has been failing with ``` Investigating (0) udev:amd64 < 237-3ubuntu10.13 -> 241-608-gfd541a5f08-0 @ii pumU Ib > Broken udev:amd64 Depends on dpkg:amd64 < 1.19.0.5ubuntu2.1 @ii mK > (>= 1.19.3) Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: udev : Depends: dpkg (>= 1.19.3) but 1.19.0.5ubuntu2.1 is to be installed W: --force-yes is deprecated, use one of the options starting with --allow instead. E: Unable to correct problems, you have held broken packages. blame: https://salsa.debian.org/systemd-team/systemd.git badpkg: installation of basic binaries failed, exit code 100 autopkgtest [18:37:50]: ERROR: erroneous package: installation of basic binaries failed, exit code 100 Exit request sent.^M Creating nova instance adt-bionic-amd64-systemd-upstream-20190311-180219 from image adt/ubuntu-bionic-amd64-server-20190311.img (UUID 2bf5f055-214b-4fcf-aadc-dd60a3a1a9d1)... Creating nova instance adt-bionic-amd64-systemd-upstream-20190311-180219 from image adt/ubuntu-bionic-amd64-server-20190311.img (UUID 2bf5f055-214b-4fcf-aadc-dd60a3a1a9d1)... ``` It's also being discussed in https://github.com/systemd/systemd/pull/11963. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1819589/+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 1817344] Re: Ubuntu CI that runs tests via autopkgtest for systemd on GitHub reports the wrong results
Thanks Iain! I'll keep an eye on this. -- 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/1817344 Title: Ubuntu CI that runs tests via autopkgtest for systemd on GitHub reports the wrong results Status in Auto Package Testing: Fix Released Status in systemd package in Ubuntu: New Bug description: I'm not sure this is the right place to report this, but apparently it's the best way to reach out to Dimitri John Ledkov (https://github.com/xnox) and Iain Lane (https://github.com/iainlane), who I believe at least know who maintains Ubuntu CI there. I'm copying the following verbatim from https://github.com/systemd/systemd/pull/11531#issuecomment-464731263 (where we are kind of discussing the issue): > The two PRs you referenced to fail in the `make check` unit tests (test-path). That's correct that test-path failed but it failed in https://github.com/systemd/systemd/pull/11685 while Ubuntu CI reported it in https://github.com/systemd/systemd/pull/11686 (that is, in https://github.com/systemd/systemd/pull/11686 in the logs for some reason UPSTREAM_PULL_REQUEST is 11685 instead of 11686 and something like that has happened often lately). In https://github.com/systemd/systemd/pull/11743#issuecomment-464637797, the issue is that Ubuntu CI showed the results for the first version of the PR (where there was a bug) and it didn't run the tests against the latest version. But in that case it's hard to tell because there is no way to figure out what exactly Ubuntu CI tested. That's why I asked @xnox to add `git describe` to https://salsa.debian.org/systemd- team/systemd/blob/master/debian/extra/checkout-upstream so that by looking at UPSTREAM_PULL_REQUEST and the output of `git describe` it would be possible to find out what Ubuntu CI reports. To manage notifications about this bug go to: https://bugs.launchpad.net/auto-package-testing/+bug/1817344/+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 1817344] Re: Ubuntu CI that runs tests via autopkgtest for systemd on GitHub reports the wrong results
Another example: https://github.com/systemd/systemd/pull/11802 refers to the correct amd64 log https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-bionic-upstream-systemd-ci-systemd-ci/bionic/amd64/s /systemd-upstream/20190222_161608_7fe1f@/log.gz . But https://github.com/systemd/systemd/pull/11804 refers to the exact same log. It is also the only result for 11804: https://api.github.com/repos/systemd/systemd/statuses/b427959d65ba0edff385146d38825bb169458554 -- 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/1817344 Title: Ubuntu CI that runs tests via autopkgtest for systemd on GitHub reports the wrong results Status in autopkgtest-cloud: New Status in systemd package in Ubuntu: New Bug description: I'm not sure this is the right place to report this, but apparently it's the best way to reach out to Dimitri John Ledkov (https://github.com/xnox) and Iain Lane (https://github.com/iainlane), who I believe at least know who maintains Ubuntu CI there. I'm copying the following verbatim from https://github.com/systemd/systemd/pull/11531#issuecomment-464731263 (where we are kind of discussing the issue): > The two PRs you referenced to fail in the `make check` unit tests (test-path). That's correct that test-path failed but it failed in https://github.com/systemd/systemd/pull/11685 while Ubuntu CI reported it in https://github.com/systemd/systemd/pull/11686 (that is, in https://github.com/systemd/systemd/pull/11686 in the logs for some reason UPSTREAM_PULL_REQUEST is 11685 instead of 11686 and something like that has happened often lately). In https://github.com/systemd/systemd/pull/11743#issuecomment-464637797, the issue is that Ubuntu CI showed the results for the first version of the PR (where there was a bug) and it didn't run the tests against the latest version. But in that case it's hard to tell because there is no way to figure out what exactly Ubuntu CI tested. That's why I asked @xnox to add `git describe` to https://salsa.debian.org/systemd- team/systemd/blob/master/debian/extra/checkout-upstream so that by looking at UPSTREAM_PULL_REQUEST and the output of `git describe` it would be possible to find out what Ubuntu CI reports. To manage notifications about this bug go to: https://bugs.launchpad.net/autopkgtest-cloud/+bug/1817344/+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 1817344] Re: Ubuntu CI that runs tests via autopkgtest for systemd on GitHub reports the wrong results
It seems to me that the logs are internally consistent, i. e. the mentioned UPSTREAM_PULL_REQUEST in the log does match the test results. But they get sent to the wrong PR, i. e. to the wrong statuses API. E. g. https://api.github.com/repos/systemd/systemd/commits/99894b867f1293f56d181d62f5015c5a0a8adbda/status was triggered by https://github.com/systemd/systemd/pull/11682 but the referenced logs are for PR #11767. This caused the landing of a regression (that the tests would have noticed). ** Package changed: autopkgtest (Ubuntu) => autopkgtest-cloud -- 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/1817344 Title: Ubuntu CI that runs tests via autopkgtest for systemd on GitHub reports the wrong results Status in autopkgtest-cloud: New Status in systemd package in Ubuntu: New Bug description: I'm not sure this is the right place to report this, but apparently it's the best way to reach out to Dimitri John Ledkov (https://github.com/xnox) and Iain Lane (https://github.com/iainlane), who I believe at least know who maintains Ubuntu CI there. I'm copying the following verbatim from https://github.com/systemd/systemd/pull/11531#issuecomment-464731263 (where we are kind of discussing the issue): > The two PRs you referenced to fail in the `make check` unit tests (test-path). That's correct that test-path failed but it failed in https://github.com/systemd/systemd/pull/11685 while Ubuntu CI reported it in https://github.com/systemd/systemd/pull/11686 (that is, in https://github.com/systemd/systemd/pull/11686 in the logs for some reason UPSTREAM_PULL_REQUEST is 11685 instead of 11686 and something like that has happened often lately). In https://github.com/systemd/systemd/pull/11743#issuecomment-464637797, the issue is that Ubuntu CI showed the results for the first version of the PR (where there was a bug) and it didn't run the tests against the latest version. But in that case it's hard to tell because there is no way to figure out what exactly Ubuntu CI tested. That's why I asked @xnox to add `git describe` to https://salsa.debian.org/systemd- team/systemd/blob/master/debian/extra/checkout-upstream so that by looking at UPSTREAM_PULL_REQUEST and the output of `git describe` it would be possible to find out what Ubuntu CI reports. To manage notifications about this bug go to: https://bugs.launchpad.net/autopkgtest-cloud/+bug/1817344/+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 1787396] Re: ss crashes when using --no-header
I confirm this on Ubuntu 18.04 (bionic) with 4.15.0-2ubuntu1. It is fixed in 18.10 (cosmic) with 4.18.0-1ubuntu2. ** Also affects: iproute2 (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: iproute2 (Ubuntu Bionic) Status: New => Confirmed ** Changed in: iproute2 (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/1787396 Title: ss crashes when using --no-header Status in iproute2 package in Ubuntu: Fix Released Status in iproute2 source package in Bionic: Confirmed Bug description: Steps to reproduce: 1) Listen on port 8989: $ nc -l 8989 & 2) Check that ss can list this listener: $ ss --no-header -nto state listening 'sport = 8989' 010.0.0.0:8989 0.0.0.0:* 3) Ask ss to list listeners on a port where nothing listens $ kill %1 # stops nc $ ss --no-header -nto state listening 'sport = 8989' Segmentation fault (core dumped) In the above, removing "--no-header" avoids the segfault. Additional information: $ lsb_release -rd Description: Ubuntu 18.04.1 LTS Release: 18.04 $ apt-cache policy iproute2 iproute2: Installed: 4.15.0-2ubuntu1 Candidate: 4.15.0-2ubuntu1 Version table: *** 4.15.0-2ubuntu1 500 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages 100 /var/lib/dpkg/status ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: iproute2 4.15.0-2ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-32.35-generic 4.15.18 Uname: Linux 4.15.0-32-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Aug 16 08:17:52 2018 InstallationDate: Installed on 2018-07-15 (32 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180714) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_CA.UTF-8 SHELL=/bin/bash SourcePackage: iproute2 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1787396/+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 1750654] [NEW] "lxc-create -B best" fails on non-btrfs/zfs system
Public bug reported: As per documentation, the `-B best` option should automatically select the best backingstore, falling back all the way to dir. But apparently it doesn't, at least not in artful's 2.1.0-0ubuntu1: $ sudo lxc-create -B best --name=autopkgtest-xenial -t ubuntu -- -r xenial lxc-create: autopkgtest-xenial: storage/btrfs.c: btrfs_create: 860 Inappropriate ioctl for device - Failed to create btrfs subvolume "/var/lib/lxc/autopkgtest-xenial/rootfs" lxc-create: autopkgtest-xenial: storage/zfs.c: zfs_create: 758 Failed to create zfs dataset "zfs:lxc/autopkgtest-xenial": lxc-create: autopkgtest-xenial: utils.c: run_command: 2326 failed to exec command lxc-create: autopkgtest-xenial: storage/zfs.c: zfs_mount: 256 No such file or directory - Failed to mount "lxc/autopkgtest-xenial" on "/usr/lib/x86_64-linux-gnu/lxc" lxc-create: autopkgtest-xenial: lxccontainer.c: create_run_template: 1294 Failed to mount rootfs lxc-create: autopkgtest-xenial: lxccontainer.c: create_run_template: 1473 container creation template for autopkgtest-xenial failed lxc-create: autopkgtest-xenial: storage/zfs.c: zfs_destroy: 613 Failed to detect zfs dataset "lxc/autopkgtest-xenial": lxc-create: autopkgtest-xenial: lxc-create: autopkgtest-xenial: lxccontainer.c: container_destroy: 2653 Error destroying rootfs for autopkgtest-xenial lxc-create: autopkgtest-xenial: tools/lxc_create.c: main: 326 Error creating container autopkgtest-xenial Moreover, it creates cruft which is hard to clean up again: $ sudo lxc-ls -f NAME STATE AUTOSTART GROUPS IPV4 IPV6 autopkgtest-xenial STOPPED 0 - -- $ sudo lxc-destroy -n autopkgtest-xenial lxc-destroy: autopkgtest-xenial: storage/zfs.c: zfs_destroy: 613 Failed to detect zfs dataset "lxc/autopkgtest-xenial": lxc-destroy: autopkgtest-xenial: utils.c: run_command: 2326 failed to exec command lxc-destroy: autopkgtest-xenial: lxccontainer.c: container_destroy: 2653 Error destroying rootfs for autopkgtest-xenial Destroying autopkgtest-xenial failed $ sudo ls -lR /var/lib/lxc/autopkgtest-xenial /var/lib/lxc/autopkgtest-xenial: total 8 -rw-r--r-- 1 root root 149 Feb 20 20:41 config drwxr-xr-x 2 root root 4096 Feb 20 20:41 rootfs /var/lib/lxc/autopkgtest-xenial/rootfs: total 0 This can only be cleaned up with `sudo rm -r`. autopkgtest-build-lxc uses this option to get performant containers out of the box. Arguably `-B best` is a sort of "unbreak my containers" option and should always implicitly be used, but is there something else that I should do here? ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: lxc 2.1.0-0ubuntu1 ProcVersionSignature: Ubuntu 4.13.0-32.35-generic 4.13.13 Uname: Linux 4.13.0-32-generic x86_64 NonfreeKernelModules: zfs zunicode zavl zcommon znvpair ApportVersion: 2.20.7-0ubuntu3.7 Architecture: amd64 Date: Tue Feb 20 20:38:55 2018 JournalErrors: Error: command ['journalctl', '-b', '--priority=warning', '--lines=1000'] failed with exit code 1: Hint: You are currently not seeing messages from other users and the system. Users in the 'systemd-journal' group can see all messages. Pass -q to turn off this notice. No journal files were opened due to insufficient permissions. PackageArchitecture: all 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 lxcsyslog: ** Affects: lxc (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apparmor apport-bug artful -- 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/1750654 Title: "lxc-create -B best" fails on non-btrfs/zfs system Status in lxc package in Ubuntu: New Bug description: As per documentation, the `-B best` option should automatically select the best backingstore, falling back all the way to dir. But apparently it doesn't, at least not in artful's 2.1.0-0ubuntu1: $ sudo lxc-create -B best --name=autopkgtest-xenial -t ubuntu -- -r xenial lxc-create: autopkgtest-xenial: storage/btrfs.c: btrfs_create: 860 Inappropriate ioctl for device - Failed to create btrfs subvolume "/var/lib/lxc/autopkgtest-xenial/rootfs" lxc-create: autopkgtest-xenial: storage/zfs.c: zfs_create: 758 Failed to create zfs dataset "zfs:lxc/autopkgtest-xenial": lxc-create: autopkgtest-xenial: utils.c: run_command: 2326 failed to exec command lxc-create: autopkgtest-xenial: storage/zfs.c: zfs_mount: 256 No such file or directory - Failed to mount "lxc/autopkgtest-xenial" on "/usr/lib/x86_64-linux-gnu/lxc" lxc-create: autopkgtest-xenial: lxccontainer.c: create_run_template: 1294 Failed to mount rootfs lxc-create: autopkgtest-xenial: lxccontainer.c: create_run_template: 1473 container creation template for autopkgtest-xenial failed lxc-create: autopkgtest-xenial: s
[Touch-packages] [Bug 1707898] Re: systemd translations are not synced with upstream
Thanks Gunnar, nice work! I cherry-picked the patches in https://salsa.debian.org/systemd-team/systemd/commit/87f54958bc24 . The debian/ changes were already in Debian master. ** Changed in: systemd (Ubuntu) Status: In Progress => Fix Committed -- 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/1707898 Title: systemd translations are not synced with upstream Status in systemd: Fix Released Status in Ubuntu Translations: New Status in systemd package in Ubuntu: Fix Committed Bug description: Translations for systemd are outdated because they do not seem to be synced with the upstream ones. For example the Czech one: Launchpad: https://translations.launchpad.net/ubuntu/artful/+source/systemd/+pots/systemd/cs/+translate - 0% translated Upstream: https://github.com/systemd/systemd/blob/master/po/cs.po - 100% translated To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1707898/+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 1707898] Re: systemd translations are not synced with upstream
I confirmed that the current "ninja -C build-deb/ systemd-pot" command
also builds a complete .pot file with policykit-1 installed
(unsurprisingly, as this also just calls gettext). So that part is fine.
What is really bad however, is to build-depend against policykit-1:
The following NEW packages will be installed:
cgmanager dbus libcgmanager0 libnih-dbus1 libnih1 libpam-systemd
libpolkit-backend-1-0 libprocps6 policykit-1 procps systemd
systemd-shim
This is an awful lot to pull into a buildd schroot, in particular it
makes systemd build-depend on itself. I'd really like to avoid that.
Are the files /usr/share/gettext/its/polkit.{its,loc} only being used at
build time, or does polkit need these at runtime for dynamic gettext
translations? My gut feeling is that it's the former, and then it would
make sense to move these two into libpolkit-gobject-1-dev instead.
systemd already build-depends on that, thus it will automatically pick
these up.
--
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/1707898
Title:
systemd translations are not synced with upstream
Status in systemd:
New
Status in Ubuntu Translations:
New
Status in systemd package in Ubuntu:
In Progress
Bug description:
Translations for systemd are outdated because they do not seem to be
synced with the upstream ones.
For example the Czech one:
Launchpad:
https://translations.launchpad.net/ubuntu/artful/+source/systemd/+pots/systemd/cs/+translate
- 0% translated
Upstream: https://github.com/systemd/systemd/blob/master/po/cs.po - 100%
translated
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1707898/+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 1707898] Re: systemd translations are not synced with upstream
Thanks Gunnar for tracking this down! Adding a policykit-1 build dependency requires some thought, as that also build-depends on systemd [1], thus this is circular. Also, there was a lot of effort with making systemd bootstrappable without excessive dependencies. But I think it's fine to add this as a [!stage1] b-dep. [1] https://anonscm.debian.org/cgit/pkg- utopia/policykit.git/tree/debian/control -- 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/1707898 Title: systemd translations are not synced with upstream Status in systemd: New Status in Ubuntu Translations: New Status in systemd package in Ubuntu: In Progress Bug description: Translations for systemd are outdated because they do not seem to be synced with the upstream ones. For example the Czech one: Launchpad: https://translations.launchpad.net/ubuntu/artful/+source/systemd/+pots/systemd/cs/+translate - 0% translated Upstream: https://github.com/systemd/systemd/blob/master/po/cs.po - 100% translated To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1707898/+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 1707898] Re: systemd translations are not synced with upstream
@Gunnar: This patch does not actually work: ❱❱❱ xgettext -f "po/POTFILES.in" -o "build-deb/po/systemd.pot" --join-existing xgettext: warning: file 'src/core/org.freedesktop.systemd1.policy.in.in' extension 'policy' is unknown; will try C xgettext: warning: file 'src/hostname/org.freedesktop.hostname1.policy.in' extension 'policy' is unknown; will try C xgettext: warning: file 'src/import/org.freedesktop.import1.policy.in' extension 'policy' is unknown; will try C xgettext: warning: file 'src/locale/org.freedesktop.locale1.policy.in' extension 'policy' is unknown; will try C xgettext: warning: file 'src/login/org.freedesktop.login1.policy.in' extension 'policy' is unknown; will try C xgettext: warning: file 'src/machine/org.freedesktop.machine1.policy.in' extension 'policy' is unknown; will try C xgettext: warning: file 'src/timedate/org.freedesktop.timedate1.policy.in' extension 'policy' is unknown; will try C And systemd.pot is unchanged. I now committed https://salsa.debian.org/systemd- team/systemd/commit/09c6423728319 to simplify the .pot generation, but it has the exact same issue. -- 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/1707898 Title: systemd translations are not synced with upstream Status in systemd: New Status in Ubuntu Translations: New Status in systemd package in Ubuntu: In Progress Bug description: Translations for systemd are outdated because they do not seem to be synced with the upstream ones. For example the Czech one: Launchpad: https://translations.launchpad.net/ubuntu/artful/+source/systemd/+pots/systemd/cs/+translate - 0% translated Upstream: https://github.com/systemd/systemd/blob/master/po/cs.po - 100% translated To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1707898/+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 1707898] Re: systemd translations are not synced with upstream
I committed the first hunk to Debian, this makes sense: https://salsa.debian.org/systemd-team/systemd/commit/18d8c2df133b8af The second is too hackish for a permanent downstream delta, IMHO: This should rather be fixed upstream, as upstream polkit (as well as Debian's and Ubuntu's older versions) have proper runtime gettext support. -- 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/1707898 Title: systemd translations are not synced with upstream Status in Ubuntu Translations: New Status in systemd package in Ubuntu: In Progress Bug description: Translations for systemd are outdated because they do not seem to be synced with the upstream ones. For example the Czech one: Launchpad: https://translations.launchpad.net/ubuntu/artful/+source/systemd/+pots/systemd/cs/+translate - 0% translated Upstream: https://github.com/systemd/systemd/blob/master/po/cs.po - 100% translated To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-translations/+bug/1707898/+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 1727202] Re: [17.10 regression] AppArmor ntp denial: Failed name lookup - disconnected path
The most plausible explanation for enumerating /usr/local/bin/ is that ntpd has some hooks.d/ mechanism which gets called after syncing the time, and that runs a shell in between. So IMHO this should be allowed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1727202 Title: [17.10 regression] AppArmor ntp denial: Failed name lookup - disconnected path Status in ntp package in Ubuntu: Fix Released Status in ntp source package in Xenial: Invalid Status in ntp source package in Zesty: Invalid Status in ntp source package in Artful: Fix Released Status in ntp source package in Bionic: Fix Released Bug description: [Impact] * NTP has new isolation features which makes it trigger apparmor issues. * Those apparmor issues not only clutter the log and make other things less readable, they also prevent ntp from reporting its actual messages. * Fix is opening the apparmor profile to follow ntp through the disconnect by the isolation feature. [Test Case] * This is hard to trigger, but then also not. Which means it is not entirely sorted out when it triggers and when not, but the following does trigger it in tests of Pitti and also mine (while at the same time sometimes it does not - mabye I had other guests or kvm instead of lxd) * First install ntp in Artful (or above unless fixed) * Install ntp and check demsg for denies * Once an issue triggers instead of the error in syslog you'll see the apparmor Deny like: apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/ntpd" name="run/systemd/journal/dev-log" pid=5600 comm="ntpd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0 [Regression Potential] * We are slightly opening up the apparmor profile which is far lower risk than adding more constraints. So safe from that POV. * OTOH one could think this might be a security issue, but in fact this isn't a new suggestion if you take a look at [1] with an ack by Seth of the Security Team. [Other Info] * n/a [1]: https://lists.ubuntu.com/archives/apparmor/2015-May/007858.html Merely installing and starting ntp.service in Ubuntu 17.10 now causes this AppArmor violation: audit: type=1400 audit(1508915894.215:25): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/ntpd" name="run/systemd/journal/dev-log" pid=5600 comm="ntpd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0 (many times). This hasn't happened in earlier Ubuntu releases yet. This was spotted by Cockpit's integration tests, as our "ubuntu- stable" image now moved to 17.10 after its release. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ntp 1:4.2.8p10+dfsg-5ubuntu3 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 Date: Wed Oct 25 03:19:34 2017 SourcePackage: ntp UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1727202/+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 1741227] Re: apparmor denial to several paths to binaries
The most plausible explanation for enumerating /usr/local/bin/ is that ntpd has some hooks.d/ mechanism which gets called after syncing the time, and that runs a shell in between. So IMHO this should be allowed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1741227 Title: apparmor denial to several paths to binaries Status in ntp package in Ubuntu: Confirmed Bug description: Issue shows up (non fatal) as: apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" name="/usr/local/sbin/" pid=23933 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" name="/usr/local/bin/" pid=23933 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Since non crit this is mostyl about many of us being curious why it actually does do it :-) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1741227/+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 1727202] Re: [17.10 regression] AppArmor ntp denial: Failed name lookup - disconnected path
I locally ran Cockpit tests on our current Ubuntu 17.10 image and re- confirm that I got the "disconnected path" error. I then upgraded the ntp package to artful-proposed, and *that* violation is now gone. As others already saw, I now get a test failure on apparmor="DENIED" operation="open" profile="/usr/sbin/ntpd" name="/usr/local/sbin/" pid=5938 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 But this is not a regression from this update, and unrelated. So this SRU is good from my POV. Thanks! ** Tags removed: verification-needed-artful ** Tags added: verification-done-artful -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1727202 Title: [17.10 regression] AppArmor ntp denial: Failed name lookup - disconnected path Status in ntp package in Ubuntu: Fix Released Status in ntp source package in Xenial: Invalid Status in ntp source package in Zesty: Invalid Status in ntp source package in Artful: Fix Committed Status in ntp source package in Bionic: Fix Released Bug description: [Impact] * NTP has new isolation features which makes it trigger apparmor issues. * Those apparmor issues not only clutter the log and make other things less readable, they also prevent ntp from reporting its actual messages. * Fix is opening the apparmor profile to follow ntp through the disconnect by the isolation feature. [Test Case] * This is hard to trigger, but then also not. Which means it is not entirely sorted out when it triggers and when not, but the following does trigger it in tests of Pitti and also mine (while at the same time sometimes it does not - mabye I had other guests or kvm instead of lxd) * First install ntp in Artful (or above unless fixed) * Install ntp and check demsg for denies * Once an issue triggers instead of the error in syslog you'll see the apparmor Deny like: apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/ntpd" name="run/systemd/journal/dev-log" pid=5600 comm="ntpd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0 [Regression Potential] * We are slightly opening up the apparmor profile which is far lower risk than adding more constraints. So safe from that POV. * OTOH one could think this might be a security issue, but in fact this isn't a new suggestion if you take a look at [1] with an ack by Seth of the Security Team. [Other Info] * n/a [1]: https://lists.ubuntu.com/archives/apparmor/2015-May/007858.html Merely installing and starting ntp.service in Ubuntu 17.10 now causes this AppArmor violation: audit: type=1400 audit(1508915894.215:25): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/ntpd" name="run/systemd/journal/dev-log" pid=5600 comm="ntpd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0 (many times). This hasn't happened in earlier Ubuntu releases yet. This was spotted by Cockpit's integration tests, as our "ubuntu- stable" image now moved to 17.10 after its release. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ntp 1:4.2.8p10+dfsg-5ubuntu3 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 Date: Wed Oct 25 03:19:34 2017 SourcePackage: ntp UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1727202/+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 1727202] Re: [17.10 regression] AppArmor denial: Failed name lookup - disconnected path
Thanks Christian! Indeed this is rather hard to reproduce locally, but that PR seems to address this. I'll let you know if it doesn't after it lands. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1727202 Title: [17.10 regression] AppArmor denial: Failed name lookup - disconnected path Status in ntp package in Ubuntu: Triaged Status in ntp source package in Artful: New Status in ntp source package in Bionic: Triaged Bug description: Merely installing and starting ntp.service in Ubuntu 17.10 now causes this AppArmor violation: audit: type=1400 audit(1508915894.215:25): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/ntpd" name="run/systemd/journal/dev-log" pid=5600 comm="ntpd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0 (many times). This hasn't happened in earlier Ubuntu releases yet. This was spotted by Cockpit's integration tests, as our "ubuntu- stable" image now moved to 17.10 after its release. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ntp 1:4.2.8p10+dfsg-5ubuntu3 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 Date: Wed Oct 25 03:19:34 2017 SourcePackage: ntp UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1727202/+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 1153671] Re: Port to python3-launchpadlib
Once you do this, these fallbacks should be cleaned up: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/crashdb_impl/launchpad.py#L30 http://bazaar.launchpad.net/~apport-hackers/apport/trunk/view/head:/apport/crashdb_impl/launchpad.py#L137 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1153671 Title: Port to python3-launchpadlib Status in apport package in Ubuntu: Triaged Bug description: Apport-cli depends on python3-launchpadlib for some actions, but it is not installable (currently). For example, apport-cli -u 542452 ERROR: The launchpadlib Python module is not installed. This functionality is not available. The current candidates for installation on raring only include python- launchpadlib (which is python2 based). I believe this bug is relevant: https://bugs.launchpad.net/launchpadlib/+bug/1060734 I'm filing this against apport in the event raring is shipped without a python3-launchpadlib package. I would recommend updating the error to make what is needing to be installed more clear. IE, ERROR: The launchpadlib Python3 module is not installed (python3-launchpadlib). This functionality is not available. Also consider adding the library as a suggested dependency. In addition, should the package not land, further steps may be required. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1153671/+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 1725348] Re: Systemd - Bypassing MemoryDenyWriteExecution policy
Patches backported into Debian packaging git: https://anonscm.debian.org/cgit/pkg- systemd/systemd.git/commit/?id=9bba5469f2b95ea9 -- 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/1725348 Title: Systemd - Bypassing MemoryDenyWriteExecution policy Status in systemd package in Ubuntu: New Status in systemd source package in Xenial: New Status in systemd source package in Zesty: New Status in systemd source package in Artful: New Status in systemd source package in Bionic: New Bug description: Hello, We would like to report to you a vulnerability about systemd which allows to bypass the MemoryDenyWriteExecution policy on Linux 4.9+. The vulnerability is described in the attached PDF file. Sincerely, Thomas IMBERT To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1725348/+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 1727202] [NEW] [17.10 regression] AppArmor denial: Failed name lookup - disconnected path
Public bug reported: Merely installing and starting ntp.service in Ubuntu 17.10 now causes this AppArmor violation: audit: type=1400 audit(1508915894.215:25): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/ntpd" name="run/systemd/journal/dev-log" pid=5600 comm="ntpd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0 (many times). This hasn't happened in earlier Ubuntu releases yet. This was spotted by Cockpit's integration tests, as our "ubuntu-stable" image now moved to 17.10 after its release. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ntp 1:4.2.8p10+dfsg-5ubuntu3 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 Date: Wed Oct 25 03:19:34 2017 SourcePackage: ntp UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: ntp (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apparmor apport-bug artful regression-release ** Tags added: regression-release -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1727202 Title: [17.10 regression] AppArmor denial: Failed name lookup - disconnected path Status in ntp package in Ubuntu: New Bug description: Merely installing and starting ntp.service in Ubuntu 17.10 now causes this AppArmor violation: audit: type=1400 audit(1508915894.215:25): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/usr/sbin/ntpd" name="run/systemd/journal/dev-log" pid=5600 comm="ntpd" requested_mask="w" denied_mask="w" fsuid=0 ouid=0 (many times). This hasn't happened in earlier Ubuntu releases yet. This was spotted by Cockpit's integration tests, as our "ubuntu- stable" image now moved to 17.10 after its release. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: ntp 1:4.2.8p10+dfsg-5ubuntu3 ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4 Uname: Linux 4.13.0-16-generic x86_64 ApportVersion: 2.20.7-0ubuntu3 Architecture: amd64 Date: Wed Oct 25 03:19:34 2017 SourcePackage: ntp UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1727202/+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 1574706] Re: Disabling the welcome wizard doesn’t dismiss it
With the demise of the Ubuntu phone (rest in peace, *tear*) this is obsolete now. ** Changed in: autopkgtest (Ubuntu) Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity8 in Ubuntu. https://bugs.launchpad.net/bugs/1574706 Title: Disabling the welcome wizard doesn’t dismiss it Status in autopkgtest package in Ubuntu: Won't Fix Status in phablet-tools package in Ubuntu: New Status in unity8 package in Ubuntu: New Bug description: The autopkgtest helper script that sets up a phone for running autopilot tests (https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/ssh- setup/adb) disables the welcome wizard and edges intro. To disable the welcome wizard, it issues the following command: phablet-config welcome-wizard --disable Which under the covers creates the following file on the device: ~/.config/ubuntu-system-settings/wizard-has-run. Unity8 doesn’t seem to have any logic to discard the currently running wizard when that file is created (maybe on purpose?). This results in the phone under test still displaying the welcome wizard when control is handed off to the app’s autopkgtests, so autopilot tests will most likely fail because the app being launched is displayed under the wizard. I’m not sure whether not dismissing the wizard when the "wizard-has- run" file is being created is intentional. If it is, then the autopkgtest helper script needs additional logic to restart unity8 and unlock the screen. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1574706/+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 1716034] Re: Network manager stops managing Ethernet links after upgrade
FTR, I don't want to blame the NetworkManager 1.2.6 SRU to xenial - that new upstream version now evades the version test in the postinst, but of course it's still that version test which is at fault. I don't see how we can use a simple version test to determine the situation that we want (one-time test after upgrading from 16.04 LTS), I suppose it needs to move to "$2 is not empty" plus creating a migration stamp file somewhere. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1716034 Title: Network manager stops managing Ethernet links after upgrade Status in network-manager package in Ubuntu: Confirmed Bug description: After upgrading Ubuntu, it stopped configuring the word connection on my headless computer (super annoying to deal with). In any case, it was an issue with NM config change that caused my wired device to become unmanaged. There are several people discussing this here: https://askubuntu.com/questions/882806/ethernet-device-not-managed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1716034/+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 1716034] Re: Network manager stops managing Ethernet links after upgrade
I'm sorry, I mean bug 1676547. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1716034 Title: Network manager stops managing Ethernet links after upgrade Status in network-manager package in Ubuntu: Confirmed Bug description: After upgrading Ubuntu, it stopped configuring the word connection on my headless computer (super annoying to deal with). In any case, it was an issue with NM config change that caused my wired device to become unmanaged. There are several people discussing this here: https://askubuntu.com/questions/882806/ethernet-device-not-managed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1716034/+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 1716034] Re: Network manager stops managing Ethernet links after upgrade
Is that any better with the fix in bug 1690992? That sounds very much like a duplicate? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1716034 Title: Network manager stops managing Ethernet links after upgrade Status in network-manager package in Ubuntu: Confirmed Bug description: After upgrading Ubuntu, it stopped configuring the word connection on my headless computer (super annoying to deal with). In any case, it was an issue with NM config change that caused my wired device to become unmanaged. There are several people discussing this here: https://askubuntu.com/questions/882806/ethernet-device-not-managed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1716034/+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 1689820] Re: /usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker:
I ran the description's test case and confirm that the crash is now fixed. Furthermore, other operations like "pkcon refresh", "pkcon get- updates", "pkcon update", and "pkcon install bash-doc" all worked fine, as before. ** Tags removed: verification-needed verification-needed-xenial ** Tags added: verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to packagekit in Ubuntu. https://bugs.launchpad.net/bugs/1689820 Title: /usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker::InFdReady Status in packagekit package in Ubuntu: Fix Released Status in packagekit source package in Xenial: Fix Committed Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding packagekit. This problem was most recently seen with package version 0.8.17-4ubuntu6~gcc5.4ubuntu1.1, the problem page at https://errors.ubuntu.com/problem/8c37a6988b890cc46b415972ef1e2ca746f9ffcc contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker you can request it at http://forms.canonical.com/reports/. SRU INFORMATION === * Impact: PackageKit immediately crashes in GetUpdateDetail() * Test case: - Be on a system (container, VM, or real iron) with at least one upgradeable package. If you don't have one, downgrade tzdata: sudo apt-get install tzdata=2016j-0ubuntu0.16.04 - Run "pkcon get-updates" to see upgradeable packages. - Run "pkcon get-update-detail tzdata" (or for a different package). - Current PackageKit immediately crashes (message from pkcon and systemctl status packagekit), with this fix it should survive and show some data (changelog doesn't work though). * Regression potential: Update details are currently completely broken, so very little to regress there. As for dropping the browser plugin package: The current package stopped working long ago with current firefox; however, the package from xenial-release will still be around. All in all this shouldn't change anything visible. * Upstream fix: https://github.com/hughsie/PackageKit/commit/18c56fa52 (only the acqpkitstatus.cpp bit) * Downstream packaging change to drop browser plugin: https://anonscm.debian.org/git/pkg- packagekit/packagekit.git/commit/?id=b98a978322 Test packages: http://people.ubuntu.com/~pitti/packagekit- updatedetail-crash/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1689820/+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 1689820] Re: /usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker:
** Description changed: The Ubuntu Error Tracker has been receiving reports about a problem regarding packagekit. This problem was most recently seen with package version 0.8.17-4ubuntu6~gcc5.4ubuntu1.1, the problem page at https://errors.ubuntu.com/problem/8c37a6988b890cc46b415972ef1e2ca746f9ffcc contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker you can request it at http://forms.canonical.com/reports/. + + SRU INFORMATION + === + * Impact: PackageKit immediately crashes in GetUpdateDetail().. + + * Test case: +- Be on a system (container, VM, or real iron) with at least one upgradeable package. If you don't have one, downgrade tzdata: + sudo apt-get install tzdata=2016j-0ubuntu0.16.04 +- Run "pkcon get-updates" to see upgradeable packages. +- Run "pkcon get-update-detail tzdata" (or for a different package). +- Current PackageKit immediately crashes (message from pkcon and systemctl status packagekit), with this fix it should survive and show some data (changelog doesn't work though). + + * Regression potential: Update details are currently completely broken, + so very little to regress there. As for dropping the browser plugin + package: The current package stopped working long ago with current + firefox; however, the package from xenial-release will still be around. + All in all this shouldn't change anything visible. + + * Upstream fix: https://github.com/hughsie/PackageKit/commit/18c56fa52 + (only the acqpkitstatus.cpp bit) + + * Downstream packaging change to drop browser plugin: + https://anonscm.debian.org/git/pkg- + packagekit/packagekit.git/commit/?id=b98a978322 ** Description changed: The Ubuntu Error Tracker has been receiving reports about a problem regarding packagekit. This problem was most recently seen with package version 0.8.17-4ubuntu6~gcc5.4ubuntu1.1, the problem page at https://errors.ubuntu.com/problem/8c37a6988b890cc46b415972ef1e2ca746f9ffcc contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker you can request it at http://forms.canonical.com/reports/. SRU INFORMATION === - * Impact: PackageKit immediately crashes in GetUpdateDetail().. + * Impact: PackageKit immediately crashes in GetUpdateDetail() - * Test case: -- Be on a system (container, VM, or real iron) with at least one upgradeable package. If you don't have one, downgrade tzdata: - sudo apt-get install tzdata=2016j-0ubuntu0.16.04 -- Run "pkcon get-updates" to see upgradeable packages. -- Run "pkcon get-update-detail tzdata" (or for a different package). -- Current PackageKit immediately crashes (message from pkcon and systemctl status packagekit), with this fix it should survive and show some data (changelog doesn't work though). + * Test case: + - Be on a system (container, VM, or real iron) with at least one upgradeable package. If you don't have one, downgrade tzdata: + sudo apt-get install tzdata=2016j-0ubuntu0.16.04 + - Run "pkcon get-updates" to see upgradeable packages. + - Run "pkcon get-update-detail tzdata" (or for a different package). + - Current PackageKit immediately crashes (message from pkcon and systemctl status packagekit), with this fix it should survive and show some data (changelog doesn't work though). - * Regression potential: Update details are currently completely broken, + * Regression potential: Update details are currently completely broken, so very little to regress there. As for dropping the browser plugin package: The current package stopped working long ago with current firefox; however, the package from xenial-release will still be around. All in all this shouldn't change anything visible. - * Upstream fix: https://github.com/hughsie/PackageKit/commit/18c56fa52 + * Upstream fix: https://github.com/hughsie/PackageKit/commit/18c56fa52 (only the acqpkitstatus.cpp bit) - * Downstream packaging change to drop browser plugin: + * Downstream packaging change to drop browser plugin: https://anonscm.debian.org/git/pkg- packagekit/packagekit.git/commit/?id=b98a978322 ** Description changed: The Ubuntu Error Tracker has been receiving reports about a problem regarding packagekit. This problem was most recently seen with package version 0.8.17-4ubuntu6~gcc5.4ubuntu1.1, the problem page at https://errors.ubuntu.com/problem/8c37a6988b890cc46b415972ef1e2ca746f9ffcc contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker you can request it at http://forms.canonical.com/reports/. SRU INFORMATION === * Impact: PackageKit immediately crashes in GetUpda
[Touch-packages] [Bug 1689820] Re: /usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker:
I found the fix and backported it to xenial. The SRU is complicated by the fact that packagekit is currently FTBFS due to recent firefox dropping NPAPI, thus the browser plugin cannot be built any more. I'll drop it. ** Changed in: packagekit (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: packagekit (Ubuntu Xenial) Status: Confirmed => In Progress ** Changed in: packagekit (Ubuntu Xenial) Assignee: (unassigned) => Martin Pitt (pitti) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to packagekit in Ubuntu. https://bugs.launchpad.net/bugs/1689820 Title: /usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker::InFdReady Status in packagekit package in Ubuntu: Fix Released Status in packagekit source package in Xenial: In Progress Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding packagekit. This problem was most recently seen with package version 0.8.17-4ubuntu6~gcc5.4ubuntu1.1, the problem page at https://errors.ubuntu.com/problem/8c37a6988b890cc46b415972ef1e2ca746f9ffcc contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1689820/+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 1696480] Re: python3-dbusmock / test_no_adapters test fails with bluez 5.45
I released 0.16.8 upstream and uploaded it to Debian unstable, from where it should autosync into Ubuntu devel soon. ** Changed in: python-dbusmock (Ubuntu) Status: Triaged => Fix Committed ** Changed in: python-dbusmock Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1696480 Title: python3-dbusmock / test_no_adapters test fails with bluez 5.45 Status in python-dbusmock: Fix Released Status in bluez package in Ubuntu: Invalid Status in python-dbusmock package in Ubuntu: Fix Committed Bug description: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#bluez http://autopkgtest.ubuntu.com/packages/p/python-dbusmock/artful/amd64 With bluez 5.45 python3-dbusmock tests fail with: == FAIL: test_no_adapters (__main__.TestBlueZ5) -- Traceback (most recent call last): File "./test_bluez5.py", line 107, in test_no_adapters self.assertEqual([l for l in out if 'Waiting to connect' not in l], []) AssertionError: Lists differ: ['org.freedesktop.DBus.Mock.MethodCalled', 'registered', 'unregistered'] != [] First list contains 3 additional elements. First extra element 0: 'org.freedesktop.DBus.Mock.MethodCalled' - ['org.freedesktop.DBus.Mock.MethodCalled', 'registered', 'unregistered'] + [] -- ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: bluez 5.45-0ubuntu1 ProcVersionSignature: Ubuntu 4.10.0-22.24-generic 4.10.15 Uname: Linux 4.10.0-22-generic x86_64 ApportVersion: 2.20.5-0ubuntu4 Architecture: amd64 CurrentDesktop: GNOME Date: Wed Jun 7 18:01:13 2017 InstallationDate: Installed on 2013-09-03 (1372 days ago) InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130902) InterestingModules: bnep bluetooth MachineType: ASUSTeK COMPUTER INC. UX32VD ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.10.0-22-generic.efi.signed root=UUID=1004226d-a9db-46c7-bd28-eca0806c12f2 ro pcie_aspm=force drm.vblankoffdelay=1 i915.semaphores=1 init=/lib/systemd/systemd-bootchart SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/29/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: UX32VD.214 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: UX32VD dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrUX32VD.214:bd01/29/2013:svnASUSTeKCOMPUTERINC.:pnUX32VD:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX32VD:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: dmi.product.name: UX32VD dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. hciconfig: rfkill: 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no upstart.bluetooth.override: manual To manage notifications about this bug go to: https://bugs.launchpad.net/python-dbusmock/+bug/1696480/+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 1696480] Re: python3-dbusmock / test_no_adapters test fails with bluez 5.45
Thanks Daniel! PR merged upstream. There are a few other test deprecation warnings/failures I'm looking into before doing a release. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1696480 Title: python3-dbusmock / test_no_adapters test fails with bluez 5.45 Status in python-dbusmock: Fix Committed Status in bluez package in Ubuntu: Invalid Status in python-dbusmock package in Ubuntu: Triaged Bug description: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#bluez http://autopkgtest.ubuntu.com/packages/p/python-dbusmock/artful/amd64 With bluez 5.45 python3-dbusmock tests fail with: == FAIL: test_no_adapters (__main__.TestBlueZ5) -- Traceback (most recent call last): File "./test_bluez5.py", line 107, in test_no_adapters self.assertEqual([l for l in out if 'Waiting to connect' not in l], []) AssertionError: Lists differ: ['org.freedesktop.DBus.Mock.MethodCalled', 'registered', 'unregistered'] != [] First list contains 3 additional elements. First extra element 0: 'org.freedesktop.DBus.Mock.MethodCalled' - ['org.freedesktop.DBus.Mock.MethodCalled', 'registered', 'unregistered'] + [] -- ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: bluez 5.45-0ubuntu1 ProcVersionSignature: Ubuntu 4.10.0-22.24-generic 4.10.15 Uname: Linux 4.10.0-22-generic x86_64 ApportVersion: 2.20.5-0ubuntu4 Architecture: amd64 CurrentDesktop: GNOME Date: Wed Jun 7 18:01:13 2017 InstallationDate: Installed on 2013-09-03 (1372 days ago) InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130902) InterestingModules: bnep bluetooth MachineType: ASUSTeK COMPUTER INC. UX32VD ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.10.0-22-generic.efi.signed root=UUID=1004226d-a9db-46c7-bd28-eca0806c12f2 ro pcie_aspm=force drm.vblankoffdelay=1 i915.semaphores=1 init=/lib/systemd/systemd-bootchart SourcePackage: bluez UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/29/2013 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: UX32VD.214 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: UX32VD dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrUX32VD.214:bd01/29/2013:svnASUSTeKCOMPUTERINC.:pnUX32VD:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnUX32VD:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0: dmi.product.name: UX32VD dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. hciconfig: rfkill: 0: phy0: Wireless LAN Soft blocked: no Hard blocked: no upstart.bluetooth.override: manual To manage notifications about this bug go to: https://bugs.launchpad.net/python-dbusmock/+bug/1696480/+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 1694438] Re: [16.04] Cannot download packages whilst offline - when using ifupdown
This also affects PackageKit 1.0.1-2 in Debian Jessie. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to packagekit in Ubuntu. https://bugs.launchpad.net/bugs/1694438 Title: [16.04] Cannot download packages whilst offline - when using ifupdown Status in packagekit package in Ubuntu: Fix Released Status in packagekit source package in Xenial: New Bug description: I am using 16.04 with the main ethernet interface being managed by ifupdown, and others by NetworkManager. Apparently PK's pk_network_get_network_state() does not properly recognize this and thinks it is offline: # pkcon update Getting updates [=] [...] Fatal error: Cannot download packages whilst offline A workaround is to change /etc/NetworkManager/NetworkManager.conf [ifupdown] managed= from "false" to "true", then "eth0" appears in "nmcli d" and PackageKit is happy. In 17.04 this is no problem any more, PackageKit works out of the box with the same ifupdown configuration and managed=false. Interestingly, "nmcli d" shows eth0ethernet unmanaged -- there, while eth0 is entirely absent in 16.04. There doesn't seem to be an nmcli command to show what PackageKit looks at; the closest is "nmcli g" but in all three cases above that says STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN connected full enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1694438/+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 1694438] [NEW] [16.04] Cannot download packages whilst offline - when using ifupdown
Public bug reported: I am using 16.04 with the main ethernet interface being managed by ifupdown, and others by NetworkManager. Apparently PK's pk_network_get_network_state() does not properly recognize this and thinks it is offline: # pkcon update Getting updates [=] [...] Fatal error: Cannot download packages whilst offline A workaround is to change /etc/NetworkManager/NetworkManager.conf [ifupdown] managed= from "false" to "true", then "eth0" appears in "nmcli d" and PackageKit is happy. In 17.04 this is no problem any more, PackageKit works out of the box with the same ifupdown configuration and managed=false. Interestingly, "nmcli d" shows eth0ethernet unmanaged -- there, while eth0 is entirely absent in 16.04. There doesn't seem to be an nmcli command to show what PackageKit looks at; the closest is "nmcli g" but in all three cases above that says STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN connected full enabled enabled enabled enabled ** Affects: packagekit (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: packagekit (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: packagekit (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: packagekit (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to packagekit in Ubuntu. https://bugs.launchpad.net/bugs/1694438 Title: [16.04] Cannot download packages whilst offline - when using ifupdown Status in packagekit package in Ubuntu: Fix Released Status in packagekit source package in Xenial: New Bug description: I am using 16.04 with the main ethernet interface being managed by ifupdown, and others by NetworkManager. Apparently PK's pk_network_get_network_state() does not properly recognize this and thinks it is offline: # pkcon update Getting updates [=] [...] Fatal error: Cannot download packages whilst offline A workaround is to change /etc/NetworkManager/NetworkManager.conf [ifupdown] managed= from "false" to "true", then "eth0" appears in "nmcli d" and PackageKit is happy. In 17.04 this is no problem any more, PackageKit works out of the box with the same ifupdown configuration and managed=false. Interestingly, "nmcli d" shows eth0ethernet unmanaged -- there, while eth0 is entirely absent in 16.04. There doesn't seem to be an nmcli command to show what PackageKit looks at; the closest is "nmcli g" but in all three cases above that says STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN connected full enabled enabled enabled enabled To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1694438/+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 1689820] Re: /usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker:
I confirmed that this is fixed in zesty. ** Changed in: packagekit (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to packagekit in Ubuntu. https://bugs.launchpad.net/bugs/1689820 Title: /usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker::InFdReady Status in packagekit package in Ubuntu: Fix Released Status in packagekit source package in Xenial: New Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding packagekit. This problem was most recently seen with package version 0.8.17-4ubuntu6~gcc5.4ubuntu1.1, the problem page at https://errors.ubuntu.com/problem/8c37a6988b890cc46b415972ef1e2ca746f9ffcc contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1689820/+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 1689820] Re: /usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker:
This is quite simple to reproduce: $ pkcon get-updates Getting updates [=] Loading cache [=] Querying [=] Finished [=] Bug fix linux-generic-4.4.0.77.83.amd64 (xenial-updates) Complete Generic Linux kernel and headers Bug fix linux-headers-generic-4.4.0.77.83.amd64 (xenial-updates) Generic Linux kernel headers Bug fix linux-headers-virtual-4.4.0.77.83.amd64 (xenial-updates) Transitional package. Bug fix linux-image-generic-4.4.0.77.83.amd64 (xenial-updates) Generic Linux kernel image Bug fix linux-image-virtual-4.4.0.77.83.amd64 (xenial-updates) This package will always depend on the latest minimal generic kernel image. Bug fix linux-virtual-4.4.0.77.83.amd64 (xenial-updates) Minimal Generic Linux kernel and headers $ pkcon get-update-detail linux-image-virtual Resolving [=] Getting update details[=] Loading cache [=] Downloading packages [ ] (0%) The daemon crashed mid-transaction! This doesn't seem to be specific to the particular package. If I downgrade tzdata $ sudo apt-get install tzdata=2016d-0ubuntu0.16.04 and query that it crashes as well: $ pkcon get-update-detail tzdata Downloading packages [ ] (0%) The daemon crashed mid-transaction! 0x723ad6d5 in AcqPackageKitStatus::updateStatus(pkgAcquire::ItemDesc&, int) () from /usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so (gdb) bt #0 0x723ad6d5 in AcqPackageKitStatus::updateStatus(pkgAcquire::ItemDesc&, int) () from /usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so #1 0x723ad7d3 in AcqPackageKitStatus::Fail(pkgAcquire::ItemDesc&) () from /usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so #2 0x71b2bd96 in pkgAcquire::Worker::RunMessages() () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 #3 0x71b2d9dc in pkgAcquire::Worker::InFdReady() () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 #4 0x71b2f1ba in pkgAcquire::RunFdsSane(fd_set*, fd_set*) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 #5 0x71b32dd2 in pkgAcquire::Run(int) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 #6 0x723b4be1 in downloadChangelog(AptCacheFile&, pkgAcquire&, pkgCache::VerIterator, std::__cxx11::basic_string, std::allocator >) () from /usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so #7 0x723c6888 in AptIntf::emitUpdateDetail(pkgCache::VerIterator const&) () from /usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so #8 0x723c73c5 in AptIntf::emitUpdateDetails(PkgList const&) () from /usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so #9 0x723cbffd in ?? () from /usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so #10 0x5556e419 in ?? () #11 0x76c0cbb5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #12 0x769866ba in start_thread (arg=0x709ec700) at pthread_create.c:333 #13 0x766bc82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 (gdb) bt full #0 0x723ad6d5 in AcqPackageKitStatus::updateStatus(pkgAcquire::ItemDesc&, int) () from /usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so No symbol table info available. #1 0x723ad7d3 in AcqPackageKitStatus::Fail(pkgAcquire::ItemDesc&) () from /usr/lib/x86_64-linux-gnu/packagekit-backend/libpk_backend_aptcc.so No symbol table info available. #2 0x71b2bd96 in pkgAcquire::Worker::RunMessages() () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 ** Also affects: packagekit (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to packagekit in Ubuntu. https://bugs.launchpad.net/bugs/1689820 Title: /usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker::InFdReady Status in packagekit package in Ubuntu: Fix Released Status in packagekit source package in Xenial: New Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding packagekit. This problem was most recently seen with package version 0.8.17-4ubuntu6~gcc5.4ubuntu1.1, the problem page at https://errors.ubuntu.com/problem/8c37a6988b890cc46b415972ef1e2ca746f9ffcc contains more details, including versions of packages affected,
[Touch-packages] [Bug 1650827] Re: /usr/lib/dovecot/dovecot-lda: "Failed name lookup - disconnected path"
** Summary changed: - "Failed name lookup - disconnected path" + /usr/lib/dovecot/dovecot-lda: "Failed name lookup - disconnected path" -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1650827 Title: /usr/lib/dovecot/dovecot-lda: "Failed name lookup - disconnected path" Status in AppArmor: Fix Committed Status in AppArmor 2.10 series: Fix Committed Status in AppArmor 2.9 series: Fix Committed Status in apparmor package in Ubuntu: Confirmed Bug description: Hi, I'm currently trying to use dovecot in a test scenario, but run into the problem of a strange malfunction of apparmor. What I do: installed packages dovecot-core and dovecot-lmtp (and of course apparmor) Then I do (as root) /usr/lib/dovecot/dovecot-lda -d hadmut
Re: [Touch-packages] [Bug 103436] Re: sshd not reconfigured by /etc/network
Hey Perry, Perry E. Metzger [2017-03-20 13:11 -0400]: > That bug report was a decade ago. Yeah, I know :-) > So far as I know, this is still an issue for your users, because sshd > does not, on its own, change its network address when one changes > networks. I would not remove this because if you remove it you're > going to harm anyone who changes addresses frequently. That's what I've thought, but it am puzzled that I cannot actually produce this situation (when removing the script). That, and the fact that Fedora or SUSE don't have this indicate that this was dealt with by something else in the meantime. > However, I have not used Ubuntu in many years (this is 2017, the bug > report was 2007) and I am no longer in a position to help you. No worries, it was a long shot anyway. Thanks for your fast response! Martin -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/103436 Title: sshd not reconfigured by /etc/network Status in openssh package in Ubuntu: Fix Released Bug description: Binary package hint: openssh-server If you have a device that roams a lot (like a laptop), you want daemons like sshd to be tweaked/restarted by scripts in /etc/network so that they re-open the socket they listen on when the network address changes. (Yes, some of us really do want to be able to remotely log in to our laptops after we bring them home and they roam onto the home WiFi network etc.) Right now there is no sshd script in /etc/network/* but it would be trivial to create one and add it to the package. For sshd, it would be simplest just to restart the daemon. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/103436/+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 103436] Re: sshd not reconfigured by /etc/network
I filed bug 1674330 about dropping the hack. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/103436 Title: sshd not reconfigured by /etc/network Status in openssh package in Ubuntu: Fix Released Bug description: Binary package hint: openssh-server If you have a device that roams a lot (like a laptop), you want daemons like sshd to be tweaked/restarted by scripts in /etc/network so that they re-open the socket they listen on when the network address changes. (Yes, some of us really do want to be able to remotely log in to our laptops after we bring them home and they roam onto the home WiFi network etc.) Right now there is no sshd script in /etc/network/* but it would be trivial to create one and add it to the package. For sshd, it would be simplest just to restart the daemon. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/103436/+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 1674330] [NEW] Please consider dropping /etc/network/if-up.d/openssh-server
Public bug reported: The /etc/network/if-up.d/openssh-server hack was introduced ten years ago [1] as a response to bug 103436. At least from today's perspective this isn't justified: I can't seem to be able to actually reproduce that issue: I can start a VM with no network interfaces, remove the above hack, then start sshd, then bring up an ethernet interface, and I can connect to ssh via ethernet just fine. Also, e. g. Fedora has no counterpart of this hack, and these days a lot of people would complain if that would cause problems, as hotpluggable/roaming network devices are everywhere. The hack introduces a race: you run into connection errors after bringing up a new interface as sshd stops listening briefly while being reloaded. That's the reason why I looked at it, as this regularly happens in upstream's cockpit integration tests. Also, /etc/network/if-up.d/ isn't being run when using networkd/netplan, i. e. in more recent Ubuntnu cloud instances. So far this doesn't seem to have caused any issues. I asked the original reporter of bug 103436 for some details, and to check whether that hack is still necessary. There is actually a proposed patch upstream [2] to use IP_FREEBIND, which is the modern solution to listening to all "future" interfaces as well. But at least for the majority of cases it seems to work fine without that even. So I wonder if it's time to bury that hack? [1] https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/commit/?id=ba6b55ed6 [2] https://bugzilla.mindrot.org/show_bug.cgi?id=2512 ** Affects: openssh (Ubuntu) Importance: Low Status: New ** Changed in: openssh (Ubuntu) Importance: Undecided => Low -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1674330 Title: Please consider dropping /etc/network/if-up.d/openssh-server Status in openssh package in Ubuntu: New Bug description: The /etc/network/if-up.d/openssh-server hack was introduced ten years ago [1] as a response to bug 103436. At least from today's perspective this isn't justified: I can't seem to be able to actually reproduce that issue: I can start a VM with no network interfaces, remove the above hack, then start sshd, then bring up an ethernet interface, and I can connect to ssh via ethernet just fine. Also, e. g. Fedora has no counterpart of this hack, and these days a lot of people would complain if that would cause problems, as hotpluggable/roaming network devices are everywhere. The hack introduces a race: you run into connection errors after bringing up a new interface as sshd stops listening briefly while being reloaded. That's the reason why I looked at it, as this regularly happens in upstream's cockpit integration tests. Also, /etc/network/if-up.d/ isn't being run when using networkd/netplan, i. e. in more recent Ubuntnu cloud instances. So far this doesn't seem to have caused any issues. I asked the original reporter of bug 103436 for some details, and to check whether that hack is still necessary. There is actually a proposed patch upstream [2] to use IP_FREEBIND, which is the modern solution to listening to all "future" interfaces as well. But at least for the majority of cases it seems to work fine without that even. So I wonder if it's time to bury that hack? [1] https://anonscm.debian.org/cgit/pkg-ssh/openssh.git/commit/?id=ba6b55ed6 [2] https://bugzilla.mindrot.org/show_bug.cgi?id=2512 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1674330/+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 103436] Re: sshd not reconfigured by /etc/network
Perry, I just revisited this: - /etc/network/if-up.d/openssh-server hack introduces a race (you run into connection errors after bringing up a new interface as sshd stops listening briefly while being reloaded). - I can't seem to be able to actually reproduce that issue: I can start a VM with no network interfaces, remove the above hack, then start sshd, then bring up an ethernet interface, and I can connect to ssh via ethernet just fine. Also, e. g. Fedora has no counterpart of this hack, and these days a lot of people would complain if that would cause problems, as hotpluggable/roaming network devices are everywhere. - /etc/network/if-up.d/ isn't being run when using networkd/netplan, thus in our cloud instances. So far this doesn't seem to have caused any issues. So my questions: (1) Can you please describe more precisely what exactly you did back then? Do you have a nonstandard SSH configuration with some ListenAddresses/AddressFamily restrictions or similar? (2) Can you please disable the hack (sudo chmod 0 /etc/network/if-up.d /openssh-server) and check if your use case works without it? Thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/103436 Title: sshd not reconfigured by /etc/network Status in openssh package in Ubuntu: Fix Released Bug description: Binary package hint: openssh-server If you have a device that roams a lot (like a laptop), you want daemons like sshd to be tweaked/restarted by scripts in /etc/network so that they re-open the socket they listen on when the network address changes. (Yes, some of us really do want to be able to remotely log in to our laptops after we bring them home and they roam onto the home WiFi network etc.) Right now there is no sshd script in /etc/network/* but it would be trivial to create one and add it to the package. For sshd, it would be simplest just to restart the daemon. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/103436/+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
Re: [Touch-packages] [Bug 1647031] Re:systemd-resolved’s127.0.0.53 server does not follow CNAME records
Blaisorblade [2017-03-15 15:03 -]:
> Another corner case seems to be binaries linked against musl libc, since
> they do not use NSS.
Note that this is generally broken and cannot be supported, regardless of the
DNS resolver. These binaries could also not resolve winbind host names, YP,
LDAP, Active Directory, or sssd users/groups, and anything else which is
handled through nsswitch.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1647031
Title:
systemd-resolved’s 127.0.0.53 server does not follow CNAME records
Status in Nextcloud:
Unknown
Status in systemd:
New
Status in network-manager package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in network-manager source package in Yakkety:
Invalid
Status in systemd source package in Yakkety:
Triaged
Bug description:
$ systemd-resolve www.freedesktop.org
www.freedesktop.org: 131.252.210.176
2610:10:20:722:a800:ff:feda:470f
(annarchy.freedesktop.org)
-- Information acquired via protocol DNS in 673.6ms.
-- Data is authenticated: no
$ ping www.freedesktop.org
ping: www.freedesktop.org: Name or service not known
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
$ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
;www.freedesktop.org. IN A
www.freedesktop.org. 7146IN CNAME annarchy.freedesktop.org.
$ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
;www.freedesktop.org. IN A
www.freedesktop.org. 14399 IN CNAME annarchy.freedesktop.org.
annarchy.freedesktop.org. 14399 IN A 131.252.210.176
I trust it needn’t be explained why this makes the internet almost
completely useless in zesty.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nextcloud-snap/+bug/1647031/+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 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records
Yes, there, see "man resolved.conf". But I'd recommend a separate file
to avoid changing the package-provided conffile:
sudo mkdir -p /etc/systemd/resolved.conf.d
printf "[Resolve]\nDNSSEC=no\n" | sudo tee
/etc/systemd/resolved.conf.d/no-dnssec.conf
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1647031
Title:
systemd-resolved’s 127.0.0.53 server does not follow CNAME records
Status in systemd:
New
Status in network-manager package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Bug description:
$ systemd-resolve www.freedesktop.org
www.freedesktop.org: 131.252.210.176
2610:10:20:722:a800:ff:feda:470f
(annarchy.freedesktop.org)
-- Information acquired via protocol DNS in 673.6ms.
-- Data is authenticated: no
$ ping www.freedesktop.org
ping: www.freedesktop.org: Name or service not known
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
$ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
;www.freedesktop.org. IN A
www.freedesktop.org. 7146IN CNAME annarchy.freedesktop.org.
$ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
;www.freedesktop.org. IN A
www.freedesktop.org. 14399 IN CNAME annarchy.freedesktop.org.
annarchy.freedesktop.org. 14399 IN A 131.252.210.176
I trust it needn’t be explained why this makes the internet almost
completely useless in zesty.
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647031/+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 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records
Note: We keep DNSSEC=allow-downgrade during development to collect
feedback, but switch it off for stable releases (we did so in yakkety
and should do so again in zesty). So if you have some trouble which is
DNSSEC related, it would be good to get a debug output of resolved while
it's failing to report/investigate it. But that should be unrelated to
the CNAME bug here.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1647031
Title:
systemd-resolved’s 127.0.0.53 server does not follow CNAME records
Status in systemd:
New
Status in network-manager package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Bug description:
$ systemd-resolve www.freedesktop.org
www.freedesktop.org: 131.252.210.176
2610:10:20:722:a800:ff:feda:470f
(annarchy.freedesktop.org)
-- Information acquired via protocol DNS in 673.6ms.
-- Data is authenticated: no
$ ping www.freedesktop.org
ping: www.freedesktop.org: Name or service not known
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
$ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
;www.freedesktop.org. IN A
www.freedesktop.org. 7146IN CNAME annarchy.freedesktop.org.
$ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
;www.freedesktop.org. IN A
www.freedesktop.org. 14399 IN CNAME annarchy.freedesktop.org.
annarchy.freedesktop.org. 14399 IN A 131.252.210.176
I trust it needn’t be explained why this makes the internet almost
completely useless in zesty.
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647031/+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 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records
Fixed upstream:
https://github.com/systemd/systemd/commit/e8d23f92b50a97bb3
** Changed in: systemd (Ubuntu)
Status: Triaged => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1647031
Title:
systemd-resolved’s 127.0.0.53 server does not follow CNAME records
Status in systemd:
New
Status in network-manager package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Committed
Bug description:
$ systemd-resolve www.freedesktop.org
www.freedesktop.org: 131.252.210.176
2610:10:20:722:a800:ff:feda:470f
(annarchy.freedesktop.org)
-- Information acquired via protocol DNS in 673.6ms.
-- Data is authenticated: no
$ ping www.freedesktop.org
ping: www.freedesktop.org: Name or service not known
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
$ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
;www.freedesktop.org. IN A
www.freedesktop.org. 7146IN CNAME annarchy.freedesktop.org.
$ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
;www.freedesktop.org. IN A
www.freedesktop.org. 14399 IN CNAME annarchy.freedesktop.org.
annarchy.freedesktop.org. 14399 IN A 131.252.210.176
I trust it needn’t be explained why this makes the internet almost
completely useless in zesty.
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647031/+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 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings
I cherry-picked the patches into the Debian packaging branch, so that on
next upload zesty can be synced again.
--
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/1647485
Title:
NVMe symlinks broken by devices with spaces in model or serial strings
Status in maas-images:
Fix Released
Status in systemd:
New
Status in systemd package in Ubuntu:
Fix Committed
Status in systemd source package in Trusty:
Fix Released
Status in systemd source package in Xenial:
Fix Released
Status in systemd source package in Yakkety:
Fix Committed
Status in systemd source package in Zesty:
Fix Committed
Status in systemd package in Debian:
New
Bug description:
[Impact]
After including the patch from bug 1642903, NVMe devices that include spaces
in their model or serial strings result in incorrect symlinks, e.g. if the
model string is "XYZ Corp NVMe drive" then instead of creating:
/dev/disk/by-id/nvme-XYZ Corp NVMe drive_SERIAL -> ../../nvme0n1
it creates:
/dev/disk/by-id/nvme-XYZ -> ../../nvme0n1
/dev/Corp -> nvme0n1
/dev/NVMe -> nvme0n1
/dev/drive_SERIAL -> nvme0n1
This is because of the way udev handles the SYMLINK value strings; by
default, it does not do any whitespace replacement. To enable
whitespace replacement of a symlink value, the rule must also include
OPTIONS+="string_escape=replace". This is done for 'md' and 'dm'
devices in their rules. However, there are no rules that actually
want to specify multiple symlinks, and defaulting to not replacing
whitespace makes no sense; instead, the default should be to replace
all whitespace in each symlink value, unless the rule explicitly
specifies OPTIONS+="string_escape=none".
[Test Case]
This assumes using udev with the patch from bug 1642903.
Without this patch, when using a NVMe drive that contains spaces in
its model and/or serial strings, check the /dev/disk/by-id/ directory.
It should contain a partially-correct symlink to the NVMe drive, with
the name up to the first space. All following space-separated parts
of the mode/serial string should have symlinks in the /dev/ directory.
This is the incorrect behavior.
With this patch, check the /dev/disk/by-id/ directory. It should
contain a fully-correct symlink to the NVMe drive, and no part of the
drive's model/serial number string should be a link in the /dev
directory.
An example of the correct/incorrect naming is in the Impact section.
There should be no other changes to any of the symlinks under /dev
before and after this patch. Typical locations for symlinks are
/dev/, /dev/disk/by-name/, /dev/disk/by-id/, /dev/disk/by-uuid/,
/dev/disk/by-label/
[Regression Potential]
Errors in udev rules can lead to an unbootable or otherwise completely
broken system if they unintentionally break or clobber existing
/dev/disks/ symlinks.
[Other Info]
This is also tracked with upstream systemd (udev) bug 4833:
https://github.com/systemd/systemd/issues/4833
Also note, this can be worked around in individual rules ONLY (i.e.
not fixed for all rules) by appending OPTIONS+="string_escape=replace"
to each of the NVMe rules with SYMLINK+="..." assignment, e.g.:
KERNEL=="nvme*[0-9]n*[0-9]", ENV{DEVTYPE}=="disk", ATTRS{model}=="?*",
ENV{ID_SERIAL_SHORT}=="?*",
ENV{ID_SERIAL}="$attr{model}_$env{ID_SERIAL_SHORT}", SYMLINK+="disk
/by-id/nvme-$env{ID_SERIAL}", OPTIONS+="string_escape=replace"
Related bugs:
* bug 1642903: introduce disk/by-id (model_serial) symlinks for NVMe drives
* bug 1651602: NVMe driver regression for non-smp/1-cpu systems
* bug 1649635: export nvme drive model/serial strings via sysfs (trusty)
To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/1647485/+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 1649453] Re: systemd starts postfix before resolver
@Scott: https://git.launchpad.net/postfix/commit/?h=stable/v3.1&id=1a190cf17cc02 looks rather complicated and also creates an unmanaged config file. Why not just always add those After= to the .service? If resolved is not enabled, then After=systemd-resolved is a no-op (it's only ordering, not a dependency -- that would be Requires= or Wants=). Also, not sure why you added network-online.target, but if you actually do want to wait for the network then you also need a corresponding Wants =network-online.target (see man systemd.special). ** No longer affects: systemd (Ubuntu) ** Tags added: resolved -- 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/1649453 Title: systemd starts postfix before resolver Status in postfix package in Ubuntu: Fix Committed Bug description: Postfix starts before systemd-resolved.service, resulting in postfix reporting that it can't find MX records for outgoing mail, as shown in the trace below: $ systemd-analyze critical-chain postfix.service systemd-resolved.service The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. postfix.service +1ms └─network.target @5.811s └─NetworkManager.service @5.690s +91ms └─dbus.service @5.627s └─basic.target @5.597s └─sockets.target @5.597s └─snapd.socket @5.597s +269us └─sysinit.target @5.596s └─systemd-timesyncd.service @5.420s +175ms └─systemd-tmpfiles-setup.service @5.408s +8ms └─local-fs.target @5.390s └─zfs-mount.service @3.879s +1.511s └─zfs-import-cache.service @2.539s +1.303s └─systemd-udev-settle.service @256ms +2.252s └─systemd-udev-trigger.service @208ms +47ms └─systemd-udevd-control.socket @148ms └─-.mount @122ms └─system.slice @124ms └─-.slice @122ms systemd-resolved.service +268ms └─network.target @5.811s └─NetworkManager.service @5.690s +91ms └─dbus.service @5.627s └─basic.target @5.597s └─sockets.target @5.597s └─snapd.socket @5.597s +269us └─sysinit.target @5.596s └─systemd-timesyncd.service @5.420s +175ms └─systemd-tmpfiles-setup.service @5.408s +8ms └─local-fs.target @5.390s └─zfs-mount.service @3.879s +1.511s └─zfs-import-cache.service @2.539s +1.303s └─systemd-udev-settle.service @256ms +2.252s └─systemd-udev-trigger.service @208ms +47ms └─systemd-udevd-control.socket @148ms └─-.mount @122ms └─system.slice @124ms └─-.slice @122ms The postfix service needs to start after systemd-resolved.service. $ lsb_release -rd Description: Ubuntu 16.10 Release: 16.10 $ apt-cache policy systemd systemd: Installed: 231-9ubuntu1 Candidate: 231-9ubuntu1 Version table: *** 231-9ubuntu1 500 500 http://mirror.aarnet.edu.au/pub/ubuntu/archive yakkety-updates/main amd64 Packages 100 /var/lib/dpkg/status 231-9git1 500 500 http://mirror.aarnet.edu.au/pub/ubuntu/archive yakkety/main amd64 Packages $ apt-cache policy postfix postfix: Installed: 3.1.0-5 Candidate: 3.1.0-5 Version table: *** 3.1.0-5 500 500 http://mirror.aarnet.edu.au/pub/ubuntu/archive yakkety/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1649453/+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 1644330] Re: resolved: correctly handle address families with /etc/hosts lookups
The fix landed in master: https://github.com/systemd/systemd/commit/4050e04b ** Changed in: systemd (Ubuntu) Status: In Progress => Fix Committed ** Changed in: systemd (Ubuntu) Milestone: ubuntu-16.12 => None -- 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/1644330 Title: resolved: correctly handle address families with /etc/hosts lookups Status in systemd: New Status in systemd package in Ubuntu: Fix Committed Bug description: I have an ipv4 entry for a key host on my network listed in /etc/hosts, for network recovery purposes. This host also has ipv6 connectivity; the ipv6 address is resolvable via DNS, but I do not have it in /etc/hosts. Resolution of hostname should be independent for each address family. Two days ago (I don't know what changed to trigger this), I stopped being able to resolve the ipv6 address for this host. I traced this down to systemd-resolved, returning a lookup failure for the nss request, because the ipv6 address is not listed in /etc/hosts. Removing resolve from /etc/nsswitch.conf restores the correct behavior. Removing the ipv4 entry for the host restores the correct behavior. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: systemd 231-9ubuntu1 ProcVersionSignature: Ubuntu 4.8.0-27.29-generic 4.8.1 Uname: Linux 4.8.0-27-generic x86_64 ApportVersion: 2.20.3-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Wed Nov 23 08:13:33 2016 InstallationDate: Installed on 2010-09-24 (2252 days ago) InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1) MachineType: LENOVO 2306CTO ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.8.0-27-generic.efi.signed root=/dev/mapper/hostname-root ro quiet splash vt.handoff=7 SourcePackage: systemd UpgradeStatus: Upgraded to yakkety on 2016-10-28 (25 days ago) dmi.bios.date: 10/25/2013 dmi.bios.vendor: LENOVO dmi.bios.version: G2ET97WW (2.57 ) dmi.board.asset.tag: Not Available dmi.board.name: 2306CTO dmi.board.vendor: LENOVO dmi.board.version: Not Defined dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvrG2ET97WW(2.57):bd10/25/2013:svnLENOVO:pn2306CTO:pvrThinkPadX230:rvnLENOVO:rn2306CTO:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 2306CTO dmi.product.version: ThinkPad X230 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1644330/+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
Re: [Touch-packages] [Bug 1642966] Re: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1
Till Kamppeter [2016-12-19 16:48 -]: > Then edit the file /lib/systemd/system/cups.path adding a line > "PartOf=cups.service" to the [Unit] section, so that the file looks like > this: > > -- > [Unit] > Description=CUPS Scheduler > PartOf=cups.service I suppose that cups.path is only for booting, i. e. you want to start cups.service on boot, not again on demand on a running system. Does it ever happen that cups.service terminates by itself due to inactivity? If not, this provides a good enough workaround for not stopping cups.path properly in the maintainer scripts. If yes, this appproach doesn't work. Note that you probably want to do the same for cups.socket, with the same reasoning as above. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1642966 Title: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1 Status in cups package in Ubuntu: Confirmed Status in init-system-helpers package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: This is in xenial-proposed, please block release to -updates accordingly :) ProblemType: Package DistroRelease: Ubuntu 16.04 Package: cups-daemon 2.1.3-4 ProcVersionSignature: Ubuntu 4.4.0-46.67-generic 4.4.24 Uname: Linux 4.4.0-46-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 CupsErrorLog: Date: Fri Nov 18 11:13:15 2016 ErrorMessage: subprocess new pre-removal script returned error exit status 1 InstallationDate: Installed on 2016-05-02 (200 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) Lpstat: device for mallards-officejet-pro-8600: dnssd://Officejet%20Pro%208600%20%5BD63461%5D._ipp._tcp.local/?uuid=1c852a4d-b800-1f08-abcd-d89d67d63461 MachineType: Dell Inc. XPS 15 9550 Papersize: a4 PpdFiles: mallards-officejet-pro-8600: HP Officejet Pro 8600, hpcups 3.16.3 ProcCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-46-generic.efi.signed root=UUID=3643ef37-7cee-41b3-9387-2faa819c44db ro quiet splash vt.handoff=7 RelatedPackageVersions: dpkg 1.18.4ubuntu1.1 apt 1.2.15 SourcePackage: cups Title: package cups-daemon 2.1.3-4 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/07/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 01.02.00 dmi.board.name: 0N7TVV dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 9 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr01.02.00:bd04/07/2016:svnDellInc.:pnXPS159550:pvr:rvnDellInc.:rn0N7TVV:rvrA00:cvnDellInc.:ct9:cvr: dmi.product.name: XPS 15 9550 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1642966/+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 1644330] Re: systemd-resolved assumes that /etc/hosts for one address family means it doesn't ask DNS for another
See the summary from https://github.com/systemd/systemd/pull/4808: I can't convince Lennart about falling back to DNS for IPv6 if hosts has an IPv4 entry -- if hosts has some answer, it should be considered authoritative, and we should not mix different sources for the same query. Often /etc/hosts gets used to blacklist ad/spam domains, and this behaviour would break that. However, the more serious case is that if you have some *.example.com in /etc/hosts and then query the MX, SOA, or other non-address record for example.com then that query also fails. That's the part that I'll fix and Lennart agrees with. ** Summary changed: - systemd-resolved assumes that /etc/hosts for one address family means it doesn't ask DNS for another + resolved: correctly handle address families with /etc/hosts lookups -- 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/1644330 Title: resolved: correctly handle address families with /etc/hosts lookups Status in systemd: New Status in systemd package in Ubuntu: In Progress Bug description: I have an ipv4 entry for a key host on my network listed in /etc/hosts, for network recovery purposes. This host also has ipv6 connectivity; the ipv6 address is resolvable via DNS, but I do not have it in /etc/hosts. Resolution of hostname should be independent for each address family. Two days ago (I don't know what changed to trigger this), I stopped being able to resolve the ipv6 address for this host. I traced this down to systemd-resolved, returning a lookup failure for the nss request, because the ipv6 address is not listed in /etc/hosts. Removing resolve from /etc/nsswitch.conf restores the correct behavior. Removing the ipv4 entry for the host restores the correct behavior. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: systemd 231-9ubuntu1 ProcVersionSignature: Ubuntu 4.8.0-27.29-generic 4.8.1 Uname: Linux 4.8.0-27-generic x86_64 ApportVersion: 2.20.3-0ubuntu8 Architecture: amd64 CurrentDesktop: Unity Date: Wed Nov 23 08:13:33 2016 InstallationDate: Installed on 2010-09-24 (2252 days ago) InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1) MachineType: LENOVO 2306CTO ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.8.0-27-generic.efi.signed root=/dev/mapper/hostname-root ro quiet splash vt.handoff=7 SourcePackage: systemd UpgradeStatus: Upgraded to yakkety on 2016-10-28 (25 days ago) dmi.bios.date: 10/25/2013 dmi.bios.vendor: LENOVO dmi.bios.version: G2ET97WW (2.57 ) dmi.board.asset.tag: Not Available dmi.board.name: 2306CTO dmi.board.vendor: LENOVO dmi.board.version: Not Defined dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Not Available dmi.modalias: dmi:bvnLENOVO:bvrG2ET97WW(2.57):bd10/25/2013:svnLENOVO:pn2306CTO:pvrThinkPadX230:rvnLENOVO:rn2306CTO:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable: dmi.product.name: 2306CTO dmi.product.version: ThinkPad X230 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1644330/+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 1648806] Re: Arbitrary code execution through crafted CrashDB or Package/Source fields in .crash files
@Benjamin: Argh, I had to uncommit/recommit these three as the CVE
numbers came in at the last minute, and apparently got the commit
messages the wrong way around (meh @ not having rebase in bzr..) I did
some surgery on the branch and the commit messages are correct now.
When I created the fixes I also verified that this was the only eval()
in the entire source, there is none left now.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1648806
Title:
Arbitrary code execution through crafted CrashDB or Package/Source
fields in .crash files
Status in Apport:
Fix Released
Status in apport package in Ubuntu:
Fix Released
Status in apport source package in Precise:
Fix Released
Status in apport source package in Trusty:
Fix Released
Status in apport source package in Xenial:
Fix Released
Status in apport source package in Yakkety:
Fix Released
Status in apport source package in Zesty:
Fix Released
Bug description:
Forwarding private (encrypted) mail from Donncha O'Cearbhaill
:
= 8< ==
Hi Martin,
I have been auditing the Apport software in my free time and
unfortunately I have found some serious security issues.
Untrusted files can be passed to apport-gtk as it is registered as the
default file handler for "text/x-apport" files. The mime-type includes
.crash files but also any unknown file type which begins with
"ProblemType: ". An attacker could social engineer a victim into opening
a malicious Apport crash file simply by clicking on it.
In apport/ui.py, Apport is reading the CrashDB field and then it then
evaluates the field as Python code if it begins with a "{". This is very
dangerous as it can allow remote attackers to execute arbitrary Python code.
The vulnerable code was introduce on 2012-08-22 in Apport revision
2464
(http://bazaar.launchpad.net/~apport-hackers/apport/trunk/files/2464).
This code was first included in release 2.6.1. All Ubuntu Desktop
versions after 12.05 (Precise) include this vulnerable code by default.
An easy fix would be to parse the value as JSON instead of eval()'ing
it.
There is also a path traversal issue where the Package or SourcePackage
fields are not sanitized before being used to build a path to the
package specific hook files in the /usr/share/apport/package-hooks/
directory.
By setting "Package: ../../../../proc/self/cwd/Downloads/rce-hook.py" a
remote attacker could exploit this bug to execute Python scripts that
have be placed in the user's Downloads directory.
Would you like to apply for a CVE for this issues or should I? I'd like
to see these issue fixed soon so that Ubuntu users can be kept safe. I'm
planning to publish a blog post about these issues but I'll wait until
patched version of Apport are available in the repositories.
Please let me know if you have any questions.
Kind Regards,
Donncha
= 8< ==
I just talked to Donna on Jabber, and he plans to disclose that in
around a week.
To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1648806/+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 1648806] Re: Arbitrary code execution through crafted CrashDB or Package/Source fields in .crash files
New upstream release with the fixes:
https://launchpad.net/apport/trunk/2.20.4
Note that Brian committed some changes to trunk in the last 1.5 hours,
so we had some mid-air collection. I force-pushed trunk and will put
back his commits on top.
** Changed in: apport
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1648806
Title:
Arbitrary code execution through crafted CrashDB or Package/Source
fields in .crash files
Status in Apport:
Fix Released
Status in apport package in Ubuntu:
Fix Committed
Status in apport source package in Precise:
Fix Released
Status in apport source package in Trusty:
Fix Released
Status in apport source package in Xenial:
Fix Released
Status in apport source package in Yakkety:
New
Status in apport source package in Zesty:
Fix Committed
Bug description:
Forwarding private (encrypted) mail from Donncha O'Cearbhaill
:
= 8< ==
Hi Martin,
I have been auditing the Apport software in my free time and
unfortunately I have found some serious security issues.
Untrusted files can be passed to apport-gtk as it is registered as the
default file handler for "text/x-apport" files. The mime-type includes
.crash files but also any unknown file type which begins with
"ProblemType: ". An attacker could social engineer a victim into opening
a malicious Apport crash file simply by clicking on it.
In apport/ui.py, Apport is reading the CrashDB field and then it then
evaluates the field as Python code if it begins with a "{". This is very
dangerous as it can allow remote attackers to execute arbitrary Python code.
The vulnerable code was introduce on 2012-08-22 in Apport revision
2464
(http://bazaar.launchpad.net/~apport-hackers/apport/trunk/files/2464).
This code was first included in release 2.6.1. All Ubuntu Desktop
versions after 12.05 (Precise) include this vulnerable code by default.
An easy fix would be to parse the value as JSON instead of eval()'ing
it.
There is also a path traversal issue where the Package or SourcePackage
fields are not sanitized before being used to build a path to the
package specific hook files in the /usr/share/apport/package-hooks/
directory.
By setting "Package: ../../../../proc/self/cwd/Downloads/rce-hook.py" a
remote attacker could exploit this bug to execute Python scripts that
have be placed in the user's Downloads directory.
Would you like to apply for a CVE for this issues or should I? I'd like
to see these issue fixed soon so that Ubuntu users can be kept safe. I'm
planning to publish a blog post about these issues but I'll wait until
patched version of Apport are available in the repositories.
Please let me know if you have any questions.
Kind Regards,
Donncha
= 8< ==
I just talked to Donna on Jabber, and he plans to disclose that in
around a week.
To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1648806/+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 1519499] Re: Shutdown failure: Assertion 'sd_id128_randomize(&id) >= 0' failed at ../src/core/dbus.c:657, function bus_on_connection(). Aborting.
This is likely fixed in current systemd versions already, but the recent commit https://github.com/systemd/systemd/commit/ad2706db7cce should fix the remaining traces of this. Current systemd package in https://launchpad.net/~pitti/+archive/ubuntu/systemd contains this patch, if you want to give it a try on Ubuntu 16.10. ** Changed in: systemd (Ubuntu) Status: Confirmed => Fix Committed -- 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/1519499 Title: Shutdown failure: Assertion 'sd_id128_randomize(&id) >= 0' failed at ../src/core/dbus.c:657, function bus_on_connection(). Aborting. Status in systemd package in Ubuntu: Fix Committed Bug description: This is a follow-up on this issue here: https://github.com/lxc/lxd/issues/1336 I cannot stop a LXD container gently and as it seems the issue lies within ubuntu/systemd which does not handle SIGPWR correctly. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1519499/+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 1641328] Re: Ordering of mdns4_minimal and resolve in /etc/nsswitch.conf causes mDNS lookups to fail
** Tags added: resolve -- 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/1641328 Title: Ordering of mdns4_minimal and resolve in /etc/nsswitch.conf causes mDNS lookups to fail Status in systemd package in Ubuntu: Confirmed Bug description: (See also libnss-resolve:amd64 231-9ubuntu1 amd64nss module to resolve names via systemd-resolved) # fresh install of yakkety mtearle@liberation:/etc$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.10 Release: 16.10 Codename: yakkety # package details mtearle@liberation:~$ apt-cache policy libnss-resolve libnss-resolve: Installed: 231-9ubuntu1 Candidate: 231-9ubuntu1 Version table: *** 231-9ubuntu1 500 500 http://mirror.rackspace.com/ubuntu yakkety-updates/main amd64 Packages 100 /var/lib/dpkg/status 231-9git1 500 500 http://mirror.rackspace.com/ubuntu yakkety/main amd64 Packages mtearle@liberation:~$ apt-cache policy systemd systemd: Installed: 231-9ubuntu1 Candidate: 231-9ubuntu1 Version table: *** 231-9ubuntu1 500 500 http://mirror.rackspace.com/ubuntu yakkety-updates/main amd64 Packages 100 /var/lib/dpkg/status 231-9git1 500 500 http://mirror.rackspace.com/ubuntu yakkety/main amd64 Packages # attempt to ping VM elsewhere on network with mDNS hostname mtearle@liberation:/etc$ ping bazzavan.local ping: bazzavan.local: Name or service not known # can find both ipv4 and ipv6 addresses for the host mtearle@liberation:/etc$ avahi-resolve-host-name bazzavan.local bazzavan.localfe80::a00:27ff:fea5:3f51 mtearle@liberation:/etc$ avahi-resolve-host-name -4 bazzavan.local bazzavan.local172.16.44.48 # can ping it mtearle@liberation:/etc$ ping -c 1 172.16.44.48 PING 172.16.44.48 (172.16.44.48) 56(84) bytes of data. 64 bytes from 172.16.44.48: icmp_seq=1 ttl=64 time=0.265 ms --- 172.16.44.48 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.265/0.265/0.265/0.000 ms # original ordering mtearle@liberation:/etc$ grep hosts /etc/nsswitch.conf hosts: files resolve [!UNAVAIL=return] mdns4_minimal [NOTFOUND=return] dns # go away and edit /etc/nsswitch.conf # change ordering of resolve and mdns4_minimal mtearle@liberation:/etc$ grep hosts /etc/nsswitch.conf hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns # check mdns lookups now work, and it now pings mtearle@liberation:/etc$ ping -c 1 bazzavan.local PING bazzavan.local (172.16.44.48) 56(84) bytes of data. 64 bytes from 172.16.44.48 (172.16.44.48): icmp_seq=1 ttl=64 time=0.161 ms --- bazzavan.local ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.161/0.161/0.161/0.000 ms # check libnss-resolve is still doing its thing mtearle@liberation:/etc$ ping -c 1 localhost.localdomain PING localhost.localdomain(localhost (::1%1)) 56 data bytes 64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.016 ms --- localhost.localdomain ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.016/0.016/0.016/0.000 ms To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1641328/+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
Re: [Touch-packages] [Bug 1636912] Re: systemd-networkd runs too late for cloud-init.service (net)
Ryan Harper [2016-12-06 12:54 -]: > The following change should go against systemd-networkd-wait- > online.service > > + # Ensure that DNS is working before reaching online target > + After=systemd-networkd-resolvconf-update.service For the record, this should be the other way around -- add Before=systemd-networkd-wait-online.service to s-n-resolvconf-update.service. The latter is a Debian downstream unit and thus avoids carrying a patch to an upstream unit that refers to a downstream one. -- 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/1636912 Title: systemd-networkd runs too late for cloud-init.service (net) Status in systemd: Fix Released Status in cloud-init package in Ubuntu: Triaged Status in resolvconf package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Confirmed Status in resolvconf source package in Xenial: In Progress Status in systemd source package in Xenial: Fix Committed Status in cloud-init source package in Yakkety: New Status in resolvconf source package in Yakkety: In Progress Status in systemd source package in Yakkety: Fix Committed Status in resolvconf package in Debian: New Bug description: Ubuntu Core 16 images using cloud-init fail to function when the DataSource is over the network (Like OpenStack) as networking is not yet available when cloud-init.service runs. cloud-init service unit deps look like this: [Unit] Description=Initial cloud-init job (metadata service crawler) DefaultDependencies=no Wants=cloud-init-local.service Wants=local-fs.target Wants=sshd-keygen.service Wants=sshd.service After=cloud-init-local.service After=networking.service Requires=networking.service Before=basic.target Before=dbus.socket Before=network-online.target Before=sshd-keygen.service Before=sshd.service Before=systemd-user-sessions.service Conflicts=shutdown.target Here's networkd unit deps: [Unit] Description=Network Service Documentation=man:systemd-networkd.service(8) ConditionCapability=CAP_NET_ADMIN DefaultDependencies=no # dbus.service can be dropped once on kdbus, and systemd-udevd.service can be # dropped once tuntap is moved to netlink After=systemd-udevd.service dbus.service network-pre.target systemd-sysusers.service systemd-sysctl.service Before=network.target multi-user.target shutdown.target Conflicts=shutdown.target Wants=network.target # On kdbus systems we pull in the busname explicitly, because it # carries policy that allows the daemon to acquire its name. Wants=org.freedesktop.network1.busname After=org.freedesktop.network1.busname And a critical-chain output: root@snap-test7:~# systemd-analyze critical-chain systemd-networkd Failed to get ID: Unit name systemd-networkd is not valid. The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. root@snap-test7:~# systemd-analyze critical-chain systemd-networkd.service The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. systemd-networkd.service +440ms └─dbus.service @11.461s └─basic.target @11.403s └─sockets.target @11.401s └─dbus.socket @11.398s └─cloud-init.service @10.127s +1.266s └─networking.service @9.305s +799ms └─network-pre.target @9.295s └─cloud-init-local.service @3.822s +5.469s └─local-fs.target @3.813s └─run-cgmanager-fs.mount @12.687s └─local-fs-pre.target @1.393s └─systemd-tmpfiles-setup-dev.service @1.116s +195ms └─kmod-static-nodes.service @887ms +193ms └─system.slice @783ms └─-.slice @721ms cloud-init would need networkd to run at or before 'networking.service' so it can raise networking to then find and use network-based datasources. # grep systemd /usr/share/snappy/dpkg.list ii libnss-resolve:amd64 229-4ubuntu11 amd64nss module to resolve names via systemd-resolved ii libpam-systemd:amd64 229-4ubuntu11 amd64system and service manager - PAM module ii libsystemd0:amd64 229-4ubuntu11 amd64systemd utility library ii systemd 229-4ubuntu11 amd64system and service manager ii systemd-sysv 229-4ubuntu11 amd64system and se
[Touch-packages] [Bug 1648068] Re: systemd-resolved.service hangs a long time on shutdown
Unfortunately resolvconf does not have a --no-scripts or similar option that would disable running the update.d/ hooks. One possible local workaround is to change /lib/systemd/system/systemd- resolved.service.d/resolvconf.conf from ExecStopPost=+/bin/sh -c '[ ! -e /run/resolvconf/enable-updates ] || /sbin/resolvconf -d systemd-resolved' to ExecStopPost+=/bin/rm -f /run/resolvconf/interface/systemd-resolved or to drop the line completely. This solves the hang on shutdown, but it does not drop 127.0.0.53 any more from /etc/resolv.conf if you manually stop systemd-resolved.service in a running system. This should actually happen the same way with dnsmasq or any other local DNS server -- if only that is in resolv.conf, then the Avahi hook script would run into this timeout on "host" as well, as the local name server is already gone. Our workaround for that in 16.04 was to never stop dnsmasq even when NetworkManager.service got stopped (via KillMode=process). However, when you do stop dnsmasq then you get similar hangs with trying to do DNS queries. At the moment, if you stop the local DNS server then there is nothing that would magically bring back the non-local DNS servers into resolv.conf (neither in zesty with resolved nor in 16.04 with dnsmasq), so you would run into timeouts either way. Thus I think just dropping the ExecStopPost= does not actually make things worse, but it fixes the hang on shutdown. -- 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/1648068 Title: systemd-resolved.service hangs a long time on shutdown Status in systemd package in Ubuntu: Fix Committed Bug description: On shutdown or "systemctl stop systemd-resolved" you get a long hang: ● systemd-resolved.service - Network Name Resolution CGroup: /system.slice/systemd-resolved.service └─control ├─15479 /bin/sh -c [ ! -e /run/resolvconf/enable-updates ] || /sbin/resolvconf -d systemd-resolved ├─15480 run-parts --arg=-d --arg=systemd-resolved /etc/resolvconf/update.d ├─15483 run-parts /etc/resolvconf/update-libc.d ├─15497 /bin/sh /usr/lib/avahi/avahi-daemon-check-dns.sh └─15509 host -t soa local. So that resolvconf hook tries to do name resolution which does not work any more at that time. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1648068/+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 1648068] Re: systemd-resolved.service hangs a long time on shutdown
https://anonscm.debian.org/cgit/pkg- systemd/systemd.git/commit/?id=dbda116b2 ** Changed in: systemd (Ubuntu) Status: Triaged => Fix Committed ** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Martin Pitt (pitti) -- 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/1648068 Title: systemd-resolved.service hangs a long time on shutdown Status in systemd package in Ubuntu: Fix Committed Bug description: On shutdown or "systemctl stop systemd-resolved" you get a long hang: ● systemd-resolved.service - Network Name Resolution CGroup: /system.slice/systemd-resolved.service └─control ├─15479 /bin/sh -c [ ! -e /run/resolvconf/enable-updates ] || /sbin/resolvconf -d systemd-resolved ├─15480 run-parts --arg=-d --arg=systemd-resolved /etc/resolvconf/update.d ├─15483 run-parts /etc/resolvconf/update-libc.d ├─15497 /bin/sh /usr/lib/avahi/avahi-daemon-check-dns.sh └─15509 host -t soa local. So that resolvconf hook tries to do name resolution which does not work any more at that time. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1648068/+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 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records
@Anders: ah, so you removed libnss-resolve, but manually enabled
systemd-resolved.service?
--
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/1647031
Title:
systemd-resolved’s 127.0.0.53 server does not follow CNAME records
Status in systemd:
New
Status in systemd package in Ubuntu:
Triaged
Bug description:
$ systemd-resolve www.freedesktop.org
www.freedesktop.org: 131.252.210.176
2610:10:20:722:a800:ff:feda:470f
(annarchy.freedesktop.org)
-- Information acquired via protocol DNS in 673.6ms.
-- Data is authenticated: no
$ ping www.freedesktop.org
ping: www.freedesktop.org: Name or service not known
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
$ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
;www.freedesktop.org. IN A
www.freedesktop.org. 7146IN CNAME annarchy.freedesktop.org.
$ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
;www.freedesktop.org. IN A
www.freedesktop.org. 14399 IN CNAME annarchy.freedesktop.org.
annarchy.freedesktop.org. 14399 IN A 131.252.210.176
I trust it needn’t be explained why this makes the internet almost
completely useless in zesty.
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647031/+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 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records
I confirm the fact that "dig @127.0.0.53 wiki.freedesktop.org" only
gives the CNAME response, not the resolution of
"annarchy.freedesktop.org." as well, which is sufficient to confirm the
fix.
But nevertheless, firefox, wget, ping etc. on wiki.freedesktop.org all
work fine, but these use NSS. Google Chrome also works fine (which uses
resolv.conf), so this appears to be more like an implementation detail
than a major user-visible bug to me? Can you confirm this, or am I
missing something?
** Changed in: systemd (Ubuntu)
Importance: Undecided => Low
** Changed in: systemd (Ubuntu)
Status: Confirmed => Triaged
--
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/1647031
Title:
systemd-resolved’s 127.0.0.53 server does not follow CNAME records
Status in systemd:
New
Status in systemd package in Ubuntu:
Triaged
Bug description:
$ systemd-resolve www.freedesktop.org
www.freedesktop.org: 131.252.210.176
2610:10:20:722:a800:ff:feda:470f
(annarchy.freedesktop.org)
-- Information acquired via protocol DNS in 673.6ms.
-- Data is authenticated: no
$ ping www.freedesktop.org
ping: www.freedesktop.org: Name or service not known
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
$ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
;www.freedesktop.org. IN A
www.freedesktop.org. 7146IN CNAME annarchy.freedesktop.org.
$ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
;www.freedesktop.org. IN A
www.freedesktop.org. 14399 IN CNAME annarchy.freedesktop.org.
annarchy.freedesktop.org. 14399 IN A 131.252.210.176
I trust it needn’t be explained why this makes the internet almost
completely useless in zesty.
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647031/+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 1517257] Re: apport-retrace should install and use gdb for target release
... and change the original patch to only install gdb into the sandbox if it matches the host architecture, as otherwise it'd be a waste. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1517257 Title: apport-retrace should install and use gdb for target release Status in Apport: Triaged Status in apport package in Ubuntu: Triaged Bug description: apport-retrace will use the version of gdb installed on the system performing the retrace. This can cause issues retracing crash reports from releases that have a newer toolchain revision than the system performing the retrace. Subsequently, it would be better if apport- retrace were to install gdb into the sandbox being used for retracing and used that version of gdb for analyzing the core dump. To manage notifications about this bug go to: https://bugs.launchpad.net/apport/+bug/1517257/+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
