[Sts-sponsors] [Bug 1871494] Re: add lshw cmd into sosreport's hardware plugin
** 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
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
** 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
** 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
@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
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
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
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
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
** 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
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
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
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
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
** 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
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
** 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
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
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
** 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
** 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
** 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
