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

2020-04-27 Thread Eric Desrochers
** Changed in: sosreport (Ubuntu Focal)
   Importance: Wishlist => Low

** Changed in: sosreport (Ubuntu Eoan)
   Importance: Wishlist => Low

** Changed in: sosreport (Ubuntu Bionic)
   Importance: Wishlist => Low

** Changed in: sosreport (Ubuntu Xenial)
   Importance: Wishlist => Low

-- 
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
Status in sosreport source package in Groovy:
  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 1870087] Re: Old broker lockfile blocks landscape-client starts

2020-04-27 Thread Łukasz Zemczak
Hello Mark, or anyone else affected,

Accepted landscape-client into focal-proposed. The package will build
now and be available at https://launchpad.net/ubuntu/+source/landscape-
client/19.12-0ubuntu4.1 in a few hours, and then in the -proposed
repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: landscape-client (Ubuntu Focal)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-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/1870087

Title:
  Old broker lockfile blocks landscape-client starts

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

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 

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

2020-04-27 Thread Nicolas Bock
** Patch added: "groovy.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1874075/+attachment/5362032/+files/groovy.debdiff

-- 
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
Status in rabbitmq-server source package in Groovy:
  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-27 Thread Dan Streetman
** 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/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
Status in rabbitmq-server source package in Groovy:
  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-27 Thread Jorge Niedbalski
@sil2100 hello lukasz

I've added a **IMPACTED VERSIONS NOTE  note in the description. Any user
running Bionic may hit this issue if running the library in standalone
and hitting the same endpoints. However, this is unlikely to be manifested
by any user, unless it is deployed with octavia (which is in the 
cloud-archive). This component (octavia-api) makes extensive use of the 
barbicanclient API and therefore any clouds >= rocky
deployed on top of Bionic will manifest the issue. 

I hope this clarifies the situation further and if not, please let me know
to provide you any further details.



** Description changed:

  [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.
+  IMPACTED VERSIONS NOTE 
  
- The issue gets exposed with the following octavia
- packages from UCA + python-barbicanclient 4.6.0ubuntu1.
+ This issue can be triggered in standalone without any cloud-archive
+ dependency and affects python-barbicanclient 4.6.0ubuntu1, which is the
+ Bionic version. The issue was fixed in 4.8.1-0ubuntu1 (disco onwards).
  
- Please note that likely this python-barbicanclient dependency should
- be part of UCA and not of main/universe.
+ However, this exception gets easily manifested in OpenStack deployments
+ that uses octavia packages from UCA + python-barbicanclient 4.6.0ubuntu1, as 
it provides direct interaction with the barbican client.
+ 
+ This means that any Ubuntu openstack cloud deployed from UCA on release
+ >= rocky will manifest this issue when deployed on top of Bionic
+ 
  
   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" 

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

2020-04-27 Thread Eric Desrochers
Sponsored in Focal:
https://launchpad.net/ubuntu/focal/+queue?queue_state=1_text=landscape-client

Now waiting in the upload queue. I already pinged sil2100 for SRU
approval.

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

Title:
  Old broker lockfile blocks landscape-client starts

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

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 

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

2020-04-27 Thread Launchpad Bug Tracker
This bug was fixed in the package landscape-client - 19.12-0ubuntu5

---
landscape-client (19.12-0ubuntu5) groovy; urgency=medium

  * d/landscape-client.service (LP: #1870087)
- Set KillMode on service to avoid killing dpkg
  through self-upgrade.

 -- Simon Poirier   Mon, 27 Apr 2020
16:13:02 +

** Changed in: landscape-client (Ubuntu Groovy)
   Status: In Progress => 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/1870087

Title:
  Old broker lockfile blocks landscape-client starts

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

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  

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

2020-04-27 Thread Eric Desrochers
Uploaded in groovy.

-- 
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
Status in sosreport source package in Groovy:
  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 1874526] Re: [landscape] Substitute oidc conf in service file

2020-04-27 Thread Eric Desrochers
Uploaded in groovy.

-- 
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
Status in sosreport source package in Groovy:
  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 1870087] Re: Old broker lockfile blocks landscape-client starts

2020-04-27 Thread Ubuntu Foundations Team Bug Bot
** Tags added: patch

-- 
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:
  In Progress
Status in landscape-client package in Ubuntu:
  In Progress
Status in landscape-client source package in Focal:
  In Progress
Status in landscape-client source package in Groovy:
  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/ 

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

2020-04-27 Thread Eric Desrochers
Uploaded in groovy (see groovy.debdiff)

** Patch added: "groovy.debdiff"
   
https://bugs.launchpad.net/landscape-client/+bug/1870087/+attachment/5361756/+files/groovy.debdiff

-- 
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:
  In Progress
Status in landscape-client package in Ubuntu:
  In Progress
Status in landscape-client source package in Focal:
  In Progress
Status in landscape-client source package in Groovy:
  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 

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

2020-04-27 Thread Eric Desrochers
Once it reaches -releases, I'll go ahead with 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/1870087

Title:
  Old broker lockfile blocks landscape-client starts

Status in Landscape Client:
  In Progress
Status in landscape-client package in Ubuntu:
  In Progress
Status in landscape-client source package in Focal:
  In Progress
Status in landscape-client source package in Groovy:
  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 

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

2020-04-27 Thread Eric Desrochers
I'll fix it manually and will upload in groovy today, so that I can move
with focal hopefully tomorrow.

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

Title:
  Old broker lockfile blocks landscape-client starts

Status in Landscape Client:
  In Progress
Status in landscape-client package in Ubuntu:
  In Progress
Status in landscape-client source package in Focal:
  In Progress
Status in landscape-client source package in Groovy:
  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 

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

2020-04-27 Thread Eric Desrochers
I left a comment in the MP as follows:
"Don't quilt files under debian/. It should always be patchless."

-- 
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:
  In Progress
Status in landscape-client package in Ubuntu:
  In Progress
Status in landscape-client source package in Focal:
  In Progress
Status in landscape-client source package in Groovy:
  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

 

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

2020-04-27 Thread Heather Lemon
** Patch removed: "fix_focal1871494b2.debdiff"
   
https://bugs.launchpad.net/ubuntu/groovy/+source/sosreport/+bug/1871494/+attachment/5357149/+files/fix_1871494b2.debdiff

** Patch added: "fix_focal1871494.debdiff"
   
https://bugs.launchpad.net/ubuntu/groovy/+source/sosreport/+bug/1871494/+attachment/5361751/+files/fix_focal1871494.debdiff

-- 
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
Status in sosreport source package in Groovy:
  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 1871494] Re: add lshw cmd into sosreport's hardware plugin

2020-04-27 Thread Heather Lemon
attached 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/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
Status in sosreport source package in Groovy:
  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 1871494] Re: add lshw cmd into sosreport's hardware plugin

2020-04-27 Thread Heather Lemon
** Patch added: "fix_groovy1871494.debdiff"
   
https://bugs.launchpad.net/ubuntu/eoan/+source/sosreport/+bug/1871494/+attachment/5361748/+files/fix_groovy1871494.debdiff

-- 
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
Status in sosreport source package in Groovy:
  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 1871494] Re: add lshw cmd into sosreport's hardware plugin

2020-04-27 Thread Eric Desrochers
Heather, can you please produce a 'groovy' 20.10 debdiff ?

Thanks

** Also affects: sosreport (Ubuntu Groovy)
   Importance: Wishlist
 Assignee: Heather Lemon (hypothetical-lemon)
   Status: In Progress

** Changed in: sosreport (Ubuntu Groovy)
   Importance: Wishlist => Low

-- 
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
Status in sosreport source package in Groovy:
  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-27 Thread Eric Desrochers
Nicolas, can you please produce a 'groovy' 20.10 debdiff ?

Thanks

** Also affects: rabbitmq-server (Ubuntu Groovy)
   Importance: Low
 Assignee: Nicolas Bock (nicolasbock)
   Status: 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:
  Won't Fix
Status in rabbitmq-server source package in Focal:
  In Progress
Status in rabbitmq-server source package in Groovy:
  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 1870087] Re: Old broker lockfile blocks landscape-client starts

2020-04-27 Thread Eric Desrochers
** Also affects: landscape-client (Ubuntu Groovy)
   Importance: High
 Assignee: Simon Poirier (simpoir)
   Status: 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/1870087

Title:
  Old broker lockfile blocks landscape-client starts

Status in Landscape Client:
  In Progress
Status in landscape-client package in Ubuntu:
  In Progress
Status in landscape-client source package in Focal:
  In Progress
Status in landscape-client source package in Groovy:
  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: 

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

2020-04-27 Thread Eric Desrochers
** Also affects: sosreport (Ubuntu Groovy)
   Importance: High
 Assignee: Eric Desrochers (slashd)
   Status: 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/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
Status in sosreport source package in Groovy:
  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 1871685] Re: [SRU] vagrant spits out ruby deprecation warnings on every call

2020-04-27 Thread Lucas Kanashiro
** Tags removed: verification-needed verification-needed-focal
** Tags added: verification-done-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/1871685

Title:
  [SRU] vagrant spits out ruby deprecation warnings on every call

Status in vagrant package in Ubuntu:
  In Progress

Bug description:
  [Impact]

  This issue is not critical but I believe it degrades a lot the user
  experience in a brand new LTS release. Every time one calls vagrant
  via CLI, Ruby 2.7 throws a bunch of warnings about some deprecated
  features, which for some (inexperienced?) users might seem a failure
  in a first look.

  This was reported not just here as a bug report but also in Discourse:

  https://discourse.ubuntu.com/t/workarounds-for-applications-which-are-
  broken-in-20-04lts/15474/5

  [Test Case]

  In a Focal LXD container:

  $ apt install vagrant
  $ vagrant
  NOTE: Gem::Specification.default_specifications_dir is deprecated; use 
Gem.default_specifications_dir instead. It will be removed on or after 
2020-02-01.
  Gem::Specification.default_specifications_dir called from 
/usr/share/rubygems-integration/all/gems/vagrant-2.2.6/lib/vagrant/bundler.rb:428.
  
/usr/share/rubygems-integration/all/gems/vagrant-2.2.6/lib/vagrant/errors.rb:103:
 warning: Using the last argument as keyword parameters is deprecated; maybe ** 
should be added to the call
  /usr/share/rubygems-integration/all/gems/i18n-1.8.2/lib/i18n.rb:195: warning: 
The called method `t' is defined here
  (eval):3: warning: Using the last argument as keyword parameters is 
deprecated; maybe ** should be added to the call
  /usr/share/rubygems-integration/all/gems/vagrant-2.2.6/lib/vagrant/ui.rb:223: 
warning: The called method `say' is defined here
  Usage: vagrant [options]  []

  -v, --versionPrint the version and exit.
  -h, --help   Print this help.

  Common commands:
   box manages boxes: installation, removal, etc.
   cloud   manages everything related to Vagrant Cloud
   destroy stops and deletes all traces of the vagrant machine
   global-status   outputs status Vagrant environments for this user
   haltstops the vagrant machine
   helpshows the help for a subcommand
   initinitializes a new Vagrant environment by creating a 
Vagrantfile
   login   
   package packages a running vagrant environment into a box
   plugin  manages plugins: install, uninstall, update, etc.
   portdisplays information about guest port mappings
   powershell  connects to machine via powershell remoting
   provision   provisions the vagrant machine
   pushdeploys code in this environment to a configured 
destination
   rdp connects to machine via RDP
   reload  restarts vagrant machine, loads new Vagrantfile 
configuration
   resume  resume a suspended vagrant machine
   snapshotmanages snapshots: saving, restoring, etc.
   ssh connects to machine via SSH
   ssh-config  outputs OpenSSH valid configuration to connect to the 
machine
   status  outputs status of the vagrant machine
   suspend suspends the machine
   up  starts and provisions the vagrant environment
   upload  upload to machine via communicator
   validatevalidates the Vagrantfile
   version prints current and latest Vagrant version
   winrm   executes commands on a machine via WinRM
   winrm-configoutputs WinRM configuration to connect to the machine

  For help on any individual command run `vagrant COMMAND -h`

  Additional subcommands are available, but are either more advanced
  or not commonly used. To see all subcommands, run the command
  `vagrant list-commands`.
  $ vagrant init
  NOTE: Gem::Specification.default_specifications_dir is deprecated; use 
Gem.default_specifications_dir instead. It will be removed on or after 
2020-02-01.
  Gem::Specification.default_specifications_dir called from 
/usr/share/rubygems-integration/all/gems/vagrant-2.2.6/lib/vagrant/bundler.rb:428.
  
/usr/share/rubygems-integration/all/gems/vagrant-2.2.6/lib/vagrant/errors.rb:103:
 warning: Using the last argument as keyword parameters is deprecated; maybe ** 
should be added to the call
  /usr/share/rubygems-integration/all/gems/i18n-1.8.2/lib/i18n.rb:195: warning: 
The called method `t' is defined here
  (eval):3: warning: Using the last argument as keyword parameters is 
deprecated; maybe ** should be added to the call
  /usr/share/rubygems-integration/all/gems/vagrant-2.2.6/lib/vagrant/ui.rb:223: 
warning: The called method `say' is defined here
  A `Vagrantfile` has been placed in this directory. You are now
  ready