[Touch-packages] [Bug 1906364] Re: unattended-upgrade still restarts blacklisted daemons

2020-12-04 Thread Bryce Harrington
I'd like to give you all an update and outline our plans for this.

The Canonical server team has made analysis of this issue a top
priority.  We've identified and tested out several possible theories.
Our findings suggest that the breakage involves two distinct issues, one
the BindTo= issue mentioned above, the other caused by a bug in the
docker.io package causing the service to stop on package upgrade; see
specifically the service stop command at the end of
/var/lib/dpkg/info/docker.io.prerm.  We'll use LP: #1870514 to track the
former issue, and #1906364 the latter.  LP: #1658691 gives some past
background for reference.

The tricky part is that unfortunately any change we make to docker.io
requires the running of the prerm script (the version of the script
already present on your system, not the one we'd be installing), and
thus triggers the bug.  In other words, updating your system to prevent
the bug will cause one more docker stop.  Thereafter, the upgrade will
not restart the service when rolling out CVE fixes to either containerd
or docker.io; it may prompt to do so if running interactively (e.g.
https://imgur.com/2Za5dbQ.png), otherwise it should respect the debconf
setting.

We would appreciate feedback, testing and/or review of the proposed fix,
available in this PPA:

   https://launchpad.net/~bryce/+archive/ubuntu/containerd-sru-lp1870514
-docker-dh/


** Also affects: unattended-upgrades (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: docker.io (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

** Also affects: unattended-upgrades (Ubuntu Hirsute)
   Importance: Undecided
   Status: Won't Fix

** Also affects: docker.io (Ubuntu Hirsute)
   Importance: Undecided
   Status: Confirmed

** Also affects: containerd (Ubuntu Hirsute)
   Importance: Undecided
   Status: Confirmed

** Also affects: unattended-upgrades (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: docker.io (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

** Also affects: unattended-upgrades (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: docker.io (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: containerd (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: unattended-upgrades (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: docker.io (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: containerd (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: unattended-upgrades (Ubuntu Groovy)
   Status: New => Won't Fix

** No longer affects: containerd (Ubuntu)

** Changed in: unattended-upgrades (Ubuntu Focal)
   Status: New => Won't Fix

** Changed in: unattended-upgrades (Ubuntu Bionic)
   Status: New => Won't Fix

** Changed in: unattended-upgrades (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: docker.io (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: docker.io (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: docker.io (Ubuntu Xenial)
 Assignee: (unassigned) => Bryce Harrington (bryce)

** Changed in: docker.io (Ubuntu Xenial)
   Importance: High => Critical

** Changed in: docker.io (Ubuntu Bionic)
   Importance: Undecided => Critical

** Changed in: docker.io (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: docker.io (Ubuntu Focal)
   Importance: Undecided => Critical

** Changed in: docker.io (Ubuntu Focal)
   Status: New => In Progress

** Changed in: docker.io (Ubuntu Groovy)
   Importance: Undecided => Critical

** Changed in: docker.io (Ubuntu Groovy)
   Status: New => In Progress

** Changed in: docker.io (Ubuntu Hirsute)
   Importance: Undecided => Critical

** Changed in: docker.io (Ubuntu Hirsute)
   Status: Confirmed => In Progress

** Changed in: docker.io (Ubuntu Hirsute)
 Assignee: (unassigned) => Bryce Harrington (bryce)

** No longer affects: containerd (Ubuntu Xenial)

** No longer affects: containerd (Ubuntu Bionic)

** No longer affects: containerd (Ubuntu Focal)

** No longer affects: containerd (Ubuntu Groovy)

** No longer affects: containerd (Ubuntu Hirsute)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1906364

Title:
  unattended-upgrade still restarts blacklisted daemons

Status in docker.io package in Ubuntu:
  In Progress
Status in unattended-upgrades package in Ubuntu:
  Won't Fix
Status in docker.io source package in Xenial:
  In Progress
Status in unattended-upgrades source package in Xen

[Touch-packages] [Bug 1906364] Re: unattended-upgrade still restarts blacklisted daemons

2020-12-02 Thread Bryce Harrington
This sounds like another dupe of
https://bugs.launchpad.net/ubuntu/+source/containerd/+bug/1870514

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1906364

Title:
  unattended-upgrade still restarts blacklisted daemons

Status in containerd package in Ubuntu:
  Confirmed
Status in docker.io package in Ubuntu:
  Confirmed
Status in unattended-upgrades package in Ubuntu:
  Won't Fix

Bug description:
  Hello,

  Today plenty of our systems running ubuntu 20.04 were restarting the
  docker daemon, even if i blacklisted the docker package. Since docker
  has an dependency on containerd thats the reason why it was restarted.
  IMO the blacklist should also check the full tree of dependencies...
  This should NOT happen!

  From the log you find:

  2020-12-01 06:40:13,881 INFO Starting unattended upgrades script
  2020-12-01 06:40:13,882 INFO Allowed origins are: o=Ubuntu,a=focal, 
o=Ubuntu,a=focal-security, o=UbuntuESMApps,a=focal-apps-security, 
o=UbuntuESM,a=focal-infra-security
  2020-12-01 06:40:13,882 INFO Initial blacklist: docker docker.io
  2020-12-01 06:40:13,882 INFO Initial whitelist (not strict):
  2020-12-01 06:40:19,139 INFO Packages that will be upgraded: containerd 
qemu-block-extra qemu-kvm qemu-system-common qemu-system-data qemu-system-gui 
qemu-system-x86 qemu-utils
  2020-12-01 06:40:19,140 INFO Writing dpkg log to 
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log
  2020-12-01 06:40:46,996 INFO All upgrades installed
  2020-12-01 06:40:50,732 INFO Starting unattended upgrades script
  2020-12-01 06:40:50,732 INFO Allowed origins are: o=Ubuntu,a=focal, 
o=Ubuntu,a=focal-security, o=UbuntuESMApps,a=focal-apps-security, 
o=UbuntuESM,a=focal-infra-security
  2020-12-01 06:40:50,733 INFO Initial blacklist: docker docker.io
  2020-12-01 06:40:50,733 INFO Initial whitelist (not strict):

  Also this happened for us on plenty of our servers almost at the same
  (why the unattended updates are not spread over time?), which
  destroyed the second time an production environment.

  This is not how unattended-upgraded should be, sadly this package lost
  our trust and we disable it and schedule the 'unattended updates' now
  on our own.

  PS: Not to say that on some servers the docker daemon did not even
  restart..

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

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


[Touch-packages] [Bug 1905088] Re: failed to install/upgrade: sshd_config: line 13: Bad configuration option

2020-11-24 Thread Bryce Harrington
Hi Huy,

The bug report appears to indicate some sort of syntax error in your
/etc/ssh/sshd_config file.  What's on line 13 of that file?

SSHDConfig:
 Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 255: 
/etc/ssh/sshd_config: line 13: Bad configuration option: Include
 /etc/ssh/sshd_config: terminating, 1 bad configuration options

If you're uncertain, then can you please attach your
/etc/ssh/sshd_config for us to review?  If that file contains any
information that is security sensitive or personally identifying please
change this bug report from "Public" to "Private".  Thanks ahead of
time.

** Summary changed:

- package openssh-server 1:7.6p1-4ubuntu0.3 failed to install/upgrade: 
installed openssh-server package post-installation script subprocess returned 
error exit status 1
+ failed to install/upgrade:  sshd_config: line 13: Bad configuration option

** Changed in: openssh (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1905088

Title:
  failed to install/upgrade:  sshd_config: line 13: Bad configuration
  option

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  Unpacking openssh-server (1:7.6p1-4ubuntu0.3) ...
  Setting up openssh-server (1:7.6p1-4ubuntu0.3) ...
  Job for ssh.service failed because the control process exited with error code.
  See "systemctl status ssh.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript ssh, action "restart" failed.
  ● ssh.service - OpenBSD Secure Shell server
 Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: 
enabled)
 Active: activating (auto-restart) (Result: exit-code) since Fri 2020-11-20 
22:09:42 CET; 20ms ago
Process: 2918 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=255)
  dpkg: error processing package openssh-server (--configure):
   installed openssh-server package post-installation script subprocess 
returned error exit status 1
  Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
  Processing triggers for ufw (0.36-0ubuntu0.18.04.1) ...
  Rules updated for profile 'OpenSSH'
  Firewall reloaded
  Processing triggers for ureadahead (0.100.0-21) ...
  ureadahead will be reprofiled on next reboot
  Processing triggers for systemd (237-3ubuntu10.43) ...
  Errors were encountered while processing:
   openssh-server

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: openssh-server 1:7.6p1-4ubuntu0.3
  ProcVersionSignature: Ubuntu 4.15.0-124.127-generic 4.15.18
  Uname: Linux 4.15.0-124-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.20
  Architecture: amd64
  Date: Fri Nov 20 22:00:10 2020
  ErrorMessage: installed openssh-server package post-installation script 
subprocess returned error exit status 1
  InstallationDate: Installed on 2018-12-27 (694 days ago)
  InstallationMedia: Ubuntu 16.04.4 LTS "Xenial Xerus" - Release amd64 
(20180228)
  Python3Details: /usr/bin/python3.6, Python 3.6.9, python3-minimal, 
3.6.7-1~18.04
  PythonDetails: /usr/bin/python2.7, Python 2.7.17, python-minimal, 2.7.15~rc1-1
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2.3
   apt  1.6.12ubuntu0.1
  SSHDConfig:
   Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 255: 
/etc/ssh/sshd_config: line 13: Bad configuration option: Include
   /etc/ssh/sshd_config: terminating, 1 bad configuration options
  SourcePackage: openssh
  Title: package openssh-server 1:7.6p1-4ubuntu0.3 failed to install/upgrade: 
installed openssh-server package post-installation script subprocess returned 
error exit status 1
  UpgradeStatus: Upgraded to bionic on 2020-06-16 (157 days ago)

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

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


[Touch-packages] [Bug 1890332] Re: apt update fails on unprivileged docker arm container due to invalid gpg signature

2020-11-24 Thread Bryce Harrington
For the privileged/unprivileged issue mentioned in comment #6, these upstream 
comments appears to be pertinent, suggesting patches that may be worth 
backporting:
  https://github.com/moby/moby/issues/40734#issuecomment-614259072
  https://github.com/moby/moby/issues/40734#issuecomment-680250761

As to the gpg errors in comment #8, I suspect those are unrelated.
Those types of errors can crop up for a wide variety of reasons,
including insufficient disk space, networking glitches, gpg problems,
etc. all mostly unrelated to the package itself, so I would suggest
looking to regular support channels for help there, for example see
https://superuser.com/questions/1059346/apt-get-update-not-working-
signing-verification-errors which suggests several solutions.  If not,
let us know.

However, it's possible that the gpg error is hiding the earlier error,
and potentially once its resolved the earlier error will come back.  So
I'll leave this issue open for now.

** Changed in: libseccomp (Ubuntu)
   Status: Confirmed => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1890332

Title:
  apt update fails on unprivileged docker arm container due to invalid
  gpg signature

Status in libseccomp package in Ubuntu:
  Incomplete

Bug description:
  Running `apt update` in a ubuntu:20.04 docker container on raspberry
  pi fails with GPG errors.

  Expected behaviour:

  Successfully update the system through `apt update`

  What happens instead:

  `Err:1 http://ports.ubuntu.com/ubuntu-ports focal InRelease
    At least one invalid signature was encountered.`

  Complete log:
  https://pastebin.com/sggGJcY1

  How to reproduce:
  On a Raspberry Pi 3b or 4b (and maybe others ?), run the following command:
  `docker run ubuntu:latest apt update`
  or more specifically:
  `docker run arm32v7/ubuntu:20.04 apt update`

  More information:
  I can reproduce the bug on the following host systems:
  * Raspberry Pi 3b running HypriotOS
  * Raspberry Pi 4b running Raspbian GNU/Linux 10 (buster)

  The problem does not happens on the following host system:
  * Raspberry Pi 3b running Arch Linux Arm

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

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


[Touch-packages] [Bug 1890332] Re: apt update fails on unprivileged docker arm container due to inaccessible clock

2020-11-24 Thread Bryce Harrington
** Summary changed:

- apt update fails on docker arm container 20.04
+ apt update fails on unprivileged docker arm container due to inaccessible 
clock

** Summary changed:

- apt update fails on unprivileged docker arm container due to inaccessible 
clock
+ apt update fails on unprivileged docker arm container due to invalid gpg 
signature

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1890332

Title:
  apt update fails on unprivileged docker arm container due to invalid
  gpg signature

Status in libseccomp package in Ubuntu:
  Confirmed

Bug description:
  Running `apt update` in a ubuntu:20.04 docker container on raspberry
  pi fails with GPG errors.

  Expected behaviour:

  Successfully update the system through `apt update`

  What happens instead:

  `Err:1 http://ports.ubuntu.com/ubuntu-ports focal InRelease
    At least one invalid signature was encountered.`

  Complete log:
  https://pastebin.com/sggGJcY1

  How to reproduce:
  On a Raspberry Pi 3b or 4b (and maybe others ?), run the following command:
  `docker run ubuntu:latest apt update`
  or more specifically:
  `docker run arm32v7/ubuntu:20.04 apt update`

  More information:
  I can reproduce the bug on the following host systems:
  * Raspberry Pi 3b running HypriotOS
  * Raspberry Pi 4b running Raspbian GNU/Linux 10 (buster)

  The problem does not happens on the following host system:
  * Raspberry Pi 3b running Arch Linux Arm

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

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


[Touch-packages] [Bug 1902540] Re: hirsute fails on add-apt-repository

2020-11-02 Thread Bryce Harrington
I'm able to reproduce this in a hirsute lxc container I created today.

Interestingly, another hirsute container I created Friday doesn't
reproduce this issue even when updated to current.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1902540

Title:
  hirsute fails on add-apt-repository

Status in software-properties package in Ubuntu:
  Confirmed

Bug description:
  On a fully updated hirsute add-apt-repository fails, example:

  root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321
  Traceback (most recent call last):
File "/usr/bin/add-apt-repository", line 330, in 
  addaptrepo = AddAptRepository()
File "/usr/bin/add-apt-repository", line 35, in __init__
  self.distro.get_sources(self.sourceslist)
File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in 
get_sources
  raise NoDistroTemplateException(
  aptsources.distro.NoDistroTemplateException: Error: could not find a 
distribution template for Ubuntu/hirsute

  The PPA seems not to matter (all trigger it) and if I manually add PPA
  sources list and GPG key it works. So maybe software-properties just
  needs to learn about hirsute?

  Or is there another components (like distro-info or such) that needs a
  bump for this to work?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1902540/+subscriptions

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


[Touch-packages] [Bug 1857036] Re: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container.

2020-07-16 Thread Bryce Harrington
** Changed in: sudo (Ubuntu Focal)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1857036

Title:
  `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE):
  Operation not permitted` error when run inside a container.

Status in sudo package in Ubuntu:
  Fix Released
Status in sudo source package in Focal:
  Fix Committed
Status in sudo source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  Logging in as a sudo user in a Ubuntu Focal Linux container displays a
  warning:

    sudo: setrlimit(RLIMIT_CORE): Operation not permitted

  The warning is entirely unnecessary - the container is trying to adjust
  RLIMIT_CORE, but this isn't allowed inside a container anyway.

  While this is "just" a warning, logging into a container as sudo is a
  very common practice, so this warning risks creating confusion for LTS
  users.

  [Test Case]
  $ lxc launch ubuntu:20.04/amd64 sudo-sru-lp1857036-test
  $ lxc shell sudo-sru-lp1857036-test

  # sudo --login --user ubuntu
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  To run a command as administrator (user "root"), use "sudo ".
  See "man sudo_root" for details.
  $ logout

  Install the PPA
  # apt-add-repository -yus ppa:bryce/sudo-sru-lp1857036-setrlimit-in-lxc
  # apt-get install sudo

  # sudo --login --user ubuntu
  $

  [Regression Potential]
  As this only affects printing of a couple warnings, the only behavioral
  change is in stderr output.

  [Discussion]
  This changes a couple warnings into equivalent debug printfs, which
  brings the sudo behavior in-line with the behavior in groovy, bionic,
  etc. and should cause no troubles.

  This patch originates from upstream, and is already in groovy's sudo
  package (which thus can be seen not to exhibit the issue).

  The upstream patch includes some new debug prints which should be
  harmless but are unnecessary to the fix so they've been removed.

  [Original Report]
  When using `sudo --login --user USERNAME` with Ubuntu Focal currently, it 
will correctly operate but it will also throw the following error before 
continuing with the logon process (which completes successfully except for the 
stated error):

  sudo: setrlimit(RLIMIT_CORE): Operation not permitted

  A full run of this was tested in a Focal LXD container after dropping
  to a root shell to reproduce (arstotzka is the host system, focal-test
  is the test container):

  teward@arstotzka:~$ lxc shell focal-test
  root@focal-test:~# sudo --login --user ubuntu
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  To run a command as administrator (user "root"), use "sudo ".
  See "man sudo_root" for details.

  ubuntu@focal-test:~$

  This appears to be similar to this issue identified on RedHat's
  tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1773148

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: sudo 1.8.29-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18
  Uname: Linux 4.15.0-72-generic x86_64
  ApportVersion: 2.20.11-0ubuntu14
  Architecture: amd64
  Date: Thu Dec 19 17:16:31 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  SourcePackage: sudo
  UpgradeStatus: No upgrade log present (probably fresh install)
  VisudoCheck:
   /etc/sudoers: parsed OK
   /etc/sudoers.d/90-cloud-init-users: parsed OK
   /etc/sudoers.d/README: parsed OK

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

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


[Touch-packages] [Bug 1857036] Re: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container.

2020-07-15 Thread Bryce Harrington
** Changed in: sudo (Ubuntu Focal)
   Status: Triaged => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1857036

Title:
  `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE):
  Operation not permitted` error when run inside a container.

Status in sudo package in Ubuntu:
  Fix Released
Status in sudo source package in Focal:
  In Progress
Status in sudo source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  Logging in as a sudo user in a Ubuntu Focal Linux container displays a
  warning:

    sudo: setrlimit(RLIMIT_CORE): Operation not permitted

  The warning is entirely unnecessary - the container is trying to adjust
  RLIMIT_CORE, but this isn't allowed inside a container anyway.

  While this is "just" a warning, logging into a container as sudo is a
  very common practice, so this warning risks creating confusion for LTS
  users.

  [Test Case]
  $ lxc launch ubuntu:20.04/amd64 sudo-sru-lp1857036-test
  $ lxc shell sudo-sru-lp1857036-test

  # sudo --login --user ubuntu
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  To run a command as administrator (user "root"), use "sudo ".
  See "man sudo_root" for details.
  $ logout

  Install the PPA
  # apt-add-repository -yus ppa:bryce/sudo-sru-lp1857036-setrlimit-in-lxc
  # apt-get install sudo

  # sudo --login --user ubuntu
  $

  [Regression Potential]
  As this only affects printing of a couple warnings, the only behavioral
  change is in stderr output.

  [Discussion]
  This changes a couple warnings into equivalent debug printfs, which
  brings the sudo behavior in-line with the behavior in groovy, bionic,
  etc. and should cause no troubles.

  This patch originates from upstream, and is already in groovy's sudo
  package (which thus can be seen not to exhibit the issue).

  The upstream patch includes some new debug prints which should be
  harmless but are unnecessary to the fix so they've been removed.

  [Original Report]
  When using `sudo --login --user USERNAME` with Ubuntu Focal currently, it 
will correctly operate but it will also throw the following error before 
continuing with the logon process (which completes successfully except for the 
stated error):

  sudo: setrlimit(RLIMIT_CORE): Operation not permitted

  A full run of this was tested in a Focal LXD container after dropping
  to a root shell to reproduce (arstotzka is the host system, focal-test
  is the test container):

  teward@arstotzka:~$ lxc shell focal-test
  root@focal-test:~# sudo --login --user ubuntu
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  To run a command as administrator (user "root"), use "sudo ".
  See "man sudo_root" for details.

  ubuntu@focal-test:~$

  This appears to be similar to this issue identified on RedHat's
  tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1773148

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: sudo 1.8.29-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18
  Uname: Linux 4.15.0-72-generic x86_64
  ApportVersion: 2.20.11-0ubuntu14
  Architecture: amd64
  Date: Thu Dec 19 17:16:31 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  SourcePackage: sudo
  UpgradeStatus: No upgrade log present (probably fresh install)
  VisudoCheck:
   /etc/sudoers: parsed OK
   /etc/sudoers.d/90-cloud-init-users: parsed OK
   /etc/sudoers.d/README: parsed OK

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

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


[Touch-packages] [Bug 1857036] Re: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container.

2020-07-15 Thread Bryce Harrington
** Description changed:

  [Impact]
  Logging in as a sudo user in a Ubuntu Focal Linux container displays a
  warning:
  
-   sudo: setrlimit(RLIMIT_CORE): Operation not permitted
+   sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  
  The warning is entirely unnecessary - the container is trying to adjust
  RLIMIT_CORE, but this isn't allowed inside a container anyway.
  
  While this is "just" a warning, logging into a container as sudo is a
  very common practice, so this warning risks creating confusion for LTS
  users.
  
  [Test Case]
  $ lxc launch ubuntu:20.04/amd64 sudo-sru-lp1857036-test
  $ lxc shell sudo-sru-lp1857036-test
  
  # sudo --login --user ubuntu
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  To run a command as administrator (user "root"), use "sudo ".
  See "man sudo_root" for details.
  $ logout
  
  Install the PPA
  # apt-add-repository -yus ppa:bryce/sudo-sru-lp1857036-setrlimit-in-lxc
  # apt-get install sudo
  
  # sudo --login --user ubuntu
- To run a command as administrator (user "root"), use "sudo ".
- See "man sudo_root" for details.
  $
  
  [Regression Potential]
  As this only affects printing of a couple warnings, the only behavioral
  change is in stderr output.
  
  [Discussion]
  This changes a couple warnings into equivalent debug printfs, which
  brings the sudo behavior in-line with the behavior in groovy, bionic,
  etc. and should cause no troubles.
  
  This patch originates from upstream, and is already in groovy's sudo
  package (which thus can be seen not to exhibit the issue).
  
  The upstream patch includes some new debug prints which should be
  harmless but are unnecessary to the fix so they've been removed.
- 
  
  [Original Report]
  When using `sudo --login --user USERNAME` with Ubuntu Focal currently, it 
will correctly operate but it will also throw the following error before 
continuing with the logon process (which completes successfully except for the 
stated error):
  
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  
  A full run of this was tested in a Focal LXD container after dropping to
  a root shell to reproduce (arstotzka is the host system, focal-test is
  the test container):
  
  teward@arstotzka:~$ lxc shell focal-test
  root@focal-test:~# sudo --login --user ubuntu
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  To run a command as administrator (user "root"), use "sudo ".
  See "man sudo_root" for details.
  
  ubuntu@focal-test:~$
  
  This appears to be similar to this issue identified on RedHat's tracker:
  https://bugzilla.redhat.com/show_bug.cgi?id=1773148
  
  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: sudo 1.8.29-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18
  Uname: Linux 4.15.0-72-generic x86_64
  ApportVersion: 2.20.11-0ubuntu14
  Architecture: amd64
  Date: Thu Dec 19 17:16:31 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  SourcePackage: sudo
  UpgradeStatus: No upgrade log present (probably fresh install)
  VisudoCheck:
   /etc/sudoers: parsed OK
   /etc/sudoers.d/90-cloud-init-users: parsed OK
   /etc/sudoers.d/README: parsed OK

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1857036

Title:
  `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE):
  Operation not permitted` error when run inside a container.

Status in sudo package in Ubuntu:
  Fix Released
Status in sudo source package in Focal:
  Triaged
Status in sudo source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  Logging in as a sudo user in a Ubuntu Focal Linux container displays a
  warning:

    sudo: setrlimit(RLIMIT_CORE): Operation not permitted

  The warning is entirely unnecessary - the container is trying to adjust
  RLIMIT_CORE, but this isn't allowed inside a container anyway.

  While this is "just" a warning, logging into a container as sudo is a
  very common practice, so this warning risks creating confusion for LTS
  users.

  [Test Case]
  $ lxc launch ubuntu:20.04/amd64 sudo-sru-lp1857036-test
  $ lxc shell sudo-sru-lp1857036-test

  # sudo --login --user ubuntu
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  To run a command as administrator (user "root"), use "sudo ".
  See "man sudo_root" for details.
  $ logout

  Install the PPA
  # apt-add-repository -yus ppa:bryce/sudo-sru-lp1857036-setrlimit-in-lxc
  # apt-get install sudo

  # sudo --login --user ubuntu
  $

  [Regression Potential]
  As this only affects printing of a couple warnings, the only behavioral
  change is in stderr output.

  [Discussion]
  This changes a couple warnings into equivalent debug printfs, which
  brings the sudo behavior in-line with the behavior in groovy, bionic,
  etc. and should cause no troubles.

  This patch originates from upstream, and is already in groovy's 

[Touch-packages] [Bug 1857036] Re: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container.

2020-07-15 Thread Bryce Harrington
** Description changed:

- When using `sudo --login --user USERNAME` with Ubuntu Focal currently,
- it will correctly operate but it will also throw the following error
- before continuing with the logon process (which completes successfully
- except for the stated error):
+ [Impact]
+ Logging in as a sudo user in a Ubuntu Focal Linux container displays a
+ warning:
+ 
+   sudo: setrlimit(RLIMIT_CORE): Operation not permitted
+ 
+ The warning is entirely unnecessary - the container is trying to adjust
+ RLIMIT_CORE, but this isn't allowed inside a container anyway.
+ 
+ While this is "just" a warning, logging into a container as sudo is a
+ very common practice, so this warning risks creating confusion for LTS
+ users.
+ 
+ [Test Case]
+ $ lxc launch ubuntu:20.04/amd64 sudo-sru-lp1857036-test
+ $ lxc shell sudo-sru-lp1857036-test
+ 
+ # sudo --login --user ubuntu
+ sudo: setrlimit(RLIMIT_CORE): Operation not permitted
+ To run a command as administrator (user "root"), use "sudo ".
+ See "man sudo_root" for details.
+ $ logout
+ 
+ Install the PPA
+ # apt-add-repository -yus ppa:bryce/sudo-sru-lp1857036-setrlimit-in-lxc
+ # apt-get install sudo
+ 
+ # sudo --login --user ubuntu
+ To run a command as administrator (user "root"), use "sudo ".
+ See "man sudo_root" for details.
+ $
+ 
+ [Regression Potential]
+ As this only affects printing of a couple warnings, the only behavioral
+ change is in stderr output.
+ 
+ [Discussion]
+ This changes a couple warnings into equivalent debug printfs, which
+ brings the sudo behavior in-line with the behavior in groovy, bionic,
+ etc. and should cause no troubles.
+ 
+ This patch originates from upstream, and is already in groovy's sudo
+ package (which thus can be seen not to exhibit the issue).
+ 
+ The upstream patch includes some new debug prints which should be
+ harmless but are unnecessary to the fix so they've been removed.
+ 
+ 
+ [Original Report]
+ When using `sudo --login --user USERNAME` with Ubuntu Focal currently, it 
will correctly operate but it will also throw the following error before 
continuing with the logon process (which completes successfully except for the 
stated error):
  
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  
  A full run of this was tested in a Focal LXD container after dropping to
  a root shell to reproduce (arstotzka is the host system, focal-test is
  the test container):
  
  teward@arstotzka:~$ lxc shell focal-test
  root@focal-test:~# sudo --login --user ubuntu
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  To run a command as administrator (user "root"), use "sudo ".
  See "man sudo_root" for details.
  
  ubuntu@focal-test:~$
  
  This appears to be similar to this issue identified on RedHat's tracker:
  https://bugzilla.redhat.com/show_bug.cgi?id=1773148
  
  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: sudo 1.8.29-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18
  Uname: Linux 4.15.0-72-generic x86_64
  ApportVersion: 2.20.11-0ubuntu14
  Architecture: amd64
  Date: Thu Dec 19 17:16:31 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  SourcePackage: sudo
  UpgradeStatus: No upgrade log present (probably fresh install)
  VisudoCheck:
   /etc/sudoers: parsed OK
   /etc/sudoers.d/90-cloud-init-users: parsed OK
   /etc/sudoers.d/README: parsed OK

** Changed in: sudo (Ubuntu Focal)
 Assignee: (unassigned) => Bryce Harrington (bryce)

** Changed in: sudo (Ubuntu Focal)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1857036

Title:
  `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE):
  Operation not permitted` error when run inside a container.

Status in sudo package in Ubuntu:
  Fix Released
Status in sudo source package in Focal:
  Triaged
Status in sudo source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  Logging in as a sudo user in a Ubuntu Focal Linux container displays a
  warning:

sudo: setrlimit(RLIMIT_CORE): Operation not permitted

  The warning is entirely unnecessary - the container is trying to adjust
  RLIMIT_CORE, but this isn't allowed inside a container anyway.

  While this is "just" a warning, logging into a container as sudo is a
  very common practice, so this warning risks creating confusion for LTS
  users.

  [Test Case]
  $ lxc launch ubuntu:20.04/amd64 sudo-sru-lp1857036-test
  $ lxc shell sudo-sru-lp1857036-test

  # sudo --login --user ubuntu
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  To run a command as administrator (user "root"), use "sudo ".
  See "man sudo_root" for details.
  $ logout

  Install the PPA
  # apt-add-repository -yu

[Touch-packages] [Bug 1827159] Re: check_all_disks includes squashfs /snap/* which are 100%

2020-07-10 Thread Bryce Harrington
df no longer shows squashfs mounts by default, as of today's coreutils
update

** Changed in: coreutils (Ubuntu)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/1827159

Title:
  check_all_disks includes squashfs /snap/* which are 100%

Status in Nagios Charm:
  Fix Released
Status in coreutils package in Ubuntu:
  Fix Released
Status in monitoring-plugins package in Ubuntu:
  Fix Released

Bug description:
  [Impact]
  False positive reports are generated in monitoring tools when artificial 
filesystems are mounted, since they show 100% disk utilization, and thus add 
unnecessary (but dire sounding) "DISK CRITICAL" noise.

  [Test Case]
  $ lxc create ubuntu-daily:19.10/amd64 lp1827159
  $ lxc exec lp1827159 bash
  # apt-get -y update
  # apt-get install monitoring-plugins
  # snap install gnome-calculator
  [...]
  # /usr/lib/nagios/plugins/check_disk -w 10 -c 10
  DISK CRITICAL - free space: / 1903 MB (1% inode=78%); /dev 0 MB (100% 
inode=99%); /dev/full 16018 MB (100% inode=99%); /dev/null 16018 MB (100% 
inode=99%); /dev/random 16018 MB (100% inode=99%); /dev/tty 16018 MB (100% 
inode=99%); /dev/urandom 16018 MB (100% inode=99%); /dev/zero 16018 MB (100% 
inode=99%); /dev/fuse 16018 MB (100% inode=99%); /dev/net/tun 16018 MB (100% 
inode=99%); /dev/lxd 0 MB (100% inode=99%); /dev/.lxd-mounts 0 MB (100% 
inode=99%); /dev/shm 16041 MB (100% inode=99%); /run 3208 MB (99% inode=99%); 
/run/lock 5 MB (100% inode=99%); /sys/fs/cgroup 16041 MB (100% inode=99%); 
/snap 1903 MB (1% inode=78%); /run/snapd/ns 3208 MB (99% inode=99%);| 
/=71MB;119160;119160;0;119170 /dev=0MB;-10;-10;0;0 
/dev/full=0MB;16008;16008;0;16018 /dev/null=0MB;16008;16008;0;16018 
/dev/random=0MB;16008;16008;0;16018 /dev/tty=0MB;16008;16008;0;16018 
/dev/urandom=0MB;16008;16008;0;16018 /dev/zero=0MB;16008;16008;0;16018 
/dev/fuse=0MB;16008;16008;0;16018 /dev/net/tun=0MB;16008;16008;0;16018 
/dev/lxd=0MB;-10;-10;0;0 /dev/.lxd-mounts=0MB;-10;-10;0;0 
/dev/shm=0MB;16031;16031;0;16041 /run=0MB;3198;3198;0;3208 
/run/lock=0MB;-5;-5;0;5 /sys/fs/cgroup=0MB;16031;16031;0;16041 
/snap=71MB;119160;119160;0;119170 /run/snapd/ns=0MB;3198;3198;0;3208

  # /usr/lib/nagios/plugins/check_disk -w 10 -c 10 -e -X squashfs
  DISK CRITICAL - free space: /dev 0 MB (100% inode=99%); /dev/lxd 0 MB (100% 
inode=99%); /dev/.lxd-mounts 0 MB (100% inode=99%); /run/lock 5 MB (100% 
inode=99%);| /=111392MB;119160;119160;0;119170 /dev=0MB;-10;-10;0;0 
/dev/full=0MB;16008;16008;0;16018 /dev/null=0MB;16008;16008;0;16018 
/dev/random=0MB;16008;16008;0;16018 /dev/tty=0MB;16008;16008;0;16018 
/dev/urandom=0MB;16008;16008;0;16018 /dev/zero=0MB;16008;16008;0;16018 
/dev/fuse=0MB;16008;16008;0;16018 /dev/net/tun=0MB;16008;16008;0;16018 
/dev/lxd=0MB;-10;-10;0;0 /dev/.lxd-mounts=0MB;-10;-10;0;0 
/dev/shm=0MB;16031;16031;0;16041 /run=0MB;3198;3198;0;3208 
/run/lock=0MB;-5;-5;0;5 /sys/fs/cgroup=0MB;16031;16031;0;16041 
/snap=111392MB;119160;119160;0;119170 /run/snapd/ns=0MB;3198;3198;0;3208

  # /usr/lib/nagios/plugins/check_disk -w 10 -c 10 -e -X tmpfs
  DISK OK| /=71MB;119160;119160;0;119170 /dev/full=0MB;16008;16008;0;16018 
/dev/null=0MB;16008;16008;0;16018 /dev/random=0MB;16008;16008;0;16018 
/dev/tty=0MB;16008;16008;0;16018 /dev/urandom=0MB;16008;16008;0;16018 
/dev/zero=0MB;16008;16008;0;16018 /dev/fuse=0MB;16008;16008;0;16018 
/dev/net/tun=0MB;16008;16008;0;16018 /snap=71MB;119160;119160;0;119170

  [Regression Potential]
  As this alters the logic of how out-of-space checks are handled, relevant 
issues to keep an eye out for would relate to filesystem checks reporting 
improperly.  These tools underlay a few different front-ends, so regression 
bugs may get filed in a few different places, however they will tend to display 
error messages involving check_disk, nagios, and either tmpfs or tracefs.

  Note that there are likely other synthetic filesystems beyond tmpfs
  and tracefs (e.g. udev, usbfs, devtmpfs, fuse.*, ...) which might also
  cause similar false positives; these should be handled as separate
  bugs, although they can likely be fixed the same way.

  [Fix]
  monitoring-plugins is modified to exclude the unwanted filesystems by 
default, in check_disk.c (see patch).

  [Discussion]
  There have been several bug reports filed about false positives with 
different synthetic file systems (see Dupes), including tracefs, squashfs, and 
tmpfs.  The commonly discussed workaround is to exclude these when running the 
tools (e.g. using the '-X ' parameter for check_all_disks).  Since wrappers 
are typically used for running the underlying tools, it is possible to add a 
string of -X... parameters.

  However, a cleaner solution is possible.  monitoring-plugins'
  check_disk.c maintains an internal exclusion list, fs_exclude_list,
  which already excludes iso9660, and can be 

[Touch-packages] [Bug 1219529] Re: df -x tmpfs fails to exclude udev (/dev)

2020-07-07 Thread Bryce Harrington
** Changed in: coreutils (Ubuntu)
   Status: Triaged => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/1219529

Title:
  df -x tmpfs fails to exclude udev (/dev)

Status in coreutils:
  New
Status in coreutils package in Ubuntu:
  Fix Committed

Bug description:
  The command:

  $ /bin/df -x tmpfs

  should exclude all filesystems of type tmpfs. The udev filesystem
  mounted at /dev is of this type:

  $ stat -f /dev
File: "/dev"
  ID: 0Namelen: 255 Type: tmpfs
  Block size: 4096   Fundamental block size: 4096
  Blocks: Total: 4109101Free: 4109098Available: 4109098
  Inodes: Total: 4109101Free: 4108501

  However, df still displays this filesystem:

  $ df -l -x tmpfs
  Filesystem  1K-blocks  Used  Available Use% Mounted on
  ...
  udev 1643640412   16436392   1% /dev
  ...

  ProblemType: Bug
  DistroRelease: Ubuntu 13.04
  Package: coreutils 8.20-3ubuntu5
  ProcVersionSignature: Ubuntu 3.8.0-29.42-generic 3.8.13.5
  Uname: Linux 3.8.0-29-generic x86_64
  ApportVersion: 2.9.2-0ubuntu8.3
  Architecture: amd64
  Date: Sun Sep  1 15:05:40 2013
  InstallationDate: Installed on 2013-08-31 (0 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
  MarkForUpload: True
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: coreutils
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1756595] Re: disk space info inadvertently provides all installed snaps

2020-07-07 Thread Bryce Harrington
** Changed in: coreutils (Ubuntu)
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1756595

Title:
  disk space info inadvertently provides all installed snaps

Status in apt package in Ubuntu:
  Fix Released
Status in coreutils package in Ubuntu:
  Fix Committed
Status in apt source package in Bionic:
  Fix Released
Status in apt source package in Disco:
  Fix Released
Status in apt source package in Eoan:
  Fix Released

Bug description:
  [Impact]
  When apport is reporting a crash, it includes the output of the "df" utility, 
to list the free disk space information per mount point.

  That output nowadays will inadvertently include all snaps that the
  user may have installed, including their revision numbers.

  Here is a simple df output:
  andreas@nsn7:~$ df
  Filesystem  1K-blocksUsed Available Use% Mounted on
  udev  8119680   0   8119680   0% /dev
  tmpfs 16301561828   1628328   1% /run
  nsn7/ROOT/ubuntu433084288 2500608 430583680   1% /
  tmpfs 8150776   1   8131888   1% /dev/shm
  tmpfs5120   4  5116   1% /run/lock
  tmpfs 8150776   0   8150776   0% 
/sys/fs/cgroup
  nsn7/var/log430763136  179456 430583680   1% /var/log
  nsn7/var/tmp430583808 128 430583680   1% /var/tmp
  /dev/sda2 1032088  160336871752  16% /boot
  /dev/sda1  5232482720520528   1% /boot/efi
  nsn7/home   430651264   67584 430583680   1% /home
  nsn7/var/cache  430653312   69632 430583680   1% /var/cache
  nsn7/var/mail   430583808 128 430583680   1% /var/mail
  nsn7/var/spool  430583808 128 430583680   1% /var/spool
  tmpfs 1630152  16   1630136   1% /run/user/120
  tmpfs 100   0   100   0% 
/var/lib/lxd/shmounts
  tmpfs 100   0   100   0% 
/var/lib/lxd/devlxd
  tmpfs 1630152  36   1630116   1% 
/run/user/1000
  nsn7/lxd/containers/squid-ds216 431444096  860416 430583680   1% 
/var/lib/lxd/storage-pools/default/containers/squid-ds216
  /dev/loop0  83712   83712 0 100% 
/snap/core/4206
  /dev/loop1 102144  102144 0 100% 
/snap/git-ubuntu/402

  You can see I have the core snap at revision 4206, and git-ubuntu at
  revision 402.

  There are already many bug reports in launchpad where one can see this
  information.

  Granted, the user can review it, refuse to send this data, etc. This
  bug is about the unexpectedness of having that information in the disk
  space data.

  If the user sees a prompt like "Would you like to include disk free
  space information in your report?", or "Would you like to include the
  output of the df(1) command in your report?", that doesn't immediately
  translate to "Would you like to include disk free space information
  and a list of all installed snaps and their revision numbers in your
  report?".

  [Test case]
  Do something that triggers the apport hook and make sure you don't see snaps 
in there.

  For example, install xterm, then add exit 1 to the start of the prerm,
  then run apt remove xterm, and investigate /var/crash/xterm.0.crash
  after that (delete before running apt).

  [Regression potential]
  Fix consists of adding -x squashfs to df output, so might hide other non-snap 
squashfs images.

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

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


[Touch-packages] [Bug 1827159] Re: check_all_disks includes squashfs /snap/* which are 100%

2020-07-07 Thread Bryce Harrington
** Changed in: coreutils (Ubuntu)
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/1827159

Title:
  check_all_disks includes squashfs /snap/* which are 100%

Status in Nagios Charm:
  Fix Released
Status in coreutils package in Ubuntu:
  Fix Committed
Status in monitoring-plugins package in Ubuntu:
  Fix Released

Bug description:
  [Impact]
  False positive reports are generated in monitoring tools when artificial 
filesystems are mounted, since they show 100% disk utilization, and thus add 
unnecessary (but dire sounding) "DISK CRITICAL" noise.

  [Test Case]
  $ lxc create ubuntu-daily:19.10/amd64 lp1827159
  $ lxc exec lp1827159 bash
  # apt-get -y update
  # apt-get install monitoring-plugins
  # snap install gnome-calculator
  [...]
  # /usr/lib/nagios/plugins/check_disk -w 10 -c 10
  DISK CRITICAL - free space: / 1903 MB (1% inode=78%); /dev 0 MB (100% 
inode=99%); /dev/full 16018 MB (100% inode=99%); /dev/null 16018 MB (100% 
inode=99%); /dev/random 16018 MB (100% inode=99%); /dev/tty 16018 MB (100% 
inode=99%); /dev/urandom 16018 MB (100% inode=99%); /dev/zero 16018 MB (100% 
inode=99%); /dev/fuse 16018 MB (100% inode=99%); /dev/net/tun 16018 MB (100% 
inode=99%); /dev/lxd 0 MB (100% inode=99%); /dev/.lxd-mounts 0 MB (100% 
inode=99%); /dev/shm 16041 MB (100% inode=99%); /run 3208 MB (99% inode=99%); 
/run/lock 5 MB (100% inode=99%); /sys/fs/cgroup 16041 MB (100% inode=99%); 
/snap 1903 MB (1% inode=78%); /run/snapd/ns 3208 MB (99% inode=99%);| 
/=71MB;119160;119160;0;119170 /dev=0MB;-10;-10;0;0 
/dev/full=0MB;16008;16008;0;16018 /dev/null=0MB;16008;16008;0;16018 
/dev/random=0MB;16008;16008;0;16018 /dev/tty=0MB;16008;16008;0;16018 
/dev/urandom=0MB;16008;16008;0;16018 /dev/zero=0MB;16008;16008;0;16018 
/dev/fuse=0MB;16008;16008;0;16018 /dev/net/tun=0MB;16008;16008;0;16018 
/dev/lxd=0MB;-10;-10;0;0 /dev/.lxd-mounts=0MB;-10;-10;0;0 
/dev/shm=0MB;16031;16031;0;16041 /run=0MB;3198;3198;0;3208 
/run/lock=0MB;-5;-5;0;5 /sys/fs/cgroup=0MB;16031;16031;0;16041 
/snap=71MB;119160;119160;0;119170 /run/snapd/ns=0MB;3198;3198;0;3208

  # /usr/lib/nagios/plugins/check_disk -w 10 -c 10 -e -X squashfs
  DISK CRITICAL - free space: /dev 0 MB (100% inode=99%); /dev/lxd 0 MB (100% 
inode=99%); /dev/.lxd-mounts 0 MB (100% inode=99%); /run/lock 5 MB (100% 
inode=99%);| /=111392MB;119160;119160;0;119170 /dev=0MB;-10;-10;0;0 
/dev/full=0MB;16008;16008;0;16018 /dev/null=0MB;16008;16008;0;16018 
/dev/random=0MB;16008;16008;0;16018 /dev/tty=0MB;16008;16008;0;16018 
/dev/urandom=0MB;16008;16008;0;16018 /dev/zero=0MB;16008;16008;0;16018 
/dev/fuse=0MB;16008;16008;0;16018 /dev/net/tun=0MB;16008;16008;0;16018 
/dev/lxd=0MB;-10;-10;0;0 /dev/.lxd-mounts=0MB;-10;-10;0;0 
/dev/shm=0MB;16031;16031;0;16041 /run=0MB;3198;3198;0;3208 
/run/lock=0MB;-5;-5;0;5 /sys/fs/cgroup=0MB;16031;16031;0;16041 
/snap=111392MB;119160;119160;0;119170 /run/snapd/ns=0MB;3198;3198;0;3208

  # /usr/lib/nagios/plugins/check_disk -w 10 -c 10 -e -X tmpfs
  DISK OK| /=71MB;119160;119160;0;119170 /dev/full=0MB;16008;16008;0;16018 
/dev/null=0MB;16008;16008;0;16018 /dev/random=0MB;16008;16008;0;16018 
/dev/tty=0MB;16008;16008;0;16018 /dev/urandom=0MB;16008;16008;0;16018 
/dev/zero=0MB;16008;16008;0;16018 /dev/fuse=0MB;16008;16008;0;16018 
/dev/net/tun=0MB;16008;16008;0;16018 /snap=71MB;119160;119160;0;119170

  [Regression Potential]
  As this alters the logic of how out-of-space checks are handled, relevant 
issues to keep an eye out for would relate to filesystem checks reporting 
improperly.  These tools underlay a few different front-ends, so regression 
bugs may get filed in a few different places, however they will tend to display 
error messages involving check_disk, nagios, and either tmpfs or tracefs.

  Note that there are likely other synthetic filesystems beyond tmpfs
  and tracefs (e.g. udev, usbfs, devtmpfs, fuse.*, ...) which might also
  cause similar false positives; these should be handled as separate
  bugs, although they can likely be fixed the same way.

  [Fix]
  monitoring-plugins is modified to exclude the unwanted filesystems by 
default, in check_disk.c (see patch).

  [Discussion]
  There have been several bug reports filed about false positives with 
different synthetic file systems (see Dupes), including tracefs, squashfs, and 
tmpfs.  The commonly discussed workaround is to exclude these when running the 
tools (e.g. using the '-X ' parameter for check_all_disks).  Since wrappers 
are typically used for running the underlying tools, it is possible to add a 
string of -X... parameters.

  However, a cleaner solution is possible.  monitoring-plugins'
  check_disk.c maintains an internal exclusion list, fs_exclude_list,
  which already excludes iso9660, and can be modified to add other
  filesystems to exclude by default.

  In other words, check_disk.c is 

[Touch-packages] [Bug 1756595] Re: disk space info inadvertently provides all installed snaps

2020-07-01 Thread Bryce Harrington
** Also affects: coreutils (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1756595

Title:
  disk space info inadvertently provides all installed snaps

Status in apt package in Ubuntu:
  Fix Released
Status in coreutils package in Ubuntu:
  New
Status in apt source package in Bionic:
  Fix Released
Status in apt source package in Disco:
  Fix Released
Status in apt source package in Eoan:
  Fix Released

Bug description:
  [Impact]
  When apport is reporting a crash, it includes the output of the "df" utility, 
to list the free disk space information per mount point.

  That output nowadays will inadvertently include all snaps that the
  user may have installed, including their revision numbers.

  Here is a simple df output:
  andreas@nsn7:~$ df
  Filesystem  1K-blocksUsed Available Use% Mounted on
  udev  8119680   0   8119680   0% /dev
  tmpfs 16301561828   1628328   1% /run
  nsn7/ROOT/ubuntu433084288 2500608 430583680   1% /
  tmpfs 8150776   1   8131888   1% /dev/shm
  tmpfs5120   4  5116   1% /run/lock
  tmpfs 8150776   0   8150776   0% 
/sys/fs/cgroup
  nsn7/var/log430763136  179456 430583680   1% /var/log
  nsn7/var/tmp430583808 128 430583680   1% /var/tmp
  /dev/sda2 1032088  160336871752  16% /boot
  /dev/sda1  5232482720520528   1% /boot/efi
  nsn7/home   430651264   67584 430583680   1% /home
  nsn7/var/cache  430653312   69632 430583680   1% /var/cache
  nsn7/var/mail   430583808 128 430583680   1% /var/mail
  nsn7/var/spool  430583808 128 430583680   1% /var/spool
  tmpfs 1630152  16   1630136   1% /run/user/120
  tmpfs 100   0   100   0% 
/var/lib/lxd/shmounts
  tmpfs 100   0   100   0% 
/var/lib/lxd/devlxd
  tmpfs 1630152  36   1630116   1% 
/run/user/1000
  nsn7/lxd/containers/squid-ds216 431444096  860416 430583680   1% 
/var/lib/lxd/storage-pools/default/containers/squid-ds216
  /dev/loop0  83712   83712 0 100% 
/snap/core/4206
  /dev/loop1 102144  102144 0 100% 
/snap/git-ubuntu/402

  You can see I have the core snap at revision 4206, and git-ubuntu at
  revision 402.

  There are already many bug reports in launchpad where one can see this
  information.

  Granted, the user can review it, refuse to send this data, etc. This
  bug is about the unexpectedness of having that information in the disk
  space data.

  If the user sees a prompt like "Would you like to include disk free
  space information in your report?", or "Would you like to include the
  output of the df(1) command in your report?", that doesn't immediately
  translate to "Would you like to include disk free space information
  and a list of all installed snaps and their revision numbers in your
  report?".

  [Test case]
  Do something that triggers the apport hook and make sure you don't see snaps 
in there.

  For example, install xterm, then add exit 1 to the start of the prerm,
  then run apt remove xterm, and investigate /var/crash/xterm.0.crash
  after that (delete before running apt).

  [Regression potential]
  Fix consists of adding -x squashfs to df output, so might hide other non-snap 
squashfs images.

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

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


[Touch-packages] [Bug 1827159] Re: check_all_disks includes squashfs /snap/* which are 100%

2020-07-01 Thread Bryce Harrington
** Also affects: coreutils (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/1827159

Title:
  check_all_disks includes squashfs /snap/* which are 100%

Status in Nagios Charm:
  Fix Released
Status in coreutils package in Ubuntu:
  New
Status in monitoring-plugins package in Ubuntu:
  Fix Released

Bug description:
  [Impact]
  False positive reports are generated in monitoring tools when artificial 
filesystems are mounted, since they show 100% disk utilization, and thus add 
unnecessary (but dire sounding) "DISK CRITICAL" noise.

  [Test Case]
  $ lxc create ubuntu-daily:19.10/amd64 lp1827159
  $ lxc exec lp1827159 bash
  # apt-get -y update
  # apt-get install monitoring-plugins
  # snap install gnome-calculator
  [...]
  # /usr/lib/nagios/plugins/check_disk -w 10 -c 10
  DISK CRITICAL - free space: / 1903 MB (1% inode=78%); /dev 0 MB (100% 
inode=99%); /dev/full 16018 MB (100% inode=99%); /dev/null 16018 MB (100% 
inode=99%); /dev/random 16018 MB (100% inode=99%); /dev/tty 16018 MB (100% 
inode=99%); /dev/urandom 16018 MB (100% inode=99%); /dev/zero 16018 MB (100% 
inode=99%); /dev/fuse 16018 MB (100% inode=99%); /dev/net/tun 16018 MB (100% 
inode=99%); /dev/lxd 0 MB (100% inode=99%); /dev/.lxd-mounts 0 MB (100% 
inode=99%); /dev/shm 16041 MB (100% inode=99%); /run 3208 MB (99% inode=99%); 
/run/lock 5 MB (100% inode=99%); /sys/fs/cgroup 16041 MB (100% inode=99%); 
/snap 1903 MB (1% inode=78%); /run/snapd/ns 3208 MB (99% inode=99%);| 
/=71MB;119160;119160;0;119170 /dev=0MB;-10;-10;0;0 
/dev/full=0MB;16008;16008;0;16018 /dev/null=0MB;16008;16008;0;16018 
/dev/random=0MB;16008;16008;0;16018 /dev/tty=0MB;16008;16008;0;16018 
/dev/urandom=0MB;16008;16008;0;16018 /dev/zero=0MB;16008;16008;0;16018 
/dev/fuse=0MB;16008;16008;0;16018 /dev/net/tun=0MB;16008;16008;0;16018 
/dev/lxd=0MB;-10;-10;0;0 /dev/.lxd-mounts=0MB;-10;-10;0;0 
/dev/shm=0MB;16031;16031;0;16041 /run=0MB;3198;3198;0;3208 
/run/lock=0MB;-5;-5;0;5 /sys/fs/cgroup=0MB;16031;16031;0;16041 
/snap=71MB;119160;119160;0;119170 /run/snapd/ns=0MB;3198;3198;0;3208

  # /usr/lib/nagios/plugins/check_disk -w 10 -c 10 -e -X squashfs
  DISK CRITICAL - free space: /dev 0 MB (100% inode=99%); /dev/lxd 0 MB (100% 
inode=99%); /dev/.lxd-mounts 0 MB (100% inode=99%); /run/lock 5 MB (100% 
inode=99%);| /=111392MB;119160;119160;0;119170 /dev=0MB;-10;-10;0;0 
/dev/full=0MB;16008;16008;0;16018 /dev/null=0MB;16008;16008;0;16018 
/dev/random=0MB;16008;16008;0;16018 /dev/tty=0MB;16008;16008;0;16018 
/dev/urandom=0MB;16008;16008;0;16018 /dev/zero=0MB;16008;16008;0;16018 
/dev/fuse=0MB;16008;16008;0;16018 /dev/net/tun=0MB;16008;16008;0;16018 
/dev/lxd=0MB;-10;-10;0;0 /dev/.lxd-mounts=0MB;-10;-10;0;0 
/dev/shm=0MB;16031;16031;0;16041 /run=0MB;3198;3198;0;3208 
/run/lock=0MB;-5;-5;0;5 /sys/fs/cgroup=0MB;16031;16031;0;16041 
/snap=111392MB;119160;119160;0;119170 /run/snapd/ns=0MB;3198;3198;0;3208

  # /usr/lib/nagios/plugins/check_disk -w 10 -c 10 -e -X tmpfs
  DISK OK| /=71MB;119160;119160;0;119170 /dev/full=0MB;16008;16008;0;16018 
/dev/null=0MB;16008;16008;0;16018 /dev/random=0MB;16008;16008;0;16018 
/dev/tty=0MB;16008;16008;0;16018 /dev/urandom=0MB;16008;16008;0;16018 
/dev/zero=0MB;16008;16008;0;16018 /dev/fuse=0MB;16008;16008;0;16018 
/dev/net/tun=0MB;16008;16008;0;16018 /snap=71MB;119160;119160;0;119170

  [Regression Potential]
  As this alters the logic of how out-of-space checks are handled, relevant 
issues to keep an eye out for would relate to filesystem checks reporting 
improperly.  These tools underlay a few different front-ends, so regression 
bugs may get filed in a few different places, however they will tend to display 
error messages involving check_disk, nagios, and either tmpfs or tracefs.

  Note that there are likely other synthetic filesystems beyond tmpfs
  and tracefs (e.g. udev, usbfs, devtmpfs, fuse.*, ...) which might also
  cause similar false positives; these should be handled as separate
  bugs, although they can likely be fixed the same way.

  [Fix]
  monitoring-plugins is modified to exclude the unwanted filesystems by 
default, in check_disk.c (see patch).

  [Discussion]
  There have been several bug reports filed about false positives with 
different synthetic file systems (see Dupes), including tracefs, squashfs, and 
tmpfs.  The commonly discussed workaround is to exclude these when running the 
tools (e.g. using the '-X ' parameter for check_all_disks).  Since wrappers 
are typically used for running the underlying tools, it is possible to add a 
string of -X... parameters.

  However, a cleaner solution is possible.  monitoring-plugins'
  check_disk.c maintains an internal exclusion list, fs_exclude_list,
  which already excludes iso9660, and can be modified to add other
  filesystems to exclude by default.

  In other words, check_disk.c is 

[Touch-packages] [Bug 1787225] Re: systemctl disable apache2 does nothing

2020-07-01 Thread Bryce Harrington
Closing as expired.

** Changed in: apache2 (Ubuntu)
   Status: Incomplete => Invalid

** Changed in: systemd (Ubuntu)
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1787225

Title:
  systemctl disable apache2 does nothing

Status in apache2 package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  I installed apache2 on Ubuntu 16.04, and out of the box it was enabled
  as a service, meaning it would automatically start at every boot. That
  is not what I want as this is my personal computer, not a server.

  $ systemctl is-enabled apache2.service 
  enabled

  
  So I ran:

  $ sudo systemctl disable apache2

  and this was the output:
 apache2.service is not a native service, redirecting to 
systemd-sysv-install
 Executing /lib/systemd/systemd-sysv-install disable apache2
 insserv: warning: current start runlevel(s) (empty) of script `apache2' 
overrides LSB defaults (2 3 4 5).
 insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script 
`apache2' overrides LSB defaults (0 1 6).
 insserv: warning: current start runlevel(s) (empty) of script `apache2' 
overrides LSB defaults (2 3 4 5).
 insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script 
`apache2' overrides LSB defaults (0 1 6).

  Then I rebooted. I expected to find apache2 not running. Instead, it was 
running.
  Surprisingly:

  $ systemctl is-enabled apache2.service 
  apache2.service is not a native service, redirecting to systemd-sysv-install
  Executing /lib/systemd/systemd-sysv-install is-enabled apache2
  disabled

  so, it shows up as disabled, yet it is started at startup.

  
  I wonder if this is what those warnings were about. Those messages are 
unclear as fuck, I have no f***ing clue what they are supposed to mean. I read 
that the CURRENT runlevel overrides a DEFAULT. I guess that should be fine, 
unless what systemctl actually changes are the defaults, and those are 
overwritten by something else, which means that "sysctl disable" will have no 
effect. If that is the case, then the warning should be more explicit:
  - be specific about the fact that "LSB defaults" are what the command is 
changing
  - tell me that as a result, the services will not be disabled
  - tell me WHAT is overriding the defaults that I'm attempting to change
  - and/or tell me what I am supposed to do to fix the issue

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: systemd 229-4ubuntu21.4
  ProcVersionSignature: Ubuntu 4.4.0-133.159-generic 4.4.134
  Uname: Linux 4.4.0-133-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Wed Aug 15 16:26:28 2018
  InstallationDate: Installed on 2013-10-11 (1768 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
  MachineType: Acer Aspire V3-571G
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-133-generic.efi.signed 
root=UUID=5830b30e-69e8-4bb4-8a2b-bc2b43c7414a ro quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 10/15/2012
  dmi.bios.vendor: Acer
  dmi.bios.version: V2.07
  dmi.board.asset.tag: Type2 - Board Asset Tag
  dmi.board.name: VA50_HC_CR
  dmi.board.vendor: Acer
  dmi.board.version: Type2 - Board Version
  dmi.chassis.type: 10
  dmi.chassis.vendor: Acer
  dmi.chassis.version: V2.07
  dmi.modalias: 
dmi:bvnAcer:bvrV2.07:bd10/15/2012:svnAcer:pnAspireV3-571G:pvrV2.07:rvnAcer:rnVA50_HC_CR:rvrType2-BoardVersion:cvnAcer:ct10:cvrV2.07:
  dmi.product.name: Aspire V3-571G
  dmi.product.version: V2.07
  dmi.sys.vendor: Acer

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

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


[Touch-packages] [Bug 1857036] Re: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container.

2020-06-11 Thread Bryce Harrington
Confirmed, I still was able to reproduce this on groovy with sudo
1.8.31-1ubuntu1, but groovy is now updated to 1.9.0-1ubuntu1 and now the
behavior is correct.

>From the bug report mentioned in comment #3, I found the commit with the
corresponding patch.

I've added a focal bug task and marked the groovy one fixed.  Although
it's just a warning, it's pretty noticeable and could cause confusion so
I think an SRU may be warranted.


** Patch added: "712afe03195e9747a442cac633b03dc5c8bfa54c.patch"
   
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1857036/+attachment/5383102/+files/712afe03195e9747a442cac633b03dc5c8bfa54c.patch

** Changed in: sudo (Ubuntu Groovy)
   Status: Confirmed => Fix Released

** Changed in: sudo (Ubuntu Focal)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1857036

Title:
  `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE):
  Operation not permitted` error when run inside a container.

Status in sudo package in Ubuntu:
  Fix Released
Status in sudo source package in Focal:
  Triaged
Status in sudo source package in Groovy:
  Fix Released

Bug description:
  When using `sudo --login --user USERNAME` with Ubuntu Focal currently,
  it will correctly operate but it will also throw the following error
  before continuing with the logon process (which completes successfully
  except for the stated error):

  sudo: setrlimit(RLIMIT_CORE): Operation not permitted

  A full run of this was tested in a Focal LXD container after dropping
  to a root shell to reproduce (arstotzka is the host system, focal-test
  is the test container):

  teward@arstotzka:~$ lxc shell focal-test
  root@focal-test:~# sudo --login --user ubuntu
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  To run a command as administrator (user "root"), use "sudo ".
  See "man sudo_root" for details.

  ubuntu@focal-test:~$

  This appears to be similar to this issue identified on RedHat's
  tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1773148

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: sudo 1.8.29-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18
  Uname: Linux 4.15.0-72-generic x86_64
  ApportVersion: 2.20.11-0ubuntu14
  Architecture: amd64
  Date: Thu Dec 19 17:16:31 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  SourcePackage: sudo
  UpgradeStatus: No upgrade log present (probably fresh install)
  VisudoCheck:
   /etc/sudoers: parsed OK
   /etc/sudoers.d/90-cloud-init-users: parsed OK
   /etc/sudoers.d/README: parsed OK

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

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


[Touch-packages] [Bug 1857036] Re: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container.

2020-06-11 Thread Bryce Harrington
** Also affects: sudo (Ubuntu Groovy)
   Importance: Undecided
   Status: Confirmed

** Also affects: sudo (Ubuntu Focal)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1857036

Title:
  `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE):
  Operation not permitted` error when run inside a container.

Status in sudo package in Ubuntu:
  Confirmed
Status in sudo source package in Focal:
  New
Status in sudo source package in Groovy:
  Confirmed

Bug description:
  When using `sudo --login --user USERNAME` with Ubuntu Focal currently,
  it will correctly operate but it will also throw the following error
  before continuing with the logon process (which completes successfully
  except for the stated error):

  sudo: setrlimit(RLIMIT_CORE): Operation not permitted

  A full run of this was tested in a Focal LXD container after dropping
  to a root shell to reproduce (arstotzka is the host system, focal-test
  is the test container):

  teward@arstotzka:~$ lxc shell focal-test
  root@focal-test:~# sudo --login --user ubuntu
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  To run a command as administrator (user "root"), use "sudo ".
  See "man sudo_root" for details.

  ubuntu@focal-test:~$

  This appears to be similar to this issue identified on RedHat's
  tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1773148

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: sudo 1.8.29-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18
  Uname: Linux 4.15.0-72-generic x86_64
  ApportVersion: 2.20.11-0ubuntu14
  Architecture: amd64
  Date: Thu Dec 19 17:16:31 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  SourcePackage: sudo
  UpgradeStatus: No upgrade log present (probably fresh install)
  VisudoCheck:
   /etc/sudoers: parsed OK
   /etc/sudoers.d/90-cloud-init-users: parsed OK
   /etc/sudoers.d/README: parsed OK

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

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


[Touch-packages] [Bug 1557157] Re: apparmor profile denied for saslauthd: /run/saslauthd/mux

2020-05-22 Thread Bryce Harrington
Can you explain the configuration process for saslauthd with slapd?  Or
a copy of your config file would do.

** Changed in: openldap (Ubuntu)
   Status: Confirmed => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1557157

Title:
  apparmor profile denied for saslauthd: /run/saslauthd/mux

Status in openldap package in Ubuntu:
  Incomplete

Bug description:
  When using slapd with saslauthd the processes communicate via the
  {,/var}/run/saslauthd/mux socket (this is the default location for the
  saslauthd server from the sasl2-bin package in the
  /etc/default/saslauthd config), but the apparmor profile for
  usr.sbin.slapd does not allow access to this socket/file.

  Syslog message:
  apparmor="DENIED" operation="connect" profile="/usr/sbin/slapd" 
name="/run/saslauthd/mux" pid=1880
  4 comm="slapd" requested_mask="r" denied_mask="r" fsuid=108 ouid=0

  
  Please add the following line to  /etc/apparmor.d/usr.sbin.slapd:
  /{,var/}run/saslauthd/mux rw,

  
  Ubuntu version: Ubuntu 14.04.4 LTS
  slapd version: 2.4.31-1+nmu2ubu

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

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


[Touch-packages] [Bug 1219529] Re: df -x tmpfs fails to exclude udev (/dev)

2020-04-22 Thread Bryce Harrington
20.04's coreutils still has the behavior described in this bug.  /dev is
listed as type 'udev' by df but df -x udev does not exclude it; df -x
devtmpfs does.

I wonder if one way to at least resolve the confusion might be to make
the code that prints the table display devtmpfs devices as 'devtmpfs'.
An obvious alternative would be to make '-x udev' be handled like '-x
udev -x devtmpfs'.  Another alternative would be to overload '-x tmpfs'
to exclude also udev and devtmpfs.  It's not clear what the best
solution would be.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/1219529

Title:
  df -x tmpfs fails to exclude udev (/dev)

Status in coreutils:
  New
Status in coreutils package in Ubuntu:
  Triaged

Bug description:
  The command:

  $ /bin/df -x tmpfs

  should exclude all filesystems of type tmpfs. The udev filesystem
  mounted at /dev is of this type:

  $ stat -f /dev
File: "/dev"
  ID: 0Namelen: 255 Type: tmpfs
  Block size: 4096   Fundamental block size: 4096
  Blocks: Total: 4109101Free: 4109098Available: 4109098
  Inodes: Total: 4109101Free: 4108501

  However, df still displays this filesystem:

  $ df -l -x tmpfs
  Filesystem  1K-blocks  Used  Available Use% Mounted on
  ...
  udev 1643640412   16436392   1% /dev
  ...

  ProblemType: Bug
  DistroRelease: Ubuntu 13.04
  Package: coreutils 8.20-3ubuntu5
  ProcVersionSignature: Ubuntu 3.8.0-29.42-generic 3.8.13.5
  Uname: Linux 3.8.0-29-generic x86_64
  ApportVersion: 2.9.2-0ubuntu8.3
  Architecture: amd64
  Date: Sun Sep  1 15:05:40 2013
  InstallationDate: Installed on 2013-08-31 (0 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
  MarkForUpload: True
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: coreutils
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 843306] Re: df ignores fs type none in options

2020-04-22 Thread Bryce Harrington
Modern df lists the actual fs types for those 'none' devices.  E.g.
udev, tmpfs, et al.   I'm guessing the reason that '-x none' was not
excluding them in this old df version was because the type wasn't
literally 'none' but perhaps \0 or else was just not being displayed.

In any case, I no longer am reproducing this very old bug, so am closing
it out as fixed.

** Changed in: coreutils (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/843306

Title:
  df ignores fs type none in options

Status in coreutils package in Ubuntu:
  Fix Released

Bug description:
  df appears to ignore the filesystem type "none" when specifying
  options on the command line. Some example output:

  gecko@magina ~> df
  Filesystem   1K-blocks  Used Available Use% Mounted on
  /dev/sda2 16018264   5669900   9534672  38% /
  none   2020908   652   2020256   1% /dev
  none   202863268   2028564   1% /dev/shm
  none   2028632   440   2028192   1% /var/run
  none   2028632 0   2028632   0% /var/lock
  /dev/sdb6457072296  42896024 390958336  10% /home
  [four different "none" systems]

  gecko@magina ~> df -x none
  Filesystem   1K-blocks  Used Available Use% Mounted on
  /dev/sda2 16018264   5669900   9534672  38% /
  none   2020908   652   2020256   1% /dev
  none   202863268   2028564   1% /dev/shm
  none   2028632   440   2028192   1% /var/run
  none   2028632 0   2028632   0% /var/lock
  /dev/sdb6457072296  42896032 390958328  10% /home
  [would expect "none" systems not to appear]

  gecko@magina ~> df -t none
  df: no file systems processed
  [would expect only "none" systems to appear]

  
  I have no idea on whether this behaviour is intentional, however I do know 
that it causes a minor bug to appear in the munin package - the df plugin is 
unable to ignore a bunch of filesystems even though it is configured to do so 
by default.

  ProblemType: Bug
  DistroRelease: Ubuntu 11.04
  Package: coreutils 8.5-1ubuntu6
  ProcVersionSignature: Ubuntu 2.6.38-10.46-generic 2.6.38.7
  Uname: Linux 2.6.38-10-generic x86_64
  Architecture: amd64
  Date: Tue Sep  6 23:48:25 2011
  EcryptfsInUse: Yes
  InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
  ProcEnviron:
   LANGUAGE=en_GB:en
   PATH=(custom, user)
   LANG=en_GB.UTF-8
   SHELL=/usr/bin/fish
  SourcePackage: coreutils
  UpgradeStatus: Upgraded to natty on 2011-08-04 (33 days ago)

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

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


[Touch-packages] [Bug 1495711] Re: df only shows one mountpoint

2020-04-22 Thread Bryce Harrington
I'm not able to reproduce this on focal, with multiple nfs mount points
mounted.

If it is still reproducible on newer versions of Ubuntu, can you provide
the full output of df, as well as log files /etc/fstab and /etc/exports
from the nfs server?  The output of dmesg (from boot) from the client
may also give clues.

** Changed in: coreutils (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/1495711

Title:
  df only shows one mountpoint

Status in coreutils package in Ubuntu:
  Incomplete

Bug description:
  Description:  Ubuntu 14.04.3 LTS
  Release:  14.04
  coreutils:
Installed: 8.21-1ubuntu5.1
Candidate: 8.21-1ubuntu5.1
Version table:
   *** 8.21-1ubuntu5.1 0
  500 http://nl.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   8.21-1ubuntu5 0
  500 http://nl.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

  It seems like df only shows one nfs mountpoint while more are mounted.

  root@klondike:~# mount | grep nfs
  192.168.1.2:/volume1/test1 on /test1 type nfs 
(rw,vers=4,addr=192.168.1.2,clientaddr=192.168.1.10)
  192.168.1.2:/volume1/test2 on /test2 type nfs 
(rw,vers=4,addr=192.168.1.2,clientaddr=192.168.1.10)
  192.168.1.2:/volume1/test3 on /test3 type nfs 
(rw,vers=4,addr=192.168.1.2,clientaddr=192.168.1.10)
  192.168.1.2:/volume1/test4 on /test4 type nfs 
(rw,vers=4,addr=192.168.1.2,clientaddr=192.168.1.10)

  root@klondike:~# df -h | grep ^192.168.1.2
  192.168.1.2:/volume1/test2  8.1T  1.4T  6.8T  17% /test2

  root@klondike:~# cat /etc/fstab | grep ^192.168.1.2
  192.168.1.2:/volume1/test1 /test1 nfs vers=4,auto 0 0
  192.168.1.2:/volume1/test2 /test2 nfs vers=4,auto 0 0
  192.168.1.2:/volume1/test3 /test3 nfs vers=4,auto 0 0
  192.168.1.2:/volume1/test4 /test4 nfs vers=4,auto 0 0

  root@klondike:~# cat /proc/mounts  | grep ^192.168.1.2
  192.168.1.2:/volume1/test1 /test1 nfs4 
rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.10,local_lock=none,addr=192.168.1.2
 0 0
  192.168.1.2:/volume1/test2 /test2 nfs4 
rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.10,local_lock=none,addr=192.168.1.2
 0 0
  192.168.1.2:/volume1/test3 /test3 nfs4 
rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.10,local_lock=none,addr=192.168.1.2
 0 0
  192.168.1.2:/volume1/test4 /test4 nfs4 
rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.10,local_lock=none,addr=192.168.1.2
 0 0

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

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


[Touch-packages] [Bug 1030519] Re: /proc/self/exe is not necessarily correct on overlayfs

2020-04-21 Thread Bryce Harrington
While there was some discussion by the kernel community around this on
the associated bug, it appears to remain unresolved there.  But it looks
to me that Robie's assessment still stands that it wouldn't be
appropriate to change this in just the logwatch patch alone.  Given the
age of this bug, I'm going to mark the logwatch task closed as I don't
think there's any further action we can take on it at this time.

** Changed in: logwatch (Ubuntu)
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to perl in Ubuntu.
https://bugs.launchpad.net/bugs/1030519

Title:
  /proc/self/exe is not necessarily correct on overlayfs

Status in logwatch package in Ubuntu:
  Invalid
Status in perl package in Ubuntu:
  Confirmed

Bug description:
  Perl should check the value from /proc/self/exe for correctness.  I'll
  open a bug in logwatch also, however there are likely many more
  applications that make use of this and depend on it's correctness.
  Bug number 1007089 tracks the overlayfs bug.

  /etc/cron.daily/00logwatch:
  sh: 1: /bin/perl: not found
  sh: 1: /bin/perl: not found
  system 'cat '/var/log/mail.log' '/var/log/mail.log.1'  | /bin/perl 
/usr/share/logwatch/scripts/shared/expandrepeats ''| /bin/perl 
/usr/share/logwatch/scripts/shared/applystddate 
''>/tmp/logwatch.BMbdlb_J/maillog' failed: 32512 at /usr/sbin/logwatch line 871.
  run-parts: /etc/cron.daily/00logwatch exited with return code 2

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: perl 5.14.2-6ubuntu2
  ProcVersionSignature: Ubuntu 3.2.0-23.31-lowlatency-pae 3.2.14
  Uname: Linux 3.2.0-23-lowlatency-pae i686
  ApportVersion: 2.0.1-0ubuntu8
  Architecture: i386
  Date: Sun Jul 29 09:06:20 2012
  SourcePackage: perl
  UpgradeStatus: Upgraded to precise on 2012-01-03 (208 days ago)

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

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


[Touch-packages] [Bug 1864869] Re: ICU returns unexpected length for string

2020-03-25 Thread Bryce Harrington
Per the PHP bug, this appears not to be in php itself but rather higher
up the stack.  Reassigning to ICU for now.


** Also affects: icu (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: php7.4 (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to icu in Ubuntu.
https://bugs.launchpad.net/bugs/1864869

Title:
  ICU returns unexpected length for string

Status in icu package in Ubuntu:
  New
Status in php7.4 package in Ubuntu:
  Invalid

Bug description:
  Calculating the grapheme string length for the word 'नमस्ते' returns 3
  instead of 4.

  This version returns unexpected result of 3:
  ICU version   65.1
  ICU Data version  65.1
  ICU TZData version2019c
  ICU Unicode version   12.1 

  This version returns the expected result of 4:
  ICU version => 63.1
  ICU Data version => 63.1
  ICU TZData version => 2018e
  ICU Unicode version => 11.0

  PHP says this is an upstream issue:
  https://bugs.php.net/bug.php?id=79308

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

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


[Touch-packages] [Bug 1866303] Re: slapd crash with pwdAccountLockedTime and stacked overlays

2020-03-18 Thread Bryce Harrington
We're no longer looking at backporting fixes for disco.

This looks suitable for SRU so the other proposed series tasks are
valid, and this is already in the server-next queue.

** Changed in: openldap (Ubuntu Disco)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1866303

Title:
  slapd crash with pwdAccountLockedTime and stacked overlays

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  New
Status in openldap source package in Bionic:
  New
Status in openldap source package in Disco:
  Won't Fix
Status in openldap source package in Eoan:
  New
Status in openldap package in Debian:
  Unknown

Bug description:
  Hello,

  Please merge openldap 2.4.49+dfsg-2 from Debian unstable to fix an
  issue in the ppolicy overlay that can crash slapd. Please also
  consider SRUing the patch after it has had some testing time.

  Upstream: https://openldap.org/its/?findid=9171
  Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953150

  The ingredients for the crash are:

  1: ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  The buggy code is not as specific as the above steps, so I suspect
  there are probably other configurations or steps that can trigger the
  same crash.

  I will attach my test script and data for reproducing the crash.

  Expected output (last lines):

  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running

  Actual output (last lines):

  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd dead

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

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


[Touch-packages] [Bug 1689833] Re: OpenVPN server does not start properly on boot

2020-03-18 Thread Bryce Harrington
** Changed in: openvpn (Ubuntu)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1689833

Title:
  OpenVPN server does not start properly on boot

Status in openvpn package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  OpenVPN intermittently fails to bind to local address during boot on
  Ubuntu Server 16.04.2 LTS. Sometimes it succeeds, sometimes it does
  not.

  /var/log/openvpn.log
  Wed May 10 15:42:02 2017 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] 
[LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Feb  2 2016
  Wed May 10 15:42:02 2017 library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 
2.08
  Wed May 10 15:42:02 2017 Diffie-Hellman initialized with 2048 bit key
  Wed May 10 15:42:02 2017 Control Channel Authentication: using 
'./easy-rsa/keys/ta.key' as a OpenVPN static key file
  Wed May 10 15:42:02 2017 Outgoing Control Channel Authentication: Using 160 
bit message hash 'SHA1' for HMAC authentication
  Wed May 10 15:42:02 2017 Incoming Control Channel Authentication: Using 160 
bit message hash 'SHA1' for HMAC authentication
  Wed May 10 15:42:02 2017 Socket Buffers: R=[212992->212992] S=[212992->212992]
  Wed May 10 15:42:02 2017 TCP/UDP: Socket bind failed on local address 
[AF_INET]192.168.4.254:1194: Cannot assign requested address
  Wed May 10 15:42:02 2017 Exiting due to fatal error

  In case it does not start, running 'sudo service openvpn start' fixes
  that problem.

  /var/log/openvpn.log
  Wed May 10 15:42:43 2017 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] 
[LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Feb  2 2016
  Wed May 10 15:42:43 2017 library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 
2.08
  Wed May 10 15:42:43 2017 Diffie-Hellman initialized with 2048 bit key
  Wed May 10 15:42:43 2017 Control Channel Authentication: using 
'./easy-rsa/keys/ta.key' as a OpenVPN static key file
  Wed May 10 15:42:43 2017 Outgoing Control Channel Authentication: Using 160 
bit message hash 'SHA1' for HMAC authentication
  Wed May 10 15:42:43 2017 Incoming Control Channel Authentication: Using 160 
bit message hash 'SHA1' for HMAC authentication
  Wed May 10 15:42:43 2017 Socket Buffers: R=[212992->212992] S=[212992->212992]
  Wed May 10 15:42:43 2017 ROUTE_GATEWAY 192.168.4.1/255.255.255.0 IFACE=ens4 
HWADDR=52:54:00:f0:26:0c
  Wed May 10 15:42:43 2017 TUN/TAP device tun0 opened
  Wed May 10 15:42:43 2017 TUN/TAP TX queue length set to 100
  Wed May 10 15:42:43 2017 do_ifconfig, tt->ipv6=0, 
tt->did_ifconfig_ipv6_setup=0
  Wed May 10 15:42:43 2017 /sbin/ip link set dev tun0 up mtu 1500
  Wed May 10 15:42:43 2017 /sbin/ip addr add dev tun0 local 172.16.1.1 peer 
172.16.1.2
  Wed May 10 15:42:43 2017 /sbin/ip route add 172.16.1.0/24 via 172.16.1.2
  Wed May 10 15:42:43 2017 GID set to nogroup
  Wed May 10 15:42:43 2017 UID set to nobody
  Wed May 10 15:42:43 2017 UDPv4 link local (bound): [AF_INET]192.168.4.254:1194
  Wed May 10 15:42:43 2017 UDPv4 link remote: [undef]
  Wed May 10 15:42:43 2017 MULTI: multi_init called, r=256 v=256
  Wed May 10 15:42:43 2017 IFCONFIG POOL: base=172.16.1.4 size=62, ipv6=0
  Wed May 10 15:42:43 2017 IFCONFIG POOL LIST
  Wed May 10 15:42:43 2017 Initialization Sequence Completed

  My guess is that systemd starts OpenVPN too early before the network
  is brought up sufficiently. Running 'sudo systemctl edit --full
  openvpn' and adding 'Wants=network-online.target' does not change that
  behaviour.

  user@server:~$ sudo systemd-analyze critical-chain
  graphical.target @2.160s
  └─multi-user.target @2.159s
    └─ntp.service @2.054s +104ms
  └─remote-fs.target @2.052s
    └─remote-fs-pre.target @2.052s
  └─open-iscsi.service @1.993s +57ms
    └─iscsid.service @1.942s +47ms
  └─network-online.target @1.941s
    └─network.target @1.929s
  └─networking.service @1.793s +134ms
    └─apparmor.service @1.140s +395ms
  └─local-fs.target @1.140s
    └─local-fs-pre.target @1.139s
  └─lvm2-monitor.service @602ms +536ms
    └─lvm2-lvmetad.service @773ms
  └─systemd-journald.socket @574ms
    └─-.slice @500ms

  The boot time is quite short. Clean install with the additional
  packages ntp and openssh-server. This happens both on bare metal and
  as a Virtual Machine (KVM) as well.

  /etc/openvpn/server.conf
  local 192.168.4.254
  port 1194
  proto udp
  dev tun
  ca ./easy-rsa/keys/ca.crt
  cert ./easy-rsa/keys/crt.crt
  key ./easy-rsa/keys/key.key
  dh ./easy-rsa/keys/dh2048.pem
  tls-auth ./easy-rsa/keys/ta.key 0
  server 172.16.1.0 255.255.255.0
  ifconfig-pool-persist ipp.txt
  push "route 192.168.0.0 255.255.255.0"
  push "route 192.168.4.0 

[Touch-packages] [Bug 1861472] Re: upgrade from fresh bionic to focal needlessly prompts user

2020-02-12 Thread Bryce Harrington
** Bug watch added: Debian Bug tracker #951220
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951220

** Also affects: openssh (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951220
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1861472

Title:
  upgrade from fresh bionic to focal needlessly prompts user

Status in openssh package in Ubuntu:
  Triaged
Status in openssh package in Debian:
  Unknown

Bug description:
  Upgrading from a fresh 18.04 LTS install to focal unexpectedly prompts
  for how to handle a change to /etc/ssh/sshd_config

  To reproduce the issue:

  lxc launch ubuntu:18.04 u18
  lxc exec u18 -- bash
  # within container
  do-release-upgrade -d
  # select restart services when prompted

  Eventually you'll be prompted to accept changes to
  /etc/ssh/sshd_config or not because of "local changes".

  Thanks

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: openssh-server 1:8.1p1-5
  ProcVersionSignature: Ubuntu 4.15.0-62.69-generic 4.15.18
  Uname: Linux 4.15.0-62-generic x86_64
  ApportVersion: 2.20.11-0ubuntu16
  Architecture: amd64
  Date: Fri Jan 31 03:37:55 2020
  ProcEnviron:
   TERM=rxvt-unicode-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: openssh
  UpgradeStatus: Upgraded to focal on 2020-01-31 (0 days ago)

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

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


[Touch-packages] [Bug 1862770] Re: MySQL autopkgtest regressed in Focal release pocket

2020-02-12 Thread Bryce Harrington
*** This bug is a duplicate of bug 1862364 ***
https://bugs.launchpad.net/bugs/1862364

** This bug has been marked a duplicate of bug 1862364
   mysql-8.0 FTBFS (focal) because of hardcoded date in test

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1862770

Title:
  MySQL autopkgtest regressed in Focal release pocket

Status in mysql-8.0 package in Ubuntu:
  New
Status in shadow package in Ubuntu:
  New

Bug description:
  http://autopkgtest.ubuntu.com/packages/m/mysql-8.0/focal/amd64
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/m/mysql-8.0/20200211_122839_60bab@/log.gz

  ...

   63%] main.events_1 [ fail ]
  Test ended at 2020-02-11 12:06:00

  CURRENT_TEST: main.events_1
  mysqltest: At line 69: Query 'ALTER EVENT event_starts_test ON SCHEDULE AT 
'2020-02-02 20:00:02'' failed.
  ERROR 1589 (HY000): Event execution time is in the past and ON COMPLETION NOT 
PRESERVE is set. The event was not changed. Specify a time in the future.

  The result from queries just before the failure was:
  drop event if exists event1;
  Warnings:
  Note  1305Event event1 does not exist
  create event event1 on schedule every 15 minute starts now() ends 
date_add(now(), interval 5 hour) DO begin end;
  alter event event1 rename to event2 enable;
  alter event event2 disable;
  alter event event2 enable;
  alter event event2 on completion not preserve;
  alter event event2 on schedule every 1 year on completion preserve rename to 
event3 comment "new comment" do begin select 1; end__
  alter event event3 rename to event2;
  drop event event2;
  create event event2 on schedule every 2 second starts now() ends 
date_add(now(), interval 5 hour) comment "some" DO begin end;
  drop event event2;
  CREATE EVENT event_starts_test ON SCHEDULE EVERY 10 SECOND COMMENT "" DO 
SELECT 1;
  SELECT interval_field, interval_value, event_definition FROM 
information_schema.events WHERE event_name='event_starts_test';
  INTERVAL_FIELDINTERVAL_VALUE  EVENT_DEFINITION
  SECOND10  SELECT 1
  SELECT execute_at IS NULL, starts IS NULL, ends IS NULL, event_comment FROM 
information_schema.events WHERE event_schema='events_test' AND 
event_name='event_starts_test';
  execute_at IS NULLstarts IS NULL  ends IS NULLEVENT_COMMENT
  1 0   1   
  safe_process[25029]: Child process: 25030, exit: 1

   - the logfile can be found in
  '/tmp/tmp.YL1y5O4jCj/var/log/main.events_1/events_1.log'

  ...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mysql-8.0/+bug/1862770/+subscriptions

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


[Touch-packages] [Bug 1861472] Re: upgrade from fresh bionic to focal needlessly prompts user

2020-02-06 Thread Bryce Harrington
So, the trivial fix is to simply append 203e9b92fe3623aeba277ee44297f7dd
to openssh-server.ucf-md5sum, as Marc had suggested above.

I can proceed with that as the fix.

---

But this suggests a few direct questions/thoughts:

0.  Does the installer use the openssh-server.ucf-md5sum from the new
package, or the previously installed one?  If the latter, then the
md5sum will need added via SRU.

1.  Where in the process did the md5sum get out of sync?  I'm not
spotting conf changes from the CVE patches by our security team, so
looks like this got to us via debian?

2.  Our merge review processes need to account for conf file changes
with ucf packages.  Although, in this case openssh presumably got sync'd
so Ubuntu-side process changes would not have caught it.

3.  There have been other reports of similar misbehavior with wrongly
detected conf file changes (Robie's LP #1747464 mentioned above may be
one, there's likely others).  Is ucf also being used in these cases, and
are those problems likewise caused by missing md5sums in their packages?

4.  Is this failure mode something that can be caught in autopkgtests?
If so, then per-package checks seem warranted to prevent this in the
future.

5.  Even better than #3 would be a distro-wide CI check for all packages
using ucf, to ensure all distro-default installed conf files (from all
pockets) have their conf file md5sums registered.


In addition, some broader scoped / philosophical / "dumb" questions:

1.  Are md5sums the best way to identify config file changes?  E.g. if
the change is just a timestamp and commented out line (such as in this
case) that shouldn't count as a "change".  What about like filtering out
commented lines, and checksumming that?

2.  Why are commented out lines included in distro-provided conf files?
Is it just for documentation, in which case those would be better kept
elsewhere and just referenced?  (Yes, this is more a debian/upstream
policy question which we probably don't have say on...)

3.  Is upgrade the right time to be prompting users about config file
changes, even if they have legitimate local config changes?  With cloud
instances, unattended-upgrades, etc. it's not so safe to assume a human
is babysitting the dist-upgrade, and breakages during dist-upgrades can
be pretty catastrophic for users.  It's also a frequently seen pattern
in our own bug triaging workloads.  Are there any other ways to solve
this need?

(Yes, much of the above is better fodder for blogs, and no need to
discuss it in depth here...)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1861472

Title:
  upgrade from fresh bionic to focal needlessly prompts user

Status in openssh package in Ubuntu:
  Triaged

Bug description:
  Upgrading from a fresh 18.04 LTS install to focal unexpectedly prompts
  for how to handle a change to /etc/ssh/sshd_config

  To reproduce the issue:

  lxc launch ubuntu:18.04 u18
  lxc exec u18 -- bash
  # within container
  do-release-upgrade -d
  # select restart services when prompted

  Eventually you'll be prompted to accept changes to
  /etc/ssh/sshd_config or not because of "local changes".

  Thanks

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: openssh-server 1:8.1p1-5
  ProcVersionSignature: Ubuntu 4.15.0-62.69-generic 4.15.18
  Uname: Linux 4.15.0-62-generic x86_64
  ApportVersion: 2.20.11-0ubuntu16
  Architecture: amd64
  Date: Fri Jan 31 03:37:55 2020
  ProcEnviron:
   TERM=rxvt-unicode-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: openssh
  UpgradeStatus: Upgraded to focal on 2020-01-31 (0 days ago)

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

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


[Touch-packages] [Bug 1861472] Re: upgrade from fresh bionic to focal needlessly prompts user

2020-02-06 Thread Bryce Harrington
Marc's comment #3 seems plausible:

stirling:~/ubuntu/Openssh$  lxc exec u18 -- bash
root@u18:~# md5sum /etc/ssh/sshd_config 
203e9b92fe3623aeba277ee44297f7dd  /etc/ssh/sshd_config
root@u18:~# grep -c 203e9b92fe3623aeba277ee44297f7dd 
/usr/share/openssh/sshd_config.md5sum
0
root@u18:~# 

Looking at sshd_config on a fresh installed 18.04 lxc and a fresh 20.04,
the sshd_config files do indeed differ by exactly the diff shown during
upgrade (and provided in comment #2).

The md5sum checking was introduced in Debian on Dec 2016 with openssh
(1:7.4p1-1)

  * Start handling /etc/ssh/sshd_config using ucf.  The immediate motivation
for this is to deal with deprecations of options related to protocol 1,
but something like this has been needed for a long time (closes:
#419574, #848089):
- sshd_config is now a slightly-patched version of upstream's, and only
  contains non-default settings (closes: #147201).
- I've included as many historical md5sums of default versions of
  sshd_config as I could reconstruct from version control, but I'm sure
  I've missed some.
- Explicitly synchronise the debconf database with the current
  configuration file state in openssh-server.config, to ensure that the
  PermitRootLogin setting is properly preserved.
- UsePrivilegeSeparation now defaults to the stronger "sandbox" rather
  than "yes", per upstream.

It's implemented in openssh-server.postinst:

...
... sed statements to customize $new_config from upstream for debian
...
mkdir -p /etc/ssh
ucf --three-way --debconf-ok \
--sum-file /usr/share/openssh/sshd_config.md5sum \
"$new_config" /etc/ssh/sshd_config
ucfr openssh-server /etc/ssh/sshd_config

AFAICT the /usr/share/openssh/sshd_config.md5sum is identical on freshly
lxc'd 18.04 and 20.04.

Running the ucf command on a focal lxc container with the 18.04 and
20.04 sshd_config files captured from fresh lxc installs reproduces the
same debconf prompt about the changed config, and then issues this
output:

stirling:~/ubuntu/Openssh/fix-apt-misprompt$ sudo ucf --no-action --three-way 
--debconf-ok --sum-file /usr/share/openssh/sshd_config.md5sum 
./sshd_config.20.04 ./sshd_config.18.04 
[sudo] password for bryce: 
Replacing config file 
/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04 with new version
cp -pf /home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04 
/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04.ucf-old
cp -pf /home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04 
/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04
cp -pf /var/lib/ucf/hashfile.6 /var/lib/ucf/hashfile.7
cp -pf /var/lib/ucf/hashfile.5 /var/lib/ucf/hashfile.6
cp -pf /var/lib/ucf/hashfile.4 /var/lib/ucf/hashfile.5
cp -pf /var/lib/ucf/hashfile.3 /var/lib/ucf/hashfile.4
cp -pf /var/lib/ucf/hashfile.2 /var/lib/ucf/hashfile.3
cp -pf /var/lib/ucf/hashfile.1 /var/lib/ucf/hashfile.2
cp -pf /var/lib/ucf/hashfile.0 /var/lib/ucf/hashfile.1
cp -pf /var/lib/ucf/hashfile /var/lib/ucf/hashfile.0
(egrep -v 
"[[:space:]]\/home\/bryce\/ubuntu\/Openssh\/fix\-apt\-misprompt\/sshd_config\.18\.04$"
 "/var/lib/ucf/hashfile"
 md5sum "/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04" | sed 
"s|/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04|/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04|";
 
) | sort > "/var/lib/ucf/hashfile"
cp -pf /home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04 
/var/lib/ucf/cache/:home:bryce:ubuntu:Openssh:fix-apt-misprompt:sshd_config.18.04


If I append the bionic sshd_config md5sum to the list and then check against 
that, no prompt is displayed, with the following output:

$ (cat /usr/share/openssh/sshd_config.md5sum; sudo md5sum sshd_config.18.04  | 
cut -d' ' -f1) > /tmp/sshd_config.md5sum
$ sudo ucf --no-action --three-way --debconf-ok --sum-file 
/tmp/sshd_config.md5sum ./sshd_config.20.04 ./sshd_config.18.04 
cp -pf /home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04 
/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04
cp -pf /var/lib/ucf/hashfile.6 /var/lib/ucf/hashfile.7
cp -pf /var/lib/ucf/hashfile.5 /var/lib/ucf/hashfile.6
cp -pf /var/lib/ucf/hashfile.4 /var/lib/ucf/hashfile.5
cp -pf /var/lib/ucf/hashfile.3 /var/lib/ucf/hashfile.4
cp -pf /var/lib/ucf/hashfile.2 /var/lib/ucf/hashfile.3
cp -pf /var/lib/ucf/hashfile.1 /var/lib/ucf/hashfile.2
cp -pf /var/lib/ucf/hashfile.0 /var/lib/ucf/hashfile.1
cp -pf /var/lib/ucf/hashfile /var/lib/ucf/hashfile.0
(egrep -v 
"[[:space:]]\/home\/bryce\/ubuntu\/Openssh\/fix\-apt\-misprompt\/sshd_config\.18\.04$"
 "/var/lib/ucf/hashfile"
 md5sum "/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04" | sed 
"s|/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04|/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04|";
 
) | sort > "/var/lib/ucf/hashfile"
cp -pf 

[Touch-packages] [Bug 1861615] Re: package libldap-2.4-2:amd64 2.4.45+dfsg-1ubuntu1.4 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting

2020-02-05 Thread Bryce Harrington
Thank you for taking the time to file a bug report.

Unfortunately the collected logs don't indicate what the issue with ldap
is.  There don't seem to be other reports of this issue, so it appears
not to be a systemic problem.  Best guess, lacking better information,
is that there was a local config or other problem previously when
updating libldab, that's only been revealed now.

I would probably attempt what the error message suggests, and remove the
ldap package and reinstall it.  Then watch for any errors or warnings
that are issued, which may give better clues what's wrong.

Since it seems likely to me that this is a local configuration problem,
rather than a bug in Ubuntu, I am marking this bug as 'Incomplete'.

However, if you believe that this is really a bug in ubuntu, then we
would be grateful if you would provide a more complete description of
the problem with steps to reproduce, explain why you believe this is a
bug in ubuntu rather than a problem specific to your system, and then
change the bug status back to 'New'.

For local configuration issues, you can find assistance here:
http://www.ubuntu.com/support/community

** Changed in: openldap (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1861615

Title:
  package libldap-2.4-2:amd64 2.4.45+dfsg-1ubuntu1.4 failed to
  install/upgrade: package is in a very bad inconsistent state; you
  should  reinstall it before attempting configuration

Status in openldap package in Ubuntu:
  Incomplete

Bug description:
  didnt work

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: libldap-2.4-2:amd64 2.4.45+dfsg-1ubuntu1.4
  ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18
  Uname: Linux 4.15.0-29-generic x86_64
  NonfreeKernelModules: kpatch_livepatch_Ubuntu_4_15_0_29_31_generic_42
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Sun Feb  2 08:12:58 2020
  DuplicateSignature:
   package:libldap-2.4-2:amd64:2.4.45+dfsg-1ubuntu1.4
   Setting up libkf5notifications-data (5.44.0-0ubuntu1) ...
   dpkg: error processing package libldap-2.4-2:amd64 (--configure):
package is in a very bad inconsistent state; you should
  ErrorMessage: package is in a very bad inconsistent state; you should  
reinstall it before attempting configuration
  InstallationDate: Installed on 2020-02-02 (0 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  Python3Details: /usr/bin/python3.6, Python 3.6.9, python3-minimal, 
3.6.7-1~18.04
  PythonDetails: N/A
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2.3
   apt  1.6.3
  SourcePackage: openldap
  Title: package libldap-2.4-2:amd64 2.4.45+dfsg-1ubuntu1.4 failed to 
install/upgrade: package is in a very bad inconsistent state; you should  
reinstall it before attempting configuration
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1861472] Re: upgrade from fresh bionic to focal needlessly prompts user

2020-02-05 Thread Bryce Harrington
I'm able to easily reproduce this in lxc using the steps provided.

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

** Changed in: openssh (Ubuntu)
   Status: New => Triaged

** Tags added: server-next

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1861472

Title:
  upgrade from fresh bionic to focal needlessly prompts user

Status in openssh package in Ubuntu:
  Triaged

Bug description:
  Upgrading from a fresh 18.04 LTS install to focal unexpectedly prompts
  for how to handle a change to /etc/ssh/sshd_config

  To reproduce the issue:

  lxc launch ubuntu:18.04 u18
  lxc exec u18 -- bash
  # within container
  do-release-upgrade -d
  # select restart services when prompted

  Eventually you'll be prompted to accept changes to
  /etc/ssh/sshd_config or not because of "local changes".

  Thanks

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: openssh-server 1:8.1p1-5
  ProcVersionSignature: Ubuntu 4.15.0-62.69-generic 4.15.18
  Uname: Linux 4.15.0-62-generic x86_64
  ApportVersion: 2.20.11-0ubuntu16
  Architecture: amd64
  Date: Fri Jan 31 03:37:55 2020
  ProcEnviron:
   TERM=rxvt-unicode-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: openssh
  UpgradeStatus: Upgraded to focal on 2020-01-31 (0 days ago)

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

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


[Touch-packages] [Bug 1861177] Re: seccomp_rule_add is very slow

2020-01-29 Thread Bryce Harrington
** Tags added: server-next

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1861177

Title:
  seccomp_rule_add is very slow

Status in snapd:
  New
Status in libseccomp package in Ubuntu:
  Triaged

Bug description:
  There is a known and patched issue with version 2.4 of libseccomp
  where certain operations have a large performance regression. This is
  causing some packages that use libseccomp such as container
  orchestration systems to occasionally time out or otherwise fail under
  certain workloads.

  Please consider porting the patch into the various Ubuntu versions
  that have version 2.4 of libseccomp and into the backports. The
  performance patch from version 2.5 (yet to be released) applies
  cleanly on top of the 2.4 branch of libseccomp.

  For more information, and for a copy of the patch (which can also be
  cherry picked from the upstream libseccomp repos) see the similar
  Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913

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

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


[Touch-packages] [Bug 1861177] Re: seccomp_rule_add is very slow

2020-01-29 Thread Bryce Harrington
2.4.1 is currently available from xenial, bionic, disco, eoan; focal
carries 2.4.2.  None of these carry the patches for this bug report yet.

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

** Changed in: libseccomp (Ubuntu)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1861177

Title:
  seccomp_rule_add is very slow

Status in snapd:
  New
Status in libseccomp package in Ubuntu:
  Triaged

Bug description:
  There is a known and patched issue with version 2.4 of libseccomp
  where certain operations have a large performance regression. This is
  causing some packages that use libseccomp such as container
  orchestration systems to occasionally time out or otherwise fail under
  certain workloads.

  Please consider porting the patch into the various Ubuntu versions
  that have version 2.4 of libseccomp and into the backports. The
  performance patch from version 2.5 (yet to be released) applies
  cleanly on top of the 2.4 branch of libseccomp.

  For more information, and for a copy of the patch (which can also be
  cherry picked from the upstream libseccomp repos) see the similar
  Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913

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

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


[Touch-packages] [Bug 1861177] Re: seccomp_rule_add is very slow

2020-01-29 Thread Bryce Harrington
The patch mentioned in the OP is attached for reference.  Per [1] it was
proposed for inclusion in Debian last November as patches db-
consolidate-some-of-the-code-which-adds-rules-to-.patch and db-add-
shadow-transactions.patch.

The corresponding bug report upstream is [2].

1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913
2: https://github.com/seccomp/libseccomp/issues/153

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

** Bug watch added: github.com/seccomp/libseccomp/issues #153
   https://github.com/seccomp/libseccomp/issues/153

** Patch added: "0001-Cherry-pick-upstream-commits-21b98d8-and-19af04d.patch"
   
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1861177/+attachment/5323922/+files/0001-Cherry-pick-upstream-commits-21b98d8-and-19af04d.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1861177

Title:
  seccomp_rule_add is very slow

Status in snapd:
  New
Status in libseccomp package in Ubuntu:
  Triaged

Bug description:
  There is a known and patched issue with version 2.4 of libseccomp
  where certain operations have a large performance regression. This is
  causing some packages that use libseccomp such as container
  orchestration systems to occasionally time out or otherwise fail under
  certain workloads.

  Please consider porting the patch into the various Ubuntu versions
  that have version 2.4 of libseccomp and into the backports. The
  performance patch from version 2.5 (yet to be released) applies
  cleanly on top of the 2.4 branch of libseccomp.

  For more information, and for a copy of the patch (which can also be
  cherry picked from the upstream libseccomp repos) see the similar
  Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913

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

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


[Touch-packages] [Bug 1860686] Re: package dnsmasq-base 2.75-1ubuntu0.16.04.5 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configu

2020-01-23 Thread Bryce Harrington
While the error message mentions dnsmasq, the only errors I'm spotting
in the log file involve corefonts:

Err:1 http://downloads.sourceforge.net/corefonts/impact32.exe
  Protocol "http" not supported or disabled in libcurl

0% [Working]

E: Failed to fetch https://managedway.dl.sourceforge.net/project/corefonts/the 
fonts/final/impact32.exe  Protocol "http" not supported or disabled in libcurl

Perhaps this relates to upstream bug https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=912956 ?


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

** Changed in: dnsmasq (Ubuntu)
   Status: New => Incomplete

** Package changed: dnsmasq (Ubuntu) => msttcorefonts (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1860686

Title:
  package dnsmasq-base 2.75-1ubuntu0.16.04.5 failed to install/upgrade:
  package is in a very bad inconsistent state; you should  reinstall it
  before attempting configuration

Status in msttcorefonts package in Ubuntu:
  Incomplete

Bug description:
  Continues throwing errors

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: dnsmasq-base 2.75-1ubuntu0.16.04.5
  ProcVersionSignature: Ubuntu 4.4.0-171.200-generic 4.4.203
  Uname: Linux 4.4.0-171-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.21
  Architecture: amd64
  Date: Thu Jan 23 10:48:05 2020
  DuplicateSignature:
   package:dnsmasq-base:2.75-1ubuntu0.16.04.5
   Processing triggers for systemd (229-4ubuntu21.23) ...
   dpkg: error processing package dnsmasq-base (--configure):
package is in a very bad inconsistent state; you should
  ErrorMessage: package is in a very bad inconsistent state; you should  
reinstall it before attempting configuration
  InstallationDate: Installed on 2015-01-19 (1829 days ago)
  InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 
(20140722.2)
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.6
   apt  1.2.32
  SourcePackage: dnsmasq
  Title: package dnsmasq-base 2.75-1ubuntu0.16.04.5 failed to install/upgrade: 
package is in a very bad inconsistent state; you should  reinstall it before 
attempting configuration
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1857036] Re: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container.

2020-01-15 Thread Bryce Harrington
The suggested workaround to put "Set disable_coredump false" into
/etc/sudo.conf appears to work for me for suppressing the warning in
focal lxc containers.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1857036

Title:
  `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE):
  Operation not permitted` error when run inside a container.

Status in sudo package in Ubuntu:
  Confirmed

Bug description:
  When using `sudo --login --user USERNAME` with Ubuntu Focal currently,
  it will correctly operate but it will also throw the following error
  before continuing with the logon process (which completes successfully
  except for the stated error):

  sudo: setrlimit(RLIMIT_CORE): Operation not permitted

  A full run of this was tested in a Focal LXD container after dropping
  to a root shell to reproduce (arstotzka is the host system, focal-test
  is the test container):

  teward@arstotzka:~$ lxc shell focal-test
  root@focal-test:~# sudo --login --user ubuntu
  sudo: setrlimit(RLIMIT_CORE): Operation not permitted
  To run a command as administrator (user "root"), use "sudo ".
  See "man sudo_root" for details.

  ubuntu@focal-test:~$

  This appears to be similar to this issue identified on RedHat's
  tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1773148

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: sudo 1.8.29-1ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18
  Uname: Linux 4.15.0-72-generic x86_64
  ApportVersion: 2.20.11-0ubuntu14
  Architecture: amd64
  Date: Thu Dec 19 17:16:31 2019
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  SourcePackage: sudo
  UpgradeStatus: No upgrade log present (probably fresh install)
  VisudoCheck:
   /etc/sudoers: parsed OK
   /etc/sudoers.d/90-cloud-init-users: parsed OK
   /etc/sudoers.d/README: parsed OK

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

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


[Touch-packages] [Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

2019-12-04 Thread Bryce Harrington
** Tags added: server-next

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1785383

Title:
  missing EDNS0 record confuses systemd-resolved

Status in systemd:
  Unknown
Status in dnsmasq package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Triaged
Status in dnsmasq source package in Bionic:
  Triaged
Status in systemd source package in Bionic:
  New

Bug description:
  [Impact]
  dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer 
for a domain it is authoritative for. systemd-resolved seems to get confused by 
this in certain circumstances; when using the stub resolver and requesting an 
address for which there are no  records, there can sometimes be a five 
second hang in resolution.

  [Fix]
  This is fixed by upstream commit 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78

  Not sure if it is worth cherry picking? I imagine the most likely
  trigger will be dnsmasq on routers which are not likely to be running
  Ubuntu, but maybe just in case.

  I also think there are some logic issues in systemd-resolved, upstream
  bug filed:

  https://github.com/systemd/systemd/issues/9785

  [Test Case]
  Simple-ish test case:

  ---
  IFACE=dummy0
  SUBNET=10.0.0

  ip link add $IFACE type dummy
  ifconfig $IFACE ${SUBNET}.1/24
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,${SUBNET}.1 &

  dig -t a test.test @10.0.0.1 | grep EDNS
  # should return "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't
  ---

  To reproduce the systemd-resolved side of the problem

  ---
  # as above, but
  # now configure systemd-resolved to look at only 10.0.0.1, then

  systemd-resolve --reset-server-features
  # should exhibit five second delay then connect, assuming sshd is running :)
  ssh test.test
  ---

  [Discussion]
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: dnsmasq-base 2.79-1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Sat Aug  4 11:33:56 2018
  InstallationDate: Installed on 2018-05-31 (64 days ago)
  InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

2019-12-04 Thread Bryce Harrington
I've linked to the upstream systemd bug report, although from comment #4
it sounds like it might be a regression caused by a security fix.

As to the dnsmasq patch mentioned in the issue description, what it
appears to be doing is checking if there is a pseudoheader in the
request, and if so adds the edns data structure to the response.  I
can't speak to what potential regressions might be concerns here, but
the patch itself looks sensible to me.  So, given adequate testing, I
don't see a reason against considering SRU for this.

** Changed in: systemd (Ubuntu)
   Status: Confirmed => Triaged

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

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

** Changed in: dnsmasq (Ubuntu Bionic)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1785383

Title:
  missing EDNS0 record confuses systemd-resolved

Status in systemd:
  Unknown
Status in dnsmasq package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Triaged
Status in dnsmasq source package in Bionic:
  Triaged
Status in systemd source package in Bionic:
  New

Bug description:
  [Impact]
  dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer 
for a domain it is authoritative for. systemd-resolved seems to get confused by 
this in certain circumstances; when using the stub resolver and requesting an 
address for which there are no  records, there can sometimes be a five 
second hang in resolution.

  [Fix]
  This is fixed by upstream commit 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78

  Not sure if it is worth cherry picking? I imagine the most likely
  trigger will be dnsmasq on routers which are not likely to be running
  Ubuntu, but maybe just in case.

  I also think there are some logic issues in systemd-resolved, upstream
  bug filed:

  https://github.com/systemd/systemd/issues/9785

  [Test Case]
  Simple-ish test case:

  ---
  IFACE=dummy0
  SUBNET=10.0.0

  ip link add $IFACE type dummy
  ifconfig $IFACE ${SUBNET}.1/24
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,${SUBNET}.1 &

  dig -t a test.test @10.0.0.1 | grep EDNS
  # should return "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't
  ---

  To reproduce the systemd-resolved side of the problem

  ---
  # as above, but
  # now configure systemd-resolved to look at only 10.0.0.1, then

  systemd-resolve --reset-server-features
  # should exhibit five second delay then connect, assuming sshd is running :)
  ssh test.test
  ---

  [Discussion]
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: dnsmasq-base 2.79-1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Sat Aug  4 11:33:56 2018
  InstallationDate: Installed on 2018-05-31 (64 days ago)
  InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

2019-12-04 Thread Bryce Harrington
Targeting to bionic, since disco/eoan/focal are on 2.80 which, per the
OP, should already be carrying the requested fix.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1785383

Title:
  missing EDNS0 record confuses systemd-resolved

Status in systemd:
  Unknown
Status in dnsmasq package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Triaged
Status in dnsmasq source package in Bionic:
  Triaged
Status in systemd source package in Bionic:
  New

Bug description:
  [Impact]
  dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer 
for a domain it is authoritative for. systemd-resolved seems to get confused by 
this in certain circumstances; when using the stub resolver and requesting an 
address for which there are no  records, there can sometimes be a five 
second hang in resolution.

  [Fix]
  This is fixed by upstream commit 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78

  Not sure if it is worth cherry picking? I imagine the most likely
  trigger will be dnsmasq on routers which are not likely to be running
  Ubuntu, but maybe just in case.

  I also think there are some logic issues in systemd-resolved, upstream
  bug filed:

  https://github.com/systemd/systemd/issues/9785

  [Test Case]
  Simple-ish test case:

  ---
  IFACE=dummy0
  SUBNET=10.0.0

  ip link add $IFACE type dummy
  ifconfig $IFACE ${SUBNET}.1/24
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,${SUBNET}.1 &

  dig -t a test.test @10.0.0.1 | grep EDNS
  # should return "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't
  ---

  To reproduce the systemd-resolved side of the problem

  ---
  # as above, but
  # now configure systemd-resolved to look at only 10.0.0.1, then

  systemd-resolve --reset-server-features
  # should exhibit five second delay then connect, assuming sshd is running :)
  ssh test.test
  ---

  [Discussion]
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: dnsmasq-base 2.79-1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Sat Aug  4 11:33:56 2018
  InstallationDate: Installed on 2018-05-31 (64 days ago)
  InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1785383] Re: missing EDNS0 record confuses systemd-resolved

2019-12-04 Thread Bryce Harrington
** Bug watch added: github.com/systemd/systemd/issues #9785
   https://github.com/systemd/systemd/issues/9785

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/9785
   Importance: Unknown
   Status: Unknown

** Description changed:

- dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty
- answer for a domain it is authoritative for. systemd-resolved seems to
- get confused by this in certain circumstances; when using the stub
- resolver and requesting an address for which there are no  records,
- there can sometimes be a five second hang in resolution.
+ [Impact]
+ dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer 
for a domain it is authoritative for. systemd-resolved seems to get confused by 
this in certain circumstances; when using the stub resolver and requesting an 
address for which there are no  records, there can sometimes be a five 
second hang in resolution.
  
- This is fixed by upstream commit
- 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78
+ [Fix]
+ This is fixed by upstream commit 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78
  
  Not sure if it is worth cherry picking? I imagine the most likely
  trigger will be dnsmasq on routers which are not likely to be running
  Ubuntu, but maybe just in case.
  
  I also think there are some logic issues in systemd-resolved, upstream
  bug filed:
  
  https://github.com/systemd/systemd/issues/9785
  
+ [Test Case]
  Simple-ish test case:
  
  ---
  IFACE=dummy0
  SUBNET=10.0.0
  
  ip link add $IFACE type dummy
  ifconfig $IFACE ${SUBNET}.1/24
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,${SUBNET}.1 &
  
  dig -t a test.test @10.0.0.1 | grep EDNS
  # should return "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't
  ---
  
  To reproduce the systemd-resolved side of the problem
  
  ---
  # as above, but
  # now configure systemd-resolved to look at only 10.0.0.1, then
  
  systemd-resolve --reset-server-features
  # should exhibit five second delay then connect, assuming sshd is running :)
  ssh test.test
  ---
  
+ [Discussion]
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: dnsmasq-base 2.79-1
  ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  Date: Sat Aug  4 11:33:56 2018
  InstallationDate: Installed on 2018-05-31 (64 days ago)
  InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64 
(20180426)
  ProcEnviron:
-  TERM=xterm
-  PATH=(custom, no user)
-  LANG=en_GB.UTF-8
-  SHELL=/bin/bash
+  TERM=xterm
+  PATH=(custom, no user)
+  LANG=en_GB.UTF-8
+  SHELL=/bin/bash
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1785383

Title:
  missing EDNS0 record confuses systemd-resolved

Status in systemd:
  Unknown
Status in dnsmasq package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  [Impact]
  dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer 
for a domain it is authoritative for. systemd-resolved seems to get confused by 
this in certain circumstances; when using the stub resolver and requesting an 
address for which there are no  records, there can sometimes be a five 
second hang in resolution.

  [Fix]
  This is fixed by upstream commit 
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78

  Not sure if it is worth cherry picking? I imagine the most likely
  trigger will be dnsmasq on routers which are not likely to be running
  Ubuntu, but maybe just in case.

  I also think there are some logic issues in systemd-resolved, upstream
  bug filed:

  https://github.com/systemd/systemd/issues/9785

  [Test Case]
  Simple-ish test case:

  ---
  IFACE=dummy0
  SUBNET=10.0.0

  ip link add $IFACE type dummy
  ifconfig $IFACE ${SUBNET}.1/24
  dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo 
--host-record=test.test,${SUBNET}.1 &

  dig -t a test.test @10.0.0.1 | grep EDNS
  # should return "; EDNS ..."
  dig -t  test.test @10.0.0.1 | grep EDNS
  # again, should return "; EDNS ..." but doesn't
  ---

  To reproduce the systemd-resolved side of the problem

  ---
  # as above, but
  # now configure systemd-resolved to look at only 10.0.0.1, then

  systemd-resolve --reset-server-features
  # should exhibit five second delay then connect, assuming sshd is running :)
  ssh test.test
  ---

  [Discussion]
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: dnsmasq-base 2.79-1
  

[Touch-packages] [Bug 1854023] Re: package openssh-client 1:7.2p2-4ubuntu2.8 failed to install/upgrade: package openssh-client is already installed and configured

2019-11-27 Thread Bryce Harrington
Could you clarify the error you're encountering?  The error message in
the title of this bug suggests the package was already installed, so
perhaps this is a non-bug?  There are no error messages or indication of
a fault being hit in any of the attached logs.

** Changed in: openssh (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1854023

Title:
  package openssh-client 1:7.2p2-4ubuntu2.8 failed to install/upgrade:
  package openssh-client is already installed and configured

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  Report that problem

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: openssh-client 1:7.2p2-4ubuntu2.8
  ProcVersionSignature: Ubuntu 4.15.0-45.48~16.04.1-generic 4.15.18
  Uname: Linux 4.15.0-45-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  AptdaemonVersion: 1.1.1+bzr982-0ubuntu14
  Architecture: amd64
  CrashReports:
   600:110:115:0:2019-11-26 16:03:39.894107818 +0530:2019-11-26 
16:03:39.894107818 +0530:/var/crash/ncurses-term.0.uploaded
   640:0:115:1269857:2019-11-26 16:02:43.810198545 +0530:2019-11-26 
16:02:44.810198545 +0530:/var/crash/ncurses-term.0.crash
   600:0:115:194068:2019-11-26 14:01:47.943607091 +0530:2019-11-26 
14:01:48.943607091 +0530:/var/crash/openssh-client.0.crash
   600:0:115:194078:2019-11-26 14:01:48.991607298 +0530:2019-11-26 
14:01:48.967607161 +0530:/var/crash/openssh-sftp-server.0.crash
   644:0:115:0:2019-11-26 16:03:05.783037835 +0530:2019-11-26 
16:03:05.783037835 +0530:/var/crash/ncurses-term.0.upload
  Date: Tue Nov 26 14:01:48 2019
  DuplicateSignature:
   package:openssh-client:1:7.2p2-4ubuntu2.8
   Processing triggers for fontconfig (2.11.94-0ubuntu1.1) ...
   dpkg: error processing package openssh-client (--configure):
    package openssh-client is already installed and configured
  ErrorMessage: package openssh-client is already installed and configured
  InstallationDate: Installed on 2019-11-26 (0 days ago)
  InstallationMedia: Lubuntu 16.04.6 LTS "Xenial Xerus" - Release amd64 
(20190227)
  RelatedPackageVersions:
   ssh-askpass   N/A
   libpam-sshN/A
   keychain  N/A
   ssh-askpass-gnome N/A
  SSHClientVersion: OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g  1 Mar 2016
  SourcePackage: openssh
  Title: package openssh-client 1:7.2p2-4ubuntu2.8 failed to install/upgrade: 
package openssh-client is already installed and configured
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1854038] Re: package openssh-sftp-server 1:7.2p2-4ubuntu2.8 failed to install/upgrade: package openssh-sftp-server is already installed and configured

2019-11-27 Thread Bryce Harrington
*** This bug is a duplicate of bug 1854023 ***
https://bugs.launchpad.net/bugs/1854023

** This bug has been marked a duplicate of bug 1854023
   package openssh-client 1:7.2p2-4ubuntu2.8 failed to install/upgrade: package 
openssh-client is already installed and configured

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1854038

Title:
  package openssh-sftp-server 1:7.2p2-4ubuntu2.8 failed to
  install/upgrade: package openssh-sftp-server is already installed and
  configured

Status in openssh package in Ubuntu:
  New

Bug description:
  check and report

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: openssh-sftp-server 1:7.2p2-4ubuntu2.8
  ProcVersionSignature: Ubuntu 4.15.0-45.48~16.04.1-generic 4.15.18
  Uname: Linux 4.15.0-45-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  AptdaemonVersion: 1.1.1+bzr982-0ubuntu14
  Architecture: amd64
  Date: Tue Nov 26 14:01:48 2019
  DuplicateSignature:
   package:openssh-sftp-server:1:7.2p2-4ubuntu2.8
   Processing triggers for fontconfig (2.11.94-0ubuntu1.1) ...
   dpkg: error processing package openssh-client (--configure):
package openssh-client is already installed and configured
  ErrorMessage: package openssh-sftp-server is already installed and configured
  InstallationDate: Installed on 2019-11-26 (0 days ago)
  InstallationMedia: Lubuntu 16.04.6 LTS "Xenial Xerus" - Release amd64 
(20190227)
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.5
   apt  1.2.29ubuntu0.1
  SourcePackage: openssh
  Title: package openssh-sftp-server 1:7.2p2-4ubuntu2.8 failed to 
install/upgrade: package openssh-sftp-server is already installed and configured
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1851695] Re: DEP8 failure/regression in nspr on arm64 and armhf

2019-11-13 Thread Bryce Harrington
Debian has a patch for the issue:

https://salsa.debian.org/go-
team/packages/notary/commit/b4f024c049b916c4b81fbd1199c86c8b5dfe2934

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to nspr in Ubuntu.
https://bugs.launchpad.net/bugs/1851695

Title:
  DEP8 failure/regression in nspr on arm64 and armhf

Status in notary package in Ubuntu:
  New
Status in nspr package in Ubuntu:
  Invalid
Status in notary package in Debian:
  Confirmed

Bug description:
  nspr 0.6.1~ds1-4 is failing DEP8 test in arm64 and armhf:

  
  autopkgtest [09:46:25]: test command1: /usr/bin/dh_golang_autopkgtest
  autopkgtest [09:46:25]: test command1: [---
  [info] Testing github.com/theupdateframework/notary...
  [info] Source code installed by binary package, overriding 
dh_auto_configure...
  [info] Disabling existing override_dh_auto_configure...
  dh build --builddirectory=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build \
--buildsystem=golang \
--with=golang
 dh_update_autotools_config 
-O--builddirectory=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build 
-O--buildsystem=golang
 dh_autoreconf 
-O--builddirectory=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build 
-O--buildsystem=golang
 debian/rules override_dh_auto_configure
  make[1]: Entering directory '/tmp/autopkgtest.G91v24/autopkgtest_tmp'
  mkdir -p "_build"
  cp -a /usr/share/gocode/src "_build"
  make[1]: Leaving directory '/tmp/autopkgtest.G91v24/autopkgtest_tmp'
 debian/rules override_dh_auto_build
  make[1]: Entering directory '/tmp/autopkgtest.G91v24/autopkgtest_tmp'
  dh_auto_build -- -tags "pkcs11"
cd _build && go install 
-gcflags=all=\"-trimpath=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src\" 
-asmflags=all=\"-trimpath=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src\" 
-v -p 1 -tags pkcs11 github.com/theupdateframework/notary 
github.com/theupdateframework/notary/client 
github.com/theupdateframework/notary/client/changelist 
github.com/theupdateframework/notary/cmd/escrow 
github.com/theupdateframework/notary/cmd/notary 
github.com/theupdateframework/notary/cmd/notary-server 
github.com/theupdateframework/notary/cmd/notary-signer 
github.com/theupdateframework/notary/cryptoservice 
github.com/theupdateframework/notary/passphrase 
github.com/theupdateframework/notary/proto 
github.com/theupdateframework/notary/server 
github.com/theupdateframework/notary/server/errors 
github.com/theupdateframework/notary/server/handlers 
github.com/theupdateframework/notary/server/snapshot 
github.com/theupdateframework/notary/server/storage 
github.com/theupdateframework/notary/server/timestamp 
github.com/theupdateframework/notary/signer 
github.com/theupdateframework/notary/signer/api 
github.com/theupdateframework/notary/signer/client 
github.com/theupdateframework/notary/signer/keydbstore 
github.com/theupdateframework/notary/storage 
github.com/theupdateframework/notary/storage/rethinkdb 
github.com/theupdateframework/notary/trustmanager 
github.com/theupdateframework/notary/trustmanager/remoteks 
github.com/theupdateframework/notary/trustmanager/yubikey 
github.com/theupdateframework/notary/trustpinning 
github.com/theupdateframework/notary/tuf 
github.com/theupdateframework/notary/tuf/data 
github.com/theupdateframework/notary/tuf/signed 
github.com/theupdateframework/notary/tuf/testutils 
github.com/theupdateframework/notary/tuf/testutils/interfaces 
github.com/theupdateframework/notary/tuf/testutils/keys 
github.com/theupdateframework/notary/tuf/utils 
github.com/theupdateframework/notary/tuf/validation 
github.com/theupdateframework/notary/utils 
github.com/theupdateframework/notary/version
  src/github.com/docker/distribution/digestset/set.go:9:2: cannot find package 
"github.com/opencontainers/go-digest" in any of:

/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src/github.com/docker/distribution/vendor/github.com/opencontainers/go-digest
 (vendor tree)
/usr/lib/go-1.12/src/github.com/opencontainers/go-digest (from $GOROOT)

/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src/github.com/opencontainers/go-digest
 (from $GOPATH)
  src/github.com/docker/distribution/blobs.go:13:2: cannot find package 
"github.com/opencontainers/image-spec/specs-go/v1" in any of:

/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src/github.com/docker/distribution/vendor/github.com/opencontainers/image-spec/specs-go/v1
 (vendor tree)
/usr/lib/go-1.12/src/github.com/opencontainers/image-spec/specs-go/v1 
(from $GOROOT)

/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src/github.com/opencontainers/image-spec/specs-go/v1
 (from $GOPATH)
  dh_auto_build: cd _build && go install 
-gcflags=all=\"-trimpath=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src\" 
-asmflags=all=\"-trimpath=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src\" 
-v -p 1 -tags pkcs11 github.com/theupdateframework/notary 

[Touch-packages] [Bug 1851337] Re: package openssh-server 1:8.0p1-6build1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1

2019-11-06 Thread Bryce Harrington
Hi csozo,

It looks like your system was under some form of memory pressure prior
to the openssh installation.  So I don't think this is a fault
necessarily in openssh itself but rather due to your computer having run
out of memory and gotten into some sort of inconsistent state.

I would recommend rebooting the machine (if you haven't already), and
running `apt-get -f install`.  It looks like there might have been some
reconfiguration questions (possibly updates to some of your manual
configuration work?) so I'd run it from a terminal window and keep an
eye on it.

Once you've done that, can you let us know if the issue is resolved or
if you get a better insight as to what went wrong?

** Description changed:

  I don't know.
  
  ProblemType: Package
  DistroRelease: Ubuntu 19.10
  Package: openssh-server 1:8.0p1-6build1
  ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
  Uname: Linux 5.3.0-19-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.1
  Architecture: amd64
  Date: Tue Nov  5 08:22:46 2019
  ErrorMessage: installed openssh-server package post-installation script 
subprocess returned error exit status 1
  InstallationDate: Installed on 2019-01-15 (293 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  Python3Details: /usr/bin/python3.7, Python 3.7.5rc1, python3-minimal, 3.7.5-1
  PythonDetails: /usr/bin/python2.7, Python 2.7.17rc1, python-minimal, 2.7.17-1
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu2
   apt  1.9.4
  SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 1: 
sshd: no hostkeys available -- exiting.
  SourcePackage: openssh
  Title: package openssh-server 1:8.0p1-6build1 failed to install/upgrade: 
installed openssh-server package post-installation script subprocess returned 
error exit status 1
  UpgradeStatus: Upgraded to eoan on 2019-11-05 (0 days ago)
  
- 
  The dpkg log shows:
  
+ ...
  Setting up default-jre-headless (2:1.11-72) ...
  Setting up libpangoxft-1.0-0:amd64 (1.42.4-7) ...
  Setting up libqt4-network:amd64 (4:4.8.7+dfsg-7ubuntu3) ...
  Setting up openssh-server (1:8.0p1-6build1) ...
  Installing new version of config file /etc/ssh/moduli ...
  rescue-ssh.target is a disabled or a static unit, not starting it.
  Job for ssh.service failed because the control process exited with error code.
  See "systemctl status ssh.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript ssh, action "restart" failed.
  ● ssh.service - OpenBSD Secure Shell server
-Loaded: loaded 
(]8;;file://csozo-PC/lib/systemd/system/ssh.service/lib/systemd/system/ssh.service]8;;;
 enabled; vendor preset: enabled)
-Active: activating (auto-restart) (Result: exit-code) since Tue 2019-11-05 
08:22:46 CET; 6ms ago
-  Docs: ]8;;man:sshd(8)man:sshd(8)]8;;
-]8;;man:sshd_config(5)man:sshd_config(5)]8;;
-   Process: 7160 ExecStartPre=/usr/sbin/sshd -t (code=exited, 
status=1/FAILURE)
+    Loaded: loaded 
(]8;;file://csozo-PC/lib/systemd/system/ssh.service/lib/systemd/system/ssh.service]8;;;
 enabled; vendor preset: enabled)
+    Active: activating (auto-restart) (Result: exit-code) since Tue 2019-11-05 
08:22:46 CET; 6ms ago
+  Docs: ]8;;man:sshd(8)man:sshd(8)]8;;
+    ]8;;man:sshd_config(5)man:sshd_config(5)]8;;
+   Process: 7160 ExecStartPre=/usr/sbin/sshd -t (code=exited, 
status=1/FAILURE)
  dpkg: error processing package openssh-server (--configure):
-  installed openssh-server package post-installation script subprocess 
returned error exit status 1
+  installed openssh-server package post-installation script subprocess 
returned error exit status 1
+ 
+ Apt ordering shows:
+ 
+ ...
+ python-lockfile:amd64: Install
+ rygel:amd64: Install
+ xbrlapi:amd64: Install
+ NULL: ConfigurePending
+ 
+ Dmesg indicates that an OOM killer event had occurred previously:
+ 
+ [26198.228512] gsd-housekeepin invoked oom-killer: 
gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
+ [26198.228515] CPU: 0 PID: 4355 Comm: gsd-housekeepin Tainted: G   OE 
5.0.0-32-generic #34-Ubuntu
+ [26198.228515] Hardware name: System manufacturer System Product Name/H61M-K, 
BIOS 0801 07/21/2014
+ [26198.228516] Call Trace:
+ [26198.228522]  dump_stack+0x63/0x8a
+ [26198.228525]  dump_header+0x54/0x2fb
+ [26198.228527]  ? sched_clock+0x9/0x10
+ [26198.228529]  oom_kill_process.cold.30+0xb/0x1d6
+ [26198.228530]  out_of_memory+0x1c3/0x490
+ [26198.228532]  __alloc_pages_slowpath+0xb68/0xea0
+ [26198.228534]  __alloc_pages_nodemask+0x2c4/0x2e0
+ [26198.228536]  alloc_pages_current+0x81/0xe0
+ [26198.228538]  __page_cache_alloc+0x6a/0xa0
+ [26198.228540]  filemap_fault+0x3f0/0x8b0
+ [26198.228541]  ? filemap_map_pages+0x1ae/0x380
+ [26198.228544]  ext4_filemap_fault+0x31/0x44
+ [26198.228546]  __do_fault+0x3c/0x130
+ [26198.228548]  __handle_mm_fault+0xe4b/0x1280
+ [26198.228550]  ? __switch_to_asm+0x41/0x70
+ [26198.228552]  

[Touch-packages] [Bug 1851337] Re: package openssh-server 1:8.0p1-6build1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1

2019-11-06 Thread Bryce Harrington
** Description changed:

  I don't know.
  
  ProblemType: Package
  DistroRelease: Ubuntu 19.10
  Package: openssh-server 1:8.0p1-6build1
  ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
  Uname: Linux 5.3.0-19-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.1
  Architecture: amd64
  Date: Tue Nov  5 08:22:46 2019
  ErrorMessage: installed openssh-server package post-installation script 
subprocess returned error exit status 1
  InstallationDate: Installed on 2019-01-15 (293 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  Python3Details: /usr/bin/python3.7, Python 3.7.5rc1, python3-minimal, 3.7.5-1
  PythonDetails: /usr/bin/python2.7, Python 2.7.17rc1, python-minimal, 2.7.17-1
  RelatedPackageVersions:
-  dpkg 1.19.7ubuntu2
-  apt  1.9.4
+  dpkg 1.19.7ubuntu2
+  apt  1.9.4
  SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 1: 
sshd: no hostkeys available -- exiting.
  SourcePackage: openssh
  Title: package openssh-server 1:8.0p1-6build1 failed to install/upgrade: 
installed openssh-server package post-installation script subprocess returned 
error exit status 1
  UpgradeStatus: Upgraded to eoan on 2019-11-05 (0 days ago)
+ 
+ 
+ The dpkg log shows:
+ 
+ Setting up default-jre-headless (2:1.11-72) ...
+ Setting up libpangoxft-1.0-0:amd64 (1.42.4-7) ...
+ Setting up libqt4-network:amd64 (4:4.8.7+dfsg-7ubuntu3) ...
+ Setting up openssh-server (1:8.0p1-6build1) ...
+ Installing new version of config file /etc/ssh/moduli ...
+ rescue-ssh.target is a disabled or a static unit, not starting it.
+ Job for ssh.service failed because the control process exited with error code.
+ See "systemctl status ssh.service" and "journalctl -xe" for details.
+ invoke-rc.d: initscript ssh, action "restart" failed.
+ ● ssh.service - OpenBSD Secure Shell server
+Loaded: loaded 
(]8;;file://csozo-PC/lib/systemd/system/ssh.service/lib/systemd/system/ssh.service]8;;;
 enabled; vendor preset: enabled)
+Active: activating (auto-restart) (Result: exit-code) since Tue 2019-11-05 
08:22:46 CET; 6ms ago
+  Docs: ]8;;man:sshd(8)man:sshd(8)]8;;
+]8;;man:sshd_config(5)man:sshd_config(5)]8;;
+   Process: 7160 ExecStartPre=/usr/sbin/sshd -t (code=exited, 
status=1/FAILURE)
+ dpkg: error processing package openssh-server (--configure):
+  installed openssh-server package post-installation script subprocess 
returned error exit status 1

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1851337

Title:
  package openssh-server 1:8.0p1-6build1 failed to install/upgrade:
  installed openssh-server package post-installation script subprocess
  returned error exit status 1

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  I don't know.

  ProblemType: Package
  DistroRelease: Ubuntu 19.10
  Package: openssh-server 1:8.0p1-6build1
  ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1
  Uname: Linux 5.3.0-19-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.1
  Architecture: amd64
  Date: Tue Nov  5 08:22:46 2019
  ErrorMessage: installed openssh-server package post-installation script 
subprocess returned error exit status 1
  InstallationDate: Installed on 2019-01-15 (293 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
(20181017.3)
  Python3Details: /usr/bin/python3.7, Python 3.7.5rc1, python3-minimal, 3.7.5-1
  PythonDetails: /usr/bin/python2.7, Python 2.7.17rc1, python-minimal, 2.7.17-1
  RelatedPackageVersions:
   dpkg 1.19.7ubuntu2
   apt  1.9.4
  SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 1: 
sshd: no hostkeys available -- exiting.
  SourcePackage: openssh
  Title: package openssh-server 1:8.0p1-6build1 failed to install/upgrade: 
installed openssh-server package post-installation script subprocess returned 
error exit status 1
  UpgradeStatus: Upgraded to eoan on 2019-11-05 (0 days ago)

  The dpkg log shows:

  ...
  Setting up default-jre-headless (2:1.11-72) ...
  Setting up libpangoxft-1.0-0:amd64 (1.42.4-7) ...
  Setting up libqt4-network:amd64 (4:4.8.7+dfsg-7ubuntu3) ...
  Setting up openssh-server (1:8.0p1-6build1) ...
  Installing new version of config file /etc/ssh/moduli ...
  rescue-ssh.target is a disabled or a static unit, not starting it.
  Job for ssh.service failed because the control process exited with error code.
  See "systemctl status ssh.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript ssh, action "restart" failed.
  ● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded 
(]8;;file://csozo-PC/lib/systemd/system/ssh.service/lib/systemd/system/ssh.service]8;;;
 enabled; vendor preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Tue 2019-11-05 
08:22:46 CET; 6ms ago
   Docs: ]8;;man:sshd(8)man:sshd(8)]8;;
     

[Touch-packages] [Bug 1760818] Re: gedit and gnome-calculator transparency/graphics corruption issue when GTK_IM_MODULE=xim is set

2019-10-11 Thread Bryce Harrington
I'm able to reproduce the faulty on bionic (not upgraded from xenial),
with GTK_IM_MODULE=xim and an empty .xinputrc.

Can also confirm the workaround suggested by Heiko L seems to fix this
issue, by changing /usr/share/themes/Ambiance/gtk-3.20/gtk.css to this:

> textview text {
>background-color: white;
> }
> scrollbar {
>background-color: white;
> }
> @import url("gtk-main.css");

This worked immediately after restarting gnome-calculator (installed
from deb, not snap) and gedit, no other system changes were required.


** Package changed: gtk+3.0 (Ubuntu) => ubuntu

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1760818

Title:
  gedit and gnome-calculator transparency/graphics corruption issue when
  GTK_IM_MODULE=xim is set

Status in Ubuntu:
  Confirmed
Status in im-config package in Ubuntu:
  Confirmed

Bug description:
  In a "Ubuntu" (Xorg) session on 18.04 gedit and gnome-calculator
  suffer from a graphics issue where parts of their windows hold parts
  of wallpaper or other windows' contents as background.

  See attached screenshot.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: light-themes 16.10+18.04.20180328-0ubuntu1
  ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10
  Uname: Linux 4.15.0-13-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Apr  3 09:12:31 2018
  PackageArchitecture: all
  SourcePackage: ubuntu-themes
  UpgradeStatus: Upgraded to bionic on 2018-02-07 (54 days ago)

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

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


[Touch-packages] [Bug 1845652] Re: rsync sends everything, not just changes

2019-10-09 Thread Bryce Harrington
Thanks for following up, I'm closing the issue as requested.

** Changed in: rsync (Ubuntu)
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1845652

Title:
  rsync sends everything, not just changes

Status in rsync package in Ubuntu:
  Invalid

Bug description:
  Repeated runs of rsync from PC to USB key send everything, not just
  the changes.

  This is reproducible.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: rsync 3.1.3-6
  ProcVersionSignature: Ubuntu 5.0.0-29.31-generic 5.0.21
  Uname: Linux 5.0.0-29-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.10-0ubuntu27.1
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Sep 27 09:18:19 2019
  InstallationDate: Installed on 2019-06-10 (109 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: rsync
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1846243] Re: package openssh-client 1:7.6p1-4ubuntu0.3 failed to install/upgrade: end of file on stdin at conffile prompt

2019-10-02 Thread Bryce Harrington
Hi Nicholas,

The reason for the error you got is because you had a local
configuration setting for ssh in your /etc/ssh/ssh_config:

-Host *
-UseRoaming no

The upgrader was asking whether to keep your changes or revert to the
vanilla config.  Since it timed out without an answer, it defaulted to
keep your configuration changes, which seems sensible in this case.  The
other changes were just deltas in commented-out lines, so would not
affect your installation at all.  I think you can safely ignore the
error.

(It might be nice if the upgrader provided a less confusing UX for
situations such as this, but that's outside the scope of ssh.)

** Changed in: openssh (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1846243

Title:
  package openssh-client 1:7.6p1-4ubuntu0.3 failed to install/upgrade:
  end of file on stdin at conffile prompt

Status in openssh package in Ubuntu:
  Invalid

Bug description:
  bug to install

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: openssh-client 1:7.6p1-4ubuntu0.3
  ProcVersionSignature: Ubuntu 4.4.0-1095.106-aws 4.4.189
  Uname: Linux 4.4.0-1095-aws x86_64
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: amd64
  Date: Tue Oct  1 17:20:44 2019
  Ec2AMI: ami-0e3d43d99dd9cda2c
  Ec2AMIManifest: (unknown)
  Ec2AvailabilityZone: ca-central-1a
  Ec2InstanceType: t2.nano
  Ec2Kernel: unavailable
  Ec2Ramdisk: unavailable
  ErrorMessage: end of file on stdin at conffile prompt
  Python3Details: /usr/bin/python3.6, Python 3.6.8, python3-minimal, 
3.6.7-1~18.04
  PythonDetails: /usr/bin/python2.7, Python 2.7.15+, python-minimal, 
2.7.15~rc1-1
  RelatedPackageVersions:
   ssh-askpass   N/A
   libpam-sshN/A
   keychain  N/A
   ssh-askpass-gnome N/A
  SSHClientVersion: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
  SourcePackage: openssh
  Title: package openssh-client 1:7.6p1-4ubuntu0.3 failed to install/upgrade: 
end of file on stdin at conffile prompt
  UpgradeStatus: Upgraded to bionic on 2019-10-01 (0 days ago)
  modified.conffile..etc.ssh.ssh_config: [modified]
  mtime.conffile..etc.ssh.ssh_config: 2019-04-30T10:51:02.029086

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

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


[Touch-packages] [Bug 1843201] Re: Unity in Wayland prompts for keyboard focus on each run of ssh-askpass-gnome

2019-09-11 Thread Bryce Harrington
I can't say for certain if the issue resides with ssh-askpass-fullscreen
or is a UI usability issue in unity, gnome, or elsewhere, however this
UI is not driven by OpenSSH itself, so I'll retarget this bugtask to
ssh-askpass-fullscreen as a slightly more likely candidate.

** Package changed: openssh (Ubuntu) => ssh-askpass-fullscreen (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1843201

Title:
  Unity in Wayland prompts for keyboard focus on each run of ssh-
  askpass-gnome

Status in gnome-desktop package in Ubuntu:
  New
Status in ssh-askpass-fullscreen package in Ubuntu:
  Incomplete
Status in unity package in Ubuntu:
  New

Bug description:
  When using a Wayland-based Unity session on Ubuntu 19.04:

  1. Have ssh-askpass-gnome as your askpass program.
  2. ssh-add -c 
  3. `ssh` to a host

  Each time, before the ssh-askpass prompt is shown, Unity shows this
  dialog:

  +-+
  | |
  | ssh-askpass wants to inhibit shortcuts  |
  | |
  | You can restore Shortcuts by pressing   |
  | Super+Escape.   |
  | |
  |_|
  |   Deny | Allow  |
  +-+

  This is mildly distracting, and it means that you need to hit ,
  answer, , instead of just answer .

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: ssh-askpass-gnome 1:7.9p1-10
  ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21
  Uname: Linux 5.0.0-27-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27.1
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Sep  8 15:04:25 2019
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   
canonical-oem-somerville-bionic-amd64-20180608-47+tunnels-mlk+X55+tunnels-mlk+X55.1
  InstallationDate: Installed on 2019-08-27 (12 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  SourcePackage: openssh
  UpgradeStatus: Upgraded to disco on 2019-08-31 (8 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-desktop/+bug/1843201/+subscriptions

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


[Touch-packages] [Bug 1841640] Re: package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync não está pronto para configuração não posso configurar (estado atual 'half-installed')

2019-08-28 Thread Bryce Harrington
Hi Leonardo,

It sounds like your upgrade may have been interrupted for some reason,
and rsync didn't finish getting configured.  Forcibly removing and
reinstalling rsync might help.   There is some advice about fixing half-
installed packages here:

https://askubuntu.com/questions/490671/fix-half-installed-package

If this doesn't work, or if you determine the reason why it got into
this state, please let us know.

** Changed in: rsync (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1841640

Title:
  package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync
  não está pronto para configuração  não posso configurar (estado atual
  'half-installed')

Status in rsync package in Ubuntu:
  Incomplete

Bug description:
  No se bien lo que acontecio. ("I don't know well what happened")

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: rsync 3.1.1-3ubuntu1
  ProcVersionSignature: Ubuntu 4.4.0-128.154-generic 4.4.131
  Uname: Linux 4.4.0-128-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  AptOrdering:
   oem-workaround-force-install-intel-red: Remove
   oem-workaround-force-install-qualcomm-red: Remove
   rsync: Configure
   NULL: ConfigurePending
  Architecture: amd64
  Date: Mon Aug 26 06:37:59 2019
  DistributionChannelDescriptor:
   # This is a distribution channel descriptor
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-xenial-amd64-20160624-2
  DpkgTerminalLog:
   A remover oem-workaround-force-install-intel-red (1.4) ...
   A remover oem-workaround-force-install-qualcomm-red (3.2) ...
   dpkg: erro ao processar o pacote rsync (--configure):
    pacote rsync não está pronto para configuração
    não posso configurar (estado atual 'half-installed')
   (dpkg: Error processing rsync package (--configure):
    rsync package not ready for configuration
    i can't configure)
  ErrorMessage: pacote rsync não está pronto para configuração  não posso 
configurar (estado atual 'half-installed')
  (ErrorMessage: rsync package not ready for configuration can't configure)
  InstallationDate: Installed on 2019-08-01 (25 days ago)
  InstallationMedia: Ubuntu 16.04 "Xenial" - Build amd64 LIVE Binary 
20160624-10:47
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1
   apt  1.2.29ubuntu0.1
  SourcePackage: rsync
  Title: package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync 
não está pronto para configuração  não posso configurar (estado atual 
'half-installed')
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1841654] Re: Replace mawk with gawk in main

2019-08-28 Thread Bryce Harrington
** Tags added: server-next

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mawk in Ubuntu.
https://bugs.launchpad.net/bugs/1841654

Title:
  Replace mawk with gawk in main

Status in mawk package in Ubuntu:
  New

Bug description:
  For POSIX compatibility reasons Ubuntu ships with mawk ("Mike's awk" =
  mawk) in main. There is an awk-symlink to mawk, thus mawk is the
  official awk implementation in Ubuntu.

  == Reasons against keeping mawk ==

  *The mawk package is synced from debian and it is heavily
  undermaintained: Debian (and thus Ubuntu) still ships version
  1.3.3-17, the same version at least since oldoldstable:
  https://packages.debian.org/search?searchon=names=mawk

  *part-time maintainer Thomas E. Dickey (https://invisible-
  island.net/mawk/) called officially out that Debian "neglected" mawk
  in 2014 ("As noted, mawk has been neglected by some packagers (see for
  example this http://bugs.debian.org/cgi-
  bin/pkgreport.cgi?package=mawk)". And Debian (and Ubuntu) still ship
  the same version five years later

  *Most other distributions ship mawk at least in its last official
  incarnation 1.3.4 in their repositories. Dickey lists AIX, Fedora,
  FinkPorts (Mac OS X), FreeBSD port, Gentoo, HPUX, MacPorts (Mac OS X),
  NetBSD pkgsrc/lang, OpenCSW (Solaris). But even that version is from
  2014 and doesn't seem to be developed anymore:
  https://github.com/ThomasDickey/mawk-20140914/commits/master

  *A planned rewrite mawk2 was planned by original author Mike Brennan
  in 2016 but obviously came to nothing:
  https://github.com/ploxiln/mawk-2/commits/master

  *Thus mawk sits in Ubuntu main in a version published upstream in 2009
  and celebrates its 10th anniversary of negligence. In a state that
  Debian was called out for 5 years ago.

  *This year it is 10 years unmaintained and largely untouched. At the
  end of the next LTS-support-cycle we can celebrate 15 years of not
  supporting it.

  *awk is included in Linux for POSIX standard compliance. Mawk is known
  to be fast and small but it is the implementation that is farthest
  from being POSIX compliant, missing things like named character
  classes like [[:space:]] within its EREs.

  == Reasons for gawk as a replacement ==

  *It is the official GNU awk implementation and known to work well with
  the rest of the GNU userland.

  *It is actively maintained with the last version 5.01 shipping in
  June, 2019 (even if Ubuntu will obviously still ship 4.2 for Eoan).

  *It is mostly compliant with the POSIX standard.

  *Most other distributions ship it as the standard POSIX
  implementation, with a awk symlink. So it had security reviews already
  by Red Hat and others.

  == Possible problems with switching to gawk in time for Ubuntu 20.4 ==

  - It might need to be MIRed by the Ubuntu security team and a review
  might take some time. So I filed this bug early with Eoan not yet out
  of the door.

  - It is much larger than mawk, the Ubuntu package is 1600 kB in size,
  while mawk is only about 190KB. Thus some might want to split out some
  basic functionality to save size. Like what is vim-tiny to vim. To
  start gawk in --traditional or --posix mode and disable the extensions
  at compile time might be a good start to reduce the size. See:
  https://www.gnu.org/software/gawk/manual/html_node/Additional-
  Configuration-Options.html#Additional-Configuration-Options

  =

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: mawk 1.3.3-17ubuntu3
  ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21
  Uname: Linux 5.0.0-27-generic x86_64
  ApportVersion: 2.20.10-0ubuntu27.1
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Aug 27 20:12:11 2019
  Dependencies:
   gcc-9-base 9.1.0-2ubuntu2~19.04
   libc6 2.29-0ubuntu2
   libgcc1 1:9.1.0-2ubuntu2~19.04
   libidn2-0 2.0.5-1
   libunistring2 0.9.10-1ubuntu2
  InstallationDate: Installed on 2018-02-23 (550 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
  ProcEnviron:
   LANGUAGE=de_AT:de
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=de_AT.UTF-8
   SHELL=/bin/bash
  SourcePackage: mawk
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1841640] Re: package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync não está pronto para configuração não posso configurar (estado atual 'half-installed')

2019-08-28 Thread Bryce Harrington
** Description changed:

- No se bien lo que acontecio.
+ No se bien lo que acontecio. ("I don't know well what happened")
  
  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: rsync 3.1.1-3ubuntu1
  ProcVersionSignature: Ubuntu 4.4.0-128.154-generic 4.4.131
  Uname: Linux 4.4.0-128-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  AptOrdering:
-  oem-workaround-force-install-intel-red: Remove
-  oem-workaround-force-install-qualcomm-red: Remove
-  rsync: Configure
-  NULL: ConfigurePending
+  oem-workaround-force-install-intel-red: Remove
+  oem-workaround-force-install-qualcomm-red: Remove
+  rsync: Configure
+  NULL: ConfigurePending
  Architecture: amd64
  Date: Mon Aug 26 06:37:59 2019
  DistributionChannelDescriptor:
-  # This is a distribution channel descriptor
-  # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
-  canonical-oem-somerville-xenial-amd64-20160624-2
+  # This is a distribution channel descriptor
+  # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
+  canonical-oem-somerville-xenial-amd64-20160624-2
  DpkgTerminalLog:
-  A remover oem-workaround-force-install-intel-red (1.4) ...
-  A remover oem-workaround-force-install-qualcomm-red (3.2) ...
-  dpkg: erro ao processar o pacote rsync (--configure):
-   pacote rsync não está pronto para configuração
-   não posso configurar (estado atual 'half-installed')
+  A remover oem-workaround-force-install-intel-red (1.4) ...
+  A remover oem-workaround-force-install-qualcomm-red (3.2) ...
+  dpkg: erro ao processar o pacote rsync (--configure):
+   pacote rsync não está pronto para configuração
+   não posso configurar (estado atual 'half-installed')
  ErrorMessage: pacote rsync não está pronto para configuração  não posso 
configurar (estado atual 'half-installed')
  InstallationDate: Installed on 2019-08-01 (25 days ago)
  InstallationMedia: Ubuntu 16.04 "Xenial" - Build amd64 LIVE Binary 
20160624-10:47
  RelatedPackageVersions:
-  dpkg 1.18.4ubuntu1
-  apt  1.2.29ubuntu0.1
+  dpkg 1.18.4ubuntu1
+  apt  1.2.29ubuntu0.1
  SourcePackage: rsync
  Title: package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync 
não está pronto para configuração  não posso configurar (estado atual 
'half-installed')
  UpgradeStatus: No upgrade log present (probably fresh install)

** Description changed:

  No se bien lo que acontecio. ("I don't know well what happened")
  
  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: rsync 3.1.1-3ubuntu1
  ProcVersionSignature: Ubuntu 4.4.0-128.154-generic 4.4.131
  Uname: Linux 4.4.0-128-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  AptOrdering:
   oem-workaround-force-install-intel-red: Remove
   oem-workaround-force-install-qualcomm-red: Remove
   rsync: Configure
   NULL: ConfigurePending
  Architecture: amd64
  Date: Mon Aug 26 06:37:59 2019
  DistributionChannelDescriptor:
   # This is a distribution channel descriptor
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-xenial-amd64-20160624-2
  DpkgTerminalLog:
   A remover oem-workaround-force-install-intel-red (1.4) ...
   A remover oem-workaround-force-install-qualcomm-red (3.2) ...
   dpkg: erro ao processar o pacote rsync (--configure):
    pacote rsync não está pronto para configuração
    não posso configurar (estado atual 'half-installed')
+  (dpkg: Error processing rsync package (--configure):
+   rsync package not ready for configuration
+   i can't configure)
  ErrorMessage: pacote rsync não está pronto para configuração  não posso 
configurar (estado atual 'half-installed')
  InstallationDate: Installed on 2019-08-01 (25 days ago)
  InstallationMedia: Ubuntu 16.04 "Xenial" - Build amd64 LIVE Binary 
20160624-10:47
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1
   apt  1.2.29ubuntu0.1
  SourcePackage: rsync
  Title: package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync 
não está pronto para configuração  não posso configurar (estado atual 
'half-installed')
  UpgradeStatus: No upgrade log present (probably fresh install)

** Description changed:

  No se bien lo que acontecio. ("I don't know well what happened")
  
  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: rsync 3.1.1-3ubuntu1
  ProcVersionSignature: Ubuntu 4.4.0-128.154-generic 4.4.131
  Uname: Linux 4.4.0-128-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  AptOrdering:
   oem-workaround-force-install-intel-red: Remove
   oem-workaround-force-install-qualcomm-red: Remove
   rsync: Configure
   NULL: ConfigurePending
  Architecture: amd64
  Date: Mon Aug 26 06:37:59 2019
  DistributionChannelDescriptor:
   # This is a distribution channel descriptor
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-xenial-amd64-20160624-2
  DpkgTerminalLog:
   A remover oem-workaround-force-install-intel-red (1.4) ...
   A remover 

[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived clusters

2019-08-26 Thread Bryce Harrington
The aforementioned link shows there's been work towards a fix in
systemd.  Can't say if that suggests what can be done to improve
keepalived, but I've tagged this "server-next" to get it on the Ubuntu
SErver Team's high priority list, as per Robie's earlier comment.

** Tags added: server-next

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101

Title:
  [master] Restarting systemd-networkd breaks keepalived clusters

Status in netplan:
  Invalid
Status in keepalived package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Triaged

Bug description:
  Configure netplan for interfaces, for example (a working config with
  IP addresses obfuscated)

  network:
  ethernets:
  eth0:
  addresses: [192.168.0.5/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth2:
  addresses:
- 12.13.14.18/29
- 12.13.14.19/29
  gateway4: 12.13.14.17
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth3:
  addresses: [10.22.11.6/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth4:
  addresses: [10.22.14.6/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth7:
  addresses: [9.5.17.34/29]
  dhcp4: false
  optional: true
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  version: 2

  Configure keepalived (again, a working config with IP addresses
  obfuscated)

  global_defs   # Block id
  {
  notification_email {
  sysadm...@blah.com
  }
  notification_email_from keepali...@system3.hq.blah.com
  smtp_server 10.22.11.7 # IP
  smtp_connect_timeout 30  # integer, seconds
  router_id system3  # string identifying the machine,
   # (doesn't have to be hostname).
  vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
  vrrp_mcast_group6 ff02::12   # optional, default ff02::12
  enable_traps # enable SNMP traps
  }
  vrrp_sync_group collection {
  group {
  wan
  lan
  phone
  }
  vrrp_instance wan {
  state MASTER
  interface eth2
  virtual_router_id 77
  priority 150
  advert_int 1
  smtp_alert
  authentication {
  auth_type PASS
  auth_pass BlahBlah
  }
  virtual_ipaddress {
  12.13.14.20
  }
  }
  vrrp_instance lan {
  state MASTER
  interface eth3
  virtual_router_id 78
  priority 150
  advert_int 1
  smtp_alert
  authentication {
  auth_type PASS
  auth_pass MoreBlah
  }
  virtual_ipaddress {
  10.22.11.13/24
  }
  }
  vrrp_instance phone {
  state MASTER
  interface eth4
  virtual_router_id 79
  priority 150
  advert_int 1
  smtp_alert
  authentication {
  auth_type PASS
  auth_pass MostBlah
  }
  virtual_ipaddress {
  10.22.14.3/24
  }
  }

  At boot the affected interfaces have:
  5: eth4:  mtu 1500 qdisc mq state UP group 
default qlen 1000
  link/ether ab:cd:ef:90:c0:e3 brd ff:ff:ff:ff:ff:ff
  inet 10.22.14.6/24 brd 10.22.14.255 scope global eth4
 valid_lft forever preferred_lft forever
  inet 10.22.14.3/24 scope global secondary eth4
 valid_lft forever preferred_lft forever
  inet6 fe80::ae1f:6bff:fe90:c0e3/64 scope link 
 valid_lft forever preferred_lft forever
  7: eth3:  mtu 1500 qdisc mq state UP group 
default qlen 1000
  link/ether ab:cd:ef:b0:26:29 brd ff:ff:ff:ff:ff:ff
  inet 10.22.11.6/24 brd 10.22.11.255 scope global eth3
 valid_lft forever preferred_lft forever
  inet 10.22.11.13/24 scope global secondary eth3
 valid_lft forever preferred_lft forever
  inet6 fe80::ae1f:6bff:feb0:2629/64 scope link 
 valid_lft forever preferred_lft forever
  9: eth2:  mtu 1500 qdisc 

[Touch-packages] [Bug 1838370] Re: slapd segfault on filter parse error

2019-08-09 Thread Bryce Harrington
** Description changed:

  Impact
  --
  
- Users willing to use the slapd rwm overlay will face a slapd segmentation 
fault
- when trying to rewrite some rules. Backporting this fix will allow users using
- stable releases to take advantage of this feature without crashing slapd. This
- issue was fixed by upstream not freeing the rwm overlay filter memory without
- prior checking.
+ Users willing to use the slapd rwm overlay will face a slapd
+ segmentation fault when trying to rewrite some rules. Backporting this
+ fix will allow users using stable releases to take advantage of this
+ feature without crashing slapd. This issue was fixed by upstream not
+ freeing the rwm overlay filter memory without prior checking.
  
  Test Case
  -
  
- In this test case, the rwm overlay will be used and a rule will be created to
- deny any search request for uid=root, then the 'ldapsearch' will be invoked to
- trigger the failure. It is important to mention that the 'ldapsearch' command
- should fail regardless the presence of the bug in the package, the target here
- is the slapd crash. To reproduce this bug one can follow the procedure below 
in
- Ubuntu xenial, bionic or disco:
+ In this test case, the rwm overlay will be used and a rule will be
+ created to deny any search request for uid=root, then the 'ldapsearch'
+ will be invoked to trigger the failure. It is important to mention that
+ the 'ldapsearch' command should fail regardless the presence of the bug
+ in the package, the target here is the slapd crash. To reproduce this
+ bug one can follow the procedure below in Ubuntu xenial, bionic or
+ disco:
  
  $ sudo apt-get update
  $ sudo apt-get install slapd ldap-utils -y
  
  Reconfigure the slapd package. When asked about a domain, use "example.com".
  Choose a password you want (or just leave it blank), and accept defaults for
  everything else:
  
  $ sudo dpkg-reconfigure slapd
  
  Create a file called 'add-rwm.ldif' with the following content:
  
  $ cat add-rwm.ldif
  dn: cn=module{0},cn=config
  changetype: modify
  add: olcModuleLoad
  olcModuleLoad: rwm
  
  dn: olcOverlay=rwm,olcDatabase={1}mdb,cn=config
  changetype: add
  objectClass: olcOverlayConfig
  objectClass: olcRwmConfig
  olcOverlay: rwm
  olcRwmRewrite: {0} rwm-rewriteEngine "on"
  olcRwmRewrite: {1} rwm-rewriteContext "searchFilter"
  olcRwmRewrite: {2} rwm-rewriteRule "(.*)(uid=root)(.*)" "$1$2$3" "#"
  
- 
  With this file in place, run:
  
  $ sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f add-rwm.ldif
  
  Now, to trigger the crash:
  
  $ ldapsearch -x -h localhost -b dc=example,dc=com -LLL uid=root
  Server is unwilling to perform (53)
  Additional information: searchFilter/searchFilterAttrDN massage error
  
- 
  slapd process will die, and /var/crash will have a crash file for slapd. You
  can run the following command to confirm the error:
  
  $ cat /var/log/syslog | grep filter_free
  Aug  9 19:51:05 popular-gorilla slapd[1479]: filter_free: unknown filter 
type=28530
  
- 
  Regression Potential
  
  
- Since the fix is a patch provided by upstream (reviewed by maintainers and us)
- simple mistakes like typos are not expected. The patch impacts only the rwm
- module which is not loaded by default. So any regression would affect only the
- users that make use of this overlay. If an user is not using rwm overlay and 
is
- facing any issue, it should be related to other problems related to LDAP
- directory services.
- 
- 
+ Since the fix is a patch provided by upstream (reviewed by maintainers
+ and us) simple mistakes like typos are not expected. The patch impacts
+ only the rwm module which is not loaded by default. So any regression
+ would affect only the users that make use of this overlay. If an user is
+ not using rwm overlay and is facing any issue, it should be related to
+ other problems related to LDAP directory services.
  
  [Original message]
  
  Hello!
  We have faced slapd crash, seems an attacker was trying to brute force one
  of our services and uid parsing failures caused slapd crash:
  
  Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH
  base="ou=test,dc=test,dc=com" scope=2 deref=0
  
filter="(&(uid=aistar123<>!n)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0"
  Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH attr=objectClass uid
  userPassword uidNumber gidNumber gecos homeDirectory loginShell
  krbPrincipalName cn memberOf modifyTimestamp modifyTimestamp
  shadowLastChange shadowMin shadow
  Max shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange
  krbPasswordExpiration pwdAttribute authorizedService accountExpires
  userAccountControl nsAccountLock host loginDisabled loginExpirationTime
  loginAllowedTimeMap sshPublic
  Key
  Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SEARCH RESULT tag=101 err=0
  nentries=0 text=massaged filter parse error
  Jul 26 18:59:47 kernel: [ 9441.554161] slapd[2367]: segfault at 18 ip
  

[Touch-packages] [Bug 1838370] Re: slapd segfault on filter parse error

2019-07-31 Thread Bryce Harrington
** Tags added: server-next

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1838370

Title:
  slapd segfault on filter parse error

Status in openldap:
  Fix Released
Status in openldap package in Ubuntu:
  Confirmed
Status in openldap source package in Xenial:
  New
Status in openldap source package in Bionic:
  New
Status in openldap source package in Disco:
  New

Bug description:
  Hello!
  We have faced slapd crash, seems an attacker was trying to brute force one
  of our services and uid parsing failures caused slapd crash:

  Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH
  base="ou=test,dc=test,dc=com" scope=2 deref=0
  
filter="(&(uid=aistar123<>!n)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0"
  Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH attr=objectClass uid
  userPassword uidNumber gidNumber gecos homeDirectory loginShell
  krbPrincipalName cn memberOf modifyTimestamp modifyTimestamp
  shadowLastChange shadowMin shadow
  Max shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange
  krbPasswordExpiration pwdAttribute authorizedService accountExpires
  userAccountControl nsAccountLock host loginDisabled loginExpirationTime
  loginAllowedTimeMap sshPublic
  Key
  Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SEARCH RESULT tag=101 err=0
  nentries=0 text=massaged filter parse error
  Jul 26 18:59:47 kernel: [ 9441.554161] slapd[2367]: segfault at 18 ip
  7fc8d18ec512 sp 7fc8889e2810 error 4 in libc-2.23.so
  [7fc8d1868000+1c]

  Another faulty filter example:
  
filter="(&(uid=sql<>?)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0"
  
filter="(&(uid=fugeone<>?123)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0"

  $ lsb_release -rd
  Description: Ubuntu 16.04.5 LTS
  Release: 16.04

  $ slapd -VVV
  @(#) $OpenLDAP: slapd  (Ubuntu) (May 22 2018 13:54:12) $
  buildd@lcy01-amd64-019
  :/build/openldap-t_Ta0O/openldap-2.4.42+dfsg/debian/build/servers/slapd

  Included static backends:
  config
  ldif

  $ apt-cache policy slapd
  slapd:
Installed: 2.4.42+dfsg-2ubuntu3.3
Candidate: 2.4.42+dfsg-2ubuntu3.5
Version table:
   2.4.42+dfsg-2ubuntu3.5 500
  500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
  Packages
   *** 2.4.42+dfsg-2ubuntu3.3 100
  100 /var/lib/dpkg/status
   2.4.42+dfsg-2ubuntu3.2 500
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64
  Packages
   2.4.42+dfsg-2ubuntu3 500
  500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

   affects ubuntu/openldap

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

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


[Touch-packages] [Bug 1838370] Re: slapd segfault on filter parse error

2019-07-31 Thread Bryce Harrington
** Patch added: "Patch mentioned in previous comment"
   
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1838370/+attachment/5280211/+files/0001-ITS-8964-Do-not-free-original-filter.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1838370

Title:
  slapd segfault on filter parse error

Status in openldap:
  Fix Released
Status in openldap package in Ubuntu:
  Confirmed
Status in openldap source package in Xenial:
  New
Status in openldap source package in Bionic:
  New
Status in openldap source package in Disco:
  New

Bug description:
  Hello!
  We have faced slapd crash, seems an attacker was trying to brute force one
  of our services and uid parsing failures caused slapd crash:

  Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH
  base="ou=test,dc=test,dc=com" scope=2 deref=0
  
filter="(&(uid=aistar123<>!n)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0"
  Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH attr=objectClass uid
  userPassword uidNumber gidNumber gecos homeDirectory loginShell
  krbPrincipalName cn memberOf modifyTimestamp modifyTimestamp
  shadowLastChange shadowMin shadow
  Max shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange
  krbPasswordExpiration pwdAttribute authorizedService accountExpires
  userAccountControl nsAccountLock host loginDisabled loginExpirationTime
  loginAllowedTimeMap sshPublic
  Key
  Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SEARCH RESULT tag=101 err=0
  nentries=0 text=massaged filter parse error
  Jul 26 18:59:47 kernel: [ 9441.554161] slapd[2367]: segfault at 18 ip
  7fc8d18ec512 sp 7fc8889e2810 error 4 in libc-2.23.so
  [7fc8d1868000+1c]

  Another faulty filter example:
  
filter="(&(uid=sql<>?)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0"
  
filter="(&(uid=fugeone<>?123)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0"

  $ lsb_release -rd
  Description: Ubuntu 16.04.5 LTS
  Release: 16.04

  $ slapd -VVV
  @(#) $OpenLDAP: slapd  (Ubuntu) (May 22 2018 13:54:12) $
  buildd@lcy01-amd64-019
  :/build/openldap-t_Ta0O/openldap-2.4.42+dfsg/debian/build/servers/slapd

  Included static backends:
  config
  ldif

  $ apt-cache policy slapd
  slapd:
Installed: 2.4.42+dfsg-2ubuntu3.3
Candidate: 2.4.42+dfsg-2ubuntu3.5
Version table:
   2.4.42+dfsg-2ubuntu3.5 500
  500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
  Packages
   *** 2.4.42+dfsg-2ubuntu3.3 100
  100 /var/lib/dpkg/status
   2.4.42+dfsg-2ubuntu3.2 500
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64
  Packages
   2.4.42+dfsg-2ubuntu3 500
  500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

   affects ubuntu/openldap

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

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


[Touch-packages] [Bug 1838436] Re: popt download location broken

2019-07-31 Thread Bryce Harrington
Debian sees the problem too, at least since mid-June:

http://duck.debian.net/static/sp/p/popt.html

https://tracker.debian.org/pkg/popt


The domain name is still registered, through next year:

https://whois.gandi.net/en/results?search=rpm5.org

>From debian/changelog, looks like the last major release, 1.16, was back
in 2010.

The project's devel mailing list had discussion activity within the last
couple years, but not very much, and nothing to explain what's going
on.:

https://www.mail-archive.com/popt-devel@rpm5.org/maillist.html


It looks like the problem isn't merely a stale link, but that the activity 
level of the upstream project has dropped - unfortunately not something really 
addressable at the distro level.  Depending on what you need from the upstream 
website, you might try reaching out to individuals from that mailing list 
discussion.

Are you spotting any secondary issues being caused by the offline
rpm5.org website, within Ubuntu or the Ubuntu project infrastructure?
If there isn't, then I think since Ubuntu has been simply syncing this
package from Debian, I think we just follow their lead on what to do
packaging-wise.

** Changed in: popt (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to popt in Ubuntu.
https://bugs.launchpad.net/bugs/1838436

Title:
  popt download location broken

Status in popt package in Ubuntu:
  Incomplete

Bug description:
  rpm5.org disappeared, with download area, home page and CVS repo.

  See also https://bugs.archlinux.org/task/62888?project=1=popt

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

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


[Touch-packages] [Bug 1531184] Re: [SRU] dnsmasq doesn't start on boot because its interface isn't up yet

2019-07-22 Thread Bryce Harrington
** Description changed:

  [Impact]
- TBD
+ dnsmasq will fail to respond on network devices that weren't up when its
+ service started, thus not binding as expected.
  
  [Test Case]
  TBD
  
  [Regression Potential]
  The fix is just configuring the order of service startup, so is unlikely to 
create any regressions.  Things to watch would be service related misbehaviors 
and general availability of the dnsmasq functionality.
  
  [Fix]
- 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=774970;filename=774970-network-online.debdiff;msg=22
+ Straightforward packaging fix to the service to make it delay startup
+ until after the network is online.
+ 
+ https://bugs.debian.org/cgi-
+ bin/bugreport.cgi?att=1;bug=774970;filename=774970-network-
+ online.debdiff;msg=22
  
  [Discussion]
  
  [Original Report]
  My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0 is 
managed manually in /etc/network/interfaces.
  
  During boot, dnsmasq is started before br-vz0 is created and this causes
  dnsmasq to exit:
  
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: dnsmasq: unknown interface br-vz0
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: unknown interface br-vz0
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: FAILED to start up
  Jan  5 08:56:17 simon-laptop NetworkManager[937]:   NetworkManager 
(version 1.0.4) is starting...
  ...
  Jan  5 08:56:18 simon-laptop NetworkManager[937]: 
interface-parser: parsing file /etc/network/interfaces
  ...
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   found bridge ports 
none for br-vz0
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   adding bridge port 
none to eni_ifaces
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   management mode: 
unmanaged
  
  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: dnsmasq 2.75-1
  ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3
  Uname: Linux 4.3.0-5-generic x86_64
  ApportVersion: 2.19.3-0ubuntu2
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Jan  5 09:53:30 2016
  PackageArchitecture: all
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1531184

Title:
  [SRU] dnsmasq doesn't start on boot because its interface isn't up yet

Status in One Hundred Papercuts:
  Confirmed
Status in dnsmasq package in Ubuntu:
  Confirmed
Status in dnsmasq package in Debian:
  New

Bug description:
  [Impact]
  dnsmasq will fail to respond on network devices that weren't up when its
  service started, thus not binding as expected.

  [Test Case]
  TBD

  [Regression Potential]
  The fix is just configuring the order of service startup, so is unlikely to 
create any regressions.  Things to watch would be service related misbehaviors 
and general availability of the dnsmasq functionality.

  [Fix]
  Straightforward packaging fix to the service to make it delay startup
  until after the network is online.

  https://bugs.debian.org/cgi-
  bin/bugreport.cgi?att=1;bug=774970;filename=774970-network-
  online.debdiff;msg=22

  [Discussion]

  [Original Report]
  My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0 is 
managed manually in /etc/network/interfaces.

  During boot, dnsmasq is started before br-vz0 is created and this
  causes dnsmasq to exit:

  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: dnsmasq: unknown interface br-vz0
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: unknown interface br-vz0
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: FAILED to start up
  Jan  5 08:56:17 simon-laptop NetworkManager[937]:   NetworkManager 
(version 1.0.4) is starting...
  ...
  Jan  5 08:56:18 simon-laptop NetworkManager[937]: 
interface-parser: parsing file /etc/network/interfaces
  ...
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   found bridge ports 
none for br-vz0
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   adding bridge port 
none to eni_ifaces
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   management mode: 
unmanaged

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: dnsmasq 2.75-1
  ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3
  Uname: Linux 4.3.0-5-generic x86_64
  ApportVersion: 2.19.3-0ubuntu2
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Jan  5 09:53:30 2016
  PackageArchitecture: all
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1822776] Re: [SRU] Apply Bash 4.4.20 to fix cpu spinning on built-in wait

2019-07-05 Thread Bryce Harrington
Thanks for testing so thoroughly!  I've gone ahead and set the
verification tags to done, to allow this to now go out.  I've also added
your script to the Test Case, for future reference.

** Description changed:

  [Impact]
  
  Long running bash loops that create and reap processes will crash,
  hanging at 100% CPU.
  
  [Test Case]
  
  A PPA with the proposed fix included is at:
  
-   https://launchpad.net/~bryce/+archive/ubuntu/bash-sru-19-010-1
+   https://launchpad.net/~bryce/+archive/ubuntu/bash-sru-19-010-1
  
  Install the PPA with the fix via:
  
-   sudo add-apt-repository ppa:bryce/bash-sru-19-010-1
-   sudo apt-get update
-   sudo apt-get install bash
+   sudo add-apt-repository ppa:bryce/bash-sru-19-010-1
+   sudo apt-get update
+   sudo apt-get install bash
  
  Run this loop for a few days/weeks:
  
    #!/bin/bash
    while true; do
  sleep 0.5 &
  wait
    done
+ 
+ Reproducer script:
+ 
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1822776/+attachment/5275112/+files
+ /bash-crash-test.sh
  
  It will eventually cause the 'wait' statement to hang, consuming 100%
  after some indeterminate amount of time, dependent on how fast PIDs are
  cycled in the machine.
  
  The Bash bug report mentions longer running loops, but it seems hash
  collisions are the cause, meaning it's just a matter of chance,
  influenced by how fast PIDs are cycled on the machine.
  
  [Regression Potential]
  
  The fix has been reviewed and accepted upstream.  The patch adds a test
  at time of pid determination for if the pid is already in use and if so,
  skip it and pick a different one.  This does change behavior slightly in
  that different pid numbers will be generated in rare cases, but nothing
  should depend on how pids are generated, as the behavior is not
  specified to be anything but random.
  
  The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) ==
  storage[psi].bucket_next", but this only shows when the original bug
  would have been triggered.
  
  Using 'apt-get source bash' to get the original source version, I
  created a deb that includes the 4.4.20 patch and have been running it
  since April 2nd. The 100% CPU spinning is solved, and no other
  regressions have been observed.
  
  Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so
  this involves linearly progressing to the next version (so not skipping
  patches).
  
  [Fix]
  
  Official patch to fix, and to bump to 4.4.20:
  
  http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020
  
  The newest Ubuntu tar.xz with patches I could find at:
  
  http://archive.ubuntu.com/ubuntu/pool/main/b/bash/
  
  also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the
  fix yet.
  
  Although not completely sure, this problem seems to have been introduced
  in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are
  affected.
  
  [Original Report]
  Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when 
spawning sub processes and waiting for them. There is a fix:
  
  https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020
  
  Our application started being affected (locking up) by this since
  migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1),
  Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version',
  because of their unusual versions as patches, apt shows it as
  4.4.18-2ubuntu1).
  
  The 4.4-020 version needs to be included. I think it's actually quite
  critical.
  
  A justification for including the fix would be that a standard language
  feature in a script language is broken, and that it's indeterminate when
  it breaks. Considering the wide spread use of bash, I'm surprised not
  more people have reported issues. My and a client started having issues
  with independently of each other very soon after upgrading to an
  affected version.

** Tags removed: verification-needed verification-needed-bionic 
verification-needed-cosmic
** Tags added: verification-done verification-done-bionic 
verification-done-cosmic

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bash in Ubuntu.
https://bugs.launchpad.net/bugs/1822776

Title:
  [SRU] Apply Bash 4.4.20 to fix cpu spinning on built-in wait

Status in bash package in Ubuntu:
  Fix Released
Status in bash source package in Bionic:
  Fix Committed
Status in bash source package in Cosmic:
  Fix Committed

Bug description:
  [Impact]

  Long running bash loops that create and reap processes will crash,
  hanging at 100% CPU.

  [Test Case]

  A PPA with the proposed fix included is at:

    https://launchpad.net/~bryce/+archive/ubuntu/bash-sru-19-010-1

  Install the PPA with the fix via:

    sudo add-apt-repository ppa:bryce/bash-sru-19-010-1
    sudo apt-get update
    sudo apt-get install bash

  Run this loop for a few days/weeks:

    #!/bin/bash
    while true; do
  sleep 0.5 &
  

[Touch-packages] [Bug 1834994] Re: rsync: --xattrs is extremely slow

2019-07-03 Thread Bryce Harrington
This issue was fixed in Debian with the attached patch from upstream.

SRU process prohibits version jumps so would reject directly updating
the rsync package on Ubuntu 16.04 to 3.2.2-2.

However, if you can define a test case to reliably reproduce the bug,
then it may be possible to get the specific patch accepted.  Would you
be willing to help draft a set of steps to reproduce the bug -
preferably something that can be performed within a few minutes or an
hour, as opposed to a few weeks (else it'll be too hard for folks to
test)?

You can see other steps required for filing an SRU at
https://wiki.ubuntu.com/StableReleaseUpdates.  Anything you can do
towards making this bug report fulfill those requirements will make it
more likely for this to get attention.

One of the potential problems in this case is that the patch is rather
large so may be harder to review.  SRU's tend to go faster when the
patch is just a few lines.

** Patch added: "speedup-xattrs.diff"
   
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1834994/+attachment/5274955/+files/speedup-xattrs.diff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1834994

Title:
  rsync: --xattrs is extremely slow

Status in rsync package in Ubuntu:
  New

Bug description:
  Ubuntu 16.04 LTS repositories contain only rsync version 3.1.1:

  $ apt policy rsync
  rsync:
Installed: 3.1.1-3ubuntu1.2
Candidate: 3.1.1-3ubuntu1.2
Version table:
   *** 3.1.1-3ubuntu1.2 500
  500 http://fi.archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   3.1.1-3ubuntu1 500
  500 http://fi.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  However, this version has a bug where flag --xattrs causes very very
  high CPU usage if source contains lots of unique extended attributes.
  I'm trying to sync 13 TB (roughly 6.5 M files) with extended
  attributes and this bug seems to make this slower and slower as the
  time goes by. The system has been copying the stuff for three weeks
  (!) now. It's getting slower every day but still seems to make
  progress so I try to run it to completion. First couple of terabytes
  suggested that this sync operation should have taken around 4 days.
  The source directory is used by glusterfs which creates checksums as
  extended attributes and practically every file has different checksum.

  Please, update rsync package on Ubuntu 16.04 to 3.1.2-2 or later.

  See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799143

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: rsync 3.1.1-3ubuntu1.2
  ProcVersionSignature: Ubuntu 4.15.0-51.55~16.04.1-lowlatency 4.15.18
  Uname: Linux 4.15.0-51-lowlatency x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  CurrentDesktop: MATE
  Date: Tue Jul  2 09:07:49 2019
  InstallationDate: Installed on 2015-02-23 (1589 days ago)
  InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 
(20150218.1)
  SourcePackage: rsync
  UpgradeStatus: Upgraded to xenial on 2016-06-10 (1116 days ago)

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

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


[Touch-packages] [Bug 1822776] Re: [SRU] Apply Bash 4.4.20 to fix cpu spinning on built-in wait

2019-07-01 Thread Bryce Harrington
Hi halfgaar, just checking in on how the testing has been coming along?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bash in Ubuntu.
https://bugs.launchpad.net/bugs/1822776

Title:
  [SRU] Apply Bash 4.4.20 to fix cpu spinning on built-in wait

Status in bash package in Ubuntu:
  Fix Released
Status in bash source package in Bionic:
  Fix Committed
Status in bash source package in Cosmic:
  Fix Committed

Bug description:
  [Impact]

  Long running bash loops that create and reap processes will crash,
  hanging at 100% CPU.

  [Test Case]

  A PPA with the proposed fix included is at:

https://launchpad.net/~bryce/+archive/ubuntu/bash-sru-19-010-1

  Install the PPA with the fix via:

sudo add-apt-repository ppa:bryce/bash-sru-19-010-1
sudo apt-get update
sudo apt-get install bash

  Run this loop for a few days/weeks:

    #!/bin/bash
    while true; do
  sleep 0.5 &
  wait
    done

  It will eventually cause the 'wait' statement to hang, consuming 100%
  after some indeterminate amount of time, dependent on how fast PIDs
  are cycled in the machine.

  The Bash bug report mentions longer running loops, but it seems hash
  collisions are the cause, meaning it's just a matter of chance,
  influenced by how fast PIDs are cycled on the machine.

  [Regression Potential]

  The fix has been reviewed and accepted upstream.  The patch adds a
  test at time of pid determination for if the pid is already in use and
  if so, skip it and pick a different one.  This does change behavior
  slightly in that different pid numbers will be generated in rare
  cases, but nothing should depend on how pids are generated, as the
  behavior is not specified to be anything but random.

  The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) ==
  storage[psi].bucket_next", but this only shows when the original bug
  would have been triggered.

  Using 'apt-get source bash' to get the original source version, I
  created a deb that includes the 4.4.20 patch and have been running it
  since April 2nd. The 100% CPU spinning is solved, and no other
  regressions have been observed.

  Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so
  this involves linearly progressing to the next version (so not
  skipping patches).

  [Fix]

  Official patch to fix, and to bump to 4.4.20:

  http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020

  The newest Ubuntu tar.xz with patches I could find at:

  http://archive.ubuntu.com/ubuntu/pool/main/b/bash/

  also didn't have the 4.4.20 patch, so it seems no Ubuntu release has
  the fix yet.

  Although not completely sure, this problem seems to have been
  introduced in the 4.4 version of Bash, so in term of LTS versions,
  18.04 and up are affected.

  [Original Report]
  Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when 
spawning sub processes and waiting for them. There is a fix:

  https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020

  Our application started being affected (locking up) by this since
  migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1),
  Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version',
  because of their unusual versions as patches, apt shows it as
  4.4.18-2ubuntu1).

  The 4.4-020 version needs to be included. I think it's actually quite
  critical.

  A justification for including the fix would be that a standard
  language feature in a script language is broken, and that it's
  indeterminate when it breaks. Considering the wide spread use of bash,
  I'm surprised not more people have reported issues. My and a client
  started having issues with independently of each other very soon after
  upgrading to an affected version.

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

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


[Touch-packages] [Bug 1834129] Re: Presence of sshd_config mandatory

2019-06-26 Thread Bryce Harrington
Hi Luke, thanks for reporting this issue.  Unfortunately, I am not able
to reproduce it.

Ubuntu 18.04.2 ships openssh-server 1:7.6p1-4ubuntu0.3, not 7.9.  Is the
version typo'd in the report or are you running a self-installed version
of openssh perhaps?

In any case, I attempted reproduction on both 18.04 (bionic) and 19.10
(eoan) in lxc, but was not able to reproduce a fault.  If you could,
please provide an exact set of commands to reproduce, and the error
message you encountered.  Please also verify you're running the stock
distro version of openssh when doing - reproducing in a clean vanilla
lxc instance or a fresh installation of ubuntu would be helpful.

$ lxc launch ubuntu:18.04/amd64 lp1834129
$ lxc exec lp1834129 bash
# apt-get update
[...]
# ps aux | grep sshd
root   685  0.0  0.0  72296  5660 ?Ss   22:31   0:00 /usr/sbin/sshd 
-D
root   687  0.0  0.0  14856  1008 ?S+   22:31   0:00 grep 
--color=auto sshd
# service sshd stop
# ps aux | grep sshd
root   718  0.0  0.0  14856  1116 ?S+   22:31   0:00 grep 
--color=auto sshd
# ls -l /run/ssh*
ls: cannot access '/run/ssh*': No such file or directory
# touch my_sshd_config
# sshd -f ./my_sshd_config
sshd re-exec requires execution with an absolute path
# /usr/sbin/sshd -f ./my_sshd_config
Missing privilege separation directory: /run/sshd
# mkdir /run/sshd
# /usr/sbin/sshd -f ./my_sshd_config
# ps aux | grep sshd
root   725  0.0  0.0  72296  3344 ?Ss   22:31   0:00 /usr/sbin/sshd 
-f ./my_sshd_config
root   727  0.0  0.0  14856  1040 ?S+   22:31   0:00 grep 
--color=auto sshd
# kill 725
# !ps
ps aux | grep sshd
root   729  0.0  0.0  14856  1004 ?S+   22:32   0:00 grep 
--color=auto sshd
# mv /etc/ssh/sshd_config /tmp/
# /usr/sbin/sshd -f ./my_sshd_config
# !ps
ps aux | grep sshd
root   732  0.0  0.0  72296  3200 ?Ss   22:32   0:00 /usr/sbin/sshd 
-f ./my_sshd_config
root   734  0.0  0.0  14856  1156 ?S+   22:32   0:00 grep 
--color=auto sshd
# ls -l /etc/ssh/sshd_*
ls: cannot access '/etc/ssh/sshd_*': No such file or directory

# passwd ubuntu
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
# su ubuntu
To run a command as administrator (user "root"), use "sudo ".
See "man sudo_root" for details.

$ ssh localhost
ubuntu@localhost's password: 
To run a command as administrator (user "root"), use "sudo ".
See "man sudo_root" for details.
$ logout
Connection to localhost closed.


$ . /etc/lsb-release && echo ${DISTRIB_DESCRIPTION}
Ubuntu 18.04.2 LTS
$ ssh -V
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
$ apt-cache policy openssh-server | grep Installed
  Installed: 1:7.6p1-4ubuntu0.3



** Changed in: openssh (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1834129

Title:
  Presence of sshd_config mandatory

Status in openssh package in Ubuntu:
  Incomplete

Bug description:
  OpenSSH 7.9p1
  Ubuntu 18..04.2 (LTS)

  If a sshd daemon is started with a "-f my_sshd_config" command-line
  specification the sshd process still requires the existence of the
  sshd_config. The bug is somewhere in one of the forked processes
  started when an external client attempts a connection. Since the
  sshd_config file does not exists, an external client connection cannot
  be started.

  Solution: If I "touch /etc/ssh/sshd_config" then the lock-up issue
  goes away and I am successfully able to login.

  Bug: If the sshd configuration file is specified in the command line
  execution of the daeomon, then this should be the only file that
  should be required.

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

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


[Touch-packages] [Bug 1819074] Re: Keepalived < 2.0.x in Ubuntu 18.04 LTS not compatible with systemd-networkd

2019-06-20 Thread Bryce Harrington
** Tags added: server-next

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1819074

Title:
  Keepalived < 2.0.x in Ubuntu 18.04 LTS  not compatible with systemd-
  networkd

Status in keepalived package in Ubuntu:
  Triaged
Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in keepalived source package in Bionic:
  Triaged
Status in netplan.io source package in Bionic:
  New
Status in systemd source package in Bionic:
  New
Status in keepalived source package in Cosmic:
  Triaged
Status in netplan.io source package in Cosmic:
  New
Status in systemd source package in Cosmic:
  New

Bug description:
  Systemd-networkd clobbers VIPs placed by other daemons on any
  reconfiguration triggering systemd-networkd restart (netplan apply for
  example).  Keepalived < version 2.0.x will not restore a VIP lost in
  this fashion, breaking high availability on Ubuntu 18.04 LTS.  A
  backport for keepalived >= 2.0.x should fix the issue.

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

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


[Touch-packages] [Bug 1819074] Re: Keepalived < 2.0.x in Ubuntu 18.04 LTS not compatible with systemd-networkd

2019-06-19 Thread Bryce Harrington
** Changed in: keepalived (Ubuntu Bionic)
   Status: New => Triaged

** Changed in: keepalived (Ubuntu Cosmic)
   Status: New => Triaged

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

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

** Changed in: keepalived (Ubuntu Cosmic)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1819074

Title:
  Keepalived < 2.0.x in Ubuntu 18.04 LTS  not compatible with systemd-
  networkd

Status in keepalived package in Ubuntu:
  Triaged
Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in keepalived source package in Bionic:
  Triaged
Status in netplan.io source package in Bionic:
  New
Status in systemd source package in Bionic:
  New
Status in keepalived source package in Cosmic:
  Triaged
Status in netplan.io source package in Cosmic:
  New
Status in systemd source package in Cosmic:
  New

Bug description:
  Systemd-networkd clobbers VIPs placed by other daemons on any
  reconfiguration triggering systemd-networkd restart (netplan apply for
  example).  Keepalived < version 2.0.x will not restore a VIP lost in
  this fashion, breaking high availability on Ubuntu 18.04 LTS.  A
  backport for keepalived >= 2.0.x should fix the issue.

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

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


[Touch-packages] [Bug 1819074] Re: Keepalived < 2.0.x in Ubuntu 18.04 LTS not compatible with systemd-networkd

2019-06-19 Thread Bryce Harrington
Given SRU and backport team policies, having a newer version of
keepalived in bionic seems pretty unlikely.  SRU policy favors backports
of specific fixes rather than entire package backports, while the
backports team generally discourages backports of libraries or services
since they can randomly break other software using them.

So, the most practical route forward would be to identify the patch(es)
needed for fixing the particular issue at hand, and go through the
regular SRU process.  I am, unfortunately, completely unfamiliar with
keepalived, but attached is a list of upstream comments mentioning "VIP"
since the v.1.3.9 release, which I generated like this:

git log --grep="VIP" v1.3.9.. > /tmp/vip_commits.txt

The next step would be for someone more familiar than me, to review the
list and identify 1 or 2 patches worth testing.  Then apply the patch to
the bionic keepalived package and test for a fix.  After we know what
patch is needed, an SRU request can be placed to have it released for
all users.

** Attachment added: "vip_commits.txt"
   
https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/1819074/+attachment/5271627/+files/vip_commits.txt

** Changed in: keepalived (Ubuntu)
   Status: Confirmed => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1819074

Title:
  Keepalived < 2.0.x in Ubuntu 18.04 LTS  not compatible with systemd-
  networkd

Status in keepalived package in Ubuntu:
  Triaged
Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in keepalived source package in Bionic:
  New
Status in netplan.io source package in Bionic:
  New
Status in systemd source package in Bionic:
  New
Status in keepalived source package in Cosmic:
  New
Status in netplan.io source package in Cosmic:
  New
Status in systemd source package in Cosmic:
  New

Bug description:
  Systemd-networkd clobbers VIPs placed by other daemons on any
  reconfiguration triggering systemd-networkd restart (netplan apply for
  example).  Keepalived < version 2.0.x will not restore a VIP lost in
  this fashion, breaking high availability on Ubuntu 18.04 LTS.  A
  backport for keepalived >= 2.0.x should fix the issue.

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

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


[Touch-packages] [Bug 1819074] Re: Keepalived < 2.0.x in Ubuntu 18.04 LTS not compatible with systemd-networkd

2019-06-19 Thread Bryce Harrington
Oh, one other thing that will be necessary to file an SRU for this would
be a a series of "paint by number" steps to reproduce the issue, and to
verify the fix.  For example, something akin to:
https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/1810583/comments/12


** Also affects: keepalived (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Also affects: netplan.io (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

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

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

** Also affects: netplan.io (Ubuntu Bionic)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1819074

Title:
  Keepalived < 2.0.x in Ubuntu 18.04 LTS  not compatible with systemd-
  networkd

Status in keepalived package in Ubuntu:
  Triaged
Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in keepalived source package in Bionic:
  New
Status in netplan.io source package in Bionic:
  New
Status in systemd source package in Bionic:
  New
Status in keepalived source package in Cosmic:
  New
Status in netplan.io source package in Cosmic:
  New
Status in systemd source package in Cosmic:
  New

Bug description:
  Systemd-networkd clobbers VIPs placed by other daemons on any
  reconfiguration triggering systemd-networkd restart (netplan apply for
  example).  Keepalived < version 2.0.x will not restore a VIP lost in
  this fashion, breaking high availability on Ubuntu 18.04 LTS.  A
  backport for keepalived >= 2.0.x should fix the issue.

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

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


[Touch-packages] [Bug 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait

2019-06-11 Thread Bryce Harrington
Fixes have been pushed to cosmic-proposed and bionic-proposed.

** Summary changed:

- Apply Bash 4.4.20 to fix cpu spinning on built-in wait
+ [SRU] Apply Bash 4.4.20 to fix cpu spinning on built-in wait

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bash in Ubuntu.
https://bugs.launchpad.net/bugs/1822776

Title:
  [SRU] Apply Bash 4.4.20 to fix cpu spinning on built-in wait

Status in bash package in Ubuntu:
  Fix Released
Status in bash source package in Bionic:
  In Progress
Status in bash source package in Cosmic:
  In Progress

Bug description:
  [Impact]

  Long running bash loops that create and reap processes will crash,
  hanging at 100% CPU.

  [Test Case]

  A PPA with the proposed fix included is at:

https://launchpad.net/~bryce/+archive/ubuntu/bash-sru-19-010-1

  Install the PPA with the fix via:

sudo add-apt-repository ppa:bryce/bash-sru-19-010-1
sudo apt-get update
sudo apt-get install bash

  Run this loop for a few days/weeks:

    #!/bin/bash
    while true; do
  sleep 0.5 &
  wait
    done

  It will eventually cause the 'wait' statement to hang, consuming 100%
  after some indeterminate amount of time, dependent on how fast PIDs
  are cycled in the machine.

  The Bash bug report mentions longer running loops, but it seems hash
  collisions are the cause, meaning it's just a matter of chance,
  influenced by how fast PIDs are cycled on the machine.

  [Regression Potential]

  The fix has been reviewed and accepted upstream.  The patch adds a
  test at time of pid determination for if the pid is already in use and
  if so, skip it and pick a different one.  This does change behavior
  slightly in that different pid numbers will be generated in rare
  cases, but nothing should depend on how pids are generated, as the
  behavior is not specified to be anything but random.

  The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) ==
  storage[psi].bucket_next", but this only shows when the original bug
  would have been triggered.

  Using 'apt-get source bash' to get the original source version, I
  created a deb that includes the 4.4.20 patch and have been running it
  since April 2nd. The 100% CPU spinning is solved, and no other
  regressions have been observed.

  Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so
  this involves linearly progressing to the next version (so not
  skipping patches).

  [Fix]

  Official patch to fix, and to bump to 4.4.20:

  http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020

  The newest Ubuntu tar.xz with patches I could find at:

  http://archive.ubuntu.com/ubuntu/pool/main/b/bash/

  also didn't have the 4.4.20 patch, so it seems no Ubuntu release has
  the fix yet.

  Although not completely sure, this problem seems to have been
  introduced in the 4.4 version of Bash, so in term of LTS versions,
  18.04 and up are affected.

  [Original Report]
  Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when 
spawning sub processes and waiting for them. There is a fix:

  https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020

  Our application started being affected (locking up) by this since
  migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1),
  Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version',
  because of their unusual versions as patches, apt shows it as
  4.4.18-2ubuntu1).

  The 4.4-020 version needs to be included. I think it's actually quite
  critical.

  A justification for including the fix would be that a standard
  language feature in a script language is broken, and that it's
  indeterminate when it breaks. Considering the wide spread use of bash,
  I'm surprised not more people have reported issues. My and a client
  started having issues with independently of each other very soon after
  upgrading to an affected version.

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

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


[Touch-packages] [Bug 1531184] Re: [SRU] dnsmasq doesn't start on boot because its interface isn't up yet

2019-06-07 Thread Bryce Harrington
** Description changed:

  [Impact]
  TBD
  
  [Test Case]
  TBD
  
  [Regression Potential]
+ The fix is just configuring the order of service startup, so is unlikely to 
create any regressions.  Things to watch would be service related misbehaviors 
and general availability of the dnsmasq functionality.
  
  [Fix]
+ 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=774970;filename=774970-network-online.debdiff;msg=22
  
  [Discussion]
  
  [Original Report]
- 
- My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0 is
- managed manually in /etc/network/interfaces.
+ My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0 is 
managed manually in /etc/network/interfaces.
  
  During boot, dnsmasq is started before br-vz0 is created and this causes
  dnsmasq to exit:
  
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: dnsmasq: unknown interface br-vz0
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: unknown interface br-vz0
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: FAILED to start up
  Jan  5 08:56:17 simon-laptop NetworkManager[937]:   NetworkManager 
(version 1.0.4) is starting...
  ...
  Jan  5 08:56:18 simon-laptop NetworkManager[937]: 
interface-parser: parsing file /etc/network/interfaces
  ...
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   found bridge ports 
none for br-vz0
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   adding bridge port 
none to eni_ifaces
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   management mode: 
unmanaged
  
  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: dnsmasq 2.75-1
  ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3
  Uname: Linux 4.3.0-5-generic x86_64
  ApportVersion: 2.19.3-0ubuntu2
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Jan  5 09:53:30 2016
  PackageArchitecture: all
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1531184

Title:
  [SRU] dnsmasq doesn't start on boot because its interface isn't up yet

Status in One Hundred Papercuts:
  Confirmed
Status in dnsmasq package in Ubuntu:
  Confirmed
Status in dnsmasq package in Debian:
  New

Bug description:
  [Impact]
  TBD

  [Test Case]
  TBD

  [Regression Potential]
  The fix is just configuring the order of service startup, so is unlikely to 
create any regressions.  Things to watch would be service related misbehaviors 
and general availability of the dnsmasq functionality.

  [Fix]
  
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=774970;filename=774970-network-online.debdiff;msg=22

  [Discussion]

  [Original Report]
  My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0 is 
managed manually in /etc/network/interfaces.

  During boot, dnsmasq is started before br-vz0 is created and this
  causes dnsmasq to exit:

  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: dnsmasq: unknown interface br-vz0
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: unknown interface br-vz0
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: FAILED to start up
  Jan  5 08:56:17 simon-laptop NetworkManager[937]:   NetworkManager 
(version 1.0.4) is starting...
  ...
  Jan  5 08:56:18 simon-laptop NetworkManager[937]: 
interface-parser: parsing file /etc/network/interfaces
  ...
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   found bridge ports 
none for br-vz0
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   adding bridge port 
none to eni_ifaces
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   management mode: 
unmanaged

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: dnsmasq 2.75-1
  ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3
  Uname: Linux 4.3.0-5-generic x86_64
  ApportVersion: 2.19.3-0ubuntu2
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Jan  5 09:53:30 2016
  PackageArchitecture: all
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1531184] Re: [SRU] dnsmasq doesn't start on boot because its interface isn't up yet

2019-06-07 Thread Bryce Harrington
** Description changed:

+ [Impact]
+ TBD
+ 
+ [Test Case]
+ TBD
+ 
+ [Regression Potential]
+ 
+ [Fix]
+ 
+ [Discussion]
+ 
+ [Original Report]
+ 
  My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0 is
  managed manually in /etc/network/interfaces.
  
  During boot, dnsmasq is started before br-vz0 is created and this causes
  dnsmasq to exit:
  
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: dnsmasq: unknown interface br-vz0
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: unknown interface br-vz0
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: FAILED to start up
  Jan  5 08:56:17 simon-laptop NetworkManager[937]:   NetworkManager 
(version 1.0.4) is starting...
  ...
  Jan  5 08:56:18 simon-laptop NetworkManager[937]: 
interface-parser: parsing file /etc/network/interfaces
  ...
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   found bridge ports 
none for br-vz0
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   adding bridge port 
none to eni_ifaces
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   management mode: 
unmanaged
  
  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: dnsmasq 2.75-1
  ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3
  Uname: Linux 4.3.0-5-generic x86_64
  ApportVersion: 2.19.3-0ubuntu2
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Jan  5 09:53:30 2016
  PackageArchitecture: all
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1531184

Title:
  [SRU] dnsmasq doesn't start on boot because its interface isn't up yet

Status in One Hundred Papercuts:
  Confirmed
Status in dnsmasq package in Ubuntu:
  Confirmed
Status in dnsmasq package in Debian:
  New

Bug description:
  [Impact]
  TBD

  [Test Case]
  TBD

  [Regression Potential]
  The fix is just configuring the order of service startup, so is unlikely to 
create any regressions.  Things to watch would be service related misbehaviors 
and general availability of the dnsmasq functionality.

  [Fix]
  
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=774970;filename=774970-network-online.debdiff;msg=22

  [Discussion]

  [Original Report]
  My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0 is 
managed manually in /etc/network/interfaces.

  During boot, dnsmasq is started before br-vz0 is created and this
  causes dnsmasq to exit:

  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: dnsmasq: unknown interface br-vz0
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: unknown interface br-vz0
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: FAILED to start up
  Jan  5 08:56:17 simon-laptop NetworkManager[937]:   NetworkManager 
(version 1.0.4) is starting...
  ...
  Jan  5 08:56:18 simon-laptop NetworkManager[937]: 
interface-parser: parsing file /etc/network/interfaces
  ...
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   found bridge ports 
none for br-vz0
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   adding bridge port 
none to eni_ifaces
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   management mode: 
unmanaged

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: dnsmasq 2.75-1
  ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3
  Uname: Linux 4.3.0-5-generic x86_64
  ApportVersion: 2.19.3-0ubuntu2
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Jan  5 09:53:30 2016
  PackageArchitecture: all
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1531184] Re: [SRU] dnsmasq doesn't start on boot because its interface isn't up yet

2019-06-07 Thread Bryce Harrington
** Summary changed:

- dnsmasq doesn't start on boot because its interface isn't up yet
+ [SRU] dnsmasq doesn't start on boot because its interface isn't up yet

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1531184

Title:
  [SRU] dnsmasq doesn't start on boot because its interface isn't up yet

Status in One Hundred Papercuts:
  Confirmed
Status in dnsmasq package in Ubuntu:
  Confirmed
Status in dnsmasq package in Debian:
  New

Bug description:
  My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0
  is managed manually in /etc/network/interfaces.

  During boot, dnsmasq is started before br-vz0 is created and this
  causes dnsmasq to exit:

  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: dnsmasq: unknown interface br-vz0
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: unknown interface br-vz0
  Jan  5 08:56:16 simon-laptop dnsmasq[1008]: FAILED to start up
  Jan  5 08:56:17 simon-laptop NetworkManager[937]:   NetworkManager 
(version 1.0.4) is starting...
  ...
  Jan  5 08:56:18 simon-laptop NetworkManager[937]: 
interface-parser: parsing file /etc/network/interfaces
  ...
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   found bridge ports 
none for br-vz0
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   adding bridge port 
none to eni_ifaces
  Jan  5 08:56:18 simon-laptop NetworkManager[937]:   management mode: 
unmanaged

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: dnsmasq 2.75-1
  ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3
  Uname: Linux 4.3.0-5-generic x86_64
  ApportVersion: 2.19.3-0ubuntu2
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Tue Jan  5 09:53:30 2016
  PackageArchitecture: all
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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


[Touch-packages] [Bug 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait

2019-06-07 Thread Bryce Harrington
** Description changed:

  [Impact]
  
  Long running bash loops that create and reap processes will crash,
  hanging at 100% CPU.
  
+ [Test Case]
  
- [Test Case]
+ A PPA with the proposed fix included is at:
+ 
+   https://launchpad.net/~bryce/+archive/ubuntu/bash-sru-19-010-1
+ 
+ Install the PPA with the fix via:
+ 
+   sudo add-apt-repository ppa:bryce/bash-sru-19-010-1
+   sudo apt-get update
+   sudo apt-get install bash
  
  Run this loop for a few days/weeks:
  
    #!/bin/bash
    while true; do
  sleep 0.5 &
  wait
    done
  
  It will eventually cause the 'wait' statement to hang, consuming 100%
  after some indeterminate amount of time, dependent on how fast PIDs are
  cycled in the machine.
  
  The Bash bug report mentions longer running loops, but it seems hash
  collisions are the cause, meaning it's just a matter of chance,
  influenced by how fast PIDs are cycled on the machine.
- 
  
  [Regression Potential]
  
  The fix has been reviewed and accepted upstream.  The patch adds a test
  at time of pid determination for if the pid is already in use and if so,
  skip it and pick a different one.  This does change behavior slightly in
  that different pid numbers will be generated in rare cases, but nothing
  should depend on how pids are generated, as the behavior is not
  specified to be anything but random.
  
  The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) ==
  storage[psi].bucket_next", but this only shows when the original bug
  would have been triggered.
  
  Using 'apt-get source bash' to get the original source version, I
  created a deb that includes the 4.4.20 patch and have been running it
  since April 2nd. The 100% CPU spinning is solved, and no other
  regressions have been observed.
  
  Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so
  this involves linearly progressing to the next version (so not skipping
  patches).
  
- 
  [Fix]
  
  Official patch to fix, and to bump to 4.4.20:
  
  http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020
  
  The newest Ubuntu tar.xz with patches I could find at:
  
  http://archive.ubuntu.com/ubuntu/pool/main/b/bash/
  
  also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the
  fix yet.
  
  Although not completely sure, this problem seems to have been introduced
  in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are
  affected.
- 
  
  [Original Report]
  Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when 
spawning sub processes and waiting for them. There is a fix:
  
  https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020
  
  Our application started being affected (locking up) by this since
  migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1),
  Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version',
  because of their unusual versions as patches, apt shows it as
  4.4.18-2ubuntu1).
  
  The 4.4-020 version needs to be included. I think it's actually quite
  critical.
  
  A justification for including the fix would be that a standard language
  feature in a script language is broken, and that it's indeterminate when
  it breaks. Considering the wide spread use of bash, I'm surprised not
  more people have reported issues. My and a client started having issues
  with independently of each other very soon after upgrading to an
  affected version.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bash in Ubuntu.
https://bugs.launchpad.net/bugs/1822776

Title:
  Apply Bash 4.4.20 to fix cpu spinning on built-in wait

Status in bash package in Ubuntu:
  Fix Released
Status in bash source package in Bionic:
  In Progress
Status in bash source package in Cosmic:
  In Progress

Bug description:
  [Impact]

  Long running bash loops that create and reap processes will crash,
  hanging at 100% CPU.

  [Test Case]

  A PPA with the proposed fix included is at:

https://launchpad.net/~bryce/+archive/ubuntu/bash-sru-19-010-1

  Install the PPA with the fix via:

sudo add-apt-repository ppa:bryce/bash-sru-19-010-1
sudo apt-get update
sudo apt-get install bash

  Run this loop for a few days/weeks:

    #!/bin/bash
    while true; do
  sleep 0.5 &
  wait
    done

  It will eventually cause the 'wait' statement to hang, consuming 100%
  after some indeterminate amount of time, dependent on how fast PIDs
  are cycled in the machine.

  The Bash bug report mentions longer running loops, but it seems hash
  collisions are the cause, meaning it's just a matter of chance,
  influenced by how fast PIDs are cycled on the machine.

  [Regression Potential]

  The fix has been reviewed and accepted upstream.  The patch adds a
  test at time of pid determination for if the pid is already in use and
  if so, skip it and pick a different one.  This does change behavior
  slightly in that different pid numbers will 

[Touch-packages] [Bug 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait

2019-06-06 Thread Bryce Harrington
** Changed in: bash (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: bash (Ubuntu Cosmic)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bash in Ubuntu.
https://bugs.launchpad.net/bugs/1822776

Title:
  Apply Bash 4.4.20 to fix cpu spinning on built-in wait

Status in bash package in Ubuntu:
  Fix Released
Status in bash source package in Bionic:
  In Progress
Status in bash source package in Cosmic:
  In Progress

Bug description:
  [Impact]

  Long running bash loops that create and reap processes will crash,
  hanging at 100% CPU.

  
  [Test Case]

  Run this loop for a few days/weeks:

    #!/bin/bash
    while true; do
  sleep 0.5 &
  wait
    done

  It will eventually cause the 'wait' statement to hang, consuming 100%
  after some indeterminate amount of time, dependent on how fast PIDs
  are cycled in the machine.

  The Bash bug report mentions longer running loops, but it seems hash
  collisions are the cause, meaning it's just a matter of chance,
  influenced by how fast PIDs are cycled on the machine.

  
  [Regression Potential]

  The fix has been reviewed and accepted upstream.  The patch adds a
  test at time of pid determination for if the pid is already in use and
  if so, skip it and pick a different one.  This does change behavior
  slightly in that different pid numbers will be generated in rare
  cases, but nothing should depend on how pids are generated, as the
  behavior is not specified to be anything but random.

  The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) ==
  storage[psi].bucket_next", but this only shows when the original bug
  would have been triggered.

  Using 'apt-get source bash' to get the original source version, I
  created a deb that includes the 4.4.20 patch and have been running it
  since April 2nd. The 100% CPU spinning is solved, and no other
  regressions have been observed.

  Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so
  this involves linearly progressing to the next version (so not
  skipping patches).

  
  [Fix]

  Official patch to fix, and to bump to 4.4.20:

  http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020

  The newest Ubuntu tar.xz with patches I could find at:

  http://archive.ubuntu.com/ubuntu/pool/main/b/bash/

  also didn't have the 4.4.20 patch, so it seems no Ubuntu release has
  the fix yet.

  Although not completely sure, this problem seems to have been
  introduced in the 4.4 version of Bash, so in term of LTS versions,
  18.04 and up are affected.

  
  [Original Report]
  Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when 
spawning sub processes and waiting for them. There is a fix:

  https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020

  Our application started being affected (locking up) by this since
  migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1),
  Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version',
  because of their unusual versions as patches, apt shows it as
  4.4.18-2ubuntu1).

  The 4.4-020 version needs to be included. I think it's actually quite
  critical.

  A justification for including the fix would be that a standard
  language feature in a script language is broken, and that it's
  indeterminate when it breaks. Considering the wide spread use of bash,
  I'm surprised not more people have reported issues. My and a client
  started having issues with independently of each other very soon after
  upgrading to an affected version.

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

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


[Touch-packages] [Bug 1830121] Re: rsync --rsync-path="sudo rsync" over ssh via pki fails due to protocol mismatch

2019-06-05 Thread Bryce Harrington
Hi Gareth, thanks for following up, and glad to hear you've sorted the
trouble out!

** Changed in: rsync (Ubuntu)
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1830121

Title:
  rsync --rsync-path="sudo rsync" over ssh via pki fails due to protocol
  mismatch

Status in Ubuntu MATE:
  Invalid
Status in rsync package in Ubuntu:
  Invalid

Bug description:
  rsync with remote sudo fails over ssh on Ubuntu Mate 18.04.2

  rsync  version 3.1.2  protocol version 31 - same on local and remote
  OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017 - same on local 
and remote

  
  I have checked for spurious output from .bashrc using

  $ ssh user@host /bin/true > out.dat

  which results in

  $ ls -l *.dat
  -rw-rw-r-- 1 user user 0 May 22 23:33 out.dat

  
  -- The [redacted] command is

  rsync -AEavvvogt --rsync-path="sudo rsync" --debug=CONNECT -e "ssh -i
  /home/xxx/.ssh/id_rsa -tt -v -o StrictHostKeyChecking=no -o
  UserKnownHostsFile=/dev/null" --exclude-from=/home/xxx/backup.exclude
  --delete --link-dest=../$lastdt /etc $dest/$dt;

  
  -- The [redacted] output is

  opening connection using: ssh -i /home/user/.ssh/id_rsa -tt -v -o 
StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -l user xxx "sudo 
rsync" --server -vvvlogDtpAre.iLsfxC --delete --link-dest ../20190506_021137 . 
/home/backups/xxx/20190522_232738  (20 args)
  OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 19: Applying options for *
  debug1: Connecting to xxx [192.168.1.120] port 22.
  debug1: Connection established.
  debug1: permanently_set_uid: 0/0
  debug1: identity file /home/user/.ssh/id_rsa type 0
  debug1: key_load_public: No such file or directory
  debug1: identity file /home/user/.ssh/id_rsa-cert type -1
  debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
  debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 
Ubuntu-4ubuntu0.3
  debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 pat OpenSSH* compat 0x0400
  debug1: Authenticating to xxx:22 as 'user'
  debug1: SSH2_MSG_KEXINIT sent
  debug1: SSH2_MSG_KEXINIT received
  debug1: kex: algorithm: curve25519-sha256
  debug1: kex: host key algorithm: ecdsa-sha2-nistp256
  debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
  debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
  debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
  debug1: Server host key: xxx
  Warning: Permanently added 'xxx,192.168.1.120' (ECDSA) to the list of known 
hosts.
  debug1: rekey after 134217728 blocks
  debug1: SSH2_MSG_NEWKEYS sent
  debug1: expecting SSH2_MSG_NEWKEYS
  debug1: SSH2_MSG_NEWKEYS received
  debug1: rekey after 134217728 blocks
  debug1: SSH2_MSG_EXT_INFO received
  debug1: kex_input_ext_info: 
server-sig-algs=
  debug1: SSH2_MSG_SERVICE_ACCEPT received
  debug1: Authentications that can continue: publickey,password
  debug1: Next authentication method: publickey
  debug1: Offering public key: RSA SHA256:xxx /home/user/.ssh/id_rsa
  debug1: Server accepts key: xxx
  debug1: Authentication succeeded (publickey).
  Authenticated to xxx ([192.168.1.120]:22).
  debug1: channel 0: new [client-session]
  debug1: Requesting no-more-sessi...@openssh.com
  debug1: Entering interactive session.
  debug1: pledge: network
  debug1: client_input_global_request: rtype hostkeys...@openssh.com want_reply 0
  debug1: tty_make_modes: no fd or tio
  debug1: Sending environment.
  debug1: Sending env LANG = en_GB.UTF-8
  debug1: Sending command: sudo rsync --server -vvvlogDtpAre.iLsfxC --delete 
--link-dest ../20190506_021137 . /home/backups/xxx/20190522_232738
  protocol version mismatch -- is your shell clean?
  (see the rsync man page for an explanation)
  rsync error: protocol incompatibility (code 2) at compat.c(178) [sender=3.1.2]
  [sender] _exit_cleanup(code=2, file=compat.c, line=178): about to call exit(2)

  
  /etc/sudoers contains
  userALL= NOPASSWD:/usr/bin/rsync

  ...which I have tried placing above (as is the default) and below lines 
beginning %admin and %sudo
  and the space in "ALL= NOPASSWD..." doesn't seem to make any difference

  I followed the instructions at
  
https://www.digitalocean.com/community/tutorials/how-to-copy-files-with-rsync-over-ssh
  
https://askubuntu.com/questions/719439/using-rsync-with-sudo-on-the-destination-machine

  - which worked on 16.04, so I wonder if there may be a bug, although
  grateful for any other suggestions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-mate/+bug/1830121/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : 

[Touch-packages] [Bug 1778073] Re: dnsmasq and resolvconf hangs on start

2019-06-03 Thread Bryce Harrington
Hi Thomas, have you had a chance to re-test this on 18.04?  From
Christian's comment #3, sounds like this issue may already be resolved,
but if not we can investigate further.

** Changed in: dnsmasq (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1778073

Title:
  dnsmasq and resolvconf hangs on start

Status in dnsmasq package in Ubuntu:
  Incomplete
Status in dnsmasq package in Debian:
  New

Bug description:
  I installed today dnsmasq and I use resolvconf in background.

  Problem is, that systemd takes 1 minute or so after service start and
  than reports:

  root@proxy:~# service dnsmasq status

   dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor 
preset: enabled)
    Drop-In: /run/systemd/generator/dnsmasq.service.d
     50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf
     Active: failed (Result: timeout) since Do 2018-06-21 15:58:13 CEST; 2min 
10s ago
    Process: 3295 ExecStop=/etc/init.d/dnsmasq systemd-stop-resolvconf 
(code=killed, signal=TERM)
    Process: 3865 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf 
(code=killed, signal=TERM)
    Process: 3837 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, 
status=0/SUCCESS)
    Process: 3825 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, 
status=0/SUCCESS)
   Main PID: 3862 (code=exited, status=0/SUCCESS)

  Jun 21 15:56:43 proxy dnsmasq[3862]: Benutze Namensserver 192.168.23.1#53
  Jun 21 15:56:43 proxy dnsmasq[3865]:  * Awakening mail retriever agent:
  Jun 21 15:56:43 proxy dnsmasq[3865]:...done.
  Jun 21 15:56:43 proxy postfix[3951]: Postfix is running with 
backwards-compatible default settings
  Jun 21 15:56:43 proxy postfix[3951]: See 
http://www.postfix.org/COMPATIBILITY_README.html for details
  Jun 21 15:56:43 proxy postfix[3951]: To disable backwards compatibility use 
"postconf compatibility_level=2" and "postfix reload"
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Start-post operation timed 
out. Stopping.
  Jun 21 15:58:13 proxy systemd[1]: Failed to start dnsmasq - A lightweight 
DHCP and caching DNS server.
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Unit entered failed state.
  Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Failed with result 
'timeout'.

  when I look into the start script /etc/init.d/dnsmasq there is a func
  systemd-start-resolvconf which points to start-resolvconf.

  There is this part:

  for interface in $DNSMASQ_EXCEPT
  do
  [ $interface = lo ] && return
  done

  Before I had not defined DNSMASQ_EXCEPT in /etc/defaults/dnsmasq.
  Problem is, that this part MUST be faulty! When I commend it out, I
  can start dnsmasq! It looks like it loops forever there?!

  Also if I define DNSMASQ_EXCEPT to my listen interface, it works - but
  is is really needed?

  I found a other user which had the same problem:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871958

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: dnsmasq 2.75-1ubuntu0.16.04.4 [modified: etc/default/dnsmasq]
  ProcVersionSignature: Ubuntu 4.15.0-23.25~16.04.1-generic 4.15.18
  Uname: Linux 4.15.0-23-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  Date: Thu Jun 21 16:12:14 2018
  InstallationDate: Installed on 2017-02-27 (479 days ago)
  InstallationMedia: Ubuntu-Server 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.8)
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm
   SHELL=/bin/bash
   PATH=(custom, no user)
   LANG=de_DE.UTF-8
  SourcePackage: dnsmasq
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.default.dnsmasq: 2018-06-21T16:07:24.818774

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

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


[Touch-packages] [Bug 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait

2019-05-30 Thread Bryce Harrington
** Changed in: bash (Ubuntu Cosmic)
   Importance: Undecided => High

** Changed in: bash (Ubuntu Cosmic)
 Assignee: (unassigned) => Bryce Harrington (bryce)

** Changed in: bash (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bash in Ubuntu.
https://bugs.launchpad.net/bugs/1822776

Title:
  Apply Bash 4.4.20 to fix cpu spinning on built-in wait

Status in bash package in Ubuntu:
  Fix Released
Status in bash source package in Bionic:
  New
Status in bash source package in Cosmic:
  New

Bug description:
  [Impact]

  Long running bash loops that create and reap processes will crash,
  hanging at 100% CPU.

  
  [Test Case]

  Run this loop for a few days/weeks:

    #!/bin/bash
    while true; do
  sleep 0.5 &
  wait
    done

  It will eventually cause the 'wait' statement to hang, consuming 100%
  after some indeterminate amount of time, dependent on how fast PIDs
  are cycled in the machine.

  The Bash bug report mentions longer running loops, but it seems hash
  collisions are the cause, meaning it's just a matter of chance,
  influenced by how fast PIDs are cycled on the machine.

  
  [Regression Potential]

  The fix has been reviewed and accepted upstream.  The patch adds a
  test at time of pid determination for if the pid is already in use and
  if so, skip it and pick a different one.  This does change behavior
  slightly in that different pid numbers will be generated in rare
  cases, but nothing should depend on how pids are generated, as the
  behavior is not specified to be anything but random.

  The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) ==
  storage[psi].bucket_next", but this only shows when the original bug
  would have been triggered.

  Using 'apt-get source bash' to get the original source version, I
  created a deb that includes the 4.4.20 patch and have been running it
  since April 2nd. The 100% CPU spinning is solved, and no other
  regressions have been observed.

  Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so
  this involves linearly progressing to the next version (so not
  skipping patches).

  
  [Fix]

  Official patch to fix, and to bump to 4.4.20:

  http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020

  The newest Ubuntu tar.xz with patches I could find at:

  http://archive.ubuntu.com/ubuntu/pool/main/b/bash/

  also didn't have the 4.4.20 patch, so it seems no Ubuntu release has
  the fix yet.

  Although not completely sure, this problem seems to have been
  introduced in the 4.4 version of Bash, so in term of LTS versions,
  18.04 and up are affected.

  
  [Original Report]
  Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when 
spawning sub processes and waiting for them. There is a fix:

  https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020

  Our application started being affected (locking up) by this since
  migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1),
  Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version',
  because of their unusual versions as patches, apt shows it as
  4.4.18-2ubuntu1).

  The 4.4-020 version needs to be included. I think it's actually quite
  critical.

  A justification for including the fix would be that a standard
  language feature in a script language is broken, and that it's
  indeterminate when it breaks. Considering the wide spread use of bash,
  I'm surprised not more people have reported issues. My and a client
  started having issues with independently of each other very soon after
  upgrading to an affected version.

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

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


[Touch-packages] [Bug 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait

2019-05-29 Thread Bryce Harrington
Hi halfgaar,

Robie asked me to help you with this bug, thanks for reporting it.  I
may not be able to get full attention on this until next week due to a
project deadline, but I've had a quick look at the patch and your
problem description, and it looks pretty straightforward.  Thanks also
for the test case, I'll run it and see if I can repro the bug myself.

It looks like both bionic and cosmic are running 4.4.18-x, so I'm
gathering cosmic will need the fix as well.  disco and eoan have moved
to bash 5.0, and I've verified the upstream source code includes the
fix, so no changes are needed for those distro releases.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bash in Ubuntu.
https://bugs.launchpad.net/bugs/1822776

Title:
  Apply Bash 4.4.20 to fix cpu spinning on built-in wait

Status in bash package in Ubuntu:
  New
Status in bash source package in Bionic:
  New
Status in bash source package in Cosmic:
  New

Bug description:
  [Impact]

  Long running bash loops that create and reap processes will crash,
  hanging at 100% CPU.

  
  [Test Case]

  Run this loop for a few days/weeks:

    #!/bin/bash
    while true; do
  sleep 0.5 &
  wait
    done

  It will eventually cause the 'wait' statement to hang, consuming 100%
  after some indeterminate amount of time, dependent on how fast PIDs
  are cycled in the machine.

  The Bash bug report mentions longer running loops, but it seems hash
  collisions are the cause, meaning it's just a matter of chance,
  influenced by how fast PIDs are cycled on the machine.

  
  [Regression Potential]

  The fix has been reviewed and accepted upstream.  The patch adds a
  test at time of pid determination for if the pid is already in use and
  if so, skip it and pick a different one.  This does change behavior
  slightly in that different pid numbers will be generated in rare
  cases, but nothing should depend on how pids are generated, as the
  behavior is not specified to be anything but random.

  The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) ==
  storage[psi].bucket_next", but this only shows when the original bug
  would have been triggered.

  Using 'apt-get source bash' to get the original source version, I
  created a deb that includes the 4.4.20 patch and have been running it
  since April 2nd. The 100% CPU spinning is solved, and no other
  regressions have been observed.

  Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so
  this involves linearly progressing to the next version (so not
  skipping patches).

  
  [Fix]

  Official patch to fix, and to bump to 4.4.20:

  http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020

  The newest Ubuntu tar.xz with patches I could find at:

  http://archive.ubuntu.com/ubuntu/pool/main/b/bash/

  also didn't have the 4.4.20 patch, so it seems no Ubuntu release has
  the fix yet.

  Although not completely sure, this problem seems to have been
  introduced in the 4.4 version of Bash, so in term of LTS versions,
  18.04 and up are affected.

  
  [Original Report]
  Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when 
spawning sub processes and waiting for them. There is a fix:

  https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020

  Our application started being affected (locking up) by this since
  migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1),
  Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version',
  because of their unusual versions as patches, apt shows it as
  4.4.18-2ubuntu1).

  The 4.4-020 version needs to be included. I think it's actually quite
  critical.

  A justification for including the fix would be that a standard
  language feature in a script language is broken, and that it's
  indeterminate when it breaks. Considering the wide spread use of bash,
  I'm surprised not more people have reported issues. My and a client
  started having issues with independently of each other very soon after
  upgrading to an affected version.

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

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


[Touch-packages] [Bug 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait

2019-05-29 Thread Bryce Harrington
** Description changed:

- Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops
- when spawning sub processes and waiting for them. There is a fix:
+ [Impact]
  
- https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020
+ Long running bash loops that create and reap processes will crash,
+ hanging at 100% CPU.
  
- Our application started being affected (locking up) by this since
- migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1),
- Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version',
- because of their unusual versions as patches, apt shows it as
- 4.4.18-2ubuntu1).
  
- The 4.4-020 version needs to be included. I think it's actually quite
- critical.
+ [Test Case]
+ 
+ Run this loop for a few days/weeks:
+ 
+   #!/bin/bash
+   while true; do
+ sleep 0.5 &
+ wait
+   done
+ 
+ It will eventually cause the 'wait' statement to hang, consuming 100%
+ after some indeterminate amount of time, dependent on how fast PIDs are
+ cycled in the machine.
  
  The Bash bug report mentions longer running loops, but it seems hash
  collisions are the cause, meaning it's just a matter of chance,
  influenced by how fast PIDs are cycled on the machine.
  
- Edit as per the SRU procedure:
  
-[Impact]
+ [Regression Potential]
  
- Long running bash loops that create and reap processes will crash,
- hanging at 100% CPU.
+ The fix has been reviewed and accepted upstream.  The patch adds a test
+ at time of pid determination for if the pid is already in use and if so,
+ skip it and pick a different one.  This does change behavior slightly in
+ that different pid numbers will be generated in rare cases, but nothing
+ should depend on how pids are generated, as the behavior is not
+ specified to be anything but random.
  
- A justification for including the fix would be that a standard language
- feature in a script language is broken, and that it's indeterminate when
- it breaks. Considering the wide spread use of bash, I'm surprised not
- more people have reported issues. My and a client started having issues
- with independently of each other very soon after upgrading to an
- affected version.
- 
-[Test Case]
- 
- Run this loop for a few days/weeks:
- 
-   #!/bin/bash
-   while true; do
- sleep 0.5 &
- wait
-   done
- 
- 
- It will cause the 'wait' statement to hang, consuming 100% after some 
indeterminate amount of time, dependent on how fast PIDs are cycled in the 
machine.
- 
-[Regression Potential]
+ The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) ==
+ storage[psi].bucket_next", but this only shows when the original bug
+ would have been triggered.
  
  Using 'apt-get source bash' to get the original source version, I
  created a deb that includes the 4.4.20 patch and have been running it
  since April 2nd. The 100% CPU spinning is solved, and no other
  regressions have been observed.
  
  Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so
  this involves linearly progressing to the next version (so not skipping
  patches).
  
-[Other Info]
+ 
+ [Fix]
  
  Official patch to fix, and to bump to 4.4.20:
  
  http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020
  
  The newest Ubuntu tar.xz with patches I could find at:
  
  http://archive.ubuntu.com/ubuntu/pool/main/b/bash/
  
  also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the
  fix yet.
  
  Although not completely sure, this problem seems to have been introduced
  in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are
  affected.
+ 
+ 
+ [Original Report]
+ Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when 
spawning sub processes and waiting for them. There is a fix:
+ 
+ https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020
+ 
+ Our application started being affected (locking up) by this since
+ migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1),
+ Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version',
+ because of their unusual versions as patches, apt shows it as
+ 4.4.18-2ubuntu1).
+ 
+ The 4.4-020 version needs to be included. I think it's actually quite
+ critical.
+ 
+ A justification for including the fix would be that a standard language
+ feature in a script language is broken, and that it's indeterminate when
+ it breaks. Considering the wide spread use of bash, I'm surprised not
+ more people have reported issues. My and a client started having issues
+ with independently of each other very soon after upgrading to an
+ affected version.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bash in Ubuntu.
https://bugs.launchpad.net/bugs/1822776

Title:
  Apply Bash 4.4.20 to fix cpu spinning on built-in wait

Status in bash package in Ubuntu:
  New
Status in bash source package in Bionic:
  New
Status in bash source package in Cosmic:
  New


[Touch-packages] [Bug 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait

2019-05-29 Thread Bryce Harrington
** Also affects: bash (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

** Changed in: bash (Ubuntu Bionic)
 Assignee: (unassigned) => Bryce Harrington (bryce)

** Also affects: bash (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bash in Ubuntu.
https://bugs.launchpad.net/bugs/1822776

Title:
  Apply Bash 4.4.20 to fix cpu spinning on built-in wait

Status in bash package in Ubuntu:
  New
Status in bash source package in Bionic:
  New
Status in bash source package in Cosmic:
  New

Bug description:
  Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops
  when spawning sub processes and waiting for them. There is a fix:

  https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020

  Our application started being affected (locking up) by this since
  migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1),
  Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version',
  because of their unusual versions as patches, apt shows it as
  4.4.18-2ubuntu1).

  The 4.4-020 version needs to be included. I think it's actually quite
  critical.

  The Bash bug report mentions longer running loops, but it seems hash
  collisions are the cause, meaning it's just a matter of chance,
  influenced by how fast PIDs are cycled on the machine.

  Edit as per the SRU procedure:

 [Impact]

  Long running bash loops that create and reap processes will crash,
  hanging at 100% CPU.

  A justification for including the fix would be that a standard
  language feature in a script language is broken, and that it's
  indeterminate when it breaks. Considering the wide spread use of bash,
  I'm surprised not more people have reported issues. My and a client
  started having issues with independently of each other very soon after
  upgrading to an affected version.

 [Test Case]

  Run this loop for a few days/weeks:

#!/bin/bash
while true; do
  sleep 0.5 &
  wait
done

  
  It will cause the 'wait' statement to hang, consuming 100% after some 
indeterminate amount of time, dependent on how fast PIDs are cycled in the 
machine.

 [Regression Potential]

  Using 'apt-get source bash' to get the original source version, I
  created a deb that includes the 4.4.20 patch and have been running it
  since April 2nd. The 100% CPU spinning is solved, and no other
  regressions have been observed.

  Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so
  this involves linearly progressing to the next version (so not
  skipping patches).

 [Other Info]

  Official patch to fix, and to bump to 4.4.20:

  http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020

  The newest Ubuntu tar.xz with patches I could find at:

  http://archive.ubuntu.com/ubuntu/pool/main/b/bash/

  also didn't have the 4.4.20 patch, so it seems no Ubuntu release has
  the fix yet.

  Although not completely sure, this problem seems to have been
  introduced in the 4.4 version of Bash, so in term of LTS versions,
  18.04 and up are affected.

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

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


[Touch-packages] [Bug 1371403] Re: [PATCH] Please disable USB autosuspend for Avocent SC Secure KVM

2016-02-04 Thread Bryce Harrington
** Changed in: systemd (Ubuntu Trusty)
   Status: In Progress => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1371403

Title:
  [PATCH] Please disable USB autosuspend for Avocent SC Secure KVM

Status in systemd package in Ubuntu:
  Invalid
Status in systemd source package in Trusty:
  Confirmed
Status in systemd source package in Utopic:
  Won't Fix

Bug description:
  My mouse becomes temporarily become unresponsive to drags and clicks,
  until I right-click or give keyboard input, when it's been idle for a
  few seconds.  The same thing affects the keyboard.  In some cases the
  mouse cursor jumps back to the center of the screen.

  The mouse and keyboard are connected to a number of different
  computers via an 8-port Avocent SC Secure KVM.  When the mouse and/or
  keyboard are directly attached to one of the PCs, there is no problem.
  I've tested with different keyboards and mice as well, and they're
  similarly messed up.

  Only the computers running Ubuntu 14.04 are affected.  Two of the computers 
are identical hardware, differing only in Ubuntu versions - the 14.04 one is 
affected but the one with 13.04 is not.  I also have a machine with 12.04 on it 
connected to the KVM which is fine.
  I first noticed the problem when I upgraded to 13.10.

  In powertop I notice that autosuspend is enabled for the Avocent.  If
  I switch that off, then the problem disappears completely.  I can also
  prevent it by issuing:

    echo 'on' > '/sys/bus/usb/devices/3-10/power/control';

  where 3-10 is the Avocent (the number is different on each of my
  systems).

  I notice in 42-usb-hid-pm.rules there is a rule for Avocent devices:

    # Catch-all for Avocent HID devices. Keyed off interface in order to only
    # trigger on HID class devices.
    ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624", 
ATTR{bInterfaceClass}=="03", TEST=="../power/control", 
ATTR{../power/control}="auto"

  However my KVM device doesn't appear to have a bInterfaceClass
  defined.

  In any case, the following udev rule corrects the problem for me:

  ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624",
  ATTR{idProduct}=="0013", ATTR{product}=="SC Secure KVM",
  TEST=="power/control", ATTR{power/control}:="on"

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

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


[Touch-packages] [Bug 1371403] Re: [PATCH] Please disable USB autosuspend for Avocent SC Secure KVM

2016-01-25 Thread Bryce Harrington
See #17 for where this is stuck.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1371403

Title:
  [PATCH] Please disable USB autosuspend for Avocent SC Secure KVM

Status in systemd package in Ubuntu:
  Invalid
Status in systemd source package in Trusty:
  In Progress
Status in systemd source package in Utopic:
  Won't Fix

Bug description:
  My mouse becomes temporarily become unresponsive to drags and clicks,
  until I right-click or give keyboard input, when it's been idle for a
  few seconds.  The same thing affects the keyboard.  In some cases the
  mouse cursor jumps back to the center of the screen.

  The mouse and keyboard are connected to a number of different
  computers via an 8-port Avocent SC Secure KVM.  When the mouse and/or
  keyboard are directly attached to one of the PCs, there is no problem.
  I've tested with different keyboards and mice as well, and they're
  similarly messed up.

  Only the computers running Ubuntu 14.04 are affected.  Two of the computers 
are identical hardware, differing only in Ubuntu versions - the 14.04 one is 
affected but the one with 13.04 is not.  I also have a machine with 12.04 on it 
connected to the KVM which is fine.
  I first noticed the problem when I upgraded to 13.10.

  In powertop I notice that autosuspend is enabled for the Avocent.  If
  I switch that off, then the problem disappears completely.  I can also
  prevent it by issuing:

    echo 'on' > '/sys/bus/usb/devices/3-10/power/control';

  where 3-10 is the Avocent (the number is different on each of my
  systems).

  I notice in 42-usb-hid-pm.rules there is a rule for Avocent devices:

    # Catch-all for Avocent HID devices. Keyed off interface in order to only
    # trigger on HID class devices.
    ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624", 
ATTR{bInterfaceClass}=="03", TEST=="../power/control", 
ATTR{../power/control}="auto"

  However my KVM device doesn't appear to have a bInterfaceClass
  defined.

  In any case, the following udev rule corrects the problem for me:

  ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624",
  ATTR{idProduct}=="0013", ATTR{product}=="SC Secure KVM",
  TEST=="power/control", ATTR{power/control}:="on"

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

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


[Touch-packages] [Bug 1371403] Re: [PATCH] Please disable USB autosuspend for Avocent SC Secure KVM

2015-11-25 Thread Bryce Harrington
Hrm, well with the := changed to =, the rule doesn't seem to be working.
(I guess it's the := change; I suppose there could be another error
somewhere...)

blackwold:~$ sudo ./disable_avocent_autosuspend 
[sudo] password for bryce: 
/sys/bus/usb/devices/3-13   on
/sys/bus/usb/devices/3-14   SC Secure KVM  auto
/sys/bus/usb/devices/3-3   Perfection1240   on
/sys/bus/usb/devices/3-4   USB Modem   on
/sys/bus/usb/devices/4-2   PRO57U SSon
/sys/bus/usb/devices/usb1   EHCI Host Controller   auto
/sys/bus/usb/devices/usb2   EHCI Host Controller   auto
/sys/bus/usb/devices/usb3   xHCI Host Controller   auto
/sys/bus/usb/devices/usb4   xHCI Host Controller   auto
--- (setting to auto)
/sys/bus/usb/devices/3-13   on
/sys/bus/usb/devices/3-14   SC Secure KVM  auto
/sys/bus/usb/devices/3-3   Perfection1240   on
/sys/bus/usb/devices/3-4   USB Modem   on
/sys/bus/usb/devices/4-2   PRO57U SSon
/sys/bus/usb/devices/usb1   EHCI Host Controller   auto
/sys/bus/usb/devices/usb2   EHCI Host Controller   auto
/sys/bus/usb/devices/usb3   xHCI Host Controller   auto
/sys/bus/usb/devices/usb4   xHCI Host Controller   auto
--- (applying udev rule)
/sys/bus/usb/devices/3-13   on
/sys/bus/usb/devices/3-14   SC Secure KVM  auto
/sys/bus/usb/devices/3-3   Perfection1240   on
/sys/bus/usb/devices/3-4   USB Modem   on
/sys/bus/usb/devices/4-2   PRO57U SSon
/sys/bus/usb/devices/usb1   EHCI Host Controller   auto
/sys/bus/usb/devices/usb2   EHCI Host Controller   auto
/sys/bus/usb/devices/usb3   xHCI Host Controller   auto
/sys/bus/usb/devices/usb4   xHCI Host Controller   auto
--- (forcing to on)
/sys/bus/usb/devices/3-13   on
/sys/bus/usb/devices/3-14   SC Secure KVM  on
/sys/bus/usb/devices/3-3   Perfection1240   on
/sys/bus/usb/devices/3-4   USB Modem   on
/sys/bus/usb/devices/4-2   PRO57U SSon
/sys/bus/usb/devices/usb1   EHCI Host Controller   auto
/sys/bus/usb/devices/usb2   EHCI Host Controller   auto
/sys/bus/usb/devices/usb3   xHCI Host Controller   auto
/sys/bus/usb/devices/usb4   xHCI Host Controller   auto
blackwold:~$ apt-cache policy udev
udev:
  Installed: 204-5ubuntu20.17
  Candidate: 204-5ubuntu20.17
  Version table:
 *** 204-5ubuntu20.17 0
500 http://us.archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64 
Packages
100 /var/lib/dpkg/status
 204-5ubuntu20.15 0
500 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 
Packages
 204-5ubuntu20 0
500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

Not really certain where to go from here...  :-/

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1371403

Title:
  [PATCH] Please disable USB autosuspend for Avocent SC Secure KVM

Status in systemd package in Ubuntu:
  Invalid
Status in systemd source package in Trusty:
  In Progress
Status in systemd source package in Utopic:
  Won't Fix

Bug description:
  My mouse becomes temporarily become unresponsive to drags and clicks,
  until I right-click or give keyboard input, when it's been idle for a
  few seconds.  The same thing affects the keyboard.  In some cases the
  mouse cursor jumps back to the center of the screen.

  The mouse and keyboard are connected to a number of different
  computers via an 8-port Avocent SC Secure KVM.  When the mouse and/or
  keyboard are directly attached to one of the PCs, there is no problem.
  I've tested with different keyboards and mice as well, and they're
  similarly messed up.

  Only the computers running Ubuntu 14.04 are affected.  Two of the computers 
are identical hardware, differing only in Ubuntu versions - the 14.04 one is 
affected but the one with 13.04 is not.  I also have a machine with 12.04 on it 
connected to the KVM which is fine.
  I first noticed the problem when I upgraded to 13.10.

  In powertop I notice that autosuspend is enabled for the Avocent.  If
  I switch that off, then the problem disappears completely.  I can also
  prevent it by issuing:

    echo 'on' > '/sys/bus/usb/devices/3-10/power/control';

  where 3-10 is the Avocent (the number is different on each of my
  systems).

  I notice in 42-usb-hid-pm.rules there is a rule for Avocent devices:

    # Catch-all for Avocent HID devices. Keyed off interface in order to only
    # trigger on HID class devices.
    ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624", 
ATTR{bInterfaceClass}=="03", TEST=="../power/control", 
ATTR{../power/control}="auto"

  However my KVM device doesn't appear to have a bInterfaceClass
  defined.

  In any case, the following udev rule corrects the problem for me:

  ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624",
  ATTR{idProduct}=="0013", ATTR{product}=="SC Secure KVM",
  TEST=="power/control", ATTR{power/control}:="on"

To manage notifications about this bug go to:

[Touch-packages] [Bug 1371403] Re: [PATCH] Please disable USB autosuspend for Avocent SC Secure KVM

2015-11-16 Thread Bryce Harrington
While the rules seem to work fine, apparently the syntax checker in the
packaging scripts don't like the use of := for assignment, so I've
change that to just =.  I think that should also work fine, but will
test once the package actually is built.


** Tags removed: verification-needed

** Changed in: systemd (Ubuntu Trusty)
   Status: Fix Committed => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1371403

Title:
  [PATCH] Please disable USB autosuspend for Avocent SC Secure KVM

Status in systemd package in Ubuntu:
  Invalid
Status in systemd source package in Trusty:
  In Progress
Status in systemd source package in Utopic:
  Won't Fix

Bug description:
  My mouse becomes temporarily become unresponsive to drags and clicks,
  until I right-click or give keyboard input, when it's been idle for a
  few seconds.  The same thing affects the keyboard.  In some cases the
  mouse cursor jumps back to the center of the screen.

  The mouse and keyboard are connected to a number of different
  computers via an 8-port Avocent SC Secure KVM.  When the mouse and/or
  keyboard are directly attached to one of the PCs, there is no problem.
  I've tested with different keyboards and mice as well, and they're
  similarly messed up.

  Only the computers running Ubuntu 14.04 are affected.  Two of the computers 
are identical hardware, differing only in Ubuntu versions - the 14.04 one is 
affected but the one with 13.04 is not.  I also have a machine with 12.04 on it 
connected to the KVM which is fine.
  I first noticed the problem when I upgraded to 13.10.

  In powertop I notice that autosuspend is enabled for the Avocent.  If
  I switch that off, then the problem disappears completely.  I can also
  prevent it by issuing:

    echo 'on' > '/sys/bus/usb/devices/3-10/power/control';

  where 3-10 is the Avocent (the number is different on each of my
  systems).

  I notice in 42-usb-hid-pm.rules there is a rule for Avocent devices:

    # Catch-all for Avocent HID devices. Keyed off interface in order to only
    # trigger on HID class devices.
    ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624", 
ATTR{bInterfaceClass}=="03", TEST=="../power/control", 
ATTR{../power/control}="auto"

  However my KVM device doesn't appear to have a bInterfaceClass
  defined.

  In any case, the following udev rule corrects the problem for me:

  ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624",
  ATTR{idProduct}=="0013", ATTR{product}=="SC Secure KVM",
  TEST=="power/control", ATTR{power/control}:="on"

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

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


[Touch-packages] [Bug 1371403] Re: [PATCH] Please disable USB autosuspend for Avocent SC Secure KVM

2015-10-22 Thread Bryce Harrington
** Changed in: systemd (Ubuntu Trusty)
   Status: Triaged => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1371403

Title:
  [PATCH] Please disable USB autosuspend for Avocent SC Secure KVM

Status in systemd package in Ubuntu:
  Invalid
Status in systemd source package in Trusty:
  In Progress
Status in systemd source package in Utopic:
  Won't Fix

Bug description:
  My mouse becomes temporarily become unresponsive to drags and clicks,
  until I right-click or give keyboard input, when it's been idle for a
  few seconds.  The same thing affects the keyboard.  In some cases the
  mouse cursor jumps back to the center of the screen.

  The mouse and keyboard are connected to a number of different
  computers via an 8-port Avocent SC Secure KVM.  When the mouse and/or
  keyboard are directly attached to one of the PCs, there is no problem.
  I've tested with different keyboards and mice as well, and they're
  similarly messed up.

  Only the computers running Ubuntu 14.04 are affected.  Two of the computers 
are identical hardware, differing only in Ubuntu versions - the 14.04 one is 
affected but the one with 13.04 is not.  I also have a machine with 12.04 on it 
connected to the KVM which is fine.
  I first noticed the problem when I upgraded to 13.10.

  In powertop I notice that autosuspend is enabled for the Avocent.  If
  I switch that off, then the problem disappears completely.  I can also
  prevent it by issuing:

    echo 'on' > '/sys/bus/usb/devices/3-10/power/control';

  where 3-10 is the Avocent (the number is different on each of my
  systems).

  I notice in 42-usb-hid-pm.rules there is a rule for Avocent devices:

    # Catch-all for Avocent HID devices. Keyed off interface in order to only
    # trigger on HID class devices.
    ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624", 
ATTR{bInterfaceClass}=="03", TEST=="../power/control", 
ATTR{../power/control}="auto"

  However my KVM device doesn't appear to have a bInterfaceClass
  defined.

  In any case, the following udev rule corrects the problem for me:

  ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624",
  ATTR{idProduct}=="0013", ATTR{product}=="SC Secure KVM",
  TEST=="power/control", ATTR{power/control}:="on"

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

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


[Touch-packages] [Bug 1255610] Re: 100% CPU usage with initctl emit plymouth-ready process

2015-05-09 Thread Bryce Harrington
Possibly dupe with #1173915?

I too am seeing 100% cpu on initctl, after a nearly three month uptime
on 14.04:

Linux dorset.bryceharrington.org 3.13.0-35-generic #62-Ubuntu SMP Fri
Aug 15 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

# cat /proc/1327/stack
[] 0x

# uptime
 17:24:15 up 87 days, 13:54,  9 users,  load average: 1.00, 1.01, 1.05

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 14.04.1 LTS
Release:14.04
Codename:   trusty

# ls -l /proc/1327/fd
total 0
lrwx-- 1 root root 64 Feb 11 02:39 0 - /dev/null
lrwx-- 1 root root 64 Feb 11 02:39 1 - /dev/pts/24
lrwx-- 1 root root 64 Feb 11 02:39 2 - /dev/pts/24
lrwx-- 1 root root 64 Feb 11 02:39 3 - socket:[9674]

# lsof | grep 9674
lsof: WARNING: can't stat() nfs4 file system /srv/Backup
  Output information may be incomplete.
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
  Output information may be incomplete.
initctl1327 root3u unix 0x8807ef6f2680  0t0 
  9674 socket

# strace -p 9674
...
poll([{fd=3, events=POLLIN}], 1, 1023162120) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1023162112) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1023162103) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1023162095) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1023162087) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1023162078) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1023162070) = 1 ([{fd=3, revents=POLLIN}])
...

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to upstart in Ubuntu.
https://bugs.launchpad.net/bugs/1255610

Title:
  100% CPU usage with initctl emit plymouth-ready process

Status in upstart package in Ubuntu:
  Confirmed

Bug description:
  root   977 99.1  2.7  98668 93964 ?R12:59 453:31
  initctl emit plymouth-ready

  this makes my CPU very hot, I don't know how to debug deeper. Any
  ideas?

  ProblemType: Bug
  DistroRelease: Ubuntu 13.10
  Package: upstart 1.10-0ubuntu7
  ProcVersionSignature: Ubuntu 3.11.0-13.20-generic 3.11.6
  Uname: Linux 3.11.0-13-generic i686
  NonfreeKernelModules: nvidia
  ApportVersion: 2.12.5-0ubuntu2.1
  Architecture: i386
  Date: Wed Nov 27 20:46:04 2013
  InstallationDate: Installed on 2012-03-12 (625 days ago)
  InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin - Beta i386 (20120301)
  MarkForUpload: True
  ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-3.11.0-13-generic 
root=UUID=d0d8bf63-cf4c-479f-9091-1f14156a902f ro quiet splash
  SourcePackage: upstart
  UpgradeStatus: Upgraded to saucy on 2013-10-21 (37 days ago)
  UpstartBugCategory: System
  UpstartRunningSessionVersion: init (upstart 1.10)
  UpstartRunningSystemVersion: init (upstart 1.10)
  modified.conffile..etc.at.deny: [inaccessible: [Errno 13] Permission denied: 
'/etc/at.deny']
  modified.conffile..etc.init.d.networking: [modified]
  mtime.conffile..etc.init.d.networking: 2013-08-27T01:19:11
  upstart.upstart-file-bridge.log:
   Job got added /com/ubuntu/Upstart/jobs/unicast_2dlocal_2davahi
   Job got added /com/ubuntu/Upstart/jobs/update_2dnotifier_2dcrash
   Job got added /com/ubuntu/Upstart/jobs/update_2dnotifier_2drelease

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

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


[Touch-packages] [Bug 973932] Re: Disabling 'below' display does not reposition windows properly

2014-12-01 Thread Bryce Harrington
Ayup.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity in Ubuntu.
https://bugs.launchpad.net/bugs/973932

Title:
  Disabling 'below' display does not reposition windows properly

Status in Unity:
  Incomplete
Status in unity package in Ubuntu:
  Incomplete

Bug description:
  [Problem]
  In a multihead config with one monitor above the other, if the lower monitor 
is disabled the windows on that screen aren't moved to the still-active display.

  [Test Case]
  0.  Attach laptop (LVDS1) to an external display (VGA1).
  1.  In the GNOME display properties applet, set the LVDS1 beneath VGA1.
  2.  Move to the lower left desktop (ctrl+alt+down)
  3.  Open one gnome terminal window on each monitor.
  4.  In the upper (VGA1) gnome terminal window type:
  xrandr --output LVDS1 --off
     (Alternatively, bring up the gnome display properties applet and shut the 
laptop display off there)
  5.  With the LVDS turned off, count the number of gnome terminal windows 
visible on VGA1
  6. Using either xrandr or gnome, re-enable LVDS1 to the above/below 
arrangement
  7.  With the LVDS re-enabled, count the number of gnome terminals visible on 
VGA1 and LVDS1

  Expected:  2, then 1/1
  Actual:
     Gnome Classic (No Effects):  2, then 1/1
     Gnome Classic (With Effects): 2, then 1/1
 Unity2D: 2, then 1/1
     Unity:  1, then 1/1

  Other findings...
  A.  On Unity, with LVDS1 off the missing gnome terminal window is 
inaccessible.  It can be recovered in various ways, but it's fairly confusing.

  B.  If step #2 is skipped and the test performed in the upper left
  desktop, Unity will place the lower windows into the lower left
  desktop.

  C.  On Unity, repeated testing of this seems to scramble the window
  positions to some extent.  The same effect does not appear to occur
  with metacity; windows generally get placed back where they'd been
  before.

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: unity 5.8.0-0ubuntu2
  ProcVersionSignature: Ubuntu 3.2.0-22.35-generic 3.2.14
  Uname: Linux 3.2.0-22-generic i686
  ApportVersion: 2.0-0ubuntu4
  Architecture: i386
  CompizPlugins: 
[core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,workarounds,scale,expo,ezoom]
  Date: Thu Apr  5 05:27:33 2012
  InstallationMedia: Ubuntu 11.10 Oneiric Ocelot - Beta i386 (20110921.2)
  SourcePackage: unity
  UpgradeStatus: Upgraded to precise on 2011-11-22 (135 days ago)

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

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


[Touch-packages] [Bug 1360606] Re: libcairo.so for Ubuntu 14.04 is dead-slow compared to Ubuntu 13.10

2014-09-18 Thread Bryce Harrington
Thanks peter and chris, sounds like the issue is resolved so I'll close
the bug as suggested.

** Changed in: cairo (Ubuntu)
   Status: New = Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cairo in Ubuntu.
https://bugs.launchpad.net/bugs/1360606

Title:
  libcairo.so for Ubuntu 14.04 is dead-slow compared to Ubuntu 13.10

Status in “cairo” package in Ubuntu:
  Fix Released

Bug description:
  I'm running the video mixer software called Snowmix that uses libcairo
  extensively. After updating to Ubuntu 14.04 Desktop amd64, I noticed
  that mixing video required 8 times more CPU compared to Ubuntu 13.10.
  Using oprofile I discovered the heavy CPU load was taking place in
  libpixman used by libcairo. However libpixman is currently the same
  release in Ubuntu 14.04 and 13.10. However I did notice that libcairo
  got upgraded from libcairo.so.2.11200.16 in Ubuntu 13.10 to
  libcairo.so.2.11301.0 in Uuntu 14.04.

  Snowmix uses libcairo2 primarily for scaling and rotating images and
  overlay them in memory.

  Replacing libcairo.so.2.11301.0 with libcairo.so.2.11200.16 in Ubuntu
  14.04 lower the CPU usage by at least 8 times. So I suspect that
  libcairo for Ubuntu 14.04 somehow got compiled without the hardware
  acceleration such as MMX/SSE2/SSE3 etc. This is quite bad if this is
  the case. If it is not the case, something else is seriously wrong
  with libcairo2.

  1)Description:Ubuntu 14.04.1 LTS
Release:14.04
  2) libcairo2:
  Installed: 1.13.0~20140204-0ubuntu1
  Candidate: 1.13.0~20140204-0ubuntu1
  Version table:
 *** 1.13.0~20140204-0ubuntu1 0
  500 http://dk.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
  100 /var/lib/dpkg/status
  3) I expected libcairo2 (libcairo.so.2.11301.0) for Ubuntu14.04 to work as 
efficient as libcairo2 (libcairo.so.2.11200.16)for Ubuntu13.10.
  4) Libcairo2 for Ubuntu 14.04 works 8 times slower indicating a lack of 
MMX/SSE2/SSE3 etc acceleration.

  For the source, you have the source for libcairo2 for Ubuntu14.04.

  I can provide you with the source code for Snowmix using libcairo2,
  but I don't expected you need it nor want it.

  Best regards
  Peter Maersk-Moller

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: libcairo2 1.13.0~20140204-0ubuntu1
  ProcVersionSignature: Ubuntu 3.13.0-34.60-generic 3.13.11.4
  Uname: Linux 3.13.0-34-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3.3
  Architecture: amd64
  Date: Sat Aug 23 15:23:38 2014
  InstallationDate: Installed on 2013-06-21 (428 days ago)
  InstallationMedia: Ubuntu 12.04.2 LTS Precise Pangolin - Release amd64 
(20130213)
  ProcEnviron:
   LANGUAGE=en_US:en
   TERM=xterm
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: cairo
  UpgradeStatus: Upgraded to trusty on 2014-08-20 (3 days ago)

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

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