[Sts-sponsors] [Bug 1865212] Re: simple.sh to be run as part of the autopkgtests

2020-04-24 Thread Eric Desrochers
** Tags removed: sts-sponsor-volunteer
** Tags added: sts-sponsor-slashd

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

Title:
  simple.sh to be run as part of the autopkgtests

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

Bug description:
  [Wishlist]

  Reporting this bug as a reminder for me to start working at eventually
  include simple.sh[0] to be run as part of the sosreport's autopkgtest.

  Autopkgtest restriction definitions requirement: needs-root

  [0] - A quick port of the travis tests to bash, requires root
  https://github.com/sosreport/sos/blob/master/tests/simple.sh

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

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


[Sts-sponsors] [Bug 1874526] Re: [landscape] Substitute oidc conf in service file

2020-04-24 Thread Eric Desrochers
** Tags added: sts-sponsor-slashd

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

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

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

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

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

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

Title:
  [landscape] Substitute oidc conf in service file

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

Bug description:
  [Impact]

  Landscape has added the ability to connect to OIDC.

  The plugin should be updated to obfuscate the sensitive information.

  https://docs.ubuntu.com/landscape/en/onprem-auth#openid-connect-
  support

  [Test Case]

  * Install sosreport
  * Run sosreport in a Landscape environment (client and server)
  * Extract archive and look at the content of sos_commands/landscape and most 
importantly make sure both "oidc-client-id" & "oidc-client-secret" are 
subsitute in files "/etc/landscape/service.conf" & 
"/etc/landscape/service.conf.old" as it should (if present).

  Extra testing:
  * Look under "sos_reports" for full report.
  * Look under "sos_logs" for warnings/errors.
    $ grep -v "INFO:" sos_logs/sos.log
  * Run "simple.sh": A quick port of the travis tests to bash. Generating 
various type of sosreports collection.
  https://raw.githubusercontent.com/sosreport/sos/master

  [Regression]

  No regression expected, we don't change/impact core functionnalities
  nor affect other plugins. If something happens it will be isolate to
  the landscape plugin itself only.

  Worse case the OID substitution won't work as expected (corner case)
  and will reveal OID sensible information, but it is very unlikely to
  happen as it will be intensively tested during the testing phase, and
  the substitute mechanism in place has been proven to work for the same
  configuration files in the landscape plugin already.

  [Other Informations]

  Upstream bug:
  https://github.com/sosreport/sos/issues/2023

  Upstream PR:
  https://github.com/sosreport/sos/pull/2025

  Upstream commit:
  
https://github.com/sosreport/sos/pull/2025/commits/0c4d821e26e1206a0b99f427b572931ba2fd9bb5

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

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


[Sts-sponsors] [Bug 1874075] Re: rabbitmq-server startup timeouts differ between SysV and systemd

2020-04-23 Thread Eric Desrochers
** Changed in: rabbitmq-server (Ubuntu Eoan)
 Assignee: Nicolas Bock (nicolasbock) => (unassigned)

** Changed in: rabbitmq-server (Ubuntu Eoan)
   Importance: Low => Undecided

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

Title:
  rabbitmq-server startup timeouts differ between SysV and systemd

Status in rabbitmq-server package in Ubuntu:
  In Progress
Status in rabbitmq-server source package in Xenial:
  In Progress
Status in rabbitmq-server source package in Bionic:
  In Progress
Status in rabbitmq-server source package in Eoan:
  Won't Fix
Status in rabbitmq-server source package in Focal:
  In Progress

Bug description:
  The startup timeouts were recently adjusted and synchronized between
  the SysV and systemd startup files.

  https://github.com/rabbitmq/rabbitmq-server-release/pull/129

  The new startup files should be included in this package.

  [Impact]

  After starting the RabbitMQ server process, the startup script will
  wait for the server to start by calling `rabbitmqctl wait` and will
  time out after 10 s.

  The startup time of the server depends on how quickly the Mnesia
  database becomes available and the server will time out after
  `mnesia_table_loading_retry_timeout` ms times
  `mnesia_table_loading_retry_limit` retries. By default this wait is
  30,000 ms times 10 retries, i.e. 300 s.

  The mismatch between these two timeout values might lead to the
  startup script failing prematurely while the server is still waiting
  for the Mnesia tables.

  This change introduces variable `RABBITMQ_STARTUP_TIMEOUT` and the
  `--timeout` option into the startup script. The default value for this
  timeout is set to 10 minutes (600 seconds).

  This change also updates the systemd service file to match the timeout
  values between the two service management methods.

  [Test Case]

  In a clustered setup with two nodes, A and B.

  1. create queue on A
  2. shut down B
  3. shut down A
  4. boot B

  The broker on B will wait for A. The systemd service will wait for 10
  seconds and then fail. Boot A and the rabbitmq-server process on B
  will complete startup.

  [Regression Potential]

  This change alters the behavior of the startup scripts when the Mnesia
  database takes long to become available. This might lead to failures
  further down the service dependency chain.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1874075/+subscriptions

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


[Sts-sponsors] [Bug 1871494] Re: add lshw cmd into sosreport's hardware plugin

2020-04-23 Thread Eric Desrochers
** Tags removed: sts-sponsor-volunteer
** Tags added: sts-sponsor-slashd

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

Title:
  add lshw cmd into sosreport's hardware plugin

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

Bug description:
  
  [Impact]

lshw(1) https://linux.die.net/man/1/lshw
   * lshw is a small tool to extract detailed information on the hardware 
 configuration of the machine. It can report exact memory configuration,
 firmware version, mainboard configuration, CPU version and speed, 
 cache configuration, bus speed, etc. on DMI-capable x86 or IA-64
 systems and on some PowerPC machines (PowerMac G4 is known to work).

   * Adding 'lshw' will help Canonical or third-party vendor using the 
 sosreport package to not having to ask 'lshw' in addition to sosreport.  
 This is a frequent command to run to troubleshoot/debug things

   * Including hardware information is a helpful debug step to determine
 issues found

  [Test Case]

   * Run sosreport in different customer scenarios:
  server, desktop, cloud, hypervisor, instance (container, vm), 
  physical server, since this is specifically listing hardware  
  informations.
   * For all distros:
 - install sosreport from the proposed pocket
 - run sosreport with default settings `sudo sosreport -a --config 
 sos.conf` 
 Or to just test hardware plugin `sosreport -o hardware --config
 sos.conf`
   * Extract archive and look at contents
- untar report file in /tmp/
  - cd /sos_commands/hardware/
  - less lshw
   -- the ouput is information about the system's hardware
  - look under "sos_logs" for warnings/errors.
  - look under "sos_reports" for full report.
   * Run `simple.sh`: A quick port of the travis unit tests to bash.  

  Generates various types of sosreports collection.
   * Ensure simple.sh test passes 
  - wget https://raw.githubusercontent.com/sosreport/sos/master
/test/simple.sh
  - execute command  `sudo tests/simple.sh`

  [Regression Potential]

   * Command implicitly slows down python script
   * Unit test failures
   * Only affects the hardware plugin and won't affect core functionalities nor 
other plugins
   * Lshw that is commonly used on system, the command cannot create any harm 
on the system (read only)
   * If the command doesn't exist sosreport will continue and move on
   * Lshw must be run as super user or it will only report partial information

  [Other Info]

   * Upstream commit:
  
https://github.com/sosreport/sos/pull/1994/commits/2dd5cd45a8381fa36ea99c85b526f9d79e526d91

  [Original description]

   * This is a wishlist to add the cmd 'lshw' into the hardware's
  sosreport plugin

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

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


[Sts-sponsors] [Bug 1874075] Re: rabbitmq-server startup timeouts differ between SysV and systemd

2020-04-23 Thread Eric Desrochers
The rationale behind not fixing Eoan can be found in the LP: #1773324
Note that Eoan will reach EOL in July 2020.

- Eric

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

Title:
  rabbitmq-server startup timeouts differ between SysV and systemd

Status in rabbitmq-server package in Ubuntu:
  In Progress
Status in rabbitmq-server source package in Xenial:
  In Progress
Status in rabbitmq-server source package in Bionic:
  In Progress
Status in rabbitmq-server source package in Eoan:
  Won't Fix
Status in rabbitmq-server source package in Focal:
  In Progress

Bug description:
  The startup timeouts were recently adjusted and synchronized between
  the SysV and systemd startup files.

  https://github.com/rabbitmq/rabbitmq-server-release/pull/129

  The new startup files should be included in this package.

  [Impact]

  After starting the RabbitMQ server process, the startup script will
  wait for the server to start by calling `rabbitmqctl wait` and will
  time out after 10 s.

  The startup time of the server depends on how quickly the Mnesia
  database becomes available and the server will time out after
  `mnesia_table_loading_retry_timeout` ms times
  `mnesia_table_loading_retry_limit` retries. By default this wait is
  30,000 ms times 10 retries, i.e. 300 s.

  The mismatch between these two timeout values might lead to the
  startup script failing prematurely while the server is still waiting
  for the Mnesia tables.

  This change introduces variable `RABBITMQ_STARTUP_TIMEOUT` and the
  `--timeout` option into the startup script. The default value for this
  timeout is set to 10 minutes (600 seconds).

  This change also updates the systemd service file to match the timeout
  values between the two service management methods.

  [Test Case]

  In a clustered setup with two nodes, A and B.

  1. create queue on A
  2. shut down B
  3. shut down A
  4. boot B

  The broker on B will wait for A. The systemd service will wait for 10
  seconds and then fail. Boot A and the rabbitmq-server process on B
  will complete startup.

  [Regression Potential]

  This change alters the behavior of the startup scripts when the Mnesia
  database takes long to become available. This might lead to failures
  further down the service dependency chain.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1874075/+subscriptions

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


[Sts-sponsors] [Bug 1874075] Re: rabbitmq-server startup timeouts differ between SysV and systemd

2020-04-23 Thread Eric Desrochers
Eoan FTBFS as follows:

==> rabbitmqctl
** (Mix) You're trying to run :rabbitmqctl on Elixir v1.9.1 but it has declared 
in its mix.exs file it supports only Elixir >= 1.6.6 and < 1.8.0
make[4]: *** [Makefile:93: escript/rabbitmqctl] Error 1
make[4]: Leaving directory '/<>/deps/rabbitmq_cli'
make[3]: *** [erlang.mk:4322: deps] Error 2
make[3]: Leaving directory '/<>/deps/rabbit'
make[2]: *** [erlang.mk:4322: deps] Error 2
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:18: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:11: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Bug reference:
https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1773324

- Eric

** Changed in: rabbitmq-server (Ubuntu Eoan)
   Status: In Progress => Won't Fix

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

Title:
  rabbitmq-server startup timeouts differ between SysV and systemd

Status in rabbitmq-server package in Ubuntu:
  In Progress
Status in rabbitmq-server source package in Xenial:
  In Progress
Status in rabbitmq-server source package in Bionic:
  In Progress
Status in rabbitmq-server source package in Eoan:
  Won't Fix
Status in rabbitmq-server source package in Focal:
  In Progress

Bug description:
  The startup timeouts were recently adjusted and synchronized between
  the SysV and systemd startup files.

  https://github.com/rabbitmq/rabbitmq-server-release/pull/129

  The new startup files should be included in this package.

  [Impact]

  After starting the RabbitMQ server process, the startup script will
  wait for the server to start by calling `rabbitmqctl wait` and will
  time out after 10 s.

  The startup time of the server depends on how quickly the Mnesia
  database becomes available and the server will time out after
  `mnesia_table_loading_retry_timeout` ms times
  `mnesia_table_loading_retry_limit` retries. By default this wait is
  30,000 ms times 10 retries, i.e. 300 s.

  The mismatch between these two timeout values might lead to the
  startup script failing prematurely while the server is still waiting
  for the Mnesia tables.

  This change introduces variable `RABBITMQ_STARTUP_TIMEOUT` and the
  `--timeout` option into the startup script. The default value for this
  timeout is set to 10 minutes (600 seconds).

  This change also updates the systemd service file to match the timeout
  values between the two service management methods.

  [Test Case]

  In a clustered setup with two nodes, A and B.

  1. create queue on A
  2. shut down B
  3. shut down A
  4. boot B

  The broker on B will wait for A. The systemd service will wait for 10
  seconds and then fail. Boot A and the rabbitmq-server process on B
  will complete startup.

  [Regression Potential]

  This change alters the behavior of the startup scripts when the Mnesia
  database takes long to become available. This might lead to failures
  further down the service dependency chain.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1874075/+subscriptions

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


[Sts-sponsors] [Bug 1874075] Re: rabbitmq-server startup timeouts differ between SysV and systemd

2020-04-22 Thread Eric Desrochers
** Changed in: rabbitmq-server (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: rabbitmq-server (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: rabbitmq-server (Ubuntu Eoan)
   Status: New => In Progress

** Changed in: rabbitmq-server (Ubuntu Focal)
   Status: New => In Progress

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

Title:
  rabbitmq-server startup timeouts differ between SysV and systemd

Status in rabbitmq-server package in Ubuntu:
  In Progress
Status in rabbitmq-server source package in Xenial:
  In Progress
Status in rabbitmq-server source package in Bionic:
  In Progress
Status in rabbitmq-server source package in Eoan:
  In Progress
Status in rabbitmq-server source package in Focal:
  In Progress

Bug description:
  The startup timeouts were recently adjusted and synchronized between
  the SysV and systemd startup files.

  https://github.com/rabbitmq/rabbitmq-server-release/pull/129

  The new startup files should be included in this package.

  [Impact]

  After starting the RabbitMQ server process, the startup script will
  wait for the server to start by calling `rabbitmqctl wait` and will
  time out after 10 s.

  The startup time of the server depends on how quickly the Mnesia
  database becomes available and the server will time out after
  `mnesia_table_loading_retry_timeout` ms times
  `mnesia_table_loading_retry_limit` retries. By default this wait is
  30,000 ms times 10 retries, i.e. 300 s.

  The mismatch between these two timeout values might lead to the
  startup script failing prematurely while the server is still waiting
  for the Mnesia tables.

  This change introduces variable `RABBITMQ_STARTUP_TIMEOUT` and the
  `--timeout` option into the startup script. The default value for this
  timeout is set to 10 minutes (600 seconds).

  This change also updates the systemd service file to match the timeout
  values between the two service management methods.

  [Test Case]

  In a clustered setup with two nodes, A and B.

  1. create queue on A
  2. shut down B
  3. shut down A
  4. boot B

  The broker on B will wait for A. The systemd service will wait for 10
  seconds and then fail. Boot A and the rabbitmq-server process on B
  will complete startup.

  [Regression Potential]

  This change alters the behavior of the startup scripts when the Mnesia
  database takes long to become available. This might lead to failures
  further down the service dependency chain.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1874075/+subscriptions

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


[Sts-sponsors] [Bug 1867676] Re: Fetching by secret container doesn't raises 404 exception

2020-04-22 Thread Eric Desrochers
** Changed in: python-barbicanclient (Ubuntu Bionic)
   Status: Triaged => In Progress

** Changed in: python-barbicanclient (Ubuntu Bionic)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

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

Title:
  Fetching by secret container doesn't raises 404 exception

Status in Ubuntu Cloud Archive:
  Invalid
Status in Ubuntu Cloud Archive queens series:
  Triaged
Status in python-barbicanclient package in Ubuntu:
  Fix Released
Status in python-barbicanclient source package in Bionic:
  In Progress
Status in python-barbicanclient source package in Disco:
  Fix Released
Status in python-barbicanclient source package in Eoan:
  Fix Released
Status in python-barbicanclient source package in Focal:
  Fix Released

Bug description:
  [Impact]

  Users of Ubuntu bionic running openstack clouds >= rocky
  can't create octavia load balancers listeners anymore since the backport of 
the following patch:

  
https://opendev.org/openstack/octavia/commit/a501714a76e04b33dfb24c4ead9956ed4696d1df

  This change was introduced as part of the following backports and
  their posterior syncs into the current Bionic version.

  This fix being SRUed here is contained in 4.8.1-0ubuntu1 (disco onwards)
  but not on the Bionic version 4.6.0-0ubuntu1.

  The issue gets exposed with the following octavia
  packages from UCA + python-barbicanclient 4.6.0ubuntu1.

  Please note that likely this python-barbicanclient dependency should
  be part of UCA and not of main/universe.

   octavia-api | 3.0.0-0ubuntu3~cloud0   | rocky  | all
   octavia-api | 4.0.0-0ubuntu1.1~cloud0 | stein  | all
   octavia-api | 4.0.0-0ubuntu1~cloud0   | train  | all

  This change added a new exception handler in the code
  that manages the decoding of the given PCKS12 certicate bundle when the 
listener is created, this handler now captures the PCKS12 decoding error and 
then raises it preventing
  the listener creation to happen (when its invoked with i.e.: 
--default-tls-container="https://10.5.0.4:9312/v1/containers/68154f38-fccf-4990-b88c-86eb3cc7fe1a";
 ) , this was originally being hidden
  under the legacy code handler as can be seen here:

  
https://opendev.org/openstack/octavia/commit/a501714a76e04b33dfb24c4ead9956ed4696d1df

  This exception is raised because the barbicanclient doesn't know how to 
distinguish between a given secret and a container, therefore, when the
  user specifies a container UUID the client tries to fetch a secret with that 
uuid (including the /containers/UUID path) and a error 400 (not the expected 
404 http error) is returned.

  The change proposed on the SRU makes the client aware of container and
  secret UUID(s) and is able to split the path to distinguish a non-
  secret (such as a container), in that way if a container is passed, it
  fails to pass the parsing validation and the right return code (404)
  is returned by the client.

  If a error 404 gets returned, then the except Exception block gets
  executed and the legacy driver code for decoding the pcks12 certicate in 
octavia is invoked, this legacy
  driver is able to decode the container payloads and the decoding of the 
pcks12 certificate succeeds.

  This differentiation was implemented here:

  https://github.com/openstack/python-
  barbicanclient/commit/6651c8ffce48ce7ff08f5563a8e6212677ea0468

  As an example (this worked before the latest bionic version was
  pushed)

  openstack loadbalancer listener create --protocol-port 443 --protocol
  "TERMINATED_HTTPS" --name "test-listener" --default-tls-
  container="https://10.5.0.4:9312/v1/containers/68154f38-fccf-4990
  -b88c-86eb3cc7fe1a" -- lb1

  With the newest package upgrade this creation will fail with the
  following exception:

  The PKCS12 bundle is unreadable. Please check the PKCS12 bundle
  validity. In addition, make sure it does not require a pass phrase.
  Error: [('asn1 encoding routines', 'asn1_d2i_read_bio', 'not enough
  data')] (HTTP 400) (Request-ID: req-8e48d0b5-3f5b-
  4d26-9920-72b03343596a)

  Further rationale on this can be found on
  https://storyboard.openstack.org/#!/story/2007371

  [Test Case]

  1) Deploy this bundle or similar
  (http://paste.ubuntu.com/p/cgbwKNZHbW/)

  2) Create self-signed certificate, key and ca
  (http://paste.ubuntu.com/p/xyyxHZGDFR/)

  3) Create the 3 certs at barbican

  $ openstack secret store --name "test-pk-1" --secret-type "private"
  --payload-content-type "text/plain" --payload="$(cat
  ./keys/controller_key.pem)"

  $ openstack secret store --name "test-ca-1" --secret-type
  "certificate" --payload-content-type "text/plain" --payload="$(cat
  ./keys/controller_ca.pem)"

  $ openstack secret store --name "test-pub-1" --secret-type
  "certificate" --payload-content-type "text/plain" --payload="$(cat
  ./keys/controller_cert.pem)"

  4) Create a loadba

[Sts-sponsors] [Bug 1870087] Re: Old broker lockfile blocks landscape-client starts

2020-04-14 Thread Eric Desrochers
Sponsored in Focal.

Thanks for your contribution Simon.

- Eric

** Tags removed: sts-sponsor-slashd

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

Title:
  Old broker lockfile blocks landscape-client starts

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

Bug description:
  [Impact]

   * landscape-client services are prevented from starting if its older PIDs get
 recycled.

   * The exact conditions for the issue, are particularly more likely to occur
 on release upgrade.

   * The proposed fix tries to verify existing locks actually belong
 to landscape-client, instead of just verifying they exist.

  [Test Case]

   * systemctl stop landscape-client

   * ln -sf 1 /var/lib/landscape/client/sockets/broker.sock.lock

   * systemctl start landscape-client

  [Regression Potential]

   * The existing twisted logic is still kept, so assuming checking process
 names fail, lock conflicts should still be detected normally.

   * The locks which twisted creates are unlikely to actually see conflicts in
 the wild as those processes are managed by systemd. False positives in
 the detection check should have minimal impact.

  [Original description]

  I have a machine which was failing to connect to the landscape
  service. In syslog I found this traceback:

  Apr  1 03:27:53 maas-1 landscape-client[1538354]: Traceback (most recent call 
last):
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/python/lockfile.py", line 160, in lock
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: 
symlink(str(os.getpid()), self.name)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: FileExistsError: [Errno 17] 
File exists: '1538397' -> b'/var/lib/landscape/client/sockets/broker.sock.lock'
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: During handling of the 
above exception, another exception occurred:
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: Traceback (most recent call 
last):
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/bin/landscape-broker", line 8, in 
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: run(sys.argv)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/landscape/client/broker/service.py", line 93, 
in run
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: 
run_landscape_service(BrokerConfiguration, BrokerService, args)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/landscape/client/service.py", line 115, in 
run_landscape_service
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: 
startApplication(application, False)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/application/app.py", line 690, in 
startApplication
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: 
service.IService(application).startService()
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/application/service.py", line 288, in 
startService
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: service.startService()
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/landscape/client/broker/service.py", line 79, 
in startService
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: self.publisher.start()
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/landscape/client/amp.py", line 45, in start
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: self._port = 
self._reactor.listen_unix(socket_path, factory)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/landscape/lib/reactor.py", line 228, in 
listen_unix
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: return 
self._reactor.listenUNIX(socket, factory, wantPID=True)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/internet/posixbase.py", line 397, in 
listenUNIX
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: p.startListening()
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/internet/unix.py", line 372, in 
startListening
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: if not 
self.lockFile.lock():
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/python/lockfile.py", line 185, in lock
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: kill(int(pid), 0)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: PermissionError: [Errno 1] 
Operation not permitted

  In the sockets directory I saw:

  $ sudo ls /var/lib/landscape/cli

[Sts-sponsors] [Bug 1870087] Re: Old broker lockfile blocks landscape-client starts

2020-04-14 Thread Eric Desrochers
** Changed in: landscape-client (Ubuntu Focal)
   Importance: Undecided => High

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

Title:
  Old broker lockfile blocks landscape-client starts

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

Bug description:
  [Impact]

   * landscape-client services are prevented from starting if its older PIDs get
 recycled.

   * The exact conditions for the issue, are particularly more likely to occur
 on release upgrade.

   * The proposed fix tries to verify existing locks actually belong
 to landscape-client, instead of just verifying they exist.

  [Test Case]

   * systemctl stop landscape-client

   * ln -sf 1 /var/lib/landscape/client/sockets/broker.sock.lock

   * systemctl start landscape-client

  [Regression Potential]

   * The existing twisted logic is still kept, so assuming checking process
 names fail, lock conflicts should still be detected normally.

   * The locks which twisted creates are unlikely to actually see conflicts in
 the wild as those processes are managed by systemd. False positives in
 the detection check should have minimal impact.

  [Original description]

  I have a machine which was failing to connect to the landscape
  service. In syslog I found this traceback:

  Apr  1 03:27:53 maas-1 landscape-client[1538354]: Traceback (most recent call 
last):
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/python/lockfile.py", line 160, in lock
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: 
symlink(str(os.getpid()), self.name)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: FileExistsError: [Errno 17] 
File exists: '1538397' -> b'/var/lib/landscape/client/sockets/broker.sock.lock'
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: During handling of the 
above exception, another exception occurred:
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: Traceback (most recent call 
last):
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/bin/landscape-broker", line 8, in 
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: run(sys.argv)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/landscape/client/broker/service.py", line 93, 
in run
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: 
run_landscape_service(BrokerConfiguration, BrokerService, args)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/landscape/client/service.py", line 115, in 
run_landscape_service
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: 
startApplication(application, False)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/application/app.py", line 690, in 
startApplication
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: 
service.IService(application).startService()
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/application/service.py", line 288, in 
startService
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: service.startService()
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/landscape/client/broker/service.py", line 79, 
in startService
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: self.publisher.start()
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/landscape/client/amp.py", line 45, in start
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: self._port = 
self._reactor.listen_unix(socket_path, factory)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/landscape/lib/reactor.py", line 228, in 
listen_unix
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: return 
self._reactor.listenUNIX(socket, factory, wantPID=True)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/internet/posixbase.py", line 397, in 
listenUNIX
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: p.startListening()
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/internet/unix.py", line 372, in 
startListening
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: if not 
self.lockFile.lock():
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/python/lockfile.py", line 185, in lock
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: kill(int(pid), 0)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: PermissionError: [Errno 1] 
Operation not permitted

  In the sockets directory I saw:

  $ sudo ls /var/lib/landscape/client/sockets/ -la
  tot

[Sts-sponsors] [Bug 1870087] Re: Old broker lockfile blocks landscape-client starts

2020-04-14 Thread Eric Desrochers
** Tags added: sts-sponsor-slashd

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

Title:
  Old broker lockfile blocks landscape-client starts

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

Bug description:
  I have a machine which was failing to connect to the landscape
  service. In syslog I found this traceback:

  Apr  1 03:27:53 maas-1 landscape-client[1538354]: Traceback (most recent call 
last):
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/python/lockfile.py", line 160, in lock
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: 
symlink(str(os.getpid()), self.name)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: FileExistsError: [Errno 17] 
File exists: '1538397' -> b'/var/lib/landscape/client/sockets/broker.sock.lock'
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: During handling of the 
above exception, another exception occurred:
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: Traceback (most recent call 
last):
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/bin/landscape-broker", line 8, in 
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: run(sys.argv)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/landscape/client/broker/service.py", line 93, 
in run
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: 
run_landscape_service(BrokerConfiguration, BrokerService, args)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/landscape/client/service.py", line 115, in 
run_landscape_service
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: 
startApplication(application, False)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/application/app.py", line 690, in 
startApplication
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: 
service.IService(application).startService()
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/application/service.py", line 288, in 
startService
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: service.startService()
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/landscape/client/broker/service.py", line 79, 
in startService
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: self.publisher.start()
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/landscape/client/amp.py", line 45, in start
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: self._port = 
self._reactor.listen_unix(socket_path, factory)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/landscape/lib/reactor.py", line 228, in 
listen_unix
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: return 
self._reactor.listenUNIX(socket, factory, wantPID=True)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/internet/posixbase.py", line 397, in 
listenUNIX
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: p.startListening()
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/internet/unix.py", line 372, in 
startListening
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: if not 
self.lockFile.lock():
  Apr  1 03:27:53 maas-1 landscape-client[1538354]:   File 
"/usr/lib/python3/dist-packages/twisted/python/lockfile.py", line 185, in lock
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: kill(int(pid), 0)
  Apr  1 03:27:53 maas-1 landscape-client[1538354]: PermissionError: [Errno 1] 
Operation not permitted

  In the sockets directory I saw:

  $ sudo ls /var/lib/landscape/client/sockets/ -la
  total 8
  drwxr-x--- 2 landscape root  4096 Apr  1 03:27 .
  drwxr-xr-x 7 landscape root  4096 Apr  1 03:27 ..
  srw-rw-rw- 1 landscape landscape0 Mar 12 01:41 broker.sock
  lrwxrwxrwx 1 landscape landscape3 Mar 12 01:41 broker.sock.lock -> 905

  Removing those two files allowed the landscape client to start as
  normal.

  Looks like we need some lockfile cleanup code on start.

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

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


[Sts-sponsors] [Bug 1870619] Re: rabbitmq-server startup does not wait long enough

2020-04-07 Thread Eric Desrochers
IIUC, this is your own patch (you being the author).

* Does upstream maintain the debian/ folder ? 
 ** If yes, can you please make sure to submit a PR upstream ?
* Can you file a bug and submit the patch to Debian as well ?
 ** https://wiki.debian.org/BugReport

Thanks !

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

Title:
  rabbitmq-server startup does not wait long enough

Status in OpenStack rabbitmq-server charm:
  New
Status in rabbitmq-server package in Ubuntu:
  Confirmed
Status in rabbitmq-server source package in Bionic:
  Confirmed
Status in rabbitmq-server source package in Eoan:
  Confirmed
Status in rabbitmq-server source package in Focal:
  Confirmed

Bug description:
  [Impact]

   * Rabbitmq-server has 2 configuration settings that affect how long it will 
wait for the mnesia database to become available
   * The default is 30 seconds x 10 retries = 300 seconds
   * The startup wrapper rabbitmq-server-wait will wait only 10 seconds
   * If the database does not come online within 10 seconds the startup script 
will fail despite the fact that rabbitmq-server is still waiting for another 
290 seconds.
   * This behavior leads to falsely identified failures in OpenStack for 
example when a Rabbitmq cluster is restarted out of order (LP: #1828988)

  [Test Case]

   * Create Rabbitmq cluster and create a queue with "ha-mode: all" policy
   * Shut down nodes one by one
   * Restart the node that was shut down first
   * This node will fail to start because it was not the master of the queue
   * Note that the startup script (SysV or systemd) will fail after 10 seconds 
while the rabbitmq-server process is still waiting for the database to come 
online

  [Regression Potential]

   * This change potentially increases the time the rabbitmq-server service 
takes to start up which might lead to failures down the dependency chain of 
startup services.
   * This change potentially changes the result of starting the rabbitmq-server 
service in case the mnesia database takes more than 10 seconds to come online. 
Without this change, the service will incorrectly fail while it will succeed 
with this change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-rabbitmq-server/+bug/1870619/+subscriptions

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


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

2020-03-31 Thread Eric Desrochers
[STS-SPONSOR]

Sponsored for E/B.

Thanks for your contribution Seyeong.

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

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

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

Bug description:
  [Impact]

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

  [Test Case]

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

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

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

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

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

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

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

  [Regression]

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

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

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

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

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

  [Others]

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

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

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

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


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

2020-03-31 Thread Eric Desrochers
[sts-sponsor]

Sponsored for E/B.

Thanks Kellen for your contribution.

- Eric

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

Title:
  LXC container reports spike in swap occasionally

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

Bug description:
  [Impact]

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

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

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

  [Test Case]

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

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

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

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

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

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

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

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

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

  
  [Regression Potential] 

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

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

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

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

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

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


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

2020-03-30 Thread Eric Desrochers
** Tags added: sts-sponsor-volunteer

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

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

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

Bug description:
  [Impact]

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

  [Test Case]

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

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

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

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

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

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

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

  [Regression]

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

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

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

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

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

  [Others]

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

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

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

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


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

2020-03-30 Thread Eric Desrochers
I like "sts-sponsor-volunteer"

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

Thought ?

Eric

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

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


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

2020-03-27 Thread Eric Desrochers
** Also affects: lxcfs (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

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

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

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

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

** Tags added: sts-sponsor-slashd

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

Title:
  LXC container reports spike in swap occasionally

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

Bug description:
  [Impact]

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

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

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

  [Test Case]

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

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

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

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

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

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

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

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

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

  
  [Regression Potential] 

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

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

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

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

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

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


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

2020-03-27 Thread Eric Desrochers
I like the tag idea. What about "sts-sponsor-padawan" ?

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

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


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

2020-03-26 Thread Eric Desrochers
** Changed in: containerd (Ubuntu Bionic)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

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

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

Title:
  [Regression] unsupported protocol scheme

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

Bug description:
  [Description]

  Kubernetes 1.16.17
  Containerd 1.3.3
  Ubuntu Bionic

  [Affected Releases]

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

  [Impact]

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

  User Impact:

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

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

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

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

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

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

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

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

  [Test Case]

  1) Configure a private docker repository repository

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

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

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

  [Possible workaround and solution]

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

  [Regression Potential]

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

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

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

  [Other Info]

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

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

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


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

2020-03-25 Thread Eric Desrochers
[FOCAL]

Note: lxd only available via SNAP.

# lsb_release -cs
focal

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

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

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

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

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

Bug description:
  [Impact]

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

  [Test Case]

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

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

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

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

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

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

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

  [Regression]

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

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

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

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

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

  [Others]

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

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

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

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


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

2020-03-25 Thread Eric Desrochers
Pushed into focal along with LP: #1865212.

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

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

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

Bug description:
  [Impact]

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

  [Test Case]

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

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

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

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

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

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

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

  [Regression]

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

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

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

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

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

  [Others]

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

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

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

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


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

2020-03-24 Thread Eric Desrochers
Sponsored in Eoan

Thanks Simon !

** Tags removed: sts-sponsor-slashd

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

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

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

Bug description:
  [Impact]

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

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

  [Test Case]

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

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

  [Regression Potential]

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

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

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

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

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

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

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


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

2020-03-24 Thread Eric Desrochers
** Description changed:

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

** Description changed:

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

** Tags added: sts-sponsor-slashd

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

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

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

Bug description:
  [Impact]

  [Test Case]

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

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

2020-03-23 Thread Eric Desrochers
** Changed in: landscape-client (Ubuntu Eoan)
   Status: New => In Progress

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

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

** Tags added: sts

** Tags added: sts-sponsor-slashd

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

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

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

Bug description:
  [Impact]

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

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

  [Test Case]

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

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

  [Regression Potential]

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

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

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

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

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

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

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


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

2020-02-26 Thread Eric Desrochers
Sponsored by dgadomski. Unsubscribing sts-sponsor team.

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

- Eric

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

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

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

Bug description:
  [Impact]

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

  [Test Case]

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

  sleep 5

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

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

  sleep 5

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

  sleep 5

  sudo nmcli c s bond0
  ##

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

  [Potential Regression]

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

  [Other informations]

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

  * Upstream bug and fix:

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

  * Only affecting Bionic:

  $ git describe --contains f03ae35
  1.10.8~2

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

  [Original description]

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

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

  Machine Type = s390x

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

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

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

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

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

  [ethernet]
  mac-address-blacklist=

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

  [ipv4]
  dns-search=
  method=auto

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

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

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

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

2020-02-24 Thread Eric Desrochers
** Changed in: network-manager (Ubuntu Bionic)
   Status: Confirmed => In Progress

** Tags added: sts-sponsor-dgadomski

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

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

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

Bug description:
  [Impact]

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

  [Test Case]

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

  sleep 5

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

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

  sleep 5

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

  sleep 5

  sudo nmcli c s bond0
  ##

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

  [Potential Regression]

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

  [Other informations]

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

  * Upstream bug and fix:

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

  * Only affecting Bionic:

  $ git describe --contains f03ae35
  1.10.8~2

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

  [Original description]

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

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

  Machine Type = s390x

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

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

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

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

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

  [ethernet]
  mac-address-blacklist=

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

  [ipv4]
  dns-search=
  method=auto

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

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

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

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

2020-02-20 Thread Eric Desrochers
** Description changed:

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

** Description changed:

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

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

2020-02-20 Thread Eric Desrochers
Sponsored for B/E

Thanks Simon !

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

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

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

Bug description:
  [Impact]

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

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

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

  [Test Case]

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

   * trigger a package installation from the landscape server.

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

  [Regression Potential]

   * The change is trivially simple.

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

  [Original Description]

  Crash in the background

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

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

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


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

2020-02-20 Thread Eric Desrochers
Thanks Lukasz,

$ lsb_release -cs
bionic

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

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

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

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

Bug description:
  [Impact]

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

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

  Current workaround:
  One can install the dependency by hand.

  [Test Case]

  # lsb_release -cs
  bionic

  # Install sssd-tools

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

  [Potential Regression]

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

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

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

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

  [Other Infos]

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

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

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

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

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


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

2020-02-20 Thread Eric Desrochers
** Changed in: landscape-client (Ubuntu Disco)
   Status: Confirmed => Won't Fix

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

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

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

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

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

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

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

Bug description:
  [Impact]

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

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

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

  [Test Case]

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

   * trigger a package installation from the landscape server.

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

  [Regression Potential]

   * The change is trivially simple.

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

  [Original Description]

  Crash in the background

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

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

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


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

2020-02-20 Thread Eric Desrochers
util-linux uploaded in focal.

Thanks Mauricio !

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

Title:
  Crash and failure installing focal

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

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

  Attached are the logs left on the install USB key.

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

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


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

2020-02-11 Thread Eric Desrochers
** Tags added: sts-sponsor-dgadomski

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

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

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

Bug description:
  [Impact]

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

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

  Current workaround:
  One can install the dependency by hand.

  [Test Case]

  # lsb_release -cs
  bionic

  # Install sssd-tools

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

  [Potential Regression]

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

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

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

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

  [Other Infos]

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

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

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

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

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


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

2020-01-14 Thread Eric Desrochers
** Tags added: sts-sponsor-slashd

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

Title:
  firefox crashes on a FIPS enabled machine

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

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

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

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

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

  Version: 2:3.45-1ubuntu1

  lsb_release -rd
  Description: Ubuntu Disco Dingo
  Release: 19.04

  Version: 2:3.42-1ubuntu2

  lsb_release -rd
  Description:  Ubuntu Bionic Beaver
  Release:  18.04

  Version: 2:3.35-2ubuntu2.3

  lsb_release -rd
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04

  Version: 2:3.28.4-0ubuntu0.16.04

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

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

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

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

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

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

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


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

2020-01-10 Thread Eric Desrochers
Sponsored in focal.

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

- Eric

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

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

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

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

Bug description:
  [Impact]

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

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

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

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

  [Test Case]

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

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

  [Regression Potential]

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

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

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

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

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

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


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

2020-01-10 Thread Eric Desrochers
** Tags added: sts-sponsor-slashd-focal

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

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

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

Bug description:
  [Impact]

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

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

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

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

  [Test Case]

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

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

  [Regression Potential]

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

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

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

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

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

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


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

2019-12-13 Thread Eric Desrochers
A current landscape-client SRU (LP: #1855522) prevents me to upload
19.12 in the archive.

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

- Eric

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

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

Title:
  Update eoan with landscape-client 19.12

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

Bug description:
  [Impact]

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

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

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

  [Test Case]

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

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

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

  [Regression Potential]

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

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

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

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


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

2019-12-11 Thread Eric Desrochers
** Changed in: landscape-client (Ubuntu Eoan)
   Status: New => In Progress

** Tags added: sts-sponsor-slashd

** Tags added: sts

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

Title:
  Update eoan with landscape-client 19.12

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

Bug description:
  [Impact]

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

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

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

  [Test Case]

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

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

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

  [Regression Potential]

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

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

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

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


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

2019-11-08 Thread Eric Desrochers
I also reported a LP bug about the lua-lpeg modernisation:

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

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

- Eric

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

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

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

Bug description:
  [Impact]

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

  [Test Case]

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

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

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

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

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

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

  The expected behavior is to have the program finish normally

  [Regression potential]

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

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

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

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

  [Original description]

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

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

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


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

2019-11-08 Thread Eric Desrochers
[sts-sponsor]

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

Thanks again Victor

- Eric

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

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

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

Bug description:
  [Impact]

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

  [Test Case]

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

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

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

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

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

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

  The expected behavior is to have the program finish normally

  [Regression potential]

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

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

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

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

  [Original description]

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

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

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


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

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

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

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

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

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

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

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

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

Bug description:
  [Impact]

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

  [Test Case]

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

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

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

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

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

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

  The expected behavior is to have the program finish normally

  [Regression potential]

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

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

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

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

  [Original description]

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

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

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


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

2019-11-07 Thread Eric Desrochers
** Changed in: lua-lpeg (Ubuntu Eoan)
 Assignee: (unassigned) => Victor Tapia (vtapia)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bug description:
  [Impact]

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

  [Test Case]

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

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

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

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

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

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

  The expected behavior is to have the program finish normally

  [Regression potential]

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

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

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

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

  [Original description]

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

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

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


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

2019-11-06 Thread Eric Desrochers
** Changed in: lua-lpeg (Ubuntu)
   Status: In Progress => Fix Committed

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

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

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

Bug description:
  [Impact]

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

  [Test Case]

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

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

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

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

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

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

  The expected behavior is to have the program finish normally

  [Regression potential]

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

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

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

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

  [Original description]

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

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

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


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

2019-11-06 Thread Eric Desrochers
[sts-sponsor]

Sponsored in focal.

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

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

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

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

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


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

no segfault nor other error ^

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

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

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


Thanks Victor for your contribution !

- Eric

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

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

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

Bug description:
  [Impact]

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

  [Test Case]

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

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

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

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

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

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

  The expected behavior is to have the program finish normally

  [Regression potential]

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

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

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

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

  [Original description]

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

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

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

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

2019-11-06 Thread Eric Desrochers
** Changed in: lua-lpeg (Ubuntu)
   Importance: Undecided => Critical

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

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

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

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

Bug description:
  [Impact]

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

  [Test Case]

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

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

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

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

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

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

  The expected behavior is to have the program finish normally

  [Regression potential]

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

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

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

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

  [Original description]

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

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

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


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

2019-11-06 Thread Eric Desrochers
** Changed in: lua-lpeg (Ubuntu)
 Assignee: (unassigned) => Victor Tapia (vtapia)

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

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

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

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

Bug description:
  [Impact]

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

  [Test Case]

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

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

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

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

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

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

  The expected behavior is to have the program finish normally

  [Regression potential]

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

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

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

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

  [Original description]

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

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

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


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

2019-10-30 Thread Eric Desrochers
Sponsored for Xenial.

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

Thanks for your contribution Matthew !

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

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

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

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

Bug description:
  [Impact]

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

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

  [Test Case]

  To reproduce:

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

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

  2) Reboot the instance

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

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

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

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

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

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

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

  [Regression Potential]

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

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

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

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

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

  [Other Info]

  In comment #4, Sultan identifies the fix as:

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

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

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

  Looking at when this was merged:

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

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

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

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

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


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

2019-10-29 Thread Eric Desrochers
** Tags added: sts-sponsor-slashd

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

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

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

Bug description:
  [Impact]

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

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

  [Test Case]

  To reproduce:

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

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

  2) Reboot the instance

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

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

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

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

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

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

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

  [Regression Potential]

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

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

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

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

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

  [Other Info]

  In comment #4, Sultan identifies the fix as:

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

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

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

  Looking at when this was merged:

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

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

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

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

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


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

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

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

- Eric

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

Title:
  report packages from security pocket

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

Bug description:
  [Impact]

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

  [Test Case]

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

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

  [Regression Potential]

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

  [Other Info]

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

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

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


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

2019-10-22 Thread Eric Desrochers
** Changed in: landscape-client (Ubuntu Eoan)
 Assignee: (unassigned) => Simon Poirier (simpoir)

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

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

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

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

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

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

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

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

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

** Tags added: sts-sponsor-slashd

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

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

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

Title:
  report packages from security pocket

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

Bug description:
  [Impact]

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

  [Test Case]

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

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

  [Regression Potential]

  ## TBD by simpoir ##

  [Other Info]

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

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

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


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

2019-10-16 Thread Eric Desrochers
$ pull-lp-source cups-filters xenial

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


$ pull-lp-source cups-filters bionic

debian/control:

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


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

- Eric

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

Title:
  ghostscript: ensure update of cups-filter

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

Bug description:
  [Impact]

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

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

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

     Per Debian Policy [1]:

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

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

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

  [Test Case]

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

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

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

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

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

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

   * Note it's broken.

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

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

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

   * Note it's now working.

  [Regression Potential]

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

  [Other Info]

   * This is only required in Xenial and Bionic.

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

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

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

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

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


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

2019-10-16 Thread Eric Desrochers
$ pull-lp-source cups-filters xenial

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



$ pull-lp-source cups-filter bionic

debian/control:

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


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

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

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

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

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

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

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

Title:
  ghostscript: ensure update of cups-filter

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

Bug description:
  [Impact]

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

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

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

     Per Debian Policy [1]:

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

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

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

  [Test Case]

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

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

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

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

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

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

   * Note it's broken.

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

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

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

   * Note it's now working.

  [Regression Potential]

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

  [Other Info]

   * This is only required in Xenial and Bionic.

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

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

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

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

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

2019-10-15 Thread Eric Desrochers
** Tags added: sts-sponsor-slashd

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

Title:
  ghostscript: ensure update of cups-filter

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

Bug description:
  [Impact]

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

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

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

     Per Debian Policy [1]:

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

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

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

  [Test Case]

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

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

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

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

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

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

   * Note it's broken.

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

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

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

   * Note it's now working.

  [Regression Potential]

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

  [Other Info]

   * This is only required in Xenial and Bionic.

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

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

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

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

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


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

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

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

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

- Eric


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

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

Title:
  ghostscript: ensure update of cups-filter

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

Bug description:
  [Impact]

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

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

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

     Per Debian Policy [1]:

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

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

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

  [Test Case]

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

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

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

   * $ wget -O ppd-with-pdf-support.ppd \
   
'http://www.openprinting.org/ppd-o-matic.php?driver=hl7x0&printer=Brother-HL-1020&show=1'

   * $ wget -O dummy.pdf \
   https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf

   * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf
     ...
     Filetype: PDF
     GPL Ghostscript 9.26: Unrecoverable error, exit code 1
     Process is dying with "Unable to determine number of pages, page count: -1
     ", exit stat 3
     ...

   * Note it's broken.

   * Install ghostscript (test) packages with the relationships
     'Breaks: cups-filters (<< 1.20.2-0ubuntu3.1)' in Bionic or
     'Breaks: ..., cups-filters (<< 1.8.3-2ubuntu3.5)' in Xenial.

   * Note it _does_ update cups-filters to version with fix.

   * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf
     ...
     Filetype: PDF
     File contains 1 pages
     Starting renderer with command: <...>
     ...

   * Note it's now working.

  [Regression Potential]

   * Low.  This only causes an update to cups-filters to a version
     that fixes an already identified/resolved problem (LP#1828401),
     which is available in bionic- & xenial-updates since May 2019.

  [Other Info]

   * This is only required in Xenial and Bionic.

   * Trusty doesn't have the ghostscript update that causes the problem.

   * Disco/Eoan have the cups-filters fix that it requires (1.22.5+).

  [1] https://www.debian.org/doc/debian-policy/ch-relationships.html
  #packages-which-break-other-packages-breaks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1848210/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1848210] Re: ghostscript: ensure update of cups-filter

2019-10-15 Thread Eric Desrochers
I will be more favourable to do the other way around by adding a
"Depends:" in cups-filters package for ghostscript version "X" ?
Especially if cups-filters always needs ghostscript ?

"Depends: ghostscript (>= CUPS_FILTER_VERSION)"

to force ghostscript to get updated instead of making the package
install to fails/breaks.

At least it's worth testing IMHO that avenue before considering the
current "Breaks:" approach.

Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1848210

Title:
  ghostscript: ensure update of cups-filter

Status in cups-filters package in Ubuntu:
  New
Status in ghostscript package in Ubuntu:
  Invalid
Status in cups-filters source package in Xenial:
  New
Status in ghostscript source package in Xenial:
  In Progress
Status in cups-filters source package in Bionic:
  New
Status in ghostscript source package in Bionic:
  In Progress

Bug description:
  [Impact]

   * After an update of ghostscript but not cups-filters
     (which is possible; eg unattended-upgrade/landscape)
     users may hit errors printing PDF files (LP#1828401).

   * Landscape and unattended-upgrade allows packages
 updates to security updates / USN-only, thus
     ghostscript is updated for CVE-2019-3839-1 and -2
     (version 9.26~dfsg+0-0ubuntu0.18.04.9 and 16.04.9)
     which may break printing PDF files on cups-filters.

   * So, to ensure that ghostscript and cups-filters are
     both updated, add a versioned 'Breaks:' relationship
     to ghostscript for older cups-filters versions which
     are not yet fixed.

     Per Debian Policy [1]:

   """
   Normally a Breaks entry will have an “earlier than” version clause;
   such a Breaks is introduced in the version ... [that] reveals a bug
   in earlier versions of the broken package ...

   This use of Breaks will inform higher-level package management tools
   that the broken package must be upgraded before the new one.
   """

   * A versioned 'Depends:' relationship is not possible
     as ghostscript doesn't depend on cups-filters, thus
     it's possible to have ghostscript installed without
     cups-filters at all.

  [Test Case]

   * Install cups-filters version without fix for LP#1828401:
     1.20.2-0ubuntu3 in Bionic, and 1.8.3-2ubuntu3.4 in Xenial.

   * Update ghostscript to/later than fix for CVE-2019-3839-1/-2
     9.26~dfsg+0-0ubuntu0.18.04.9 in Bionic / .16.04.9 in Xenial.

   * Notice it does _not_ update cups-filters to version with fix:
     1.20.2-0ubuntu3.1 in Bionic, and 1.8.3-2ubuntu3.5 in Xenial.

   * $ wget -O ppd-with-pdf-support.ppd \
   
'http://www.openprinting.org/ppd-o-matic.php?driver=hl7x0&printer=Brother-HL-1020&show=1'

   * $ wget -O dummy.pdf \
   https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf

   * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf
     ...
     Filetype: PDF
     GPL Ghostscript 9.26: Unrecoverable error, exit code 1
     Process is dying with "Unable to determine number of pages, page count: -1
     ", exit stat 3
     ...

   * Note it's broken.

   * Install ghostscript (test) packages with the relationships
     'Breaks: cups-filters (<< 1.20.2-0ubuntu3.1)' in Bionic or
     'Breaks: ..., cups-filters (<< 1.8.3-2ubuntu3.5)' in Xenial.

   * Note it _does_ update cups-filters to version with fix.

   * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf
     ...
     Filetype: PDF
     File contains 1 pages
     Starting renderer with command: <...>
     ...

   * Note it's now working.

  [Regression Potential]

   * Low.  This only causes an update to cups-filters to a version
     that fixes an already identified/resolved problem (LP#1828401),
     which is available in bionic- & xenial-updates since May 2019.

  [Other Info]

   * This is only required in Xenial and Bionic.

   * Trusty doesn't have the ghostscript update that causes the problem.

   * Disco/Eoan have the cups-filters fix that it requires (1.22.5+).

  [1] https://www.debian.org/doc/debian-policy/ch-relationships.html
  #packages-which-break-other-packages-breaks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1848210/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1847924] Re: Introduce broken state parsing to mdadm

2019-10-15 Thread Eric Desrochers
** Also affects: mdadm (Ubuntu Ff-series)
   Importance: Undecided
   Status: New

** Changed in: mdadm (Ubuntu Ff-series)
   Status: New => Confirmed

** Changed in: mdadm (Ubuntu Ff-series)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: mdadm (Ubuntu Ff-series)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1847924

Title:
  Introduce broken state parsing to mdadm

Status in mdadm package in Ubuntu:
  In Progress
Status in mdadm source package in Bionic:
  In Progress
Status in mdadm source package in Disco:
  In Progress
Status in mdadm source package in Eoan:
  In Progress
Status in mdadm source package in FF-Series:
  Confirmed

Bug description:
  [Impact]

  * Currently, mounted raid0/md-linear arrays have no indication/warning
  when one or more members are removed or suffer from some non-
  recoverable error condition. The mdadm tool shows "clean" state
  regardless if a member was removed.

  * The patch proposed in this SRU addresses this issue by introducing a
  new state "broken", which is analog to "clean" but indicates that
  array is not in a good/correct state. The commit, available upstream
  as 43ebc910 ("mdadm: Introduce new array state 'broken' for
  raid0/linear") [0], was extensively discussed and received a good
  amount of reviews/analysis by both the current mdadm maintainer as
  well as an old maintainer.

  * One important note here is that this patch requires a counter-part in the 
kernel to be fully functional, which was SRUed in LP: #1847773.
  It works fine/transparently without this kernel counter-part though.

  [Test case]

  * To test this patch, create a raid0 or linear md array on Linux using
  mdadm, like: "mdadm --create md0 --level=0 --raid-devices=2
  /dev/nvme0n1 /dev/nvme1n1";

  * Format the array using a FS of your choice (for example ext4) and
  mount the array;

  * Remove one member of the array, for example using sysfs interface
  (for nvme: echo 1 > /sys/block/nvme0n1/device/device/remove, for scsi:
  echo 1 > /sys/block/sdX/device/delete);

  * Without this patch, the array state shown by "mdadm --detail" is
  "clean", regardless a member is missing/failed.

  [Regression potential]

  * There's not much potential regression here; we just exhibit arrays'
  state as "broken" if they have one or more missing/failed members; we
  believe the most common "issue" that could be reported from this patch
  is if an userspace tool rely on the array status as being always
  "clean" even for broken devices, then such tool may behave differently
  with this patch.

  * Note that we *proactively* skipped Xenial SRU here, in order to
  prevent potential regressions - Xenial mdadm tool lacks code
  infrastructure used by this patch, so the decision was for
  safety/stability, by only SRUing Bionic / Disco / Eoan mdadm versions.

  [0]
  https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/commit/?id=43ebc910

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1847924/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1846138] Re: backport mod_reqtimeout with handshake support

2019-10-10 Thread Eric Desrochers
[VERIFICATION XENIAL - Part 2]
* Feedback #3:
"
I also tested and now it works perfectly, I can count the seconds which I 
configure for the handshake timeout and the connection is terminated exactly 
when the handshake timeout expires 

Great job!
"

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1846138

Title:
  backport mod_reqtimeout with handshake support

Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Xenial:
  Fix Committed
Status in apache2 source package in Bionic:
  Fix Released
Status in apache2 source package in Disco:
  Fix Released

Bug description:
  [Impact]

  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite
  because there are no free connections. The connections will be in
  state "established" ~ 2 hours.

  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy

  This issue can be resolved by enabling the parameter(mod_reqtimeout).
  This parameter is available in apache 2.4.39 (released on 2019-04-01).

  [Test Case]

  This test case has been brought to my attention by an impacted user:
  "
  You must have an apache2 server, with an haproxy in front of it, and you 
initiate SSL connections with "nc" between 50 and 8000 connections and because 
the SSL connection process is never finished all those connections get stucked 
and never timeout.
  "

  Reproducer (Thanks to Szilard):
  https://pastebin.ubuntu.com/p/6Hk64CDc7H/

  [Regression Potential]

  * The backport already exist in Bionic/Disco (done by security team
  via the security channel)

  * It is also backported upstream into 2.4 (branch : 2.4.x)

  * It was tested pre-release by an impacted user, and the outcome was
  positive:

  "I have tested the below packages for enabling handshake
  parameter(mod_reqtimeout) in apache. Looks the package is working
  fine. "

  * Local autopkgtest inside qemu, revealed no issues:
  autopkgtest [12:09:48]:  summary
  duplicate-module-load PASS
  htcacheclean PASS
  ssl-passphrase   PASS
  chroot   PASS

  [Other Info]

  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.

  Lack of this feature was exhausting free connections when sent
  corrupted packets.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1846138/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1846138] Re: backport mod_reqtimeout with handshake support

2019-10-10 Thread Eric Desrochers
[VERIFICATION XENIAL]

* Feedback #1:

>From an impacted user:
"
They confirmed that from their perspective the test is OK, and the apache2 
packages are delivering expected result
"

* Feedback #2:
>From SustEng Mauricio (mfo):
"
The backport in xenial-proposed worked exactly as eoan 
(with the AcceptFilter bits mentioned in previous comment)
...
"

** Description changed:

  [Impact]
  
  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite because
  there are no free connections. The connections will be in state
  "established" ~ 2 hours.
  
  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy
  
  This issue can be resolved by enabling the parameter(mod_reqtimeout).
  This parameter is available in apache 2.4.39 (released on 2019-04-01).
  
  [Test Case]
  
  This test case has been brought to my attention by an impacted user:
  "
  You must have an apache2 server, with an haproxy in front of it, and you 
initiate SSL connections with "nc" between 50 and 8000 connections and because 
the SSL connection process is never finished all those connections get stucked 
and never timeout.
  "
  
+ Reproducer (Thanks to Szilard):
+ https://pastebin.ubuntu.com/p/6Hk64CDc7H/
+ 
  [Regression Potential]
  
  * The backport already exist in Bionic/Disco (done by security team via
  the security channel)
  
  * It is also backported upstream into 2.4 (branch : 2.4.x)
  
  * It was tested pre-release by an impacted user, and the outcome was
  positive:
  
  "I have tested the below packages for enabling handshake
  parameter(mod_reqtimeout) in apache. Looks the package is working fine.
  "
  
  * Local autopkgtest inside qemu, revealed no issues:
  autopkgtest [12:09:48]:  summary
  duplicate-module-load PASS
  htcacheclean PASS
  ssl-passphrase   PASS
  chroot   PASS
  
- 
  [Other Info]
  
  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.
  
  Lack of this feature was exhausting free connections when sent corrupted
  packets.

** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1846138

Title:
  backport mod_reqtimeout with handshake support

Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Xenial:
  Fix Committed
Status in apache2 source package in Bionic:
  Fix Released
Status in apache2 source package in Disco:
  Fix Released

Bug description:
  [Impact]

  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite
  because there are no free connections. The connections will be in
  state "established" ~ 2 hours.

  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy

  This issue can be resolved by enabling the parameter(mod_reqtimeout).
  This parameter is available in apache 2.4.39 (released on 2019-04-01).

  [Test Case]

  This test case has been brought to my attention by an impacted user:
  "
  You must h

[Sts-sponsors] [Bug 1846138] Re: backport mod_reqtimeout with handshake support

2019-10-08 Thread Eric Desrochers
** Description changed:

  [Impact]
  
  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite because
  there are no free connections. The connections will be in state
  "established" ~ 2 hours.
  
  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy
  
  This issue can be resolved by enabling the parameter(mod_reqtimeout).
  This parameter is available in apache 2.4.39 (released on 2019-04-01).
  
  [Test Case]
  
  This test case has been brought to my attention by an impacted user:
  "
  You must have an apache2 server, with an haproxy in front of it, and you 
initiate SSL connections with "nc" between 50 and 8000 connections and because 
the SSL connection process is never finished all those connections get stucked 
and never timeout.
  "
  
  [Regression Potential]
  
  * The backport already exist in Bionic/Disco (done by security team via
  the security channel)
  
  * It is also backported upstream into 2.4 (branch : 2.4.x)
  
  * It was tested pre-release by an impacted user, and the outcome was
  positive:
  
  "I have tested the below packages for enabling handshake
  parameter(mod_reqtimeout) in apache. Looks the package is working fine.
  "
  
+ * Local autopkgtest inside qemu, revealed no issues:
+ autopkgtest [12:09:48]:  summary
+ duplicate-module-load PASS
+ htcacheclean PASS
+ ssl-passphrase   PASS
+ chroot   PASS
+ 
+ 
  [Other Info]
  
  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.
  
  Lack of this feature was exhausting free connections when sent corrupted
  packets.

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1846138

Title:
  backport mod_reqtimeout with handshake support

Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Xenial:
  In Progress
Status in apache2 source package in Bionic:
  Fix Released
Status in apache2 source package in Disco:
  Fix Released

Bug description:
  [Impact]

  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite
  because there are no free connections. The connections will be in
  state "established" ~ 2 hours.

  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy

  This issue can be resolved by enabling the parameter(mod_reqtimeout).
  This parameter is available in apache 2.4.39 (released on 2019-04-01).

  [Test Case]

  This test case has been brought to my attention by an impacted user:
  "
  You must have an apache2 server, with an haproxy in front of it, and you 
initiate SSL connections with "nc" between 50 and 8000 connections and because 
the SSL connection process is never finished all those connections get stucked 
and never timeout.
  "

  [Regression Potential]

  * The backport already exist in Bionic/Disco (done by security team
  via the security channel)

  * It is also backported upstream into 2.4 (branch : 2.4.x)

  * It was tested pre-release by an impacted user, and the outcome was
  positive:

  

[Sts-sponsors] [Bug 1846138] Re: backport mod_reqtimeout with handshake support

2019-10-08 Thread Eric Desrochers
** Description changed:

  ## DRAFT ##
  [Impact]
  
  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite because
  there are no free connections. The connections will be in state
  "established" ~ 2 hours.
  
  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy
  
  This issue can be resolved by enabling the parameter(mod_reqtimeout).
  This parameter is available in apache 2.4.39 (released on 2019-04-01).
  
  [Test Case]
  
+ This test case has been brought to my attention by an impacted user:
+ "
+ You must have an apache2 server, with an haproxy in front of it, and you 
initiate SSL connections with "nc" between 50 and 8000 connections and because 
the SSL connection process is never finished all those connections get stucked 
and never timeout.
+ "
+ 
  [Regression Potential]
  
  * The backport already exist in Bionic/Disco (done by security team via
  the security channel)
  
  * It is also backported upstream into 2.4 (branch : 2.4.x)
- 
  
  [Other Info]
  
  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.
  
  Lack of this feature was exhausting free connections when sent corrupted
  packets.

** Description changed:

- ## DRAFT ##
  [Impact]
  
  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite because
  there are no free connections. The connections will be in state
  "established" ~ 2 hours.
  
  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy
  
  This issue can be resolved by enabling the parameter(mod_reqtimeout).
  This parameter is available in apache 2.4.39 (released on 2019-04-01).
  
  [Test Case]
  
  This test case has been brought to my attention by an impacted user:
  "
  You must have an apache2 server, with an haproxy in front of it, and you 
initiate SSL connections with "nc" between 50 and 8000 connections and because 
the SSL connection process is never finished all those connections get stucked 
and never timeout.
  "
  
  [Regression Potential]
  
  * The backport already exist in Bionic/Disco (done by security team via
  the security channel)
  
  * It is also backported upstream into 2.4 (branch : 2.4.x)
  
  [Other Info]
  
  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.
  
  Lack of this feature was exhausting free connections when sent corrupted
  packets.

** Description changed:

  [Impact]
  
  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite because
  there are no free connections. The connections will be in state
  "established" ~ 2 hours.
  
  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443

[Sts-sponsors] [Bug 1846138] Re: backport mod_reqtimeout with handshake support

2019-10-08 Thread Eric Desrochers
** Description changed:

  ## DRAFT ##
  [Impact]
  
  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite because
  there are no free connections. The connections will be in state
  "established" ~ 2 hours.
  
- 1.2. Detailed trouble description 
- # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy 
- tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy 
+ 1.2. Detailed trouble description
+ # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy
  
- 
- This issue can be resolved by enabling the parameter(mod_reqtimeout). This 
parameter is available in apache 2.4.39 (released on 2019-04-01).
+ This issue can be resolved by enabling the parameter(mod_reqtimeout).
+ This parameter is available in apache 2.4.39 (released on 2019-04-01).
  
  [Test Case]
  
  [Regression Potential]
+ 
+ * The backport already exist in Bionic/Disco (done by security team via
+ the security channel)
+ 
+ * It is also backported upstream into 2.4 (branch : 2.4.x)
+ 
  
  [Other Info]
  
  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.
  
  Lack of this feature was exhausting free connections when sent corrupted
  packets.

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1846138

Title:
  backport mod_reqtimeout with handshake support

Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Xenial:
  In Progress
Status in apache2 source package in Bionic:
  Fix Released
Status in apache2 source package in Disco:
  Fix Released

Bug description:
  ## DRAFT ##
  [Impact]

  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite
  because there are no free connections. The connections will be in
  state "established" ~ 2 hours.

  1.2. Detailed trouble description
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy

  This issue can be resolved by enabling the parameter(mod_reqtimeout).
  This parameter is available in apache 2.4.39 (released on 2019-04-01).

  [Test Case]

  [Regression Potential]

  * The backport already exist in Bionic/Disco (done by security team
  via the security channel)

  * It is also backported upstream into 2.4 (branch : 2.4.x)

  
  [Other Info]

  [Original description]
  Backport the handshake feature in mod_reqtimeout 

[Sts-sponsors] [Bug 1846138] Re: backport mod_reqtimeout with handshake support

2019-10-08 Thread Eric Desrochers
** Changed in: apache2 (Ubuntu Xenial)
   Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1846138

Title:
  backport mod_reqtimeout with handshake support

Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Xenial:
  In Progress
Status in apache2 source package in Bionic:
  Fix Released
Status in apache2 source package in Disco:
  Fix Released

Bug description:
  ## DRAFT ##
  [Impact]

  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite
  because there are no free connections. The connections will be in
  state "established" ~ 2 hours.

  1.2. Detailed trouble description 
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy 

  
  This issue can be resolved by enabling the parameter(mod_reqtimeout). This 
parameter is available in apache 2.4.39 (released on 2019-04-01).

  [Test Case]

  [Regression Potential]

  [Other Info]

  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.

  Lack of this feature was exhausting free connections when sent
  corrupted packets.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1846138/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1846138] Re: backport mod_reqtimeout with handshake support

2019-10-08 Thread Eric Desrochers
** Description changed:

  ## DRAFT ##
- [Impact] 
+ [Impact]
+ 
+ When running TCP Defensics suite which sends corrupt packages towards
+ vip__public port 443, the suite is hanging after the half suite because
+ there are no free connections. The connections will be in state
+ "established" ~ 2 hours.
+ 
+ 1.2. Detailed trouble description 
+ # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443 
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy 
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy 
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy 
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy 
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy 
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy 
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy 
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy 
+ tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy 
+ 
+ 
+ This issue can be resolved by enabling the parameter(mod_reqtimeout). This 
parameter is available in apache 2.4.39 (released on 2019-04-01).
  
  [Test Case]
  
  [Regression Potential]
- 
  
  [Other Info]
  
  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.
  
  Lack of this feature was exhausting free connections when sent corrupted
  packets.

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1846138

Title:
  backport mod_reqtimeout with handshake support

Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Xenial:
  Confirmed
Status in apache2 source package in Bionic:
  Fix Released
Status in apache2 source package in Disco:
  Fix Released

Bug description:
  ## DRAFT ##
  [Impact]

  When running TCP Defensics suite which sends corrupt packages towards
  vip__public port 443, the suite is hanging after the half suite
  because there are no free connections. The connections will be in
  state "established" ~ 2 hours.

  1.2. Detailed trouble description 
  # ip netns exec haproxy netstat -npea | grep XXX.XXX.XXX.XXX | grep -i 
establish | grep 443 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YYY.YY.YYY.YY:2940 ESTABLISHED 115 81148003 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:24979 ESTABLISHED 115 81802005 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:19394 ESTABLISHED 115 81782263 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:13931 ESTABLISHED 115 81752052 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:12668 ESTABLISHED 115 81743719 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2961 ESTABLISHED 115 81139548 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:8918 ESTABLISHED 115 81738132 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:2957 ESTABLISHED 115 81148041 
29817/haproxy 
  tcp 0 0 XXX.XXX.XXX.XXX:443 YY.YY.YYY.YY:10552 ESTABLISHED 115 81744903 
29817/haproxy 

  
  This issue can be resolved by enabling the parameter(mod_reqtimeout). This 
parameter is available in apache 2.4.39 (released on 2019-04-01).

  [Test Case]

  [Regression Potential]

  [Other Info]

  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.

  Lack of this feature was exhausting free connections when sent
  corrupted packets.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1846138/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1846138] Re: backport mod_reqtimeout with handshake support

2019-10-08 Thread Eric Desrochers
** Changed in: apache2 (Ubuntu Disco)
   Status: New => Fix Released

** Changed in: apache2 (Ubuntu Bionic)
   Status: New => Confirmed

** Changed in: apache2 (Ubuntu Bionic)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1846138

Title:
  backport mod_reqtimeout with handshake support

Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Xenial:
  Confirmed
Status in apache2 source package in Bionic:
  Fix Released
Status in apache2 source package in Disco:
  Fix Released

Bug description:
  ## DRAFT ##
  [Impact] 

  [Test Case]

  [Regression Potential]

  
  [Other Info]

  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.

  Lack of this feature was exhausting free connections when sent
  corrupted packets.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1846138/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1846138] Re: backport mod_reqtimeout with handshake support

2019-10-08 Thread Eric Desrochers
** Changed in: apache2 (Ubuntu)
   Status: New => Fix Released

** Changed in: apache2 (Ubuntu)
 Assignee: Jesse Williamson (chardan) => (unassigned)

** Changed in: apache2 (Ubuntu Xenial)
 Assignee: (unassigned) => Jesse Williamson (chardan)

** Description changed:

- Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to
- Apache 2.4.18.
+ ## DRAFT ##
+ [Impact] 
+ 
+ [Test Case]
+ 
+ [Regression Potential]
+ 
+ 
+ [Other Info]
+ 
+ [Original description]
+ Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.
  
  Lack of this feature was exhausting free connections when sent corrupted
  packets.

** Changed in: apache2 (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: apache2 (Ubuntu Xenial)
   Status: New => Confirmed

** Also affects: apache2 (Ubuntu Disco)
   Importance: Undecided
   Status: New

** Also affects: apache2 (Ubuntu Bionic)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1846138

Title:
  backport mod_reqtimeout with handshake support

Status in apache2 package in Ubuntu:
  Fix Released
Status in apache2 source package in Xenial:
  Confirmed
Status in apache2 source package in Bionic:
  Fix Released
Status in apache2 source package in Disco:
  Fix Released

Bug description:
  ## DRAFT ##
  [Impact] 

  [Test Case]

  [Regression Potential]

  
  [Other Info]

  [Original description]
  Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 
2.4.18.

  Lack of this feature was exhausting free connections when sent
  corrupted packets.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1846138/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1796501] Re: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

2019-10-04 Thread Eric Desrochers
** Tags added: sts-sponsor-ddstreet

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1796501

Title:
  systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  In Progress

Bug description:
  I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't 
exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the 
following steps:
  1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size.
  2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit.
  3. Ask upstream for SOA of test.asdf. with EDNS0.
  4. Ask upstream for SOA of test.asdf. without EDNS0.
  5. Repeat 1-4 for DS of test.asdf.
  6. Repeat 1-5 for asdf.
  7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size.
  8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size.

  The upstream returns an unfragmented NXDOMAIN response for steps 1-6,
  an unfragmented NOERROR response for step 7 and a fragmented NOERROR
  response for step 8 which is the correct behaviour. DNSSEC records are
  included in the response if the DO-bit in the request was set.

  systemd-resolved should take the response from step 1 and start with
  validation instead of starting useless retries with reduced feture
  set. Step 3 and 4 are completely useless and probably lead to the
  SERVFAIL because I have configured it with DNSSEC=yes to prevent
  downgrade attacks.

  This regression seems to be caused by the patch resolved-Mitigate-
  DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic
  should only be executed if it is configured as DNSSEC=allow-downgrade
  or DNSSEC=no. See also
  https://github.com/systemd/systemd/pull/8608#issuecomment-396927885.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1842437] Re: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev

2019-10-04 Thread Eric Desrochers
[STS-Sponsor]

Sponsored in Bionic.

Thanks Mauricio for your great work on this bug and the FTBFS situation.

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1842437

Title:
  Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem
  with udev

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Users / systemd can fail to mount a filesystem by UUID
 (e.g., during boot, triggering emergency shell prompt)
 if the magic bytes for the nilfs filesystem are written
 to the right place in a partition of another filesystem,
 (for whatever reason or coincidence).

   * Note this can happen after the filesystem/mount is working
 correctly, so a change of behavior/problem can potentially
 be noticed when trying to mount the filesystem again, which
 can very well be the next time the system boots.

   * This happens because if udev blkid detects more than one
 filesystem, it does not print the UUID env vars required
 to create the /dev/disk/by-id symlinks and other things.

   * The fix enhances the check for valid nilfs superblock by
 specifically checking a value read from disk to be valid/
 within a value range, which addresses this one occurrence
 and prevents a lot more.

  [Test Case]

   * Synthetic test case written for this problem on comment #6.

  [Regression Potential]

   * Low.  The code is contained in the probe for the nilfs filesystem.

   * This just makes it be more restrictive about the possibly valid
 values for a few bytes read from disk (that now need to be within
 the acceptable range of valid values) so this only decreases false-
 positives, and cannot increase false-negatives of valid filesystems.

  [Original Description]

  The nilfs filesystem has a backup superblock at the end of the device.

  If the magic number is coincidentally found at the right position
  and the filesystem is on a partition/not-wholedisk device,
  the only check left is for checksum verification,
  which is explicitly ignored in 'udev built-in blkid'.

  This causes blkid to detect one actually valid filesystem with a
  superblock at the beginning of the device (e.g., ext4), and then
  an invalid nilfs2 filesystem due to a coincidental magic number
  at the end of the device.

  And this causes blkid to break out of the safeprobe routine
  (which expects a single filesystem to be detected), and not
  print the UUIDs, thus not creating /dev/disk/by-uuid/ links
  which prevent mounting the partition by-uuid at boot time,
  causing emergency shell/boot failures.

  This upstream fix resolved the problem by introducing a check
  for the 'bytes' paramenters in the superblock, which is read
  from disk, and turns out to have an out-of-range value.

  - 'liblkid: Add length check in probe_nilfs2 before crc32'
  
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2

  $ git describe --contains ac681a310c32319423297544833932f4d689a7a2
  v2.29-rc1~172

  Xenial, which is v2.27.1-based, is the only release that needs it.
  Bionic is v2.31.1, so all post-Xenial supported releases have it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1842437/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1838555] Re: nvme-cli 1.5 in Bionic does not support Micron NVME drives

2019-10-04 Thread Eric Desrochers
[sts-sponsor]

Since this is a "HWE/new feature", please read
https://wiki.ubuntu.com/StableReleaseUpdates#Other_safe_cases

and see if your patch fits inside the policy.

Also, I would like to see more justification/testings (detailed steps,
output, ...) using a micron nmve drive type, local autopkgtest (if any),
software testsuite report (if any), ...

Anything that would support that the regression potential is low, and
that the micro plugin is working as expected.

I would also suggest to look upstream, and see if there was any major
bugfix, CVE, ... after the micron add support, that could be a red flag
or simply worth be adding inside this SRU to-be.

Regards,
Eric


** Changed in: nvme-cli (Ubuntu Bionic)
   Importance: Medium => Wishlist

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1838555

Title:
  nvme-cli 1.5 in Bionic does not support Micron NVME drives

Status in nvme-cli package in Ubuntu:
  Fix Released
Status in nvme-cli source package in Bionic:
  In Progress

Bug description:
  [Impact]

  This was discovered at a customer site and affects all of their Bionic
  installs that have Micron NVMe drives.

  The version of nvme-cli present in Ubuntu 18.04 Bionic Beaver (1.5-1)
  does not include support to manage updating the firmware on Micron
  NVMe drives. The missing support also means that the customer cannot
  format their block size to 4k, as needed by Ceph.

  Version 1.6-1 and later versions do include this support, and can be
  used by rebuilding the package from upstream source as a static
  binary. This is not ideal, but a workaround.

  [Test Case]

  Install nvme-cli from Bionic, and attempt to update firmware for any
  Micron NVMe drive, using a command similar to the below. It will fail,
  as the drive is not supported.

  $ nvme micron select-download /dev/n1 --fw
  ./Micron_9200_FW-101008S0.tar --select=ALL

  With the upstream commit patched into place, we can verify the
  subcommands function with:

  $ nvme micron

  This will display the help screen and a list of supported commands.

  $ nvme micron select-download

  This will show the help page for firmware updating, and required
  arguments. Running again with the arguments from the first example
  will update the firmware on the drives successfully.

  You can find a test package for Bionic here:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf237119-test

  [Regression Potential]

  The opportunity for regression is low. The Micron support is
  implemented as a plugin for the application and the changes are more
  or less standalone. The code paths can only be accessed via "nvme
  micron" subcommands.

  If a regression happens, then users should refrain from running "nvme
  micron" commands while the package is fixed.

  [Other Info]

  The commit that adds support for Micron drives is:

  commit 0124daa3331602365d009a9e8229454c41931c07
  Author: Stephen Tubbs 
  Date:   Wed May 9 07:06:03 2018 -0700
  Subject: Add support for Micron plugin

  https://github.com/linux-nvme/nvme-
  cli/commit/0124daa3331602365d009a9e8229454c41931c07

  This commit landed in version 1.6, and is present in the following
  distros:

  $ rmadison nvme-cli -a amd64
  nvme-cli | 1.5-1 | bionic/universe | amd64
  nvme-cli | 1.6-1 | cosmic/universe | amd64
  nvme-cli | 1.7-1 | disco/universe  | amd64
  nvme-cli | 1.7-1 | eoan/universe   | amd64

  There is a minor backport required for the commit into version 1.5,
  and that is in the Makefile. Some other plugins which are not
  currently present are in the patch, and needed to be removed from the
  OBJS line.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nvme-cli/+bug/1838555/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1838555] Re: nvme-cli 1.5 in Bionic does not support Micron NVME drives

2019-10-01 Thread Eric Desrochers
** Changed in: nvme-cli (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1838555

Title:
  nvme-cli 1.5 in Bionic does not support Micron NVME drives

Status in nvme-cli package in Ubuntu:
  Fix Released
Status in nvme-cli source package in Bionic:
  In Progress

Bug description:
  [Impact]

  This was discovered at a customer site and affects all of their Bionic
  installs that have Micron NVMe drives.

  The version of nvme-cli present in Ubuntu 18.04 Bionic Beaver (1.5-1)
  does not include support to manage updating the firmware on Micron
  NVMe drives. The missing support also means that the customer cannot
  format their block size to 4k, as needed by Ceph.

  Version 1.6-1 and later versions do include this support, and can be
  used by rebuilding the package from upstream source as a static
  binary. This is not ideal, but a workaround.

  [Test Case]

  Install nvme-cli from Bionic, and attempt to update firmware for any
  Micron NVMe drive, using a command similar to the below. It will fail,
  as the drive is not supported.

  $ nvme micron select-download /dev/n1 --fw
  ./Micron_9200_FW-101008S0.tar --select=ALL

  With the upstream commit patched into place, we can verify the
  subcommands function with:

  $ nvme micron

  This will display the help screen and a list of supported commands.

  $ nvme micron select-download

  This will show the help page for firmware updating, and required
  arguments. Running again with the arguments from the first example
  will update the firmware on the drives successfully.

  You can find a test package for Bionic here:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf237119-test

  [Regression Potential]

  The opportunity for regression is low. The Micron support is
  implemented as a plugin for the application and the changes are more
  or less standalone. The code paths can only be accessed via "nvme
  micron" subcommands.

  If a regression happens, then users should refrain from running "nvme
  micron" commands while the package is fixed.

  [Other Info]

  The commit that adds support for Micron drives is:

  commit 0124daa3331602365d009a9e8229454c41931c07
  Author: Stephen Tubbs 
  Date:   Wed May 9 07:06:03 2018 -0700
  Subject: Add support for Micron plugin

  https://github.com/linux-nvme/nvme-
  cli/commit/0124daa3331602365d009a9e8229454c41931c07

  This commit landed in version 1.6, and is present in the following
  distros:

  $ rmadison nvme-cli -a amd64
  nvme-cli | 1.5-1 | bionic/universe | amd64
  nvme-cli | 1.6-1 | cosmic/universe | amd64
  nvme-cli | 1.7-1 | disco/universe  | amd64
  nvme-cli | 1.7-1 | eoan/universe   | amd64

  There is a minor backport required for the commit into version 1.5,
  and that is in the Makefile. Some other plugins which are not
  currently present are in the patch, and needed to be removed from the
  OBJS line.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nvme-cli/+bug/1838555/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1842437] Re: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev

2019-09-26 Thread Eric Desrochers
@mfo,

I will gladly resume the sponsoring as soon as LP: #1844504 is "Fix
Released" and util-linux builds fine.

Thanks for your good work on this Mauricio !

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1842437

Title:
  Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem
  with udev

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Users / systemd can fail to mount a filesystem by UUID
 (e.g., during boot, triggering emergency shell prompt)
 if the magic bytes for the nilfs filesystem are written
 to the right place in a partition of another filesystem,
 (for whatever reason or coincidence).

   * Note this can happen after the filesystem/mount is working
 correctly, so a change of behavior/problem can potentially
 be noticed when trying to mount the filesystem again, which
 can very well be the next time the system boots.

   * This happens because if udev blkid detects more than one
 filesystem, it does not print the UUID env vars required
 to create the /dev/disk/by-id symlinks and other things.

   * The fix enhances the check for valid nilfs superblock by
 specifically checking a value read from disk to be valid/
 within a value range, which addresses this one occurrence
 and prevents a lot more.

  [Test Case]

   * Synthetic test case written for this problem on comment #6.

  [Regression Potential]

   * Low.  The code is contained in the probe for the nilfs filesystem.

   * This just makes it be more restrictive about the possibly valid
 values for a few bytes read from disk (that now need to be within
 the acceptable range of valid values) so this only decreases false-
 positives, and cannot increase false-negatives of valid filesystems.

  [Original Description]

  The nilfs filesystem has a backup superblock at the end of the device.

  If the magic number is coincidentally found at the right position
  and the filesystem is on a partition/not-wholedisk device,
  the only check left is for checksum verification,
  which is explicitly ignored in 'udev built-in blkid'.

  This causes blkid to detect one actually valid filesystem with a
  superblock at the beginning of the device (e.g., ext4), and then
  an invalid nilfs2 filesystem due to a coincidental magic number
  at the end of the device.

  And this causes blkid to break out of the safeprobe routine
  (which expects a single filesystem to be detected), and not
  print the UUIDs, thus not creating /dev/disk/by-uuid/ links
  which prevent mounting the partition by-uuid at boot time,
  causing emergency shell/boot failures.

  This upstream fix resolved the problem by introducing a check
  for the 'bytes' paramenters in the superblock, which is read
  from disk, and turns out to have an out-of-range value.

  - 'liblkid: Add length check in probe_nilfs2 before crc32'
  
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2

  $ git describe --contains ac681a310c32319423297544833932f4d689a7a2
  v2.29-rc1~172

  Xenial, which is v2.27.1-based, is the only release that needs it.
  Bionic is v2.31.1, so all post-Xenial supported releases have it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1842437/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1836635] Re: Bionic: support for Solarflare X2542 network adapter (sfc driver)

2019-09-25 Thread Eric Desrochers
Sponsored in Bionic.

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1836635

Title:
  Bionic: support for Solarflare X2542 network adapter (sfc driver)

Status in debian-installer package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid
Status in debian-installer source package in Bionic:
  In Progress
Status in linux source package in Bionic:
  Fix Released
Status in debian-installer source package in Cosmic:
  Invalid
Status in linux source package in Cosmic:
  Invalid
Status in debian-installer source package in Disco:
  Invalid
Status in linux source package in Disco:
  Invalid
Status in debian-installer source package in Eoan:
  Invalid
Status in linux source package in Eoan:
  Invalid

Bug description:
  [Impact]

   * Support for Solarflare X2542 network adapter
     (Medford2 / SFC9250) in the Bionic sfc driver.

   * This network adapter is present on recent hardware,
     at least HP 2019 and Dell PowerEdge R740xd systems.

   * On recent-hardware deployments that would rather use
     the Bionic LTS / GA supported kernel and cannot move
     to HWE kernels this adapter is non functional at all.

  [Test Case]

   * The X2542 adapter has been exercised with iperf3 and nc
     across 2 hosts on 25G link speed w/ MTUs 1400/1500/9000
     on both directions, for 1 week.

     Its performance is on par with the Cosmic 4.18 kernel
     (which contains all these patches) and the out-of-tree
     driver from the vendor.

   * The 7000 series adapter (for regression testing an old model,
     supported previously) has been exercised with iperf and netperf
     (TCP_STREAM, UDP_STREAM, TCP_RR, UDP_RR, and TCP_CRR) in one
     host (client/server in different adapter ports isolated with
     network namespaces, so traffic goes through the network switch),
     on 10G link speed on MTUs 1500/9000, for 1 weekend.

     No regressions observed between the original and test kernels.

  [Regression Potential]

   * The patchset touches a lot of the sfc driver, so the potential
     for regression definitely exists. Thus, a lot of consideration
     and testing happened:

   * It has been tested on other adapter which uses the old code,
     and no regressions were found so far (see 7000 series above).

   * The patchset is exclusively cherry-picks, no single backport.

   * The patchset essentially moves the Bionic driver up in the
     upstream 'git log --oneline -- drivers/net/ethernet/sfc/':

     - since commit d4a7a8893d4c ("sfc: pass valid pointers from 
efx_enqueue_unwind")
     - until commit 7f61e6c6279b ("sfc: support FEC configuration through 
ethtool")
     - except for 2 commits (not needed / unrelated)
   - commit 42356d9a137b ("sfc: support RSS spreading of ethtool ntuple 
filters")
   - commit 9baeb5eb1f83 ("sfc: falcon: remove duplicated bit-wise or of 
LOOPBACK_SGMII")
     - plus 2 more recent commits (fixes)
   - commit 458bd99e4974 ("sfc: remove ctpio_dmabuf_start from stats")
   - commit 0c235113b3c4 ("sfc: stop the TX queue before pushing new 
buffers")

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1836635/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1842437] Re: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev

2019-09-24 Thread Eric Desrochers
LP: #1844504

** Tags added: ftbfs

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1842437

Title:
  Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem
  with udev

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Users / systemd can fail to mount a filesystem by UUID
 (e.g., during boot, triggering emergency shell prompt)
 if the magic bytes for the nilfs filesystem are written
 to the right place in a partition of another filesystem,
 (for whatever reason or coincidence).

   * Note this can happen after the filesystem/mount is working
 correctly, so a change of behavior/problem can potentially
 be noticed when trying to mount the filesystem again, which
 can very well be the next time the system boots.

   * This happens because if udev blkid detects more than one
 filesystem, it does not print the UUID env vars required
 to create the /dev/disk/by-id symlinks and other things.

   * The fix enhances the check for valid nilfs superblock by
 specifically checking a value read from disk to be valid/
 within a value range, which addresses this one occurrence
 and prevents a lot more.

  [Test Case]

   * Synthetic test case written for this problem on comment #6.

  [Regression Potential]

   * Low.  The code is contained in the probe for the nilfs filesystem.

   * This just makes it be more restrictive about the possibly valid
 values for a few bytes read from disk (that now need to be within
 the acceptable range of valid values) so this only decreases false-
 positives, and cannot increase false-negatives of valid filesystems.

  [Original Description]

  The nilfs filesystem has a backup superblock at the end of the device.

  If the magic number is coincidentally found at the right position
  and the filesystem is on a partition/not-wholedisk device,
  the only check left is for checksum verification,
  which is explicitly ignored in 'udev built-in blkid'.

  This causes blkid to detect one actually valid filesystem with a
  superblock at the beginning of the device (e.g., ext4), and then
  an invalid nilfs2 filesystem due to a coincidental magic number
  at the end of the device.

  And this causes blkid to break out of the safeprobe routine
  (which expects a single filesystem to be detected), and not
  print the UUIDs, thus not creating /dev/disk/by-uuid/ links
  which prevent mounting the partition by-uuid at boot time,
  causing emergency shell/boot failures.

  This upstream fix resolved the problem by introducing a check
  for the 'bytes' paramenters in the superblock, which is read
  from disk, and turns out to have an out-of-range value.

  - 'liblkid: Add length check in probe_nilfs2 before crc32'
  
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2

  $ git describe --contains ac681a310c32319423297544833932f4d689a7a2
  v2.29-rc1~172

  Xenial, which is v2.27.1-based, is the only release that needs it.
  Bionic is v2.31.1, so all post-Xenial supported releases have it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1842437/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1842437] Re: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev

2019-09-17 Thread Eric Desrochers
Maybe a kernel change between your successful built and my today
sponsoring build failure ?

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1842437

Title:
  Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem
  with udev

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Users / systemd can fail to mount a filesystem by UUID
 (e.g., during boot, triggering emergency shell prompt)
 if the magic bytes for the nilfs filesystem are written
 to the right place in a partition of another filesystem,
 (for whatever reason or coincidence).

   * Note this can happen after the filesystem/mount is working
 correctly, so a change of behavior/problem can potentially
 be noticed when trying to mount the filesystem again, which
 can very well be the next time the system boots.

   * This happens because if udev blkid detects more than one
 filesystem, it does not print the UUID env vars required
 to create the /dev/disk/by-id symlinks and other things.

   * The fix enhances the check for valid nilfs superblock by
 specifically checking a value read from disk to be valid/
 within a value range, which addresses this one occurrence
 and prevents a lot more.

  [Test Case]

   * Synthetic test case written for this problem on comment #6.

  [Regression Potential]

   * Low.  The code is contained in the probe for the nilfs filesystem.

   * This just makes it be more restrictive about the possibly valid
 values for a few bytes read from disk (that now need to be within
 the acceptable range of valid values) so this only decreases false-
 positives, and cannot increase false-negatives of valid filesystems.

  [Original Description]

  The nilfs filesystem has a backup superblock at the end of the device.

  If the magic number is coincidentally found at the right position
  and the filesystem is on a partition/not-wholedisk device,
  the only check left is for checksum verification,
  which is explicitly ignored in 'udev built-in blkid'.

  This causes blkid to detect one actually valid filesystem with a
  superblock at the beginning of the device (e.g., ext4), and then
  an invalid nilfs2 filesystem due to a coincidental magic number
  at the end of the device.

  And this causes blkid to break out of the safeprobe routine
  (which expects a single filesystem to be detected), and not
  print the UUIDs, thus not creating /dev/disk/by-uuid/ links
  which prevent mounting the partition by-uuid at boot time,
  causing emergency shell/boot failures.

  This upstream fix resolved the problem by introducing a check
  for the 'bytes' paramenters in the superblock, which is read
  from disk, and turns out to have an out-of-range value.

  - 'liblkid: Add length check in probe_nilfs2 before crc32'
  
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2

  $ git describe --contains ac681a310c32319423297544833932f4d689a7a2
  v2.29-rc1~172

  Xenial, which is v2.27.1-based, is the only release that needs it.
  Bionic is v2.31.1, so all post-Xenial supported releases have it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1842437/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1842437] Re: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev

2019-09-17 Thread Eric Desrochers
@mfo,

Unfortunately the build ftbfs as follow:

https://launchpadlibrarian.net/443016838/buildlog_ubuntu-xenial-amd64.util-linux_2.27.1-6ubuntu3.9_BUILDING.txt.gz
...
masks:
script: openpty failed: No such file or directory
Makefile:11211: recipe for target 'check-recursive' failed
make[3]: *** [check-recursive] Terminated
debian/rules:177: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Terminated
debian/rules:54: recipe for target 'build' failed
make: *** [build] Terminated
E: Caught signal ‘Terminated’: terminating immediately
...

Investigation is going to be needed.

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1842437

Title:
  Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem
  with udev

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Users / systemd can fail to mount a filesystem by UUID
 (e.g., during boot, triggering emergency shell prompt)
 if the magic bytes for the nilfs filesystem are written
 to the right place in a partition of another filesystem,
 (for whatever reason or coincidence).

   * Note this can happen after the filesystem/mount is working
 correctly, so a change of behavior/problem can potentially
 be noticed when trying to mount the filesystem again, which
 can very well be the next time the system boots.

   * This happens because if udev blkid detects more than one
 filesystem, it does not print the UUID env vars required
 to create the /dev/disk/by-id symlinks and other things.

   * The fix enhances the check for valid nilfs superblock by
 specifically checking a value read from disk to be valid/
 within a value range, which addresses this one occurrence
 and prevents a lot more.

  [Test Case]

   * Synthetic test case written for this problem on comment #6.

  [Regression Potential]

   * Low.  The code is contained in the probe for the nilfs filesystem.

   * This just makes it be more restrictive about the possibly valid
 values for a few bytes read from disk (that now need to be within
 the acceptable range of valid values) so this only decreases false-
 positives, and cannot increase false-negatives of valid filesystems.

  [Original Description]

  The nilfs filesystem has a backup superblock at the end of the device.

  If the magic number is coincidentally found at the right position
  and the filesystem is on a partition/not-wholedisk device,
  the only check left is for checksum verification,
  which is explicitly ignored in 'udev built-in blkid'.

  This causes blkid to detect one actually valid filesystem with a
  superblock at the beginning of the device (e.g., ext4), and then
  an invalid nilfs2 filesystem due to a coincidental magic number
  at the end of the device.

  And this causes blkid to break out of the safeprobe routine
  (which expects a single filesystem to be detected), and not
  print the UUIDs, thus not creating /dev/disk/by-uuid/ links
  which prevent mounting the partition by-uuid at boot time,
  causing emergency shell/boot failures.

  This upstream fix resolved the problem by introducing a check
  for the 'bytes' paramenters in the superblock, which is read
  from disk, and turns out to have an out-of-range value.

  - 'liblkid: Add length check in probe_nilfs2 before crc32'
  
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2

  $ git describe --contains ac681a310c32319423297544833932f4d689a7a2
  v2.29-rc1~172

  Xenial, which is v2.27.1-based, is the only release that needs it.
  Bionic is v2.31.1, so all post-Xenial supported releases have it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1842437/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1842437] Re: Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem with udev

2019-09-17 Thread Eric Desrochers
** Tags added: sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1842437

Title:
  Xenial: libblkid: fix false-positive/misdetection of nilfs2 filesystem
  with udev

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Users / systemd can fail to mount a filesystem by UUID
 (e.g., during boot, triggering emergency shell prompt)
 if the magic bytes for the nilfs filesystem are written
 to the right place in a partition of another filesystem,
 (for whatever reason or coincidence).

   * Note this can happen after the filesystem/mount is working
 correctly, so a change of behavior/problem can potentially
 be noticed when trying to mount the filesystem again, which
 can very well be the next time the system boots.

   * This happens because if udev blkid detects more than one
 filesystem, it does not print the UUID env vars required
 to create the /dev/disk/by-id symlinks and other things.

   * The fix enhances the check for valid nilfs superblock by
 specifically checking a value read from disk to be valid/
 within a value range, which addresses this one occurrence
 and prevents a lot more.

  [Test Case]

   * Synthetic test case written for this problem on comment #6.

  [Regression Potential]

   * Low.  The code is contained in the probe for the nilfs filesystem.

   * This just makes it be more restrictive about the possibly valid
 values for a few bytes read from disk (that now need to be within
 the acceptable range of valid values) so this only decreases false-
 positives, and cannot increase false-negatives of valid filesystems.

  [Original Description]

  The nilfs filesystem has a backup superblock at the end of the device.

  If the magic number is coincidentally found at the right position
  and the filesystem is on a partition/not-wholedisk device,
  the only check left is for checksum verification,
  which is explicitly ignored in 'udev built-in blkid'.

  This causes blkid to detect one actually valid filesystem with a
  superblock at the beginning of the device (e.g., ext4), and then
  an invalid nilfs2 filesystem due to a coincidental magic number
  at the end of the device.

  And this causes blkid to break out of the safeprobe routine
  (which expects a single filesystem to be detected), and not
  print the UUIDs, thus not creating /dev/disk/by-uuid/ links
  which prevent mounting the partition by-uuid at boot time,
  causing emergency shell/boot failures.

  This upstream fix resolved the problem by introducing a check
  for the 'bytes' paramenters in the superblock, which is read
  from disk, and turns out to have an out-of-range value.

  - 'liblkid: Add length check in probe_nilfs2 before crc32'
  
https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=ac681a310c32319423297544833932f4d689a7a2

  $ git describe --contains ac681a310c32319423297544833932f4d689a7a2
  v2.29-rc1~172

  Xenial, which is v2.27.1-based, is the only release that needs it.
  Bionic is v2.31.1, so all post-Xenial supported releases have it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1842437/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1843036] Re: [regression] SNMP missing disks in hrStorageTable

2019-09-07 Thread Eric Desrochers
** Description changed:

  [IMPACT]
  
  It has been brought to me the following:
  
  Some hosts have started to cause UNKNOWN return values in Nagios for
  checks on their disks. This is because these hosts are no longer
  reporting their disks as part of the SNMP table hrStorageTable
  (1.3.6.1.2.1.25.2.3.1 ) - only memory devices are being reported. The
  affected hosts that I have investigated received updates for SNMP:
  
  Upgrade package libsnmp-base 5.7.3+dfsg-1.8ubuntu3.1 to 
5.7.3+dfsg-1.8ubuntu3.2
  Upgrade package libsnmp30 5.7.3+dfsg-1.8ubuntu3.1 to 5.7.3+dfsg-1.8ubuntu3.2
  Upgrade package snmpd 5.7.3+dfsg-1.8ubuntu3.1 to 5.7.3+dfsg-1.8ubuntu3.2
  
  It seems likely that this package update is the cause.
  
  As debug info, you can see the difference between 2 nearly identical
  servers, one of which received the SNMP updates, and one which did not.
  You can see that the one without the update is returning disks in the
  SNMP output:
  
  # snmpwalk -v2c -cpublic arcprsmt01 1.3.6.1.2.1.25.2.3.1.3
  iso.3.6.1.2.1.25.2.3.1.3.1 = STRING: "Physical memory"
  iso.3.6.1.2.1.25.2.3.1.3.3 = STRING: "Virtual memory"
  iso.3.6.1.2.1.25.2.3.1.3.6 = STRING: "Memory buffers"
  iso.3.6.1.2.1.25.2.3.1.3.7 = STRING: "Cached memory"
  iso.3.6.1.2.1.25.2.3.1.3.8 = STRING: "Shared memory"
  iso.3.6.1.2.1.25.2.3.1.3.10 = STRING: "Swap space"
  iso.3.6.1.2.1.25.2.3.1.3.31 = STRING: "/"
  iso.3.6.1.2.1.25.2.3.1.3.37 = STRING: "/run"
  iso.3.6.1.2.1.25.2.3.1.3.39 = STRING: "/dev/shm"
  iso.3.6.1.2.1.25.2.3.1.3.40 = STRING: "/run/lock"
  iso.3.6.1.2.1.25.2.3.1.3.41 = STRING: "/sys/fs/cgroup"
  iso.3.6.1.2.1.25.2.3.1.3.67 = STRING: "/run/snapd/ns"
  iso.3.6.1.2.1.25.2.3.1.3.70 = STRING: 
"/var/lib/docker/containers/3cad3d36991b677c37b08b374a7bfeceddf36a6b6754edaa1ff687b00111a6b8/mounts/shm"
  iso.3.6.1.2.1.25.2.3.1.3.73 = STRING: 
"/var/lib/docker/containers/c605c4b76dea65d562ba024212a38e24fb710186c499187b6604478b7ff678e9/mounts/shm"
  iso.3.6.1.2.1.25.2.3.1.3.82 = STRING: "/run/user/2002"
  iso.3.6.1.2.1.25.2.3.1.3.253 = STRING: 
"/var/lib/docker/containers/dc74a157fbaaa284e0e5b8ca4afc88769bf625eb796d89a5d26f98a540cabf35/mounts/shm"
  iso.3.6.1.2.1.25.2.3.1.3.256 = STRING: 
"/var/lib/docker/containers/6ce6193433f9c1c95cccbfbbe08a3f3385bdbc4f2e3f0baa02d11baf3866dfd2/mounts/shm"
  iso.3.6.1.2.1.25.2.3.1.3.258 = STRING: "/run/user/1000"
  
  The other, which received SNMP updates, is returning only memory
  devices, such as swap and shmem:
  
  # snmpwalk -v2c -cpublic arcprsmt02 1.3.6.1.2.1.25.2.3.1.3
  iso.3.6.1.2.1.25.2.3.1.3.1 = STRING: "Physical memory"
  iso.3.6.1.2.1.25.2.3.1.3.3 = STRING: "Virtual memory"
  iso.3.6.1.2.1.25.2.3.1.3.6 = STRING: "Memory buffers"
  iso.3.6.1.2.1.25.2.3.1.3.7 = STRING: "Cached memory"
  iso.3.6.1.2.1.25.2.3.1.3.8 = STRING: "Shared memory"
  iso.3.6.1.2.1.25.2.3.1.3.10 = STRING: "Swap space"
  
  [Test Case]
  
  * Install snmp snmpd
  * Configure /etc/snmp/snmpd.conf by adding the following:
-  view   systemonly  included   .1.3.6.1.2.1.25.2.3.1.3
+  view   systemonly  included   .1.3.6.1.2.1.25.2.3.1.3
  * Restart snmpd
  * Use snmpwalk:
-  ** snmpwalk -v2c -cpublic localhost 1.3.6.1.2.1.25.2.3.1.3
+  ** snmpwalk -v2c -cpublic localhost 1.3.6.1.2.1.25.2.3.1.3
  
  Expected behavior is to see the disk as follow:
  "
  iso.3.6.1.2.1.25.2.3.1.3.1 = STRING: "Physical memory"
  iso.3.6.1.2.1.25.2.3.1.3.3 = STRING: "Virtual memory"
  iso.3.6.1.2.1.25.2.3.1.3.6 = STRING: "Memory buffers"
  iso.3.6.1.2.1.25.2.3.1.3.7 = STRING: "Cached memory"
  iso.3.6.1.2.1.25.2.3.1.3.8 = STRING: "Shared memory"
  iso.3.6.1.2.1.25.2.3.1.3.10 = STRING: "Swap space"
  iso.3.6.1.2.1.25.2.3.1.3.31 = STRING: "/"
  iso.3.6.1.2.1.25.2.3.1.3.33 = STRING: "/dev"
  iso.3.6.1.2.1.25.2.3.1.3.45 = STRING: "/dev/lxd"
  iso.3.6.1.2.1.25.2.3.1.3.46 = STRING: "/dev/.lxd-mounts"
  iso.3.6.1.2.1.25.2.3.1.3.63 = STRING: "/proc/sys/kernel/random/boot_id"
  iso.3.6.1.2.1.25.2.3.1.3.66 = STRING: "/dev/shm"
  iso.3.6.1.2.1.25.2.3.1.3.67 = STRING: "/run"
  iso.3.6.1.2.1.25.2.3.1.3.68 = STRING: "/run/lock"
  iso.3.6.1.2.1.25.2.3.1.3.69 = STRING: "/sys/fs/cgroup"
  "
  
  [Potential Regression]
  The fix has been tested by various impacted users, and feedback were all 
positives. Note that this fix a regression introduced by: 
https://bugs.launchpad.net/bugs/1835818
  
  [Other information]
  
  # Upstream commit:
  
https://github.com/net-snmp/net-snmp/commit/71e487212bd65839e7454df9701524d08cf0d74f
+ 
https://github.com/net-snmp/net-snmp/commit/bcb1a6b8afc444bbcd099a195e08f0b01cbc8f6b
  
  # git describe --contains 71e487212bd65839e7454df9701524d08cf0d74f
  v5.8.pre1
  
  # rmadison:
   net-snmp | 5.7.3+dfsg-1ubuntu4 | xenial   | source
   net-snmp | 5.7.3+dfsg-1ubuntu4.2   | xenial-security  | source
   net-snmp | 5.7.3+dfsg-1ubuntu4.2   | xenial-updates   | source
   net-snmp | 5.7.3+dfsg-1ubuntu4.3   | xenial-proposed  | source
   net-snmp | 5.7.3+dfsg-1.8ubuntu3   | bionic   | source
   net-snmp | 5.7.3

[Sts-sponsors] [Bug 1843036] Re: [regression] SNMP missing disks in hrStorageTable

2019-09-06 Thread Eric Desrochers
** Description changed:

  [IMPACT]
  
  It has been brought to me the following:
  
  Some hosts have started to cause UNKNOWN return values in Nagios for
  checks on their disks. This is because these hosts are no longer
  reporting their disks as part of the SNMP table hrStorageTable
  (1.3.6.1.2.1.25.2.3.1 ) - only memory devices are being reported. The
  affected hosts that I have investigated received updates for SNMP:
  
  Upgrade package libsnmp-base 5.7.3+dfsg-1.8ubuntu3.1 to 
5.7.3+dfsg-1.8ubuntu3.2
  Upgrade package libsnmp30 5.7.3+dfsg-1.8ubuntu3.1 to 5.7.3+dfsg-1.8ubuntu3.2
  Upgrade package snmpd 5.7.3+dfsg-1.8ubuntu3.1 to 5.7.3+dfsg-1.8ubuntu3.2
  
  It seems likely that this package update is the cause.
  
  As debug info, you can see the difference between 2 nearly identical
  servers, one of which received the SNMP updates, and one which did not.
  You can see that the one without the update is returning disks in the
  SNMP output:
  
  # snmpwalk -v2c -cpublic arcprsmt01 1.3.6.1.2.1.25.2.3.1.3
  iso.3.6.1.2.1.25.2.3.1.3.1 = STRING: "Physical memory"
  iso.3.6.1.2.1.25.2.3.1.3.3 = STRING: "Virtual memory"
  iso.3.6.1.2.1.25.2.3.1.3.6 = STRING: "Memory buffers"
  iso.3.6.1.2.1.25.2.3.1.3.7 = STRING: "Cached memory"
  iso.3.6.1.2.1.25.2.3.1.3.8 = STRING: "Shared memory"
  iso.3.6.1.2.1.25.2.3.1.3.10 = STRING: "Swap space"
  iso.3.6.1.2.1.25.2.3.1.3.31 = STRING: "/"
  iso.3.6.1.2.1.25.2.3.1.3.37 = STRING: "/run"
  iso.3.6.1.2.1.25.2.3.1.3.39 = STRING: "/dev/shm"
  iso.3.6.1.2.1.25.2.3.1.3.40 = STRING: "/run/lock"
  iso.3.6.1.2.1.25.2.3.1.3.41 = STRING: "/sys/fs/cgroup"
  iso.3.6.1.2.1.25.2.3.1.3.67 = STRING: "/run/snapd/ns"
  iso.3.6.1.2.1.25.2.3.1.3.70 = STRING: 
"/var/lib/docker/containers/3cad3d36991b677c37b08b374a7bfeceddf36a6b6754edaa1ff687b00111a6b8/mounts/shm"
  iso.3.6.1.2.1.25.2.3.1.3.73 = STRING: 
"/var/lib/docker/containers/c605c4b76dea65d562ba024212a38e24fb710186c499187b6604478b7ff678e9/mounts/shm"
  iso.3.6.1.2.1.25.2.3.1.3.82 = STRING: "/run/user/2002"
  iso.3.6.1.2.1.25.2.3.1.3.253 = STRING: 
"/var/lib/docker/containers/dc74a157fbaaa284e0e5b8ca4afc88769bf625eb796d89a5d26f98a540cabf35/mounts/shm"
  iso.3.6.1.2.1.25.2.3.1.3.256 = STRING: 
"/var/lib/docker/containers/6ce6193433f9c1c95cccbfbbe08a3f3385bdbc4f2e3f0baa02d11baf3866dfd2/mounts/shm"
  iso.3.6.1.2.1.25.2.3.1.3.258 = STRING: "/run/user/1000"
  
  The other, which received SNMP updates, is returning only memory
  devices, such as swap and shmem:
  
  # snmpwalk -v2c -cpublic arcprsmt02 1.3.6.1.2.1.25.2.3.1.3
  iso.3.6.1.2.1.25.2.3.1.3.1 = STRING: "Physical memory"
  iso.3.6.1.2.1.25.2.3.1.3.3 = STRING: "Virtual memory"
  iso.3.6.1.2.1.25.2.3.1.3.6 = STRING: "Memory buffers"
  iso.3.6.1.2.1.25.2.3.1.3.7 = STRING: "Cached memory"
  iso.3.6.1.2.1.25.2.3.1.3.8 = STRING: "Shared memory"
  iso.3.6.1.2.1.25.2.3.1.3.10 = STRING: "Swap space"
  
  [Test Case]
  
- * Install/configure snmp snmpd
- * Run snmpwalk:
- (e.g. snmpwalk -v2c -cpublic localhost 1.3.6.1.2.1.25.2.3.1.3)
+ * Install snmp snmpd
+ * Configure /etc/snmp/snmpd.conf by adding the following:
+  view   systemonly  included   .1.3.6.1.2.1.25.2.3.1.3
+ * Restart snmpd
+ * Use snmpwalk:
+  ** snmpwalk -v2c -cpublic localhost 1.3.6.1.2.1.25.2.3.1.3
+ 
+ Expected behavior is to see the disk as follow:
+ "
+ iso.3.6.1.2.1.25.2.3.1.3.1 = STRING: "Physical memory"
+ iso.3.6.1.2.1.25.2.3.1.3.3 = STRING: "Virtual memory"
+ iso.3.6.1.2.1.25.2.3.1.3.6 = STRING: "Memory buffers"
+ iso.3.6.1.2.1.25.2.3.1.3.7 = STRING: "Cached memory"
+ iso.3.6.1.2.1.25.2.3.1.3.8 = STRING: "Shared memory"
+ iso.3.6.1.2.1.25.2.3.1.3.10 = STRING: "Swap space"
+ iso.3.6.1.2.1.25.2.3.1.3.31 = STRING: "/"
+ iso.3.6.1.2.1.25.2.3.1.3.33 = STRING: "/dev"
+ iso.3.6.1.2.1.25.2.3.1.3.45 = STRING: "/dev/lxd"
+ iso.3.6.1.2.1.25.2.3.1.3.46 = STRING: "/dev/.lxd-mounts"
+ iso.3.6.1.2.1.25.2.3.1.3.63 = STRING: "/proc/sys/kernel/random/boot_id"
+ iso.3.6.1.2.1.25.2.3.1.3.66 = STRING: "/dev/shm"
+ iso.3.6.1.2.1.25.2.3.1.3.67 = STRING: "/run"
+ iso.3.6.1.2.1.25.2.3.1.3.68 = STRING: "/run/lock"
+ iso.3.6.1.2.1.25.2.3.1.3.69 = STRING: "/sys/fs/cgroup"
+ "
  
  [Potential Regression]
- None, the fix has been tested by various impacted users, and feedbacks were 
all positives.
- This fix a regression introduced by : https://bugs.launchpad.net/bugs/1835818
+ The fix has been tested by various impacted users, and feedback were all 
positives. Note that this fix a regression introduced by: 
https://bugs.launchpad.net/bugs/1835818
  
  [Other information]
  
  # Upstream commit:
  
https://github.com/net-snmp/net-snmp/commit/71e487212bd65839e7454df9701524d08cf0d74f
  
  # git describe --contains 71e487212bd65839e7454df9701524d08cf0d74f
- v5.8.pre1~7^2~14^2~15^2~22
- 
+ v5.8.pre1
  
  # rmadison:
-  net-snmp | 5.7.3+dfsg-1ubuntu4 | xenial   | source
-  net-snmp | 5.7.3+dfsg-1ubuntu4.2   | xenial-security  | source
-  net-snmp | 5.7.3+dfsg-1ubuntu4.2   | xenial-updates   | source
-  net-snmp | 5.7.3+dfsg-1ubuntu4.3 

[Sts-sponsors] [Bug 1834340] Re: Regression for GMail after libssl upgrade with TLSv1.3

2019-09-05 Thread Eric Desrochers
** Changed in: asterisk (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: asterisk (Ubuntu Disco)
   Status: New => In Progress

** Changed in: asterisk (Ubuntu Disco)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: asterisk (Ubuntu Bionic)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: mailsync (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: mailsync (Ubuntu Bionic)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: mailsync (Ubuntu Disco)
   Status: New => In Progress

** Changed in: mailsync (Ubuntu Disco)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: prayer (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: prayer (Ubuntu Bionic)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: prayer (Ubuntu Disco)
   Status: New => In Progress

** Changed in: prayer (Ubuntu Disco)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: asterisk (Ubuntu Eoan)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: prayer (Ubuntu Eoan)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: mailsync (Ubuntu Eoan)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1834340

Title:
  Regression for GMail after libssl upgrade with TLSv1.3

Status in asterisk package in Ubuntu:
  Fix Released
Status in mailsync package in Ubuntu:
  Fix Released
Status in php-imap package in Ubuntu:
  Invalid
Status in prayer package in Ubuntu:
  Fix Released
Status in uw-imap package in Ubuntu:
  Fix Released
Status in asterisk source package in Bionic:
  In Progress
Status in mailsync source package in Bionic:
  In Progress
Status in php-imap source package in Bionic:
  Invalid
Status in prayer source package in Bionic:
  In Progress
Status in uw-imap source package in Bionic:
  Fix Released
Status in asterisk source package in Disco:
  In Progress
Status in mailsync source package in Disco:
  In Progress
Status in php-imap source package in Disco:
  Invalid
Status in prayer source package in Disco:
  In Progress
Status in uw-imap source package in Disco:
  Fix Released
Status in asterisk source package in Eoan:
  Fix Released
Status in mailsync source package in Eoan:
  Fix Released
Status in php-imap source package in Eoan:
  Invalid
Status in prayer source package in Eoan:
  Fix Released
Status in uw-imap source package in Eoan:
  Fix Released
Status in uw-imap package in Debian:
  Fix Released

Bug description:
  [Impact]

   * Users of libc-client2007e (e.g., php7.x-imap) can no longer
     connect to GMail on Bionic and later, after introduction of
     TLSv1.3 with OpenSSL 1.1.1 (normal upgrade path in Bionic).

   * GMail requires Server Name Indication (SNI) to be set when
     TLSv1.3 is used, otherwise the server provided certificate
     fails verification in the client and connection is aborted.

   * The fix is to set SNI to the hostname that the client will
     perform verification on. The change is only enabled if the
     client is built with OpenSSL 1.1.1 or later (i.e., TLSv1.3
     support) so not to affect pre- TLSv1.3 support's behavior.

   * However it is functional nonetheless if the client is built
     with OpenSSL 1.1.1 or later but an earlier TLS version ends
     up used due to the handshake/negotiation/server TLS support
     (e.g., TLSv1.2); this shouldn't be a problem per test below.

   * Regression testing happened with a crawled list of IMAP/POP
     SSL servers (167 servers), and no regressions were observed.
     Actually, one more email provider/server has been fixed too.

   * OpenSSL-only demonstration with -(no)servername:

     $ echo QUIT \
   | openssl s_client \
     -connect imap.gmail.com:993 \
     -verify_hostname imap.gmail.com \
     -noservername `# or -servername imap.gmail.com` \
     -tls1_3 -brief 2>&1 \
   | grep -i ^verif

    Output with '-noservername':

    verify error:num=18:self signed certificate
    verify error:num=62:Hostname mismatch
    Verification error: Hostname mismatch

    Output with '-servername imap.gmail.com'

    Verification: OK
    Verified peername: imap.gmail.com

  [Test Case]

   * Commands:

     $ sudo apt install uw-mailutils
     $ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"

     $ sudo apt install php7.2-cli php7.2-imap
     $ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", 
"password");'

   * Before:

     $ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
     Certificate failure for imap.googlemail.com: self signed certificate: 
/OU=No SNI provided; please fix your client./CN=invalid2.invalid
     Certificate failure for imap.goo

[Sts-sponsors] [Bug 1668771] Re: [SRU] systemd-resolved negative caching for extended period of time

2019-08-29 Thread Eric Desrochers
There is discussion to push systemd 241 to Eoan:
https://launchpad.net/bugs/1841790

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1668771

Title:
  [SRU] systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache
  the result for very long (infinity?). I have to restart systemd-
  resolved to have the negative caching purged.

  * After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

  [Test Case]

  * If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s 
(See 201d995),
  however, there are several use cases on which this condition is not 
acceptable (See #5552 comments)
  and the only workaround would be to disable cache entirely or flush it , 
which isn't optimal.

  * Configure /etc/systemd/resolved.conf as follows:

  Cache=yes (default)

  * Restart systemd-resolved (systemctl restart systemd-
  resolved.service)

  * Run a host/getent command against a entry that will return SERVFAIL
  and check the journalctl output to see that the reply gets served from
  cache.

  root@systemd-disco:/home/ubuntu# host www.no-record.cl
  Host www.montemar.cl not found: 2(SERVFAIL)
  root@systemd-disco:/home/ubuntu# journalctl -u systemd-resolved -n
  -- Logs begin at Fri 2019-07-12 18:09:42 UTC, end at Tue 2019-07-23 15:10:17 
UTC. --
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Transaction 6222 for 
 on scope dns on ens3/* now complete with 
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Sending response packet 
with id 61042 on interface 1/AF_INET.
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Freeing transaction 
6222.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Got DNS stub UDP query 
packet for id 53580
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Looking up RR for  
www.no-record.cl IN A.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: RCODE SERVFAIL cache 
hit for  www.no-record.cl IN A
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Transaction 58570 for < 
www.no-record.cl IN A> on scope dns on ens3/* now complete with  scope dns on ens3/.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Using feature level UDP 
for transaction 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending query packet 
with id 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Processing incoming 
packet on transaction 22382 (rcode=SERVFAIL).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Server returned error: 
SERVFAIL
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Not caching negative 
entry for: www.metaklass.org IN A, cache mode set to no-negative
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Transaction 22382 for 
 on scope dns on ens3/ now complete with from network 
(unsigned).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending response packet 
with id 31060 on interface 1/AF_INET.

  The following patch https://github.com/systemd/systemd/pull/13047
  implements the required changes.

  [Other Info]

  Note that systemd in Eoan is being upgraded to upstream 242, so I am
  not adding this to Eoan now, as I don't want to disturb the merge. If
  needed after the merge, I'll add to Eoan.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1668771/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

2019-08-29 Thread Eric Desrochers
** Tags removed: sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Bionic:
  Fix Committed
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  Fix Committed
Status in makedumpfile source package in Eoan:
  Fix Released

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

  [Other information]

  Salsa Debian commit:
  
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1835818] Re: snmpd causes autofs mount points to be mounted on service start/restart

2019-08-29 Thread Eric Desrochers
** Tags removed: sts-sponsor sts-sponsor-ddstreet

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1835818

Title:
  snmpd causes autofs mount points to be mounted on service
  start/restart

Status in net-snmp package in Ubuntu:
  Fix Released
Status in net-snmp source package in Xenial:
  In Progress
Status in net-snmp source package in Bionic:
  In Progress
Status in net-snmp source package in Cosmic:
  Won't Fix
Status in net-snmp source package in Disco:
  In Progress
Status in net-snmp source package in Eoan:
  Fix Released
Status in net-snmp package in Debian:
  Unknown

Bug description:
  [Impact]

  Autofs direct map triggers are visible in /etc/mtab.
  On boot, when snmpd starts, it iterates over the entries in /etc/mtab and 
performs statfs() on them.
  This trigger automount to mount autofs mounts even if the user does not 
explicitly access them.

  However this happens only if autofs service is started before snmpd.
  If snmpd stars first /etc/mtab is not yet populated with autofs mounts and 
therefore
  are not mounted.

  When there a few autofs mount points the impact is insignificant.
  However when there are thousands of them, this causes unnecessary overhead on 
operations
  such as df.
  This also delays the system shutdown time since everything needs to be 
unmounted.

  [Test Case]

  *** Test Case 1 - During boot:

  The user that brought this issue to our attention would observe all autofs 
mounts
  be mounted at boot, because in their environment autofs would start first.

  In my environment snmpd starts first so to reproduce I had to add a small 
delay in
  snmpd init script.

  In /etc/init.d/snmp :
  @@ -36,6 +36,8 @@ cd /

   case "$1" in
     start)
  +# Delay snmp start
  +sleep 2
   log_daemon_msg "Starting SNMP services:"
   # remove old symlink with previous version
   if [ -L /var/run/agentx ]; then

  $cat /etc/auto.master
  /- /etc/auto.nfs --timeout=30

  $cat /etc/auto.nfs
  /home/test1 -fstype=nfs,hard,intr,nosuid,no-subtree-check,tcp :/srv/export/test1
  /home/test2 -fstype=nfs,hard,intr,nosuid,no-subtree-check,tcp :/srv/export/test2

  Reboot vm, syslog entries :

  # Autofs starts
  Jul 11 11:04:16 xenial-vm3 autofs[1295]:  * Starting automount...
  Jul 11 11:04:16 xenial-vm3 automount[1357]: Starting automounter version 
5.1.1, master map /etc/auto.master
  Jul 11 11:04:16 xenial-vm3 automount[1357]: using kernel protocol version 5.02
  # Mount triggers, now visible in mtab
  Jul 11 11:04:16 xenial-vm3 automount[1357]: mounted direct on /home/test1 
with timeout 300, freq 75 seconds
  Jul 11 11:04:16 xenial-vm3 automount[1357]: mounted direct on /home/test2 
with timeout 300, freq 75 seconds
  Jul 11 11:04:16 xenial-vm3 autofs[1295]:...done.
  ...
  # SNMP starts
  Jul 11 11:04:18 xenial-vm3 snmpd[1294]:  * Starting SNMP services:
  Jul 11 11:04:18 xenial-vm3 systemd[1]: proc-sys-fs-binfmt_misc.automount: Got 
automount request for /proc/sys/fs/binfmt_misc, triggered by 1394 (snmpd)
  Jul 11 11:04:18 xenial-vm3 systemd[1]: Mounting Arbitrary Executable File 
Formats File System...
  Jul 11 11:04:18 xenial-vm3 systemd[1]: Mounted Arbitrary Executable File 
Formats File System.
  Jul 11 11:04:18 xenial-vm3 automount[1357]: attempting to mount entry 
/home/test1 <==
  Jul 11 11:04:18 xenial-vm3 kernel: [8.880685] FS-Cache: Loaded
  Jul 11 11:04:18 xenial-vm3 kernel: [8.889318] FS-Cache: Netfs 'nfs' 
registered for caching
  Jul 11 11:04:18 xenial-vm3 kernel: [8.902672] NFS: Registering the 
id_resolver key type
  Jul 11 11:04:18 xenial-vm3 kernel: [8.902680] Key type id_resolver 
registered
  Jul 11 11:04:18 xenial-vm3 kernel: [8.902682] Key type id_legacy 
registered
  Jul 11 11:04:18 xenial-vm3 automount[1357]: mounted /home/test1  <==
  Jul 11 11:04:18 xenial-vm3 automount[1357]: attempting to mount entry 
/home/test2  <==
  Jul 11 11:04:18 xenial-vm3 kernel: [9.163011] random: nonblocking pool is 
initialized
  Jul 11 11:04:18 xenial-vm3 automount[1357]: mounted /home/test2  <===

  *** Test Case 2 - Restart snmpd :

  To reproduce this case, autofs mounts should not be mounted to begin with.
  (restart autofs or let it expire)

  #systemctl restart snmpd.service

  Syslog entries :

  Jul 11 11:15:40 xenial-vm3 systemd[1]: Stopping LSB: SNMP agents...
  Jul 11 11:15:40 xenial-vm3 snmpd[1668]:  * Stopping SNMP services:
  Jul 11 11:15:40 xenial-vm3 snmpd[1434]: Received TERM or STOP signal...  
shutting down...
  Jul 11 11:15:40 xenial-vm3 systemd[1]: Stopped LSB: SNMP agents.
  Jul 11 11:15:40 xenial-vm3 systemd[1]: Starting LSB: SNMP agents...
  Jul 11 11:15:42 xenial-vm3 snmpd[1677]:  * Starting SNMP services:
  Jul 11 11:15:42 xenial-vm3 automount[1357]: attempting to mount entry 
/home/test1 <===
  Jul 11 11:15:42 xenial-vm3 automount[1357]: mounted /home/test1 <

[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

2019-08-27 Thread Eric Desrochers
Hi Andrew Cloke,

Yes, I'm currently sponsoring D/B for cascardo/gpicolli.

Disco is already uploaded waiting for SRU team approval:
https://launchpad.net/ubuntu/disco/+queue?queue_state=1&queue_text=makedumpfile

Bionic debdiff needs some rework before I do the final upload.

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  Fix Released
Status in makedumpfile source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  Fix Released

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

  [Other information]

  Salsa Debian commit:
  
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

2019-08-16 Thread Eric Desrochers
** Tags added: sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  Fix Committed
Status in makedumpfile source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

  [Other information]

  Salsa Debian commit:
  
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1834340] Re: Regression for GMail after libssl upgrade with TLSv1.3

2019-08-13 Thread Eric Desrochers
** Also affects: asterisk (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: mailsync (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: prayer (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1834340

Title:
  Regression for GMail after libssl upgrade with TLSv1.3

Status in asterisk package in Ubuntu:
  New
Status in mailsync package in Ubuntu:
  New
Status in php-imap package in Ubuntu:
  Invalid
Status in prayer package in Ubuntu:
  New
Status in uw-imap package in Ubuntu:
  In Progress
Status in asterisk source package in Bionic:
  New
Status in mailsync source package in Bionic:
  New
Status in php-imap source package in Bionic:
  Invalid
Status in prayer source package in Bionic:
  New
Status in uw-imap source package in Bionic:
  In Progress
Status in asterisk source package in Disco:
  New
Status in mailsync source package in Disco:
  New
Status in php-imap source package in Disco:
  Invalid
Status in prayer source package in Disco:
  New
Status in uw-imap source package in Disco:
  In Progress
Status in asterisk source package in Eoan:
  New
Status in mailsync source package in Eoan:
  New
Status in php-imap source package in Eoan:
  Invalid
Status in prayer source package in Eoan:
  New
Status in uw-imap source package in Eoan:
  In Progress

Bug description:
  [Impact]

   * Users of libc-client2007e (e.g., php7.x-imap) can no longer
     connect to GMail on Bionic and later, after introduction of
     TLSv1.3 with OpenSSL 1.1.1 (normal upgrade path in Bionic).

   * GMail requires Server Name Indication (SNI) to be set when
     TLSv1.3 is used, otherwise the server provided certificate
     fails verification in the client and connection is aborted.

   * The fix is to set SNI to the hostname that the client will
     perform verification on. The change is only enabled if the
     client is built with OpenSSL 1.1.1 or later (i.e., TLSv1.3
     support) so not to affect pre- TLSv1.3 support's behavior.

   * However it is functional nonetheless if the client is built
     with OpenSSL 1.1.1 or later but an earlier TLS version ends
     up used due to the handshake/negotiation/server TLS support
     (e.g., TLSv1.2); this shouldn't be a problem per test below.

   * Regression testing happened with a crawled list of IMAP/POP
     SSL servers (167 servers), and no regressions were observed.
     Actually, one more email provider/server has been fixed too.

   * OpenSSL-only demonstration with -(no)servername:

     $ echo QUIT \
   | openssl s_client \
     -connect imap.gmail.com:993 \
     -verify_hostname imap.gmail.com \
     -noservername `# or -servername imap.gmail.com` \
     -tls1_3 -brief 2>&1 \
   | grep -i ^verif

    Output with '-noservername':

    verify error:num=18:self signed certificate
    verify error:num=62:Hostname mismatch
    Verification error: Hostname mismatch

    Output with '-servername imap.gmail.com'

    Verification: OK
    Verified peername: imap.gmail.com

  [Test Case]

   * Commands:

     $ sudo apt install uw-mailutils
     $ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"

     $ sudo apt install php7.2-cli php7.2-imap
     $ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", 
"password");'

   * Before:

     $ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
     Certificate failure for imap.googlemail.com: self signed certificate: 
/OU=No SNI provided; please fix your client./CN=invalid2.invalid
     Certificate failure for imap.googlemail.com: self signed certificate: 
/OU=No SNI provided; please fix your client./CN=invalid2.invalid

     $ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", 
"password");'
     PHP Warning:  imap_open(): Couldn't open stream 
{imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
     PHP Notice:  Unknown: Certificate failure for imap.gmail.com: self signed 
certificate: /OU=No SNI provided; please fix your client./CN=invalid2.invalid 
(errflg=2) in Unknown on line 0

   * After:

     $ mailutil check "{imap.googlemail.com:993/imap/ssl}INBOX"
     {ce-in-f16.1e100.net/imap} username:
     ^C

     $ php -r 'imap_open("{imap.gmail.com:993/imap/ssl}INBOX", "username", 
"password");'
     PHP Warning:  imap_open(): Couldn't open stream 
{imap.gmail.com:993/imap/ssl}INBOX in Command line code on line 1
     PHP Notice:  Unknown: Retrying PLAIN authentication after [ALERT] Invalid 
credentials (Failure) (errflg=1) in Unknown on line 0
     PHP Notice:  Unknown: Retrying PLAIN authentication after [ALERT] Invalid 
credentials (Failure) (errflg=1) in Unknown on line 0
     PHP Notice:  Unknown: Can not authenticate to IMAP server: [ALERT] Invalid 
credentials (Failure) (errflg=2) in Unknown on line 0

   * Regression testing scripts/results are 

[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

2019-08-06 Thread Eric Desrochers
makedumpfile merge to "1:1.6.6-2ubuntu1" sponsored in Eoan.

I appended the changelog to add the entry block[0] currently found in 
eoan-proposed that was missing to keep track of everything that has been done 
on the package:
Since it was made by cascardo before 1:1.6.5-1ubuntu3 exist.

Note:
- I didn't want this to be a blocker for this upload due to many factors, but 
cascardo/gpicolli, can you guys have a look before the feature freeze[1] at 
this lintian report[2], it would be awesome. It's good to make the code more 
modern, but debian packaging too, especially when time permit like now (devel 
release).

[0] 
makedumpfile (1:1.6.5-1ubuntu3) eoan; urgency=medium

  * debian/kdump-config.in:
- Add kdump retry/delay mechanism when dumping over network.
  (LP: #1681909)

 -- gpicc...@canonical.com (Guilherme G. Piccoli)  Thu, 04 Jul 2019
15:20:53 -0300

[1] - https://wiki.ubuntu.com/EoanErmine/ReleaseSchedule

[2] - https://pastebin.canonical.com/p/dWYkNhwjCb/

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  Fix Committed
Status in makedumpfile source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

  [Other information]

  Salsa Debian commit:
  
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1838358] Re: Ibus causes gnome-shell to freeze when password fields are selected in Firefox

2019-08-01 Thread Eric Desrochers
Sponsored for Bionic.

* Patch already found in Cosmic onwards.
* Patch has been tested pre-SRU with an impact user.
* Nitpick: I have added the upstream bug link in the DEP3 header -> 
+Bug-Upstream: https://github.com/ibus/ibus/issues/2002

Thanks Matthew !

** Bug watch added: github.com/ibus/ibus/issues #2002
   https://github.com/ibus/ibus/issues/2002

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1838358

Title:
  Ibus causes gnome-shell to freeze when password fields are selected in
  Firefox

Status in ibus package in Ubuntu:
  Fix Released
Status in ibus source package in Bionic:
  In Progress

Bug description:
  [Impact]

  The following has been seen in a VMware Horizon VDI. I cannot reproduce this
  issue myself.

  When a user interacts with any password field in Firefox, gnome-shell
  and Firefox both freeze and the system becomes unusable. If you ssh
  into the system and terminate Firefox, gnome-shell unfreezes.

  This only happens when the environment variable GTK_IM_MODULE is set to 
"ibus". If you unset the variable, or change it to
  GTK_IM_MODULE=gtk-im-context-simple and then start Firefox, everything works 
as intended.

  This has been seen before with gnome-shell 3.28.4-0ubuntu18.04.1, ibus
  1.5.17-3ubuntu4 and Firefox versions starting with 
68.0+build3-0ubuntu0.18.04.1

  Note: Chrome[ium] and other applications do not trigger it, and it cannot be
  reproduced in other desktop environments.

  This seems to be an interaction issue between ibus and gnome-shell.

  
  [Test Case]

  Launch firefox from within a gnome-session, making sure the
  GTK_IM_MODULE is set to "ibus". Note, this is the default value.

  $ env GTK_IM_MODULE="ibus" firefox

  Navigate to any website which has a password field. Wikipedia or
  Reddit will do.

  Click a password field and attempt to enter text. Firefox and gnome-
  shell both lock up and stay frozen for an extended period of time.

  Now, try it with the fix by enabling:

  $ env IBUS_DISCARD_PASSWORD=1 firefox

  When you enter text into a password field, ibus should directly pass through
  the text and the problem will be solved.

  We can also ask it to always apply for a specific application with:

  $ export IBUS_DISCARD_PASSWORD_APPS="firefox"
  $ firefox

  Again, when you enter text into a password input field, the problem will be
  solved.

  Test package is available here:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf235370-test

  Please test with the revised version,
  1.5.17-3ubuntu4+sf235370v20190731b1.

  [Regression Potential]

  This change has a low risk of regression, because the default behaviour is
  unchanged. To be able to use the password input field discard functionality, 
a user has to explicitly set an environment variable for the specific process, 
or set a regex that matches a process name.

  This means the fix is not enabled by default on any machines, and will
  only be utilised by those suffering problems and go and manually set
  environment variables or have their system administrator enable the
  environment variables permanently.

  This commit is present in upstream ibus from version ibus-1.5.19
  onward, and is currently present in cosmic, disco and eoan.

  If a regression occurs, users can ensure that the environment
  variables are unset and continue working.

  [Other info]

  * This patch is functionally the same as ibus-xx-f19-password.patch,
  but just hides the features behind environment variables.

  * When ibus is built with the patch ibus-xx-f19-password.patch which
  was dropped in ibus-1.5.17-2, the problem is solved.

  Instead of using ibus-xx-f19-password.patch, we will instead fix it with
  upstream commit f328fd67f479faa46ca87bf3c85eed7080ec5ec0:

  https://github.com/ibus/ibus/commit/f328fd67f479faa46ca87bf3c85eed7080ec5ec0

  Subject: client/gtk2: Add IBUS_DISCARD_PASSWORD for firefox and chrome
  Author: fujiwarat 

  This implements the password discard functionality found in
  ibus-xx-f19-password.patch and places it behind two environment variables,
  IBUS_DISCARD_PASSWORD and IBUS_DISCARD_PASSWORD_APPS.

  IBUS_DISCARD_PASSWORD is for a single process, and IBUS_DISCARD_PASSWORD_APPS
  lets you set a regex of process names to filter and enable the fix for.

  If IBUS_DISCARD_PASSWORD is set or IBUS_DISCARD_PASSWORD_APPS is set
  with the process name which input is being placed into password
  fields, ibus will pass through the input to the application without
  any processing.

  * This only affect Bionic

  - Upstream first introduction:
  $ git describe --contains  f328fd67f479faa46ca87bf3c85eed7080ec5ec0
  1.5.19~7

  - Ubuntu ibus current version found in the archive:
  $ rmadison ibus
   ==> ibus | 1.5.17-3ubuntu4   | bionic 
   ibus | 1.5.19-1ubuntu1   | cosmic 
   ibus | 1.5.19-1ubuntu2   | disco  
   ibus | 1.5.19-4ubuntu2   | eoan

To 

[Sts-sponsors] [Bug 1838358] Re: Ibus causes gnome-shell to freeze when password fields are selected in Firefox

2019-08-01 Thread Eric Desrochers
** Description changed:

  [Impact]
  
  The following has been seen in a VMware Horizon VDI. I cannot reproduce this
  issue myself.
  
  When a user interacts with any password field in Firefox, gnome-shell
  and Firefox both freeze and the system becomes unusable. If you ssh into
  the system and terminate Firefox, gnome-shell unfreezes.
  
  This only happens when the environment variable GTK_IM_MODULE is set to 
"ibus". If you unset the variable, or change it to
  GTK_IM_MODULE=gtk-im-context-simple and then start Firefox, everything works 
as intended.
  
  This has been seen before with gnome-shell 3.28.4-0ubuntu18.04.1, ibus
  1.5.17-3ubuntu4 and Firefox versions starting with 
68.0+build3-0ubuntu0.18.04.1
  
  Note: Chrome[ium] and other applications do not trigger it, and it cannot be
  reproduced in other desktop environments.
  
  This seems to be an interaction issue between ibus and gnome-shell.
  
- [Fix]
  
- When ibus is built with the patch ibus-xx-f19-password.patch which was
- dropped in ibus-1.5.17-2, the problem is solved.
- 
- Instead of using ibus-xx-f19-password.patch, we will instead fix it with
- upstream commit f328fd67f479faa46ca87bf3c85eed7080ec5ec0:
- 
- https://github.com/ibus/ibus/commit/f328fd67f479faa46ca87bf3c85eed7080ec5ec0
- 
- Subject: client/gtk2: Add IBUS_DISCARD_PASSWORD for firefox and chrome 
- Author: fujiwarat 
- 
- This implements the password discard functionality found in 
- ibus-xx-f19-password.patch and places it behind two environment variables,
- IBUS_DISCARD_PASSWORD and IBUS_DISCARD_PASSWORD_APPS.
- 
- IBUS_DISCARD_PASSWORD is for a single process, and IBUS_DISCARD_PASSWORD_APPS
- lets you set a regex of process names to filter and enable the fix for.
- 
- If IBUS_DISCARD_PASSWORD is set or IBUS_DISCARD_PASSWORD_APPS is set with the
- process name which input is being placed into password fields, ibus will pass
- through the input to the application without any processing.
- 
- [Testcase]
+ [Test Case]
  
  Launch firefox from within a gnome-session, making sure the
  GTK_IM_MODULE is set to "ibus". Note, this is the default value.
  
  $ env GTK_IM_MODULE="ibus" firefox
  
  Navigate to any website which has a password field. Wikipedia or Reddit
  will do.
  
  Click a password field and attempt to enter text. Firefox and gnome-
  shell both lock up and stay frozen for an extended period of time.
  
  Now, try it with the fix by enabling:
  
  $ env IBUS_DISCARD_PASSWORD=1 firefox
  
  When you enter text into a password field, ibus should directly pass through
  the text and the problem will be solved.
  
  We can also ask it to always apply for a specific application with:
  
  $ export IBUS_DISCARD_PASSWORD_APPS="firefox"
- $ firefox 
+ $ firefox
  
  Again, when you enter text into a password input field, the problem will be
  solved.
  
  Test package is available here:
  
  https://launchpad.net/~mruffell/+archive/ubuntu/sf235370-test
  
  Please test with the revised version,
  1.5.17-3ubuntu4+sf235370v20190731b1.
  
  [Regression Potential]
  
  This change has a low risk of regression, because the default behaviour is
- unchanged. To be able to use the password input field discard functionality,
- a user has to explicitly set an environment variable for the specific 
process, or set a regex that matches a process name.
+ unchanged. To be able to use the password input field discard functionality, 
a user has to explicitly set an environment variable for the specific process, 
or set a regex that matches a process name.
  
  This means the fix is not enabled by default on any machines, and will
  only be utilised by those suffering problems and go and manually set
  environment variables or have their system administrator enable the
  environment variables permanently.
  
- This commit is present in upstream ibus from version ibus-1.5.19 onward, and
- is currently present in cosmic, disco and eoan. 
+ This commit is present in upstream ibus from version ibus-1.5.19 onward,
+ and is currently present in cosmic, disco and eoan.
  
- If a regression occurs, users can ensure that the environment variables are
- unset and continue working.
+ If a regression occurs, users can ensure that the environment variables
+ are unset and continue working.
  
- [Notes]
+ [Other info]
  
- This patch is functionally the same as ibus-xx-f19-password.patch, but just
- hides the features behind environment variables.
+ * This patch is functionally the same as ibus-xx-f19-password.patch, but
+ just hides the features behind environment variables.
+ 
+ * When ibus is built with the patch ibus-xx-f19-password.patch which was
+ dropped in ibus-1.5.17-2, the problem is solved.
+ 
+ Instead of using ibus-xx-f19-password.patch, we will instead fix it with
+ upstream commit f328fd67f479faa46ca87bf3c85eed7080ec5ec0:
+ 
+ https://github.com/ibus/ibus/commit/f328fd67f479faa46ca87bf3c85eed7080ec5ec0
+ 
+ Subject: client/gtk2: Add IBUS_DISCARD_PASSWORD for firefox and chrome

[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

2019-07-31 Thread Eric Desrochers
Quick update:

It seems to fail the same way with 1:1.6.5-1ubuntu2, so NOT introduced
by this SRU via 1:1.6.5-1ubuntu3

We still have to test the autopkgtest locally on ppc64el arch and
instrument/monitor the test to understand why no crash is found in
/var/crash at the end of the test.

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  Fix Committed
Status in makedumpfile source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

  [Other information]

  Salsa Debian commit:
  
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

2019-07-23 Thread Eric Desrochers
Quick update

# excuses... page:

makedumpfile (1:1.6.5-1ubuntu2 to 1:1.6.5-1ubuntu3)
Maintainer: Louis Bouchard
0 days old
autopkgtest for kpatch/0.5.0-0ubuntu2: amd64: Ignored failure
autopkgtest for makedumpfile/1:1.6.5-1ubuntu3: amd64: Pass, arm64: Pass, armhf: 
Pass, i386: Pass, ppc64el: Regression ♻ , s390x: Ignored failure
Not considered

# logs
.
makedumpfile: crash test: checking for crash file
makedumpfile: ERROR: crash test: Found no compressed dumps
.

gpicolli and I are investigating the root cause.

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  Fix Committed
Status in makedumpfile source package in Xenial:
  Won't Fix
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

  [Other information]

  Salsa Debian commit:
  
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

2019-07-23 Thread Eric Desrochers
Sponsored for 'Eoan'.

We'll be able to start the SRU sponsoring as soon as it lands in
-releases.

Notes:
* Patch lands in debian unstable ~2 weeks ago : 
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

* Patch have been "Signed-off-by" by a member of the Ubuntu kernel team.

** Changed in: makedumpfile (Ubuntu Eoan)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  Fix Committed
Status in makedumpfile source package in Xenial:
  In Progress
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  Fix Committed

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

  [Other information]

  Salsa Debian commit:
  
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

2019-07-23 Thread Eric Desrochers
** Description changed:

  [Impact]
  
  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware delays,
  usually not fixable from drivers. Some adapters known to act like this
  are bnx2x, tg3 and ixgbe.
  
  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network dump,
  kdump will retry some times and sleep between the attempts in order to
  exclude the case of NICs that aren't ready yet but will soon be able to
  transmit packets.
  
  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.
  
  [Test case]
  
  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.
  
  [Regression potential]
  
  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.
+ 
+ [Other information]
+ 
+ Salsa Debian commit:
+ 
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  In Progress
Status in makedumpfile source package in Xenial:
  In Progress
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  In Progress

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

  [Other information]

  Salsa Debian commit:
  
https://salsa.debian.org/debian/makedumpfile/commit/d63ba95337988be1eac8c8c76d90825ff5c6d17f

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured

2019-07-22 Thread Eric Desrochers
Marking Cosmic as 'Won't fix'.

Ubuntu 18.10 (Cosmic Cuttlefish) End Of Life reached on July 18 2019.


** Changed in: makedumpfile (Ubuntu Cosmic)
   Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1681909

Title:
  kdump is not captured in remote host when kdump over ssh is configured

Status in The Ubuntu-power-systems project:
  In Progress
Status in makedumpfile package in Ubuntu:
  In Progress
Status in makedumpfile source package in Xenial:
  In Progress
Status in makedumpfile source package in Bionic:
  In Progress
Status in makedumpfile source package in Cosmic:
  Won't Fix
Status in makedumpfile source package in Disco:
  In Progress
Status in makedumpfile source package in Eoan:
  In Progress

Bug description:
  [Impact]

  * Kdump over network (like NFS mount or SSH dump) relies on network-
  online target from systemd. Even so, there are some NICs that report
  "Link Up" state but aren't ready to transmit packets. This is a
  generally bad behavior that is credited probably to NIC firmware
  delays, usually not fixable from drivers. Some adapters known to act
  like this are bnx2x, tg3 and ixgbe.

  * Kdump is a mechanism that may be a last resort to debug complex/hard
  to reproduce issues, so it's interesting to increase its reliability /
  resilience. We then propose here a solution/quirk to this issue on
  network dump by adding a retry/delay mechanism; if it's a network
  dump, kdump will retry some times and sleep between the attempts in
  order to exclude the case of NICs that aren't ready yet but will soon
  be able to transmit packets.

  * Although first reported by IBM in PowerPC arch, the scope for this
  issue is the NIC, and it was later reported in x86 arch too.

  [Test case]

  Usually it's difficult to naturally reproduce this issue in a deterministic 
way, but we have an artificial test case on comment #24 of this LP.
  Also, we have a report from this bug in which the user managed to reproduce 
the problem consistently - it's fixed after testing our solution.

  [Regression potential]

  There's not a clear regression potential here since it's just a retry/delay 
mechanism. Some potential problems may come from bad coding in the script.
  The delay between attempts is only 3 sec per iteration, so it shouldn't block 
the kdump progress for a high amount of time at once.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1821252] Re: systemctl set-default breaks recovery mode

2019-06-25 Thread Eric Desrochers
Sponsored in stable release for D/C/B/X.

Note: The fix is already merged into Debian and Eoan (Current devel
release).

Thanks Steven for your patch contribution, and Ioanna for producing the
debdiffs and all the SRU related work.

Regards,
Eric

** Tags removed: sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1821252

Title:
  systemctl set-default breaks recovery mode

Status in friendly-recovery package in Ubuntu:
  Fix Released
Status in friendly-recovery source package in Xenial:
  In Progress
Status in friendly-recovery source package in Bionic:
  In Progress
Status in friendly-recovery source package in Cosmic:
  In Progress
Status in friendly-recovery source package in Disco:
  In Progress
Status in friendly-recovery source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * A recovery mode boot is effectively a normal boot on any system
  that has ever had systemctl set-default run on it, i.e., the recovery
  kernel parameter does nothing. In particular, ubiquity calls systemctl
  set-default as part of the oem-config process, rendering recovery mode
  useless on any oem-configured machine.

   * This is a regression from previous behavior, where recovery mode
  would override a user-set default target.

   * This would also restore the intuitive behavior of this package. It
  is intended to be run by setting a kernel parameter for a one-time
  boot, and should therefore take priority over any other settings (such
  as configuring a different default target).

  [Test Case]

   * Run systemctl set-default multi-user.target

   * Use the GRUB menu to try to boot into recovery mode

   * Observe that you end up at a TTY, not in recovery mode

  [Regression Potential]

   * Possible regression if someone set recovery as a default kernel
  parameter, then relied on the default systemd target to override it.
  This seems like an unlikely use-case.

  [Original Description]

  Fresh Ubuntu 18.04.2 server install

  Try to boot to recovery mode from GRUB. Works correctly.

  Use systemctl to set a different default, say systemctl set-default
  multi-user.target

  Try to boot to recovery mode from GRUB. End up at getty and not the
  recovery menu.

  Delete /etc/systemd/system/default.target* and recovery mode works
  normally again.

  I believe this can be fixed by changing normaldir to earlydir in the
  generator.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/1821252/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1821252] Re: systemctl set-default breaks recovery mode

2019-06-21 Thread Eric Desrochers
xnox will upload to debian experimental and will sync to eoan.
I'll take care of the stable release once the above ^ is completed.

- Eric

** Tags added: sts-sponsor-slashd

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1821252

Title:
  systemctl set-default breaks recovery mode

Status in friendly-recovery package in Ubuntu:
  In Progress
Status in friendly-recovery source package in Xenial:
  In Progress
Status in friendly-recovery source package in Bionic:
  In Progress
Status in friendly-recovery source package in Cosmic:
  In Progress
Status in friendly-recovery source package in Disco:
  In Progress
Status in friendly-recovery source package in Eoan:
  In Progress

Bug description:
  [Impact]

   * A recovery mode boot is effectively a normal boot on any system
  that has ever had systemctl set-default run on it, i.e., the recovery
  kernel parameter does nothing. In particular, ubiquity calls systemctl
  set-default as part of the oem-config process, rendering recovery mode
  useless on any oem-configured machine.

   * This is a regression from previous behavior, where recovery mode
  would override a user-set default target.

   * This would also restore the intuitive behavior of this package. It
  is intended to be run by setting a kernel parameter for a one-time
  boot, and should therefore take priority over any other settings (such
  as configuring a different default target).

  [Test Case]

   * Run systemctl set-default multi-user.target

   * Use the GRUB menu to try to boot into recovery mode

   * Observe that you end up at a TTY, not in recovery mode

  [Regression Potential]

   * Possible regression if someone set recovery as a default kernel
  parameter, then relied on the default systemd target to override it.
  This seems like an unlikely use-case.

  [Original Description]

  Fresh Ubuntu 18.04.2 server install

  Try to boot to recovery mode from GRUB. Works correctly.

  Use systemctl to set a different default, say systemctl set-default
  multi-user.target

  Try to boot to recovery mode from GRUB. End up at getty and not the
  recovery menu.

  Delete /etc/systemd/system/default.target* and recovery mode works
  normally again.

  I believe this can be fixed by changing normaldir to earlydir in the
  generator.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/1821252/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1818527] Re: Stub resolver cache is corrupted

2019-06-11 Thread Eric Desrochers
** Description changed:

  [Impact]
  systemd-resolved fails to resolve A records
  
  [Description]
  When systemd-resolve caches a non-existent CNAME record for a specific 
domain, further attempts at resolving A records for that same domain  fail. 
This has been fixed upstream in v240.
  
  Upstream commit: https://github.com/systemd/systemd/commit/3740146a4cbd
  
  $ git describe --contains 3740146a4cbd
  v240~839
  
  $ rmadison systemd --arch amd64
-  systemd | 229-4ubuntu4 | xenial  | source, ...
-  systemd | 229-4ubuntu21.21 | xenial-security | source, ...
-  systemd | 229-4ubuntu21.21 | xenial-updates  | source, ...
-  systemd | 237-3ubuntu10| bionic  | source, ...
-  systemd | 237-3ubuntu10.19 | bionic-security | source, ...
-  systemd | 237-3ubuntu10.21 | bionic-updates  | source, ...
-  systemd | 237-3ubuntu10.22 | bionic-proposed | source, ...
-  systemd | 239-7ubuntu10| cosmic  | source, ...
-  systemd | 239-7ubuntu10.12 | cosmic-security | source, ...
-  systemd | 239-7ubuntu10.13 | cosmic-updates  | source, ...
-  systemd | 239-7ubuntu10.14 | cosmic-proposed | source, ...
-  systemd | 240-6ubuntu5 | disco   | source, ...
-  systemd | 240-6ubuntu5.1   | disco-proposed  | source, ...
-  systemd | 240-6ubuntu9 | eoan| source, ...
+  systemd | 229-4ubuntu4 | xenial  | source, ...
+  systemd | 229-4ubuntu21.21 | xenial-security | source, ...
+  systemd | 229-4ubuntu21.21 | xenial-updates  | source, ...
+  systemd | 237-3ubuntu10| bionic  | source, ...
+  systemd | 237-3ubuntu10.19 | bionic-security | source, ...
+  systemd | 237-3ubuntu10.21 | bionic-updates  | source, ...
+  systemd | 237-3ubuntu10.22 | bionic-proposed | source, ...
+  systemd | 239-7ubuntu10| cosmic  | source, ...
+  systemd | 239-7ubuntu10.12 | cosmic-security | source, ...
+  systemd | 239-7ubuntu10.13 | cosmic-updates  | source, ...
+  systemd | 239-7ubuntu10.14 | cosmic-proposed | source, ...
+  systemd | 240-6ubuntu5 | disco   | source, ...
+  systemd | 240-6ubuntu5.1   | disco-proposed  | source, ...
+  systemd | 240-6ubuntu9 | eoan| source, ...
  
  Despite the package versions above, only Bionic is affected. Cosmic
  already includes a backported fix, and Xenial doesn't seem affected due
  to resolvconf handling DNS resolution.
  
  [Test Case]
  Flush resolved's caches and try resolving a non-existent CNAME record. 
Further resolution attempts for the corresponding A record will fail:
  
+ #1 
+ On a Bionic host:
  $ systemd-resolve --flush-caches
  $ dig github.com CNAME
  $ dig github.com A
+ 
+ #2 
+ On a Bionic host:
+ $ systemd-resolve --flush-caches
+ $ dig github.com CNAME
+ $ dig github.com A
+ 
+ Build a lxd with Cosmic/Disoo/Eoan and late (systemd-240):
+ $ lxc launch ubuntu:cosmic cosmiclxd
+ $ lxd exec cosmiclxd bash
+ $ dig github.com A
+ 
+ Despite the fact that Cosmic and late has the proper fix,
+ Cosmic/Disco/Eoan container can suffer from the bug too if the host is
+ Bionic (container uses the host as a DNS resolver).
+ 
+ So you may face the problem inside Cosmic/Disco/Eoan inside a container,
+ but it's still the same Bionic systemd bug.
  
  [Regression Potential]
  The regression potential for this fix should be very low, as it's a direct 
cherry-pick from upstream systemd. It has seen extensive testing  in both 
upstream and other Ubuntu releases, and was verified for Bionic through 
autopkgtests.
  
  
  
  [Original Description]
  
  It seems that when systemd-resolve cache an non-existent CNAME record
  for a domain, any attempt to resolve A record for the same domain fail.
  
  systemd version the issue has been seen with
  Installed: 237-3ubuntu10.13
  Used distribution
  
  Distributor ID: Ubuntu
  Description: Ubuntu 18.04.2 LTS
  Release: 18.04
  Codename: bionic
  
  Expected behaviour you didn't see
  
  Return A record for a domain when it exists.
  
  Unexpected behaviour you saw
  
  Resolution failed.
  
  Steps to reproduce the problem
  
  Whait for 1 minutes (github.com TTL for A record)
  
  Try to resolv github.com CNAME record dig CNAME github.com
  
  This will return an empty result.
  
  Then try to resolve github.com A record dig A github.com.
  
  This will now return empty result unless you restart systemd-resolved or
  wait for cache expiration.
  
  At the same time using another DNS will resolve correctly dig A
  github.com @8.8.8.8.
  
  Exemple :
  
  Wait for 1 minutes to let cache expire, then run
  
  dig CNAME github.com
  dig A github.com
  # no result
  dig A github.com @8.8.8.8
  # ;; ANSWER SECTION:
  # github.com. 59  IN  A   192.30.253.113
  # github.com. 59  IN  A   192.30.253.112
  
  PS: Don't forget to restart systemd-resolve, before trying to post an
  answer.
  
  This bug was first reported in github
  https://github.com/systemd/systemd/issues/11789 bu

[Sts-sponsors] [Bug 1817321] Re: installer does not support iSCSI iBFT

2019-06-11 Thread Eric Desrochers
Sponsored for Bionic 'd-i'.

The new kernel version used "4.18.0-20" (aka HWE) and "4.15.0-50" are
both available in the archive for Bionic in -updates.

$ rmadison linux-image-4.18.0-20-generic
 linux-image-4.18.0-20-generic | 4.18.0-20.21~18.04.1 | bionic-security | 
amd64, arm64, armhf, i386, ppc64el, s390x
 linux-image-4.18.0-20-generic | 4.18.0-20.21~18.04.1 | bionic-updates  | 
amd64, arm64, armhf, i386, ppc64el, s390x

$ rmadison linux-image-4.15.0-50-generic
 linux-image-4.15.0-50-generic | 4.15.0-50.54 | bionic-security | 
amd64, arm64, armhf, i386, ppc64el, s390x
 linux-image-4.15.0-50-generic | 4.15.0-50.54 | bionic-updates  | 
amd64, arm64, armhf, i386, ppc64el, s390x

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1817321

Title:
  installer does not support iSCSI iBFT

Status in debian-installer package in Ubuntu:
  Fix Released
Status in hw-detect package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in partman-iscsi package in Ubuntu:
  Fix Released
Status in debian-installer source package in Bionic:
  In Progress
Status in hw-detect source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Fix Released
Status in partman-iscsi source package in Bionic:
  Fix Committed
Status in debian-installer source package in Cosmic:
  In Progress
Status in hw-detect source package in Cosmic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Released
Status in partman-iscsi source package in Cosmic:
  Fix Committed
Status in debian-installer source package in Disco:
  In Progress
Status in hw-detect source package in Disco:
  Fix Committed
Status in linux source package in Disco:
  Fix Released
Status in partman-iscsi source package in Disco:
  Fix Committed
Status in debian-installer source package in Eoan:
  Fix Released
Status in hw-detect source package in Eoan:
  Fix Released
Status in linux source package in Eoan:
  Fix Released
Status in partman-iscsi source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * It's not possible to access iBFT (iSCSI Boot Firmware Table) information
     (settings for network interface, initiator, and target) in the installer
     because the 'iscsi_ibft' module is not present in udeb packages.

   * Even if it was, the installer does not handle iBFT information at all,
     thus any settings are ignored, and iSCSI-related configuration has to
     be done manually or with workarounds.

   * This impacts user-experience and automatic installation on systems and
     deployments which actually do provide the iBFT feature and information,
     but cannot use it practically.

   * With proper iBFT support in the installer (kernel module in udeb package
     and automatic iSCSI-related configuration) users will be able to rely on
     iBFT to install/deploy Ubuntu on their servers and datacenters.

   * These fixes add the 'iscsi_ibft' kernel module in the scsi-modules udeb,
     and configure network/iSCSI according to iBFT information in disk-detect.

     This is done in disk-detect so that the iSCSI LUNs are detected as disks
     (useful in case of no other disks in the system so the installer doesn't
     complain nor wait too long) and that any partman-related preseed options
     are not required and may be still available for the user.

  [Test Case]

   * linux package / kernel module in udeb:

     $ dpkg-deb -c scsi-modules_*.udeb | grep iscsi_ibft.ko

     Check the module loads in the installer environment.
     See comment with example for disco.

   * d-i/hw-detect/partman-iscsi package:
     See comments 11, 12, 13.

  [Regression Potential]

   * linux package: low, the kernel module is not loaded by default,
     and only checks whether iBFT information is present in firmware,
     then exposes that in sysfs in read-only mode.

   * d-i/hw-detect/partman-iscsi:
     - d-i: kernel version update to include iscsi_ibft module,
    based on kernel released to -updates plus one week
    monitoring bug reports -- it should be OK.
    Tested on amd64/i386/arm64/ppc64el on QEMU, plus amd64
    on baremetal -- see comment 11.
     - hw-detect: low, the changes are enabled by a preseed option.
  see comment 12.
     - partman-iscsi: low, simple changes, plus one fix that has
  been tested in detail, and falls back to
  previous behavior if it fails.
  see comment 13.

  [Other Info]

   * This has been verified both by the developer with a simple iSCSI
     iBFT environment (2 VMs: iSCSI target & initiator with UEFI+iPXE)
     and by an user with system/firmware that supports iBFT for iSCSI.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1817321/+subscriptions

-- 
Mailing

[Sts-sponsors] [Bug 1817321] Re: installer does not support iSCSI iBFT

2019-06-11 Thread Eric Desrochers
Sponsored for Disco 'd-i'. - No-Change rebuild
Will review C/B  'd-i' soon (which involve master kernel change)

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1817321

Title:
  installer does not support iSCSI iBFT

Status in debian-installer package in Ubuntu:
  Fix Released
Status in hw-detect package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in partman-iscsi package in Ubuntu:
  Fix Released
Status in debian-installer source package in Bionic:
  In Progress
Status in hw-detect source package in Bionic:
  Fix Committed
Status in linux source package in Bionic:
  Fix Released
Status in partman-iscsi source package in Bionic:
  Fix Committed
Status in debian-installer source package in Cosmic:
  In Progress
Status in hw-detect source package in Cosmic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Released
Status in partman-iscsi source package in Cosmic:
  Fix Committed
Status in debian-installer source package in Disco:
  In Progress
Status in hw-detect source package in Disco:
  Fix Committed
Status in linux source package in Disco:
  Fix Released
Status in partman-iscsi source package in Disco:
  Fix Committed
Status in debian-installer source package in Eoan:
  Fix Released
Status in hw-detect source package in Eoan:
  Fix Released
Status in linux source package in Eoan:
  Fix Released
Status in partman-iscsi source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * It's not possible to access iBFT (iSCSI Boot Firmware Table) information
     (settings for network interface, initiator, and target) in the installer
     because the 'iscsi_ibft' module is not present in udeb packages.

   * Even if it was, the installer does not handle iBFT information at all,
     thus any settings are ignored, and iSCSI-related configuration has to
     be done manually or with workarounds.

   * This impacts user-experience and automatic installation on systems and
     deployments which actually do provide the iBFT feature and information,
     but cannot use it practically.

   * With proper iBFT support in the installer (kernel module in udeb package
     and automatic iSCSI-related configuration) users will be able to rely on
     iBFT to install/deploy Ubuntu on their servers and datacenters.

   * These fixes add the 'iscsi_ibft' kernel module in the scsi-modules udeb,
     and configure network/iSCSI according to iBFT information in disk-detect.

     This is done in disk-detect so that the iSCSI LUNs are detected as disks
     (useful in case of no other disks in the system so the installer doesn't
     complain nor wait too long) and that any partman-related preseed options
     are not required and may be still available for the user.

  [Test Case]

   * linux package / kernel module in udeb:

     $ dpkg-deb -c scsi-modules_*.udeb | grep iscsi_ibft.ko

     Check the module loads in the installer environment.
     See comment with example for disco.

   * d-i/hw-detect/partman-iscsi package:
     See comments 11, 12, 13.

  [Regression Potential]

   * linux package: low, the kernel module is not loaded by default,
     and only checks whether iBFT information is present in firmware,
     then exposes that in sysfs in read-only mode.

   * d-i/hw-detect/partman-iscsi:
     - d-i: kernel version update to include iscsi_ibft module,
    based on kernel released to -updates plus one week
    monitoring bug reports -- it should be OK.
    Tested on amd64/i386/arm64/ppc64el on QEMU, plus amd64
    on baremetal -- see comment 11.
     - hw-detect: low, the changes are enabled by a preseed option.
  see comment 12.
     - partman-iscsi: low, simple changes, plus one fix that has
  been tested in detail, and falls back to
  previous behavior if it fails.
  see comment 13.

  [Other Info]

   * This has been verified both by the developer with a simple iSCSI
     iBFT environment (2 VMs: iSCSI target & initiator with UEFI+iPXE)
     and by an user with system/firmware that supports iBFT for iSCSI.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1817321/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1818527] Re: Stub resolver cache is corrupted

2019-06-05 Thread Eric Desrochers
[sts-sponsor]

There is an SRU in progress for systemd already for Bionic. It will have
to wait for LP: #1814373 and #1825997 to be 'Fix Released' before
sponsoring that particular bug.

Thanks Heitor for your contribution.

Let's circle back later.

- Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1818527

Title:
  Stub resolver cache is corrupted

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Invalid
Status in systemd source package in Bionic:
  In Progress

Bug description:
  [Impact]
  systemd-resolved fails to resolve A records

  [Description]
  When systemd-resolve caches a non-existent CNAME record for a specific 
domain, further attempts at resolving A records for that same domain  fail. 
This has been fixed upstream in v240.

  Upstream commit:
  https://github.com/systemd/systemd/commit/3740146a4cbd

  $ git describe --contains 3740146a4cbd
  v240~839

  $ rmadison systemd --arch amd64
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.21 | xenial-security | source, ...
   systemd | 229-4ubuntu21.21 | xenial-updates  | source, ...
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.19 | bionic-security | source, ...
   systemd | 237-3ubuntu10.21 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.22 | bionic-proposed | source, ...
   systemd | 239-7ubuntu10| cosmic  | source, ...
   systemd | 239-7ubuntu10.12 | cosmic-security | source, ...
   systemd | 239-7ubuntu10.13 | cosmic-updates  | source, ...
   systemd | 239-7ubuntu10.14 | cosmic-proposed | source, ...
   systemd | 240-6ubuntu5 | disco   | source, ...
   systemd | 240-6ubuntu5.1   | disco-proposed  | source, ...
   systemd | 240-6ubuntu9 | eoan| source, ...

  Despite the package versions above, only Bionic is affected. Cosmic
  already includes a backported fix, and Xenial doesn't seem affected
  due  to resolvconf handling DNS resolution.

  [Test Case]
  Flush resolved's caches and try resolving a non-existent CNAME record. 
Further resolution attempts for the corresponding A record will fail:

  $ systemd-resolve --flush-caches
  $ dig github.com CNAME
  $ dig github.com A

  [Regression Potential]
  The regression potential for this fix should be very low, as it's a direct 
cherry-pick from upstream systemd. It has seen extensive testing  in both 
upstream and other Ubuntu releases, and was verified for Bionic through 
autopkgtests.

  

  [Original Description]

  It seems that when systemd-resolve cache an non-existent CNAME record
  for a domain, any attempt to resolve A record for the same domain
  fail.

  systemd version the issue has been seen with
  Installed: 237-3ubuntu10.13
  Used distribution

  Distributor ID: Ubuntu
  Description: Ubuntu 18.04.2 LTS
  Release: 18.04
  Codename: bionic

  Expected behaviour you didn't see

  Return A record for a domain when it exists.

  Unexpected behaviour you saw

  Resolution failed.

  Steps to reproduce the problem

  Whait for 1 minutes (github.com TTL for A record)

  Try to resolv github.com CNAME record dig CNAME github.com

  This will return an empty result.

  Then try to resolve github.com A record dig A github.com.

  This will now return empty result unless you restart systemd-resolved
  or wait for cache expiration.

  At the same time using another DNS will resolve correctly dig A
  github.com @8.8.8.8.

  Exemple :

  Wait for 1 minutes to let cache expire, then run

  dig CNAME github.com
  dig A github.com
  # no result
  dig A github.com @8.8.8.8
  # ;; ANSWER SECTION:
  # github.com. 59  IN  A   192.30.253.113
  # github.com. 59  IN  A   192.30.253.112

  PS: Don't forget to restart systemd-resolve, before trying to post an
  answer.

  This bug was first reported in github
  https://github.com/systemd/systemd/issues/11789 but systemd version in
  ubuntu is too  old.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818527/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1824236] Re: supermin/liguestfs fails to configure network

2019-05-31 Thread Eric Desrochers
Sponsoring for 'E'.

Considering libguestfs maintainer and Ioanna answers to my concern that
this code can never run outside the appliance and that can't create any
harm inside the appliance as well.

Also trusting that Ioanna will soon file a bug and submit the patch to
Debian as well.

-Eric

** Changed in: libguestfs (Ubuntu)
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1824236

Title:
  supermin/liguestfs fails to configure network

Status in libguestfs package in Ubuntu:
  Fix Committed
Status in supermin package in Ubuntu:
  Invalid
Status in libguestfs source package in Bionic:
  In Progress
Status in supermin source package in Bionic:
  Invalid
Status in libguestfs source package in Cosmic:
  In Progress
Status in supermin source package in Cosmic:
  Invalid
Status in libguestfs source package in Disco:
  In Progress
Status in supermin source package in Disco:
  Invalid

Bug description:
  [Impact]
  libguestfs cannot configure network on Bionic onward.

  This bug is a combination of libguestfs/supermin package and
  /etc/dhcp/dhclient-enter-hooks.d/resolved script from systemd,
  present on Bionic onward.
  When supermin creates the appliance does chroot and executes its init script.
  If networking is enabled init will call dhclient sript to configure the 
network.

  On Bionic onward the make_resolv_conf function of dhclient_script is 
overwritten
  in /etc/dhcp/dhclient-eneter-hooks.d/resolved which before exiting restarts
  the systemd.resolved service.
  However, this happening in chroot environment fails with
  "System has not been booted with systemd as init system (PID 1). Can't 
operate."
  and network is left unconfigured.

  [Test Case]

  $ sudo guestfish -a xenial-server-cloudimg-amd64-disk1.img --network -v << EOF
  run
  mount /dev/sda1 /
  command 'apt update'
  EOF

  libguestfs: launch: program=guestfish
  libguestfs: launch: version=1.36.13
  libguestfs: launch: backend registered: unix
  libguestfs: launch: backend registered: uml
  libguestfs: launch: backend registered: libvirt
  ...
  supermin: deleting initramfs files
  supermin: chroot
  Starting /init script ...
  ...
  + dhclient --version
  + dhclient eth0
  System has not been booted with systemd as init system (PID 1). Can't operate.
  ...
  commandrvf: apt update

  WARNING: apt does not have a stable CLI interface. Use with caution in
  scripts.

  W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/InRelease  
Temporary failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://security.ubuntu.com/ubuntu/dists/xenial-security/InRelease  Temporary 
failure resolving 'security.ubuntu.com'
  W: Some index files failed to download. They have been ignored, or old ones 
used instead.
  ...

  [Regression Potential]

  Minimal. The fix removes the /etc/dhcp/dhclient-eneter-hooks.d/resolved hook 
installed by systemd.
  systemd is not used inside the appliance so it should not cause any 
regression.

  
https://bugs.launchpad.net/ubuntu/cosmic/+source/libguestfs/+bug/1824236/comments/18
  
https://bugs.launchpad.net/ubuntu/cosmic/+source/libguestfs/+bug/1824236/comments/19

  [Other]

  Affects B,C,D,E.

  Upstream fix :
  
https://github.com/libguestfs/libguestfs/commit/2bb6be333e6347d3f18856627d8ad8e50b8e5427

  Workaround

  1) Assume that libguestfs is installed, if not :
  $ sudo apt-get install libguestfs-tools

  2) Move the base.tar.gz to a temp dir, extract and remove tarball
  $ sudo mv /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/base.tar.gz ~/tempdir/
  $ cd ~/tempdir
  $ sudo tar -xzvf base.tar.gz
  $ sudo rm base.tar.gz

  3) Remove the etc/dhcp/dhclient-enter-hooks.d/resolved file
  $ sudo rm etc/dhcp/dhclient-enter-hooks.d/resolved

  4) Create tarball again
  $ sudo tar -czvf base.tar.gz etc

  5) Move it back to installation dir
  $ sudo mv base.tar.gz /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/

  6) Clean cache
  $ sudo rm -rf /var/tmp/.guestfs*

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1824236/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : https://help.launchpad.net/ListHelp


[Sts-sponsors] [Bug 1824236] Re: supermin/liguestfs fails to configure network

2019-05-31 Thread Eric Desrochers
** Description changed:

  [Impact]
  libguestfs cannot configure network on Bionic onward.
  
  This bug is a combination of libguestfs/supermin package and
  /etc/dhcp/dhclient-enter-hooks.d/resolved script from systemd,
  present on Bionic onward.
  When supermin creates the appliance does chroot and executes its init script.
  If networking is enabled init will call dhclient sript to configure the 
network.
  
  On Bionic onward the make_resolv_conf function of dhclient_script is 
overwritten
  in /etc/dhcp/dhclient-eneter-hooks.d/resolved which before exiting restarts
  the systemd.resolved service.
  However, this happening in chroot environment fails with
  "System has not been booted with systemd as init system (PID 1). Can't 
operate."
  and network is left unconfigured.
  
  [Test Case]
  
  $ sudo guestfish -a xenial-server-cloudimg-amd64-disk1.img --network -v << EOF
  run
  mount /dev/sda1 /
  command 'apt update'
  EOF
  
  libguestfs: launch: program=guestfish
  libguestfs: launch: version=1.36.13
  libguestfs: launch: backend registered: unix
  libguestfs: launch: backend registered: uml
  libguestfs: launch: backend registered: libvirt
  ...
  supermin: deleting initramfs files
  supermin: chroot
  Starting /init script ...
  ...
  + dhclient --version
  + dhclient eth0
  System has not been booted with systemd as init system (PID 1). Can't operate.
  ...
  commandrvf: apt update
  
  WARNING: apt does not have a stable CLI interface. Use with caution in
  scripts.
  
  W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/InRelease  
Temporary failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://security.ubuntu.com/ubuntu/dists/xenial-security/InRelease  Temporary 
failure resolving 'security.ubuntu.com'
  W: Some index files failed to download. They have been ignored, or old ones 
used instead.
  ...
  
  [Regression Potential]
  
  Minimal. The fix removes the /etc/dhcp/dhclient-eneter-hooks.d/resolved hook 
installed by systemd.
  systemd is not used inside the appliance so it should not cause any 
regression.
  
+ 
https://bugs.launchpad.net/ubuntu/cosmic/+source/libguestfs/+bug/1824236/comments/18
+ 
https://bugs.launchpad.net/ubuntu/cosmic/+source/libguestfs/+bug/1824236/comments/19
  
  [Other]
  
  Affects B,C,D,E.
  
  Upstream fix :
  
https://github.com/libguestfs/libguestfs/commit/2bb6be333e6347d3f18856627d8ad8e50b8e5427
- 
  
  Workaround
  
  1) Assume that libguestfs is installed, if not :
  $ sudo apt-get install libguestfs-tools
  
  2) Move the base.tar.gz to a temp dir, extract and remove tarball
  $ sudo mv /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/base.tar.gz ~/tempdir/
  $ cd ~/tempdir
  $ sudo tar -xzvf base.tar.gz
  $ sudo rm base.tar.gz
  
  3) Remove the etc/dhcp/dhclient-enter-hooks.d/resolved file
  $ sudo rm etc/dhcp/dhclient-enter-hooks.d/resolved
  
  4) Create tarball again
  $ sudo tar -czvf base.tar.gz etc
  
  5) Move it back to installation dir
  $ sudo mv base.tar.gz /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/
  
  6) Clean cache
  $ sudo rm -rf /var/tmp/.guestfs*

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1824236

Title:
  supermin/liguestfs fails to configure network

Status in libguestfs package in Ubuntu:
  In Progress
Status in supermin package in Ubuntu:
  Invalid
Status in libguestfs source package in Bionic:
  In Progress
Status in supermin source package in Bionic:
  Invalid
Status in libguestfs source package in Cosmic:
  In Progress
Status in supermin source package in Cosmic:
  Invalid
Status in libguestfs source package in Disco:
  In Progress
Status in supermin source package in Disco:
  Invalid

Bug description:
  [Impact]
  libguestfs cannot configure network on Bionic onward.

  This bug is a combination of libguestfs/supermin package and
  /etc/dhcp/dhclient-enter-hooks.d/resolved script from systemd,
  present on Bionic onward.
  When supermin creates the appliance does chroot and executes its init script.
  If networking is enabled init will call dhclient sript to configure the 
network.

  On Bionic onward the make_resolv_conf function of dhclient_script is 
overwritten
  in /etc/dhcp/dhclient-eneter-hooks.d/resolved which before exiting restarts
  the systemd.resolved service.
  However, this happening in chroot environment fails with
  "System has not been booted with systemd as init system (PID 1). Can't 
operate."
  and network is left unconfigured.

  [Test Case]

  $ sudo guestfish -a xenial-server-cloudimg-amd64-disk1.img --network -v << EOF
  run
  mount /dev/sda1 /
  command 'apt update'
  EOF

  libguestfs: launc

[Sts-sponsors] [Bug 1824236] Re: supermin/liguestfs fails to configure network

2019-05-31 Thread Eric Desrochers
Thanks to both of you Ioanna and Richard for your quick reply.

It addresses my concern, you would understand why I ask for
clarification, this patch at first glance look unusual.

Ioanna, you are right, the version are so alike that I missed the
version difference at first.

 libguestfs | 1:1.40.2-1ubuntu1| disco/universe  | source
 libguestfs | 1:1.40.2-2ubuntu1| eoan/universe   | source

I see the difference now, thanks for bringing this up.
Please don't produce a new debdiff. I'll do the necessary change manually 
during the sponsorship:

- Versioning:
Eoan: 1.40.2-2ubuntu2
Disco: 1.40.2-1ubuntu1.1

and

- Quilt patch renaming byt adding the numeric order.

Regards,
Eric

-- 
You received this bug notification because you are a member of STS
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1824236

Title:
  supermin/liguestfs fails to configure network

Status in libguestfs package in Ubuntu:
  In Progress
Status in supermin package in Ubuntu:
  Invalid
Status in libguestfs source package in Bionic:
  In Progress
Status in supermin source package in Bionic:
  Invalid
Status in libguestfs source package in Cosmic:
  In Progress
Status in supermin source package in Cosmic:
  Invalid
Status in libguestfs source package in Disco:
  In Progress
Status in supermin source package in Disco:
  Invalid

Bug description:
  [Impact]
  libguestfs cannot configure network on Bionic onward.

  This bug is a combination of libguestfs/supermin package and
  /etc/dhcp/dhclient-enter-hooks.d/resolved script from systemd,
  present on Bionic onward.
  When supermin creates the appliance does chroot and executes its init script.
  If networking is enabled init will call dhclient sript to configure the 
network.

  On Bionic onward the make_resolv_conf function of dhclient_script is 
overwritten
  in /etc/dhcp/dhclient-eneter-hooks.d/resolved which before exiting restarts
  the systemd.resolved service.
  However, this happening in chroot environment fails with
  "System has not been booted with systemd as init system (PID 1). Can't 
operate."
  and network is left unconfigured.

  [Test Case]

  $ sudo guestfish -a xenial-server-cloudimg-amd64-disk1.img --network -v << EOF
  run
  mount /dev/sda1 /
  command 'apt update'
  EOF

  libguestfs: launch: program=guestfish
  libguestfs: launch: version=1.36.13
  libguestfs: launch: backend registered: unix
  libguestfs: launch: backend registered: uml
  libguestfs: launch: backend registered: libvirt
  ...
  supermin: deleting initramfs files
  supermin: chroot
  Starting /init script ...
  ...
  + dhclient --version
  + dhclient eth0
  System has not been booted with systemd as init system (PID 1). Can't operate.
  ...
  commandrvf: apt update

  WARNING: apt does not have a stable CLI interface. Use with caution in
  scripts.

  W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/InRelease  
Temporary failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease  Temporary 
failure resolving 'archive.ubuntu.com'
  W: Failed to fetch 
http://security.ubuntu.com/ubuntu/dists/xenial-security/InRelease  Temporary 
failure resolving 'security.ubuntu.com'
  W: Some index files failed to download. They have been ignored, or old ones 
used instead.
  ...

  [Regression Potential]

  Minimal. The fix removes the /etc/dhcp/dhclient-eneter-hooks.d/resolved hook 
installed by systemd.
  systemd is not used inside the appliance so it should not cause any 
regression.

  
https://bugs.launchpad.net/ubuntu/cosmic/+source/libguestfs/+bug/1824236/comments/18
  
https://bugs.launchpad.net/ubuntu/cosmic/+source/libguestfs/+bug/1824236/comments/19

  [Other]

  Affects B,C,D,E.

  Upstream fix :
  
https://github.com/libguestfs/libguestfs/commit/2bb6be333e6347d3f18856627d8ad8e50b8e5427

  Workaround

  1) Assume that libguestfs is installed, if not :
  $ sudo apt-get install libguestfs-tools

  2) Move the base.tar.gz to a temp dir, extract and remove tarball
  $ sudo mv /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/base.tar.gz ~/tempdir/
  $ cd ~/tempdir
  $ sudo tar -xzvf base.tar.gz
  $ sudo rm base.tar.gz

  3) Remove the etc/dhcp/dhclient-enter-hooks.d/resolved file
  $ sudo rm etc/dhcp/dhclient-enter-hooks.d/resolved

  4) Create tarball again
  $ sudo tar -czvf base.tar.gz etc

  5) Move it back to installation dir
  $ sudo mv base.tar.gz /usr/lib/x86_64-linux-gnu/guestfs/supermin.d/

  6) Clean cache
  $ sudo rm -rf /var/tmp/.guestfs*

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1824236/+subscriptions

-- 
Mailing list: https://launchpad.net/~sts-sponsors
Post to : sts-sponsors@lists.launchpad.net
Unsubscribe : https://launchpad.net/~sts-sponsors
More help   : 

<    1   2   3   4   5   6   7   >