[Touch-packages] [Bug 1848330] Re: Installing auditd sometimes fails in post-inst

[Andreas Hasenack]

I'm going over the DEP8 failures

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

Title:
  Installing auditd sometimes fails in post-inst

Status in audit package in Ubuntu:
  Fix Released
Status in audit source package in Bionic:
  Fix Committed
Status in audit package in Debian:
  New

Bug description:
  [Impact]

  Sometimes, auditd will get stuck when starting up, causing systemd to
  kill it after a while since it (systemd) never got the start
  notification.

  Upstream troubleshooted this to be caused by calling a syslog()
  function inside a signal handler.

  [Test Case]
  There is no reliable test case to reproduce the bug, other than trying the 
fixed packages on an affected system where the hang occurs more frequently.

  Basically:
  sudo systemctl stop auditd
  sudo systemctl start auditd

  should work reliably. Do not run that in a tight loop, however, as
  that will trigger a it's-restarting-too-frequently failure.

  [Where problems could occur]
  - if auditd fails to start, then the first fallback is syslog, and if that is 
not picking up the audit messages, the last resort is the kernel buffer, which 
can fill up. In the case it fills up, audit logs will be lost.

  - it's possible to configure the audit system to panic() the machine
  if audit messages are lost or otherwise not able to be recorded
  (auditctl -f 2; default is 1 which is printk())

  - the update restarts auditd as expected. Misconfiguration on very
  very busy systems could mean that audit logs would be lost during the
  brief moment the service is restarted. If that's the case, this update
  would just be one more way to trigger it, but not be the root cause of
  the problem

  - similarly, as is usual with updates that restart services, it's
  possible than an incorrect configuration for auditd is present, but
  was never loaded before. The restart will load the config, and will
  fail in such a case.

  - this update removes a logging statement that occurs during startup:

  ("dispatcher %d reaped", pid)

  It's unlikely, but possible, that some monitoring software could be
  looking for that message in the logs. It won't be there anymore after
  this update.

  [Other Info]
  The patch is committed upstream and part of the 2.8.5 release, which is 
present in Focal and later.
  The real fix for this bug is just dropping the audit_msg() call in the signal 
handler code. But the original reporter of the bug, who is also who came up 
with the fix (see https://bugzilla.redhat.com/show_bug.cgi?id=1587995#c4) 
stated that with the 3 changes in the patch the startup hang didn't happen to 
him anymore. Since this bug is difficult to reproduce elsewhere (either you 
have it, or you don't), I chose to keep the 3 changes instead of just the 
removal of the audit_msg() call.

  [Original Description]

  This happens sometimes when installing auditd on Ubuntu 18.04.2, most
  installations work successfully, though. Re-running the install also
  fixes the issue, but the failure breaks our automation. The log from
  the failure looks like this:

  # apt install auditd
  ...
  Setting up auditd (1:2.8.2-1ubuntu1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → 
/lib/systemd/system/auditd.service.
  Job for auditd.service failed because a timeout was exceeded.
  See "systemctl status auditd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript auditd, action "start" failed.
  ● auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
     Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
   Docs: man:auditd(8)
     https://github.com/linux-audit/audit-documentation
    Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)

  Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing 
Service...
  Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: 
/sbin/audispd pid: 9705
  Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
  Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation 
timed out. Terminating.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 
'stop-sigterm' timed out. Killing.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9702 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9703 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process 
exited, code=killed status=9
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 
'timeout'.
  Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing 
Service.
  dpkg: error processing package auditd (--configure):

[Touch-packages] [Bug 1848330] Re: Installing auditd sometimes fails in post-inst

[Andreas Hasenack]

Package uploaded to the SRU queue

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

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

Title:
  Installing auditd sometimes fails in post-inst

Status in audit package in Ubuntu:
  In Progress
Status in audit package in Debian:
  New

Bug description:
  [Impact]

  Sometimes, auditd will get stuck when starting up, causing systemd to
  kill it after a while since it (systemd) never got the start
  notification.

  Upstream troubleshooted this to be caused by calling a syslog()
  function inside a signal handler.

  [Test Case]
  There is no reliable test case to reproduce the bug, other than trying the 
fixed packages on an affected system where the hang occurs more frequently.

  Basically:
  sudo systemctl stop auditd
  sudo systemctl start auditd

  should work reliably. Do not run that in a tight loop, however, as
  that will trigger a it's-restarting-too-frequently failure.

  [Where problems could occur]
  - if auditd fails to start, then the first fallback is syslog, and if that is 
not picking up the audit messages, the last resort is the kernel buffer, which 
can fill up. In the case it fills up, audit logs will be lost.

  - it's possible to configure the audit system to panic() the machine
  if audit messages are lost or otherwise not able to be recorded
  (auditctl -f 2; default is 1 which is printk())

  - the update restarts auditd as expected. Misconfiguration on very
  very busy systems could mean that audit logs would be lost during the
  brief moment the service is restarted. If that's the case, this update
  would just be one more way to trigger it, but not be the root cause of
  the problem

  - similarly, as is usual with updates that restart services, it's
  possible than an incorrect configuration for auditd is present, but
  was never loaded before. The restart will load the config, and will
  fail in such a case.

  - this update removes a logging statement that occurs during startup:

  ("dispatcher %d reaped", pid)

  It's unlikely, but possible, that some monitoring software could be
  looking for that message in the logs. It won't be there anymore after
  this update.

  [Other Info]
  The patch is committed upstream and part of the 2.8.5 release, which is 
present in Focal and later.
  The real fix for this bug is just dropping the audit_msg() call in the signal 
handler code. But the original reporter of the bug, who is also who came up 
with the fix (see https://bugzilla.redhat.com/show_bug.cgi?id=1587995#c4) 
stated that with the 3 changes in the patch the startup hang didn't happen to 
him anymore. Since this bug is difficult to reproduce elsewhere (either you 
have it, or you don't), I chose to keep the 3 changes instead of just the 
removal of the audit_msg() call.

  [Original Description]

  This happens sometimes when installing auditd on Ubuntu 18.04.2, most
  installations work successfully, though. Re-running the install also
  fixes the issue, but the failure breaks our automation. The log from
  the failure looks like this:

  # apt install auditd
  ...
  Setting up auditd (1:2.8.2-1ubuntu1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → 
/lib/systemd/system/auditd.service.
  Job for auditd.service failed because a timeout was exceeded.
  See "systemctl status auditd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript auditd, action "start" failed.
  ● auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
     Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
   Docs: man:auditd(8)
     https://github.com/linux-audit/audit-documentation
    Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)

  Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing 
Service...
  Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: 
/sbin/audispd pid: 9705
  Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
  Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation 
timed out. Terminating.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 
'stop-sigterm' timed out. Killing.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9702 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9703 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process 
exited, code=killed status=9
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 
'timeout'.
  Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing 
Service.
  dpkg: error processing package auditd 

[Touch-packages] [Bug 1848330] Re: Installing auditd sometimes fails in post-inst

[Andreas Hasenack]

** Description changed:

  [Impact]
  
  Sometimes, auditd will get stuck when starting up, causing systemd to
  kill it after a while since it (systemd) never got the start
  notification.
  
  Upstream troubleshooted this to be caused by calling a syslog() function
  inside a signal handler.
  
  [Test Case]
  There is no reliable test case to reproduce the bug, other than trying the 
fixed packages on an affected system where the hang occurs more frequently.
  
  Basically:
  sudo systemctl stop auditd
  sudo systemctl start auditd
  
  should work reliably. Do not run that in a tight loop, however, as that
  will trigger a it's-restarting-too-frequently failure.
  
  [Where problems could occur]
  - if auditd fails to start, then the first fallback is syslog, and if that is 
not picking up the audit messages, the last resort is the kernel buffer, which 
can fill up. In the case it fills up, audit logs will be lost.
  
  - it's possible to configure the audit system to panic() the machine if
  audit messages are lost or otherwise not able to be recorded (auditctl
  -f 2; default is 1 which is printk())
  
  - the update restarts auditd as expected. Misconfiguration on very very
  busy systems could mean that audit logs would be lost during the brief
  moment the service is restarted. If that's the case, this update would
  just be one more way to trigger it, but not be the root cause of the
  problem
  
  - similarly, as is usual with updates that restart services, it's
  possible than an incorrect configuration for auditd is present, but was
  never loaded before. The restart will load the config, and will fail in
  such a case.
  
  - this update removes a logging statement that occurs during startup:
  
  ("dispatcher %d reaped", pid)
  
  It's unlikely, but possible, that some monitoring software could be
  looking for that message in the logs. It won't be there anymore after
  this update.
  
  [Other Info]
  The patch is committed upstream and part of the 2.8.5 release, which is 
present in Focal and later.
+ The real fix for this bug is just dropping the audit_msg() call in the signal 
handler code. But the original reporter of the bug, who is also who came up 
with the fix (see https://bugzilla.redhat.com/show_bug.cgi?id=1587995#c4) 
stated that with the 3 changes in the patch the startup hang didn't happen to 
him anymore. Since this bug is difficult to reproduce elsewhere (either you 
have it, or you don't), I chose to keep the 3 changes instead of just the 
removal of the audit_msg() call.
  
  [Original Description]
  
  This happens sometimes when installing auditd on Ubuntu 18.04.2, most
  installations work successfully, though. Re-running the install also
  fixes the issue, but the failure breaks our automation. The log from the
  failure looks like this:
  
  # apt install auditd
  ...
  Setting up auditd (1:2.8.2-1ubuntu1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → 
/lib/systemd/system/auditd.service.
  Job for auditd.service failed because a timeout was exceeded.
  See "systemctl status auditd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript auditd, action "start" failed.
  ● auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
     Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
   Docs: man:auditd(8)
     https://github.com/linux-audit/audit-documentation
    Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
  
  Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing 
Service...
  Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: 
/sbin/audispd pid: 9705
  Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
  Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation 
timed out. Terminating.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 
'stop-sigterm' timed out. Killing.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9702 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9703 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process 
exited, code=killed status=9
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 
'timeout'.
  Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing 
Service.
  dpkg: error processing package auditd (--configure):
   installed auditd package post-installation script subprocess returned error 
exit status 1

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

Title:
  Installing auditd sometimes fails in post-inst

Status in audit package in Ubuntu:
  Confirmed

[Touch-packages] [Bug 1848330] Re: Installing auditd sometimes fails in post-inst

[Andreas Hasenack]

** Description changed:

  [Impact]
  
-  * An explanation of the effects of the bug on users and
+ Sometimes, auditd will get stuck when starting up, causing systemd to
+ kill it after a while since it (systemd) never got the start
+ notification.
  
-  * justification for backporting the fix to the stable release.
- 
-  * In addition, it is helpful, but not required, to include an
-explanation of how the upload fixes this bug.
+ Upstream troubleshooted this to be caused by calling a syslog() function
+ inside a signal handler.
  
  [Test Case]
+ There is no reliable test case to reproduce the bug, other than trying the 
fixed packages on an affected system where the hang occurs more frequently.
  
-  * detailed instructions how to reproduce the bug
+ Basically:
+ sudo systemctl stop auditd
+ sudo systemctl start auditd
  
-  * these should allow someone who is not familiar with the affected
-package to reproduce the bug and verify that the updated package fixes
-the problem.
+ should work reliably. Do not run that in a tight loop, however, as that
+ will trigger a it's-restarting-too-frequently failure.
  
  [Where problems could occur]
+ - if auditd fails to start, then the first fallback is syslog, and if that is 
not picking up the audit messages, the last resort is the kernel buffer, which 
can fill up. In the case it fills up, audit logs will be lost.
  
-  * Think about what the upload changes in the software. Imagine the change is
-wrong or breaks something else: how would this show up?
+ - it's possible to configure the audit system to panic() the machine if
+ audit messages are lost or otherwise not able to be recorded (auditctl
+ -f 2; default is 1 which is printk())
  
-  * It is assumed that any SRU candidate patch is well-tested before
-upload and has a low overall risk of regression, but it's important
-to make the effort to think about what ''could'' happen in the
-event of a regression.
+ - the update restarts auditd as expected. Misconfiguration on very very
+ busy systems could mean that audit logs would be lost during the brief
+ moment the service is restarted. If that's the case, this update would
+ just be one more way to trigger it, but not be the root cause of the
+ problem
  
-  * This must '''never''' be "None" or "Low", or entirely an argument as to why
-your upload is low risk.
+ - this update removes a logging statement that occurs during startup:
  
-  * This both shows the SRU team that the risks have been considered,
-and provides guidance to testers in regression-testing the SRU.
+ ("dispatcher %d reaped", pid)
+ 
+ It's unlikely, but possible, that some monitoring software could be
+ looking for that message in the logs. It won't be there anymore after
+ this update.
+ 
  
  [Other Info]
-  
-  * Anything else you think is useful to include
-  * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
-  * and address these questions in advance
+ The patch is committed upstream and part of the 2.8.5 release, which is 
present in Focal and later.
  
  
  [Original Description]
  
- 
- This happens sometimes when installing auditd on Ubuntu 18.04.2, most 
installations work successfully, though. Re-running the install also fixes the 
issue, but the failure breaks our automation. The log from the failure looks 
like this:
+ This happens sometimes when installing auditd on Ubuntu 18.04.2, most
+ installations work successfully, though. Re-running the install also
+ fixes the issue, but the failure breaks our automation. The log from the
+ failure looks like this:
  
  # apt install auditd
  ...
  Setting up auditd (1:2.8.2-1ubuntu1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → 
/lib/systemd/system/auditd.service.
  Job for auditd.service failed because a timeout was exceeded.
  See "systemctl status auditd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript auditd, action "start" failed.
  ● auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
     Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
   Docs: man:auditd(8)
     https://github.com/linux-audit/audit-documentation
    Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
  
  Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing 
Service...
  Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: 
/sbin/audispd pid: 9705
  Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
  Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation 
timed out. Terminating.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 
'stop-sigterm' timed out. Killing.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9702 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 

[Touch-packages] [Bug 1848330] Re: Installing auditd sometimes fails in post-inst

[Andreas Hasenack]

Yikes @Kodiak, sounds painful :(

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

Title:
  Installing auditd sometimes fails in post-inst

Status in audit package in Ubuntu:
  Confirmed
Status in audit package in Debian:
  New

Bug description:
  [Impact]

   * An explanation of the effects of the bug on users and

   * justification for backporting the fix to the stable release.

   * In addition, it is helpful, but not required, to include an
 explanation of how the upload fixes this bug.

  [Test Case]

   * detailed instructions how to reproduce the bug

   * these should allow someone who is not familiar with the affected
 package to reproduce the bug and verify that the updated package fixes
 the problem.

  [Where problems could occur]

   * Think about what the upload changes in the software. Imagine the change is
 wrong or breaks something else: how would this show up?

   * It is assumed that any SRU candidate patch is well-tested before
 upload and has a low overall risk of regression, but it's important
 to make the effort to think about what ''could'' happen in the
 event of a regression.

   * This must '''never''' be "None" or "Low", or entirely an argument as to why
 your upload is low risk.

   * This both shows the SRU team that the risks have been considered,
 and provides guidance to testers in regression-testing the SRU.

  [Other Info]
   
   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
   * and address these questions in advance

  
  [Original Description]

  
  This happens sometimes when installing auditd on Ubuntu 18.04.2, most 
installations work successfully, though. Re-running the install also fixes the 
issue, but the failure breaks our automation. The log from the failure looks 
like this:

  # apt install auditd
  ...
  Setting up auditd (1:2.8.2-1ubuntu1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → 
/lib/systemd/system/auditd.service.
  Job for auditd.service failed because a timeout was exceeded.
  See "systemctl status auditd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript auditd, action "start" failed.
  ● auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
     Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
   Docs: man:auditd(8)
     https://github.com/linux-audit/audit-documentation
    Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)

  Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing 
Service...
  Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: 
/sbin/audispd pid: 9705
  Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
  Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation 
timed out. Terminating.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 
'stop-sigterm' timed out. Killing.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9702 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9703 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process 
exited, code=killed status=9
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 
'timeout'.
  Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing 
Service.
  dpkg: error processing package auditd (--configure):
   installed auditd package post-installation script subprocess returned error 
exit status 1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1848330/+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 1848330] Re: Installing auditd sometimes fails in post-inst

[Andreas Hasenack]

** Description changed:

- This happens sometimes when installing auditd on Ubuntu 18.04.2, most
- installations work successfully, though. Re-running the install also
- fixes the issue, but the failure breaks our automation. The log from the
- failure looks like this:
+ [Impact]
+ 
+  * An explanation of the effects of the bug on users and
+ 
+  * justification for backporting the fix to the stable release.
+ 
+  * In addition, it is helpful, but not required, to include an
+explanation of how the upload fixes this bug.
+ 
+ [Test Case]
+ 
+  * detailed instructions how to reproduce the bug
+ 
+  * these should allow someone who is not familiar with the affected
+package to reproduce the bug and verify that the updated package fixes
+the problem.
+ 
+ [Where problems could occur]
+ 
+  * Think about what the upload changes in the software. Imagine the change is
+wrong or breaks something else: how would this show up?
+ 
+  * It is assumed that any SRU candidate patch is well-tested before
+upload and has a low overall risk of regression, but it's important
+to make the effort to think about what ''could'' happen in the
+event of a regression.
+ 
+  * This must '''never''' be "None" or "Low", or entirely an argument as to why
+your upload is low risk.
+ 
+  * This both shows the SRU team that the risks have been considered,
+and provides guidance to testers in regression-testing the SRU.
+ 
+ [Other Info]
+  
+  * Anything else you think is useful to include
+  * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
+  * and address these questions in advance
+ 
+ 
+ [Original Description]
+ 
+ 
+ This happens sometimes when installing auditd on Ubuntu 18.04.2, most 
installations work successfully, though. Re-running the install also fixes the 
issue, but the failure breaks our automation. The log from the failure looks 
like this:
  
  # apt install auditd
  ...
  Setting up auditd (1:2.8.2-1ubuntu1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → 
/lib/systemd/system/auditd.service.
  Job for auditd.service failed because a timeout was exceeded.
  See "systemctl status auditd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript auditd, action "start" failed.
  ● auditd.service - Security Auditing Service
-Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
-Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
-  Docs: man:auditd(8)
-https://github.com/linux-audit/audit-documentation
-   Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
+    Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
+    Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
+  Docs: man:auditd(8)
+    https://github.com/linux-audit/audit-documentation
+   Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)
  
  Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing 
Service...
  Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: 
/sbin/audispd pid: 9705
  Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
  Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation 
timed out. Terminating.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 
'stop-sigterm' timed out. Killing.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9702 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9703 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process 
exited, code=killed status=9
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 
'timeout'.
  Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing 
Service.
  dpkg: error processing package auditd (--configure):
-  installed auditd package post-installation script subprocess returned error 
exit status 1
+  installed auditd package post-installation script subprocess returned error 
exit status 1

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

Title:
  Installing auditd sometimes fails in post-inst

Status in audit package in Ubuntu:
  Confirmed
Status in audit package in Debian:
  New

Bug description:
  [Impact]

   * An explanation of the effects of the bug on users and

   * justification for backporting the fix to the stable release.

   * In addition, it is helpful, but not required, to include an
 explanation of how the upload fixes this bug.

  [Test Case]

   * detailed instructions how to reproduce the bug

   * these should allow someone who is not familiar with the affected
 

[Touch-packages] [Bug 1848330] Re: Installing auditd sometimes fails in post-inst

[Andreas Hasenack]

I'm having difficulties reproducing the bug, to validate the patch. I
build bionic test packages with the patch mentioned earlier, if someone
wants to test: https://launchpad.net/~ahasenack/+archive/ubuntu/audit-
startup-hang-1848330

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

Title:
  Installing auditd sometimes fails in post-inst

Status in audit package in Ubuntu:
  Confirmed
Status in audit package in Debian:
  New

Bug description:
  This happens sometimes when installing auditd on Ubuntu 18.04.2, most
  installations work successfully, though. Re-running the install also
  fixes the issue, but the failure breaks our automation. The log from
  the failure looks like this:

  # apt install auditd
  ...
  Setting up auditd (1:2.8.2-1ubuntu1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → 
/lib/systemd/system/auditd.service.
  Job for auditd.service failed because a timeout was exceeded.
  See "systemctl status auditd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript auditd, action "start" failed.
  ● auditd.service - Security Auditing Service
 Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
   Docs: man:auditd(8)
 https://github.com/linux-audit/audit-documentation
Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)

  Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing 
Service...
  Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: 
/sbin/audispd pid: 9705
  Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
  Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation 
timed out. Terminating.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 
'stop-sigterm' timed out. Killing.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9702 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9703 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process 
exited, code=killed status=9
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 
'timeout'.
  Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing 
Service.
  dpkg: error processing package auditd (--configure):
   installed auditd package post-installation script subprocess returned error 
exit status 1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1848330/+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 1848330] Re: Installing auditd sometimes fails in post-inst

[Andreas Hasenack]

correct source package name is audit, not auditd (apparently we have/had
both)

** Changed in: auditd (Ubuntu)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

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

** Also affects: audit (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962451
   Importance: Unknown
   Status: Unknown

** Package changed: auditd (Ubuntu) => audit (Ubuntu)

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

Title:
  Installing auditd sometimes fails in post-inst

Status in audit package in Ubuntu:
  Confirmed
Status in audit package in Debian:
  Unknown

Bug description:
  This happens sometimes when installing auditd on Ubuntu 18.04.2, most
  installations work successfully, though. Re-running the install also
  fixes the issue, but the failure breaks our automation. The log from
  the failure looks like this:

  # apt install auditd
  ...
  Setting up auditd (1:2.8.2-1ubuntu1) ...
  Created symlink /etc/systemd/system/multi-user.target.wants/auditd.service → 
/lib/systemd/system/auditd.service.
  Job for auditd.service failed because a timeout was exceeded.
  See "systemctl status auditd.service" and "journalctl -xe" for details.
  invoke-rc.d: initscript auditd, action "start" failed.
  ● auditd.service - Security Auditing Service
 Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: timeout) since Tue 2019-09-17 18:43:06 UTC; 11ms 
ago
   Docs: man:auditd(8)
 https://github.com/linux-audit/audit-documentation
Process: 9702 ExecStart=/sbin/auditd (code=killed, signal=KILL)

  Sep 17 18:40:06 compute-node21 systemd[1]: Starting Security Auditing 
Service...
  Sep 17 18:40:06 compute-node21 auditd[9703]: Started dispatcher: 
/sbin/audispd pid: 9705
  Sep 17 18:40:06 compute-node21 audispd[9705]: No plugins found, exiting
  Sep 17 18:41:36 compute-node21 systemd[1]: auditd.service: Start operation 
timed out. Terminating.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: State 
'stop-sigterm' timed out. Killing.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9702 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Killing process 
9703 (auditd) with signal SIGKILL.
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Control process 
exited, code=killed status=9
  Sep 17 18:43:06 compute-node21 systemd[1]: auditd.service: Failed with result 
'timeout'.
  Sep 17 18:43:06 compute-node21 systemd[1]: Failed to start Security Auditing 
Service.
  dpkg: error processing package auditd (--configure):
   installed auditd package post-installation script subprocess returned error 
exit status 1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1848330/+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 1898593] [NEW] Fix sphinx doc building

[Andreas Hasenack]

Public bug reported:

This basically the same bug as #1894907, but there I decided to disable
docs rebuilding, after checking that none of the patches were against
the docs source.

Furthermore, we should probably fix these lintian issues:

E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/developer.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/download.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/genindex.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/getsasl.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/index.html You may use the libjs-mathjax package. 
(https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/operations.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/packager.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/search.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/setup.html You may use the libjs-mathjax package. 
(https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/support.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: cyrus-sasl2 source: source-is-missing doc/html/_static/jquery.js line length 
is 32014 characters (>512)
E: cyrus-sasl2 source: source-is-missing doc/html/_static/js/modernizr.min.js   
E: cyrus-sasl2 source: source-is-missing doc/html/_static/underscore.js line 
length is 519 characters (>512)
E: cyrus-sasl2 source: source-is-missing 
docsrc/exts/themes/cyrus/static/js/modernizr.min.js
E: cyrus-sasl2 source: source-is-missing 
docsrc/exts/themes/sphinx_rtd_theme/static/js/modernizr.min.js

** Affects: cyrus-sasl2 (Ubuntu)
 Importance: Medium
 Status: Triaged

** Summary changed:

- Build docs with sphinx
+ Fix sphinx doc building

** Changed in: cyrus-sasl2 (Ubuntu)
   Status: New => Triaged

** Changed in: cyrus-sasl2 (Ubuntu)
   Importance: Undecided => Medium

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

Title:
  Fix sphinx doc building

Status in cyrus-sasl2 package in Ubuntu:
  Triaged

Bug description:
  This basically the same bug as #1894907, but there I decided to
  disable docs rebuilding, after checking that none of the patches were
  against the docs source.

  Furthermore, we should probably fix these lintian issues:

  E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/developer.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
  E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/download.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
  E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/genindex.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
  E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/getsasl.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
  E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/index.html You may use the libjs-mathjax package. 
(https://cdn.mathjax.org/mathjax/latest/mathjax.js)
  E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/operations.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
  E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/packager.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
  E: cyrus-sasl2-doc: privacy-breach-uses-embedded-file 
usr/share/doc/cyrus-sasl2-doc/search.html You may use the libjs-mathjax 
package. (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
  E: 

[Touch-packages] [Bug 1894907] Re: FTBFS with sphinx 3.2

[Andreas Hasenack]

I filed https://bugs.launchpad.net/ubuntu/+source/cyrus-
sasl2/+bug/1898593 to properly fix the doc building with sphinx.

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

Title:
  FTBFS with sphinx 3.2

Status in Cyrus-sasl2:
  New
Status in cyrus-sasl2 package in Ubuntu:
  Triaged
Status in cyrus-sasl2 package in Debian:
  New

Bug description:
  cyrus-sasl2 ships with a sphinx extension to build its documentation,
  and this extension was based on a very old sphinx version. It no
  longer builds with sphinx 3.2.1 from groovy, failing in several
  places:

  a) "NoUri"
  Extension error:
  Could not import extension sphinxlocal.builders.manpage (exception: cannot 
import name 'NoUri' from 'sphinx.environment' 
(/usr/lib/python3/dist-packages/sphinx/environment/__init__.py))
  make[2]: *** [Makefile:1166: man/.sphinx-build.stamp] Error 2
  make[2]: Leaving directory 
'/home/ubuntu/deb/cyrus-sasl2-2.1.27+dfsg/build-heimdal'
  make[1]: *** [Makefile:686: all-recursive] Error 1
  make[1]: Leaving directory 
'/home/ubuntu/deb/cyrus-sasl2-2.1.27+dfsg/build-heimdal'
  make: *** [Makefile:556: all] Error 2

  Debian has a bug report already at https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=955095

  b) MACRO_DEF
  Extension error:
  Could not import extension sphinxlocal.builders.manpage (exception: cannot 
import name 'MACRO_DEF' from 'sphinx.writers.manpage' 
(/usr/lib/python3/dist-packages/sphinx/writers/manpage.py))
  make[4]: *** [Makefile:1166: man/.sphinx-build.stamp] Error 2
  make[4]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
  make[3]: *** [Makefile:686: all-recursive] Error 1
  make[3]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
  make[2]: *** [Makefile:556: all] Error 2
  make[2]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
  dh_auto_build: error: cd build-heimdal && make -j4 
sasldir=/usr/lib/x86_64-linux-gnu/sasl2 returned exit code 2
  make[1]: *** [debian/rules:164: override_dh_auto_build] Error 25
  make[1]: Leaving directory '/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2'
  make: *** [debian/rules:122: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/cyrus-sasl2/+bug/1894907/+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 1894907] Re: FTBFS with sphinx 3.2

[Andreas Hasenack]

I got as far as this collection of patches: 
https://paste.ubuntu.com/p/wvRzpByDXT/ :
--- a/docsrc/exts/sphinxlocal/writers/manpage.py
+++ b/docsrc/exts/sphinxlocal/writers/manpage.py
@@ -14,7 +14,6 @@
 
 from docutils import nodes
 from sphinx.writers.manpage import (
-MACRO_DEF,
 ManualPageWriter,
 ManualPageTranslator as BaseTranslator
 )
@@ -73,9 +72,6 @@
 self._docinfo['version'] = builder.config.version
 self._docinfo['manual_group'] = builder.config.project
 
-# since self.append_header() is never called, need to do this here
-self.body.append(MACRO_DEF)
-
 # overwritten -- don't wrap literal_block with font calls
 self.defs['literal_block'] = ('.sp\n.nf\n', '\n.fi\n')
 
--- a/docsrc/exts/sphinxlocal/writers/manpage.py
+++ b/docsrc/exts/sphinxlocal/writers/manpage.py
@@ -13,6 +13,8 @@
 """
 
 from docutils import nodes
+from time import strftime
+
 from sphinx.writers.manpage import (
 ManualPageWriter,
 ManualPageTranslator as BaseTranslator
@@ -21,7 +23,6 @@
 
 from sphinx import addnodes
 from sphinx.locale import admonitionlabels, _
-from sphinx.util.osutil import ustrftime
 
 class CyrusManualPageWriter(ManualPageWriter):
 
@@ -66,7 +67,7 @@
 if builder.config.today:
 self._docinfo['date'] = builder.config.today
 else:
-self._docinfo['date'] = ustrftime(builder.config.today_fmt
+self._docinfo['date'] = strftime(builder.config.today_fmt
   or _('%B %d, %Y'))
 self._docinfo['copyright'] = builder.config.copyright
 self._docinfo['version'] = builder.config.version
diff --git a/docsrc/exts/sphinxlocal/roles/saslman.py 
b/docsrc/exts/sphinxlocal/roles/saslman.py
index f881d98f..bcafeece 100644
--- a/docsrc/exts/sphinxlocal/roles/saslman.py
+++ b/docsrc/exts/sphinxlocal/roles/saslman.py
@@ -18,7 +18,6 @@ from string import Template
 import re
 
 def setup(app):
-app.info('Initializing saslman plugin')
 app.add_crossref_type('saslman', 'saslman', '%s', nodes.generated)
 return
 
diff --git a/docsrc/exts/sphinxlocal/builders/manpage.py 
b/docsrc/exts/sphinxlocal/builders/manpage.py
index a6281f79..126839e0 100644
--- a/docsrc/exts/sphinxlocal/builders/manpage.py
+++ b/docsrc/exts/sphinxlocal/builders/manpage.py
@@ -21,7 +21,6 @@ from docutils.frontend import OptionParser
 from sphinx import addnodes
 from sphinx.errors import SphinxError
 from sphinx.builders import Builder
-from sphinx.environment import NoUri
 from sphinx.util.nodes import inline_all_toctrees
 from sphinx.util.console import bold, darkgreen
 from sphinx.writers.manpage import ManualPageWriter


That moves along a bit, but then fails with;
sed -e 's,[@]LIB_DOOR[@],,g' -e 's,[@]SASL_DL_LIB[@],-ldl,g' -e 
's,[@]LIBS[@],-lresolv ,g' -e 's,[@]VERSION[@],2.1.27,g' -e 
's,[@]libdir[@],/usr/lib/x86_64-linux-gnu,g' -e 's,[@]prefix[@],/usr,g' -e 
's,[@]exec_prefix[@],/usr,g' -e 's,[@]includedir[@],/usr/include,g' < 
../libsasl2.pc.in > libsasl2.pc
/usr/bin/sphinx-build -d docsrc/.doctrees -n -q -b cyrman ./docsrc ./man
WARNING: The config value `author' has type `list', defaults to `str'.
WARNING: The config value `epub_author' has type `str', defaults to `list'.
WARNING: The config value `epub_publisher' has type `str', defaults to `list'.

Extension error:
Handler  for event 
'config-inited' threw an exception (exception: 'list' object has no attribute 
'translate')
['The Cyrus Team']
make[4]: *** [Makefile:1166: man/.sphinx-build.stamp] Error 2
make[4]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
make[3]: *** [Makefile:686: all-recursive] Error 1
make[3]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
make[2]: *** [Makefile:556: all] Error 2
make[2]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
dh_auto_build: error: cd build-heimdal && make -j4 
sasldir=/usr/lib/x86_64-linux-gnu/sasl2 returned exit code 2
make[1]: *** [debian/rules:164: override_dh_auto_build] Error 25
make[1]: Leaving directory '/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2'
make: *** [debian/rules:122: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

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

Title:
  FTBFS with sphinx 3.2

Status in Cyrus-sasl2:
  New
Status in cyrus-sasl2 package in Ubuntu:
  Triaged
Status in cyrus-sasl2 package in Debian:
  New

Bug description:
  cyrus-sasl2 ships with a sphinx extension to build its documentation,
  and this extension was based on a very old sphinx version. It no
  longer builds with sphinx 3.2.1 from groovy, failing in several
  places:

  a) "NoUri"
  Extension error:
  Could not import extension sphinxlocal.builders.manpage (exception: 

[Touch-packages] [Bug 1895302] Re: groovy debootstrap leaves /e/d/motd-news.wasremoved around

[Andreas Hasenack]

I think the remaining scenario is (b) (look up in the bug description),
and (c) is just a wildcard scenario ("anything else I didn't think of").

For (b), I think the more likely case would be another base-files SRU without 
the fix from this bug here, and where the user would have:
- base-files installed
- motd-news-config NOT installed
- ubuntu-server NOT installed

In that scenario, the base-files postinst would create /etc/default
/motd-news.wasremoved, with the consequence that a follow-up install of
ubuntu-server/motd-news-config would install the motd-news config with
ENABLED=0 instead of ENABLED=1.

It's also possible the above would happen on a release upgrade, if only
base-files is installed to begin with. That would ugrade base-files to
the version in the next release, effectively behaving like just a base-
files upgrade, and create the .wasremoved file as well.

** Changed in: base-files (Ubuntu Xenial)
   Status: Incomplete => In Progress

** Changed in: base-files (Ubuntu Bionic)
   Status: Incomplete => In Progress

** Changed in: base-files (Ubuntu Focal)
   Status: Incomplete => In Progress

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

Title:
  groovy debootstrap leaves /e/d/motd-news.wasremoved around

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  In Progress
Status in base-files source package in Bionic:
  In Progress
Status in base-files source package in Focal:
  In Progress

Bug description:
  [Impact]
  A fresh install of base-files, like done when using debootstrap, using the 
base-files from the -updates repository (in the case of ubuntu stable 
releases), will leave an empty /etc/default/motd-news.wasremoved file. This 
file is an artifact of the mechanism used to handle a corner case in the 
previous SRU where it would signal the motd-news-config package to install 
/etc/default/motd-news with ENABLED=0. See testcases (h) and (i) in the 
previous base-files SRU at 
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888575 for details. 
In test case (i) it was acked that the empty .wasremoved file was lying around, 
but its impact was deemed not relevant (see [other info] item (a)).

  Another case where /etc/default/motd-news.wasremoved would be created
  when it shouldn't be is when you have just base-files installed (and
  no ubuntu-server or motd-news-config) and did a reinstall of base-
  files, or an upgrade. It would again touch /etc/default/motd-
  news.wasremoved.

  The consequence of having /etc/default/motd-news.wasremoved when it's
  unintended is that a follow-up install of ubuntu-server, or motd-news-
  config for that matter, will install /etc/default/motd-news with
  ENABLED=0 instead of ENABLED=1.

  This was the case of the groovy debootstrap which resulted in this bug
  being filed. While debootstrap won't mix multiple repositories (like
  release with updates), and thus this isn't easily a problem in
  released versions of ubuntu, the groovy case was the one that was
  doing a fresh install of base-files with the buggy touch /etc/default
  /motd-news.wasremoved, and a subsequent install of ubuntu-server left
  motd-news disabled in groovy images produced by such a method
  (debootstrap).

  These are the scenarios I was able to come up with in which a stable
  release could be affected by this bug:

  a) debootstrap with release and updates pocket enabled
  There are no config options that I'm aware of that would tell debootstrap to 
use multiple pockets when creating a chroot, but let's say it was done by 
hacking the script or something else. It would then be the same case as groovy 
until this fix: subsequent installations of ubuntu-server or motd-news-config 
would default to having motd-news disabled

  b) A system that has just base-files from the previous SRU installed,
  and no ubuntu-server and no motd-news-config. If base-files were
  updated again and without the fix presented here (let's say, another
  SRU instead of this one), it would create /etc/default/motd-
  news.wasremoved, and again, a subsequent install of ubuntu-server or
  motd-news-config would install motd-news in a disabled state

  c) Any other case where the postinst script of base-files is run again
  without the fix presented here, and when there is no /etc/default
  /motd-news{,.dpkg*} file present.

  To avoid creating /etc/default/motd-news.wasremoved when we shouldn't, the 
maintainer scripts were changed as follows:
  - motd-news-config postinst: always remove the .wasremoved file in configure 
if found, regardless if /etc/default/motd-news was sed'ed or not, or if we are 
upgrading or on a first install
  - base-files postinst: guard the creation of .wasremoved with:
    - Only during an upgrade
    - Only if ubuntu-server is installed (via a dpkg -l check)

  

[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

I meant, see *also* https://bugs.launchpad.net/bugs/1895302, no idea yet
if it's related.

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

Title:
  Split motd-news config into a new package

Status in base-files package in Ubuntu:
  Fix Released
Status in livecd-rootfs package in Ubuntu:
  Invalid
Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Released
Status in livecd-rootfs source package in Xenial:
  Triaged
Status in ubuntu-meta source package in Xenial:
  Fix Committed
Status in base-files source package in Bionic:
  Fix Released
Status in livecd-rootfs source package in Bionic:
  Invalid
Status in ubuntu-meta source package in Bionic:
  Fix Released
Status in base-files source package in Focal:
  Fix Released
Status in livecd-rootfs source package in Focal:
  Invalid
Status in ubuntu-meta source package in Focal:
  Fix Released
Status in base-files source package in Groovy:
  Fix Released
Status in livecd-rootfs source package in Groovy:
  Invalid
Status in ubuntu-meta source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.

  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config

  Care must be taken to preserve a changed /etc/default/motd-news when
  the upgrade installs the new motd-news-config package. For example, on
  a server that has set ENABLED=0 in /etc/default/motd-news and upgrades
  to the new base-files and ubuntu-server, and gets the new motd-config-
  news package, ENABLED=0 must remain set.

  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled

  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification

  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled

  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled

  e) removing motd-news-config will also remove ubuntu-server (since
  it's a depends, and not a recommends)

  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files

  g) Removing motd-news-server leaves /e/d/motd-news around; purging
  motd-news-server removes the /e/d/motd-news config file

  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0

  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled

  j) Perform a release upgrade from the previous ubuntu release to the
  one being tested while having ubuntu-server NOT installed (or use a
  desktop install). At the end, motd-news should be disabled. Verify
  with:

  $ sudo /etc/update-motd.d/50-motd-news --force
  $ (no output)

  k) Test that supporting changes for xenial are in place:

i) verify grub-legacy-ec2 is not in the xenial server seed
ii) verify that the rootfs manifest built from the ubuntu-cpc project 
contains the ubuntu-server package
iii) verify that images built from the ubuntu-cpc project which purge 
grub-legacy-ec2 have retained ubuntu-server

  [Regression Potential]
  This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
  a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 
the motd-news-config package when it is installed, otherwise this SRU would 
jsut re-enabled motd-news. This is handled in 

Re: [Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

ostinst, like this:
>   --- a/debian/postinst.in
>   +++ b/debian/postinst.in
>   @@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
>if [ ! -e ${motd_news_config} ]; then
>  if [ ! -e ${motd_news_config}.dpkg-remove ]; then
>if [ ! -e ${motd_news_config}.dpkg-backup ]; then
>   -  touch ${motd_news_config}.wasremoved
>   +  # The .wasremoved file only matters if ubuntu-server is installed,
>   +  # because that's what will pull in motd-news-config
>   +  if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
>   +touch ${motd_news_config}.wasremoved
>   +  fi
>fi
>  fi
>fi
>
>   But deemed it too risky, and not worth further potential regressions.
>   It seemed to work, though, at least for groovy.
>
>   b) Currently the xenial cloud images, with the exception of the AWS
>   one, do not have ubuntu-server installed. This means that this SRU
>   will disable motd-news on them, unless ubuntu-server was manually
>   installed for some reason. This includes LXD xenial images as well.
>
>   c) The new motd-news-config package has its d/control priority set to
>   "optional", so a release upgrade won't pick it up (presumably the same
>   applies to the installer). I've been told there are archive overrides
>   that might need updating as well: dear SRU team member, please check,
>   or ask an archive admin to check.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888575/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: distribution=ubuntu; sourcepackage=base-files;
> component=main; status=Fix Released; importance=Undecided; assignee=
> andr...@canonical.com;
> Launchpad-Bug: distribution=ubuntu; sourcepackage=livecd-rootfs;
> component=main; status=Invalid; importance=Undecided; assignee=None;
> Launchpad-Bug: distribution=ubuntu; sourcepackage=ubuntu-meta;
> component=main; status=Fix Released; importance=Undecided; assignee=
> andr...@canonical.com;
> Launchpad-Bug: distribution=ubuntu; distroseries=xenial;
> sourcepackage=base-files; component=main; status=Fix Released;
> importance=Undecided; assignee=andr...@canonical.com;
> Launchpad-Bug: distribution=ubuntu; distroseries=xenial;
> sourcepackage=livecd-rootfs; component=main; status=Triaged;
> importance=Undecided; assignee=None;
> Launchpad-Bug: distribution=ubuntu; distroseries=xenial;
> sourcepackage=ubuntu-meta; component=main; status=Fix Committed;
> importance=Undecided; assignee=andr...@canonical.com;
> Launchpad-Bug: distribution=ubuntu; distroseries=bionic;
> sourcepackage=base-files; component=main; status=Fix Released;
> importance=Undecided; assignee=andr...@canonical.com;
> Launchpad-Bug: distribution=ubuntu; distroseries=bionic;
> sourcepackage=livecd-rootfs; component=main; status=Invalid;
> importance=Undecided; assignee=None;
> Launchpad-Bug: distribution=ubuntu; distroseries=bionic;
> sourcepackage=ubuntu-meta; component=main; status=Fix Released;
> importance=Undecided; assignee=andr...@canonical.com;
> Launchpad-Bug: distribution=ubuntu; distroseries=focal;
> sourcepackage=base-files; component=main; status=Fix Released;
> importance=Undecided; assignee=andr...@canonical.com;
> Launchpad-Bug: distribution=ubuntu; distroseries=focal;
> sourcepackage=livecd-rootfs; component=main; status=Invalid;
> importance=Undecided; assignee=None;
> Launchpad-Bug: distribution=ubuntu; distroseries=focal;
> sourcepackage=ubuntu-meta; component=main; status=Fix Released;
> importance=Undecided; assignee=andr...@canonical.com;
> Launchpad-Bug: distribution=ubuntu; distroseries=groovy;
> sourcepackage=base-files; component=main; status=Fix Released;
> importance=Undecided; assignee=andr...@canonical.com;
> Launchpad-Bug: distribution=ubuntu; distroseries=groovy;
> sourcepackage=livecd-rootfs; component=main; status=Invalid;
> importance=Undecided; assignee=None;
> Launchpad-Bug: distribution=ubuntu; distroseries=groovy;
> sourcepackage=ubuntu-meta; component=main; status=Fix Released;
> importance=Undecided; assignee=andr...@canonical.com;
> Launchpad-Bug-Tags: verification-done-bionic verification-done-focal
> verification-needed verification-needed-xenial
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: ahasenack janitor mvo ogra sil2100 tjaalton
> vorlon
> Launchpad-Bug-Reporter: Andreas Hasenack (ahasenack)
> Launchpad-Bug-Modifier: Oliver Grawert (ogra)
> Launchpad-Message-Rationale: Subscriber
> Launchpad-Message-For: ahasenack
>

-- 
You received this bug notification because you are a member of Ubuntu
Touch 

[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

root@xenial-base-files:~# apt-cache policy ubuntu-server
ubuntu-server:
  Installed: 1.361.6
  Candidate: 1.361.6
  Version table:
 *** 1.361.6 500
500 http://br.archive.ubuntu.com/ubuntu xenial-proposed/main amd64 
Packages
100 /var/lib/dpkg/status
 1.361.5 500
500 http://br.archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
 1.361 500
500 http://br.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

ubuntu-server 1.361.5, currently in xenial-updates, has grub-legacy-ec2
in the Depends line:

root@xenial-base-files:~# apt-cache show ubuntu-server=1.361.5|grep ec2
Depends: acpid, apport, at, bcache-tools, btrfs-tools, byobu, 
cloud-guest-utils, cloud-initramfs-copymods, cloud-initramfs-dyn-netconf, curl, 
ethtool, fonts-ubuntu-font-family-console, git, grub-legacy-ec2, ifenslave, 
lvm2, mdadm, open-iscsi, open-vm-tools, overlayroot, patch, screen, 
software-properties-common, sosreport, tmux, ubuntu-cloudimage-keyring, 
update-notifier-common, vim, vlan, xfsprogs, motd-news-config

But ubuntu-server 1.361.6 from proposed does not, as expected:
root@xenial-base-files:~# apt-cache show ubuntu-server=1.361.6|grep ec2
root@xenial-base-files:~#

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

Title:
  Split motd-news config into a new package

Status in base-files package in Ubuntu:
  Fix Released
Status in livecd-rootfs package in Ubuntu:
  Invalid
Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Released
Status in livecd-rootfs source package in Xenial:
  Triaged
Status in ubuntu-meta source package in Xenial:
  Fix Committed
Status in base-files source package in Bionic:
  Fix Released
Status in livecd-rootfs source package in Bionic:
  Invalid
Status in ubuntu-meta source package in Bionic:
  Fix Released
Status in base-files source package in Focal:
  Fix Released
Status in livecd-rootfs source package in Focal:
  Invalid
Status in ubuntu-meta source package in Focal:
  Fix Released
Status in base-files source package in Groovy:
  Fix Released
Status in livecd-rootfs source package in Groovy:
  Invalid
Status in ubuntu-meta source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.

  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config

  Care must be taken to preserve a changed /etc/default/motd-news when
  the upgrade installs the new motd-news-config package. For example, on
  a server that has set ENABLED=0 in /etc/default/motd-news and upgrades
  to the new base-files and ubuntu-server, and gets the new motd-config-
  news package, ENABLED=0 must remain set.

  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled

  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification

  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled

  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled

  e) removing motd-news-config will also remove ubuntu-server (since
  it's a depends, and not a recommends)

  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files

  g) Removing motd-news-server leaves /e/d/motd-news around; purging
  motd-news-server removes the /e/d/motd-news config file

  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0

  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled

  j) Perform a 

[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

Sorry again, I jumped he gun. I don't know how to do k-ii and k-iii, I
thought (k) was one of the original test cases.

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

Title:
  Split motd-news config into a new package

Status in base-files package in Ubuntu:
  Fix Released
Status in livecd-rootfs package in Ubuntu:
  Invalid
Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Released
Status in livecd-rootfs source package in Xenial:
  Triaged
Status in ubuntu-meta source package in Xenial:
  Fix Committed
Status in base-files source package in Bionic:
  Fix Released
Status in livecd-rootfs source package in Bionic:
  Invalid
Status in ubuntu-meta source package in Bionic:
  Fix Released
Status in base-files source package in Focal:
  Fix Released
Status in livecd-rootfs source package in Focal:
  Invalid
Status in ubuntu-meta source package in Focal:
  Fix Released
Status in base-files source package in Groovy:
  Fix Released
Status in livecd-rootfs source package in Groovy:
  Invalid
Status in ubuntu-meta source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.

  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config

  Care must be taken to preserve a changed /etc/default/motd-news when
  the upgrade installs the new motd-news-config package. For example, on
  a server that has set ENABLED=0 in /etc/default/motd-news and upgrades
  to the new base-files and ubuntu-server, and gets the new motd-config-
  news package, ENABLED=0 must remain set.

  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled

  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification

  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled

  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled

  e) removing motd-news-config will also remove ubuntu-server (since
  it's a depends, and not a recommends)

  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files

  g) Removing motd-news-server leaves /e/d/motd-news around; purging
  motd-news-server removes the /e/d/motd-news config file

  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0

  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled

  j) Perform a release upgrade from the previous ubuntu release to the
  one being tested while having ubuntu-server NOT installed (or use a
  desktop install). At the end, motd-news should be disabled. Verify
  with:

  $ sudo /etc/update-motd.d/50-motd-news --force
  $ (no output)

  k) Test that supporting changes for xenial are in place:

i) verify grub-legacy-ec2 is not in the xenial server seed
ii) verify that the rootfs manifest built from the ubuntu-cpc project 
contains the ubuntu-server package
iii) verify that images built from the ubuntu-cpc project which purge 
grub-legacy-ec2 have retained ubuntu-server

  [Regression Potential]
  This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
  a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 
the motd-news-config package when it is installed, otherwise this SRU would 
jsut re-enabled motd-news. This 

[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

Sorry, I wasn't clear. I'll re-run (k) with ubuntu-meta from xenial
proposed now, with base-files from xenial-updates.

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

Title:
  Split motd-news config into a new package

Status in base-files package in Ubuntu:
  Fix Released
Status in livecd-rootfs package in Ubuntu:
  Invalid
Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Released
Status in livecd-rootfs source package in Xenial:
  Triaged
Status in ubuntu-meta source package in Xenial:
  Fix Committed
Status in base-files source package in Bionic:
  Fix Released
Status in livecd-rootfs source package in Bionic:
  Invalid
Status in ubuntu-meta source package in Bionic:
  Fix Released
Status in base-files source package in Focal:
  Fix Released
Status in livecd-rootfs source package in Focal:
  Invalid
Status in ubuntu-meta source package in Focal:
  Fix Released
Status in base-files source package in Groovy:
  Fix Released
Status in livecd-rootfs source package in Groovy:
  Invalid
Status in ubuntu-meta source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.

  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config

  Care must be taken to preserve a changed /etc/default/motd-news when
  the upgrade installs the new motd-news-config package. For example, on
  a server that has set ENABLED=0 in /etc/default/motd-news and upgrades
  to the new base-files and ubuntu-server, and gets the new motd-config-
  news package, ENABLED=0 must remain set.

  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled

  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification

  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled

  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled

  e) removing motd-news-config will also remove ubuntu-server (since
  it's a depends, and not a recommends)

  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files

  g) Removing motd-news-server leaves /e/d/motd-news around; purging
  motd-news-server removes the /e/d/motd-news config file

  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0

  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled

  j) Perform a release upgrade from the previous ubuntu release to the
  one being tested while having ubuntu-server NOT installed (or use a
  desktop install). At the end, motd-news should be disabled. Verify
  with:

  $ sudo /etc/update-motd.d/50-motd-news --force
  $ (no output)

  k) Test that supporting changes for xenial are in place:

i) verify grub-legacy-ec2 is not in the xenial server seed
ii) verify that the rootfs manifest built from the ubuntu-cpc project 
contains the ubuntu-server package
iii) verify that images built from the ubuntu-cpc project which purge 
grub-legacy-ec2 have retained ubuntu-server

  [Regression Potential]
  This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
  a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 
the motd-news-config package when it is installed, otherwise this SRU would 
jsut re-enabled motd-news. This 

[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

I have another upload for base-files, for bug #1895302 (see comment
#23). I can re-run the (k) test case, and of course the testcase for
that bug specifically.

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

Title:
  Split motd-news config into a new package

Status in base-files package in Ubuntu:
  Fix Released
Status in livecd-rootfs package in Ubuntu:
  Invalid
Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Released
Status in livecd-rootfs source package in Xenial:
  Triaged
Status in ubuntu-meta source package in Xenial:
  Fix Committed
Status in base-files source package in Bionic:
  Fix Released
Status in livecd-rootfs source package in Bionic:
  Invalid
Status in ubuntu-meta source package in Bionic:
  Fix Released
Status in base-files source package in Focal:
  Fix Released
Status in livecd-rootfs source package in Focal:
  Invalid
Status in ubuntu-meta source package in Focal:
  Fix Released
Status in base-files source package in Groovy:
  Fix Released
Status in livecd-rootfs source package in Groovy:
  Invalid
Status in ubuntu-meta source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.

  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config

  Care must be taken to preserve a changed /etc/default/motd-news when
  the upgrade installs the new motd-news-config package. For example, on
  a server that has set ENABLED=0 in /etc/default/motd-news and upgrades
  to the new base-files and ubuntu-server, and gets the new motd-config-
  news package, ENABLED=0 must remain set.

  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled

  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification

  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled

  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled

  e) removing motd-news-config will also remove ubuntu-server (since
  it's a depends, and not a recommends)

  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files

  g) Removing motd-news-server leaves /e/d/motd-news around; purging
  motd-news-server removes the /e/d/motd-news config file

  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0

  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled

  j) Perform a release upgrade from the previous ubuntu release to the
  one being tested while having ubuntu-server NOT installed (or use a
  desktop install). At the end, motd-news should be disabled. Verify
  with:

  $ sudo /etc/update-motd.d/50-motd-news --force
  $ (no output)

  k) Test that supporting changes for xenial are in place:

i) verify grub-legacy-ec2 is not in the xenial server seed
ii) verify that the rootfs manifest built from the ubuntu-cpc project 
contains the ubuntu-server package
iii) verify that images built from the ubuntu-cpc project which purge 
grub-legacy-ec2 have retained ubuntu-server

  [Regression Potential]
  This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
  a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 
the motd-news-config package when it is installed, otherwise this SRU 

[Touch-packages] [Bug 1895302] Re: groovy debootstrap leaves /e/d/motd-news.wasremoved around

[Andreas Hasenack]

** Description changed:

  [Impact]
  A fresh install of base-files, like done when using debootstrap, using the 
base-files from the -updates repository (in the case of ubuntu stable 
releases), will leave an empty /etc/default/motd-news.wasremoved file. This 
file is an artifact of the mechanism used to handle a corner case in the 
previous SRU where it would signal the motd-news-config package to install 
/etc/default/motd-news with ENABLED=0. See testcases (h) and (i) in the 
previous base-files SRU at 
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888575 for details. 
In test case (i) it was acked that the empty .wasremoved file was lying around, 
but its impact was deemed not relevant (see [other info] item (a)).
  
  Another case where /etc/default/motd-news.wasremoved would be created
  when it shouldn't be is when you have just base-files installed (and no
  ubuntu-server or motd-news-config) and did a reinstall of base-files, or
  an upgrade. It would again touch /etc/default/motd-news.wasremoved.
  
  The consequence of having /etc/default/motd-news.wasremoved when it's
  unintended is that a follow-up install of ubuntu-server, or motd-news-
  config for that matter, will install /etc/default/motd-news with
  ENABLED=0 instead of ENABLED=1.
  
  This was the case of the groovy debootstrap which resulted in this bug
  being filed. While debootstrap won't mix multiple repositories (like
  release with updates), and thus this isn't easily a problem in released
  versions of ubuntu, the groovy case was the one that was doing a fresh
  install of base-files with the buggy touch /etc/default/motd-
  news.wasremoved, and a subsequent install of ubuntu-server left motd-
  news disabled in groovy images produced by such a method (debootstrap).
  
  These are the scenarios I was able to come up with in which a stable
  release could be affected by this bug:
  
  a) debootstrap with release and updates pocket enabled
  There are no config options that I'm aware of that would tell debootstrap to 
use multiple pockets when creating a chroot, but let's say it was done by 
hacking the script or something else. It would then be the same case as groovy 
until this fix: subsequent installations of ubuntu-server or motd-news-config 
would default to having motd-news disabled
  
  b) A system that has just base-files from the previous SRU installed,
  and no ubuntu-server and no motd-news-config. If base-files were updated
  again and without the fix presented here (let's say, another SRU instead
  of this one), it would create /etc/default/motd-news.wasremoved, and
  again, a subsequent install of ubuntu-server or motd-news-config would
  install motd-news in a disabled state
  
  c) Any other case where the postinst script of base-files is run again
  without the fix presented here, and when there is no /etc/default/motd-
  news{,.dpkg*} file present.
  
  To avoid creating /etc/default/motd-news.wasremoved when we shouldn't, the 
maintainer scripts were changed as follows:
  - motd-news-config postinst: always remove the .wasremoved file in configure 
if found, regardless if /etc/default/motd-news was sed'ed or not, or if we are 
upgrading or on a first install
  - base-files postinst: guard the creation of .wasremoved with:
    - Only during an upgrade
    - Only if ubuntu-server is installed (via a dpkg -l check)
  
  [Test Case]
  * On the system under test, remove motd-news-config and ubuntu-server if they 
are installed, and keep base-files from the update pocket. Something like this:
  sudo apt update && sudo apt dist-upgrade -y
  sudo apt purge motd-news-config ubuntu-server
  apt-cache policy base-files <-- to verify it's from updates
  
  * In this scenario, you should have no /etc/default/motd* files:
  $ ll /etc/default/motd*
  ls: cannot access '/etc/default/motd*': No such file or directory
  
  * reinstall base-files:
  sudo apt install --reinstall base-files
  
  * Before this SRU, this would create /etc/default/motd-news.wasremoved:
  $ ll /etc/default/motd*
  -rw-r--r-- 1 root root 0 Sep 16 20:24 /etc/default/motd-news.wasremoved
  
  With the package from proposed for this SRU installed, no such file is 
created:
  $ ll /etc/default/motd*
  ls: cannot access '/etc/default/motd*': No such file or directory
  
  [Regression Potential]
  This SRU is further changing maintainer scripts, to address an issue in the 
previous maintainer script. Should there be new regressions or new issues, it 
might get harder and harder to fix them.
  
  I did wonder about the `dpkg -l` call in base-files' postinst. I worried
  about locks, or pre-dependencies, but dpkg was already being used in
  this script, although not with -l (list), just a version comparison. But
  at least it's already installed.
  
  My other worry was with the dpkg -l output and which flags I should
  check to determine if ubuntu-server was installed. "^ii" doesn't work,
  because ubuntu-server might be being upgraded in the 

[Touch-packages] [Bug 1895302] Re: groovy debootstrap leaves /e/d/motd-news.wasremoved around

[Andreas Hasenack]

** Description changed:

  [Impact]
  A fresh install of base-files, like done when using debootstrap, using the 
base-files from the -updates repository (in the case of ubuntu stable 
releases), will leave an empty /etc/default/motd-news.wasremoved file. This 
file is an artifact of the mechanism used to handle a corner case in the 
previous SRU where it would signal the motd-news-config package to install 
/etc/default/motd-news with ENABLED=0. See testcases (h) and (i) in the 
previous base-files SRU at 
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888575 for details. 
In test case (i) it was acked that the empty .wasremoved file was lying around, 
but its impact was deemed not relevant (see [other info] item (a)).
  
  Another case where /etc/default/motd-news.wasremoved would be created
  when it shouldn't be is when you have just base-files installed (and no
  ubuntu-server or motd-news-config) and did a reinstall of base-files, or
  an upgrade. It would again touch /etc/default/motd-news.wasremoved.
  
  The consequence of having /etc/default/motd-news.wasremoved when it's
  unintended is that a follow-up install of ubuntu-server, or motd-news-
  config for that matter, will install /etc/default/motd-news with
  ENABLED=0 instead of ENABLED=1.
  
  This was the case of the groovy debootstrap which resulted in this bug
  being filed. While debootstrap won't mix multiple repositories (like
  release with updates), and thus this isn't easily a problem in released
  versions of ubuntu, the groovy case was the one that was doing a fresh
  install of base-files with the buggy touch /etc/default/motd-
  news.wasremoved, and a subsequent install of ubuntu-server left motd-
  news disabled in groovy images produced by such a method (debootstrap).
  
  These are the scenarios I was able to come up with in which a stable
  release could be affected by this bug:
  
  a) debootstrap with release and updates pocket enabled
  There are no config options that I'm aware of that would tell debootstrap to 
use multiple pockets when creating a chroot, but let's say it was done by 
hacking the script or something else. It would then be the same case as groovy 
until this fix: subsequent installations of ubuntu-server or motd-news-config 
would default to having motd-news disabled
  
  b) A system that has just base-files from the previous SRU installed,
  and no ubuntu-server and no motd-news-config. If base-files were updated
  again and without the fix presented here (let's say, another SRU instead
  of this one), it would create /etc/default/motd-news.wasremoved, and
  again, a subsequent install of ubuntu-server or motd-news-config would
  install motd-news in a disabled state
  
  c) Any other case where the postinst script of base-files is run again
  without the fix presented here, and when there is no /etc/default/motd-
  news{,.dpkg*} file present.
  
  To avoid creating /etc/default/motd-news.wasremoved when we shouldn't, the 
maintainer scripts were changed as follows:
  - motd-news-config postinst: always remove the .wasremoved file in configure 
if found, regardless if /etc/default/motd-news was sed'ed or not, or if we are 
upgrading or on a first install
  - base-files postinst: guard the creation of .wasremoved with:
    - Only during an upgrade
    - Only if ubuntu-server is installed (via a dpkg -l check)
  
  [Test Case]
  * On the system under test, remove motd-news-config and ubuntu-server if they 
are installed, and keep base-files from the update pocket. Something like this:
- sudo apt update
+ sudo apt update && sudo apt dist-upgrade -y
  sudo apt purge motd-news-config ubuntu-server
  apt-cache policy base-files <-- to verify it's from updates
  
  * In this scenario, you should have no /etc/default/motd* files:
  $ ll /etc/default/motd*
  ls: cannot access '/etc/default/motd*': No such file or directory
  
  * reinstall base-files:
  sudo apt install --reinstall base-files
  
  * Before this SRU, this would create /etc/default/motd-news.wasremoved:
  $ ll /etc/default/motd*
  -rw-r--r-- 1 root root 0 Sep 16 20:24 /etc/default/motd-news.wasremoved
  
  With the package from proposed for this SRU installed, no such file is 
created:
  $ ll /etc/default/motd*
  ls: cannot access '/etc/default/motd*': No such file or directory
  
  [Regression Potential]
  This SRU is further changing maintainer scripts, to address an issue in the 
previous maintainer script. Should there be new regressions or new issues, it 
might get harder and harder to fix them.
  
  I did wonder about the `dpkg -l` call in base-files' postinst. I worried
  about locks, or pre-dependencies, but dpkg was already being used in
  this script, although not with -l (list), just a version comparison. But
  at least it's already installed.
  
  My other worry was with the dpkg -l output and which flags I should
  check to determine if ubuntu-server was installed. "^ii" doesn't work,
  because ubuntu-server might be being 

[Touch-packages] [Bug 1895302] Re: groovy debootstrap leaves /e/d/motd-news.wasremoved around

[Andreas Hasenack]

s:
  sudo apt update
  sudo apt purge motd-news-config ubuntu-server
  apt-cache policy base-files <-- to verify it's from updates
  
  * In this scenario, you should have no /etc/default/motd* files:
  $ ll /etc/default/motd*
  ls: cannot access '/etc/default/motd*': No such file or directory
  
  * reinstall base-files:
  sudo apt install --reinstall base-files
  
  * Before this SRU, this would create /etc/default/motd-news.wasremoved:
  $ ll /etc/default/motd*
  -rw-r--r-- 1 root root 0 Sep 16 20:24 /etc/default/motd-news.wasremoved
  
  With the package from proposed for this SRU installed, no such file is 
created:
  $ ll /etc/default/motd*
  ls: cannot access '/etc/default/motd*': No such file or directory
  
  [Regression Potential]
  This SRU is further changing maintainer scripts, to address an issue in the 
previous maintainer script. Should there be new regressions or new issues, it 
might get harder and harder to fix them.
  
  I did wonder about the `dpkg -l` call in base-files' postinst. I worried
  about locks, or pre-dependencies, but dpkg was already being used in
  this script, although not with -l (list), just a version comparison. But
  at least it's already installed.
  
  My other worry was with the dpkg -l output and which flags I should
  check to determine if ubuntu-server was installed. "^ii" doesn't work,
  because ubuntu-server might be being upgraded in the same apt
  transaction, but ^i seemed good enough. Furthermore, I changed the check
  for a package name that doesn't exist, to see if dpkg -l would complain
  and fail the whole script (which runs with set -e), but it was ok and
  just behaved as if the package wasn't installed, which is what we need.
  
  [Other Info]
+ The previous SRU at 
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888575 and its 
attached merge proposals has more detailed info about the history of this 
motd-news split, and things that were considered.
  
-  * Anything else you think is useful to include
-  * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
-  * and address these questions in advance
+ Manually, I used debootstrap with --make-tarball, replace the base-files
+ deb, and --unpack-tarball, to simulate debootstrap with an updated base-
+ files, to confirm this change here would fix the debootstrap problem,
+ and it worked. But I deemed it too complicated to describe as a testcase
+ for this SRU. If you, dear SRU reviewer, would prefer this test to be
+ added, please let me know.
  
  [Original Description]
  
  When debootstrapping groovy, we see an empty /etc/default/motd-
  news.wasremoved file.
  
  - groovy: base-files 11ubuntu12
  -rw-r--r-- 1 root root 0 set 11 10:20 /etc/default/motd-news.wasremoved
  
  If motd-news-config is later installed, maybe via ubuntu-server, then
  the presence of this file will disable motd-news by default, which is
  unintended as it's meant to be enabled on a server.

** Also affects: base-files (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: base-files (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: base-files (Ubuntu Xenial)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: base-files (Ubuntu Bionic)
     Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: base-files (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: base-files (Ubuntu Bionic)
   Status: New => In Progress

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

Title:
  groovy debootstrap leaves /e/d/motd-news.wasremoved around

Status in base-files package in Ubuntu:
  In Progress
Status in base-files source package in Xenial:
  In Progress
Status in base-files source package in Bionic:
  In Progress
Status in base-files source package in Focal:
  In Progress

Bug description:
  [Impact]
  A fresh install of base-files, like done when using debootstrap, using the 
base-files from the -updates repository (in the case of ubuntu stable 
releases), will leave an empty /etc/default/motd-news.wasremoved file. This 
file is an artifact of the mechanism used to handle a corner case in the 
previous SRU where it would signal the motd-news-config package to install 
/etc/default/motd-news with ENABLED=0. See testcases (h) and (i) in the 
previous base-files SRU at 
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888575 for details. 
In test case (i) it was acked that the empty .wasremoved file was lying around, 
but its impact was deemed not relevant (see [other info] item (a)).

  Another case where /etc/default/motd-news.wasremoved would be created
  when it shouldn't be is when you have just base-files installed (and
  no ubuntu-server or motd-news-config) and did a reinstall of base-
  files, or an upgr

[Touch-packages] [Bug 1895302] Re: groovy debootstrap leaves /e/d/motd-news.wasremoved around

[Andreas Hasenack]

** Description changed:

  [Impact]
  A fresh install of base-files, like done when using debootstrap, using the 
base-files from the -updates repository (in the case of ubuntu stable 
releases), will leave an empty /etc/default/motd-news.wasremoved file. This 
file is an artifact of the mechanism used to handle a corner case in the 
previous SRU where it would signal the motd-news-config package to install 
/etc/default/motd-news with ENABLED=0. See testcases (h) and (i) in the 
previous base-files SRU at 
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888575 for details. 
In test case (i) it was acked that the empty .wasremoved file was lying around, 
but its impact was deemed not relevant (see [other info] item (a)).
  
  Another case where /etc/default/motd-news.wasremoved would be created
  when it shouldn't be is when you have just base-files installed (and no
  ubuntu-server or motd-news-config) and did a reinstall of base-files, or
  an upgrade. It would again touch /etc/default/motd-news.wasremoved.
  
  The consequence of having /etc/default/motd-news.wasremoved when it's
  unintended is that a follow-up install of ubuntu-server, or motd-news-
  config for that matter, will install /etc/default/motd-news with
  ENABLED=0 instead of ENABLED=1.
  
  This was the case of the groovy debootstrap which resulted in this bug
  being filed. While debootstrap won't mix multiple repositories (like
  release with updates), and thus this isn't easily a problem in released
  versions of ubuntu, the groovy case was the one that was doing a fresh
  install of base-files with the buggy touch /etc/default/motd-
  news.wasremoved, and a subsequent install of ubuntu-server left motd-
  news disabled in groovy images produced by such a method (debootstrap).
  
  These are the scenarios I was able to come up with in which a stable
  release could be affected by this bug:
  
  a) debootstrap with release and updates pocket enabled
  There are no config options that I'm aware of that would tell debootstrap to 
use multiple pockets when creating a chroot, but let's say it was done by 
hacking the script or something else. It would then be the same case as groovy 
until this fix: subsequent installations of ubuntu-server or motd-news-config 
would default to having motd-news disabled
  
  b) A system that has just base-files from the previous SRU installed,
  and no ubuntu-server and no motd-news-config. If base-files were updated
  again and without the fix presented here (let's say, another SRU instead
  of this one), it would create /etc/default/motd-news.wasremoved, and
  again, a subsequent install of ubuntu-server or motd-news-config would
  install motd-news in a disabled state
  
  c) Any other case where the postinst script of base-files is run again
  without the fix presented here, and when there is no /etc/default/motd-
  news{,.dpkg*} file present.
  
  To avoid creating /etc/default/motd-news.wasremoved when we shouldn't, the 
maintainer scripts were changed as follows:
  - motd-news-config postinst: always remove the .wasremoved file in configure 
if found, regardless if /etc/default/motd-news was sed'ed or not, or if we are 
upgrading or on a first install
  - base-files postinst: guard the creation of .wasremoved with:
-   - Only during an upgrade
-   - Only if ubuntu-server is installed (via a dpkg -l check)
- 
+   - Only during an upgrade
+   - Only if ubuntu-server is installed (via a dpkg -l check)
  
  [Test Case]
+ * On the system under test, remove motd-news-config and ubuntu-server if they 
are installed, and keep base-files from the update pocket. Something like this:
+ sudo apt update
+ sudo apt purge motd-news-config ubuntu-server
+ apt-cache policy base-files <-- to verify it's from updates
  
-  * detailed instructions how to reproduce the bug
+ * In this scenario, you should have no /etc/default/motd* files:
+ $ ll /etc/default/motd*
+ ls: cannot access '/etc/default/motd*': No such file or directory
  
-  * these should allow someone who is not familiar with the affected
-    package to reproduce the bug and verify that the updated package fixes
-    the problem.
+ * reinstall base-files:
+ sudo apt install --reinstall base-files
+ 
+ * Before this SRU, this would create /etc/default/motd-news.wasremoved:
+ $ ll /etc/default/motd*
+ -rw-r--r-- 1 root root 0 Sep 16 20:24 /etc/default/motd-news.wasremoved
+ 
+ With the package from proposed for this SRU installed, no such file is 
created:
+ $ ll /etc/default/motd*
+ ls: cannot access '/etc/default/motd*': No such file or directory
+ 
  
  [Regression Potential]
  
   * discussion of how regressions are most likely to manifest as a result
  of this change.
  
   * It is assumed that any SRU candidate patch is well-tested before
     upload and has a low overall risk of regression, but it's important
     to make the effort to think about what ''could'' happen in the
     event of a regression.
  
   * This both shows the SRU team 

[Touch-packages] [Bug 1895302] Re: groovy debootstrap leaves /e/d/motd-news.wasremoved around

[Andreas Hasenack]

** Description changed:

  [Impact]
- A fresh install of base-files, like done when using debootstrap, using the 
base-files from the -updates repository (in the case of ubuntu stable 
releases), will leave an empty /etc/default/motd-news.wasremoved file. This 
file is an artifact of the mechanism used to handle a corner case in the 
previous SRU where it would signal the motd-news-config package to install 
/etc/default/motd-news with ENABLED=0. See testcases (h) and (i) in the 
previous base-files SRU at 
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888575 for details. 
In test case (i) it was acked that the empty .wasremoved file was lying around, 
but its impact was deemed low (see [other info] item (a)).
+ A fresh install of base-files, like done when using debootstrap, using the 
base-files from the -updates repository (in the case of ubuntu stable 
releases), will leave an empty /etc/default/motd-news.wasremoved file. This 
file is an artifact of the mechanism used to handle a corner case in the 
previous SRU where it would signal the motd-news-config package to install 
/etc/default/motd-news with ENABLED=0. See testcases (h) and (i) in the 
previous base-files SRU at 
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888575 for details. 
In test case (i) it was acked that the empty .wasremoved file was lying around, 
but its impact was deemed not relevant (see [other info] item (a)).
  
  Another case where /etc/default/motd-news.wasremoved would be created
  when it shouldn't be is when you have just base-files installed (and no
  ubuntu-server or motd-news-config) and did a reinstall of base-files, or
  an upgrade. It would again touch /etc/default/motd-news.wasremoved.
  
  The consequence of having /etc/default/motd-news.wasremoved when it's
  unintended is that a follow-up install of ubuntu-server, or motd-news-
  config for that matter, will install /etc/default/motd-news with
  ENABLED=0 instead of ENABLED=1.
  
  This was the case of the groovy debootstrap which resulted in this bug
  being filed. While debootstrap won't mix multiple repositories (like
- release with updates), and thus this isn't strictly a problem in
- released versions of ubuntu, the groovy case was the one that was doing
- a fresh install of base-files with the buggy touch /etc/default/motd-
+ release with updates), and thus this isn't easily a problem in released
+ versions of ubuntu, the groovy case was the one that was doing a fresh
+ install of base-files with the buggy touch /etc/default/motd-
  news.wasremoved, and a subsequent install of ubuntu-server left motd-
  news disabled in groovy images produced by such a method (debootstrap).
  
- For stable releases, the impact is lessened because debootstrap will
- grab the release pocket for its job, and base-files from that pocket, in
- all ubuntu releases other than groovy, does not have the code that
- creates /etc/default/motd-news.wasremoved.
- 
- There are two ways this can affect a stable release of ubuntu:
+ These are the scenarios I was able to come up with in which a stable
+ release could be affected by this bug:
  
  a) debootstrap with release and updates pocket enabled
- There are no config options that I'm aware of that would tell debootstrap to 
use multiple pockets when creating a chroot, but let's say it was done. In this 
case, it would be the same case as groovy was until this fix: subsequent 
installations of ubuntu-server or motd-news-config would default to having 
motd-news disabled
+ There are no config options that I'm aware of that would tell debootstrap to 
use multiple pockets when creating a chroot, but let's say it was done by 
hacking the script or something else. It would then be the same case as groovy 
until this fix: subsequent installations of ubuntu-server or motd-news-config 
would default to having motd-news disabled
  
  b) A system that has just base-files from the previous SRU installed,
  and no ubuntu-server and no motd-news-config. If base-files were updated
- again, and without the fix presented here, it would create /etc/default
- /motd-news.wasremoved, and again, a subsequent install of ubuntu-server
- or motd-news-config would install motd-news in a disabled state
+ again and without the fix presented here (let's say, another SRU instead
+ of this one), it would create /etc/default/motd-news.wasremoved, and
+ again, a subsequent install of ubuntu-server or motd-news-config would
+ install motd-news in a disabled state
  
  c) Any other case where the postinst script of base-files is run again
  without the fix presented here, and when there is no /etc/default/motd-
  news{,.dpkg*} file present.
+ 
+ To avoid creating /etc/default/motd-news.wasremoved when we shouldn't, the 
maintainer scripts were changed as follows:
+ - motd-news-config postinst: always remove the .wasremoved file in configure 
if found, regardless if /etc/default/motd-news was sed'ed or not, or if we are 
upgrading or on a 

[Touch-packages] [Bug 1895302] Re: groovy debootstrap leaves /e/d/motd-news.wasremoved around

[Andreas Hasenack]

** Description changed:

  [Impact]
  A fresh install of base-files, like done when using debootstrap, using the 
base-files from the -updates repository (in the case of ubuntu stable 
releases), will leave an empty /etc/default/motd-news.wasremoved file. This 
file is an artifact of the mechanism used to handle a corner case in the 
previous SRU where it would signal the motd-news-config package to install 
/etc/default/motd-news with ENABLED=0. See testcases (h) and (i) in the 
previous base-files SRU at 
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888575 for details. 
In test case (i) it was acked that the empty .wasremoved file was lying around, 
but its impact was deemed low (see [other info] item (a)).
  
  Another case where /etc/default/motd-news.wasremoved would be created
  when it shouldn't be is when you have just base-files installed (and no
  ubuntu-server or motd-news-config) and did a reinstall of base-files, or
  an upgrade. It would again touch /etc/default/motd-news.wasremoved.
  
  The consequence of having /etc/default/motd-news.wasremoved when it's
  unintended is that a follow-up install of ubuntu-server, or motd-news-
  config for that matter, will install /etc/default/motd-news with
  ENABLED=0 instead of ENABLED=1.
  
  This was the case of the groovy debootstrap which resulted in this bug
  being filed. While debootstrap won't mix multiple repositories (like
  release with updates), and thus this isn't strictly a problem in
  released versions of ubuntu, the groovy case was the one that was doing
  a fresh install of base-files with the buggy touch /etc/default/motd-
  news.wasremoved, and a subsequent install of ubuntu-server left motd-
  news disabled in groovy images produced by such a method (debootstrap).
  
  For stable releases, the impact is lessened because debootstrap will
  grab the release pocket for its job, and base-files from that pocket, in
  all ubuntu releases other than groovy, does not have the code that
  creates /etc/default/motd-news.wasremoved.
  
- This would affect a stable release anytime the postinst script from
- base-files from the previous SRU is run and there are no /etc/default
- /motd-news{,.dpkg*} files present. This could be a system which just
- doesn't have ubuntu-server or motd-news-config installed, in which case
- creating the .wasremoved file is wrong. Or a system which has those
- packages installed, and the user erroneously, in an attempt to disable
- motd-news, removed /etc/default/motd-news, in which case it's correct to
- create /etc/default/motd-news.wasremoved.
+ There are two ways this can affect a stable release of ubuntu:
  
- If debootstrap is somehow coached into using the release and updates
- pocket, then the stable release it's bootstrapping would suffer from
- this bug in the same way that groovy did: base-files would be installed
- without ubuntu-server or motd-news-config, and an empty /etc/default
- /motd-news.wasremoved file would be creating, disabling motd-news in any
- future installation of motd-news-config or ubuntu-server.
+ a) debootstrap with release and updates pocket enabled
+ There are no config options that I'm aware of that would tell debootstrap to 
use multiple pockets when creating a chroot, but let's say it was done. In this 
case, it would be the same case as groovy was until this fix: subsequent 
installations of ubuntu-server or motd-news-config would default to having 
motd-news disabled
  
+ b) A system that has just base-files from the previous SRU installed,
+ and no ubuntu-server and no motd-news-config. If base-files were updated
+ again, and without the fix presented here, it would create /etc/default
+ /motd-news.wasremoved, and again, a subsequent install of ubuntu-server
+ or motd-news-config would install motd-news in a disabled state
+ 
+ c) Any other case where the postinst script of base-files is run again
+ without the fix presented here, and when there is no /etc/default/motd-
+ news{,.dpkg*} file present.
  
  [Test Case]
  
   * detailed instructions how to reproduce the bug
  
   * these should allow someone who is not familiar with the affected
     package to reproduce the bug and verify that the updated package fixes
     the problem.
  
  [Regression Potential]
  
   * discussion of how regressions are most likely to manifest as a result
  of this change.
  
   * It is assumed that any SRU candidate patch is well-tested before
     upload and has a low overall risk of regression, but it's important
     to make the effort to think about what ''could'' happen in the
     event of a regression.
  
   * This both shows the SRU team that the risks have been considered,
     and provides guidance to testers in regression-testing the SRU.
  
  [Other Info]
  
   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
   * and address these questions in advance
  
  [Original 

[Touch-packages] [Bug 1895302] Re: groovy debootstrap leaves /e/d/motd-news.wasremoved around

[Andreas Hasenack]

** Description changed:

  [Impact]
+ A fresh install of base-files, like done when using debootstrap, using the 
base-files from the -updates repository (in the case of ubuntu stable 
releases), will leave an empty /etc/default/motd-news.wasremoved file. This 
file is an artifact of the mechanism used to handle a corner case in the 
previous SRU where it would signal the motd-news-config package to install 
/etc/default/motd-news with ENABLED=0. See testcases (h) and (i) in the 
previous base-files SRU at 
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888575 for details. 
In test case (i) it was acked that the empty .wasremoved file was lying around, 
but its impact was deemed low (see [other info] item (a)).
  
-  * An explanation of the effects of the bug on users and
+ Another case where /etc/default/motd-news.wasremoved would be created
+ when it shouldn't be is when you have just base-files installed (and no
+ ubuntu-server or motd-news-config) and did a reinstall of base-files, or
+ an upgrade. It would again touch /etc/default/motd-news.wasremoved.
  
-  * justification for backporting the fix to the stable release.
+ The consequence of having /etc/default/motd-news.wasremoved when it's
+ unintended is that a follow-up install of ubuntu-server, or motd-news-
+ config for that matter, will install /etc/default/motd-news with
+ ENABLED=0 instead of ENABLED=1.
  
-  * In addition, it is helpful, but not required, to include an
-explanation of how the upload fixes this bug.
+ This was the case of the groovy debootstrap which resulted in this bug
+ being filed. While debootstrap won't mix multiple repositories (like
+ release with updates), and thus this isn't strictly a problem in
+ released versions of ubuntu, the groovy case was the one that was doing
+ a fresh install of base-files with the buggy touch /etc/default/motd-
+ news.wasremoved, and a subsequent install of ubuntu-server left motd-
+ news disabled in groovy images produced by such a method (debootstrap).
+ 
+ For stable releases, the impact is lessened because debootstrap will
+ grab the release pocket for its job, and base-files from that pocket, in
+ all ubuntu releases other than groovy, does not have the code that
+ creates /etc/default/motd-news.wasremoved.
+ 
+ This would affect a stable release anytime the postinst script from
+ base-files from the previous SRU is run and there are no /etc/default
+ /motd-news{,.dpkg*} files present. This could be a system which just
+ doesn't have ubuntu-server or motd-news-config installed, in which case
+ creating the .wasremoved file is wrong. Or a system which has those
+ packages installed, and the user erroneously, in an attempt to disable
+ motd-news, removed /etc/default/motd-news, in which case it's correct to
+ create /etc/default/motd-news.wasremoved.
+ 
+ If debootstrap is somehow coached into using the release and updates
+ pocket, then the stable release it's bootstrapping would suffer from
+ this bug in the same way that groovy did: base-files would be installed
+ without ubuntu-server or motd-news-config, and an empty /etc/default
+ /motd-news.wasremoved file would be creating, disabling motd-news in any
+ future installation of motd-news-config or ubuntu-server.
+ 
  
  [Test Case]
  
-  * detailed instructions how to reproduce the bug
+  * detailed instructions how to reproduce the bug
  
-  * these should allow someone who is not familiar with the affected
-package to reproduce the bug and verify that the updated package fixes
-the problem.
+  * these should allow someone who is not familiar with the affected
+    package to reproduce the bug and verify that the updated package fixes
+    the problem.
  
  [Regression Potential]
  
-  * discussion of how regressions are most likely to manifest as a result
+  * discussion of how regressions are most likely to manifest as a result
  of this change.
  
-  * It is assumed that any SRU candidate patch is well-tested before
-upload and has a low overall risk of regression, but it's important
-to make the effort to think about what ''could'' happen in the
-event of a regression.
+  * It is assumed that any SRU candidate patch is well-tested before
+    upload and has a low overall risk of regression, but it's important
+    to make the effort to think about what ''could'' happen in the
+    event of a regression.
  
-  * This both shows the SRU team that the risks have been considered,
-and provides guidance to testers in regression-testing the SRU.
+  * This both shows the SRU team that the risks have been considered,
+    and provides guidance to testers in regression-testing the SRU.
  
  [Other Info]
-  
-  * Anything else you think is useful to include
-  * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
-  * and address these questions in advance
  
+  * Anything else you think is useful to include
+  * Anticipate questions from users, SRU, +1 

[Touch-packages] [Bug 1895302] Re: groovy debootstrap leaves /e/d/motd-news.wasremoved around

[Andreas Hasenack]

** Description changed:

+ [Impact]
+ 
+  * An explanation of the effects of the bug on users and
+ 
+  * justification for backporting the fix to the stable release.
+ 
+  * In addition, it is helpful, but not required, to include an
+explanation of how the upload fixes this bug.
+ 
+ [Test Case]
+ 
+  * detailed instructions how to reproduce the bug
+ 
+  * these should allow someone who is not familiar with the affected
+package to reproduce the bug and verify that the updated package fixes
+the problem.
+ 
+ [Regression Potential]
+ 
+  * discussion of how regressions are most likely to manifest as a result
+ of this change.
+ 
+  * It is assumed that any SRU candidate patch is well-tested before
+upload and has a low overall risk of regression, but it's important
+to make the effort to think about what ''could'' happen in the
+event of a regression.
+ 
+  * This both shows the SRU team that the risks have been considered,
+and provides guidance to testers in regression-testing the SRU.
+ 
+ [Other Info]
+  
+  * Anything else you think is useful to include
+  * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
+  * and address these questions in advance
+ 
+ 
+ [Original Description]
+ 
  When debootstrapping groovy, we see an empty /etc/default/motd-
  news.wasremoved file.
  
  - groovy: base-files 11ubuntu12
  -rw-r--r-- 1 root root 0 set 11 10:20 /etc/default/motd-news.wasremoved
  
  If motd-news-config is later installed, maybe via ubuntu-server, then
  the presence of this file will disable motd-news by default, which is
  unintended as it's meant to be enabled on a server.

** Also affects: base-files (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: base-files (Ubuntu Focal)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: base-files (Ubuntu Focal)
   Status: New => In Progress

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

Title:
  groovy debootstrap leaves /e/d/motd-news.wasremoved around

Status in base-files package in Ubuntu:
  In Progress
Status in base-files source package in Focal:
  In Progress

Bug description:
  [Impact]

   * An explanation of the effects of the bug on users and

   * justification for backporting the fix to the stable release.

   * In addition, it is helpful, but not required, to include an
 explanation of how the upload fixes this bug.

  [Test Case]

   * detailed instructions how to reproduce the bug

   * these should allow someone who is not familiar with the affected
 package to reproduce the bug and verify that the updated package fixes
 the problem.

  [Regression Potential]

   * discussion of how regressions are most likely to manifest as a
  result of this change.

   * It is assumed that any SRU candidate patch is well-tested before
 upload and has a low overall risk of regression, but it's important
 to make the effort to think about what ''could'' happen in the
 event of a regression.

   * This both shows the SRU team that the risks have been considered,
 and provides guidance to testers in regression-testing the SRU.

  [Other Info]
   
   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
   * and address these questions in advance


  [Original Description]

  When debootstrapping groovy, we see an empty /etc/default/motd-
  news.wasremoved file.

  - groovy: base-files 11ubuntu12
  -rw-r--r-- 1 root root 0 set 11 10:20 /etc/default/motd-news.wasremoved

  If motd-news-config is later installed, maybe via ubuntu-server, then
  the presence of this file will disable motd-news by default, which is
  unintended as it's meant to be enabled on a server.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1895302/+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 1895302] Re: groovy debootstrap leaves /e/d/motd-news.wasremoved around

[Andreas Hasenack]

** Merge proposal linked:
   
https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git/base-files/+merge/390766

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

Title:
  groovy debootstrap leaves /e/d/motd-news.wasremoved around

Status in base-files package in Ubuntu:
  In Progress

Bug description:
  When debootstrapping groovy, we see an empty /etc/default/motd-
  news.wasremoved file.

  - groovy: base-files 11ubuntu12
  -rw-r--r-- 1 root root 0 set 11 10:20 /etc/default/motd-news.wasremoved

  If motd-news-config is later installed, maybe via ubuntu-server, then
  the presence of this file will disable motd-news by default, which is
  unintended as it's meant to be enabled on a server.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1895302/+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 1894838] Re: FFe: update to 2.4.53, fixing crash bugs

[Andreas Hasenack]

Thanks for the review laney

I did run the sssd dep8 tests, which exercise openldap, but not a
replication.

So I followed the server guide on setting up replication with TLS
(https://ubuntu.com/server/docs/service-ldap-replication and
https://ubuntu.com/server/docs/service-ldap-with-tls) and confirmed
replication was working. I added data to the provider, and it
immediately appeared on the consumer. Of course, this is a basic test,
and didn't even show the original bug in the current groovy packages,
nor when I updated to 2.4.53 from my ppa, but at least it's not a brown
paper bag release.

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

Title:
  FFe: update to 2.4.53, fixing crash bugs

Status in openldap package in Ubuntu:
  Confirmed

Bug description:
  Groovy has openldap 2.4.51

  Upstream made two quick new releases after that: 2.4.52 and 2.4.53. A
  crash was reported in the mailing list:

  https://lists.openldap.org/hyperkitty/list/openldap-
  techni...@openldap.org/thread/NKOM6DI7RQY6FDLRZGSGYJSGONKIRFEP/

  """
  This segfault is due to a problem with the fix for ITS#9282 that went into 
  the OpenLDAP 2.4.51 and OpenLDAP 2.4.52 releases.  This is fixed in the 
  2.4.53 release (released today).
  """

  Almost all changes in 2.4.52 and 2.4.53 are bug fixes, but a few feathre 
changes/additions slipped through, hence this FFe:
  OpenLDAP 2.4.53 (2020/09/07)
  Added slapd syncrepl additional SYNC logging (ITS#9043)
  Fixed slapd syncrepl segfault on NULL cookie on REFRESH (ITS#9282)
  Fixed slapd syncrepl to use fresh connection on REFRESH fallback 
(ITS#9338)
  Fixed slapo-ppolicy race condition for pwdFailureTime (ITS#9302,ITS#9334)
  Build
  Require OpenSSL 1.0.2 or later (ITS#9323)
  Fixed libldap compilation issue with broken C compilers (ITS#9332)

  OpenLDAP 2.4.52 (2020/08/28)
  Added libldap LDAP_OPT_X_TLS_REQUIRE_SAN option (ITS#9318)
  Added libldap OpenSSL support for multiple EECDH curves (ITS#9054)
  Added slapd OpenSSL support for multiple EECDH curves (ITS#9054)
  Fixed librewrite malloc/free corruption (ITS#9249)
  Fixed libldap hang when using UDP and server down (ITS#9328)
  Fixed slapd syncrepl rare deadlock due to network issues (ITS#9324)
  Fixed slapd syncrepl regression that could trigger an assert (ITS#9329)
  Fixed slapd-mdb index error with collapsed range (ITS#9135)

  I grouped the changes with links to the bug reports:
  Replication fixes:
  Fixed slapd syncrepl segfault on NULL cookie on REFRESH 
(https://bugs.openldap.org/show_bug.cgi?id=9282)
  Fixed slapd syncrepl to use fresh connection on REFRESH fallback 
(https://bugs.openldap.org/show_bug.cgi?id=9338)
  Fixed slapd syncrepl rare deadlock due to network issues 
(https://bugs.openldap.org/show_bug.cgi?id=9324)
  Fixed slapd syncrepl regression that could trigger an assert 
(https://bugs.openldap.org/show_bug.cgi?id=9329)

  Features and other non-fixes changes:
  Added slapd syncrepl additional SYNC logging 
(https://bugs.openldap.org/show_bug.cgi?id=9043)
  Require OpenSSL 1.0.2 or later 
(https://bugs.openldap.org/show_bug.cgi?id=9323)
  Added libldap LDAP_OPT_X_TLS_REQUIRE_SAN option 
(https://bugs.openldap.org/show_bug.cgi?id=9318)
  Added libldap OpenSSL support for multiple EECDH curves 
(https://bugs.openldap.org/show_bug.cgi?id=9054)
  Added slapd OpenSSL support for multiple EECDH curves 
(https://bugs.openldap.org/show_bug.cgi?id=9054)

  Other fixes:
  Fixed slapo-ppolicy race condition for pwdFailureTime 
(https://bugs.openldap.org/show_bug.cgi?id=9302,https://bugs.openldap.org/show_bug.cgi?id=9334)
  Fixed libldap compilation issue with broken C compilers 
(https://bugs.openldap.org/show_bug.cgi?id=9332)
  Fixed librewrite malloc/free corruption 
(https://bugs.openldap.org/show_bug.cgi?id=9249)
  Fixed libldap hang when using UDP and server down 
(https://bugs.openldap.org/show_bug.cgi?id=9328)
  Fixed slapd-mdb index error with collapsed range 
(https://bugs.openldap.org/show_bug.cgi?id=9135)

  
  PPA with a groovy proposed and all arches test build (still ongoing as I 
write this): 
https://launchpad.net/~ahasenack/+archive/ubuntu/openldap-2453/+packages

  I believe a backport of that many fixes is riskier than an update to
  the new upstream version at this point.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1894838/+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 1895302] Re: groovy debootstrap leaves /e/d/motd-news.wasremoved around

[Andreas Hasenack]

Nor the upgrade after that, ugh. Fixing.

** Changed in: base-files (Ubuntu)
   Importance: Undecided => High

** Changed in: base-files (Ubuntu)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: base-files (Ubuntu)
   Status: New => In Progress

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

Title:
  groovy debootstrap leaves /e/d/motd-news.wasremoved around

Status in base-files package in Ubuntu:
  In Progress

Bug description:
  When debootstrapping groovy, we see an empty /etc/default/motd-
  news.wasremoved file.

  - groovy: base-files 11ubuntu12
  -rw-r--r-- 1 root root 0 set 11 10:20 /etc/default/motd-news.wasremoved

  If motd-news-config is later installed, maybe via ubuntu-server, then
  the presence of this file will disable motd-news by default, which is
  unintended as it's meant to be enabled on a server.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1895302/+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 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

I filed https://bugs.launchpad.net/ubuntu/+source/base-
files/+bug/1895302 for that. Do you happen to know a good way to test
the first-time installation of base-files with debootstrap? It would be
awesome if I could give it a ppa to consider, in addition to the
archive, and it would then just pick my test base-files instead of the
one from the archive.

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

Title:
  Split motd-news config into a new package

Status in base-files package in Ubuntu:
  Fix Released
Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Released
Status in ubuntu-meta source package in Xenial:
  Fix Released
Status in base-files source package in Bionic:
  Fix Released
Status in ubuntu-meta source package in Bionic:
  Fix Released
Status in base-files source package in Focal:
  Fix Released
Status in ubuntu-meta source package in Focal:
  Fix Released
Status in base-files source package in Groovy:
  Fix Released
Status in ubuntu-meta source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.

  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config

  Care must be taken to preserve a changed /etc/default/motd-news when
  the upgrade installs the new motd-news-config package. For example, on
  a server that has set ENABLED=0 in /etc/default/motd-news and upgrades
  to the new base-files and ubuntu-server, and gets the new motd-config-
  news package, ENABLED=0 must remain set.

  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled

  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification

  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled

  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled

  e) removing motd-news-config will also remove ubuntu-server (since
  it's a depends, and not a recommends)

  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files

  g) Removing motd-news-server leaves /e/d/motd-news around; purging
  motd-news-server removes the /e/d/motd-news config file

  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0

  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled

  j) Perform a release upgrade from the previous ubuntu release to the
  one being tested while having ubuntu-server NOT installed (or use a
  desktop install). At the end, motd-news should be disabled. Verify
  with:

  $ sudo /etc/update-motd.d/50-motd-news --force
  $ (no output)

  [Regression Potential]
  This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
  a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 
the motd-news-config package when it is installed, otherwise this SRU would 
jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's 
configure case.

  b) /e/d/motd-news config file was *removed* while it belonged to base-files. 
In such a case, a normal upgrade of the package (base-files in this example) 
would not reinstate the file. Much less this upgrade here, which has an 
explicit rm_conffile maintscript-helper for it. But the motd-news-config 
package that could be installed in the 

[Touch-packages] [Bug 1895302] Re: groovy debootstrap leaves /e/d/motd-news.wasremoved around

[Andreas Hasenack]

I think this postinst bit never considered the fresh install case:

# special case of having /etc/default/motd-news removed by hand
# signal the motd-news-config package that this happened, so that
# it does not put back the file with default contents which would
# re-enable motd-news
motd_news_config="/etc/default/motd-news"
if [ ! -e ${motd_news_config} ]; then
  if [ ! -e ${motd_news_config}.dpkg-remove ]; then
if [ ! -e ${motd_news_config}.dpkg-backup ]; then
  touch ${motd_news_config}.wasremoved
fi
  fi
fi

Having it only act on upgrades might be the easier fix. I'll test.

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

Title:
  groovy debootstrap leaves /e/d/motd-news.wasremoved around

Status in base-files package in Ubuntu:
  New

Bug description:
  When debootstrapping groovy, we see an empty /etc/default/motd-
  news.wasremoved file.

  - groovy: base-files 11ubuntu12
  -rw-r--r-- 1 root root 0 set 11 10:20 /etc/default/motd-news.wasremoved

  If motd-news-config is later installed, maybe via ubuntu-server, then
  the presence of this file will disable motd-news by default, which is
  unintended as it's meant to be enabled on a server.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1895302/+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 1894907] Re: FTBFS with sphinx 2.4

[Andreas Hasenack]

** Summary changed:

- FTBFS with sphinx 2.4: cannot import name 'NoUri'
+ FTBFS with sphinx 2.4

** Description changed:

- Getting this failure to build on groovy:
+ cyrus-sasl2 ships with a sphinx extension to build its documentation,
+ and this extension was based on a very old sphinx version. It no longer
+ builds with sphinx 3.2.1 from groovy, failing in several places:
  
+ a) "NoUri"
  Extension error:
  Could not import extension sphinxlocal.builders.manpage (exception: cannot 
import name 'NoUri' from 'sphinx.environment' 
(/usr/lib/python3/dist-packages/sphinx/environment/__init__.py))
  make[2]: *** [Makefile:1166: man/.sphinx-build.stamp] Error 2
  make[2]: Leaving directory 
'/home/ubuntu/deb/cyrus-sasl2-2.1.27+dfsg/build-heimdal'
  make[1]: *** [Makefile:686: all-recursive] Error 1
  make[1]: Leaving directory 
'/home/ubuntu/deb/cyrus-sasl2-2.1.27+dfsg/build-heimdal'
  make: *** [Makefile:556: all] Error 2
  
+ Debian has a bug report already at https://bugs.debian.org/cgi-
+ bin/bugreport.cgi?bug=955095
  
- Debian has a bug report already at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955095
+ b) MACRO_DEF
+ Extension error:
+ Could not import extension sphinxlocal.builders.manpage (exception: cannot 
import name 'MACRO_DEF' from 'sphinx.writers.manpage' 
(/usr/lib/python3/dist-packages/sphinx/writers/manpage.py))
+ make[4]: *** [Makefile:1166: man/.sphinx-build.stamp] Error 2
+ make[4]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
+ make[3]: *** [Makefile:686: all-recursive] Error 1
+ make[3]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
+ make[2]: *** [Makefile:556: all] Error 2
+ make[2]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
+ dh_auto_build: error: cd build-heimdal && make -j4 
sasldir=/usr/lib/x86_64-linux-gnu/sasl2 returned exit code 2
+ make[1]: *** [debian/rules:164: override_dh_auto_build] Error 25
+ make[1]: Leaving directory '/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2'
+ make: *** [debian/rules:122: build] Error 2
+ dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

** Summary changed:

- FTBFS with sphinx 2.4
+ FTBFS with sphinx 3.2

** Bug watch added: github.com/cyrusimap/cyrus-sasl/issues #624
   https://github.com/cyrusimap/cyrus-sasl/issues/624

** Also affects: cyrus-sasl2 via
   https://github.com/cyrusimap/cyrus-sasl/issues/624
   Importance: Unknown
   Status: Unknown

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

Title:
  FTBFS with sphinx 3.2

Status in Cyrus-sasl2:
  Unknown
Status in cyrus-sasl2 package in Ubuntu:
  Triaged
Status in cyrus-sasl2 package in Debian:
  New

Bug description:
  cyrus-sasl2 ships with a sphinx extension to build its documentation,
  and this extension was based on a very old sphinx version. It no
  longer builds with sphinx 3.2.1 from groovy, failing in several
  places:

  a) "NoUri"
  Extension error:
  Could not import extension sphinxlocal.builders.manpage (exception: cannot 
import name 'NoUri' from 'sphinx.environment' 
(/usr/lib/python3/dist-packages/sphinx/environment/__init__.py))
  make[2]: *** [Makefile:1166: man/.sphinx-build.stamp] Error 2
  make[2]: Leaving directory 
'/home/ubuntu/deb/cyrus-sasl2-2.1.27+dfsg/build-heimdal'
  make[1]: *** [Makefile:686: all-recursive] Error 1
  make[1]: Leaving directory 
'/home/ubuntu/deb/cyrus-sasl2-2.1.27+dfsg/build-heimdal'
  make: *** [Makefile:556: all] Error 2

  Debian has a bug report already at https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=955095

  b) MACRO_DEF
  Extension error:
  Could not import extension sphinxlocal.builders.manpage (exception: cannot 
import name 'MACRO_DEF' from 'sphinx.writers.manpage' 
(/usr/lib/python3/dist-packages/sphinx/writers/manpage.py))
  make[4]: *** [Makefile:1166: man/.sphinx-build.stamp] Error 2
  make[4]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
  make[3]: *** [Makefile:686: all-recursive] Error 1
  make[3]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
  make[2]: *** [Makefile:556: all] Error 2
  make[2]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
  dh_auto_build: error: cd build-heimdal && make -j4 
sasldir=/usr/lib/x86_64-linux-gnu/sasl2 returned exit code 2
  make[1]: *** [debian/rules:164: override_dh_auto_build] Error 25
  make[1]: Leaving directory '/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2'
  make: *** [debian/rules:122: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/cyrus-sasl2/+bug/1894907/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to 

[Touch-packages] [Bug 1895006] Re: FTBFS with sphinx 2.4: cannot import name 'MACRO_DEF'

[Andreas Hasenack]

*** This bug is a duplicate of bug 1894907 ***
https://bugs.launchpad.net/bugs/1894907

** This bug has been marked a duplicate of bug 1894907
   FTBFS with sphinx 2.4: cannot import name 'NoUri'

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

Title:
  FTBFS with sphinx 2.4: cannot import name 'MACRO_DEF'

Status in cyrus-sasl2 package in Ubuntu:
  Triaged
Status in cyrus-sasl2 package in Debian:
  New

Bug description:
  sed -e 's,[@]LIB_DOOR[@],,g' -e 's,[@]SASL_DL_LIB[@],-ldl,g' -e 
's,[@]LIBS[@],-lresolv ,g' -e 's,[@]VERSION[@],2.1.27,g' -e 
's,[@]libdir[@],/usr/lib/x86_64-linux-gnu,g' -e 's,[@]prefix[@],/usr,g' -e 
's,[@]exec_prefix[@],/usr,g' -e 's,[@]includedir[@],/usr/include,g' < 
../libsasl2.pc.in > libsasl2.pc
  /usr/bin/sphinx-build -d docsrc/.doctrees -n -q -b cyrman ./docsrc ./man

  Extension error:
  Could not import extension sphinxlocal.builders.manpage (exception: cannot 
import name 'MACRO_DEF' from 'sphinx.writers.manpage' 
(/usr/lib/python3/dist-packages/sphinx/writers/manpage.py))
  make[4]: *** [Makefile:1166: man/.sphinx-build.stamp] Error 2
  make[4]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
  make[3]: *** [Makefile:686: all-recursive] Error 1
  make[3]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
  make[2]: *** [Makefile:556: all] Error 2
  make[2]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
  dh_auto_build: error: cd build-heimdal && make -j4 
sasldir=/usr/lib/x86_64-linux-gnu/sasl2 returned exit code 2
  make[1]: *** [debian/rules:164: override_dh_auto_build] Error 25
  make[1]: Leaving directory '/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2'
  make: *** [debian/rules:122: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1895006/+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 1895302] [NEW] groovy debootstrap leaves /e/d/motd-news.wasremoved around

[Andreas Hasenack]

Public bug reported:

When debootstrapping groovy, we see an empty /etc/default/motd-
news.wasremoved file.

- groovy: base-files 11ubuntu12
-rw-r--r-- 1 root root 0 set 11 10:20 /etc/default/motd-news.wasremoved

If motd-news-config is later installed, maybe via ubuntu-server, then
the presence of this file will disable motd-news by default, which is
unintended as it's meant to be enabled on a server.

** Affects: base-files (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  groovy debootstrap leaves /e/d/motd-news.wasremoved around

Status in base-files package in Ubuntu:
  New

Bug description:
  When debootstrapping groovy, we see an empty /etc/default/motd-
  news.wasremoved file.

  - groovy: base-files 11ubuntu12
  -rw-r--r-- 1 root root 0 set 11 10:20 /etc/default/motd-news.wasremoved

  If motd-news-config is later installed, maybe via ubuntu-server, then
  the presence of this file will disable motd-news by default, which is
  unintended as it's meant to be enabled on a server.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1895302/+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 1894838] Re: FFe: update to 2.4.53, fixing crash bugs

[Andreas Hasenack]

Switched bug to "New" so it can be considered by the release team.

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

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

Title:
  FFe: update to 2.4.53, fixing crash bugs

Status in openldap package in Ubuntu:
  New

Bug description:
  Groovy has openldap 2.4.51

  Upstream made two quick new releases after that: 2.4.52 and 2.4.53. A
  crash was reported in the mailing list:

  https://lists.openldap.org/hyperkitty/list/openldap-
  techni...@openldap.org/thread/NKOM6DI7RQY6FDLRZGSGYJSGONKIRFEP/

  """
  This segfault is due to a problem with the fix for ITS#9282 that went into 
  the OpenLDAP 2.4.51 and OpenLDAP 2.4.52 releases.  This is fixed in the 
  2.4.53 release (released today).
  """

  Almost all changes in 2.4.52 and 2.4.53 are bug fixes, but a few feathre 
changes/additions slipped through, hence this FFe:
  OpenLDAP 2.4.53 (2020/09/07)
  Added slapd syncrepl additional SYNC logging (ITS#9043)
  Fixed slapd syncrepl segfault on NULL cookie on REFRESH (ITS#9282)
  Fixed slapd syncrepl to use fresh connection on REFRESH fallback 
(ITS#9338)
  Fixed slapo-ppolicy race condition for pwdFailureTime (ITS#9302,ITS#9334)
  Build
  Require OpenSSL 1.0.2 or later (ITS#9323)
  Fixed libldap compilation issue with broken C compilers (ITS#9332)

  OpenLDAP 2.4.52 (2020/08/28)
  Added libldap LDAP_OPT_X_TLS_REQUIRE_SAN option (ITS#9318)
  Added libldap OpenSSL support for multiple EECDH curves (ITS#9054)
  Added slapd OpenSSL support for multiple EECDH curves (ITS#9054)
  Fixed librewrite malloc/free corruption (ITS#9249)
  Fixed libldap hang when using UDP and server down (ITS#9328)
  Fixed slapd syncrepl rare deadlock due to network issues (ITS#9324)
  Fixed slapd syncrepl regression that could trigger an assert (ITS#9329)
  Fixed slapd-mdb index error with collapsed range (ITS#9135)

  I grouped the changes with links to the bug reports:
  Replication fixes:
  Fixed slapd syncrepl segfault on NULL cookie on REFRESH 
(https://bugs.openldap.org/show_bug.cgi?id=9282)
  Fixed slapd syncrepl to use fresh connection on REFRESH fallback 
(https://bugs.openldap.org/show_bug.cgi?id=9338)
  Fixed slapd syncrepl rare deadlock due to network issues 
(https://bugs.openldap.org/show_bug.cgi?id=9324)
  Fixed slapd syncrepl regression that could trigger an assert 
(https://bugs.openldap.org/show_bug.cgi?id=9329)

  Features and other non-fixes changes:
  Added slapd syncrepl additional SYNC logging 
(https://bugs.openldap.org/show_bug.cgi?id=9043)
  Require OpenSSL 1.0.2 or later 
(https://bugs.openldap.org/show_bug.cgi?id=9323)
  Added libldap LDAP_OPT_X_TLS_REQUIRE_SAN option 
(https://bugs.openldap.org/show_bug.cgi?id=9318)
  Added libldap OpenSSL support for multiple EECDH curves 
(https://bugs.openldap.org/show_bug.cgi?id=9054)
  Added slapd OpenSSL support for multiple EECDH curves 
(https://bugs.openldap.org/show_bug.cgi?id=9054)

  Other fixes:
  Fixed slapo-ppolicy race condition for pwdFailureTime 
(https://bugs.openldap.org/show_bug.cgi?id=9302,https://bugs.openldap.org/show_bug.cgi?id=9334)
  Fixed libldap compilation issue with broken C compilers 
(https://bugs.openldap.org/show_bug.cgi?id=9332)
  Fixed librewrite malloc/free corruption 
(https://bugs.openldap.org/show_bug.cgi?id=9249)
  Fixed libldap hang when using UDP and server down 
(https://bugs.openldap.org/show_bug.cgi?id=9328)
  Fixed slapd-mdb index error with collapsed range 
(https://bugs.openldap.org/show_bug.cgi?id=9135)

  
  PPA with a groovy proposed and all arches test build (still ongoing as I 
write this): 
https://launchpad.net/~ahasenack/+archive/ubuntu/openldap-2453/+packages

  I believe a backport of that many fixes is riskier than an update to
  the new upstream version at this point.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1894838/+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 1895006] [NEW] FTBFS with sphinx 2.4: cannot import name 'MACRO_DEF'

[Andreas Hasenack]

Public bug reported:

sed -e 's,[@]LIB_DOOR[@],,g' -e 's,[@]SASL_DL_LIB[@],-ldl,g' -e 
's,[@]LIBS[@],-lresolv ,g' -e 's,[@]VERSION[@],2.1.27,g' -e 
's,[@]libdir[@],/usr/lib/x86_64-linux-gnu,g' -e 's,[@]prefix[@],/usr,g' -e 
's,[@]exec_prefix[@],/usr,g' -e 's,[@]includedir[@],/usr/include,g' < 
../libsasl2.pc.in > libsasl2.pc
/usr/bin/sphinx-build -d docsrc/.doctrees -n -q -b cyrman ./docsrc ./man

Extension error:
Could not import extension sphinxlocal.builders.manpage (exception: cannot 
import name 'MACRO_DEF' from 'sphinx.writers.manpage' 
(/usr/lib/python3/dist-packages/sphinx/writers/manpage.py))
make[4]: *** [Makefile:1166: man/.sphinx-build.stamp] Error 2
make[4]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
make[3]: *** [Makefile:686: all-recursive] Error 1
make[3]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
make[2]: *** [Makefile:556: all] Error 2
make[2]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
dh_auto_build: error: cd build-heimdal && make -j4 
sasldir=/usr/lib/x86_64-linux-gnu/sasl2 returned exit code 2
make[1]: *** [debian/rules:164: override_dh_auto_build] Error 25
make[1]: Leaving directory '/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2'
make: *** [debian/rules:122: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

** Affects: cyrus-sasl2 (Ubuntu)
 Importance: High
 Status: Triaged

** Affects: cyrus-sasl2 (Debian)
 Importance: Unknown
 Status: Unknown


** Tags: ftbfs

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

** Also affects: cyrus-sasl2 (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955095
   Importance: Unknown
   Status: Unknown

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

Title:
  FTBFS with sphinx 2.4: cannot import name 'MACRO_DEF'

Status in cyrus-sasl2 package in Ubuntu:
  Triaged
Status in cyrus-sasl2 package in Debian:
  Unknown

Bug description:
  sed -e 's,[@]LIB_DOOR[@],,g' -e 's,[@]SASL_DL_LIB[@],-ldl,g' -e 
's,[@]LIBS[@],-lresolv ,g' -e 's,[@]VERSION[@],2.1.27,g' -e 
's,[@]libdir[@],/usr/lib/x86_64-linux-gnu,g' -e 's,[@]prefix[@],/usr,g' -e 
's,[@]exec_prefix[@],/usr,g' -e 's,[@]includedir[@],/usr/include,g' < 
../libsasl2.pc.in > libsasl2.pc
  /usr/bin/sphinx-build -d docsrc/.doctrees -n -q -b cyrman ./docsrc ./man

  Extension error:
  Could not import extension sphinxlocal.builders.manpage (exception: cannot 
import name 'MACRO_DEF' from 'sphinx.writers.manpage' 
(/usr/lib/python3/dist-packages/sphinx/writers/manpage.py))
  make[4]: *** [Makefile:1166: man/.sphinx-build.stamp] Error 2
  make[4]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
  make[3]: *** [Makefile:686: all-recursive] Error 1
  make[3]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
  make[2]: *** [Makefile:556: all] Error 2
  make[2]: Leaving directory 
'/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2/build-heimdal'
  dh_auto_build: error: cd build-heimdal && make -j4 
sasldir=/usr/lib/x86_64-linux-gnu/sasl2 returned exit code 2
  make[1]: *** [debian/rules:164: override_dh_auto_build] Error 25
  make[1]: Leaving directory '/home/ubuntu/git/packages/cyrus-sasl2/cyrus-sasl2'
  make: *** [debian/rules:122: build] Error 2
  dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1895006/+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 1894907] Re: FTBFS with sphinx 2.4: cannot import name 'NoUri'

[Andreas Hasenack]

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

** Also affects: cyrus-sasl2 (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955095
   Importance: Unknown
   Status: Unknown

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

Title:
  FTBFS with sphinx 2.4: cannot import name 'NoUri'

Status in cyrus-sasl2 package in Ubuntu:
  New
Status in cyrus-sasl2 package in Debian:
  Unknown

Bug description:
  Getting this failure to build on groovy:

  Extension error:
  Could not import extension sphinxlocal.builders.manpage (exception: cannot 
import name 'NoUri' from 'sphinx.environment' 
(/usr/lib/python3/dist-packages/sphinx/environment/__init__.py))
  make[2]: *** [Makefile:1166: man/.sphinx-build.stamp] Error 2
  make[2]: Leaving directory 
'/home/ubuntu/deb/cyrus-sasl2-2.1.27+dfsg/build-heimdal'
  make[1]: *** [Makefile:686: all-recursive] Error 1
  make[1]: Leaving directory 
'/home/ubuntu/deb/cyrus-sasl2-2.1.27+dfsg/build-heimdal'
  make: *** [Makefile:556: all] Error 2

  
  Debian has a bug report already at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955095

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1894907/+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 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

Hmm, the impact of having that file there in this situation is that if
you *then* install the motd-news-config package, it will see that file,
remove it, and install /etc/default/motd-news with ENABLED=0 instead of
ENABLED=1.

Can you easily remove /etc/default/motd-news.wasremoved manually in your
scripts for now for this situation?

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

Title:
  Split motd-news config into a new package

Status in base-files package in Ubuntu:
  Fix Released
Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Released
Status in ubuntu-meta source package in Xenial:
  Fix Released
Status in base-files source package in Bionic:
  Fix Released
Status in ubuntu-meta source package in Bionic:
  Fix Released
Status in base-files source package in Focal:
  Fix Released
Status in ubuntu-meta source package in Focal:
  Fix Released
Status in base-files source package in Groovy:
  Fix Released
Status in ubuntu-meta source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.

  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config

  Care must be taken to preserve a changed /etc/default/motd-news when
  the upgrade installs the new motd-news-config package. For example, on
  a server that has set ENABLED=0 in /etc/default/motd-news and upgrades
  to the new base-files and ubuntu-server, and gets the new motd-config-
  news package, ENABLED=0 must remain set.

  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled

  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification

  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled

  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled

  e) removing motd-news-config will also remove ubuntu-server (since
  it's a depends, and not a recommends)

  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files

  g) Removing motd-news-server leaves /e/d/motd-news around; purging
  motd-news-server removes the /e/d/motd-news config file

  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0

  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled

  j) Perform a release upgrade from the previous ubuntu release to the
  one being tested while having ubuntu-server NOT installed (or use a
  desktop install). At the end, motd-news should be disabled. Verify
  with:

  $ sudo /etc/update-motd.d/50-motd-news --force
  $ (no output)

  [Regression Potential]
  This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
  a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 
the motd-news-config package when it is installed, otherwise this SRU would 
jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's 
configure case.

  b) /e/d/motd-news config file was *removed* while it belonged to base-files. 
In such a case, a normal upgrade of the package (base-files in this example) 
would not reinstate the file. Much less this upgrade here, which has an 
explicit rm_conffile maintscript-helper for it. But the motd-news-config 
package that could be installed in the transaction would place 

[Touch-packages] [Bug 1894838] Re: FFe: update to 2.4.53, fixing crash bugs

[Andreas Hasenack]

The sssd DEP8 tests, which exercise the ldap server a bit, passed
locally:

...
autopkgtest [09:48:35]:  summary
ldap-user-group-ldap-auth PASS
ldap-user-group-krb5-auth PASS

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

Title:
  FFe: update to 2.4.53, fixing crash bugs

Status in openldap package in Ubuntu:
  In Progress

Bug description:
  Groovy has openldap 2.4.51

  Upstream made two quick new releases after that: 2.4.52 and 2.4.53. A
  crash was reported in the mailing list:

  https://lists.openldap.org/hyperkitty/list/openldap-
  techni...@openldap.org/thread/NKOM6DI7RQY6FDLRZGSGYJSGONKIRFEP/

  """
  This segfault is due to a problem with the fix for ITS#9282 that went into 
  the OpenLDAP 2.4.51 and OpenLDAP 2.4.52 releases.  This is fixed in the 
  2.4.53 release (released today).
  """

  Almost all changes in 2.4.52 and 2.4.53 are bug fixes, but a few feathre 
changes/additions slipped through, hence this FFe:
  OpenLDAP 2.4.53 (2020/09/07)
  Added slapd syncrepl additional SYNC logging (ITS#9043)
  Fixed slapd syncrepl segfault on NULL cookie on REFRESH (ITS#9282)
  Fixed slapd syncrepl to use fresh connection on REFRESH fallback 
(ITS#9338)
  Fixed slapo-ppolicy race condition for pwdFailureTime (ITS#9302,ITS#9334)
  Build
  Require OpenSSL 1.0.2 or later (ITS#9323)
  Fixed libldap compilation issue with broken C compilers (ITS#9332)

  OpenLDAP 2.4.52 (2020/08/28)
  Added libldap LDAP_OPT_X_TLS_REQUIRE_SAN option (ITS#9318)
  Added libldap OpenSSL support for multiple EECDH curves (ITS#9054)
  Added slapd OpenSSL support for multiple EECDH curves (ITS#9054)
  Fixed librewrite malloc/free corruption (ITS#9249)
  Fixed libldap hang when using UDP and server down (ITS#9328)
  Fixed slapd syncrepl rare deadlock due to network issues (ITS#9324)
  Fixed slapd syncrepl regression that could trigger an assert (ITS#9329)
  Fixed slapd-mdb index error with collapsed range (ITS#9135)

  I grouped the changes with links to the bug reports:
  Replication fixes:
  Fixed slapd syncrepl segfault on NULL cookie on REFRESH 
(https://bugs.openldap.org/show_bug.cgi?id=9282)
  Fixed slapd syncrepl to use fresh connection on REFRESH fallback 
(https://bugs.openldap.org/show_bug.cgi?id=9338)
  Fixed slapd syncrepl rare deadlock due to network issues 
(https://bugs.openldap.org/show_bug.cgi?id=9324)
  Fixed slapd syncrepl regression that could trigger an assert 
(https://bugs.openldap.org/show_bug.cgi?id=9329)

  Features and other non-fixes changes:
  Added slapd syncrepl additional SYNC logging 
(https://bugs.openldap.org/show_bug.cgi?id=9043)
  Require OpenSSL 1.0.2 or later 
(https://bugs.openldap.org/show_bug.cgi?id=9323)
  Added libldap LDAP_OPT_X_TLS_REQUIRE_SAN option 
(https://bugs.openldap.org/show_bug.cgi?id=9318)
  Added libldap OpenSSL support for multiple EECDH curves 
(https://bugs.openldap.org/show_bug.cgi?id=9054)
  Added slapd OpenSSL support for multiple EECDH curves 
(https://bugs.openldap.org/show_bug.cgi?id=9054)

  Other fixes:
  Fixed slapo-ppolicy race condition for pwdFailureTime 
(https://bugs.openldap.org/show_bug.cgi?id=9302,https://bugs.openldap.org/show_bug.cgi?id=9334)
  Fixed libldap compilation issue with broken C compilers 
(https://bugs.openldap.org/show_bug.cgi?id=9332)
  Fixed librewrite malloc/free corruption 
(https://bugs.openldap.org/show_bug.cgi?id=9249)
  Fixed libldap hang when using UDP and server down 
(https://bugs.openldap.org/show_bug.cgi?id=9328)
  Fixed slapd-mdb index error with collapsed range 
(https://bugs.openldap.org/show_bug.cgi?id=9135)

  
  PPA with a groovy proposed and all arches test build (still ongoing as I 
write this): 
https://launchpad.net/~ahasenack/+archive/ubuntu/openldap-2453/+packages

  I believe a backport of that many fixes is riskier than an update to
  the new upstream version at this point.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1894838/+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 1894907] [NEW] FTBFS with sphinx 2.4: cannot import name 'NoUri'

[Andreas Hasenack]

Public bug reported:

Getting this failure to build on groovy:

Extension error:
Could not import extension sphinxlocal.builders.manpage (exception: cannot 
import name 'NoUri' from 'sphinx.environment' 
(/usr/lib/python3/dist-packages/sphinx/environment/__init__.py))
make[2]: *** [Makefile:1166: man/.sphinx-build.stamp] Error 2
make[2]: Leaving directory 
'/home/ubuntu/deb/cyrus-sasl2-2.1.27+dfsg/build-heimdal'
make[1]: *** [Makefile:686: all-recursive] Error 1
make[1]: Leaving directory 
'/home/ubuntu/deb/cyrus-sasl2-2.1.27+dfsg/build-heimdal'
make: *** [Makefile:556: all] Error 2


Debian has a bug report already at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955095

** Affects: cyrus-sasl2 (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: ftbfs

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

Title:
  FTBFS with sphinx 2.4: cannot import name 'NoUri'

Status in cyrus-sasl2 package in Ubuntu:
  New

Bug description:
  Getting this failure to build on groovy:

  Extension error:
  Could not import extension sphinxlocal.builders.manpage (exception: cannot 
import name 'NoUri' from 'sphinx.environment' 
(/usr/lib/python3/dist-packages/sphinx/environment/__init__.py))
  make[2]: *** [Makefile:1166: man/.sphinx-build.stamp] Error 2
  make[2]: Leaving directory 
'/home/ubuntu/deb/cyrus-sasl2-2.1.27+dfsg/build-heimdal'
  make[1]: *** [Makefile:686: all-recursive] Error 1
  make[1]: Leaving directory 
'/home/ubuntu/deb/cyrus-sasl2-2.1.27+dfsg/build-heimdal'
  make: *** [Makefile:556: all] Error 2

  
  Debian has a bug report already at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955095

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1894907/+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 1894838] Re: FFe: update to 2.4.53, fixing crash bugs

[Andreas Hasenack]

** Description changed:

- To be filled
+ Groovy has openldap 2.4.51
+ 
+ Upstream made two quick new releases after that: 2.4.52 and 2.4.53. A
+ crash was reported in the mailing list:
  
  https://lists.openldap.org/hyperkitty/list/openldap-
  techni...@openldap.org/thread/NKOM6DI7RQY6FDLRZGSGYJSGONKIRFEP/
+ 
+ """
+ This segfault is due to a problem with the fix for ITS#9282 that went into 
+ the OpenLDAP 2.4.51 and OpenLDAP 2.4.52 releases.  This is fixed in the 
+ 2.4.53 release (released today).
+ """
+ 
+ Almost all changes in 2.4.52 and 2.4.53 are bug fixes, but a few feathre 
changes/additions slipped through, hence this FFe:
+ OpenLDAP 2.4.53 (2020/09/07)
+ Added slapd syncrepl additional SYNC logging (ITS#9043)
+ Fixed slapd syncrepl segfault on NULL cookie on REFRESH (ITS#9282)
+ Fixed slapd syncrepl to use fresh connection on REFRESH fallback 
(ITS#9338)
+ Fixed slapo-ppolicy race condition for pwdFailureTime (ITS#9302,ITS#9334)
+ Build
+ Require OpenSSL 1.0.2 or later (ITS#9323)
+ Fixed libldap compilation issue with broken C compilers (ITS#9332)
+ 
+ OpenLDAP 2.4.52 (2020/08/28)
+ Added libldap LDAP_OPT_X_TLS_REQUIRE_SAN option (ITS#9318)
+ Added libldap OpenSSL support for multiple EECDH curves (ITS#9054)
+ Added slapd OpenSSL support for multiple EECDH curves (ITS#9054)
+ Fixed librewrite malloc/free corruption (ITS#9249)
+ Fixed libldap hang when using UDP and server down (ITS#9328)
+ Fixed slapd syncrepl rare deadlock due to network issues (ITS#9324)
+ Fixed slapd syncrepl regression that could trigger an assert (ITS#9329)
+ Fixed slapd-mdb index error with collapsed range (ITS#9135)
+ 
+ I grouped the changes with links to the bug reports:
+ Replication fixes:
+ Fixed slapd syncrepl segfault on NULL cookie on REFRESH 
(https://bugs.openldap.org/show_bug.cgi?id=9282)
+ Fixed slapd syncrepl to use fresh connection on REFRESH fallback 
(https://bugs.openldap.org/show_bug.cgi?id=9338)
+ Fixed slapd syncrepl rare deadlock due to network issues 
(https://bugs.openldap.org/show_bug.cgi?id=9324)
+ Fixed slapd syncrepl regression that could trigger an assert 
(https://bugs.openldap.org/show_bug.cgi?id=9329)
+ 
+ Features and other non-fixes changes:
+ Added slapd syncrepl additional SYNC logging 
(https://bugs.openldap.org/show_bug.cgi?id=9043)
+ Require OpenSSL 1.0.2 or later 
(https://bugs.openldap.org/show_bug.cgi?id=9323)
+ Added libldap LDAP_OPT_X_TLS_REQUIRE_SAN option 
(https://bugs.openldap.org/show_bug.cgi?id=9318)
+ Added libldap OpenSSL support for multiple EECDH curves 
(https://bugs.openldap.org/show_bug.cgi?id=9054)
+ Added slapd OpenSSL support for multiple EECDH curves 
(https://bugs.openldap.org/show_bug.cgi?id=9054)
+ 
+ Other fixes:
+ Fixed slapo-ppolicy race condition for pwdFailureTime 
(https://bugs.openldap.org/show_bug.cgi?id=9302,https://bugs.openldap.org/show_bug.cgi?id=9334)
+ Fixed libldap compilation issue with broken C compilers 
(https://bugs.openldap.org/show_bug.cgi?id=9332)
+ Fixed librewrite malloc/free corruption 
(https://bugs.openldap.org/show_bug.cgi?id=9249)
+ Fixed libldap hang when using UDP and server down 
(https://bugs.openldap.org/show_bug.cgi?id=9328)
+ Fixed slapd-mdb index error with collapsed range 
(https://bugs.openldap.org/show_bug.cgi?id=9135)
+ 
+ 
+ PPA with a groovy proposed and all arches test build (still ongoing as I 
write this): 
https://launchpad.net/~ahasenack/+archive/ubuntu/openldap-2453/+packages
+ 
+ I believe a backport of that many fixes is riskier than an update to the
+ new upstream version at this point.

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

Title:
  FFe: update to 2.4.53, fixing crash bugs

Status in openldap package in Ubuntu:
  In Progress

Bug description:
  Groovy has openldap 2.4.51

  Upstream made two quick new releases after that: 2.4.52 and 2.4.53. A
  crash was reported in the mailing list:

  https://lists.openldap.org/hyperkitty/list/openldap-
  techni...@openldap.org/thread/NKOM6DI7RQY6FDLRZGSGYJSGONKIRFEP/

  """
  This segfault is due to a problem with the fix for ITS#9282 that went into 
  the OpenLDAP 2.4.51 and OpenLDAP 2.4.52 releases.  This is fixed in the 
  2.4.53 release (released today).
  """

  Almost all changes in 2.4.52 and 2.4.53 are bug fixes, but a few feathre 
changes/additions slipped through, hence this FFe:
  OpenLDAP 2.4.53 (2020/09/07)
  Added slapd syncrepl additional SYNC logging (ITS#9043)
  Fixed slapd syncrepl segfault on NULL cookie on REFRESH (ITS#9282)
  Fixed slapd syncrepl to use fresh connection on REFRESH fallback 
(ITS#9338)
  Fixed slapo-ppolicy race condition for pwdFailureTime (ITS#9302,ITS#9334)
  Build
  Require OpenSSL 1.0.2 or later (ITS#9323)
  Fixed libldap compilation issue with broken C compilers (ITS#9332)

  

[Touch-packages] [Bug 1894838] [NEW] FFe: update to 2.4.53, fixing crash bugs

[Andreas Hasenack]

Public bug reported:

To be filled

https://lists.openldap.org/hyperkitty/list/openldap-
techni...@openldap.org/thread/NKOM6DI7RQY6FDLRZGSGYJSGONKIRFEP/

** Affects: openldap (Ubuntu)
 Importance: High
 Assignee: Andreas Hasenack (ahasenack)
 Status: In Progress

** Description changed:

  To be filled
+ 
+ https://lists.openldap.org/hyperkitty/list/openldap-
+ techni...@openldap.org/thread/NKOM6DI7RQY6FDLRZGSGYJSGONKIRFEP/

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

Title:
  FFe: update to 2.4.53, fixing crash bugs

Status in openldap package in Ubuntu:
  In Progress

Bug description:
  To be filled

  https://lists.openldap.org/hyperkitty/list/openldap-
  techni...@openldap.org/thread/NKOM6DI7RQY6FDLRZGSGYJSGONKIRFEP/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1894838/+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 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

Xenial verification

Versions we are handling:
base-files 9.4ubuntu4.12 -> 9.4ubuntu4.13
ubuntu-server 1.361.4-> 1.361.5
motd-news-config n/a -> 9.4ubuntu4.13

Note that in xenial, at the moment, ubuntu-server is not pre-installed
in the images.

This verification is quite long, given the amount of tests involved.

TL;DR All tests from (a) to (j) passed as required.

xenial verification succeeded.


a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled

starting point:
ubuntu@xenial-motd-news-split:~$ dpkg -l base-files ubuntu-server 
motd-news-config | grep ^ii
dpkg-query: no packages found matching motd-news-config
ii  base-files 9.4ubuntu4.12 amd64Debian base system miscellaneous 
files
ii  ubuntu-server  1.361.4   amd64The Ubuntu Server system

unmodified config:
ubuntu@xenial-motd-news-split:~$ dpkg -s base-files | grep 
/etc/default/motd-news; echo -n ' '; md5sum /etc/default/motd-news | awk 
'{print $2,$1}'
 /etc/default/motd-news c08a329a603b640095da5ffe4e73491c
 /etc/default/motd-news c08a329a603b640095da5ffe4e73491c

motd-news enabled:
ubuntu@xenial-motd-news-split:~$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.
ubuntu@xenial-motd-news-split:~$ echo $?
0

apt install base-files result:
The following NEW packages will be installed:
  motd-news-config
The following packages will be upgraded:
  base-files ubuntu-server
2 upgraded, 1 newly installed, 0 to remove and 9 not upgraded.

new state:
ubuntu@xenial-motd-news-split:~$ dpkg -l base-files ubuntu-server 
motd-news-config | grep ^ii
ii  base-files   9.4ubuntu4.13 amd64Debian base system 
miscellaneous files
ii  motd-news-config 9.4ubuntu4.13 all  Configuration for motd-news 
shipped in base-files
ii  ubuntu-server1.361.5   amd64The Ubuntu Server system

motd-news remains enabled:
ubuntu@xenial-motd-news-split:~$ sudo /etc/update-motd.d/50-motd-news 
--force;echo $?

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.
0


b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification

Starting point:
ubuntu@xenial-motd-news-split:~$ dpkg -l base-files ubuntu-server 
motd-news-config | grep ^ii
dpkg-query: no packages found matching motd-news-config
ii  base-files 9.4ubuntu4.12 amd64Debian base system miscellaneous 
files
ii  ubuntu-server  1.361.4   amd64The Ubuntu Server system

Modified config file, to disable motd-news:
ubuntu@xenial-motd-news-split:~$ sudo sed -i 's,^ENABLED=.*,ENABLED=0,' 
/etc/default/motd-news 
ubuntu@xenial-motd-news-split:~$ dpkg -s base-files | grep 
/etc/default/motd-news; echo -n ' '; md5sum /etc/default/motd-news | awk 
'{print $2,$1}'
 /etc/default/motd-news c08a329a603b640095da5ffe4e73491c
 /etc/default/motd-news e2d38a5c7454c64a967d6a2fe033558f
ubuntu@xenial-motd-news-split:~$ sudo /etc/update-motd.d/50-motd-news 
--force;echo $?
0

base-files install result:
The following NEW packages will be installed:
  motd-news-config
The following packages will be upgraded:
  base-files ubuntu-server
2 upgraded, 1 newly installed, 0 to remove and 9 not upgraded.

new state:
ii  base-files   9.4ubuntu4.13 amd64Debian base system 
miscellaneous files
ii  motd-news-config 9.4ubuntu4.13 all  Configuration for motd-news 
shipped in base-files
ii  ubuntu-server1.361.5   amd64The Ubuntu Server system

motd-news remains disabled:
ubuntu@xenial-motd-news-split:~$ ll /etc/default/motd-news*
-rw-r--r-- 1 root root 682 Aug 25 21:15 /etc/default/motd-news
ubuntu@xenial-motd-news-split:~$ sudo /etc/update-motd.d/50-motd-news 
--force;echo $?
0

config file moved to the motd-news-config package and the modification was 
preserved:
ubuntu@xenial-motd-news-split:~$ dpkg -s motd-news-config | grep 
/etc/default/motd-news; echo -n ' '; md5sum /etc/default/motd-news | awk 
'{print $2,$1}'
 /etc/default/motd-news c08a329a603b640095da5ffe4e73491c
 /etc/default/motd-news e2d38a5c7454c64a967d6a2fe033558f


c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled

initial state:
ubuntu@xenial-motd-news-split:~$ dpkg -l base-files ubuntu-server 
motd-news-config | grep ^ii
dpkg-query: no packages found matching ubuntu-server
dpkg-query: no packages found matching motd-news-config
ii  base-files 9.4ubuntu4.12 amd64 

[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

For the focal verification, I added a secondary test (j2) like I did for
bionic, and that is a release upgrade from an updated focal non-server
system to groovy, using the base-files package from focal-proposed, thus
simulating the release upgrade once this SRU is complete.

Result is correct as well. Details below.

j2) do-release-upgrade from focal to groovy with the focal-proposed base-files 
package installed, no ubuntu-server installed, and thus motd-news-config 
disabled:
Starting point: 
ubuntu@focal-motd-news-split:~$ dpkg -l base-files ubuntu-server 
motd-news-config | grep ^ii
dpkg-query: no packages found matching motd-news-config 
ii  base-files 11ubuntu5.2  amd64Debian base system miscellaneous 
files
ubuntu@focal-motd-news-split:~$ sudo /etc/update-motd.d/50-motd-news --force
ubuntu@focal-motd-news-split:~$ echo $? 
0   
ubuntu@focal-motd-news-split:~$ apt-cache policy base-files 
base-files: 
  Installed: 11ubuntu5.2
  Candidate: 11ubuntu5.2
  Version table:
 *** 11ubuntu5.2 500
500 http://br.archive.ubuntu.com/ubuntu focal-proposed/main amd64 
Packages
(...)   

Just before running do-release-upgrade, I removed focal-proposed from 
sources.list, to avoid upgrading other packages, not related to this test.

Final state:
ubuntu@focal-motd-news-split:~$ dpkg -l base-files ubuntu-server 
motd-news-config | grep ^ii
dpkg-query: no packages found matching motd-news-config 
ii  base-files 11ubuntu12   amd64Debian base system miscellaneous 
files
ubuntu@focal-motd-news-split:~$ apt-cache policy base-files 
base-files: 
  Installed: 11ubuntu12 
  Candidate: 11ubuntu12 
  Version table:
 *** 11ubuntu12 500 
500 http://br.archive.ubuntu.com/ubuntu groovy/main amd64 Packages  

motd-new disabled as expected:  
ubuntu@focal-motd-news-split:~$ sudo /etc/update-motd.d/50-motd-news --force
ubuntu@focal-motd-news-split:~$ echo $? 
0

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

Title:
  Split motd-news config into a new package

Status in base-files package in Ubuntu:
  Fix Released
Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Committed
Status in ubuntu-meta source package in Xenial:
  Fix Committed
Status in base-files source package in Bionic:
  Fix Committed
Status in ubuntu-meta source package in Bionic:
  Fix Committed
Status in base-files source package in Focal:
  Fix Committed
Status in ubuntu-meta source package in Focal:
  Fix Committed
Status in base-files source package in Groovy:
  Fix Released
Status in ubuntu-meta source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.

  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config

  Care must be taken to preserve a changed /etc/default/motd-news when
  the upgrade installs the new motd-news-config package. For example, on
  a server that has set 

[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

Bionic verification

This verification is quite long, given the amount of tests involved.

TL;DR All tests from (a) to (j) passed as required.

bionic verification succeeded.

Latest updates from bionic:
base-files:
 *** 10.1ubuntu2.9 500
500 http://br.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
and
ubuntu-server:
 *** 1.417.4 500
500 http://br.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages


a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled

Starting point:
ubuntu@bionic-motd-news-split:~$ dpkg -l base-files ubuntu-server 
motd-news-config | grep ^ii
dpkg-query: no packages found matching motd-news-config
ii  base-files 10.1ubuntu2.9 amd64Debian base system miscellaneous 
files
ii  ubuntu-server  1.417.4   amd64The Ubuntu Server system

Unmodified config:
$ dpkg -s base-files | grep /etc/default/motd-news; echo -n ' '; md5sum 
/etc/default/motd-news | awk '{print $2,$1}'
 /etc/default/motd-news c08a329a603b640095da5ffe4e73491c
 /etc/default/motd-news c08a329a603b640095da5ffe4e73491c

Installing base-files pulls in motd-news-config and upgrades base-files and 
ubuntu-server:
ubuntu@bionic-motd-news-split:~$ sudo apt install base-files
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  motd-news-config ubuntu-server
Recommended packages:
  grub-legacy-ec2
The following NEW packages will be installed:
  motd-news-config
The following packages will be upgraded:
  base-files ubuntu-server
2 upgraded, 1 newly installed, 0 to remove and 14 not upgraded

motd-news remains enabled:
ubuntu@bionic-motd-news-split:~$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.

config is now part of motd-news-config package:
ubuntu@bionic-motd-news-split:~$ dpkg -s motd-news-config | grep 
/etc/default/motd-news; echo -n ' '; md5sum /etc/default/motd-news | awk 
'{print $2,$1}'
 /etc/default/motd-news c08a329a603b640095da5ffe4e73491c
 /etc/default/motd-news c08a329a603b640095da5ffe4e73491c


b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification

Starting point:
ubuntu@bionic-motd-news-split:~$ dpkg -l base-files ubuntu-server 
motd-news-config | grep ^ii
dpkg-query: no packages found matching motd-news-config
ii  base-files 10.1ubuntu2.9 amd64Debian base system miscellaneous 
files
ii  ubuntu-server  1.417.4   amd64The Ubuntu Server system

Modified config:
ubuntu@bionic-motd-news-split:~$ sudo sed -i "s,^ENABLED=.*,ENABLED=0," 
/etc/default/motd-news
ubuntu@bionic-motd-news-split:~$ dpkg -s base-files | grep 
/etc/default/motd-news; echo -n ' '; md5sum /etc/default/motd-news | awk 
'{print $2,$1}'
 /etc/default/motd-news c08a329a603b640095da5ffe4e73491c
 /etc/default/motd-news e2d38a5c7454c64a967d6a2fe033558f

motd-news disabled with that modification:
ubuntu@bionic-motd-news-split:~$ sudo /etc/update-motd.d/50-motd-news --force
ubuntu@bionic-motd-news-split:~$ echo $?
0

Running apt install base-files also pulls in motd-news-config and upgrades 
ubuntu-server:
ubuntu@bionic-motd-news-split:~$ sudo apt install base-files
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  motd-news-config ubuntu-server
Recommended packages:
  grub-legacy-ec2
The following NEW packages will be installed:
  motd-news-config
The following packages will be upgraded:
  base-files ubuntu-server
2 upgraded, 1 newly installed, 0 to remove and 14 not upgraded.

Config file now belongs to motd-news-config, and is still flagged as modified:
ubuntu@bionic-motd-news-split:~$ dpkg -s motd-news-config | grep 
/etc/default/motd-news; echo -n ' '; md5sum /etc/default/motd-news | awk 
'{print $2,$1}'
 /etc/default/motd-news c08a329a603b640095da5ffe4e73491c
 /etc/default/motd-news e2d38a5c7454c64a967d6a2fe033558f

And motd-news remains disabled because of the modification:
ubuntu@bionic-motd-news-split:~$ sudo /etc/update-motd.d/50-motd-news --force
ubuntu@bionic-motd-news-split:~$ echo $?
0

And no other config file is in /e/d:
ubuntu@bionic-motd-news-split:~$ ls -la /etc/default/motd-news*
-rw-r--r-- 1 root root 682 Aug 25 19:26 /etc/default/motd-news


c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled

Starting point:
ubuntu@bionic-motd-news-split:~$ dpkg -l base-files 

[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

Focal verification

This verification is quite long, given the amount of tests involved.

TL;DR All tests from (a) to (j) passed as required.

focal verification succeeded.

Details below.


a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains, motd-news remains enabled

Starting with:
ii  base-files 11ubuntu5.1  amd64Debian base system miscellaneous 
files
ii  ubuntu-server  1.450.1  amd64The Ubuntu Server system

With proposed enabled, an apt install base-files pulls in motd-news-config and 
upgrades ubuntu-server:
$ sudo apt install base-files
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  motd-news-config ubuntu-server
The following NEW packages will be installed:
  motd-news-config
The following packages will be upgraded:
  base-files ubuntu-server
(...)

And motd-news remains enabled:
ubuntu@focal-motd-news-split:~$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.

ubuntu@focal-motd-news-split:~$ apt-cache policy base-files ubuntu-server 
motd-news-config
base-files:
  Installed: 11ubuntu5.2
  Candidate: 11ubuntu5.2
  Version table:
 *** 11ubuntu5.2 500
500 http://br.archive.ubuntu.com/ubuntu focal-proposed/main amd64 
Packages
(...)
ubuntu-server:
  Installed: 1.450.2
  Candidate: 1.450.2
  Version table:
 *** 1.450.2 500
500 http://br.archive.ubuntu.com/ubuntu focal-proposed/main amd64 
Packages
100 /var/lib/dpkg/status
(...)
motd-news-config:
  Installed: 11ubuntu5.2
  Candidate: 11ubuntu5.2
  Version table:
 *** 11ubuntu5.2 500
500 http://br.archive.ubuntu.com/ubuntu focal-proposed/main amd64 
Packages


b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
apt install base-files
- upgrades ubuntu-server
- installs motd-news-config
- /e/d/motd-news remains with the original modification

First, change /e/d/motd-news to disable the service:
ubuntu@focal-motd-news-split:~$ sudo sed -i 's,^ENABLED=.*,ENABLED=0,' 
/etc/default/motd-news 
ubuntu@focal-motd-news-split:~$ sudo /etc/update-motd.d/50-motd-news --force
ubuntu@focal-motd-news-split:~$ 

Confirm installed packages:
ubuntu@focal-motd-news-split:~$ dpkg -l base-files ubuntu-server 
motd-news-config | grep ^i
dpkg-query: no packages found matching motd-news-config
ii  base-files 11ubuntu5.1  amd64Debian base system miscellaneous 
files
ii  ubuntu-server  1.450.1  amd64The Ubuntu Server system

Install base-files, which upgrades ubuntu-server, base-files, and installs the 
new motd-news-config package:
ubuntu@focal-motd-news-split:~$ sudo apt install base-files
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  motd-news-config ubuntu-server
The following NEW packages will be installed:
  motd-news-config
The following packages will be upgraded:
  base-files ubuntu-server
2 upgraded, 1 newly installed, 0 to remove and 15 not upgraded.

And confirm motd-news remains disabled (which was the modification done):
ubuntu@focal-motd-news-split:~$ sudo /etc/update-motd.d/50-motd-news --force
ubuntu@focal-motd-news-split:~$ 

c) base-files installed, ubuntu-server not installed, unmodified /e/d/motd-news
apt install base-files
- upgrades base-files
- removes /e/d/motd-news
- motd-news is disabled

Starting from:
- unmodified config:
ubuntu@focal-motd-news-split:~$ dpkg -s base-files | grep 
/etc/default/motd-news ; md5sum /etc/default/motd-news 
 /etc/default/motd-news c08a329a603b640095da5ffe4e73491c
c08a329a603b640095da5ffe4e73491c  /etc/default/motd-news

- ubuntu-server removed:
ubuntu@focal-motd-news-split:~$ dpkg -l base-files ubuntu-server 
motd-news-config | grep ^i
dpkg-query: no packages found matching ubuntu-server
dpkg-query: no packages found matching motd-news-config
ii  base-files 11ubuntu5.1  amd64Debian base system miscellaneous 
files

apt install base-files upgrades just base-files, and /e/d/motd-news is removed, 
resulting in a disabled motd-news:
$ sudo apt install base-files
...
The following packages will be upgraded:
  base-files
1 upgraded, 0 newly installed, 0 to remove and 15 not upgraded.
...
ubuntu@focal-motd-news-split:~$ ls -la /etc/default/motd-news
ls: cannot access '/etc/default/motd-news': No such file or directory
ubuntu@focal-motd-news-split:~$ sudo /etc/update-motd.d/50-motd-news --force
ubuntu@focal-motd-news-split:~$ 


d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
apt install base-files
- upgrades base-files
- /e/d/motd-news gets renamed to backup
- motd-news is disabled

[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

This is fixed in groovy already.

** Changed in: ubuntu-meta (Ubuntu Groovy)
   Status: In Progress => Fix Released

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

Title:
  Split motd-news config into a new package

Status in base-files package in Ubuntu:
  Fix Released
Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Committed
Status in ubuntu-meta source package in Xenial:
  Fix Committed
Status in base-files source package in Bionic:
  Fix Committed
Status in ubuntu-meta source package in Bionic:
  Fix Committed
Status in base-files source package in Focal:
  Fix Committed
Status in ubuntu-meta source package in Focal:
  Fix Committed
Status in base-files source package in Groovy:
  Fix Released
Status in ubuntu-meta source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.

  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config

  Care must be taken to preserve a changed /etc/default/motd-news when
  the upgrade installs the new motd-news-config package. For example, on
  a server that has set ENABLED=0 in /etc/default/motd-news and upgrades
  to the new base-files and ubuntu-server, and gets the new motd-config-
  news package, ENABLED=0 must remain set.

  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled

  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification

  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled

  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled

  e) removing motd-news-config will also remove ubuntu-server (since
  it's a depends, and not a recommends)

  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files

  g) Removing motd-news-server leaves /e/d/motd-news around; purging
  motd-news-server removes the /e/d/motd-news config file

  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0

  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled

  j) Perform a release upgrade from the previous ubuntu release to the
  one being tested while having ubuntu-server NOT installed (or use a
  desktop install). At the end, motd-news should be disabled. Verify
  with:

  $ sudo /etc/update-motd.d/50-motd-news --force
  $ (no output)

  [Regression Potential]
  This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
  a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 
the motd-news-config package when it is installed, otherwise this SRU would 
jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's 
configure case.

  b) /e/d/motd-news config file was *removed* while it belonged to base-files. 
In such a case, a normal upgrade of the package (base-files in this example) 
would not reinstate the file. Much less this upgrade here, which has an 
explicit rm_conffile maintscript-helper for it. But the motd-news-config 
package that could be installed in the transaction would place the default 
config file back, and the default is ENABLED=1. Thus, a system that had 
motd-news disabled via removing the config file would now have it re-enabled 
after the upgrade.
  This was trickier to 

[Touch-packages] [Bug 1888572] Re: motd-news: use wget instead of curl

[Andreas Hasenack]

Xenial verification

Test (a)

Current base-files and curl installed (no ubuntu-server out-of-the-box on 
xenial lxd images):
ii  base-files 9.4ubuntu4.12  amd64Debian base system 
miscellaneous files
ii  curl   7.47.0-1ubuntu2.16 amd64command line tool for 
transferring data with URL syntax

motd-news runs:
ubuntu@xenial-motd-news-wget:~$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.

Remove curl, and it exits immediatelly:
ubuntu@xenial-motd-news-wget:~$ dpkg -l curl | grep curl
un  curl (no description available)

ubuntu@xenial-motd-news-wget:~$ sudo /etc/update-motd.d/50-motd-news --force
ubuntu@xenial-motd-news-wget:~$ echo $?
0

With base-files and motd-news-config from xenial-proposed:
base-files:
  Installed: 9.4ubuntu4.13
  Candidate: 9.4ubuntu4.13
  Version table:
 *** 9.4ubuntu4.13 500
500 http://br.archive.ubuntu.com/ubuntu xenial-proposed/main amd64 
Packages
100 /var/lib/dpkg/status
(...)
motd-news-config:
  Installed: 9.4ubuntu4.13
  Candidate: 9.4ubuntu4.13
  Version table:
 *** 9.4ubuntu4.13 500
500 http://br.archive.ubuntu.com/ubuntu xenial-proposed/main amd64 
Packages

Still with curl removed:
ubuntu@xenial-motd-news-wget:~$ dpkg -l curl | grep curl
un  curl (no description available)

motd-news works again:
ubuntu@xenial-motd-news-wget:~$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.
ubuntu@xenial-motd-news-wget:~$ echo $?
0


Test (b)
Verify motd-news per cloud remains working.

b1) aws
ubuntu@xenial-motd-news-wget:~$ cloud-id
aws
ubuntu@xenial-motd-news-wget:~$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.
ubuntu@xenial-motd-news-wget:~$ sudo sh -x /etc/update-motd.d/50-motd-news 
--force 2>&1 | grep -wE 'wget .*cloud_id/[a-z]+'
+ wget --timeout 60 -U wget/1.17.1-1ubuntu1.5 Ubuntu/16.04.7/LTS 
GNU/Linux/5.4.0-42-generic/x86_64 Intel(R)/Core(TM)/i7-7600U/CPU/@/2.80GHz 
cloud_id/aws -O- --content-on-error https://motd.ubuntu.com

b2) gce
ubuntu@xenial-motd-news-wget:~$ cloud-id
gce
ubuntu@xenial-motd-news-wget:~$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.
ubuntu@xenial-motd-news-wget:~$ sudo sh -x /etc/update-motd.d/50-motd-news 
--force 2>&1 | grep -wE 'wget .*cloud_id/[a-z]+'
+ wget --timeout 60 -U wget/1.17.1-1ubuntu1.5 Ubuntu/16.04.7/LTS 
GNU/Linux/5.4.0-42-generic/x86_64 Intel(R)/Core(TM)/i7-7600U/CPU/@/2.80GHz 
cloud_id/gce -O- --content-on-error https://motd.ubuntu.com

b3) azure
ubuntu@xenial-motd-news-wget:~$ cloud-id
azure
ubuntu@xenial-motd-news-wget:~$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.
ubuntu@xenial-motd-news-wget:~$ sudo sh -x /etc/update-motd.d/50-motd-news 
--force 2>&1 | grep -wE 'wget .*cloud_id/[a-z]+'
+ wget --timeout 60 -U wget/1.17.1-1ubuntu1.5 Ubuntu/16.04.7/LTS 
GNU/Linux/5.4.0-42-generic/x86_64 Intel(R)/Core(TM)/i7-7600U/CPU/@/2.80GHz 
cloud_id/azure -O- --content-on-error https://motd.ubuntu.com


Xenial verification succeeded.


** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial

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

Title:
  motd-news: use wget instead of curl

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Committed
Status in base-files source package in Bionic:
  Fix Committed
Status in base-files source package in Focal:
  Fix Committed

Bug description:
  [Impact] 
  The motd-news script is using curl, but since that is an optional package, 
there is no guarantee that it will be installed. The script correctly checks 
for its presence before trying to use it, though, so it won't fail. As we don't 
want to add such a dependency to the base-files package, we should switch to 
wget, which is standard.

  [Test Case]
  wget has a different behavior than curl in some areas, one of which is 
crucial for the motd-per-cloud feature. While curl will only complain about a 
404 from the server if given a specific parameter 

[Touch-packages] [Bug 1888572] Re: motd-news: use wget instead of curl

[Andreas Hasenack]

Bionic verification

Test (a)

Current base-files, ubuntu-server and curl installed:
ii  base-files 10.1ubuntu2.9  amd64Debian base system 
miscellaneous files
ii  curl   7.58.0-2ubuntu3.10 amd64command line tool for 
transferring data with URL syntax
ii  ubuntu-server  1.417.4amd64The Ubuntu Server system

motd-news runs:
$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.

Without curl, it exits immediately:
ubuntu@bionic-motd-news-wget:~$ dpkg -l curl | grep curl
un  curl (no description available)
ubuntu@bionic-motd-news-wget:~$ sudo /etc/update-motd.d/50-motd-news --force
ubuntu@bionic-motd-news-wget:~$ echo $?
0
ubuntu@bionic-motd-news-wget:~$ 

Installing base-files and motd-news-config from bionic-proposed:
ubuntu@bionic-motd-news-wget:~$ apt-cache policy base-files motd-news-config
base-files:
  Installed: 10.1ubuntu2.10
  Candidate: 10.1ubuntu2.10
  Version table:
 *** 10.1ubuntu2.10 500
500 http://br.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 
Packages
100 /var/lib/dpkg/status
(...)
motd-news-config:
  Installed: 10.1ubuntu2.10
  Candidate: 10.1ubuntu2.10
  Version table:
 *** 10.1ubuntu2.10 500
500 http://br.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 
Packages

Still no curl:
$ dpkg -l curl | grep curl
un  curl (no description available)

motd-news works again:
ubuntu@bionic-motd-news-wget:~$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.
ubuntu@bionic-motd-news-wget:~$ echo $?
0


Test (b)
Verify motd-news per cloud remains working.

b1) aws
ubuntu@bionic-motd-news-wget:~$ cloud-id
aws
ubuntu@bionic-motd-news-wget:~$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.
ubuntu@bionic-motd-news-wget:~$ sudo sh -x /etc/update-motd.d/50-motd-news 
--force 2>&1 | grep -wE 'wget .*cloud_id/[a-z]+'
+ wget --timeout 60 -U wget/1.19.4-1ubuntu2.2 Ubuntu/18.04.5/LTS 
GNU/Linux/5.4.0-42-generic/x86_64 Intel(R)/Core(TM)/i7-7600U/CPU/@/2.80GHz 
cloud_id/aws -O- --content-on-error https://motd.ubuntu.com

b2) gce
ubuntu@bionic-motd-news-wget:~$ cloud-id
gce
ubuntu@bionic-motd-news-wget:~$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.
ubuntu@bionic-motd-news-wget:~$ sudo sh -x /etc/update-motd.d/50-motd-news 
--force 2>&1 | grep -wE 'wget .*cloud_id/[a-z]+'
+ wget --timeout 60 -U wget/1.19.4-1ubuntu2.2 Ubuntu/18.04.5/LTS 
GNU/Linux/5.4.0-42-generic/x86_64 Intel(R)/Core(TM)/i7-7600U/CPU/@/2.80GHz 
cloud_id/gce -O- --content-on-error https://motd.ubuntu.com

b3) azure
ubuntu@bionic-motd-news-wget:~$ cloud-id
azure
ubuntu@bionic-motd-news-wget:~$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.
ubuntu@bionic-motd-news-wget:~$ sudo sh -x /etc/update-motd.d/50-motd-news 
--force 2>&1 | grep -wE 'wget .*cloud_id/[a-z]+'
+ wget --timeout 60 -U wget/1.19.4-1ubuntu2.2 Ubuntu/18.04.5/LTS 
GNU/Linux/5.4.0-42-generic/x86_64 Intel(R)/Core(TM)/i7-7600U/CPU/@/2.80GHz 
cloud_id/azure -O- --content-on-error https://motd.ubuntu.com


Bionic verification succeeded.


** Tags removed: verification-needed-bionic verification-needed-focal
** Tags added: verification-done-bionic verification-done-focal

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

Title:
  motd-news: use wget instead of curl

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Committed
Status in base-files source package in Bionic:
  Fix Committed
Status in base-files source package in Focal:
  Fix Committed

Bug description:
  [Impact] 
  The motd-news script is using curl, but since that is an optional package, 
there is no guarantee that it will be installed. The script correctly checks 
for its presence before trying to use it, though, so it won't fail. As we don't 
want to add such a dependency to the base-files package, we should switch to 
wget, which is standard.

  [Test Case]
  wget has a different behavior than curl in some areas, one of which is 

[Touch-packages] [Bug 1888572] Re: motd-news: use wget instead of curl

[Andreas Hasenack]

Focal verification

Test (a)

Current base-files, ubuntu-server and curl installed:
ii  base-files 11ubuntu5.1   amd64Debian base system 
miscellaneous files
ii  curl   7.68.0-1ubuntu2.2 amd64command line tool for 
transferring data with URL syntax
ii  ubuntu-server  1.450.1   amd64The Ubuntu Server system

motd-news runs:
$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.

Without curl:
$ dpkg -l curl | grep curl
un  curl (no description available)

motd-news exits immediately:
ubuntu@focal-motd-news-wget:~$ sudo /etc/update-motd.d/50-motd-news --force
ubuntu@focal-motd-news-wget:~$ echo $?
0

With base-files and motd-news-config from focal-proposed:
ubuntu@focal-motd-news-wget:~$ apt-cache policy base-files motd-news-config
base-files:
  Installed: 11ubuntu5.2
  Candidate: 11ubuntu5.2
  Version table:
 *** 11ubuntu5.2 500
500 http://br.archive.ubuntu.com/ubuntu focal-proposed/main amd64 
Packages
(...)
motd-news-config:
  Installed: 11ubuntu5.2
  Candidate: 11ubuntu5.2
  Version table:
 *** 11ubuntu5.2 500
500 http://br.archive.ubuntu.com/ubuntu focal-proposed/main amd64 
Packages

Still no curl:
$ dpkg -l curl | grep curl
un  curl (no description available)

motd-news works again:
$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.


Test (b)
Verify motd-news per cloud remains working.

b1) aws
ubuntu@focal-motd-news-wget:~$ cloud-id
aws
$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.

cloud_id/aws was sent:
$ sudo sh -x /etc/update-motd.d/50-motd-news --force 2>&1 | grep -wE 'wget 
.*cloud_id/[a-z]+'
+ wget --timeout 60 -U wget/1.20.3-1ubuntu1 Ubuntu/20.04.1/LTS 
GNU/Linux/5.4.0-42-generic/x86_64 Intel(R)/Core(TM)/i7-7600U/CPU/@/2.80GHz 
cloud_id/aws -O- --content-on-error https://motd.ubuntu.com


b2) gce
ubuntu@focal-motd-news-wget:~$ cloud-id
gce
ubuntu@focal-motd-news-wget:~$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.
ubuntu@focal-motd-news-wget:~$ sudo sh -x /etc/update-motd.d/50-motd-news 
--force 2>&1 | grep -wE 'wget .*cloud_id/[a-z]+'
+ wget --timeout 60 -U wget/1.20.3-1ubuntu1 Ubuntu/20.04.1/LTS 
GNU/Linux/5.4.0-42-generic/x86_64 Intel(R)/Core(TM)/i7-7600U/CPU/@/2.80GHz 
cloud_id/gce -O- --content-on-error https://motd.ubuntu.com

b3) azure
ubuntu@focal-motd-news-wget:~$ cloud-id
azure
ubuntu@focal-motd-news-wget:~$ sudo /etc/update-motd.d/50-motd-news --force

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.
ubuntu@focal-motd-news-wget:~$ sudo sh -x /etc/update-motd.d/50-motd-news 
--force 2>&1 | grep -wE 'wget .*cloud_id/[a-z]+'
+ wget --timeout 60 -U wget/1.20.3-1ubuntu1 Ubuntu/20.04.1/LTS 
GNU/Linux/5.4.0-42-generic/x86_64 Intel(R)/Core(TM)/i7-7600U/CPU/@/2.80GHz 
cloud_id/azure -O- --content-on-error https://motd.ubuntu.com


Focal verification succeeded.

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

Title:
  motd-news: use wget instead of curl

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Committed
Status in base-files source package in Bionic:
  Fix Committed
Status in base-files source package in Focal:
  Fix Committed

Bug description:
  [Impact] 
  The motd-news script is using curl, but since that is an optional package, 
there is no guarantee that it will be installed. The script correctly checks 
for its presence before trying to use it, though, so it won't fail. As we don't 
want to add such a dependency to the base-files package, we should switch to 
wget, which is standard.

  [Test Case]
  wget has a different behavior than curl in some areas, one of which is 
crucial for the motd-per-cloud feature. While curl will only complain about a 
404 from the server if given a specific parameter (-f), wget does that by 
default, and needs special handling.

  a) With curl, base-files and ubuntu-server installed, first verify motd-news 
works:
  $ sudo /etc/update-motd.d/50-motd-news --force

   * Are you ready for Kubernetes 1.19? It's 

[Touch-packages] [Bug 1886572] Re: Remove uptime from the motd-news user agent

[Andreas Hasenack]

Xenial verification 

Current version:
ubuntu@xenial-motd-news-no-uptime:~$ apt-cache policy base-files
base-files: 
  Installed: 9.4ubuntu4.12  
  Candidate: 9.4ubuntu4.12  
  Version table:
 *** 9.4ubuntu4.12 500  
500 http://br.archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
100 /var/lib/dpkg/status

Uptime is there:
ubuntu@xenial-motd-news-no-uptime:~$ grep uptime /etc/update-motd.d/50-motd-news
# Some messages may only be pertinent before or after some amount of uptime 
read up idle < /proc/uptime 
uptime="uptime/$up/$idle"   
USER_AGENT="curl/$curl_ver $lsb $platform $cpu $uptime cloud_id/$cloud_id"  

After updating: 
ubuntu@xenial-motd-news-no-uptime:~$ apt-cache policy base-files
base-files: 
  Installed: 9.4ubuntu4.13  
  Candidate: 9.4ubuntu4.13  
  Version table:
 *** 9.4ubuntu4.13 500  
500 http://br.archive.ubuntu.com/ubuntu xenial-proposed/main amd64 
Packages
100 /var/lib/dpkg/status

Uptime is gone: 
ubuntu@xenial-motd-news-no-uptime:~$ grep uptime /etc/update-motd.d/50-motd-news
ubuntu@xenial-motd-news-no-uptime:~$


Xenial verification succeeded.

** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial

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

Title:
  Remove uptime from the motd-news user agent

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Committed
Status in base-files source package in Bionic:
  Fix Committed
Status in base-files source package in Focal:
  Fix Committed

Bug description:
  [Impact] 
  The uptime value in the user-agent string sent to the motd-news server is 
unused and not necessary. It should be removed.

  [Test Case]
  Inspect the /etc/update-motd.d/50-motd-news script and verify that uptime is 
no longer used.

  Previous version:
  $ grep uptime /etc/update-motd.d/50-motd-news 
  # Some messages may only be pertinent before or after some amount of uptime
  read up idle < /proc/uptime
  uptime="uptime/$up/$idle"
  USER_AGENT="curl/$curl_ver $lsb $platform $cpu $uptime cloud_id/$cloud_id"

  Updated version:
  $ grep uptime /etc/update-motd.d/50-motd-news
   (no output)

  
  [Regression Potential] 
  The server side, if it were checking this value, could be surprised by this 
change.

  [Other Info]
  N/A

  [Original Description]
  I don't why that was included but it shouldn't be. Please remove it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1886572/+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 1886572] Re: Remove uptime from the motd-news user agent

[Andreas Hasenack]

Focal verification  

Current focal version:  
  Version table:
 *** 11ubuntu5.1 500
500 http://br.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages

Verifying uptime is present:
# grep uptime /etc/update-motd.d/50-motd-news   
# Some messages may only be pertinent before or after some amount of uptime 
read up idle < /proc/uptime 
uptime="uptime/$up/$idle"   
USER_AGENT="curl/$curl_ver $lsb $platform $cpu $uptime cloud_id/$cloud_id"  

In the updated version, uptime is gone: 
base-files: 
  Installed: 11ubuntu5.2
  Candidate: 11ubuntu5.2
  Version table:
 *** 11ubuntu5.2 500
500 http://br.archive.ubuntu.com/ubuntu focal-proposed/main amd64 
Packages

# grep uptime /etc/update-motd.d/50-motd-news   
#   

Focal verification succeeded. 

** Tags removed: verification-needed-focal
** Tags added: verification-done-focal

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

Title:
  Remove uptime from the motd-news user agent

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Committed
Status in base-files source package in Bionic:
  Fix Committed
Status in base-files source package in Focal:
  Fix Committed

Bug description:
  [Impact] 
  The uptime value in the user-agent string sent to the motd-news server is 
unused and not necessary. It should be removed.

  [Test Case]
  Inspect the /etc/update-motd.d/50-motd-news script and verify that uptime is 
no longer used.

  Previous version:
  $ grep uptime /etc/update-motd.d/50-motd-news 
  # Some messages may only be pertinent before or after some amount of uptime
  read up idle < /proc/uptime
  uptime="uptime/$up/$idle"
  USER_AGENT="curl/$curl_ver $lsb $platform $cpu $uptime cloud_id/$cloud_id"

  Updated version:
  $ grep uptime /etc/update-motd.d/50-motd-news
   (no output)

  
  [Regression Potential] 
  The server side, if it were checking this value, could be surprised by this 
change.

  [Other Info]
  N/A

  [Original Description]
  I don't why that was included but it shouldn't be. Please remove it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1886572/+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 1886572] Re: Remove uptime from the motd-news user agent

[Andreas Hasenack]

Bionic verification 

Current version:
$ apt-cache policy base-files   
base-files: 
  Installed: 10.1ubuntu2.9  
  Candidate: 10.1ubuntu2.9  
  Version table:
 *** 10.1ubuntu2.9 500  
500 http://br.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
100 /var/lib/dpkg/status

Uptime is there:
ubuntu@bionic-motd-news-no-uptime:~$ grep uptime /etc/update-motd.d/50-motd-news
# Some messages may only be pertinent before or after some amount of uptime 
read up idle < /proc/uptime 
uptime="uptime/$up/$idle"   
USER_AGENT="curl/$curl_ver $lsb $platform $cpu $uptime cloud_id/$cloud_id"  

After updating, it's gone:  
ubuntu@bionic-motd-news-no-uptime:~$ apt-cache policy base-files
base-files: 
  Installed: 10.1ubuntu2.10 
  Candidate: 10.1ubuntu2.10 
  Version table:
 *** 10.1ubuntu2.10 500 
500 http://br.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 
Packages
100 /var/lib/dpkg/status
 10.1ubuntu2.9 500  

ubuntu@bionic-motd-news-no-uptime:~$ grep uptime /etc/update-motd.d/50-motd-news
ubuntu@bionic-motd-news-no-uptime:~$

Bionic verification succeeded.

** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

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

Title:
  Remove uptime from the motd-news user agent

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Committed
Status in base-files source package in Bionic:
  Fix Committed
Status in base-files source package in Focal:
  Fix Committed

Bug description:
  [Impact] 
  The uptime value in the user-agent string sent to the motd-news server is 
unused and not necessary. It should be removed.

  [Test Case]
  Inspect the /etc/update-motd.d/50-motd-news script and verify that uptime is 
no longer used.

  Previous version:
  $ grep uptime /etc/update-motd.d/50-motd-news 
  # Some messages may only be pertinent before or after some amount of uptime
  read up idle < /proc/uptime
  uptime="uptime/$up/$idle"
  USER_AGENT="curl/$curl_ver $lsb $platform $cpu $uptime cloud_id/$cloud_id"

  Updated version:
  $ grep uptime /etc/update-motd.d/50-motd-news
   (no output)

  
  [Regression Potential] 
  The server side, if it were checking this value, could be surprised by this 
change.

  [Other Info]
  N/A

  [Original Description]
  I don't why that was included but it shouldn't be. Please remove it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1886572/+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 1886572] Re: Remove uptime from the motd-news user agent

[Andreas Hasenack]

The NEW package (motd-news-config) needs to be accepted, and needs to go
into main. I believe an archive admin needs to intervene. Also, ubuntu-
meta needs to be accepted together with this.

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

Title:
  Remove uptime from the motd-news user agent

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  Fix Committed
Status in base-files source package in Bionic:
  Fix Committed
Status in base-files source package in Focal:
  Fix Committed

Bug description:
  [Impact] 
  The uptime value in the user-agent string sent to the motd-news server is 
unused and not necessary. It should be removed.

  [Test Case]
  Inspect the /etc/update-motd.d/50-motd-news script and verify that uptime is 
no longer used.

  Previous version:
  $ grep uptime /etc/update-motd.d/50-motd-news 
  # Some messages may only be pertinent before or after some amount of uptime
  read up idle < /proc/uptime
  uptime="uptime/$up/$idle"
  USER_AGENT="curl/$curl_ver $lsb $platform $cpu $uptime cloud_id/$cloud_id"

  Updated version:
  $ grep uptime /etc/update-motd.d/50-motd-news
   (no output)

  
  [Regression Potential] 
  The server side, if it were checking this value, could be surprised by this 
change.

  [Other Info]
  N/A

  [Original Description]
  I don't why that was included but it shouldn't be. Please remove it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1886572/+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 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

There are two things missing for this to be testable:
a) the motd-news-config NEW package needs to be accepted
b) it needs to be moved into main
c) ubuntu-meta needs to be accepted as well (my mistake there, I missed the bug 
number in d/changelog in the xenial and bionic uploads)

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

Title:
  Split motd-news config into a new package

Status in base-files package in Ubuntu:
  Fix Released
Status in ubuntu-meta package in Ubuntu:
  In Progress
Status in base-files source package in Xenial:
  Fix Committed
Status in ubuntu-meta source package in Xenial:
  In Progress
Status in base-files source package in Bionic:
  Fix Committed
Status in ubuntu-meta source package in Bionic:
  In Progress
Status in base-files source package in Focal:
  Fix Committed
Status in ubuntu-meta source package in Focal:
  In Progress
Status in base-files source package in Groovy:
  Fix Released
Status in ubuntu-meta source package in Groovy:
  In Progress

Bug description:
  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.

  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config

  Care must be taken to preserve a changed /etc/default/motd-news when
  the upgrade installs the new motd-news-config package. For example, on
  a server that has set ENABLED=0 in /etc/default/motd-news and upgrades
  to the new base-files and ubuntu-server, and gets the new motd-config-
  news package, ENABLED=0 must remain set.

  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled

  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification

  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled

  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled

  e) removing motd-news-config will also remove ubuntu-server (since
  it's a depends, and not a recommends)

  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files

  g) Removing motd-news-server leaves /e/d/motd-news around; purging
  motd-news-server removes the /e/d/motd-news config file

  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0

  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled

  j) Perform a release upgrade from the previous ubuntu release to the
  one being tested while having ubuntu-server NOT installed (or use a
  desktop install). At the end, motd-news should be disabled. Verify
  with:

  $ sudo /etc/update-motd.d/50-motd-news --force
  $ (no output)

  [Regression Potential]
  This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
  a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 
the motd-news-config package when it is installed, otherwise this SRU would 
jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's 
configure case.

  b) /e/d/motd-news config file was *removed* while it belonged to base-files. 
In such a case, a normal upgrade of the package (base-files in this example) 
would not reinstate the file. Much less this upgrade here, which has an 
explicit rm_conffile maintscript-helper for it. But the motd-news-config 
package that could be installed in the transaction would place the default 
config file back, and the default is 

[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

** Description changed:

  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.
  
  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config
  
  Care must be taken to preserve a changed /etc/default/motd-news when the
  upgrade installs the new motd-news-config package. For example, on a
  server that has set ENABLED=0 in /etc/default/motd-news and upgrades to
  the new base-files and ubuntu-server, and gets the new motd-config-news
  package, ENABLED=0 must remain set.
  
  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled
  
  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification
  
  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled
  
  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled
  
  e) removing motd-news-config will also remove ubuntu-server (since it's
  a depends, and not a recommends)
  
  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files
  
  g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-
  news-server removes the /e/d/motd-news config file
  
  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0
  
  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled
+ 
+ j) Perform a release upgrade from the previous ubuntu release to the one
+ being tested while having ubuntu-server NOT installed (or use a desktop
+ install).
  
  [Regression Potential]
  This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
  a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 
the motd-news-config package when it is installed, otherwise this SRU would 
jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's 
configure case.
  
  b) /e/d/motd-news config file was *removed* while it belonged to base-files. 
In such a case, a normal upgrade of the package (base-files in this example) 
would not reinstate the file. Much less this upgrade here, which has an 
explicit rm_conffile maintscript-helper for it. But the motd-news-config 
package that could be installed in the transaction would place the default 
config file back, and the default is ENABLED=1. Thus, a system that had 
motd-news disabled via removing the config file would now have it re-enabled 
after the upgrade.
  This was trickier to handle, and we do it in base-files's postinst and 
motd-news-config's  postinst. The drawback is that in one scenario, where just 
base-files is upgraded and /e/d/motd-news was manually removed by the user, 
there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" 
below for details).
  
  In general, the regression risks here are:
  - have motd-news enabled again on a system where it was previously disabled. 
We tried to envision two ways it would have been disabled (set ENABLED=0, and 
remove the config file). There are probably others
  - differences in dpkg and/or debhelper behavior in older ubuntu releases 
leading to unexpected results (should be covered by the test cases from this 
SRU)
  - xenial in particular is trickier, because src:base-files there does NOT use 
debhelper, so many of the things we take for granted have to be done by hand
  - have some sort of dpkg postinst or dependency error because of unpredicted 
scenarios. Certain assumptions are being made, like the renames that 
dpkg-maintscript-helper does, 

[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

** Description changed:

  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.
  
  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config
  
  Care must be taken to preserve a changed /etc/default/motd-news when the
  upgrade installs the new motd-news-config package. For example, on a
  server that has set ENABLED=0 in /etc/default/motd-news and upgrades to
  the new base-files and ubuntu-server, and gets the new motd-config-news
  package, ENABLED=0 must remain set.
  
  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled
  
  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification
  
  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled
  
  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled
  
  e) removing motd-news-config will also remove ubuntu-server (since it's
  a depends, and not a recommends)
  
  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files
  
  g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-
  news-server removes the /e/d/motd-news config file
  
  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0
  
  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled
  
  [Regression Potential]
  This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
  a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 
the motd-news-config package when it is installed, otherwise this SRU would 
jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's 
configure case.
  
  b) /e/d/motd-news config file was *removed* while it belonged to base-files. 
In such a case, a normal upgrade of the package (base-files in this example) 
would not reinstate the file. Much less this upgrade here, which has an 
explicit rm_conffile maintscript-helper for it. But the motd-news-config 
package that could be installed in the transaction would place the default 
config file back, and the default is ENABLED=1. Thus, a system that had 
motd-news disabled via removing the config file would now have it re-enabled 
after the upgrade.
  This was trickier to handle, and we do it in base-files's postinst and 
motd-news-config's  postinst. The drawback is that in one scenario, where just 
base-files is upgraded and /e/d/motd-news was manually removed by the user, 
there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" 
below for details).
  
  In general, the regression risks here are:
  - have motd-news enabled again on a system where it was previously disabled. 
We tried to envision two ways it would have been disabled (set ENABLED=0, and 
remove the config file). There are probably others
  - differences in dpkg and/or debhelper behavior in older ubuntu releases 
leading to unexpected results (should be covered by the test cases from this 
SRU)
  - xenial in particular is trickier, because src:base-files there does NOT use 
debhelper, so many of the things we take for granted have to be done by hand
  - have some sort of dpkg postinst or dependency error because of unpredicted 
scenarios. Certain assumptions are being made, like the renames that 
dpkg-maintscript-helper does, and that the filename 
/etc/default/motd-news.wasremoved that I'm touching and verifying is really 
mine and not something that was there already.
  - the versions 

[Touch-packages] [Bug 1886572] Re: Remove uptime from the motd-news user agent

[Andreas Hasenack]

** Merge proposal linked:
   
https://code.launchpad.net/~ahasenack/ubuntu/+source/base-files/+git/base-files/+merge/389300

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

Title:
  Remove uptime from the motd-news user agent

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  In Progress
Status in base-files source package in Bionic:
  In Progress
Status in base-files source package in Focal:
  In Progress

Bug description:
  [Impact] 
  The uptime value in the user-agent string sent to the motd-news server is 
unused and not necessary. It should be removed.

  [Test Case]
  Inspect the /etc/update-motd.d/50-motd-news script and verify that uptime is 
no longer used.

  Previous version:
  $ grep uptime /etc/update-motd.d/50-motd-news 
  # Some messages may only be pertinent before or after some amount of uptime
  read up idle < /proc/uptime
  uptime="uptime/$up/$idle"
  USER_AGENT="curl/$curl_ver $lsb $platform $cpu $uptime cloud_id/$cloud_id"

  Updated version:
  $ grep uptime /etc/update-motd.d/50-motd-news
   (no output)

  
  [Regression Potential] 
  The server side, if it were checking this value, could be surprised by this 
change.

  [Other Info]
  N/A

  [Original Description]
  I don't why that was included but it shouldn't be. Please remove it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1886572/+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 1888572] Re: motd-news: use wget instead of curl

[Andreas Hasenack]

** Description changed:

- The motd-news script is using curl, but since that is an optional
- package, there is no guarantee that it will be installed. The script
- correctly checks for its presence before trying to use it, though, so it
- won't fail. As we don't want to add such a dependency to the base-files
- package, we should switch to wget, which is standard.
+ [Impact] 
+ The motd-news script is using curl, but since that is an optional package, 
there is no guarantee that it will be installed. The script correctly checks 
for its presence before trying to use it, though, so it won't fail. As we don't 
want to add such a dependency to the base-files package, we should switch to 
wget, which is standard.
+ 
+ [Test Case]
+ wget has a different behavior than curl in some areas, one of which is 
crucial for the motd-per-cloud feature. While curl will only complain about a 
404 from the server if given a specific parameter (-f), wget does that by 
default, and needs special handling.
+ 
+ a) With curl, base-files and ubuntu-server installed, first verify motd-news 
works:
+ $ sudo /etc/update-motd.d/50-motd-news --force
+ 
+  * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
+sudo snap install microk8s --channel=1.19/candidate --classic
+ 
+https://microk8s.io/ has docs and details.
+ 
+ Now remove curl, and retry. It should exit immediately with no output:
+ 
+ $ sudo /etc/update-motd.d/50-motd-news --force
+ 
+ Install the updated base-files package and the new motd-news-config
+ package from proposed:
+ 
+ $ sudo apt install base-files motd-news-config
+ 
+ Note curl is still not available:
+ $ curl
+ 
+ Command 'curl' not found, but can be installed with:
+ 
+ sudo apt install curl
+ 
+ Re-run the motd-news script, this time it should produce output again:
+ $ sudo /etc/update-motd.d/50-motd-news --force
+ 
+  * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
+sudo snap install microk8s --channel=1.19/candidate --classic
+ 
+https://microk8s.io/ has docs and details.
+ 
+ b) Verify motd-news per cloud remains working.
+ If you have /usr/bin/cloud-id, copy it to a backup:
+ sudo cp /usr/bin/cloud-id{,.orig}
+ 
+ Create a new one, per supported cloud. For aws, for example:
+ echo -e '#!/bin/sh\necho aws' | sudo tee /usr/bin/cloud-id
+ 
+ Confirm by running it:
+ $ cloud-id
+ aws
+ 
+ And confirm motd-news keeps working (it might return different content):
+ $ sudo /etc/update-motd.d/50-motd-news --force
+ 
+  * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
+sudo snap install microk8s --channel=1.19/candidate --classic
+ 
+https://microk8s.io/ has docs and details.
+ 
+ Repeat for the gce and azure clouds, by changing the cloud-id script
+ accordingly.
+ 
+ To confirm the right cloud_id is being used, use sh -x and grep for its
+ output:
+ 
+ $ sudo sh -x /etc/update-motd.d/50-motd-news --force 2>&1 | grep -wE 'wget 
.*cloud_id/[a-z]+'
+ + wget --timeout 60 -U wget/1.20.3-1ubuntu1 Ubuntu/20.04.1/LTS 
GNU/Linux/5.4.0-42-generic/x86_64 Intel(R)/Core(TM)/i7-7600U/CPU/@/2.80GHz 
cloud_id/azure -O- --content-on-error https://motd.ubuntu.com
+ 
+ This also verifies again it's using wget instead of curl.
+ 
+ 
+ [Regression Potential] 
+ Possible regressions will likely be tied to a difference in behavior between 
curl and wget. In fact, one was caught[1] in the development release and the 
fix is included here, with a test.
+ 
+ 
+ [Other Info]
+ N/A
+ 
+ 1. https://bugs.launchpad.net/bugs/1889117

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

Title:
  motd-news: use wget instead of curl

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  In Progress
Status in base-files source package in Bionic:
  In Progress
Status in base-files source package in Focal:
  In Progress

Bug description:
  [Impact] 
  The motd-news script is using curl, but since that is an optional package, 
there is no guarantee that it will be installed. The script correctly checks 
for its presence before trying to use it, though, so it won't fail. As we don't 
want to add such a dependency to the base-files package, we should switch to 
wget, which is standard.

  [Test Case]
  wget has a different behavior than curl in some areas, one of which is 
crucial for the motd-per-cloud feature. While curl will only complain about a 
404 from the server if given a specific parameter (-f), wget does that by 
default, and needs special handling.

  a) With curl, base-files and ubuntu-server installed, first verify motd-news 
works:
  $ sudo /etc/update-motd.d/50-motd-news --force

   * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
 sudo snap install microk8s --channel=1.19/candidate --classic

 https://microk8s.io/ has docs and details.

  Now remove 

[Touch-packages] [Bug 1886572] Re: Remove uptime from the motd-news user agent

[Andreas Hasenack]

** Description changed:

+ [Impact] 
+ The uptime value in the user-agent string sent to the motd-news server is 
unused and not necessary. It should be removed.
+ 
+ [Test Case]
+ Inspect the /etc/update-motd.d/50-motd-news script and verify that uptime is 
no longer used.
+ 
+ Previous version:
+ $ grep uptime /etc/update-motd.d/50-motd-news 
+ # Some messages may only be pertinent before or after some amount of uptime
+ read up idle < /proc/uptime
+ uptime="uptime/$up/$idle"
+ USER_AGENT="curl/$curl_ver $lsb $platform $cpu $uptime cloud_id/$cloud_id"
+ 
+ Updated version:
+ $ grep uptime /etc/update-motd.d/50-motd-news
+  (no output)
+ 
+ 
+ [Regression Potential] 
+ The server side, if it were checking this value, could be surprised by this 
change.
+ 
+ [Other Info]
+ N/A
+ 
+ [Original Description]
  I don't why that was included but it shouldn't be. Please remove it.

** Also affects: base-files (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: base-files (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: base-files (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: base-files (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: base-files (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: base-files (Ubuntu Focal)
   Status: New => In Progress

** Changed in: base-files (Ubuntu Xenial)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: base-files (Ubuntu Bionic)
     Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: base-files (Ubuntu Focal)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

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

Title:
  Remove uptime from the motd-news user agent

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  In Progress
Status in base-files source package in Bionic:
  In Progress
Status in base-files source package in Focal:
  In Progress

Bug description:
  [Impact] 
  The uptime value in the user-agent string sent to the motd-news server is 
unused and not necessary. It should be removed.

  [Test Case]
  Inspect the /etc/update-motd.d/50-motd-news script and verify that uptime is 
no longer used.

  Previous version:
  $ grep uptime /etc/update-motd.d/50-motd-news 
  # Some messages may only be pertinent before or after some amount of uptime
  read up idle < /proc/uptime
  uptime="uptime/$up/$idle"
  USER_AGENT="curl/$curl_ver $lsb $platform $cpu $uptime cloud_id/$cloud_id"

  Updated version:
  $ grep uptime /etc/update-motd.d/50-motd-news
   (no output)

  
  [Regression Potential] 
  The server side, if it were checking this value, could be surprised by this 
change.

  [Other Info]
  N/A

  [Original Description]
  I don't why that was included but it shouldn't be. Please remove it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1886572/+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 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

** Description changed:

  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.
  
  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config
  
  Care must be taken to preserve a changed /etc/default/motd-news when the
  upgrade installs the new motd-news-config package. For example, on a
  server that has set ENABLED=0 in /etc/default/motd-news and upgrades to
  the new base-files and ubuntu-server, and gets the new motd-config-news
  package, ENABLED=0 must remain set.
  
  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled
  
  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification
  
  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled
  
  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled
  
  e) removing motd-news-config will also remove ubuntu-server (since it's
  a depends, and not a recommends)
  
  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files
  
  g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-
  news-server removes the /e/d/motd-news config file
  
  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0
  
  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled
  
  [Regression Potential]
  This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
  a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 
the motd-news-config package when it is installed, otherwise this SRU would 
jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's 
configure case.
  
  b) /e/d/motd-news config file was *removed* while it belonged to base-files. 
In such a case, a normal upgrade of the package (base-files in this example) 
would not reinstate the file. Much less this upgrade here, which has an 
explicit rm_conffile maintscript-helper for it. But the motd-news-config 
package that could be installed in the transaction would place the default 
config file back, and the default is ENABLED=1. Thus, a system that had 
motd-news disabled via removing the config file would now have it re-enabled 
after the upgrade.
  This was trickier to handle, and we do it in base-files's postinst and 
motd-news-config's  postinst. The drawback is that in one scenario, where just 
base-files is upgraded and /e/d/motd-news was manually removed by the user, 
there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" 
below for details).
  
  In general, the regression risks here are:
  - have motd-news enabled again on a system where it was previously disabled. 
We tried to envision two ways it would have been disabled (set ENABLED=0, and 
remove the config file). There are probably others
  - differences in dpkg and/or debhelper behavior in older ubuntu releases 
leading to unexpected results (should be covered by the test cases from this 
SRU)
  - xenial in particular is trickier, because src:base-files there does NOT use 
debhelper, so many of the things we take for granted have to be done by hand
  - have some sort of dpkg postinst or dependency error because of unpredicted 
scenarios. Certain assumptions are being made, like the renames that 
dpkg-maintscript-helper does, and that the filename 
/etc/default/motd-news.wasremoved that I'm touching and verifying is really 
mine and not something that was there already.
  - the versions 

[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

** Description changed:

  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.
  
  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config
  
  Care must be taken to preserve a changed /etc/default/motd-news when the
  upgrade installs the new motd-news-config package. For example, on a
  server that has set ENABLED=0 in /etc/default/motd-news and upgrades to
  the new base-files and ubuntu-server, and gets the new motd-config-news
  package, ENABLED=0 must remain set.
  
  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled
  
  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification
  
  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled
  
  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled
  
  e) removing motd-news-config will also remove ubuntu-server (since it's
  a depends, and not a recommends)
  
  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files
  
  g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-
  news-server removes the /e/d/motd-news config file
  
  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0
  
  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled
  
  [Regression Potential]
  This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
  a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 
the motd-news-config package when it is installed, otherwise this SRU would 
jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's 
configure case.
  
  b) /e/d/motd-news config file was *removed* while it belonged to base-files. 
In such a case, a normal upgrade of the package (base-files in this example) 
would not reinstate the file. Much less this upgrade here, which has an 
explicit rm_conffile maintscript-helper for it. But the motd-news-config 
package that could be installed in the transaction would place the default 
config file back, and the default is ENABLED=1. Thus, a system that had 
motd-news disabled via removing the config file would now have it re-enabled 
after the upgrade.
- This was trickier to handle, and we do it in base-files's postinst and 
motd-news-config's  postinst. The drawback is that in one scenario, where just 
base-files is upgraded, there will be a /e/d/motd-news.wasremoved leftover 
empty file (see "other info" below for details).
+ This was trickier to handle, and we do it in base-files's postinst and 
motd-news-config's  postinst. The drawback is that in one scenario, where just 
base-files is upgraded and /e/d/motd-news was manually removed by the user, 
there will be a /e/d/motd-news.wasremoved leftover empty file (see "other info" 
below for details).
  
  In general, the regression risks here are:
  - have motd-news enabled again on a system where it was previously disabled. 
We tried to envision two ways it would have been disabled (set ENABLED=0, and 
remove the config file). There are probably others
  - differences in dpkg and/or debhelper behavior in older ubuntu releases 
leading to unexpected results (should be covered by the test cases from this 
SRU)
  - xenial in particular is trickier, because src:base-files there does NOT use 
debhelper, so many of the things we take for granted have to be done by hand
  - have some sort of dpkg postinst or dependency error because 

[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

** Description changed:

  [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.
  
  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
  - have ubuntu-server depend on motd-news-config
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on motd-news-config
  
  Care must be taken to preserve a changed /etc/default/motd-news when the
  upgrade installs the new motd-news-config package. For example, on a
  server that has set ENABLED=0 in /etc/default/motd-news and upgrades to
  the new base-files and ubuntu-server, and gets the new motd-config-news
  package, ENABLED=0 must remain set.
  
  [Test Case]
  a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains, motd-news remains enabled
  
  b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
  apt install base-files
  - upgrades ubuntu-server
  - installs motd-news-config
  - /e/d/motd-news remains with the original modification
  
  c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
  apt install base-files
  - upgrades base-files
  - removes /e/d/motd-news
  - motd-news is disabled
  
  d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
  apt install base-files
  - upgrades base-files
  - /e/d/motd-news gets renamed to backup
  - motd-news is disabled
  
  e) removing motd-news-config will also remove ubuntu-server (since it's
  a depends, and not a recommends)
  
  f) upgrading just ubuntu-server should pull motd-news-config in, and
  force-upgrade base-files
  
  g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-
  news-server removes the /e/d/motd-news config file
  
  h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
  - apt install base-files
  - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
  - /e/d/motd-news is installed with ENABLED=0
  
  i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
  - apt install base-files
  - base-files is upgraded
  - no /e/d/motd-news is installed, motd-news remains disabled
  
  [Regression Potential]
+ This update is about config file ownership transfer: /e/d/motd-news belonged 
to base-files, now it belongs to motd-news-config. We tried to handle two 
important cases here:
+ a) /e/d/motd-news config was changed while it belonged to base-files. For 
example, an user could have set ENABLED=0. We need to transfer that change to 
the motd-news-config package when it is installed, otherwise this SRU would 
jsut re-enabled motd-news. This is handled in d/motd-news-config.postinst's 
configure case.
+ 
+ b) /e/d/motd-news config file was *removed* while it belonged to base-files. 
In such a case, a normal upgrade of the package (base-files in this example) 
would not reinstate the file. Much less this upgrade here, which has an 
explicit rm_conffile maintscript-helper for it. But the motd-news-config 
package that could be installed in the transaction would place the default 
config file back, and the default is ENABLED=1. Thus, a system that had 
motd-news disabled via removing the config file would now have it re-enabled 
after the upgrade.
+ This was trickier to handle, and we do it in base-files's postinst and 
motd-news-config's  postinst. The drawback is that in one scenario, where just 
base-files is upgraded, there will be a /e/d/motd-news.wasremoved leftover 
empty file (see "other info" below for details).
+ 
+ In general, the regression risks here are:
+ - have motd-news enabled again on a system where it was previously disabled. 
We tried to envision two ways it would have been disabled (set ENABLED=0, and 
remove the config file). There are probably others
+ - differences in dpkg and/or debhelper behavior in older ubuntu releases 
leading to unexpected results (should be covered by the test cases from this 
SRU)
+ - xenial in particular is trickier, because src:base-files there does NOT use 
debhelper, so many of the things we take for granted have to be done by hand
+ - have some sort of dpkg postinst or dependency error because of unpredicted 
scenarios. Certain assumptions are being made, like the renames that 
dpkg-maintscript-helper does, and that the filename 
/etc/default/motd-news.wasremoved that I'm touching and verifying is really 
mine and not something that was there already.
+ - the versions I'm breaking/replacing on, and using rm_conffiles 

[Touch-packages] [Bug 1888575] Re: Split motd-news config into a new package

[Andreas Hasenack]

** Description changed:

- The motd-news script is largely useless for desktop users, as they
- rarely login via a text console. It makes more sense for server users.
+ [Impact] 
+ The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.
  
  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
  - move /etc/default/motd-news from base-files into a NEW package 
(motd-news-config)
  - have ubuntu-server depend on motd-news-config (or recommends)
  - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends (or recommends) on motd-news-config
  
  Care must be taken to preserve a changed /etc/default/motd-news when the
  upgrade installs the new motd-news-config package. For example, on a
  server that has set ENABLED=0 in /etc/default/motd-news and upgrades to
  the new base-files and ubuntu-server, and gets the new motd-config-news
  package, ENABLED=0 must remain set.
+ 
+ [Test Case]
+ a) base-files installed, ubuntu-server installed, unmodified /e/d/motd-news
+ apt install base-files
+ - upgrades ubuntu-server
+ - installs motd-news-config
+ - /e/d/motd-news remains, motd-news remains enabled
+ 
+ b) base-files installed, ubuntu-server installed, modified /e/d/motd-news
+ apt install base-files
+ - upgrades ubuntu-server
+ - installs motd-news-config
+ - /e/d/motd-news remains with the original modification
+ 
+ c) base-files installed, ubuntu-server not installed, unmodified 
/e/d/motd-news
+ apt install base-files
+ - upgrades base-files
+ - removes /e/d/motd-news
+ - motd-news is disabled
+ 
+ d) base-files installed, ubuntu-server not installed, modified /e/d/motd-news
+ apt install base-files
+ - upgrades base-files
+ - /e/d/motd-news gets renamed to backup
+ - motd-news is disabled
+ 
+ e) removing motd-news-config will also remove ubuntu-server (since it's
+ a depends, and not a recommends)
+ 
+ f) upgrading just ubuntu-server should pull motd-news-config in, and
+ force-upgrade base-files
+ 
+ g) Removing motd-news-server leaves /e/d/motd-news around; purging motd-
+ news-server removes the /e/d/motd-news config file
+ 
+ h) base-files installed, ubuntu-server installed, removed /e/d/motd-news
+ - apt install base-files
+ - upgrades base-files, upgrades ubuntu-server, installs motd-news-config
+ - /e/d/motd-news is installed with ENABLED=0
+ 
+ i) base-files installed, ubuntu-server NOT installed, removed e/d/motd-news
+ - apt install base-files
+ - base-files is upgraded
+ - no /e/d/motd-news is installed, motd-news remains disabled
+ 
+ [Regression Potential]
+ 
+ 
+ [Other Info]
+ 
+ Testcase (i) will leave around an empty /etc/default/motd-news.wasremoved 
file, created by the base-files postinst. This file is removed by the 
motd-news-config postinst, but since that package doesn't get installed in that 
particular scenario, the file remains. I toyed with the idea of adding an extra 
check to base-file's postinst, like this:
+ --- a/debian/postinst.in
+ +++ b/debian/postinst.in
+ @@ -133,7 +133,11 @@ motd_news_config="/etc/default/motd-news"
+  if [ ! -e ${motd_news_config} ]; then
+if [ ! -e ${motd_news_config}.dpkg-remove ]; then
+  if [ ! -e ${motd_news_config}.dpkg-backup ]; then
+ -  touch ${motd_news_config}.wasremoved
+ +  # The .wasremoved file only matters if ubuntu-server is installed,
+ +  # because that's what will pull in motd-news-config
+ +  if dpkg -l ubuntu-server 2>/dev/null | grep -q ^i; then
+ +touch ${motd_news_config}.wasremoved
+ +  fi
+  fi
+fi
+  fi
+ 
+ But deemed it too risky, and not worth further potential regressions.

** Description changed:

- [Impact] 
+ [Impact]
  The motd-news script is largely useless for desktop users, as they rarely 
login via a text console. It makes more sense for server users.
  
  We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
- - move /etc/default/motd-news from base-files into a NEW package 
(motd-news-config)
- - have ubuntu-server depend on motd-news-config (or recommends)
- - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends (or recommends) on motd-news-config
+ - move /etc/default/motd-news from base-files into a new binary package 
(motd-news-config, produced by src:base-files)
+ - have ubuntu-server depend on motd-news-config
+ - have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends on 

[Touch-packages] [Bug 1872118] Re: [SRU] DHCP Cluster crashes after a few hours

[Andreas Hasenack]

bind9 in focal uses the 9.16.x versions of these libraries, packaged
separately. It's just 9.11.x that was packaged as bind9-libs because of
legacy applications like isc-dhcp that do not work with the 9.16 version
of bind9.

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

Title:
  [SRU] DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  In Progress
Status in isc-dhcp package in Ubuntu:
  In Progress
Status in bind9-libs source package in Focal:
  In Progress
Status in isc-dhcp source package in Focal:
  In Progress
Status in bind9-libs source package in Groovy:
  In Progress
Status in isc-dhcp source package in Groovy:
  In Progress

Bug description:
  [Description]

  isc-dhcp-server uses libisc-export (coming from bind9-libs package) for 
handling the socket event(s) when configured in peer mode (master/secondary). 
It's possible that a sequence of messages dispatched by the master that 
requires acknowledgment from its peers holds a socket
  in a pending to send state, a timer or a subsequent write request can be 
scheduled into this socket and the !sock->pending_send assertion
  will be raised when trying to write again at the time data hasn't been 
flushed entirely and the pending_send flag hasn't been reset to 0 state.

  If this race condition happens, the following stacktrace will be
  hit:

  (gdb) info threads
    Id Target Id Frame
  * 1 Thread 0x7fb4ddecb700 (LWP 3170) __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
    2 Thread 0x7fb4dd6ca700 (LWP 3171) __lll_lock_wait 
(futex=futex@entry=0x7fb4de6d2028, private=0) at lowlevellock.c:52
    3 Thread 0x7fb4de6cc700 (LWP 3169) futex_wake (private=, 
processes_to_wake=1, futex_word=) at 
../sysdeps/nptl/futex-internal.h:364
    4 Thread 0x7fb4de74f740 (LWP 3148) futex_wait_cancelable 
(private=, expected=0, futex_word=0x7fb4de6cd0d0) at 
../sysdeps/nptl/futex-internal.h:183

  (gdb) frame 2
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  (gdb) bt
  #1 0x7fb4deaa7859 in __GI_abort () at abort.c:79
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  #4 process_fd (writeable=, readable=, fd=11, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4054
  #5 process_fds (writefds=, readfds=0x7fb4de6d1090, maxfd=13, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4211
  #6 watcher (uap=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4397
  #7 0x7fb4dea68609 in start_thread (arg=) at 
pthread_create.c:477
  #8 0x7fb4deba4103 in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

  (gdb) frame 3
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  4041 in ../../../../lib/isc/unix/socket.c
  (gdb) p sock->pending_send
  $2 = 1

  [TEST CASE]

  1) Install isc-dhcp-server in 2 focal machine(s).
  2) Configure peer/cluster mode as follows:
     Primary configuration: https://pastebin.ubuntu.com/p/XYj648MghK/
     Secondary configuration: https://pastebin.ubuntu.com/p/PYkcshZCWK/
  2) Run dhcpd as follows in both machine(s)

  # dhcpd -f -d -4 -cf /etc/dhcp/dhcpd.conf --no-pid ens4

  3) Leave the cluster running for a long (2h) period until the
  crash/race condition is reproduced.

  [REGRESSION POTENTIAL]

  * The fix will prevent the assertion to happen in the dispatch_send
  path, later versions of isch-dhcp upstream lack this logic and entirely 
removed the existence of this flag. Therefore, removing the need for this
  assertion at process_fd shouldn't be problematic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dhcp/+bug/1872118/+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 1889117] [NEW] switch to wget results in no motd-news in clouds

[Andreas Hasenack]

Public bug reported:

cloud-specific motd news relies on the user-agent string cloud_id
/ being included in the user-agent. The server, when
receiving this string, will try to return the cloud-specific index file,
which is `index.txt.`. If that file doesn't exist, then the
404 error document is returned, which happens to be set to the default
`index.txt` normal motd-news file.

curl happily returns that without flagging this as an error situation (a
404: it needs an extra command-line argument for that). wget, however,
fails without printing the error document:

$ wget -U cloud_id/aws https://motd.ubuntu.com -O-
--2020-07-27 15:45:47--  https://motd.ubuntu.com/
Resolving motd.ubuntu.com (motd.ubuntu.com)... 54.171.230.55, 34.249.145.219, 
2a05:d018:91c:3200:c887:2f22:290f:a7c, ...
Connecting to motd.ubuntu.com (motd.ubuntu.com)|54.171.230.55|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2020-07-27 15:45:48 ERROR 404: Not Found.

Not only that, it will also fail in its exit status:
$ echo $?
8

Whereas curl didn't:
$ curl -A cloud_id/aws https://motd.ubuntu.com
 * "If you've been waiting for the perfect Kubernetes dev solution for
   macOS, the wait is over. Learn how to install Microk8s on macOS."

   https://www.techrepublic.com/article/how-to-install-microk8s-on-macos/
$ echo $?
0
$ 


We need to pass --content-on-error, ignore the error status 8 (or all?) and 
make it quiet (-q):

$ wget -U cloud_id/aws https://motd.ubuntu.com -O- --content-on-error -q ; echo 
$?
 * "If you've been waiting for the perfect Kubernetes dev solution for
   macOS, the wait is over. Learn how to install Microk8s on macOS."

   https://www.techrepublic.com/article/how-to-install-microk8s-on-macos/
8

** Affects: base-files (Ubuntu)
 Importance: Undecided
     Assignee: Andreas Hasenack (ahasenack)
 Status: In Progress

** Changed in: base-files (Ubuntu)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: base-files (Ubuntu)
   Status: New => In Progress

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

Title:
  switch to wget results in no motd-news in clouds

Status in base-files package in Ubuntu:
  In Progress

Bug description:
  cloud-specific motd news relies on the user-agent string cloud_id
  / being included in the user-agent. The server, when
  receiving this string, will try to return the cloud-specific index
  file, which is `index.txt.`. If that file doesn't exist,
  then the 404 error document is returned, which happens to be set to
  the default `index.txt` normal motd-news file.

  curl happily returns that without flagging this as an error situation
  (a 404: it needs an extra command-line argument for that). wget,
  however, fails without printing the error document:

  $ wget -U cloud_id/aws https://motd.ubuntu.com -O-
  --2020-07-27 15:45:47--  https://motd.ubuntu.com/
  Resolving motd.ubuntu.com (motd.ubuntu.com)... 54.171.230.55, 34.249.145.219, 
2a05:d018:91c:3200:c887:2f22:290f:a7c, ...
  Connecting to motd.ubuntu.com (motd.ubuntu.com)|54.171.230.55|:443... 
connected.
  HTTP request sent, awaiting response... 404 Not Found
  2020-07-27 15:45:48 ERROR 404: Not Found.

  Not only that, it will also fail in its exit status:
  $ echo $?
  8

  Whereas curl didn't:
  $ curl -A cloud_id/aws https://motd.ubuntu.com
   * "If you've been waiting for the perfect Kubernetes dev solution for
 macOS, the wait is over. Learn how to install Microk8s on macOS."

 https://www.techrepublic.com/article/how-to-install-microk8s-on-macos/
  $ echo $?
  0
  $ 

  
  We need to pass --content-on-error, ignore the error status 8 (or all?) and 
make it quiet (-q):

  $ wget -U cloud_id/aws https://motd.ubuntu.com -O- --content-on-error -q ; 
echo $?
   * "If you've been waiting for the perfect Kubernetes dev solution for
 macOS, the wait is over. Learn how to install Microk8s on macOS."

 https://www.techrepublic.com/article/how-to-install-microk8s-on-macos/
  8

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1889117/+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 1887577] Re: DEP8: Invalid capability setuid

[Andreas Hasenack]

Hm, not sure, it works for me on a focal host:

$ cat Makefile 
# emits defined capabilities in a simple list, e.g. "CAP_NAME CAP_NAME2"
CAPABILITIES=$(shell echo "\#include " | cpp -dM | LC_ALL=C 
sed -n -e '/CAP_EMPTY_SET/d' -e 's/^\#define[ \t]\+CAP_\([A-Z0-9_]\+\)[ 
\t]\+\([0-9xa-f]\+\)\(.*\)$$/CAP_\1/p' | LC_ALL=C sort)

all:
@echo $(CAPABILITIES)

$ make
CAP_AUDIT_CONTROL CAP_AUDIT_READ CAP_AUDIT_WRITE CAP_BLOCK_SUSPEND CAP_CHOWN 
CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_FOWNER CAP_FSETID CAP_IPC_LOCK 
CAP_IPC_OWNER CAP_KILL CAP_LEASE CAP_LINUX_IMMUTABLE CAP_MAC_ADMIN 
CAP_MAC_OVERRIDE CAP_MKNOD CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST 
CAP_NET_RAW CAP_SETFCAP CAP_SETGID CAP_SETPCAP CAP_SETUID CAP_SYSLOG 
CAP_SYS_ADMIN CAP_SYS_BOOT CAP_SYS_CHROOT CAP_SYS_MODULE CAP_SYS_NICE 
CAP_SYS_PACCT CAP_SYS_PTRACE CAP_SYS_RAWIO CAP_SYS_RESOURCE CAP_SYS_TIME 
CAP_SYS_TTY_CONFIG CAP_WAKE_ALARM


Interesting, on groovy it doesn't:
$ make

$

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

Title:
  DEP8: Invalid capability setuid

Status in apparmor package in Ubuntu:
  New

Bug description:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-
  groovy/groovy/amd64/a/apparmor/20200713_202347_dd214@/log.gz

  Excuses is showing apparmor failing dep8 tests when they are triggered
  by another package.

  last time apparmor was uploaded was on May 14th, and this is the
  package under test:

  https://launchpad.net/ubuntu/+source/apparmor/2.13.3-7ubuntu6

  
  The errors are like this:
  FAIL: test_profile_newer_rewrites_cache (__main__.AAParserAltCacheTests)
  --
  Traceback (most recent call last):
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 50, in 
new_unittest_func
  return unittest_func(self)
File "./caching.py", line 448, in test_profile_newer_rewrites_cache
  self._generate_cache_file()
File "./caching.py", line 257, in _generate_cache_file
  self.run_cmd_check(cmd)
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 73, in run_cmd_check
  self.assertEqual(rc, expected_rc, "Got return code %d, expected 
%d\nCommand run: %s\nOutput: %s" % (rc, expected_rc, (' '.join(command)), 
report))
  AssertionError: 1 != 0 : Got return code 1, expected 0
  Command run: ../apparmor_parser --config-file=./parser.conf --base 
/tmp/aa-caching-s3l9wndt --skip-kernel-load --cache-loc 
/tmp/aa-caching-s3l9wndt/cache --cache-loc 
/tmp/aa-caching-s3l9wndt/aa-alt-cachezi43qt78 -q --write-cache -r 
/tmp/aa-caching-s3l9wndt/sbin.pingy
  Output: AppArmor parser error for /tmp/aa-caching-s3l9wndt/sbin.pingy in 
/tmp/aa-caching-s3l9wndt/suid-abstraction at line 3: Invalid capability setuid.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1887577/+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 1888575] [NEW] Split motd-news config into a new package

[Andreas Hasenack]

Public bug reported:

The motd-news script is largely useless for desktop users, as they
rarely login via a text console. It makes more sense for server users.

We can use package dependencies to have the motd-news script enabled on 
servers, but disabled on desktops, and still handle upgrades. This is the plan:
- move /etc/default/motd-news from base-files into a NEW package 
(motd-news-config)
- have ubuntu-server depend on motd-news-config (or recommends)
- have base-files break current ubuntu-server, so that if base-files if 
upgraded and ubuntu-server is installed, ubuntu-server will also be upgraded to 
the new version which has the depends (or recommends) on motd-news-config

Care must be taken to preserve a changed /etc/default/motd-news when the
upgrade installs the new motd-news-config package. For example, on a
server that has set ENABLED=0 in /etc/default/motd-news and upgrades to
the new base-files and ubuntu-server, and gets the new motd-config-news
package, ENABLED=0 must remain set.

** Affects: base-files (Ubuntu)
 Importance: Undecided
 Assignee: Andreas Hasenack (ahasenack)
 Status: In Progress

** Affects: ubuntu-meta (Ubuntu)
 Importance: Undecided
 Assignee: Andreas Hasenack (ahasenack)
 Status: In Progress

** Affects: base-files (Ubuntu Xenial)
 Importance: Undecided
 Assignee: Andreas Hasenack (ahasenack)
 Status: In Progress

** Affects: ubuntu-meta (Ubuntu Xenial)
 Importance: Undecided
 Assignee: Andreas Hasenack (ahasenack)
 Status: In Progress

** Affects: base-files (Ubuntu Bionic)
 Importance: Undecided
 Assignee: Andreas Hasenack (ahasenack)
 Status: In Progress

** Affects: ubuntu-meta (Ubuntu Bionic)
 Importance: Undecided
 Assignee: Andreas Hasenack (ahasenack)
 Status: In Progress

** Affects: base-files (Ubuntu Focal)
 Importance: Undecided
 Assignee: Andreas Hasenack (ahasenack)
 Status: In Progress

** Affects: ubuntu-meta (Ubuntu Focal)
 Importance: Undecided
 Assignee: Andreas Hasenack (ahasenack)
 Status: In Progress

** Affects: base-files (Ubuntu Groovy)
 Importance: Undecided
 Assignee: Andreas Hasenack (ahasenack)
 Status: In Progress

** Affects: ubuntu-meta (Ubuntu Groovy)
 Importance: Undecided
 Assignee: Andreas Hasenack (ahasenack)
 Status: In Progress

** Also affects: ubuntu-meta (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: base-files (Ubuntu Groovy)
   Importance: Undecided
 Assignee: Andreas Hasenack (ahasenack)
   Status: In Progress

** Also affects: ubuntu-meta (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: base-files (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: ubuntu-meta (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: base-files (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: ubuntu-meta (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: base-files (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: ubuntu-meta (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: base-files (Ubuntu Xenial)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: base-files (Ubuntu Bionic)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: base-files (Ubuntu Focal)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: ubuntu-meta (Ubuntu Xenial)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: ubuntu-meta (Ubuntu Bionic)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: ubuntu-meta (Ubuntu Focal)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: ubuntu-meta (Ubuntu Groovy)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: base-files (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: base-files (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: base-files (Ubuntu Focal)
   Status: New => In Progress

** Changed in: ubuntu-meta (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: ubuntu-meta (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: ubuntu-meta (Ubuntu Focal)
   Status: New => In Progress

** Changed in: ubuntu-meta (Ubuntu Groovy)
   Status: New => In Progress

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

Title:
  Split motd-news config into a new package

Status in base-files package in Ubuntu:
  In Progress
Status in ubuntu-meta package in Ubuntu:
  In Progress
Status in base-files source package in Xenial:
  In Progress
Status in ubuntu-meta source packa

[Touch-packages] [Bug 1888572] Re: motd-news: use wget instead of curl

[Andreas Hasenack]

This was fixed for groovy in https://launchpad.net/ubuntu/+source/base-
files/11ubuntu9

** Changed in: base-files (Ubuntu)
   Status: In Progress => Fix Released

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

Title:
  motd-news: use wget instead of curl

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  In Progress
Status in base-files source package in Bionic:
  In Progress
Status in base-files source package in Focal:
  In Progress

Bug description:
  The motd-news script is using curl, but since that is an optional
  package, there is no guarantee that it will be installed. The script
  correctly checks for its presence before trying to use it, though, so
  it won't fail. As we don't want to add such a dependency to the base-
  files package, we should switch to wget, which is standard.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888572/+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 1888572] [NEW] motd-news: use wget instead of curl

[Andreas Hasenack]

Public bug reported:

The motd-news script is using curl, but since that is an optional
package, there is no guarantee that it will be installed. The script
correctly checks for its presence before trying to use it, though, so it
won't fail. As we don't want to add such a dependency to the base-files
package, we should switch to wget, which is standard.

** Affects: base-files (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: base-files (Ubuntu Xenial)
 Importance: Undecided
 Assignee: Andreas Hasenack (ahasenack)
 Status: In Progress

** Affects: base-files (Ubuntu Bionic)
 Importance: Undecided
 Assignee: Andreas Hasenack (ahasenack)
 Status: In Progress

** Affects: base-files (Ubuntu Focal)
 Importance: Undecided
 Assignee: Andreas Hasenack (ahasenack)
 Status: In Progress

** Also affects: base-files (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: base-files (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: base-files (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: base-files (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: base-files (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: base-files (Ubuntu Focal)
   Status: New => In Progress

** Changed in: base-files (Ubuntu Xenial)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: base-files (Ubuntu Bionic)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: base-files (Ubuntu Focal)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: base-files (Ubuntu)
 Assignee: Andreas Hasenack (ahasenack) => (unassigned)

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

Title:
  motd-news: use wget instead of curl

Status in base-files package in Ubuntu:
  Fix Released
Status in base-files source package in Xenial:
  In Progress
Status in base-files source package in Bionic:
  In Progress
Status in base-files source package in Focal:
  In Progress

Bug description:
  The motd-news script is using curl, but since that is an optional
  package, there is no guarantee that it will be installed. The script
  correctly checks for its presence before trying to use it, though, so
  it won't fail. As we don't want to add such a dependency to the base-
  files package, we should switch to wget, which is standard.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1888572/+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 1887577] Re: DEP8: Invalid capability setuid

[Andreas Hasenack]

** Tags added: update-excuses

** Tags added: update-excuse

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

Title:
  DEP8: Invalid capability setuid

Status in apparmor package in Ubuntu:
  New

Bug description:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-
  groovy/groovy/amd64/a/apparmor/20200713_202347_dd214@/log.gz

  Excuses is showing apparmor failing dep8 tests when they are triggered
  by another package.

  last time apparmor was uploaded was on May 14th, and this is the
  package under test:

  https://launchpad.net/ubuntu/+source/apparmor/2.13.3-7ubuntu6

  
  The errors are like this:
  FAIL: test_profile_newer_rewrites_cache (__main__.AAParserAltCacheTests)
  --
  Traceback (most recent call last):
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 50, in 
new_unittest_func
  return unittest_func(self)
File "./caching.py", line 448, in test_profile_newer_rewrites_cache
  self._generate_cache_file()
File "./caching.py", line 257, in _generate_cache_file
  self.run_cmd_check(cmd)
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 73, in run_cmd_check
  self.assertEqual(rc, expected_rc, "Got return code %d, expected 
%d\nCommand run: %s\nOutput: %s" % (rc, expected_rc, (' '.join(command)), 
report))
  AssertionError: 1 != 0 : Got return code 1, expected 0
  Command run: ../apparmor_parser --config-file=./parser.conf --base 
/tmp/aa-caching-s3l9wndt --skip-kernel-load --cache-loc 
/tmp/aa-caching-s3l9wndt/cache --cache-loc 
/tmp/aa-caching-s3l9wndt/aa-alt-cachezi43qt78 -q --write-cache -r 
/tmp/aa-caching-s3l9wndt/sbin.pingy
  Output: AppArmor parser error for /tmp/aa-caching-s3l9wndt/sbin.pingy in 
/tmp/aa-caching-s3l9wndt/suid-abstraction at line 3: Invalid capability setuid.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1887577/+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 1887577] [NEW] DEP8: Invalid capability setuid

[Andreas Hasenack]

Public bug reported:

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
/autopkgtest-
groovy/groovy/amd64/a/apparmor/20200713_202347_dd214@/log.gz

Excuses is showing apparmor failing dep8 tests when they are triggered
by another package.

last time apparmor was uploaded was on May 14th, and this is the package
under test:

https://launchpad.net/ubuntu/+source/apparmor/2.13.3-7ubuntu6


The errors are like this:
FAIL: test_profile_newer_rewrites_cache (__main__.AAParserAltCacheTests)
--
Traceback (most recent call last):
  File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 50, in 
new_unittest_func
return unittest_func(self)
  File "./caching.py", line 448, in test_profile_newer_rewrites_cache
self._generate_cache_file()
  File "./caching.py", line 257, in _generate_cache_file
self.run_cmd_check(cmd)
  File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 73, in run_cmd_check
self.assertEqual(rc, expected_rc, "Got return code %d, expected %d\nCommand 
run: %s\nOutput: %s" % (rc, expected_rc, (' '.join(command)), report))
AssertionError: 1 != 0 : Got return code 1, expected 0
Command run: ../apparmor_parser --config-file=./parser.conf --base 
/tmp/aa-caching-s3l9wndt --skip-kernel-load --cache-loc 
/tmp/aa-caching-s3l9wndt/cache --cache-loc 
/tmp/aa-caching-s3l9wndt/aa-alt-cachezi43qt78 -q --write-cache -r 
/tmp/aa-caching-s3l9wndt/sbin.pingy
Output: AppArmor parser error for /tmp/aa-caching-s3l9wndt/sbin.pingy in 
/tmp/aa-caching-s3l9wndt/suid-abstraction at line 3: Invalid capability setuid.

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


** Tags: dep8

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

Title:
  DEP8: Invalid capability setuid

Status in apparmor package in Ubuntu:
  New

Bug description:
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-
  groovy/groovy/amd64/a/apparmor/20200713_202347_dd214@/log.gz

  Excuses is showing apparmor failing dep8 tests when they are triggered
  by another package.

  last time apparmor was uploaded was on May 14th, and this is the
  package under test:

  https://launchpad.net/ubuntu/+source/apparmor/2.13.3-7ubuntu6

  
  The errors are like this:
  FAIL: test_profile_newer_rewrites_cache (__main__.AAParserAltCacheTests)
  --
  Traceback (most recent call last):
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 50, in 
new_unittest_func
  return unittest_func(self)
File "./caching.py", line 448, in test_profile_newer_rewrites_cache
  self._generate_cache_file()
File "./caching.py", line 257, in _generate_cache_file
  self.run_cmd_check(cmd)
File "/tmp/tmp.40nJ4LqRYT/parser/tst/testlib.py", line 73, in run_cmd_check
  self.assertEqual(rc, expected_rc, "Got return code %d, expected 
%d\nCommand run: %s\nOutput: %s" % (rc, expected_rc, (' '.join(command)), 
report))
  AssertionError: 1 != 0 : Got return code 1, expected 0
  Command run: ../apparmor_parser --config-file=./parser.conf --base 
/tmp/aa-caching-s3l9wndt --skip-kernel-load --cache-loc 
/tmp/aa-caching-s3l9wndt/cache --cache-loc 
/tmp/aa-caching-s3l9wndt/aa-alt-cachezi43qt78 -q --write-cache -r 
/tmp/aa-caching-s3l9wndt/sbin.pingy
  Output: AppArmor parser error for /tmp/aa-caching-s3l9wndt/sbin.pingy in 
/tmp/aa-caching-s3l9wndt/suid-abstraction at line 3: Invalid capability setuid.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1887577/+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 1557157] Re: apparmor profile denied for saslauthd: /run/saslauthd/mux

[Andreas Hasenack]

Kopanocore armhf is the only persistent red, but this test/package is
known to be flaky on armhf.

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

Title:
  apparmor profile denied for saslauthd: /run/saslauthd/mux

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Trusty:
  Won't Fix
Status in openldap source package in Xenial:
  Fix Committed
Status in openldap source package in Bionic:
  Fix Committed
Status in openldap source package in Eoan:
  Fix Committed
Status in openldap source package in Focal:
  Fix Committed
Status in openldap source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  When using openldap with sasl authentication, the slapd process will
  communicate with the saslauthd daemon via a socket in
  {,/var}/run/saslauthd/mux. Unfortunately, this will fail in every
  Ubuntu release from trusty onwards, because slapd's apparmor profile
  doesn't contain the necessary directive to allow it to read/write
  from/to the socket specified above.

  The fix is simple: just add the necessary directive to allow slapd to
  read/write from/to the saslauthd socket.

  [Test Case]

  One can reproduce the problem by doing:

  $ lxc launch ubuntu-daily:groovy openldap-bugbug1557157-groovy
  $ lxc shell openldap-bugbug1557157-groovy
  # apt install slapd sasl2-bin ldap-utils apparmor-utils

  (As the domain name, use "example.com").

  # sed -i -e 's/^START=.*/START=yes/' /etc/default/saslauthd
  # cat > /etc/ldap/sasl2/slapd.conf << __EOF__
  mech_list: PLAIN
  pwcheck_method: saslauthd
  __EOF__
  # adduser openldap sasl
  # aa-enforce /etc/apparmor.d/usr.sbin.slapd
  # systemctl restart slapd.service
  # systemctl restart saslauthd.service
  # passwd root

  (You can choose any password here. You will need to type it when
  running the next command.)

  # ldapsearch -H ldapi:/// -LLL -b 'dc=example,dc=com' -s base -U root
  -Y PLAIN

  The command will fail with something like:

  ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
  additional info: SASL(-1): generic failure: Password verification 
failed

  [Regression Potential]

  This is an extremely simple and well contained fix, so I don't
  envision any possible regressions after applying it.  It is important
  noticing that, since the problem affects older Ubuntu releases, the
  openldap package will have to be rebuilt against possible newer
  versions of libraries and other depencencies, which, albeit unlikely,
  may cause issues.

  [Original Description]

  When using slapd with saslauthd the processes communicate via the
  {,/var}/run/saslauthd/mux socket (this is the default location for the
  saslauthd server from the sasl2-bin package in the
  /etc/default/saslauthd config), but the apparmor profile for
  usr.sbin.slapd does not allow access to this socket/file.

  Syslog message:
  apparmor="DENIED" operation="connect" profile="/usr/sbin/slapd" 
name="/run/saslauthd/mux" pid=1880
  4 comm="slapd" requested_mask="r" denied_mask="r" fsuid=108 ouid=0

  Please add the following line to  /etc/apparmor.d/usr.sbin.slapd:
  /{,var/}run/saslauthd/mux rw,

  Ubuntu version: Ubuntu 14.04.4 LTS
  slapd version: 2.4.31-1+nmu2ubu

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557157/+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 1866303] Re: slapd crash with pwdAccountLockedTime and stacked overlays

[Andreas Hasenack]

Kopanocore armhf is the only persistent red, but this test/package is
known to be flaky on armhf.

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

Title:
  slapd crash with pwdAccountLockedTime and stacked overlays

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  Fix Committed
Status in openldap source package in Bionic:
  Fix Committed
Status in openldap source package in Disco:
  Won't Fix
Status in openldap source package in Eoan:
  Fix Committed
Status in openldap package in Debian:
  Fix Released

Bug description:
  [Impact]
  In the configuration and conditions described below, slapd can crash:

  1. ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  [Test Case]

  * get the files from the bug:
  mkdir slapd-test-case; cd slapd-test-case
  wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334194/+files/slapd.conf
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334195/+files/data.ldif
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334196/+files/samba.schema
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334197/+files/script

  * run the script:
  sudo apt update && sudo sh ./script

  * With the bug, the result is:
  ldap_bind: Invalid credentials (49)
  slapd dead

  * If when confirming the bug you don't see "slapd dead" like above,
  check manually, as slapd might have been in the process of shutting
  down when the script checked its status: "sudo systemctl status slapd"

  * With the fixed packages, you get a living slapd at the end (you can
  run the script again on the same system after updating the packages):

  sudo sh ./script
  ...
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running

  [Regression Potential]
  The fix is in the password policy overlay (not enabled by default), so any 
regressions would be around that area and could potentially impact 
authentication ("binding") to openldap.

  [Other Info]
  This was fixed in focal and "cooked" there for a long while, as suggested by 
the Debian maintainer. We haven't received further bug reports about this in 
focal+.

  [Original Description]

  Hello,

  Please merge openldap 2.4.49+dfsg-2 from Debian unstable to fix an
  issue in the ppolicy overlay that can crash slapd. Please also
  consider SRUing the patch after it has had some testing time.

  Upstream: https://openldap.org/its/?findid=9171
  Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953150

  The ingredients for the crash are:

  1: ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  The buggy code is not as specific as the above steps, so I suspect
  there are probably other configurations or steps that can trigger the
  same crash.

  I will attach my test script and data for reproducing the crash.

  Expected output (last lines):

  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running

  Actual output (last lines):

  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd dead

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+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 1557157] Re: apparmor profile denied for saslauthd: /run/saslauthd/mux

[Andreas Hasenack]

The asterisk DEP8 armhf test was retried and is now green.

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

Title:
  apparmor profile denied for saslauthd: /run/saslauthd/mux

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Trusty:
  Won't Fix
Status in openldap source package in Xenial:
  Fix Committed
Status in openldap source package in Bionic:
  Fix Committed
Status in openldap source package in Eoan:
  Fix Committed
Status in openldap source package in Focal:
  Fix Committed
Status in openldap source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  When using openldap with sasl authentication, the slapd process will
  communicate with the saslauthd daemon via a socket in
  {,/var}/run/saslauthd/mux. Unfortunately, this will fail in every
  Ubuntu release from trusty onwards, because slapd's apparmor profile
  doesn't contain the necessary directive to allow it to read/write
  from/to the socket specified above.

  The fix is simple: just add the necessary directive to allow slapd to
  read/write from/to the saslauthd socket.

  [Test Case]

  One can reproduce the problem by doing:

  $ lxc launch ubuntu-daily:groovy openldap-bugbug1557157-groovy
  $ lxc shell openldap-bugbug1557157-groovy
  # apt install slapd sasl2-bin ldap-utils apparmor-utils

  (As the domain name, use "example.com").

  # sed -i -e 's/^START=.*/START=yes/' /etc/default/saslauthd
  # cat > /etc/ldap/sasl2/slapd.conf << __EOF__
  mech_list: PLAIN
  pwcheck_method: saslauthd
  __EOF__
  # adduser openldap sasl
  # aa-enforce /etc/apparmor.d/usr.sbin.slapd
  # systemctl restart slapd.service
  # systemctl restart saslauthd.service
  # passwd root

  (You can choose any password here. You will need to type it when
  running the next command.)

  # ldapsearch -H ldapi:/// -LLL -b 'dc=example,dc=com' -s base -U root
  -Y PLAIN

  The command will fail with something like:

  ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
  additional info: SASL(-1): generic failure: Password verification 
failed

  [Regression Potential]

  This is an extremely simple and well contained fix, so I don't
  envision any possible regressions after applying it.  It is important
  noticing that, since the problem affects older Ubuntu releases, the
  openldap package will have to be rebuilt against possible newer
  versions of libraries and other depencencies, which, albeit unlikely,
  may cause issues.

  [Original Description]

  When using slapd with saslauthd the processes communicate via the
  {,/var}/run/saslauthd/mux socket (this is the default location for the
  saslauthd server from the sasl2-bin package in the
  /etc/default/saslauthd config), but the apparmor profile for
  usr.sbin.slapd does not allow access to this socket/file.

  Syslog message:
  apparmor="DENIED" operation="connect" profile="/usr/sbin/slapd" 
name="/run/saslauthd/mux" pid=1880
  4 comm="slapd" requested_mask="r" denied_mask="r" fsuid=108 ouid=0

  Please add the following line to  /etc/apparmor.d/usr.sbin.slapd:
  /{,var/}run/saslauthd/mux rw,

  Ubuntu version: Ubuntu 14.04.4 LTS
  slapd version: 2.4.31-1+nmu2ubu

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557157/+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 1866303] Re: slapd crash with pwdAccountLockedTime and stacked overlays

[Andreas Hasenack]

Eoan verification

Reproducing the problem:
  Version table:
 *** 2.4.48+dfsg-1ubuntu1.1 500
500 http://br.archive.ubuntu.com/ubuntu eoan-updates/main amd64 Packages
500 http://br.archive.ubuntu.com/ubuntu eoan-security/main amd64 
Packages
100 /var/lib/dpkg/status

ubuntu@eoan-openldap-crash-1866303:~/slapd-test-case$ sudo sh ./script
...
Closing DB...
slapd running
ldap_bind: Invalid credentials (49)
slapd dead


With the proposed packages:
  Version table:
 *** 2.4.48+dfsg-1ubuntu1.2 500
500 http://br.archive.ubuntu.com/ubuntu eoan-proposed/main amd64 
Packages
100 /var/lib/dpkg/status


slapd remains running:
ubuntu@eoan-openldap-crash-1866303:~/slapd-test-case$ sudo sh ./script
...
Closing DB...
slapd running
ldap_bind: Invalid credentials (49)
slapd running


Eoan verification succeeded.

** Tags removed: verification-needed-eoan
** Tags added: verification-done-eoan

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

Title:
  slapd crash with pwdAccountLockedTime and stacked overlays

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  Fix Committed
Status in openldap source package in Bionic:
  Fix Committed
Status in openldap source package in Disco:
  Won't Fix
Status in openldap source package in Eoan:
  Fix Committed
Status in openldap package in Debian:
  Fix Released

Bug description:
  [Impact]
  In the configuration and conditions described below, slapd can crash:

  1. ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  [Test Case]

  * get the files from the bug:
  mkdir slapd-test-case; cd slapd-test-case
  wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334194/+files/slapd.conf
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334195/+files/data.ldif
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334196/+files/samba.schema
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334197/+files/script

  * run the script:
  sudo apt update && sudo sh ./script

  * With the bug, the result is:
  ldap_bind: Invalid credentials (49)
  slapd dead

  * If when confirming the bug you don't see "slapd dead" like above,
  check manually, as slapd might have been in the process of shutting
  down when the script checked its status: "sudo systemctl status slapd"

  * With the fixed packages, you get a living slapd at the end (you can
  run the script again on the same system after updating the packages):

  sudo sh ./script
  ...
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running

  [Regression Potential]
  The fix is in the password policy overlay (not enabled by default), so any 
regressions would be around that area and could potentially impact 
authentication ("binding") to openldap.

  [Other Info]
  This was fixed in focal and "cooked" there for a long while, as suggested by 
the Debian maintainer. We haven't received further bug reports about this in 
focal+.

  [Original Description]

  Hello,

  Please merge openldap 2.4.49+dfsg-2 from Debian unstable to fix an
  issue in the ppolicy overlay that can crash slapd. Please also
  consider SRUing the patch after it has had some testing time.

  Upstream: https://openldap.org/its/?findid=9171
  Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953150

  The ingredients for the crash are:

  1: ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  The buggy code is not as specific as the above steps, so I suspect
  there are probably other configurations or steps that can trigger the
  same crash.

  I will attach my test script and data for reproducing the crash.

  Expected output (last lines):

  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running

  Actual output (last lines):

  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd dead

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+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 1866303] Re: slapd crash with pwdAccountLockedTime and stacked overlays

[Andreas Hasenack]

The asterisk DEP8 armhf test was retried and is now green.

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

Title:
  slapd crash with pwdAccountLockedTime and stacked overlays

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  Fix Committed
Status in openldap source package in Bionic:
  Fix Committed
Status in openldap source package in Disco:
  Won't Fix
Status in openldap source package in Eoan:
  Fix Committed
Status in openldap package in Debian:
  Fix Released

Bug description:
  [Impact]
  In the configuration and conditions described below, slapd can crash:

  1. ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  [Test Case]

  * get the files from the bug:
  mkdir slapd-test-case; cd slapd-test-case
  wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334194/+files/slapd.conf
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334195/+files/data.ldif
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334196/+files/samba.schema
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334197/+files/script

  * run the script:
  sudo apt update && sudo sh ./script

  * With the bug, the result is:
  ldap_bind: Invalid credentials (49)
  slapd dead

  * If when confirming the bug you don't see "slapd dead" like above,
  check manually, as slapd might have been in the process of shutting
  down when the script checked its status: "sudo systemctl status slapd"

  * With the fixed packages, you get a living slapd at the end (you can
  run the script again on the same system after updating the packages):

  sudo sh ./script
  ...
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running

  [Regression Potential]
  The fix is in the password policy overlay (not enabled by default), so any 
regressions would be around that area and could potentially impact 
authentication ("binding") to openldap.

  [Other Info]
  This was fixed in focal and "cooked" there for a long while, as suggested by 
the Debian maintainer. We haven't received further bug reports about this in 
focal+.

  [Original Description]

  Hello,

  Please merge openldap 2.4.49+dfsg-2 from Debian unstable to fix an
  issue in the ppolicy overlay that can crash slapd. Please also
  consider SRUing the patch after it has had some testing time.

  Upstream: https://openldap.org/its/?findid=9171
  Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953150

  The ingredients for the crash are:

  1: ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  The buggy code is not as specific as the above steps, so I suspect
  there are probably other configurations or steps that can trigger the
  same crash.

  I will attach my test script and data for reproducing the crash.

  Expected output (last lines):

  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running

  Actual output (last lines):

  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd dead

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+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 1866303] Re: slapd crash with pwdAccountLockedTime and stacked overlays

[Andreas Hasenack]

Bionic verification

Reproducing the bug:
  Version table:
 *** 2.4.45+dfsg-1ubuntu1.5 500
500 http://br.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
500 http://br.archive.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
100 /var/lib/dpkg/status


$ sudo sh ./script
...
Closing DB...
slapd running
ldap_bind: Invalid credentials (49)
slapd dead


Updating to proposed:
  Version table:
 *** 2.4.45+dfsg-1ubuntu1.6 500
500 http://br.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 
Packages
100 /var/lib/dpkg/status


Now slapd remains running:
$ sudo sh ./script
...
Closing DB...
slapd running
ldap_bind: Invalid credentials (49)
slapd running


Bionic verification succeeded.

** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

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

Title:
  slapd crash with pwdAccountLockedTime and stacked overlays

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  Fix Committed
Status in openldap source package in Bionic:
  Fix Committed
Status in openldap source package in Disco:
  Won't Fix
Status in openldap source package in Eoan:
  Fix Committed
Status in openldap package in Debian:
  Fix Released

Bug description:
  [Impact]
  In the configuration and conditions described below, slapd can crash:

  1. ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  [Test Case]

  * get the files from the bug:
  mkdir slapd-test-case; cd slapd-test-case
  wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334194/+files/slapd.conf
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334195/+files/data.ldif
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334196/+files/samba.schema
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334197/+files/script

  * run the script:
  sudo apt update && sudo sh ./script

  * With the bug, the result is:
  ldap_bind: Invalid credentials (49)
  slapd dead

  * If when confirming the bug you don't see "slapd dead" like above,
  check manually, as slapd might have been in the process of shutting
  down when the script checked its status: "sudo systemctl status slapd"

  * With the fixed packages, you get a living slapd at the end (you can
  run the script again on the same system after updating the packages):

  sudo sh ./script
  ...
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running

  [Regression Potential]
  The fix is in the password policy overlay (not enabled by default), so any 
regressions would be around that area and could potentially impact 
authentication ("binding") to openldap.

  [Other Info]
  This was fixed in focal and "cooked" there for a long while, as suggested by 
the Debian maintainer. We haven't received further bug reports about this in 
focal+.

  [Original Description]

  Hello,

  Please merge openldap 2.4.49+dfsg-2 from Debian unstable to fix an
  issue in the ppolicy overlay that can crash slapd. Please also
  consider SRUing the patch after it has had some testing time.

  Upstream: https://openldap.org/its/?findid=9171
  Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953150

  The ingredients for the crash are:

  1: ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  The buggy code is not as specific as the above steps, so I suspect
  there are probably other configurations or steps that can trigger the
  same crash.

  I will attach my test script and data for reproducing the crash.

  Expected output (last lines):

  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running

  Actual output (last lines):

  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd dead

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+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 1866303] Re: slapd crash with pwdAccountLockedTime and stacked overlays

[Andreas Hasenack]

Xenial verification (for real)

Reproducing the bug:
  Version table:
 *** 2.4.42+dfsg-2ubuntu3.8 500
500 http://br.archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
500 http://br.archive.ubuntu.com/ubuntu xenial-security/main amd64 
Packages
100 /var/lib/dpkg/status


$ sudo sh ./script
...
Closing DB...
slapd running
ldap_bind: Invalid credentials (49)
slapd dead


With the packages from proposed, slapd remains running:
  Version table:
 *** 2.4.42+dfsg-2ubuntu3.9 500
500 http://br.archive.ubuntu.com/ubuntu xenial-proposed/main amd64 
Packages
100 /var/lib/dpkg/status

$ sudo sh ./script
...
Closing DB...
slapd running
ldap_bind: Invalid credentials (49)
slapd running


Xenial verification succeeded.

** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial

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

Title:
  slapd crash with pwdAccountLockedTime and stacked overlays

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  Fix Committed
Status in openldap source package in Bionic:
  Fix Committed
Status in openldap source package in Disco:
  Won't Fix
Status in openldap source package in Eoan:
  Fix Committed
Status in openldap package in Debian:
  Fix Released

Bug description:
  [Impact]
  In the configuration and conditions described below, slapd can crash:

  1. ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  [Test Case]

  * get the files from the bug:
  mkdir slapd-test-case; cd slapd-test-case
  wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334194/+files/slapd.conf
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334195/+files/data.ldif
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334196/+files/samba.schema
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334197/+files/script

  * run the script:
  sudo apt update && sudo sh ./script

  * With the bug, the result is:
  ldap_bind: Invalid credentials (49)
  slapd dead

  * If when confirming the bug you don't see "slapd dead" like above,
  check manually, as slapd might have been in the process of shutting
  down when the script checked its status: "sudo systemctl status slapd"

  * With the fixed packages, you get a living slapd at the end (you can
  run the script again on the same system after updating the packages):

  sudo sh ./script
  ...
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running

  [Regression Potential]
  The fix is in the password policy overlay (not enabled by default), so any 
regressions would be around that area and could potentially impact 
authentication ("binding") to openldap.

  [Other Info]
  This was fixed in focal and "cooked" there for a long while, as suggested by 
the Debian maintainer. We haven't received further bug reports about this in 
focal+.

  [Original Description]

  Hello,

  Please merge openldap 2.4.49+dfsg-2 from Debian unstable to fix an
  issue in the ppolicy overlay that can crash slapd. Please also
  consider SRUing the patch after it has had some testing time.

  Upstream: https://openldap.org/its/?findid=9171
  Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953150

  The ingredients for the crash are:

  1: ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  The buggy code is not as specific as the above steps, so I suspect
  there are probably other configurations or steps that can trigger the
  same crash.

  I will attach my test script and data for reproducing the crash.

  Expected output (last lines):

  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running

  Actual output (last lines):

  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd dead

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+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 1557157] Re: apparmor profile denied for saslauthd: /run/saslauthd/mux

[Andreas Hasenack]

Focal verification

First, reproducing the problem:

  Version table:
 *** 2.4.49+dfsg-2ubuntu1.2 500
500 http://br.archive.ubuntu.com/ubuntu focal-updates/main amd64 
Packages
500 http://br.archive.ubuntu.com/ubuntu focal-security/main amd64 
Packages
100 /var/lib/dpkg/status

ldapsearch fails:
root@focal-openldap-saslauthd-1557157:~# ldapsearch -H ldapi:/// -LLL -b 
'dc=example,dc=com' -s base -U root -Y PLAIN
SASL/PLAIN authentication started
Please enter your password: 
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
additional info: SASL(-1): generic failure: Password verification failed

and dmesg complains:
[18037.506232] audit: type=1400 audit(1594229527.198:647): apparmor="DENIED" 
operation="connect" 
namespace="root//lxd-focal-openldap-saslauthd-1557157_"
 profile="/usr/sbin/slapd" name="/run/saslauthd/mux" pid=171680 comm="slapd" 
requested_mask="wr" denied_mask="wr" fsuid=1000112 ouid=100


With the proposed packages:
 *** 2.4.49+dfsg-2ubuntu1.3 500
500 http://br.archive.ubuntu.com/ubuntu focal-proposed/main amd64 
Packages
100 /var/lib/dpkg/status


ldapsearch works:
root@focal-openldap-saslauthd-1557157:~# ldapsearch -H ldapi:/// -LLL -b 
'dc=example,dc=com' -s base -U root -Y PLAIN
SASL/PLAIN authentication started
Please enter your password: 
SASL username: root
SASL SSF: 0
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: example
dc: example


And there is no apparmor DENIED message in dmesg.

Focal verification succeeded.

** Tags removed: verification-needed-focal
** Tags added: verification-done-focal

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

Title:
  apparmor profile denied for saslauthd: /run/saslauthd/mux

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Trusty:
  Won't Fix
Status in openldap source package in Xenial:
  Fix Committed
Status in openldap source package in Bionic:
  Fix Committed
Status in openldap source package in Eoan:
  Fix Committed
Status in openldap source package in Focal:
  Fix Committed
Status in openldap source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  When using openldap with sasl authentication, the slapd process will
  communicate with the saslauthd daemon via a socket in
  {,/var}/run/saslauthd/mux. Unfortunately, this will fail in every
  Ubuntu release from trusty onwards, because slapd's apparmor profile
  doesn't contain the necessary directive to allow it to read/write
  from/to the socket specified above.

  The fix is simple: just add the necessary directive to allow slapd to
  read/write from/to the saslauthd socket.

  [Test Case]

  One can reproduce the problem by doing:

  $ lxc launch ubuntu-daily:groovy openldap-bugbug1557157-groovy
  $ lxc shell openldap-bugbug1557157-groovy
  # apt install slapd sasl2-bin ldap-utils apparmor-utils

  (As the domain name, use "example.com").

  # sed -i -e 's/^START=.*/START=yes/' /etc/default/saslauthd
  # cat > /etc/ldap/sasl2/slapd.conf << __EOF__
  mech_list: PLAIN
  pwcheck_method: saslauthd
  __EOF__
  # adduser openldap sasl
  # aa-enforce /etc/apparmor.d/usr.sbin.slapd
  # systemctl restart slapd.service
  # systemctl restart saslauthd.service
  # passwd root

  (You can choose any password here. You will need to type it when
  running the next command.)

  # ldapsearch -H ldapi:/// -LLL -b 'dc=example,dc=com' -s base -U root
  -Y PLAIN

  The command will fail with something like:

  ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
  additional info: SASL(-1): generic failure: Password verification 
failed

  [Regression Potential]

  This is an extremely simple and well contained fix, so I don't
  envision any possible regressions after applying it.  It is important
  noticing that, since the problem affects older Ubuntu releases, the
  openldap package will have to be rebuilt against possible newer
  versions of libraries and other depencencies, which, albeit unlikely,
  may cause issues.

  [Original Description]

  When using slapd with saslauthd the processes communicate via the
  {,/var}/run/saslauthd/mux socket (this is the default location for the
  saslauthd server from the sasl2-bin package in the
  /etc/default/saslauthd config), but the apparmor profile for
  usr.sbin.slapd does not allow access to this socket/file.

  Syslog message:
  apparmor="DENIED" operation="connect" profile="/usr/sbin/slapd" 
name="/run/saslauthd/mux" pid=1880
  4 comm="slapd" requested_mask="r" denied_mask="r" fsuid=108 ouid=0

  Please add the following line to  /etc/apparmor.d/usr.sbin.slapd:
  /{,var/}run/saslauthd/mux rw,

  Ubuntu version: Ubuntu 14.04.4 LTS
  slapd version: 2.4.31-1+nmu2ubu

To manage notifications about this bug go to:

[Touch-packages] [Bug 1557157] Re: apparmor profile denied for saslauthd: /run/saslauthd/mux

[Andreas Hasenack]

Xenial verification

Reproducing the error:
root@xenial-openldap-saslauthd-1557157:~# ldapsearch -H ldapi:/// -LLL -b 
'dc=example,dc=com' -s base -U root -Y PLAIN
SASL/PLAIN authentication started
Please enter your password:
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
 additional info: SASL(-1): generic failure: Password verification failed

And dmesg:
[qua jul 8 11:50:42 2020] audit: type=1400 audit(1594219843.513:405): 
apparmor="DENIED" operation="connect" 
namespace="root//lxd-xenial-openldap-saslauthd-1557157_"
 profile="/usr/sbin/slapd" name="/run/saslauthd/mux" pid=83468 comm="slapd" 
requested_mask="wr" denied_mask="wr" fsuid=1000112 ouid=100

With the updated packages, ldapsearch works:
root@xenial-openldap-saslauthd-1557157:~# apt-cache policy slapd
slapd:
  Installed: 2.4.42+dfsg-2ubuntu3.9
  Candidate: 2.4.42+dfsg-2ubuntu3.9
  Version table:
 *** 2.4.42+dfsg-2ubuntu3.9 500
500 http://br.archive.ubuntu.com/ubuntu xenial-proposed/main amd64 
Packages
100 /var/lib/dpkg/status
...

root@xenial-openldap-saslauthd-1557157:~# ldapsearch -H ldapi:/// -LLL -b 
'dc=example,dc=com' -s base -U root -Y PLAIN
SASL/PLAIN authentication started
Please enter your password:
SASL username: root
SASL SSF: 0
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: example
dc: example

And no dmesg apparmor error.

Xenial verification succeeded.


** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial

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

Title:
  apparmor profile denied for saslauthd: /run/saslauthd/mux

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Trusty:
  Won't Fix
Status in openldap source package in Xenial:
  Fix Committed
Status in openldap source package in Bionic:
  Fix Committed
Status in openldap source package in Eoan:
  Fix Committed
Status in openldap source package in Focal:
  Fix Committed
Status in openldap source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  When using openldap with sasl authentication, the slapd process will
  communicate with the saslauthd daemon via a socket in
  {,/var}/run/saslauthd/mux. Unfortunately, this will fail in every
  Ubuntu release from trusty onwards, because slapd's apparmor profile
  doesn't contain the necessary directive to allow it to read/write
  from/to the socket specified above.

  The fix is simple: just add the necessary directive to allow slapd to
  read/write from/to the saslauthd socket.

  [Test Case]

  One can reproduce the problem by doing:

  $ lxc launch ubuntu-daily:groovy openldap-bugbug1557157-groovy
  $ lxc shell openldap-bugbug1557157-groovy
  # apt install slapd sasl2-bin ldap-utils apparmor-utils

  (As the domain name, use "example.com").

  # sed -i -e 's/^START=.*/START=yes/' /etc/default/saslauthd
  # cat > /etc/ldap/sasl2/slapd.conf << __EOF__
  mech_list: PLAIN
  pwcheck_method: saslauthd
  __EOF__
  # adduser openldap sasl
  # aa-enforce /etc/apparmor.d/usr.sbin.slapd
  # systemctl restart slapd.service
  # systemctl restart saslauthd.service
  # passwd root

  (You can choose any password here. You will need to type it when
  running the next command.)

  # ldapsearch -H ldapi:/// -LLL -b 'dc=example,dc=com' -s base -U root
  -Y PLAIN

  The command will fail with something like:

  ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
  additional info: SASL(-1): generic failure: Password verification 
failed

  [Regression Potential]

  This is an extremely simple and well contained fix, so I don't
  envision any possible regressions after applying it.  It is important
  noticing that, since the problem affects older Ubuntu releases, the
  openldap package will have to be rebuilt against possible newer
  versions of libraries and other depencencies, which, albeit unlikely,
  may cause issues.

  [Original Description]

  When using slapd with saslauthd the processes communicate via the
  {,/var}/run/saslauthd/mux socket (this is the default location for the
  saslauthd server from the sasl2-bin package in the
  /etc/default/saslauthd config), but the apparmor profile for
  usr.sbin.slapd does not allow access to this socket/file.

  Syslog message:
  apparmor="DENIED" operation="connect" profile="/usr/sbin/slapd" 
name="/run/saslauthd/mux" pid=1880
  4 comm="slapd" requested_mask="r" denied_mask="r" fsuid=108 ouid=0

  Please add the following line to  /etc/apparmor.d/usr.sbin.slapd:
  /{,var/}run/saslauthd/mux rw,

  Ubuntu version: Ubuntu 14.04.4 LTS
  slapd version: 2.4.31-1+nmu2ubu

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to   

[Touch-packages] [Bug 1557157] Re: apparmor profile denied for saslauthd: /run/saslauthd/mux

[Andreas Hasenack]

Eoan verification

First, reproducing the bug:

  Version table:
 *** 2.4.48+dfsg-1ubuntu1.1 500
500 http://br.archive.ubuntu.com/ubuntu eoan-updates/main amd64 Packages
500 http://br.archive.ubuntu.com/ubuntu eoan-security/main amd64 
Packages
100 /var/lib/dpkg/status


ldapsearch fails:
root@eoan-openldap-saslauthd-1557157:~# ldapsearch -H ldapi:/// -LLL -b 
'dc=example,dc=com' -s base -U root -Y PLAIN
SASL/PLAIN authentication started
Please enter your password: 
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
additional info: SASL(-1): generic failure: Password verification failed


And dmesg shows the apparmor DENIED message:
[17713.076558] audit: type=1400 audit(1594229202.756:559): apparmor="DENIED" 
operation="connect" 
namespace="root//lxd-eoan-openldap-saslauthd-1557157_" 
profile="/usr/sbin/slapd" name="/run/saslauthd/mux" pid=162867 comm="slapd" 
requested_mask="wr" denied_mask="wr" fsuid=1000111 ouid=100


With the package from proposed:
  Version table:
 *** 2.4.48+dfsg-1ubuntu1.2 500
500 http://br.archive.ubuntu.com/ubuntu eoan-proposed/main amd64 
Packages
100 /var/lib/dpkg/status

ldapsearch works:
root@eoan-openldap-saslauthd-1557157:~# ldapsearch -H ldapi:/// -LLL -b 
'dc=example,dc=com' -s base -U root -Y PLAIN
SASL/PLAIN authentication started
Please enter your password: 
SASL username: root
SASL SSF: 0
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: example
dc: example


And there is no DENIED message in dmesg.

eoan verification succeeded.

** Tags removed: verification-needed-eoan
** Tags added: verification-done-eoan

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

Title:
  apparmor profile denied for saslauthd: /run/saslauthd/mux

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Trusty:
  Won't Fix
Status in openldap source package in Xenial:
  Fix Committed
Status in openldap source package in Bionic:
  Fix Committed
Status in openldap source package in Eoan:
  Fix Committed
Status in openldap source package in Focal:
  Fix Committed
Status in openldap source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  When using openldap with sasl authentication, the slapd process will
  communicate with the saslauthd daemon via a socket in
  {,/var}/run/saslauthd/mux. Unfortunately, this will fail in every
  Ubuntu release from trusty onwards, because slapd's apparmor profile
  doesn't contain the necessary directive to allow it to read/write
  from/to the socket specified above.

  The fix is simple: just add the necessary directive to allow slapd to
  read/write from/to the saslauthd socket.

  [Test Case]

  One can reproduce the problem by doing:

  $ lxc launch ubuntu-daily:groovy openldap-bugbug1557157-groovy
  $ lxc shell openldap-bugbug1557157-groovy
  # apt install slapd sasl2-bin ldap-utils apparmor-utils

  (As the domain name, use "example.com").

  # sed -i -e 's/^START=.*/START=yes/' /etc/default/saslauthd
  # cat > /etc/ldap/sasl2/slapd.conf << __EOF__
  mech_list: PLAIN
  pwcheck_method: saslauthd
  __EOF__
  # adduser openldap sasl
  # aa-enforce /etc/apparmor.d/usr.sbin.slapd
  # systemctl restart slapd.service
  # systemctl restart saslauthd.service
  # passwd root

  (You can choose any password here. You will need to type it when
  running the next command.)

  # ldapsearch -H ldapi:/// -LLL -b 'dc=example,dc=com' -s base -U root
  -Y PLAIN

  The command will fail with something like:

  ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
  additional info: SASL(-1): generic failure: Password verification 
failed

  [Regression Potential]

  This is an extremely simple and well contained fix, so I don't
  envision any possible regressions after applying it.  It is important
  noticing that, since the problem affects older Ubuntu releases, the
  openldap package will have to be rebuilt against possible newer
  versions of libraries and other depencencies, which, albeit unlikely,
  may cause issues.

  [Original Description]

  When using slapd with saslauthd the processes communicate via the
  {,/var}/run/saslauthd/mux socket (this is the default location for the
  saslauthd server from the sasl2-bin package in the
  /etc/default/saslauthd config), but the apparmor profile for
  usr.sbin.slapd does not allow access to this socket/file.

  Syslog message:
  apparmor="DENIED" operation="connect" profile="/usr/sbin/slapd" 
name="/run/saslauthd/mux" pid=1880
  4 comm="slapd" requested_mask="r" denied_mask="r" fsuid=108 ouid=0

  Please add the following line to  /etc/apparmor.d/usr.sbin.slapd:
  /{,var/}run/saslauthd/mux rw,

  Ubuntu version: Ubuntu 14.04.4 LTS
  slapd version: 2.4.31-1+nmu2ubu

To manage notifications about 

[Touch-packages] [Bug 1866303] Re: slapd crash with pwdAccountLockedTime and stacked overlays

[Andreas Hasenack]

I'm sorry, the above verification was for the other bug that this upload
is fixing.

** Tags removed: verification-done-xenial
** Tags added: verification-needed-xenial

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

Title:
  slapd crash with pwdAccountLockedTime and stacked overlays

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  Fix Committed
Status in openldap source package in Bionic:
  Fix Committed
Status in openldap source package in Disco:
  Won't Fix
Status in openldap source package in Eoan:
  Fix Committed
Status in openldap package in Debian:
  Fix Released

Bug description:
  [Impact]
  In the configuration and conditions described below, slapd can crash:

  1. ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  [Test Case]

  * get the files from the bug:
  mkdir slapd-test-case; cd slapd-test-case
  wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334194/+files/slapd.conf
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334195/+files/data.ldif
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334196/+files/samba.schema
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334197/+files/script

  * run the script:
  sudo apt update && sudo sh ./script

  * With the bug, the result is:
  ldap_bind: Invalid credentials (49)
  slapd dead

  * If when confirming the bug you don't see "slapd dead" like above,
  check manually, as slapd might have been in the process of shutting
  down when the script checked its status: "sudo systemctl status slapd"

  * With the fixed packages, you get a living slapd at the end (you can
  run the script again on the same system after updating the packages):

  sudo sh ./script
  ...
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running

  [Regression Potential]
  The fix is in the password policy overlay (not enabled by default), so any 
regressions would be around that area and could potentially impact 
authentication ("binding") to openldap.

  [Other Info]
  This was fixed in focal and "cooked" there for a long while, as suggested by 
the Debian maintainer. We haven't received further bug reports about this in 
focal+.

  [Original Description]

  Hello,

  Please merge openldap 2.4.49+dfsg-2 from Debian unstable to fix an
  issue in the ppolicy overlay that can crash slapd. Please also
  consider SRUing the patch after it has had some testing time.

  Upstream: https://openldap.org/its/?findid=9171
  Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953150

  The ingredients for the crash are:

  1: ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  The buggy code is not as specific as the above steps, so I suspect
  there are probably other configurations or steps that can trigger the
  same crash.

  I will attach my test script and data for reproducing the crash.

  Expected output (last lines):

  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running

  Actual output (last lines):

  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd dead

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+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 1557157] Re: apparmor profile denied for saslauthd: /run/saslauthd/mux

[Andreas Hasenack]

bionic verification

First reproducing the problem:
  Version table:
 *** 2.4.45+dfsg-1ubuntu1.5 500
500 http://br.archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
500 http://br.archive.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
100 /var/lib/dpkg/status

Command fails:
root@bionic-openldap-saslauthd-1557157:~# ldapsearch -H ldapi:/// -LLL -b 
'dc=example,dc=com' -s base -U root -Y PLAIN
SASL/PLAIN authentication started
Please enter your password: 
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
additional info: SASL(-1): generic failure: Password verification failed

And dmesg shows the apparmor denial:
[17283.881912] audit: type=1400 audit(1594228773.536:453): apparmor="DENIED" 
operation="connect" 
namespace="root//lxd-bionic-openldap-saslauthd-1557157_"
 profile="/usr/sbin/slapd" name="/run/saslauthd/mux" pid=153401 comm="slapd" 
requested_mask="wr" denied_mask="wr" fsuid=1000111 ouid=100


With the updated package from proposed:
  Version table:
 *** 2.4.45+dfsg-1ubuntu1.6 500
500 http://br.archive.ubuntu.com/ubuntu bionic-proposed/main amd64 
Packages
100 /var/lib/dpkg/status

The ldapsearch command works, and there is no apparmor error in dmesg:
root@bionic-openldap-saslauthd-1557157:~# ldapsearch -H ldapi:/// -LLL -b 
'dc=example,dc=com' -s base -U root -Y PLAIN
SASL/PLAIN authentication started
Please enter your password: 
SASL username: root
SASL SSF: 0
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: example
dc: example


Bionic verification succeeded.

** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

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

Title:
  apparmor profile denied for saslauthd: /run/saslauthd/mux

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Trusty:
  Won't Fix
Status in openldap source package in Xenial:
  Fix Committed
Status in openldap source package in Bionic:
  Fix Committed
Status in openldap source package in Eoan:
  Fix Committed
Status in openldap source package in Focal:
  Fix Committed
Status in openldap source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  When using openldap with sasl authentication, the slapd process will
  communicate with the saslauthd daemon via a socket in
  {,/var}/run/saslauthd/mux. Unfortunately, this will fail in every
  Ubuntu release from trusty onwards, because slapd's apparmor profile
  doesn't contain the necessary directive to allow it to read/write
  from/to the socket specified above.

  The fix is simple: just add the necessary directive to allow slapd to
  read/write from/to the saslauthd socket.

  [Test Case]

  One can reproduce the problem by doing:

  $ lxc launch ubuntu-daily:groovy openldap-bugbug1557157-groovy
  $ lxc shell openldap-bugbug1557157-groovy
  # apt install slapd sasl2-bin ldap-utils apparmor-utils

  (As the domain name, use "example.com").

  # sed -i -e 's/^START=.*/START=yes/' /etc/default/saslauthd
  # cat > /etc/ldap/sasl2/slapd.conf << __EOF__
  mech_list: PLAIN
  pwcheck_method: saslauthd
  __EOF__
  # adduser openldap sasl
  # aa-enforce /etc/apparmor.d/usr.sbin.slapd
  # systemctl restart slapd.service
  # systemctl restart saslauthd.service
  # passwd root

  (You can choose any password here. You will need to type it when
  running the next command.)

  # ldapsearch -H ldapi:/// -LLL -b 'dc=example,dc=com' -s base -U root
  -Y PLAIN

  The command will fail with something like:

  ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
  additional info: SASL(-1): generic failure: Password verification 
failed

  [Regression Potential]

  This is an extremely simple and well contained fix, so I don't
  envision any possible regressions after applying it.  It is important
  noticing that, since the problem affects older Ubuntu releases, the
  openldap package will have to be rebuilt against possible newer
  versions of libraries and other depencencies, which, albeit unlikely,
  may cause issues.

  [Original Description]

  When using slapd with saslauthd the processes communicate via the
  {,/var}/run/saslauthd/mux socket (this is the default location for the
  saslauthd server from the sasl2-bin package in the
  /etc/default/saslauthd config), but the apparmor profile for
  usr.sbin.slapd does not allow access to this socket/file.

  Syslog message:
  apparmor="DENIED" operation="connect" profile="/usr/sbin/slapd" 
name="/run/saslauthd/mux" pid=1880
  4 comm="slapd" requested_mask="r" denied_mask="r" fsuid=108 ouid=0

  Please add the following line to  /etc/apparmor.d/usr.sbin.slapd:
  /{,var/}run/saslauthd/mux rw,

  Ubuntu version: Ubuntu 14.04.4 LTS
  slapd version: 2.4.31-1+nmu2ubu

To 

[Touch-packages] [Bug 1866303] Re: slapd crash with pwdAccountLockedTime and stacked overlays

[Andreas Hasenack]

Xenial verification

Reproducing the error:
root@xenial-openldap-saslauthd-1557157:~# ldapsearch -H ldapi:/// -LLL -b 
'dc=example,dc=com' -s base -U root -Y PLAIN
SASL/PLAIN authentication started
Please enter your password: 
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
additional info: SASL(-1): generic failure: Password verification failed

And dmesg:
[qua jul  8 11:50:42 2020] audit: type=1400 audit(1594219843.513:405): 
apparmor="DENIED" operation="connect" 
namespace="root//lxd-xenial-openldap-saslauthd-1557157_"
 profile="/usr/sbin/slapd" name="/run/saslauthd/mux" pid=83468 comm="slapd" 
requested_mask="wr" denied_mask="wr" fsuid=1000112 ouid=100


With the updated packages, ldapsearch works:
root@xenial-openldap-saslauthd-1557157:~# apt-cache policy slapd
slapd:
  Installed: 2.4.42+dfsg-2ubuntu3.9
  Candidate: 2.4.42+dfsg-2ubuntu3.9
  Version table:
 *** 2.4.42+dfsg-2ubuntu3.9 500
500 http://br.archive.ubuntu.com/ubuntu xenial-proposed/main amd64 
Packages
100 /var/lib/dpkg/status
...

root@xenial-openldap-saslauthd-1557157:~# ldapsearch -H ldapi:/// -LLL -b 
'dc=example,dc=com' -s base -U root -Y PLAIN
SASL/PLAIN authentication started
Please enter your password: 
SASL username: root
SASL SSF: 0
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: example
dc: example


And no dmesg apparmor error.

Xenial verification succeeded.

** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial

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

Title:
  slapd crash with pwdAccountLockedTime and stacked overlays

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  Fix Committed
Status in openldap source package in Bionic:
  Fix Committed
Status in openldap source package in Disco:
  Won't Fix
Status in openldap source package in Eoan:
  Fix Committed
Status in openldap package in Debian:
  Fix Released

Bug description:
  [Impact]
  In the configuration and conditions described below, slapd can crash:

  1. ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  [Test Case]

  * get the files from the bug:
  mkdir slapd-test-case; cd slapd-test-case
  wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334194/+files/slapd.conf
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334195/+files/data.ldif
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334196/+files/samba.schema
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334197/+files/script

  * run the script:
  sudo apt update && sudo sh ./script

  * With the bug, the result is:
  ldap_bind: Invalid credentials (49)
  slapd dead

  * If when confirming the bug you don't see "slapd dead" like above,
  check manually, as slapd might have been in the process of shutting
  down when the script checked its status: "sudo systemctl status slapd"

  * With the fixed packages, you get a living slapd at the end (you can
  run the script again on the same system after updating the packages):

  sudo sh ./script
  ...
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running

  [Regression Potential]
  The fix is in the password policy overlay (not enabled by default), so any 
regressions would be around that area and could potentially impact 
authentication ("binding") to openldap.

  [Other Info]
  This was fixed in focal and "cooked" there for a long while, as suggested by 
the Debian maintainer. We haven't received further bug reports about this in 
focal+.

  [Original Description]

  Hello,

  Please merge openldap 2.4.49+dfsg-2 from Debian unstable to fix an
  issue in the ppolicy overlay that can crash slapd. Please also
  consider SRUing the patch after it has had some testing time.

  Upstream: https://openldap.org/its/?findid=9171
  Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953150

  The ingredients for the crash are:

  1: ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  The buggy code is not as specific as the above steps, so I suspect
  there are probably other configurations or steps that can trigger the
  same crash.

  I will attach my test script and data for reproducing the crash.

  Expected output (last lines):

  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running

  Actual output 

[Touch-packages] [Bug 1886572] Re: Remove uptime from the motd-news user agent

[Andreas Hasenack]

There is this comment next to the uptime grabbing:
# Some messages may only be pertinent before or after some amount of uptime
read up idle < /proc/uptime
uptime="uptime/$up/$idle"

As far as I know, this was never used, as the server serves static
content.

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

Title:
  Remove uptime from the motd-news user agent

Status in base-files package in Ubuntu:
  In Progress

Bug description:
  I don't why that was included but it shouldn't be. Please remove it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1886572/+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 1886572] Re: Remove uptime from the motd-news user agent

[Andreas Hasenack]

** Changed in: base-files (Ubuntu)
   Status: New => In Progress

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

Title:
  Remove uptime from the motd-news user agent

Status in base-files package in Ubuntu:
  In Progress

Bug description:
  I don't why that was included but it shouldn't be. Please remove it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1886572/+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 1557157] Re: apparmor profile denied for saslauthd: /run/saslauthd/mux

[Andreas Hasenack]

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

** Changed in: openldap (Ubuntu Eoan)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

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

Title:
  apparmor profile denied for saslauthd: /run/saslauthd/mux

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Trusty:
  Won't Fix
Status in openldap source package in Xenial:
  Confirmed
Status in openldap source package in Bionic:
  Confirmed
Status in openldap source package in Eoan:
  Confirmed
Status in openldap source package in Focal:
  Confirmed
Status in openldap source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  When using openldap with sasl authentication, the slapd process will
  communicate with the saslauthd daemon via a socket in
  {,/var}/run/saslauthd/mux. Unfortunately, this will fail in every
  Ubuntu release from trusty onwards, because slapd's apparmor profile
  doesn't contain the necessary directive to allow it to read/write
  from/to the socket specified above.

  The fix is simple: just add the necessary directive to allow slapd to
  read/write from/to the saslauthd socket.

  [Test Case]

  One can reproduce the problem by doing:

  $ lxc launch ubuntu-daily:groovy openldap-bugbug1557157-groovy
  $ lxc shell openldap-bugbug1557157-groovy
  # apt install slapd sasl2-bin ldap-utils apparmor-utils

  (As the domain name, use "example.com").

  # sed -i -e 's/^START=.*/START=yes/' /etc/default/saslauthd
  # cat > /etc/ldap/sasl2/slapd.conf << __EOF__
  mech_list: PLAIN
  pwcheck_method: saslauthd
  __EOF__
  # adduser openldap sasl
  # aa-enforce /etc/apparmor.d/usr.sbin.slapd
  # systemctl restart slapd.service
  # systemctl restart saslauthd.service
  # passwd root

  (You can choose any password here. You will need to type it when
  running the next command.)

  # ldapsearch -H ldapi:/// -LLL -b 'dc=example,dc=com' -s base -U root
  -Y PLAIN

  The command will fail with something like:

  ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80)
  additional info: SASL(-1): generic failure: Password verification 
failed

  [Regression Potential]

  This is an extremely simple and well contained fix, so I don't
  envision any possible regressions after applying it.  It is important
  noticing that, since the problem affects older Ubuntu releases, the
  openldap package will have to be rebuilt against possible newer
  versions of libraries and other depencencies, which, albeit unlikely,
  may cause issues.

  [Original Description]

  When using slapd with saslauthd the processes communicate via the
  {,/var}/run/saslauthd/mux socket (this is the default location for the
  saslauthd server from the sasl2-bin package in the
  /etc/default/saslauthd config), but the apparmor profile for
  usr.sbin.slapd does not allow access to this socket/file.

  Syslog message:
  apparmor="DENIED" operation="connect" profile="/usr/sbin/slapd" 
name="/run/saslauthd/mux" pid=1880
  4 comm="slapd" requested_mask="r" denied_mask="r" fsuid=108 ouid=0

  Please add the following line to  /etc/apparmor.d/usr.sbin.slapd:
  /{,var/}run/saslauthd/mux rw,

  Ubuntu version: Ubuntu 14.04.4 LTS
  slapd version: 2.4.31-1+nmu2ubu

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557157/+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 1866303] Re: slapd crash with pwdAccountLockedTime and stacked overlays

[Andreas Hasenack]

** Description changed:

- [Impact] 
+ [Impact]
  In the configuration and conditions described below, slapd can crash:
  
  1. ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control
- 
  
  [Test Case]
  
  * get the files from the bug:
  mkdir slapd-test-case; cd slapd-test-case
  wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334194/+files/slapd.conf
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334195/+files/data.ldif
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334196/+files/samba.schema
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334197/+files/script
  
  * run the script:
  sudo apt update && sudo sh ./script
  
  * With the bug, the result is:
  ldap_bind: Invalid credentials (49)
  slapd dead
  
  * If when confirming the bug you don't see "slapd dead" like above,
  check manually, as slapd might have been in the process of shutting down
  when the script checked its status: "sudo systemctl status slapd"
  
- * With the fixed packages, you get a living slapd at the end (you can run the 
script again on the same system):
- sudo add-apt-repository ppa:ahasenack/slapd-crash-bug-1866303 -y -u
+ * With the fixed packages, you get a living slapd at the end (you can
+ run the script again on the same system after updating the packages):
+ 
  sudo sh ./script
  ...
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running
  
- [Regression Potential] 
+ [Regression Potential]
  The fix is in the password policy overlay (not enabled by default), so any 
regressions would be around that area and could potentially impact 
authentication ("binding") to openldap.
  
  [Other Info]
  This was fixed in focal and "cooked" there for a long while, as suggested by 
the Debian maintainer. We haven't received further bug reports about this in 
focal+.
- 
  
  [Original Description]
  
  Hello,
  
  Please merge openldap 2.4.49+dfsg-2 from Debian unstable to fix an issue
  in the ppolicy overlay that can crash slapd. Please also consider SRUing
  the patch after it has had some testing time.
  
  Upstream: https://openldap.org/its/?findid=9171
  Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953150
  
  The ingredients for the crash are:
  
  1: ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control
  
  The buggy code is not as specific as the above steps, so I suspect there
  are probably other configurations or steps that can trigger the same
  crash.
  
  I will attach my test script and data for reproducing the crash.
  
  Expected output (last lines):
  
  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running
  
  Actual output (last lines):
  
  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd dead

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

Title:
  slapd crash with pwdAccountLockedTime and stacked overlays

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  In Progress
Status in openldap source package in Bionic:
  In Progress
Status in openldap source package in Disco:
  Won't Fix
Status in openldap source package in Eoan:
  In Progress
Status in openldap package in Debian:
  Fix Released

Bug description:
  [Impact]
  In the configuration and conditions described below, slapd can crash:

  1. ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  [Test Case]

  * get the files from the bug:
  mkdir slapd-test-case; cd slapd-test-case
  wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334194/+files/slapd.conf
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334195/+files/data.ldif
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334196/+files/samba.schema
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334197/+files/script

  * run the script:
  sudo apt update && sudo sh ./script

  * With the bug, the result is:
  ldap_bind: Invalid credentials (49)
  slapd dead

  * If when confirming the bug you don't see "slapd dead" like above,
  check manually, as slapd might have been in the process of shutting
  down 

[Touch-packages] [Bug 1866303] Re: slapd crash with pwdAccountLockedTime and stacked overlays

[Andreas Hasenack]

** Description changed:

+ [Impact] 
+ In the configuration and conditions described below, slapd can crash:
+ 
+ 1. ppolicy overlay configured with pwdLockout: TRUE
+ 2. smbk5pwd overlay stacked after ppolicy
+ 3. an account locked out via pwdAccountLockedTime
+ 4. a client binding to the locked-out account and also requesting the ppolicy 
control
+ 
+ 
+ [Test Case]
+ 
+ * get the files from the bug:
+ mkdir slapd-test-case; cd slapd-test-case
+ wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334194/+files/slapd.conf
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334195/+files/data.ldif
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334196/+files/samba.schema
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334197/+files/script
+ 
+ * run the script:
+ sudo apt update && sudo sh ./script
+ 
+ * With the bug, the result is:
+ ldap_bind: Invalid credentials (49)
+ slapd dead
+ 
+ * If when confirming the bug you don't see "slapd dead" like above,
+ check manually, as slapd might have been in the process of shutting down
+ when the script checked its status: "sudo systemctl status slapd"
+ 
+ * With the fixed packages, you get a living slapd at the end (you can run the 
script again on the same system):
+ sudo add-apt-repository ppa:ahasenack/slapd-crash-bug-1866303 -y -u
+ sudo sh ./script
+ ...
+ slapd running
+ ldap_bind: Invalid credentials (49)
+ slapd running
+ 
+ [Regression Potential] 
+ The fix is in the password policy overlay (not enabled by default), so any 
regressions would be around that area and could potentially impact 
authentication ("binding") to openldap.
+ 
+ [Other Info]
+ This was fixed in focal and "cooked" there for a long while, as suggested by 
the Debian maintainer. We haven't received further bug reports about this in 
focal+.
+ 
+ 
+ [Original Description]
+ 
  Hello,
  
  Please merge openldap 2.4.49+dfsg-2 from Debian unstable to fix an issue
  in the ppolicy overlay that can crash slapd. Please also consider SRUing
  the patch after it has had some testing time.
  
  Upstream: https://openldap.org/its/?findid=9171
  Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953150
  
  The ingredients for the crash are:
  
  1: ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control
  
  The buggy code is not as specific as the above steps, so I suspect there
  are probably other configurations or steps that can trigger the same
  crash.
  
  I will attach my test script and data for reproducing the crash.
  
  Expected output (last lines):
  
  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running
  
  Actual output (last lines):
  
  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd dead

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

Title:
  slapd crash with pwdAccountLockedTime and stacked overlays

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  In Progress
Status in openldap source package in Bionic:
  In Progress
Status in openldap source package in Disco:
  Won't Fix
Status in openldap source package in Eoan:
  In Progress
Status in openldap package in Debian:
  Fix Released

Bug description:
  [Impact] 
  In the configuration and conditions described below, slapd can crash:

  1. ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  
  [Test Case]

  * get the files from the bug:
  mkdir slapd-test-case; cd slapd-test-case
  wget -ct0 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334194/+files/slapd.conf
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334195/+files/data.ldif
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334196/+files/samba.schema
 
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+attachment/5334197/+files/script

  * run the script:
  sudo apt update && sudo sh ./script

  * With the bug, the result is:
  ldap_bind: Invalid credentials (49)
  slapd dead

  * If when confirming the bug you don't see "slapd dead" like above,
  check manually, as slapd might have been in the process of shutting
  down when the script checked its status: "sudo systemctl status slapd"

  * With the fixed packages, you get a living slapd at the end (you can run the 
script again on the same system):
 

[Touch-packages] [Bug 1866303] Re: slapd crash with pwdAccountLockedTime and stacked overlays

[Andreas Hasenack]

This fix was added to focal, and we haven't received any crash reports
about it as far as I know, so I'm proceeding with the SRU for the other
ubuntu releases.

** Changed in: openldap (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: openldap (Ubuntu Xenial)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

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

** Changed in: openldap (Ubuntu Bionic)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: openldap (Ubuntu Eoan)
   Status: New => In Progress

** Changed in: openldap (Ubuntu Eoan)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

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

Title:
  slapd crash with pwdAccountLockedTime and stacked overlays

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  In Progress
Status in openldap source package in Bionic:
  In Progress
Status in openldap source package in Disco:
  Won't Fix
Status in openldap source package in Eoan:
  In Progress
Status in openldap package in Debian:
  Fix Released

Bug description:
  Hello,

  Please merge openldap 2.4.49+dfsg-2 from Debian unstable to fix an
  issue in the ppolicy overlay that can crash slapd. Please also
  consider SRUing the patch after it has had some testing time.

  Upstream: https://openldap.org/its/?findid=9171
  Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953150

  The ingredients for the crash are:

  1: ppolicy overlay configured with pwdLockout: TRUE
  2. smbk5pwd overlay stacked after ppolicy
  3. an account locked out via pwdAccountLockedTime
  4. a client binding to the locked-out account and also requesting the ppolicy 
control

  The buggy code is not as specific as the above steps, so I suspect
  there are probably other configurations or steps that can trigger the
  same crash.

  I will attach my test script and data for reproducing the crash.

  Expected output (last lines):

  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd running

  Actual output (last lines):

  [ ok ] Starting OpenLDAP: slapd.
  slapd running
  ldap_bind: Invalid credentials (49)
  slapd dead

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+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 1884366] Re: package libkrb5-3 1.16-2build1 failed to install/upgrade: unable to make backup link of './usr/lib/i386-linux-gnu/libkrb5.so.3.3' before installing new version: Inpu

[Andreas Hasenack]

Your dmesg is full of errors like these:
[   19.583604] SQUASHFS error: zlib decompression failed, data probably corrupt
[   19.583608] SQUASHFS error: squashfs_read_data failed to read block 
0x8116e5ed
[   19.583610] SQUASHFS error: Unable to read fragment cache entry [8116e5ed]

Are you running from a cdrom/flash drive?
 /cow 8250080 1226092   7023988  15% /

In any case, this is filesystem corruption, or bad disk/cdrom, and not a
bug in the krb5 package.

** Changed in: krb5 (Ubuntu)
   Status: New => Invalid

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

Title:
  package libkrb5-3 1.16-2build1 failed to install/upgrade: unable to
  make backup link of './usr/lib/i386-linux-gnu/libkrb5.so.3.3' before
  installing new version: Input/output error

Status in krb5 package in Ubuntu:
  Invalid

Bug description:
  Unable to update or upgrade libkrb5-3:i386 at 18.04 i386

  $ sudo apt install libkrb5-3:i386
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  The following additional packages will be installed:
libgssapi-krb5-2 libkrb5support0
  Suggested packages:
krb5-doc krb5-user
  The following packages will be upgraded:
libgssapi-krb5-2 libkrb5-3 libkrb5support0
  3 upgraded, 0 newly installed, 0 to remove and 723 not upgraded.
  Need to get 467 kB of archives.
  After this operation, 0 B of additional disk space will be used.
  Do you want to continue? [Y/n] 
  Get:1 http://security.ubuntu.com/ubuntu bionic-security/main i386 
libkrb5support0 i386 1.16-2ubuntu0.1 [32.5 kB]
  Get:2 http://security.ubuntu.com/ubuntu bionic-security/main i386 
libgssapi-krb5-2 i386 1.16-2ubuntu0.1 [132 kB]
  Get:3 http://security.ubuntu.com/ubuntu bionic-security/main i386 libkrb5-3 
i386 1.16-2ubuntu0.1 [303 kB]
  Fetched 467 kB in 2s (300 kB/s)
  (Reading database ... 250947 files and directories currently installed.)
  Preparing to unpack .../libkrb5support0_1.16-2ubuntu0.1_i386.deb ...
  Unpacking libkrb5support0:i386 (1.16-2ubuntu0.1) over (1.16-2build1) ...
  Preparing to unpack .../libgssapi-krb5-2_1.16-2ubuntu0.1_i386.deb ...
  Unpacking libgssapi-krb5-2:i386 (1.16-2ubuntu0.1) over (1.16-2build1) ...
  Preparing to unpack .../libkrb5-3_1.16-2ubuntu0.1_i386.deb ...
  Unpacking libkrb5-3:i386 (1.16-2ubuntu0.1) over (1.16-2build1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libkrb5-3_1.16-2ubuntu0.1_i386.deb (--unpack):
   unable to make backup link of './usr/lib/i386-linux-gnu/libkrb5.so.3.3' 
before installing new version: Input/output error
  Errors were encountered while processing:
   /var/cache/apt/archives/libkrb5-3_1.16-2ubuntu0.1_i386.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)

  ProblemType: Package
  DistroRelease: Ubuntu 18.04
  Package: libkrb5-3 1.16-2build1
  ProcVersionSignature: Ubuntu 4.15.0-20.21-lowlatency 4.15.17
  Uname: Linux 4.15.0-20-lowlatency i686
  ApportVersion: 2.20.9-0ubuntu7
  AptOrdering:
   libkrb5support0:i386: Install
   libgssapi-krb5-2:i386: Install
   libkrb5-3:i386: Install
   NULL: ConfigurePending
  Architecture: i386
  CasperVersion: 1.394
  Date: Sat Jun 20 13:02:48 2020
  ErrorMessage: unable to make backup link of 
'./usr/lib/i386-linux-gnu/libkrb5.so.3.3' before installing new version: 
Input/output error
  LiveMediaBuild: Ubuntu-Studio 18.04 LTS "Bionic Beaver" - Release i386 
(20180426)
  Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal, 3.6.5-3
  PythonDetails: /usr/bin/python2.7, Python 2.7.15rc1, python-minimal, 
2.7.15~rc1-1
  RelatedPackageVersions:
   dpkg 1.19.0.5ubuntu2
   apt  1.6.1
  SourcePackage: krb5
  Title: package libkrb5-3 1.16-2build1 failed to install/upgrade: unable to 
make backup link of './usr/lib/i386-linux-gnu/libkrb5.so.3.3' before installing 
new version: Input/output error
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1884366/+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 1880209] Re: slapd configuration does not ask for olcbackend and doesn't add one. Has to be added by hand.

[Andreas Hasenack]

Just fixed, it might take a few minutes or hours to update on the site.

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

Title:
  slapd configuration does not ask for olcbackend and doesn't add one.
  Has to be added by hand.

Status in Ubuntu Server Guide:
  Fix Released
Status in openldap package in Ubuntu:
  New

Bug description:
  Installing slapd and ldap-utils results in missing backend

  dn: olcBackend={0}mdb,cn=config

  the installer skips the installation step. Has to be added by
  ldpamodify.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: slapd 2.4.49+dfsg-2ubuntu1.2
  ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34
  Uname: Linux 5.4.0-31-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27
  Architecture: amd64
  CNConfig:
   Error: command ['pkexec', '/usr/bin/ldapsearch', '-Q', '-LLL', '-Y 
EXTERNAL', '-H ldapi:///', '-b cn=config'] failed with exit code 127: 
polkit-agent-helper-1: error response to PolicyKit daemon: 
GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
   Error executing command as another user: Not authorized
   
   This incident has been reported.
  CasperMD5CheckResult: skip
  Date: Fri May 22 18:27:59 2020
  InstallationDate: Installed on 2020-04-20 (32 days ago)
  InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Beta amd64 
(20200417)
  SourcePackage: openldap
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/serverguide/+bug/1880209/+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 1880209] Re: slapd configuration does not ask for olcbackend and doesn't add one. Has to be added by hand.

[Andreas Hasenack]

Oh, I can fix that. Let me add a server-guide task.

** Also affects: serverguide
   Importance: Undecided
   Status: New

** Changed in: serverguide
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: serverguide
   Importance: Undecided => Low

** Changed in: serverguide
   Status: New => Fix Released

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

Title:
  slapd configuration does not ask for olcbackend and doesn't add one.
  Has to be added by hand.

Status in Ubuntu Server Guide:
  Fix Released
Status in openldap package in Ubuntu:
  New

Bug description:
  Installing slapd and ldap-utils results in missing backend

  dn: olcBackend={0}mdb,cn=config

  the installer skips the installation step. Has to be added by
  ldpamodify.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: slapd 2.4.49+dfsg-2ubuntu1.2
  ProcVersionSignature: Ubuntu 5.4.0-31.35-generic 5.4.34
  Uname: Linux 5.4.0-31-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27
  Architecture: amd64
  CNConfig:
   Error: command ['pkexec', '/usr/bin/ldapsearch', '-Q', '-LLL', '-Y 
EXTERNAL', '-H ldapi:///', '-b cn=config'] failed with exit code 127: 
polkit-agent-helper-1: error response to PolicyKit daemon: 
GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
   Error executing command as another user: Not authorized
   
   This incident has been reported.
  CasperMD5CheckResult: skip
  Date: Fri May 22 18:27:59 2020
  InstallationDate: Installed on 2020-04-20 (32 days ago)
  InstallationMedia: Ubuntu-Server 20.04 LTS "Focal Fossa" - Beta amd64 
(20200417)
  SourcePackage: openldap
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/serverguide/+bug/1880209/+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 507728] Re: man page missing for slapo-nssov

[Andreas Hasenack]

This was fixed in 2.4.47+dfsg-2ubuntu1) for disco.

** Changed in: openldap (Ubuntu)
   Status: Confirmed => Fix Released

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

Title:
  man page missing for slapo-nssov

Status in openldap package in Ubuntu:
  Fix Released

Bug description:
  source package: openldap (2.4.18-0ubuntu1)

  >lsb_release -rd
  Description:  Ubuntu 9.10
  Release:  9.10

   >apt-cache policy slapd
  slapd:
Installed: 2.4.18-0ubuntu1
Candidate: 2.4.18-0ubuntu1
Version table:
   *** 2.4.18-0ubuntu1 0
  500 http://us.archive.ubuntu.com karmic/main Packages
  100 /var/lib/dpkg/status

  the man page for the nss overlay (e.g. slapo-nssov) is not present.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/507728/+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 495418] Re: Enable GSSAPI support (for likewise-open)

[Andreas Hasenack]

I'm trying[1] to back this out, but it will remove symbols from the
library without bumping the soname. Our next chance is when openldap 2.5
comes out, which will likely bump the soname.


1. 
https://code.launchpad.net/~ahasenack/ubuntu/+source/openldap/+git/openldap/+merge/383797

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

Title:
  Enable GSSAPI support (for likewise-open)

Status in openldap package in Ubuntu:
  Fix Released

Bug description:
  Proposed patch does two things:

  (a) Adds the --with-gssapi autoconf option necessary to
  enable code in libraries/libldap/gssapi.c (i.e #define HAVE_GSSAPI).
  This option was present in 2.4.16 from what I can tell but is not in the 
2.4.18 code in
  lucid.

  (b) Makes guess_service_principal() more robust when trying
  to determine what principal name to use (based on the hostname
  or dns name) when binding to a server.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/495418/+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 1875697] Re: drop fix-ldap-distribution.patch?

[Andreas Hasenack]

I patched the patch, ugh, but I'll think of a nice way to set this
dynamically before uploading. I'm dropping a lot of delta in the 2.4.50
merge :)

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

Title:
  drop fix-ldap-distribution.patch?

Status in openldap package in Ubuntu:
  In Progress
Status in openldap source package in Focal:
  Won't Fix

Bug description:
  Hi,

  In version 2.4.49+dfsg-3 I fixed a bug where the version was missing
  from the -V output in OpenLDAP programs:
  .

  At the same time, I've patched it to display the package version
  there, instead of the upstream version:

  # slapd -VV
  @(#) $OpenLDAP: slapd 2.4.49+dfsg-4 (Apr 15 2020 04:33:16) $
Debian OpenLDAP Maintainers 

  If showing the distro version here fulfills the same requirements as
  the fix-ldap-distribution.patch, then maybe that patch can be dropped?

  Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1875697/+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 1875697] Re: drop fix-ldap-distribution.patch?

[Andreas Hasenack]

I don't think this change is worth an SRU for focal, as the goal is to
drop a delta. It would also change a signature of sorts, so best not to
change that in an LTS release.

** Changed in: openldap (Ubuntu Focal)
   Status: Triaged => Won't Fix

** Changed in: openldap (Ubuntu)
 Assignee: (unassigned) => Andreas Hasenack (ahasenack)

** Changed in: openldap (Ubuntu)
   Status: Triaged => In Progress

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

Title:
  drop fix-ldap-distribution.patch?

Status in openldap package in Ubuntu:
  In Progress
Status in openldap source package in Focal:
  Won't Fix

Bug description:
  Hi,

  In version 2.4.49+dfsg-3 I fixed a bug where the version was missing
  from the -V output in OpenLDAP programs:
  <https://bugs.debian.org/864637>.

  At the same time, I've patched it to display the package version
  there, instead of the upstream version:

  # slapd -VV
  @(#) $OpenLDAP: slapd 2.4.49+dfsg-4 (Apr 15 2020 04:33:16) $
Debian OpenLDAP Maintainers 

  If showing the distro version here fulfills the same requirements as
  the fix-ldap-distribution.patch, then maybe that patch can be dropped?

  Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1875697/+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 1875697] Re: drop fix-ldap-distribution.patch?

[Andreas Hasenack]

That comes from debian/patches/set-maintainer-name

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

Title:
  drop fix-ldap-distribution.patch?

Status in openldap package in Ubuntu:
  Triaged
Status in openldap source package in Focal:
  Triaged

Bug description:
  Hi,

  In version 2.4.49+dfsg-3 I fixed a bug where the version was missing
  from the -V output in OpenLDAP programs:
  .

  At the same time, I've patched it to display the package version
  there, instead of the upstream version:

  # slapd -VV
  @(#) $OpenLDAP: slapd 2.4.49+dfsg-4 (Apr 15 2020 04:33:16) $
Debian OpenLDAP Maintainers 

  If showing the distro version here fulfills the same requirements as
  the fix-ldap-distribution.patch, then maybe that patch can be dropped?

  Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1875697/+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 1875697] Re: drop fix-ldap-distribution.patch?

[Andreas Hasenack]

I think dropping this delta is fine, as the "ubuntu" name will still
show as long as there is a delta. But looks like the email is wrong, we
should be showing ubuntu-devel@ there instead of the debian maintainers
list.

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

Title:
  drop fix-ldap-distribution.patch?

Status in openldap package in Ubuntu:
  Triaged
Status in openldap source package in Focal:
  Triaged

Bug description:
  Hi,

  In version 2.4.49+dfsg-3 I fixed a bug where the version was missing
  from the -V output in OpenLDAP programs:
  .

  At the same time, I've patched it to display the package version
  there, instead of the upstream version:

  # slapd -VV
  @(#) $OpenLDAP: slapd 2.4.49+dfsg-4 (Apr 15 2020 04:33:16) $
Debian OpenLDAP Maintainers 

  If showing the distro version here fulfills the same requirements as
  the fix-ldap-distribution.patch, then maybe that patch can be dropped?

  Thanks.

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