[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
> I will attempt to upstream this fix to klibc, but I believe the change
to Bionic should happen in parallel/independently since the upstream
patch will not make its way back to Bionic (which is stuck at 2.0.4, as
mentioned above).
Yes that is the plan to SRU the fix on top of what is currently found in
Bionic's klibc.
And I'll gladly sponsor your patch in Bionic.
The idea with upstream is to make our contribution available to other
who may suffer from the same issue, make sure it won't re-occur in a
future release of Ubuntu as we will sync from debian which sync from
upstream, ... and also have some kind of upstream
adoption/approval/review of your proposal fix.
Let's give a few days after the submission for the upstream to have some
time to review your patch. If it takes too long for them to get back to
us, I'll sponsor the patch as-is, knowing that it was submitted to
upstream with a reasonable amount of time given to them to review.
- Eric
** Changed in: klibc (Ubuntu Bionic)
Assignee: (unassigned) => Khaled El Mously (kmously)
** Changed in: klibc (Ubuntu Bionic)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
In Progress
Bug description:
[Impact]
In some cases, ipconfig can take a longer time than the user-specified
timeouts, causing unexpected delays.
[Test Plan]
Any situation where ipconfig encounters an error sending the DHCP packet, it
will automatically set a delay of 10 seconds, which could be longer than the
user-specified timeout. It can be reproduced by creating a dummy interface and
attempting to run ipconfig on it with a timeout value of less than 10:
# ip link add eth1 type dummy
# date; /usr/lib/klibc/bin/ipconfig -t 2 eth1; date
Thu Nov 18 04:46:13 EST 2021
IP-Config: eth1 hardware address ae:e0:f5:9d:7e:00 mtu 1500 DHCP RARP
IP-Config: no response after 2 secs - giving up
Thu Nov 18 04:46:23 EST 2021
^ Notice above, ipconfig thinks that it waited 2 seconds, but the
timestamps show an actual delay of 10 seconds.
[Where problems could occur]
Please see reproduction steps above. We are seeing this in production too
(see comment #2).
[Other Info]
A patch to fix the issue is being proposed here. It is a safe fix - it only
checks before going into sleep that the timeout never exceeds the
user-requested value.
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list:
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
And let them judge if it's worth an upstream adoption or not as a first
exercise. Then we can take a decision for Ubuntu.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
I still believe, it would be a good practice to submit the patch to
upstream.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
And let them judge if it's worth the adoption or not as a first
exercise. Then we can take a decision for Ubuntu.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
Khaled El Mously (kmously),
Thanks for the update. I'll review this and talk with sil2100, an SRU
verification member.
Could you please help to fill the SRU template in the description above.
Extra documentations can be found here:
https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
What make Bionic more susceptible to this particular problem ? Bionic
kernel version in use ? else ?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in
case of error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had
actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
** Description changed:
+ ** SRU TEMPLATE DRAFT **
+
+ [Impact]
+
+
+ [Test Plan]
+
+
+ [Where problems could occur]
+
+
+ [Other Info]
+
+
+ [Original Description]
+
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again later"
at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end up
extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
+ I believe the current behaviour is buggy. This is confirmed when the
+ following line is executed:
- I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
+ if (loop_timeout >= 0 &&
+ now.tv_sec - start >= loop_timeout) {
+ printf("IP-Config: no response after %d "
+ "secs - giving up\n", loop_timeout);
+ rc = -1;
+ goto bail;
+ }
-
- if (loop_timeout >= 0 &&
- now.tv_sec - start >= loop_timeout) {
- printf("IP-Config: no response after %d "
-"secs - giving up\n", loop_timeout);
- rc = -1;
- goto bail;
- }
-
-
- 'loop_timeout' is the user-specified time-out. With a value of 2, in case of
error, this line prints:
+ 'loop_timeout' is the user-specified time-out. With a value of 2, in
+ case of error, this line prints:
IP-Config: no response after 2 secs - giving up
-
- So it thinks that it waited 2 seconds - however, in reality it had actually
waited for 10 seconds.
+ So it thinks that it waited 2 seconds - however, in reality it had
+ actually waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually used
never exceeds the user-specified timeout.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
** SRU TEMPLATE DRAFT **
[Impact]
[Test Plan]
[Where problems could occur]
[Other Info]
[Original Description]
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
** Tags added: sts
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of
error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually
waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1947099] Re: ipconfig does not honour user-requested timeouts in some cases
@Khaled El Mously (kmously)
I don't see this piece of code in the klibc upstream project[0]
Is this something you only reproduce in Bionic/18.04LTS ?
Since your fix is not found anywhere else, I would be tempted to assume that it
could be affecting other releases of Ubuntu and possibly more.
Could you please erport a bug and submit your patch by making sure the
upstream klibc project adopts it ? It would help get some traction in
order to SRU this patch into Ubuntu.
If it needs to be a UBUNTU_SAUCE only, please provide rationale.
- Eric
[0] - https://git.kernel.org/pub/scm/libs/klibc/klibc.git/about/
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1947099
Title:
ipconfig does not honour user-requested timeouts in some cases
Status in klibc package in Ubuntu:
New
Status in klibc source package in Bionic:
New
Bug description:
In some cases, ipconfig can take longer than the user-specified
timeouts, causing unexpected delays.
in main.c, in function loop(), the process can go into
process_timeout_event() (or process_receive_event() ) and if it
encounters an error situation, will set an attempt to "try again
later" at time equal now + 10 seconds by setting
s->expire = now + 10;
This can happen at any time during the main event loop, which can end
up extending the user-specified timeout if "now + 10" is greater than
"start_time + user-specified-timeout".
I believe a patch like the following is needed to avoid this problem:
--- a/usr/kinit/ipconfig/main.c
+++ b/usr/kinit/ipconfig/main.c
@@ -437,6 +437,13 @@ static int loop(void)
if (timeout > s->expire - now.tv_sec)
timeout = s->expire - now.tv_sec;
+
+ /* Compensate for already-lost time */
+ gettimeofday(, NULL);
+ if (now.tv_sec + timeout > start + loop_timeout) {
+ timeout = loop_timeout - (now.tv_sec - start);
+ printf("Lowered timeout to match user request
= (%d s) \n", timeout);
+ }
}
I believe the current behaviour is buggy. This is confirmed when the
following line is executed:
if (loop_timeout >= 0 &&
now.tv_sec - start >= loop_timeout) {
printf("IP-Config: no response after %d "
"secs - giving up\n", loop_timeout);
rc = -1;
goto bail;
}
'loop_timeout' is the user-specified time-out. With a value of 2, in case of
error, this line prints:
IP-Config: no response after 2 secs - giving up
So it thinks that it waited 2 seconds - however, in reality it had actually
waited for 10 seconds.
The suggested code-change ensures that the timeout that is actually
used never exceeds the user-specified timeout.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1947099/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
[Verification Focal] This has been brought to my attention by an impacted user: " I was able to apply the fixed procps package from the focal-proposed repo on servers in a test cluster. The fix resolved the issue with free -V and the related DataStax OpsCenter error. Thanks " - Eric ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: Fix Committed Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] * Breakage of tools expecting the version number or the number to substantially match the Debian package version. * May confuse users expecting the version to substantially match the Debian package version. * Restores behavior to that provided in Groovy/Hirsute+ and Bionic and prior releases. - Focal is the only release affected. * Backported Debian fix to restore ".tarball-version" file to provide version information during build. - Also included the autopkgtests for versioning from the same Debian fix. [Test Plan] 1) Create a Focal (or derived from Focal) system. 2) Execute "ps --version" or any of the binaries provided by the package with their respective version flags. 3) Instead of desired output of the version, the output is: the invoked binary name followed by "from procps-ng UNKNOWN" Example: "ps from procps-ng UNKNOWN" [Where problems could occur] * This fix could cause issues if applications have come to depend on the incorrect behavior. IE, an application that uses a version string of "UNKNOWN" as part of a heuristic for identifying a Focal system. * If the version of procps-ng is incremented, this patch would need to be updated or removed if it is no longer relevant. Otherwise, an incorrect version would be reported by the binaries. [Other Info] * This change is in Groovy+ and Debian packaging with the same version of procps-ng. - Introduced in procps (2:3.3.16-5) unstable in Debian. [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
[autopkg regression] All tests are now fine. They needed a second retry. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: Fix Committed Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] * Breakage of tools expecting the version number or the number to substantially match the Debian package version. * May confuse users expecting the version to substantially match the Debian package version. * Restores behavior to that provided in Groovy/Hirsute+ and Bionic and prior releases. - Focal is the only release affected. * Backported Debian fix to restore ".tarball-version" file to provide version information during build. - Also included the autopkgtests for versioning from the same Debian fix. [Test Plan] 1) Create a Focal (or derived from Focal) system. 2) Execute "ps --version" or any of the binaries provided by the package with their respective version flags. 3) Instead of desired output of the version, the output is: the invoked binary name followed by "from procps-ng UNKNOWN" Example: "ps from procps-ng UNKNOWN" [Where problems could occur] * This fix could cause issues if applications have come to depend on the incorrect behavior. IE, an application that uses a version string of "UNKNOWN" as part of a heuristic for identifying a Focal system. * If the version of procps-ng is incremented, this patch would need to be updated or removed if it is no longer relevant. Otherwise, an incorrect version would be reported by the binaries. [Other Info] * This change is in Groovy+ and Debian packaging with the same version of procps-ng. - Introduced in procps (2:3.3.16-5) unstable in Debian. [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
I totally get your concern. In the same time, other procps pkkg in Ubuntu groovy, ... uses the same approach. But I leave you to decide what is best for this particular bug. Let us know. Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: In Progress Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] * Breakage of tools expecting the version number or the number to substantially match the Debian package version. * May confuse users expecting the version to substantially match the Debian package version. * Restores behavior to that provided in Groovy/Hirsute+ and Bionic and prior releases. - Focal is the only release affected. * Backported Debian fix to restore ".tarball-version" file to provide version information during build. - Also included the autopkgtests for versioning from the same Debian fix. [Test Plan] 1) Create a Focal (or derived from Focal) system. 2) Execute "ps --version" or any of the binaries provided by the package with their respective version flags. 3) Instead of desired output of the version, the output is: the invoked binary name followed by "from procps-ng UNKNOWN" Example: "ps from procps-ng UNKNOWN" [Where problems could occur] * This fix could cause issues if applications have come to depend on the incorrect behavior. IE, an application that uses a version string of "UNKNOWN" as part of a heuristic for identifying a Focal system. * If the version of procps-ng is incremented, this patch would need to be updated or removed if it is no longer relevant. Otherwise, an incorrect version would be reported by the binaries. [Other Info] * This change is in Groovy+ and Debian packaging with the same version of procps-ng. - Introduced in procps (2:3.3.16-5) unstable in Debian. [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
** Tags removed: sts-sponsors-slashd -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: In Progress Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] * Breakage of tools expecting the version number or the number to substantially match the Debian package version. * May confuse users expecting the version to substantially match the Debian package version. * Restores behavior to that provided in Groovy/Hirsute+ and Bionic and prior releases. - Focal is the only release affected. * Backported Debian fix to restore ".tarball-version" file to provide version information during build. - Also included the autopkgtests for versioning from the same Debian fix. [Test Plan] 1) Create a Focal (or derived from Focal) system. 2) Execute "ps --version" or any of the binaries provided by the package with their respective version flags. 3) Instead of desired output of the version, the output is: the invoked binary name followed by "from procps-ng UNKNOWN" Example: "ps from procps-ng UNKNOWN" [Where problems could occur] * This fix could cause issues if applications have come to depend on the incorrect behavior. IE, an application that uses a version string of "UNKNOWN" as part of a heuristic for identifying a Focal system. * If the version of procps-ng is incremented, this patch would need to be updated or removed if it is no longer relevant. Otherwise, an incorrect version would be reported by the binaries. [Other Info] * This change is in Groovy+ and Debian packaging with the same version of procps-ng. - Introduced in procps (2:3.3.16-5) unstable in Debian. [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
[sts-sponsors] Sponsored in Focal upload queue, now waiting for SRU verification team approval. Thanks for your contribution, Kellen. Test case validation (before upload): root@procpsf:/tmp# pgrep --version pgrep from procps-ng 3.3.16 root@procpsf:/tmp# ps --version ps from procps-ng 3.3.16 root@procpsf:/tmp# free --version free from procps-ng 3.3.16 - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: In Progress Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] * Breakage of tools expecting the version number or the number to substantially match the Debian package version. * May confuse users expecting the version to substantially match the Debian package version. * Restores behavior to that provided in Groovy/Hirsute+ and Bionic and prior releases. - Focal is the only release affected. * Backported Debian fix to restore ".tarball-version" file to provide version information during build. - Also included the autopkgtests for versioning from the same Debian fix. [Test Plan] 1) Create a Focal (or derived from Focal) system. 2) Execute "ps --version" or any of the binaries provided by the package with their respective version flags. 3) Instead of desired output of the version, the output is: the invoked binary name followed by "from procps-ng UNKNOWN" Example: "ps from procps-ng UNKNOWN" [Where problems could occur] * This fix could cause issues if applications have come to depend on the incorrect behavior. IE, an application that uses a version string of "UNKNOWN" as part of a heuristic for identifying a Focal system. * If the version of procps-ng is incremented, this patch would need to be updated or removed if it is no longer relevant. Otherwise, an incorrect version would be reported by the binaries. [Other Info] * This change is in Groovy+ and Debian packaging with the same version of procps-ng. - Introduced in procps (2:3.3.16-5) unstable in Debian. [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
** Description changed: [Impact] * Breakage of tools expecting the version number or the number to substantially match the Debian package version. * May confuse users expecting the version to substantially match the Debian package version. * Restores behavior to that provided in Groovy/Hirsute+ and Bionic and prior releases. - Focal is the only release affected. * Backported Debian fix to restore ".tarball-version" file to provide version information during build. - Also included the autopkgtests for versioning from the same Debian fix. [Test Plan] 1) Create a Focal (or derived from Focal) system. 2) Execute "ps --version" or any of the binaries provided by the package with their respective version flags. 3) Instead of desired output of the version, the output is: the invoked binary name followed by "from procps-ng UNKNOWN" Example: "ps from procps-ng UNKNOWN" [Where problems could occur] * This fix could cause issues if applications have come to depend on the incorrect behavior. IE, an application that uses a version string of "UNKNOWN" as part of a heuristic for identifying a Focal system. * If the version of procps-ng is incremented, this patch would need to be updated or removed if it is no longer relevant. Otherwise, an incorrect version would be reported by the binaries. - * The addition of the autopkgtests could cause testing failures. [Other Info] * This change is in Groovy+ and Debian packaging with the same version of procps-ng. - Introduced in procps (2:3.3.16-5) unstable in Debian. [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: In Progress Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] * Breakage of tools expecting the version number or the number to substantially match the Debian package version. * May confuse users expecting the version to substantially match the Debian package version. * Restores behavior to that provided in Groovy/Hirsute+ and Bionic and prior releases. - Focal is the only release affected. * Backported Debian fix to restore ".tarball-version" file to provide version information during build. - Also included the autopkgtests for versioning from the same Debian fix. [Test Plan] 1) Create a Focal (or derived from Focal) system. 2) Execute "ps --version" or any of the binaries provided by the package with their respective version flags. 3) Instead of desired output of the version, the output is: the invoked binary name followed by "from procps-ng UNKNOWN" Example: "ps from procps-ng UNKNOWN" [Where problems could occur] * This fix could cause issues if applications have come to depend on the incorrect behavior. IE, an application that uses a version string of "UNKNOWN" as part of a heuristic for identifying a Focal system. * If the version of procps-ng is incremented, this patch would need to be updated or removed if it is no longer relevant. Otherwise, an incorrect version would be reported by the binaries. [Other Info] * This change is in Groovy+ and Debian packaging with the same version of procps-ng. - Introduced in procps (2:3.3.16-5) unstable in Debian. [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
[sts-sponsors] Debian uses autopkgtest for 'version' w/ restriction superficial as follows: Tests: version Restrictions: superficial https://people.debian.org/~eriberto/README.package-tests.html superficial The test does not provide significant test coverage, so if it passes, that does not necessarily mean that the package under test is actually functional. If a superficial test fails, it will be treated like any other failing test, but if it succeeds, this is only a weak indication of success. Continuous integration systems should treat a package where all non-superficial tests are skipped as equivalent to a package where all tests are skipped. Additionally, since that ".tarball-version" only focus on upstream version "3.3.16". The version won't change unless ones bump the version (which won't happen in stable release) unless under serious exception. So this value is unlikely to be removed or changes any time soon in Focal. Usually, adding autopkgtest inside an SRU is not a desired change. For the above reasons, I think it is safe to skip the autopkgtest and only focus on the version fix. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: In Progress Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] * Breakage of tools expecting the version number or the number to substantially match the Debian package version. * May confuse users expecting the version to substantially match the Debian package version. * Restores behavior to that provided in Groovy/Hirsute+ and Bionic and prior releases. - Focal is the only release affected. * Backported Debian fix to restore ".tarball-version" file to provide version information during build. - Also included the autopkgtests for versioning from the same Debian fix. [Test Plan] 1) Create a Focal (or derived from Focal) system. 2) Execute "ps --version" or any of the binaries provided by the package with their respective version flags. 3) Instead of desired output of the version, the output is: the invoked binary name followed by "from procps-ng UNKNOWN" Example: "ps from procps-ng UNKNOWN" [Where problems could occur] * This fix could cause issues if applications have come to depend on the incorrect behavior. IE, an application that uses a version string of "UNKNOWN" as part of a heuristic for identifying a Focal system. * If the version of procps-ng is incremented, this patch would need to be updated or removed if it is no longer relevant. Otherwise, an incorrect version would be reported by the binaries. * The addition of the autopkgtests could cause testing failures. [Other Info] * This change is in Groovy+ and Debian packaging with the same version of procps-ng. - Introduced in procps (2:3.3.16-5) unstable in Debian. [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
** Tags added: sts-sponsors-slashd -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: Confirmed Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] [Test Plan] [Where problems could occur] [Other Info] [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
** Tags added: seg sts ** Also affects: procps (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: procps (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: procps (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: procps (Ubuntu Impish) Importance: Undecided Assignee: Kellen Renshaw (krenshaw) Status: Confirmed ** Changed in: procps (Ubuntu Bionic) Status: New => Fix Released ** Changed in: procps (Ubuntu Hirsute) Status: New => Fix Released ** Changed in: procps (Ubuntu Impish) Status: Confirmed => Fix Released ** Changed in: procps (Ubuntu Focal) Assignee: (unassigned) => Kellen Renshaw (krenshaw) ** Changed in: procps (Ubuntu Impish) Assignee: Kellen Renshaw (krenshaw) => (unassigned) ** Changed in: procps (Ubuntu Focal) Importance: Undecided => Low ** Description changed: + [Impact] + + + [Test Plan] + + + [Where problems could occur] + + + [Other Info] + + + [Original Description] + From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. ** Changed in: procps (Ubuntu Focal) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Fix Released Status in procps source package in Bionic: Fix Released Status in procps source package in Focal: Confirmed Status in procps source package in Hirsute: Fix Released Status in procps source package in Impish: Fix Released Bug description: [Impact] [Test Plan] [Where problems could occur] [Other Info] [Original Description] From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1917148] Re: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2
I'll be reviewing the change with my colleague Kellen. In the meanwhile ... What is the concern/impact behind not having the version available in ps ? (Outside it should output/report it) ? The version can be found in the package version (dpkg -l procps) Is it for integrity purposes in order to make sure the ps binary in place really comes from that given procps package ? If it is the case, making --version works won't help much as an integrity check. There are other approaches that can be used to achieve this goal such as 'dpkg '-- verify' and '--audit' To summarize, I'm trying to find the rationale behind it to clearly document the bug when we'll reach the SRU approval/justification. Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1917148 Title: ps version is UNKNOWN in procps 2:3.3.16-1ubuntu2 Status in procps package in Ubuntu: Confirmed Bug description: From Linux Lint 20.1, so Focal Fossa 20.04.1 Package procps 2:3.3.16-1ubuntu2 $ LANG=C ps --version ps from procps-ng UNKNOWN I don't know if it comes from Ubuntu or upstream. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1917148/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
systemd reaches day 7 wo/ autopkgtest failure nor negative
outcome/feedbacks.
I have asked 'sil2100' to promote the package into bionic-updates.
Stay tuned ...
- Eric
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Won't Fix
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Fix Released
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
Thanks Maanus for all the testing. Much appreciated.
I'll take care of the rest in a couple of days with Lukasz.
Package needs to stay in proposed for a couple more days (minimum 7 days)
- Eric
** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Won't Fix
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Fix Committed
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
Hi Maanus,
Would you mind perform the 'test cases' now against the systemd's
bionic-proposed package ? And report any outcome.
This is one of the last steps for Lukasz to approve the proposed package
after the baking minimum aging period (7 days) in verification phase.
- Eric
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Won't Fix
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Fix Committed
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
Uploaded into bionic upload queue, now waiting for SRU approval.
- Eric
** Changed in: systemd (Ubuntu Bionic)
Status: Incomplete => In Progress
** Changed in: systemd (Ubuntu Bionic)
Assignee: (unassigned) => Eric Desrochers (slashd)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Won't Fix
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, defa
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
Good catch Dan.
Maanus could you repeat the testing with what Dan brought up ?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Won't Fix
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Incomplete
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
vrrp_sync_group collection {
group {
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
Thanks @Maanus.
So the outcome is positive here then.
- Eric
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Won't Fix
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Incomplete
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
vrrp_sync_group collection {
group {
wan
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
@maanus, That is a first iteration.
sudo add-apt-repository ppa:slashd/keepconfiguration
sudo apt-get update
Let me know the outcome.
- Eric
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Won't Fix
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Incomplete
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
Any volunteer to test a package in Bionic in the attempt to support
keepconfiguration ?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Won't Fix
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
Incomplete
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
vrrp_sync_group collection {
group {
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
I think 'backports' would have been a great place to have this behavior change in Bionic while keep the current one in -updates. I just came across an email about 'backports' about to die (from rbasak). Let's see what is the outcome and rely on the flock() alternative for now. I'll monitor the "-backports" discussion and let's see from there. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
I'm on the same page. Maybe we should leave the package in -update as is and go with the flock() alternative. OR evaluate if, let's say, the Focal's iptables could be backported (if feasible) in bionic-backports. That way, one who wants the 'wait' and 'wait-interval' to be available could rely on -backport, while the rest of our Bionic users could remain on the same old iptables behavior provided in -updates. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
New testpackage: iptables - 1.6.1-2ubuntu2+testpkg20210706b8 Note: If that works as expected for Andreas. The only things that needed would be to update the manpage, which I didn't do on this current test pkg. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
Both 'iptables' and 'ip*tables-restores' sleep and wait until the lock is released if no 'wait' option. If 'wait' option is set, it wait for the amount of time instructed and stop waiting. I think the printed message make more sense now : # time cat /etc/rules.v4 | iptables-restore -c Another app is currently holding the xtables lock; still -9s 0us time ahead to have a chance to grab the lock... # time cat /etc/rules.v4 | iptables-restore -c -w 2 Another app is currently holding the xtables lock. Stopped waiting after 2s. # time cat /etc/rules.v4 | ip6tables-restore -c Another app is currently holding the xtables lock; still -9s 0us time ahead to have a chance to grab the lock... # time cat /etc/rules.v4 | ip6tables-restore -c -w 2 Another app is currently holding the xtables lock. Stopped waiting after 2s. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
I'll work to re-arrange the fprintf if 'wait' option is used or not and see the outcome of it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
Version in comment #12 is "iptables - 1.6.1-2ubuntu2+testpkg20210706b4" -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
I have a new test pkg: This pkg keeps the same behavior for 'iptables' # Hold the lock: flock /run/xtables.lock sleep 36000 # It holds and wait until flock() finishes or get killed, and then get executed. iptables -L # With 'wait' option, it waits until the wait time is ended: time iptables -L -w 3 Another app is currently holding the xtables lock. Stopped waiting after 3s. real0m3.006s user0m0.002s sys 0m0.001s --- # Hold the lock: flock /run/xtables.lock sleep 36000 # cat /etc/rules.v4 | iptables-restore -c -w 5 Another app is currently holding the xtables lock. Perhaps you want to use the -w option? real0m5.009s user0m0.006s sys 0m0.001s The 'wait' option instruction is respected. The message may be confusing as it is suggesting to use '-w' even if it was used. This is the progress I have made so far. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
What about "iptables - 1.6.1-2ubuntu2+testpkg20210629b3" ? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
Thanks Andreas. I'll be working on a minimalistic patch set (if feasible) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
Thanks Andreas. I'll be working on a minimalistic patch set -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
Look like a potential patchset to backport without having to bump
version in stable release:
6e2e169eb iptables: remove duplicated argument parsing code
24f81746 xshared: do not lock again and again if "-w" option is not specified
72bb3dbf0 xshared: using the blocking file lock request when we wait
indefinitely
999eaa24 iptables-restore: support acquiring the lock.
65801d02 iptables-restore.8: document -w/-W options
21ba5b38 ip{,6}tables-restore: Don't accept wait-interval without wait
I'll test it, and then will talk w/ the SRU verification team to see if
eligible for SRU.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1791958
Title:
iptables-restore is missing -w option
Status in iptables package in Ubuntu:
Confirmed
Bug description:
For CRIU we need to have iptables version 1.6.2 which includes the
'-w' option in iptables-restore.
This is a request to update iptables to 1.6.2 in 18.10 and if possible
backport the necessary changes to 18.04.
The CRIU project gets right now many bug reports (mostly in the
combination LXD + CRIU) due to the missing '-w' option in iptables-
restore. Especially as 18.04 will be around for some time it would be
good to have iptables-restore available with '-w'.
This is one example bug report: https://github.com/checkpoint-
restore/criu/issues/551
But not only CRIU would benefit from this change. It seems also
problematic with Kubernetes:
https://github.com/kubernetes/kubernetes/pull/60978
So if possible, please update iptables to 1.6.2 (or backport changes)
to support -w in iptables-restore.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
Look like a potential patchset to backport without having to bump
version in stable release:
I'll test it, and then will alk w/ the SRU verification team to see if
eligible for SRU.
commit 6e2e169eb66b63d2991e1c7ada931e3cdb0ced32
Author: Lorenzo Colitti
Date: Thu Mar 16 16:55:01 2017 +0900
iptables: remove duplicated argument parsing code
1. Factor out repeated code to a new xs_has_arg function.
2. Add a new parse_wait_time option to parse the value of -w.
3. Make parse_wait_interval take argc and argv so its callers
can be simpler.
+
21ba5b38 ip{,6}tables-restore: Don't accept wait-interval without wait
d89dc47a iptables-restore/save: exit when given an unknown option
65801d02 iptables-restore.8: document -w/-W options
999eaa24 iptables-restore: support acquiring the lock.
** Tags added: seg sts
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1791958
Title:
iptables-restore is missing -w option
Status in iptables package in Ubuntu:
Confirmed
Bug description:
For CRIU we need to have iptables version 1.6.2 which includes the
'-w' option in iptables-restore.
This is a request to update iptables to 1.6.2 in 18.10 and if possible
backport the necessary changes to 18.04.
The CRIU project gets right now many bug reports (mostly in the
combination LXD + CRIU) due to the missing '-w' option in iptables-
restore. Especially as 18.04 will be around for some time it would be
good to have iptables-restore available with '-w'.
This is one example bug report: https://github.com/checkpoint-
restore/criu/issues/551
But not only CRIU would benefit from this change. It seems also
problematic with Kubernetes:
https://github.com/kubernetes/kubernetes/pull/60978
So if possible, please update iptables to 1.6.2 (or backport changes)
to support -w in iptables-restore.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791958] Re: iptables-restore is missing -w option
Look like a potential patchset to backport without having to bump
version in stable release:
21ba5b38 ip{,6}tables-restore: Don't accept wait-interval without wait
d89dc47a iptables-restore/save: exit when given an unknown option
65801d02 iptables-restore.8: document -w/-W options
999eaa24 iptables-restore: support acquiring the lock.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1791958
Title:
iptables-restore is missing -w option
Status in iptables package in Ubuntu:
Confirmed
Bug description:
For CRIU we need to have iptables version 1.6.2 which includes the
'-w' option in iptables-restore.
This is a request to update iptables to 1.6.2 in 18.10 and if possible
backport the necessary changes to 18.04.
The CRIU project gets right now many bug reports (mostly in the
combination LXD + CRIU) due to the missing '-w' option in iptables-
restore. Especially as 18.04 will be around for some time it would be
good to have iptables-restore available with '-w'.
This is one example bug report: https://github.com/checkpoint-
restore/criu/issues/551
But not only CRIU would benefit from this change. It seems also
problematic with Kubernetes:
https://github.com/kubernetes/kubernetes/pull/60978
So if possible, please update iptables to 1.6.2 (or backport changes)
to support -w in iptables-restore.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1791958/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1930286] Re: Defensics' synopsys fuzzer testing tool cause openssh to segfault
** Description changed: [Impact] Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 * Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. * coredump: $ gdb $(which sshd) .sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) [Test plan] ** NOT REPRODUCIBLE ON MY SIDE ** This seems to be a corner case generated by the Defensics fuzzer test suite (proprietary software from synopsys). That's the only way this could have been reproduced so far. + Here's the details I could gather about the fuzzer test scenario: + + -- + Test Suite: SSHv2 Server Test Suite by Synopsys + Test Case Description: + SSHv2.Key-Exchange.DH-GROUP-EXCHANGE-SHA256.message-sequence.duplicate-message: + Insert extra message 'message-2' before message 'client-newkeys' + -- + [Where problem could occur] [Other information] Upstream fix: https://github.com/openssh/openssh-portable/commit/2adbe1e63bc313d03e8e84e652cc623af8ebb163 Only Xenial requires the fix: # git describe --contains 2adbe1e V_7_5_P1~7 # rmadison openssh => openssh | 1:7.2p2-4ubuntu2.10 | xenial-updates | source openssh | 1:7.6p1-4 | bionic | source openssh | 1:7.6p1-4ubuntu0.3 | bionic-security | source openssh | 1:7.6p1-4ubuntu0.3 | bionic-updates | source openssh | 1:7.6p1-4ubuntu0.4 | bionic-proposed | source openssh | 1:8.2p1-4 | focal| source openssh | 1:8.2p1-4ubuntu0.2 | focal-security | source openssh | 1:8.2p1-4ubuntu0.2 | focal-updates| source openssh | 1:8.3p1-1 | groovy | source openssh | 1:8.3p1-1ubuntu0.1 | groovy-security | source openssh | 1:8.3p1-1ubuntu0.1 | groovy-updates | source openssh | 1:8.4p1-5ubuntu1| hirsute | source openssh | 1:8.4p1-5ubuntu1| impish | source -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1930286 Title: Defensics' synopsys fuzzer testing tool cause openssh to segfault Status in openssh package in Ubuntu: Fix Released Status in openssh source package in Xenial: In Progress Bug description: [Impact] Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 * Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. * coredump: $ gdb $(which sshd) .sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at
[Touch-packages] [Bug 1930286] Re: Defensics' synopsys fuzzer testing tool cause openssh to segfault
debdiff to go over the ESM process by security team. Thanks - Eric ** Patch added: "xenial_lp1930286.debdiff" https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1930286/+attachment/5502934/+files/xenial_lp1930286.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1930286 Title: Defensics' synopsys fuzzer testing tool cause openssh to segfault Status in openssh package in Ubuntu: Fix Released Status in openssh source package in Xenial: In Progress Bug description: [Impact] Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 * Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. * coredump: $ gdb $(which sshd) .sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) [Test plan] ** NOT REPRODUCIBLE ON MY SIDE ** This seems to be a corner case generated by the Defensics fuzzer test suite (proprietary software from synopsys). That's the only way this could have been reproduced so far. [Where problem could occur] [Other information] Upstream fix: https://github.com/openssh/openssh-portable/commit/2adbe1e63bc313d03e8e84e652cc623af8ebb163 Only Xenial requires the fix: # git describe --contains 2adbe1e V_7_5_P1~7 # rmadison openssh => openssh | 1:7.2p2-4ubuntu2.10 | xenial-updates | source openssh | 1:7.6p1-4 | bionic | source openssh | 1:7.6p1-4ubuntu0.3 | bionic-security | source openssh | 1:7.6p1-4ubuntu0.3 | bionic-updates | source openssh | 1:7.6p1-4ubuntu0.4 | bionic-proposed | source openssh | 1:8.2p1-4 | focal| source openssh | 1:8.2p1-4ubuntu0.2 | focal-security | source openssh | 1:8.2p1-4ubuntu0.2 | focal-updates| source openssh | 1:8.3p1-1 | groovy | source openssh | 1:8.3p1-1ubuntu0.1 | groovy-security | source openssh | 1:8.3p1-1ubuntu0.1 | groovy-updates | source openssh | 1:8.4p1-5ubuntu1| hirsute | source openssh | 1:8.4p1-5ubuntu1| impish | source To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1930286/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1930286] Re: Defensics' synopsys fuzzer testing tool cause openssh to segfault
** Changed in: openssh (Ubuntu Xenial) Status: New => In Progress ** Description changed: + [Impact] Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 * Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. Still working on getting access to one (if possible) in order to better understand what the failing test scenario is doing. * coredump: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) + + [Test plan] + + ** NOT REPRODUCIBLE ON MY SIDE ** + + This seems to be a corner case generated by the Defensics fuzzer test + suite (proprietary software from synopsys). + + That's the only way this could have been reproduced so far. + + [Where problem could occur] + + [Other information] + + Upstream fix: + https://github.com/openssh/openssh-portable/commit/2adbe1e63bc313d03e8e84e652cc623af8ebb163 + + Only Xenial requires the fix: + + # git describe --contains 2adbe1e + V_7_5_P1~7 + + # rmadison openssh + => openssh | 1:7.2p2-4ubuntu2.10 | xenial-updates | source + openssh | 1:7.6p1-4 | bionic | source + openssh | 1:7.6p1-4ubuntu0.3 | bionic-security | source + openssh | 1:7.6p1-4ubuntu0.3 | bionic-updates | source + openssh | 1:7.6p1-4ubuntu0.4 | bionic-proposed | source + openssh | 1:8.2p1-4 | focal| source + openssh | 1:8.2p1-4ubuntu0.2 | focal-security | source + openssh | 1:8.2p1-4ubuntu0.2 | focal-updates| source + openssh | 1:8.3p1-1 | groovy | source + openssh | 1:8.3p1-1ubuntu0.1 | groovy-security | source + openssh | 1:8.3p1-1ubuntu0.1 | groovy-updates | source + openssh | 1:8.4p1-5ubuntu1| hirsute | source + openssh | 1:8.4p1-5ubuntu1| impish | source ** Changed in: openssh (Ubuntu) Status: New => Fix Released ** Changed in: openssh (Ubuntu Xenial) Importance: Undecided => Medium ** Description changed: - [Impact] + [Impact] Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 * Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) - As of today, I have no access to a reproducer. Still working on getting - access to one (if possible) in order to better understand what the - failing test scenario is doing. + As of today, I have no access to a reproducer. * coredump: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in
[Touch-packages] [Bug 1930286] Re: Defensics' synopsys fuzzer testing tool cause openssh to segfault
UA customer test pkg outcome: " We ran the Defensics test suite before and after installing the test packages. We could observe two core dumps before the test package installation. But after test package installation, core dumps were not generated. Can you provide this package as the fix? " This concludes that xenial + commit 2adbe1e63bc313d03e8e84e652cc623af8ebb163 fixes their fuzzer segfault situation. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1930286 Title: Defensics' synopsys fuzzer testing tool cause openssh to segfault Status in openssh package in Ubuntu: New Status in openssh source package in Xenial: New Bug description: Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 * Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. Still working on getting access to one (if possible) in order to better understand what the failing test scenario is doing. * coredump: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1930286/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1930286] Re: Defensics' synopsys fuzzer testing tool cause openssh to segfault
Hello Seth, So far no production impact has been reported, for now it is only reproducible using that particular fuzzer on xenial's openssh version. Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1930286 Title: Defensics' synopsys fuzzer testing tool cause openssh to segfault Status in openssh package in Ubuntu: New Status in openssh source package in Xenial: New Bug description: Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 * Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. Still working on getting access to one (if possible) in order to better understand what the failing test scenario is doing. * coredump: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1930286/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1930286] Re: Defensics fuzzer testing tool cause openssh to segfault
I have produced a test pkg including the potential fix candidate above for the impacted UA customer to test in their lab. Unfortunately, I have no access to a reproducer since this fuzzer is proprietary and need to be purchased. Meaning, the testing will rely on UA customer end. - Eric ** Description changed: - I'm reporting this bug to keep track of it, as of today I'm still - collecting informations. + Here's what has been brought to my attention by a UA customer: - Here's what I have gathered so far: + * Release: + Xenial/16.04LTS - Release: Xenial/16.04LTS - Openssh version :7.2p2-4ubuntu2.10 - Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) + * Openssh version: + 7.2p2-4ubuntu2.10 + + * Fuzzer tool used: + https://www.synopsys.com/software-integrity/security-testing/fuzz testing.html (proprietary software) As of today, I have no access to a reproducer. Still working on getting - access to one and better understand what the failing test scenario is - doing. + access to one (if possible) in order to better understand what the + failing test scenario is doing. - gdb backtrace: + * coredump: + $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) ** Summary changed: - Defensics fuzzer testing tool cause openssh to segfault + Defensics' synopsys fuzzer testing tool cause openssh to segfault ** Description changed: Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 - * Fuzzer tool used: - https://www.synopsys.com/software-integrity/security-testing/fuzz testing.html (proprietary software) + * Fuzzer tool used: + https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html(proprietary software) As of today, I have no access to a reproducer. Still working on getting access to one (if possible) in order to better understand what the failing test scenario is doing. * coredump: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8
[Touch-packages] [Bug 1930286] Re: Defensics fuzzer testing tool cause openssh to segfault
Potential fix candidate: https://github.com/openssh/openssh-portable/commit/2adbe1e63bc313d03e8e84e652cc623af8ebb163 ** Tags added: seg sts -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1930286 Title: Defensics fuzzer testing tool cause openssh to segfault Status in openssh package in Ubuntu: New Status in openssh source package in Xenial: New Bug description: I'm reporting this bug to keep track of it, as of today I'm still collecting informations. Here's what I have gathered so far: Release: Xenial/16.04LTS Openssh version :7.2p2-4ubuntu2.10 Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. Still working on getting access to one and better understand what the failing test scenario is doing. gdb backtrace: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1930286/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1930286] [NEW] Defensics fuzzer testing tool cause openssh to segfault
Public bug reported: I'm reporting this bug to keep track of it, as of today I'm still collecting informations. Here's what I have gathered so far: Release: Xenial/16.04LTS Openssh version :7.2p2-4ubuntu2.10 Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. Still working on getting access to one and better understand what the failing test scenario is doing. gdb backtrace: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) ** Affects: openssh (Ubuntu) Importance: Undecided Status: New ** Affects: openssh (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: openssh (Ubuntu Xenial) Importance: Undecided Status: New ** Description changed: I'm reporting this bug to keep track of it, as of today I'm still collecting informations. Here's what I have gathered so far: Release: Xenial/16.04LTS Openssh version :7.2p2-4ubuntu2.10 - Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html + Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) + + As of today, I have no access to a reproducer. gdb backtrace: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) ** Description changed: I'm reporting this bug to keep track of it, as of today I'm still collecting informations. Here's what I have gathered so far: Release: Xenial/16.04LTS Openssh version :7.2p2-4ubuntu2.10 Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) - As of today, I have no access to a reproducer. + As of today, I have no access to a reproducer. Still working on getting + access to one and better understand what the failing
[Touch-packages] [Bug 1856871] Re: i/o error if next unused loop device is queried
** Changed in: linux (Ubuntu) Assignee: Eric Desrochers (slashd) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1856871 Title: i/o error if next unused loop device is queried Status in linux package in Ubuntu: In Progress Status in parted package in Ubuntu: Invalid Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in udev package in Ubuntu: Invalid Bug description: This is reproducible in Bionic and late. Here's an example running 'focal': $ lsb_release -cs focal $ uname -r 5.3.0-24-generic The error is: blk_update_request: I/O error, dev loop2, sector 0 and on more recent kernel: kernel: [18135.185709] blk_update_request: I/O error, dev loop18, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0 How to trigger it: $ sosreport -o block or more precisely the cmd causing the situation inside the block plugin: $ parted -s $(losetup -f) unit s print https://github.com/sosreport/sos/blob/master/sos/plugins/block.py#L52 but if I run it on the next next unused loop device, in this case /dev/loop3 (which is also unused), no errors. While I agree that sosreport shouldn't query unused loop devices, there is definitely something going on with the next unused loop device. What is differentiate loop2 and loop3 and any other unused ones ? 3 things so far I have noticed: * loop2 is the next unused loop device (losetup -f) * A reboot is needed (if some loop modification (snap install, mount loop, ...) has been made at runtime * I have also noticed that loop2 (or whatever the next unused one is) have some stat as oppose to other unused loop devices. The stat exist already right after the system boot for the next unused loop device. /sys/block/loop2/stat :: 2 0 10 0 1 0 0 0 0 0 0 2 = number of read I/Os processed 10 = number of sectors read 1 = number of write I/Os processed Explanation of each column: https://www.kernel.org/doc/html/latest/block/stat.html while /dev/loop3 doesn't /sys/block/loop3/stat :: 0 0 0 0 0 0 0 0 0 0 0 Which tells me that something during the boot process most likely acquired (on purpose or not) the next unused loop and possibly didn't released it well enough. If loop2 is generating errors, and I install a snap, the snap squashfs will take loop2, making loop3 the next unused loop device. If I query loop3 with 'parted' right after, no errors. If I reboot, and query loop3 again, then no I'll have an error. To triggers the errors it need to be after a reboot and it only impact the first unused loop device available (losetup -f). This was tested with focal/systemd whic his very close to latest upstream code. This has been test with latest v5.5 mainline kernel as well. For now, I don't think it's a kernel problem, I'm more thinking of a userspace misbehaviour dealing with loop device (or block device) at boot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1856871/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
** Description changed: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. - [TEST CASE] + [TEST PLAN] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. - [REGRESSION POTENTIAL] + [WHERE PROBLEM COULD OCCUR] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. - [SCOPE] + [OTHER] - This is already in H, need backporting to B,G,F. - - Ubuntu-hirsute commits : - - https://git.launchpad.net/~ubuntu-core- - dev/ubuntu/+source/systemd/commit/?h=ubuntu- - hirsute=ce31df6711a8e112cff929ed3bbdcd194f876270 - - https://git.launchpad.net/~ubuntu-core- - dev/ubuntu/+source/systemd/commit/?h=ubuntu- - hirsute=ec1130fece7ca66273773119775e51045a74122c - - Debian commits : - - https://salsa.debian.org/systemd- - team/systemd/-/commit/ce31df6711a8e112cff929ed3bbdcd194f876270 - - https://salsa.debian.org/systemd- - team/systemd/-/commit/ec1130fece7ca66273773119775e51045a74122c - - [OTHER] + This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Status in systemd source package in Groovy: In Progress Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST PLAN] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [WHERE PROBLEM COULD OCCUR] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes
[Touch-packages] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
** Changed in: systemd (Ubuntu Groovy) Assignee: (unassigned) => Ioanna Alifieraki (joalif) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Status in systemd source package in Groovy: In Progress Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. [SCOPE] This is already in H, need backporting to B,G,F. Ubuntu-hirsute commits : https://git.launchpad.net/~ubuntu-core- dev/ubuntu/+source/systemd/commit/?h=ubuntu- hirsute=ce31df6711a8e112cff929ed3bbdcd194f876270 https://git.launchpad.net/~ubuntu-core- dev/ubuntu/+source/systemd/commit/?h=ubuntu- hirsute=ec1130fece7ca66273773119775e51045a74122c Debian commits : https://salsa.debian.org/systemd- team/systemd/-/commit/ce31df6711a8e112cff929ed3bbdcd194f876270 https://salsa.debian.org/systemd- team/systemd/-/commit/ec1130fece7ca66273773119775e51045a74122c [OTHER] Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
** Tags added: sts-sponsors-ddstreet ** Changed in: systemd (Ubuntu Focal) Status: Confirmed => In Progress ** Changed in: systemd (Ubuntu Groovy) Status: Confirmed => In Progress ** Changed in: systemd (Ubuntu Bionic) Status: Confirmed => In Progress ** Changed in: systemd (Ubuntu Bionic) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Changed in: systemd (Ubuntu Focal) Assignee: (unassigned) => Ioanna Alifieraki (joalif) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Status in systemd source package in Groovy: In Progress Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. [OTHER] This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1856871] Re: i/o error if next unused loop device is queried
The upstream proposal fix that mfo and I worked on has been applied: https://patchwork.kernel.org/project/linux- block/patch/20210222154123.61797-1-...@canonical.com/ - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1856871 Title: i/o error if next unused loop device is queried Status in linux package in Ubuntu: Incomplete Status in parted package in Ubuntu: New Status in snapd package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Status in udev package in Ubuntu: Invalid Bug description: This is reproducible in Bionic and late. Here's an example running 'focal': $ lsb_release -cs focal $ uname -r 5.3.0-24-generic The error is: blk_update_request: I/O error, dev loop2, sector 0 and on more recent kernel: kernel: [18135.185709] blk_update_request: I/O error, dev loop18, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0 How to trigger it: $ sosreport -o block or more precisely the cmd causing the situation inside the block plugin: $ parted -s $(losetup -f) unit s print https://github.com/sosreport/sos/blob/master/sos/plugins/block.py#L52 but if I run it on the next next unused loop device, in this case /dev/loop3 (which is also unused), no errors. While I agree that sosreport shouldn't query unused loop devices, there is definitely something going on with the next unused loop device. What is differentiate loop2 and loop3 and any other unused ones ? 3 things so far I have noticed: * loop2 is the next unused loop device (losetup -f) * A reboot is needed (if some loop modification (snap install, mount loop, ...) has been made at runtime * I have also noticed that loop2 (or whatever the next unused one is) have some stat as oppose to other unused loop devices. The stat exist already right after the system boot for the next unused loop device. /sys/block/loop2/stat :: 2 0 10 0 1 0 0 0 0 0 0 2 = number of read I/Os processed 10 = number of sectors read 1 = number of write I/Os processed Explanation of each column: https://www.kernel.org/doc/html/latest/block/stat.html while /dev/loop3 doesn't /sys/block/loop3/stat :: 0 0 0 0 0 0 0 0 0 0 0 Which tells me that something during the boot process most likely acquired (on purpose or not) the next unused loop and possibly didn't released it well enough. If loop2 is generating errors, and I install a snap, the snap squashfs will take loop2, making loop3 the next unused loop device. If I query loop3 with 'parted' right after, no errors. If I reboot, and query loop3 again, then no I'll have an error. To triggers the errors it need to be after a reboot and it only impact the first unused loop device available (losetup -f). This was tested with focal/systemd whic his very close to latest upstream code. This has been test with latest v5.5 mainline kernel as well. For now, I don't think it's a kernel problem, I'm more thinking of a userspace misbehaviour dealing with loop device (or block device) at boot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1856871/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] Re: systemd-coredump user is created by something other than its derived systemd packages
d/rules: 91 CONFFLAGS_deb = \ 92 -Dselinux=true \ 93 -Dhwdb=true \ => 94 -Dsysusers=true \ Would it make sense to turn this off ? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1915936 Title: systemd-coredump user is created by something other than its derived systemd packages Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Status in systemd source package in Focal: New Status in systemd source package in Groovy: New Status in systemd source package in Hirsute: New Status in systemd package in Debian: Unknown Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] Re: systemd-coredump user is created by something other than its derived systemd packages
** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1915936 Title: systemd-coredump user is created by something other than its derived systemd packages Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Status in systemd source package in Focal: New Status in systemd source package in Groovy: New Status in systemd source package in Hirsute: New Status in systemd package in Debian: Unknown Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] Re: systemd-coredump user is created by something other than its derived systemd packages
** Bug watch added: Debian Bug tracker #982976 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982976 ** Also affects: systemd (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982976 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1915936 Title: systemd-coredump user is created by something other than its derived systemd packages Status in systemd package in Ubuntu: New Status in systemd package in Debian: Unknown Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] Re: systemd-coredump user is created by something other than its derived systemd packages
Right, but it doesn't seem right to have it set by default to "/". -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1915936 Title: systemd-coredump user is created by something other than its derived systemd packages Status in systemd package in Ubuntu: New Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] Re: systemd-coredump user is created by something other than its derived systemd packages
** Summary changed: - systemd-coredump user is create by something other than its derived systemd packages + systemd-coredump user is created by something other than its derived systemd packages -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1915936 Title: systemd-coredump user is created by something other than its derived systemd packages Status in systemd package in Ubuntu: New Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] Re: systemd-coredump user is create by something other than its derived systemd packages
Home Directory¶ The home directory for a new system user. If omitted, defaults to the root directory. Only applies to lines of type u and should otherwise be left unset (or "-"). It is recommended to omit this, unless software strictly requires a home directory to be set. systemd-sysusers only sets the home directory record in the user database. To actually create the directory, consider adding a corresponding tmpfiles.d(5) fragment. ** Tags added: seg sts -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1915936 Title: systemd-coredump user is create by something other than its derived systemd packages Status in systemd package in Ubuntu: New Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] Re: systemd-coredump user is create by something other than its derived systemd packages
https://www.freedesktop.org/software/systemd/man/sysusers.d.html# u Create a system user and group of the specified name should they not exist yet. The user's primary group will be set to the group bearing the same name unless the ID field specifies it. The account will be created disabled, so that logins are not allowed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1915936 Title: systemd-coredump user is create by something other than its derived systemd packages Status in systemd package in Ubuntu: New Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] Re: systemd-coredump user is create by something other than its derived systemd packages
sudo /bin/systemd-sysusers --cat-config # /usr/lib/sysusers.d/systemd.conf # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. g systemd-journal - - u systemd-network - "systemd Network Management" u systemd-resolve - "systemd Resolver" u systemd-timesync - "systemd Time Synchronization" u systemd-coredump - "systemd Core Dumper" -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1915936 Title: systemd-coredump user is create by something other than its derived systemd packages Status in systemd package in Ubuntu: New Bug description: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915936/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1915936] [NEW] systemd-coredump user is create by something other than its derived systemd packages
Public bug reported: systemd-coredump binary package is instructed as follows: #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers # /var/log/syslog syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to "/run/systemd" directive in the appropriate postint. It is contradictory. * Why systemd-coredump user is created at installation time and/or without 'systemd-coredump' package installed ? * Why this early creation set the home directory to "/" ? ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Description changed: systemd-coredump binary package is instructed as follows: - #debian/systemd-coredump.postinst: + #debian/systemd-coredump.postinst: adduser --quiet --system --group --no-create-home --home /run/systemd \ --gecos "systemd Core Dumper" systemd-coredump But one doesn't need this package to be installed to have the systemd- coredump user created. This was taken from a focal 20.04.2 fresh installation (Right after a vanilla installation): # cat /etc/passwd: ... systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin ... # dpkg -l | grep -i systemd ii dbus-user-session1.12.16-2ubuntu2.1 amd64simple interprocess messaging system (systemd --user integration) ii libnss-systemd:amd64 245.4-4ubuntu3.4 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.4 amd64system and service manager - PAM module ii libsystemd0:amd64245.4-4ubuntu3.4 amd64systemd utility library ii networkd-dispatcher 2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd 234-3build2 amd64Python 3 bindings for systemd ii systemd 245.4-4ubuntu3.4 amd64system and service manager ii systemd-sysv 245.4-4ubuntu3.4 amd64system and service manager - SysV links ii systemd-timesyncd245.4-4ubuntu3.4 amd64minimalistic service to synchronize local time with NTP servers - - # /var/log/installer/installer-journal.txt - Feb 17 15:27:19 ubuntu-server systemd-sysusers[844]: Creating group systemd-coredump with gid 998. - Feb 17 15:27:19 ubuntu-server systemd-sysusers[844]: Creating user systemd-coredump (systemd Core Dumper) with uid 998 and gid 998. + # /var/log/syslog + syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating group systemd-coredump with gid 999. + syslog:Feb 17 15:31:56 test systemd-sysusers[402]: Creating user systemd-coredump (systemd Core Dumper) with uid 999 and gid 999. Additionnally, you may notice the home directory during the user creation at installation sets it to "/" as opposed to
[Touch-packages] [Bug 1907676] Re: segmentation fault when opening fd
This is fixed in active development release (hirsute): python-apt (2.1.7) unstable; urgency=medium * SECURITY UPDATE: various memory and file descriptor leaks (LP: #1899193) - python/arfile.cc, python/generic.h, python/tag.cc, python/tarfile.cc: fix file descriptor and memory leaks - python/apt_instmodule.cc, python/apt_instmodule.h, python/arfile.h: Avoid reference cycle with control,data members in apt_inst.DebFile objects - tests/test_cve_2020_27351.py: Test cases for DebFile (others not easily testable) * Regression fixes for the updates merged too: - arfile.cc: Fix segmentation fault when opening fd, track lifetime correctly (Closes: #977000) - arfile: Regression: Collect file<->deb/ar reference cycles -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1907676 Title: segmentation fault when opening fd Status in python-apt package in Ubuntu: Fix Released Status in python-apt source package in Xenial: New Status in python-apt source package in Bionic: New Status in python-apt source package in Focal: New Status in python-apt source package in Groovy: New Status in python-apt package in Debian: Unknown Bug description: [Impact] USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. [Test case] # Landscape scenario: 1) On the Landscape server, create a package profile that installs a single package, 'hello' is enough. 2) On the Landscape server, apply the package profile to a client 3) On the Landscape client, verify that there is no segfault message on '/var/log/kern.log' 4) On the Landscape server, verify that the activity to apply the package profile ends with success. Step 3) would show a segfault and step 4), the activity would stay 'In Progress' forever. # dak scenario: dak crashes with a segmentation fault in python3-apt when processing uploads or processing the NEW queue on ftp-master; and also on my playground server (used to generate the backtrace). [Where problems could occurs] [Other info] See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 Fix: https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1907676/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907676] Re: segmentation fault when opening fd
@julian, thanks for the quick reply. Will do. ** Changed in: python-apt (Ubuntu) Status: New => Fix Released ** Description changed: [Impact] USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. [Test case] # Landscape scenario: 1) On the Landscape server, create a package profile that installs a single package, 'hello' is enough. 2) On the Landscape server, apply the package profile to a client 3) On the Landscape client, verify that there is no segfault message on '/var/log/kern.log' 4) On the Landscape server, verify that the activity to apply the package profile ends with success. Step 3) would show a segfault and step 4), the activity would stay 'In Progress' forever. - [Where problem could occurs] + # dak scenario: + dak crashes with a segmentation fault in python3-apt when processing + uploads or processing the NEW queue on ftp-master; and also on my + playground server (used to generate the backtrace). + + [Where problems could occurs] [Other info] See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 Fix: https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1907676 Title: segmentation fault when opening fd Status in python-apt package in Ubuntu: Fix Released Status in python-apt source package in Xenial: New Status in python-apt source package in Bionic: New Status in python-apt source package in Focal: New Status in python-apt source package in Groovy: New Status in python-apt package in Debian: Unknown Bug description: [Impact] USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. [Test case] # Landscape scenario: 1) On the Landscape server, create a package profile that installs a single package, 'hello' is enough. 2) On the Landscape server, apply the package profile to a client 3) On the Landscape client, verify that there is no segfault message on '/var/log/kern.log' 4) On the Landscape server, verify that the activity to apply the package profile ends with success. Step 3) would show a segfault and step 4), the activity would stay 'In Progress' forever. # dak scenario: dak crashes with a segmentation fault in python3-apt when processing uploads or processing the NEW queue on ftp-master; and also on my playground server (used to generate the backtrace). [Where problems could occurs] [Other info] See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 Fix: https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1907676/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907676] Re: segmentation fault when opening fd
This package is 'native' and I don't want for instance to introduce 'quilt' before talking to the maintainer. @julian, how do you want to proceed to fix this bug in python-apt ? - Eric ** Description changed: [Impact] USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. [Test case] - # Landscape scenario: + # Landscape scenario: 1) On the Landscape server, create a package profile that installs a single package, 'hello' is enough. 2) On the Landscape server, apply the package profile to a client 3) On the Landscape client, verify that there is no segfault message on '/var/log/kern.log' 4) On the Landscape server, verify that the activity to apply the package profile ends with success. Step 3) would show a segfault and step 4), the activity would stay 'In Progress' forever. [Where problem could occurs] [Other info] See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 Fix: https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1907676 Title: segmentation fault when opening fd Status in python-apt package in Ubuntu: Fix Released Status in python-apt source package in Xenial: New Status in python-apt source package in Bionic: New Status in python-apt source package in Focal: New Status in python-apt source package in Groovy: New Status in python-apt package in Debian: Unknown Bug description: [Impact] USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. [Test case] # Landscape scenario: 1) On the Landscape server, create a package profile that installs a single package, 'hello' is enough. 2) On the Landscape server, apply the package profile to a client 3) On the Landscape client, verify that there is no segfault message on '/var/log/kern.log' 4) On the Landscape server, verify that the activity to apply the package profile ends with success. Step 3) would show a segfault and step 4), the activity would stay 'In Progress' forever. # dak scenario: dak crashes with a segmentation fault in python3-apt when processing uploads or processing the NEW queue on ftp-master; and also on my playground server (used to generate the backtrace). [Where problems could occurs] [Other info] See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 Fix: https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1907676/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907676] Re: segmentation fault when opening fd
** Description changed: + [Impact] + USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. + [Test case] + + # Landscape scenario: + 1) On the Landscape server, create a package profile that installs a single package, 'hello' is enough. + 2) On the Landscape server, apply the package profile to a client + 3) On the Landscape client, verify that there is no segfault message on '/var/log/kern.log' + 4) On the Landscape server, verify that the activity to apply the package profile ends with success. + + Step 3) would show a segfault and step 4), the activity would stay 'In + Progress' forever. + + [Where problem could occurs] + + [Other info] + See Debian bug: + https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 + Fix: + https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1907676 Title: segmentation fault when opening fd Status in python-apt package in Ubuntu: New Status in python-apt source package in Xenial: New Status in python-apt source package in Bionic: New Status in python-apt source package in Focal: New Status in python-apt source package in Groovy: New Status in python-apt package in Debian: Unknown Bug description: [Impact] USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. [Test case] # Landscape scenario: 1) On the Landscape server, create a package profile that installs a single package, 'hello' is enough. 2) On the Landscape server, apply the package profile to a client 3) On the Landscape client, verify that there is no segfault message on '/var/log/kern.log' 4) On the Landscape server, verify that the activity to apply the package profile ends with success. Step 3) would show a segfault and step 4), the activity would stay 'In Progress' forever. [Where problem could occurs] [Other info] See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 Fix: https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1907676/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1907676] Re: segmentation fault when opening fd
The current situation of python-apt is somewhat critical as no packages can be pushed via Landscape to machines at the moment. This is causing landscape-package-changer to segfault as follows: [apport-retrace] Core was generated by `/usr/bin/python3 /usr/bin/landscape-package-changer --quiet'. Program terminated with signal SIGSEGV, Segmentation fault. #0 ararchive_new (type=0x7f652626e0a0 , args=, kwds=) at python/arfile.cc:438 This seems to be a fix candidate: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 - Eric ** Tags added: seg sts ** Also affects: python-apt (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: python-apt (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: python-apt (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: python-apt (Ubuntu Groovy) Importance: Undecided Status: New ** Changed in: python-apt (Ubuntu Groovy) Importance: Undecided => High ** Changed in: python-apt (Ubuntu Focal) Importance: Undecided => High ** Changed in: python-apt (Ubuntu Xenial) Importance: Undecided => High ** Changed in: python-apt (Ubuntu) Importance: Undecided => High ** Changed in: python-apt (Ubuntu Bionic) Importance: Undecided => Critical ** Changed in: python-apt (Ubuntu Bionic) Importance: Critical => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-apt in Ubuntu. https://bugs.launchpad.net/bugs/1907676 Title: segmentation fault when opening fd Status in python-apt package in Ubuntu: New Status in python-apt source package in Xenial: New Status in python-apt source package in Bionic: New Status in python-apt source package in Focal: New Status in python-apt source package in Groovy: New Status in python-apt package in Debian: Unknown Bug description: USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1907676/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
All regression failures, PASSED after a retry. There is no autopkgtest regression (failures) anymore. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS- SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake, which these patches to cyrus-sasl2 should now parse correctly. [Other Info] The below two commits are needed. The first fixes the problem, the second fixes some unused parameter warnings. commit 816e529043de08f3f9dcc4097380de39478b0b16 Author: Simo Sorce Date: Thu Feb
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
I have retried all the FAILED tests. * postfix/3.3.0-1ubuntu0.3 (amd64) PASSED the 2nd time: http://autopkgtest.ubuntu.com/packages/p/postfix/bionic/amd64 * kimap/17.12.3-0ubuntu1 (armhf, ppc64el, arm64) are queued and waiting to retry. Stay tune ... - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: Fix Committed Status in cyrus-sasl2 source package in Bionic: Fix Committed Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package from -proposed https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS- SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake, which these patches to cyrus-sasl2 should now parse correctly. [Other Info] The below two commits are needed. The first
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
[sts-sponsors] cyrus-sasl2 has been sponsored in Bionic. I have already pinged sil2100 for its SRU verification. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS-SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake, which these patches to cyrus-sasl2 should now parse correctly. [Other Info] The below two commits are needed. The first fixes the problem, the second fixes some unused parameter
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
[sts-sponsors] adcli option #1 has been sponsored in Bionic with the following nitpicking: * Changed version from "0.8.2-1ubuntu2.1" to "0.8.2-1ubuntu1.1" * Changed debian/control to d/control. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes cyrus-sasl2 work with Microsoft implementations of GSS-SPNEGO, which will be the more common usecase, it may change the behaviour when connecting to a MIT krb5 server with the GSS-SPNEGO protocol, as krb5 assumes use of confidentiality and integrity modes. This shouldn't be a problem as the krb5 implementation signals its intentions by setting the correct flags during handshake, which these patches to cyrus-sasl2 should now parse correctly. [Other Info] The below two commits are
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
Matthew, I was thinking about possibly to declare some package relationships to not allow the offending packages' combination to occur, when I came across the exact same thought from cpaelzer. I don't know if you notice it, here it goes[0]: " One suggestion for the coming related uploads. Do you think it would make sense to ensure that the now-known-bad combinations of packages won't be allowed together. Maybe when you go for adcli and sssd in LP #1868703 again - they might have their dependency to libsasl2-modules-gssapi-mit be versioned to be greater or equal the fixed cyrus_sasl2? " Matthew do you have a plan to ensure the users will have the right combinations/package relationships ? - Eric [0]- https://lists.ubuntu.com/archives/ubuntu-server/2020-December/008613.html -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends:
[Touch-packages] [Bug 1906627] Re: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression
Matthew, I was thinking about possibly to declare some package relationships to not allow the offending packages' combination to occur, when I came across the exact same thought from cpaelzer. I don't know if you notice it, here it goes: " One suggestion for the coming related uploads. Do you think it would make sense to ensure that the now-known-bad combinations of packages won't be allowed together. Maybe when you go for adcli and sssd in LP #1868703 again - they might have their dependency to libsasl2-modules-gssapi-mit be versioned to be greater or equal the fixed cyrus_sasl2? " Matthew do you have a plan to ensure user will have the right combinations/package relationships ? - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/1906627 Title: GSS-SPNEGO implementation in cyrus-sasl2 is incompatible with Active Directory, causing recent adcli regression Status in adcli package in Ubuntu: Fix Released Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in adcli source package in Bionic: In Progress Status in cyrus-sasl2 source package in Bionic: In Progress Bug description: [Impact] A recent release of adcli 0.8.2-1ubuntu1 to bionic-updates caused a regression for some users when attempting to join a Active Directory realm. adcli introduced a default behaviour change, moving from GSS- API to GSS-SPNEGO as the default channel encryption algorithm. adcli uses the GSS-SPNEGO implementation from libsasl2-modules-gssapi- mit, a part of cyrus-sasl2. The implementation seems to have some compatibility issues with particular configurations of Active Directory on recent Windows Server systems. Particularly, adcli sends a ldap query to the domain controller, which responds with a tcp ack, but never returns a ldap response. The connection just hangs at this point and no more traffic is sent. You can see it on the packet trace below: https://paste.ubuntu.com/p/WRnnRMGBPm/ On Focal, where the implementation of GSS-SPNEGO is working, we see a full exchange, and adcli works as expected: https://paste.ubuntu.com/p/8668pJrr2m/ The fix is to not assume use of confidentiality and integrity modes, and instead use the flags negotiated by GSS-API during the initial handshake, as required by Microsoft's implementation. [Testcase] You will need to set up a Windows Server 2019 system, install and configure Active Directory and enable LDAP extensions and configure LDAPS and import the AD SSL certificate to the Ubuntu client. Create some users in Active Directory. On the Ubuntu client, set up /etc/hosts with the hostname of the Windows Server machine, if your system isn't configured for AD DNS. From there, install adcli 0.8.2-1 from -release. $ sudo apt install adcli Set up a packet trace with tcpdump: $ sudo tcpdump -i any port '(389 or 3268 or 636 or 3269)' Next, join the AD realm using the normal GSS-API: # adcli join --verbose -U Administrator --domain WIN- SB6JAS7PH22.testing.local --domain-controller WIN- SB6JAS7PH22.testing.local --domain-realm TESTING.LOCAL You will be prompted for Administrator's passowrd. The output should look like the below: https://paste.ubuntu.com/p/NWHGQn746D/ Next, enable -proposed, and install adcli 0.8.2-1ubuntu1 which caused the regression. Repeat the above steps. Now you should see the connection hang. https://paste.ubuntu.com/p/WRnnRMGBPm/ Finally, install the fixed cyrus-sasl2 package, which is available from the below ppa: https://launchpad.net/~mruffell/+archive/ubuntu/lp1906627-test $ sudo add-apt-repository ppa:mruffell/lp1906627-test $ sudo apt-get update $ sudo apt install libsasl2-2 libsasl2-modules libsasl2-modules-db libsasl2-modules-gssapi-mit Repeat the steps. GSS-SPNEGO should be working as intended, and you should get output like below: https://paste.ubuntu.com/p/W5cJNGvCsx/ [Where problems could occur] Since we are changing the implementation of GSS-SPNEGO, and cyrus- sasl2 is the library which provides it, we can potentially break any package which depends on libsasl2-modules-gssapi-mit for GSS-SPNEGO. $ apt rdepends libsasl2-modules-gssapi-mit libsasl2-modules-gssapi-mit Reverse Depends: |Suggests: ldap-utils Depends: adcli Conflicts: libsasl2-modules-gssapi-heimdal |Suggests: libsasl2-modules Conflicts: libsasl2-modules-gssapi-heimdal |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules |Suggests: ldap-utils |Depends: msktutil Conflicts: libsasl2-modules-gssapi-heimdal |Depends: libapache2-mod-webauthldap Depends: freeipa-server Depends: freeipa-client Depends: adcli Depends: 389-ds-base |Recommends: sssd-krb5-common |Suggests: slapd |Suggests: libsasl2-modules While this SRU makes
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
** Changed in: systemd (Ubuntu Bionic)
Assignee: Eric Desrochers (slashd) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Confirmed
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
vrrp_sync_group collection {
[Touch-packages] [Bug 1865226] Re: gdm-smartcard pam config needs to be updated for Ubuntu and installed
(I have ping sil2100 internally for him to provide his 2 cents on this bug.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1865226 Title: gdm-smartcard pam config needs to be updated for Ubuntu and installed Status in gdm: New Status in GNOME Settings Daemon: Unknown Status in gdm3 package in Ubuntu: Confirmed Status in gnome-settings-daemon package in Ubuntu: In Progress Status in pam package in Ubuntu: Invalid Status in gdm3 source package in Bionic: Won't Fix Status in pam source package in Bionic: Invalid Status in gdm3 source package in Focal: Confirmed Status in gnome-settings-daemon source package in Focal: New Status in pam source package in Focal: Invalid Status in gdm3 source package in Groovy: Confirmed Status in gnome-settings-daemon source package in Groovy: New Status in pam source package in Groovy: Invalid Bug description: the pam profile for gdm-smartcard is missing. gdm refuses to login with a smartcard. Looking at ubuntu/+source/gdm3, other pam files are pregenerated into debian/ and installed from there; gdm-smartcard is left out. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.4 ProcVersionSignature: Ubuntu 5.3.0-24.26~18.04.2-generic 5.3.10 Uname: Linux 5.3.0-24-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 28 14:30:30 2020 InstallationDate: Installed on 2016-05-23 (1376 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.gdm3.Xsession: 2018-04-27T11:41:04.766901 To manage notifications about this bug go to: https://bugs.launchpad.net/gdm/+bug/1865226/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1865226] Re: gdm-smartcard pam config needs to be updated for Ubuntu and installed
Lukasz (sil2100) can we have your SRU team input on this bug with regard to Bionic/18.04lTS ? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1865226 Title: gdm-smartcard pam config needs to be updated for Ubuntu and installed Status in gdm: New Status in GNOME Settings Daemon: Unknown Status in gdm3 package in Ubuntu: Confirmed Status in gnome-settings-daemon package in Ubuntu: In Progress Status in pam package in Ubuntu: Invalid Status in gdm3 source package in Bionic: Won't Fix Status in pam source package in Bionic: Invalid Status in gdm3 source package in Focal: Confirmed Status in gnome-settings-daemon source package in Focal: New Status in pam source package in Focal: Invalid Status in gdm3 source package in Groovy: Confirmed Status in gnome-settings-daemon source package in Groovy: New Status in pam source package in Groovy: Invalid Bug description: the pam profile for gdm-smartcard is missing. gdm refuses to login with a smartcard. Looking at ubuntu/+source/gdm3, other pam files are pregenerated into debian/ and installed from there; gdm-smartcard is left out. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.4 ProcVersionSignature: Ubuntu 5.3.0-24.26~18.04.2-generic 5.3.10 Uname: Linux 5.3.0-24-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 28 14:30:30 2020 InstallationDate: Installed on 2016-05-23 (1376 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.gdm3.Xsession: 2018-04-27T11:41:04.766901 To manage notifications about this bug go to: https://bugs.launchpad.net/gdm/+bug/1865226/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1865226] Re: gdm-smartcard pam config needs to be updated for Ubuntu and installed
I unfortunately don't have a smartcard device handy to test/debug/ but if I compare with RHEL which is known to be working... Redhat has the following configuration "gdm-smarcard" which includes "smartcard-auth", a symlink pointing to "smartcard-auth-local" I think we should 'mimic' this (at least as a starting point) without the selinux and other RHEL specific bits. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1865226 Title: gdm-smartcard pam config needs to be updated for Ubuntu and installed Status in gdm: New Status in gdm3 package in Ubuntu: Confirmed Status in pam package in Ubuntu: Invalid Status in gdm3 source package in Bionic: New Status in pam source package in Bionic: Invalid Status in gdm3 source package in Focal: Confirmed Status in pam source package in Focal: Invalid Status in gdm3 source package in Groovy: Confirmed Status in pam source package in Groovy: Invalid Bug description: the pam profile for gdm-smartcard is missing. gdm refuses to login with a smartcard. Looking at ubuntu/+source/gdm3, other pam files are pregenerated into debian/ and installed from there; gdm-smartcard is left out. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.4 ProcVersionSignature: Ubuntu 5.3.0-24.26~18.04.2-generic 5.3.10 Uname: Linux 5.3.0-24-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 28 14:30:30 2020 InstallationDate: Installed on 2016-05-23 (1376 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.gdm3.Xsession: 2018-04-27T11:41:04.766901 To manage notifications about this bug go to: https://bugs.launchpad.net/gdm/+bug/1865226/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1865226] Re: gdm-smartcard pam config needs to be updated for Ubuntu and installed
# git clone https://gitlab.gnome.org/GNOME/gdm.git # find . -name "gdm-smartcard*" ./data/pam-arch/gdm-smartcard.pam ./data/pam-redhat/gdm-smartcard.pam ./data/pam-exherbo/gdm-smartcard.pam ./data/pam-lfs/gdm-smartcard.pam It seems like Ubuntu/Debian will have to start by having a 'compatible' PAM stack config. So far looking upstream, it seems to only be defined for 4 specific distros: - Archlinux - Redhat - Exherbo - Linux From Scratch (LFS) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1865226 Title: gdm-smartcard pam config needs to be updated for Ubuntu and installed Status in gdm: New Status in gdm3 package in Ubuntu: Confirmed Status in pam package in Ubuntu: Invalid Status in gdm3 source package in Bionic: New Status in pam source package in Bionic: Invalid Status in gdm3 source package in Focal: Confirmed Status in pam source package in Focal: Invalid Status in gdm3 source package in Groovy: Confirmed Status in pam source package in Groovy: Invalid Bug description: the pam profile for gdm-smartcard is missing. gdm refuses to login with a smartcard. Looking at ubuntu/+source/gdm3, other pam files are pregenerated into debian/ and installed from there; gdm-smartcard is left out. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.4 ProcVersionSignature: Ubuntu 5.3.0-24.26~18.04.2-generic 5.3.10 Uname: Linux 5.3.0-24-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 28 14:30:30 2020 InstallationDate: Installed on 2016-05-23 (1376 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.gdm3.Xsession: 2018-04-27T11:41:04.766901 To manage notifications about this bug go to: https://bugs.launchpad.net/gdm/+bug/1865226/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1865226] Re: gdm-smartcard pam config needs to be updated for Ubuntu and installed
** Changed in: gdm3 (Ubuntu Groovy) Importance: Medium => High ** Also affects: pam (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: gdm3 (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: pam (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: gdm3 (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: gdm3 (Ubuntu Focal) Status: New => Confirmed ** Changed in: gdm3 (Ubuntu Focal) Importance: Undecided => High ** Changed in: gdm3 (Ubuntu Bionic) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1865226 Title: gdm-smartcard pam config needs to be updated for Ubuntu and installed Status in gdm: New Status in gdm3 package in Ubuntu: Confirmed Status in pam package in Ubuntu: Invalid Status in gdm3 source package in Bionic: New Status in pam source package in Bionic: New Status in gdm3 source package in Focal: Confirmed Status in pam source package in Focal: New Status in gdm3 source package in Groovy: Confirmed Status in pam source package in Groovy: Invalid Bug description: the pam profile for gdm-smartcard is missing. gdm refuses to login with a smartcard. Looking at ubuntu/+source/gdm3, other pam files are pregenerated into debian/ and installed from there; gdm-smartcard is left out. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.4 ProcVersionSignature: Ubuntu 5.3.0-24.26~18.04.2-generic 5.3.10 Uname: Linux 5.3.0-24-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 28 14:30:30 2020 InstallationDate: Installed on 2016-05-23 (1376 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.gdm3.Xsession: 2018-04-27T11:41:04.766901 To manage notifications about this bug go to: https://bugs.launchpad.net/gdm/+bug/1865226/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
I have a first iteration of a package:
It's not a final solution nor a long term solution. It is only made to
determine if its fix the problem before considering an SRU: (Ideally one
would test this package in non-production area)
Adding this PPA to your system
sudo add-apt-repository ppa:slashd/sf263217
sudo apt-get update
Please report back any feedbacks in this bug.
- Eric
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Confirmed
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived, heartbeat, corosync, pacemaker (interface aliases are restarted)
The above test package has been made for 'systemd' in bionic ^
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived, heartbeat,
corosync, pacemaker (interface aliases are restarted)
Status in netplan:
Confirmed
Status in heartbeat package in Ubuntu:
Won't Fix
Status in keepalived package in Ubuntu:
In Progress
Status in systemd package in Ubuntu:
In Progress
Status in keepalived source package in Xenial:
Confirmed
Status in systemd source package in Xenial:
Confirmed
Status in keepalived source package in Bionic:
Confirmed
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Disco:
Won't Fix
Status in systemd source package in Eoan:
Fix Released
Status in keepalived source package in Focal:
Confirmed
Status in systemd source package in Focal:
Fix Released
Bug description:
[impact]
- ALL related HA software has a small problem if interfaces are being
managed by systemd-networkd: nic restarts/reconfigs are always going
to wipe all interfaces aliases when HA software is not expecting it to
(no coordination between them.
- keepalived, smb ctdb, pacemaker, all suffer from this. Pacemaker is
smarter in this case because it has a service monitor that will
restart the virtual IP resource, in affected node & nic, before
considering a real failure, but other HA service might consider a real
failure when it is not.
[test case]
- comment #14 is a full test case: to have 3 node pacemaker, in that
example, and cause a networkd service restart: it will trigger a
failure for the virtual IP resource monitor.
- other example is given in the original description for keepalived.
both suffer from the same issue (and other HA softwares as well).
[regression potential]
- this backports KeepConfiguration parameter, which adds some
significant complexity to networkd's configuration and behavior, which
could lead to regressions in correctly configuring the network at
networkd start, or incorrectly maintaining configuration at networkd
restart, or losing network state at networkd stop.
- Any regressions are most likely to occur during networkd start,
restart, or stop, and most likely to involve missing or incorrect ip
address(es).
- the change is based in upstream patches adding the exact feature we
needed to fix this issue & it will be integrated with a netplan change
to add the needed stanza to systemd nic configuration file
(KeepConfiguration=)
[other info]
original description:
---
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
vrrp_sync_group collection {
group {
wan
[Touch-packages] [Bug 1895757] Re: Terminal hangs running sudo when "use_pty" is set in /etc/sudoers
[sts-sponsors]
I have sponsored it in bionic.
Thanks for your contribution Heitor
- Eric
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1895757
Title:
Terminal hangs running sudo when "use_pty" is set in /etc/sudoers
Status in sudo package in Ubuntu:
Fix Released
Status in sudo source package in Bionic:
In Progress
Bug description:
[Impact]
sudo commands can hang when IO logging is enabled
[Description]
When doing cleanup in pty_close(), sudo can leave file descriptors and events
behind that would later cause poll() to wait on a "dead" pty. This can cause
sudo to hang when IO logging is enabled, due to the poll() timeouts.
The issue has been fixed upstream by the commit below:
- In pty_close() close the slave and remove any events associated
(4df454310dae)
$ git describe --contains 4df454310dae96d01d09a05be89dc8c57fd4cef7
SUDO_1_8_23
$ rmadison sudo
sudo | 1.8.16-0ubuntu1 | xenial | source, ...
sudo | 1.8.16-0ubuntu1.9 | xenial-security | source, ...
sudo | 1.8.16-0ubuntu1.9 | xenial-updates | source, ...
sudo | 1.8.21p2-3ubuntu1 | bionic | source, ...
sudo | 1.8.21p2-3ubuntu1.2 | bionic-security | source, ...
=> sudo | 1.8.21p2-3ubuntu1.2 | bionic-updates | source, ... <
sudo | 1.8.31-1ubuntu1 | focal| source, ...
sudo | 1.8.31-1ubuntu1.1 | focal-updates| source, ...
sudo | 1.9.1-1ubuntu1 | groovy | source, ...
Xenial doesn't exhibit this behaviour, so fixes are only needed for Bionic
(Focal onwards already have the fix by default due to sudo version).
[Test Case]
1. Ensure /etc/sudoers contains 'Defaults use_pty'
2. Execute the following test command:
$ for i in {1..10}; do sudo -- cat /var/log/syslog; done
The terminal will hang during syslog output.
[Regression Potential]
The fix introduces additional cleaning when closing/flushing pty devices, so
the
regression potential should be low. It has been present upstream since
sudo-1.8.23, so it has seen thorough testing in most Linux distributions
including Ubuntu.
A regression could possibly cause issues when switching back out from sudo
sessions, as the changes only touch the pty_close path, but seems unlikely
considering the patch has been present in other Ubuntu releases as well.
--
An SSH terminal into an Ubuntu server (tested on 18.04.5) hangs running a
command using 'sudo' when 'use_pty' is set in /etc/sudoers.
Steps to reproduce ('sudo' version --> 1.8.21p2-3ubuntu1.2):
1) Log in into an Ubuntu server (tested on 18.04.5 using SSH)
2) Ensure that /etc/sudoers has the following line (add this line if not
present)
Defaults use_pty
3) Execute the following (test 'sudo' command):
for i in {1..10}; do sudo -- cat /var/log/syslog; done
The terminal hangs and the following backtrace is obtained:
(gdb) bt
#0 0x7f751d5c8cc4 in __GI___poll (fds=0x55d0159917b0, nfds=1,
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x7f751d8b146a in poll (__timeout=, __nfds=, __fds=) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2 sudo_ev_scan_impl (base=base@entry=0x55d015990dc0, flags=flags@entry=0)
at ../../../lib/util/event_poll.c:155
#3 0x7f751d8aa74d in sudo_ev_loop_v1 (base=base@entry=0x55d015990dc0,
flags=flags@entry=0) at ../../../lib/util/event.c:617
#4 0x55d01570597a in del_io_events (nonblocking=nonblocking@entry=false)
at ../../src/exec_pty.c:1537
#5 0x55d015707b97 in pty_close (cstat=0x7ffd074d6110) at
../../src/exec_pty.c:697
#6 exec_pty (details=details@entry=0x55d01591e0e0 ,
cstat=cstat@entry=0x7ffd074d6110) at ../../src/exec_pty.c:1412
#7 0x55d015701178 in sudo_execute (details=0x55d01591e0e0
, cstat=0x7ffd074d6110) at ../../src/exec.c:391
#8 0x55d01570e15b in run_command (details=0x55d01591e0e0
) at ../../src/sudo.c:968
#9 0x55d0156ff9a0 in main (argc=, argv=,
envp=) at ../../src/sudo.c:294
A similar (most likely the same) bug has been reported here
https://access.redhat.com/solutions/3404401.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1895757/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1895757] Re: Terminal hangs running sudo when "use_pty" is set in /etc/sudoers
** Description changed:
[Impact]
sudo commands can hang when IO logging is enabled
[Description]
When doing cleanup in pty_close(), sudo can leave file descriptors and events
behind that would later cause poll() to wait on a "dead" pty. This can cause
sudo to hang when IO logging is enabled, due to the poll() timeouts.
The issue has been fixed upstream by the commit below:
- In pty_close() close the slave and remove any events associated
(4df454310dae)
+ $ git describe --contains 4df454310dae96d01d09a05be89dc8c57fd4cef7
+ SUDO_1_8_23^2~60
+
+
$ rmadison sudo
- sudo | 1.8.16-0ubuntu1 | xenial | source, ...
- sudo | 1.8.16-0ubuntu1.9 | xenial-security | source, ...
- sudo | 1.8.16-0ubuntu1.9 | xenial-updates | source, ...
- sudo | 1.8.21p2-3ubuntu1 | bionic | source, ...
- sudo | 1.8.21p2-3ubuntu1.2 | bionic-security | source, ...
- sudo | 1.8.21p2-3ubuntu1.2 | bionic-updates | source, ... <
- sudo | 1.8.31-1ubuntu1 | focal| source, ...
- sudo | 1.8.31-1ubuntu1.1 | focal-updates| source, ...
- sudo | 1.9.1-1ubuntu1 | groovy | source, ...
+ sudo | 1.8.16-0ubuntu1 | xenial | source, ...
+ sudo | 1.8.16-0ubuntu1.9 | xenial-security | source, ...
+ sudo | 1.8.16-0ubuntu1.9 | xenial-updates | source, ...
+ sudo | 1.8.21p2-3ubuntu1 | bionic | source, ...
+ sudo | 1.8.21p2-3ubuntu1.2 | bionic-security | source, ...
+ sudo | 1.8.21p2-3ubuntu1.2 | bionic-updates | source, ... <
+ sudo | 1.8.31-1ubuntu1 | focal| source, ...
+ sudo | 1.8.31-1ubuntu1.1 | focal-updates| source, ...
+ sudo | 1.9.1-1ubuntu1 | groovy | source, ...
Xenial doesn't exhibit this behaviour, so fixes are only needed for Bionic
(Focal onwards already have the fix by default due to sudo version).
[Test Case]
1. Ensure /etc/sudoers contains 'Defaults use_pty'
2. Execute the following test command:
$ for i in {1..10}; do sudo -- cat /var/log/syslog; done
The terminal will hang during syslog output.
[Regression Potential]
The fix introduces additional cleaning when closing/flushing pty devices, so
the
regression potential should be low. It has been present upstream since
sudo-1.8.23, so it has seen thorough testing in most Linux distributions
including Ubuntu.
A regression could possibly cause issues when switching back out from sudo
sessions, as the changes only touch the pty_close path, but seems unlikely
considering the patch has been present in other Ubuntu releases as well.
--
An SSH terminal into an Ubuntu server (tested on 18.04.5) hangs running a
command using 'sudo' when 'use_pty' is set in /etc/sudoers.
Steps to reproduce ('sudo' version --> 1.8.21p2-3ubuntu1.2):
1) Log in into an Ubuntu server (tested on 18.04.5 using SSH)
2) Ensure that /etc/sudoers has the following line (add this line if not
present)
Defaults use_pty
3) Execute the following (test 'sudo' command):
for i in {1..10}; do sudo -- cat /var/log/syslog; done
The terminal hangs and the following backtrace is obtained:
(gdb) bt
#0 0x7f751d5c8cc4 in __GI___poll (fds=0x55d0159917b0, nfds=1,
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x7f751d8b146a in poll (__timeout=, __nfds=, __fds=) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2 sudo_ev_scan_impl (base=base@entry=0x55d015990dc0, flags=flags@entry=0)
at ../../../lib/util/event_poll.c:155
#3 0x7f751d8aa74d in sudo_ev_loop_v1 (base=base@entry=0x55d015990dc0,
flags=flags@entry=0) at ../../../lib/util/event.c:617
#4 0x55d01570597a in del_io_events (nonblocking=nonblocking@entry=false)
at ../../src/exec_pty.c:1537
#5 0x55d015707b97 in pty_close (cstat=0x7ffd074d6110) at
../../src/exec_pty.c:697
#6 exec_pty (details=details@entry=0x55d01591e0e0 ,
cstat=cstat@entry=0x7ffd074d6110) at ../../src/exec_pty.c:1412
#7 0x55d015701178 in sudo_execute (details=0x55d01591e0e0
, cstat=0x7ffd074d6110) at ../../src/exec.c:391
#8 0x55d01570e15b in run_command (details=0x55d01591e0e0
) at ../../src/sudo.c:968
#9 0x55d0156ff9a0 in main (argc=, argv=,
envp=) at ../../src/sudo.c:294
A similar (most likely the same) bug has been reported here
https://access.redhat.com/solutions/3404401.
** Description changed:
[Impact]
sudo commands can hang when IO logging is enabled
[Description]
When doing cleanup in pty_close(), sudo can leave file descriptors and events
behind that would later cause poll() to wait on a "dead" pty. This can cause
sudo to hang when IO logging is enabled, due to the poll() timeouts.
The issue has been fixed upstream by the commit below:
- In pty_close() close the slave and remove any events associated
(4df454310dae)
$ git describe --contains 4df454310dae96d01d09a05be89dc8c57fd4cef7
- SUDO_1_8_23^2~60
-
+ SUDO_1_8_23
$
[Touch-packages] [Bug 1865226] Re: gdm-smartcard pam config needs to be updated for Ubuntu and installed
** Changed in: gdm3 (Ubuntu Groovy) Importance: Low => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1865226 Title: gdm-smartcard pam config needs to be updated for Ubuntu and installed Status in gdm: New Status in gdm3 package in Ubuntu: Confirmed Status in pam package in Ubuntu: Invalid Status in gdm3 source package in Groovy: Confirmed Status in pam source package in Groovy: Invalid Bug description: the pam profile for gdm-smartcard is missing. gdm refuses to login with a smartcard. Looking at ubuntu/+source/gdm3, other pam files are pregenerated into debian/ and installed from there; gdm-smartcard is left out. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.4 ProcVersionSignature: Ubuntu 5.3.0-24.26~18.04.2-generic 5.3.10 Uname: Linux 5.3.0-24-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 28 14:30:30 2020 InstallationDate: Installed on 2016-05-23 (1376 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.gdm3.Xsession: 2018-04-27T11:41:04.766901 To manage notifications about this bug go to: https://bugs.launchpad.net/gdm/+bug/1865226/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1865226] Re: gdm-smartcard pam config needs to be updated for Ubuntu and installed
It has been brought to my attention by a UA customer that they are suffering from which seems a similar situation: " Our only currently working SmartCard access from Linux, over SSSD, to AD, is on RHEL7. I was able to get SSH access on Ubuntu 20.04LTS, after adding "ad_gpo_access_control = permissive" in sssd.conf. Logging in locally fails (prompting for password, rather than PIN). It is also still prompting for the Password twice on all local login attempts. RHEL7 -> Ubuntu 20.04LTS (SSH) - Success Ubuntu 20.04LTS -> RHEL7 (SSH) - Success Ubuntu Desktop login (GDM or CLI) - Fail Ubuntu Desktop login via local username/pw - Success, but with 2 pw prompts. " -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pam in Ubuntu. https://bugs.launchpad.net/bugs/1865226 Title: gdm-smartcard pam config needs to be updated for Ubuntu and installed Status in gdm: New Status in gdm3 package in Ubuntu: Confirmed Status in pam package in Ubuntu: Invalid Status in gdm3 source package in Groovy: Confirmed Status in pam source package in Groovy: Invalid Bug description: the pam profile for gdm-smartcard is missing. gdm refuses to login with a smartcard. Looking at ubuntu/+source/gdm3, other pam files are pregenerated into debian/ and installed from there; gdm-smartcard is left out. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gdm3 3.28.3-0ubuntu18.04.4 ProcVersionSignature: Ubuntu 5.3.0-24.26~18.04.2-generic 5.3.10 Uname: Linux 5.3.0-24-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.11 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Feb 28 14:30:30 2020 InstallationDate: Installed on 2016-05-23 (1376 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1) SourcePackage: gdm3 UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.gdm3.Xsession: 2018-04-27T11:41:04.766901 To manage notifications about this bug go to: https://bugs.launchpad.net/gdm/+bug/1865226/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
I'll retry the test before we investigate further. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: In Progress Status in initramfs-tools source package in Focal: Fix Released Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: In Progress Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: New Bug description: [Impact] * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu is currently unable to decrypt the rootfs if the array gets degraded, like for example if one of the array's members gets removed. * The problem has 2 main aspects: first, cryptsetup initramfs script attempts to decrypt the array only in the local-top boot stage, and in case it fails, it gives-up and show user a shell (boot is aborted). * Second, mdadm initramfs script that assembles degraded arrays executes later on boot, in the local-block stage. So, in a stacked setup of encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails early in the boot, preventing mdadm to assemble the degraded array. * The hereby proposed solution has 2 components: first, cryptsetup script is modified to allow a gentle failure on local-top stage, then it retries for a while (according to a heuristic based on ROOTDELAY with minimum of 30 executions) in a later stage (local-block). This gives time to other initramfs scripts to run, like mdadm in local- block stage. And this is meant to work this way according to initramfs-tools documentation (although Ubuntu changed it a bit with wait-for-root, hence we stopped looping on local-block, see next bullet). * Second, initramfs-tools was adjusted - currently, it runs for a while the mdadm local-block script, in order to assemble the arrays in a non-degraded mode. We extended this approach to also execute cryptsetup, in a way that after mdadm ends its execution, we execute at least once more time cryptsetup. In an ideal world we should loop on local-block as Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup mentions from initramfs-tools code), but this would be really a big change, non-SRUable probably. I plan to work that for future Ubuntu releases. [Test case] * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to create a RAID1 volume and an encrypted root on top of it. * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table from one of the RAID members. Reboot and it will fail to mount rootfs and continue boot process. * If using the initramfs-toos/cryptsetup patches hereby proposed, the rootfs can be mounted normally. [Regression potential] * There are potential for regressions, since this is a change in 2 boot components. The patches were designed in a way to keep the regular case working, it changes the failure case which is not currently working anyway. * A modification in the behavior of cryptsetup was introduced: right now, if we fail the password 3 times (the default maximum attempts), the script doesn't "panic" and drop to a shell immediately; instead it runs once more (or twice, if mdadm is installed) before failing. This is a minor change given the benefit of the being able to mount rootfs in a degraded RAID1 scenario. * Other potential regressions could show-up as boot problems, but the change in initramfs-tools specifically is not invasive, it just may delay boot time a bit, given we now run cryptsetup multiple times on local-block, with 1 sec delays between executions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
Autopkgtest failure found: autopkgtest for systemd/246.4-1ubuntu1: amd64: Regression ♻ , arm64: Pass, armhf: Pass, ppc64el: Pass, s390x: Ignored failure https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-groovy/groovy/amd64/s/systemd/20200922_224614_79186@/log.gz autopkgtest [22:45:59]: summary timedatedPASS hostnamedPASS localed-locale PASS localed-x11-keymap PASS logind PASS unit-config PASS storage PASS networkd-test.py PASS build-login PASS boot-and-servicesPASS udev PASS root-unittests PASS tests-in-lxd PASS upstream FAIL timed out boot-smoke PASS systemd-fsckdFLAKY non-zero exit status 137 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: In Progress Status in initramfs-tools source package in Focal: Fix Released Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: In Progress Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: New Bug description: [Impact] * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu is currently unable to decrypt the rootfs if the array gets degraded, like for example if one of the array's members gets removed. * The problem has 2 main aspects: first, cryptsetup initramfs script attempts to decrypt the array only in the local-top boot stage, and in case it fails, it gives-up and show user a shell (boot is aborted). * Second, mdadm initramfs script that assembles degraded arrays executes later on boot, in the local-block stage. So, in a stacked setup of encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails early in the boot, preventing mdadm to assemble the degraded array. * The hereby proposed solution has 2 components: first, cryptsetup script is modified to allow a gentle failure on local-top stage, then it retries for a while (according to a heuristic based on ROOTDELAY with minimum of 30 executions) in a later stage (local-block). This gives time to other initramfs scripts to run, like mdadm in local- block stage. And this is meant to work this way according to initramfs-tools documentation (although Ubuntu changed it a bit with wait-for-root, hence we stopped looping on local-block, see next bullet). * Second, initramfs-tools was adjusted - currently, it runs for a while the mdadm local-block script, in order to assemble the arrays in a non-degraded mode. We extended this approach to also execute cryptsetup, in a way that after mdadm ends its execution, we execute at least once more time cryptsetup. In an ideal world we should loop on local-block as Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup mentions from initramfs-tools code), but this would be really a big change, non-SRUable probably. I plan to work that for future Ubuntu releases. [Test case] * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to create a RAID1 volume and an encrypted root on top of it. * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table from one of the RAID members. Reboot and it will fail to mount rootfs and continue boot process. * If using the initramfs-toos/cryptsetup patches hereby proposed, the rootfs can be mounted normally. [Regression potential] * There are potential for regressions, since this is a change in 2 boot components. The patches were designed in a way to keep the regular case working, it changes the failure case which is not currently working anyway. * A modification in the behavior of cryptsetup was introduced: right now, if we fail the password 3 times (the default maximum attempts), the script doesn't "panic" and drop to a shell immediately; instead it runs once more (or twice, if mdadm is installed) before failing. This is a minor change given the benefit of the being able to mount rootfs in a degraded RAID1 scenario. * Other
[Touch-packages] [Bug 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
[sts-sponsors] Sponsored and uploaded into groovy. Let's now wait until the package lands in groovy-releases before proceeding with the SRU. Thanks mfo and gpiccoli for your contributions. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: In Progress Status in initramfs-tools source package in Focal: Fix Released Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: In Progress Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: New Bug description: [Impact] * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu is currently unable to decrypt the rootfs if the array gets degraded, like for example if one of the array's members gets removed. * The problem has 2 main aspects: first, cryptsetup initramfs script attempts to decrypt the array only in the local-top boot stage, and in case it fails, it gives-up and show user a shell (boot is aborted). * Second, mdadm initramfs script that assembles degraded arrays executes later on boot, in the local-block stage. So, in a stacked setup of encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails early in the boot, preventing mdadm to assemble the degraded array. * The hereby proposed solution has 2 components: first, cryptsetup script is modified to allow a gentle failure on local-top stage, then it retries for a while (according to a heuristic based on ROOTDELAY with minimum of 30 executions) in a later stage (local-block). This gives time to other initramfs scripts to run, like mdadm in local- block stage. And this is meant to work this way according to initramfs-tools documentation (although Ubuntu changed it a bit with wait-for-root, hence we stopped looping on local-block, see next bullet). * Second, initramfs-tools was adjusted - currently, it runs for a while the mdadm local-block script, in order to assemble the arrays in a non-degraded mode. We extended this approach to also execute cryptsetup, in a way that after mdadm ends its execution, we execute at least once more time cryptsetup. In an ideal world we should loop on local-block as Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup mentions from initramfs-tools code), but this would be really a big change, non-SRUable probably. I plan to work that for future Ubuntu releases. [Test case] * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to create a RAID1 volume and an encrypted root on top of it. * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table from one of the RAID members. Reboot and it will fail to mount rootfs and continue boot process. * If using the initramfs-toos/cryptsetup patches hereby proposed, the rootfs can be mounted normally. [Regression potential] * There are potential for regressions, since this is a change in 2 boot components. The patches were designed in a way to keep the regular case working, it changes the failure case which is not currently working anyway. * A modification in the behavior of cryptsetup was introduced: right now, if we fail the password 3 times (the default maximum attempts), the script doesn't "panic" and drop to a shell immediately; instead it runs once more (or twice, if mdadm is installed) before failing. This is a minor change given the benefit of the being able to mount rootfs in a degraded RAID1 scenario. * Other potential regressions could show-up as boot problems, but the change in initramfs-tools specifically is not invasive, it just may delay boot time a bit, given we now run cryptsetup multiple times on local-block, with 1 sec delays between executions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
@gpiccoli, Can you break down everything this debdiff does per file being modified in the d/changelog along with the summary you have already provided ? It would ease for future reference and make the d/changelog more accurate about the changes. * d/cryptsetup-initramfs.install: - * d/functions cryptsetup-2.3.3/debian/functions: - * d/initramfs/scripts/local-block/cryptroot: - * d/initramfs/scripts/local-bottom/cryptroot: - * d/initramfs/scripts/local-top/cryptroot: - -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: In Progress Status in initramfs-tools source package in Focal: Fix Released Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: In Progress Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: New Bug description: [Impact] * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu is currently unable to decrypt the rootfs if the array gets degraded, like for example if one of the array's members gets removed. * The problem has 2 main aspects: first, cryptsetup initramfs script attempts to decrypt the array only in the local-top boot stage, and in case it fails, it gives-up and show user a shell (boot is aborted). * Second, mdadm initramfs script that assembles degraded arrays executes later on boot, in the local-block stage. So, in a stacked setup of encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails early in the boot, preventing mdadm to assemble the degraded array. * The hereby proposed solution has 2 components: first, cryptsetup script is modified to allow a gentle failure on local-top stage, then it retries for a while (according to a heuristic based on ROOTDELAY with minimum of 30 executions) in a later stage (local-block). This gives time to other initramfs scripts to run, like mdadm in local- block stage. And this is meant to work this way according to initramfs-tools documentation (although Ubuntu changed it a bit with wait-for-root, hence we stopped looping on local-block, see next bullet). * Second, initramfs-tools was adjusted - currently, it runs for a while the mdadm local-block script, in order to assemble the arrays in a non-degraded mode. We extended this approach to also execute cryptsetup, in a way that after mdadm ends its execution, we execute at least once more time cryptsetup. In an ideal world we should loop on local-block as Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup mentions from initramfs-tools code), but this would be really a big change, non-SRUable probably. I plan to work that for future Ubuntu releases. [Test case] * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to create a RAID1 volume and an encrypted root on top of it. * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table from one of the RAID members. Reboot and it will fail to mount rootfs and continue boot process. * If using the initramfs-toos/cryptsetup patches hereby proposed, the rootfs can be mounted normally. [Regression potential] * There are potential for regressions, since this is a change in 2 boot components. The patches were designed in a way to keep the regular case working, it changes the failure case which is not currently working anyway. * A modification in the behavior of cryptsetup was introduced: right now, if we fail the password 3 times (the default maximum attempts), the script doesn't "panic" and drop to a shell immediately; instead it runs once more (or twice, if mdadm is installed) before failing. This is a minor change given the benefit of the being able to mount rootfs in a degraded RAID1 scenario. * Other potential regressions could show-up as boot problems, but the change in initramfs-tools specifically is not invasive, it just may delay boot time a bit, given we now run cryptsetup multiple times on local-block, with 1 sec delays between executions. To manage notifications about this bug go to:
[Touch-packages] [Bug 1427600] Re: apport-unpack: ValueError: ['UserGroups'] has no binary content
I'm having the same stack trace from groovy, when trying to unpack ii apport 2.20.11-0ubuntu45 all automatically generate crash reports for debugging ii apport-symptoms0.23 all symptom scripts for apport ii python3-apport 2.20.11-0ubuntu45 all Python 3 library for Apport crash report handling -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1427600 Title: apport-unpack: ValueError: ['UserGroups'] has no binary content Status in apport package in Ubuntu: Fix Released Status in apport source package in Xenial: Triaged Status in apport source package in Focal: Fix Released Status in apport source package in Groovy: Fix Released Bug description: [Impact] apport-unpack crashes when trying to unpack a crash [Test Case] On a system running 20.04 LTS: 1) create an additional user who is only a member of their own group e.g. bdmurray@clean-focal-amd64:~$ id crashy uid=1001(crashy) gid=1001(crashy) groups=1001(crashy) 2) Launch a process as that user 3) kill -11 that process 4) Confirm there is a crash file in /var/crash for that process 5) Run apport-unpack on that .crash file With the version of apport from -proposed you will not get another crash file when unpacking the crash file. [Regression Potential] We are just setting UserGroups to 'N/A' as opposed to having it be completely empty so there isn't any chance for regression. When running apport-unpack to get at a core dump laney@raleigh> sudo apport-unpack _usr_lib_x86_64-linux-gnu_urfkill_urfkilld.0.crash ~/temp/zozoz [sudo] password for laney: Traceback (most recent call last): File "/usr/bin/apport-unpack", line 73, in pr.extract_keys(f, bin_keys, dir) File "/usr/lib/python3/dist-packages/problem_report.py", line 253, in extract_keys [item for item, element in b64_block.items() if element is False]) ValueError: ['UserGroups'] has no binary content laney@raleigh> apport-cli --version 2.16.2 It's not terrible, because most files are unpacked (those which sort before UserGroups, I guess). ProblemType: BugDistroRelease: Ubuntu 15.04 Package: apport 2.16.2-0ubuntu1 ProcVersionSignature: Ubuntu 3.19.0-7.7-generic 3.19.0 Uname: Linux 3.19.0-7-generic x86_64 ApportLog: ApportVersion: 2.16.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Tue Mar 3 10:09:26 2015 InstallationDate: Installed on 2012-10-07 (876 days ago) InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Beta amd64 (20121007) PackageArchitecture: allSourcePackage: apport UpgradeStatus: Upgraded to vivid on 2013-05-07 (665 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1427600/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1427600] Re: apport-unpack: ValueError: ['UserGroups'] has no binary content
$ lsb_release -cs bionic $ apport-unpack /var/tmp/_usr_bin_.0.crash /tmp/ Traceback (most recent call last): File "/usr/bin/apport-unpack", line 74, in pr.extract_keys(f, bin_keys, dir) File "/usr/lib/python3/dist-packages/problem_report.py", line 270, in extract_keys [item for item, element in b64_block.items() if element is False]) ValueError: ['UserGroups'] has no binary content -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1427600 Title: apport-unpack: ValueError: ['UserGroups'] has no binary content Status in apport package in Ubuntu: Fix Released Status in apport source package in Xenial: Triaged Status in apport source package in Focal: Fix Released Status in apport source package in Groovy: Fix Released Bug description: [Impact] apport-unpack crashes when trying to unpack a crash [Test Case] On a system running 20.04 LTS: 1) create an additional user who is only a member of their own group e.g. bdmurray@clean-focal-amd64:~$ id crashy uid=1001(crashy) gid=1001(crashy) groups=1001(crashy) 2) Launch a process as that user 3) kill -11 that process 4) Confirm there is a crash file in /var/crash for that process 5) Run apport-unpack on that .crash file With the version of apport from -proposed you will not get another crash file when unpacking the crash file. [Regression Potential] We are just setting UserGroups to 'N/A' as opposed to having it be completely empty so there isn't any chance for regression. When running apport-unpack to get at a core dump laney@raleigh> sudo apport-unpack _usr_lib_x86_64-linux-gnu_urfkill_urfkilld.0.crash ~/temp/zozoz [sudo] password for laney: Traceback (most recent call last): File "/usr/bin/apport-unpack", line 73, in pr.extract_keys(f, bin_keys, dir) File "/usr/lib/python3/dist-packages/problem_report.py", line 253, in extract_keys [item for item, element in b64_block.items() if element is False]) ValueError: ['UserGroups'] has no binary content laney@raleigh> apport-cli --version 2.16.2 It's not terrible, because most files are unpacked (those which sort before UserGroups, I guess). ProblemType: BugDistroRelease: Ubuntu 15.04 Package: apport 2.16.2-0ubuntu1 ProcVersionSignature: Ubuntu 3.19.0-7.7-generic 3.19.0 Uname: Linux 3.19.0-7-generic x86_64 ApportLog: ApportVersion: 2.16.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Tue Mar 3 10:09:26 2015 InstallationDate: Installed on 2012-10-07 (876 days ago) InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Beta amd64 (20121007) PackageArchitecture: allSourcePackage: apport UpgradeStatus: Upgraded to vivid on 2013-05-07 (665 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1427600/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded
[sts-sponsor] Sponsored in Focal/Bionic. Thanks for your contribution. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879980 Title: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded Status in cryptsetup package in Ubuntu: In Progress Status in initramfs-tools package in Ubuntu: Fix Released Status in mdadm package in Ubuntu: Opinion Status in cryptsetup source package in Xenial: Won't Fix Status in initramfs-tools source package in Xenial: Won't Fix Status in mdadm source package in Xenial: Won't Fix Status in cryptsetup source package in Bionic: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in mdadm source package in Bionic: Opinion Status in cryptsetup source package in Focal: In Progress Status in initramfs-tools source package in Focal: In Progress Status in mdadm source package in Focal: Opinion Status in cryptsetup source package in Groovy: In Progress Status in initramfs-tools source package in Groovy: Fix Released Status in mdadm source package in Groovy: Opinion Status in cryptsetup package in Debian: New Bug description: [Impact] * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu is currently unable to decrypt the rootfs if the array gets degraded, like for example if one of the array's members gets removed. * The problem has 2 main aspects: first, cryptsetup initramfs script attempts to decrypt the array only in the local-top boot stage, and in case it fails, it gives-up and show user a shell (boot is aborted). * Second, mdadm initramfs script that assembles degraded arrays executes later on boot, in the local-block stage. So, in a stacked setup of encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails early in the boot, preventing mdadm to assemble the degraded array. * The hereby proposed solution has 2 components: first, cryptsetup script is modified to allow a gentle failure on local-top stage, then it retries for a while (according to a heuristic based on ROOTDELAY with minimum of 30 executions) in a later stage (local-block). This gives time to other initramfs scripts to run, like mdadm in local- block stage. And this is meant to work this way according to initramfs-tools documentation (although Ubuntu changed it a bit with wait-for-root, hence we stopped looping on local-block, see next bullet). * Second, initramfs-tools was adjusted - currently, it runs for a while the mdadm local-block script, in order to assemble the arrays in a non-degraded mode. We extended this approach to also execute cryptsetup, in a way that after mdadm ends its execution, we execute at least once more time cryptsetup. In an ideal world we should loop on local-block as Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup mentions from initramfs-tools code), but this would be really a big change, non-SRUable probably. I plan to work that for future Ubuntu releases. [Test case] * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to create a RAID1 volume and an encrypted root on top of it. * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table from one of the RAID members. Reboot and it will fail to mount rootfs and continue boot process. * If using the initramfs-toos/cryptsetup patches hereby proposed, the rootfs can be mounted normally. [Regression potential] * There are potential for regressions, since this is a change in 2 boot components. The patches were designed in a way to keep the regular case working, it changes the failure case which is not currently working anyway. * A modification in the behavior of cryptsetup was introduced: right now, if we fail the password 3 times (the default maximum attempts), the script doesn't "panic" and drop to a shell immediately; instead it runs once more (or twice, if mdadm is installed) before failing. This is a minor change given the benefit of the being able to mount rootfs in a degraded RAID1 scenario. * Other potential regressions could show-up as boot problems, but the change in initramfs-tools specifically is not invasive, it just may delay boot time a bit, given we now run cryptsetup multiple times on local-block, with 1 sec delays between executions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.
[sts-sponsor] Sponsored in Focal/Bionic. Thanks for your contribution. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1879987 Title: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist. Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Trusty: Won't Fix Status in initramfs-tools source package in Xenial: In Progress Status in initramfs-tools source package in Bionic: In Progress Status in initramfs-tools source package in Eoan: Won't Fix Status in initramfs-tools source package in Focal: In Progress Status in initramfs-tools source package in Groovy: Fix Released Bug description: [Impact] * Currently, if users provide the wrong console in kernel command-line (like console=ttyS1, when the right one is ttyS0) *and* "quiet" parameter is not provided, we may face an infinite loop on initramfs- tools, effectively blocking the boot. * Details are: the _log_msg() functions is "void" typed, which means it returns whatever its last command returns; this function is the basic building block for all error/warning messages in initramfs-tools. In case a bad console was provided to kernel on command-line, printf (and apparently all write()-related functions) returns error, and so this error is carried over in _log_msg(). * Happens that checkfs() function has a loop that runs forever in this scenario (*if* fsck is not present in initramfs, and obviously if "quiet" is not provided in the command-line). The situation is easily reproducible. * This SRU proposes a pretty simple fix: return zero on _log_msg(). We should definitely not brake the boot due to error log functions. [Test Case] * To reproduce this, one must boot a system (virtual machine is good) with the wrong console set on kernel command-line through the "console=" parameter *and* not pass the "quiet" parameter. * Also, e2fsck tool shouldn't be present in the initrd - for that, the 6th field of /etc/fstab (fs_passno) should be 0 and initrd must be recreated after that. This is the default in Ubuntu, though. [Regression Potential] * The regression potential is small, we're just returning 0 after a printf that is executed in error paths, so I don't expect any issues from that. But in case something bad happens after this change, I expect a more friendly" breakage, like an initramfs panic (drop to a shell), not a silent failure or boot-loop. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1820929] Re: netplan should consider adding more udev attribute for exact matching of failover 3-netdev interfaces
[sts-sponsor] Sponsored in Bionic. Thanks for your contribution. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1820929 Title: netplan should consider adding more udev attribute for exact matching of failover 3-netdev interfaces Status in netplan: Triaged Status in initramfs-tools package in Ubuntu: New Status in netplan.io package in Ubuntu: Triaged Status in systemd package in Ubuntu: Incomplete Status in initramfs-tools source package in Bionic: In Progress Status in netplan.io source package in Bionic: New Status in systemd source package in Bionic: New Bug description: [Impact] * At present, virtual machines utilizing net_failover network interface configurations are incorrectly configured due to the reliance on the MAC address to identify specific network interfaces. When net_failover is utilized, multiple interfaces will bear the same MAC address (the net_failover master itself, as well as the interfaces subordinate to it), rendering the MAC address ineffective for unique identification of the interface. This results in incorrect naming of network interfaces from the "set-name" directive in the netplan configuration. * The solution here is to use the interface name instead of the MAC address when the interface is a net_failover master device. Logic is added on initramfs-tools to check the device type and virtio flags to apply this change only to net_failover master devices. [Test Case] * The change can be tested by configuring a virtual machine with a virtio_net network device with the "failover=on" option to the "-device" option to qemu, e.g., -device virtio-net- pci,netdev=hostnet0,id=net0,bus=pci.0,addr=0x3,mac=00:00:17:00:18:04,failover=on * This will set the virtio device "standby" feature bit (bit 62, counting from 0). This requires a version of qemu with support for this feature. * When so configured, the netplan configuration generated by initramfs will not contain a "macaddress:" match directive for the network interface in question. [Regression Potential] * Erroneous identification of a network interface as a net_failover master device could lead to omission of a macaddress directive, causing interfaces to be incorrectly named. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1820929/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890177] Re: rsyslogd: file '/dev/console': open error: Permission denied
** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1890177 Title: rsyslogd: file '/dev/console': open error: Permission denied Status in rsyslog package in Ubuntu: New Status in rsyslog source package in Focal: Fix Committed Bug description: [Impact] At the moment rsyslog cannot have access /dev/console due to a mismatch permission/ownership between '/dev/console' and the Privilege Drop User and Group 'syslog' in rsyslog. [Test Case] * Deploy focal/20.04LTS (tested in gcloud instance) * Install rsyslog * systemctl restart rsyslog OR systemctl restart rsyslog * Inspect /var/log/syslog for the following error: syslog:Aug 4 14:37:56 rsyslogd: file '/dev/console': open error: Permission denied [v8.2001.0 try https://www.rsyslog.com/e/2433 ] [Regression potential] https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1890177/comments/4 [Other information] Other bug: https://github.com/GoogleCloudPlatform/compute-image-packages/issues/889 [Original description] The Privilege Drop options ($PrivDrop*) in focal's rsyslog both point to 'syslog' for the user and group, and don't match the ownership/permission of '/dev/console' generating the following: syslog:Aug 3 15:16:58 rsyslogd: file '/dev/console': open error: Permission denied [v8.2001.0 try https://www.rsyslog.com/e/2433 ] Looking in Bionic/18.04LTS, '/dev/console' used to be root:syslog[1], nowadays it's root:tty[2] [1] - Bionic/18.04LTS (Gcloud instance) # ls -l /dev/console crw--w 1 root syslog 5, 1 Aug 3 15:17 /dev/console [2] - Focal/20.04LTS (Gcloud instance) # ls -l /dev/console crw--w 1 root tty 5, 1 Aug 3 17:19 /dev/console # /etc/rsyslog.conf $PrivDropToUser syslog $PrivDropToGroup syslog ** As a debug exercise I did the following: - Cannot reproduce the situation if I intentionally get rid of the PrivDrop* options. - Cannot reproduce the situation if I intentionally add 'syslog' user member of 'tty' group. Meaning that it's pretty obvious with the above statement that the permission denied is caused by the permission/ownership mismatch between '/dev/console' 's ownership permission & syslog user (PrivDropTo[User|Group]). Other bug: https://github.com/GoogleCloudPlatform/compute-image-packages/issues/889 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1890177/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890177] Re: rsyslogd: file '/dev/console': open error: Permission denied
@zack You could wait until the logrotate happen and restart rsyslog or you could simply do manual restart using 'systemctl restart rsyslog' and then look in /var/log/syslog. What triggers the error is at rsyslog startup from what I have notice during my test. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1890177 Title: rsyslogd: file '/dev/console': open error: Permission denied Status in rsyslog package in Ubuntu: New Status in rsyslog source package in Focal: Fix Committed Bug description: [Impact] At the moment rsyslog cannot have access /dev/console due to a mismatch permission/ownership between '/dev/console' and the Privilege Drop User and Group 'syslog' in rsyslog. [Test Case] * Deploy focal/20.04LTS (tested in gcloud instance) * Install rsyslog * systemctl restart rsyslog OR systemctl restart rsyslog * Inspect /var/log/syslog for the following error: syslog:Aug 4 14:37:56 rsyslogd: file '/dev/console': open error: Permission denied [v8.2001.0 try https://www.rsyslog.com/e/2433 ] [Regression potential] https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1890177/comments/4 [Other information] Other bug: https://github.com/GoogleCloudPlatform/compute-image-packages/issues/889 [Original description] The Privilege Drop options ($PrivDrop*) in focal's rsyslog both point to 'syslog' for the user and group, and don't match the ownership/permission of '/dev/console' generating the following: syslog:Aug 3 15:16:58 rsyslogd: file '/dev/console': open error: Permission denied [v8.2001.0 try https://www.rsyslog.com/e/2433 ] Looking in Bionic/18.04LTS, '/dev/console' used to be root:syslog[1], nowadays it's root:tty[2] [1] - Bionic/18.04LTS (Gcloud instance) # ls -l /dev/console crw--w 1 root syslog 5, 1 Aug 3 15:17 /dev/console [2] - Focal/20.04LTS (Gcloud instance) # ls -l /dev/console crw--w 1 root tty 5, 1 Aug 3 17:19 /dev/console # /etc/rsyslog.conf $PrivDropToUser syslog $PrivDropToGroup syslog ** As a debug exercise I did the following: - Cannot reproduce the situation if I intentionally get rid of the PrivDrop* options. - Cannot reproduce the situation if I intentionally add 'syslog' user member of 'tty' group. Meaning that it's pretty obvious with the above statement that the permission denied is caused by the permission/ownership mismatch between '/dev/console' 's ownership permission & syslog user (PrivDropTo[User|Group]). Other bug: https://github.com/GoogleCloudPlatform/compute-image-packages/issues/889 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1890177/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890177] Re: rsyslogd: file '/dev/console': open error: Permission denied
@zack You could wait until the logrotate happen that will then restart rsyslog itself or you could simply do a manual restart using 'systemctl restart rsyslog' and then look in /var/log/syslog. What triggers the error is at rsyslog startup from what I have notice during my test. - Eric -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1890177 Title: rsyslogd: file '/dev/console': open error: Permission denied Status in rsyslog package in Ubuntu: New Status in rsyslog source package in Focal: Fix Committed Bug description: [Impact] At the moment rsyslog cannot have access /dev/console due to a mismatch permission/ownership between '/dev/console' and the Privilege Drop User and Group 'syslog' in rsyslog. [Test Case] * Deploy focal/20.04LTS (tested in gcloud instance) * Install rsyslog * systemctl restart rsyslog OR systemctl restart rsyslog * Inspect /var/log/syslog for the following error: syslog:Aug 4 14:37:56 rsyslogd: file '/dev/console': open error: Permission denied [v8.2001.0 try https://www.rsyslog.com/e/2433 ] [Regression potential] https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1890177/comments/4 [Other information] Other bug: https://github.com/GoogleCloudPlatform/compute-image-packages/issues/889 [Original description] The Privilege Drop options ($PrivDrop*) in focal's rsyslog both point to 'syslog' for the user and group, and don't match the ownership/permission of '/dev/console' generating the following: syslog:Aug 3 15:16:58 rsyslogd: file '/dev/console': open error: Permission denied [v8.2001.0 try https://www.rsyslog.com/e/2433 ] Looking in Bionic/18.04LTS, '/dev/console' used to be root:syslog[1], nowadays it's root:tty[2] [1] - Bionic/18.04LTS (Gcloud instance) # ls -l /dev/console crw--w 1 root syslog 5, 1 Aug 3 15:17 /dev/console [2] - Focal/20.04LTS (Gcloud instance) # ls -l /dev/console crw--w 1 root tty 5, 1 Aug 3 17:19 /dev/console # /etc/rsyslog.conf $PrivDropToUser syslog $PrivDropToGroup syslog ** As a debug exercise I did the following: - Cannot reproduce the situation if I intentionally get rid of the PrivDrop* options. - Cannot reproduce the situation if I intentionally add 'syslog' user member of 'tty' group. Meaning that it's pretty obvious with the above statement that the permission denied is caused by the permission/ownership mismatch between '/dev/console' 's ownership permission & syslog user (PrivDropTo[User|Group]). Other bug: https://github.com/GoogleCloudPlatform/compute-image-packages/issues/889 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1890177/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1881976] Re: apport-gtk and apport-kde install xiterm+thai as dependency (x-terminal-emulator)
The apport (2.20.11-0ubuntu27.6) security channel build haven't been caught in that FTBFS situation because it was tested against the former pycodestyle package: Get:310 http://ftpmaster.internal/ubuntu focal/universe amd64 pycodestyle all 2.5.0-2 [5092 B] -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1881976 Title: apport-gtk and apport-kde install xiterm+thai as dependency (x -terminal-emulator) Status in apport package in Ubuntu: Fix Released Status in apport source package in Focal: Fix Committed Bug description: [Impact] * When installing apport-gtk (or apport-kde) on a non-GUI installation (cloud image, server image) as a dependency providing x-terminal-emulator xiterm+thai package is pulled in, which is not appropriate for most locales. My understanding is it was selected due to lowest number of unsatisfied dependencies. [Test Case] * lxc launch ubuntu:20.04 test * lxc shell test * apt update * apt install apport-gtk * Examine the packages listed to be installed: xiterm+thai is one of them. [Regression Potential] * In dedicated archive mirrors with limited number of packages changing that may cause errors due to packages missing in the archive. However, that's unlikely. [Other Info] * It is not affecting bionic, since x-terminal-emulator is listed as 'Suggests' not 'Depends' there. * Original bug description: Vanilla install of Ubuntu 20.04 set to an Australian locale includes the "Thai X Terminal" package. This package should not be included. I noticed that it is also reported against Xubuntu and Lubuntu: https://bugs.launchpad.net/lubuntu-next/+bug/1747341 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1881976/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1881976] Re: apport-gtk and apport-kde install xiterm+thai as dependency (x-terminal-emulator)
[sts-sponsor note] Package doesn't build due to new pycodestyle (2.6.0-1~20.04.1) found in focal-proposed as opposed to its former version (2.5.0-2) that now detects the following during the test: Running pycodestyle... ./setup.py:78:33: E741 ambiguous variable name 'l' ./test/test_fileutils.py:380:13: E741 ambiguous variable name 'l' ./test/test_signal_crashes.py:141:13: E741 ambiguous variable name 'l' ./test/test_ui.py:1773:43: E741 ambiguous variable name 'l' ./backends/packaging-apt-dpkg.py:1222:13: E741 ambiguous variable name 'l' ./backends/packaging-apt-dpkg.py:1233:17: E741 ambiguous variable name 'l' ./build/lib/apport/__init__.py:67:13: E741 ambiguous variable name 'l' ./build/lib/apport/fileutils.py:332:9: E741 ambiguous variable name 'l' ./build/lib/apport/hookutils.py:620:9: E741 ambiguous variable name 'l' ./build/lib/apport/hookutils.py:630:9: E741 ambiguous variable name 'l' This has been addressed in apport groovy where ambiguous 'l' have been replaced by 'line'. # d/changelog apport (2.20.11-0ubuntu42) groovy; urgency=medium * Fix pep8 errors regarding ambiguous variables. -- Brian Murray Wed, 24 Jun 2020 09:15:51 -0700 Patch example: ... - for l in lines: - fd.write(l) + for line in lines: + fd.write(line) ... The same fix now need to be applied into focal for the package to start building again. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1881976 Title: apport-gtk and apport-kde install xiterm+thai as dependency (x -terminal-emulator) Status in apport package in Ubuntu: Fix Released Status in apport source package in Focal: Fix Committed Bug description: [Impact] * When installing apport-gtk (or apport-kde) on a non-GUI installation (cloud image, server image) as a dependency providing x-terminal-emulator xiterm+thai package is pulled in, which is not appropriate for most locales. My understanding is it was selected due to lowest number of unsatisfied dependencies. [Test Case] * lxc launch ubuntu:20.04 test * lxc shell test * apt update * apt install apport-gtk * Examine the packages listed to be installed: xiterm+thai is one of them. [Regression Potential] * In dedicated archive mirrors with limited number of packages changing that may cause errors due to packages missing in the archive. However, that's unlikely. [Other Info] * It is not affecting bionic, since x-terminal-emulator is listed as 'Suggests' not 'Depends' there. * Original bug description: Vanilla install of Ubuntu 20.04 set to an Australian locale includes the "Thai X Terminal" package. This package should not be included. I noticed that it is also reported against Xubuntu and Lubuntu: https://bugs.launchpad.net/lubuntu-next/+bug/1747341 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1881976/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1881976] Re: apport-gtk and apport-kde install xiterm+thai as dependency (x-terminal-emulator)
[sts-sponsor note] Package doesn't build due to new pycodestyle (2.6.0-1~20.04.1) found in focal-proposed as opposed to its former version (2.5.0-2) that now detects the following during the test: Running pycodestyle... ./setup.py:78:33: E741 ambiguous variable name 'l' ./test/test_fileutils.py:380:13: E741 ambiguous variable name 'l' ./test/test_signal_crashes.py:141:13: E741 ambiguous variable name 'l' ./test/test_ui.py:1773:43: E741 ambiguous variable name 'l' ./backends/packaging-apt-dpkg.py:1222:13: E741 ambiguous variable name 'l' ./backends/packaging-apt-dpkg.py:1233:17: E741 ambiguous variable name 'l' ./build/lib/apport/__init__.py:67:13: E741 ambiguous variable name 'l' ./build/lib/apport/fileutils.py:332:9: E741 ambiguous variable name 'l' ./build/lib/apport/hookutils.py:620:9: E741 ambiguous variable name 'l' ./build/lib/apport/hookutils.py:630:9: E741 ambiguous variable name 'l' This has been addressed in apport groovy where ambiguous 'l' have been replaced by 'line'. # d/changelog apport (2.20.11-0ubuntu42) groovy; urgency=medium * Fix pep8 errors regarding ambiguous variables. -- Brian Murray Wed, 24 Jun 2020 09:15:51 -0700 Patch example: ... -for l in lines: -fd.write(l) +for line in lines: +fd.write(line) ... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/1881976 Title: apport-gtk and apport-kde install xiterm+thai as dependency (x -terminal-emulator) Status in apport package in Ubuntu: Fix Released Status in apport source package in Focal: Fix Committed Bug description: [Impact] * When installing apport-gtk (or apport-kde) on a non-GUI installation (cloud image, server image) as a dependency providing x-terminal-emulator xiterm+thai package is pulled in, which is not appropriate for most locales. My understanding is it was selected due to lowest number of unsatisfied dependencies. [Test Case] * lxc launch ubuntu:20.04 test * lxc shell test * apt update * apt install apport-gtk * Examine the packages listed to be installed: xiterm+thai is one of them. [Regression Potential] * In dedicated archive mirrors with limited number of packages changing that may cause errors due to packages missing in the archive. However, that's unlikely. [Other Info] * It is not affecting bionic, since x-terminal-emulator is listed as 'Suggests' not 'Depends' there. * Original bug description: Vanilla install of Ubuntu 20.04 set to an Australian locale includes the "Thai X Terminal" package. This package should not be included. I noticed that it is also reported against Xubuntu and Lubuntu: https://bugs.launchpad.net/lubuntu-next/+bug/1747341 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1881976/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890177] Re: rsyslogd: file '/dev/console': open error: Permission denied
I have retried the autpkgtest test on ppc64el. It is failing on 'systemd-fsckd'. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1890177 Title: rsyslogd: file '/dev/console': open error: Permission denied Status in rsyslog package in Ubuntu: New Status in rsyslog source package in Focal: Fix Committed Bug description: [Impact] At the moment rsyslog cannot have access /dev/console due to a mismatch permission/ownership between '/dev/console' and the Privilege Drop User and Group 'syslog' in rsyslog. [Test Case] * Deploy focal/20.04LTS (tested in gcloud instance) * Install rsyslog * systemctl restart rsyslog OR systemctl restart rsyslog * Inspect /var/log/syslog for the following error: syslog:Aug 4 14:37:56 rsyslogd: file '/dev/console': open error: Permission denied [v8.2001.0 try https://www.rsyslog.com/e/2433 ] [Regression potential] https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1890177/comments/4 [Other information] Other bug: https://github.com/GoogleCloudPlatform/compute-image-packages/issues/889 [Original description] The Privilege Drop options ($PrivDrop*) in focal's rsyslog both point to 'syslog' for the user and group, and don't match the ownership/permission of '/dev/console' generating the following: syslog:Aug 3 15:16:58 rsyslogd: file '/dev/console': open error: Permission denied [v8.2001.0 try https://www.rsyslog.com/e/2433 ] Looking in Bionic/18.04LTS, '/dev/console' used to be root:syslog[1], nowadays it's root:tty[2] [1] - Bionic/18.04LTS (Gcloud instance) # ls -l /dev/console crw--w 1 root syslog 5, 1 Aug 3 15:17 /dev/console [2] - Focal/20.04LTS (Gcloud instance) # ls -l /dev/console crw--w 1 root tty 5, 1 Aug 3 17:19 /dev/console # /etc/rsyslog.conf $PrivDropToUser syslog $PrivDropToGroup syslog ** As a debug exercise I did the following: - Cannot reproduce the situation if I intentionally get rid of the PrivDrop* options. - Cannot reproduce the situation if I intentionally add 'syslog' user member of 'tty' group. Meaning that it's pretty obvious with the above statement that the permission denied is caused by the permission/ownership mismatch between '/dev/console' 's ownership permission & syslog user (PrivDropTo[User|Group]). Other bug: https://github.com/GoogleCloudPlatform/compute-image-packages/issues/889 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1890177/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
