Re: Tuesday triage report (2024-03-25)

[Andreas Hasenack]

Hi,

On Thu, Mar 28, 2024 at 4:55 PM Andreas Hasenack  wrote:
>
> Hi,
>
> On Thu, Mar 28, 2024 at 4:54 PM Lucas Kanashiro
>  wrote:
> >
> > # Bug triage
> >
> > ## https://pad.lv/2058942 || D   | New   | mysql-8.0
> >| package mysql-server-8.0 8.0.36-0ubuntu0.23.10.1 failed to … |
> >
> > Marked as Incomplete. Asked for more information.
> >
> > ## https://pad.lv/2058964 || D   | New   | autofs   
> >| proposed-migration for autofs 5.1.9-1ubuntu2 |
> >
> > This requires some investigation. Do we want to tag this as server-todo?
>
> I'll take a look.
>
> First glance:
>
> Missing build dependencies: sssd-common

The cause is https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/2058576

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Tuesday triage report (2024-03-25)

[Andreas Hasenack]

Hi,

On Thu, Mar 28, 2024 at 4:54 PM Lucas Kanashiro
 wrote:
>
> # Bug triage
>
> ## https://pad.lv/2058942 || D   | New   | mysql-8.0  
>  | package mysql-server-8.0 8.0.36-0ubuntu0.23.10.1 failed to … |
>
> Marked as Incomplete. Asked for more information.
>
> ## https://pad.lv/2058964 || D   | New   | autofs 
>  | proposed-migration for autofs 5.1.9-1ubuntu2 |
>
> This requires some investigation. Do we want to tag this as server-todo?

I'll take a look.

First glance:

Missing build dependencies: sssd-common

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Merge Opportunities Report - 2024-02-26

[Andreas Hasenack]

Hi,

On Mon, Feb 26, 2024 at 5:48 AM Bryce Harrington
 wrote:
>
> New Mergeable Version in Debian Unstable
> --
> high  multipath-tools   0.9.7-4   0.9.4-5ubuntu3
> high  samba 2:4.19.5+dfsg-1   
> 2:4.19.4+dfsg-3ubuntu1

MP up: 
https://code.launchpad.net/~ahasenack/ubuntu/+source/samba/+git/samba/+merge/461236

> low   at3.2.5-2.1 3.2.5-1ubuntu1
> low   autofs5.1.9-1   5.1.8-3.1ubuntu1

MP up: 
https://code.launchpad.net/~ahasenack/ubuntu/+source/autofs/+git/autofs/+merge/461238

> low   exim4 4.97-54.97-4ubuntu1
> low   haproxy   2.9.5-1   2.8.5-1ubuntu1

We will stay on 2.8.x for the LTS


> low   libvirt   10.0.0-2  10.0.0-1ubuntu1

Was done in 
https://code.launchpad.net/~sergiodj/ubuntu/+source/libvirt/+git/libvirt/+merge/460871
but not uploaded yet, Sergio?

> low   pcs   0.11.7-1  0.11.6-1ubuntu1
> low   php8.28.2.16-2  8.2.12-1ubuntu2
> low   qemu  1:8.2.1+ds-2  1:8.2.1+ds-1ubuntu1
> low   ruby3.1   3.1.2-8   3.1.2-7ubuntu4
> low   spamassassin  4.0.1~pre1-1  4.0.0-8ubuntu1
> low   squid 6.6-1 6.5-1ubuntu3
> low   sssd  2.9.4-1   2.9.2-1ubuntu2
> low   sysstat   12.7.5-2  12.6.1-1ubuntu1
> low   targetcli-fb  1:2.1.53-1.1  1:2.1.53-1ubuntu3
> low   unbound   1.19.1-1  1.18.0-2ubuntu2

I'm taking this one, it's a simple i386 delta.

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Merge Opportunities Report - 2024-02-12

[Andreas Hasenack]

Hi,

On Mon, Feb 12, 2024 at 5:47 AM Bryce Harrington
 wrote:
> gnokii  0.6.31+dfsg-2ubuntu10 0.6.31+dfsg-5   
>  Andreas Hasenack

gnokii 0.6.31+dfsg-5ubuntu1 was published in noble/universe on
2024-02-07 (https://launchpad.net/ubuntu/+source/gnokii/0.6.31+dfsg-5ubuntu1)
and is in the release pocket already.

> golang-github-shirou-gopsutil   3.22.10-1ubuntu1  3.23.12-3   
>  Andreas Hasenack

golang-github-shirou-gopsutil 3.23.12-3ubuntu1 was published on
2024-02-08 
(https://launchpad.net/ubuntu/+source/golang-github-shirou-gopsutil/3.23.12-3ubuntu1)
and is in the release pocket already.


> php-net-ldap2   2.2.1-2ubuntu12.3.0-1         
>  Andreas Hasenack

https://launchpad.net/ubuntu/+source/php-net-ldap2/2.3.0-1 was synced
on 2024-02-08 and is in the release pocket already.

> tomcat9 9.0.70-1ubuntu1   9.0.70-2    
>  Andreas Hasenack

https://launchpad.net/ubuntu/+source/tomcat9/9.0.70-2 was synced a
while ago, but is still in proposed, so this report is correct.

> ust 2.13.6-2ubuntu1   2.13.7-1    
>  Andreas Hasenack

https://launchpad.net/ubuntu/+source/ust/2.13.7-1 was synced on
2024-02-08 and is in the release pocket already.

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Merge Opportunities Report - 2024-02-05

[Andreas Hasenack]

thos Ribeiro
> dislocker   0.7.3-2.1ubuntu2  0.7.3-3 
>  Lucas Kanashiro
> django-cte  1.3.0-1ubuntu11.3.2-1 
>  Lena Voytek
> django-oauth-toolkit1.7.0-2ubuntu12.3.0-3 
>  Lena Voytek
> elinks  0.16.1.1-4ubuntu1 0.16.1.1-4.1
>  Athos Ribeiro
> glance  2:27.0.0-0ubuntu1 2:27.0.0-2  
>  Corey Bryant
> gnokii  0.6.31+dfsg-2ubuntu10 0.6.31+dfsg-5   
>  Andreas Hasenack
> golang-github-shirou-gopsutil   3.22.10-1ubuntu1  3.23.12-3   
>  Andreas Hasenack
> ironic-ui   6.2.1-0ubuntu16.2.1-3 
>  Corey Bryant
> keystone2:24.0.0-0ubuntu1 2:24.0.0-2  
>  Corey Bryant
> libcgi-application-plugin-messagestack-perl  0.34-4ubuntu3 0.34-5 
>   Lucas Kanashiro
> lua-dbi 0.7.2-3ubuntu20.7.2-4 
>  Athos Ribeiro
> manila  1:17.0.0-0ubuntu1 1:17.1.0-1  
>  Corey Bryant
> migrate 0.13.0-0ubuntu2   0.13.0-4
>  Corey Bryant
> mistral 17.0.0-0ubuntu1   17.0.0-3
>  Corey Bryant
> monitoring-plugins  2.3.3-6ubuntu12.3.5-1 
>  Bryce Harrington
> murano  1:16.0.0-0ubuntu1 1:16.0.0-1  
>  Corey Bryant
> murano-agent1:12.0.0-0ubuntu1 1:12.0.0-1  
>  Corey Bryant
> murano-dashboard1:16.0.0-0ubuntu1 1:16.0.0-1  
>  Corey Bryant
> nagios-plugins-rabbitmq 1:1.2.0-2.2ubuntu11:1.2.0-2.5 
>  Christian Ehrhardt
> netatalk3.1.15~ds-1ubuntu13.1.18~ds-1 
>  Sergio Durigan Junior
> networking-l2gw 1:20.0.0-0ubuntu1 1:20.0.0-1  
>  Corey Bryant
> neutron-vpnaas  2:23.0.0-0ubuntu1 2:23.0.0-2  
>  Corey Bryant
> neutron-vpnaas-dashboard8.0.0-2ubuntu19.0.0-1 
>  Corey Bryant
> node-nan2.17.0-1ubuntu1   2.18.0-1
>  Bryce Harrington
> octavia-dashboard   12.0.0-0ubuntu1   12.0.0-1
>  Corey Bryant
> openstack-pkg-tools 123ubuntu2126 
>  Corey Bryant
> ovn-octavia-provider5.0.0-0ubuntu15.0.0-2 
>  Corey Bryant
> pexpect 4.8.0-4ubuntu14.9-1   
>  Sergio Durigan Junior
> pg8000  1.23.0-0ubuntu1   1.30.3-2
>  Corey Bryant
> php-amqplib 3.5.4-1ubuntu13.6.0-1 
>  Athos Ribeiro
> php-cache-integration-tests 0.17.0-2ubuntu1   0.17.0-5
>  Bryce Harrington
> php-doctrine-dbal   3.6.1+dfsg-1ubuntu1   3.8.0+dfsg-1
>  Athos Ribeiro
> php-klogger 1.2.2-1ubuntu11.2.2-2 
>  Athos Ribeiro
> php-net-ldap2   2.2.1-2ubuntu12.3.0-1 
>  Andreas Hasenack
> psycopg33.1.8-0ubuntu13.1.17-2
>  Lena Voytek
> python-barbicanclient   5.6.1-0ubuntu15.6.1-2 
>  Corey Bryant
> python-castellan4.3.0-0ubuntu14.3.0-2 
>  Corey Bryant
> python-cinderclient 1:9.4.0-0ubuntu1  1:9.4.0-2   
>  Corey Bryant
> python-debtcollector2.3.0-0ubuntu12.5.0-3 
>  Corey Bryant
> python-diskimage-builder3.29.0-0ubuntu1   3.30.0-3
>  Corey Bryant
> python-django-compressor4.0-2ubuntu1  4.0-4   
>  Lena Voytek
> python-django-crispy-forms  1.14.0-4ubuntu1   2.1-2   
>  Lena Voytek
> python-django-modelcluster  6.0-2ubuntu1  6.2.1-1 
>  Lena Voytek
> python-django-tagging   1:0.5.0-4ubuntu1  1:0.5.0-5   
>  Lena Voytek
> python-glanceclient 1:4.4.0-0ubuntu1  1:4.4.0-2   
>  Corey Bryant
> python-glance-store 4.6.1-0ubuntu14.6.1-3 
>  Corey Bryant
> python-ironicclient 5.4.0-0ubuntu15.4.0-2 
>  Corey Bryant
> python-ironic-inspector-client  5.0.0-0ubuntu15.0.0-2 
&

Re: Goodbye Canonical

[Andreas Hasenack]

Thanks for your help and for being our colleague, Michał!


On Wed, Oct 18, 2023 at 10:29 AM Michał Małoszewski <
michal.maloszew...@canonical.com> wrote:
>
> Hi,
>
> Today is my last day at Canonical. I am happy that I could share my
working days with you and learn so much. It was a pleasure to meet you.
Hope to see you one day.
>
> Best regards,
> Michał
> --
> ubuntu-server mailing list
> ubuntu-server@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
> More info: https://wiki.ubuntu.com/ServerTeam
-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Wednesday Rriage Report

[Andreas Hasenack]

Hi,

On Wed, Aug 16, 2023 at 9:38 AM Athos Ribeiro
 wrote:
>
> Bugs last updated on 2023-08-15 (Tuesday)
> Date range identified as: "Wednesday triage"
>
> https://pad.lv/2031442 | wireguard | Wireguard Broken In 23.04
>The user claims wireguard does not work at all in lunar, but does not 
> provide
>any logs nor enough information for us to reproduce the bug. I asked for 
> more
>information here.
>
> Bugs not touched in 60 days:
>
> https://pad.lv/1973630 | nfs-utils | Deprecate /etc/default/nfs-*
>The debian maitainer replied to the debian bug. They propose some changes 
> to
>the configuration in question which do not seem to fully address our
>concerns.  It would be nice to reply to the Debian bug, but since the
>maintainer added a "moreinfo" tag, I suppose they'd be expecting Andreas to
>provide the information (and remove the tag). I will sync with Andreas
>on this one.
>

I replied to the debian bug. I don't think we should add a delta
because of this, as handling config file changes is already annoying
on its own, and would be *very* annoying as a delta. I would
definitely prefer to see these files gone, though.

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Monday Triage Report (2023-06-26)

[Andreas Hasenack]

Hi

On Tue, Jun 27, 2023 at 3:24 AM Christian Ehrhardt
 wrote:
>
> On Mon, Jun 26, 2023 at 10:20 PM Sergio Durigan Junior
>  wrote:
> >
> > On Monday, June 26 2023, I wrote:
> >
> > > Bug Triage
> > > ==
> > >
> > > ### https://pad.lv/1991441 | Confirmed | glusterfs | glusterd and
> > > glusterfs crashes after dist-upgrade from foca… |
> > >
> > > armhf + illegal instruction = fun.  I subscribed ubuntu-server, but I
> > > don't have an armhf system available to test the problem.  I'll see if I
> > > can reserve one.
> >
> > I looked into this one and posted my findings there.
>
> Interesting Sergio,
> I wonder if
> https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1991441/comments/5
> into
> https://github.com/gluster/glusterfs/issues/3911
> into
> https://github.com/gluster/glusterfs/issues/702
>
> Doesn't this sort of imply we should remove armhf binaries from
> glusterfs going forward.
> If there can be a fix for the problem that is there in the existing
> versions affected (jammy AFAICS) great, we'll serve it.
> But going forward more of that is gonna happen.
>
> WDY(all)T of removing armhf in glusterfs in >Mantic and asking Debian
> if they want to do the same?

+1, I had an encounter with armhf incompatibility before[1] in
glusterfs, which was fixed, but at that time upstream already said
that it was pure luck it was fixed, because they don't care about
32bits.


1. https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1951408

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Upcoming change: rsyslog's apparmor enforced by default

[Andreas Hasenack]

Hi Steve,

On Sun, Feb 12, 2023 at 2:48 AM Steve Langasek
 wrote:
>
> Hi Andreas,
>
> On Sat, Feb 11, 2023 at 02:45:17PM -0300, Andreas Hasenack wrote:
> > Hi,
>
> > In the next few days, if all goes according to plan, I'll upload
> > rsyslogd to lunar with a change[1] to the way its apparmor profile is
> > applied.
>
> > The confinement status won't be changed during upgrades, but fresh
> > installs will have the apparmor profile enforced by default. Up until
> > now, it's been disabled.
>
> Can you elaborate on this decision not to change the behavior on upgrade?
> It's expected on upgrade between releases that behavior will change; and to

Hmm, you are right, I was thinking in the context of lunar to lunar
upgrades, and not release upgrades, which is what we are aiming for.

> not enforce for upgrading users means a difference in configs between new
> installs and upgrades that complicates the support matrix over the long
> term.
>
> I am strongly in favor of making the behavior on upgrade conform to the
> behavior on new installs - even if that means there might be some unpleasant
> surprises where the package fails to configure because of apparmor being
> enabled.  That seems unlikely to me in any case; even if the user has
> diverged from the stock rsyslog config, it seems more likely to me that the
> daemon would still start up but might in some cases fail to log.  Again,

Correct, I'm not failing the startup because apparmor failed to apply
or load, and that is in line with current rsyslog's behavior towards
its plugins. If a plugin fails to write a log (like mysql is not
available, or apparmor prevented it from doing so), it will just keep
retrying in the background, instead of failing the whole daemon or the
logging to other places.

I'll make the change, thanks for the feedback!

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Upcoming change: rsyslog's apparmor enforced by default

[Andreas Hasenack]

Hi,

In the next few days, if all goes according to plan, I'll upload
rsyslogd to lunar with a change[1] to the way its apparmor profile is
applied.

The confinement status won't be changed during upgrades, but fresh
installs will have the apparmor profile enforced by default. Up until
now, it's been disabled.

A summary is in the README.apparmor[2] file, and d/NEWS was also
updated/created. I tried a mix of fixed and dynamic profile snippets,
and packages can install their own snippets if needed. These would
usually be packages that alter the rsyslog configuration to log
somewhere else where the normal apparmor profile would have denied
that, but at the same time we don't want to allow that by default if
it's not needed.

There are a few more use cases I would like to tackle, including more
test cases, and the `omprog` plugin is an obvious one. This is not yet
covered, and I hope to get more data about its usage before coming up
with a solution. It's hard to try to detect its usage in the config
file because the config can be in so many different formats. Maybe we
can come up with generic sandbox of some sort for binaries used with
the omprog plugin, or maybe we will just have to leave users to adjust
that via the existing /etc/apparmor.d/local/usr.sbin.rsyslogd
mechanism.

This adds a lot of delta to the package, at least in line count, but I
don't think it's hard to maintain. I'll also of course try to submit
this to debian, once we settled on the approach in lunar.

1. 
https://code.launchpad.net/~ahasenack/ubuntu/+source/rsyslog/+git/rsyslog/+merge/436955
2. 
https://git.launchpad.net/~ahasenack/ubuntu/+source/rsyslog/tree/debian/README.apparmor?h=lunar-rsyslog-enable-apparmor-dep8-take4-dot-d

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Tuesday triage (2022-01-30)

[Andreas Hasenack]

Hi,

On Tue, Jan 31, 2023 at 4:07 PM Lucas Kanashiro
 wrote:
> ## https://pad.lv/2004145 || D   | New   | wireguard  
>  | Massive (3x) performance regression for WireGuard in Ubuntu… |
>
> Andreas started to engage with the bug reporter. I did not try to reproduce 
> it because it would require some Digital Ocean droplets.

I think the next step for this one would be to try with local VMs of
Ubuntu 18.04 and 22.04, and see if in this environment we can already
spot the performance hit. That would exclude something specific to the
host where the DO VMs run.

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Wednesday triage report (2022-11-29)

[Andreas Hasenack]

Hi,

On Wed, Nov 30, 2022 at 9:55 AM Athos Ribeiro
 wrote:

> ## dsctriage ##
>
> Showing comments belonging to the Server category, updated on 2022-11-29 
> (Tuesday)
> Automated Server Installs  [Michael Hudson Doyle] 
> (https://discourse.ubuntu.com/t/16612)
> └─ +82394 [Modem7, 2022-11-29] (https://discourse.ubuntu.com/t/16612/51)
> └─ +82396 [Alowther, 2022-11-29] (https://discourse.ubuntu.com/t/16612/52)
>└─ +82397 [Modem7, 2022-11-29] 
> (https://discourse.ubuntu.com/t/16612/53)
>
>The second (new) comment here replies the first one. Nothing to do here.
>
> Virtualization - multipass [Robie Basak] 
> (https://discourse.ubuntu.com/t/11983)
> └─ +82386 [Jason C. Nucciarone, 2022-11-29] 
> (https://discourse.ubuntu.com/t/11983/2)
>
>Andreas replied to this one as I was going through it. Thanks, Andreas :)

There is still a pending issue where with selecting multipass to use
the libvirt backend. The instructions we have in that page no longer
work, and I quickly tried what it was proposing but that didn't work.
I probably did something wrong, but further investigation is needed.

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Monday triage report

[Andreas Hasenack]

Hi,

On Mon, Nov 21, 2022 at 2:52 PM Athos Ribeiro 
wrote:

> Discourse Comment Triage Helper
> Showing comments belonging to the Server category, updated between
> 2022-11-18 (Friday) and 2022-11-20 (Sunday) inclusive
> Service - Kerberos with O… [Andreas Hasenack] (
> https://discourse.ubuntu.com/t/15356)
> └─ +82056 [Surfrock66, 2022-11-20] (
> https://discourse.ubuntu.com/t/15356/15)
>
>This is possibly a user with a configuration issue. I am unsure on how
> to
>proceed on this one. Should we ask them for more information in the
> discourse
>thread itself, ask them to file a bug or point the user to some user
> support
>channel?
>
>
I saw this one in my inbox, and didn't tend to it because a) it's the most
complicated setup we have in the guide; b) I would probably have to
redeploy that thing to understand the details of what he is asking.
-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Second Kinetic Kudu test rebuild

[Andreas Hasenack]

freeradius was a flaky failure, the retry was successful and the
package is gone from the FTBFS list.

On Mon, Sep 19, 2022 at 6:13 PM Andreas Hasenack  wrote:
>
> I checked pam-p11 and freeradius.
>
> pam-p11 is legit, and I filed a bug[1] for it. I tested on s390x and
> ppc64el and the ftbfs happens there indeed.
>
> freeradius looked odd, and when I retried in an s390x VM with
> kinetic-proposed, it passed. I asked Graham on irc if he could retry
> it on his ppa, or if I should upload a no-change rebuild (probably the
> former is best).
>
> 1. https://bugs.launchpad.net/ubuntu/+source/pam-p11/+bug/1990194
>
> On Mon, Sep 19, 2022 at 8:45 AM Graham Inggs  wrote:
> >
> > The second test rebuild of Kinetic Kudu was started on September 14,
> > 2022 for all architectures, all components. The rebuild is finished
> > for the main component on all architectures, finished for
> > universe/multiverse on amd64, i386 and ppc64el, and still running on
> > the other architectures.
> >
> > Results (please also look at the superseded builds) can be found at
> >
> > https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20220914-kinetic-kinetic.html
> >
> > Additional build failures for packages in kinetic-proposed (not yet
> > migrated to kinetic) can be found at
> >
> > http://qa.ubuntuwire.com/ftbfs/
> >
> > Please help fixing the build failures.
> >
> > Graham
> >
> > --
> > ubuntu-devel mailing list
> > ubuntu-de...@lists.ubuntu.com
> > Modify settings or unsubscribe at: 
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Second Kinetic Kudu test rebuild

[Andreas Hasenack]

I checked pam-p11 and freeradius.

pam-p11 is legit, and I filed a bug[1] for it. I tested on s390x and
ppc64el and the ftbfs happens there indeed.

freeradius looked odd, and when I retried in an s390x VM with
kinetic-proposed, it passed. I asked Graham on irc if he could retry
it on his ppa, or if I should upload a no-change rebuild (probably the
former is best).

1. https://bugs.launchpad.net/ubuntu/+source/pam-p11/+bug/1990194

On Mon, Sep 19, 2022 at 8:45 AM Graham Inggs  wrote:
>
> The second test rebuild of Kinetic Kudu was started on September 14,
> 2022 for all architectures, all components. The rebuild is finished
> for the main component on all architectures, finished for
> universe/multiverse on amd64, i386 and ppc64el, and still running on
> the other architectures.
>
> Results (please also look at the superseded builds) can be found at
>
> https://people.canonical.com/~ginggs/ftbfs-report/test-rebuild-20220914-kinetic-kinetic.html
>
> Additional build failures for packages in kinetic-proposed (not yet
> migrated to kinetic) can be found at
>
> http://qa.ubuntuwire.com/ftbfs/
>
> Please help fixing the build failures.
>
> Graham
>
> --
> ubuntu-devel mailing list
> ubuntu-de...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Tuesday bug triage report (2022-09-05)

[Andreas Hasenack]

Hi,

On Thu, Sep 8, 2022 at 4:32 PM Sergio Durigan Junior
 wrote:
>
> On Thursday, September 08 2022, Lucas Kanashiro wrote:
>
> > ## https://pad.lv/1987992 - *(New)   [autofs]- autofs:
> > Missing support of SCRAM for SASL binds
> >
> > The bug reporter proposed a patch which should be submitted upstream, I
> > asked them to do so and once it is done add a reference to that in the bug
> > so we can track.
>
> Thanks, Lucas.
>
> This was the bug I mentioned during the standup today.  I was going to
> suggest sending the patch upstream, but I'd like to take a second look
> just in case.  Either way, I agree with your feedback there.

I agree the placement of the SCRAM module is unfortunate (being in the
gssapi mit package), and it prevents someone who prefers the heimdal
gssapi plugin to install the scam plugin, but we have to think about
it a bit:
- this is moving a module from one package to another. How much of a
surprise will this be to our sasl users? Some users might be using
sasl without even knowing it
- is there a risk of someone who was using either SCRAM or any of the
GSSAPI plugins of losing access to either of them after a
dist-upgrade? If yes, this can have serious consequences (i.e., loss
of authentication and access to a service)
- the real bug is that you cannot have both the heimdal gssapi sasl
plugin and SCRAM installed at the same time, because the packages that
contain these plugins conflict with each other.

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Merge Opportunities Report - 2022-08-15

[Andreas Hasenack]

Hello,

On Mon, Aug 15, 2022 at 4:50 AM Bryce Harrington
 wrote:

> Merges last authored or uploaded by Server team member or alumnus (via 
> Merge-o-Matic)
> --
> bagel   1.2.2-3ubuntu11.2.2-4 
>  Utkarsh Gupta
> cacti   1.2.20+ds1-2ubuntu1   1.2.21+ds1-1
>  Athos Ribeiro
> freecad 0.19.2+dfsg1-3ubuntu2 0.20+dfsg1-4
>  Robie Basak

I did this one as part of my +1 maintenance shift, it became a sync
and is in kinetic-proposed:

https://launchpad.net/ubuntu/+source/freecad/0.20+dfsg1-4

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Wednesday Triage Report (2022-06-08)

[Andreas Hasenack]

Hi,

On Wed, Jun 8, 2022 at 8:36 PM Sergio Durigan Junior
 wrote:
>
> ustriage found 27 bugs.  These are the noteworthy ones:
>
> ### https://pad.lv/1915095 - *(Incomplete) [clamav] - clamscan modifies
> atime during scheduled scans
>
> Revisited the test case I had proposed and updated it to make sure it
> triggers the bug.  Still waiting for upstream on this one (and still a
> low priority bug).
>
>
> ### https://pad.lv/1977491 - (Confirmed) [samba] - Update Samba in
> 22.04LTS to 4.15.7 so macOS clients can con…
>
> Seems like a valid regression, but I don't have access to a MacOS in
> order to test it.  I'm Cc'ing Andreas here so that he can take a look;
> maybe he's able to test the bug.  Let me know otherwise.

This is a case where we will have to rely on the community/reporter to
test, but if there is a clear commit or patch, we should try to SRU
it.

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Merge Opportunities Report - 2022-05-30

[Andreas Hasenack]

Hi,

On Mon, May 30, 2022 at 7:52 AM Bryce Harrington
 wrote:

> pythonpy0.4.11b-3ubuntu1  0.4.11b-3.1 
>  Andreas Hasenack

Just made this a sync, since the same patch was applied to the debian package.

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Merge Opportunities Report - 2022-05-16

[Andreas Hasenack]

Hi,

On Mon, May 16, 2022 at 4:54 AM Bryce Harrington
 wrote:

> tango   9.2.5a+dfsg1-2ubuntu1 9.3.4+dfsg1-1   
>  Andreas Hasenack

I merged tango and
https://launchpad.net/ubuntu/+source/tango/9.3.4+dfsg1-1ubuntu1
migrated ~10 days ago

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Log-rotation doesn't work for catalina.out in src:tomcat9 as intended

[Andreas Hasenack]

Hi,

On Thu, May 12, 2022 at 10:53 AM Utkarsh Gupta
 wrote:
>
> Hi Andreas,
>
> On Thu, May 12, 2022 at 6:17 PM Andreas Hasenack  
> wrote:
> > This reminded me that frr is also affected by this:
> > https://bugs.launchpad.net/ubuntu/+source/frr/+bug/1958162
> >
> > And frr is in main now. I'll work on it.
>
> Ah. D'you think there could be somewhat of a common solution here?
> Or are each of them going to be very different from each other?

I don't know yet :)

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Log-rotation doesn't work for catalina.out in src:tomcat9 as intended

[Andreas Hasenack]

Hi,

On Tue, May 10, 2022 at 5:07 AM Evren Yurtesen  wrote:
>
> Hi Robie and Utkarsh,
>
>
> This issue is not isolated to tomcat9 package. For example, jetty9 package 
> logging does not work. Rsyslog says:

This reminded me that frr is also affected by this:

https://bugs.launchpad.net/ubuntu/+source/frr/+bug/1958162

And frr is in main now. I'll work on it.

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

nfs-utils update status

[Andreas Hasenack]

Hi,

I just wrote a lengthy email to a debian bug
(https://bugs.debian.org/1005236) and thought I should share it here
too. CCing ubuntu-devel@ since this is not an Ubuntu Server package.

This is the current situation with nfs-utils regarding LP bug
#1878601[1]. I guess the most important part is how to handle the
migration of /etc/default/nfs-* to /etc/nfs.conf, and changes in
general, considering the next ubuntu release is an LTS. Details in the
text below.

"""
I've been looking at the exp package lately, since I'm trying to
update[1] the ubuntu nfs-utils package as well, which we neglected for
many releases.

There are upstream changes, and packaging changes, and a question on
how to handle upgrades.

src:libnfsidmap and src:libnfsidmap-regex were pulled[2][3] into
upstream's nfs-utils (in 2017 and 2020, respectively), which deprecate
those source packages in debian and ubuntu. libnfsidmap actually
forked, and got some new features like LDAP_tls_reqcert config
support[4] and SASL binds[5] in its new home in nfs-utils, for
example, besides plenty of fixes.

Upstream's most visible change is probably the configuration. Instead
of a complicated mechanism to source different configuration files
(/etc/sysconfig in RH, /etc/default/nfs-* in debian/ubuntu), and then
adjust command-line options to all the different daemons, upstream now
changed the daemons themselves to read a new /etc/nfs.conf ini-style
config file[6]. Fedora has a python conversion script[7] that they use
as a one-shot systemd service unit[8]. I played[9] with it a little
and we can easily make it work with debian/ubuntu, and that opens up
some paths for us to handle the migration.

Maybe the only reason to keep the /etc/default/nfs-* files is for sysv
initscripts, to be able to run or not a particular service
(NEED_=yes|no), if that's still an objective. For systemd, it
will be the usual systemctl enable/disable/mark/unmask.

The old nfs-config.service unit is gone, since there is no need to
generate an aggregated config file for the different systemd units to
source and adjust command line options.

The old libnfsidmap2 package unfortunately has an incorrect major
number, it should have been libnfsidmap0 (the library it carries is
.so.0.3.0 and has a soname of 0). Maybe there is some history behind
this. That creates the odd situation now with the new one, which is
libnfsidmap1. Reminds me of the pcre2/pcre3 situation, where pcre2 is
newer.

There is a new service, nfsdcld, a client tracking daemon, used in
NFSv4. It's just an upgrade from what was called "legacy tracking" in
old kernels, then got replaced by "nfsdcltrack", but that one isn't
container-friendly, and now we have nfsdcld.

NFS, as usual, has many intertwined services, and I'm just happy that
all the systemd units seem to have correct declarations and that it
"just works", so far at least in my testing. But corner cases are for
sure there somewhere. I tested one, where nfs was exporting an iscsi
mounted filesystem, and in older versions that would hang the boot of
the server, but that worked, phew. That sounded exactly like a "corner
case".

Finally, the reverse dependencies need to be rebuilt and checked that
they still work. In Ubuntu, that's nfs-ganesha and sssd, and they at
least build, I haven't checked Debian.

So, my summary:
- it's my opinion that debian and ubuntu need the new version sooner
rather than later. I'm actively working on bringing it into ubuntu,
based on the exp package from debian. My branch is currently at [10],
with a PPA at [11]. The delta we had was basically zeroed, due to a
combination of upstream changes and debian changes.
- we need a plan for an upgrade path. Some choices:
  - do nothing but release notes
  - detect if /etc/default/nfs-* have changes, and warn in that case,
asking the user to move the changes over to /etc/nfs.conf
  - to help with above, also ship fedora's script and let the user
know it exists and could be used. Maybe even run it and place the
output somewhere temporary for analysis
  - actually run fedora's conversion script in postinst, and let the
user know it was done and ask them to double check
- old source packages (src:libnfsidmap and src:libnfsidmap-regex) need
to be removed/obsoleted. I think it's safe to say upstream libnfsidmap
is gone, but libnfsidmap-regex still seems active. We *could* just not
build nfs-utils's regex plugin, and use src:libnfsidmap-regex, but the
libnfsidmap history has shown that at least in that case, nfs-utils'
implementation has diverged over time.

Cheers!


1. https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1878601
2. 
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=1ea6d9231f839b968adb44eaf98b363f436cb1d5
3. 
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=940caffdfb9953a2ccfecec81664e4a179753461
4. 
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=d77ee0f18c0e0658f892932600c38c346c4d5337
5. 

Quagga removal, welcome frr

[Andreas Hasenack]

Hi all,

quagga was removed[1] from Debian, and is unmaintained upstream. I'm
working on a MIR[1] for frr which is a fork from quagga and replaces
it.

I don't know yet if it's a 100% drop-in replacement, and wanted to ask
others at large how they would be impacted by the removal of quagga
from Ubuntu.

The intent is to remove quagga from Ubuntu as well, and replace it with frr.



1. https://tracker.debian.org/news/1281917/removed-124-4-from-unstable/
2. https://bugs.launchpad.net/ubuntu/+source/frr/+bug/1951834

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Merge Opportunities Report - 2021-12-27

[Andreas Hasenack]

Hi,

On Mon, Dec 27, 2021 at 5:57 AM Bryce Harrington
 wrote:
>
> New Mergeable Version in Debian Unstable
> --
> high  apache2   2.4.52-1  2.4.51-2ubuntu1
> high  bind9 1:9.17.21-1   1:9.16.15-1ubuntu3

We don't want bind9 9.17, but 9.16 has newer upstream releases which
we should probably grab. Debian has 9.16.22 in the stable release:

bind9  | 1:9.16.22-1~deb11u1  | stable
  | source

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Friday bug triage

[Andreas Hasenack]

Here is an old MP when I dealt with bug patterns for the first (and last) time:

https://code.launchpad.net/~ahasenack/apport/samba-security-share-bugpattern/+merge/327251

Hope this helps

On Fri, Nov 12, 2021 at 2:38 PM Utkarsh Gupta
 wrote:
>
> Hiya,
>
> On Thu, Nov 11, 2021 at 6:00 PM Robie Basak  wrote:
> > It would be preferable to adjust the apport hook (if needed) and add a
> > Launchpad bug pattern. Then users can be pointed to some text about it
> > (eg. pointers to fixing it or getting further help) but we won't get bug
> > reports.
> >
> > Is that possible in this case?
>
> I am not sure how that works. I've no experience in working with
> Launchpad bug patterns. But if you think that'd stop these bug
> reports, then I am all in for the change! \o/
>
>
> - u
>
> --
> ubuntu-server mailing list
> ubuntu-server@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
> More info: https://wiki.ubuntu.com/ServerTeam

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Friday bug triage

[Andreas Hasenack]

Hi,

On Fri, Jul 23, 2021 at 1:15 PM Utkarsh Gupta 
wrote:

>
> 5. LP: #1937316 - (New) [ubuntu-advantage-tools] - Cannot
>download source packages provided by Ubuntu ESM
>
> Pinged the other squad which looks at ua-tools, so they'll
> look at this one. We didn't do anything to the bug.
>
>
FWIW, this is a known issue. The credentials to download packages from ESM
are stored in a 0600 root:root file, so normal non-root users cannot read
them, which means the apt-get source command must be run as root. I'm
pretty sure there is a bug about this already, still open. My suggestion
would be for people affected by this to create a group and chmod 0640
root: that file, if they want non-root users to download ESM source
packages.
-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Triage Report - Friday 25th of June 2021

[Andreas Hasenack]

I change only the release-specific tag, not the generic one.

On Fri, Jun 25, 2021 at 8:19 AM Robie Basak 
wrote:

> On Fri, Jun 25, 2021 at 09:33:04AM +0200, Christian Ehrhardt wrote:
> > @Robie - maybe you can explain better what the right handling nowadays
> would be?
>
> I'm not sure, but the important thing is that the entry goes clean and
> green in the pending-sru report
> (https://people.canonical.com/~ubuntu-archive/pending-sru.html).
>
> It looks like
>
> https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/sru-report
> doesn't care about any verification-done flag.
> --
> ubuntu-server mailing list
> ubuntu-server@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
> More info: https://wiki.ubuntu.com/ServerTeam
-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Wednesday Triage Report (2020-09-23)

[Andreas Hasenack]

Hi,

On Thu, Sep 24, 2020 at 12:07 AM Sergio Durigan Junior
 wrote:
>
> Hi,
>
> This Wednesday I did my first triage, replacing Rafael.
>
> The only noteworthy bug I have is this one:
>
> - https://pad.lv/1676328 - *(Confirmed) [sssd] - sssd_be is leaking
>   memory
>
> There has been a comment by yet another person confirming the bug.  This
> is obviously not server-next, but I don't have anything meaningful to
> reply to the user for now.  Andreas, you mentioned in the bug that you
> were going to look at the changes in 1.16 and see if anything comes up;
> do you remember doing that?  I know it's been a while, but...

I didn't find good immediate candidates

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Triage report (2020-09-10)

[Andreas Hasenack]

And after fixing those, I found 2 or 3 more. I will rename one to
"cyrus-sasl2 doesn't build with sphinx 3.2.x" and dupe the other(s).


On Thu, Sep 10, 2020 at 11:10 AM Paride Legovini
 wrote:
>
> Found 19 bugs, mostly being actively worked at.
> New bugs worth mentioning:
>
> LP: #1894907 - +(New)   [cyrus-sasl2]- FTBFS with sphinx
> 2.4: cannot import name 'NoUri'
>
> LP: #1895006 - +(Triaged)   [cyrus-sasl2]- FTBFS with sphinx
> 2.4: cannot import name 'MACRO_DEF'
>
> FTBFS bugs filed by Andreas, I subscribed the team.
> Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955095
>
> LP: #1895023 - (New)[resource-agents] - autopkgtest fails in
> focal
>
> Marked as duplicate of LP: #1828258.
>
> Paride
>
> --
> ubuntu-server mailing list
> ubuntu-server@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
> More info: https://wiki.ubuntu.com/ServerTeam

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Bug triage report for 2020-09-08 (Tuesday triage)

[Andreas Hasenack]

I updated the bug with the new intention

On Tue, Sep 8, 2020 at 11:51 PM Rafael David Tinoco
 wrote:
>
> > The reporter is correct in that this comes up every now and then.
> > GlusterFS is very popular with samba clustering (CTDB) setups. Would
> > it be worth it to add a delta with debian and create a new binary
> > package for just the glusterfs vfs module and place that in universe?
> >
>
> I like the idea @ahasenack, if you have bandwidth for that... or at
> least to keep this in the backlog...
>
> In my previous discourse doc:
>
> https://discourse.ubuntu.com/t/ctdb-create-a-3-node-nfs-ha-backed-by-a-clustered-filesystem/11608
>
> I even talked about CTDB + NFS HA and quoted GlusterFS as an example:
>
> """
> SUMMARY
>
> 2 x clustered filesystem servers (could be GlusterFS servers)
> 3 x nodes as clients to this Clustered Filesystem
> The 3 NFS nodes will act as clients to Clustered FS
> The 3 NFS nodes will act as servers for NFS service
> The NFS service will be High Available among all 3 nodes
> NFS clients can DNS load balance among the 3 x NFS servers
> If 1 NFS server goes down, the other NFS server will act on its behalf
> All NFS servers will serve the SAME FILESYSTEM
> CTDB lock file MUST reside in a clustered filesystem directory
> """
>
> Just checked and we're synced with Debian in 8.1-1 for GlusterFS.
>
> I'm +1 as I have always liked GlusterFS =).

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Bug triage report for 2020-09-08 (Tuesday triage)

[Andreas Hasenack]

Hi,

On Tue, Sep 8, 2020 at 4:07 PM Lucas Kanashiro
 wrote:
>
> == Triage ==
> Bugs last updated on 2020-09-07 (Monday)
> Date range identified as: "Tuesday triage"
> Found 25 bugs
>
> The list of bugs today is longer than usual but most of them are bugs that 
> people are working on or expired ones. A few comments below:
>
> https://pad.lv/1894618 - (New)[samba]  - samba vfs 
> glusterfs shares do not work because glusterfs.so is missing from 
> samba-vfs-modules
> -> The bug reporter asked for inclusion of glusterfs.so in the package, but 
> it was intentionally disabled because GlusterFS is not in main. Explained the 
> situation and marked it as Won't Fix (apparently no team wants to own it 
> according to the MIR bug).

The reporter is correct in that this comes up every now and then.
GlusterFS is very popular with samba clustering (CTDB) setups. Would
it be worth it to add a delta with debian and create a new binary
package for just the glusterfs vfs module and place that in universe?

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Merge Opportunities Report - 2020-08-10

[Andreas Hasenack]

On Mon, Aug 10, 2020 at 12:50 PM Bryce Harrington
 wrote:
>
> New Version in Debian Unstable
> -->
>  low   nginx 1.18.0-5  1.18.0-3ubuntu2

I grabbed nginx

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Merge Opportunities Report - 2020-07-13

[Andreas Hasenack]

On Mon, Jul 13, 2020 at 12:47 PM Bryce Harrington <
bryce.harring...@canonical.com> wrote:

> New Version in Debian Unstable
>
> --
> high  apache2   2.4.43-1  2.4.41-4ubuntu3
>


I have a branch for this, just pending a bileto run



> high  multipath-tools   0.8.4-1   0.8.3-1ubuntu2
>
> high  nut   2.7.4-12  2.7.4-11ubuntu4
>
> high  openipmi  2.0.29-0.12.0.27-0ubuntu2
>
> high  samba 2:4.12.5+dfsg-3
>  2:4.12.2+dfsg-0ubuntu1
>

I'll get to it, but there has been some churn with this 4.12.5 samba and
sssd working together.



> New Version in Experimental
>
> --
> high  spamassassin  4.0.0~0.0svn1879217-1 3.4.4-1ubuntu1
>
> high  tmux  3.2~rc1-1 3.1b-1
>
> low   haproxy   2.1.7-1   2.0.15-1
>
>

We *could* adopt this haproxy. It's not upstream's LTS (that would be the
2.0.x series, which we have in focal btw). We would be getting our feet wet
with the new features in preparation for the next LTS.
-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Fwd: Registration for DebConf20 Online is Open

[Andreas Hasenack]

-- Forwarded message -
From: 
Date: Sun, Jul 12, 2020 at 10:04 AM
Subject: Registration for DebConf20 Online is Open
To: , <
debconf-annou...@lists.debian.org>


The DebConf team is glad to announce that registrations for DebConf20
Online is
now open. To register for DebConf20, please visit our website at

https://debconf20.debconf.org/register

Participation to DebConf20 is conditional to your respect of our Code of
Conduct. We require you to read, understand and abide by this code:

https://debconf.org/codeofconduct.shtml

A few notes about the registration process:

- We need to know attendees' locations to better plan the schedule around
  timezones. Please make sure you fill in the "Country I call home" field in
  the registration form accordingly. It's specially important to have this
  data for people who submitted talks, but also for other attendees.

- There is an attempt to provide DebConf20 T-shirts, so there is a field for
  that as well. As you might imagine, the logistics of that is not exactly
  easy, so there are no guarantees that it actually happens.

- We are also offering financial support for those who require it in order
to
  attend due to the current economic crisis. Please refer to the
  corresponding page at the website for more information:

  https://debconf20.debconf.org/about/bursaries/

Any questions about registrations should be addressed to
.
-BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEEst7mYDbECCn80PEM/A2xu81GC94FAl8LCjcACgkQ/A2xu81G
C96kZxAAlAmTWFxYNQmxU1RO7XXhseY2H1U9/pREfB4Q5LiANzo8en+PLs3wt3cI
NQp4ncopZFR0DDNx/FrQM/MVWhkQRjt2EmLgNLO+6X8b6MCV7I/5T0iYjRasz0XY
EkpVfxk2jxm1I8C+fG5k5aMMprdF1FX4AqPvBKnVNK9yIVe4Xj8pSi+trrZBXcMI
KiR0CYXvrdINZirPh9JeuKscFsJ5ME12lrL2jqLjPUwWnMZHYASQoCW8BcxmbVQ/
aDaUY4Q861ilZUYFYPMZKskZBF9SqwFHuVu3jY26Du1A3Q+0kp3Xeq1IPoOAQbz/
vy1i8Y9FjrGNT+ejjq0hD2WjovBLmzU1OmBJY3q5LE7eLOKDzVYAjjFzCYzYyy25
MCLYO45v8vuDWM+dlirvAN5SZcNCyQvpJMFMkHKacuo1FAwGZC9HccVqCf2UXisx
9M6TCe5a7hkIBcpzPdnB3bCtZMr/0rZUdXNHskPnD84GGmbp3l9k2w3XVCoy4Cbl
BwLdt8Zdwu4NGGh5cL/eMQGcRG6QAULfABGJrkCEdT8ReBohc2bOAK7viVjqMp9W
lzDS6epqODk4IP8n+rihkR0k96leUzzlk5mWrr/7StsfpU2V0KBjmmI9DvC6zc9v
xpRaS9Xz+qw646SoFO5MDDfy3iIirnJZ1HbhbHioKbs4fYirulE=
=MYBZ
-END PGP SIGNATURE-
-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Linux Plumbers 2020 Conference (online)

[Andreas Hasenack]

FYI

https://www.linuxplumbersconf.org/event/7/page/47-attend
-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Merge Opportunities Report - 2020-06-08

[Andreas Hasenack]

On Mon, Jun 8, 2020 at 1:01 PM Bryce Harrington
 wrote:
>
> New Version in Debian Unstable
> --
> high  apache2   2.4.43-1  2.4.41-4ubuntu3
> high  nut   2.7.4-12  2.7.4-11ubuntu4
> high  sosreport 3.9-2 3.9-1ubuntu3
> low   dpdk  19.11.2-1 19.11.1-0ubuntu2
> low   exim4 4.94-24.93-15ubuntu1
> low   krb5  1.17-71.17-6ubuntu4

Hold on krb5, there is a -8 (soon to be -9 I think) that I think has
all our delta.

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Proposed migration: bind9-libs

[Andreas Hasenack]

Just a heads up that I'm working in the bind9-libs migration:

bind9-libs (1:9.11.16+dfsg-3~build1 to 1:9.11.18+dfsg-1) in proposed for 20 days

candidate

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Cleaning up the openldap packaging

[Andreas Hasenack]

Hello,

for this post-LTS cycle I wanted to cleanup our openldap packaging and
get more in line with Debian's. We have some very old delta that was
added circa 2009 due to likewise-open (as far as I could dig up), and
that we shouldn't carry anymore.

To that end, I started this [merge
proposal](https://code.launchpad.net/~ahasenack/ubuntu/+source/openldap/+git/openldap/+merge/383797),
but was quickly reminded by Ryan Tandy (Debian's openldap maintainer)
that in order to drop these two pieces of delta:

- gssapi patch (introduced via https://code.launchpad.net/bugs/495418)
- connection-less ldap (ldap over udp)

i would have to change the soname of the library, because dropping the
changes above means removing symbols from the library and thus
breaking backwards compatibility with anything that might be using
them.

I believe back then when this was introduced, likewise-open didn't
support sasl gssapi, just plain gssapi. About "connection-less ldap",
as far as I can tell, that was last needed to do ldap suffix discovery
with windows 2000 servers.

Not being able to drop these is unfortunate, as at least the gssapi
patch is kind of wrong to be carried (sasl gssapi should be used
instead), but, as they say, we are between a rock and a hard place.

It looks like the best moment to drop those is when openldap 2.5 comes
out, as that will (likely) have a soname bump, and we can then remove
this delta and do a proper transition. But it's unclear when that
release will happen.

Another change I wanted to drop is the nss overlay. Debian doesn't
build it, I don't think we need another nss library/system, and
distributions seem to be standardizing on sssd. We don't even have any
other nss module in ubuntu main, just sssd: the rest is in universe.

If you are one of the users of this nss overlay in openldap, I would
lke to hear from you.

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

[Bug 1723350] Re: sssd offline on boot, stays offline forever

[Andreas Hasenack]

** Description changed:

  [Impact]
  sssd can switch to an offline mode of operation when it cannot reach the 
authentication or id backend. It uses several methods to assess the situation, 
and one of them is monitoring the /etc/resolv.conf file for changes.
  
  In ubuntu that file is a symlink to /run/systemd/resolve/stub-
  resolv.conf, but the target doesn't exist at all times during boot. It's
  expected that symlink to be broken for a while during boot.
  
  Turns out that the monitoring that sssd was doing on /etc/resolv.conf
  didn't take into consideration that what could change was the *target*
  of the symlink. it completely ignored that fact, and didn't notice when
  the resolv.conf contents actually changed in this scenario, which
  resulted in sssd staying in the offline mode when it shouldn't.
  
  There are two fixes being pulled in for this SRU:
  a) fix the monitoring of the target of the /etc/resolv.conf symlink
  b) change the fallback polling code to keep trying, instead of giving up 
right away
  
  [Test Case]
  It's recommended to test this in a lxd container, or a vm.
  
  Preparation steps. When prompted for an openldap/slapd password, chose any 
password you want. It won't be needed again:
  $ sudo apt update && sudo apt dist-upgrade
  $ sudo apt install sssd-ldap sssd-tools sssd-dbus slapd dnsmasq
  
  Become root:
  $ sudo su -
  
  Detect your ip:
  # export interface=$(ip route | grep default | sed -r 's,^default via .* dev 
([a-z0-9]+) .*,\1,')
  # export ip=$(ip addr show dev $interface | grep "inet [0-9]" | awk '{print 
$2}' | cut -d / -f 1)
  
  Confirm the $ip variable is correct for your case:
  # echo $ip
  
  Create /etc/dnsmasq.d/sssd-test.conf using your real ip:
  # cat > /etc/dnsmasq.d/sssd-test.conf < /etc/sssd/sssd.conf  /etc/resolv.conf.good
  
  Confirm /etc/resolv.conf is a broken symlink:
  # ll /etc/resolv.conf*
  lrwxrwxrwx 1 root root 23 May 13 20:48 /etc/resolv.conf -> 
/etc/resolv.conf.target
  -rw-r--r-- 1 root root 24 May 13 20:48 /etc/resolv.conf.good
  
  Open another terminal/screen and tail the sssd logs with a grep:
  # tail -f /var/log/sssd/sssd.log | grep -i resolv
  
  Start sssd
  # systemctl restart sssd
  
  The tail output from that other terminal should say sssd is monitoring 
/etc/resolv.conf (that's the broken symlink):
  (Mon May 18 17:32:34 2020) [sssd] [_snotify_create] (0x0400): Added a watch 
for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using 
function resolv_conf_inotify_cb after delay 1.0
  
  Repeat this sssctl call until it shows the offline mode persistently:
  # sssctl domain-status LDAP
  Online status: Offline
  
  Active servers:
  LDAP: not connected
  
  Discovered LDAP servers:
  - ldap01.example.com
  
  "Unbreak" the symlink:
  # cp /etc/resolv.conf.good /etc/resolv.conf.target
  
  The log should now say:
  (Mon May 18 17:33:30 2020) [sssd] [process_dir_event] (0x0400): Not 
interested in resolv.conf.target
  
  This shows that sssd didn't pick up that resolv.conf changed, via the
  target of the symlink.
  
  Run sssctl again, and the online status will remain offline.
  
  With the fixed packages, the sssd startup log will say:
  (Mon May 18 17:17:06 2020) [sssd] [_snotify_create] (0x0400): Added a watch 
for /etc/resolv.conf.target with inotify flags 0x8D88 internal flags 0x1 using 
function resolv_conf_inotify_cb after delay 1.0
  
  Showing that it's monitoring the symlink target.
  
  And after fixing the broken symlink, it will say:
  (Mon May 18 17:18:06 2020) [sssd] [process_dir_event] (0x0400): received 
notification for watched file [resolv.conf.target] under /etc
  
  Run sssctl again, it should almost immediately switch to online:
  # sssctl domain-status LDAP
  Online status: Online
  
  Active servers:
  LDAP: ldap01.example.com
  
  Discovered LDAP servers:
  - ldap01.example.com
  
  b) polling test
  Repeat the previous test, but with "try_inotify = false" in sssd.conf, like 
this:
  # cat > /etc/sssd/sssd.conf 

[Bug 1723350] Re: sssd offline on boot, stays offline forever

[Andreas Hasenack]

** Changed in: sssd (Ubuntu Eoan)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1723350

Title:
  sssd offline on boot, stays offline forever

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1723350/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1723350] Re: sssd offline on boot, stays offline forever

[Andreas Hasenack]

** Description changed:

  [Impact]
  sssd can switch to an offline mode of operation when it cannot reach the 
authentication or id backend. It uses several methods to assess the situation, 
and one of them is monitoring the /etc/resolv.conf file for changes.
  
  In ubuntu that file is a symlink to /run/systemd/resolve/stub-
  resolv.conf, but the target doesn't exist at all times during boot. It's
  expected that symlink to be broken for a while during boot.
  
  Turns out that the monitoring that sssd was doing on /etc/resolv.conf
  didn't take into consideration that what could change was the *target*
  of the symlink. it completely ignored that fact, and didn't notice when
  the resolv.conf contents actually changed in this scenario, which
  resulted in sssd staying in the offline mode when it shouldn't.
  
  There are two fixes being pulled in for this SRU:
  a) fix the monitoring of the target of the /etc/resolv.conf symlink
  b) change the fallback polling code to keep trying, instead of giving up 
right away
  
  [Test Case]
  It's recommended to test this in a lxd container, or a vm.
  
  Preparation steps. When prompted for an openldap/slapd password, chose any 
password you want. It won't be needed again:
  $ sudo apt update && sudo apt dist-upgrade
  $ sudo apt install sssd-ldap sssd-tools sssd-dbus slapd dnsmasq
  
  Become root:
  $ sudo su -
  
  Detect your ip:
  # export interface=$(ip route | grep default | sed -r 's,^default via .* dev 
([a-z0-9]+) .*,\1,')
  # export ip=$(ip addr show dev $interface | grep "inet [0-9]" | awk '{print 
$2}' | cut -d / -f 1)
  
  Confirm the $ip variable is correct for your case:
  # echo $ip
  
  Create /etc/dnsmasq.d/sssd-test.conf using your real ip:
  # cat > /etc/dnsmasq.d/sssd-test.conf < /etc/sssd/sssd.conf  /etc/resolv.conf.good
  
  Confirm /etc/resolv.conf is a broken symlink:
  # ll /etc/resolv.conf*
  lrwxrwxrwx 1 root root 23 May 13 20:48 /etc/resolv.conf -> 
/etc/resolv.conf.target
  -rw-r--r-- 1 root root 24 May 13 20:48 /etc/resolv.conf.good
  
  Open another terminal/screen and tail the sssd logs with a grep:
  # tail -f /var/log/sssd/sssd.log | grep -i resolv
  
  Start sssd
  # systemctl restart sssd
  
  The tail output from that other terminal should say sssd is monitoring 
/etc/resolv.conf (that's the broken symlink):
  (Mon May 18 17:32:34 2020) [sssd] [_snotify_create] (0x0400): Added a watch 
for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using 
function resolv_conf_inotify_cb after delay 1.0
  
  Repeat this sssctl call until it shows the offline mode persistently:
  # sssctl domain-status LDAP
  Online status: Offline
  
  Active servers:
  LDAP: not connected
  
  Discovered LDAP servers:
  - ldap01.example.com
  
  "Unbreak" the symlink:
  # cp /etc/resolv.conf.good /etc/resolv.conf.target
  
  The log should now say:
  (Mon May 18 17:33:30 2020) [sssd] [process_dir_event] (0x0400): Not 
interested in resolv.conf.target
  
  This shows that sssd didn't pick up that resolv.conf changed, via the
  target of the symlink.
  
  Run sssctl again, and the online status will remain offline.
  
  With the fixed packages, the sssd startup log will say:
  (Mon May 18 17:17:06 2020) [sssd] [_snotify_create] (0x0400): Added a watch 
for /etc/resolv.conf.target with inotify flags 0x8D88 internal flags 0x1 using 
function resolv_conf_inotify_cb after delay 1.0
  
  Showing that it's monitoring the symlink target.
  
  And after fixing the broken symlink, it will say:
  (Mon May 18 17:18:06 2020) [sssd] [process_dir_event] (0x0400): received 
notification for watched file [resolv.conf.target] under /etc
  
  Run sssctl again, it should almost immediately switch to online:
  # sssctl domain-status LDAP
  Online status: Online
  
  Active servers:
  LDAP: ldap01.example.com
  
  Discovered LDAP servers:
  - ldap01.example.com
  
  b) polling test
  Repeat the previous test, but with "try_inotify = false" in sssd.conf, like 
this:
  # cat > /etc/sssd/sssd.conf 

[Bug 1723350] Re: sssd offline on boot, stays offline forever

[Andreas Hasenack]

** Description changed:

  [Impact]
  sssd can switch to an offline mode of operation when it cannot reach the 
authentication or id backend. It uses several methods to assess the situation, 
and one of them is monitoring the /etc/resolv.conf file for changes.
  
  In ubuntu that file is a symlink to /run/systemd/resolve/stub-
  resolv.conf, but the target doesn't exist at all times during boot. It's
  expected that symlink to be broken for a while during boot.
  
  Turns out that the monitoring that sssd was doing on /etc/resolv.conf
  didn't take into consideration that what could change was the *target*
  of the symlink. it completely ignored that fact, and didn't notice when
  the resolv.conf contents actually changed in this scenario, which
  resulted in sssd staying in the offline mode when it shouldn't.
  
  There are two fixes being pulled in for this SRU:
  a) fix the monitoring of the target of the /etc/resolv.conf symlink
  b) change the fallback polling code to keep trying, instead of giving up 
right away
  
  [Test Case]
  It's recommended to test this in a lxd container, or a vm.
  
  Preparation steps. When prompted for an openldap/slapd password, chose any 
password you want. It won't be needed again:
  $ sudo apt update && sudo apt dist-upgrade
  $ sudo apt install sssd-ldap sssd-tools sssd-dbus slapd dnsmasq
  
  Become root:
  $ sudo su -
  
  Detect your ip:
  # export interface=$(ip route | grep default | sed -r 's,^default via .* dev 
([a-z0-9]+) .*,\1,')
  # export ip=$(ip addr show dev $interface | grep "inet [0-9]" | awk '{print 
$2}' | cut -d / -f 1)
  
  Confirm the $ip variable is correct for your case:
  # echo $ip
  
  Create /etc/dnsmasq.d/sssd-test.conf using your real ip:
  # cat > /etc/dnsmasq.d/sssd-test.conf < /etc/sssd/sssd.conf  /etc/resolv.conf.good
  
  Confirm /etc/resolv.conf is a broken symlink:
  # ll /etc/resolv.conf*
  lrwxrwxrwx 1 root root 23 May 13 20:48 /etc/resolv.conf -> 
/etc/resolv.conf.target
  -rw-r--r-- 1 root root 24 May 13 20:48 /etc/resolv.conf.good
  
  Open another terminal/screen and tail the sssd logs with a grep:
- # tail -f /var/log/sssd/sssd.log | grep resolv
+ # tail -f /var/log/sssd/sssd.log | grep -i resolv
  
  Start sssd
  # systemctl restart sssd
  
  The tail output from that other terminal should say sssd is monitoring 
/etc/resolv.conf (that's the broken symlink):
  (Mon May 18 17:32:34 2020) [sssd] [_snotify_create] (0x0400): Added a watch 
for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using 
function resolv_conf_inotify_cb after delay 1.0
  
  Repeat this sssctl call until it shows the offline mode persistently:
  # sssctl domain-status LDAP
  Online status: Offline
  
  Active servers:
  LDAP: not connected
  
  Discovered LDAP servers:
  - ldap01.example.com
  
  "Unbreak" the symlink:
  # cp /etc/resolv.conf.good /etc/resolv.conf.target
  
  The log should now say:
  (Mon May 18 17:33:30 2020) [sssd] [process_dir_event] (0x0400): Not 
interested in resolv.conf.target
  
  This shows that sssd didn't pick up that resolv.conf changed, via the
  target of the symlink.
  
  Run sssctl again, and the online status will remain offline.
  
  With the fixed packages, the sssd startup log will say:
  (Mon May 18 17:17:06 2020) [sssd] [_snotify_create] (0x0400): Added a watch 
for /etc/resolv.conf.target with inotify flags 0x8D88 internal flags 0x1 using 
function resolv_conf_inotify_cb after delay 1.0
  
  Showing that it's monitoring the symlink target.
  
  And after fixing the broken symlink, it will say:
  (Mon May 18 17:18:06 2020) [sssd] [process_dir_event] (0x0400): received 
notification for watched file [resolv.conf.target] under /etc
  
  Run sssctl again, it should almost immediately switch to online:
  # sssctl domain-status LDAP
  Online status: Online
  
  Active servers:
  LDAP: ldap01.example.com
  
  Discovered LDAP servers:
  - ldap01.example.com
  
  b) polling test
  Repeat the previous test, but with "try_inotify = false" in sssd.conf, like 
this:
  # cat > /etc/sssd/sssd.conf 

[Bug 1723350] Re: sssd offline on boot, stays offline forever

[Andreas Hasenack]

** Description changed:

  [Impact]
  sssd can switch to an offline mode of operation when it cannot reach the 
authentication or id backend. It uses several methods to assess the situation, 
and one of them is monitoring the /etc/resolv.conf file for changes.
  
  In ubuntu that file is a symlink to /run/systemd/resolve/stub-
  resolv.conf, but the target doesn't exist at all times during boot. It's
  expected that symlink to be broken for a while during boot.
  
  Turns out that the monitoring that sssd was doing on /etc/resolv.conf
  didn't take into consideration that what could change was the *target*
  of the symlink. it completely ignored that fact, and didn't notice when
  the resolv.conf contents actually changed in this scenario, which
  resulted in sssd staying in the offline mode when it shouldn't.
  
  There are two fixes being pulled in for this SRU:
  a) fix the monitoring of the target of the /etc/resolv.conf symlink
  b) change the fallback polling code to keep trying, instead of giving up 
right away
  
  [Test Case]
  It's recommended to test this in a lxd container, or a vm.
  
- Preparation steps:
+ Preparation steps. When prompted for an openldap/slapd password, chose any 
password you want. It won't be needed again:
  $ sudo apt update && sudo apt dist-upgrade
  $ sudo apt install sssd-ldap sssd-tools sssd-dbus slapd dnsmasq
  
  Become root:
  $ sudo su -
  
  Detect your ip:
  # export interface=$(ip route | grep default | sed -r 's,^default via .* dev 
([a-z0-9]+) .*,\1,')
  # export ip=$(ip addr show dev $interface | grep "inet [0-9]" | awk '{print 
$2}' | cut -d / -f 1)
  
  Confirm the $ip variable is correct for your case:
  # echo $ip
  
  Create /etc/dnsmasq.d/sssd-test.conf using your real ip:
  # cat > /etc/dnsmasq.d/sssd-test.conf < /etc/sssd/sssd.conf  /etc/resolv.conf.good
  
  Confirm /etc/resolv.conf is a broken symlink:
  # ll /etc/resolv.conf*
  lrwxrwxrwx 1 root root 23 May 13 20:48 /etc/resolv.conf -> 
/etc/resolv.conf.target
  -rw-r--r-- 1 root root 24 May 13 20:48 /etc/resolv.conf.good
  
  Open another terminal/screen and tail the sssd logs with a grep:
  # tail -f /var/log/sssd/sssd.log | grep resolv
  
  Start sssd
  # systemctl restart sssd
  
  The tail output from that other terminal should say sssd is monitoring 
/etc/resolv.conf (that's the broken symlink):
  (Mon May 18 17:32:34 2020) [sssd] [_snotify_create] (0x0400): Added a watch 
for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using 
function resolv_conf_inotify_cb after delay 1.0
  
- 
  Repeat this sssctl call until it shows the offline mode persistently:
  # sssctl domain-status LDAP
  Online status: Offline
  
  Active servers:
  LDAP: not connected
  
  Discovered LDAP servers:
  - ldap01.example.com
  
  "Unbreak" the symlink:
  # cp /etc/resolv.conf.good /etc/resolv.conf.target
  
  The log should now say:
  (Mon May 18 17:33:30 2020) [sssd] [process_dir_event] (0x0400): Not 
interested in resolv.conf.target
  
  This shows that sssd didn't pick up that resolv.conf changed, via the
  target of the symlink.
  
  Run sssctl again, and the online status will remain offline.
  
- 
  With the fixed packages, the sssd startup log will say:
  (Mon May 18 17:17:06 2020) [sssd] [_snotify_create] (0x0400): Added a watch 
for /etc/resolv.conf.target with inotify flags 0x8D88 internal flags 0x1 using 
function resolv_conf_inotify_cb after delay 1.0
  
  Showing that it's monitoring the symlink target.
  
  And after fixing the broken symlink, it will say:
  (Mon May 18 17:18:06 2020) [sssd] [process_dir_event] (0x0400): received 
notification for watched file [resolv.conf.target] under /etc
  
  Run sssctl again, it should almost immediately switch to online:
  # sssctl domain-status LDAP
  Online status: Online
  
  Active servers:
  LDAP: ldap01.example.com
  
  Discovered LDAP servers:
  - ldap01.example.com
- 
  
  b) polling test
  Repeat the previous test, but with "try_inotify = false" in sssd.conf, like 
this:
  # cat > /etc/sssd/sssd.conf 

[Bug 1723350] Re: sssd offline on boot, stays offline forever

[Andreas Hasenack]

** Description changed:

  [Impact]
  sssd can switch to an offline mode of operation when it cannot reach the 
authentication or id backend. It uses several methods to assess the situation, 
and one of them is monitoring the /etc/resolv.conf file for changes.
  
  In ubuntu that file is a symlink to /run/systemd/resolve/stub-
  resolv.conf, but the target doesn't exist at all times during boot. It's
  expected that symlink to be broken for a while during boot.
  
  Turns out that the monitoring that sssd was doing on /etc/resolv.conf
  didn't take into consideration that what could change was the *target*
  of the symlink. it completely ignored that fact, and didn't notice when
  the resolv.conf contents actually changed in this scenario, which
  resulted in sssd staying in the offline mode when it shouldn't.
  
  There are two fixes being pulled in for this SRU:
  a) fix the monitoring of the target of the /etc/resolv.conf symlink
  b) change the fallback polling code to keep trying, instead of giving up 
right away
  
  [Test Case]
  It's recommended to test this in a lxd container, or a vm.
  
  Preparation steps:
  $ sudo apt update && sudo apt dist-upgrade
  $ sudo apt install sssd-ldap sssd-tools sssd-dbus slapd dnsmasq
  
  Become root:
  $ sudo su -
  
  Detect your ip:
  # export interface=$(ip route | grep default | sed -r 's,^default via .* dev 
([a-z0-9]+) .*,\1,')
  # export ip=$(ip addr show dev $interface | grep "inet [0-9]" | awk '{print 
$2}' | cut -d / -f 1)
  
  Confirm the $ip variable is correct for your case:
  # echo $ip
  
  Create /etc/dnsmasq.d/sssd-test.conf using your real ip:
  # cat > /etc/dnsmasq.d/sssd-test.conf < /etc/sssd/sssd.conf  /etc/resolv.conf.good
  
  Confirm /etc/resolv.conf is a broken symlink:
  # ll /etc/resolv.conf*
  lrwxrwxrwx 1 root root 23 May 13 20:48 /etc/resolv.conf -> 
/etc/resolv.conf.target
  -rw-r--r-- 1 root root 24 May 13 20:48 /etc/resolv.conf.good
  
  Open another terminal/screen and tail the sssd logs with a grep:
  # tail -f /var/log/sssd/sssd.log | grep resolv
  
  Start sssd
  # systemctl restart sssd
  
- Repeat the sssctl call until it shows the offline mode persistently:
+ The tail output from that other terminal should say sssd is monitoring 
/etc/resolv.conf (that's the broken symlink):
+ (Mon May 18 17:32:34 2020) [sssd] [_snotify_create] (0x0400): Added a watch 
for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using 
function resolv_conf_inotify_cb after delay 1.0
+ 
+ 
+ Repeat this sssctl call until it shows the offline mode persistently:
  # sssctl domain-status LDAP
  Online status: Offline
  
  Active servers:
  LDAP: not connected
  
  Discovered LDAP servers:
  - ldap01.example.com
  
  "Unbreak" the symlink:
  # cp /etc/resolv.conf.good /etc/resolv.conf.target
  
+ The log should now say:
+ (Mon May 18 17:33:30 2020) [sssd] [process_dir_event] (0x0400): Not 
interested in resolv.conf.target
+ 
+ This shows that sssd didn't pick up that resolv.conf changed, via the
+ target of the symlink.
+ 
+ Run sssctl again, and the online status will remain offline.
+ 
+ 
+ With the fixed packages, the sssd startup log will say:
+ (Mon May 18 17:17:06 2020) [sssd] [_snotify_create] (0x0400): Added a watch 
for /etc/resolv.conf.target with inotify flags 0x8D88 internal flags 0x1 using 
function resolv_conf_inotify_cb after delay 1.0
+ 
+ Showing that it's monitoring the symlink target.
+ 
+ And after fixing the broken symlink, it will say:
+ (Mon May 18 17:18:06 2020) [sssd] [process_dir_event] (0x0400): received 
notification for watched file [resolv.conf.target] under /etc
+ 
  Run sssctl again, it should almost immediately switch to online:
  # sssctl domain-status LDAP
  Online status: Online
  
  Active servers:
  LDAP: ldap01.example.com
  
  Discovered LDAP servers:
  - ldap01.example.com
  
- For the above steps, the log file being tailed will show this for the startup 
of sssd:
- (Mon May 18 17:17:06 2020) [sssd] [_snotify_create] (0x0400): Added a watch 
for /etc/resolv.conf.target with inotify flags 0x8D88 internal flags 0x1 using 
function resolv_conf_inotify_cb after delay 1.0
- 
- And this for when the symlink is fixed:
- (Mon May 18 17:18:06 2020) [sssd] [process_dir_event] (0x0400): received 
notification for watched file [resolv.conf.target] under /etc
  
  b) polling test
  Repeat the previous test, but with "try_inotify = false" in sssd.conf, like 
this:
  # cat > /etc/sssd/sssd.conf 

[Bug 1723350] Re: sssd offline on boot, stays offline forever

[Andreas Hasenack]

** Description changed:

  [Impact]
  sssd can switch to an offline mode of operation when it cannot reach the 
authentication or id backend. It uses several methods to assess the situation, 
and one of them is monitoring the /etc/resolv.conf file for changes.
  
  In ubuntu that file is a symlink to /run/systemd/resolve/stub-
  resolv.conf, but the target doesn't exist at all times during boot. It's
  expected that symlink to be broken for a while during boot.
  
  Turns out that the monitoring that sssd was doing on /etc/resolv.conf
  didn't take into consideration that what could change was the *target*
  of the symlink. it completely ignored that fact, and didn't notice when
  the resolv.conf contents actually changed in this scenario, which
  resulted in sssd staying in the offline mode when it shouldn't.
  
  There are two fixes being pulled in for this SRU:
  a) fix the monitoring of the target of the /etc/resolv.conf symlink
  b) change the fallback polling code to keep trying, instead of giving up 
right away
  
  [Test Case]
  It's recommended to test this in a lxd container, or a vm.
  
  Preparation steps:
  $ sudo apt install sssd-ldap sssd-tools sssd-dbus slapd dnsmasq
  
  Become root:
  $ sudo su -
  
  Detect your ip:
  # export interface=$(ip route | grep default | sed -r 's,^default via .* dev 
([a-z0-9]+) .*,\1,')
  # export ip=$(ip addr show dev $interface | grep "inet [0-9]" | awk '{print 
$2}' | cut -d / -f 1)
  
  Confirm the $ip variable is correct for your case:
  # echo $ip
  
  Create /etc/dnsmasq.d/sssd-test.conf using your real ip:
  # cat > /etc/dnsmasq.d/sssd-test.conf < /etc/sssd/sssd.conf  /etc/resolv.conf.good
  
  Confirm /etc/resolv.conf is a broken symlink:
  # ll /etc/resolv.conf*
  lrwxrwxrwx 1 root root 23 May 13 20:48 /etc/resolv.conf -> 
/etc/resolv.conf.target
  -rw-r--r-- 1 root root 24 May 13 20:48 /etc/resolv.conf.good
+ 
+ Open another terminal/screen and tail the sssd logs with a grep:
+ # tail -f /var/log/sssd/sssd.log | grep resolv
  
  Start sssd
  # systemctl restart sssd
  
  Repeat the sssctl call until it shows the offline mode persistently:
  # sssctl domain-status LDAP
  Online status: Offline
  
  Active servers:
  LDAP: not connected
  
  Discovered LDAP servers:
  - ldap01.example.com
  
  "Unbreak" the symlink:
  # cp /etc/resolv.conf.good /etc/resolv.conf.target
  
  Run sssctl again, it should almost immediately switch to online:
  # sssctl domain-status LDAP
  Online status: Online
  
  Active servers:
  LDAP: ldap01.example.com
  
  Discovered LDAP servers:
  - ldap01.example.com
  
  b) polling test
  Repeat the previous test, but with "try_inotify = false" in sssd.conf, like 
this:
  # cat > /etc/sssd/sssd.conf 

[Bug 1723350] Re: sssd offline on boot, stays offline forever

[Andreas Hasenack]

** Description changed:

  [Impact]
  sssd can switch to an offline mode of operation when it cannot reach the 
authentication or id backend. It uses several methods to assess the situation, 
and one of them is monitoring the /etc/resolv.conf file for changes.
  
  In ubuntu that file is a symlink to /run/systemd/resolve/stub-
  resolv.conf, but the target doesn't exist at all times during boot. It's
  expected that symlink to be broken for a while during boot.
  
  Turns out that the monitoring that sssd was doing on /etc/resolv.conf
  didn't take into consideration that what could change was the *target*
  of the symlink. it completely ignored that fact, and didn't notice when
  the resolv.conf contents actually changed in this scenario, which
  resulted in sssd staying in the offline mode when it shouldn't.
  
  There are two fixes being pulled in for this SRU:
  a) fix the monitoring of the target of the /etc/resolv.conf symlink
  b) change the fallback polling code to keep trying, instead of giving up 
right away
  
  [Test Case]
  It's recommended to test this in a lxd container, or a vm.
  
  Preparation steps:
- $ sudo apt install sssd-ldap sssd-tools sssd-dbus slapd ldap-utils dnsmasq
+ $ sudo apt install sssd-ldap sssd-tools sssd-dbus slapd dnsmasq
  
  Become root:
  $ sudo su -
  
  Detect your ip:
  # export interface=$(ip route | grep default | sed -r 's,^default via .* dev 
([a-z0-9]+) .*,\1,')
  # export ip=$(ip addr show dev $interface | grep "inet [0-9]" | awk '{print 
$2}' | cut -d / -f 1)
  
  Confirm the $ip variable is correct for your case:
  # echo $ip
  
  Create /etc/dnsmasq.d/sssd-test.conf using your real ip:
  # cat > /etc/dnsmasq.d/sssd-test.conf < /etc/sssd/sssd.conf  /etc/resolv.conf.good
  
  Confirm /etc/resolv.conf is a broken symlink:
  # ll /etc/resolv.conf*
  lrwxrwxrwx 1 root root 23 May 13 20:48 /etc/resolv.conf -> 
/etc/resolv.conf.target
  -rw-r--r-- 1 root root 24 May 13 20:48 /etc/resolv.conf.good
  
  Start sssd
  # systemctl restart sssd
  
  Repeat the sssctl call until it shows the offline mode persistently:
  # sssctl domain-status LDAP
  Online status: Offline
  
  Active servers:
  LDAP: not connected
  
  Discovered LDAP servers:
  - ldap01.example.com
  
  "Unbreak" the symlink:
  # cp /etc/resolv.conf.good /etc/resolv.conf.target
  
  Run sssctl again, it should almost immediately switch to online:
  # sssctl domain-status LDAP
  Online status: Online
  
  Active servers:
  LDAP: ldap01.example.com
  
  Discovered LDAP servers:
  - ldap01.example.com
  
  b) polling test
  Repeat the previous test, but with "try_inotify = false" in sssd.conf, like 
this:
  # cat > /etc/sssd/sssd.conf 

[Bug 1723350] Re: sssd offline on boot, stays offline forever

[Andreas Hasenack]

** Description changed:

  [Impact]
  sssd can switch to an offline mode of operation when it cannot reach the 
authentication or id backend. It uses several methods to assess the situation, 
and one of them is monitoring the /etc/resolv.conf file for changes.
  
  In ubuntu that file is a symlink to /run/systemd/resolve/stub-
  resolv.conf, but the target doesn't exist at all times during boot. It's
  expected that symlink to be broken for a while during boot.
  
  Turns out that the monitoring that sssd was doing on /etc/resolv.conf
  didn't take into consideration that what could change was the *target*
  of the symlink. it completely ignored that fact, and didn't notice when
  the resolv.conf contents actually changed in this scenario, which
  resulted in sssd staying in the offline mode when it shouldn't.
  
  There are two fixes being pulled in for this SRU:
  a) fix the monitoring of the target of the /etc/resolv.conf symlink
  b) change the fallback polling code to keep trying, instead of giving up 
right away
  
  [Test Case]
  It's recommended to test this in a lxd container, or a vm.
  
  Preparation steps:
  $ sudo apt install sssd-ldap sssd-tools sssd-dbus slapd ldap-utils dnsmasq
  
  Become root:
  $ sudo su -
  
  Detect your ip:
  # export interface=$(ip route | grep default | sed -r 's,^default via .* dev 
([a-z0-9]+) .*,\1,')
  # export ip=$(ip addr show dev $interface | grep "inet [0-9]" | awk '{print 
$2}' | cut -d / -f 1)
  
  Confirm the $ip variable is correct for your case:
  # echo $ip
  
  Create /etc/dnsmasq.d/sssd-test.conf using your real ip:
  # cat > /etc/dnsmasq.d/sssd-test.conf < /etc/sssd/sssd.conf  /etc/resolv.conf.good
  
  Confirm /etc/resolv.conf is a broken symlink:
  # ll /etc/resolv.conf*
  lrwxrwxrwx 1 root root 23 May 13 20:48 /etc/resolv.conf -> 
/etc/resolv.conf.target
  -rw-r--r-- 1 root root 24 May 13 20:48 /etc/resolv.conf.good
  
  Start sssd
  # systemctl restart sssd
  
  Repeat the sssctl call until it shows the offline mode persistently:
  # sssctl domain-status LDAP
  Online status: Offline
  
  Active servers:
  LDAP: not connected
  
  Discovered LDAP servers:
  - ldap01.example.com
  
  "Unbreak" the symlink:
  # cp /etc/resolv.conf.good /etc/resolv.conf.target
  
  Run sssctl again, it should almost immediately switch to online:
  # sssctl domain-status LDAP
  Online status: Online
  
  Active servers:
  LDAP: ldap01.example.com
  
  Discovered LDAP servers:
  - ldap01.example.com
  
+ b) polling test
+ Repeat the previous test, but with "try_inotify = false" in sssd.conf, like 
this:
+ # cat > /etc/sssd/sssd.conf 

[Bug 1872476] Re: Shared files are shown as folders

[Andreas Hasenack]

This is fixed in 4.12.2 uploaded to groovy, so marking that task as fix
released.

** Changed in: samba (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1872476

Title:
  Shared files are shown as folders

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1872476/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1875354] Re: No more smb access after migration to UBUNTU 20.04 from UBUNTU 19.10

[Andreas Hasenack]

Mustapa, about files being shown as directories, you are probably being
affected by bug
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1872476 which is an
in-progress SRU and has a fix uploaded to focal-proposed already.

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/1875354

Title:
  No more smb access after migration to UBUNTU 20.04 from UBUNTU 19.10

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1875354/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

autopackage tests are also green: https://people.canonical.com/~ubuntu-
archive/proposed-migration/focal/update_excuses.html#python-certbot-
nginx

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875471

Title:
  python3-certbot-nginx is incompatible with its dependencies

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-certbot-nginx/+bug/1875471/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

Checks (a), (b), (c), (d) passed, plus the comments from others who
installed the package on their servers or test rigs. Marking the
verification as succeeded.


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

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875471

Title:
  python3-certbot-nginx is incompatible with its dependencies

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-certbot-nginx/+bug/1875471/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

a) Run https://wiki.ubuntu.com/StableReleaseUpdates/Certbot/TestScript.
Full output attached.

Package from proposed is installed:
 *** 0.40.0-0ubuntu0.1 500
500 http://br.archive.ubuntu.com/ubuntu focal-proposed/universe amd64 
Packages
100 /var/lib/dpkg/status
 0.39.0-1 500
500 http://br.archive.ubuntu.com/ubuntu focal/universe amd64 Packages

Script being run with CERTBOT_PREINSTALLED=1 because not all certbot
packages were updated in this SRU

(...)
testing roundcube-1222.conf...passed
testing section-continuations-2525.conf...passed
testing section-empty-continuations-2731.conf...passed
testing semacode-1598.conf...passed
testing two-blocks-one-line-1693.conf...passed
Success!
Package versions tested:
certbot 0.40.0-1
letsencrypt
python3-acme1.1.0-1
python3-certbot 0.40.0-1
python3-certbot-apache  0.39.0-1
python3-certbot-nginx   0.40.0-0ubuntu0.1
python3-josepy  1.2.0-2

real4m23.223s



** Attachment added: "sru-1875471-test-a-log.txt"
   
https://bugs.launchpad.net/ubuntu/+source/python-certbot-nginx/+bug/1875471/+attachment/5371730/+files/sru-1875471-test-a-log.txt

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875471

Title:
  python3-certbot-nginx is incompatible with its dependencies

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-certbot-nginx/+bug/1875471/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

Focal verification tests (b), (c) and (d) below:
a) Running script from 
https://wiki.ubuntu.com/StableReleaseUpdates/Certbot/TestScript

b) Request a registration with nginx
sudo certbot -d certbot-test.justgohome.co.uk --agree-tos --staging 
--register-unsafely-without-email --nginx

python3-certbot-nginx from proposed:
  Version table:
 *** 0.40.0-0ubuntu0.1 500
500 http://ports.ubuntu.com/ubuntu-ports focal-proposed/universe 
ppc64el Packages
100 /var/lib/dpkg/status
 0.39.0-1 500
500 http://ports.ubuntu.com/ubuntu-ports focal/universe ppc64el Packages

ubuntu@certbot-test:~$ sudo certbot -d certbot-test.justgohome.co.uk 
--agree-tos --staging --register-unsafely-without-email --nginx
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Registering without email!
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for certbot-test.justgohome.co.uk
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/default

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP 
access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/default

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled
https://certbot-test.justgohome.co.uk

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=certbot-test.justgohome.co.uk
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/certbot-test.justgohome.co.uk/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/certbot-test.justgohome.co.uk/privkey.pem
   Your cert will expire on 2020-08-12. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.


c) Request a registration using apache
sudo certbot -d certbot-test.justgohome.co.uk --agree-tos --staging 
--register-unsafely-without-email --apache

python3-certbot-apache from release:
  Version table:
 *** 0.39.0-1 500
500 http://ports.ubuntu.com/ubuntu-ports focal/universe ppc64el Packages
100 /var/lib/dpkg/status

ubuntu@certbot-test:~$ sudo certbot -d certbot-test.justgohome.co.uk 
--agree-tos --staging --register-unsafely-without-email --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Registering without email!
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for certbot-test.justgohome.co.uk
Enabled Apache rewrite module
Waiting for verification...
Cleaning up challenges
Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf
Enabled Apache socache_shmcb module
Enabled Apache ssl module
Deploying Certificate to VirtualHost 
/etc/apache2/sites-available/000-default-le-ssl.conf
Enabling available site: /etc/apache2/sites-available/000-default-le-ssl.conf

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP 
access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Enabled Apache rewrite module
Redirecting vhost in /etc/apache2/sites-enabled/000-default.conf to ssl vhost 
in /etc/apache2/sites-available/000-default-le-ssl.conf

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled

[Bug 1723350] Re: sssd offline on boot, stays offline forever

[Andreas Hasenack]

** Description changed:

+ [Impact] 
+ sssd can switch to an offline mode of operation when it cannot reach the 
authentication or id backend. It uses several methods to assess the situation, 
and one of them is monitoring the /etc/resolv.conf file for changes.
+ 
+ In ubuntu that file is a symlink to /run/systemd/resolve/stub-
+ resolv.conf, but the target doesn't exist at all times during boot. It's
+ expected that symlink to be broken for a while during boot.
+ 
+ Turns out that the monitoring that sssd was doing on /etc/resolv.conf
+ didn't take into consideration that what could change was the *target*
+ of the symlink. it completely ignored that fact, and didn't notice when
+ the resolv.conf contents actually changed in this scenario, which
+ resulted in sssd staying in the offline mode when it shouldn't.
+ 
+ There are two fixes being pulled in for this SRU:
+ a) fix the monitoring of the target of the /etc/resolv.conf symlink
+ b) change the fallback polling code to keep trying, instead of giving up 
right away
+ 
+ [Test Case]
+ It's recommended to test this in a lxd container, or a vm.
+ 
+ Preparation steps:
+ $ sudo apt install sssd-ldap sssd-tools sssd-dbus slapd ldap-utils dnsmasq
+ 
+ Become root:
+ $ sudo su -
+ 
+ Detect your ip:
+ # export interface=$(ip route | grep default | sed -r 's,^default via .* dev 
([a-z0-9]+) .*,\1,')
+ # export ip=$(ip addr show dev $interface | grep "inet [0-9]" | awk '{print 
$2}' | cut -d / -f 1)
+ 
+ Confirm the $ip variable is correct for your case:
+ # echo $ip
+ 
+ Create /etc/dnsmasq.d/sssd-test.conf using your real ip:
+ # cat > /etc/dnsmasq.d/sssd-test.conf < /etc/sssd/sssd.conf  /etc/resolv.conf.good
+ 
+ Confirm /etc/resolv.conf is a broken symlink:
+ # ll /etc/resolv.conf*
+ lrwxrwxrwx 1 root root 23 May 13 20:48 /etc/resolv.conf -> 
/etc/resolv.conf.target
+ -rw-r--r-- 1 root root 24 May 13 20:48 /etc/resolv.conf.good
+ 
+ Start sssd
+ # systemctl restart sssd
+ 
+ Repeat the sssctl call until it shows the offline mode persistently:
+ # sssctl domain-status LDAP
+ Online status: Offline
+ 
+ Active servers:
+ LDAP: not connected
+ 
+ Discovered LDAP servers:
+ - ldap01.example.com
+ 
+ "Unbreak" the symlink:
+ # cp /etc/resolv.conf.good /etc/resolv.conf.target
+ 
+ Run sssctl again, it should almost immediately switch to online:
+ # sssctl domain-status LDAP
+ Online status: Online
+ 
+ Active servers:
+ LDAP: ldap01.example.com
+ 
+ Discovered LDAP servers:
+ - ldap01.example.com
+ 
+ 
+ [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]
+ 
  SSSD 1.15.3-2ubuntu1 on 17.10/artful (previous versions on artful were
  also affected) is offline on boot and seems to stay offline forever (I
  waited over 20 minutes).
  
  sssd_nss.log:
  (Fri Oct 13 09:49:50 2017) [sssd[nss]] [sss_dp_get_reply] (0x0010): The Data 
Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline]
  (Fri Oct 13 09:49:51 2017) [sssd[nss]] [sss_dp_get_reply] (0x0010): The Data 
Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline]
  (Fri Oct 13 09:49:51 2017) [sssd[nss]] [sss_dp_get_reply] (0x0010): The Data 
Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline]
  (Fri Oct 13 09:49:51 2017) [sssd[nss]] [sss_dp_get_reply] (0x0010): The Data 
Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline]
  ...
  
  SSSD immediately returns to normal operation after restarting it or
  after sending SIGUSR2.
  
  A workaround for the problem is creating the file 
/etc/systemd/system/sssd.service.d/override.conf with contents
  [Unit]
  Requires=network-online.target
  After=network-online.target

** Description changed:

- [Impact] 
+ [Impact]
  sssd can switch to an offline mode of operation when it cannot reach the 
authentication or id backend. It uses several methods to assess the situation, 
and one of them is monitoring the /etc/resolv.conf file for changes.
  
  In ubuntu that file is a symlink to /run/systemd/resolve/stub-
  resolv.conf, but the 

[Bug 1723350] Re: sssd offline on boot, stays offline forever

[Andreas Hasenack]

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

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

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1723350

Title:
  sssd offline on boot, stays offline forever

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1723350/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[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
Server, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/495418

Title:
  Enable GSSAPI support (for likewise-open)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/495418/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

Re: Ubuntu 20.04 performance

[Andreas Hasenack]

I've seen this slugginesh too, but half expected it, since there is a lot
of overhead in that connection through the GUI. Was this better in previous
ubuntu releases?

On Wed, May 13, 2020 at 12:20 PM Leroy Tennison 
wrote:

> Thanks for getting back to me.  When I log into the console using
> virt-manager and use vi to edit .bashrc it takes a second or two to load
> and cursor movement had a slight but detectable delay.  When I connect
> using ssh the response is almost immediate (as it is with virsh console).
> I actually installed the VM from the downloaded iso and that response in
> virt-manager was far worse.
>
> --
> *From:* ubuntu-server  on behalf
> of Andreas Hasenack 
> *Sent:* Wednesday, May 13, 2020 9:57 AM
> *Cc:* ubuntu-server 
> *Subject:* [EXTERNAL] Re: Ubuntu 20.04 performance
>
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
> Do you mean the vm is sluggish, or the virt-manager tool?
>
> Harriscomputer
>
>
> *Leroy Tennison*Network Information/Cyber Security Specialist
> E: le...@datavoiceint.com
>
>
> 2220 Bush Dr
> McKinney, Texas
> 75070
> www.datavoiceint.com <http://www..com>
>
> This message has been sent on behalf of a company that is part of the
> Harris Operating Group of Constellation Software Inc.
>
> If you prefer not to be contacted by Harris Operating Group please notify
> us <http://subscribe.harriscomputer.com/>.
>
>
>
> This message is intended exclusively for the individual or entity to which
> it is addressed. This communication may contain information that is
> proprietary, privileged or confidential or otherwise legally exempt from
> disclosure. If you are not the named addressee, you are not authorized to
> read, print, retain, copy or disseminate this message or any part of it. If
> you have received this message in error, please notify the sender
> immediately by e-mail and delete all copies of the message.
>
>
> On Wed, May 13, 2020 at 11:52 AM Leroy Tennison 
> wrote:
>
> I realize it's "just released" but have noticed something which is almost
> impossible to document in a bug report.  Performance using virt-manager is
> sluggish at best whereas there are no apparent issues via an ssh
> connection.  Might want to see if you can reproduce that.  This is a server
> install (no GUI) and I have allocated only 1 CPU but the fact that
> ssh-based performance is fine indicates a possible problem.  I should also
> mention that the problem does not occur with virsh console.
>
> Harriscomputer
>
>
> *Leroy Tennison *Network Information/Cyber Security Specialist
> E: le...@datavoiceint.com
>
>
> 2220 Bush Dr
> McKinney, Texas
> 75070
> www.datavoiceint.com <http://www..com>
>
> This message has been sent on behalf of a company that is part of the
> Harris Operating Group of Constellation Software Inc.
>
> If you prefer not to be contacted by Harris Operating Group please notify
> us
> <https://linkprotect.cudasvc.com/url?a=http%3a%2f%2fsubscribe.harriscomputer.com%2f=E,1,UxBMDc39042EcDjXfzP_bv_VfPkhvS9EYOuzpjVq6Af38kexy6N175WQmWj0rHGu5_Q8qJmrKOMAZYUx8YCle2TO4-psMn1_JWAv7jP1PcGUcFAfAAAMXQ,,=1>.
>
>
>
>
> This message is intended exclusively for the individual or entity to which
> it is addressed. This communication may contain information that is
> proprietary, privileged or confidential or otherwise legally exempt from
> disclosure. If you are not the named addressee, you are not authorized to
> read, print, retain, copy or disseminate this message or any part of it. If
> you have received this message in error, please notify the sender
> immediately by e-mail and delete all copies of the message.
>
>
> --
> ubuntu-server mailing list
> ubuntu-server@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
> More info: https://wiki.ubuntu.com/ServerTeam
>
>
-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

Re: Ubuntu 20.04 performance

[Andreas Hasenack]

Do you mean the vm is sluggish, or the virt-manager tool?

On Wed, May 13, 2020 at 11:52 AM Leroy Tennison 
wrote:

> I realize it's "just released" but have noticed something which is almost
> impossible to document in a bug report.  Performance using virt-manager is
> sluggish at best whereas there are no apparent issues via an ssh
> connection.  Might want to see if you can reproduce that.  This is a server
> install (no GUI) and I have allocated only 1 CPU but the fact that
> ssh-based performance is fine indicates a possible problem.  I should also
> mention that the problem does not occur with virsh console.
>
> Harriscomputer
>
>
> *Leroy Tennison*Network Information/Cyber Security Specialist
> E: le...@datavoiceint.com
>
>
> 2220 Bush Dr
> McKinney, Texas
> 75070
> www.datavoiceint.com 
>
> This message has been sent on behalf of a company that is part of the
> Harris Operating Group of Constellation Software Inc.
>
> If you prefer not to be contacted by Harris Operating Group please notify
> us .
>
>
>
> This message is intended exclusively for the individual or entity to which
> it is addressed. This communication may contain information that is
> proprietary, privileged or confidential or otherwise legally exempt from
> disclosure. If you are not the named addressee, you are not authorized to
> read, print, retain, copy or disseminate this message or any part of it. If
> you have received this message in error, please notify the sender
> immediately by e-mail and delete all copies of the message.
>
>
> --
> ubuntu-server mailing list
> ubuntu-server@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
> More info: https://wiki.ubuntu.com/ServerTeam
-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

[Bug 1723350] Re: sssd offline on boot, stays offline forever

[Andreas Hasenack]

Just tested and eoan is affected, focal is clear.

** Also affects: sssd (Ubuntu Eoan)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1723350

Title:
  sssd offline on boot, stays offline forever

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1723350/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1723350] Re: sssd offline on boot, stays offline forever

[Andreas Hasenack]

Ok, I have a simple way to reproduce this, and was able to test the
upstream patch. I'll polish it up and put it up for review, then prepare
the SRU paperwork.

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1723350

Title:
  sssd offline on boot, stays offline forever

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1723350/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1723350] Re: sssd offline on boot, stays offline forever

[Andreas Hasenack]

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

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

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1723350

Title:
  sssd offline on boot, stays offline forever

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1723350/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1872476] Re: Shared files are shown as folders

[Andreas Hasenack]

For the SRU team reviewing this, I can confirm the bug is fixed in samba
4.12.2 which I will upload to groovy shortly:

root@groovy-samba-file-folder:~# gio info smb://127.0.0.1/testshare/123.txt | 
grep '^type:'
type: regular
root@groovy-samba-file-folder:~# apt-cache policy samba
samba:
  Installed: 2:4.12.2+dfsg-0ubuntu1~ppa2
  Candidate: 2:4.12.2+dfsg-0ubuntu1~ppa2
  Version table:
 *** 2:4.12.2+dfsg-0ubuntu1~ppa2 500
500 http://ppa.launchpad.net/ahasenack/samba-4122/ubuntu groovy/main 
amd64 Packages
100 /var/lib/dpkg/status
 2:4.11.6+dfsg-0ubuntu1.1 500
500 http://archive.ubuntu.com/ubuntu groovy/main amd64 Packages

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1872476

Title:
  Shared files are shown as folders

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1872476/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1827041] Re: Regression in smbclient, username required for anonymous login

[Andreas Hasenack]

No, comment #8 shows disco is already fixed. This may be SRU material
for Bionic.

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1827041

Title:
  Regression in smbclient, username required for anonymous login

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1827041/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

Fwd: [Samba] sambaXP 2020 - Online Edition - FOR FREE!

[Andreas Hasenack]

FYI

-- Forwarded message -
From: Karolin Seeger via samba 
Date: Mon, May 11, 2020 at 8:47 AM
Subject: [Samba] sambaXP 2020 - Online Edition - FOR FREE!
To: , 


SambaXP 2020 - Online Edition

The 19th International Conference for the open source software Samba
will take place from 26th - 28th May 2020 as an *free* online event. The
planned IO-Lab is cancelled.

SambaXP is the annual meeting of the international Samba team with
developers, users, manufacturers and system integrators within the Samba
ecosystem, which has been held since 2002.
Due to the current COVID-19 situation and the associated travel and
meeting restrictions, this year's conference unfortunately cannot take
place at the usual venue in Göttingen. Therefore the organizing
committee is planning a digital edition of the popular conference for
this year.

The speakers will give their presentations live from their desks, so
that participants can follow the conference from anywhere in the world
via the Internet. Compared to the usual event format, the online event
offers even more flexibility: It is easier to switch between tracks
running in parallel or even follow two presentations at the same time.
The event is recorded with consent of the speakers and will be available
online after the conference.

The traditional tutorial by Stefan Kania will also be held as a webinar
on the day before the conference (Tuesday, 25 May 2020). This year's
topic: "Clustering with CTDB".

The IO-Lab, which is planned for the first time in the context of this
year's SambaXP unfortunately cannot take place due to the current
circumstances.

You can find all the latest information and the registration form at
https://sambaxp.org.
The organizing committee is available for questions at l...@sambaxp.org.

We are looking forward to a digital SambaXP 2020 and would like to thank
the sponsors Google and Microsoft.

Stay healthy!

Cheers,
Karolin

--
Karolin Seeger  https://samba.org/~kseeger/
Release Manager Samba Team  https://samba.org
Team Lead Samba SerNet  https://sernet.de

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

[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
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875697

Title:
  drop fix-ldap-distribution.patch?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1875697/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[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
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875697

Title:
  drop fix-ldap-distribution.patch?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1875697/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[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
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875697

Title:
  drop fix-ldap-distribution.patch?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1875697/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[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
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875697

Title:
  drop fix-ldap-distribution.patch?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1875697/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1872454] Re: Enable timemachine support

[Andreas Hasenack]

Debian tried it, and disabled this support again because it pulled in
too many dependencies: https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=941654

Samba 4.12.x has another spotlight backend, elastic search:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941654

I'm not a macos user so I'm not sure how these are used or which one is
best. I'll rely on the community to chime in here.


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

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1872454

Title:
  Enable timemachine support

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1872454/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1877623] [NEW] ftbfs s390x, riscv

[Andreas Hasenack]

Public bug reported:

https://launchpad.net/ubuntu/+source/memcached/1.6.5-2/

build log (warning: over 10Mb):
https://launchpad.net/ubuntu/+source/memcached/1.6.5-2/+build/19216634/+files
/buildlog_ubuntu-groovy-s390x.memcached_1.6.5-2_BUILDING.txt.gz

On s390x:

Test Summary Report
---
t/binary-extstore.t   (Wstat: 65280 Tests: 8290 Failed: 1)
  Failed test:  8286
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/chunked-extstore.t  (Wstat: 65024 Tests: 413 Failed: 346)
  Failed tests:  2, 48-87, 94, 100, 104, 106, 112-361, 363-413
  Non-zero exit status: 254
t/extstore.t  (Wstat: 1024 Tests: 26 Failed: 4)
  Failed tests:  4, 13-14, 16
  Non-zero exit status: 4
Files=77, Tests=72502, 365 wallclock secs ( 5.94 usr  0.52 sys + 13.27 cusr  
4.42 csys = 24.15 CPU)
Result: FAIL
make[1]: *** [Makefile:2220: test] Error 1

On riscv:
Test Summary Report
---
t/chunked-extstore.t  (Wstat: 2304 Tests: 413 Failed: 9)
  Failed tests:  131-133, 187-189, 243-245
  Non-zero exit status: 9
t/restart.t   (Wstat: 512 Tests: 1 Failed: 0)
  Non-zero exit status: 2
  Parse errors: No plan found in TAP output
Files=77, Tests=103639, 1959 wallclock secs (221.09 usr 32.88 sys + 562.72 cusr 
245.87 csys = 1062.56 CPU)
Result: FAIL

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


** Tags: ftbfs

** Description changed:

  https://launchpad.net/ubuntu/+source/memcached/1.6.5-2/
  
  build log (warning: over 10Mb):
  https://launchpad.net/ubuntu/+source/memcached/1.6.5-2/+build/19216634/+files
  /buildlog_ubuntu-groovy-s390x.memcached_1.6.5-2_BUILDING.txt.gz
  
+ On s390x:
  
  Test Summary Report
  ---
  t/binary-extstore.t   (Wstat: 65280 Tests: 8290 Failed: 1)
-   Failed test:  8286
-   Non-zero exit status: 255
-   Parse errors: No plan found in TAP output
+   Failed test:  8286
+   Non-zero exit status: 255
+   Parse errors: No plan found in TAP output
  t/chunked-extstore.t  (Wstat: 65024 Tests: 413 Failed: 346)
-   Failed tests:  2, 48-87, 94, 100, 104, 106, 112-361, 363-413
-   Non-zero exit status: 254
+   Failed tests:  2, 48-87, 94, 100, 104, 106, 112-361, 363-413
+   Non-zero exit status: 254
  t/extstore.t  (Wstat: 1024 Tests: 26 Failed: 4)
-   Failed tests:  4, 13-14, 16
-   Non-zero exit status: 4
+   Failed tests:  4, 13-14, 16
+   Non-zero exit status: 4
  Files=77, Tests=72502, 365 wallclock secs ( 5.94 usr  0.52 sys + 13.27 cusr  
4.42 csys = 24.15 CPU)
  Result: FAIL
  make[1]: *** [Makefile:2220: test] Error 1
+ 
+ On riscv:
+ Test Summary Report
+ ---
+ t/chunked-extstore.t  (Wstat: 2304 Tests: 413 Failed: 9)
+   Failed tests:  131-133, 187-189, 243-245
+   Non-zero exit status: 9
+ t/restart.t   (Wstat: 512 Tests: 1 Failed: 0)
+   Non-zero exit status: 2
+   Parse errors: No plan found in TAP output
+ Files=77, Tests=103639, 1959 wallclock secs (221.09 usr 32.88 sys + 562.72 
cusr 245.87 csys = 1062.56 CPU)
+ Result: FAIL

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to memcached in Ubuntu.
https://bugs.launchpad.net/bugs/1877623

Title:
  ftbfs s390x, riscv

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/memcached/+bug/1877623/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

Uploaded, waiting for SRU team.

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875471

Title:
  python3-certbot-nginx is incompatible with its dependencies

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-certbot-nginx/+bug/1875471/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1557157] Re: apparmor profile denied for saslauthd: /run/saslauthd/mux

[Andreas Hasenack]

** Tags added: bitesize

** Tags added: server-next

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

Title:
  apparmor profile denied for saslauthd: /run/saslauthd/mux

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557157/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

** Description changed:

  This bug tracks an update for python-certbot from 0.39.0 to 0.40.0.
  
  This update includes bugfixes only following the SRU policy exception
  defined at https://wiki.ubuntu.com/StableReleaseUpdates/Certbot.
  
  [Impact]
  
  Reguesting a certificate via the nginx plugin fails:
  
  AttributeError: module 'acme.challenges' has no attribute 'TLSSNI01'
  
  The problem here is python-certbot-nginx contains references to code in
  python-acme that has been removed. This problem makes python-certbot-
  nginx completely unable to obtain certificates.
  
  [Major Changes]
  
  To fix the problem, python-certbot-nginx is being updated from 0.39.0 to
  0.40.0. The diff[1] is small and is about removing TLSSNI01 support.
  
  It was also noticed that the build-time tests were never run due to a
  bug in how they were called in d/rules. This has been fixed, and turns
  out the current version in focal release (0.39.0-1) is already an FTBFS
  when tests are properly run during build.
  
  To have the tests run at build time (as was the original intention), the
  conditional in d/rules was fixed and a patch from upstream was added. I
  also submitted the d/rules fix to Debian via [2]. Once that is merged,
  groovy will have the fix as well via a standard sync. Note the extra
  patch isn't needed in that version.
  
  1. see the linked MP. Getting a diff from github just for the nginx plugin is 
hard because it is a subdirectory of the bigger certbot project. You can try, 
though: https://github.com/certbot/certbot/compare/v0.39.0...v0.40.0 and search 
for "certbot-nginx"
  2. 
https://salsa.debian.org/letsencrypt-team/certbot/certbot-nginx/-/merge_requests/1
  
  [Test Plan]
  
  a) See
  https://wiki.ubuntu.com/StableReleaseUpdates/Certbot#SRU_Verification_Process.
  Run https://wiki.ubuntu.com/StableReleaseUpdates/Certbot/TestScript
  (script updated by Brad Warren for this update, thank you!). Sample
  trailer output in comment #18.
  
  b) Request a registration with nginx (example shown in comment #19):
  sudo certbot -d  --agree-tos --staging 
--register-unsafely-without-email --nginx
  
  c) Request a registration using apache (example shown in comment #21):
  sudo certbot -d  --agree-tos --staging 
--register-unsafely-without-email --apache
  
- TODO: add testscript.sh run results
+ d) Search build logs for "dh_auto_test" and confirm it was called and
+ that the build-time tests were run. In launchpad, you can find these by
+ going to https://launchpad.net/ubuntu/+source/python-certbot-nginx and
+ clicking through the version of this package in focal-proposed and the
+ builds on the right hand side of the screen.
  
  [Regression Potential]
  
  Upstream performs extensive testing before release, giving us a high
  degree of confidence in the general case. There problems are most likely
  to manifest in Ubuntu-specific integrations, such as in relation to the
  versions of dependencies available and other packaging-specific matters.
  
  python-acme 1.x which removed TLSSNI01 (among other changes) shouldn't
  have migrated to the release pocket without also migrating a newer 1.x
  version of python-certbot-*. This was fixed in the development release
  and in Debian via an ABI provides.
  
  This situation of having a more recent python-acme in focal but not 
accompanying python-certbot-* version bumps to the same series also made some 
related packages to become FTBFS in focal release:
  - bug #1876933: python-certbot FTBFS due to failing build time tests
  - bug #1876929: python-acme FTBFS due to unsatisfied dependency on 
python3-idna << 2.8
  - bug #1876934: python-certbot-apache FTBFS due to failing build time tests
  
  python-certbot-nginx 0.39.0 didn't become an FTBFS like python-certbot-
  apache just because of the d/rules error in calling those tests, which
  is being fixed in this update.
  
  Fixing those FTBFS issues in the other packages is not in scope for this
  SRU. It is expected that certbot in general will get more updates in the
  future during the lifecycle of Ubuntu Focal, and updating the packages
  at that time will fix the build problem. At the moment, they don't
  impact the functionality of the system. See the discussion further down
  here in this bug, in particular comment #12 and comment #15, the latter
  being what was implemented for this SRU.
  
  [Original Description]
  This issue only affects version 0.39.0-1 of the python-certbot-nginx package 
in Ubuntu 20.04.
  
  To reproduce the problem, install python3-certbot-nginx and run a
  command like:
  
  sudo certbot -d example.org --agree-tos --staging --register-unsafely-
  without-email --nginx
  
  This command will fail and the relevant output is:
  
  AttributeError: module 'acme.challenges' has no attribute 'TLSSNI01'
  
  The problem here is python-certbot-nginx contains references to code in
  python-acme that has been removed. This problem makes python-certbot-
  nginx completely 

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

** Description changed:

  This bug tracks an update for python-certbot from 0.39.0 to 0.40.0.
  
  This update includes bugfixes only following the SRU policy exception
  defined at https://wiki.ubuntu.com/StableReleaseUpdates/Certbot.
  
  [Impact]
  
  Reguesting a certificate via the nginx plugin fails:
  
  AttributeError: module 'acme.challenges' has no attribute 'TLSSNI01'
  
  The problem here is python-certbot-nginx contains references to code in
  python-acme that has been removed. This problem makes python-certbot-
  nginx completely unable to obtain certificates.
  
  [Major Changes]
  
  To fix the problem, python-certbot-nginx is being updated from 0.39.0 to
  0.40.0. The diff[1] is small and is about removing TLSSNI01 support.
  
  It was also noticed that the build-time tests were never run due to a
  bug in how they were called in d/rules. This has been fixed, and turns
  out the current version in focal release (0.39.0-1) is already an FTBFS
  when tests are properly run during build.
  
  To have the tests run at build time (as was the original intention), the
  conditional in d/rules was fixed and a patch from upstream was added. I
  also submitted the d/rules fix to Debian via [2]. Once that is merged,
  groovy will have the fix as well via a standard sync. Note the extra
  patch isn't needed in that version.
  
- 1. see the linked MP. Getting a diff from github just for the nginx plugin is 
hard because it is a subdirectory of the bigger certbot project.
+ 1. see the linked MP. Getting a diff from github just for the nginx plugin is 
hard because it is a subdirectory of the bigger certbot project. You can try, 
though: https://github.com/certbot/certbot/compare/v0.39.0...v0.40.0 and search 
for "certbot-nginx"
  2. 
https://salsa.debian.org/letsencrypt-team/certbot/certbot-nginx/-/merge_requests/1
  
  [Test Plan]
  
  a) See
  https://wiki.ubuntu.com/StableReleaseUpdates/Certbot#SRU_Verification_Process.
  Run https://wiki.ubuntu.com/StableReleaseUpdates/Certbot/TestScript
  (script updated by Brad Warren for this update, thank you!). Sample
  trailer output in comment #18.
  
  b) Request a registration with nginx (example shown in comment #19):
  sudo certbot -d  --agree-tos --staging 
--register-unsafely-without-email --nginx
  
  c) Request a registration using apache (example shown in comment #21):
  sudo certbot -d  --agree-tos --staging 
--register-unsafely-without-email --apache
  
  TODO: add testscript.sh run results
  
  [Regression Potential]
  
  Upstream performs extensive testing before release, giving us a high
  degree of confidence in the general case. There problems are most likely
  to manifest in Ubuntu-specific integrations, such as in relation to the
  versions of dependencies available and other packaging-specific matters.
  
  python-acme 1.x which removed TLSSNI01 (among other changes) shouldn't
  have migrated to the release pocket without also migrating a newer 1.x
  version of python-certbot-*. This was fixed in the development release
  and in Debian via an ABI provides.
  
  This situation of having a more recent python-acme in focal but not 
accompanying python-certbot-* version bumps to the same series also made some 
related packages to become FTBFS in focal release:
  - bug #1876933: python-certbot FTBFS due to failing build time tests
  - bug #1876929: python-acme FTBFS due to unsatisfied dependency on 
python3-idna << 2.8
  - bug #1876934: python-certbot-apache FTBFS due to failing build time tests
  
  python-certbot-nginx 0.39.0 didn't become an FTBFS like python-certbot-
  apache just because of the d/rules error in calling those tests, which
  is being fixed in this update.
  
  Fixing those FTBFS issues in the other packages is not in scope for this
  SRU. It is expected that certbot in general will get more updates in the
  future during the lifecycle of Ubuntu Focal, and updating the packages
  at that time will fix the build problem. At the moment, they don't
  impact the functionality of the system. See the discussion further down
  here in this bug, in particular comment #12 and comment #15, the latter
  being what was implemented for this SRU.
  
  [Original Description]
  This issue only affects version 0.39.0-1 of the python-certbot-nginx package 
in Ubuntu 20.04.
  
  To reproduce the problem, install python3-certbot-nginx and run a
  command like:
  
  sudo certbot -d example.org --agree-tos --staging --register-unsafely-
  without-email --nginx
  
  This command will fail and the relevant output is:
  
  AttributeError: module 'acme.challenges' has no attribute 'TLSSNI01'
  
  The problem here is python-certbot-nginx contains references to code in
  python-acme that has been removed. This problem makes python-certbot-
  nginx completely unable to obtain certificates.
  
  As the upstream maintainer of this package, I'll suggest two ways to fix
  this problem:
  
  1. Update python-certbot-nginx to our 0.40.0 release. The benefit 

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

Successful run with apache:
ubuntu@certbot-test:~$ sudo certbot -d certbot-test.justgohome.co.uk 
--agree-tos --staging --register-unsafely-without-email --apache
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache
Obtaining a new certificate
Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf
Enabled Apache socache_shmcb module
Enabled Apache ssl module
Deploying Certificate to VirtualHost 
/etc/apache2/sites-available/000-default-le-ssl.conf
Enabling available site: /etc/apache2/sites-available/000-default-le-ssl.conf

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP 
access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Enabled Apache rewrite module
Redirecting vhost in /etc/apache2/sites-enabled/000-default.conf to ssl vhost 
in /etc/apache2/sites-available/000-default-le-ssl.conf

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled
https://certbot-test.justgohome.co.uk

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=certbot-test.justgohome.co.uk
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/certbot-test.justgohome.co.uk/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/certbot-test.justgohome.co.uk/privkey.pem
   Your cert will expire on 2020-08-04. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"


** Description changed:

  This bug tracks an update for python-certbot from 0.39.0 to 0.40.0.
  
  This update includes bugfixes only following the SRU policy exception
  defined at https://wiki.ubuntu.com/StableReleaseUpdates/Certbot.
  
  [Impact]
  
  Not directly applicable; see the exception policy document at
  https://wiki.ubuntu.com/StableReleaseUpdates/Certbot
  
  Reguesting a certificate via the nginx plugin fails:
  
  AttributeError: module 'acme.challenges' has no attribute 'TLSSNI01'
  
  The problem here is python-certbot-nginx contains references to code in
  python-acme that has been removed. This problem makes python-certbot-
  nginx completely unable to obtain certificates.
  
  [Major Changes]
  
  To fix the problem, python-certbot-nginx is being updated from 0.39.0 to
  0.40.0. The diff[1] is small and is about removing TLSSNI01 support.
  
  It was also noticed that the build-time tests were never run due to a
  bug in how they were called in d/rules. This has been fixed, and turns
  out the current version in focal release (0.39.0-1) is already an FTBFS
  when tests are properly run during build.
  
  To have the tests run at build time (as was the original intention), the
  conditional in d/rules was fixed and a patch from upstream was added. I
  also submitted the d/rules fix to Debian via [2]. Once that is merged,
  groovy will have the fix as well via a standard sync. Note the extra
  patch isn't needed in that version.
  
  1. see the linked MP. Getting a diff from github just for the nginx plugin is 
hard because it is a subdirectory of the bigger certbot project.
  2. 
https://salsa.debian.org/letsencrypt-team/certbot/certbot-nginx/-/merge_requests/1
  
  [Test Plan]
  
- See
+ a) See
  https://wiki.ubuntu.com/StableReleaseUpdates/Certbot#SRU_Verification_Process
+ 
+ b) Request a registration with nginx:
+ sudo certbot -d  --agree-tos --staging 
--register-unsafely-without-email --nginx
+ 
+ c) Request a registration using apache:
+ sudo certbot -d  --agree-tos --staging 
--register-unsafely-without-email --apache
+ 
+ Comment #19 shows a successful manual registration using nginx and
+ packages from a test PPA
  
  TODO: add testscript.sh run results
  TODO: add manual registration results with nginx and apache against staging
  
  [Regression Potential]
  
  Upstream performs extensive testing before release, giving us a high
  degree of confidence in the general case. There problems are most likely
  to manifest in Ubuntu-specific integrations, such as in relation to the
  versions of dependencies available and other packaging-specific matters.
  
  python-acme 1.x which removed TLSSNI01 (among other changes) shouldn't
  have migrated to the release pocket 

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

** Description changed:

  This bug tracks an update for python-certbot from 0.39.0 to 0.40.0.
  
  This update includes bugfixes only following the SRU policy exception
  defined at https://wiki.ubuntu.com/StableReleaseUpdates/Certbot.
  
  [Impact]
  
  Not directly applicable; see the exception policy document at
  https://wiki.ubuntu.com/StableReleaseUpdates/Certbot
  
  Reguesting a certificate via the nginx plugin fails:
  
  AttributeError: module 'acme.challenges' has no attribute 'TLSSNI01'
  
  The problem here is python-certbot-nginx contains references to code in
  python-acme that has been removed. This problem makes python-certbot-
  nginx completely unable to obtain certificates.
  
  [Major Changes]
  
  To fix the problem, python-certbot-nginx is being updated from 0.39.0 to
  0.40.0. The diff[1] is small and is about removing TLSSNI01 support.
  
  It was also noticed that the build-time tests were never run due to a
  bug in how they were called in d/rules. This has been fixed, and turns
  out the current version in focal release (0.39.0-1) is already an FTBFS
  when tests are properly run during build.
  
  To have the tests run at build time (as was the original intention), the
  conditional in d/rules was fixed and a patch from upstream was added. I
  also submitted the d/rules fix to Debian via [2]. Once that is merged,
  groovy will have the fix as well via a standard sync. Note the extra
  patch isn't needed in that version.
- 
  
  1. see the linked MP. Getting a diff from github just for the nginx plugin is 
hard because it is a subdirectory of the bigger certbot project.
  2. 
https://salsa.debian.org/letsencrypt-team/certbot/certbot-nginx/-/merge_requests/1
  
  [Test Plan]
  
  See
  https://wiki.ubuntu.com/StableReleaseUpdates/Certbot#SRU_Verification_Process
  
  TODO: add testscript.sh run results
  TODO: add manual registration results with nginx and apache against staging
  
  [Regression Potential]
  
  Upstream performs extensive testing before release, giving us a high
  degree of confidence in the general case. There problems are most likely
  to manifest in Ubuntu-specific integrations, such as in relation to the
  versions of dependencies available and other packaging-specific matters.
  
  python-acme 1.x which removed TLSSNI01 (among other changes) shouldn't
  have migrated to the release pocket without also migrating a newer 1.x
  version of python-certbot-*. This was fixed in the development release
  and in Debian via an ABI provides.
  
  This situation of having a more recent python-acme in focal but not 
accompanying python-certbot-* version bumps to the same series also made some 
related packages to become FTBFS in focal release:
  - bug #1876933: python-certbot FTBFS due to failing build time tests
  - bug #1876929: python-acme FTBFS due to unsatisfied dependency on 
python3-idna << 2.8
  - bug #1876934: python-certbot-apache FTBFS due to failing build time tests
  
  python-certbot-nginx 0.39.0 didn't become an FTBFS like python-certbot-
  apache just because of the d/rules error in calling those tests, which
  is being fixed in this update.
  
  Fixing those FTBFS issues in the other packages is not in scope for this
  SRU. It is expected that certbot in general will get more updates in the
  future during the lifecycle of Ubuntu Focal, and updating the packages
  at that time will fix the build problem. At the moment, they don't
  impact the functionality of the system. See the discussion further down
- here in this bug.
+ here in this bug, in particular comment #12 and comment #15, the latter
+ being what was implemented for this SRU.
  
  [Original Description]
  This issue only affects version 0.39.0-1 of the python-certbot-nginx package 
in Ubuntu 20.04.
  
  To reproduce the problem, install python3-certbot-nginx and run a
  command like:
  
  sudo certbot -d example.org --agree-tos --staging --register-unsafely-
  without-email --nginx
  
  This command will fail and the relevant output is:
  
  AttributeError: module 'acme.challenges' has no attribute 'TLSSNI01'
  
  The problem here is python-certbot-nginx contains references to code in
  python-acme that has been removed. This problem makes python-certbot-
  nginx completely unable to obtain certificates.
  
  As the upstream maintainer of this package, I'll suggest two ways to fix
  this problem:
  
  1. Update python-certbot-nginx to our 0.40.0 release. The benefit of
  this is it sticks to well tested versions of our software rather than
  making potentially error prone backports. Certbot has an SRU exception
  which can be seen at
  https://wiki.ubuntu.com/StableReleaseUpdates/Certbot. The diff of  code
  upstream between 0.39.0 and 0.40.0 if you all want to take this route
  can be see at
  https://gist.github.com/bmw/a88429687f4aed13e300fafdad85ce30.
  
  2. You can manually backport minimal fixes. The only changes that should
  required from the above gist are the changes to:
  
  * 

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

** Description changed:

- This issue only affects version 0.39.0-1 of the python-certbot-nginx
- package in Ubuntu 20.04.
+ This bug tracks an update for python-certbot from 0.39.0 to 0.40.0.
+ 
+ This update includes bugfixes only following the SRU policy exception
+ defined at https://wiki.ubuntu.com/StableReleaseUpdates/Certbot.
+ 
+ [Impact]
+ 
+ Not directly applicable; see the exception policy document at
+ https://wiki.ubuntu.com/StableReleaseUpdates/Certbot
+ 
+ Reguesting a certificate via the nginx plugin fails:
+ 
+ AttributeError: module 'acme.challenges' has no attribute 'TLSSNI01'
+ 
+ The problem here is python-certbot-nginx contains references to code in
+ python-acme that has been removed. This problem makes python-certbot-
+ nginx completely unable to obtain certificates.
+ 
+ [Major Changes]
+ 
+ To fix the problem, python-certbot-nginx is being updated from 0.39.0 to
+ 0.40.0. The diff[1] is small and is about removing TLSSNI01 support.
+ 
+ It was also noticed that the build-time tests were never run due to a
+ bug in how they were called in d/rules. This has been fixed, and turns
+ out the current version in focal release (0.39.0-1) is already an FTBFS
+ when tests are properly run during build.
+ 
+ To have the tests run at build time (as was the original intention), the
+ conditional in d/rules was fixed and a patch from upstream was added. I
+ also submitted the d/rules fix to Debian via [2]. Once that is merged,
+ groovy will have the fix as well via a standard sync. Note the extra
+ patch isn't needed in that version.
+ 
+ 
+ 1. see the linked MP. Getting a diff from github just for the nginx plugin is 
hard because it is a subdirectory of the bigger certbot project.
+ 2. 
https://salsa.debian.org/letsencrypt-team/certbot/certbot-nginx/-/merge_requests/1
+ 
+ [Test Plan]
+ 
+ See
+ https://wiki.ubuntu.com/StableReleaseUpdates/Certbot#SRU_Verification_Process
+ 
+ TODO: add testscript.sh run results
+ TODO: add manual registration results with nginx and apache against staging
+ 
+ [Regression Potential]
+ 
+ Upstream performs extensive testing before release, giving us a high
+ degree of confidence in the general case. There problems are most likely
+ to manifest in Ubuntu-specific integrations, such as in relation to the
+ versions of dependencies available and other packaging-specific matters.
+ 
+ python-acme 1.x which removed TLSSNI01 (among other changes) shouldn't
+ have migrated to the release pocket without also migrating a newer 1.x
+ version of python-certbot-*. This was fixed in the development release
+ and in Debian via an ABI provides.
+ 
+ This situation of having a more recent python-acme in focal but not 
accompanying python-certbot-* version bumps to the same series also made some 
related packages to become FTBFS in focal release:
+ - bug #1876933: python-certbot FTBFS due to failing build time tests
+ - bug #1876929: python-acme FTBFS due to unsatisfied dependency on 
python3-idna << 2.8
+ - bug #1876934: python-certbot-apache FTBFS due to failing build time tests
+ 
+ python-certbot-nginx 0.39.0 didn't become an FTBFS like python-certbot-
+ apache just because of the d/rules error in calling those tests, which
+ is being fixed in this update.
+ 
+ Fixing those FTBFS issues in the other packages is not in scope for this
+ SRU. It is expected that certbot in general will get more updates in the
+ future during the lifecycle of Ubuntu Focal, and updating the packages
+ at that time will fix the build problem. At the moment, they don't
+ impact the functionality of the system. See the discussion further down
+ here in this bug.
+ 
+ [Original Description]
+ This issue only affects version 0.39.0-1 of the python-certbot-nginx package 
in Ubuntu 20.04.
  
  To reproduce the problem, install python3-certbot-nginx and run a
  command like:
  
  sudo certbot -d example.org --agree-tos --staging --register-unsafely-
  without-email --nginx
  
  This command will fail and the relevant output is:
  
  AttributeError: module 'acme.challenges' has no attribute 'TLSSNI01'
  
  The problem here is python-certbot-nginx contains references to code in
  python-acme that has been removed. This problem makes python-certbot-
  nginx completely unable to obtain certificates.
  
  As the upstream maintainer of this package, I'll suggest two ways to fix
  this problem:
  
  1. Update python-certbot-nginx to our 0.40.0 release. The benefit of
  this is it sticks to well tested versions of our software rather than
  making potentially error prone backports. Certbot has an SRU exception
  which can be seen at
  https://wiki.ubuntu.com/StableReleaseUpdates/Certbot. The diff of  code
  upstream between 0.39.0 and 0.40.0 if you all want to take this route
  can be see at
  https://gist.github.com/bmw/a88429687f4aed13e300fafdad85ce30.
  
  2. You can manually backport minimal fixes. The only changes that should
  required from the above gist are the changes to:
  
  * 

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

Staging server test worked just fine. I'll prepare the SRU paperwork.


ubuntu@certbot-test:~$ sudo certbot -d certbot-test.justgohome.co.uk 
--agree-tos --staging --register-unsafely-without-email --nginx
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for certbot-test.justgohome.co.uk
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/default

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP 
access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/default

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled
https://certbot-test.justgohome.co.uk

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=certbot-test.justgohome.co.uk
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/certbot-test.justgohome.co.uk/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/certbot-test.justgohome.co.uk/privkey.pem
   Your cert will expire on 2020-08-04. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875471

Title:
  python3-certbot-nginx is incompatible with its dependencies

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-certbot-nginx/+bug/1875471/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

Thanks for the test update, worked great:
(...)
testing section-continuations-2525.conf...passed
testing section-empty-continuations-2731.conf...passed
testing semacode-1598.conf...passed
testing two-blocks-one-line-1693.conf...passed
Success!
Package versions tested:
certbot 0.40.0-1
letsencrypt 
python3-acme1.1.0-1
python3-certbot 0.40.0-1
python3-certbot-apache  0.39.0-1
python3-certbot-nginx   0.40.0-0ubuntu0.1~ppa1
python3-josepy  1.2.0-2


Looks like we can proceed with (d). I'll do a real test with the staging server 
tomorrow.

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875471

Title:
  python3-certbot-nginx is incompatible with its dependencies

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-certbot-nginx/+bug/1875471/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

https://launchpad.net/~ahasenack/+archive/ubuntu/certbot-
tlssni01-1875471-d

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875471

Title:
  python3-certbot-nginx is incompatible with its dependencies

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-certbot-nginx/+bug/1875471/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

That sounds good, let me prepare a separate ppa for (d)

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875471

Title:
  python3-certbot-nginx is incompatible with its dependencies

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-certbot-nginx/+bug/1875471/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

The testscript at
https://wiki.ubuntu.com/StableReleaseUpdates/Certbot/TestScript no
longer works:

Cloning into '/root/gopath/src/github.com/letsencrypt/boulder'...
remote: Enumerating objects: 2676, done.
remote: Counting objects: 100% (2676/2676), done.
remote: Compressing objects: 100% (2106/2106), done.
remote: Total 2676 (delta 577), reused 1597 (delta 425), pack-reused 0
Receiving objects: 100% (2676/2676), 4.68 MiB | 6.77 MiB/s, done.
Resolving deltas: 100% (577/577), done.
sed: can't read tests/boulder-integration.sh: No such file or directory

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875471

Title:
  python3-certbot-nginx is incompatible with its dependencies

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-certbot-nginx/+bug/1875471/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

Ok, I filed bugs for the FTBFS issues, but per policy, we won't do an
update just to fix failed-to-build-from-source bugs: these should be
updated together with something else.

Thanks for all the options you outlined in comment #8, and for the check
in comment #11.

So to keep things simple:

a) update just python-certbot-nginx to 0.40.0, and gloss over the fact
that the build-time tests are being skipped;

b) fix the build-time tests call in python-certbot-nginx, which will require 
these other changes:
- bump python-certbot-apache to 0.40.0
- drop TLSSNI01 from python-certbot 0.40.0
- preferably fix python-acme's idna build-deps and update it together, as that 
would also run tests with the current idna in focal
I didn't check if the version bumps have the commits you mentioned, but the 
tests and a minimal run worked. If this looks feasable, the next step would be 
to run the full test suite, and also try this on a live server with proper DNS 
setup.

c) bump everything to what we have in groovy, so that the versions match
expectations and we don't have this big mismatch we are seeing in focal
right now

There is a feeling we should go with (a) to fix the immediate problem,
and (b) can be done over time, or even (c).

I have the (b) scenario done in my ppa at
https://launchpad.net/~ahasenack/+archive/ubuntu/certbot-
tlssni01-1875471

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875471

Title:
  python3-certbot-nginx is incompatible with its dependencies

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-certbot-nginx/+bug/1875471/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1876564] Re: mail-stack-delivery has missing packages on focal

[Andreas Hasenack]

The server guide has a warning about this package being deprecated
(paride just added it):

https://ubuntu.com/server/docs/mail-postfix
"""
Deprecation warning: please note that the mail-stack-delivery metapackage has 
been deprecated in Focal. The package still exists for compatibility reasons, 
but won’t setup a working email system.
"""

A search doesn't turn mail-stack-delivery up anywhere else, so I'm
marking that task as released.

** Changed in: serverguide
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1876564

Title:
  mail-stack-delivery has missing packages on focal

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

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1876564] Re: mail-stack-delivery has missing packages on focal

[Andreas Hasenack]

This was the deprecation notice sent back then:

https://lists.ubuntu.com/archives/ubuntu-server/2018-March/007682.html

some replies came back in May:
https://lists.ubuntu.com/archives/ubuntu-server/2018-May/007707.html

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1876564

Title:
  mail-stack-delivery has missing packages on focal

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

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1876622] Re: Can't upgrade samba-common-bin: undefined symbol: smb_strtoul

[Andreas Hasenack]

Thanks for getting back to us. I'll close the bug.

** Changed in: samba (Ubuntu)
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/1876622

Title:
  Can't upgrade samba-common-bin: undefined symbol: smb_strtoul

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1876622/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1876564] Re: mail-stack-delivery has missing packages on focal

[Andreas Hasenack]

I think this bug is wontfix, or opinion, but we need tasks for the Focal
release notes, and the server guide. I'm failing at that, can't figure
out the UI to do it.

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1876564

Title:
  mail-stack-delivery has missing packages on focal

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

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1872476] Re: Shared files are shown as folders

[Andreas Hasenack]

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

** Changed in: samba (Ubuntu Focal)
 Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)

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

** Changed in: samba (Ubuntu Focal)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1872476

Title:
  Shared files are shown as folders

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1872476/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

Quick update on the current focal situation regarding some of these
packages:

These are currently an FTBFS in focal:
- python-certbot 0.40.0-1 (build-time tests fail)
- python-acme 1.1.0-1 (build-dep python3-idna <<2.8 not satisfied. When it was 
last built in focal, python3-idna was at 2.6)
- python-certbot-apache 0.39.0-1 (build-time tests fail)

python-certbot-nginx 0.39.0-1 builds, but just because the tests are
incorrectly skipped in d/rules. If they run, they fail, and that would
FTBFS this package as well.

If I change python-acme to accept python3-idna 2.8 as a build-dep
(changing d/control do python3-idna << 2.9), then it builds. I don't
know if this change is acceptable. Upstream python-idna made a 2.9
release in February 17th 2020, which we have in groovy and debian
unstable.

Will continue tomorrow.

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875471

Title:
  python3-certbot-nginx is incompatible with its dependencies

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-certbot-nginx/+bug/1875471/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

Sorry for having gone radio silent in the past few days. I'm back on
this tomorrow.

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875471

Title:
  python3-certbot-nginx is incompatible with its dependencies

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-certbot-nginx/+bug/1875471/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1876622] Re: Can't upgrade samba-common-bin: undefined symbol: smb_strtoul

[Andreas Hasenack]

Sorry, "Pay close attention", not "Play" :)

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/1876622

Title:
  Can't upgrade samba-common-bin: undefined symbol: smb_strtoul

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1876622/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1876622] Re: Can't upgrade samba-common-bin: undefined symbol: smb_strtoul

[Andreas Hasenack]

Yeah, that was probably the cause. To finish fixing your system
regarding the samba packages, you should be able to run these now:

sudo apt update
sudo apt -f install


Play close attention to what the last one tells you ("-f" stands for "fix"). If 
it doesn't look unreasonable and it's asking you to proceed, you may do so. In 
the end, the dpkg -l list should only contain "ii" or "rc" packages, not iU or 
iF which indicates problems.

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/1876622

Title:
  Can't upgrade samba-common-bin: undefined symbol: smb_strtoul

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1876622/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1876622] Re: Can't upgrade samba-common-bin: undefined symbol: smb_strtoul

[Andreas Hasenack]

You may have had an old samba from 18.04 still installing, as a result
of your release upgrade. Could you please run this command and show the
output?


dpkg -l | grep -E "(samba|smb|registry-tools|winbind|libwbclient|ctdb)"

** Changed in: samba (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to samba in Ubuntu.
https://bugs.launchpad.net/bugs/1876622

Title:
  Can't upgrade samba-common-bin: undefined symbol: smb_strtoul

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1876622/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

Re: Upgrade 16.04 to 18.04

[Andreas Hasenack]

Hello,

On Fri, May 1, 2020 at 7:35 PM Leroy Tennison 
wrote:

> (I don't know what's wrong with my mail but I had to open an attachment to
> see your reply).  Thanks for getting back to me, ran 'apt-get install
> ca-certificates' and the reply was that it was already the latest version.
> Tried do-release-upgrade again - smae result.
>


which ca-certificates package do you have installed? Note that the one in
updates is higher than the one in security:

 ca-certificates | 20170717~16.04.1| xenial-security  | source, all
 ca-certificates | 20170717~16.04.2| xenial-updates   | source, all
-- 
ubuntu-server mailing list
ubuntu-server@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
More info: https://wiki.ubuntu.com/ServerTeam

[Bug 1875697] Re: drop fix-ldap-distribution.patch?

[Andreas Hasenack]

I'm adding this to my list of delta to drop in this cycle.

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875697

Title:
  drop fix-ldap-distribution.patch?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1875697/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1839767] Re: apparmor DENIED freshclam and clamd access to openssl.cnf

[Andreas Hasenack]

Disco is EOL, marking its task as such.

** Changed in: clamav (Ubuntu Disco)
   Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1839767

Title:
  apparmor DENIED freshclam and clamd access to openssl.cnf

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1839767/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

PPA with test packages: https://launchpad.net/~ahasenack/+archive/ubuntu
/certbot-tlssni01-1875471

It has python-certbot with TLSSNI01 removed, probably not necessary for
this bugfix, but it allowed me to re-introduce the build-time tests for
the python-certbot-nginx package.

Will continue tomorrow.

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875471

Title:
  python3-certbot-nginx is incompatible with its dependencies

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-certbot-nginx/+bug/1875471/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

Would this commit be correct to apply on top of 0.40.0 to at least match
python-acme 1.1.0-1 that is in focal w.r.t. TLSSNI01's removal?

https://github.com/certbot/certbot/commit/4b488614cf7749c8139c11f0983fe4b71e29827f
* Remove tls sni common (#7527)

* fixes #7478

* add changelog entry


If it's hard to check, then never mind. It just feels we could still be open to 
problems by having python-acme *without* TLSSNI01 but python-certbot *with* it 
somewhere in the code.

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875471

Title:
  python3-certbot-nginx is incompatible with its dependencies

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-certbot-nginx/+bug/1875471/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1875471] Re: python3-certbot-nginx is incompatible with its dependencies

[Andreas Hasenack]

So python-certbot 0.40.0 still has TLSSNI01, but not acme, and so far
only python-certbot-nginx is triggering the error. Probably not worth
bumping python-certbot just to be able to run its tests correctly.

-- 
You received this bug notification because you are a member of Ubuntu
Server, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1875471

Title:
  python3-certbot-nginx is incompatible with its dependencies

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-certbot-nginx/+bug/1875471/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs