Re: [Sts-sponsors] easy bugs for seyeongkim to take

[Eric Desrochers]

I like "sts-sponsor-volunteer"

Mauricio, your concern about skill levels make a lot of sense.
Note to myself, don't pick tag name on Friday night without thinking too
much about it while watching Star Wars with the kids. ;)

Thought ?

Eric

On Mon, Mar 30, 2020 at 7:08 AM Mauricio Oliveira <
mauricio.olive...@canonical.com> wrote:

> I do like the tag idea too.
>
> However, I think we should not use wording associated with skill
> levels (no matter how great and cool padawan is :-) to avoid the
> impression a bug requires less skill from the assignee to handle it
> (even though it may be the case, technically.)
>
> If that makes sense, perhaps tags like "sts-sponsor-volunteer" or
> "sts-sponsor-help" indicate a more proactive attitude from the person
> willing to take it.
>
> Then a search link for the tag, with a banner like "We need you for
> SRUs!" (lol, just kidding) prompting people to volunteer for
> fixes/SRUs to help with their own review/sponsoring practice, would
> help! :-)
>
> cheers,
>
> On Fri, Mar 27, 2020 at 10:50 PM Eric Desrochers
>  wrote:
> >
> > I like the tag idea. What about "sts-sponsor-padawan" ?
> >
> > On Fri, Mar 27, 2020 at 5:19 PM Dan Streetman <
> dan.street...@canonical.com> wrote:
> >>
> >> going thru my old watched bugs, here are some bugs that should be easy
> >> to handle.  Maybe we should figure out a LP bug tag to use for bugs
> >> that we find that are good for potential sponsors, like seyeongkim, to
> >> take?
> >>
> >> https://bugs.launchpad.net/ubuntu/bionic/+source/nvme-cli/+bug/1800544
> >> -super easy bug
> >>
> >>
> https://bugs.launchpad.net/ubuntu/bionic/+source/python-etcd3gw/+bug/1820083
> >> -the actual patch is trivial, but this needs fixing in debian as well
> >> and setting up a reproducer to verify might be difficult.  This
> >> originally came from a case from Bloomberg, so setuid might be able to
> >> help with reproducer and/or verification.
> >>
> >>
> https://bugs.launchpad.net/ubuntu/xenial/+source/drbd-utils/+bug/1673255
> >> -i have not actually looked at this one in a long time, so i'm not
> >> sure if it is still needed, but should be easy enough to check if it's
> >> still needed, and if so then it should be easy to patch
> >>
> >> --
> >> Mailing list: https://launchpad.net/~sts-sponsors
> >> Post to : sts-sponsors@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~sts-sponsors
> >> More help   : https://help.launchpad.net/ListHelp
> >
> > --
> > Mailing list: https://launchpad.net/~sts-sponsors
> > Post to : sts-sponsors@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~sts-sponsors
> > More help   : https://help.launchpad.net/ListHelp
>
>
>
> --
> Mauricio Faria de Oliveira
>
-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1860813] Re: LXC container reports spike in swap occasionally

[Eric Desrochers]

** Also affects: lxcfs (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: lxcfs (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: lxcfs (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: lxcfs (Ubuntu Bionic)
 Assignee: (unassigned) => Kellen Renshaw (krenshaw)

** Changed in: lxcfs (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: lxcfs (Ubuntu Bionic)
   Status: New => In Progress

** Tags added: sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1860813

Title:
  LXC container reports spike in swap occasionally

Status in lxcfs package in Ubuntu:
  Fix Released
Status in lxcfs source package in Xenial:
  New
Status in lxcfs source package in Bionic:
  In Progress
Status in lxcfs source package in Eoan:
  New

Bug description:
  [Impact]

   * lxcfs provides a container-specific view of /proc/meminfo.
  Occasionally, with near zero or zero swap usage *and* swap accounting
  turned on (kernel parameter swapaccount=1), the container will report
  100% swap utilization.

   * This issue has been encountered and could result in unecessary
  alerts or potential automated attempts at remediating a non-existent
  "full swap" issue.

   * This fix changed the logic used for SwapFree when swap accounting
  is enabled to better handle situations where memswusage is less than
  memusage, caused by the fuzziness of the usage_in_bytes counters used
  as the source. Specifically, it added a check for memusage being
  larger than memswusage and if so, sets 0 as the value of swapusage.
  Otherwise the calculation (memswusage - memusage) remains the same.

  [Test Case]

   * Requires a Bionic (18.04) or Eoan (19.10) host with swap space.

   * Enable swap accounting with the "swapaccount=1" kernel parameter on
  the kernel command line. Edit /etc/default/grub, add "swapaccount=1"
  to the GRUB_CMDLINE_LINUX_DEFAULT="other parameters" line, then run
  "update-grub" and reboot to make the change active.

   * Ensure lxd is installed, "sudo apt install lxd"

   * Create a lxd/lxc container with "lxc launch ubuntu:X
  container_name" with X being either b[ionic] or e[oan].

   * Open two shells to the container with "lxc shell container_name"

   * In one of the shells, run: watch -n 0.1 "grep Swap /proc/meminfo"

   * In the other, run: while true; do free; done

   * You should see SwapFree intermittently drop to zero in the first
  terminal.

   * The fix results in small non-zero swap "usage" intermittently
  instead of intermittent SwapFree = 0.

  
  [Regression Potential] 

   * Low, as swap accounting must be enabled to encounter the bug and
  the fix.

   * Potential for unanticipated edge cases in the values of memusage
  and memswusage to cause incorrect swap reporting within the container,
  with swap accounting turned on.

   * Any tooling that expected, compensated, or relied on the behavior
  may no longer work as expected.

  [Other Info]
   
   * Cherrypick of a one line fix to address this specific situation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxcfs/+bug/1860813/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

Re: [Sts-sponsors] easy bugs for seyeongkim to take

[Eric Desrochers]

I like the tag idea. What about "sts-sponsor-padawan" ?

On Fri, Mar 27, 2020 at 5:19 PM Dan Streetman 
wrote:

> going thru my old watched bugs, here are some bugs that should be easy
> to handle.  Maybe we should figure out a LP bug tag to use for bugs
> that we find that are good for potential sponsors, like seyeongkim, to
> take?
>
> https://bugs.launchpad.net/ubuntu/bionic/+source/nvme-cli/+bug/1800544
> -super
> 
> easy bug
>
>
> https://bugs.launchpad.net/ubuntu/bionic/+source/python-etcd3gw/+bug/1820083
> -the
> 
> actual patch is trivial, but this needs fixing in debian as well
> and setting up a reproducer to verify might be difficult.  This
> originally came from a case from Bloomberg, so setuid might be able to
> help with reproducer and/or verification.
>
> https://bugs.launchpad.net/ubuntu/xenial/+source/drbd-utils/+bug/1673255
> -i
> 
> have not actually looked at this one in a long time, so i'm not
> sure if it is still needed, but should be easy enough to check if it's
> still needed, and if so then it should be easy to patch
>
> --
> Mailing list: https://launchpad.net/~sts-sponsors
> Post to : sts-sponsors@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~sts-sponsors
> More help   : https://help.launchpad.net/ListHelp
>
-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1867398] Re: [Regression] unsupported protocol scheme

[Eric Desrochers]

** Changed in: containerd (Ubuntu Bionic)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

** Changed in: containerd (Ubuntu Bionic)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1867398

Title:
  [Regression] unsupported protocol scheme

Status in containerd package in Ubuntu:
  Fix Released
Status in containerd source package in Bionic:
  Fix Committed
Status in containerd source package in Eoan:
  Fix Released
Status in containerd source package in Focal:
  Fix Released

Bug description:
  [Description]

  Kubernetes 1.16.17
  Containerd 1.3.3
  Ubuntu Bionic

  [Affected Releases]

   containerd | 1.3.3-0ubuntu1~18.04.1 | bionic-updates/universe  | source, 
amd64, arm64, armhf, i386, ppc64el, s390x
   containerd | 1.3.3-0ubuntu1~19.10.1 | eoan-updates/universe| source, 
amd64, arm64, armhf, i386, ppc64el, s390x
   containerd | 1.3.3-0ubuntu1 | focal| source, 
amd64, arm64, armhf, ppc64el, s390x

  [Impact]

  Reported upstream:
  https://github.com/containerd/containerd/issues/4108

  User Impact:

  Since the Ubuntu bionic-updates bump of the version 1.3.3 through [0] 
https://bugs.launchpad.net/ubuntu/+source/containerd/+bug/1854841
  a regression was introduced.

  The following endpoint description stopped working when scheduling
  pods with k8s 1.16-1.17 isn't longer working.

  
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."niedbalski-bastion.cloud.sts:5000"]
    endpoint = ["niedbalski-bastion.cloud.sts:5000"]

  As an example, creating a k8s pod defined as following:

  apiVersion: v1
  kind: Pod
  metadata:
    name: busybox
    namespace: default
  spec:
    containers:
  - name: busybox
    image: niedbalski-bastion.cloud.sts:5000/busybox:latest
    command:
  - sleep
  - "3600"
    imagePullSecrets:
  - name: regcred
    restartPolicy: Always

  Will fail in the current Bionic-updates version with the following
  error:

  " failed to do request: Head niedbalski-
  bastion.cloud.sts:///v2/busybox/manifests/latest: unsupported protocol
  scheme "niedbalski-bastion.cloud.sts"

  Normal Scheduled default-scheduler Successfully assigned default/busybox to 
juju-3a79d2-00268738-4
  Normal Pulling 8m39s (x4 over 10m) kubelet, juju-3a79d2-00268738-4 Pulling 
image "niedbalski-bastion.cloud.sts:5000/busybox:latest"
  Warning Failed 8m39s (x4 over 10m) kubelet, juju-3a79d2-00268738-4 Failed to 
pull image "niedbalski-bastion.cloud.sts:5000/busybox:latest": rpc error: code 
= Unknown desc = failed to pull and unpack image 
"niedbalski-bastion.cloud.sts:5000/busybox:latest": failed to resolve reference 
"niedbalski-bastion.cloud.sts:5000/busybox:latest": failed to do request: Head 
niedbalski-bastion.cloud.sts:///v2/busybox/manifests/latest: unsupported 
protocol scheme "niedbalski-bastion.cloud.sts"
  Warning Failed 8m39s (x4 over 10m) kubelet, juju-3a79d2-00268738-4 Error: 
ErrImagePull
  Warning Failed 8m27s (x6 over 10m) kubelet, juju-3a79d2-00268738-4 Error: 
ImagePullBackOff
  Normal BackOff 4m56s (x21 over 10m) kubelet, juju-3a79d2-00268738-4 Back-off 
pulling image "niedbalski-bastion.cloud.sts:5000/busybox:latest"

  [Test Case]

  1) Configure a private docker repository repository

  2)  Modify the containerd registry mirror config as follows:
  ** http://paste.ubuntu.com/p/yP63WMkVT6/

  3) Execute the following pod (http://paste.ubuntu.com/p/BVYQFMfCmk/)

  Status of the scheduled pod should be ImagePullBackOff
  and the before mentioned error should be raised.

  [Possible workaround and solution]

  As a workaround change the endpoint to support the scheme (https://)
  Provide a fallback mechanism for URL parsing validation to fallback to http 
or https.
  I suspect that this change introduced on 1.3.3 through
  0b29c9c) may be the offending commit.

  [Regression Potential]

  ** The change proposed on the SRU takes in consideration both cases
  1) a endpoint without a schema 2) a endpoint with a schema.

  1) worked in 1.2.6 as explained in the "Impact section" and stopped
  being supported with the current Bionic version 1.3.3, 2) Should work
  on both cases.

  In neither case this should break existing endpoint definitions
  now new deployments of containerd.

  [Other Info]

  ** This commit upstream
  
https://github.com/containerd/containerd/commit/a022c218194c05449ad69b69c48fc6cac9d6f0b3
  addresses the issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/containerd/+bug/1867398/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1868215] Re: SRU: [lxd] Drop db collection and introduce lxd.buginfo

[Eric Desrochers]

[FOCAL]

Note: lxd only available via SNAP.

# lsb_release -cs
focal

# snap list lxd
Name  Version  RevTracking  Publisher   Notes
lxd   3.0.411348  3.0/stable/…  canonical✓  -

# ls -altr /sos_commands/lxd/lxd.buginfo 
-rw-r--r-- 1 root root 22017 Mar 25 16:41 
/sos_commands/lxd/lxd.buginfo

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1868215

Title:
  SRU: [lxd] Drop db collection and introduce lxd.buginfo

Status in sosreport package in Ubuntu:
  Fix Released
Status in sosreport source package in Bionic:
  In Progress
Status in sosreport source package in Eoan:
  In Progress
Status in sosreport source package in Focal:
  Fix Released

Bug description:
  [Impact]

  sosreport doesn't have to collect everything related to lxd which is very 
huge and unhelpful that much.
  This commit make sosreport collect proper info as installation types.

  [Test Case]

  Scenario #1
  * Deploy a machine (Xenial) with lxd installed as a DEB package
  * Install sosreport
  * sudo sosreport -o lxd or/and sudo sosreport -a
  * Extract the archive in /tmp and go in path_to_sosreport/sos_commands/lxd
  The data collection should be the one in the else statement of the plugin.

  Scenario #2
  * Deploy a machine (Bionic and late) with lxd installed as a SNAP.
  * Install sosreport
  * sudo sosreport -o lxd or/and sudo sosreport -a
  * Extract the archive in /tmp and go in path_to_sosreport/sos_commands/lxd
  The data collection should be the one in the if statement of the plugin, only 
executing "lxd.buginfo" command only available in SNAP.

  Scenario #3:
  A quick script to run on a node to verify multiple different options (as a 
sanity check):

  https://raw.githubusercontent.com/sosreport/sos/master/tests/simple.sh

  sudo bash simple.sh /usr/bin/python3 /usr/bin/sosreport

  simple.sh is a quick port of the travis tests to bash, requires root.

  There is some work to incorporate this exact script into the sosreport
  package for autopkg testing, but meanwhile it can be run manually for
  verifications.

  [Regression]

  "lxd.buginfo" has the advantage of not needing updates whenever
  lxd upstream add a new feature or find something new that’s worth capturing 
since LXD is now only offered as a SNAP nowadays.

  The plugin will remain backward compatible with DEB and SNAP, until
  there is no supported lxd DEB package available.

  If a problem occurs it will only impact the lxd plugin, not the other
  plugins nor core functionnalities.

  If for some reasons a command can be executed (not found in versions
  installed or else). sosreport is fault tolerant, and will
  continue/skip the command that doesn't exist, fails, ...

  FWIW, the commit has been +1 by lxd upstream himself stgraber:
  https://github.com/sosreport/sos/pull/1982/

  [Others]

  upstream patch
  - 
https://github.com/sosreport/sos/pull/1982/commits/bdc5ffdf5b8376ab2014ec8fbd9a878cc9d0d264

  LXD upstream reference:
  
https://discuss.linuxcontainers.org/t/what-lxd-information-should-be-collected-by-sosreport

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1868215/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1868215] Re: SRU: [lxd] Drop db collection and introduce lxd.buginfo

[Eric Desrochers]

Pushed into focal along with LP: #1865212.

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1868215

Title:
  SRU: [lxd] Drop db collection and introduce lxd.buginfo

Status in sosreport package in Ubuntu:
  In Progress
Status in sosreport source package in Bionic:
  In Progress
Status in sosreport source package in Eoan:
  In Progress
Status in sosreport source package in Focal:
  In Progress

Bug description:
  [Impact]

  sosreport doesn't have to collect everything related to lxd which is very 
huge and unhelpful that much.
  This commit make sosreport collect proper info as installation types.

  [Test Case]

  Scenario #1
  * Deploy a machine (Xenial) with lxd installed as a DEB package
  * Install sosreport
  * sudo sosreport -o lxd or/and sudo sosreport -a
  * Extract the archive in /tmp and go in path_to_sosreport/sos_commands/lxd
  The data collection should be the one in the else statement of the plugin.

  Scenario #2
  * Deploy a machine (Bionic and late) with lxd installed as a SNAP.
  * Install sosreport
  * sudo sosreport -o lxd or/and sudo sosreport -a
  * Extract the archive in /tmp and go in path_to_sosreport/sos_commands/lxd
  The data collection should be the one in the if statement of the plugin, only 
executing "lxd.buginfo" command only available in SNAP.

  Scenario #3:
  A quick script to run on a node to verify multiple different options (as a 
sanity check):

  https://raw.githubusercontent.com/sosreport/sos/master/tests/simple.sh

  sudo bash simple.sh /usr/bin/python3 /usr/bin/sosreport

  simple.sh is a quick port of the travis tests to bash, requires root.

  There is some work to incorporate this exact script into the sosreport
  package for autopkg testing, but meanwhile it can be run manually for
  verifications.

  [Regression]

  "lxd.buginfo" has the advantage of not needing updates whenever
  lxd upstream add a new feature or find something new that’s worth capturing 
since LXD is now only offered as a SNAP nowadays.

  The plugin will remain backward compatible with DEB and SNAP, until
  there is no supported lxd DEB package available.

  If a problem occurs it will only impact the lxd plugin, not the other
  plugins nor core functionnalities.

  If for some reasons a command can be executed (not found in versions
  installed or else). sosreport is fault tolerant, and will
  continue/skip the command that doesn't exist, fails, ...

  FWIW, the commit has been +1 by lxd upstream himself stgraber:
  https://github.com/sosreport/sos/pull/1982/

  [Others]

  upstream patch
  - 
https://github.com/sosreport/sos/pull/1982/commits/bdc5ffdf5b8376ab2014ec8fbd9a878cc9d0d264

  LXD upstream reference:
  
https://discuss.linuxcontainers.org/t/what-lxd-information-should-be-collected-by-sosreport

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1868215/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1850205] Re: AttributeError: module 'apt_pkg' has no attribute 'rewrite_section'

[Eric Desrochers]

Sponsored in Eoan

Thanks Simon !

** Tags removed: sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1850205

Title:
  AttributeError: module 'apt_pkg' has no attribute 'rewrite_section'

Status in Landscape Client:
  Fix Committed
Status in landscape-client package in Ubuntu:
  Fix Released
Status in landscape-client source package in Eoan:
  In Progress
Status in landscape-client source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * Regression when applying a package profile through landscape on
 ubuntu-19.10. Process will stack-trace.
 
   * The issue is caused by removal of some obsolete methods from
 python-apt.

   * The backported patch replaces old rewrite_section() by 
 TagSection.write()

  [Test Case]

   * On ubuntu 19.10 (eoan) install landscape-client, run landscape-config,
 and create a package profile on the account.

   * check /var/log/landscape/package-changer.log for exceptions.

  [Regression Potential]

   * The change has already been published for ubuntu 20.04 and is
  verified.

   * Patched callsites are only used by package profiles, which would limit
 the effect of regressions.

   * One possible regression could be in encoding errors,
 as the new methods handle binary files directly instead of receiving
 strings. This would imply an issue with python-apt.

  [original description]
  There has been an API change in focal/eoan for python3-apt >= 1.9, and the 
package changer now raises exceptions:

  AttributeError: module 'apt_pkg' has no attribute 'rewrite_section'

To manage notifications about this bug go to:
https://bugs.launchpad.net/landscape-client/+bug/1850205/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1868215] Re: SRU: [lxd] Drop db collection and introduce lxd.buginfo

[Eric Desrochers]

** Description changed:

  [Impact]
  
  [Test Case]
  
  Scenario #1
  * Deploy a machine (Xenial) with lxd installed as a DEB package
  * Install sosreport
  * sudo sosreport -o lxd or/and sudo sosreport -a
  * Extract the archive in /tmp and go in path_to_sosreport/sos_commands/lxd
  The data collection should be the one in the else statement of the plugin.
  
- 
  Scenario #2
  * Deploy a machine (Bionic and late) with lxd installed as a SNAP.
  * Install sosreport
  * sudo sosreport -o lxd or/and sudo sosreport -a
  * Extract the archive in /tmp and go in path_to_sosreport/sos_commands/lxd
  The data collection should be the one in the if statement of the plugin, only 
executing "lxd.buginfo" command only available in SNAP.
-  
+ 
  Scenario #3:
- A quick script to run on a node to verify multiple different options:
+ A quick script to run on a node to verify multiple different options (as a 
sanity check):
+ 
  https://raw.githubusercontent.com/sosreport/sos/master/tests/simple.sh
  
  sudo bash simple.sh /usr/bin/python3 /usr/bin/sosreport
  
  simple.sh is a quick port of the travis tests to bash, requires root.
  
  There is some work to incorporate this exact script into the sosreport
  package for autopkg testing, but meanwhile it can be run manually for
  verifications.
  
  [Regression]
  
  "lxd.buginfo" has the advantage of not needing updates whenever
  lxd upstream add a new feature or find something new that’s worth capturing 
since LXD is now only offered as a SNAP nowadays.
  
  The plugin will remain backward compatible with DEB and SNAP, until
  there is no supported lxd DEB package available.
  
- The commit has been +1 by lxd upstream stgraber, FWIW: 
+ The commit has been +1 by lxd upstream stgraber, FWIW:
  https://github.com/sosreport/sos/pull/1982/
  
  [Others]
  
  upstream patch
  - 
https://github.com/sosreport/sos/pull/1982/commits/bdc5ffdf5b8376ab2014ec8fbd9a878cc9d0d264
  
  LXD upstream reference:
  
https://discuss.linuxcontainers.org/t/what-lxd-information-should-be-collected-by-sosreport

** Description changed:

  [Impact]
  
  [Test Case]
  
  Scenario #1
  * Deploy a machine (Xenial) with lxd installed as a DEB package
  * Install sosreport
  * sudo sosreport -o lxd or/and sudo sosreport -a
  * Extract the archive in /tmp and go in path_to_sosreport/sos_commands/lxd
  The data collection should be the one in the else statement of the plugin.
  
  Scenario #2
  * Deploy a machine (Bionic and late) with lxd installed as a SNAP.
  * Install sosreport
  * sudo sosreport -o lxd or/and sudo sosreport -a
  * Extract the archive in /tmp and go in path_to_sosreport/sos_commands/lxd
  The data collection should be the one in the if statement of the plugin, only 
executing "lxd.buginfo" command only available in SNAP.
  
  Scenario #3:
  A quick script to run on a node to verify multiple different options (as a 
sanity check):
  
  https://raw.githubusercontent.com/sosreport/sos/master/tests/simple.sh
  
  sudo bash simple.sh /usr/bin/python3 /usr/bin/sosreport
  
  simple.sh is a quick port of the travis tests to bash, requires root.
  
  There is some work to incorporate this exact script into the sosreport
  package for autopkg testing, but meanwhile it can be run manually for
  verifications.
  
  [Regression]
  
  "lxd.buginfo" has the advantage of not needing updates whenever
  lxd upstream add a new feature or find something new that’s worth capturing 
since LXD is now only offered as a SNAP nowadays.
  
  The plugin will remain backward compatible with DEB and SNAP, until
  there is no supported lxd DEB package available.
  
- The commit has been +1 by lxd upstream stgraber, FWIW:
+ If a problem occurs it will only impact the lxd plugin, not the other
+ plugins nor core functionnalities.
+ 
+ If for some reasons a command can be executed (not found in versions
+ installed or else). sosreport is fault tolerant, and will continue/skip
+ the command that doesn't exist, fails, ...
+ 
+ FWIW, the commit has been +1 by lxd upstream himself stgraber:
  https://github.com/sosreport/sos/pull/1982/
  
  [Others]
  
  upstream patch
  - 
https://github.com/sosreport/sos/pull/1982/commits/bdc5ffdf5b8376ab2014ec8fbd9a878cc9d0d264
  
  LXD upstream reference:
  
https://discuss.linuxcontainers.org/t/what-lxd-information-should-be-collected-by-sosreport

** Tags added: sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1868215

Title:
  SRU: [lxd] Drop db collection and introduce lxd.buginfo

Status in sosreport package in Ubuntu:
  In Progress
Status in sosreport source package in Bionic:
  In Progress
Status in sosreport source package in Eoan:
  In Progress
Status in sosreport source package in Focal:
  In Progress

Bug description:
  [Impact]

  [Test Case]

  Scenario #1
  * Deploy a machine (Xenial) with lxd installed as a DEB package
  * Install sosreport
 

[Sts-sponsors] [Bug 1850205] Re: AttributeError: module 'apt_pkg' has no attribute 'rewrite_section'

[Eric Desrochers]

** Changed in: landscape-client (Ubuntu Eoan)
   Status: New => In Progress

** Changed in: landscape-client (Ubuntu Eoan)
 Assignee: (unassigned) => Simon Poirier (simpoir)

** Changed in: landscape-client (Ubuntu Eoan)
   Importance: Undecided => Medium

** Tags added: sts

** Tags added: sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1850205

Title:
  AttributeError: module 'apt_pkg' has no attribute 'rewrite_section'

Status in Landscape Client:
  Fix Committed
Status in landscape-client package in Ubuntu:
  Fix Released
Status in landscape-client source package in Eoan:
  In Progress
Status in landscape-client source package in Focal:
  Fix Released

Bug description:
  [Impact]

   * Regression when applying a package profile through landscape on
 ubuntu-19.10. Process will stack-trace.
 
   * The issue is caused by removal of some obsolete methods from
 python-apt.

   * The backported patch replaces old rewrite_section() by 
 TagSection.write()

  [Test Case]

   * On ubuntu 19.10 (eoan) install landscape-client, run landscape-config,
 and create a package profile on the account.

   * check /var/log/landscape/package-changer.log for exceptions.

  [Regression Potential]

   * The change has already been published for ubuntu 20.04 and is
  verified.

   * Patched callsites are only used by package profiles, which would limit
 the effect of regressions.

   * One possible regression could be in encoding errors,
 as the new methods handle binary files directly instead of receiving
 strings. This would imply an issue with python-apt.

  [original description]
  There has been an API change in focal/eoan for python3-apt >= 1.9, and the 
package changer now raises exceptions:

  AttributeError: module 'apt_pkg' has no attribute 'rewrite_section'

To manage notifications about this bug go to:
https://bugs.launchpad.net/landscape-client/+bug/1850205/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1794478] Re: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it

[Eric Desrochers]

Sponsored by dgadomski. Unsubscribing sts-sponsor team.

Thanks for your contribution Seyeong.
Thanks for the sponsoring Dariusz.

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1794478

Title:
  Automatic ipv4 not assigned to bond interface is manual ipv6 is
  assigned to it

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  In Progress

Bug description:
  [Impact]

  In case creating bond interface, IPv4 address is not automatically
  assigned when IPv6 has manual setting.

  [Test Case]

  1. create 18.04.4 instance, network-manager version is 1.10.6-2ubuntu.1.2 as 
original description.
  2. ipv6 manual, ipv4 auto
  ##
  sudo nmcli con add type bond con-name bond0 ifname bond0 mode active-backup;
  sudo nmcli con mod bond0 bond.options "downdelay=0, fail_over_mac=none, 
miimon=100, mode=active-backup,num_grat_arp=0, primary_reselect=always, 
updelay=0";
  sudo nmcli con mod bond0 ipv6.method manual ipv6.addresses 
fe81::ff:fe97:a27f/64;
  sudo nmcli con mod bond0 ipv4.method auto;
  sudo nmcli con add type bond-slave ifname ens34 master bond0;
  sudo nmcli con add type bond-slave ifname ens35 master bond0;
  sudo nmcli con mod bond0 +bond.options mii=100

  sleep 5

  sudo nmcli con up bond-slave-ens34
  sudo nmcli con up bond-slave-ens35
  sudo nmcli con up bond0;

  sleep 5;
  sudo nmcli c s bond0
  ##
  3. ipv6 auto, ipv4 auto
  ##
  sudo nmcli con add type bond con-name bond0 ifname bond0 mode active-backup;
  sudo nmcli con mod bond0 bond.options "downdelay=0, fail_over_mac=none, 
miimon=100, mode=active-backup,num_grat_arp=0, primary_reselect=always, 
updelay=0";
  sudo nmcli con mod bond0 ipv6.method auto;
  sudo nmcli con mod bond0 ipv4.method auto;
  sudo nmcli con add type bond-slave ifname ens34 master bond0;
  sudo nmcli con add type bond-slave ifname ens35 master bond0;
  sudo nmcli con mod bond0 +bond.options mii=100

  sleep 5

  sudo nmcli con up bond-slave-ens34
  sudo nmcli con up bond-slave-ens35
  sudo nmcli con up bond0;

  sleep 5

  sudo nmcli c s bond0
  ##

  when run #3, it is working, but with #2, it is not working.

  [Potential Regression]

  Actually nothing special. fix just remove if statement. but it needs
  Network Manager restarted.

  [Other informations]

  After upstream fix, it is working fine with #2 and #3 above.

  * Upstream bug and fix:

  https://bugzilla.redhat.com/show_bug.cgi?id=1575944
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/f03ae35

  * Only affecting Bionic:

  $ git describe --contains f03ae35
  1.10.8~2

  $ rmadison network-manager
  ==> network-manager | 1.10.6-2ubuntu1.2   | bionic-updates
  network-manager | 1.20.4-2ubuntu2.2   | eoan-updates
  network-manager | 1.22.4-1ubuntu2 | focal

  [Original description]

  ---Problem Description---
  Bond interface with automatic ipv4 mode and manual ipv6 mode fails to get 
automatic ipv4 assigned from dhcp server.

  ---uname output---
  Linux NetworkTest 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 
2018 s390x s390x s390x GNU/Linux

  Machine Type = s390x

  ---Debugger---
  A debugger is not configured

  ---Steps to Reproduce---
   When user configures ipv4 as automatic and ipv6 as manual for bond interface 
automatic ipv4 is not getting assigned.
  Looks like dhcp client request for ipv4 is not done to dhcp server after 
maunal ipv6 is assigned quickly to bond interface

  This issue will not happen in below cases:
  1)with ipv4 automatic and ipv6 manual configuration for ethernet or vlan 
interface.
  2)with ipv4 automatic and ipv6 automatic configuration for bond interface
  3)with ipv4 automatic and ipv6 disabled configuration for bond interface

  Configuration:
  Bond interface, ipv4 automatic mode and ipv6 automatic mode

  root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond
  [connection]
  id=test_bond
  uuid=63e54542-5135-47ac-a954-b861c3937be2
  type=bond
  interface-name=test_bond
  permissions=
  timestamp=1537944121

  [ethernet]
  mac-address-blacklist=

  [bond]
  downdelay=0
  fail_over_mac=none
  miimon=100
  mode=active-backup
  num_grat_arp=0
  primary_reselect=always
  updelay=0

  [ipv4]
  dns-search=
  method=auto

  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  method=auto

  From /var/log/syslog, we can see ip got assigned:

  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPDISCOVER on test_bond to 
255.255.255.255 port 67 interval 3 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPREQUEST of 10.2.3.55 on 
test_bond to 255.255.255.255 port 67 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPOFFER of 10.2.3.55 

[Sts-sponsors] [Bug 1794478] Re: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it

[Eric Desrochers]

** Changed in: network-manager (Ubuntu Bionic)
   Status: Confirmed => In Progress

** Tags added: sts-sponsor-dgadomski

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1794478

Title:
  Automatic ipv4 not assigned to bond interface is manual ipv6 is
  assigned to it

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  In Progress

Bug description:
  [Impact]

  In case creating bond interface, IPv4 address is not automatically
  assigned when IPv6 has manual setting.

  [Test Case]

  1. create 18.04.4 instance, network-manager version is 1.10.6-2ubuntu.1.2 as 
original description.
  2. ipv6 manual, ipv4 auto
  ##
  sudo nmcli con add type bond con-name bond0 ifname bond0 mode active-backup;
  sudo nmcli con mod bond0 bond.options "downdelay=0, fail_over_mac=none, 
miimon=100, mode=active-backup,num_grat_arp=0, primary_reselect=always, 
updelay=0";
  sudo nmcli con mod bond0 ipv6.method manual ipv6.addresses 
fe81::ff:fe97:a27f/64;
  sudo nmcli con mod bond0 ipv4.method auto;
  sudo nmcli con add type bond-slave ifname ens34 master bond0;
  sudo nmcli con add type bond-slave ifname ens35 master bond0;
  sudo nmcli con mod bond0 +bond.options mii=100

  sleep 5

  sudo nmcli con up bond-slave-ens34
  sudo nmcli con up bond-slave-ens35
  sudo nmcli con up bond0;

  sleep 5;
  sudo nmcli c s bond0
  ##
  3. ipv6 auto, ipv4 auto
  ##
  sudo nmcli con add type bond con-name bond0 ifname bond0 mode active-backup;
  sudo nmcli con mod bond0 bond.options "downdelay=0, fail_over_mac=none, 
miimon=100, mode=active-backup,num_grat_arp=0, primary_reselect=always, 
updelay=0";
  sudo nmcli con mod bond0 ipv6.method auto;
  sudo nmcli con mod bond0 ipv4.method auto;
  sudo nmcli con add type bond-slave ifname ens34 master bond0;
  sudo nmcli con add type bond-slave ifname ens35 master bond0;
  sudo nmcli con mod bond0 +bond.options mii=100

  sleep 5

  sudo nmcli con up bond-slave-ens34
  sudo nmcli con up bond-slave-ens35
  sudo nmcli con up bond0;

  sleep 5

  sudo nmcli c s bond0
  ##

  when run #3, it is working, but with #2, it is not working.

  [Potential Regression]

  Actually nothing special. fix just remove if statement. but it needs
  Network Manager restarted.

  [Other informations]

  After upstream fix, it is working fine with #2 and #3 above.

  * Upstream bug and fix:

  https://bugzilla.redhat.com/show_bug.cgi?id=1575944
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/f03ae35

  * Only affecting Bionic:

  $ git describe --contains f03ae35
  1.10.8~2

  $ rmadison network-manager
  ==> network-manager | 1.10.6-2ubuntu1.2   | bionic-updates
  network-manager | 1.20.4-2ubuntu2.2   | eoan-updates
  network-manager | 1.22.4-1ubuntu2 | focal

  [Original description]

  ---Problem Description---
  Bond interface with automatic ipv4 mode and manual ipv6 mode fails to get 
automatic ipv4 assigned from dhcp server.

  ---uname output---
  Linux NetworkTest 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 
2018 s390x s390x s390x GNU/Linux

  Machine Type = s390x

  ---Debugger---
  A debugger is not configured

  ---Steps to Reproduce---
   When user configures ipv4 as automatic and ipv6 as manual for bond interface 
automatic ipv4 is not getting assigned.
  Looks like dhcp client request for ipv4 is not done to dhcp server after 
maunal ipv6 is assigned quickly to bond interface

  This issue will not happen in below cases:
  1)with ipv4 automatic and ipv6 manual configuration for ethernet or vlan 
interface.
  2)with ipv4 automatic and ipv6 automatic configuration for bond interface
  3)with ipv4 automatic and ipv6 disabled configuration for bond interface

  Configuration:
  Bond interface, ipv4 automatic mode and ipv6 automatic mode

  root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond
  [connection]
  id=test_bond
  uuid=63e54542-5135-47ac-a954-b861c3937be2
  type=bond
  interface-name=test_bond
  permissions=
  timestamp=1537944121

  [ethernet]
  mac-address-blacklist=

  [bond]
  downdelay=0
  fail_over_mac=none
  miimon=100
  mode=active-backup
  num_grat_arp=0
  primary_reselect=always
  updelay=0

  [ipv4]
  dns-search=
  method=auto

  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  method=auto

  From /var/log/syslog, we can see ip got assigned:

  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPDISCOVER on test_bond to 
255.255.255.255 port 67 interval 3 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPREQUEST of 10.2.3.55 on 
test_bond to 255.255.255.255 port 67 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPOFFER of 10.2.3.55 from 
10.2.3.1
  

[Sts-sponsors] [Bug 1862226] Re: /usr/sbin/sss_obfuscate fails to run: ImportError: No module named pysss

[Eric Desrochers]

** Description changed:

  [Impact]
  
  Current bionic d/control doesn't include "python3-sss" or "python-sss"
  as runtime dependency:
  
  Package: sssd-tools
  Architecture: any
  Depends:
   python,
   sssd-common (= ${binary:Version}),
   ${misc:Depends},
   ${shlibs:Depends}
  Description: System Security Services Daemon -- tools
   Provides a set of daemons to manage access to remote directories and
   authentication mechanisms. It provides an NSS and PAM interface toward
   the system and a pluggable backend system to connect to multiple different
   account sources. It is also the basis to provide client auditing and policy
   services for projects like FreeIPA.
  
  Current workaround:
  One can install the dependency by hand.
  
  [Test Case]
  
  # lsb_release -cs
  bionic
  
  # Install sssd-tools
  
  # sss_obfuscate
  Traceback (most recent call last):
    File "/usr/sbin/sss_obfuscate", line 8, in 
  import pysss
  ImportError: No module named pysss
  
  [Potential Regression]
  
- After adding the dependency, if one run let's say 'apt-get upgrade':
+ * After adding the dependency, if one run let's say 'apt-get upgrade':
  
  APT-GET(8) - upgrade:
  under no circumstances are currently installed packages removed, or packages 
not already installed retrieved and installed.
  
  Meaning that one who would go that route, may not be able to get the
  update and will continue to experience the problem (No module named
  pysss)
  
  APT-GET(8) - dist-upgrade:
  dist-upgrade in addition to performing the function of upgrade, also 
intelligently handles changing dependencies with new versions of packages
+ 
+ * Since sss_obfuscate never work out of the box (without one installing
+ the missing dependency manually) ... first I don't expect a significant
+ adoption/use of this binary ... but since we are 'enabling'
+ sss_obfuscate to finally work out of the box ... who knows what bugs can
+ be found in sss_obfuscate that we didn't know before because it was
+ simply not used.
+ 
+ Clearly autopkgtest doesn't test that functionnality, otherwsie it would
+ have caught this before. Some dogfooding testing of sss_obfuscate in
+ -proposed may be useful to catch potential bugs related to its
+ "enablement".
+ 
+ Worst worst case, sss_obfuscate won't work as it currently does anyway,
+ and so far it didn't seems to be a major problem in the sssd ubuntu
+ community.
+ 
+ SSS_OBFUSCATE(8):
+ sss_obfuscate converts a given password into human-unreadable format and 
places it into appropriate domain section of the SSSD config file.
  
  [Other Infos]
  
  * Debian upstream:
  
https://salsa.debian.org/sssd-team/sssd/commit/b41c0f81c6dcc672636220c46ed3d52f3b69ba7c
  
  * Debian Bug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905220
  
  Rmadison:
  => sssd-tools | 1.16.1-1ubuntu1.4  | bionic-updates
     sssd-tools | 2.2.0-4ubuntu1 | eoan
     sssd-tools | 2.2.2-1| focal
     sssd-tools | 2.2.2-1ubuntu1 | focal-proposed

** Description changed:

  [Impact]
  
  Current bionic d/control doesn't include "python3-sss" or "python-sss"
  as runtime dependency:
  
  Package: sssd-tools
  Architecture: any
  Depends:
   python,
   sssd-common (= ${binary:Version}),
   ${misc:Depends},
   ${shlibs:Depends}
  Description: System Security Services Daemon -- tools
   Provides a set of daemons to manage access to remote directories and
   authentication mechanisms. It provides an NSS and PAM interface toward
   the system and a pluggable backend system to connect to multiple different
   account sources. It is also the basis to provide client auditing and policy
   services for projects like FreeIPA.
  
  Current workaround:
  One can install the dependency by hand.
  
  [Test Case]
  
  # lsb_release -cs
  bionic
  
  # Install sssd-tools
  
  # sss_obfuscate
  Traceback (most recent call last):
    File "/usr/sbin/sss_obfuscate", line 8, in 
  import pysss
  ImportError: No module named pysss
  
  [Potential Regression]
  
  * After adding the dependency, if one run let's say 'apt-get upgrade':
  
  APT-GET(8) - upgrade:
  under no circumstances are currently installed packages removed, or packages 
not already installed retrieved and installed.
  
  Meaning that one who would go that route, may not be able to get the
  update and will continue to experience the problem (No module named
  pysss)
  
  APT-GET(8) - dist-upgrade:
  dist-upgrade in addition to performing the function of upgrade, also 
intelligently handles changing dependencies with new versions of packages
  
  * Since sss_obfuscate never work out of the box (without one installing
  the missing dependency manually) ... first I don't expect a significant
  adoption/use of this binary ... but since we are 'enabling'
  sss_obfuscate to finally work out of the box ... who knows what bugs can
  be found in sss_obfuscate that we didn't know before because it was
  simply not used.
  
  Clearly autopkgtest doesn't test that 

[Sts-sponsors] [Bug 1758529] Re: landscape-package-changer crashed with io.UnsupportedOperation in pulse(): fileno

[Eric Desrochers]

Sponsored for B/E

Thanks Simon !

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1758529

Title:
  landscape-package-changer crashed with io.UnsupportedOperation in
  pulse(): fileno

Status in Landscape Client:
  Fix Committed
Status in landscape-client package in Ubuntu:
  Fix Released
Status in python-apt package in Ubuntu:
  Invalid
Status in landscape-client source package in Bionic:
  In Progress
Status in python-apt source package in Bionic:
  Invalid
Status in landscape-client source package in Disco:
  Won't Fix
Status in python-apt source package in Disco:
  Invalid
Status in landscape-client source package in Eoan:
  In Progress
Status in python-apt source package in Eoan:
  Invalid

Bug description:
  [Impact]

   * landscape-package-changer will output stack traces when executed
 with python3. This adds noise in the logs and confuse apport into
 thinking there was a crash, even though the error does not affect
 functionality.

   * The activity log for package operations will also show errors.

   * The patch overrides python-apt reporting of progress, as
 landscape-package-changer is never executed from a terminal.

  [Test Case]

   * register landscape-client and wait for packages to be reported.

   * trigger a package installation from the landscape server.

   * check /var/log/landscape/manager.log for Package changer warnings

  [Regression Potential]

   * The change is trivially simple.

   * The changed code path is only used by python-apt progress reporting.
 Since landscape-package-changer does not rely on it and is able
 to continue, other errors would likely have the same fate: that is
 crashing the progress reporting thread and continuing.

  [Original Description]

  Crash in the background

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: landscape-client 18.01-0ubuntu2
  ProcVersionSignature: Ubuntu 4.15.0-12.13-generic 4.15.7
  Uname: Linux 4.15.0-12-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  Date: Sat Mar 24 07:05:34 2018
  ExecutablePath: /usr/bin/landscape-package-changer
  InstallationDate: Installed on 2015-07-04 (994 days ago)
  InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
  InterpreterPath: /usr/bin/python3.6
  ProcCmdline: /usr/bin/python3 /usr/bin/landscape-package-changer --quiet
  ProcEnviron:
   LANGUAGE=en_GB:en
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
  Python3Details: /usr/bin/python3.6, Python 3.6.5rc1, python3-minimal, 3.6.4-1
  PythonArgs: ['/usr/bin/landscape-package-changer', '--quiet']
  PythonDetails: /usr/bin/python2.7, Python 2.7.14+, python-minimal, 2.7.14-4
  SourcePackage: landscape-client
  Title: landscape-package-changer crashed with io.UnsupportedOperation in 
pulse(): fileno
  Traceback:
   Traceback (most recent call last):
     File "/usr/lib/python3/dist-packages/apt/progress/text.py", line 164, in 
pulse
   not os.isatty(self._file.fileno())):
   io.UnsupportedOperation: fileno
  UpgradeStatus: Upgraded to bionic on 2018-03-15 (8 days ago)
  UserGroups:

To manage notifications about this bug go to:
https://bugs.launchpad.net/landscape-client/+bug/1758529/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1862226] Re: /usr/sbin/sss_obfuscate fails to run: ImportError: No module named pysss

[Eric Desrochers]

Thanks Lukasz,

$ lsb_release -cs
bionic

$ apt-cache policy python-sss
python-sss:
  Installed: (none)
  Candidate: 1.16.1-1ubuntu1.4
  Version table:
 1.16.1-1ubuntu1.4 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1862226

Title:
  /usr/sbin/sss_obfuscate fails to run: ImportError: No module named
  pysss

Status in sssd package in Ubuntu:
  Fix Released
Status in sssd source package in Bionic:
  In Progress
Status in sssd source package in Eoan:
  Fix Released
Status in sssd package in Debian:
  Fix Released

Bug description:
  [Impact]

  Current bionic d/control doesn't include "python3-sss" or "python-sss"
  as runtime dependency:

  Package: sssd-tools
  Architecture: any
  Depends:
   python,
   sssd-common (= ${binary:Version}),
   ${misc:Depends},
   ${shlibs:Depends}
  Description: System Security Services Daemon -- tools
   Provides a set of daemons to manage access to remote directories and
   authentication mechanisms. It provides an NSS and PAM interface toward
   the system and a pluggable backend system to connect to multiple different
   account sources. It is also the basis to provide client auditing and policy
   services for projects like FreeIPA.

  Current workaround:
  One can install the dependency by hand.

  [Test Case]

  # lsb_release -cs
  bionic

  # Install sssd-tools

  # sss_obfuscate
  Traceback (most recent call last):
    File "/usr/sbin/sss_obfuscate", line 8, in 
  import pysss
  ImportError: No module named pysss

  [Potential Regression]

  After adding the dependency, if one run let's say 'apt-get upgrade':

  APT-GET(8) - upgrade:
  under no circumstances are currently installed packages removed, or packages 
not already installed retrieved and installed.

  Meaning that one who would go that route, may not be able to get the
  update and will continue to experience the problem (No module named
  pysss)

  APT-GET(8) - dist-upgrade:
  dist-upgrade in addition to performing the function of upgrade, also 
intelligently handles changing dependencies with new versions of packages

  [Other Infos]

  * Debian upstream:
  
https://salsa.debian.org/sssd-team/sssd/commit/b41c0f81c6dcc672636220c46ed3d52f3b69ba7c

  * Debian Bug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905220

  Rmadison:
  => sssd-tools | 1.16.1-1ubuntu1.4  | bionic-updates
     sssd-tools | 2.2.0-4ubuntu1 | eoan
     sssd-tools | 2.2.2-1| focal
     sssd-tools | 2.2.2-1ubuntu1 | focal-proposed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1862226/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1758529] Re: landscape-package-changer crashed with io.UnsupportedOperation in pulse(): fileno

[Eric Desrochers]

** Changed in: landscape-client (Ubuntu Disco)
   Status: Confirmed => Won't Fix

** Changed in: landscape-client (Ubuntu Eoan)
 Assignee: (unassigned) => Simon Poirier (simpoir)

** Changed in: landscape-client (Ubuntu Bionic)
 Assignee: (unassigned) => Simon Poirier (simpoir)

** Changed in: landscape-client (Ubuntu Bionic)
   Status: Confirmed => In Progress

** Changed in: landscape-client (Ubuntu Eoan)
   Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1758529

Title:
  landscape-package-changer crashed with io.UnsupportedOperation in
  pulse(): fileno

Status in Landscape Client:
  Fix Committed
Status in landscape-client package in Ubuntu:
  Fix Released
Status in python-apt package in Ubuntu:
  Invalid
Status in landscape-client source package in Bionic:
  In Progress
Status in python-apt source package in Bionic:
  Invalid
Status in landscape-client source package in Disco:
  Won't Fix
Status in python-apt source package in Disco:
  Invalid
Status in landscape-client source package in Eoan:
  In Progress
Status in python-apt source package in Eoan:
  Invalid

Bug description:
  [Impact]

   * landscape-package-changer will output stack traces when executed
 with python3. This adds noise in the logs and confuse apport into
 thinking there was a crash, even though the error does not affect
 functionality.

   * The activity log for package operations will also show errors.

   * The patch overrides python-apt reporting of progress, as
 landscape-package-changer is never executed from a terminal.

  [Test Case]

   * register landscape-client and wait for packages to be reported.

   * trigger a package installation from the landscape server.

   * check /var/log/landscape/manager.log for Package changer warnings

  [Regression Potential]

   * The change is trivially simple.

   * The changed code path is only used by python-apt progress reporting.
 Since landscape-package-changer does not rely on it and is able
 to continue, other errors would likely have the same fate: that is
 crashing the progress reporting thread and continuing.

  [Original Description]

  Crash in the background

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: landscape-client 18.01-0ubuntu2
  ProcVersionSignature: Ubuntu 4.15.0-12.13-generic 4.15.7
  Uname: Linux 4.15.0-12-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.8-0ubuntu10
  Architecture: amd64
  Date: Sat Mar 24 07:05:34 2018
  ExecutablePath: /usr/bin/landscape-package-changer
  InstallationDate: Installed on 2015-07-04 (994 days ago)
  InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422)
  InterpreterPath: /usr/bin/python3.6
  ProcCmdline: /usr/bin/python3 /usr/bin/landscape-package-changer --quiet
  ProcEnviron:
   LANGUAGE=en_GB:en
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
  Python3Details: /usr/bin/python3.6, Python 3.6.5rc1, python3-minimal, 3.6.4-1
  PythonArgs: ['/usr/bin/landscape-package-changer', '--quiet']
  PythonDetails: /usr/bin/python2.7, Python 2.7.14+, python-minimal, 2.7.14-4
  SourcePackage: landscape-client
  Title: landscape-package-changer crashed with io.UnsupportedOperation in 
pulse(): fileno
  Traceback:
   Traceback (most recent call last):
     File "/usr/lib/python3/dist-packages/apt/progress/text.py", line 164, in 
pulse
   not os.isatty(self._file.fileno())):
   io.UnsupportedOperation: fileno
  UpgradeStatus: Upgraded to bionic on 2018-03-15 (8 days ago)
  UserGroups:

To manage notifications about this bug go to:
https://bugs.launchpad.net/landscape-client/+bug/1758529/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1862846] Re: Crash and failure installing focal

[Eric Desrochers]

util-linux uploaded in focal.

Thanks Mauricio !

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1862846

Title:
  Crash and failure installing focal

Status in subiquity:
  New
Status in curtin package in Ubuntu:
  Fix Released
Status in util-linux package in Ubuntu:
  In Progress
Status in curtin source package in Eoan:
  Invalid
Status in util-linux source package in Eoan:
  In Progress
Status in curtin source package in Focal:
  Fix Released
Status in util-linux source package in Focal:
  In Progress
Status in util-linux package in Debian:
  New

Bug description:
  During an install of the daily live image for 20.04 Ubuntu Server, the
  installer first crashed and restarted itself, then failed to install
  the system.

  Attached are the logs left on the install USB key.

To manage notifications about this bug go to:
https://bugs.launchpad.net/subiquity/+bug/1862846/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1862226] Re: /usr/sbin/sss_obfuscate fails to run: ImportError: No module named pysss

[Eric Desrochers]

** Tags added: sts-sponsor-dgadomski

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1862226

Title:
  /usr/sbin/sss_obfuscate fails to run: ImportError: No module named
  pysss

Status in sssd package in Ubuntu:
  Fix Released
Status in sssd source package in Bionic:
  Confirmed
Status in sssd source package in Eoan:
  Fix Released
Status in sssd package in Debian:
  Fix Released

Bug description:
  [Impact]

  Current bionic d/control doesn't include "python3-sss" or "python-sss"
  as runtime dependency:

  Package: sssd-tools
  Architecture: any
  Depends:
   python,
   sssd-common (= ${binary:Version}),
   ${misc:Depends},
   ${shlibs:Depends}
  Description: System Security Services Daemon -- tools
   Provides a set of daemons to manage access to remote directories and
   authentication mechanisms. It provides an NSS and PAM interface toward
   the system and a pluggable backend system to connect to multiple different
   account sources. It is also the basis to provide client auditing and policy
   services for projects like FreeIPA.

  Current workaround:
  One can install the dependency by hand.

  [Test Case]

  # lsb_release -cs
  bionic

  # Install sssd-tools

  # sss_obfuscate
  Traceback (most recent call last):
    File "/usr/sbin/sss_obfuscate", line 8, in 
  import pysss
  ImportError: No module named pysss

  [Potential Regression]

  After adding the dependency, if one run let's say 'apt-get upgrade':

  APT-GET(8) - upgrade:
  under no circumstances are currently installed packages removed, or packages 
not already installed retrieved and installed.

  Meaning that one who would go that route, may not be able to get the
  update and will continue to experience the problem (No module named
  pysss)

  APT-GET(8) - dist-upgrade:
  dist-upgrade in addition to performing the function of upgrade, also 
intelligently handles changing dependencies with new versions of packages

  [Other Infos]

  * Debian upstream:
  
https://salsa.debian.org/sssd-team/sssd/commit/b41c0f81c6dcc672636220c46ed3d52f3b69ba7c

  * Debian Bug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905220

  Rmadison:
  => sssd-tools | 1.16.1-1ubuntu1.4  | bionic-updates
     sssd-tools | 2.2.0-4ubuntu1 | eoan
     sssd-tools | 2.2.2-1| focal
     sssd-tools | 2.2.2-1ubuntu1 | focal-proposed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1862226/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1843044] Re: firefox crashes on a FIPS enabled machine

[Eric Desrochers]

** Tags added: sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1843044

Title:
  firefox crashes on a FIPS enabled machine

Status in Mozilla Firefox:
  New
Status in firefox package in Ubuntu:
  Confirmed

Bug description:
  [IMPACT]
  firefox is not a FIPS certified library. firefox uses bundled nss and on a 
machine running FIPS enabled kernel, nss by default goes into FIPS mode if 
/proc/sys/crypto/fips_enabled=1. This is an untested configuration and since 
firefox with bundled nss is not a certified library we propose disabling 
reading the 'fips_enabled' flag and therefore switching the library 
automatically into FIPS mode. A FIPS customer reported firefox crash on a FIPS 
enabled system and strace showed it was repeatedly trying to read the 
fips_enabled flag from the bundled nss before crashing.

  The proposed patch disables reading the /proc/sys/crypto/fips_enabled
  flag. The users of the library however can force nss into FIPS mode
  via an environment variable. We plan to leave it as is so as not to
  regress existing users who may be using it.

  The issue impacts firefox versions in eoan, disco, bionic and xenial.

  lsb_release -rd
  Description:  Ubuntu Eoan Ermine (development branch)
  Release: 19.10

  Version: 2:3.45-1ubuntu1

  lsb_release -rd
  Description: Ubuntu Disco Dingo
  Release: 19.04

  Version: 2:3.42-1ubuntu2

  lsb_release -rd
  Description:  Ubuntu Bionic Beaver
  Release:  18.04

  Version: 2:3.35-2ubuntu2.3

  lsb_release -rd
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04

  Version: 2:3.28.4-0ubuntu0.16.04

  [FIX]
  This fix proposes to disable bundled nss in firefox reading 
proc/sys/crypto/fips_enabled. We only want fips certified modules reading this 
file and running in fips mode. firefox is not one of our fips certified 
modules, so should not be reading this along with our fips certified modules to 
determine whether to run in fips mode.

  Users who do want to run the library in FIPS mode can do so by using
  the environment variable "NSS_FIPS". We propose to leave it as is so
  as not to regress anyone using this. The user who is using this option
  should be doing so with the awareness.

  [TEST]
  Tested on a xenial and bionic desktop ISO running FIPS enabled kernel and in 
FIPS mode. With the patch fix no crashes were observed when launching firefox 
browser.
  Without the patch fix, firefox crashes.

  Tested on a xenial and bionic desktop ISO running non-FIPS generic
  kernel. With the patch fix, firefox worked as expected and no changes
  were observed.

  [REGRESSION POTENTIAL]
  The regression potential for this is small. A FIPS kernel is required to
  create /proc/sys/crypto/fips_enabled and it is not available in the standard 
Ubuntu archive. For users forcing FIPS through environment variable, nothing 
has changed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/1843044/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1858802] Re: libblkid: no bcache UUID due to ambivalent detection of bcache and xfs_external_log for regular xfs in bcache backing device

[Eric Desrochers]

Sponsored in focal.

* Fix approved upstream
* Bug reported and patch submitted to upstream Debian.
 
Please keep an eye on the excuses page for util-linux.

- Eric

** Tags removed: sts-sponsor-slashd-focal

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1858802

Title:
  libblkid: no bcache UUID due to ambivalent detection of bcache and
  xfs_external_log for regular xfs in bcache backing device

Status in util-linux package in Ubuntu:
  In Progress
Status in util-linux source package in Xenial:
  In Progress
Status in util-linux source package in Bionic:
  In Progress
Status in util-linux source package in Disco:
  In Progress
Status in util-linux source package in Eoan:
  In Progress
Status in util-linux source package in Focal:
  In Progress
Status in util-linux package in Debian:
  Unknown

Bug description:
  [Impact]

   * Users with an XFS filesystem on top of bcache
     (this is seen on some ceph, cloud deployments)
     might fail to reference the bcache device by
     UUID or other udev properties.

   * The journal of the regular XFS filesystem in
     the bcache device is incorrectly detected as
     an XFS external log; so two superblocks are
     detected (bcache and xfs_external_log).

   * Thus blkid fails with ambivalent superblocks
     detected then doesn't provide the usual udev
     properties (UUID, etc.)

   * The fix improves the probe function for XFS
     external log so it detects it's regular XFS
     and bails out.

  [Test Case]

   * See test steps detailed in comment #7 and later.
     - Create an XFS filesystem with the journal/log
   in the beginning of the bcache device (< 256K).
     - Stop the bcache device.
     - Run '$ blkid -o udev -p $BCACHE_BACKING_DEVICE'.

     $ sudo make-bcache -B $BACKING_DEV
     $ sudo mkfs.xfs -d agsize=16m -l agnum=0 -f $BCACHE_DEV
     $ echo 1 | sudo tee /sys/block/$(basename $BCACHE_DEV)/bcache/stop
     $ sudo blkid -o udev -p $BACKING_DEV

  [Regression Potential]

   * The patch only changes the detection function
     for XFS external log to be more general about
     the sector where the magic of regular XFS may
     be found (which is shifted inside the bcache.)

   * It still checks at sector zero (the only one
     checked previously), so this behavior didn't
     change.

   * Possible regressions are actual XFS external
     log devices that are not anymore detected as
     such. (Although that would probably indicate
     a different bug in libblkid.)

  [Other Info]
   * upstream commit:
     
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=d756af7d640c51ce8d1414607bd3f17eeecf2424

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1858802/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1858802] Re: libblkid: no bcache UUID due to ambivalent detection of bcache and xfs_external_log for regular xfs in bcache backing device

[Eric Desrochers]

** Tags added: sts-sponsor-slashd-focal

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1858802

Title:
  libblkid: no bcache UUID due to ambivalent detection of bcache and
  xfs_external_log for regular xfs in bcache backing device

Status in util-linux package in Ubuntu:
  In Progress
Status in util-linux source package in Xenial:
  In Progress
Status in util-linux source package in Bionic:
  In Progress
Status in util-linux source package in Disco:
  In Progress
Status in util-linux source package in Eoan:
  In Progress
Status in util-linux source package in Focal:
  In Progress
Status in util-linux package in Debian:
  Unknown

Bug description:
  [Impact]

   * Users with an XFS filesystem on top of bcache
     (this is seen on some ceph, cloud deployments)
     might fail to reference the bcache device by
     UUID or other udev properties.

   * The journal of the regular XFS filesystem in
     the bcache device is incorrectly detected as
     an XFS external log; so two superblocks are
     detected (bcache and xfs_external_log).

   * Thus blkid fails with ambivalent superblocks
     detected then doesn't provide the usual udev
     properties (UUID, etc.)

   * The fix improves the probe function for XFS
     external log so it detects it's regular XFS
     and bails out.

  [Test Case]

   * See test steps detailed in comment #7 and later.
     - Create an XFS filesystem with the journal/log
   in the beginning of the bcache device (< 256K).
     - Stop the bcache device.
     - Run '$ blkid -o udev -p $BCACHE_BACKING_DEVICE'.

     $ sudo make-bcache -B $BACKING_DEV
     $ sudo mkfs.xfs -d agsize=16m -l agnum=0 -f $BCACHE_DEV
     $ echo 1 | sudo tee /sys/block/$(basename $BCACHE_DEV)/bcache/stop
     $ sudo blkid -o udev -p $BACKING_DEV

  [Regression Potential]

   * The patch only changes the detection function
     for XFS external log to be more general about
     the sector where the magic of regular XFS may
     be found (which is shifted inside the bcache.)

   * It still checks at sector zero (the only one
     checked previously), so this behavior didn't
     change.

   * Possible regressions are actual XFS external
     log devices that are not anymore detected as
     such. (Although that would probably indicate
     a different bug in libblkid.)

  [Other Info]
   * upstream commit:
     
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=d756af7d640c51ce8d1414607bd3f17eeecf2424

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1858802/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1855756] Re: Update eoan with landscape-client 19.12

[Eric Desrochers]

A current landscape-client SRU (LP: #1855522) prevents me to upload
19.12 in the archive.

Let's circle back in Jan 2020 for the sponsoring of 19.12 lds-client.

- Eric

** Changed in: landscape-client (Ubuntu Eoan)
   Status: In Progress => Confirmed

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1855756

Title:
  Update eoan with landscape-client 19.12

Status in landscape-client package in Ubuntu:
  Fix Released
Status in landscape-client source package in Eoan:
  Confirmed

Bug description:
  [Impact]

  Reference:
  https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases

  This SRU is for the 19.12 release of landscape-client which includes:

   * Modernized packaging.
   * Added support for python-apt 1.9
   * Converted init script to systemd service.
   * Sysinfo: add support for multiple IPv6 addresses per interface. (LP: 
#829379)
   * Upstream version of previous SRU patches.

  [Test Case]

   * There is no specific test cases for this since it's an upstream release 
including all 
 previously patched bugfixes, along with with a few regression fixes due to 
new versions
 present in eoan.

   * The current unit test suite and system test suite now pass on eoan/focal.
 (e.g. https://travis-ci.org/CanonicalLtd/landscape-client/builds/620310386)

   * The updated packaging also adds build-time testing, which should help 
raise regressions faster
 in the future.

  [Regression Potential]

   * Most of the changes, apart from the ones listed above have been patched 
through SRU and are
 already proven. 
   
   * The init.d to systemd update is a potential regression point. In the event 
there were any
 issues with this change, the effect would be fairly apparent since 
landscape-client relies
 on it for startup. However, the new service configuration is much simpler 
than previously.

   * Another potential regression point is the update python-apt support. It 
changed package
 profiles enforcement. As the feature was completely broken, any regression 
would likely
 affect edge cases in package profiles which were not already covered by 
current test suites.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1855756/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1855756] Re: Update eoan with landscape-client 19.12

[Eric Desrochers]

** Changed in: landscape-client (Ubuntu Eoan)
   Status: New => In Progress

** Tags added: sts-sponsor-slashd

** Tags added: sts

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1855756

Title:
  Update eoan with landscape-client 19.12

Status in landscape-client package in Ubuntu:
  Fix Released
Status in landscape-client source package in Eoan:
  In Progress

Bug description:
  [Impact]

  Reference:
  https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases

  This SRU is for the 19.12 release of landscape-client which includes:

   * Modernized packaging.
   * Added support for python-apt 1.9
   * Converted init script to systemd service.
   * Sysinfo: add support for multiple IPv6 addresses per interface. (LP: 
#829379)
   * Upstream version of previous SRU patches.

  [Test Case]

   * There is no specific test cases for this since it's an upstream release 
including all 
 previously patched bugfixes, along with with a few regression fixes due to 
new versions
 present in eoan.

   * The current unit test suite and system test suite now pass on eoan/focal.
 (e.g. https://travis-ci.org/CanonicalLtd/landscape-client/builds/620310386)

   * The updated packaging also adds build-time testing, which should help 
raise regressions faster
 in the future.

  [Regression Potential]

   * Most of the changes, apart from the ones listed above have been patched 
through SRU and are
 already proven. 
   
   * The init.d to systemd update is a potential regression point. In the event 
there were any
 issues with this change, the effect would be fairly apparent since 
landscape-client relies
 on it for startup. However, the new service configuration is much simpler 
than previously.

   * Another potential regression point is the update python-apt support. It 
changed package
 profiles enforcement. As the feature was completely broken, any regression 
would likely
 affect edge cases in package profiles which were not already covered by 
current test suites.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1855756/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1580385] Re: /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures

[Eric Desrochers]

I also reported a LP bug about the lua-lpeg modernisation:

LP:
https://bugs.launchpad.net/debian/+source/lua-lpeg/+bug/1851854

Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944360

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1580385

Title:
  /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures

Status in lua-lpeg package in Ubuntu:
  Fix Released
Status in lua-lpeg source package in Xenial:
  In Progress
Status in lua-lpeg source package in Bionic:
  In Progress
Status in lua-lpeg source package in Disco:
  In Progress
Status in lua-lpeg source package in Eoan:
  In Progress
Status in lua-lpeg package in Debian:
  New

Bug description:
  [Impact]

  Under certain conditions, lpeg will crash while walking the pattern
  tree looking for TCapture nodes.

  [Test Case]

  The reproducer, taken from an upstream discussion (link in "Other
  info"), is:

  $ cat repro.lua
  #!/usr/bin/env lua
  lpeg = require "lpeg"

  p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
  p:match("xx")

  The program crashes due to a hascaptures() infinite recursion:

  $ ./repro.lua
  Segmentation fault (core dumped)

  (gdb) bt -25
  #523984 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523985 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523986 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523987 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523988 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523989 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523990 0x77a3815c in ?? () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523991 0x77a388e3 in compile () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523992 0x77a36fab in ?? () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523993 0xfd1e in ?? ()
  #523994 0x5556a5fc in ?? ()
  #523995 0x555600c8 in ?? ()
  #523996 0xf63f in ?? ()
  #523997 0x5556030f in ?? ()
  #523998 0xdc91 in lua_pcallk ()
  #523999 0xb896 in ?? ()
  #524000 0xc54b in ?? ()
  #524001 0xfd1e in ?? ()
  #524002 0x55560092 in ?? ()
  #524003 0xf63f in ?? ()
  #524004 0x5556030f in ?? ()
  #524005 0xdc91 in lua_pcallk ()
  #524006 0xb64b in ?? ()
  #524007 0x77c94bbb in __libc_start_main (main=0xb5f0, argc=2, 
argv=0x7fffe6d8, init=, fini=, 
rtld_fini=, stack_end=0x7fffe6c8)
  at ../csu/libc-start.c:308
  #524008 0xb70a in ?? ()

  The expected behavior is to have the program finish normally

  [Regression potential]

  Low, this is a backport from upstream and only limits the infinite recursion 
in a scenario where it shouldn't happen to begin with (TCapture node search).
  [Other info]

  This was fixed upstream in 1.0.1 by stopping the recursion in TCall
  nodes and controlling that TRule nodes do not follow siblings (sib2)

  The upstream discussion can be found here:
  http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-
  td7674831.html

  My analysis can be found here:
  http://pastebin.ubuntu.com/p/n4824ftZt9/plain/

  [Original description]

  The Ubuntu Error Tracker has been receiving reports about a problem
  regarding nmap.  This problem was most recently seen with version
  7.01-2ubuntu2, the problem page at
  https://errors.ubuntu.com/problem/5e852236a443bab0279d47c8a9b7e55802bfb46f
  contains more details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lua-lpeg/+bug/1580385/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1580385] Re: /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures

[Eric Desrochers]

[sts-sponsor]

Sponsored for E, D, B & X. Packages are now waiting in their respectives
upload queues for approval in order to start building in -proposed for
the testing phase of the SRU.

Thanks again Victor

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1580385

Title:
  /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures

Status in lua-lpeg package in Ubuntu:
  Fix Released
Status in lua-lpeg source package in Xenial:
  In Progress
Status in lua-lpeg source package in Bionic:
  In Progress
Status in lua-lpeg source package in Disco:
  In Progress
Status in lua-lpeg source package in Eoan:
  In Progress
Status in lua-lpeg package in Debian:
  New

Bug description:
  [Impact]

  Under certain conditions, lpeg will crash while walking the pattern
  tree looking for TCapture nodes.

  [Test Case]

  The reproducer, taken from an upstream discussion (link in "Other
  info"), is:

  $ cat repro.lua
  #!/usr/bin/env lua
  lpeg = require "lpeg"

  p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
  p:match("xx")

  The program crashes due to a hascaptures() infinite recursion:

  $ ./repro.lua
  Segmentation fault (core dumped)

  (gdb) bt -25
  #523984 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523985 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523986 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523987 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523988 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523989 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523990 0x77a3815c in ?? () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523991 0x77a388e3 in compile () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523992 0x77a36fab in ?? () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523993 0xfd1e in ?? ()
  #523994 0x5556a5fc in ?? ()
  #523995 0x555600c8 in ?? ()
  #523996 0xf63f in ?? ()
  #523997 0x5556030f in ?? ()
  #523998 0xdc91 in lua_pcallk ()
  #523999 0xb896 in ?? ()
  #524000 0xc54b in ?? ()
  #524001 0xfd1e in ?? ()
  #524002 0x55560092 in ?? ()
  #524003 0xf63f in ?? ()
  #524004 0x5556030f in ?? ()
  #524005 0xdc91 in lua_pcallk ()
  #524006 0xb64b in ?? ()
  #524007 0x77c94bbb in __libc_start_main (main=0xb5f0, argc=2, 
argv=0x7fffe6d8, init=, fini=, 
rtld_fini=, stack_end=0x7fffe6c8)
  at ../csu/libc-start.c:308
  #524008 0xb70a in ?? ()

  The expected behavior is to have the program finish normally

  [Regression potential]

  Low, this is a backport from upstream and only limits the infinite recursion 
in a scenario where it shouldn't happen to begin with (TCapture node search).
  [Other info]

  This was fixed upstream in 1.0.1 by stopping the recursion in TCall
  nodes and controlling that TRule nodes do not follow siblings (sib2)

  The upstream discussion can be found here:
  http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-
  td7674831.html

  My analysis can be found here:
  http://pastebin.ubuntu.com/p/n4824ftZt9/plain/

  [Original description]

  The Ubuntu Error Tracker has been receiving reports about a problem
  regarding nmap.  This problem was most recently seen with version
  7.01-2ubuntu2, the problem page at
  https://errors.ubuntu.com/problem/5e852236a443bab0279d47c8a9b7e55802bfb46f
  contains more details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lua-lpeg/+bug/1580385/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1580385] Re: /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures

[Eric Desrochers]

Another note on the focal package of lua-lpeg ... (and this also implies
to debian) the src package still uses v7 debhelper compat version which
is 11 years old and obviously deprecated nowadays.

I have reported a bug against lua-lpeg debian as follows:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944360

If no action from debian, I'll try to spend some time fixing it (if time
permit)

I deally, I would like to see lua-lpeg being modernize before we enter
the freeze schedule with a modern debhelper version and fixing any
relevant lintian report warning.

** Bug watch added: Debian Bug tracker #944360
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944360

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1580385

Title:
  /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures

Status in lua-lpeg package in Ubuntu:
  Fix Released
Status in lua-lpeg source package in Xenial:
  In Progress
Status in lua-lpeg source package in Bionic:
  In Progress
Status in lua-lpeg source package in Disco:
  In Progress
Status in lua-lpeg source package in Eoan:
  In Progress
Status in lua-lpeg package in Debian:
  New

Bug description:
  [Impact]

  Under certain conditions, lpeg will crash while walking the pattern
  tree looking for TCapture nodes.

  [Test Case]

  The reproducer, taken from an upstream discussion (link in "Other
  info"), is:

  $ cat repro.lua
  #!/usr/bin/env lua
  lpeg = require "lpeg"

  p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
  p:match("xx")

  The program crashes due to a hascaptures() infinite recursion:

  $ ./repro.lua
  Segmentation fault (core dumped)

  (gdb) bt -25
  #523984 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523985 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523986 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523987 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523988 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523989 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523990 0x77a3815c in ?? () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523991 0x77a388e3 in compile () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523992 0x77a36fab in ?? () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523993 0xfd1e in ?? ()
  #523994 0x5556a5fc in ?? ()
  #523995 0x555600c8 in ?? ()
  #523996 0xf63f in ?? ()
  #523997 0x5556030f in ?? ()
  #523998 0xdc91 in lua_pcallk ()
  #523999 0xb896 in ?? ()
  #524000 0xc54b in ?? ()
  #524001 0xfd1e in ?? ()
  #524002 0x55560092 in ?? ()
  #524003 0xf63f in ?? ()
  #524004 0x5556030f in ?? ()
  #524005 0xdc91 in lua_pcallk ()
  #524006 0xb64b in ?? ()
  #524007 0x77c94bbb in __libc_start_main (main=0xb5f0, argc=2, 
argv=0x7fffe6d8, init=, fini=, 
rtld_fini=, stack_end=0x7fffe6c8)
  at ../csu/libc-start.c:308
  #524008 0xb70a in ?? ()

  The expected behavior is to have the program finish normally

  [Regression potential]

  Low, this is a backport from upstream and only limits the infinite recursion 
in a scenario where it shouldn't happen to begin with (TCapture node search).
  [Other info]

  This was fixed upstream in 1.0.1 by stopping the recursion in TCall
  nodes and controlling that TRule nodes do not follow siblings (sib2)

  The upstream discussion can be found here:
  http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-
  td7674831.html

  My analysis can be found here:
  http://pastebin.ubuntu.com/p/n4824ftZt9/plain/

  [Original description]

  The Ubuntu Error Tracker has been receiving reports about a problem
  regarding nmap.  This problem was most recently seen with version
  7.01-2ubuntu2, the problem page at
  https://errors.ubuntu.com/problem/5e852236a443bab0279d47c8a9b7e55802bfb46f
  contains more details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lua-lpeg/+bug/1580385/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1580385] Re: /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures

[Eric Desrochers]

** Changed in: lua-lpeg (Ubuntu Eoan)
 Assignee: (unassigned) => Victor Tapia (vtapia)

** Changed in: lua-lpeg (Ubuntu Disco)
 Assignee: (unassigned) => Victor Tapia (vtapia)

** Changed in: lua-lpeg (Ubuntu Bionic)
 Assignee: (unassigned) => Victor Tapia (vtapia)

** Changed in: lua-lpeg (Ubuntu Xenial)
 Assignee: (unassigned) => Victor Tapia (vtapia)

** Changed in: lua-lpeg (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: lua-lpeg (Ubuntu Disco)
   Status: New => In Progress

** Changed in: lua-lpeg (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: lua-lpeg (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: lua-lpeg (Ubuntu Disco)
   Importance: Undecided => Medium

** Changed in: lua-lpeg (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: lua-lpeg (Ubuntu Eoan)
   Importance: Undecided => Medium

** Changed in: lua-lpeg (Ubuntu Eoan)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1580385

Title:
  /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures

Status in lua-lpeg package in Ubuntu:
  Fix Released
Status in lua-lpeg source package in Xenial:
  In Progress
Status in lua-lpeg source package in Bionic:
  In Progress
Status in lua-lpeg source package in Disco:
  In Progress
Status in lua-lpeg source package in Eoan:
  In Progress
Status in lua-lpeg package in Debian:
  New

Bug description:
  [Impact]

  Under certain conditions, lpeg will crash while walking the pattern
  tree looking for TCapture nodes.

  [Test Case]

  The reproducer, taken from an upstream discussion (link in "Other
  info"), is:

  $ cat repro.lua
  #!/usr/bin/env lua
  lpeg = require "lpeg"

  p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
  p:match("xx")

  The program crashes due to a hascaptures() infinite recursion:

  $ ./repro.lua
  Segmentation fault (core dumped)

  (gdb) bt -25
  #523984 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523985 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523986 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523987 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523988 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523989 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523990 0x77a3815c in ?? () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523991 0x77a388e3 in compile () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523992 0x77a36fab in ?? () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523993 0xfd1e in ?? ()
  #523994 0x5556a5fc in ?? ()
  #523995 0x555600c8 in ?? ()
  #523996 0xf63f in ?? ()
  #523997 0x5556030f in ?? ()
  #523998 0xdc91 in lua_pcallk ()
  #523999 0xb896 in ?? ()
  #524000 0xc54b in ?? ()
  #524001 0xfd1e in ?? ()
  #524002 0x55560092 in ?? ()
  #524003 0xf63f in ?? ()
  #524004 0x5556030f in ?? ()
  #524005 0xdc91 in lua_pcallk ()
  #524006 0xb64b in ?? ()
  #524007 0x77c94bbb in __libc_start_main (main=0xb5f0, argc=2, 
argv=0x7fffe6d8, init=, fini=, 
rtld_fini=, stack_end=0x7fffe6c8)
  at ../csu/libc-start.c:308
  #524008 0xb70a in ?? ()

  The expected behavior is to have the program finish normally

  [Regression potential]

  Low, this is a backport from upstream and only limits the infinite recursion 
in a scenario where it shouldn't happen to begin with (TCapture node search).
  [Other info]

  This was fixed upstream in 1.0.1 by stopping the recursion in TCall
  nodes and controlling that TRule nodes do not follow siblings (sib2)

  The upstream discussion can be found here:
  http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-
  td7674831.html

  My analysis can be found here:
  http://pastebin.ubuntu.com/p/n4824ftZt9/plain/

  [Original description]

  The Ubuntu Error Tracker has been receiving reports about a problem
  regarding nmap.  This problem was most recently seen with version
  7.01-2ubuntu2, the problem page at
  https://errors.ubuntu.com/problem/5e852236a443bab0279d47c8a9b7e55802bfb46f
  contains more details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lua-lpeg/+bug/1580385/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1580385] Re: /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures

[Eric Desrochers]

** Changed in: lua-lpeg (Ubuntu)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1580385

Title:
  /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures

Status in lua-lpeg package in Ubuntu:
  Fix Committed
Status in lua-lpeg source package in Xenial:
  New
Status in lua-lpeg source package in Bionic:
  New
Status in lua-lpeg source package in Disco:
  New
Status in lua-lpeg source package in Eoan:
  New
Status in lua-lpeg package in Debian:
  New

Bug description:
  [Impact]

  Under certain conditions, lpeg will crash while walking the pattern
  tree looking for TCapture nodes.

  [Test Case]

  The reproducer, taken from an upstream discussion (link in "Other
  info"), is:

  $ cat repro.lua
  #!/usr/bin/env lua
  lpeg = require "lpeg"

  p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
  p:match("xx")

  The program crashes due to a hascaptures() infinite recursion:

  $ ./repro.lua
  Segmentation fault (core dumped)

  (gdb) bt -25
  #523984 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523985 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523986 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523987 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523988 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523989 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523990 0x77a3815c in ?? () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523991 0x77a388e3 in compile () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523992 0x77a36fab in ?? () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523993 0xfd1e in ?? ()
  #523994 0x5556a5fc in ?? ()
  #523995 0x555600c8 in ?? ()
  #523996 0xf63f in ?? ()
  #523997 0x5556030f in ?? ()
  #523998 0xdc91 in lua_pcallk ()
  #523999 0xb896 in ?? ()
  #524000 0xc54b in ?? ()
  #524001 0xfd1e in ?? ()
  #524002 0x55560092 in ?? ()
  #524003 0xf63f in ?? ()
  #524004 0x5556030f in ?? ()
  #524005 0xdc91 in lua_pcallk ()
  #524006 0xb64b in ?? ()
  #524007 0x77c94bbb in __libc_start_main (main=0xb5f0, argc=2, 
argv=0x7fffe6d8, init=, fini=, 
rtld_fini=, stack_end=0x7fffe6c8)
  at ../csu/libc-start.c:308
  #524008 0xb70a in ?? ()

  The expected behavior is to have the program finish normally

  [Regression potential]

  Low, this is a backport from upstream and only limits the infinite recursion 
in a scenario where it shouldn't happen to begin with (TCapture node search).
  [Other info]

  This was fixed upstream in 1.0.1 by stopping the recursion in TCall
  nodes and controlling that TRule nodes do not follow siblings (sib2)

  The upstream discussion can be found here:
  http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-
  td7674831.html

  My analysis can be found here:
  http://pastebin.ubuntu.com/p/n4824ftZt9/plain/

  [Original description]

  The Ubuntu Error Tracker has been receiving reports about a problem
  regarding nmap.  This problem was most recently seen with version
  7.01-2ubuntu2, the problem page at
  https://errors.ubuntu.com/problem/5e852236a443bab0279d47c8a9b7e55802bfb46f
  contains more details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lua-lpeg/+bug/1580385/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1580385] Re: /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures

[Eric Desrochers]

[sts-sponsor]

Sponsored in focal.

# Nitpick:
I have appended the changelog to add the LP bug.

# Upstream project have no vcs, therefore no commit available. Upstream
just release tarballs.

# No merge/sync needed. Debian and Ubuntu package are already at same
version level.

# Since this is easy to reproduce using the given repro.lua program, I took 
some time to double-check before final upload:
---

-> With current pkg found in the archive
$ ./repro.lua 
Segmentation fault (core dumped)


-> With the just got sponsored pkg
$ ./repro.lua 
root@focal:/tmp# 

no segfault nor other error ^

# SRU note
As an fyi, for the continuity (SRU), since most versions are identical, please 
use the following approach:

From:
 
 lua-lpeg | 1.0.0-2  | bionic/universe  
 lua-lpeg | 1.0.0-2  | disco/universe   
 lua-lpeg | 1.0.0-2  | eoan
 lua-lpeg | 1.0.0-2  | focal

To :
 
 lua-lpeg | 1.0.0-2ubuntu0.18.04.1  | bionic/universe  
 lua-lpeg | 1.0.0-2ubuntu0.19.04.1  | disco/universe   
 lua-lpeg | 1.0.0-2ubuntu0.19.10.1  | eoan
 lua-lpeg | 1.0.0-2ubuntu1  | focal  


Thanks Victor for your contribution !

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1580385

Title:
  /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures

Status in lua-lpeg package in Ubuntu:
  In Progress
Status in lua-lpeg source package in Xenial:
  New
Status in lua-lpeg source package in Bionic:
  New
Status in lua-lpeg source package in Disco:
  New
Status in lua-lpeg source package in Eoan:
  New
Status in lua-lpeg package in Debian:
  New

Bug description:
  [Impact]

  Under certain conditions, lpeg will crash while walking the pattern
  tree looking for TCapture nodes.

  [Test Case]

  The reproducer, taken from an upstream discussion (link in "Other
  info"), is:

  $ cat repro.lua
  #!/usr/bin/env lua
  lpeg = require "lpeg"

  p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
  p:match("xx")

  The program crashes due to a hascaptures() infinite recursion:

  $ ./repro.lua
  Segmentation fault (core dumped)

  (gdb) bt -25
  #523984 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523985 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523986 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523987 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523988 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523989 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523990 0x77a3815c in ?? () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523991 0x77a388e3 in compile () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523992 0x77a36fab in ?? () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523993 0xfd1e in ?? ()
  #523994 0x5556a5fc in ?? ()
  #523995 0x555600c8 in ?? ()
  #523996 0xf63f in ?? ()
  #523997 0x5556030f in ?? ()
  #523998 0xdc91 in lua_pcallk ()
  #523999 0xb896 in ?? ()
  #524000 0xc54b in ?? ()
  #524001 0xfd1e in ?? ()
  #524002 0x55560092 in ?? ()
  #524003 0xf63f in ?? ()
  #524004 0x5556030f in ?? ()
  #524005 0xdc91 in lua_pcallk ()
  #524006 0xb64b in ?? ()
  #524007 0x77c94bbb in __libc_start_main (main=0xb5f0, argc=2, 
argv=0x7fffe6d8, init=, fini=, 
rtld_fini=, stack_end=0x7fffe6c8)
  at ../csu/libc-start.c:308
  #524008 0xb70a in ?? ()

  The expected behavior is to have the program finish normally

  [Regression potential]

  Low, this is a backport from upstream and only limits the infinite recursion 
in a scenario where it shouldn't happen to begin with (TCapture node search).
  [Other info]

  This was fixed upstream in 1.0.1 by stopping the recursion in TCall
  nodes and controlling that TRule nodes do not follow siblings (sib2)

  The upstream discussion can be found here:
  http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-
  td7674831.html

  My analysis can be found here:
  http://pastebin.ubuntu.com/p/n4824ftZt9/plain/

  [Original description]

  The Ubuntu Error Tracker has been receiving reports about a problem
  regarding nmap.  This problem was most recently seen with version
  7.01-2ubuntu2, the problem page at
  https://errors.ubuntu.com/problem/5e852236a443bab0279d47c8a9b7e55802bfb46f
  contains more details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lua-lpeg/+bug/1580385/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : 

[Sts-sponsors] [Bug 1580385] Re: /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures

[Eric Desrochers]

** Changed in: lua-lpeg (Ubuntu)
   Importance: Undecided => Critical

** Changed in: lua-lpeg (Ubuntu)
   Importance: Critical => Medium

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1580385

Title:
  /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures

Status in lua-lpeg package in Ubuntu:
  In Progress
Status in lua-lpeg source package in Xenial:
  New
Status in lua-lpeg source package in Bionic:
  New
Status in lua-lpeg source package in Disco:
  New
Status in lua-lpeg source package in Eoan:
  New
Status in lua-lpeg package in Debian:
  New

Bug description:
  [Impact]

  Under certain conditions, lpeg will crash while walking the pattern
  tree looking for TCapture nodes.

  [Test Case]

  The reproducer, taken from an upstream discussion (link in "Other
  info"), is:

  $ cat repro.lua
  #!/usr/bin/env lua
  lpeg = require "lpeg"

  p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
  p:match("xx")

  The program crashes due to a hascaptures() infinite recursion:

  $ ./repro.lua
  Segmentation fault (core dumped)

  (gdb) bt -25
  #523984 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523985 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523986 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523987 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523988 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523989 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523990 0x77a3815c in ?? () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523991 0x77a388e3 in compile () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523992 0x77a36fab in ?? () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523993 0xfd1e in ?? ()
  #523994 0x5556a5fc in ?? ()
  #523995 0x555600c8 in ?? ()
  #523996 0xf63f in ?? ()
  #523997 0x5556030f in ?? ()
  #523998 0xdc91 in lua_pcallk ()
  #523999 0xb896 in ?? ()
  #524000 0xc54b in ?? ()
  #524001 0xfd1e in ?? ()
  #524002 0x55560092 in ?? ()
  #524003 0xf63f in ?? ()
  #524004 0x5556030f in ?? ()
  #524005 0xdc91 in lua_pcallk ()
  #524006 0xb64b in ?? ()
  #524007 0x77c94bbb in __libc_start_main (main=0xb5f0, argc=2, 
argv=0x7fffe6d8, init=, fini=, 
rtld_fini=, stack_end=0x7fffe6c8)
  at ../csu/libc-start.c:308
  #524008 0xb70a in ?? ()

  The expected behavior is to have the program finish normally

  [Regression potential]

  Low, this is a backport from upstream and only limits the infinite recursion 
in a scenario where it shouldn't happen to begin with (TCapture node search).
  [Other info]

  This was fixed upstream in 1.0.1 by stopping the recursion in TCall
  nodes and controlling that TRule nodes do not follow siblings (sib2)

  The upstream discussion can be found here:
  http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-
  td7674831.html

  My analysis can be found here:
  http://pastebin.ubuntu.com/p/n4824ftZt9/plain/

  [Original description]

  The Ubuntu Error Tracker has been receiving reports about a problem
  regarding nmap.  This problem was most recently seen with version
  7.01-2ubuntu2, the problem page at
  https://errors.ubuntu.com/problem/5e852236a443bab0279d47c8a9b7e55802bfb46f
  contains more details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lua-lpeg/+bug/1580385/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1580385] Re: /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures

[Eric Desrochers]

** Changed in: lua-lpeg (Ubuntu)
 Assignee: (unassigned) => Victor Tapia (vtapia)

** Changed in: lua-lpeg (Ubuntu)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1580385

Title:
  /usr/bin/nmap:11:hascaptures:hascaptures:hascaptures:hascaptures:hascaptures

Status in lua-lpeg package in Ubuntu:
  In Progress
Status in lua-lpeg source package in Xenial:
  New
Status in lua-lpeg source package in Bionic:
  New
Status in lua-lpeg source package in Disco:
  New
Status in lua-lpeg source package in Eoan:
  New
Status in lua-lpeg package in Debian:
  Unknown

Bug description:
  [Impact]

  Under certain conditions, lpeg will crash while walking the pattern
  tree looking for TCapture nodes.

  [Test Case]

  The reproducer, taken from an upstream discussion (link in "Other
  info"), is:

  $ cat repro.lua
  #!/usr/bin/env lua
  lpeg = require "lpeg"

  p = lpeg.C(-lpeg.P{lpeg.P'x' * lpeg.V(1) + lpeg.P'y'})
  p:match("xx")

  The program crashes due to a hascaptures() infinite recursion:

  $ ./repro.lua
  Segmentation fault (core dumped)

  (gdb) bt -25
  #523984 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523985 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523986 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523987 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523988 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523989 0x77a3743c in hascaptures () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523990 0x77a3815c in ?? () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523991 0x77a388e3 in compile () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523992 0x77a36fab in ?? () from 
/usr/lib/x86_64-linux-gnu/lua/5.2/lpeg.so
  #523993 0xfd1e in ?? ()
  #523994 0x5556a5fc in ?? ()
  #523995 0x555600c8 in ?? ()
  #523996 0xf63f in ?? ()
  #523997 0x5556030f in ?? ()
  #523998 0xdc91 in lua_pcallk ()
  #523999 0xb896 in ?? ()
  #524000 0xc54b in ?? ()
  #524001 0xfd1e in ?? ()
  #524002 0x55560092 in ?? ()
  #524003 0xf63f in ?? ()
  #524004 0x5556030f in ?? ()
  #524005 0xdc91 in lua_pcallk ()
  #524006 0xb64b in ?? ()
  #524007 0x77c94bbb in __libc_start_main (main=0xb5f0, argc=2, 
argv=0x7fffe6d8, init=, fini=, 
rtld_fini=, stack_end=0x7fffe6c8)
  at ../csu/libc-start.c:308
  #524008 0xb70a in ?? ()

  The expected behavior is to have the program finish normally

  [Regression potential]

  Low, this is a backport from upstream and only limits the infinite recursion 
in a scenario where it shouldn't happen to begin with (TCapture node search).
  [Other info]

  This was fixed upstream in 1.0.1 by stopping the recursion in TCall
  nodes and controlling that TRule nodes do not follow siblings (sib2)

  The upstream discussion can be found here:
  http://lua.2524044.n2.nabble.com/LPeg-intermittent-stack-exhaustion-
  td7674831.html

  My analysis can be found here:
  http://pastebin.ubuntu.com/p/n4824ftZt9/plain/

  [Original description]

  The Ubuntu Error Tracker has been receiving reports about a problem
  regarding nmap.  This problem was most recently seen with version
  7.01-2ubuntu2, the problem page at
  https://errors.ubuntu.com/problem/5e852236a443bab0279d47c8a9b7e55802bfb46f
  contains more details.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lua-lpeg/+bug/1580385/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1840686] Re: Xenial images won't reboot if disk size is > 2TB when using GPT

[Eric Desrochers]

Sponsored for Xenial.

The package is now waiting for SRU approval in order to start building
in xenial-proposed for the testing phase of the SRU.

Thanks for your contribution Matthew !

** Tags removed: sts-sponsor sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1840686

Title:
  Xenial images won't reboot if disk size is > 2TB when using GPT

Status in cloud-init:
  Won't Fix
Status in grub package in Ubuntu:
  Fix Released
Status in grub source package in Xenial:
  In Progress

Bug description:
  [Impact]

  On Xenial images which use GPT instead of MBR to enable efi based
  booting, there is an issue where after booting an instance that has a
  disk size of 2049 GB or higher, we hang on the next subsequent boot
  (Logs indicate it hanging on "Booting Hard Disk 0").

  This is a problem in grub2 where the system would become unbootable
  after ext* online resize if no resize_inode was created at ext* format
  time.

  [Test Case]

  To reproduce:

  1) Create an image with a disk size of 3072 GB using a serial that has
  GPT:

  gcloud compute instances create test-3072-xenial --image daily-
  ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel
  --boot-disk-size 3072

  2) Reboot the instance

  The instance will hang on reboot and you cannot connect. If you go to
  GCP console and select Logs > Serial port 1 (console), you will see
  the boot process has stopped at "Booting Hard Disk 0".

  I have built a test package, which is available here:

  https://launchpad.net/~mruffell/+archive/ubuntu/lp1840686-test

  If you do step 1) but do not reboot, and instead add the PPA, install
  the new grub like so:

  1) gcloud compute instances create test-3072-xenial --image 
daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel 
--boot-disk-size 3072
  2) sudo add-apt-repository ppa:mruffell/lp1840686-test
  3) sudo apt-get update
  4) sudo apt remove grub-common grub-efi-amd64 grub-efi-amd64-bin 
grub-efi-amd64-signed grub-pc-bin grub2-common
  5) sudo apt install grub-common grub-efi-amd64 grub-efi-amd64-bin grub-pc-bin 
grub2-common
  6) sudo grub-install /dev/sda
  7) sudo reboot

  The instance will boot successfully and you will be able to connect.

  Note, we must use "daily-ubuntu-1604-xenial-v20190731" as the image,
  as it is enabled for GPT and efi. GCP was reverted back to MBR and
  bios booting because of this bug, so the latest images will not
  reproduce the problem.

  [Regression Potential]

  Grub is a core package and every care must be taken in order to not
  introduce any regressions.

  The commit is present in B, D, E and F, and is considered well tested
  and widely adopted by the community.

  The commit comes with its own testcase, to test the ext4_metabg fix.

  The changes are localised to ext* based filesystems, although since
  they are the most popular family of filesystems used by the community,
  this does not reduce risk of breakage by much.

  If a regression were to happen, a regression would have a large
  impact, and in the worst case, can lead to unbootable systems and data
  loss for users who are not technical enough to reinstall grub from a
  working package inside the broken system chroot.

  [Other Info]

  In comment #4, Sultan identifies the fix as:

  commit e20aa39ea4298011ba716087713cff26c6c52006
  Author: Vladimir Serbinenko 
  Date:   Mon Feb 16 20:53:26 2015 +0100
  Subject: ext2: Support META_BG.

  This commit is from upstream grub2, and can be found here:

  
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e20aa39ea4298011ba716087713cff26c6c52006

  Looking at when this was merged:

  $ git describe --contains e20aa39ea4298011ba716087713cff26c6c52006
  2.02-beta3~429

  This commit is present in B, D, E and F, leaving X as the only version
  needing an SRU.

  The commit cleanly cherry picks to X, because the delta from
  2.02~beta2-36ubuntu3.22 to 2.02-beta3~429 is small.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1840686/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1840686] Re: Xenial images won't reboot if disk size is > 2TB when using GPT

[Eric Desrochers]

** Tags added: sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1840686

Title:
  Xenial images won't reboot if disk size is > 2TB when using GPT

Status in cloud-init:
  Won't Fix
Status in grub package in Ubuntu:
  Fix Released
Status in grub source package in Xenial:
  In Progress

Bug description:
  [Impact]

  On Xenial images which use GPT instead of MBR to enable efi based
  booting, there is an issue where after booting an instance that has a
  disk size of 2049 GB or higher, we hang on the next subsequent boot
  (Logs indicate it hanging on "Booting Hard Disk 0").

  This is a problem in grub2 where the system would become unbootable
  after ext* online resize if no resize_inode was created at ext* format
  time.

  [Test Case]

  To reproduce:

  1) Create an image with a disk size of 3072 GB using a serial that has
  GPT:

  gcloud compute instances create test-3072-xenial --image daily-
  ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel
  --boot-disk-size 3072

  2) Reboot the instance

  The instance will hang on reboot and you cannot connect. If you go to
  GCP console and select Logs > Serial port 1 (console), you will see
  the boot process has stopped at "Booting Hard Disk 0".

  I have built a test package, which is available here:

  https://launchpad.net/~mruffell/+archive/ubuntu/lp1840686-test

  If you do step 1) but do not reboot, and instead add the PPA, install
  the new grub like so:

  1) gcloud compute instances create test-3072-xenial --image 
daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel 
--boot-disk-size 3072
  2) sudo add-apt-repository ppa:mruffell/lp1840686-test
  3) sudo apt-get update
  4) sudo apt remove grub-common grub-efi-amd64 grub-efi-amd64-bin 
grub-efi-amd64-signed grub-pc-bin grub2-common
  5) sudo apt install grub-common grub-efi-amd64 grub-efi-amd64-bin grub-pc-bin 
grub2-common
  6) sudo grub-install /dev/sda
  7) sudo reboot

  The instance will boot successfully and you will be able to connect.

  Note, we must use "daily-ubuntu-1604-xenial-v20190731" as the image,
  as it is enabled for GPT and efi. GCP was reverted back to MBR and
  bios booting because of this bug, so the latest images will not
  reproduce the problem.

  [Regression Potential]

  Grub is a core package and every care must be taken in order to not
  introduce any regressions.

  The commit is present in B, D, E and F, and is considered well tested
  and widely adopted by the community.

  The commit comes with its own testcase, to test the ext4_metabg fix.

  The changes are localised to ext* based filesystems, although since
  they are the most popular family of filesystems used by the community,
  this does not reduce risk of breakage by much.

  If a regression were to happen, a regression would have a large
  impact, and in the worst case, can lead to unbootable systems and data
  loss for users who are not technical enough to reinstall grub from a
  working package inside the broken system chroot.

  [Other Info]

  In comment #4, Sultan identifies the fix as:

  commit e20aa39ea4298011ba716087713cff26c6c52006
  Author: Vladimir Serbinenko 
  Date:   Mon Feb 16 20:53:26 2015 +0100
  Subject: ext2: Support META_BG.

  This commit is from upstream grub2, and can be found here:

  
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e20aa39ea4298011ba716087713cff26c6c52006

  Looking at when this was merged:

  $ git describe --contains e20aa39ea4298011ba716087713cff26c6c52006
  2.02-beta3~429

  This commit is present in B, D, E and F, leaving X as the only version
  needing an SRU.

  The commit cleanly cherry picks to X, because the delta from
  2.02~beta2-36ubuntu3.22 to 2.02-beta3~429 is small.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1840686/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1848828] Re: report packages from security pocket

[Eric Desrochers]

Simon and I are working on delivering a more recent lds-client codebase
(ofc including the code to fix this particular bug) and modernising the
actual src package (e.g. compat v7 to v12) for focal.

Once everything is found in focal-release, we will SRU PR#57 and PR#70
into stable releases.

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1848828

Title:
  report packages from security pocket

Status in landscape-client package in Ubuntu:
  In Progress
Status in landscape-client source package in Xenial:
  In Progress
Status in landscape-client source package in Bionic:
  In Progress
Status in landscape-client source package in Disco:
  In Progress
Status in landscape-client source package in Eoan:
  In Progress
Status in landscape-client source package in Focal:
  In Progress

Bug description:
  [Impact]

  I report this bug to add the necessary bit into lds-client for all
  affected/supported releases.

  [Test Case]

  * One must use Landscape server on-prem (version >=19.01) or hosted which 
already contain the necessary server side change.
  * Install landscape-client.
  * Successfully register a client against Landscape server.
  * Security updates will only rely on USN notices and could possibly ignore 
other packages found in -security pocket even if they are there simply by the 
fact that there was no USN notice specific for them.

  (e.g. systemd has an USN, systemd get updated but its derived systemd
  binary packages aren't updated)

  [Regression Potential]

  * The patch flags potential security updates by matching the pocket name. The 
server then does additional package selection from that info. If the pocket 
matching were to break, security updates would continue as it was previously.
  * False positive matching could be possible, assuming one builds a mirror 
which mimics security pockets and contains normal updates. In that case, 
landscape could mistakenly update as if they were security updates.
  * Landscape may apply security updates without USN data, if the update comes 
from a security pocket. Since this matches the behaviour of unattended-upgrades 
and MOTD info, this may be closer to what users expect, even though this is a 
change of behaviour.

  [Other Info]

  * Upstream details:
  
https://github.com/CanonicalLtd/landscape-client/commit/93a3b47965da199785e9b3d226cb61f721e54196
  https://github.com/CanonicalLtd/landscape-client/pull/57
  https://github.com/CanonicalLtd/landscape-client/pull/70

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1848828/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1848828] Re: report packages from security pocket

[Eric Desrochers]

** Changed in: landscape-client (Ubuntu Eoan)
 Assignee: (unassigned) => Simon Poirier (simpoir)

** Changed in: landscape-client (Ubuntu Disco)
 Assignee: (unassigned) => Simon Poirier (simpoir)

** Changed in: landscape-client (Ubuntu Bionic)
 Assignee: (unassigned) => Simon Poirier (simpoir)

** Changed in: landscape-client (Ubuntu Xenial)
 Assignee: (unassigned) => Simon Poirier (simpoir)

** Changed in: landscape-client (Ubuntu Eoan)
   Status: New => In Progress

** Changed in: landscape-client (Ubuntu Disco)
   Status: New => In Progress

** Changed in: landscape-client (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: landscape-client (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: landscape-client (Ubuntu Eoan)
   Importance: Undecided => Medium

** Changed in: landscape-client (Ubuntu Disco)
   Importance: Undecided => Medium

** Tags added: sts-sponsor-slashd

** Changed in: landscape-client (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: landscape-client (Ubuntu Xenial)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1848828

Title:
  report packages from security pocket

Status in landscape-client package in Ubuntu:
  In Progress
Status in landscape-client source package in Xenial:
  In Progress
Status in landscape-client source package in Bionic:
  In Progress
Status in landscape-client source package in Disco:
  In Progress
Status in landscape-client source package in Eoan:
  In Progress
Status in landscape-client source package in Focal:
  In Progress

Bug description:
  [Impact]

  I report this bug to add the necessary bit into lds-client for all
  affected/supported releases.

  [Test Case]

  * One must use Landscape server on-prem (version >=19.01) or hosted which 
already contain the necessary server side change.
  * Install landscape-client.
  * Successfully register a client against Landscape server.
  * Security updates will only rely on USN notices and could possibly ignore 
other packages found in -security pocket even if they are there simply by the 
fact that there was no USN notice specific for them.

  (e.g. systemd has an USN, systemd get updated but its derived systemd
  binary packages aren't updated)

  [Regression Potential]

  ## TBD by simpoir ##

  [Other Info]

  * Upstream details:
  
https://github.com/CanonicalLtd/landscape-client/commit/93a3b47965da199785e9b3d226cb61f721e54196
  https://github.com/CanonicalLtd/landscape-client/pull/57
  https://github.com/CanonicalLtd/landscape-client/pull/70

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1848828/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1848210] Re: ghostscript: ensure update of cups-filter

[Eric Desrochers]

$ pull-lp-source cups-filters xenial

debian/control:
.
Package: cups-filters
Architecture: any
Depends: ${shlibs:Depends},
 ${misc:Depends},
 cups-filters-core-drivers (>= ${binary:Version}),
 bc,
 ghostscript (>= 9.02~),
 imagemagick (>= 6.4~),
 poppler-utils


$ pull-lp-source cups-filters bionic

debian/control:

Package: cups-filters
Architecture: any
Depends: ${shlibs:Depends},
 ${misc:Depends},
 cups-filters-core-drivers (>= ${binary:Version}),
 bc,
 ghostscript (>= 9.02~),
 poppler-utils


After more investigation, the Depends is already in place in both X/B.

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1848210

Title:
  ghostscript: ensure update of cups-filter

Status in cups-filters package in Ubuntu:
  New
Status in ghostscript package in Ubuntu:
  Fix Released
Status in cups-filters source package in Xenial:
  New
Status in ghostscript source package in Xenial:
  In Progress
Status in cups-filters source package in Bionic:
  New
Status in ghostscript source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * After an update of ghostscript but not cups-filters
     (which is possible; eg unattended-upgrade/landscape)
     users may hit errors printing PDF files (LP#1828401).

   * Landscape and unattended-upgrade allows packages
 updates to security updates / USN-only, thus
     ghostscript is updated for CVE-2019-3839-1 and -2
     (version 9.26~dfsg+0-0ubuntu0.18.04.9 and 16.04.9)
     which may break printing PDF files on cups-filters.

   * So, to ensure that ghostscript and cups-filters are
     both updated, add a versioned 'Breaks:' relationship
     to ghostscript for older cups-filters versions which
     are not yet fixed.

     Per Debian Policy [1]:

   """
   Normally a Breaks entry will have an “earlier than” version clause;
   such a Breaks is introduced in the version ... [that] reveals a bug
   in earlier versions of the broken package ...

   This use of Breaks will inform higher-level package management tools
   that the broken package must be upgraded before the new one.
   """

   * A versioned 'Depends:' relationship is not possible
     as ghostscript doesn't depend on cups-filters, thus
     it's possible to have ghostscript installed without
     cups-filters at all.

  [Test Case]

   * Install cups-filters version without fix for LP#1828401:
     1.20.2-0ubuntu3 in Bionic, and 1.8.3-2ubuntu3.4 in Xenial.

   * Update ghostscript to/later than fix for CVE-2019-3839-1/-2
     9.26~dfsg+0-0ubuntu0.18.04.9 in Bionic / .16.04.9 in Xenial.

   * Notice it does _not_ update cups-filters to version with fix:
     1.20.2-0ubuntu3.1 in Bionic, and 1.8.3-2ubuntu3.5 in Xenial.

   * $ wget -O ppd-with-pdf-support.ppd \
   
'http://www.openprinting.org/ppd-o-matic.php?driver=hl7x0=Brother-HL-1020=1'

   * $ wget -O dummy.pdf \
   https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf

   * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf
     ...
     Filetype: PDF
     GPL Ghostscript 9.26: Unrecoverable error, exit code 1
     Process is dying with "Unable to determine number of pages, page count: -1
     ", exit stat 3
     ...

   * Note it's broken.

   * Install ghostscript (test) packages with the relationships
     'Breaks: cups-filters (<< 1.20.2-0ubuntu3.1)' in Bionic or
     'Breaks: ..., cups-filters (<< 1.8.3-2ubuntu3.5)' in Xenial.

   * Note it _does_ update cups-filters to version with fix.

   * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf
     ...
     Filetype: PDF
     File contains 1 pages
     Starting renderer with command: <...>
     ...

   * Note it's now working.

  [Regression Potential]

   * Low.  This only causes an update to cups-filters to a version
     that fixes an already identified/resolved problem (LP#1828401),
     which is available in bionic- & xenial-updates since May 2019.

  [Other Info]

   * This is only required in Xenial and Bionic.

   * Trusty doesn't have the ghostscript update that causes the problem.

   * Disco/Eoan have the cups-filters fix that it requires (1.22.5+).

  [1] https://www.debian.org/doc/debian-policy/ch-relationships.html
  #packages-which-break-other-packages-breaks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1848210/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1848210] Re: ghostscript: ensure update of cups-filter

[Eric Desrochers]

$ pull-lp-source cups-filters xenial

debian/control:
.
Package: cups-filters
Architecture: any
Depends: ${shlibs:Depends},
 ${misc:Depends},
 cups-filters-core-drivers (>= ${binary:Version}),
 bc,
 ghostscript (>= 9.02~),
 imagemagick (>= 6.4~),
 poppler-utils



$ pull-lp-source cups-filter bionic

debian/control:

Package: cups-filters
Architecture: any
Depends: ${shlibs:Depends},
 ${misc:Depends},
 cups-filters-core-drivers (>= ${binary:Version}),
 bc,
 ghostscript (>= 9.02~),
 poppler-utils


The "Depends:" I was talking about is already in place, just need to
change the version.

** Changed in: cups-filters (Ubuntu Bionic)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: cups-filters (Ubuntu Xenial)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: cups-filters (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: cups-filters (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: ghostscript (Ubuntu)
   Status: Invalid => Fix Released

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1848210

Title:
  ghostscript: ensure update of cups-filter

Status in cups-filters package in Ubuntu:
  New
Status in ghostscript package in Ubuntu:
  Fix Released
Status in cups-filters source package in Xenial:
  New
Status in ghostscript source package in Xenial:
  In Progress
Status in cups-filters source package in Bionic:
  New
Status in ghostscript source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * After an update of ghostscript but not cups-filters
     (which is possible; eg unattended-upgrade/landscape)
     users may hit errors printing PDF files (LP#1828401).

   * Landscape and unattended-upgrade allows packages
 updates to security updates / USN-only, thus
     ghostscript is updated for CVE-2019-3839-1 and -2
     (version 9.26~dfsg+0-0ubuntu0.18.04.9 and 16.04.9)
     which may break printing PDF files on cups-filters.

   * So, to ensure that ghostscript and cups-filters are
     both updated, add a versioned 'Breaks:' relationship
     to ghostscript for older cups-filters versions which
     are not yet fixed.

     Per Debian Policy [1]:

   """
   Normally a Breaks entry will have an “earlier than” version clause;
   such a Breaks is introduced in the version ... [that] reveals a bug
   in earlier versions of the broken package ...

   This use of Breaks will inform higher-level package management tools
   that the broken package must be upgraded before the new one.
   """

   * A versioned 'Depends:' relationship is not possible
     as ghostscript doesn't depend on cups-filters, thus
     it's possible to have ghostscript installed without
     cups-filters at all.

  [Test Case]

   * Install cups-filters version without fix for LP#1828401:
     1.20.2-0ubuntu3 in Bionic, and 1.8.3-2ubuntu3.4 in Xenial.

   * Update ghostscript to/later than fix for CVE-2019-3839-1/-2
     9.26~dfsg+0-0ubuntu0.18.04.9 in Bionic / .16.04.9 in Xenial.

   * Notice it does _not_ update cups-filters to version with fix:
     1.20.2-0ubuntu3.1 in Bionic, and 1.8.3-2ubuntu3.5 in Xenial.

   * $ wget -O ppd-with-pdf-support.ppd \
   
'http://www.openprinting.org/ppd-o-matic.php?driver=hl7x0=Brother-HL-1020=1'

   * $ wget -O dummy.pdf \
   https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf

   * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf
     ...
     Filetype: PDF
     GPL Ghostscript 9.26: Unrecoverable error, exit code 1
     Process is dying with "Unable to determine number of pages, page count: -1
     ", exit stat 3
     ...

   * Note it's broken.

   * Install ghostscript (test) packages with the relationships
     'Breaks: cups-filters (<< 1.20.2-0ubuntu3.1)' in Bionic or
     'Breaks: ..., cups-filters (<< 1.8.3-2ubuntu3.5)' in Xenial.

   * Note it _does_ update cups-filters to version with fix.

   * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf
     ...
     Filetype: PDF
     File contains 1 pages
     Starting renderer with command: <...>
     ...

   * Note it's now working.

  [Regression Potential]

   * Low.  This only causes an update to cups-filters to a version
     that fixes an already identified/resolved problem (LP#1828401),
     which is available in bionic- & xenial-updates since May 2019.

  [Other Info]

   * This is only required in Xenial and Bionic.

   * Trusty doesn't have the ghostscript update that causes the problem.

   * Disco/Eoan have the cups-filters fix that it requires (1.22.5+).

  [1] https://www.debian.org/doc/debian-policy/ch-relationships.html
  #packages-which-break-other-packages-breaks

To manage notifications about this bug go to:

[Sts-sponsors] [Bug 1848210] Re: ghostscript: ensure update of cups-filter

[Eric Desrochers]

** Tags added: sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1848210

Title:
  ghostscript: ensure update of cups-filter

Status in cups-filters package in Ubuntu:
  New
Status in ghostscript package in Ubuntu:
  Invalid
Status in cups-filters source package in Xenial:
  New
Status in ghostscript source package in Xenial:
  In Progress
Status in cups-filters source package in Bionic:
  New
Status in ghostscript source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * After an update of ghostscript but not cups-filters
     (which is possible; eg unattended-upgrade/landscape)
     users may hit errors printing PDF files (LP#1828401).

   * Landscape and unattended-upgrade allows packages
 updates to security updates / USN-only, thus
     ghostscript is updated for CVE-2019-3839-1 and -2
     (version 9.26~dfsg+0-0ubuntu0.18.04.9 and 16.04.9)
     which may break printing PDF files on cups-filters.

   * So, to ensure that ghostscript and cups-filters are
     both updated, add a versioned 'Breaks:' relationship
     to ghostscript for older cups-filters versions which
     are not yet fixed.

     Per Debian Policy [1]:

   """
   Normally a Breaks entry will have an “earlier than” version clause;
   such a Breaks is introduced in the version ... [that] reveals a bug
   in earlier versions of the broken package ...

   This use of Breaks will inform higher-level package management tools
   that the broken package must be upgraded before the new one.
   """

   * A versioned 'Depends:' relationship is not possible
     as ghostscript doesn't depend on cups-filters, thus
     it's possible to have ghostscript installed without
     cups-filters at all.

  [Test Case]

   * Install cups-filters version without fix for LP#1828401:
     1.20.2-0ubuntu3 in Bionic, and 1.8.3-2ubuntu3.4 in Xenial.

   * Update ghostscript to/later than fix for CVE-2019-3839-1/-2
     9.26~dfsg+0-0ubuntu0.18.04.9 in Bionic / .16.04.9 in Xenial.

   * Notice it does _not_ update cups-filters to version with fix:
     1.20.2-0ubuntu3.1 in Bionic, and 1.8.3-2ubuntu3.5 in Xenial.

   * $ wget -O ppd-with-pdf-support.ppd \
   
'http://www.openprinting.org/ppd-o-matic.php?driver=hl7x0=Brother-HL-1020=1'

   * $ wget -O dummy.pdf \
   https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf

   * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf
     ...
     Filetype: PDF
     GPL Ghostscript 9.26: Unrecoverable error, exit code 1
     Process is dying with "Unable to determine number of pages, page count: -1
     ", exit stat 3
     ...

   * Note it's broken.

   * Install ghostscript (test) packages with the relationships
     'Breaks: cups-filters (<< 1.20.2-0ubuntu3.1)' in Bionic or
     'Breaks: ..., cups-filters (<< 1.8.3-2ubuntu3.5)' in Xenial.

   * Note it _does_ update cups-filters to version with fix.

   * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf
     ...
     Filetype: PDF
     File contains 1 pages
     Starting renderer with command: <...>
     ...

   * Note it's now working.

  [Regression Potential]

   * Low.  This only causes an update to cups-filters to a version
     that fixes an already identified/resolved problem (LP#1828401),
     which is available in bionic- & xenial-updates since May 2019.

  [Other Info]

   * This is only required in Xenial and Bionic.

   * Trusty doesn't have the ghostscript update that causes the problem.

   * Disco/Eoan have the cups-filters fix that it requires (1.22.5+).

  [1] https://www.debian.org/doc/debian-policy/ch-relationships.html
  #packages-which-break-other-packages-breaks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1848210/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1848210] Re: ghostscript: ensure update of cups-filter

[Eric Desrochers]

I will be more favourable to do the other way around by adding a
"Depends:" in cups-filters package for ghostscript version "X" ?
Especially if cups-filters always needs ghostscript ?

It will force ghostscript to get updated instead of making the package
install to fails/breaks.

At least it's worth testing IMHO that avenue before considering the
current "Breaks:" approach.

- Eric


** Also affects: cups-filters (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1848210

Title:
  ghostscript: ensure update of cups-filter

Status in cups-filters package in Ubuntu:
  New
Status in ghostscript package in Ubuntu:
  Invalid
Status in cups-filters source package in Xenial:
  New
Status in ghostscript source package in Xenial:
  In Progress
Status in cups-filters source package in Bionic:
  New
Status in ghostscript source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * After an update of ghostscript but not cups-filters
     (which is possible; eg unattended-upgrade/landscape)
     users may hit errors printing PDF files (LP#1828401).

   * Landscape and unattended-upgrade allows packages
 updates to security updates / USN-only, thus
     ghostscript is updated for CVE-2019-3839-1 and -2
     (version 9.26~dfsg+0-0ubuntu0.18.04.9 and 16.04.9)
     which may break printing PDF files on cups-filters.

   * So, to ensure that ghostscript and cups-filters are
     both updated, add a versioned 'Breaks:' relationship
     to ghostscript for older cups-filters versions which
     are not yet fixed.

     Per Debian Policy [1]:

   """
   Normally a Breaks entry will have an “earlier than” version clause;
   such a Breaks is introduced in the version ... [that] reveals a bug
   in earlier versions of the broken package ...

   This use of Breaks will inform higher-level package management tools
   that the broken package must be upgraded before the new one.
   """

   * A versioned 'Depends:' relationship is not possible
     as ghostscript doesn't depend on cups-filters, thus
     it's possible to have ghostscript installed without
     cups-filters at all.

  [Test Case]

   * Install cups-filters version without fix for LP#1828401:
     1.20.2-0ubuntu3 in Bionic, and 1.8.3-2ubuntu3.4 in Xenial.

   * Update ghostscript to/later than fix for CVE-2019-3839-1/-2
     9.26~dfsg+0-0ubuntu0.18.04.9 in Bionic / .16.04.9 in Xenial.

   * Notice it does _not_ update cups-filters to version with fix:
     1.20.2-0ubuntu3.1 in Bionic, and 1.8.3-2ubuntu3.5 in Xenial.

   * $ wget -O ppd-with-pdf-support.ppd \
   
'http://www.openprinting.org/ppd-o-matic.php?driver=hl7x0=Brother-HL-1020=1'

   * $ wget -O dummy.pdf \
   https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf

   * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf
     ...
     Filetype: PDF
     GPL Ghostscript 9.26: Unrecoverable error, exit code 1
     Process is dying with "Unable to determine number of pages, page count: -1
     ", exit stat 3
     ...

   * Note it's broken.

   * Install ghostscript (test) packages with the relationships
     'Breaks: cups-filters (<< 1.20.2-0ubuntu3.1)' in Bionic or
     'Breaks: ..., cups-filters (<< 1.8.3-2ubuntu3.5)' in Xenial.

   * Note it _does_ update cups-filters to version with fix.

   * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf
     ...
     Filetype: PDF
     File contains 1 pages
     Starting renderer with command: <...>
     ...

   * Note it's now working.

  [Regression Potential]

   * Low.  This only causes an update to cups-filters to a version
     that fixes an already identified/resolved problem (LP#1828401),
     which is available in bionic- & xenial-updates since May 2019.

  [Other Info]

   * This is only required in Xenial and Bionic.

   * Trusty doesn't have the ghostscript update that causes the problem.

   * Disco/Eoan have the cups-filters fix that it requires (1.22.5+).

  [1] https://www.debian.org/doc/debian-policy/ch-relationships.html
  #packages-which-break-other-packages-breaks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1848210/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1848210] Re: ghostscript: ensure update of cups-filter

[Eric Desrochers]

I will be more favourable to do the other way around by adding a
"Depends:" in cups-filters package for ghostscript version "X" ?
Especially if cups-filters always needs ghostscript ?

"Depends: ghostscript (>= CUPS_FILTER_VERSION)"

to force ghostscript to get updated instead of making the package
install to fails/breaks.

At least it's worth testing IMHO that avenue before considering the
current "Breaks:" approach.

Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1848210

Title:
  ghostscript: ensure update of cups-filter

Status in cups-filters package in Ubuntu:
  New
Status in ghostscript package in Ubuntu:
  Invalid
Status in cups-filters source package in Xenial:
  New
Status in ghostscript source package in Xenial:
  In Progress
Status in cups-filters source package in Bionic:
  New
Status in ghostscript source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * After an update of ghostscript but not cups-filters
     (which is possible; eg unattended-upgrade/landscape)
     users may hit errors printing PDF files (LP#1828401).

   * Landscape and unattended-upgrade allows packages
 updates to security updates / USN-only, thus
     ghostscript is updated for CVE-2019-3839-1 and -2
     (version 9.26~dfsg+0-0ubuntu0.18.04.9 and 16.04.9)
     which may break printing PDF files on cups-filters.

   * So, to ensure that ghostscript and cups-filters are
     both updated, add a versioned 'Breaks:' relationship
     to ghostscript for older cups-filters versions which
     are not yet fixed.

     Per Debian Policy [1]:

   """
   Normally a Breaks entry will have an “earlier than” version clause;
   such a Breaks is introduced in the version ... [that] reveals a bug
   in earlier versions of the broken package ...

   This use of Breaks will inform higher-level package management tools
   that the broken package must be upgraded before the new one.
   """

   * A versioned 'Depends:' relationship is not possible
     as ghostscript doesn't depend on cups-filters, thus
     it's possible to have ghostscript installed without
     cups-filters at all.

  [Test Case]

   * Install cups-filters version without fix for LP#1828401:
     1.20.2-0ubuntu3 in Bionic, and 1.8.3-2ubuntu3.4 in Xenial.

   * Update ghostscript to/later than fix for CVE-2019-3839-1/-2
     9.26~dfsg+0-0ubuntu0.18.04.9 in Bionic / .16.04.9 in Xenial.

   * Notice it does _not_ update cups-filters to version with fix:
     1.20.2-0ubuntu3.1 in Bionic, and 1.8.3-2ubuntu3.5 in Xenial.

   * $ wget -O ppd-with-pdf-support.ppd \
   
'http://www.openprinting.org/ppd-o-matic.php?driver=hl7x0=Brother-HL-1020=1'

   * $ wget -O dummy.pdf \
   https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf

   * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf
     ...
     Filetype: PDF
     GPL Ghostscript 9.26: Unrecoverable error, exit code 1
     Process is dying with "Unable to determine number of pages, page count: -1
     ", exit stat 3
     ...

   * Note it's broken.

   * Install ghostscript (test) packages with the relationships
     'Breaks: cups-filters (<< 1.20.2-0ubuntu3.1)' in Bionic or
     'Breaks: ..., cups-filters (<< 1.8.3-2ubuntu3.5)' in Xenial.

   * Note it _does_ update cups-filters to version with fix.

   * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf
     ...
     Filetype: PDF
     File contains 1 pages
     Starting renderer with command: <...>
     ...

   * Note it's now working.

  [Regression Potential]

   * Low.  This only causes an update to cups-filters to a version
     that fixes an already identified/resolved problem (LP#1828401),
     which is available in bionic- & xenial-updates since May 2019.

  [Other Info]

   * This is only required in Xenial and Bionic.

   * Trusty doesn't have the ghostscript update that causes the problem.

   * Disco/Eoan have the cups-filters fix that it requires (1.22.5+).

  [1] https://www.debian.org/doc/debian-policy/ch-relationships.html
  #packages-which-break-other-packages-breaks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1848210/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1847924] Re: Introduce broken state parsing to mdadm

[Eric Desrochers]

** Also affects: mdadm (Ubuntu Ff-series)
   Importance: Undecided
   Status: New

** Changed in: mdadm (Ubuntu Ff-series)
   Status: New => Confirmed

** Changed in: mdadm (Ubuntu Ff-series)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: mdadm (Ubuntu Ff-series)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1847924

Title:
  Introduce broken state parsing to mdadm

Status in mdadm package in Ubuntu:
  In Progress
Status in mdadm source package in Bionic:
  In Progress
Status in mdadm source package in Disco:
  In Progress
Status in mdadm source package in Eoan:
  In Progress
Status in mdadm source package in FF-Series:
  Confirmed

Bug description:
  [Impact]

  * Currently, mounted raid0/md-linear arrays have no indication/warning
  when one or more members are removed or suffer from some non-
  recoverable error condition. The mdadm tool shows "clean" state
  regardless if a member was removed.

  * The patch proposed in this SRU addresses this issue by introducing a
  new state "broken", which is analog to "clean" but indicates that
  array is not in a good/correct state. The commit, available upstream
  as 43ebc910 ("mdadm: Introduce new array state 'broken' for
  raid0/linear") [0], was extensively discussed and received a good
  amount of reviews/analysis by both the current mdadm maintainer as
  well as an old maintainer.

  * One important note here is that this patch requires a counter-part in the 
kernel to be fully functional, which was SRUed in LP: #1847773.
  It works fine/transparently without this kernel counter-part though.

  [Test case]

  * To test this patch, create a raid0 or linear md array on Linux using
  mdadm, like: "mdadm --create md0 --level=0 --raid-devices=2
  /dev/nvme0n1 /dev/nvme1n1";

  * Format the array using a FS of your choice (for example ext4) and
  mount the array;

  * Remove one member of the array, for example using sysfs interface
  (for nvme: echo 1 > /sys/block/nvme0n1/device/device/remove, for scsi:
  echo 1 > /sys/block/sdX/device/delete);

  * Without this patch, the array state shown by "mdadm --detail" is
  "clean", regardless a member is missing/failed.

  [Regression potential]

  * There's not much potential regression here; we just exhibit arrays'
  state as "broken" if they have one or more missing/failed members; we
  believe the most common "issue" that could be reported from this patch
  is if an userspace tool rely on the array status as being always
  "clean" even for broken devices, then such tool may behave differently
  with this patch.

  * Note that we *proactively* skipped Xenial SRU here, in order to
  prevent potential regressions - Xenial mdadm tool lacks code
  infrastructure used by this patch, so the decision was for
  safety/stability, by only SRUing Bionic / Disco / Eoan mdadm versions.

  [0]
  https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/commit/?id=43ebc910

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1847924/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1846138] Re: backport mod_reqtimeout with handshake support

[Eric Desrochers]

[VERIFICATION XENIAL - Part 2]
* Feedback #3:
"
I also tested and now it works perfectly, I can count the seconds which I 
configure for the handshake timeout and the connection is terminated exactly 
when the handshake timeout expires 

Great job!
"

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1846138

Title:
  backport mod_reqtimeout with handshake support

Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Xenial:
  Fix Committed
Status in apache2 source package in Bionic:
  Fix Released
Status in apache2 source package in Disco:
  Fix Released

Bug description:
  [Impact]

  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite
  because there are no free connections. The connections will be in
  state "established" ~ 2 hours.

  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy

  This issue can be resolved by enabling the parameter(mod_reqtimeout).
  This parameter is available in apache 2.4.39 (released on 2019-04-01).

  [Test Case]

  This test case has been brought to my attention by an impacted user:
  "
  You must have an apache2 server, with an haproxy in front of it, and you 
initiate SSL connections with "nc" between 50 and 8000 connections and because 
the SSL connection process is never finished all those connections get stucked 
and never timeout.
  "

  Reproducer (Thanks to Szilard):
  https://pastebin.ubuntu.com/p/6Hk64CDc7H/

  [Regression Potential]

  * The backport already exist in Bionic/Disco (done by security team
  via the security channel)

  * It is also backported upstream into 2.4 (branch : 2.4.x)

  * It was tested pre-release by an impacted user, and the outcome was
  positive:

  "I have tested the below packages for enabling handshake
  parameter(mod_reqtimeout) in apache. Looks the package is working
  fine. "

  * Local autopkgtest inside qemu, revealed no issues:
  autopkgtest [12:09:48]:  summary
  duplicate-module-load PASS
  htcacheclean PASS
  ssl-passphrase   PASS
  chroot   PASS

  [Other Info]

  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.

  Lack of this feature was exhausting free connections when sent
  corrupted packets.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1846138/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1846138] Re: backport mod_reqtimeout with handshake support

[Eric Desrochers]

[VERIFICATION XENIAL]

* Feedback #1:

>From an impacted user:
"
They confirmed that from their perspective the test is OK, and the apache2 
packages are delivering expected result
"

* Feedback #2:
>From SustEng Mauricio (mfo):
"
The backport in xenial-proposed worked exactly as eoan 
(with the AcceptFilter bits mentioned in previous comment)
...
"

** Description changed:

  [Impact]
  
  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite because
  there are no free connections. The connections will be in state
  "established" ~ 2 hours.
  
  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy
  
  This issue can be resolved by enabling the parameter(mod_reqtimeout).
  This parameter is available in apache 2.4.39 (released on 2019-04-01).
  
  [Test Case]
  
  This test case has been brought to my attention by an impacted user:
  "
  You must have an apache2 server, with an haproxy in front of it, and you 
initiate SSL connections with "nc" between 50 and 8000 connections and because 
the SSL connection process is never finished all those connections get stucked 
and never timeout.
  "
  
+ Reproducer (Thanks to Szilard):
+ https://pastebin.ubuntu.com/p/6Hk64CDc7H/
+ 
  [Regression Potential]
  
  * The backport already exist in Bionic/Disco (done by security team via
  the security channel)
  
  * It is also backported upstream into 2.4 (branch : 2.4.x)
  
  * It was tested pre-release by an impacted user, and the outcome was
  positive:
  
  "I have tested the below packages for enabling handshake
  parameter(mod_reqtimeout) in apache. Looks the package is working fine.
  "
  
  * Local autopkgtest inside qemu, revealed no issues:
  autopkgtest [12:09:48]:  summary
  duplicate-module-load PASS
  htcacheclean PASS
  ssl-passphrase   PASS
  chroot   PASS
  
- 
  [Other Info]
  
  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.
  
  Lack of this feature was exhausting free connections when sent corrupted
  packets.

** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1846138

Title:
  backport mod_reqtimeout with handshake support

Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Xenial:
  Fix Committed
Status in apache2 source package in Bionic:
  Fix Released
Status in apache2 source package in Disco:
  Fix Released

Bug description:
  [Impact]

  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite
  because there are no free connections. The connections will be in
  state "established" ~ 2 hours.

  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy

  This issue can be resolved by enabling the parameter(mod_reqtimeout).
  This parameter is available in apache 2.4.39 (released on 2019-04-01).

  [Test Case]

  This test case has been brought to my attention by an impacted user:
  "
  You must 

[Sts-sponsors] [Bug 1846138] Re: backport mod_reqtimeout with handshake support

[Eric Desrochers]

** Description changed:

  [Impact]
  
  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite because
  there are no free connections. The connections will be in state
  "established" ~ 2 hours.
  
  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy
  
  This issue can be resolved by enabling the parameter(mod_reqtimeout).
  This parameter is available in apache 2.4.39 (released on 2019-04-01).
  
  [Test Case]
  
  This test case has been brought to my attention by an impacted user:
  "
  You must have an apache2 server, with an haproxy in front of it, and you 
initiate SSL connections with "nc" between 50 and 8000 connections and because 
the SSL connection process is never finished all those connections get stucked 
and never timeout.
  "
  
  [Regression Potential]
  
  * The backport already exist in Bionic/Disco (done by security team via
  the security channel)
  
  * It is also backported upstream into 2.4 (branch : 2.4.x)
  
  * It was tested pre-release by an impacted user, and the outcome was
  positive:
  
  "I have tested the below packages for enabling handshake
  parameter(mod_reqtimeout) in apache. Looks the package is working fine.
  "
  
+ * Local autopkgtest inside qemu, revealed no issues:
+ autopkgtest [12:09:48]:  summary
+ duplicate-module-load PASS
+ htcacheclean PASS
+ ssl-passphrase   PASS
+ chroot   PASS
+ 
+ 
  [Other Info]
  
  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.
  
  Lack of this feature was exhausting free connections when sent corrupted
  packets.

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1846138

Title:
  backport mod_reqtimeout with handshake support

Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Xenial:
  In Progress
Status in apache2 source package in Bionic:
  Fix Released
Status in apache2 source package in Disco:
  Fix Released

Bug description:
  [Impact]

  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite
  because there are no free connections. The connections will be in
  state "established" ~ 2 hours.

  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy

  This issue can be resolved by enabling the parameter(mod_reqtimeout).
  This parameter is available in apache 2.4.39 (released on 2019-04-01).

  [Test Case]

  This test case has been brought to my attention by an impacted user:
  "
  You must have an apache2 server, with an haproxy in front of it, and you 
initiate SSL connections with "nc" between 50 and 8000 connections and because 
the SSL connection process is never finished all those connections get stucked 
and never timeout.
  "

  [Regression Potential]

  * The backport already exist in Bionic/Disco (done by security team
  via the security channel)

  * It is also backported upstream into 2.4 (branch : 2.4.x)

  * It was tested pre-release by an impacted user, and the outcome was
  positive:

  

[Sts-sponsors] [Bug 1846138] Re: backport mod_reqtimeout with handshake support

[Eric Desrochers]

** Description changed:

  ## DRAFT ##
  [Impact]
  
  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite because
  there are no free connections. The connections will be in state
  "established" ~ 2 hours.
  
  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy
  
  This issue can be resolved by enabling the parameter(mod_reqtimeout).
  This parameter is available in apache 2.4.39 (released on 2019-04-01).
  
  [Test Case]
  
+ This test case has been brought to my attention by an impacted user:
+ "
+ You must have an apache2 server, with an haproxy in front of it, and you 
initiate SSL connections with "nc" between 50 and 8000 connections and because 
the SSL connection process is never finished all those connections get stucked 
and never timeout.
+ "
+ 
  [Regression Potential]
  
  * The backport already exist in Bionic/Disco (done by security team via
  the security channel)
  
  * It is also backported upstream into 2.4 (branch : 2.4.x)
- 
  
  [Other Info]
  
  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.
  
  Lack of this feature was exhausting free connections when sent corrupted
  packets.

** Description changed:

- ## DRAFT ##
  [Impact]
  
  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite because
  there are no free connections. The connections will be in state
  "established" ~ 2 hours.
  
  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy
  
  This issue can be resolved by enabling the parameter(mod_reqtimeout).
  This parameter is available in apache 2.4.39 (released on 2019-04-01).
  
  [Test Case]
  
  This test case has been brought to my attention by an impacted user:
  "
  You must have an apache2 server, with an haproxy in front of it, and you 
initiate SSL connections with "nc" between 50 and 8000 connections and because 
the SSL connection process is never finished all those connections get stucked 
and never timeout.
  "
  
  [Regression Potential]
  
  * The backport already exist in Bionic/Disco (done by security team via
  the security channel)
  
  * It is also backported upstream into 2.4 (branch : 2.4.x)
  
  [Other Info]
  
  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.
  
  Lack of this feature was exhausting free connections when sent corrupted
  packets.

** Description changed:

  [Impact]
  
  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite because
  there are no free connections. The connections will be in state
  "established" ~ 2 hours.
  
  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 

[Sts-sponsors] [Bug 1846138] Re: backport mod_reqtimeout with handshake support

[Eric Desrochers]

** Description changed:

  ## DRAFT ##
  [Impact]
  
  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite because
  there are no free connections. The connections will be in state
  "established" ~ 2 hours.
  
- 1.2. Detailed trouble description 
- # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy 
+ 1.2. Detailed trouble description
+ # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy
  
- 
- This issue can be resolved by enabling the parameter(mod_reqtimeout). This 
parameter is available in apache 2.4.39 (released on 2019-04-01).
+ This issue can be resolved by enabling the parameter(mod_reqtimeout).
+ This parameter is available in apache 2.4.39 (released on 2019-04-01).
  
  [Test Case]
  
  [Regression Potential]
+ 
+ * The backport already exist in Bionic/Disco (done by security team via
+ the security channel)
+ 
+ * It is also backported upstream into 2.4 (branch : 2.4.x)
+ 
  
  [Other Info]
  
  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.
  
  Lack of this feature was exhausting free connections when sent corrupted
  packets.

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1846138

Title:
  backport mod_reqtimeout with handshake support

Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Xenial:
  In Progress
Status in apache2 source package in Bionic:
  Fix Released
Status in apache2 source package in Disco:
  Fix Released

Bug description:
  ## DRAFT ##
  [Impact]

  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite
  because there are no free connections. The connections will be in
  state "established" ~ 2 hours.

  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy

  This issue can be resolved by enabling the parameter(mod_reqtimeout).
  This parameter is available in apache 2.4.39 (released on 2019-04-01).

  [Test Case]

  [Regression Potential]

  * The backport already exist in Bionic/Disco (done by security team
  via the security channel)

  * It is also backported upstream into 2.4 (branch : 2.4.x)

  
  [Other Info]

  [Original description]
  Backport the handshake feature in mod_reqtimeout 

[Sts-sponsors] [Bug 1846138] Re: backport mod_reqtimeout with handshake support

[Eric Desrochers]

** Changed in: apache2 (Ubuntu Xenial)
   Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1846138

Title:
  backport mod_reqtimeout with handshake support

Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Xenial:
  In Progress
Status in apache2 source package in Bionic:
  Fix Released
Status in apache2 source package in Disco:
  Fix Released

Bug description:
  ## DRAFT ##
  [Impact]

  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite
  because there are no free connections. The connections will be in
  state "established" ~ 2 hours.

  1.2. Detailed trouble description 
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy 

  
  This issue can be resolved by enabling the parameter(mod_reqtimeout). This 
parameter is available in apache 2.4.39 (released on 2019-04-01).

  [Test Case]

  [Regression Potential]

  [Other Info]

  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.

  Lack of this feature was exhausting free connections when sent
  corrupted packets.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1846138/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1846138] Re: backport mod_reqtimeout with handshake support

[Eric Desrochers]

** Changed in: apache2 (Ubuntu Disco)
   Status: New => Fix Released

** Changed in: apache2 (Ubuntu Bionic)
   Status: New => Confirmed

** Changed in: apache2 (Ubuntu Bionic)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1846138

Title:
  backport mod_reqtimeout with handshake support

Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Xenial:
  Confirmed
Status in apache2 source package in Bionic:
  Fix Released
Status in apache2 source package in Disco:
  Fix Released

Bug description:
  ## DRAFT ##
  [Impact] 

  [Test Case]

  [Regression Potential]

  
  [Other Info]

  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.

  Lack of this feature was exhausting free connections when sent
  corrupted packets.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1846138/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1846138] Re: backport mod_reqtimeout with handshake support

[Eric Desrochers]

** Changed in: apache2 (Ubuntu)
   Status: New => Fix Released

** Changed in: apache2 (Ubuntu)
 Assignee: Jesse Williamson (chardan) => (unassigned)

** Changed in: apache2 (Ubuntu Xenial)
 Assignee: (unassigned) => Jesse Williamson (chardan)

** Description changed:

- Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to
- Apache 2.4.18.
+ ## DRAFT ##
+ [Impact] 
+ 
+ [Test Case]
+ 
+ [Regression Potential]
+ 
+ 
+ [Other Info]
+ 
+ [Original description]
+ Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.
  
  Lack of this feature was exhausting free connections when sent corrupted
  packets.

** Changed in: apache2 (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: apache2 (Ubuntu Xenial)
   Status: New => Confirmed

** Also affects: apache2 (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Also affects: apache2 (Ubuntu Bionic)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1846138

Title:
  backport mod_reqtimeout with handshake support

Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Xenial:
  Confirmed
Status in apache2 source package in Bionic:
  Fix Released
Status in apache2 source package in Disco:
  Fix Released

Bug description:
  ## DRAFT ##
  [Impact] 

  [Test Case]

  [Regression Potential]

  
  [Other Info]

  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.

  Lack of this feature was exhausting free connections when sent
  corrupted packets.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1846138/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1796501] Re: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

[Eric Desrochers]

** Tags added: sts-sponsor-ddstreet

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1796501

Title:
  systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  In Progress

Bug description:
  I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't 
exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the 
following steps:
  1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size.
  2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit.
  3. Ask upstream for SOA of test.asdf. with EDNS0.
  4. Ask upstream for SOA of test.asdf. without EDNS0.
  5. Repeat 1-4 for DS of test.asdf.
  6. Repeat 1-5 for asdf.
  7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size.
  8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size.

  The upstream returns an unfragmented NXDOMAIN response for steps 1-6,
  an unfragmented NOERROR response for step 7 and a fragmented NOERROR
  response for step 8 which is the correct behaviour. DNSSEC records are
  included in the response if the DO-bit in the request was set.

  systemd-resolved should take the response from step 1 and start with
  validation instead of starting useless retries with reduced feture
  set. Step 3 and 4 are completely useless and probably lead to the
  SERVFAIL because I have configured it with DNSSEC=yes to prevent
  downgrade attacks.

  This regression seems to be caused by the patch resolved-Mitigate-
  DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic
  should only be executed if it is configured as DNSSEC=allow-downgrade
  or DNSSEC=no. See also
  https://github.com/systemd/systemd/pull/8608#issuecomment-396927885.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1842437] Re: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev

[Eric Desrochers]

[STS-Sponsor]

Sponsored in Bionic.

Thanks Mauricio for your great work on this bug and the FTBFS situation.

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1842437

Title:
  Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem
  with udev

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Users / systemd can fail to mount a filesystem by UUID
 (e.g., during boot, triggering emergency shell prompt)
 if the magic bytes for the nilfs filesystem are written
 to the right place in a partition of another filesystem,
 (for whatever reason or coincidence).

   * Note this can happen after the filesystem/mount is working
 correctly, so a change of behavior/problem can potentially
 be noticed when trying to mount the filesystem again, which
 can very well be the next time the system boots.

   * This happens because if udev blkid detects more than one
 filesystem, it does not print the UUID env vars required
 to create the /dev/disk/by-id symlinks and other things.

   * The fix enhances the check for valid nilfs superblock by
 specifically checking a value read from disk to be valid/
 within a value range, which addresses this one occurrence
 and prevents a lot more.

  [Test Case]

   * Synthetic test case written for this problem on comment #6.

  [Regression Potential]

   * Low.  The code is contained in the probe for the nilfs filesystem.

   * This just makes it be more restrictive about the possibly valid
 values for a few bytes read from disk (that now need to be within
 the acceptable range of valid values) so this only decreases false-
 positives, and cannot increase false-negatives of valid filesystems.

  [Original Description]

  The nilfs filesystem has a backup superblock at the end of the device.

  If the magic number is coincidentally found at the right position
  and the filesystem is on a partition/not-wholedisk device,
  the only check left is for checksum verification,
  which is explicitly ignored in 'udev built-in blkid'.

  This causes blkid to detect one actually valid filesystem with a
  superblock at the beginning of the device (e.g., ext4), and then
  an invalid nilfs2 filesystem due to a coincidental magic number
  at the end of the device.

  And this causes blkid to break out of the safeprobe routine
  (which expects a single filesystem to be detected), and not
  print the UUIDs, thus not creating /dev/disk/by-uuid/ links
  which prevent mounting the partition by-uuid at boot time,
  causing emergency shell/boot failures.

  This upstream fix resolved the problem by introducing a check
  for the 'bytes' paramenters in the superblock, which is read
  from disk, and turns out to have an out-of-range value.

  - 'liblkid: Add length check in probe_nilfs2 before crc32'
  
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2

  $ git describe --contains ac681a310c32319423297544833932f4d689a7a2
  v2.29-rc1~172

  Xenial, which is v2.27.1-based, is the only release that needs it.
  Bionic is v2.31.1, so all post-Xenial supported releases have it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1842437/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1838555] Re: nvme-cli 1.5 in Bionic does not support Micron NVME drives

[Eric Desrochers]

[sts-sponsor]

Since this is a "HWE/new feature", please read
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases

and see if your patch fits inside the policy.

Also, I would like to see more justification/testings (detailed steps,
output, ...) using a micron nmve drive type, local autopkgtest (if any),
software testsuite report (if any), ...

Anything that would support that the regression potential is low, and
that the micro plugin is working as expected.

I would also suggest to look upstream, and see if there was any major
bugfix, CVE, ... after the micron add support, that could be a red flag
or simply worth be adding inside this SRU to-be.

Regards,
Eric


** Changed in: nvme-cli (Ubuntu Bionic)
   Importance: Medium => Wishlist

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1838555

Title:
  nvme-cli 1.5 in Bionic does not support Micron NVME drives

Status in nvme-cli package in Ubuntu:
  Fix Released
Status in nvme-cli source package in Bionic:
  In Progress

Bug description:
  [Impact]

  This was discovered at a customer site and affects all of their Bionic
  installs that have Micron NVMe drives.

  The version of nvme-cli present in Ubuntu 18.04 Bionic Beaver (1.5-1)
  does not include support to manage updating the firmware on Micron
  NVMe drives. The missing support also means that the customer cannot
  format their block size to 4k, as needed by Ceph.

  Version 1.6-1 and later versions do include this support, and can be
  used by rebuilding the package from upstream source as a static
  binary. This is not ideal, but a workaround.

  [Test Case]

  Install nvme-cli from Bionic, and attempt to update firmware for any
  Micron NVMe drive, using a command similar to the below. It will fail,
  as the drive is not supported.

  $ nvme micron select-download /dev/n1 --fw
  ./Micron_9200_FW-101008S0.tar --select=ALL

  With the upstream commit patched into place, we can verify the
  subcommands function with:

  $ nvme micron

  This will display the help screen and a list of supported commands.

  $ nvme micron select-download

  This will show the help page for firmware updating, and required
  arguments. Running again with the arguments from the first example
  will update the firmware on the drives successfully.

  You can find a test package for Bionic here:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf237119-test

  [Regression Potential]

  The opportunity for regression is low. The Micron support is
  implemented as a plugin for the application and the changes are more
  or less standalone. The code paths can only be accessed via "nvme
  micron" subcommands.

  If a regression happens, then users should refrain from running "nvme
  micron" commands while the package is fixed.

  [Other Info]

  The commit that adds support for Micron drives is:

  commit 0124daa3331602365d009a9e8229454c41931c07
  Author: Stephen Tubbs 
  Date:   Wed May 9 07:06:03 2018 -0700
  Subject: Add support for Micron plugin

  https://github.com/linux-nvme/nvme-
  cli/commit/0124daa3331602365d009a9e8229454c41931c07

  This commit landed in version 1.6, and is present in the following
  distros:

  $ rmadison nvme-cli -a amd64
  nvme-cli | 1.5-1 | bionic/universe | amd64
  nvme-cli | 1.6-1 | cosmic/universe | amd64
  nvme-cli | 1.7-1 | disco/universe  | amd64
  nvme-cli | 1.7-1 | eoan/universe   | amd64

  There is a minor backport required for the commit into version 1.5,
  and that is in the Makefile. Some other plugins which are not
  currently present are in the patch, and needed to be removed from the
  OBJS line.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nvme-cli/+bug/1838555/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1838555] Re: nvme-cli 1.5 in Bionic does not support Micron NVME drives

[Eric Desrochers]

** Changed in: nvme-cli (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1838555

Title:
  nvme-cli 1.5 in Bionic does not support Micron NVME drives

Status in nvme-cli package in Ubuntu:
  Fix Released
Status in nvme-cli source package in Bionic:
  In Progress

Bug description:
  [Impact]

  This was discovered at a customer site and affects all of their Bionic
  installs that have Micron NVMe drives.

  The version of nvme-cli present in Ubuntu 18.04 Bionic Beaver (1.5-1)
  does not include support to manage updating the firmware on Micron
  NVMe drives. The missing support also means that the customer cannot
  format their block size to 4k, as needed by Ceph.

  Version 1.6-1 and later versions do include this support, and can be
  used by rebuilding the package from upstream source as a static
  binary. This is not ideal, but a workaround.

  [Test Case]

  Install nvme-cli from Bionic, and attempt to update firmware for any
  Micron NVMe drive, using a command similar to the below. It will fail,
  as the drive is not supported.

  $ nvme micron select-download /dev/n1 --fw
  ./Micron_9200_FW-101008S0.tar --select=ALL

  With the upstream commit patched into place, we can verify the
  subcommands function with:

  $ nvme micron

  This will display the help screen and a list of supported commands.

  $ nvme micron select-download

  This will show the help page for firmware updating, and required
  arguments. Running again with the arguments from the first example
  will update the firmware on the drives successfully.

  You can find a test package for Bionic here:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf237119-test

  [Regression Potential]

  The opportunity for regression is low. The Micron support is
  implemented as a plugin for the application and the changes are more
  or less standalone. The code paths can only be accessed via "nvme
  micron" subcommands.

  If a regression happens, then users should refrain from running "nvme
  micron" commands while the package is fixed.

  [Other Info]

  The commit that adds support for Micron drives is:

  commit 0124daa3331602365d009a9e8229454c41931c07
  Author: Stephen Tubbs 
  Date:   Wed May 9 07:06:03 2018 -0700
  Subject: Add support for Micron plugin

  https://github.com/linux-nvme/nvme-
  cli/commit/0124daa3331602365d009a9e8229454c41931c07

  This commit landed in version 1.6, and is present in the following
  distros:

  $ rmadison nvme-cli -a amd64
  nvme-cli | 1.5-1 | bionic/universe | amd64
  nvme-cli | 1.6-1 | cosmic/universe | amd64
  nvme-cli | 1.7-1 | disco/universe  | amd64
  nvme-cli | 1.7-1 | eoan/universe   | amd64

  There is a minor backport required for the commit into version 1.5,
  and that is in the Makefile. Some other plugins which are not
  currently present are in the patch, and needed to be removed from the
  OBJS line.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nvme-cli/+bug/1838555/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1842437] Re: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev

[Eric Desrochers]

@mfo,

I will gladly resume the sponsoring as soon as LP: #1844504 is "Fix
Released" and util-linux builds fine.

Thanks for your good work on this Mauricio !

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1842437

Title:
  Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem
  with udev

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Users / systemd can fail to mount a filesystem by UUID
 (e.g., during boot, triggering emergency shell prompt)
 if the magic bytes for the nilfs filesystem are written
 to the right place in a partition of another filesystem,
 (for whatever reason or coincidence).

   * Note this can happen after the filesystem/mount is working
 correctly, so a change of behavior/problem can potentially
 be noticed when trying to mount the filesystem again, which
 can very well be the next time the system boots.

   * This happens because if udev blkid detects more than one
 filesystem, it does not print the UUID env vars required
 to create the /dev/disk/by-id symlinks and other things.

   * The fix enhances the check for valid nilfs superblock by
 specifically checking a value read from disk to be valid/
 within a value range, which addresses this one occurrence
 and prevents a lot more.

  [Test Case]

   * Synthetic test case written for this problem on comment #6.

  [Regression Potential]

   * Low.  The code is contained in the probe for the nilfs filesystem.

   * This just makes it be more restrictive about the possibly valid
 values for a few bytes read from disk (that now need to be within
 the acceptable range of valid values) so this only decreases false-
 positives, and cannot increase false-negatives of valid filesystems.

  [Original Description]

  The nilfs filesystem has a backup superblock at the end of the device.

  If the magic number is coincidentally found at the right position
  and the filesystem is on a partition/not-wholedisk device,
  the only check left is for checksum verification,
  which is explicitly ignored in 'udev built-in blkid'.

  This causes blkid to detect one actually valid filesystem with a
  superblock at the beginning of the device (e.g., ext4), and then
  an invalid nilfs2 filesystem due to a coincidental magic number
  at the end of the device.

  And this causes blkid to break out of the safeprobe routine
  (which expects a single filesystem to be detected), and not
  print the UUIDs, thus not creating /dev/disk/by-uuid/ links
  which prevent mounting the partition by-uuid at boot time,
  causing emergency shell/boot failures.

  This upstream fix resolved the problem by introducing a check
  for the 'bytes' paramenters in the superblock, which is read
  from disk, and turns out to have an out-of-range value.

  - 'liblkid: Add length check in probe_nilfs2 before crc32'
  
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2

  $ git describe --contains ac681a310c32319423297544833932f4d689a7a2
  v2.29-rc1~172

  Xenial, which is v2.27.1-based, is the only release that needs it.
  Bionic is v2.31.1, so all post-Xenial supported releases have it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1842437/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1836635] Re: Bionic: support for Solarflare X2542 network adapter (sfc driver)

[Eric Desrochers]

Sponsored in Bionic.

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1836635

Title:
  Bionic: support for Solarflare X2542 network adapter (sfc driver)

Status in debian-installer package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid
Status in debian-installer source package in Bionic:
  In Progress
Status in linux source package in Bionic:
  Fix Released
Status in debian-installer source package in Cosmic:
  Invalid
Status in linux source package in Cosmic:
  Invalid
Status in debian-installer source package in Disco:
  Invalid
Status in linux source package in Disco:
  Invalid
Status in debian-installer source package in Eoan:
  Invalid
Status in linux source package in Eoan:
  Invalid

Bug description:
  [Impact]

   * Support for Solarflare X2542 network adapter
     (Medford2 / SFC9250) in the Bionic sfc driver.

   * This network adapter is present on recent hardware,
     at least HP 2019 and Dell PowerEdge R740xd systems.

   * On recent-hardware deployments that would rather use
     the Bionic LTS / GA supported kernel and cannot move
     to HWE kernels this adapter is non functional at all.

  [Test Case]

   * The X2542 adapter has been exercised with iperf3 and nc
     across 2 hosts on 25G link speed w/ MTUs 1400/1500/9000
     on both directions, for 1 week.

     Its performance is on par with the Cosmic 4.18 kernel
     (which contains all these patches) and the out-of-tree
     driver from the vendor.

   * The 7000 series adapter (for regression testing an old model,
     supported previously) has been exercised with iperf and netperf
     (TCP_STREAM, UDP_STREAM, TCP_RR, UDP_RR, and TCP_CRR) in one
     host (client/server in different adapter ports isolated with
     network namespaces, so traffic goes through the network switch),
     on 10G link speed on MTUs 1500/9000, for 1 weekend.

     No regressions observed between the original and test kernels.

  [Regression Potential]

   * The patchset touches a lot of the sfc driver, so the potential
     for regression definitely exists. Thus, a lot of consideration
     and testing happened:

   * It has been tested on other adapter which uses the old code,
     and no regressions were found so far (see 7000 series above).

   * The patchset is exclusively cherry-picks, no single backport.

   * The patchset essentially moves the Bionic driver up in the
     upstream 'git log --oneline -- drivers/net/ethernet/sfc/':

     - since commit d4a7a8893d4c ("sfc: pass valid pointers from 
efx_enqueue_unwind")
     - until commit 7f61e6c6279b ("sfc: support FEC configuration through 
ethtool")
     - except for 2 commits (not needed / unrelated)
   - commit 42356d9a137b ("sfc: support RSS spreading of ethtool ntuple 
filters")
   - commit 9baeb5eb1f83 ("sfc: falcon: remove duplicated bit-wise or of 
LOOPBACK_SGMII")
     - plus 2 more recent commits (fixes)
   - commit 458bd99e4974 ("sfc: remove ctpio_dmabuf_start from stats")
   - commit 0c235113b3c4 ("sfc: stop the TX queue before pushing new 
buffers")

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1836635/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1842437] Re: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev

[Eric Desrochers]

LP: #1844504

** Tags added: ftbfs

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1842437

Title:
  Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem
  with udev

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Users / systemd can fail to mount a filesystem by UUID
 (e.g., during boot, triggering emergency shell prompt)
 if the magic bytes for the nilfs filesystem are written
 to the right place in a partition of another filesystem,
 (for whatever reason or coincidence).

   * Note this can happen after the filesystem/mount is working
 correctly, so a change of behavior/problem can potentially
 be noticed when trying to mount the filesystem again, which
 can very well be the next time the system boots.

   * This happens because if udev blkid detects more than one
 filesystem, it does not print the UUID env vars required
 to create the /dev/disk/by-id symlinks and other things.

   * The fix enhances the check for valid nilfs superblock by
 specifically checking a value read from disk to be valid/
 within a value range, which addresses this one occurrence
 and prevents a lot more.

  [Test Case]

   * Synthetic test case written for this problem on comment #6.

  [Regression Potential]

   * Low.  The code is contained in the probe for the nilfs filesystem.

   * This just makes it be more restrictive about the possibly valid
 values for a few bytes read from disk (that now need to be within
 the acceptable range of valid values) so this only decreases false-
 positives, and cannot increase false-negatives of valid filesystems.

  [Original Description]

  The nilfs filesystem has a backup superblock at the end of the device.

  If the magic number is coincidentally found at the right position
  and the filesystem is on a partition/not-wholedisk device,
  the only check left is for checksum verification,
  which is explicitly ignored in 'udev built-in blkid'.

  This causes blkid to detect one actually valid filesystem with a
  superblock at the beginning of the device (e.g., ext4), and then
  an invalid nilfs2 filesystem due to a coincidental magic number
  at the end of the device.

  And this causes blkid to break out of the safeprobe routine
  (which expects a single filesystem to be detected), and not
  print the UUIDs, thus not creating /dev/disk/by-uuid/ links
  which prevent mounting the partition by-uuid at boot time,
  causing emergency shell/boot failures.

  This upstream fix resolved the problem by introducing a check
  for the 'bytes' paramenters in the superblock, which is read
  from disk, and turns out to have an out-of-range value.

  - 'liblkid: Add length check in probe_nilfs2 before crc32'
  
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2

  $ git describe --contains ac681a310c32319423297544833932f4d689a7a2
  v2.29-rc1~172

  Xenial, which is v2.27.1-based, is the only release that needs it.
  Bionic is v2.31.1, so all post-Xenial supported releases have it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1842437/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1842437] Re: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev

[Eric Desrochers]

Maybe a kernel change between your successful built and my today
sponsoring build failure ?

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1842437

Title:
  Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem
  with udev

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Users / systemd can fail to mount a filesystem by UUID
 (e.g., during boot, triggering emergency shell prompt)
 if the magic bytes for the nilfs filesystem are written
 to the right place in a partition of another filesystem,
 (for whatever reason or coincidence).

   * Note this can happen after the filesystem/mount is working
 correctly, so a change of behavior/problem can potentially
 be noticed when trying to mount the filesystem again, which
 can very well be the next time the system boots.

   * This happens because if udev blkid detects more than one
 filesystem, it does not print the UUID env vars required
 to create the /dev/disk/by-id symlinks and other things.

   * The fix enhances the check for valid nilfs superblock by
 specifically checking a value read from disk to be valid/
 within a value range, which addresses this one occurrence
 and prevents a lot more.

  [Test Case]

   * Synthetic test case written for this problem on comment #6.

  [Regression Potential]

   * Low.  The code is contained in the probe for the nilfs filesystem.

   * This just makes it be more restrictive about the possibly valid
 values for a few bytes read from disk (that now need to be within
 the acceptable range of valid values) so this only decreases false-
 positives, and cannot increase false-negatives of valid filesystems.

  [Original Description]

  The nilfs filesystem has a backup superblock at the end of the device.

  If the magic number is coincidentally found at the right position
  and the filesystem is on a partition/not-wholedisk device,
  the only check left is for checksum verification,
  which is explicitly ignored in 'udev built-in blkid'.

  This causes blkid to detect one actually valid filesystem with a
  superblock at the beginning of the device (e.g., ext4), and then
  an invalid nilfs2 filesystem due to a coincidental magic number
  at the end of the device.

  And this causes blkid to break out of the safeprobe routine
  (which expects a single filesystem to be detected), and not
  print the UUIDs, thus not creating /dev/disk/by-uuid/ links
  which prevent mounting the partition by-uuid at boot time,
  causing emergency shell/boot failures.

  This upstream fix resolved the problem by introducing a check
  for the 'bytes' paramenters in the superblock, which is read
  from disk, and turns out to have an out-of-range value.

  - 'liblkid: Add length check in probe_nilfs2 before crc32'
  
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2

  $ git describe --contains ac681a310c32319423297544833932f4d689a7a2
  v2.29-rc1~172

  Xenial, which is v2.27.1-based, is the only release that needs it.
  Bionic is v2.31.1, so all post-Xenial supported releases have it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1842437/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1842437] Re: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev

[Eric Desrochers]

@mfo,

Unfortunately the build ftbfs as follow:

https://launchpadlibrarian.net/443016838/buildlog_ubuntu-xenial-amd64.util-linux_2.27.1-6ubuntu3.9_BUILDING.txt.gz
...
masks:
script: openpty failed: No such file or directory
Makefile:11211: recipe for target 'check-recursive' failed
make[3]: *** [check-recursive] Terminated
debian/rules:177: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Terminated
debian/rules:54: recipe for target 'build' failed
make: *** [build] Terminated
E: Caught signal ‘Terminated’: terminating immediately
...

Investigation is going to be needed.

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1842437

Title:
  Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem
  with udev

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Users / systemd can fail to mount a filesystem by UUID
 (e.g., during boot, triggering emergency shell prompt)
 if the magic bytes for the nilfs filesystem are written
 to the right place in a partition of another filesystem,
 (for whatever reason or coincidence).

   * Note this can happen after the filesystem/mount is working
 correctly, so a change of behavior/problem can potentially
 be noticed when trying to mount the filesystem again, which
 can very well be the next time the system boots.

   * This happens because if udev blkid detects more than one
 filesystem, it does not print the UUID env vars required
 to create the /dev/disk/by-id symlinks and other things.

   * The fix enhances the check for valid nilfs superblock by
 specifically checking a value read from disk to be valid/
 within a value range, which addresses this one occurrence
 and prevents a lot more.

  [Test Case]

   * Synthetic test case written for this problem on comment #6.

  [Regression Potential]

   * Low.  The code is contained in the probe for the nilfs filesystem.

   * This just makes it be more restrictive about the possibly valid
 values for a few bytes read from disk (that now need to be within
 the acceptable range of valid values) so this only decreases false-
 positives, and cannot increase false-negatives of valid filesystems.

  [Original Description]

  The nilfs filesystem has a backup superblock at the end of the device.

  If the magic number is coincidentally found at the right position
  and the filesystem is on a partition/not-wholedisk device,
  the only check left is for checksum verification,
  which is explicitly ignored in 'udev built-in blkid'.

  This causes blkid to detect one actually valid filesystem with a
  superblock at the beginning of the device (e.g., ext4), and then
  an invalid nilfs2 filesystem due to a coincidental magic number
  at the end of the device.

  And this causes blkid to break out of the safeprobe routine
  (which expects a single filesystem to be detected), and not
  print the UUIDs, thus not creating /dev/disk/by-uuid/ links
  which prevent mounting the partition by-uuid at boot time,
  causing emergency shell/boot failures.

  This upstream fix resolved the problem by introducing a check
  for the 'bytes' paramenters in the superblock, which is read
  from disk, and turns out to have an out-of-range value.

  - 'liblkid: Add length check in probe_nilfs2 before crc32'
  
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2

  $ git describe --contains ac681a310c32319423297544833932f4d689a7a2
  v2.29-rc1~172

  Xenial, which is v2.27.1-based, is the only release that needs it.
  Bionic is v2.31.1, so all post-Xenial supported releases have it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1842437/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1842437] Re: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev

[Eric Desrochers]

** Tags added: sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1842437

Title:
  Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem
  with udev

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Users / systemd can fail to mount a filesystem by UUID
 (e.g., during boot, triggering emergency shell prompt)
 if the magic bytes for the nilfs filesystem are written
 to the right place in a partition of another filesystem,
 (for whatever reason or coincidence).

   * Note this can happen after the filesystem/mount is working
 correctly, so a change of behavior/problem can potentially
 be noticed when trying to mount the filesystem again, which
 can very well be the next time the system boots.

   * This happens because if udev blkid detects more than one
 filesystem, it does not print the UUID env vars required
 to create the /dev/disk/by-id symlinks and other things.

   * The fix enhances the check for valid nilfs superblock by
 specifically checking a value read from disk to be valid/
 within a value range, which addresses this one occurrence
 and prevents a lot more.

  [Test Case]

   * Synthetic test case written for this problem on comment #6.

  [Regression Potential]

   * Low.  The code is contained in the probe for the nilfs filesystem.

   * This just makes it be more restrictive about the possibly valid
 values for a few bytes read from disk (that now need to be within
 the acceptable range of valid values) so this only decreases false-
 positives, and cannot increase false-negatives of valid filesystems.

  [Original Description]

  The nilfs filesystem has a backup superblock at the end of the device.

  If the magic number is coincidentally found at the right position
  and the filesystem is on a partition/not-wholedisk device,
  the only check left is for checksum verification,
  which is explicitly ignored in 'udev built-in blkid'.

  This causes blkid to detect one actually valid filesystem with a
  superblock at the beginning of the device (e.g., ext4), and then
  an invalid nilfs2 filesystem due to a coincidental magic number
  at the end of the device.

  And this causes blkid to break out of the safeprobe routine
  (which expects a single filesystem to be detected), and not
  print the UUIDs, thus not creating /dev/disk/by-uuid/ links
  which prevent mounting the partition by-uuid at boot time,
  causing emergency shell/boot failures.

  This upstream fix resolved the problem by introducing a check
  for the 'bytes' paramenters in the superblock, which is read
  from disk, and turns out to have an out-of-range value.

  - 'liblkid: Add length check in probe_nilfs2 before crc32'
  
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2

  $ git describe --contains ac681a310c32319423297544833932f4d689a7a2
  v2.29-rc1~172

  Xenial, which is v2.27.1-based, is the only release that needs it.
  Bionic is v2.31.1, so all post-Xenial supported releases have it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1842437/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1843036] Re: [regression] SNMP missing disks in hrStorageTable

[Eric Desrochers]

** Description changed:

  [IMPACT]
  
  It has been brought to me the following:
  
  Some hosts have started to cause UNKNOWN return values in Nagios for
  checks on their disks. This is because these hosts are no longer
  reporting their disks as part of the SNMP table hrStorageTable
  (1.3.6.1.2.1.25.2.3.1 ) - only memory devices are being reported. The
  affected hosts that I have investigated received updates for SNMP:
  
  Upgrade package libsnmp-base 5.7.3+dfsg-1.8ubuntu3.1 to 
5.7.3+dfsg-1.8ubuntu3.2
  Upgrade package libsnmp30 5.7.3+dfsg-1.8ubuntu3.1 to 5.7.3+dfsg-1.8ubuntu3.2
  Upgrade package snmpd 5.7.3+dfsg-1.8ubuntu3.1 to 5.7.3+dfsg-1.8ubuntu3.2
  
  It seems likely that this package update is the cause.
  
  As debug info, you can see the difference between 2 nearly identical
  servers, one of which received the SNMP updates, and one which did not.
  You can see that the one without the update is returning disks in the
  SNMP output:
  
  # snmpwalk -v2c -cpublic arcprsmt01 1.3.6.1.2.1.25.2.3.1.3
  iso.3.6.1.2.1.25.2.3.1.3.1 = STRING: "Physical memory"
  iso.3.6.1.2.1.25.2.3.1.3.3 = STRING: "Virtual memory"
  iso.3.6.1.2.1.25.2.3.1.3.6 = STRING: "Memory buffers"
  iso.3.6.1.2.1.25.2.3.1.3.7 = STRING: "Cached memory"
  iso.3.6.1.2.1.25.2.3.1.3.8 = STRING: "Shared memory"
  iso.3.6.1.2.1.25.2.3.1.3.10 = STRING: "Swap space"
  iso.3.6.1.2.1.25.2.3.1.3.31 = STRING: "/"
  iso.3.6.1.2.1.25.2.3.1.3.37 = STRING: "/run"
  iso.3.6.1.2.1.25.2.3.1.3.39 = STRING: "/dev/shm"
  iso.3.6.1.2.1.25.2.3.1.3.40 = STRING: "/run/lock"
  iso.3.6.1.2.1.25.2.3.1.3.41 = STRING: "/sys/fs/cgroup"
  iso.3.6.1.2.1.25.2.3.1.3.67 = STRING: "/run/snapd/ns"
  iso.3.6.1.2.1.25.2.3.1.3.70 = STRING: 
"/var/lib/docker/containers/3cad3d36991b677c37b08b374a7bfeceddf36a6b6754edaa1ff687b00111a6b8/mounts/shm"
  iso.3.6.1.2.1.25.2.3.1.3.73 = STRING: 
"/var/lib/docker/containers/c605c4b76dea65d562ba024212a38e24fb710186c499187b6604478b7ff678e9/mounts/shm"
  iso.3.6.1.2.1.25.2.3.1.3.82 = STRING: "/run/user/2002"
  iso.3.6.1.2.1.25.2.3.1.3.253 = STRING: 
"/var/lib/docker/containers/dc74a157fbaaa284e0e5b8ca4afc88769bf625eb796d89a5d26f98a540cabf35/mounts/shm"
  iso.3.6.1.2.1.25.2.3.1.3.256 = STRING: 
"/var/lib/docker/containers/6ce6193433f9c1c95cccbfbbe08a3f3385bdbc4f2e3f0baa02d11baf3866dfd2/mounts/shm"
  iso.3.6.1.2.1.25.2.3.1.3.258 = STRING: "/run/user/1000"
  
  The other, which received SNMP updates, is returning only memory
  devices, such as swap and shmem:
  
  # snmpwalk -v2c -cpublic arcprsmt02 1.3.6.1.2.1.25.2.3.1.3
  iso.3.6.1.2.1.25.2.3.1.3.1 = STRING: "Physical memory"
  iso.3.6.1.2.1.25.2.3.1.3.3 = STRING: "Virtual memory"
  iso.3.6.1.2.1.25.2.3.1.3.6 = STRING: "Memory buffers"
  iso.3.6.1.2.1.25.2.3.1.3.7 = STRING: "Cached memory"
  iso.3.6.1.2.1.25.2.3.1.3.8 = STRING: "Shared memory"
  iso.3.6.1.2.1.25.2.3.1.3.10 = STRING: "Swap space"
  
  [Test Case]
  
  * Install snmp snmpd
  * Configure /etc/snmp/snmpd.conf by adding the following:
-  view   systemonly  included   .1.3.6.1.2.1.25.2.3.1.3
+  view   systemonly  included   .1.3.6.1.2.1.25.2.3.1.3
  * Restart snmpd
  * Use snmpwalk:
-  ** snmpwalk -v2c -cpublic localhost 1.3.6.1.2.1.25.2.3.1.3
+  ** snmpwalk -v2c -cpublic localhost 1.3.6.1.2.1.25.2.3.1.3
  
  Expected behavior is to see the disk as follow:
  "
  iso.3.6.1.2.1.25.2.3.1.3.1 = STRING: "Physical memory"
  iso.3.6.1.2.1.25.2.3.1.3.3 = STRING: "Virtual memory"
  iso.3.6.1.2.1.25.2.3.1.3.6 = STRING: "Memory buffers"
  iso.3.6.1.2.1.25.2.3.1.3.7 = STRING: "Cached memory"
  iso.3.6.1.2.1.25.2.3.1.3.8 = STRING: "Shared memory"
  iso.3.6.1.2.1.25.2.3.1.3.10 = STRING: "Swap space"
  iso.3.6.1.2.1.25.2.3.1.3.31 = STRING: "/"
  iso.3.6.1.2.1.25.2.3.1.3.33 = STRING: "/dev"
  iso.3.6.1.2.1.25.2.3.1.3.45 = STRING: "/dev/lxd"
  iso.3.6.1.2.1.25.2.3.1.3.46 = STRING: "/dev/.lxd-mounts"
  iso.3.6.1.2.1.25.2.3.1.3.63 = STRING: "/proc/sys/kernel/random/boot_id"
  iso.3.6.1.2.1.25.2.3.1.3.66 = STRING: "/dev/shm"
  iso.3.6.1.2.1.25.2.3.1.3.67 = STRING: "/run"
  iso.3.6.1.2.1.25.2.3.1.3.68 = STRING: "/run/lock"
  iso.3.6.1.2.1.25.2.3.1.3.69 = STRING: "/sys/fs/cgroup"
  "
  
  [Potential Regression]
  The fix has been tested by various impacted users, and feedback were all 
positives. Note that this fix a regression introduced by: 
https://bugs.launchpad.net/bugs/1835818
  
  [Other information]
  
  # Upstream commit:
  
https://github.com/net-snmp/net-snmp/commit/71e487212bd65839e7454df9701524d08cf0d74f
+ 
https://github.com/net-snmp/net-snmp/commit/bcb1a6b8afc444bbcd099a195e08f0b01cbc8f6b
  
  # git describe --contains 71e487212bd65839e7454df9701524d08cf0d74f
  v5.8.pre1
  
  # rmadison:
   net-snmp | 5.7.3+dfsg-1ubuntu4 | xenial   | source
   net-snmp | 5.7.3+dfsg-1ubuntu4.2   | xenial-security  | source
   net-snmp | 5.7.3+dfsg-1ubuntu4.2   | xenial-updates   | source
   net-snmp | 5.7.3+dfsg-1ubuntu4.3   | xenial-proposed  | source
   net-snmp | 5.7.3+dfsg-1.8ubuntu3   | bionic   | source
   net-snmp | 

[Sts-sponsors] [Bug 1843036] Re: [regression] SNMP missing disks in hrStorageTable

[Eric Desrochers]

** Description changed:

  [IMPACT]
  
  It has been brought to me the following:
  
  Some hosts have started to cause UNKNOWN return values in Nagios for
  checks on their disks. This is because these hosts are no longer
  reporting their disks as part of the SNMP table hrStorageTable
  (1.3.6.1.2.1.25.2.3.1 ) - only memory devices are being reported. The
  affected hosts that I have investigated received updates for SNMP:
  
  Upgrade package libsnmp-base 5.7.3+dfsg-1.8ubuntu3.1 to 
5.7.3+dfsg-1.8ubuntu3.2
  Upgrade package libsnmp30 5.7.3+dfsg-1.8ubuntu3.1 to 5.7.3+dfsg-1.8ubuntu3.2
  Upgrade package snmpd 5.7.3+dfsg-1.8ubuntu3.1 to 5.7.3+dfsg-1.8ubuntu3.2
  
  It seems likely that this package update is the cause.
  
  As debug info, you can see the difference between 2 nearly identical
  servers, one of which received the SNMP updates, and one which did not.
  You can see that the one without the update is returning disks in the
  SNMP output:
  
  # snmpwalk -v2c -cpublic arcprsmt01 1.3.6.1.2.1.25.2.3.1.3
  iso.3.6.1.2.1.25.2.3.1.3.1 = STRING: "Physical memory"
  iso.3.6.1.2.1.25.2.3.1.3.3 = STRING: "Virtual memory"
  iso.3.6.1.2.1.25.2.3.1.3.6 = STRING: "Memory buffers"
  iso.3.6.1.2.1.25.2.3.1.3.7 = STRING: "Cached memory"
  iso.3.6.1.2.1.25.2.3.1.3.8 = STRING: "Shared memory"
  iso.3.6.1.2.1.25.2.3.1.3.10 = STRING: "Swap space"
  iso.3.6.1.2.1.25.2.3.1.3.31 = STRING: "/"
  iso.3.6.1.2.1.25.2.3.1.3.37 = STRING: "/run"
  iso.3.6.1.2.1.25.2.3.1.3.39 = STRING: "/dev/shm"
  iso.3.6.1.2.1.25.2.3.1.3.40 = STRING: "/run/lock"
  iso.3.6.1.2.1.25.2.3.1.3.41 = STRING: "/sys/fs/cgroup"
  iso.3.6.1.2.1.25.2.3.1.3.67 = STRING: "/run/snapd/ns"
  iso.3.6.1.2.1.25.2.3.1.3.70 = STRING: 
"/var/lib/docker/containers/3cad3d36991b677c37b08b374a7bfeceddf36a6b6754edaa1ff687b00111a6b8/mounts/shm"
  iso.3.6.1.2.1.25.2.3.1.3.73 = STRING: 
"/var/lib/docker/containers/c605c4b76dea65d562ba024212a38e24fb710186c499187b6604478b7ff678e9/mounts/shm"
  iso.3.6.1.2.1.25.2.3.1.3.82 = STRING: "/run/user/2002"
  iso.3.6.1.2.1.25.2.3.1.3.253 = STRING: 
"/var/lib/docker/containers/dc74a157fbaaa284e0e5b8ca4afc88769bf625eb796d89a5d26f98a540cabf35/mounts/shm"
  iso.3.6.1.2.1.25.2.3.1.3.256 = STRING: 
"/var/lib/docker/containers/6ce6193433f9c1c95cccbfbbe08a3f3385bdbc4f2e3f0baa02d11baf3866dfd2/mounts/shm"
  iso.3.6.1.2.1.25.2.3.1.3.258 = STRING: "/run/user/1000"
  
  The other, which received SNMP updates, is returning only memory
  devices, such as swap and shmem:
  
  # snmpwalk -v2c -cpublic arcprsmt02 1.3.6.1.2.1.25.2.3.1.3
  iso.3.6.1.2.1.25.2.3.1.3.1 = STRING: "Physical memory"
  iso.3.6.1.2.1.25.2.3.1.3.3 = STRING: "Virtual memory"
  iso.3.6.1.2.1.25.2.3.1.3.6 = STRING: "Memory buffers"
  iso.3.6.1.2.1.25.2.3.1.3.7 = STRING: "Cached memory"
  iso.3.6.1.2.1.25.2.3.1.3.8 = STRING: "Shared memory"
  iso.3.6.1.2.1.25.2.3.1.3.10 = STRING: "Swap space"
  
  [Test Case]
  
- * Install/configure snmp snmpd
- * Run snmpwalk:
- (e.g. snmpwalk -v2c -cpublic localhost 1.3.6.1.2.1.25.2.3.1.3)
+ * Install snmp snmpd
+ * Configure /etc/snmp/snmpd.conf by adding the following:
+  view   systemonly  included   .1.3.6.1.2.1.25.2.3.1.3
+ * Restart snmpd
+ * Use snmpwalk:
+  ** snmpwalk -v2c -cpublic localhost 1.3.6.1.2.1.25.2.3.1.3
+ 
+ Expected behavior is to see the disk as follow:
+ "
+ iso.3.6.1.2.1.25.2.3.1.3.1 = STRING: "Physical memory"
+ iso.3.6.1.2.1.25.2.3.1.3.3 = STRING: "Virtual memory"
+ iso.3.6.1.2.1.25.2.3.1.3.6 = STRING: "Memory buffers"
+ iso.3.6.1.2.1.25.2.3.1.3.7 = STRING: "Cached memory"
+ iso.3.6.1.2.1.25.2.3.1.3.8 = STRING: "Shared memory"
+ iso.3.6.1.2.1.25.2.3.1.3.10 = STRING: "Swap space"
+ iso.3.6.1.2.1.25.2.3.1.3.31 = STRING: "/"
+ iso.3.6.1.2.1.25.2.3.1.3.33 = STRING: "/dev"
+ iso.3.6.1.2.1.25.2.3.1.3.45 = STRING: "/dev/lxd"
+ iso.3.6.1.2.1.25.2.3.1.3.46 = STRING: "/dev/.lxd-mounts"
+ iso.3.6.1.2.1.25.2.3.1.3.63 = STRING: "/proc/sys/kernel/random/boot_id"
+ iso.3.6.1.2.1.25.2.3.1.3.66 = STRING: "/dev/shm"
+ iso.3.6.1.2.1.25.2.3.1.3.67 = STRING: "/run"
+ iso.3.6.1.2.1.25.2.3.1.3.68 = STRING: "/run/lock"
+ iso.3.6.1.2.1.25.2.3.1.3.69 = STRING: "/sys/fs/cgroup"
+ "
  
  [Potential Regression]
- None, the fix has been tested by various impacted users, and feedbacks were 
all positives.
- This fix a regression introduced by : https://bugs.launchpad.net/bugs/1835818
+ The fix has been tested by various impacted users, and feedback were all 
positives. Note that this fix a regression introduced by: 
https://bugs.launchpad.net/bugs/1835818
  
  [Other information]
  
  # Upstream commit:
  
https://github.com/net-snmp/net-snmp/commit/71e487212bd65839e7454df9701524d08cf0d74f
  
  # git describe --contains 71e487212bd65839e7454df9701524d08cf0d74f
- v5.8.pre1~7^2~14^2~15^2~22
- 
+ v5.8.pre1
  
  # rmadison:
-  net-snmp | 5.7.3+dfsg-1ubuntu4 | xenial   | source
-  net-snmp | 5.7.3+dfsg-1ubuntu4.2   | xenial-security  | source
-  net-snmp | 5.7.3+dfsg-1ubuntu4.2   | xenial-updates   | source
-  net-snmp | 5.7.3+dfsg-1ubuntu4.3 

[Sts-sponsors] [Bug 1668771] Re: [SRU] systemd-resolved negative caching for extended period of time

[Eric Desrochers]

There is discussion to push systemd 241 to Eoan:
https://launchpad.net/bugs/1841790

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1668771

Title:
  [SRU] systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache
  the result for very long (infinity?). I have to restart systemd-
  resolved to have the negative caching purged.

  * After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

  [Test Case]

  * If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s 
(See 201d995),
  however, there are several use cases on which this condition is not 
acceptable (See #5552 comments)
  and the only workaround would be to disable cache entirely or flush it , 
which isn't optimal.

  * Configure /etc/systemd/resolved.conf as follows:

  Cache=yes (default)

  * Restart systemd-resolved (systemctl restart systemd-
  resolved.service)

  * Run a host/getent command against a entry that will return SERVFAIL
  and check the journalctl output to see that the reply gets served from
  cache.

  root@systemd-disco:/home/ubuntu# host www.no-record.cl
  Host www.montemar.cl not found: 2(SERVFAIL)
  root@systemd-disco:/home/ubuntu# journalctl -u systemd-resolved -n
  -- Logs begin at Fri 2019-07-12 18:09:42 UTC, end at Tue 2019-07-23 15:10:17 
UTC. --
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Transaction 6222 for 
 on scope dns on ens3/* now complete with 
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Sending response packet 
with id 61042 on interface 1/AF_INET.
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Freeing transaction 
6222.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Got DNS stub UDP query 
packet for id 53580
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Looking up RR for  
www.no-record.cl IN A.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: RCODE SERVFAIL cache 
hit for  www.no-record.cl IN A
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Transaction 58570 for < 
www.no-record.cl IN A> on scope dns on ens3/* now complete with  scope dns on ens3/.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Using feature level UDP 
for transaction 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending query packet 
with id 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Processing incoming 
packet on transaction 22382 (rcode=SERVFAIL).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Server returned error: 
SERVFAIL
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Not caching negative 
entry for: www.metaklass.org IN A, cache mode set to no-negative
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Transaction 22382 for 
 on scope dns on ens3/ now complete with from network 
(unsigned).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending response packet 
with id 31060 on interface 1/AF_INET.

  The following patch https://github.com/systemd/systemd/pull/13047
  implements the required changes.

  [Other Info]

  Note that systemd in Eoan is being upgraded to upstream 242, so I am
  not adding this to Eoan now, as I don't want to disturb the merge. If
  needed after the merge, I'll add to Eoan.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1668771/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

[Eric Desrochers]

** Tags removed: sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Bionic:
  Fix Committed
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  Fix Committed
Status in makedumpfile source package in Eoan:
  Fix Released

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

  [Other information]

  Salsa Debian commit:
  
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

[Eric Desrochers]

Hi Andrew Cloke,

Yes, I'm currently sponsoring D/B for cascardo/gpicolli.

Disco is already uploaded waiting for SRU team approval:
https://launchpad.net/ubuntu/disco/+queue?queue_state=1_text=makedumpfile

Bionic debdiff needs some rework before I do the final upload.

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  Fix Released

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

  [Other information]

  Salsa Debian commit:
  
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

[Eric Desrochers]

** Tags added: sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  Fix Committed
Status in makedumpfile source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

  [Other information]

  Salsa Debian commit:
  
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1834340] Re: Regression for GMail after libssl upgrade with TLSv1.3

[Eric Desrochers]

** Also affects: asterisk (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: mailsync (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: prayer (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1834340

Title:
  Regression for GMail after libssl upgrade with TLSv1.3

Status in asterisk package in Ubuntu:
  New
Status in mailsync package in Ubuntu:
  New
Status in php-imap package in Ubuntu:
  Invalid
Status in prayer package in Ubuntu:
  New
Status in uw-imap package in Ubuntu:
  In Progress
Status in asterisk source package in Bionic:
  New
Status in mailsync source package in Bionic:
  New
Status in php-imap source package in Bionic:
  Invalid
Status in prayer source package in Bionic:
  New
Status in uw-imap source package in Bionic:
  In Progress
Status in asterisk source package in Disco:
  New
Status in mailsync source package in Disco:
  New
Status in php-imap source package in Disco:
  Invalid
Status in prayer source package in Disco:
  New
Status in uw-imap source package in Disco:
  In Progress
Status in asterisk source package in Eoan:
  New
Status in mailsync source package in Eoan:
  New
Status in php-imap source package in Eoan:
  Invalid
Status in prayer source package in Eoan:
  New
Status in uw-imap source package in Eoan:
  In Progress

Bug description:
  [Impact]

   * Users of libc-client2007e (e.g., php7.x-imap) can no longer
     connect to GMail on Bionic and later, after introduction of
     TLSv1.3 with OpenSSL 1.1.1 (normal upgrade path in Bionic).

   * GMail requires Server Name Indication (SNI) to be set when
     TLSv1.3 is used, otherwise the server provided certificate
     fails verification in the client and connection is aborted.

   * The fix is to set SNI to the hostname that the client will
     perform verification on. The change is only enabled if the
     client is built with OpenSSL 1.1.1 or later (i.e., TLSv1.3
     support) so not to affect pre- TLSv1.3 support's behavior.

   * However it is functional nonetheless if the client is built
     with OpenSSL 1.1.1 or later but an earlier TLS version ends
     up used due to the handshake/negotiation/server TLS support
     (e.g., TLSv1.2); this shouldn't be a problem per test below.

   * Regression testing happened with a crawled list of IMAP/POP
     SSL servers (167 servers), and no regressions were observed.
     Actually, one more email provider/server has been fixed too.

   * OpenSSL-only demonstration with -(no)servername:

     $ echo QUIT \
   | openssl s_client \
     -connect imap.gmail.com:993 \
     -verify_hostname imap.gmail.com \
     -noservername `# or -servername imap.gmail.com` \
     -tls1_3 -brief 2>&1 \
   | grep -i ^verif

    Output with '-noservername':

    verify error:num=18:self signed certificate
    verify error:num=62:Hostname mismatch
    Verification error: Hostname mismatch

    Output with '-servername imap.gmail.com'

    Verification: OK
    Verified peername: imap.gmail.com

  [Test Case]

   * Commands:

     $ sudo apt install uw-mailutils
     $ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"

     $ sudo apt install php7.2-cli php7.2-imap
     $ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", 
"password");'

   * Before:

     $ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
     Certificate failure for imap.googlemail.com: self signed certificate: 
/OU=No SNI provided; please fix your client./CN=invalid2.invalid
     Certificate failure for imap.googlemail.com: self signed certificate: 
/OU=No SNI provided; please fix your client./CN=invalid2.invalid

     $ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", 
"password");'
     PHP Warning:  imap_open(): Couldn't open stream 
{imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
     PHP Notice:  Unknown: Certificate failure for imap.gmail.com: self signed 
certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid 
(errflg=2) in Unknown on line 0

   * After:

     $ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
     {ce-in-f16.1e100.net/imap} username:
     ^C

     $ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", 
"password");'
     PHP Warning:  imap_open(): Couldn't open stream 
{imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
     PHP Notice:  Unknown: Retrying PLAIN authentication after [ALERT] Invalid 
credentials (Failure) (errflg=1) in Unknown on line 0
     PHP Notice:  Unknown: Retrying PLAIN authentication after [ALERT] Invalid 
credentials (Failure) (errflg=1) in Unknown on line 0
     PHP Notice:  Unknown: Can not authenticate to IMAP server: [ALERT] Invalid 
credentials (Failure) (errflg=2) in Unknown on line 0

   * Regression testing scripts/results are 

[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

[Eric Desrochers]

makedumpfile merge to "1:1.6.6-2ubuntu1" sponsored in Eoan.

I appended the changelog to add the entry block[0] currently found in 
eoan-proposed that was missing to keep track of everything that has been done 
on the package:
Since it was made by cascardo before 1:1.6.5-1ubuntu3 exist.

Note:
- I didn't want this to be a blocker for this upload due to many factors, but 
cascardo/gpicolli, can you guys have a look before the feature freeze[1] at 
this lintian report[2], it would be awesome. It's good to make the code more 
modern, but debian packaging too, especially when time permit like now (devel 
release).

[0] 
makedumpfile (1:1.6.5-1ubuntu3) eoan; urgency=medium

  * debian/kdump-config.in:
- Add kdump retry/delay mechanism when dumping over network.
  (LP: #1681909)

 -- gpicc...@canonical.com (Guilherme G. Piccoli)  Thu, 04 Jul 2019
15:20:53 -0300

[1] - https://wiki.ubuntu.com/EoanErmine/ReleaseSchedule

[2] - https://pastebin.canonical.com/p/dWYkNhwjCb/

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  Fix Committed
Status in makedumpfile source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

  [Other information]

  Salsa Debian commit:
  
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1838358] Re: Ibus causes gnome-shell to freeze when password fields are selected in Firefox

[Eric Desrochers]

Sponsored for Bionic.

* Patch already found in Cosmic onwards.
* Patch has been tested pre-SRU with an impact user.
* Nitpick: I have added the upstream bug link in the DEP3 header -> 
+Bug-Upstream: https://github.com/ibus/ibus/issues/2002

Thanks Matthew !

** Bug watch added: github.com/ibus/ibus/issues #2002
   https://github.com/ibus/ibus/issues/2002

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1838358

Title:
  Ibus causes gnome-shell to freeze when password fields are selected in
  Firefox

Status in ibus package in Ubuntu:
  Fix Released
Status in ibus source package in Bionic:
  In Progress

Bug description:
  [Impact]

  The following has been seen in a VMware Horizon VDI. I cannot reproduce this
  issue myself.

  When a user interacts with any password field in Firefox, gnome-shell
  and Firefox both freeze and the system becomes unusable. If you ssh
  into the system and terminate Firefox, gnome-shell unfreezes.

  This only happens when the environment variable GTK_IM_MODULE is set to 
"ibus". If you unset the variable, or change it to
  GTK_IM_MODULE=gtk-im-context-simple and then start Firefox, everything works 
as intended.

  This has been seen before with gnome-shell 3.28.4-0ubuntu18.04.1, ibus
  1.5.17-3ubuntu4 and Firefox versions starting with 
68.0+build3-0ubuntu0.18.04.1

  Note: Chrome[ium] and other applications do not trigger it, and it cannot be
  reproduced in other desktop environments.

  This seems to be an interaction issue between ibus and gnome-shell.

  
  [Test Case]

  Launch firefox from within a gnome-session, making sure the
  GTK_IM_MODULE is set to "ibus". Note, this is the default value.

  $ env GTK_IM_MODULE="ibus" firefox

  Navigate to any website which has a password field. Wikipedia or
  Reddit will do.

  Click a password field and attempt to enter text. Firefox and gnome-
  shell both lock up and stay frozen for an extended period of time.

  Now, try it with the fix by enabling:

  $ env IBUS_DISCARD_PASSWORD=1 firefox

  When you enter text into a password field, ibus should directly pass through
  the text and the problem will be solved.

  We can also ask it to always apply for a specific application with:

  $ export IBUS_DISCARD_PASSWORD_APPS="firefox"
  $ firefox

  Again, when you enter text into a password input field, the problem will be
  solved.

  Test package is available here:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf235370-test

  Please test with the revised version,
  1.5.17-3ubuntu4+sf235370v20190731b1.

  [Regression Potential]

  This change has a low risk of regression, because the default behaviour is
  unchanged. To be able to use the password input field discard functionality, 
a user has to explicitly set an environment variable for the specific process, 
or set a regex that matches a process name.

  This means the fix is not enabled by default on any machines, and will
  only be utilised by those suffering problems and go and manually set
  environment variables or have their system administrator enable the
  environment variables permanently.

  This commit is present in upstream ibus from version ibus-1.5.19
  onward, and is currently present in cosmic, disco and eoan.

  If a regression occurs, users can ensure that the environment
  variables are unset and continue working.

  [Other info]

  * This patch is functionally the same as ibus-xx-f19-password.patch,
  but just hides the features behind environment variables.

  * When ibus is built with the patch ibus-xx-f19-password.patch which
  was dropped in ibus-1.5.17-2, the problem is solved.

  Instead of using ibus-xx-f19-password.patch, we will instead fix it with
  upstream commit f328fd67f479faa46ca87bf3c85eed7080ec5ec0:

  https://github.com/ibus/ibus/commit/f328fd67f479faa46ca87bf3c85eed7080ec5ec0

  Subject: client/gtk2: Add IBUS_DISCARD_PASSWORD for firefox and chrome
  Author: fujiwarat 

  This implements the password discard functionality found in
  ibus-xx-f19-password.patch and places it behind two environment variables,
  IBUS_DISCARD_PASSWORD and IBUS_DISCARD_PASSWORD_APPS.

  IBUS_DISCARD_PASSWORD is for a single process, and IBUS_DISCARD_PASSWORD_APPS
  lets you set a regex of process names to filter and enable the fix for.

  If IBUS_DISCARD_PASSWORD is set or IBUS_DISCARD_PASSWORD_APPS is set
  with the process name which input is being placed into password
  fields, ibus will pass through the input to the application without
  any processing.

  * This only affect Bionic

  - Upstream first introduction:
  $ git describe --contains  f328fd67f479faa46ca87bf3c85eed7080ec5ec0
  1.5.19~7

  - Ubuntu ibus current version found in the archive:
  $ rmadison ibus
   ==> ibus | 1.5.17-3ubuntu4   | bionic 
   ibus | 1.5.19-1ubuntu1   | cosmic 
   ibus | 1.5.19-1ubuntu2   | disco  
   ibus | 1.5.19-4ubuntu2   | eoan

To 

[Sts-sponsors] [Bug 1838358] Re: Ibus causes gnome-shell to freeze when password fields are selected in Firefox

[Eric Desrochers]

** Description changed:

  [Impact]
  
  The following has been seen in a VMware Horizon VDI. I cannot reproduce this
  issue myself.
  
  When a user interacts with any password field in Firefox, gnome-shell
  and Firefox both freeze and the system becomes unusable. If you ssh into
  the system and terminate Firefox, gnome-shell unfreezes.
  
  This only happens when the environment variable GTK_IM_MODULE is set to 
"ibus". If you unset the variable, or change it to
  GTK_IM_MODULE=gtk-im-context-simple and then start Firefox, everything works 
as intended.
  
  This has been seen before with gnome-shell 3.28.4-0ubuntu18.04.1, ibus
  1.5.17-3ubuntu4 and Firefox versions starting with 
68.0+build3-0ubuntu0.18.04.1
  
  Note: Chrome[ium] and other applications do not trigger it, and it cannot be
  reproduced in other desktop environments.
  
  This seems to be an interaction issue between ibus and gnome-shell.
  
- [Fix]
  
- When ibus is built with the patch ibus-xx-f19-password.patch which was
- dropped in ibus-1.5.17-2, the problem is solved.
- 
- Instead of using ibus-xx-f19-password.patch, we will instead fix it with
- upstream commit f328fd67f479faa46ca87bf3c85eed7080ec5ec0:
- 
- https://github.com/ibus/ibus/commit/f328fd67f479faa46ca87bf3c85eed7080ec5ec0
- 
- Subject: client/gtk2: Add IBUS_DISCARD_PASSWORD for firefox and chrome 
- Author: fujiwarat 
- 
- This implements the password discard functionality found in 
- ibus-xx-f19-password.patch and places it behind two environment variables,
- IBUS_DISCARD_PASSWORD and IBUS_DISCARD_PASSWORD_APPS.
- 
- IBUS_DISCARD_PASSWORD is for a single process, and IBUS_DISCARD_PASSWORD_APPS
- lets you set a regex of process names to filter and enable the fix for.
- 
- If IBUS_DISCARD_PASSWORD is set or IBUS_DISCARD_PASSWORD_APPS is set with the
- process name which input is being placed into password fields, ibus will pass
- through the input to the application without any processing.
- 
- [Testcase]
+ [Test Case]
  
  Launch firefox from within a gnome-session, making sure the
  GTK_IM_MODULE is set to "ibus". Note, this is the default value.
  
  $ env GTK_IM_MODULE="ibus" firefox
  
  Navigate to any website which has a password field. Wikipedia or Reddit
  will do.
  
  Click a password field and attempt to enter text. Firefox and gnome-
  shell both lock up and stay frozen for an extended period of time.
  
  Now, try it with the fix by enabling:
  
  $ env IBUS_DISCARD_PASSWORD=1 firefox
  
  When you enter text into a password field, ibus should directly pass through
  the text and the problem will be solved.
  
  We can also ask it to always apply for a specific application with:
  
  $ export IBUS_DISCARD_PASSWORD_APPS="firefox"
- $ firefox 
+ $ firefox
  
  Again, when you enter text into a password input field, the problem will be
  solved.
  
  Test package is available here:
  
  https://launchpad.net/~mruffell/+archive/ubuntu/sf235370-test
  
  Please test with the revised version,
  1.5.17-3ubuntu4+sf235370v20190731b1.
  
  [Regression Potential]
  
  This change has a low risk of regression, because the default behaviour is
- unchanged. To be able to use the password input field discard functionality,
- a user has to explicitly set an environment variable for the specific 
process, or set a regex that matches a process name.
+ unchanged. To be able to use the password input field discard functionality, 
a user has to explicitly set an environment variable for the specific process, 
or set a regex that matches a process name.
  
  This means the fix is not enabled by default on any machines, and will
  only be utilised by those suffering problems and go and manually set
  environment variables or have their system administrator enable the
  environment variables permanently.
  
- This commit is present in upstream ibus from version ibus-1.5.19 onward, and
- is currently present in cosmic, disco and eoan. 
+ This commit is present in upstream ibus from version ibus-1.5.19 onward,
+ and is currently present in cosmic, disco and eoan.
  
- If a regression occurs, users can ensure that the environment variables are
- unset and continue working.
+ If a regression occurs, users can ensure that the environment variables
+ are unset and continue working.
  
- [Notes]
+ [Other info]
  
- This patch is functionally the same as ibus-xx-f19-password.patch, but just
- hides the features behind environment variables.
+ * This patch is functionally the same as ibus-xx-f19-password.patch, but
+ just hides the features behind environment variables.
+ 
+ * When ibus is built with the patch ibus-xx-f19-password.patch which was
+ dropped in ibus-1.5.17-2, the problem is solved.
+ 
+ Instead of using ibus-xx-f19-password.patch, we will instead fix it with
+ upstream commit f328fd67f479faa46ca87bf3c85eed7080ec5ec0:
+ 
+ https://github.com/ibus/ibus/commit/f328fd67f479faa46ca87bf3c85eed7080ec5ec0
+ 
+ Subject: client/gtk2: Add IBUS_DISCARD_PASSWORD for firefox and chrome

[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

[Eric Desrochers]

Quick update:

It seems to fail the same way with 1:1.6.5-1ubuntu2, so NOT introduced
by this SRU via 1:1.6.5-1ubuntu3

We still have to test the autopkgtest locally on ppc64el arch and
instrument/monitor the test to understand why no crash is found in
/var/crash at the end of the test.

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  Fix Committed
Status in makedumpfile source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

  [Other information]

  Salsa Debian commit:
  
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

[Eric Desrochers]

Quick update

# excuses... page:

makedumpfile (1:1.6.5-1ubuntu2 to 1:1.6.5-1ubuntu3)
Maintainer: Louis Bouchard
0 days old
autopkgtest for kpatch/0.5.0-0ubuntu2: amd64: Ignored failure
autopkgtest for makedumpfile/1:1.6.5-1ubuntu3: amd64: Pass, arm64: Pass, armhf: 
Pass, i386: Pass, ppc64el: Regression ♻ , s390x: Ignored failure
Not considered

# logs
.
makedumpfile: crash test: checking for crash file
makedumpfile: ERROR: crash test: Found no compressed dumps
.

gpicolli and I are investigating the root cause.

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  Fix Committed
Status in makedumpfile source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

  [Other information]

  Salsa Debian commit:
  
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

[Eric Desrochers]

Sponsored for 'Eoan'.

We'll be able to start the SRU sponsoring as soon as it lands in
-releases.

Notes:
* Patch lands in debian unstable ~2 weeks ago : 
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

* Patch have been "Signed-off-by" by a member of the Ubuntu kernel team.

** Changed in: makedumpfile (Ubuntu Eoan)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  Fix Committed
Status in makedumpfile source package in Xenial:
  In Progress
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

  [Other information]

  Salsa Debian commit:
  
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

[Eric Desrochers]

** Description changed:

  [Impact]
  
  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware delays,
  usually not fixable from drivers. Some adapters known to act like this
  are bnx2x, tg3 and ixgbe.
  
  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network dump,
  kdump will retry some times and sleep between the attempts in order to
  exclude the case of NICs that aren't ready yet but will soon be able to
  transmit packets.
  
  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.
  
  [Test case]
  
  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.
  
  [Regression potential]
  
  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.
+ 
+ [Other information]
+ 
+ Salsa Debian commit:
+ 
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  In Progress
Status in makedumpfile source package in Xenial:
  In Progress
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  In Progress

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

  [Other information]

  Salsa Debian commit:
  
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

[Eric Desrochers]

Marking Cosmic as 'Won't fix'.

Ubuntu 18.10 (Cosmic Cuttlefish) End Of Life reached on July 18 2019.


** Changed in: makedumpfile (Ubuntu Cosmic)
   Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  In Progress
Status in makedumpfile source package in Xenial:
  In Progress
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  In Progress

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1821252] Re: systemctl set-default breaks recovery mode

[Eric Desrochers]

Sponsored in stable release for D/C/B/X.

Note: The fix is already merged into Debian and Eoan (Current devel
release).

Thanks Steven for your patch contribution, and Ioanna for producing the
debdiffs and all the SRU related work.

Regards,
Eric

** Tags removed: sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1821252

Title:
  systemctl set-default breaks recovery mode

Status in friendly-recovery package in Ubuntu:
  Fix Released
Status in friendly-recovery source package in Xenial:
  In Progress
Status in friendly-recovery source package in Bionic:
  In Progress
Status in friendly-recovery source package in Cosmic:
  In Progress
Status in friendly-recovery source package in Disco:
  In Progress
Status in friendly-recovery source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * A recovery mode boot is effectively a normal boot on any system
  that has ever had systemctl set-default run on it, i.e., the recovery
  kernel parameter does nothing. In particular, ubiquity calls systemctl
  set-default as part of the oem-config process, rendering recovery mode
  useless on any oem-configured machine.

   * This is a regression from previous behavior, where recovery mode
  would override a user-set default target.

   * This would also restore the intuitive behavior of this package. It
  is intended to be run by setting a kernel parameter for a one-time
  boot, and should therefore take priority over any other settings (such
  as configuring a different default target).

  [Test Case]

   * Run systemctl set-default multi-user.target

   * Use the GRUB menu to try to boot into recovery mode

   * Observe that you end up at a TTY, not in recovery mode

  [Regression Potential]

   * Possible regression if someone set recovery as a default kernel
  parameter, then relied on the default systemd target to override it.
  This seems like an unlikely use-case.

  [Original Description]

  Fresh Ubuntu 18.04.2 server install

  Try to boot to recovery mode from GRUB. Works correctly.

  Use systemctl to set a different default, say systemctl set-default
  multi-user.target

  Try to boot to recovery mode from GRUB. End up at getty and not the
  recovery menu.

  Delete /etc/systemd/system/default.target* and recovery mode works
  normally again.

  I believe this can be fixed by changing normaldir to earlydir in the
  generator.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/1821252/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1821252] Re: systemctl set-default breaks recovery mode

[Eric Desrochers]

xnox will upload to debian experimental and will sync to eoan.
I'll take care of the stable release once the above ^ is completed.

- Eric

** Tags added: sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1821252

Title:
  systemctl set-default breaks recovery mode

Status in friendly-recovery package in Ubuntu:
  In Progress
Status in friendly-recovery source package in Xenial:
  In Progress
Status in friendly-recovery source package in Bionic:
  In Progress
Status in friendly-recovery source package in Cosmic:
  In Progress
Status in friendly-recovery source package in Disco:
  In Progress
Status in friendly-recovery source package in Eoan:
  In Progress

Bug description:
  [Impact]

   * A recovery mode boot is effectively a normal boot on any system
  that has ever had systemctl set-default run on it, i.e., the recovery
  kernel parameter does nothing. In particular, ubiquity calls systemctl
  set-default as part of the oem-config process, rendering recovery mode
  useless on any oem-configured machine.

   * This is a regression from previous behavior, where recovery mode
  would override a user-set default target.

   * This would also restore the intuitive behavior of this package. It
  is intended to be run by setting a kernel parameter for a one-time
  boot, and should therefore take priority over any other settings (such
  as configuring a different default target).

  [Test Case]

   * Run systemctl set-default multi-user.target

   * Use the GRUB menu to try to boot into recovery mode

   * Observe that you end up at a TTY, not in recovery mode

  [Regression Potential]

   * Possible regression if someone set recovery as a default kernel
  parameter, then relied on the default systemd target to override it.
  This seems like an unlikely use-case.

  [Original Description]

  Fresh Ubuntu 18.04.2 server install

  Try to boot to recovery mode from GRUB. Works correctly.

  Use systemctl to set a different default, say systemctl set-default
  multi-user.target

  Try to boot to recovery mode from GRUB. End up at getty and not the
  recovery menu.

  Delete /etc/systemd/system/default.target* and recovery mode works
  normally again.

  I believe this can be fixed by changing normaldir to earlydir in the
  generator.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/1821252/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1818527] Re: Stub resolver cache is corrupted

[Eric Desrochers]

** Description changed:

  [Impact]
  systemd-resolved fails to resolve A records
  
  [Description]
  When systemd-resolve caches a non-existent CNAME record for a specific 
domain, further attempts at resolving A records for that same domain  fail. 
This has been fixed upstream in v240.
  
  Upstream commit: https://github.com/systemd/systemd/commit/3740146a4cbd
  
  $ git describe --contains 3740146a4cbd
  v240~839
  
  $ rmadison systemd --arch amd64
-  systemd | 229-4ubuntu4 | xenial  | source, ...
-  systemd | 229-4ubuntu21.21 | xenial-security | source, ...
-  systemd | 229-4ubuntu21.21 | xenial-updates  | source, ...
-  systemd | 237-3ubuntu10| bionic  | source, ...
-  systemd | 237-3ubuntu10.19 | bionic-security | source, ...
-  systemd | 237-3ubuntu10.21 | bionic-updates  | source, ...
-  systemd | 237-3ubuntu10.22 | bionic-proposed | source, ...
-  systemd | 239-7ubuntu10| cosmic  | source, ...
-  systemd | 239-7ubuntu10.12 | cosmic-security | source, ...
-  systemd | 239-7ubuntu10.13 | cosmic-updates  | source, ...
-  systemd | 239-7ubuntu10.14 | cosmic-proposed | source, ...
-  systemd | 240-6ubuntu5 | disco   | source, ...
-  systemd | 240-6ubuntu5.1   | disco-proposed  | source, ...
-  systemd | 240-6ubuntu9 | eoan| source, ...
+  systemd | 229-4ubuntu4 | xenial  | source, ...
+  systemd | 229-4ubuntu21.21 | xenial-security | source, ...
+  systemd | 229-4ubuntu21.21 | xenial-updates  | source, ...
+  systemd | 237-3ubuntu10| bionic  | source, ...
+  systemd | 237-3ubuntu10.19 | bionic-security | source, ...
+  systemd | 237-3ubuntu10.21 | bionic-updates  | source, ...
+  systemd | 237-3ubuntu10.22 | bionic-proposed | source, ...
+  systemd | 239-7ubuntu10| cosmic  | source, ...
+  systemd | 239-7ubuntu10.12 | cosmic-security | source, ...
+  systemd | 239-7ubuntu10.13 | cosmic-updates  | source, ...
+  systemd | 239-7ubuntu10.14 | cosmic-proposed | source, ...
+  systemd | 240-6ubuntu5 | disco   | source, ...
+  systemd | 240-6ubuntu5.1   | disco-proposed  | source, ...
+  systemd | 240-6ubuntu9 | eoan| source, ...
  
  Despite the package versions above, only Bionic is affected. Cosmic
  already includes a backported fix, and Xenial doesn't seem affected due
  to resolvconf handling DNS resolution.
  
  [Test Case]
  Flush resolved's caches and try resolving a non-existent CNAME record. 
Further resolution attempts for the corresponding A record will fail:
  
+ #1 
+ On a Bionic host:
  $ systemd-resolve --flush-caches
  $ dig github.com CNAME
  $ dig github.com A
+ 
+ #2 
+ On a Bionic host:
+ $ systemd-resolve --flush-caches
+ $ dig github.com CNAME
+ $ dig github.com A
+ 
+ Build a lxd with Cosmic/Disoo/Eoan and late (systemd-240):
+ $ lxc launch ubuntu:cosmic cosmiclxd
+ $ lxd exec cosmiclxd bash
+ $ dig github.com A
+ 
+ Despite the fact that Cosmic and late has the proper fix,
+ Cosmic/Disco/Eoan container can suffer from the bug too if the host is
+ Bionic (container uses the host as a DNS resolver).
+ 
+ So you may face the problem inside Cosmic/Disco/Eoan inside a container,
+ but it's still the same Bionic systemd bug.
  
  [Regression Potential]
  The regression potential for this fix should be very low, as it's a direct 
cherry-pick from upstream systemd. It has seen extensive testing  in both 
upstream and other Ubuntu releases, and was verified for Bionic through 
autopkgtests.
  
  
  
  [Original Description]
  
  It seems that when systemd-resolve cache an non-existent CNAME record
  for a domain, any attempt to resolve A record for the same domain fail.
  
  systemd version the issue has been seen with
  Installed: 237-3ubuntu10.13
  Used distribution
  
  Distributor ID: Ubuntu
  Description: Ubuntu 18.04.2 LTS
  Release: 18.04
  Codename: bionic
  
  Expected behaviour you didn't see
  
  Return A record for a domain when it exists.
  
  Unexpected behaviour you saw
  
  Resolution failed.
  
  Steps to reproduce the problem
  
  Whait for 1 minutes (github.com TTL for A record)
  
  Try to resolv github.com CNAME record dig CNAME github.com
  
  This will return an empty result.
  
  Then try to resolve github.com A record dig A github.com.
  
  This will now return empty result unless you restart systemd-resolved or
  wait for cache expiration.
  
  At the same time using another DNS will resolve correctly dig A
  github.com @8.8.8.8.
  
  Exemple :
  
  Wait for 1 minutes to let cache expire, then run
  
  dig CNAME github.com
  dig A github.com
  # no result
  dig A github.com @8.8.8.8
  # ;; ANSWER SECTION:
  # github.com. 59  IN  A   192.30.253.113
  # github.com. 59  IN  A   192.30.253.112
  
  PS: Don't forget to restart systemd-resolve, before trying to post an
  answer.
  
  This bug was first reported in github
  https://github.com/systemd/systemd/issues/11789 

[Sts-sponsors] [Bug 1817321] Re: installer does not support iSCSI iBFT

[Eric Desrochers]

Sponsored for Bionic 'd-i'.

The new kernel version used "4.18.0-20" (aka HWE) and "4.15.0-50" are
both available in the archive for Bionic in -updates.

$ rmadison linux-image-4.18.0-20-generic
 linux-image-4.18.0-20-generic | 4.18.0-20.21~18.04.1 | bionic-security | 
amd64, arm64, armhf, i386, ppc64el, s390x
 linux-image-4.18.0-20-generic | 4.18.0-20.21~18.04.1 | bionic-updates  | 
amd64, arm64, armhf, i386, ppc64el, s390x

$ rmadison linux-image-4.15.0-50-generic
 linux-image-4.15.0-50-generic | 4.15.0-50.54 | bionic-security | 
amd64, arm64, armhf, i386, ppc64el, s390x
 linux-image-4.15.0-50-generic | 4.15.0-50.54 | bionic-updates  | 
amd64, arm64, armhf, i386, ppc64el, s390x

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1817321

Title:
  installer does not support iSCSI iBFT

Status in debian-installer package in Ubuntu:
  Fix Released
Status in hw-detect package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in partman-iscsi package in Ubuntu:
  Fix Released
Status in debian-installer source package in Bionic:
  In Progress
Status in hw-detect source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Fix Released
Status in partman-iscsi source package in Bionic:
  Fix Committed
Status in debian-installer source package in Cosmic:
  In Progress
Status in hw-detect source package in Cosmic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Released
Status in partman-iscsi source package in Cosmic:
  Fix Committed
Status in debian-installer source package in Disco:
  In Progress
Status in hw-detect source package in Disco:
  Fix Committed
Status in linux source package in Disco:
  Fix Released
Status in partman-iscsi source package in Disco:
  Fix Committed
Status in debian-installer source package in Eoan:
  Fix Released
Status in hw-detect source package in Eoan:
  Fix Released
Status in linux source package in Eoan:
  Fix Released
Status in partman-iscsi source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * It's not possible to access iBFT (iSCSI Boot Firmware Table) information
     (settings for network interface, initiator, and target) in the installer
     because the 'iscsi_ibft' module is not present in udeb packages.

   * Even if it was, the installer does not handle iBFT information at all,
     thus any settings are ignored, and iSCSI-related configuration has to
     be done manually or with workarounds.

   * This impacts user-experience and automatic installation on systems and
     deployments which actually do provide the iBFT feature and information,
     but cannot use it practically.

   * With proper iBFT support in the installer (kernel module in udeb package
     and automatic iSCSI-related configuration) users will be able to rely on
     iBFT to install/deploy Ubuntu on their servers and datacenters.

   * These fixes add the 'iscsi_ibft' kernel module in the scsi-modules udeb,
     and configure network/iSCSI according to iBFT information in disk-detect.

     This is done in disk-detect so that the iSCSI LUNs are detected as disks
     (useful in case of no other disks in the system so the installer doesn't
     complain nor wait too long) and that any partman-related preseed options
     are not required and may be still available for the user.

  [Test Case]

   * linux package / kernel module in udeb:

     $ dpkg-deb -c scsi-modules_*.udeb | grep iscsi_ibft.ko

     Check the module loads in the installer environment.
     See comment with example for disco.

   * d-i/hw-detect/partman-iscsi package:
     See comments 11, 12, 13.

  [Regression Potential]

   * linux package: low, the kernel module is not loaded by default,
     and only checks whether iBFT information is present in firmware,
     then exposes that in sysfs in read-only mode.

   * d-i/hw-detect/partman-iscsi:
     - d-i: kernel version update to include iscsi_ibft module,
    based on kernel released to -updates plus one week
    monitoring bug reports -- it should be OK.
    Tested on amd64/i386/arm64/ppc64el on QEMU, plus amd64
    on baremetal -- see comment 11.
     - hw-detect: low, the changes are enabled by a preseed option.
  see comment 12.
     - partman-iscsi: low, simple changes, plus one fix that has
  been tested in detail, and falls back to
  previous behavior if it fails.
  see comment 13.

  [Other Info]

   * This has been verified both by the developer with a simple iSCSI
     iBFT environment (2 VMs: iSCSI target & initiator with UEFI+iPXE)
     and by an user with system/firmware that supports iBFT for iSCSI.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1817321/+subscriptions

-- 

[Sts-sponsors] [Bug 1817321] Re: installer does not support iSCSI iBFT

[Eric Desrochers]

Sponsored for Disco 'd-i'. - No-Change rebuild
Will review C/B  'd-i' soon (which involve master kernel change)

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1817321

Title:
  installer does not support iSCSI iBFT

Status in debian-installer package in Ubuntu:
  Fix Released
Status in hw-detect package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in partman-iscsi package in Ubuntu:
  Fix Released
Status in debian-installer source package in Bionic:
  In Progress
Status in hw-detect source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Fix Released
Status in partman-iscsi source package in Bionic:
  Fix Committed
Status in debian-installer source package in Cosmic:
  In Progress
Status in hw-detect source package in Cosmic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Released
Status in partman-iscsi source package in Cosmic:
  Fix Committed
Status in debian-installer source package in Disco:
  In Progress
Status in hw-detect source package in Disco:
  Fix Committed
Status in linux source package in Disco:
  Fix Released
Status in partman-iscsi source package in Disco:
  Fix Committed
Status in debian-installer source package in Eoan:
  Fix Released
Status in hw-detect source package in Eoan:
  Fix Released
Status in linux source package in Eoan:
  Fix Released
Status in partman-iscsi source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * It's not possible to access iBFT (iSCSI Boot Firmware Table) information
     (settings for network interface, initiator, and target) in the installer
     because the 'iscsi_ibft' module is not present in udeb packages.

   * Even if it was, the installer does not handle iBFT information at all,
     thus any settings are ignored, and iSCSI-related configuration has to
     be done manually or with workarounds.

   * This impacts user-experience and automatic installation on systems and
     deployments which actually do provide the iBFT feature and information,
     but cannot use it practically.

   * With proper iBFT support in the installer (kernel module in udeb package
     and automatic iSCSI-related configuration) users will be able to rely on
     iBFT to install/deploy Ubuntu on their servers and datacenters.

   * These fixes add the 'iscsi_ibft' kernel module in the scsi-modules udeb,
     and configure network/iSCSI according to iBFT information in disk-detect.

     This is done in disk-detect so that the iSCSI LUNs are detected as disks
     (useful in case of no other disks in the system so the installer doesn't
     complain nor wait too long) and that any partman-related preseed options
     are not required and may be still available for the user.

  [Test Case]

   * linux package / kernel module in udeb:

     $ dpkg-deb -c scsi-modules_*.udeb | grep iscsi_ibft.ko

     Check the module loads in the installer environment.
     See comment with example for disco.

   * d-i/hw-detect/partman-iscsi package:
     See comments 11, 12, 13.

  [Regression Potential]

   * linux package: low, the kernel module is not loaded by default,
     and only checks whether iBFT information is present in firmware,
     then exposes that in sysfs in read-only mode.

   * d-i/hw-detect/partman-iscsi:
     - d-i: kernel version update to include iscsi_ibft module,
    based on kernel released to -updates plus one week
    monitoring bug reports -- it should be OK.
    Tested on amd64/i386/arm64/ppc64el on QEMU, plus amd64
    on baremetal -- see comment 11.
     - hw-detect: low, the changes are enabled by a preseed option.
  see comment 12.
     - partman-iscsi: low, simple changes, plus one fix that has
  been tested in detail, and falls back to
  previous behavior if it fails.
  see comment 13.

  [Other Info]

   * This has been verified both by the developer with a simple iSCSI
     iBFT environment (2 VMs: iSCSI target & initiator with UEFI+iPXE)
     and by an user with system/firmware that supports iBFT for iSCSI.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1817321/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1818527] Re: Stub resolver cache is corrupted

[Eric Desrochers]

[sts-sponsor]

There is an SRU in progress for systemd already for Bionic. It will have
to wait for LP: #1814373 and #1825997 to be 'Fix Released' before
sponsoring that particular bug.

Thanks Heitor for your contribution.

Let's circle back later.

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1818527

Title:
  Stub resolver cache is corrupted

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Invalid
Status in systemd source package in Bionic:
  In Progress

Bug description:
  [Impact]
  systemd-resolved fails to resolve A records

  [Description]
  When systemd-resolve caches a non-existent CNAME record for a specific 
domain, further attempts at resolving A records for that same domain  fail. 
This has been fixed upstream in v240.

  Upstream commit:
  https://github.com/systemd/systemd/commit/3740146a4cbd

  $ git describe --contains 3740146a4cbd
  v240~839

  $ rmadison systemd --arch amd64
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.21 | xenial-security | source, ...
   systemd | 229-4ubuntu21.21 | xenial-updates  | source, ...
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.19 | bionic-security | source, ...
   systemd | 237-3ubuntu10.21 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.22 | bionic-proposed | source, ...
   systemd | 239-7ubuntu10| cosmic  | source, ...
   systemd | 239-7ubuntu10.12 | cosmic-security | source, ...
   systemd | 239-7ubuntu10.13 | cosmic-updates  | source, ...
   systemd | 239-7ubuntu10.14 | cosmic-proposed | source, ...
   systemd | 240-6ubuntu5 | disco   | source, ...
   systemd | 240-6ubuntu5.1   | disco-proposed  | source, ...
   systemd | 240-6ubuntu9 | eoan| source, ...

  Despite the package versions above, only Bionic is affected. Cosmic
  already includes a backported fix, and Xenial doesn't seem affected
  due  to resolvconf handling DNS resolution.

  [Test Case]
  Flush resolved's caches and try resolving a non-existent CNAME record. 
Further resolution attempts for the corresponding A record will fail:

  $ systemd-resolve --flush-caches
  $ dig github.com CNAME
  $ dig github.com A

  [Regression Potential]
  The regression potential for this fix should be very low, as it's a direct 
cherry-pick from upstream systemd. It has seen extensive testing  in both 
upstream and other Ubuntu releases, and was verified for Bionic through 
autopkgtests.

  

  [Original Description]

  It seems that when systemd-resolve cache an non-existent CNAME record
  for a domain, any attempt to resolve A record for the same domain
  fail.

  systemd version the issue has been seen with
  Installed: 237-3ubuntu10.13
  Used distribution

  Distributor ID: Ubuntu
  Description: Ubuntu 18.04.2 LTS
  Release: 18.04
  Codename: bionic

  Expected behaviour you didn't see

  Return A record for a domain when it exists.

  Unexpected behaviour you saw

  Resolution failed.

  Steps to reproduce the problem

  Whait for 1 minutes (github.com TTL for A record)

  Try to resolv github.com CNAME record dig CNAME github.com

  This will return an empty result.

  Then try to resolve github.com A record dig A github.com.

  This will now return empty result unless you restart systemd-resolved
  or wait for cache expiration.

  At the same time using another DNS will resolve correctly dig A
  github.com @8.8.8.8.

  Exemple :

  Wait for 1 minutes to let cache expire, then run

  dig CNAME github.com
  dig A github.com
  # no result
  dig A github.com @8.8.8.8
  # ;; ANSWER SECTION:
  # github.com. 59  IN  A   192.30.253.113
  # github.com. 59  IN  A   192.30.253.112

  PS: Don't forget to restart systemd-resolve, before trying to post an
  answer.

  This bug was first reported in github
  https://github.com/systemd/systemd/issues/11789 but systemd version in
  ubuntu is too  old.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818527/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1824236] Re: supermin/liguestfs fails to configure network

[Eric Desrochers]

Sponsoring for 'E'.

Considering libguestfs maintainer and Ioanna answers to my concern that
this code can never run outside the appliance and that can't create any
harm inside the appliance as well.

Also trusting that Ioanna will soon file a bug and submit the patch to
Debian as well.

-Eric

** Changed in: libguestfs (Ubuntu)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1824236

Title:
  supermin/liguestfs fails to configure network

Status in libguestfs package in Ubuntu:
  Fix Committed
Status in supermin package in Ubuntu:
  Invalid
Status in libguestfs source package in Bionic:
  In Progress
Status in supermin source package in Bionic:
  Invalid
Status in libguestfs source package in Cosmic:
  In Progress
Status in supermin source package in Cosmic:
  Invalid
Status in libguestfs source package in Disco:
  In Progress
Status in supermin source package in Disco:
  Invalid

Bug description:
  [Impact]
  libguestfs cannot configure network on Bionic onward.

  This bug is a combination of libguestfs/supermin package and
  /etc/dhcp/dhclient-enter-hooks.d/resolved script from systemd,
  present on Bionic onward.
  When supermin creates the appliance does chroot and executes its init script.
  If networking is enabled init will call dhclient sript to configure the 
network.

  On Bionic onward the make_resolv_conf function of dhclient_script is 
overwritten
  in /etc/dhcp/dhclient-eneter-hooks.d/resolved which before exiting restarts
  the systemd.resolved service.
  However, this happening in chroot environment fails with
  "System has not been booted with systemd as init system (PID 1). Can't 
operate."
  and network is left unconfigured.

  [Test Case]

  $ sudo guestfish -a xenial-server-cloudimg-amd64-disk1.img --network -v << EOF
  run
  mount /dev/sda1 /
  command 'apt update'
  EOF

  libguestfs: launch: program=guestfish
  libguestfs: launch: version=1.36.13
  libguestfs: launch: backend registered: unix
  libguestfs: launch: backend registered: uml
  libguestfs: launch: backend registered: libvirt
  ...
  supermin: deleting initramfs files
  supermin: chroot
  Starting /init script ...
  ...
  + dhclient --version
  + dhclient eth0
  System has not been booted with systemd as init system (PID 1). Can't operate.
  ...
  commandrvf: apt update

  WARNING: apt does not have a stable CLI interface. Use with caution in
  scripts.

  W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/InRelease  
Temporary failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://security.ubuntu.com/ubuntu/dists/xenial-security/InRelease  Temporary 
failure resolving 'security.ubuntu.com'
  W: Some index files failed to download. They have been ignored, or old ones 
used instead.
  ...

  [Regression Potential]

  Minimal. The fix removes the /etc/dhcp/dhclient-eneter-hooks.d/resolved hook 
installed by systemd.
  systemd is not used inside the appliance so it should not cause any 
regression.

  
https://bugs.launchpad.net/ubuntu/cosmic/+source/libguestfs/+bug/1824236/comments/18
  
https://bugs.launchpad.net/ubuntu/cosmic/+source/libguestfs/+bug/1824236/comments/19

  [Other]

  Affects B,C,D,E.

  Upstream fix :
  
https://github.com/libguestfs/libguestfs/commit/2bb6be333e6347d3f18856627d8ad8e50b8e5427

  Workaround

  1) Assume that libguestfs is installed, if not :
  $ sudo apt-get install libguestfs-tools

  2) Move the base.tar.gz to a temp dir, extract and remove tarball
  $ sudo mv /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/base.tar.gz ~/tempdir/
  $ cd ~/tempdir
  $ sudo tar -xzvf base.tar.gz
  $ sudo rm base.tar.gz

  3) Remove the etc/dhcp/dhclient-enter-hooks.d/resolved file
  $ sudo rm etc/dhcp/dhclient-enter-hooks.d/resolved

  4) Create tarball again
  $ sudo tar -czvf base.tar.gz etc

  5) Move it back to installation dir
  $ sudo mv base.tar.gz /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/

  6) Clean cache
  $ sudo rm -rf /var/tmp/.guestfs*

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1824236/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1824236] Re: supermin/liguestfs fails to configure network

[Eric Desrochers]

to continue my comment #16 

Looking further and if I understand this correctly, this piece of code
seems to only operate inside supermin appliances which doesn't use
systemd inside it ?

Is there any other circumstances where this piece of code can be run
outside a non-systemd appliance ?

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1824236

Title:
  supermin/liguestfs fails to configure network

Status in libguestfs package in Ubuntu:
  In Progress
Status in supermin package in Ubuntu:
  Invalid
Status in libguestfs source package in Bionic:
  In Progress
Status in supermin source package in Bionic:
  Invalid
Status in libguestfs source package in Cosmic:
  In Progress
Status in supermin source package in Cosmic:
  Invalid
Status in libguestfs source package in Disco:
  In Progress
Status in supermin source package in Disco:
  Invalid

Bug description:
  [Impact]
  libguestfs cannot configure network on Bionic onward.

  This bug is a combination of libguestfs/supermin package and
  /etc/dhcp/dhclient-enter-hooks.d/resolved script from systemd,
  present on Bionic onward.
  When supermin creates the appliance does chroot and executes its init script.
  If networking is enabled init will call dhclient sript to configure the 
network.

  On Bionic onward the make_resolv_conf function of dhclient_script is 
overwritten
  in /etc/dhcp/dhclient-eneter-hooks.d/resolved which before exiting restarts
  the systemd.resolved service.
  However, this happening in chroot environment fails with
  "System has not been booted with systemd as init system (PID 1). Can't 
operate."
  and network is left unconfigured.

  [Test Case]

  $ sudo guestfish -a xenial-server-cloudimg-amd64-disk1.img --network -v << EOF
  run
  mount /dev/sda1 /
  command 'apt update'
  EOF

  libguestfs: launch: program=guestfish
  libguestfs: launch: version=1.36.13
  libguestfs: launch: backend registered: unix
  libguestfs: launch: backend registered: uml
  libguestfs: launch: backend registered: libvirt
  ...
  supermin: deleting initramfs files
  supermin: chroot
  Starting /init script ...
  ...
  + dhclient --version
  + dhclient eth0
  System has not been booted with systemd as init system (PID 1). Can't operate.
  ...
  commandrvf: apt update

  WARNING: apt does not have a stable CLI interface. Use with caution in
  scripts.

  W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/InRelease  
Temporary failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://security.ubuntu.com/ubuntu/dists/xenial-security/InRelease  Temporary 
failure resolving 'security.ubuntu.com'
  W: Some index files failed to download. They have been ignored, or old ones 
used instead.
  ...

  [Regression Potential]

  Minimal. The fix removes the /etc/dhcp/dhclient-eneter-hooks.d/resolved hook 
installed by systemd.
  systemd is not used inside the appliance so it should not cause any 
regression.

  
  [Other]

  Affects B,C,D,E.

  Upstream fix :
  
https://github.com/libguestfs/libguestfs/commit/2bb6be333e6347d3f18856627d8ad8e50b8e5427

  
  Workaround

  1) Assume that libguestfs is installed, if not :
  $ sudo apt-get install libguestfs-tools

  2) Move the base.tar.gz to a temp dir, extract and remove tarball
  $ sudo mv /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/base.tar.gz ~/tempdir/
  $ cd ~/tempdir
  $ sudo tar -xzvf base.tar.gz
  $ sudo rm base.tar.gz

  3) Remove the etc/dhcp/dhclient-enter-hooks.d/resolved file
  $ sudo rm etc/dhcp/dhclient-enter-hooks.d/resolved

  4) Create tarball again
  $ sudo tar -czvf base.tar.gz etc

  5) Move it back to installation dir
  $ sudo mv base.tar.gz /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/

  6) Clean cache
  $ sudo rm -rf /var/tmp/.guestfs*

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1824236/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1824236] Re: supermin/liguestfs fails to configure network

[Eric Desrochers]

Thanks Ioanna for providing a patch and work with upstream maintainer.

I have some concern that I want to address before talking about sponsorship.
I haven't tested libguestfs, so my observation are only base on the patch you 
have provided upstream, and my concern inside Ubuntu.

I would have prefer to see upstream adopting an approach based on
detecting if the host run 'Ubuntu' then apply the workaround, otherwise
don't apply it. Instead of deploying the workaround everywhere
regardless of the Linux distribution. IMHO, it would have look more
cleaner and less risky since the ubuntu workaround involve a remove file
operation. I would have prefer to isolate the 'rm' operation at the
maximum and limit it only when really needed.

Talking about this 'rm' operation[0], it deletes a 'dpkg-managed' file
part of systemd package[1]. It's a pretty critical package here, so you
would understand I'm taking this seriously. I'm afraid this could impact
user who benefit of this libguestfs workaround at next systemd package
upgrade if the file is absent for instance, and possibly break the next
pkg upgrade of systemd

Could you please verify that aspect ?

I'm also concern about what could be other potential impact in the absence of 
this file.
Ideally, I would definitely prefer not allowing libguestfs to do such operation.

Can you think of another way to fix this ?
 
Feel free to share your thoughts and correct me If I miss something I should 
know about this change, but so far this is some of my concern looking again 
looking the patch.

[0] - rm -f /etc/dhcp/dhclient-enter-hooks.d/resolved
[1] - apt-file search /etc/dhcp/dhclient-enter-hooks.d/resolved
systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved


Here's some changes to apply to the current debdiff
- The 'Eoan' version need to be changed from "1.40.2-2ubuntu1.1" to 
"1.40.2-2ubuntu2". Let's use "1.40.2-2ubuntu1.1" for Disco instead.
- Your quilt patch need to be rename from 
"appliance-Remove-etc-dhcp-dhclient-enter-hooks.d-res.patch" 
"0016-appliance-Remove-etc-dhcp-dhclient-enter-hooks.d-res.patch" to stay 
consistent with the already existing patch numeric ordering.

Regards,
Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1824236

Title:
  supermin/liguestfs fails to configure network

Status in libguestfs package in Ubuntu:
  In Progress
Status in supermin package in Ubuntu:
  Invalid
Status in libguestfs source package in Bionic:
  In Progress
Status in supermin source package in Bionic:
  Invalid
Status in libguestfs source package in Cosmic:
  In Progress
Status in supermin source package in Cosmic:
  Invalid
Status in libguestfs source package in Disco:
  In Progress
Status in supermin source package in Disco:
  Invalid

Bug description:
  [Impact]
  libguestfs cannot configure network on Bionic onward.

  This bug is a combination of libguestfs/supermin package and
  /etc/dhcp/dhclient-enter-hooks.d/resolved script from systemd,
  present on Bionic onward.
  When supermin creates the appliance does chroot and executes its init script.
  If networking is enabled init will call dhclient sript to configure the 
network.

  On Bionic onward the make_resolv_conf function of dhclient_script is 
overwritten
  in /etc/dhcp/dhclient-eneter-hooks.d/resolved which before exiting restarts
  the systemd.resolved service.
  However, this happening in chroot environment fails with
  "System has not been booted with systemd as init system (PID 1). Can't 
operate."
  and network is left unconfigured.

  [Test Case]

  $ sudo guestfish -a xenial-server-cloudimg-amd64-disk1.img --network -v << EOF
  run
  mount /dev/sda1 /
  command 'apt update'
  EOF

  libguestfs: launch: program=guestfish
  libguestfs: launch: version=1.36.13
  libguestfs: launch: backend registered: unix
  libguestfs: launch: backend registered: uml
  libguestfs: launch: backend registered: libvirt
  ...
  supermin: deleting initramfs files
  supermin: chroot
  Starting /init script ...
  ...
  + dhclient --version
  + dhclient eth0
  System has not been booted with systemd as init system (PID 1). Can't operate.
  ...
  commandrvf: apt update

  WARNING: apt does not have a stable CLI interface. Use with caution in
  scripts.

  W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/InRelease  
Temporary failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://security.ubuntu.com/ubuntu/dists/xenial-security/InRelease  Temporary 
failure resolving 'security.ubuntu.com'
  W: Some index files failed to download. They have been ignored, or old ones 
used instead.
  ...

  [Regression Potential]

  

[Sts-sponsors] [Bug 1824236] Re: supermin/liguestfs fails to configure network

[Eric Desrochers]

Ok I'll review the debdiff for 'Eoan' tomorrow.

Thanks Ionna.

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1824236

Title:
  supermin/liguestfs fails to configure network

Status in libguestfs package in Ubuntu:
  In Progress
Status in supermin package in Ubuntu:
  Invalid
Status in libguestfs source package in Bionic:
  In Progress
Status in supermin source package in Bionic:
  Invalid
Status in libguestfs source package in Cosmic:
  In Progress
Status in supermin source package in Cosmic:
  Invalid
Status in libguestfs source package in Disco:
  In Progress
Status in supermin source package in Disco:
  Invalid

Bug description:
  [Impact]
  libguestfs cannot configure network on Bionic onward.

  This bug is a combination of libguestfs/supermin package and
  /etc/dhcp/dhclient-enter-hooks.d/resolved script from systemd,
  present on Bionic onward.
  When supermin creates the appliance does chroot and executes its init script.
  If networking is enabled init will call dhclient sript to configure the 
network.

  On Bionic onward the make_resolv_conf function of dhclient_script is 
overwritten
  in /etc/dhcp/dhclient-eneter-hooks.d/resolved which before exiting restarts
  the systemd.resolved service.
  However, this happening in chroot environment fails with
  "System has not been booted with systemd as init system (PID 1). Can't 
operate."
  and network is left unconfigured.

  [Test Case]

  $ sudo guestfish -a xenial-server-cloudimg-amd64-disk1.img --network -v << EOF
  run
  mount /dev/sda1 /
  command 'apt update'
  EOF

  libguestfs: launch: program=guestfish
  libguestfs: launch: version=1.36.13
  libguestfs: launch: backend registered: unix
  libguestfs: launch: backend registered: uml
  libguestfs: launch: backend registered: libvirt
  ...
  supermin: deleting initramfs files
  supermin: chroot
  Starting /init script ...
  ...
  + dhclient --version
  + dhclient eth0
  System has not been booted with systemd as init system (PID 1). Can't operate.
  ...
  commandrvf: apt update

  WARNING: apt does not have a stable CLI interface. Use with caution in
  scripts.

  W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/InRelease  
Temporary failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://security.ubuntu.com/ubuntu/dists/xenial-security/InRelease  Temporary 
failure resolving 'security.ubuntu.com'
  W: Some index files failed to download. They have been ignored, or old ones 
used instead.
  ...

  [Regression Potential]

  Minimal. The fix removes the /etc/dhcp/dhclient-eneter-hooks.d/resolved hook 
installed by systemd.
  systemd is not used inside the appliance so it should not cause any 
regression.

  
  [Other]

  Affects B,C,D,E.

  Upstream fix :
  
https://github.com/libguestfs/libguestfs/commit/2bb6be333e6347d3f18856627d8ad8e50b8e5427

  
  Workaround

  1) Assume that libguestfs is installed, if not :
  $ sudo apt-get install libguestfs-tools

  2) Move the base.tar.gz to a temp dir, extract and remove tarball
  $ sudo mv /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/base.tar.gz ~/tempdir/
  $ cd ~/tempdir
  $ sudo tar -xzvf base.tar.gz
  $ sudo rm base.tar.gz

  3) Remove the etc/dhcp/dhclient-enter-hooks.d/resolved file
  $ sudo rm etc/dhcp/dhclient-enter-hooks.d/resolved

  4) Create tarball again
  $ sudo tar -czvf base.tar.gz etc

  5) Move it back to installation dir
  $ sudo mv base.tar.gz /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/

  6) Clean cache
  $ sudo rm -rf /var/tmp/.guestfs*

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1824236/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1817321] Re: installer does not support iSCSI iBFT

[Eric Desrochers]

Sponsored 'd-i' for Eoan, now that both hw-detect and partman-iscsi have
been built and land in release.

- Eric

** Changed in: debian-installer (Ubuntu Eoan)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1817321

Title:
  installer does not support iSCSI iBFT

Status in debian-installer package in Ubuntu:
  Fix Committed
Status in hw-detect package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in partman-iscsi package in Ubuntu:
  Fix Released
Status in debian-installer source package in Bionic:
  Confirmed
Status in hw-detect source package in Bionic:
  Confirmed
Status in linux source package in Bionic:
  Fix Released
Status in partman-iscsi source package in Bionic:
  Confirmed
Status in debian-installer source package in Cosmic:
  Confirmed
Status in hw-detect source package in Cosmic:
  Confirmed
Status in linux source package in Cosmic:
  Fix Released
Status in partman-iscsi source package in Cosmic:
  Confirmed
Status in debian-installer source package in Disco:
  Confirmed
Status in hw-detect source package in Disco:
  Confirmed
Status in linux source package in Disco:
  Fix Released
Status in partman-iscsi source package in Disco:
  Confirmed
Status in debian-installer source package in Eoan:
  Fix Committed
Status in hw-detect source package in Eoan:
  Fix Released
Status in linux source package in Eoan:
  Fix Released
Status in partman-iscsi source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * It's not possible to access iBFT (iSCSI Boot Firmware Table) information
     (settings for network interface, initiator, and target) in the installer
     because the 'iscsi_ibft' module is not present in udeb packages.

   * Even if it was, the installer does not handle iBFT information at all,
     thus any settings are ignored, and iSCSI-related configuration has to
     be done manually or with workarounds.

   * This impacts user-experience and automatic installation on systems and
     deployments which actually do provide the iBFT feature and information,
     but cannot use it practically.

   * With proper iBFT support in the installer (kernel module in udeb package
     and automatic iSCSI-related configuration) users will be able to rely on
     iBFT to install/deploy Ubuntu on their servers and datacenters.

   * These fixes add the 'iscsi_ibft' kernel module in the scsi-modules udeb,
     and configure network/iSCSI according to iBFT information in disk-detect.

     This is done in disk-detect so that the iSCSI LUNs are detected as disks
     (useful in case of no other disks in the system so the installer doesn't
     complain nor wait too long) and that any partman-related preseed options
     are not required and may be still available for the user.

  [Test Case]

   * linux package / kernel module in udeb:

     $ dpkg-deb -c scsi-modules_*.udeb | grep iscsi_ibft.ko

     Check the module loads in the installer environment.
     See comment with example for disco.

   * d-i/hw-detect/partman-iscsi package:
     See comments 11, 12, 13.

  [Regression Potential]

   * linux package: low, the kernel module is not loaded by default,
     and only checks whether iBFT information is present in firmware,
     then exposes that in sysfs in read-only mode.

   * d-i/hw-detect/partman-iscsi:
     - d-i: kernel version update to include iscsi_ibft module,
    based on kernel released to -updates plus one week
    monitoring bug reports -- it should be OK.
    Tested on amd64/i386/arm64/ppc64el on QEMU, plus amd64
    on baremetal -- see comment 11.
     - hw-detect: low, the changes are enabled by a preseed option.
  see comment 12.
     - partman-iscsi: low, simple changes, plus one fix that has
  been tested in detail, and falls back to
  previous behavior if it fails.
  see comment 13.

  [Other Info]

   * This has been verified both by the developer with a simple iSCSI
     iBFT environment (2 VMs: iSCSI target & initiator with UEFI+iPXE)
     and by an user with system/firmware that supports iBFT for iSCSI.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1817321/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1817321] Re: installer does not support iSCSI iBFT

[Eric Desrochers]

Sponsored for Eoan, considering that Mauricio has submitted the patch to Debian 
already.
debbugs are "bug watches" in the LP.

Everything looks good me.

The only thing missing is the d-i rebuild with no modification but that
have to wait until hw-detect/parman-iscsi are both built.

- Eric

** Changed in: partman-iscsi (Ubuntu Eoan)
   Status: In Progress => Fix Committed

** Changed in: hw-detect (Ubuntu Eoan)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1817321

Title:
  installer does not support iSCSI iBFT

Status in debian-installer package in Ubuntu:
  Confirmed
Status in hw-detect package in Ubuntu:
  Fix Committed
Status in linux package in Ubuntu:
  Fix Released
Status in partman-iscsi package in Ubuntu:
  Fix Committed
Status in debian-installer source package in Bionic:
  Confirmed
Status in hw-detect source package in Bionic:
  Confirmed
Status in linux source package in Bionic:
  Fix Released
Status in partman-iscsi source package in Bionic:
  Confirmed
Status in debian-installer source package in Cosmic:
  Confirmed
Status in hw-detect source package in Cosmic:
  Confirmed
Status in linux source package in Cosmic:
  Fix Released
Status in partman-iscsi source package in Cosmic:
  Confirmed
Status in debian-installer source package in Disco:
  Confirmed
Status in hw-detect source package in Disco:
  Confirmed
Status in linux source package in Disco:
  Fix Released
Status in partman-iscsi source package in Disco:
  Confirmed
Status in debian-installer source package in Eoan:
  Confirmed
Status in hw-detect source package in Eoan:
  Fix Committed
Status in linux source package in Eoan:
  Fix Released
Status in partman-iscsi source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

   * It's not possible to access iBFT (iSCSI Boot Firmware Table) information
     (settings for network interface, initiator, and target) in the installer
     because the 'iscsi_ibft' module is not present in udeb packages.

   * Even if it was, the installer does not handle iBFT information at all,
     thus any settings are ignored, and iSCSI-related configuration has to
     be done manually or with workarounds.

   * This impacts user-experience and automatic installation on systems and
     deployments which actually do provide the iBFT feature and information,
     but cannot use it practically.

   * With proper iBFT support in the installer (kernel module in udeb package
     and automatic iSCSI-related configuration) users will be able to rely on
     iBFT to install/deploy Ubuntu on their servers and datacenters.

   * These fixes add the 'iscsi_ibft' kernel module in the scsi-modules udeb,
     and configure network/iSCSI according to iBFT information in disk-detect.

     This is done in disk-detect so that the iSCSI LUNs are detected as disks
     (useful in case of no other disks in the system so the installer doesn't
     complain nor wait too long) and that any partman-related preseed options
     are not required and may be still available for the user.

  [Test Case]

   * linux package / kernel module in udeb:

     $ dpkg-deb -c scsi-modules_*.udeb | grep iscsi_ibft.ko

     Check the module loads in the installer environment.
     See comment with example for disco.

   * d-i/hw-detect/partman-iscsi package:
     See comments 11, 12, 13.

  [Regression Potential]

   * linux package: low, the kernel module is not loaded by default,
     and only checks whether iBFT information is present in firmware,
     then exposes that in sysfs in read-only mode.

   * d-i/hw-detect/partman-iscsi:
     - d-i: kernel version update to include iscsi_ibft module,
    based on kernel released to -updates plus one week
    monitoring bug reports -- it should be OK.
    Tested on amd64/i386/arm64/ppc64el on QEMU, plus amd64
    on baremetal -- see comment 11.
     - hw-detect: low, the changes are enabled by a preseed option.
  see comment 12.
     - partman-iscsi: low, simple changes, plus one fix that has
  been tested in detail, and falls back to
  previous behavior if it fails.
  see comment 13.

  [Other Info]

   * This has been verified both by the developer with a simple iSCSI
     iBFT environment (2 VMs: iSCSI target & initiator with UEFI+iPXE)
     and by an user with system/firmware that supports iBFT for iSCSI.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1817321/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1817321] Re: installer does not support iSCSI iBFT

[Eric Desrochers]

** Changed in: partman-iscsi (Ubuntu Eoan)
   Status: Confirmed => In Progress

** Changed in: partman-iscsi (Ubuntu Eoan)
   Importance: Undecided => Medium

** Changed in: hw-detect (Ubuntu Eoan)
   Importance: Undecided => Medium

** Changed in: hw-detect (Ubuntu Eoan)
   Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1817321

Title:
  installer does not support iSCSI iBFT

Status in debian-installer package in Ubuntu:
  Confirmed
Status in hw-detect package in Ubuntu:
  In Progress
Status in linux package in Ubuntu:
  Fix Released
Status in partman-iscsi package in Ubuntu:
  In Progress
Status in debian-installer source package in Bionic:
  Confirmed
Status in hw-detect source package in Bionic:
  Confirmed
Status in linux source package in Bionic:
  Fix Released
Status in partman-iscsi source package in Bionic:
  Confirmed
Status in debian-installer source package in Cosmic:
  Confirmed
Status in hw-detect source package in Cosmic:
  Confirmed
Status in linux source package in Cosmic:
  Fix Released
Status in partman-iscsi source package in Cosmic:
  Confirmed
Status in debian-installer source package in Disco:
  Confirmed
Status in hw-detect source package in Disco:
  Confirmed
Status in linux source package in Disco:
  Fix Released
Status in partman-iscsi source package in Disco:
  Confirmed
Status in debian-installer source package in Eoan:
  Confirmed
Status in hw-detect source package in Eoan:
  In Progress
Status in linux source package in Eoan:
  Fix Released
Status in partman-iscsi source package in Eoan:
  In Progress

Bug description:
  [Impact]

   * It's not possible to access iBFT (iSCSI Boot Firmware Table) information
     (settings for network interface, initiator, and target) in the installer
     because the 'iscsi_ibft' module is not present in udeb packages.

   * Even if it was, the installer does not handle iBFT information at all,
     thus any settings are ignored, and iSCSI-related configuration has to
     be done manually or with workarounds.

   * This impacts user-experience and automatic installation on systems and
     deployments which actually do provide the iBFT feature and information,
     but cannot use it practically.

   * With proper iBFT support in the installer (kernel module in udeb package
     and automatic iSCSI-related configuration) users will be able to rely on
     iBFT to install/deploy Ubuntu on their servers and datacenters.

   * These fixes add the 'iscsi_ibft' kernel module in the scsi-modules udeb,
     and configure network/iSCSI according to iBFT information in disk-detect.

     This is done in disk-detect so that the iSCSI LUNs are detected as disks
     (useful in case of no other disks in the system so the installer doesn't
     complain nor wait too long) and that any partman-related preseed options
     are not required and may be still available for the user.

  [Test Case]

   * linux package / kernel module in udeb:

     $ dpkg-deb -c scsi-modules_*.udeb | grep iscsi_ibft.ko

     Check the module loads in the installer environment.
     See comment with example for disco.

   * d-i/hw-detect/partman-iscsi package:
     See comments 11, 12, 13.

  [Regression Potential]

   * linux package: low, the kernel module is not loaded by default,
     and only checks whether iBFT information is present in firmware,
     then exposes that in sysfs in read-only mode.

   * d-i/hw-detect/partman-iscsi:
     - d-i: kernel version update to include iscsi_ibft module,
    based on kernel released to -updates plus one week
    monitoring bug reports -- it should be OK.
    Tested on amd64/i386/arm64/ppc64el on QEMU, plus amd64
    on baremetal -- see comment 11.
     - hw-detect: low, the changes are enabled by a preseed option.
  see comment 12.
     - partman-iscsi: low, simple changes, plus one fix that has
  been tested in detail, and falls back to
  previous behavior if it fails.
  see comment 13.

  [Other Info]

   * This has been verified both by the developer with a simple iSCSI
     iBFT environment (2 VMs: iSCSI target & initiator with UEFI+iPXE)
     and by an user with system/firmware that supports iBFT for iSCSI.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1817321/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1824236] Re: supermin/liguestfs fails to configure network

[Eric Desrochers]

[sts-sponsor]

I have some concern about the patch being more or less suggested by
upstream, but never merged upstream. I see they previously merge a
workaround for Ubuntu, can you discuss with them and see if that can be
merged again upstream ? I'm trying to avoid to have to carry a patch in
Ubuntu for libguestfs forever because upstream didn't merge it.

As I read the code so far, the workaround does (and only needed in ubuntu FWIU):
touch /etc/fstab 
rm -f /etc/dhcp/dhclient-enter-hooks.d/resolved

but the workaround is applied to all, regardless of the Linux
distribution.

If we PR something upstream, would it be possible to suggest a separate
if statement which will detect if it's ubuntu and/or debian

What would you think of something like this:
-
++ # Workarounds for ubuntu/debian
++ ubuntu = 
++ if test "$guestfs_network" = 1 and ubuntu = ; then
++touch /etc/fstab 
++rm -f /etc/dhcp/dhclient-enter-hooks.d/resolved
fi

+ if test "$guestfs_network" = 1; then
+ iface=$(ls -I all -I default -I lo /proc/sys/net/ipv4/conf)
+-touch /etc/fstab   # Workaround for Ubuntu.
--# Two workarounds for Ubuntu:
--touch /etc/fstab 
--rm -f /etc/dhcp/dhclient-enter-hooks.d/resolved
+ if dhclient --version >/dev/null 2>&1; then
+ dhclient $iface
+ else


I don't feel comfortable to sponsor this in Eoan, before further discussion 
with upstream to merged the change.
-

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1824236

Title:
  supermin/liguestfs fails to configure network

Status in libguestfs package in Ubuntu:
  In Progress
Status in supermin package in Ubuntu:
  In Progress
Status in libguestfs source package in Bionic:
  In Progress
Status in supermin source package in Bionic:
  New
Status in libguestfs source package in Cosmic:
  In Progress
Status in supermin source package in Cosmic:
  New
Status in libguestfs source package in Disco:
  In Progress
Status in supermin source package in Disco:
  New

Bug description:
  Description

  supermin cannot configure network on Bionic onward.

  This bug is a combination of supermin package and 
  /etc/dhcp/dhclient-enter-hooks.d/resolved script from systemd,
  present on Bionic onward.
  When supermin creates the appliance does chroot and executes its init script.
  If networking is enabled init will call dhclient sript to configure the 
network.

  On Bionic onward the make_resolv_conf function of dhclient_script is 
overwritten
  in /etc/dhcp/dhclient-eneter-hooks.d/resolved which before exiting restarts
  the systemd.resolved service. 
  However, this happening in chroot environment fails with 
  "System has not been booted with systemd as init system (PID 1). Can't 
operate."
  and network is left unconfigured.

  
  Test Case 

  $ sudo guestfish -a xenial-server-cloudimg-amd64-disk1.img --network -v << 
EOF 
  run 
  mount /dev/sda1 / 
  command 'apt update' 
  EOF 

  libguestfs: launch: program=guestfish
  libguestfs: launch: version=1.36.13
  libguestfs: launch: backend registered: unix
  libguestfs: launch: backend registered: uml
  libguestfs: launch: backend registered: libvirt
  ...
  supermin: deleting initramfs files
  supermin: chroot
  Starting /init script ...
  ...
  + dhclient --version
  + dhclient eth0
  System has not been booted with systemd as init system (PID 1). Can't operate.
  ...
  commandrvf: apt update

  WARNING: apt does not have a stable CLI interface. Use with caution in
  scripts.

  W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/InRelease  
Temporary failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://security.ubuntu.com/ubuntu/dists/xenial-security/InRelease  Temporary 
failure resolving 'security.ubuntu.com'
  W: Some index files failed to download. They have been ignored, or old ones 
used instead.
  ...

  
  Workaround

  1) Assume that libguestfs is installed, if not : 
  $ sudo apt-get install libguestfs-tools 

  2) Move the base.tar.gz to a temp dir, extract and remove tarball 
  $ sudo mv /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/base.tar.gz ~/tempdir/ 
  $ cd ~/tempdir 
  $ sudo tar -xzvf base.tar.gz 
  $ sudo rm base.tar.gz 

  3) Remove the etc/dhcp/dhclient-enter-hooks.d/resolved file 
  $ sudo rm etc/dhcp/dhclient-enter-hooks.d/resolved 

  4) Create tarball again 
  $ sudo tar -czvf base.tar.gz etc 

  5) Move it back to installation dir 
  $ sudo mv base.tar.gz /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/ 

  6) Clean cache 
  $ sudo rm -rf /var/tmp/.guestfs*

To manage notifications about this bug go to:

[Sts-sponsors] [Bug 1824236] Re: supermin/liguestfs fails to configure network

[Eric Desrochers]

[sts-sponsor]

I have some concern about the patch being more or less suggested by
upstream, but never merged upstream. I see they previously merge a
workaround for Ubuntu, can you discuss with them and see if that can be
merged again upstream ? I'm trying to avoid to have to carry a patch in
Ubuntu for libguestfs forever because upstream didn't merge it.

As I read the code so far, the workaround does (and only needed in ubuntu FWIU):
touch /etc/fstab
rm -f /etc/dhcp/dhclient-enter-hooks.d/resolved

but the workaround is applied to all, regardless of the Linux
distribution.

If we PR something upstream, would it be possible to suggest a separate
if statement which will detect if it's ubuntu and/or debian

What would you think of something like this (or something along those line, so 
that the workaround is only applied in a ubuntu context) it would look like 
cleaner IMHO:
-
++ # Workarounds for ubuntu/debian
++ ubuntu = 
++ if test "$guestfs_network" = 1 and ubuntu = ; then
++ touch /etc/fstab
++ rm -f /etc/dhcp/dhclient-enter-hooks.d/resolved
fi

+ if test "$guestfs_network" = 1; then
+ iface=$(ls -I all -I default -I lo /proc/sys/net/ipv4/conf)
+- touch /etc/fstab # Workaround for Ubuntu.
-- # Two workarounds for Ubuntu:
-- touch /etc/fstab
-- rm -f /etc/dhcp/dhclient-enter-hooks.d/resolved
+ if dhclient --version >/dev/null 2>&1; then
+ dhclient $iface
+ else
-

I don't feel comfortable to sponsor this in Eoan, before further
discussion with upstream to merged the change.

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1824236

Title:
  supermin/liguestfs fails to configure network

Status in libguestfs package in Ubuntu:
  In Progress
Status in supermin package in Ubuntu:
  In Progress
Status in libguestfs source package in Bionic:
  In Progress
Status in supermin source package in Bionic:
  New
Status in libguestfs source package in Cosmic:
  In Progress
Status in supermin source package in Cosmic:
  New
Status in libguestfs source package in Disco:
  In Progress
Status in supermin source package in Disco:
  New

Bug description:
  Description

  supermin cannot configure network on Bionic onward.

  This bug is a combination of supermin package and 
  /etc/dhcp/dhclient-enter-hooks.d/resolved script from systemd,
  present on Bionic onward.
  When supermin creates the appliance does chroot and executes its init script.
  If networking is enabled init will call dhclient sript to configure the 
network.

  On Bionic onward the make_resolv_conf function of dhclient_script is 
overwritten
  in /etc/dhcp/dhclient-eneter-hooks.d/resolved which before exiting restarts
  the systemd.resolved service. 
  However, this happening in chroot environment fails with 
  "System has not been booted with systemd as init system (PID 1). Can't 
operate."
  and network is left unconfigured.

  
  Test Case 

  $ sudo guestfish -a xenial-server-cloudimg-amd64-disk1.img --network -v << 
EOF 
  run 
  mount /dev/sda1 / 
  command 'apt update' 
  EOF 

  libguestfs: launch: program=guestfish
  libguestfs: launch: version=1.36.13
  libguestfs: launch: backend registered: unix
  libguestfs: launch: backend registered: uml
  libguestfs: launch: backend registered: libvirt
  ...
  supermin: deleting initramfs files
  supermin: chroot
  Starting /init script ...
  ...
  + dhclient --version
  + dhclient eth0
  System has not been booted with systemd as init system (PID 1). Can't operate.
  ...
  commandrvf: apt update

  WARNING: apt does not have a stable CLI interface. Use with caution in
  scripts.

  W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/InRelease  
Temporary failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://security.ubuntu.com/ubuntu/dists/xenial-security/InRelease  Temporary 
failure resolving 'security.ubuntu.com'
  W: Some index files failed to download. They have been ignored, or old ones 
used instead.
  ...

  
  Workaround

  1) Assume that libguestfs is installed, if not : 
  $ sudo apt-get install libguestfs-tools 

  2) Move the base.tar.gz to a temp dir, extract and remove tarball 
  $ sudo mv /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/base.tar.gz ~/tempdir/ 
  $ cd ~/tempdir 
  $ sudo tar -xzvf base.tar.gz 
  $ sudo rm base.tar.gz 

  3) Remove the etc/dhcp/dhclient-enter-hooks.d/resolved file 
  $ sudo rm etc/dhcp/dhclient-enter-hooks.d/resolved 

  4) Create tarball again 
  $ sudo tar -czvf base.tar.gz etc 

  5) Move it back to installation dir 
  $ sudo mv base.tar.gz /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/ 

  6) Clean cache 
  $ sudo rm -rf /var/tmp/.guestfs*

[Sts-sponsors] [Bug 1828467] Re: [sru] remove juju-db stop/start service interactions

[Eric Desrochers]

I marked Trusty as 'Won't Fix' in it reached EOL.

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1828467

Title:
  [sru] remove juju-db stop/start service interactions

Status in sosreport package in Ubuntu:
  In Progress
Status in sosreport source package in Trusty:
  Won't Fix
Status in sosreport source package in Xenial:
  New
Status in sosreport source package in Bionic:
  New
Status in sosreport source package in Cosmic:
  New
Status in sosreport source package in Disco:
  New
Status in sosreport source package in Eoan:
  In Progress

Bug description:
  [Impact]

  The juju plugin will stop and start the juju-db service during data 
collection.
  sosreport should not impact running services, or attempt to recover them.

  This has been reported upstream[0] and will be fixed by the juju 2.x
  refactor[1]

  This is a stop-gap tracking the removal of the juju-db service restart
  code in existing sosreport releases.

  [0] - https://github.com/sosreport/sos/issues/1653
  [1] - https://github.com/sosreport/sos/pull/1670

  [Test Case]

   * Make sure you are in the juju controller.
   * Install sosreport
   * Look mongod PID before
     ** $ pidof mongod
   * Run sosreport, ensuring that the juju plugin is exercised
   * Confirm the juju-db service was not restarted, and mongoexport data 
captured.
  * Look mongod PID after
     ** $ pidof mongod

  Check for errors while running, or in /tmp/sosreport-*/sos_logs/

  The offending function ensure_service_is_running() in theory doesn't
  create any harm unless juju plugin is exercised during a sosreport run
  from a juju controller where mongod and/or juju-db resides.

  [Regression Potential]

   * Risk is low.
   * Change is limited in scope to the juju plugin.
   * Worst-case scenario is that the mongoexport command will fail to collect 
any data, which won't affect core functionality of sosreport itself nor impact 
other sosreport plugins.

  [Other information]

  We will temporary divert from the juju plugin found upstream and
  debian, while the refactoring is completed to avoid any situation
  where sosreport is run on a controller since it may have production
  impact on Ubuntu juju environment.

  Once the refactoring of the juju plugin is completed upstream, we will
  make sure to update debian and put the juju plugin align with what
  found upstream and debian.

  Actually, sosreport 3.7 micro-release is blocked waiting for this
  refactoring to be completed (LP: #1825010).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1828467/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1828467] Re: [sru] remove juju-db stop/start service interactions

[Eric Desrochers]

I marked Trusty as 'Won't Fix' as it reached EOL.

** Description changed:

  [Impact]
  
  The juju plugin will stop and start the juju-db service during data 
collection.
  sosreport should not impact running services, or attempt to recover them.
  
  This has been reported upstream[0] and will be fixed by the juju 2.x
  refactor[1]
  
  This is a stop-gap tracking the removal of the juju-db service restart
  code in existing sosreport releases.
  
  [0] - https://github.com/sosreport/sos/issues/1653
  [1] - https://github.com/sosreport/sos/pull/1670
  
  [Test Case]
  
-  * Make sure you are in the juju controller.
+  * Make sure you are in the juju controller.
   * Install sosreport
   * Look mongod PID before
     ** $ pidof mongod
   * Run sosreport, ensuring that the juju plugin is exercised
   * Confirm the juju-db service was not restarted, and mongoexport data 
captured.
  * Look mongod PID after
     ** $ pidof mongod
- 
  
  Check for errors while running, or in /tmp/sosreport-*/sos_logs/
  
  The offending function ensure_service_is_running() in theory doesn't
  create any harm unless juju plugin is exercised during a sosreport run
  from a juju controller where mongod and/or juju-db resides.
  
  [Regression Potential]
  
   * Risk is low.
   * Change is limited in scope to the juju plugin.
   * Worst-case scenario is that the mongoexport command will fail to collect 
any data, which won't affect core functionality of sosreport itself nor impact 
other sosreport plugins.
+ 
+ [Other information]
+ 
+ We will temporary divert from the juju plugin found upstream and debian,
+ while the refactoring is completed to avoid any situation where
+ sosreport is run on a controller since it may have production impact on
+ Ubuntu juju environment.
+ 
+ Once the refactoring of the juju plugin is completed upstream, we will
+ make sure to update debian and put the juju plugin align with what found
+ upstream and debian.
+ 
+ Actually, sosreport 3.7 micro-release is waiting on this via LP:
+ #1825010.

** Description changed:

  [Impact]
  
  The juju plugin will stop and start the juju-db service during data 
collection.
  sosreport should not impact running services, or attempt to recover them.
  
  This has been reported upstream[0] and will be fixed by the juju 2.x
  refactor[1]
  
  This is a stop-gap tracking the removal of the juju-db service restart
  code in existing sosreport releases.
  
  [0] - https://github.com/sosreport/sos/issues/1653
  [1] - https://github.com/sosreport/sos/pull/1670
  
  [Test Case]
  
   * Make sure you are in the juju controller.
   * Install sosreport
   * Look mongod PID before
     ** $ pidof mongod
   * Run sosreport, ensuring that the juju plugin is exercised
   * Confirm the juju-db service was not restarted, and mongoexport data 
captured.
  * Look mongod PID after
     ** $ pidof mongod
  
  Check for errors while running, or in /tmp/sosreport-*/sos_logs/
  
  The offending function ensure_service_is_running() in theory doesn't
  create any harm unless juju plugin is exercised during a sosreport run
  from a juju controller where mongod and/or juju-db resides.
  
  [Regression Potential]
  
   * Risk is low.
   * Change is limited in scope to the juju plugin.
   * Worst-case scenario is that the mongoexport command will fail to collect 
any data, which won't affect core functionality of sosreport itself nor impact 
other sosreport plugins.
  
  [Other information]
  
  We will temporary divert from the juju plugin found upstream and debian,
  while the refactoring is completed to avoid any situation where
  sosreport is run on a controller since it may have production impact on
  Ubuntu juju environment.
  
  Once the refactoring of the juju plugin is completed upstream, we will
  make sure to update debian and put the juju plugin align with what found
  upstream and debian.
  
- Actually, sosreport 3.7 micro-release is waiting on this via LP:
- #1825010.
+ Actually, sosreport 3.7 micro-release is blocked waiting for this
+ refactoring to be completed (LP: #1825010).

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1828467

Title:
  [sru] remove juju-db stop/start service interactions

Status in sosreport package in Ubuntu:
  In Progress
Status in sosreport source package in Trusty:
  Won't Fix
Status in sosreport source package in Xenial:
  New
Status in sosreport source package in Bionic:
  New
Status in sosreport source package in Cosmic:
  New
Status in sosreport source package in Disco:
  New
Status in sosreport source package in Eoan:
  In Progress

Bug description:
  [Impact]

  The juju plugin will stop and start the juju-db service during data 
collection.
  sosreport should not impact running services, or attempt to recover them.

  This has been reported upstream[0] and will be fixed by the juju 2.x
  refactor[1]

  This is a stop-gap tracking the 

[Sts-sponsors] [Bug 1828467] Re: [sru] remove juju-db stop/start service interactions

[Eric Desrochers]

** Changed in: sosreport (Ubuntu Trusty)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1828467

Title:
  [sru] remove juju-db stop/start service interactions

Status in sosreport package in Ubuntu:
  In Progress
Status in sosreport source package in Trusty:
  Won't Fix
Status in sosreport source package in Xenial:
  New
Status in sosreport source package in Bionic:
  New
Status in sosreport source package in Cosmic:
  New
Status in sosreport source package in Disco:
  New
Status in sosreport source package in Eoan:
  In Progress

Bug description:
  [Impact]

  The juju plugin will stop and start the juju-db service during data 
collection.
  sosreport should not impact running services, or attempt to recover them.

  This has been reported upstream[0] and will be fixed by the juju 2.x
  refactor[1]

  This is a stop-gap tracking the removal of the juju-db service restart
  code in existing sosreport releases.

  [0] - https://github.com/sosreport/sos/issues/1653
  [1] - https://github.com/sosreport/sos/pull/1670

  [Test Case]

   * Make sure you are in the juju controller.
   * Install sosreport
   * Look mongod PID before
     ** $ pidof mongod
   * Run sosreport, ensuring that the juju plugin is exercised
   * Confirm the juju-db service was not restarted, and mongoexport data 
captured.
  * Look mongod PID after
     ** $ pidof mongod

  
  Check for errors while running, or in /tmp/sosreport-*/sos_logs/

  The offending function ensure_service_is_running() in theory doesn't
  create any harm unless juju plugin is exercised during a sosreport run
  from a juju controller where mongod and/or juju-db resides.

  [Regression Potential]

   * Risk is low.
   * Change is limited in scope to the juju plugin.
   * Worst-case scenario is that the mongoexport command will fail to collect 
any data, which won't affect core functionality of sosreport itself nor impact 
other sosreport plugins.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1828467/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1572908] Re: sssd-ad pam_sss(cron:account): Access denied for user

[Eric Desrochers]

Sponsored for D/C/B/X.

Thanks Victor !

** Changed in: sssd (Ubuntu Xenial)
   Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1572908

Title:
  sssd-ad pam_sss(cron:account): Access denied for user

Status in sssd package in Ubuntu:
  Fix Released
Status in sssd source package in Xenial:
  In Progress
Status in sssd source package in Bionic:
  In Progress
Status in sssd source package in Cosmic:
  In Progress
Status in sssd source package in Disco:
  In Progress
Status in sssd source package in Eoan:
  Fix Released

Bug description:
  [Impact]

  SSSD has GPO_CROND set to "crond" in its code while Debian/Ubuntu use
  "cron" as a PAM service. This difference makes AD users have cron
  blocked by default, instead of having it enabled.

  [Test Case]

  - With an Active Directory user created (e.g. logonuser@TESTS.LOCAL),
  set a cron task:

  logonuser@tests.local@xenial-sssd-ad:~$ crontab -l | grep -v ^#
  * * * * * true /tmp/crontest

  - If the default is set to "crond" the task is blocked:

  # ag pam /var/log/ | grep -i denied | head -n 2
  /var/log/auth.log.1:772:Feb 21 11:00:01 xenial-sssd-ad CRON[2387]: 
pam_sss(cron:account): Access denied for user logonuser@tests.local: 6 
(Permission denied)
  /var/log/auth.log.1:773:Feb 21 11:01:01 xenial-sssd-ad CRON[2390]: 
pam_sss(cron:account): Access denied for user logonuser@tests.local: 6 
(Permission denied)

  - Setting GPO_CROND to "cron" or adding "ad_gpo_map_batch = +cron" to
  the configuration file solves the issue.

  [Regression potential]

  Minimal. The default value does not apply to Debian/Ubuntu, and those
  who added a configuration option to circumvent the issue
  ("ad_gpo_map_batch = +cron") will continue working after this patch is
  applied.

  [Other Info]

  Upstream commit:
  https://github.com/SSSD/sssd/commit/bc65ba9a07a924a58b13a0d5a935114ab72b7524

  # git describe --contains bc65ba9a07a924a58b13a0d5a935114ab72b7524
  sssd-2_1_0~14

  # rmadison sssd
  => sssd | 1.13.4-1ubuntu1.13 | xenial-proposed 
  => sssd | 1.16.1-1ubuntu1.1  | bionic-updates
  => sssd | 1.16.3-1ubuntu2| cosmic  
  => sssd | 1.16.3-3ubuntu1| disco

  
  [Original description]

  User cron jobs has Access denied for user

  pr 21 11:05:02 edvlw08 CRON[6848]: pam_sss(cron:account): Access denied for 
user : 6 (Zugriff verweigert)
  Apr 21 11:05:02 edvlw08 CRON[6848]: Zugriff verweigert
  Apr 21 11:05:02 edvlw08 cron[965]: Zugriff verweigert

  SSSD-AD Login works, i see also my AD groups

  Description:Ubuntu 16.04 LTS
  Release:16.04

  sssd:
    Installed: 1.13.4-1ubuntu1
    Candidate: 1.13.4-1ubuntu1
    Version table:
   *** 1.13.4-1ubuntu1 500
  500 http://at.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  100 /var/lib/dpkg/status
  sssd-ad:
    Installed: 1.13.4-1ubuntu1
    Candidate: 1.13.4-1ubuntu1
    Version table:
   *** 1.13.4-1ubuntu1 500
  500 http://at.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  100 /var/lib/dpkg/status
  libpam-sss:
    Installed: 1.13.4-1ubuntu1
    Candidate: 1.13.4-1ubuntu1
    Version table:
   *** 1.13.4-1ubuntu1 500
  500 http://at.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  100 /var/lib/dpkg/status

  /ect/sssd/sssd.conf
  [sssd]
  services = nss, pam
  config_file_version = 2
  domains = test.at

  [nss]
  default_shell = /bin/false

  [domain/test.at]
  decription = TEST - ActiveDirectory
  enumerate = false
  cache_credentials = true
  id_provider = ad
  auth_provider = ad
  chpass_provider = ad
  ad_domain = test.at
  access_provider = ad
  subdomains_provider = none
  ldap_use_tokengroups = false
  dyndns_update = true
  krb5_realm = TEST.AT
  krb5_store_password_if_offline = true
  ldap_id_mapping = false
  krb5_keytab = /etc/krb5.host.keytab
  ldap_krb5_keytab = /etc/krb5.host.keytab
  ldap_use_tokengroups = false
  ldap_referrals = false

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1572908/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1572908] Re: sssd-ad pam_sss(cron:account): Access denied for user

[Eric Desrochers]

Sponsored for 'eoan', considering the patch is merged upstream and
already part of debian.

Nitpick:
- Rename quilt patch d/p/GPO_CROND-customization.diff to 
d/p/GPO_CROND-customization.patch
- Rework the DEP3 header

Note for next sponsoring (Disco debdiff) I haven't look others yet.
A quick look at the Disco debdiff, the actual proposed disco version would need 
to be changed from "1.16.3-3ubuntu2" to "1.16.3-3ubuntu1.1"

Thanks
Eric

** Changed in: sssd (Ubuntu Eoan)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1572908

Title:
  sssd-ad pam_sss(cron:account): Access denied for user

Status in sssd package in Ubuntu:
  Fix Committed
Status in sssd source package in Xenial:
  New
Status in sssd source package in Bionic:
  New
Status in sssd source package in Cosmic:
  New
Status in sssd source package in Disco:
  In Progress
Status in sssd source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

  SSSD has GPO_CROND set to "crond" in its code while Debian/Ubuntu use
  "cron" as a PAM service. This difference makes AD users have cron
  blocked by default, instead of having it enabled.

  [Test Case]

  - With an Active Directory user created (e.g. logonuser@TESTS.LOCAL),
  set a cron task:

  logonuser@tests.local@xenial-sssd-ad:~$ crontab -l | grep -v ^#
  * * * * * true /tmp/crontest

  - If the default is set to "crond" the task is blocked:

  # ag pam /var/log/ | grep -i denied | head -n 2
  /var/log/auth.log.1:772:Feb 21 11:00:01 xenial-sssd-ad CRON[2387]: 
pam_sss(cron:account): Access denied for user logonuser@tests.local: 6 
(Permission denied)
  /var/log/auth.log.1:773:Feb 21 11:01:01 xenial-sssd-ad CRON[2390]: 
pam_sss(cron:account): Access denied for user logonuser@tests.local: 6 
(Permission denied)

  - Setting GPO_CROND to "cron" or adding "ad_gpo_map_batch = +cron" to
  the configuration file solves the issue.

  [Regression potential]

  Minimal. The default value does not apply to Debian/Ubuntu, and those
  who added a configuration option to circumvent the issue
  ("ad_gpo_map_batch = +cron") will continue working after this patch is
  applied.

  [Other Info]

  Upstream commit:
  https://github.com/SSSD/sssd/commit/bc65ba9a07a924a58b13a0d5a935114ab72b7524

  # git describe --contains bc65ba9a07a924a58b13a0d5a935114ab72b7524
  sssd-2_1_0~14

  # rmadison sssd
  => sssd | 1.13.4-1ubuntu1.13 | xenial-proposed 
  => sssd | 1.16.1-1ubuntu1.1  | bionic-updates
  => sssd | 1.16.3-1ubuntu2| cosmic  
  => sssd | 1.16.3-3ubuntu1| disco

  
  [Original description]

  User cron jobs has Access denied for user

  pr 21 11:05:02 edvlw08 CRON[6848]: pam_sss(cron:account): Access denied for 
user : 6 (Zugriff verweigert)
  Apr 21 11:05:02 edvlw08 CRON[6848]: Zugriff verweigert
  Apr 21 11:05:02 edvlw08 cron[965]: Zugriff verweigert

  SSSD-AD Login works, i see also my AD groups

  Description:Ubuntu 16.04 LTS
  Release:16.04

  sssd:
    Installed: 1.13.4-1ubuntu1
    Candidate: 1.13.4-1ubuntu1
    Version table:
   *** 1.13.4-1ubuntu1 500
  500 http://at.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  100 /var/lib/dpkg/status
  sssd-ad:
    Installed: 1.13.4-1ubuntu1
    Candidate: 1.13.4-1ubuntu1
    Version table:
   *** 1.13.4-1ubuntu1 500
  500 http://at.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  100 /var/lib/dpkg/status
  libpam-sss:
    Installed: 1.13.4-1ubuntu1
    Candidate: 1.13.4-1ubuntu1
    Version table:
   *** 1.13.4-1ubuntu1 500
  500 http://at.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
  100 /var/lib/dpkg/status

  /ect/sssd/sssd.conf
  [sssd]
  services = nss, pam
  config_file_version = 2
  domains = test.at

  [nss]
  default_shell = /bin/false

  [domain/test.at]
  decription = TEST - ActiveDirectory
  enumerate = false
  cache_credentials = true
  id_provider = ad
  auth_provider = ad
  chpass_provider = ad
  ad_domain = test.at
  access_provider = ad
  subdomains_provider = none
  ldap_use_tokengroups = false
  dyndns_update = true
  krb5_realm = TEST.AT
  krb5_store_password_if_offline = true
  ldap_id_mapping = false
  krb5_keytab = /etc/krb5.host.keytab
  ldap_krb5_keytab = /etc/krb5.host.keytab
  ldap_use_tokengroups = false
  ldap_referrals = false

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1572908/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1822062] Re: Race condition on boot between cups and sssd

[Eric Desrochers]

There is a debian->ubuntu sync right now in eoan-proposed.

I'll sponsor it once the actual sync is completed and found in eoan-
releases.

Meanwhile, could you please report a bug and forward the patch to debian
to make sure the problem is fix to prevent re-introducing the issue at
next debian->ubuntu sync/merge.

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1822062

Title:
  Race condition on boot between cups and sssd

Status in cups package in Ubuntu:
  In Progress
Status in cups source package in Xenial:
  New
Status in cups source package in Bionic:
  New
Status in cups source package in Cosmic:
  New
Status in cups source package in Disco:
  New
Status in cups source package in Eoan:
  In Progress

Bug description:
  [Impact]

   * When cups has set the "SystemGroup" directive to an external group
  provided through sss and cups starts before sssd has finished booting,
  cups will crash because the group does not exist.

   * The patch adds an "After=sssd.service" clause to the service unit
  file.

  [Test Case]

   * Configure an external authentication service (LDAP, AD...) and
  create a group, for instance "lpadmins@tests.local"

   * Set SystemGroup to match that group in /etc/cups/cups-files.conf:
  SystemGroup lpadmins@tests.local

   * Reboot

   * If cups has started before sssd has finished booting, cups will crash:
  Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup 
"lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf.

   * If cups starts after sssd, it will work fine.

  [Regression Potential]

   * Minimal: this patch affects just the ordering of the service unit
  file.

  [Other Info]

   * Upstream:
  https://github.com/apple/cups/commit/4d0f1959a3f46973caec2cd41828c59674fe195d

  [Original description]

  When cups has set the "SystemGroup" directive to an external group
  provided through sss and cups starts before sssd has finished booting,
  cups will crash because the group does not exist. For instance, with a
  group named lpadmins@tests.local served from Active Directory through
  sssd, if the sssd service hasn't booted before cups:

  Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler.
  Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler.
  Mar 27 10:10:33 cups-sssd systemd[1]: Started Make remote CUPS printers 
available locally.
  Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup 
"lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf.
  Mar 27 10:10:33 cups-sssd cupsd[21463]: Unable to read 
"/etc/cups/cups-files.conf" due to errors.
  Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Main process exited, 
code=exited, status=1/FAILURE
  Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Failed with result 
'exit-code'.
  Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Service hold-off time 
over, scheduling restart.
  Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Scheduled restart job, 
restart counter is at 2.
  Mar 27 10:10:33 cups-sssd systemd[1]: Stopping Make remote CUPS printers 
available locally...
  Mar 27 10:10:33 cups-sssd systemd[1]: Stopped Make remote CUPS printers 
available locally.
  Mar 27 10:10:33 cups-sssd systemd[1]: Stopped CUPS Scheduler.

  If sssd is running before cups starts, everything works as expected.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1822062/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1825250] Re: ethmonitor does not list interfaces without assigned IP address

[Eric Desrochers]

Sponsored for 'eoan' considering that the:
1) Both upstream fixes are merged upstream
2) Bug is reported in debian against resource-agents (debbugs #927311)
3) Eoan is now open (#ubuntu-release topic: ... Archive: Open | Eoan Release 
Coordination...)

Nitpick:
d/changelog was mentionning 'unstable' instead of 'eoan'.

- Eric

** Changed in: resource-agents (Ubuntu Eoan)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1825250

Title:
  ethmonitor does not list interfaces without assigned IP address

Status in resource-agents package in Ubuntu:
  Fix Committed
Status in resource-agents source package in Xenial:
  Confirmed
Status in resource-agents source package in Bionic:
  Confirmed
Status in resource-agents source package in Cosmic:
  Confirmed
Status in resource-agents source package in Disco:
  Confirmed
Status in resource-agents source package in Eoan:
  Fix Committed
Status in resource-agents package in Debian:
  New

Bug description:
  [Impact]
  Some network interfaces will not be monitored by ethmonitor

  [Description]
  The is_interface() function in ethmonitor tries to match an interface to a 
list obtained from the 'ip' tool. It lists interfaces using the 'inet' family, 
which omits interfaces that don't have an IP address assigned.

  If the interface that we're looking for is e.g. a VLAN bridge that
  does not have an IP address, it won't show up in the listing and
  is_interface() will return false. ethmonitor will miss that interface,
  and it won't be available for monitoring.

  Upstream commits:
  - https://github.com/ClusterLabs/resource-agents/commit/40d05029ce0b 
  - https://github.com/ClusterLabs/resource-agents/commit/c0ac191c73f1

  [Test Case]
  1) Ensure there's a network interface without an assigned IP address. For 
example, virbr0-nic will be created automatically by uvt-kvm:
  # ip addr show dev virbr0-nic
  11: virbr0-nic:  mtu 1500 qdisc fq_codel 
master virbr0 state DOWN group default qlen 1000
  link/ether 52:54:00:e9:5e:af brd ff:ff:ff:ff:ff:ff

  2) Install pcs+arping and create a new ethmonitor resource with the target 
interface:
  # sudo apt update && sudo apt install pcs arping -y
  # pcs resource create p_nic ocf:heartbeat:ethmonitor interface=virbr0-nic op 
monitor timeout="10s"

  3) Debug-start ethmonitor resource and check for "Interface does not exist 
messages"
  # pcs resource debug-start p_nic
  Operation start for p_nic (ocf:heartbeat:ethmonitor) returned: 'ok' (0)
   >  stderr: WARNING: Interface virbr0-nic does not exist
   >  stderr: NOTICE: link_status: DOWN

  [Regression Potential]
  The regression potential is low, since we are relaxing the monitoring 
conditions for interfaces without an assigned IP address. The patches have been 
tested against Travis-CI before being merged upstream, and will be tested 
against autopkgtest for each target distro.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1825250/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1825250] Re: ethmonitor does not list interfaces without assigned IP address

[Eric Desrochers]

** Changed in: resource-agents (Ubuntu Eoan)
   Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1825250

Title:
  ethmonitor does not list interfaces without assigned IP address

Status in resource-agents package in Ubuntu:
  In Progress
Status in resource-agents source package in Xenial:
  Confirmed
Status in resource-agents source package in Bionic:
  Confirmed
Status in resource-agents source package in Cosmic:
  Confirmed
Status in resource-agents source package in Disco:
  Confirmed
Status in resource-agents source package in Eoan:
  In Progress
Status in resource-agents package in Debian:
  New

Bug description:
  [Impact]
  Some network interfaces will not be monitored by ethmonitor

  [Description]
  The is_interface() function in ethmonitor tries to match an interface to a 
list obtained from the 'ip' tool. It lists interfaces using the 'inet' family, 
which omits interfaces that don't have an IP address assigned.

  If the interface that we're looking for is e.g. a VLAN bridge that
  does not have an IP address, it won't show up in the listing and
  is_interface() will return false. ethmonitor will miss that interface,
  and it won't be available for monitoring.

  Upstream commits:
  - https://github.com/ClusterLabs/resource-agents/commit/40d05029ce0b 
  - https://github.com/ClusterLabs/resource-agents/commit/c0ac191c73f1

  [Test Case]
  1) Ensure there's a network interface without an assigned IP address. For 
example, virbr0-nic will be created automatically by uvt-kvm:
  # ip addr show dev virbr0-nic
  11: virbr0-nic:  mtu 1500 qdisc fq_codel 
master virbr0 state DOWN group default qlen 1000
  link/ether 52:54:00:e9:5e:af brd ff:ff:ff:ff:ff:ff

  2) Install pcs+arping and create a new ethmonitor resource with the target 
interface:
  # sudo apt update && sudo apt install pcs arping -y
  # pcs resource create p_nic ocf:heartbeat:ethmonitor interface=virbr0-nic op 
monitor timeout="10s"

  3) Debug-start ethmonitor resource and check for "Interface does not exist 
messages"
  # pcs resource debug-start p_nic
  Operation start for p_nic (ocf:heartbeat:ethmonitor) returned: 'ok' (0)
   >  stderr: WARNING: Interface virbr0-nic does not exist
   >  stderr: NOTICE: link_status: DOWN

  [Regression Potential]
  The regression potential is low, since we are relaxing the monitoring 
conditions for interfaces without an assigned IP address. The patches have been 
tested against Travis-CI before being merged upstream, and will be tested 
against autopkgtest for each target distro.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1825250/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1821343] Re: slapd process failure is not detected by systemd

[Eric Desrochers]

Sponsored in disco.

** Changed in: openldap (Ubuntu)
   Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1821343

Title:
  slapd process failure is not detected by systemd

Status in openldap package in Ubuntu:
  In Progress
Status in openldap source package in Xenial:
  Confirmed
Status in openldap source package in Bionic:
  Confirmed
Status in openldap source package in Cosmic:
  Confirmed
Status in openldap package in Debian:
  New

Bug description:
  [Impact]
  Systemd service reports slapd as active, even though it may have failed

  [Description]
  The slapd package for OpenLDAP is shipped with a SysV-style init script 
(/etc/init.d/slapd). Systemd automatically converts this to a systemd service 
by generating the unit file using the systemd-sysv-generator(8) utility. The 
generated unit file contains Type=forking and RemainAfterExit=yes directives.

  If the slapd daemon process exits due to some failure (e.g., it
  receives a SIGTERM or SIGKILL), the failure is not detected properly
  by systemd. The service is still reported as active even though the
  child (daemon) process has exited with a signal.

  We can easily fix this by including a proper systemd service file for
  slapd in the openldap package. Since the init.d script already does
  most of the necessary work (parsing configs, setting up PID files,
  etc.), we don't need anything complicated for the systemd unit file.
  Just making sure that RemainAfterExit is set to "no" makes the systemd
  service behave in the expected way.

  [Test Case]
  1) Deploy a disco container
  $ lxc launch images:ubuntu/disco disco

  2) Install slapd
  ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y

  3) Verify that slapd is running with the auto-generated service
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
     Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago
   Docs: man:systemd-sysv-generator(8)
    Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)
  Tasks: 3 (limit: 4915)
     Memory: 712.6M
     CGroup: /system.slice/slapd.service
     └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u 
openldap -F /etc/ldap/slapd.d

  4) SIGKILL the slapd process (PID is displayed in systemctl status output)
  ubuntu@disco:~$ sudo kill -9 1109

  5) Check if systemd service lists slapd as still active, even though it was 
terminated
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
     Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago
   Docs: man:systemd-sysv-generator(8)
    Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)

  6) Check if systemd has loaded both
  /run/systemd/generator.late/slapd.service &
  /usr/lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf

  $ systemctl cat slapd

  [Regression Potential]
  The regression potential for this fix should be very low, if we keep the new 
systemd unit file close to the one generated by systemd-sysv-generator(8). The 
only significant change would be the RemainAfterExit directive, and this should 
make the slapd service behave like a "normal" forking service. Nonetheless, 
we'll perform scripted test runs to make sure no regressions arise.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1821343] Re: slapd process failure is not detected by systemd

[Eric Desrochers]

** Description changed:

  [Impact]
  Systemd service reports slapd as active, even though it may have failed
  
  [Description]
  The slapd package for OpenLDAP is shipped with a SysV-style init script 
(/etc/init.d/slapd). Systemd automatically converts this to a systemd service 
by generating the unit file using the systemd-sysv-generator(8) utility. The 
generated unit file contains Type=forking and RemainAfterExit=yes directives.
  
  If the slapd daemon process exits due to some failure (e.g., it receives
  a SIGTERM or SIGKILL), the failure is not detected properly by systemd.
  The service is still reported as active even though the child (daemon)
  process has exited with a signal.
  
  We can easily fix this by including a proper systemd service file for
  slapd in the openldap package. Since the init.d script already does most
  of the necessary work (parsing configs, setting up PID files, etc.), we
  don't need anything complicated for the systemd unit file. Just making
  sure that RemainAfterExit is set to "no" makes the systemd service
  behave in the expected way.
  
  [Test Case]
  1) Deploy a disco container
  $ lxc launch images:ubuntu/disco disco
  
  2) Install slapd
  ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y
  
  3) Verify that slapd is running with the auto-generated service
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
-Loaded: loaded (/etc/init.d/slapd; generated)
-Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago
-  Docs: man:systemd-sysv-generator(8)
-   Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)
- Tasks: 3 (limit: 4915)
-Memory: 712.6M
-CGroup: /system.slice/slapd.service
-└─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u 
openldap -F /etc/ldap/slapd.d
+    Loaded: loaded (/etc/init.d/slapd; generated)
+    Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago
+  Docs: man:systemd-sysv-generator(8)
+   Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)
+ Tasks: 3 (limit: 4915)
+    Memory: 712.6M
+    CGroup: /system.slice/slapd.service
+    └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u 
openldap -F /etc/ldap/slapd.d
  
  4) SIGKILL the slapd process (PID is displayed in systemctl status output)
  ubuntu@disco:~$ sudo kill -9 1109
  
  5) Check if systemd service lists slapd as still active, even though it was 
terminated
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
-Loaded: loaded (/etc/init.d/slapd; generated)
-Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago
-  Docs: man:systemd-sysv-generator(8)
-   Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)
+    Loaded: loaded (/etc/init.d/slapd; generated)
+    Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago
+  Docs: man:systemd-sysv-generator(8)
+   Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)
+ 
+ 6) Check if systemd has loaded both
+ /run/systemd/generator.late/slapd.service &
+ /usr/lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf
+ 
+ $ systemctl cat slapd
  
  [Regression Potential]
  The regression potential for this fix should be very low, if we keep the new 
systemd unit file close to the one generated by systemd-sysv-generator(8). The 
only significant change would be the RemainAfterExit directive, and this should 
make the slapd service behave like a "normal" forking service. Nonetheless, 
we'll perform scripted test runs to make sure no regressions arise.

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1821343

Title:
  slapd process failure is not detected by systemd

Status in openldap package in Ubuntu:
  Confirmed
Status in openldap source package in Xenial:
  Confirmed
Status in openldap source package in Bionic:
  Confirmed
Status in openldap source package in Cosmic:
  Confirmed
Status in openldap package in Debian:
  New

Bug description:
  [Impact]
  Systemd service reports slapd as active, even though it may have failed

  [Description]
  The slapd package for OpenLDAP is shipped with a SysV-style init script 
(/etc/init.d/slapd). Systemd automatically converts this to a systemd service 
by generating the unit file using the systemd-sysv-generator(8) utility. The 
generated unit file contains Type=forking and RemainAfterExit=yes directives.

  If the slapd daemon process exits due to some failure (e.g., it
  receives a SIGTERM or SIGKILL), the failure is not detected properly
  by systemd. The service is still reported as active even though the
  child (daemon) process has exited with a signal.

  We 

[Sts-sponsors] [Bug 1821343] Re: slapd process failure is not detected by systemd

[Eric Desrochers]

[sts-sponsor note]

I am concerned about just adding the service unit, and not making your package 
work
with systemd, especially for maintainer scripts (may break package upgrade... 
would be good to test and add this to the [test case].

May I suggest you look at debian/control and debian/rules to evaluate if :
* Build-Depends of "dh-systemd" (debian/control) for the maintainer scripts to 
contain appropriate code 
* dh --with=systemd (debian/rules) 

are needed ?

https://people.debian.org/~stapelberg/debconf13-making-your-package-
work-with-systemd.pdf

Regards,
Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1821343

Title:
  slapd process failure is not detected by systemd

Status in openldap package in Ubuntu:
  Confirmed
Status in openldap source package in Xenial:
  Confirmed
Status in openldap source package in Bionic:
  Confirmed
Status in openldap source package in Cosmic:
  Confirmed
Status in openldap package in Debian:
  Unknown

Bug description:
  [Impact]
  Systemd service reports slapd as active, even though it may have failed

  [Description]
  The slapd package for OpenLDAP is shipped with a SysV-style init script 
(/etc/init.d/slapd). Systemd automatically converts this to a systemd service 
by generating the unit file using the systemd-sysv-generator(8) utility. The 
generated unit file contains Type=forking and RemainAfterExit=yes directives.

  If the slapd daemon process exits due to some failure (e.g., it
  receives a SIGTERM or SIGKILL), the failure is not detected properly
  by systemd. The service is still reported as active even though the
  child (daemon) process has exited with a signal.

  We can easily fix this by including a proper systemd service file for
  slapd in the openldap package. Since the init.d script already does
  most of the necessary work (parsing configs, setting up PID files,
  etc.), we don't need anything complicated for the systemd unit file.
  Just making sure that RemainAfterExit is set to "no" makes the systemd
  service behave in the expected way.

  [Test Case]
  1) Deploy a disco container
  $ lxc launch images:ubuntu/disco disco

  2) Install slapd
  ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y

  3) Verify that slapd is running with the auto-generated service
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
 Loaded: loaded (/etc/init.d/slapd; generated)
 Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago
   Docs: man:systemd-sysv-generator(8)
Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)
  Tasks: 3 (limit: 4915)
 Memory: 712.6M
 CGroup: /system.slice/slapd.service
 └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u 
openldap -F /etc/ldap/slapd.d

  4) SIGKILL the slapd process (PID is displayed in systemctl status output)
  ubuntu@disco:~$ sudo kill -9 1109

  5) Check if systemd service lists slapd as still active, even though it was 
terminated
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
 Loaded: loaded (/etc/init.d/slapd; generated)
 Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago
   Docs: man:systemd-sysv-generator(8)
Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)

  [Regression Potential]
  The regression potential for this fix should be very low, if we keep the new 
systemd unit file close to the one generated by systemd-sysv-generator(8). The 
only significant change would be the RemainAfterExit directive, and this should 
make the slapd service behave like a "normal" forking service. Nonetheless, 
we'll perform scripted test runs to make sure no regressions arise.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp

[Sts-sponsors] [Bug 1817738] Re: Can't change virtual terminal on login screen or when auto-login is enabled

[Eric Desrochers]

https://launchpad.net/ubuntu/+source/gdm3/+publishinghistory
Deleted Bionic  proposedmaingnome   3.28.3-0ubuntu18.04.5

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1817738

Title:
  Can't change virtual terminal on login screen or when auto-login is
  enabled

Status in OEM Priority Project:
  Confirmed
Status in gdm3 package in Ubuntu:
  Invalid
Status in plymouth package in Ubuntu:
  Fix Released
Status in gdm3 source package in Bionic:
  Invalid
Status in plymouth source package in Bionic:
  In Progress
Status in plymouth source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

  When AutomaticLogin is enabled in gdm3, or it is showing the login screen,
  the "chvt" command blocks indefinitely (usually resumes with gdm3 restart).

  This prevents users to change the foreground virtual terminal, and it can
  also prevent pm-suspend to complete (as it invokes chvt).

  This problem happens in Bionic; it's already fixed in Cosmic and
  later.

  This patch to plymouth helps it not to revert the VT/tty to VT_AUTO
  (after gdm calls 'plymouth deactivate' and changes it to VT_PROCESS)
  which causes the ioctl(VT_SETACTIVE) not to generate the event that
  the ioctl(VT_WAITACTIVE) will block/wait on just afterward.

  Workarounds are to either disable plymouth / remove 'splash' from the
  kernel command line or change it to use a different/non-graphical VT
  for console (console=tty0 [default] or console=tty1 [equivalent] are
  affected, but console=ttyS0 or console=ttyS1 are not, being serial).

  [Test case]

  1) Install Bionic/18.04 LTS Desktop

  2) Ensure plymouth / 'splash' is enabled (default)

  $ grep splash /proc/cmdline
  BOOT_IMAGE=... root=... splash ...

  3) Ensure console is tty0 (default) or tty1 
  $ dmesg | grep console
  [0.004000] console [tty0] enabled

  
  A) Login screen, regardless of automatic login

 4) Ensure the login screen/tty 1 is the displaying
(i.e., it's foregound/active VT) or change to it:

$ sudo chvt 1 # this works/finishes.
$

 5) $ ssh  'sudo fgconsole' # check tty1 is foreground VT
1

 6) $ ssh  'sudo chvt 4' # this blocks/doesn't finish

  
  B) Automatic login, regardless of login screen

 4) Enable AutomaticLogin in /etc/gdm3/custom.conf
   [daemon]
   AutomaticLoginEnable = true
   AutomaticLogin = 

 5) Reboot your system and make sure AutoLogin works by not
  requesting password before opening the  session.

 6) Print active VT
(in Bionic, autologin user session runs on tty1)

$ sudo fgconsole
1

 7) sudo chvt 4 # this blocks/doesn't finish

  
  From SSH one can check that chvt is blocked waiting
  on new VT to become active, which doesn't happen in
  this case (old VT in VT_AUTO + KB_GRAPHICS mode):

  $ cat /proc/$(pidof chvt)/stack
  [<0>] __vt_event_wait.isra.2.part.3+0x40/0x90
  [<0>] vt_waitactive+0x80/0xd0
  [<0>] vt_ioctl+0xd26/0x1140
  [<0>] tty_ioctl+0xf6/0x8c0
  [<0>] do_vfs_ioctl+0xa8/0x630
  [<0>] SyS_ioctl+0x79/0x90
  [<0>] do_syscall_64+0x73/0x130
  [<0>] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
  [<0>] 0x

  [Potential regression]

  Low.  This plymouth patch is upstream and it's already applied
  in Cosmic and later for ~6 months (0.9.3-1ubuntu10 / Oct 2018)
  for LP: #1795637 (different problem/effect, same root cause).

  Besides, it's conservative in nature, and it's spirit makes a
  lot of sense (stop handling more udev events after deactivate).
  There are no additional fixes to its code changes upstream.

  [Original Description]

  $ sudo strace chvt 4
  <...>
  openat(AT_FDCWD, "/dev/tty0", O_RDWR) = 3
  ioctl(3, TCGETS, {B38400 opost isig icanon echo ...}) = 0
  ioctl(3, KDGKBTYPE, 0x7ffdcdb0efa7) = 0
  ioctl(3, VT_ACTIVATE, 0x4) = 0
  ioctl(3, VT_WAITACTIVE, 0x4

  VT_ACTIVATE will cause a switch to VT number.
  VT_WAITACTIVE will sleep/wait until the specified VT has been activated.

  $ sudo cat /proc/$(pidof chvt)/stack
  [<0>] __vt_event_wait.isra.2.part.3+0x40/0x90
  [<0>] vt_waitactive+0x80/0xd0
  [<0>] vt_ioctl+0xd26/0x1140
  [<0>] tty_ioctl+0xf6/0x8c0
  [<0>] do_vfs_ioctl+0xa8/0x630
  [<0>] SyS_ioctl+0x79/0x90
  [<0>] do_syscall_64+0x73/0x130
  [<0>] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
  [<0>] 0x

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1817738/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp