date:20200518

Proposed migration: bind9-libs

2020-05-18 Thread 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

2020-05-18 Thread 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

2020-05-18 Thread 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

2020-05-18 Thread 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

2020-05-18 Thread 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

2020-05-18 Thread 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

2020-05-18 Thread 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

2020-05-18 Thread 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

2020-05-18 Thread 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

2020-05-18 Thread 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

Re: Ubuntu 20.04 performance

2020-05-18 Thread Leroy Tennison

Did a test Ubuntu 18.04 install and, although it was a little sluggish, not 
nearly as sluggish as Ubuntu 20.04.

From: ubuntu-server  on behalf of 
Andreas Hasenack 
Sent: Wednesday, May 13, 2020 1:08 PM
To: 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.

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 
mailto:le...@datavoiceint.com>> 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 
mailto:ubuntu-server-boun...@lists.ubuntu.com>>
 on behalf of Andreas Hasenack 
mailto:andr...@canonical.com>>
Sent: Wednesday, May 13, 2020 9:57 AM
Cc: ubuntu-server 
mailto:ubuntu-server@lists.ubuntu.com>>
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

[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]

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.

Harriscomputer

Leroy Tennison
Network Information/Cyber Security Specialist
E: le...@datavoiceint.com

[cid:Data-Voice-International-LOGO_aa3d1c6e-5cfb-451f-ba2c-af8059e69609.PNG]

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.

On Wed, May 13, 2020 at 11:52 AM Leroy Tennison 
mailto:le...@datavoiceint.com>> 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

[cid:1720f38cc15c204bfcc1]

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

Merge Opportunities Report - 2020-05-18

2020-05-18 Thread Bryce Harrington

New Version in Debian Unstable
--
high  apache2   2.4.43-1  
2.4.41-4ubuntu3 
high  bind9 1:9.16.2-3
1:9.16.1-0ubuntu2   
high  chrony3.5-8 3.5-6ubuntu6  
  
high  clamav0.102.3+dfsg-1
0.102.2+dfsg-2ubuntu1   
high  nut   2.7.4-12  
2.7.4-11ubuntu4 
high  ocfs2-tools   1.8.6-3   
1.8.6-2ubuntu1  
high  sosreport 3.9-2 3.9-1ubuntu3  
  
high  squid 4.11-54.10-1ubuntu2 
  
low   containerd1.3.4~ds1-1   
1.3.3-0ubuntu2  
low   crmsh 4.2.0-3   
4.2.0-2ubuntu1  
low   dpdk  19.11.1-2 
19.11.1-0ubuntu1
low   exim4 4.93-16   
4.93-15ubuntu1  
low   krb5  1.17-71.17-6ubuntu4 
  
low   kronosnet 1.16-21.15-1ubuntu1 
  
low   libdbi-drivers0.9.0-9   
0.9.0-8ubuntu1  
low   libvirt   6.0.0-7   
6.0.0-0ubuntu8  
low   mako  1.1.2+ds1-1   
1.1.0+ds1-1ubuntu2  
low   nagios-nrpe   4.0.3-1   
4.0.0-2ubuntu1  
low   nss   2:3.52-1  
2:3.49.1-1ubuntu1   
low   php7.47.4.5-1   
7.4.3-4ubuntu3  
low   python-seamicroclient 0.4.0+2016.05.20.git.40ee44c664-4 
0.4.0+2016.05.20.git.40ee44c664-3ubuntu1
low   qemu  1:5.0-5   
1:4.2-3ubuntu6  
low   rabbitmq-server   3.8.3-1   
3.8.3-0ubuntu1  
low   rdma-core 29.0-128.0-1ubuntu1 
  
low   runc  1.0.0~rc10+dfsg2-1
1.0.0~rc10-0ubuntu1 
low   sg3-utils 1.45-11.44-1ubuntu2 
  
low   spice 0.14.3-1  
0.14.2-4ubuntu3 
low   ssh-import-id 5.10-15.10-0ubuntu1 
  
low   virglrenderer 0.8.2-2   
0.8.2-1ubuntu1  
low   vlan  2.0.5 2.0.4ubuntu2  
  


New Version in Experimental
--
low   haproxy   2.1.4-1   2.0.14-1  
   
low   http-parser   2.9.3-1   2.9.2-2   
   
low   python-django 2:3.0.6-1 2:2.2.12-1
   


New Upstream not in Debian
--
high  atUNKNOWN   3.1.23-1ubuntu1   
   
high  bcache-tools  UNKNOWN   1.0.8-3   
   
high  checksecurity UNKNOWN   2.0.16+nmu1ubuntu1
   
high  drbd-utils9.13.19.11.0-1build1
   
high  libapache2-mod-auth-plain UNKNOWN   2.0.52
   
high  logwatch  7.5.3/logwatch-7.5.3  7.5.2-1ubuntu1
   
high  lsscsi0.31  0.30-0.1  
   
high  multipath-tools   0.8.4 0.8.3-1ubuntu2
   
high  numactl   2.0.132.0.12-1  
   
high  openipmi  2.0.282.0.27-0ubuntu2   
   
high  pacemaker 2.0.4~rc2 2.0.3-3ubuntu3
   
high  postfix   3.5.2 3.5.1-1   
   
high  procmail  UNKNOWN   3.22-26   
   
high

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

2020-05-18 Thread 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

2020-05-18 Thread 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

2020-05-18 Thread 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

Proposed migration: bind9-libs

Cleaning up the openldap packaging

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

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

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

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

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

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

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

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

Re: Ubuntu 20.04 performance

Merge Opportunities Report - 2020-05-18

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

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

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

15 matches

Site Navigation

Mail list logo

Footer information