[Touch-packages] [Bug 1930286] Re: Defensics' synopsys fuzzer testing tool cause openssh to segfault

2021-06-07 Thread Eric Desrochers
** 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

2021-06-07 Thread Eric Desrochers
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

2021-06-07 Thread Eric Desrochers
** 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

2021-06-07 Thread Eric Desrochers
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

2021-06-02 Thread Eric Desrochers
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

2021-06-02 Thread Eric Desrochers
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

2021-06-02 Thread Eric Desrochers
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

2021-05-31 Thread Eric Desrochers
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

2021-05-25 Thread Eric Desrochers
** 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

2021-02-23 Thread Eric Desrochers
** 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

2021-02-23 Thread Eric Desrochers
** 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

2021-02-23 Thread Eric Desrochers
** 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

2021-02-22 Thread Eric Desrochers
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

2021-02-17 Thread Eric Desrochers
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

2021-02-17 Thread Eric Desrochers
** 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

2021-02-17 Thread Eric Desrochers
** 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

2021-02-17 Thread Eric Desrochers
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

2021-02-17 Thread Eric Desrochers
** 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

2021-02-17 Thread Eric Desrochers
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

2021-02-17 Thread Eric Desrochers
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

2021-02-17 Thread Eric Desrochers
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

2021-02-17 Thread Eric Desrochers
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

2020-12-20 Thread Eric Desrochers
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

2020-12-20 Thread Eric Desrochers
@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

2020-12-20 Thread Eric Desrochers
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

2020-12-20 Thread Eric Desrochers
** 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

2020-12-20 Thread Eric Desrochers
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

2020-12-12 Thread Eric Desrochers
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

2020-12-12 Thread Eric Desrochers
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

2020-12-10 Thread Eric Desrochers
[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

2020-12-10 Thread Eric Desrochers
[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

2020-12-07 Thread Eric Desrochers
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

2020-12-07 Thread Eric Desrochers
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)

2020-11-26 Thread Eric Desrochers
** 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

2020-11-20 Thread Eric Desrochers
(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

2020-11-20 Thread Eric Desrochers
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

2020-10-26 Thread Eric Desrochers
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

2020-10-16 Thread Eric Desrochers
# 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

2020-10-13 Thread Eric Desrochers
** 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)

2020-10-06 Thread Eric Desrochers
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)

2020-10-06 Thread Eric Desrochers
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

2020-09-30 Thread Eric Desrochers
[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

2020-09-30 Thread Eric Desrochers
** 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

2020-09-25 Thread Eric Desrochers
** 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

2020-09-25 Thread Eric Desrochers
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

2020-09-23 Thread Eric Desrochers
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

2020-09-23 Thread Eric Desrochers
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

2020-09-22 Thread Eric Desrochers
[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

2020-09-22 Thread Eric Desrochers
@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

2020-09-02 Thread Eric Desrochers
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

2020-09-02 Thread Eric Desrochers
$ 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

2020-09-02 Thread Eric Desrochers
[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.

2020-09-02 Thread Eric Desrochers
[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

2020-09-02 Thread Eric Desrochers
[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

2020-08-10 Thread Eric Desrochers
** 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

2020-08-08 Thread Eric Desrochers
@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

2020-08-08 Thread Eric Desrochers
@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)

2020-08-07 Thread Eric Desrochers
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)

2020-08-07 Thread Eric Desrochers
[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)

2020-08-07 Thread Eric Desrochers
[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

2020-08-07 Thread Eric Desrochers
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


[Touch-packages] [Bug 1890177] Re: rsyslogd: file '/dev/console': open error: Permission denied

2020-08-07 Thread Eric Desrochers
I have retry the test, it is failing on 'systemd-fsckd'.

Let's see.

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

2020-08-04 Thread Eric Desrochers
** Description changed:

  [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
+ * 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

-- 
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:
  In Progress

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

2020-08-04 Thread Eric Desrochers
Thanks @sil2100 for your pre-approval comment.

I have uploaded it into focal upload queue. 
It is now waiting for the official SRU team approval in order to start building 
in focal-proposed for the verification test phase.

- 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:
  In Progress

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

2020-08-04 Thread Eric Desrochers
** Description changed:

+ [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
+ * 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]
+ 
+ [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

** Description changed:

  [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
  * 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

-- 
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:
  In Progress

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
  * 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 ]

 

[Touch-packages] [Bug 1890177] Re: rsyslogd: file '/dev/console': open error: Permission denied

2020-08-04 Thread Eric Desrochers
** Changed in: rsyslog (Ubuntu Focal)
   Status: New => In Progress

** Changed in: rsyslog (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: rsyslog (Ubuntu Focal)
 Assignee: (unassigned) => Eric Desrochers (slashd)

-- 
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:
  In Progress

Bug 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

2020-08-04 Thread Eric Desrochers
One easy fix would possibly be the following:

# debian/rsyslog.postinst
case "$1" in
configure)
adduser --system --group --no-create-home --quiet syslog || true
adduser syslog adm || true
   +adduser syslog tty || true


I have tested it in a PPA, and it works just fine:

Preparing to unpack .../rsyslog_8.2001.0-1ubuntu1+test2020307b1_amd64.deb ...
Unpacking rsyslog (8.2001.0-1ubuntu1+test2020307b1) over (8.2001.0-1ubuntu1) ...
Setting up rsyslog (8.2001.0-1ubuntu1+test2020307b1) ...
The user `syslog' is already a member of `adm'.
Adding user `syslog' to group `tty' ...
==> Adding user syslog to group tty <==
Done.
Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
Processing triggers for man-db (2.9.1-1) ...
Processing triggers for systemd (245.4-4ubuntu3.1) ...


# /etc/group
tty:x:5:syslog

-- 
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:
  New

Bug 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

2020-08-03 Thread Eric Desrochers
https://wiki.debian.org/SystemGroups

tty: TTY devices are owned by this group. This is used by write and wall
to enable them to write to other people's TTYs, but it is not intended
to be used directly.

-- 
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:
  New

Bug 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

2020-08-03 Thread Eric Desrochers
One easy fix would possibly be the following:

# debian/rsyslog.postinst
case "$1" in
configure)
adduser --system --group --no-create-home --quiet syslog || true
adduser syslog adm || true
   +adduser syslog tty || true

I'll give it a try and test.

-- 
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:
  New

Bug 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] [NEW] rsyslogd: file '/dev/console': open error: Permission denied

2020-08-03 Thread Eric Desrochers
Public bug reported:

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

** Affects: rsyslog (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: rsyslog (Ubuntu Focal)
 Importance: Undecided
 Status: New


** Tags: seg sts

** Tags added: seg sts

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

** Description changed:

  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 
+ # 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

-- 
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:
  New

Bug 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 1870585] Re: Not cleaning /var/tmp by default

2020-07-31 Thread Eric Desrochers
** Bug watch added: Debian Bug tracker #966621
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966621

** Also affects: systemd (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966621
   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/1870585

Title:
  Not cleaning /var/tmp by default

Status in systemd package in Ubuntu:
  New
Status in systemd package in Debian:
  Unknown

Bug description:
  1) 20.04
  2) 245.2-1ubuntu2
  3) I expect /var/tmp to be cleaned up in some way.
  4) It's commented out per 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773313

  In sosreport was comparing the difference between /tmp (Ubuntu/Debian)
  and /var/tmp (RH) and determined that as long as /var/tmp gets cleaned
  on a regular basis we would prefer /var/tmp.

  The  bug that appears to have prompted the disabling was fixed a long
  time ago, can we have this 30d delete re-enabled by default?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1870585/+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)

2020-07-29 Thread Eric Desrochers
[sts-sponsor]

Sponsored in active development release (groovy)

** Changed in: apport (Ubuntu)
   Status: In Progress => Fix Committed

-- 
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 Committed
Status in apport source package in Focal:
  In Progress

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)

2020-07-29 Thread Eric Desrochers
[sts-sponsor]

@dgadomski

I don't think you can add a runtime dependency from universe to a
package found in main

 apport-gtk | 2.20.11-0ubuntu42   | groovy   
 konsole | 4:20.04.3-0ubuntu1  | groovy/universe 

This would most likely require an MIR for konsole first.

https://wiki.ubuntu.com/MainInclusionProcess

Dependencies:

All binary dependencies (including Recommends:) must be satisfiable in
main (i. e. the preferred alternative must be in main). If not, these
dependencies need a separate MIR report (this can be a separate bug or
another task on the main MIR bug)

-- 
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:
  In Progress
Status in apport source package in Focal:
  In Progress

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 1875927] Re: add support for phys_port_name attribute in Xenial/16.04LTS

2020-05-22 Thread Eric Desrochers
** Changed in: systemd (Ubuntu Xenial)
   Status: In Progress => Won't Fix

** Changed in: systemd (Ubuntu Xenial)
 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/1875927

Title:
  add support for phys_port_name attribute in Xenial/16.04LTS

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Won't Fix

Bug description:
  [Impact]
  In Xenial/16.04LTS, one can't generate network interface name from 
"phys_port_name" attribute.

  "phys_port_name" indicates the interface physical port name within the
  NIC.

  [Test Case]

  Check that udev (systemd-udevd) provides the phys_port_name property
  Tests should be done on kernel versions: v4.15 (HWE)

  # cat /sys/class/net//phys_port_name
  yyy

  Look if interface name contains the 'phys_port_name':

  $ ip link show
  
  3: ens3nyyy:  ...
  

  [Regression Potential]

  * This piece of code is already in place in Bionic (systemd) and late.
  AFAICT, nothing has been reported since then with regards to this feature.

  * phys_port_name kernel support has been introduced in v4.1, but none
  of the current v4.4 Xenial kernel drivers uses it (minus rocker which
  is a test bed software switch for devel work on switchdev, it has no
  real function)

  # Xenial - kernel v4.4
  config-4.4.0-142-generic:# CONFIG_NET_SWITCHDEV is not set

  No drivers uses the phys_port_name method at all + NET_SWITCHDEV is
  not even turned on.

  # Xenial HWE - kernel v4.15
  config-4.15.0-99-generic:CONFIG_NET_SWITCHDEV=y

  Meaning if a regression arise, it will be limited to the HWE kernel (v4.15) 
and to the "Ethernet switch device driver model (switchdev)":
  mlx5
  mlxsw
  bnxt
  sfc (solarflar)

  --
  drivers/net/ethernet:
  --
  broadcom/bnxt/bnxt_vfr.c: .ndo_get_phys_port_name = 
bnxt_vf_rep_get_phys_port_name
  broadcom/bnxt/bnxt.c: .ndo_get_phys_port_name = bnxt_get_phys_port_name
  cavium/liquidio/lio_vf_rep.c: .ndo_get_phys_port_name = 
lio_vf_rep_phys_port_name,
  mellanox/mlx5/core/en_rep.c:  .ndo_get_phys_port_name  = 
mlx5e_rep_get_phys_port_name,
  mellanox/mlxsw/switchx2.c:.ndo_get_phys_port_name = 
mlxsw_sx_port_get_phys_port_name,
  mellanox/mlxsw/spectrum.c:.ndo_get_phys_port_name = 
mlxsw_sp_port_get_phys_port_name,
  netronome/nfp/nfp_net_repr.c: .ndo_get_phys_port_name = 
nfp_port_get_phys_port_name,
  netronome/nfp/nfp_net_common.c:   .ndo_get_phys_port_name = 
nfp_port_get_phys_port_name,
  rocker/rocker_main.c: .ndo_get_phys_port_name = 
rocker_port_get_phys_port_name,
  sfc/efx.c:.ndo_get_phys_port_name = efx_get_phys_port_name,
  --

  # On other more specific kernels the regression potential can be
  expanded to virtio-net driver as well.

  # cloud-init may taint the result as it renames switchdev(s) after
  systemd at first initialization (even without the phys_port_name
  support) as follows:

  (Testing on a sfc card / server deployed by MAAS)

  syslog:May 20 22:12:43 OBFUSCATED_HOST kernel: [ 36.199674] sfc :08:00.1 
ens1f1: renamed from eth1 ## systemd
  syslog:May 20 22:12:43 OBFUSCATED_HOST kernel: [ 37.128236] sfc :08:00.0 
ens1f0: renamed from eth0 ## systemd

  syslog:May 20 22:12:43 OBFUSCATED_HOST kernel: [ 84.653460] sfc :08:00.0 
ens1f0np0: renamed from ens1f0 ## cloud-init
  syslog:May 20 22:12:43 OBFUSCATED_HOST kernel: [ 84.697177] sfc :08:00.1 
ens1f1np1: renamed from ens1f1 ## cloud-init

  cloud-init.log:2020-05-20 22:04:53,980 - util.py[DEBUG]: Running command 
['ip', 'link', 'set', 'ens1f0', 'name', 'ens1f0np0'] with allowed return codes 
[0] (shell=False, capture=True)
  cloud-init.log:2020-05-20 22:04:54,016 - util.py[DEBUG]: Running command 
['ip', 'link', 'set', 'ens1f1', 'name', 'ens1f1np1'] with allowed return codes 
[0] (shell=False, capture=True)

  systemd:
  ... OBFUSCATED_HOST systemd[1]: sys-subsystem-net-devices-ens1f1.device: Dev 
sys-subsystem-net-devices-ens1f1.device appeared twice with different sysfs 
paths /sys/devices/pci:00/:00:03.0/:08:00.1/net/ens1f1 and 
/sys/devices/pci:00/:00:03.0/:08:00.1/net/ens1f1np1

  # 1 concern was raise here by ddstreet:
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1875927/comments/1

  Here's the result of the test I have performed:
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1875927/comments/5

  This change indeed rename existing switchdev interfaces to add the
  'phys_port_name' (if any) into it. I'm afraid this will be a non-
  acceptable behaviour change in stable release and won't be SRU'able.

  More discussion on this topic to come 

  [Other informations]
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506

  [Original

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

2020-05-22 Thread Eric Desrochers
I tested with debian buster and I wasn't able to reproduce (w/o quiet
parameter)

I'm not yet too sure if it's a pure initramfs-tools or something
introduced by a package hooks.

I first thought that plymouth could have beeb a potential candidate, but
I disabled it and even purge it and problem persisted.

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

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  kernel get stucks at boot if console=ttyS* is specified in the kernel
  cmdline and that serial HW isn't available on the system.

  Reproduced with:
  4.4 (from Xenial), 4.15 (from Bionic), 5.4 (native, Focal) and 5.7-next 
(mainline)

  Removing the non-existent 'console=ttyS*' parameter fixes the
  situation.

  I tested it using KVM/qemu, but it has been brought to my attention
  that it was reproducible in VMware as well.

  I think it is safe to say that it is unlikely to be specifics to a
  certain virtualization technology type.

  Didn't test on baremetal yet.

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 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

2020-05-21 Thread Eric Desrochers
** Changed in: linux (Ubuntu)
   Status: Confirmed => Incomplete

** Changed in: initramfs-tools (Ubuntu)
   Status: New => Confirmed

** Changed in: initramfs-tools (Ubuntu)
   Importance: Undecided => High

** Changed in: initramfs-tools (Ubuntu)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

-- 
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:
  Confirmed
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  kernel get stucks at boot if console=ttyS* is specified in the kernel
  cmdline and that serial HW isn't available on the system.

  Reproduced with:
  4.4 (from Xenial), 4.15 (from Bionic), 5.4 (native, Focal) and 5.7-next 
(mainline)

  Removing the non-existent 'console=ttyS*' parameter fixes the
  situation.

  I tested it using KVM/qemu, but it has been brought to my attention
  that it was reproducible in VMware as well.

  I think it is safe to say that it is unlikely to be specifics to a
  certain virtualization technology type.

  Didn't test on baremetal yet.

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 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

2020-05-21 Thread Eric Desrochers
** Summary changed:

- kernel get stuck at boot if specified 'console=ttyS* ' doesn't exist.
+ machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

** Also affects: initramfs-tools (Ubuntu)
   Importance: Undecided
   Status: New

-- 
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:
  New
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  kernel get stucks at boot if console=ttyS* is specified in the kernel
  cmdline and that serial HW isn't available on the system.

  Reproduced with:
  4.4 (from Xenial), 4.15 (from Bionic), 5.4 (native, Focal) and 5.7-next 
(mainline)

  Removing the non-existent 'console=ttyS*' parameter fixes the
  situation.

  I tested it using KVM/qemu, but it has been brought to my attention
  that it was reproducible in VMware as well.

  I think it is safe to say that it is unlikely to be specifics to a
  certain virtualization technology type.

  Didn't test on baremetal yet.

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 1875927] Re: add support for phys_port_name attribute in Xenial/16.04LTS

2020-05-21 Thread Eric Desrochers
** Description changed:

  [Impact]
  In Xenial/16.04LTS, one can't generate network interface name from 
"phys_port_name" attribute.
  
  "phys_port_name" indicates the interface physical port name within the
  NIC.
  
  [Test Case]
  
  Check that udev (systemd-udevd) provides the phys_port_name property
  Tests should be done on kernel versions: v4.15 (HWE)
  
  # cat /sys/class/net//phys_port_name
  yyy
  
  Look if interface name contains the 'phys_port_name':
  
  $ ip link show
  
  3: ens3nyyy:  ...
  
  
  [Regression Potential]
  
  * This piece of code is already in place in Bionic (systemd) and late.
  AFAICT, nothing has been reported since then with regards to this feature.
  
  * phys_port_name kernel support has been introduced in v4.1, but none of
  the current v4.4 Xenial kernel drivers uses it (minus rocker which is a
  test bed software switch for devel work on switchdev, it has no real
  function)
  
  # Xenial - kernel v4.4
  config-4.4.0-142-generic:# CONFIG_NET_SWITCHDEV is not set
  
  No drivers uses the phys_port_name method at all + NET_SWITCHDEV is not
  even turned on.
  
  # Xenial HWE - kernel v4.15
  config-4.15.0-99-generic:CONFIG_NET_SWITCHDEV=y
  
  Meaning if a regression arise, it will be limited to the HWE kernel (v4.15) 
and to the "Ethernet switch device driver model (switchdev)":
  mlx5
  mlxsw
  bnxt
  sfc (solarflar)
  
  --
  drivers/net/ethernet:
  --
  broadcom/bnxt/bnxt_vfr.c: .ndo_get_phys_port_name = 
bnxt_vf_rep_get_phys_port_name
  broadcom/bnxt/bnxt.c: .ndo_get_phys_port_name = bnxt_get_phys_port_name
  cavium/liquidio/lio_vf_rep.c: .ndo_get_phys_port_name = 
lio_vf_rep_phys_port_name,
  mellanox/mlx5/core/en_rep.c:  .ndo_get_phys_port_name  = 
mlx5e_rep_get_phys_port_name,
  mellanox/mlxsw/switchx2.c:.ndo_get_phys_port_name = 
mlxsw_sx_port_get_phys_port_name,
  mellanox/mlxsw/spectrum.c:.ndo_get_phys_port_name = 
mlxsw_sp_port_get_phys_port_name,
  netronome/nfp/nfp_net_repr.c: .ndo_get_phys_port_name = 
nfp_port_get_phys_port_name,
  netronome/nfp/nfp_net_common.c:   .ndo_get_phys_port_name = 
nfp_port_get_phys_port_name,
  rocker/rocker_main.c: .ndo_get_phys_port_name = 
rocker_port_get_phys_port_name,
  sfc/efx.c:.ndo_get_phys_port_name = efx_get_phys_port_name,
  --
  
  # On other more specific kernels the regression potential can be
  expanded to virtio-net driver as well.
  
  # cloud-init may taint the result as it renames switchdev(s) after
  systemd at first initialization (even without the phys_port_name
  support) as follows:
  
  (Testing on a sfc card / server deployed by MAAS)
  
  syslog:May 20 22:12:43 OBFUSCATED_HOST kernel: [ 36.199674] sfc :08:00.1 
ens1f1: renamed from eth1 ## systemd
  syslog:May 20 22:12:43 OBFUSCATED_HOST kernel: [ 37.128236] sfc :08:00.0 
ens1f0: renamed from eth0 ## systemd
  
  syslog:May 20 22:12:43 OBFUSCATED_HOST kernel: [ 84.653460] sfc :08:00.0 
ens1f0np0: renamed from ens1f0 ## cloud-init
  syslog:May 20 22:12:43 OBFUSCATED_HOST kernel: [ 84.697177] sfc :08:00.1 
ens1f1np1: renamed from ens1f1 ## cloud-init
  
  cloud-init.log:2020-05-20 22:04:53,980 - util.py[DEBUG]: Running command 
['ip', 'link', 'set', 'ens1f0', 'name', 'ens1f0np0'] with allowed return codes 
[0] (shell=False, capture=True)
  cloud-init.log:2020-05-20 22:04:54,016 - util.py[DEBUG]: Running command 
['ip', 'link', 'set', 'ens1f1', 'name', 'ens1f1np1'] with allowed return codes 
[0] (shell=False, capture=True)
  
+ systemd:
+ ... OBFUSCATED_HOST systemd[1]: sys-subsystem-net-devices-ens1f1.device: Dev 
sys-subsystem-net-devices-ens1f1.device appeared twice with different sysfs 
paths /sys/devices/pci:00/:00:03.0/:08:00.1/net/ens1f1 and 
/sys/devices/pci:00/:00:03.0/:08:00.1/net/ens1f1np1
+ 
  # 1 concern was raise here by ddstreet:
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1875927/comments/1
  
  Here's the result of the test I have performed:
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1875927/comments/5
  
  This change indeed rename existing switchdev interfaces to add the
  'phys_port_name' (if any) into it. I'm afraid this will be a non-
  acceptable behaviour change in stable release and won't be SRU'able.
  
  More discussion on this topic to come 
  
  [Other informations]
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506
  
  [Original Description]
  
  It has been brought to my attention that systemd in Xenial/16.04LTS
  doesn't have support for phys_port_name[0] attribute.
  
  The support has been first introduced in systemd version "232" via:
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506
  
  Bionic and late have the necessary bits ( systemd >232), but not Xenial
  (229)[1]
  
  Support for "phys_port_name" has been first introduced in the kernel
  

[Touch-packages] [Bug 1875927] Re: add support for phys_port_name attribute in Xenial/16.04LTS

2020-05-21 Thread Eric Desrochers
** Description changed:

  [Impact]
  In Xenial/16.04LTS, one can't generate network interface name from 
"phys_port_name" attribute.
  
  "phys_port_name" indicates the interface physical port name within the
  NIC.
  
  [Test Case]
  
  Check that udev (systemd-udevd) provides the phys_port_name property
  Tests should be done on kernel versions: v4.15 (HWE)
  
  # cat /sys/class/net//phys_port_name
  yyy
  
  Look if interface name contains the 'phys_port_name':
  
  $ ip link show
  
  3: ens3nyyy:  ...
  
  
  [Regression Potential]
  
  * This piece of code is already in place in Bionic (systemd) and late.
  AFAICT, nothing has been reported since then with regards to this feature.
  
  * phys_port_name kernel support has been introduced in v4.1, but none of
  the current v4.4 Xenial kernel drivers uses it (minus rocker which is a
  test bed software switch for devel work on switchdev, it has no real
  function)
  
  # Xenial - kernel v4.4
  config-4.4.0-142-generic:# CONFIG_NET_SWITCHDEV is not set
  
  No drivers uses the phys_port_name method at all + NET_SWITCHDEV is not
  even turned on.
  
  # Xenial HWE - kernel v4.15
  config-4.15.0-99-generic:CONFIG_NET_SWITCHDEV=y
  
  Meaning if a regression arise, it will be limited to the HWE kernel (v4.15) 
and to the "Ethernet switch device driver model (switchdev)":
  mlx5
  mlxsw
  bnxt
  sfc (solarflar)
  
  --
  drivers/net/ethernet:
  --
  broadcom/bnxt/bnxt_vfr.c: .ndo_get_phys_port_name = 
bnxt_vf_rep_get_phys_port_name
  broadcom/bnxt/bnxt.c: .ndo_get_phys_port_name = bnxt_get_phys_port_name
  cavium/liquidio/lio_vf_rep.c: .ndo_get_phys_port_name = 
lio_vf_rep_phys_port_name,
  mellanox/mlx5/core/en_rep.c:  .ndo_get_phys_port_name  = 
mlx5e_rep_get_phys_port_name,
  mellanox/mlxsw/switchx2.c:.ndo_get_phys_port_name = 
mlxsw_sx_port_get_phys_port_name,
  mellanox/mlxsw/spectrum.c:.ndo_get_phys_port_name = 
mlxsw_sp_port_get_phys_port_name,
  netronome/nfp/nfp_net_repr.c: .ndo_get_phys_port_name = 
nfp_port_get_phys_port_name,
  netronome/nfp/nfp_net_common.c:   .ndo_get_phys_port_name = 
nfp_port_get_phys_port_name,
  rocker/rocker_main.c: .ndo_get_phys_port_name = 
rocker_port_get_phys_port_name,
  sfc/efx.c:.ndo_get_phys_port_name = efx_get_phys_port_name,
  --
  
  # On other more specific kernels the regression potential can be
  expanded to virtio-net driver as well.
  
  # cloud-init may taint the result as it renames switchdev(s) after
  systemd at first initialization (even without the phys_port_name
  support) as follows:
  
  (Testing on a sfc card / server deployed by MAAS)
  
  syslog:May 20 22:12:43 OBFUSCATED_HOST kernel: [ 36.199674] sfc :08:00.1 
ens1f1: renamed from eth1 ## systemd
  syslog:May 20 22:12:43 OBFUSCATED_HOST kernel: [ 37.128236] sfc :08:00.0 
ens1f0: renamed from eth0 ## systemd
  
  syslog:May 20 22:12:43 OBFUSCATED_HOST kernel: [ 84.653460] sfc :08:00.0 
ens1f0np0: renamed from ens1f0 ## cloud-init
  syslog:May 20 22:12:43 OBFUSCATED_HOST kernel: [ 84.697177] sfc :08:00.1 
ens1f1np1: renamed from ens1f1 ## cloud-init
  
  cloud-init.log:2020-05-20 22:04:53,980 - util.py[DEBUG]: Running command 
['ip', 'link', 'set', 'ens1f0', 'name', 'ens1f0np0'] with allowed return codes 
[0] (shell=False, capture=True)
  cloud-init.log:2020-05-20 22:04:54,016 - util.py[DEBUG]: Running command 
['ip', 'link', 'set', 'ens1f1', 'name', 'ens1f1np1'] with allowed return codes 
[0] (shell=False, capture=True)
  
- **
- Concern:
+ # 1 concern was raise here by ddstreet:
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1875927/comments/1
  
- Result:
+ Here's the result of the test I have performed:
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1875927/comments/5
- **
  
  [Other informations]
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506
  
  [Original Description]
  
  It has been brought to my attention that systemd in Xenial/16.04LTS
  doesn't have support for phys_port_name[0] attribute.
  
  The support has been first introduced in systemd version "232" via:
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506
  
  Bionic and late have the necessary bits ( systemd >232), but not Xenial
  (229)[1]
  
  Support for "phys_port_name" has been first introduced in the kernel
  with v4.1[2]
  
  [0]
  - https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
  - 
https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
  - https://www.kernel.org/doc/Documentation/networking/switchdev.txt
  
  [1]
  # git systemd/systemd
  git describe --contains 4887b656c22af059d4e833de7b56544f24951184
  v232~15
  
  # rmadison
   => systemd | 229-4ubuntu21.27 | xenial-updates
   systemd | 237-3ubuntu10.39 | bionic-updates
   systemd | 240-6ubuntu5.8   | disco-updates
   systemd | 

[Touch-packages] [Bug 1878723] Re: Kernel panic when used with upstart after 0.11-4ubuntu2.1 update

2020-05-15 Thread Eric Desrochers
** Changed in: json-c (Ubuntu)
   Status: Fix Released => Triaged

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

Title:
  Kernel panic when used with upstart after 0.11-4ubuntu2.1 update

Status in json-c package in Ubuntu:
  Triaged

Bug description:
  Installing the 0.11-4ubuntu2.1 security update on a Xenial system with
  upstart installed, the system crashes with a kernel panic.

  The error message is:

  [   99.992278] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x0100
  [   99.992278] 
  [   99.996057] CPU: 0 PID: 1 Comm: init Not tainted 4.4.0-1105-aws #116-Ubuntu
  [   99.996057] Hardware name: Xen HVM domU, BIOS 4.2.amazon 08/24/2006
  [   99.996057]  0086 0f10ff6977efbf32 88003d45fe10 
8140926b
  [   99.996057]  81caddf8 88003d45fea8 88003d45fe98 
81195a84
  [   99.996057]  8810 88003d45fea8 88003d45fe40 
0f10ff6977efbf32
  [   99.996057] Call Trace:
  [   99.996057]  [] dump_stack+0x6d/0x92
  [   99.996057]  [] panic+0xd3/0x227
  [   99.996057]  [] do_exit+0xb9d/0xba0
  [   99.996057]  [] do_group_exit+0x47/0xb0
  [   99.996057]  [] SyS_exit_group+0x14/0x20
  [   99.996057]  [] entry_SYSCALL_64_fastpath+0x22/0xcb
  [   99.996057] Kernel Offset: disabled

  Downgrading to libjson-c2_0.11-4ubuntu2 resolves the issue.

  Steps to reproduce:
  * Create a system with Xenial installed (I'm using an AWS instance with AMI 
ami-0f2ed58082cb08a4d)
  * Install upstart: apt-get install upstart-sysv
  * Reboot
  * Update apt and upgrade the packages: apt-get update && apt-get upgrade . 
This causes the kernel panic.
  * To repeat the kernel panic, run dpkg --configure -a

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/json-c/+bug/1878723/+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 1875927] Re: add support for phys_port_name attribute in Xenial/16.04LTS

2020-05-12 Thread Eric Desrochers
** Description changed:

  [Impact]
  In Xenial/16.04LTS, one can't generate network interface name from 
"phys_port_name" attribute.
  
  "phys_port_name" indicates the interface physical port name within the
  NIC.
  
  [Test Case]
  
  Check that udev (systemd-udevd) provides the phys_port_name property
  Tests should be done on kernel versions: v4.15 (HWE)
+ 
+ # cat /sys/class/net//phys_port_name
+ yyy
+ 
+ Look if interface name contains the 'phys_port_name':
+ 
+ $ ip link show
+ 
+ 3: ens3nyyy:  ...
+ 
  
  [Regression Potential]
  
  * This piece of code is already in place in Bionic (systemd) and late.
  AFAICT, nothing has been reported since then with regards to this feature.
  
  * phys_port_name kernel support has been introduced in v4.1, but none of
  the current v4.4 Xenial kernel drivers uses it (minus rocker which is a
  test bed software switch for devel work on switchdev, it has no real
  function)
  
  # Xenial - kernel v4.4
  config-4.4.0-142-generic:# CONFIG_NET_SWITCHDEV is not set
  
  No drivers uses the phys_port_name method at all + NET_SWITCHDEV is not
  even turned on.
  
  # Xenial HWE - kernel v4.15
  config-4.15.0-99-generic:CONFIG_NET_SWITCHDEV=y
  
  Meaning if a regression arise, it will be limited to the HWE kernel (v4.15) 
and to the "Ethernet switch device driver model (switchdev)":
  mlx5
  mlxsw
  bnxt
  sfc (solarflar)
  
  --
  drivers/net/ethernet:
  --
  broadcom/bnxt/bnxt_vfr.c: .ndo_get_phys_port_name = 
bnxt_vf_rep_get_phys_port_name
  broadcom/bnxt/bnxt.c: .ndo_get_phys_port_name = bnxt_get_phys_port_name
  cavium/liquidio/lio_vf_rep.c: .ndo_get_phys_port_name = 
lio_vf_rep_phys_port_name,
  mellanox/mlx5/core/en_rep.c:  .ndo_get_phys_port_name  = 
mlx5e_rep_get_phys_port_name,
  mellanox/mlxsw/switchx2.c:.ndo_get_phys_port_name = 
mlxsw_sx_port_get_phys_port_name,
  mellanox/mlxsw/spectrum.c:.ndo_get_phys_port_name = 
mlxsw_sp_port_get_phys_port_name,
  netronome/nfp/nfp_net_repr.c: .ndo_get_phys_port_name = 
nfp_port_get_phys_port_name,
  netronome/nfp/nfp_net_common.c:   .ndo_get_phys_port_name = 
nfp_port_get_phys_port_name,
  rocker/rocker_main.c: .ndo_get_phys_port_name = 
rocker_port_get_phys_port_name,
  sfc/efx.c:.ndo_get_phys_port_name = efx_get_phys_port_name,
  --
  
  **
  One item I'm currently testing is ddstreet's comment:
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1875927/comments/1
  **
  
  [Other informations]
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506
  
  [Original Description]
  
  It has been brought to my attention that systemd in Xenial/16.04LTS
  doesn't have support for phys_port_name[0] attribute.
  
  The support has been first introduced in systemd version "232" via:
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506
  
  Bionic and late have the necessary bits ( systemd >232), but not Xenial
  (229)[1]
  
  Support for "phys_port_name" has been first introduced in the kernel
  with v4.1[2]
  
  [0]
  - https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
  - 
https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
  - https://www.kernel.org/doc/Documentation/networking/switchdev.txt
  
  [1]
  # git systemd/systemd
  git describe --contains 4887b656c22af059d4e833de7b56544f24951184
  v232~15
  
  # rmadison
   => systemd | 229-4ubuntu21.27 | xenial-updates
   systemd | 237-3ubuntu10.39 | bionic-updates
   systemd | 240-6ubuntu5.8   | disco-updates
   systemd | 242-7ubuntu3.7   | eoan-updates
   systemd | 245.4-4ubuntu3   | focal
   systemd | 245.4-4ubuntu3   | groovy
  
  [2]
  https://github.com/torvalds/linux/commit/db24a9044ee1
  
  $ git describe --contains db24a9044ee1
  v4.1-rc1

** Description changed:

  [Impact]
  In Xenial/16.04LTS, one can't generate network interface name from 
"phys_port_name" attribute.
  
  "phys_port_name" indicates the interface physical port name within the
  NIC.
  
  [Test Case]
  
  Check that udev (systemd-udevd) provides the phys_port_name property
  Tests should be done on kernel versions: v4.15 (HWE)
  
  # cat /sys/class/net//phys_port_name
  yyy
  
  Look if interface name contains the 'phys_port_name':
  
  $ ip link show
  
  3: ens3nyyy:  ...
  
  
  [Regression Potential]
  
  * This piece of code is already in place in Bionic (systemd) and late.
  AFAICT, nothing has been reported since then with regards to this feature.
  
  * phys_port_name kernel support has been introduced in v4.1, but none of
  the current v4.4 Xenial kernel drivers uses it (minus rocker which is a
  test bed software switch for devel work on switchdev, it has no real
  function)
  
  # Xenial - kernel v4.4
  config-4.4.0-142-generic:# CONFIG_NET_SWITCHDEV is not set
  
  No drivers uses the phys_port_name method at all + NET_SWITCHDEV is not

[Touch-packages] [Bug 1875927] Re: add support for phys_port_name attribute in Xenial/16.04LTS

2020-05-12 Thread Eric Desrochers
** Description changed:

  [Impact]
  In Xenial/16.04LTS, one can't generate network interface name from 
"phys_port_name" attribute.
  
  "phys_port_name" indicates the interface physical port name within the
  NIC.
  
  [Test Case]
  
  Check that udev (systemd-udevd) provides the phys_port_name property
- Tests should be done on both kernel versions: v4.4 and v4.15
+ Tests should be done on kernel versions: v4.15 (HWE)
  
  [Regression Potential]
  
  Risk: Low
  * This piece of code is already in place in Bionic (systemd) and late.
  AFAICT, nothing has been reported since then with regards to this feature.
  
- * phys_port_name kernel support has been introduced in v4.1. Xenial
- supported kernel are : v4.4 and v4.15 (HWE).
+ * phys_port_name kernel support has been introduced in v4.1, but none of
+ the current v4.4 Xenial kernel drivers uses it (minus rocker which is a
+ test bed software switch for devel work on switchdev, it has no real
+ function)
  
- * If a regression arise, it will most likely be limited to the "Ethernet
- switch device driver model (switchdev)" reported by: rocker, mlxsw,
- broadcom, ...
+ # Xenial - kernel v4.4 
+ config-4.4.0-142-generic:# CONFIG_NET_SWITCHDEV is not set
+ 
+ No drivers uses the phys_port_name method at all + NET_SWITCHDEV is not
+ even turned on.
+ 
+ # Xenial HWE - kernel v4.15 
+ config-4.15.0-99-generic:CONFIG_NET_SWITCHDEV=y
+ 
+ Meaning if a regression arise, it will be limited to the HWE kernel (v4.15) 
and to the "Ethernet switch device driver model (switchdev)":
+ mlx5
+ mlxsw
+ bnxt
+ 
+ --
+ drivers/net/ethernet/mellanox/mlx5/core/en_rep.c: .ndo_get_phys_port_name 
 = mlx5e_rep_get_phys_port_name,
+ drivers/net/ethernet/mellanox/mlxsw/switchx2.c:   .ndo_get_phys_port_name 
= mlxsw_sx_port_get_phys_port_name,
+ drivers/net/ethernet/mellanox/mlxsw/spectrum.c:   .ndo_get_phys_port_name 
= mlxsw_sp_port_get_phys_port_name,
+ drivers/net/ethernet/sfc/efx.c:   .ndo_get_phys_port_name = 
efx_get_phys_port_name,
+ drivers/net/ethernet/broadcom/bnxt/bnxt_vfr.c:.ndo_get_phys_port_name 
= bnxt_vf_rep_get_phys_port_name
+ drivers/net/ethernet/broadcom/bnxt/bnxt.c:.ndo_get_phys_port_name = 
bnxt_get_phys_port_name
+ drivers/net/ethernet/rocker/rocker_main.c:.ndo_get_phys_port_name 
= rocker_port_get_phys_port_name,
+ drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c:.ndo_get_phys_port_name 
= lio_vf_rep_phys_port_name,
+ drivers/net/ethernet/netronome/nfp/nfp_net_repr.c:.ndo_get_phys_port_name 
= nfp_port_get_phys_port_name,
+ drivers/net/ethernet/netronome/nfp/nfp_net_common.c:  .ndo_get_phys_port_name 
= nfp_port_get_phys_port_name,
+ 
+ --
+ 
+ ** 
+ One item I'm currently testing is ddstreet's comment:
+ https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1875927/comments/1
+ **
  
  [Other informations]
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506
  
  [Original Description]
  
  It has been brought to my attention that systemd in Xenial/16.04LTS
  doesn't have support for phys_port_name[0] attribute.
  
  The support has been first introduced in systemd version "232" via:
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506
  
  Bionic and late have the necessary bits ( systemd >232), but not Xenial
  (229)[1]
  
  Support for "phys_port_name" has been first introduced in the kernel
  with v4.1[2]
  
  [0]
  - https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
  - 
https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
  - https://www.kernel.org/doc/Documentation/networking/switchdev.txt
  
  [1]
  # git systemd/systemd
  git describe --contains 4887b656c22af059d4e833de7b56544f24951184
  v232~15
  
  # rmadison
   => systemd | 229-4ubuntu21.27 | xenial-updates
   systemd | 237-3ubuntu10.39 | bionic-updates
   systemd | 240-6ubuntu5.8   | disco-updates
   systemd | 242-7ubuntu3.7   | eoan-updates
   systemd | 245.4-4ubuntu3   | focal
   systemd | 245.4-4ubuntu3   | groovy
  
  [2]
  https://github.com/torvalds/linux/commit/db24a9044ee1
  
  $ git describe --contains db24a9044ee1
  v4.1-rc1

** Description changed:

  [Impact]
  In Xenial/16.04LTS, one can't generate network interface name from 
"phys_port_name" attribute.
  
  "phys_port_name" indicates the interface physical port name within the
  NIC.
  
  [Test Case]
  
  Check that udev (systemd-udevd) provides the phys_port_name property
  Tests should be done on kernel versions: v4.15 (HWE)
  
  [Regression Potential]
  
  Risk: Low
  * This piece of code is already in place in Bionic (systemd) and late.
  AFAICT, nothing has been reported since then with regards to this feature.
  
  * phys_port_name kernel support has been introduced in v4.1, but none of
  the current v4.4 Xenial kernel drivers uses it (minus rocker which is a
  test bed 

[Touch-packages] [Bug 1875927] Re: add support for phys_port_name attribute in Xenial/16.04LTS

2020-05-06 Thread Eric Desrochers
https://git.centos.org/rpms/systemd/c/83b94d10951d79445f7975bff835a88261c11a4e?branch=83b94d10951d79445f7975bff835a88261c11a4e

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

Title:
  add support for phys_port_name attribute in Xenial/16.04LTS

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  In Progress

Bug description:
  [Impact]
  In Xenial/16.04LTS, one can't generate network interface name from 
"phys_port_name" attribute.

  "phys_port_name" indicates the interface physical port name within the
  NIC.

  [Test Case]

  Check that udev (systemd-udevd) provides the phys_port_name property
  Tests should be done on both kernel versions: v4.4 and v4.15

  [Regression Potential]

  Risk: Low
  * This piece of code is already in place in Bionic (systemd) and late.
  AFAICT, nothing has been reported since then with regards to this feature.

  * phys_port_name kernel support has been introduced in v4.1. Xenial
  supported kernel are : v4.4 and v4.15 (HWE).

  * If a regression arise, it will most likely be limited to the
  "Ethernet switch device driver model (switchdev)" reported by: rocker,
  mlxsw, broadcom, ...

  [Other informations]
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506

  [Original Description]

  It has been brought to my attention that systemd in Xenial/16.04LTS
  doesn't have support for phys_port_name[0] attribute.

  The support has been first introduced in systemd version "232" via:
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506

  Bionic and late have the necessary bits ( systemd >232), but not
  Xenial (229)[1]

  Support for "phys_port_name" has been first introduced in the kernel
  with v4.1[2]

  [0]
  - https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
  - 
https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
  - https://www.kernel.org/doc/Documentation/networking/switchdev.txt

  [1]
  # git systemd/systemd
  git describe --contains 4887b656c22af059d4e833de7b56544f24951184
  v232~15

  # rmadison
   => systemd | 229-4ubuntu21.27 | xenial-updates
   systemd | 237-3ubuntu10.39 | bionic-updates
   systemd | 240-6ubuntu5.8   | disco-updates
   systemd | 242-7ubuntu3.7   | eoan-updates
   systemd | 245.4-4ubuntu3   | focal
   systemd | 245.4-4ubuntu3   | groovy

  [2]
  https://github.com/torvalds/linux/commit/db24a9044ee1

  $ git describe --contains db24a9044ee1
  v4.1-rc1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1875927/+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 1875927] Re: add support for phys_port_name attribute in Xenial/16.04LTS

2020-05-06 Thread Eric Desrochers
Centos had to revert the patch in their systemd package via:
commit 83b94d10951d79445f7975bff835a88261c11a4e 

SOURCES/0499-Revert-udev-net_id-add-support-for-phys_port_name-at.patch


They workaround (differing from upstream) the regression installing script and 
udev rule to add phys_port_name for mlxsw and rocker drivers and put them in 
dracut.

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

Title:
  add support for phys_port_name attribute in Xenial/16.04LTS

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  In Progress

Bug description:
  [Impact]
  In Xenial/16.04LTS, one can't generate network interface name from 
"phys_port_name" attribute.

  "phys_port_name" indicates the interface physical port name within the
  NIC.

  [Test Case]

  Check that udev (systemd-udevd) provides the phys_port_name property
  Tests should be done on both kernel versions: v4.4 and v4.15

  [Regression Potential]

  Risk: Low
  * This piece of code is already in place in Bionic (systemd) and late.
  AFAICT, nothing has been reported since then with regards to this feature.

  * phys_port_name kernel support has been introduced in v4.1. Xenial
  supported kernel are : v4.4 and v4.15 (HWE).

  * If a regression arise, it will most likely be limited to the
  "Ethernet switch device driver model (switchdev)" reported by: rocker,
  mlxsw, broadcom, ...

  [Other informations]
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506

  [Original Description]

  It has been brought to my attention that systemd in Xenial/16.04LTS
  doesn't have support for phys_port_name[0] attribute.

  The support has been first introduced in systemd version "232" via:
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506

  Bionic and late have the necessary bits ( systemd >232), but not
  Xenial (229)[1]

  Support for "phys_port_name" has been first introduced in the kernel
  with v4.1[2]

  [0]
  - https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
  - 
https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
  - https://www.kernel.org/doc/Documentation/networking/switchdev.txt

  [1]
  # git systemd/systemd
  git describe --contains 4887b656c22af059d4e833de7b56544f24951184
  v232~15

  # rmadison
   => systemd | 229-4ubuntu21.27 | xenial-updates
   systemd | 237-3ubuntu10.39 | bionic-updates
   systemd | 240-6ubuntu5.8   | disco-updates
   systemd | 242-7ubuntu3.7   | eoan-updates
   systemd | 245.4-4ubuntu3   | focal
   systemd | 245.4-4ubuntu3   | groovy

  [2]
  https://github.com/torvalds/linux/commit/db24a9044ee1

  $ git describe --contains db24a9044ee1
  v4.1-rc1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1875927/+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 1875927] Re: add support for phys_port_name attribute in Xenial/16.04LTS

2020-05-05 Thread Eric Desrochers
Right, @ddstreet it's a very good point to validate/verify. 
Definitely worth looking at that aspect pre-SRU.

Bionic and late has the fix since release time ... meaning that patch
has never been introduced via SRU yet.

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

Title:
  add support for phys_port_name attribute in Xenial/16.04LTS

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  In Progress

Bug description:
  [Impact]
  In Xenial/16.04LTS, one can't generate network interface name from 
"phys_port_name" attribute.

  "phys_port_name" indicates the interface physical port name within the
  NIC.

  [Test Case]

  Check that udev (systemd-udevd) provides the phys_port_name property
  Tests should be done on both kernel versions: v4.4 and v4.15

  [Regression Potential]

  Risk: Low
  * This piece of code is already in place in Bionic (systemd) and late.
  AFAICT, nothing has been reported since then with regards to this feature.

  * phys_port_name kernel support has been introduced in v4.1. Xenial
  supported kernel are : v4.4 and v4.15 (HWE).

  * If a regression arise, it will most likely be limited to the
  "Ethernet switch device driver model (switchdev)" reported by: rocker,
  mlxsw, broadcom, ...

  [Other informations]
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506

  [Original Description]

  It has been brought to my attention that systemd in Xenial/16.04LTS
  doesn't have support for phys_port_name[0] attribute.

  The support has been first introduced in systemd version "232" via:
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506

  Bionic and late have the necessary bits ( systemd >232), but not
  Xenial (229)[1]

  Support for "phys_port_name" has been first introduced in the kernel
  with v4.1[2]

  [0]
  - https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
  - 
https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
  - https://www.kernel.org/doc/Documentation/networking/switchdev.txt

  [1]
  # git systemd/systemd
  git describe --contains 4887b656c22af059d4e833de7b56544f24951184
  v232~15

  # rmadison
   => systemd | 229-4ubuntu21.27 | xenial-updates
   systemd | 237-3ubuntu10.39 | bionic-updates
   systemd | 240-6ubuntu5.8   | disco-updates
   systemd | 242-7ubuntu3.7   | eoan-updates
   systemd | 245.4-4ubuntu3   | focal
   systemd | 245.4-4ubuntu3   | groovy

  [2]
  https://github.com/torvalds/linux/commit/db24a9044ee1

  $ git describe --contains db24a9044ee1
  v4.1-rc1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1875927/+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 1875927] Re: add support for phys_port_name attribute in Xenial/16.04LTS

2020-04-29 Thread Eric Desrochers
** Description changed:

+ [Impact]
+ In Xenial/16.04LTS, one can't generate network interface name from 
"phys_port_name" attribute.
+ 
+ "phys_port_name" indicates the interface physical port name within the
+ NIC.
+ 
+ [Test Case]
+ 
+ Check that udev (systemd-udevd) provides the phys_port_name property
+ Tests should be done on both kernel versions: v4.4 and v4.15
+ 
+ [Regression Potential]
+ 
+ Risk: Low
+ * This piece of code is already in place in Bionic (systemd) and late.
+ AFAICT, nothing has been reported since then with regards to this feature.
+ 
+ * phys_port_name kernel support has been introduced in v4.1. Xenial
+ supported kernel are : v4.4 and v4.15 (HWE).
+ 
+ * If a regression arise, it will most likely be limited to the "Ethernet
+ switch device driver model (switchdev)" reported by: rocker, mlxsw,
+ broadcom, ...
+ 
+ [Other informations]
+ 
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
+ https://github.com/systemd/systemd/pull/4506
+ 
+ [Original Description]
+ 
  It has been brought to my attention that systemd in Xenial/16.04LTS
  doesn't have support for phys_port_name[0] attribute.
  
  The support has been first introduced in systemd version "232" via:
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506
  
  Bionic and late have the necessary bits ( systemd >232), but not Xenial
  (229)[1]
  
  Support for "phys_port_name" has been first introduced in the kernel
  with v4.1[2]
  
  [0]
  - https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
  - 
https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
  - https://www.kernel.org/doc/Documentation/networking/switchdev.txt
  
  [1]
  # git systemd/systemd
  git describe --contains 4887b656c22af059d4e833de7b56544f24951184
  v232~15
  
  # rmadison
   => systemd | 229-4ubuntu21.27 | xenial-updates
   systemd | 237-3ubuntu10.39 | bionic-updates
   systemd | 240-6ubuntu5.8   | disco-updates
   systemd | 242-7ubuntu3.7   | eoan-updates
   systemd | 245.4-4ubuntu3   | focal
   systemd | 245.4-4ubuntu3   | groovy
  
  [2]
  https://github.com/torvalds/linux/commit/db24a9044ee1
  
  $ git describe --contains db24a9044ee1
  v4.1-rc1

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

Title:
  add support for phys_port_name attribute in Xenial/16.04LTS

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  In Progress

Bug description:
  [Impact]
  In Xenial/16.04LTS, one can't generate network interface name from 
"phys_port_name" attribute.

  "phys_port_name" indicates the interface physical port name within the
  NIC.

  [Test Case]

  Check that udev (systemd-udevd) provides the phys_port_name property
  Tests should be done on both kernel versions: v4.4 and v4.15

  [Regression Potential]

  Risk: Low
  * This piece of code is already in place in Bionic (systemd) and late.
  AFAICT, nothing has been reported since then with regards to this feature.

  * phys_port_name kernel support has been introduced in v4.1. Xenial
  supported kernel are : v4.4 and v4.15 (HWE).

  * If a regression arise, it will most likely be limited to the
  "Ethernet switch device driver model (switchdev)" reported by: rocker,
  mlxsw, broadcom, ...

  [Other informations]
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506

  [Original Description]

  It has been brought to my attention that systemd in Xenial/16.04LTS
  doesn't have support for phys_port_name[0] attribute.

  The support has been first introduced in systemd version "232" via:
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506

  Bionic and late have the necessary bits ( systemd >232), but not
  Xenial (229)[1]

  Support for "phys_port_name" has been first introduced in the kernel
  with v4.1[2]

  [0]
  - https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
  - 
https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
  - https://www.kernel.org/doc/Documentation/networking/switchdev.txt

  [1]
  # git systemd/systemd
  git describe --contains 4887b656c22af059d4e833de7b56544f24951184
  v232~15

  # rmadison
   => systemd | 229-4ubuntu21.27 | xenial-updates
   systemd | 237-3ubuntu10.39 | bionic-updates
   systemd | 240-6ubuntu5.8   | disco-updates
   systemd | 242-7ubuntu3.7   | eoan-updates
   systemd | 245.4-4ubuntu3   | focal
   systemd | 245.4-4ubuntu3   | groovy

  [2]
  https://github.com/torvalds/linux/commit/db24a9044ee1

  $ git describe --contains db24a9044ee1
  v4.1-rc1

To manage notifications about this bug go to:

[Touch-packages] [Bug 1875927] Re: add support for phys_port_name attribute in Xenial/16.04LTS

2020-04-29 Thread Eric Desrochers
** Description changed:

  It has been brought to my attention that systemd in Xenial/16.04LTS
  doesn't have support for phys_port_name[0] attribute.
  
  The support has been first introduced in systemd version "232" via:
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506
  
  Bionic and late have the necessary bits ( systemd >232), but not Xenial
  (229)[1]
+ 
+ Support for "phys_port_name" has been first introduced in the kernel
+ with v4.1[2]
  
  [0]
  - https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
  - 
https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
  - https://www.kernel.org/doc/Documentation/networking/switchdev.txt
  
  [1]
  # git systemd/systemd
  git describe --contains 4887b656c22af059d4e833de7b56544f24951184
  v232~15
  
  # rmadison
   => systemd | 229-4ubuntu21.27 | xenial-updates
   systemd | 237-3ubuntu10.39 | bionic-updates
   systemd | 240-6ubuntu5.8   | disco-updates
   systemd | 242-7ubuntu3.7   | eoan-updates
   systemd | 245.4-4ubuntu3   | focal
   systemd | 245.4-4ubuntu3   | groovy
+ 
+ [2]
+ https://github.com/torvalds/linux/commit/db24a9044ee1
+ 
+ $ git describe --contains db24a9044ee1
+ v4.1-rc1

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

Title:
  add support for phys_port_name attribute in Xenial/16.04LTS

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  In Progress

Bug description:
  It has been brought to my attention that systemd in Xenial/16.04LTS
  doesn't have support for phys_port_name[0] attribute.

  The support has been first introduced in systemd version "232" via:
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506

  Bionic and late have the necessary bits ( systemd >232), but not
  Xenial (229)[1]

  Support for "phys_port_name" has been first introduced in the kernel
  with v4.1[2]

  [0]
  - https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
  - 
https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
  - https://www.kernel.org/doc/Documentation/networking/switchdev.txt

  [1]
  # git systemd/systemd
  git describe --contains 4887b656c22af059d4e833de7b56544f24951184
  v232~15

  # rmadison
   => systemd | 229-4ubuntu21.27 | xenial-updates
   systemd | 237-3ubuntu10.39 | bionic-updates
   systemd | 240-6ubuntu5.8   | disco-updates
   systemd | 242-7ubuntu3.7   | eoan-updates
   systemd | 245.4-4ubuntu3   | focal
   systemd | 245.4-4ubuntu3   | groovy

  [2]
  https://github.com/torvalds/linux/commit/db24a9044ee1

  $ git describe --contains db24a9044ee1
  v4.1-rc1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1875927/+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 1875927] [NEW] add support for phys_port_name attribute in Xenial/16.04LTS

2020-04-29 Thread Eric Desrochers
Public bug reported:

It has been brought to my attention that systemd in Xenial/16.04LTS
doesn't have support for phys_port_name[0] attribute.

The support has been first introduced in systemd version "232" via:
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
https://github.com/systemd/systemd/pull/4506

Bionic and late have the necessary bits ( systemd >232), but not Xenial
(229)[1]

Support for "phys_port_name" has been first introduced in the kernel
with v4.1[2]

[0]
- https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
- 
https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
- https://www.kernel.org/doc/Documentation/networking/switchdev.txt

[1]
# git systemd/systemd
git describe --contains 4887b656c22af059d4e833de7b56544f24951184
v232~15

# rmadison
 => systemd | 229-4ubuntu21.27 | xenial-updates
 systemd | 237-3ubuntu10.39 | bionic-updates
 systemd | 240-6ubuntu5.8   | disco-updates
 systemd | 242-7ubuntu3.7   | eoan-updates
 systemd | 245.4-4ubuntu3   | focal
 systemd | 245.4-4ubuntu3   | groovy

[2]
https://github.com/torvalds/linux/commit/db24a9044ee1

$ git describe --contains db24a9044ee1
v4.1-rc1

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: systemd (Ubuntu Xenial)
 Importance: Medium
 Assignee: Eric Desrochers (slashd)
 Status: In Progress


** Tags: sts

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

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

** Tags added: sts

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

** Changed in: systemd (Ubuntu Xenial)
     Assignee: (unassigned) => Eric Desrochers (slashd)

** Changed in: systemd (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: systemd (Ubuntu Xenial)
   Status: Confirmed => In Progress

** Description changed:

  It has been brought to my attention that systemd in Xenial/16.04LTS
  doesn't have support for phys_port_name[0] attribute.
  
  The support has been first introduced in systemd version "232" via:
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
+ https://github.com/systemd/systemd/pull/4506
  
  Bionic and late have the necessary bits ( systemd >232), but not Xenial
  (229).
  
- [0] 
+ [0]
  - https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
  - 
https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html

** Description changed:

  It has been brought to my attention that systemd in Xenial/16.04LTS
  doesn't have support for phys_port_name[0] attribute.
  
  The support has been first introduced in systemd version "232" via:
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506
  
  Bionic and late have the necessary bits ( systemd >232), but not Xenial
- (229).
+ (229)[1]
  
  [0]
  - https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
  - 
https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
+ 
+ [1]
+ # git systemd/systemd
+ git describe --contains 4887b656c22af059d4e833de7b56544f24951184
+ v232~15
+ 
+ # rmadison
+  => systemd | 229-4ubuntu21.27 | xenial-updates  
+  systemd | 237-3ubuntu10.39 | bionic-updates  
+  systemd | 240-6ubuntu5.8   | disco-updates   
+  systemd | 242-7ubuntu3.7   | eoan-updates
+  systemd | 245.4-4ubuntu3   | focal  
+  systemd | 245.4-4ubuntu3   | groovy

** Description changed:

  It has been brought to my attention that systemd in Xenial/16.04LTS
  doesn't have support for phys_port_name[0] attribute.
  
  The support has been first introduced in systemd version "232" via:
  
https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184
  https://github.com/systemd/systemd/pull/4506
  
  Bionic and late have the necessary bits ( systemd >232), but not Xenial
  (229)[1]
  
  [0]
  - https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
  - 
https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
+ - https://www.kernel.org/doc/Documentation/networking/switchdev.txt
  
  [1]
  # git systemd/systemd
  git describe --contains 4887b656c22af059d4e833de7b56544f24951184
  v232~15
  
  # rmadison
-  => systemd | 229-4ubuntu21.27 | xenial-updates  
-  systemd | 237-3ubuntu10.39 | bionic-updates  
-  systemd | 240-6ubuntu5.8   | disco-updates   
-  systemd | 242-7ubuntu3.7   | eoan-updates
-  systemd | 245.4-4ubuntu3   | focal  
-  systemd | 245.4-4ubuntu3   | groovy
+  => systemd | 229-4ubuntu21.27 | xenial-updates
+  systemd | 237-3ubuntu10.39 | bionic-updates
+  systemd | 240-6ubuntu5.8   | disco-updates
+  systemd | 242-7ubuntu3.7   | eoan-updates
+  systemd | 245.4-4ubuntu3   | focal
+

[Touch-packages] [Bug 1870585] Re: Not cleaning /var/tmp by default

2020-04-11 Thread Eric Desrochers
** Tags added: sosreport 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/1870585

Title:
  Not cleaning /var/tmp by default

Status in systemd package in Ubuntu:
  New

Bug description:
  1) 20.04
  2) 245.2-1ubuntu2
  3) I expect /var/tmp to be cleaned up in some way.
  4) It's commented out per 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773313

  In sosreport was comparing the difference between /tmp (Ubuntu/Debian)
  and /var/tmp (RH) and determined that as long as /var/tmp gets cleaned
  on a regular basis we would prefer /var/tmp.

  The  bug that appears to have prompted the disabling was fixed a long
  time ago, can we have this 30d delete re-enabled by default?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1870585/+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 1863414] Re: Have many "/usr/lib/python3.8/subprocess.py:838: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used" o

2020-02-26 Thread Eric Desrochers
** Tags added: champagne

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

Title:
  Have many "/usr/lib/python3.8/subprocess.py:838: RuntimeWarning: line
  buffering (buffering=1) isn't supported in binary mode, the default
  buffer size will be used" on simple APT usage

Status in python3-defaults package in Ubuntu:
  Confirmed
Status in python3.8 package in Ubuntu:
  Won't Fix

Bug description:
  Steps to reproduce:
  1. Have Ubuntu 20.04 LTS installed
  2. Run regular APT task such as `sudo apt dist-upgrade`
  3. Wait it to finish

  Expected results:
  * APT runs without any warnings and/or errors

  Actual results:
  * APT runs with many python-related warnings like

  >```
  >/usr/lib/python3.8/subprocess.py:838: RuntimeWarning: line buffering 
(buffering=1) isn't supported >in binary mode, the default buffer size will be 
used
  >  self.stdin = io.open(p2cwrite, 'wb', bufsize)
  >
  >```

  Full output below:

  ```
  $ sudo apt dist-upgrade 
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Calculating upgrade... Done
  The following packages were automatically installed and are no longer 
required:
ruby-json ruby-pg ruby-sequel ruby-sequel-pg
  Use 'sudo apt autoremove' to remove them.
  The following NEW packages will be installed:
kdevelop55-libs libxentoolcore1 ubuntu-mate-wallpapers-focal
  The following packages will be upgraded:
atril atril-common debootstrap dmeventd dmsetup dnsmasq-base engrampa 
engrampa-common fwupd fwupd-signed gir1.2-atrildocument-1.5.0
gir1.2-atrilview-1.5.0 gir1.2-freedesktop gir1.2-glib-2.0 gir1.2-pluma-1.0 
initramfs-tools initramfs-tools-bin initramfs-tools-core
iproute2 isc-dhcp-client isc-dhcp-common jekyll k3b k3b-data k3b-i18n 
kdevelop kdevelop-data libatrildocument-dev libatrildocument3
libatrilview-dev libatrilview3 libdevmapper-event1.02.1 libdevmapper1.02.1 
libdistro-info-perl libfwupd2 libfwupdplugin1
libgirepository-1.0-1 libk3b7 libk3b7-extracodecs liblvm2cmd2.03 
libmate-sensors-applet-plugin-dev libmate-sensors-applet-plugin0
libmate-slab0 libmate-window-settings-dev libmate-window-settings1 
libmatedict-dev libmatedict6 libmysqlclient21 libmysqlclient21:i386
libvirt-clients libvirt-daemon libvirt-daemon-driver-qemu 
libvirt-daemon-driver-storage-rbd libvirt-daemon-system
libvirt-daemon-system-systemd libvirt0 libxenstore3.0 
libxmlgraphics-commons-java lvm2 mate-applets mate-applets-common mate-common
mate-control-center mate-control-center-common mate-core 
mate-desktop-environment mate-desktop-environment-core
mate-desktop-environment-extra mate-desktop-environment-extras 
mate-dock-applet mate-media mate-media-common mate-netbook
mate-netbook-common mate-notification-daemon 
mate-notification-daemon-common mate-power-manager mate-power-manager-common
mate-screensaver mate-screensaver-common mate-sensors-applet 
mate-sensors-applet-common mate-sensors-applet-nvidia mate-system-monitor
mate-system-monitor-common mate-terminal mate-terminal-common 
mate-user-share mate-user-share-common mate-utils mate-utils-common maxima
maxima-doc maxima-share mozo nano pluma pluma-common pluma-dev pluma-doc 
plymouth-theme-ubuntu-mate-logo plymouth-theme-ubuntu-mate-text
python-caja-common python3-caja python3-distro-info python3-macaroonbakery 
qemu-block-extra qemu-kvm qemu-system-common qemu-system-data
qemu-system-gui qemu-system-x86 qemu-utils ubuntu-mate-artwork 
ubuntu-mate-default-settings ubuntu-mate-icon-themes
ubuntu-mate-lightdm-theme ubuntu-mate-live-settings ubuntu-mate-themes 
ubuntu-mate-wallpapers ubuntu-mate-wallpapers-artful
ubuntu-mate-wallpapers-bionic ubuntu-mate-wallpapers-common 
ubuntu-mate-wallpapers-complete ubuntu-mate-wallpapers-cosmic
ubuntu-mate-wallpapers-disco ubuntu-mate-wallpapers-eoan 
ubuntu-mate-wallpapers-legacy ubuntu-mate-wallpapers-photos
ubuntu-mate-wallpapers-utopic ubuntu-mate-wallpapers-vivid 
ubuntu-mate-wallpapers-wily ubuntu-mate-wallpapers-xenial
ubuntu-mate-wallpapers-yakkety ubuntu-mate-wallpapers-zesty umbrello
  136 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
  Need to get 215 MB of archives.
  After this operation, 12,8 MB of additional disk space will be used.
  Do you want to continue? [Y/n] 
  Get:1 http://archive.ubuntu.com/ubuntu focal/universe amd64 mate-common all 
1.24.0-1ubuntu1 [17,0 kB]
  ...
  Get:139 http://archive.ubuntu.com/ubuntu focal/universe amd64 
mate-dock-applet amd64 20.04.0-0ubuntu1 [91,8 kB]
  Fetched 215 MB in 4min 4s (882 kB/s)  
 
  Extracting templates from packages: 100%
  Preconfiguring packages ...
  (Reading database ... 961594 files and directories 

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

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

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

- Eric

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

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

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

Bug description:
  [Impact]

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

  [Test Case]

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

  sleep 5

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

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

  sleep 5

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

  sleep 5

  sudo nmcli c s bond0
  ##

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

  [Potential Regression]

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

  [Other informations]

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

  * Upstream bug and fix:

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

  * Only affecting Bionic:

  $ git describe --contains f03ae35
  1.10.8~2

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

  [Original description]

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

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

  Machine Type = s390x

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

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

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

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

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

  [ethernet]
  mac-address-blacklist=

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

  [ipv4]
  dns-search=
  method=auto

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

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

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

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

2020-02-24 Thread Eric Desrochers
** Information type changed from Private to Public

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

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

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

Bug description:
  [Impact]

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

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

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

  [Test Case]

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

   * trigger a package installation from the landscape server.

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

  [Regression Potential]

   * The change is trivially simple.

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

  [Original Description]

  Crash in the background

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

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

-- 
Mailing list: https://launchpad.net/~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 1794478] Re: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it

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

** Tags added: sts-sponsor-dgadomski

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

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

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

Bug description:
  [Impact]

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

  [Test Case]

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

  sleep 5

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

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

  sleep 5

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

  sleep 5

  sudo nmcli c s bond0
  ##

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

  [Potential Regression]

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

  [Other informations]

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

  * Upstream bug and fix:

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

  * Only affecting Bionic:

  $ git describe --contains f03ae35
  1.10.8~2

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

  [Original description]

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

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

  Machine Type = s390x

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

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

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

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

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

  [ethernet]
  mac-address-blacklist=

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

  [ipv4]
  dns-search=
  method=auto

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

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

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

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

2020-02-24 Thread Eric Desrochers
@xtrusia,

Is this ready for sponsorship ?

I'll have a look when ready.

- Eric

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

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

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

Bug description:
  [Impact]

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

  [Test Case]

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

  sleep 5

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

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

  sleep 5

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

  sleep 5

  sudo nmcli c s bond0
  ##

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

  [Potential Regression]

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

  [Other informations]

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

  * Upstream bug and fix:

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

  * Only affecting Bionic:

  $ git describe --contains f03ae35
  1.10.8~2

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

  [Original description]

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

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

  Machine Type = s390x

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

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

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

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

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

  [ethernet]
  mac-address-blacklist=

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

  [ipv4]
  dns-search=
  method=auto

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

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

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

[Touch-packages] [Bug 1862846] Re: Crash and failure installing focal

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

Thanks Mauricio !

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

Title:
  Crash and failure installing focal

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

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

  Attached are the logs left on the install USB key.

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

-- 
Mailing list: https://launchpad.net/~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 1828901] Re: add PTY support for runuser

2020-02-15 Thread Eric Desrochers
The sosreport juju plugin refactoring has been simplified.

For now, we don't expect the juju plugin to drop privileges any time
soon.

Thanks !

** Changed in: util-linux (Ubuntu Xenial)
   Status: In Progress => Won't Fix

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

Title:
  add PTY support for runuser

Status in util-linux package in Ubuntu:
  Fix Released
Status in util-linux source package in Xenial:
  Won't Fix
Status in util-linux package in Debian:
  Fix Released

Bug description:
  [IMPACT]

  [TEST CASE]

  [REGRESSION POTENTIAL]

  [OTHER INFORMATION]

  Debbug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815922

  This is fixing a CVE vulnerability:
  https://security-tracker.debian.org/tracker/CVE-2016-2779

  Restricting ioctl on the kernel side seems the better approach, patches have 
been posted to kernel-hardening list
  http://www.openwall.com/lists/oss-security/2016/02/27/1
  https://marc.info/?l=util-linux-ng=145694736107128=2
  2.31 introduces a new --pty option to separate privileged and unprivileged
  shells (not enabled by default and the cli switch is necessary).

  [ORIGINAL DESCRIPTION]
  After a discussion with security team on what would be their recommended way 
to run command as 'juju-user' inside the sosreport juju plugin which is run as 
root, in order to avoid using 'sudo' or 'su' command.

  The recommendation was to use 'runuser -P'

  runuser PTY support is present in Bionic and late, but not in Xenial.

  I'm opening this bug in the effort to update util-linux/runuser code
  in Xenial to add the PTY support.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1828901/+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 1794478] Re: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it

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

+ 
+ [Impact]
+ [Test Case]
+ [Potential Regression]
+ 
+ [Other informations]
+ 
+ * Upstream bug[0] and fix[1]:
+ 
+ https://bugzilla.redhat.com/show_bug.cgi?id=1575944
+ https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/f03ae35
+ 
+ * Only affectinb Bionic:
+ 
+ $ git describe --contains f03ae35
+ 1.10.8~2
+ 
+ $ rmadison network-manager
+ ==> network-manager | 1.10.6-2ubuntu1.2   | bionic-updates
+ network-manager | 1.20.4-2ubuntu2.2   | eoan-updates   
+ network-manager | 1.22.4-1ubuntu2 | focal
+ 
+ [Original description]
  ---Problem Description---
  Bond interface with automatic ipv4 mode and manual ipv6 mode fails to get 
automatic ipv4 assigned from dhcp server.
-  
+ 
  ---uname output---
  Linux NetworkTest 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 
2018 s390x s390x s390x GNU/Linux
-  
- Machine Type = s390x 
-  
+ 
+ Machine Type = s390x
+ 
  ---Debugger---
  A debugger is not configured
-  
+ 
  ---Steps to Reproduce---
-  When user configures ipv4 as automatic and ipv6 as manual for bond interface 
automatic ipv4 is not getting assigned.
+  When user configures ipv4 as automatic and ipv6 as manual for bond interface 
automatic ipv4 is not getting assigned.
  Looks like dhcp client request for ipv4 is not done to dhcp server after 
maunal ipv6 is assigned quickly to bond interface
  
  This issue will not happen in below cases:
  1)with ipv4 automatic and ipv6 manual configuration for ethernet or vlan 
interface.
  2)with ipv4 automatic and ipv6 automatic configuration for bond interface
  3)with ipv4 automatic and ipv6 disabled configuration for bond interface
  
  Configuration:
  Bond interface, ipv4 automatic mode and ipv6 automatic mode
  
- root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond 
+ root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond
  [connection]
  id=test_bond
  uuid=63e54542-5135-47ac-a954-b861c3937be2
  type=bond
  interface-name=test_bond
  permissions=
  timestamp=1537944121
  
  [ethernet]
  mac-address-blacklist=
  
  [bond]
  downdelay=0
  fail_over_mac=none
  miimon=100
  mode=active-backup
  num_grat_arp=0
  primary_reselect=always
  updelay=0
  
  [ipv4]
  dns-search=
  method=auto
  
  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  method=auto
  
  From /var/log/syslog, we can see ip got assigned:
  
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPDISCOVER on test_bond to 
255.255.255.255 port 67 interval 3 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPREQUEST of 10.2.3.55 on 
test_bond to 255.255.255.255 port 67 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPOFFER of 10.2.3.55 from 
10.2.3.1
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPACK of 10.2.3.55 from 10.2.3.1
  
  root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
  28: test_bond:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000
- link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
- inet 10.2.3.55/24 brd 10.2.3.255 scope global dynamic noprefixroute 
test_bond
-valid_lft 353sec preferred_lft 353sec
- inet6 fe80::ff:feb3:b522/64 scope link 
-valid_lft forever preferred_lft forever
- 
+ link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
+ inet 10.2.3.55/24 brd 10.2.3.255 scope global dynamic noprefixroute 
test_bond
+    valid_lft 353sec preferred_lft 353sec
+ inet6 fe80::ff:feb3:b522/64 scope link
+    valid_lft forever preferred_lft forever
  
  
+++
  Bond interface, ipv4 automatic mode and ipv6 manual mode
  
- root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond 
+ root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond
  [connection]
  id=test_bond
  uuid=3efb153a-a6e4-48fb-aa04-f0b8cb549bab
  type=bond
  interface-name=test_bond
  permissions=
  timestamp=1537943300
  
  [ethernet]
  mac-address-blacklist=
  
  [bond]
  downdelay=0
  fail_over_mac=none
  miimon=100
  mode=active-backup
  num_grat_arp=0
  primary_reselect=always
  updelay=0
  
  [ipv4]
  dns-search=
  method=auto
  
  [ipv6]
  addr-gen-mode=stable-privacy
  address1=fe81::32a5:bc5f:287f:8db8/64
  dns-search=
  method=manual
  
  No automatic ip assigned to ipv4 and no requests to dhcp server seen in 
/var/log/syslog
  root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
  29: test_bond:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000
- link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
- inet6 fe81::32a5:bc5f:287f:8db8/64 scope link noprefixroute 
-valid_lft forever preferred_lft forever
- 
+ link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
+ inet6 fe81::32a5:bc5f:287f:8db8/64 scope link noprefixroute
+    valid_lft forever preferred_lft forever
  
  ==> Correct LP-Package 

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

2020-02-14 Thread Eric Desrochers
Thanks for reporting the outcome of your test.

We will start the SRU process in order to update network-manager package
next week.

Regards,

Eric

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

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

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

Bug description:
  ---Problem Description---
  Bond interface with automatic ipv4 mode and manual ipv6 mode fails to get 
automatic ipv4 assigned from dhcp server.
   
  ---uname output---
  Linux NetworkTest 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 
2018 s390x s390x s390x GNU/Linux
   
  Machine Type = s390x 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   When user configures ipv4 as automatic and ipv6 as manual for bond interface 
automatic ipv4 is not getting assigned.
  Looks like dhcp client request for ipv4 is not done to dhcp server after 
maunal ipv6 is assigned quickly to bond interface

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

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

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

  [ethernet]
  mac-address-blacklist=

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

  [ipv4]
  dns-search=
  method=auto

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

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

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

  root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
  28: test_bond:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000
  link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
  inet 10.2.3.55/24 brd 10.2.3.255 scope global dynamic noprefixroute 
test_bond
 valid_lft 353sec preferred_lft 353sec
  inet6 fe80::ff:feb3:b522/64 scope link 
 valid_lft forever preferred_lft forever

  
  
+++
  Bond interface, ipv4 automatic mode and ipv6 manual mode

  root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond 
  [connection]
  id=test_bond
  uuid=3efb153a-a6e4-48fb-aa04-f0b8cb549bab
  type=bond
  interface-name=test_bond
  permissions=
  timestamp=1537943300

  [ethernet]
  mac-address-blacklist=

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

  [ipv4]
  dns-search=
  method=auto

  [ipv6]
  addr-gen-mode=stable-privacy
  address1=fe81::32a5:bc5f:287f:8db8/64
  dns-search=
  method=manual

  No automatic ip assigned to ipv4 and no requests to dhcp server seen in 
/var/log/syslog
  root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
  29: test_bond:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000
  link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
  inet6 fe81::32a5:bc5f:287f:8db8/64 scope link noprefixroute 
 valid_lft forever preferred_lft forever

  
  ==> Correct LP-Package need to be assigned...!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1794478/+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 1794478] Re: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it

2020-02-12 Thread Eric Desrochers
This look like a similar issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1575944
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/f03ae35


A test package (including the above fix) is available on my PPA:
sudo add-apt-repository ppa:slashd/lp1794478
sudo apt-get update

Please let me know the outcome.

- Eric

** Bug watch added: Red Hat Bugzilla #1575944
   https://bugzilla.redhat.com/show_bug.cgi?id=1575944

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

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

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

Bug description:
  ---Problem Description---
  Bond interface with automatic ipv4 mode and manual ipv6 mode fails to get 
automatic ipv4 assigned from dhcp server.
   
  ---uname output---
  Linux NetworkTest 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 
2018 s390x s390x s390x GNU/Linux
   
  Machine Type = s390x 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   When user configures ipv4 as automatic and ipv6 as manual for bond interface 
automatic ipv4 is not getting assigned.
  Looks like dhcp client request for ipv4 is not done to dhcp server after 
maunal ipv6 is assigned quickly to bond interface

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

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

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

  [ethernet]
  mac-address-blacklist=

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

  [ipv4]
  dns-search=
  method=auto

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

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

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

  root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
  28: test_bond:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000
  link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
  inet 10.2.3.55/24 brd 10.2.3.255 scope global dynamic noprefixroute 
test_bond
 valid_lft 353sec preferred_lft 353sec
  inet6 fe80::ff:feb3:b522/64 scope link 
 valid_lft forever preferred_lft forever

  
  
+++
  Bond interface, ipv4 automatic mode and ipv6 manual mode

  root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond 
  [connection]
  id=test_bond
  uuid=3efb153a-a6e4-48fb-aa04-f0b8cb549bab
  type=bond
  interface-name=test_bond
  permissions=
  timestamp=1537943300

  [ethernet]
  mac-address-blacklist=

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

  [ipv4]
  dns-search=
  method=auto

  [ipv6]
  addr-gen-mode=stable-privacy
  address1=fe81::32a5:bc5f:287f:8db8/64
  dns-search=
  method=manual

  No automatic ip assigned to ipv4 and no requests to dhcp server seen in 
/var/log/syslog
  root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
  29: test_bond:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000
  link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
  inet6 fe81::32a5:bc5f:287f:8db8/64 scope link noprefixroute 
 valid_lft forever preferred_lft forever

  
  ==> Correct LP-Package need to be assigned...!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1794478/+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 1822416] Re: resolve: do not hit CNAME or DNAME entry in NODATA cache

2020-02-05 Thread Eric Desrochers
You can find it here:
https://www.ubuntuupdates.org/package/core/bionic/universe/updates/systemd?id=1401429=2

-
Version: 237-3ubuntu10.23   2019-06-21 00:06:25 UTC
  systemd (237-3ubuntu10.23) bionic; urgency=medium

  * d/p/resolved-do-not-hit-CNAME-in-NODATA.patch:
- fix stub resolver cache (LP: #1818527)

 -- Heitor Alves de Siqueira  Tue, 04 Jun 2019
15:54:24 -0300

Source diff to previous version
1818527 Stub resolver cache is corrupted
-

The fix has been first introduced in "237-3ubuntu10.23" so
"237-3ubuntu10.38" definitely should have it still, yes.

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

Title:
  resolve: do not hit CNAME or DNAME entry in NODATA cache

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Disco:
  Fix Released
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  The question: DNS A record lookups fail to resolve due to cached CNAME
  NODATA lookups ...

  https://askubuntu.com/questions/1063462/18-04-server-systemd-resolve-
  returns-cached-cname-nodata-for-a-lookup

  Upstream at Github: Systemd issue 998 - Cached cname NODATA returned
  for A lookup ...

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

  
  Please patch ...

  
https://github.com/systemd/systemd/commit/3740146a4cbd99883af79e375ee4836206dcea4e

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1822416/+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


  1   2   3   4   5   6   7   8   >