[Touch-packages] [Bug 2061726] [NEW] rsyslog apparmor denial on reading /proc/sys/net/ipv6/conf/all/disable_ipv6

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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"

[Martin Pitt]

** 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

[Martin Pitt]

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 

[Touch-packages] [Bug 2056768] [NEW] apparmor="DENIED" operation="open" class="file" profile="rsyslogd" name="/run/systemd/sessions/"

[Martin Pitt]

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.

[Martin Pitt]

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.

[Martin Pitt]

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.

[Martin Pitt]

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 

[Touch-packages] [Bug 2037703] Re: dpkg-reconfigure openssh-server doesn't ask questions again

[Martin Pitt]

-- 
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

[Martin Pitt]

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: 

[Touch-packages] [Bug 2046158] Re: Updating wireguard-peer.allowed-ips gets wrong default netmask for IPv6 addresses

[Martin Pitt]

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

[Martin Pitt]

** 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 

[Touch-packages] [Bug 2046158] [NEW] Updating wireguard-peer.allowed-ips gets wrong default netmask for IPv6 addresses

[Martin Pitt]

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: 

[Touch-packages] [Bug 2040483] Re: AppArmor denies crun sending signals to containers (stop, kill)

[Martin Pitt]

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)

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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: 

[Touch-packages] [Bug 1982482] [NEW] SSH password login not attempted/denied

[Martin Pitt]

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 

[Touch-packages] [Bug 1966416] Re: pam_faillock does not actually deny login after given number of failures

[Martin Pitt]

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

[Martin Pitt]

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  

[Touch-packages] [Bug 1962035] Re: apparmor blocks VM installation when automatic UEFI firmware is set

[Martin Pitt]

/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 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

[Martin Pitt]

** 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

[Martin Pitt]

> 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.

  
  

[Touch-packages] [Bug 1945321] Re: umockdev 0.16.3-1 breaks autopkgtest of bolt

[Martin Pitt]

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

[Martin Pitt]

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 (bus, 0744);
  (

[Touch-packages] [Bug 1934995] Re: Broken on ppc64el (toolchain bug?)

[Martin Pitt]

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?)

[Martin Pitt]

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

[Martin Pitt]

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)

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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 

[Touch-packages] [Bug 1837233] [NEW] [bionic] Manual IPv6 routes are not set

[Martin Pitt]

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 

[Touch-packages] [Bug 1831296] Re: __main__.SeccompTest is failing on Ubuntu CI

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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: 

[Touch-packages] [Bug 1707898] Re: systemd translations are not synced with upstream

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

@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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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:

[Martin Pitt]

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:

[Martin Pitt]

** 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 

[Touch-packages] [Bug 1689820] Re: /usr/lib/packagekit/packagekitd:11:pkgCache::Iterator:AcqPackageKitStatus::updateStatus:AcqPackageKitStatus::Fail:pkgAcquire::Worker::RunMessages:pkgAcquire::Worker:

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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:

[Martin Pitt]

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:

[Martin Pitt]

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) () 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 

[Touch-packages] [Bug 1650827] Re: /usr/lib/dovecot/dovecot-lda: "Failed name lookup - disconnected path"

[Martin Pitt]

** 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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

@Scott:
https://git.launchpad.net/postfix/commit/?h=stable/v3.1=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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

@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

[Martin Pitt]

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() >= 0' failed at ../src/core/dbus.c:657, function bus_on_connection(). Aborting.

[Martin Pitt]

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() >= 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

[Martin Pitt]

** 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)

[Martin Pitt]

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 

[Touch-packages] [Bug 1648068] Re: systemd-resolved.service hangs a long time on shutdown

[Martin Pitt]

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

[Martin Pitt]

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

[Martin Pitt]

@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

[Martin Pitt]

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

[Martin Pitt]

... 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

[Touch-packages] [Bug 1517257] Re: apport-retrace should install and use gdb for target release

[Martin Pitt]

Idea from sprint discussion:

In apport:
 - Don't try to run gdb from the retracing target sandbox

 - Add --gdb-root  argument to apport-retrace that will set PATH,
LD_LIBRARY_PATH, and possibly some env var to specify the gdb plugin dir
to appropriate subdirs of . Calling "gdb" should then prefer
running gdb from that dir.

In the retracer deployment:
 - add --gdb-root on the sandbox with the same release but the host's native 
architecture
 - Ensure that gdb is installed in that

-- 
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