[Touch-packages] [Bug 1403955] Re: DHCP's Option interface-mtu 9000 is being ignored on bridge interface br0
Hi Robie,
Let me answer your questions:
Why is br0 being set up to bridge eth0? Is something doing this automatically
or is this configuration necessary for something (if so, what?)?
This configuration (br0 on a single physical interface) is automatically
generated by deploying openstack Juno (I don't know what particular component
does it, atm) on Trusty. In our case it's not necessary/mandatory, but just the
result of the installation. I don't know what consequences we might face by
disabling/removing br0, though.
Without using br0 and just using plain eth0, does the interface-mtu option
work correctly?
Will do asap, but on a first guess I think it would work
... If so, I'm not sure it really makes sense for the DHCP client to set the
MTU on eth0 when receiving DHCP over br0. I suppose it depends on the use case
though.
I agree. In this particular scenario, having just one physical interface
sharing its mac address with the bridge, I think it makes sense to expect the
interface's MTU being set (there's no other interface acting as a constraint).
Other situations, with several interfaces, manual config might be mandatory.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1403955
Title:
DHCP's Option interface-mtu 9000 is being ignored on bridge
interface br0
Status in isc-dhcp package in Ubuntu:
New
Bug description:
In an env with jumbo frames enabled, and using MAAS as DHCP server,
the client receives the following IPv4 lease:
$ cat /var/lib/dhcp/dhclient.br0.leases
lease {
interface br0;
fixed-address 10.230.20.26;
filename pxelinux.0;
option subnet-mask 255.255.248.0;
option dhcp-lease-time 43200;
option routers 10.230.16.1;
option dhcp-message-type 5;
option dhcp-server-identifier 10.230.20.1;
option domain-name-servers 10.230.20.1;
option interface-mtu 9000;
option broadcast-address 10.230.23.255;
option domain-name ctsstack.qa.1ss;
renew 3 2014/12/17 16:48:15;
rebind 3 2014/12/17 21:52:09;
expire 3 2014/12/17 23:22:09;
}
The interfaces show the following config after boot:
$ ifconfig br0
br0 Link encap:Ethernet HWaddr a0:d3:c1:01:9d:58
inet addr:10.230.20.26 Bcast:10.230.23.255 Mask:255.255.248.0
inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:530530 errors:0 dropped:0 overruns:0 frame:0
TX packets:1591569 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:68713489 (68.7 MB) TX bytes:213710979 (213.7 MB)
$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr a0:d3:c1:01:9d:58
inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:10539274 errors:0 dropped:3394 overruns:0 frame:454
TX packets:2627412 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2320560616 (2.3 GB) TX bytes:3562885157 (3.5 GB)
Interrupt:32
option interface-mtu 9000; from the lease file is being ignored by br0.
Could it be related to eth0 MTU size? If that's the case, shouldn't both
interfaces be updated?
Other info:
$ brctl show br0
bridge name bridge id STP enabled interfaces
br0 8000.a0d3c1019d58 no eth0
$ cat /etc/network/eth0.config
iface eth0 inet manual
auto br0
iface br0 inet dhcp
bridge_ports eth0
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1403955/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1732703] Re: MAAS does not detect properly if Ubuntu is using upstart/systemd
** Tags removed: verification-needed verification-needed-trusty
** Tags added: verification-done verification-done-trusty
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1732703
Title:
MAAS does not detect properly if Ubuntu is using upstart/systemd
Status in MAAS:
Won't Fix
Status in MAAS 1.9 series:
In Progress
Status in maas package in Ubuntu:
Won't Fix
Status in snapd package in Ubuntu:
Won't Fix
Status in systemd package in Ubuntu:
New
Status in maas source package in Trusty:
Fix Committed
Status in snapd source package in Trusty:
Invalid
Status in systemd source package in Trusty:
New
Bug description:
[impact]
Since Trusty uses upstart by default, MAAS manages its services with upstart.
However, when a user installs systemd (even if it is not used as the init
system), MAAS detects systemd installed and tries to manage its services via
systemd. This obviously creates issues and prevents MAAS from working.
[Test Case]
1. Install & configure MAAS
2. Add machines
3. install systemd
4. MAAS will fail to manage machines
[Regression potential]
Minimal. This just ensures that upstart is detected correctly even if systemd
is installed (but not used).
[Original bug report]
Trusty uses upstart by default, and installing snapd (e.g. for livepatch
purposes), pulls systemd too. In this setup, upstart is _not_ replaced by
systemd, but MAAS "detects" systemd as init because of the existence of
/run/systemd/system:
@src/provisioningserver/utils/__init__.py:505
SYSTEMD_RUN_PATH = '/run/systemd/system'
def get_init_system():
"""Returns 'upstart' or 'systemd'."""
if os.path.exists(SYSTEMD_RUN_PATH):
return 'systemd'
else:
return 'upstart'
One possible solution would be to check if /sbin/init is a symlink
pointing to /lib/systemd/systemd:
def get_init_system():
"""Returns 'upstart' or 'systemd'."""
initpath = os.readlink("/sbin/init")
if (initpath == "/lib/systemd/systemd"):
return 'systemd'
else:
return 'upstart'
Other affected parts of the code are the postinst files for maas-proxy
and maas-dhcp (debian/maas-proxy.postinst debian/maas-dhcp.postinst),
throwing an error if maas is installed after systemd in Trusty
To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1732703/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :
** Description changed: - netbooting the bionic live CD[1] over NFS goes straight to maintenance - mode : + [Impact] + + Mounting manually a network share (NFS) and masking it breaks the state of other units (and their dependencies). + Casper is masking a mounted NFS share, blocking the normal boot process as described in the original description, but the issue comes from systemd. + + [Test Case] + + - NFS mount point at /media + root@iscsi-bionic:/home/ubuntu# mount | grep media + 10.230.56.72:/tmp/mnt on /media type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.127,local_lock=none,addr=10.230.56.72) + + - Test mount point (/test) defined in /etc/fstab: + root@iscsi-bionic:/home/ubuntu# cat /etc/fstab |grep test + tmpfs /test tmpfs nosuid,nodev 0 0 + + 1. If media.mount is not masked, everything works fine: + + root@iscsi-bionic:/home/ubuntu# mount | grep test + root@iscsi-bionic:/home/ubuntu# systemctl status media.mount | grep Active +Active: active (mounted) since Thu 2018-11-15 16:03:59 UTC; 3 weeks 6 days ago + root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active +Active: inactive (dead) since Thu 2018-12-13 10:33:52 UTC; 4min 11s ago + root@iscsi-bionic:/home/ubuntu# systemctl start test.mount + root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active +Active: active (mounted) since Thu 2018-12-13 10:38:13 UTC; 3s ago + root@iscsi-bionic:/home/ubuntu# mount | grep test + tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) + root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount + root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active +Active: inactive (dead) since Thu 2018-12-13 10:38:32 UTC; 3s ago + root@iscsi-bionic:/home/ubuntu# mount | grep test + + 2. If media.mount is masked, other mounts are failing: + + root@iscsi-bionic:/home/ubuntu# systemctl mask media.mount + Created symlink /etc/systemd/system/media.mount → /dev/null. + root@iscsi-bionic:/home/ubuntu# systemctl start test.mount + Job for test.mount failed. + See "systemctl status test.mount" and "journalctl -xe" for details. + root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active +Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 10s ago + root@iscsi-bionic:/home/ubuntu# mount | grep test + tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) + root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount + root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active +Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 25s ago + root@iscsi-bionic:/home/ubuntu# mount | grep test + tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) + root@iscsi-bionic:/home/ubuntu# systemctl start test.mount + Job for test.mount failed. + See "systemctl status test.mount" and "journalctl -xe" for details. + root@iscsi-bionic:/home/ubuntu# mount | grep test + tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) + tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) + root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount + root@iscsi-bionic:/home/ubuntu# mount | grep test + tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) + tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) + + [Regression potential] + + Minimal. Originally, one failing mount point blocked the processing of + the rest due to how the return codes were handled for every line in + /proc/self/mountinfo. This patch removes this "dependency" and keeps the + failure local to the affected mount point, allowing the rest to be + processed normally. + + [Other Info] + + Upstream bug: https://github.com/systemd/systemd/issues/10874 + Fixed upstream with commit: https://github.com/systemd/systemd/commit/c165888426ef99440418592a8cdbaff4b7c319b3 + + [Original Description] + + + netbooting the bionic live CD[1] over NFS goes straight to maintenance mode : [1] http://cdimage.ubuntu.com/daily-live/current/ # casper.log Begin: Adding live session user... ... dbus-daemon[568]: [session uid=999 pid=568] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' (uid=999 pid=569 comm="" label="unconfined") dbus-daemon[568]: [session uid=999 pid=568] Successfully activated service 'org.gtk.vfs.Daemon' dbus-daemon[568]: [session uid=999 pid=568] Activating service name='org.gtk.vfs.Metadata' requested by ':1.0' (uid=999 pid=569 comm="" label="unconfined") fuse: device not found, try 'modprobe fuse' first dbus-daemon[568]: [session uid=999 pid=568] Successfully activated service 'org.gtk.vfs.Metadata' (gvfsd-metadata:580): GUdev-CRITICAL **: 16:28:56.270: g_udev_device_has_property: assertion 'G_UDEV_IS_DEVICE (device)' failed (gvfsd-metadata:580): GUdev-CRITICAL **: 16:28:56.270: g_udev_device_has_property: assertion 'G_UDEV_IS_DEVICE (device)' failed A connection to the bus can't be made done.
[Touch-packages] [Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :
** No longer affects: casper (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1755863 Title: netbooting the bionic live CD over NFS goes straight to maintenance mode : Status in systemd package in Ubuntu: Confirmed Bug description: [Impact] Mounting manually a network share (NFS) and masking it breaks the state of other units (and their dependencies). Casper is masking a mounted NFS share, blocking the normal boot process as described in the original description, but the issue comes from systemd. [Test Case] - NFS mount point at /media root@iscsi-bionic:/home/ubuntu# mount | grep media 10.230.56.72:/tmp/mnt on /media type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.127,local_lock=none,addr=10.230.56.72) - Test mount point (/test) defined in /etc/fstab: root@iscsi-bionic:/home/ubuntu# cat /etc/fstab |grep test tmpfs /test tmpfs nosuid,nodev 0 0 1. If media.mount is not masked, everything works fine: root@iscsi-bionic:/home/ubuntu# mount | grep test root@iscsi-bionic:/home/ubuntu# systemctl status media.mount | grep Active Active: active (mounted) since Thu 2018-11-15 16:03:59 UTC; 3 weeks 6 days ago root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: inactive (dead) since Thu 2018-12-13 10:33:52 UTC; 4min 11s ago root@iscsi-bionic:/home/ubuntu# systemctl start test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: active (mounted) since Thu 2018-12-13 10:38:13 UTC; 3s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: inactive (dead) since Thu 2018-12-13 10:38:32 UTC; 3s ago root@iscsi-bionic:/home/ubuntu# mount | grep test 2. If media.mount is masked, other mounts are failing: root@iscsi-bionic:/home/ubuntu# systemctl mask media.mount Created symlink /etc/systemd/system/media.mount → /dev/null. root@iscsi-bionic:/home/ubuntu# systemctl start test.mount Job for test.mount failed. See "systemctl status test.mount" and "journalctl -xe" for details. root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 10s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 25s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl start test.mount Job for test.mount failed. See "systemctl status test.mount" and "journalctl -xe" for details. root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) [Regression potential] Minimal. Originally, one failing mount point blocked the processing of the rest due to how the return codes were handled for every line in /proc/self/mountinfo. This patch removes this "dependency" and keeps the failure local to the affected mount point, allowing the rest to be processed normally. [Other Info] Upstream bug: https://github.com/systemd/systemd/issues/10874 Fixed upstream with commit: https://github.com/systemd/systemd/commit/c165888426ef99440418592a8cdbaff4b7c319b3 [Original Description] netbooting the bionic live CD[1] over NFS goes straight to maintenance mode : [1] http://cdimage.ubuntu.com/daily-live/current/ # casper.log Begin: Adding live session user... ... dbus-daemon[568]: [session uid=999 pid=568] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' (uid=999 pid=569 comm="" label="unconfined") dbus-daemon[568]: [session uid=999 pid=568] Successfully activated service 'org.gtk.vfs.Daemon' dbus-daemon[568]: [session uid=999 pid=568] Activating service name='org.gtk.vfs.Metadata' requested by ':1.0' (uid=999 pid=569 comm="" label="unconfined") fuse: device not found, try 'modprobe fuse' first dbus-daemon[568]: [session uid=999 pid=568] Successfully activated service 'org.gtk.vfs.Metadata' (gvfsd-metadata:580): GUdev-CRITICAL **: 16:28:56.270:
[Touch-packages] [Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :
** Patch added: "disco-stop-mount-error-propagation.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1755863/+attachment/5222912/+files/disco-stop-mount-error-propagation.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1755863 Title: netbooting the bionic live CD over NFS goes straight to maintenance mode : Status in systemd package in Ubuntu: Confirmed Bug description: [Impact] Mounting manually a network share (NFS) and masking it breaks the state of other units (and their dependencies). Casper is masking a mounted NFS share, blocking the normal boot process as described in the original description, but the issue comes from systemd. [Test Case] - NFS mount point at /media root@iscsi-bionic:/home/ubuntu# mount | grep media 10.230.56.72:/tmp/mnt on /media type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.127,local_lock=none,addr=10.230.56.72) - Test mount point (/test) defined in /etc/fstab: root@iscsi-bionic:/home/ubuntu# cat /etc/fstab |grep test tmpfs /test tmpfs nosuid,nodev 0 0 1. If media.mount is not masked, everything works fine: root@iscsi-bionic:/home/ubuntu# mount | grep test root@iscsi-bionic:/home/ubuntu# systemctl status media.mount | grep Active Active: active (mounted) since Thu 2018-11-15 16:03:59 UTC; 3 weeks 6 days ago root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: inactive (dead) since Thu 2018-12-13 10:33:52 UTC; 4min 11s ago root@iscsi-bionic:/home/ubuntu# systemctl start test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: active (mounted) since Thu 2018-12-13 10:38:13 UTC; 3s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: inactive (dead) since Thu 2018-12-13 10:38:32 UTC; 3s ago root@iscsi-bionic:/home/ubuntu# mount | grep test 2. If media.mount is masked, other mounts are failing: root@iscsi-bionic:/home/ubuntu# systemctl mask media.mount Created symlink /etc/systemd/system/media.mount → /dev/null. root@iscsi-bionic:/home/ubuntu# systemctl start test.mount Job for test.mount failed. See "systemctl status test.mount" and "journalctl -xe" for details. root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 10s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 25s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl start test.mount Job for test.mount failed. See "systemctl status test.mount" and "journalctl -xe" for details. root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) [Regression potential] Minimal. Originally, one failing mount point blocked the processing of the rest due to how the return codes were handled for every line in /proc/self/mountinfo. This patch removes this "dependency" and keeps the failure local to the affected mount point, allowing the rest to be processed normally. [Other Info] Upstream bug: https://github.com/systemd/systemd/issues/10874 Fixed upstream with commit: https://github.com/systemd/systemd/commit/c165888426ef99440418592a8cdbaff4b7c319b3 [Original Description] netbooting the bionic live CD[1] over NFS goes straight to maintenance mode : [1] http://cdimage.ubuntu.com/daily-live/current/ # casper.log Begin: Adding live session user... ... dbus-daemon[568]: [session uid=999 pid=568] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' (uid=999 pid=569 comm="" label="unconfined") dbus-daemon[568]: [session uid=999 pid=568] Successfully activated service 'org.gtk.vfs.Daemon' dbus-daemon[568]: [session uid=999 pid=568] Activating service name='org.gtk.vfs.Metadata' requested by ':1.0' (uid=999 pid=569 comm="" label="unconfined") fuse: device not found, try 'modprobe fuse' first dbus-daemon[568]:
[Touch-packages] [Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :
Hi, I'm working on the patches for Disco, Cosmic, Bionic and Xenial. It's not in Disco yet, but the fix process will be tracked in this bug. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1755863 Title: netbooting the bionic live CD over NFS goes straight to maintenance mode : Status in systemd package in Ubuntu: Confirmed Bug description: [Impact] Mounting manually a network share (NFS) and masking it breaks the state of other units (and their dependencies). Casper is masking a mounted NFS share, blocking the normal boot process as described in the original description, but the issue comes from systemd. [Test Case] - NFS mount point at /media root@iscsi-bionic:/home/ubuntu# mount | grep media 10.230.56.72:/tmp/mnt on /media type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.127,local_lock=none,addr=10.230.56.72) - Test mount point (/test) defined in /etc/fstab: root@iscsi-bionic:/home/ubuntu# cat /etc/fstab |grep test tmpfs /test tmpfs nosuid,nodev 0 0 1. If media.mount is not masked, everything works fine: root@iscsi-bionic:/home/ubuntu# mount | grep test root@iscsi-bionic:/home/ubuntu# systemctl status media.mount | grep Active Active: active (mounted) since Thu 2018-11-15 16:03:59 UTC; 3 weeks 6 days ago root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: inactive (dead) since Thu 2018-12-13 10:33:52 UTC; 4min 11s ago root@iscsi-bionic:/home/ubuntu# systemctl start test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: active (mounted) since Thu 2018-12-13 10:38:13 UTC; 3s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: inactive (dead) since Thu 2018-12-13 10:38:32 UTC; 3s ago root@iscsi-bionic:/home/ubuntu# mount | grep test 2. If media.mount is masked, other mounts are failing: root@iscsi-bionic:/home/ubuntu# systemctl mask media.mount Created symlink /etc/systemd/system/media.mount → /dev/null. root@iscsi-bionic:/home/ubuntu# systemctl start test.mount Job for test.mount failed. See "systemctl status test.mount" and "journalctl -xe" for details. root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 10s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 25s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl start test.mount Job for test.mount failed. See "systemctl status test.mount" and "journalctl -xe" for details. root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) [Regression potential] Minimal. Originally, one failing mount point blocked the processing of the rest due to how the return codes were handled for every line in /proc/self/mountinfo. This patch removes this "dependency" and keeps the failure local to the affected mount point, allowing the rest to be processed normally. [Other Info] Upstream bug: https://github.com/systemd/systemd/issues/10874 Fixed upstream with commit: https://github.com/systemd/systemd/commit/c165888426ef99440418592a8cdbaff4b7c319b3 [Original Description] netbooting the bionic live CD[1] over NFS goes straight to maintenance mode : [1] http://cdimage.ubuntu.com/daily-live/current/ # casper.log Begin: Adding live session user... ... dbus-daemon[568]: [session uid=999 pid=568] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' (uid=999 pid=569 comm="" label="unconfined") dbus-daemon[568]: [session uid=999 pid=568] Successfully activated service 'org.gtk.vfs.Daemon' dbus-daemon[568]: [session uid=999 pid=568] Activating service name='org.gtk.vfs.Metadata' requested by ':1.0' (uid=999 pid=569 comm="" label="unconfined") fuse: device not found, try 'modprobe fuse' first dbus-daemon[568]: [session uid=999 pid=568] Successfully activated service
[Touch-packages] [Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :
** Patch added: "xenial-stop-mount-error-propagation.debdiff" https://bugs.launchpad.net/ubuntu/cosmic/+source/systemd/+bug/1755863/+attachment/5223751/+files/xenial-stop-mount-error-propagation.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1755863 Title: netbooting the bionic live CD over NFS goes straight to maintenance mode : Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: [Impact] Mounting manually a network share (NFS) and masking it breaks the state of other units (and their dependencies). Casper is masking a mounted NFS share, blocking the normal boot process as described in the original description, but the issue comes from systemd. [Test Case] - NFS mount point at /media root@iscsi-bionic:/home/ubuntu# mount | grep media 10.230.56.72:/tmp/mnt on /media type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.127,local_lock=none,addr=10.230.56.72) - Test mount point (/test) defined in /etc/fstab: root@iscsi-bionic:/home/ubuntu# cat /etc/fstab |grep test tmpfs /test tmpfs nosuid,nodev 0 0 1. If media.mount is not masked, everything works fine: root@iscsi-bionic:/home/ubuntu# mount | grep test root@iscsi-bionic:/home/ubuntu# systemctl status media.mount | grep Active Active: active (mounted) since Thu 2018-11-15 16:03:59 UTC; 3 weeks 6 days ago root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: inactive (dead) since Thu 2018-12-13 10:33:52 UTC; 4min 11s ago root@iscsi-bionic:/home/ubuntu# systemctl start test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: active (mounted) since Thu 2018-12-13 10:38:13 UTC; 3s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: inactive (dead) since Thu 2018-12-13 10:38:32 UTC; 3s ago root@iscsi-bionic:/home/ubuntu# mount | grep test 2. If media.mount is masked, other mounts are failing: root@iscsi-bionic:/home/ubuntu# systemctl mask media.mount Created symlink /etc/systemd/system/media.mount → /dev/null. root@iscsi-bionic:/home/ubuntu# systemctl start test.mount Job for test.mount failed. See "systemctl status test.mount" and "journalctl -xe" for details. root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 10s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 25s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl start test.mount Job for test.mount failed. See "systemctl status test.mount" and "journalctl -xe" for details. root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) [Regression potential] Minimal. Originally, one failing mount point blocked the processing of the rest due to how the return codes were handled for every line in /proc/self/mountinfo. This patch removes this "dependency" and keeps the failure local to the affected mount point, allowing the rest to be processed normally. [Other Info] Upstream bug: https://github.com/systemd/systemd/issues/10874 Fixed upstream with commit: https://github.com/systemd/systemd/commit/c165888426ef99440418592a8cdbaff4b7c319b3 [Original Description] netbooting the bionic live CD[1] over NFS goes straight to maintenance mode : [1] http://cdimage.ubuntu.com/daily-live/current/ # casper.log Begin: Adding live session user... ... dbus-daemon[568]: [session uid=999 pid=568] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' (uid=999 pid=569 comm="" label="unconfined") dbus-daemon[568]: [session uid=999 pid=568] Successfully activated service
[Touch-packages] [Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :
** Patch added: "bionic-stop-mount-error-propagation.debdiff" https://bugs.launchpad.net/ubuntu/cosmic/+source/systemd/+bug/1755863/+attachment/5223753/+files/bionic-stop-mount-error-propagation.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1755863 Title: netbooting the bionic live CD over NFS goes straight to maintenance mode : Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: [Impact] Mounting manually a network share (NFS) and masking it breaks the state of other units (and their dependencies). Casper is masking a mounted NFS share, blocking the normal boot process as described in the original description, but the issue comes from systemd. [Test Case] - NFS mount point at /media root@iscsi-bionic:/home/ubuntu# mount | grep media 10.230.56.72:/tmp/mnt on /media type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.127,local_lock=none,addr=10.230.56.72) - Test mount point (/test) defined in /etc/fstab: root@iscsi-bionic:/home/ubuntu# cat /etc/fstab |grep test tmpfs /test tmpfs nosuid,nodev 0 0 1. If media.mount is not masked, everything works fine: root@iscsi-bionic:/home/ubuntu# mount | grep test root@iscsi-bionic:/home/ubuntu# systemctl status media.mount | grep Active Active: active (mounted) since Thu 2018-11-15 16:03:59 UTC; 3 weeks 6 days ago root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: inactive (dead) since Thu 2018-12-13 10:33:52 UTC; 4min 11s ago root@iscsi-bionic:/home/ubuntu# systemctl start test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: active (mounted) since Thu 2018-12-13 10:38:13 UTC; 3s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: inactive (dead) since Thu 2018-12-13 10:38:32 UTC; 3s ago root@iscsi-bionic:/home/ubuntu# mount | grep test 2. If media.mount is masked, other mounts are failing: root@iscsi-bionic:/home/ubuntu# systemctl mask media.mount Created symlink /etc/systemd/system/media.mount → /dev/null. root@iscsi-bionic:/home/ubuntu# systemctl start test.mount Job for test.mount failed. See "systemctl status test.mount" and "journalctl -xe" for details. root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 10s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 25s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl start test.mount Job for test.mount failed. See "systemctl status test.mount" and "journalctl -xe" for details. root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) [Regression potential] Minimal. Originally, one failing mount point blocked the processing of the rest due to how the return codes were handled for every line in /proc/self/mountinfo. This patch removes this "dependency" and keeps the failure local to the affected mount point, allowing the rest to be processed normally. [Other Info] Upstream bug: https://github.com/systemd/systemd/issues/10874 Fixed upstream with commit: https://github.com/systemd/systemd/commit/c165888426ef99440418592a8cdbaff4b7c319b3 [Original Description] netbooting the bionic live CD[1] over NFS goes straight to maintenance mode : [1] http://cdimage.ubuntu.com/daily-live/current/ # casper.log Begin: Adding live session user... ... dbus-daemon[568]: [session uid=999 pid=568] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' (uid=999 pid=569 comm="" label="unconfined") dbus-daemon[568]: [session uid=999 pid=568] Successfully activated service
[Touch-packages] [Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :
** Patch added: "cosmic-stop-mount-error-propagation.debdiff" https://bugs.launchpad.net/ubuntu/cosmic/+source/systemd/+bug/1755863/+attachment/5223752/+files/cosmic-stop-mount-error-propagation.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1755863 Title: netbooting the bionic live CD over NFS goes straight to maintenance mode : Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: [Impact] Mounting manually a network share (NFS) and masking it breaks the state of other units (and their dependencies). Casper is masking a mounted NFS share, blocking the normal boot process as described in the original description, but the issue comes from systemd. [Test Case] - NFS mount point at /media root@iscsi-bionic:/home/ubuntu# mount | grep media 10.230.56.72:/tmp/mnt on /media type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.127,local_lock=none,addr=10.230.56.72) - Test mount point (/test) defined in /etc/fstab: root@iscsi-bionic:/home/ubuntu# cat /etc/fstab |grep test tmpfs /test tmpfs nosuid,nodev 0 0 1. If media.mount is not masked, everything works fine: root@iscsi-bionic:/home/ubuntu# mount | grep test root@iscsi-bionic:/home/ubuntu# systemctl status media.mount | grep Active Active: active (mounted) since Thu 2018-11-15 16:03:59 UTC; 3 weeks 6 days ago root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: inactive (dead) since Thu 2018-12-13 10:33:52 UTC; 4min 11s ago root@iscsi-bionic:/home/ubuntu# systemctl start test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: active (mounted) since Thu 2018-12-13 10:38:13 UTC; 3s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: inactive (dead) since Thu 2018-12-13 10:38:32 UTC; 3s ago root@iscsi-bionic:/home/ubuntu# mount | grep test 2. If media.mount is masked, other mounts are failing: root@iscsi-bionic:/home/ubuntu# systemctl mask media.mount Created symlink /etc/systemd/system/media.mount → /dev/null. root@iscsi-bionic:/home/ubuntu# systemctl start test.mount Job for test.mount failed. See "systemctl status test.mount" and "journalctl -xe" for details. root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 10s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# systemctl status test.mount | grep Active Active: failed (Result: protocol) since Thu 2018-12-13 10:40:06 UTC; 25s ago root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl start test.mount Job for test.mount failed. See "systemctl status test.mount" and "journalctl -xe" for details. root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) root@iscsi-bionic:/home/ubuntu# systemctl stop test.mount root@iscsi-bionic:/home/ubuntu# mount | grep test tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /test type tmpfs (rw,nosuid,nodev,relatime) [Regression potential] Minimal. Originally, one failing mount point blocked the processing of the rest due to how the return codes were handled for every line in /proc/self/mountinfo. This patch removes this "dependency" and keeps the failure local to the affected mount point, allowing the rest to be processed normally. [Other Info] Upstream bug: https://github.com/systemd/systemd/issues/10874 Fixed upstream with commit: https://github.com/systemd/systemd/commit/c165888426ef99440418592a8cdbaff4b7c319b3 [Original Description] netbooting the bionic live CD[1] over NFS goes straight to maintenance mode : [1] http://cdimage.ubuntu.com/daily-live/current/ # casper.log Begin: Adding live session user... ... dbus-daemon[568]: [session uid=999 pid=568] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' (uid=999 pid=569 comm="" label="unconfined") dbus-daemon[568]: [session uid=999 pid=568] Successfully activated service
[Touch-packages] [Bug 1804487] Re: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled
## VERIFICATION DISCO - Before the fix: ubuntu@disco:~$ dpkg -l | grep "ii systemd " ii systemd 239-7ubuntu10 amd64 system and service manager #EDNS query ubuntu@disco:~$ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 #No EDNS query falling back to TCP ubuntu@disco:~$ dig +noall +answer +noedns testing.irongiantdesign.com @127.0.0.53 | wc -l 29 #No EDNS query ignoring the truncate flag (stick to UDP only) ubuntu@disco:~$ dig +noall +answer +noedns +ignore testing.irongiantdesign.com @127.0.0.53 | wc -l 29 - With the fix: ubuntu@disco:~$ dpkg -l | grep "ii systemd " ii systemd 239-7ubuntu15 amd64 system and service manager #EDNS query ubuntu@disco:~$ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 #No EDNS query falling back to TCP ubuntu@disco:~$ dig +noall +answer +noedns testing.irongiantdesign.com @127.0.0.53 | wc -l 30 #No EDNS query ignoring the truncate flag (stick to UDP only) ubuntu@disco:~$ dig +noall +answer +noedns +ignore testing.irongiantdesign.com @127.0.0.53 | wc -l 29 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1804487 Title: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Committed Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: Fix Committed Status in systemd package in Debian: Fix Released Bug description: [Impact] TCP stub is cutting down the payload to 512 bytes when EDNS is disabled. This makes non-EDNS clients (nslookup) receive a "shortened" answer even when UDP returns a truncated reply for a new TCP query. For instance, - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 In the second case, no-EDNS, TCP should provide the complete answer, but it's capped at UDP's size. [Test Case] Query systemd-resolved with a domain name that resolves to multiple (lots.. 30+) A records. A client with EDNS support (dig) will receive all of them, a client without support (nslookup or dig +noedns) will have a truncated list. Using the example above: EDNS: dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l non-EDNS: dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l [Regression potential] Minimal. This change only affects TCP requests, and the new size is already used in the code for other requests. [Other Info] Upstream bug: https://github.com/systemd/systemd/issues/10816 Fixed upstream with commit: https://github.com/systemd/systemd/commit/e6eed9445956cfa496e1db933bfd3530db23bfce [Original Description] Querying a domain name that has >512 bytes in records (e.g. 30+ A records), the number of results depends on the DNS client used: - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 Normally a client that doesn't support EDNS would receive a truncated reply from the initial UDP connection (limited by the spec to 512 bytes) and a second query would be established via TCP to receive the complete results. In this case, the number of results is the same regardless of the protocol used (29). Upstream bug: https://github.com/systemd/systemd/issues/10816 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1804487/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1804487] Re: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled
** Patch added: "systemd-TCP-size-disco.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804487/+attachment/5217391/+files/systemd-TCP-size-disco.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1804487 Title: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: [Impact] TCP stub is cutting down the payload to 512 bytes when EDNS is disabled. This makes non-EDNS clients (nslookup) receive a "shortened" answer even when UDP returns a truncated reply for a new TCP query. For instance, - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 In the second case, no-EDNS, TCP should provide the complete answer, but it's capped at UDP's size. [Test Case] Query systemd-resolved with a domain name that resolves to multiple (lots.. 30+) A records. A client with EDNS support (dig) will receive all of them, a client without support (nslookup or dig +noedns) will have a truncated list. Using the example above: EDNS: dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l non-EDNS: dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l [Regression potential] Minimal. This change only affects TCP requests, and the new size is already used in the code for other requests. [Other Info] Upstream bug: https://github.com/systemd/systemd/issues/10816 Fixed upstream with commit: https://github.com/systemd/systemd/commit/e6eed9445956cfa496e1db933bfd3530db23bfce [Original Description] Querying a domain name that has >512 bytes in records (e.g. 30+ A records), the number of results depends on the DNS client used: - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 Normally a client that doesn't support EDNS would receive a truncated reply from the initial UDP connection (limited by the spec to 512 bytes) and a second query would be established via TCP to receive the complete results. In this case, the number of results is the same regardless of the protocol used (29). Upstream bug: https://github.com/systemd/systemd/issues/10816 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804487/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1804487] Re: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled
** Patch added: "systemd-TCP-size-cosmic.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804487/+attachment/5217390/+files/systemd-TCP-size-cosmic.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1804487 Title: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: [Impact] TCP stub is cutting down the payload to 512 bytes when EDNS is disabled. This makes non-EDNS clients (nslookup) receive a "shortened" answer even when UDP returns a truncated reply for a new TCP query. For instance, - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 In the second case, no-EDNS, TCP should provide the complete answer, but it's capped at UDP's size. [Test Case] Query systemd-resolved with a domain name that resolves to multiple (lots.. 30+) A records. A client with EDNS support (dig) will receive all of them, a client without support (nslookup or dig +noedns) will have a truncated list. Using the example above: EDNS: dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l non-EDNS: dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l [Regression potential] Minimal. This change only affects TCP requests, and the new size is already used in the code for other requests. [Other Info] Upstream bug: https://github.com/systemd/systemd/issues/10816 Fixed upstream with commit: https://github.com/systemd/systemd/commit/e6eed9445956cfa496e1db933bfd3530db23bfce [Original Description] Querying a domain name that has >512 bytes in records (e.g. 30+ A records), the number of results depends on the DNS client used: - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 Normally a client that doesn't support EDNS would receive a truncated reply from the initial UDP connection (limited by the spec to 512 bytes) and a second query would be established via TCP to receive the complete results. In this case, the number of results is the same regardless of the protocol used (29). Upstream bug: https://github.com/systemd/systemd/issues/10816 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804487/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1804487] Re: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled
** Description changed: + [Impact] + + TCP stub is cutting down the payload to 512 bytes when EDNS is disabled. + This makes non-EDNS clients (nslookup) receive a "shortened" answer even + when UDP returns a truncated reply for a new TCP query. For instance, + + - If the client supports EDNS: + + $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l + 30 + + - If the client does not support EDNS: + + $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l + 29 + + In the second case, no-EDNS, TCP should provide the complete answer, but + it's capped at UDP's size. + + [Test Case] + + Query systemd-resolved with a domain name that resolves to multiple + (lots.. 30+) A records. A client with EDNS support (dig) will receive + all of them, a client without support (nslookup or dig +noedns) will + have a truncated list. + + [Regression potential] + + Minimal. This change only affects TCP requests, and the new size is + already used in the code for other requests. + + [Other Info] + + Upstream bug: https://github.com/systemd/systemd/issues/10816 + Fixed upstream with commit: https://github.com/systemd/systemd/commit/e6eed9445956cfa496e1db933bfd3530db23bfce + + [Original Description] + Querying a domain name that has >512 bytes in records (e.g. 30+ A records), the number of results depends on the DNS client used: - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l - 30 + 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 Normally a client that doesn't support EDNS would receive a truncated reply from the initial UDP connection (limited by the spec to 512 bytes) and a second query would be established via TCP to receive the complete results. In this case, the number of results is the same regardless of the protocol used (29). Upstream bug: https://github.com/systemd/systemd/issues/10816 ** Description changed: [Impact] TCP stub is cutting down the payload to 512 bytes when EDNS is disabled. This makes non-EDNS clients (nslookup) receive a "shortened" answer even when UDP returns a truncated reply for a new TCP query. For instance, - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 In the second case, no-EDNS, TCP should provide the complete answer, but it's capped at UDP's size. [Test Case] Query systemd-resolved with a domain name that resolves to multiple (lots.. 30+) A records. A client with EDNS support (dig) will receive all of them, a client without support (nslookup or dig +noedns) will - have a truncated list. + have a truncated list. Using the example above: + + EDNS: dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l + non-EDNS: dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l [Regression potential] Minimal. This change only affects TCP requests, and the new size is already used in the code for other requests. [Other Info] Upstream bug: https://github.com/systemd/systemd/issues/10816 Fixed upstream with commit: https://github.com/systemd/systemd/commit/e6eed9445956cfa496e1db933bfd3530db23bfce [Original Description] Querying a domain name that has >512 bytes in records (e.g. 30+ A records), the number of results depends on the DNS client used: - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 Normally a client that doesn't support EDNS would receive a truncated reply from the initial UDP connection (limited by the spec to 512 bytes) and a second query would be established via TCP to receive the complete results. In this case, the number of results is the same regardless of the protocol used (29). Upstream bug: https://github.com/systemd/systemd/issues/10816 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1804487 Title: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: [Impact] TCP stub is cutting down the payload to 512 bytes when EDNS is disabled. This makes non-EDNS clients (nslookup) receive a "shortened" answer even
[Touch-packages] [Bug 1804487] Re: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled
** Patch added: "systemd-TCP-size-bionic.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804487/+attachment/5217389/+files/systemd-TCP-size-bionic.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1804487 Title: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: [Impact] TCP stub is cutting down the payload to 512 bytes when EDNS is disabled. This makes non-EDNS clients (nslookup) receive a "shortened" answer even when UDP returns a truncated reply for a new TCP query. For instance, - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 In the second case, no-EDNS, TCP should provide the complete answer, but it's capped at UDP's size. [Test Case] Query systemd-resolved with a domain name that resolves to multiple (lots.. 30+) A records. A client with EDNS support (dig) will receive all of them, a client without support (nslookup or dig +noedns) will have a truncated list. Using the example above: EDNS: dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l non-EDNS: dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l [Regression potential] Minimal. This change only affects TCP requests, and the new size is already used in the code for other requests. [Other Info] Upstream bug: https://github.com/systemd/systemd/issues/10816 Fixed upstream with commit: https://github.com/systemd/systemd/commit/e6eed9445956cfa496e1db933bfd3530db23bfce [Original Description] Querying a domain name that has >512 bytes in records (e.g. 30+ A records), the number of results depends on the DNS client used: - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 Normally a client that doesn't support EDNS would receive a truncated reply from the initial UDP connection (limited by the spec to 512 bytes) and a second query would be established via TCP to receive the complete results. In this case, the number of results is the same regardless of the protocol used (29). Upstream bug: https://github.com/systemd/systemd/issues/10816 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804487/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1804487] [NEW] systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled
Public bug reported: Querying a domain name that has >512 bytes in records (e.g. 30+ A records), the number of results depends on the DNS client used: - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 Normally a client that doesn't support EDNS would receive a truncated reply from the initial UDP connection (limited by the spec to 512 bytes) and a second query would be established via TCP to receive the complete results. In this case, the number of results is the same regardless of the protocol used (29). Upstream bug: https://github.com/systemd/systemd/issues/10816 ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: sts -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1804487 Title: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled Status in systemd package in Ubuntu: New Bug description: Querying a domain name that has >512 bytes in records (e.g. 30+ A records), the number of results depends on the DNS client used: - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 Normally a client that doesn't support EDNS would receive a truncated reply from the initial UDP connection (limited by the spec to 512 bytes) and a second query would be established via TCP to receive the complete results. In this case, the number of results is the same regardless of the protocol used (29). Upstream bug: https://github.com/systemd/systemd/issues/10816 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1804487/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1368411] Re: Cannot insert IPV6 rule before IPV4 rules
The fix works as expected in B/C: #COSMIC ubuntu@c-ufw:~$ dpkg -l | grep ufw ii ufw 0.36-0ubuntu0.18.10.1 all program for managing a Netfilter firewall ubuntu@c-ufw:~$ sudo ufw status numbered Status: active To Action From -- -- [ 1] 22/tcp ALLOW INAnywhere [ 2] Anywhere ALLOW IN1.2.3.4 [ 3] 22/tcp (v6)ALLOW INAnywhere (v6) [ 4] Anywhere (v6) ALLOW IN2001:db8::/32 ubuntu@c-ufw:~$ sudo ufw prepend deny from 6.7.8.9 Rule inserted ubuntu@c-ufw:~$ sudo ufw prepend deny from 2a02:2210:12:a:b820:fff:fea2:25d1 Rule inserted (v6) ubuntu@c-ufw:~$ sudo ufw status numbered Status: active To Action From -- -- [ 1] Anywhere DENY IN 6.7.8.9 [ 2] 22/tcp ALLOW INAnywhere [ 3] Anywhere ALLOW IN1.2.3.4 [ 4] Anywhere (v6) DENY IN 2a02:2210:12:a:b820:fff:fea2:25d1 [ 5] 22/tcp (v6)ALLOW INAnywhere (v6) [ 6] Anywhere (v6) ALLOW IN2001:db8::/32 #BIONIC ubuntu@b-ufw:~$ dpkg -l | grep ufw ii ufw 0.36-0ubuntu0.18.04.1 all program for managing a Netfilter firewall ubuntu@b-ufw:~$ sudo ufw status numbered Status: active To Action From -- -- [ 1] 22/tcp ALLOW INAnywhere [ 2] Anywhere ALLOW IN1.2.3.4 [ 3] 22/tcp (v6)ALLOW INAnywhere (v6) [ 4] Anywhere (v6) ALLOW IN2001:db8::/32 ubuntu@b-ufw:~$ sudo ufw prepend allow from 2001:db8::/32 Skipping inserting existing rule (v6) ubuntu@b-ufw:~$ sudo ufw status numbered Status: active To Action From -- -- [ 1] 22/tcp ALLOW INAnywhere [ 2] Anywhere ALLOW IN1.2.3.4 [ 3] 22/tcp (v6)ALLOW INAnywhere (v6) [ 4] Anywhere (v6) ALLOW IN2001:db8::/32 ubuntu@b-ufw:~$ sudo ufw prepend deny from 6.7.8.9 Rule inserted ubuntu@b-ufw:~$ sudo ufw prepend deny from 2a02:2210:12:a:b820:fff:fea2:25d1 Rule inserted (v6) ubuntu@b-ufw:~$ sudo ufw status numbered Status: active To Action From -- -- [ 1] Anywhere DENY IN 6.7.8.9 [ 2] 22/tcp ALLOW INAnywhere [ 3] Anywhere ALLOW IN1.2.3.4 [ 4] Anywhere (v6) DENY IN 2a02:2210:12:a:b820:fff:fea2:25d1 [ 5] 22/tcp (v6)ALLOW INAnywhere (v6) [ 6] Anywhere (v6) ALLOW IN2001:db8::/32 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1368411 Title: Cannot insert IPV6 rule before IPV4 rules Status in ufw: Fix Released Status in ufw package in Ubuntu: Fix Released Status in ufw source package in Bionic: Fix Committed Status in ufw source package in Cosmic: Fix Committed Status in ufw source package in Disco: Fix Released Status in ufw package in Debian: Fix Released Bug description: [Impact] ufw's 'insert' command is designed to work with 'ufw status numbered' to insert rules in specific places in the ruleset. This makes it more difficult than it should be for using ufw as part of an IPS/dynamic firewall (eg, fail2ban) since if the firewall already has an IPv4 rule then the user/IPS must calculate the position of an IPv6-only rule before inserting it. From the git commit: " add 'prepend' command Introduce 'prepend' command to add rules to the top of the IPv4 and/or IPv6 chains. This is particularly useful for dynamic firewalls/IPS (eg, fail2ban). Unlike 'insert', 'prepend' does not require knowledge about the IPv6 rule number so integration into IPS is much easier. " [Test Case] $ sudo ufw allow 22/tcp $ sudo ufw allow from 1.2.3.4 $ sudo ufw allow from 2001:db8::/32 $ sudo ufw enable $ sudo ufw status numbered ... [ 1] 22/tcp ALLOW INAnywhere [ 2] Anywhere ALLOW IN1.2.3.4 [ 3] 22/tcp (v6)ALLOW INAnywhere (v6) [ 4] Anywhere (v6) ALLOW IN2001:db8::/32 # unchanged from 0.35 $ sudo ufw insert 1
[Touch-packages] [Bug 1822062] [NEW] Race condition on boot between cups and sssd
Public bug reported: When cups has set the "SystemGroup" directive to an external group provided through sss and cups starts before sssd has finished booting, cups will crash because the group does not exist. For instance, with a group named lpadmins@tests.local served from Active Directory through sssd, if the sssd service hasn't booted before cups: Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unable to read "/etc/cups/cups-files.conf" due to errors. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Failed with result 'exit-code'. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Service hold-off time over, scheduling restart. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Scheduled restart job, restart counter is at 2. Mar 27 10:10:33 cups-sssd systemd[1]: Stopping Make remote CUPS printers available locally... Mar 27 10:10:33 cups-sssd systemd[1]: Stopped Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd systemd[1]: Stopped CUPS Scheduler. If sssd is running before cups starts, everything works as expected. ** Affects: cups (Ubuntu) Importance: Undecided Status: New ** Tags: sts -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1822062 Title: Race condition on boot between cups and sssd Status in cups package in Ubuntu: New Bug description: When cups has set the "SystemGroup" directive to an external group provided through sss and cups starts before sssd has finished booting, cups will crash because the group does not exist. For instance, with a group named lpadmins@tests.local served from Active Directory through sssd, if the sssd service hasn't booted before cups: Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unable to read "/etc/cups/cups-files.conf" due to errors. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Failed with result 'exit-code'. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Service hold-off time over, scheduling restart. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Scheduled restart job, restart counter is at 2. Mar 27 10:10:33 cups-sssd systemd[1]: Stopping Make remote CUPS printers available locally... Mar 27 10:10:33 cups-sssd systemd[1]: Stopped Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd systemd[1]: Stopped CUPS Scheduler. If sssd is running before cups starts, everything works as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1822062/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822062] Re: Race condition on boot between cups and sssd
# VERIFICATION: XENIAL - Using the reproducer defined in the test case and the version in -updates: ubuntu@xenial-sssd-ad:~$ dpkg -l | grep -E "cups-daemon| cups |cups-common" ii cups 2.1.3-4ubuntu0.7 amd64Common UNIX Printing System(tm) - PPD/driver support, web interface ii cups-common 2.1.3-4ubuntu0.7 all Common UNIX Printing System(tm) - common files ii cups-daemon 2.1.3-4ubuntu0.7 amd64Common UNIX Printing System(tm) - daemon ubuntu@xenial-sssd-ad:~$ grep -i systemgroup /etc/cups/cups-files.conf SystemGroup lpadmins@TESTS.LOCAL ubuntu@xenial-sssd-ad:~$ systemd-analyze critical-chain cups.service The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. cups.service @5d 44min 12.341s └─basic.target @35.619s └─sockets.target @35.617s └─lxd.socket @35.592s +11ms └─sysinit.target @35.463s └─cloud-init.service @31.929s +3.152s └─networking.service @15.375s +16.549s └─network-pre.target @15.326s └─cloud-init-local.service @6.646s +8.677s └─systemd-remount-fs.service @5.484s +342ms └─system.slice @5.461s └─-.slice @5.389s - After reboot, cups fails to start: ubuntu@xenial-sssd-ad:~$ systemctl status cups ● cups.service - CUPS Scheduler Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: failed (Result: start-limit-hit) since Tue 2019-05-07 10:06:07 UTC; 1min 57s ago Docs: man:cupsd(8) Process: 1152 ExecStart=/usr/sbin/cupsd -l (code=exited, status=1/FAILURE) Main PID: 1152 (code=exited, status=1/FAILURE) May 07 10:06:07 xenial-sssd-ad systemd[1]: cups.service: Failed with result 'exit-code'. May 07 10:06:07 xenial-sssd-ad systemd[1]: Started CUPS Scheduler. May 07 10:06:07 xenial-sssd-ad cupsd[1152]: Unknown SystemGroup "lpadmins@TESTS.LOCAL" on line 19 of /etc/ May 07 10:06:07 xenial-sssd-ad cupsd[1152]: Unable to read "/etc/cups/cups-files.conf" due to errors. May 07 10:06:07 xenial-sssd-ad systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILUR May 07 10:06:07 xenial-sssd-ad systemd[1]: cups.service: Unit entered failed state. May 07 10:06:07 xenial-sssd-ad systemd[1]: cups.service: Failed with result 'exit-code'. May 07 10:06:07 xenial-sssd-ad systemd[1]: cups.service: Start request repeated too quickly. May 07 10:06:07 xenial-sssd-ad systemd[1]: Failed to start CUPS Scheduler. May 07 10:06:07 xenial-sssd-ad systemd[1]: cups.service: Failed with result 'start-limit-hit'. - Using the version in -proposed, after rebooting: ubuntu@xenial-sssd-ad:~$ dpkg -l | grep -E "cups-daemon| cups |cups-common" ii cups 2.1.3-4ubuntu0.8 amd64Common UNIX Printing System(tm) - PPD/driver support, web interface ii cups-common 2.1.3-4ubuntu0.8 all Common UNIX Printing System(tm) - common files ii cups-daemon 2.1.3-4ubuntu0.8 amd64Common UNIX Printing System(tm) - daemon ubuntu@xenial-sssd-ad:~$ systemctl status cups ● cups.service - CUPS Scheduler Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2019-05-07 10:14:10 UTC; 2min 20s ago Docs: man:cupsd(8) Main PID: 1276 (cupsd) Tasks: 1 Memory: 2.1M CPU: 12ms CGroup: /system.slice/cups.service └─1276 /usr/sbin/cupsd -l May 07 10:14:10 xenial-sssd-ad systemd[1]: Started CUPS Scheduler. ubuntu@xenial-sssd-ad:~$ systemd-analyze critical-chain cups.service The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. cups.service @32.661s └─sssd.service @29.252s +3.393s └─basic.target @29.247s └─sockets.target @29.245s └─lxd.socket @29.225s +10ms └─sysinit.target @29.117s └─cloud-init.service @26.685s +2.416s └─networking.service @11.315s +15.364s └─network-pre.target @11.301s └─cloud-init-local.service @3.841s +7.457s └─systemd-remount-fs.service @3.084s +278ms └─systemd-journald.socket @3.036s └─-.slice @2.984s - Using the version in -proposed, with sssd not installed in the machine (and setting SystemGroup to the original local group "lpadmin"), cups still starts: buntu@xenial-sssd-ad:~$ systemctl status cups ● cups.service - CUPS Scheduler Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2019-05-07 10:18:50 UTC;
[Touch-packages] [Bug 1822062] Re: Race condition on boot between cups and sssd
** Tags removed: verification-needed verification-needed-disco ** Tags added: verification-done verification-done-disco -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1822062 Title: Race condition on boot between cups and sssd Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: Fix Committed Status in cups source package in Bionic: Fix Committed Status in cups source package in Cosmic: Fix Committed Status in cups source package in Disco: Fix Committed Status in cups source package in Eoan: Fix Released Bug description: [Impact] * When cups has set the "SystemGroup" directive to an external group provided through sss and cups starts before sssd has finished booting, cups will crash because the group does not exist. * The patch adds an "After=sssd.service" clause to the service unit file. [Test Case] * Configure an external authentication service (LDAP, AD...) and create a group, for instance "lpadmins@tests.local" * Set SystemGroup to match that group in /etc/cups/cups-files.conf: SystemGroup lpadmins@tests.local * Reboot * If cups has started before sssd has finished booting, cups will crash: Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf. * If cups starts after sssd, it will work fine. [Regression Potential] * Minimal: this patch affects just the ordering of the service unit file. [Other Info] * Upstream: https://github.com/apple/cups/commit/4d0f1959a3f46973caec2cd41828c59674fe195d [Original description] When cups has set the "SystemGroup" directive to an external group provided through sss and cups starts before sssd has finished booting, cups will crash because the group does not exist. For instance, with a group named lpadmins@tests.local served from Active Directory through sssd, if the sssd service hasn't booted before cups: Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unable to read "/etc/cups/cups-files.conf" due to errors. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Failed with result 'exit-code'. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Service hold-off time over, scheduling restart. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Scheduled restart job, restart counter is at 2. Mar 27 10:10:33 cups-sssd systemd[1]: Stopping Make remote CUPS printers available locally... Mar 27 10:10:33 cups-sssd systemd[1]: Stopped Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd systemd[1]: Stopped CUPS Scheduler. If sssd is running before cups starts, everything works as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1822062/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822062] Re: Race condition on boot between cups and sssd
# VERIFICATION: BIONIC - Using the reproducer defined in the test case and the version in -updates: ubuntu@bionic-sssd-ad:~$ dpkg -l | grep -E "cups-daemon| cups |cups-common" ii cups 2.2.7-1ubuntu2.4 amd64Common UNIX Printing System(tm) - PPD/driver support, web interface ii cups-common 2.2.7-1ubuntu2.4 all Common UNIX Printing System(tm) - common files ii cups-daemon 2.2.7-1ubuntu2.4 amd64Common UNIX Printing System(tm) - daemon ubuntu@bionic-sssd-ad:~$ grep -i systemgroup /etc/cups/cups-files.conf SystemGroup lpadmins@TESTS.LOCAL ubuntu@bionic-sssd-ad:~$ systemd-analyze critical-chain cups.service The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. cups.service @5d 44min 17.034s └─basic.target @41.538s └─sockets.target @41.534s └─lxd.socket @41.422s +104ms └─sysinit.target @41.320s └─systemd-update-utmp.service @40.757s +99ms └─systemd-tmpfiles-setup.service @39.550s +1.181s └─local-fs.target @13.659s └─var-lib-lxcfs.mount @43.131s └─local-fs-pre.target @9.991s └─systemd-tmpfiles-setup-dev.service @8.859s +1.127s └─kmod-static-nodes.service @8.510s +303ms └─systemd-journald.socket @8.460s └─system.slice @8.334s └─-.slice @8.326s - After reboot, cups fails to start: ubuntu@bionic-sssd-ad:~$ systemctl status cups ● cups.service - CUPS Scheduler Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2019-05-07 10:06:32 UTC; 27min ago Docs: man:cupsd(8) Process: 969 ExecStart=/usr/sbin/cupsd -l (code=exited, status=1/FAILURE) Main PID: 969 (code=exited, status=1/FAILURE) May 07 10:06:32 bionic-sssd-ad systemd[1]: cups.service: Service hold-off time over, scheduling restart. May 07 10:06:32 bionic-sssd-ad systemd[1]: cups.service: Scheduled restart job, restart counter is at 5. May 07 10:06:32 bionic-sssd-ad systemd[1]: Stopped CUPS Scheduler. May 07 10:06:32 bionic-sssd-ad systemd[1]: cups.service: Start request repeated too quickly. May 07 10:06:32 bionic-sssd-ad systemd[1]: cups.service: Failed with result 'exit-code'. May 07 10:06:32 bionic-sssd-ad systemd[1]: Failed to start CUPS Scheduler. ubuntu@bionic-sssd-ad:~$ grep cupsd /var/log/syslog | grep -v kernel May 7 10:06:30 bionic-sssd-ad cupsd[860]: Unknown SystemGroup "lpadmins@TESTS.LOCAL" on line 19 of /etc/cups/cups-files.conf. May 7 10:06:30 bionic-sssd-ad cupsd[860]: Unable to read "/etc/cups/cups-files.conf" due to errors. ... - Using the version in -proposed, after rebooting, cups works fine: ubuntu@bionic-sssd-ad:~$ dpkg -l | grep -E "cups-daemon| cups |cups-common" ii cups 2.2.7-1ubuntu2.5 amd64Common UNIX Printing System(tm) - PPD/driver support, web interface ii cups-common 2.2.7-1ubuntu2.5 all Common UNIX Printing System(tm) - common files ii cups-daemon 2.2.7-1ubuntu2.5 amd64Common UNIX Printing System(tm) - daemon ubuntu@bionic-sssd-ad:~$ systemctl status cups ● cups.service - CUPS Scheduler Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2019-05-07 10:36:49 UTC; 9min ago Docs: man:cupsd(8) Main PID: 1036 (cupsd) Tasks: 1 (limit: 2361) CGroup: /system.slice/cups.service └─1036 /usr/sbin/cupsd -l May 07 10:36:49 bionic-sssd-ad systemd[1]: Started CUPS Scheduler. ubuntu@bionic-sssd-ad:~$ systemd-analyze critical-chain cups.service The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. cups.service @46.601s └─sssd.service @39.137s +7.411s └─basic.target @39.068s └─sockets.target @39.062s └─snapd.socket @38.991s +62ms └─sysinit.target @38.817s └─cloud-init.service @35.077s +3.695s └─systemd-networkd-wait-online.service @33.910s +1.151s └─systemd-networkd.service @33.667s +205ms └─network-pre.target @33.654s └─cloud-init-local.service @19.639s +14.007s └─systemd-remount-fs.service @6.538s +851ms └─systemd-journald.socket @6.460s └─system.slice @6.408s └─-.slice @6.129s - Using the version in -proposed, with sssd not installed in the machine (and setting SystemGroup to the original local group "lpadmin"), cups still
[Touch-packages] [Bug 1822062] Re: Race condition on boot between cups and sssd
# VERIFICATION: COSMIC - Using the reproducer defined in the test case and the version in -updates: ubuntu@cosmic-sssd-ad:~$ dpkg -l | grep -E "cups-daemon| cups |cups-common" ii cups 2.2.8-5ubuntu1.2amd64 Common UNIX Printing System(tm) - PPD/driver support, web interface ii cups-common 2.2.8-5ubuntu1.2all Common UNIX Printing System(tm) - common files ii cups-daemon 2.2.8-5ubuntu1.2amd64 Common UNIX Printing System(tm) - daemon ubuntu@cosmic-sssd-ad:~$ grep -i systemgroup /etc/cups/cups-files.conf SystemGroup lpadmins@TESTS.LOCAL ubuntu@cosmic-sssd-ad:~$ systemd-analyze critical-chain cups.service The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. cups.service @5d 44min 19.075s └─basic.target @32.610s └─sockets.target @32.602s └─snap.lxd.daemon.unix.socket @2min 24.862s └─snap-lxd-10601.mount @2min 1.485s +39ms └─local-fs-pre.target @8.493s └─systemd-tmpfiles-setup-dev.service @8.103s +386ms └─systemd-sysusers.service @7.546s +550ms └─systemd-remount-fs.service @7.143s +373ms └─systemd-journald.socket @7.033s └─-.mount @6.938s └─system.slice @6.938s └─-.slice @6.938s - After reboot, cups fails to start: ubuntu@cosmic-sssd-ad:~$ systemctl status cups ● cups.service - CUPS Scheduler Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2019-05-07 10:06:49 UTC; 57min ago Docs: man:cupsd(8) Process: 1173 ExecStart=/usr/sbin/cupsd -l (code=exited, status=1/FAILURE) Main PID: 1173 (code=exited, status=1/FAILURE) May 07 10:06:49 cosmic-sssd-ad systemd[1]: cups.service: Service RestartSec=100ms expired, scheduling rest May 07 10:06:49 cosmic-sssd-ad systemd[1]: cups.service: Scheduled restart job, restart counter is at 5. May 07 10:06:49 cosmic-sssd-ad systemd[1]: Stopped CUPS Scheduler. May 07 10:06:49 cosmic-sssd-ad systemd[1]: cups.service: Start request repeated too quickly. May 07 10:06:49 cosmic-sssd-ad systemd[1]: cups.service: Failed with result 'exit-code'. May 07 10:06:49 cosmic-sssd-ad systemd[1]: Failed to start CUPS Scheduler. ubuntu@cosmic-sssd-ad:~$ grep cupsd /var/log/syslog | grep -v kernel May 7 10:06:45 cosmic-sssd-ad cupsd[1033]: Unknown SystemGroup "lpadmins@TESTS.LOCAL" on line 19 of /etc/cups/cups-files.conf. May 7 10:06:45 cosmic-sssd-ad cupsd[1033]: Unable to read "/etc/cups/cups-files.conf" due to errors. May 7 10:06:47 cosmic-sssd-ad cupsd[1122]: Unknown SystemGroup "lpadmins@TESTS.LOCAL" on line 19 of /etc/cups/cups-files.conf. May 7 10:06:47 cosmic-sssd-ad cupsd[1122]: Unable to read "/etc/cups/cups-files.conf" due to errors. ... - Using the version in -proposed, after rebooting, cups works fine: ubuntu@cosmic-sssd-ad:~$ dpkg -l | grep -E "cups-daemon| cups |cups-common" ii cups 2.2.8-5ubuntu1.3amd64 Common UNIX Printing System(tm) - PPD/driver support, web interface ii cups-common 2.2.8-5ubuntu1.3all Common UNIX Printing System(tm) - common files ii cups-daemon 2.2.8-5ubuntu1.3amd64 Common UNIX Printing System(tm) - daemon ubuntu@cosmic-sssd-ad:~$ systemctl status cups ● cups.service - CUPS Scheduler Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2019-05-07 11:13:20 UTC; 58s ago Docs: man:cupsd(8) Main PID: 1297 (cupsd) Tasks: 1 (limit: 2361) Memory: 2.7M CGroup: /system.slice/cups.service └─1297 /usr/sbin/cupsd -l May 07 11:13:20 cosmic-sssd-ad systemd[1]: Started CUPS Scheduler. ubuntu@cosmic-sssd-ad:~$ systemd-analyze critical-chain cups.service The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. cups.service @1min 6.619s └─sssd.service @54.111s +12.499s └─basic.target @54.032s └─sockets.target @54.030s └─snapd.socket @53.965s +61ms └─sysinit.target @53.361s └─cloud-init.service @48.760s +4.493s └─systemd-networkd-wait-online.service @46.946s +1.809s └─systemd-networkd.service @46.237s +675ms └─network-pre.target @46.230s └─cloud-init-local.service @22.765s +23.458s └─systemd-remount-fs.service @10.923s +199ms └─systemd-journald.socket @10.574s └─system.slice @10.466s └─-.slice @10.466s - Using the version in -proposed, with sssd not
[Touch-packages] [Bug 1822062] Re: Race condition on boot between cups and sssd
# VERIFICATION: DISCO - Using the reproducer defined in the test case and the version in -updates: ubuntu@disco-sssd-ad:~$ dpkg -l | grep -E "cups-daemon| cups |cups-common" ii cups 2.2.10-4amd64 Common UNIX Printing System(tm) - PPD/driver support, web interface ii cups-common 2.2.10-4all Common UNIX Printing System(tm) - common files ii cups-daemon 2.2.10-4amd64 Common UNIX Printing System(tm) - daemon ubuntu@disco-sssd-ad:~$ grep -i systemgroup /etc/cups/cups-files.conf SystemGroup lpadmins@TESTS.LOCAL ubuntu@disco-sssd-ad:~$ systemd-analyze critical-chain cups.service The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. cups.service +161ms └─cups.socket @46.229s └─sysinit.target @42.682s └─cloud-init.service @37.411s +5.239s └─systemd-networkd-wait-online.service @35.640s +1.727s └─systemd-networkd.service @35.419s +189ms └─network-pre.target @35.415s └─cloud-init-local.service @21.419s +13.992s └─systemd-remount-fs.service @7.277s +570ms └─systemd-journald.socket @7.070s └─system.slice @6.915s └─-.slice @6.915s - After reboot, cups fails to start: ubuntu@disco-sssd-ad:~$ systemctl status cups ● cups.service - CUPS Scheduler Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Tue 2019-05-07 11:12:09 UTC; 16min ago Docs: man:cupsd(8) Process: 747 ExecStart=/usr/sbin/cupsd -l (code=exited, status=1/FAILURE) Main PID: 747 (code=exited, status=1/FAILURE) May 07 11:12:09 disco-sssd-ad systemd[1]: Stopped CUPS Scheduler. May 07 11:12:09 disco-sssd-ad systemd[1]: Started CUPS Scheduler. May 07 11:12:09 disco-sssd-ad systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE May 07 11:12:09 disco-sssd-ad systemd[1]: cups.service: Failed with result 'exit-code'. May 07 11:12:09 disco-sssd-ad systemd[1]: cups.service: Service RestartSec=100ms expired, scheduling resta May 07 11:12:09 disco-sssd-ad systemd[1]: cups.service: Scheduled restart job, restart counter is at 5. May 07 11:12:09 disco-sssd-ad systemd[1]: Stopped CUPS Scheduler. May 07 11:12:09 disco-sssd-ad systemd[1]: cups.service: Start request repeated too quickly. May 07 11:12:09 disco-sssd-ad systemd[1]: cups.service: Failed with result 'exit-code'. May 07 11:12:09 disco-sssd-ad systemd[1]: Failed to start CUPS Scheduler. ubuntu@disco-sssd-ad:~$ grep cupsd /var/log/syslog | grep -v kernel May 7 11:12:10 disco-sssd-ad cupsd[692]: Unknown SystemGroup "lpadmins@TESTS.LOCAL" on line 19 of /etc/cups/cups-files.conf. May 7 11:12:10 disco-sssd-ad cupsd[692]: Unable to read "/etc/cups/cups-files.conf" due to errors. May 7 11:12:10 disco-sssd-ad cupsd[721]: Unknown SystemGroup "lpadmins@TESTS.LOCAL" on line 19 of /etc/cups/cups-files.conf. ... - Using the version in -proposed, after rebooting, cups works fine: ubuntu@disco-sssd-ad:~$ dpkg -l | grep -E "cups-daemon| cups |cups-common" ii cups 2.2.10-4ubuntu1 amd64 Common UNIX Printing System(tm) - PPD/driver support, web interface ii cups-common 2.2.10-4ubuntu1 all Common UNIX Printing System(tm) - common files ii cups-daemon 2.2.10-4ubuntu1 amd64 Common UNIX Printing System(tm) - daemon ubuntu@disco-sssd-ad:~$ systemctl status cups ● cups.service - CUPS Scheduler Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2019-05-07 11:32:52 UTC; 33s ago Docs: man:cupsd(8) Main PID: 812 (cupsd) Tasks: 1 (limit: 2356) Memory: 2.5M CGroup: /system.slice/cups.service └─812 /usr/sbin/cupsd -l May 07 11:32:52 disco-sssd-ad systemd[1]: Started CUPS Scheduler. ubuntu@disco-sssd-ad:~$ systemd-analyze critical-chain cups.service The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. cups.service @49.422s └─sssd.service @41.473s +7.943s └─basic.target @41.321s └─sockets.target @41.318s └─snapd.socket @41.111s +184ms └─sysinit.target @40.800s └─cloud-init.service @37.899s +2.895s └─systemd-networkd-wait-online.service @36.713s +1.141s └─systemd-networkd.service @36.346s +360ms └─network-pre.target @36.341s └─cloud-init-local.service @21.748s +14.588s └─systemd-remount-fs.service @8.932s +140ms └─systemd-journald.socket @8.844s
[Touch-packages] [Bug 1822062] Re: Race condition on boot between cups and sssd
** Description changed: + [Impact] + + * When cups has set the "SystemGroup" directive to an external group + provided through sss and cups starts before sssd has finished booting, + cups will crash because the group does not exist. + + * The patch adds an "After=sssd.service" clause to the service unit + file. + + [Test Case] + + * Configure an external authentication service (LDAP, AD...) and create + a group, for instance "lpadmins@tests.local" + + * Set SystemGroup to match that group (SystemGroup = + "lpadmins@tests.local") + + * Reboot + + * If cups has started before sssd has finished booting, cups will crash: + Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf. + + * If cups starts after sssd, it will work fine. + + [Regression Potential] + + * Minimal: this patch affects just the ordering of the service unit + file. + + [Other Info] + + * Upstream: https://github.com/apple/cups/commit/4d0f1959a3f46973caec2cd41828c59674fe195d + + [Original description] + When cups has set the "SystemGroup" directive to an external group provided through sss and cups starts before sssd has finished booting, cups will crash because the group does not exist. For instance, with a group named lpadmins@tests.local served from Active Directory through sssd, if the sssd service hasn't booted before cups: Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unable to read "/etc/cups/cups-files.conf" due to errors. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Failed with result 'exit-code'. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Service hold-off time over, scheduling restart. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Scheduled restart job, restart counter is at 2. Mar 27 10:10:33 cups-sssd systemd[1]: Stopping Make remote CUPS printers available locally... Mar 27 10:10:33 cups-sssd systemd[1]: Stopped Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd systemd[1]: Stopped CUPS Scheduler. If sssd is running before cups starts, everything works as expected. ** Also affects: cups (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: cups (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: cups (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: cups (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: cups (Ubuntu Cosmic) Importance: Undecided Status: New ** Description changed: [Impact] - * When cups has set the "SystemGroup" directive to an external group + * When cups has set the "SystemGroup" directive to an external group provided through sss and cups starts before sssd has finished booting, cups will crash because the group does not exist. - * The patch adds an "After=sssd.service" clause to the service unit + * The patch adds an "After=sssd.service" clause to the service unit file. [Test Case] - * Configure an external authentication service (LDAP, AD...) and create + * Configure an external authentication service (LDAP, AD...) and create a group, for instance "lpadmins@tests.local" - * Set SystemGroup to match that group (SystemGroup = - "lpadmins@tests.local") + * Set SystemGroup to match that group in /etc/cups/cups-files.conf: + SystemGroup lpadmins@tests.local - * Reboot + * Reboot - * If cups has started before sssd has finished booting, cups will crash: + * If cups has started before sssd has finished booting, cups will crash: Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf. - * If cups starts after sssd, it will work fine. + * If cups starts after sssd, it will work fine. [Regression Potential] - * Minimal: this patch affects just the ordering of the service unit + * Minimal: this patch affects just the ordering of the service unit file. [Other Info] - - * Upstream: https://github.com/apple/cups/commit/4d0f1959a3f46973caec2cd41828c59674fe195d + + * Upstream: + https://github.com/apple/cups/commit/4d0f1959a3f46973caec2cd41828c59674fe195d [Original description] When cups has set the "SystemGroup" directive to an external group provided through sss and cups starts before sssd has finished booting, cups will crash because the group does not exist. For instance, with a group named lpadmins@tests.local served from Active
[Touch-packages] [Bug 1822062] Re: Race condition on boot between cups and sssd
** Patch added: "disco-cups.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1822062/+attachment/5258667/+files/disco-cups.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1822062 Title: Race condition on boot between cups and sssd Status in cups package in Ubuntu: New Status in cups source package in Xenial: New Status in cups source package in Bionic: New Status in cups source package in Cosmic: New Status in cups source package in Disco: New Status in cups source package in Eoan: New Bug description: [Impact] * When cups has set the "SystemGroup" directive to an external group provided through sss and cups starts before sssd has finished booting, cups will crash because the group does not exist. * The patch adds an "After=sssd.service" clause to the service unit file. [Test Case] * Configure an external authentication service (LDAP, AD...) and create a group, for instance "lpadmins@tests.local" * Set SystemGroup to match that group in /etc/cups/cups-files.conf: SystemGroup lpadmins@tests.local * Reboot * If cups has started before sssd has finished booting, cups will crash: Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf. * If cups starts after sssd, it will work fine. [Regression Potential] * Minimal: this patch affects just the ordering of the service unit file. [Other Info] * Upstream: https://github.com/apple/cups/commit/4d0f1959a3f46973caec2cd41828c59674fe195d [Original description] When cups has set the "SystemGroup" directive to an external group provided through sss and cups starts before sssd has finished booting, cups will crash because the group does not exist. For instance, with a group named lpadmins@tests.local served from Active Directory through sssd, if the sssd service hasn't booted before cups: Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unable to read "/etc/cups/cups-files.conf" due to errors. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Failed with result 'exit-code'. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Service hold-off time over, scheduling restart. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Scheduled restart job, restart counter is at 2. Mar 27 10:10:33 cups-sssd systemd[1]: Stopping Make remote CUPS printers available locally... Mar 27 10:10:33 cups-sssd systemd[1]: Stopped Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd systemd[1]: Stopped CUPS Scheduler. If sssd is running before cups starts, everything works as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1822062/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822062] Re: Race condition on boot between cups and sssd
** Patch added: "disco-cups.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1822062/+attachment/5258668/+files/disco-cups.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1822062 Title: Race condition on boot between cups and sssd Status in cups package in Ubuntu: New Status in cups source package in Xenial: New Status in cups source package in Bionic: New Status in cups source package in Cosmic: New Status in cups source package in Disco: New Status in cups source package in Eoan: New Bug description: [Impact] * When cups has set the "SystemGroup" directive to an external group provided through sss and cups starts before sssd has finished booting, cups will crash because the group does not exist. * The patch adds an "After=sssd.service" clause to the service unit file. [Test Case] * Configure an external authentication service (LDAP, AD...) and create a group, for instance "lpadmins@tests.local" * Set SystemGroup to match that group in /etc/cups/cups-files.conf: SystemGroup lpadmins@tests.local * Reboot * If cups has started before sssd has finished booting, cups will crash: Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf. * If cups starts after sssd, it will work fine. [Regression Potential] * Minimal: this patch affects just the ordering of the service unit file. [Other Info] * Upstream: https://github.com/apple/cups/commit/4d0f1959a3f46973caec2cd41828c59674fe195d [Original description] When cups has set the "SystemGroup" directive to an external group provided through sss and cups starts before sssd has finished booting, cups will crash because the group does not exist. For instance, with a group named lpadmins@tests.local served from Active Directory through sssd, if the sssd service hasn't booted before cups: Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unable to read "/etc/cups/cups-files.conf" due to errors. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Failed with result 'exit-code'. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Service hold-off time over, scheduling restart. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Scheduled restart job, restart counter is at 2. Mar 27 10:10:33 cups-sssd systemd[1]: Stopping Make remote CUPS printers available locally... Mar 27 10:10:33 cups-sssd systemd[1]: Stopped Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd systemd[1]: Stopped CUPS Scheduler. If sssd is running before cups starts, everything works as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1822062/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822062] Re: Race condition on boot between cups and sssd
** Patch added: "cosmic-cups.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1822062/+attachment/5258669/+files/cosmic-cups.debdiff ** Patch removed: "disco-cups.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1822062/+attachment/5258668/+files/disco-cups.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1822062 Title: Race condition on boot between cups and sssd Status in cups package in Ubuntu: New Status in cups source package in Xenial: New Status in cups source package in Bionic: New Status in cups source package in Cosmic: New Status in cups source package in Disco: New Status in cups source package in Eoan: New Bug description: [Impact] * When cups has set the "SystemGroup" directive to an external group provided through sss and cups starts before sssd has finished booting, cups will crash because the group does not exist. * The patch adds an "After=sssd.service" clause to the service unit file. [Test Case] * Configure an external authentication service (LDAP, AD...) and create a group, for instance "lpadmins@tests.local" * Set SystemGroup to match that group in /etc/cups/cups-files.conf: SystemGroup lpadmins@tests.local * Reboot * If cups has started before sssd has finished booting, cups will crash: Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf. * If cups starts after sssd, it will work fine. [Regression Potential] * Minimal: this patch affects just the ordering of the service unit file. [Other Info] * Upstream: https://github.com/apple/cups/commit/4d0f1959a3f46973caec2cd41828c59674fe195d [Original description] When cups has set the "SystemGroup" directive to an external group provided through sss and cups starts before sssd has finished booting, cups will crash because the group does not exist. For instance, with a group named lpadmins@tests.local served from Active Directory through sssd, if the sssd service hasn't booted before cups: Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unable to read "/etc/cups/cups-files.conf" due to errors. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Failed with result 'exit-code'. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Service hold-off time over, scheduling restart. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Scheduled restart job, restart counter is at 2. Mar 27 10:10:33 cups-sssd systemd[1]: Stopping Make remote CUPS printers available locally... Mar 27 10:10:33 cups-sssd systemd[1]: Stopped Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd systemd[1]: Stopped CUPS Scheduler. If sssd is running before cups starts, everything works as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1822062/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822062] Re: Race condition on boot between cups and sssd
** Patch added: "bionic-cups.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1822062/+attachment/5258670/+files/bionic-cups.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1822062 Title: Race condition on boot between cups and sssd Status in cups package in Ubuntu: New Status in cups source package in Xenial: New Status in cups source package in Bionic: New Status in cups source package in Cosmic: New Status in cups source package in Disco: New Status in cups source package in Eoan: New Bug description: [Impact] * When cups has set the "SystemGroup" directive to an external group provided through sss and cups starts before sssd has finished booting, cups will crash because the group does not exist. * The patch adds an "After=sssd.service" clause to the service unit file. [Test Case] * Configure an external authentication service (LDAP, AD...) and create a group, for instance "lpadmins@tests.local" * Set SystemGroup to match that group in /etc/cups/cups-files.conf: SystemGroup lpadmins@tests.local * Reboot * If cups has started before sssd has finished booting, cups will crash: Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf. * If cups starts after sssd, it will work fine. [Regression Potential] * Minimal: this patch affects just the ordering of the service unit file. [Other Info] * Upstream: https://github.com/apple/cups/commit/4d0f1959a3f46973caec2cd41828c59674fe195d [Original description] When cups has set the "SystemGroup" directive to an external group provided through sss and cups starts before sssd has finished booting, cups will crash because the group does not exist. For instance, with a group named lpadmins@tests.local served from Active Directory through sssd, if the sssd service hasn't booted before cups: Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unable to read "/etc/cups/cups-files.conf" due to errors. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Failed with result 'exit-code'. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Service hold-off time over, scheduling restart. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Scheduled restart job, restart counter is at 2. Mar 27 10:10:33 cups-sssd systemd[1]: Stopping Make remote CUPS printers available locally... Mar 27 10:10:33 cups-sssd systemd[1]: Stopped Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd systemd[1]: Stopped CUPS Scheduler. If sssd is running before cups starts, everything works as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1822062/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1822062] Re: Race condition on boot between cups and sssd
** Patch added: "xenial-cups.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1822062/+attachment/5258671/+files/xenial-cups.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1822062 Title: Race condition on boot between cups and sssd Status in cups package in Ubuntu: New Status in cups source package in Xenial: New Status in cups source package in Bionic: New Status in cups source package in Cosmic: New Status in cups source package in Disco: New Status in cups source package in Eoan: New Bug description: [Impact] * When cups has set the "SystemGroup" directive to an external group provided through sss and cups starts before sssd has finished booting, cups will crash because the group does not exist. * The patch adds an "After=sssd.service" clause to the service unit file. [Test Case] * Configure an external authentication service (LDAP, AD...) and create a group, for instance "lpadmins@tests.local" * Set SystemGroup to match that group in /etc/cups/cups-files.conf: SystemGroup lpadmins@tests.local * Reboot * If cups has started before sssd has finished booting, cups will crash: Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf. * If cups starts after sssd, it will work fine. [Regression Potential] * Minimal: this patch affects just the ordering of the service unit file. [Other Info] * Upstream: https://github.com/apple/cups/commit/4d0f1959a3f46973caec2cd41828c59674fe195d [Original description] When cups has set the "SystemGroup" directive to an external group provided through sss and cups starts before sssd has finished booting, cups will crash because the group does not exist. For instance, with a group named lpadmins@tests.local served from Active Directory through sssd, if the sssd service hasn't booted before cups: Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started CUPS Scheduler. Mar 27 10:10:33 cups-sssd systemd[1]: Started Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unknown SystemGroup "lpadmins@tests.local" on line 19 of /etc/cups/cups-files.conf. Mar 27 10:10:33 cups-sssd cupsd[21463]: Unable to read "/etc/cups/cups-files.conf" due to errors. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Main process exited, code=exited, status=1/FAILURE Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Failed with result 'exit-code'. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Service hold-off time over, scheduling restart. Mar 27 10:10:33 cups-sssd systemd[1]: cups.service: Scheduled restart job, restart counter is at 2. Mar 27 10:10:33 cups-sssd systemd[1]: Stopping Make remote CUPS printers available locally... Mar 27 10:10:33 cups-sssd systemd[1]: Stopped Make remote CUPS printers available locally. Mar 27 10:10:33 cups-sssd systemd[1]: Stopped CUPS Scheduler. If sssd is running before cups starts, everything works as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1822062/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1796501] Re: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes
** Patch removed: "eoan debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+attachment/5288416/+files/systemd_241-7ubuntu2.debdiff ** Patch added: "eoan.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+attachment/5294401/+files/eoan.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1796501 Title: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: In Progress Bug description: I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the following steps: 1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size. 2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit. 3. Ask upstream for SOA of test.asdf. with EDNS0. 4. Ask upstream for SOA of test.asdf. without EDNS0. 5. Repeat 1-4 for DS of test.asdf. 6. Repeat 1-5 for asdf. 7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size. 8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size. The upstream returns an unfragmented NXDOMAIN response for steps 1-6, an unfragmented NOERROR response for step 7 and a fragmented NOERROR response for step 8 which is the correct behaviour. DNSSEC records are included in the response if the DO-bit in the request was set. systemd-resolved should take the response from step 1 and start with validation instead of starting useless retries with reduced feture set. Step 3 and 4 are completely useless and probably lead to the SERVFAIL because I have configured it with DNSSEC=yes to prevent downgrade attacks. This regression seems to be caused by the patch resolved-Mitigate- DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic should only be executed if it is configured as DNSSEC=allow-downgrade or DNSSEC=no. See also https://github.com/systemd/systemd/pull/8608#issuecomment-396927885. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1796501] Re: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes
** Patch removed: "eoan.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+attachment/5294401/+files/eoan.debdiff ** Patch added: "eoan.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+attachment/5294438/+files/eoan.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1796501 Title: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: In Progress Bug description: I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the following steps: 1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size. 2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit. 3. Ask upstream for SOA of test.asdf. with EDNS0. 4. Ask upstream for SOA of test.asdf. without EDNS0. 5. Repeat 1-4 for DS of test.asdf. 6. Repeat 1-5 for asdf. 7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size. 8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size. The upstream returns an unfragmented NXDOMAIN response for steps 1-6, an unfragmented NOERROR response for step 7 and a fragmented NOERROR response for step 8 which is the correct behaviour. DNSSEC records are included in the response if the DO-bit in the request was set. systemd-resolved should take the response from step 1 and start with validation instead of starting useless retries with reduced feture set. Step 3 and 4 are completely useless and probably lead to the SERVFAIL because I have configured it with DNSSEC=yes to prevent downgrade attacks. This regression seems to be caused by the patch resolved-Mitigate- DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic should only be executed if it is configured as DNSSEC=allow-downgrade or DNSSEC=no. See also https://github.com/systemd/systemd/pull/8608#issuecomment-396927885. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1896614] Re: Race condition when starting dbus services
In the original report, the issue happened randomly on boot when a service[1] was triggering a reload while systemd-logind was starting, resulting in a list of queued jobs that were never executed. The issue can happen too under high load conditions, as reported upstream: https://github.com/systemd/systemd/issues/12956 To simplify the reproducer I went with systemd-logind+daemon-reload, but it can be done with any other dbus service. [1] [Unit] Description=Disable unattended upgrades After=network-online.target local-fs.target [Service] Type=oneshot ExecStart=/bin/bash -c "/bin/chmod 644 /etc/cron.daily/apt-compat ; /bin/systemctl disable apt-daily-upgrade.timer apt-daily.timer ; /bin/systemctl stop apt-daily-upgrade.timer apt-daily.timer" [Install] WantedBy=multi-user.target ** Bug watch added: github.com/systemd/systemd/issues #12956 https://github.com/systemd/systemd/issues/12956 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1896614 Title: Race condition when starting dbus services Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: In certain scenarios, such as high load environments or when "systemctl daemon-reload" runs at the same time a dbus service is starting (e.g. systemd-logind), systemd is not able to track properly when the service has started, keeping the job 'running' forever. The issue appears when systemd runs the "AddMatch" dbus method call to track the service's "NameOwnerChange" once it has already ran. A working instance would look like this: https://pastebin.ubuntu.com/p/868J6WBRQx/ A failing instance would be: https://pastebin.ubuntu.com/p/HhJZ4p8dT5/ I've been able to reproduce the issue on Bionic (237-3ubuntu10.42) running: sudo systemctl daemon-reload & sudo systemctl restart systemd-logind To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896614/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1896614] [NEW] Race condition when starting dbus services
Public bug reported: In certain scenarios, such as high load environments or when "systemctl daemon-reload" runs at the same time a dbus service is starting (e.g. systemd-logind), systemd is not able to track properly when the service has started, keeping the job 'running' forever. The issue appears when systemd runs the "AddMatch" dbus method call to track the service's "NameOwnerChange" once it has already ran. A working instance would look like this: https://pastebin.ubuntu.com/p/868J6WBRQx/ A failing instance would be: https://pastebin.ubuntu.com/p/HhJZ4p8dT5/ I've been able to reproduce the issue on Bionic (237-3ubuntu10.42) running: sudo systemctl daemon-reload & sudo systemctl restart systemd-logind ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Tags: sts ** Tags added: sts ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1896614 Title: Race condition when starting dbus services Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: In certain scenarios, such as high load environments or when "systemctl daemon-reload" runs at the same time a dbus service is starting (e.g. systemd-logind), systemd is not able to track properly when the service has started, keeping the job 'running' forever. The issue appears when systemd runs the "AddMatch" dbus method call to track the service's "NameOwnerChange" once it has already ran. A working instance would look like this: https://pastebin.ubuntu.com/p/868J6WBRQx/ A failing instance would be: https://pastebin.ubuntu.com/p/HhJZ4p8dT5/ I've been able to reproduce the issue on Bionic (237-3ubuntu10.42) running: sudo systemctl daemon-reload & sudo systemctl restart systemd-logind To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1896614/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1896614] Re: Race condition when starting dbus services
# VERIFICATION Note: As a reminder, the issue here is that there's a race condition between any DBUS service and systemctl daemon-reload, where systemd adds the DBUS filter (AddMatch) that looks for a name change when that has already happened. I'll be using systemd-logind as the DBUS service in my reproducer. Using the following reproducer: for i in $(seq 1 1000); do echo $i; ssh $SERVER 'sudo systemctl daemon- reload & sudo systemctl restart systemd-logind'; done - With systemd=237-3ubuntu10.42 (-updates), after a few runs, systemd-logind is stuck as a running job and ssh is not responsive. DBUS messages[1] show that the AddMatch filter is set by systemd after systemd-logind has acquired its final name (systemd-login1) - With systemd=237-3ubuntu10.43 (-proposed), systemd-logind does not get stuck and everything continues to work. In a scenario[2] where the systemd DBUS AddMatch message arrives after the final systemd-logind NameOwnerChanged, systemd is able to catch up thanks to the GetNameOwner introduced in the patch [1] https://pastebin.ubuntu.com/p/NxRNX9bwCP/ [2] https://pastebin.ubuntu.com/p/jpKpW3g2bK/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1896614 Title: Race condition when starting dbus services Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Bug description: [impact] In certain scenarios, such as high load environments or when "systemctl daemon-reload" runs at the same time a dbus service is starting (e.g. systemd-logind), systemd is not able to track properly when the service has started, keeping the job 'running' forever. [test case] set up a 1-cpu VM with Bionic, and configure the system with a ssh key so the user can ssh to localhost. Then run something like: $ while timeout 5 ssh localhost true; do echo 'reloading'; sudo systemctl restart systemd-logind & sudo systemctl daemon-reload; done if that doesn't work try: $ while timeout 5 ssh localhost true; do echo 'reloading'; sudo sh -c 'systemctl restart systemd-logind & systemctl daemon-reload'; done once the reproducer exits the while loop, there should be a running job for systemd-logind, and any logins attempted after the bug is reproduced should also hang waiting for the systemd-logind job to complete, e.g.: ubuntu@lp1896614-b:~$ systemctl list-jobs JOB UNIT TYPE STATE 525 systemd-logind.service start running 669 session-6.scopestart waiting 664 session-5.scopestart waiting 3 jobs listed. [regression potential] any regression would likely involve services that are Type=dbus failing to complete starting. as with any systemd change, regressions could also involve assertion failures in systemd which causes it to exit. [scope] this is needed only for bionic. this is fixed upstream with commit a5a8776ae5e4244b7f5acb2a1bfbe6e0b4d8a870 which is including starting in v243, so it is included already in focal and later. (per upstream bug) this was introduced by upstream commit 75152a4d6aedbfd3ee8b2d5782b9edf27407622a which was included starting in v237, so this bug is not present in xenial or earlier. [original description] In certain scenarios, such as high load environments or when "systemctl daemon-reload" runs at the same time a dbus service is starting (e.g. systemd-logind), systemd is not able to track properly when the service has started, keeping the job 'running' forever. The issue appears when systemd runs the "AddMatch" dbus method call to track the service's "NameOwnerChange" once it has already ran. A working instance would look like this: https://pastebin.ubuntu.com/p/868J6WBRQx/ A failing instance would be: https://pastebin.ubuntu.com/p/HhJZ4p8dT5/ I've been able to reproduce the issue on Bionic (237-3ubuntu10.42) running: sudo systemctl daemon-reload & sudo systemctl restart systemd-logind To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1896614/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1927078] [NEW] Don't allow useradd to use fully numeric names
Public bug reported: [Description] Fully numeric names support in Ubuntu is inconsistent in Focal onwards because systemd does not like them[1] but are still allowed by default by useradd, leaving the session behavior in hands of the running applications. Two examples: 1. After creating a user named "0", the user can log in via ssh or console but loginctl won't create a session for it: root@focal:/home/ubuntu# useradd -m 0 root@focal:/home/ubuntu# id 0 uid=1005(0) gid=1005(0) groups=1005(0) .. 0@192.168.122.6's password: Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-48-generic x86_64) Last login: Thu Apr 8 16:17:06 2021 from 192.168.122.1 $ loginctl No sessions. $ w 16:20:09 up 4 min, 1 user, load average: 0.03, 0.14, 0.08 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT 0pts/0192.168.122.116:170.00s 0.00s 0.00s w And pam-systemd shows the following message: Apr 08 16:17:06 focal sshd[1584]: pam_unix(sshd:session): session opened for user 0 by (uid=0) Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): pam-systemd initializing Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): Failed to get user record: Invalid argument 2. With that same username, every successful authentication in gdm will loop back to gdm again instead of starting gnome, making the user unable to login. Making useradd fail (unless --badnames is set) when a fully numeric name is used will make the default OS behavior consistent. [Other info] - Upstream does not support fully numeric usernames - useradd has a --badnames parameter that would still allow the use of these type of names ** Affects: shadow (Ubuntu) Importance: Undecided Status: New ** Affects: shadow (Ubuntu Focal) Importance: Undecided Status: New ** Affects: shadow (Ubuntu Groovy) Importance: Undecided Status: New ** Affects: shadow (Ubuntu Hirsute) Importance: Undecided Status: New ** Affects: shadow (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: shadow (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: shadow (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: shadow (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: shadow (Ubuntu Impish) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1927078 Title: Don't allow useradd to use fully numeric names Status in shadow package in Ubuntu: New Status in shadow source package in Focal: New Status in shadow source package in Groovy: New Status in shadow source package in Hirsute: New Status in shadow source package in Impish: New Bug description: [Description] Fully numeric names support in Ubuntu is inconsistent in Focal onwards because systemd does not like them[1] but are still allowed by default by useradd, leaving the session behavior in hands of the running applications. Two examples: 1. After creating a user named "0", the user can log in via ssh or console but loginctl won't create a session for it: root@focal:/home/ubuntu# useradd -m 0 root@focal:/home/ubuntu# id 0 uid=1005(0) gid=1005(0) groups=1005(0) .. 0@192.168.122.6's password: Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-48-generic x86_64) Last login: Thu Apr 8 16:17:06 2021 from 192.168.122.1 $ loginctl No sessions. $ w 16:20:09 up 4 min, 1 user, load average: 0.03, 0.14, 0.08 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT 0pts/0192.168.122.116:170.00s 0.00s 0.00s w And pam-systemd shows the following message: Apr 08 16:17:06 focal sshd[1584]: pam_unix(sshd:session): session opened for user 0 by (uid=0) Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): pam-systemd initializing Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): Failed to get user record: Invalid argument 2. With that same username, every successful authentication in gdm will loop back to gdm again instead of starting gnome, making the user unable to login. Making useradd fail (unless --badnames is set) when a fully numeric name is used will make the default OS behavior consistent. [Other info] - Upstream does not support fully numeric usernames - useradd has a --badnames parameter that would still allow the use of these type of names To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1927078/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1927078] Re: Don't allow useradd to use fully numeric names
I don't have a strong opinion either, but given that scripts would ignore the warnings and the resulting numeric users are going to face random, seemingly unrelated issues thanks to the interaction with systemd, I think I prefer the failure. FWIW, I've prepared a test version in a PPA[1] which keeps the rules from Debian[2] but prevents the fully numeric names. This is what it looks like: $ useradd 0 useradd: invalid user name '0' $ echo $? 3 $ sudo useradd 0c0 $ sudo useradd 0 --badnames $ cat /etc/passwd | grep ^0 0c0:x:1001:1001::/home/0c0:/bin/sh 0:x:1002:1002::/home/0:/bin/sh [1] https://launchpad.net/~vtapia/+archive/ubuntu/sf305373 [2] https://salsa.debian.org/debian/shadow/-/blob/master/debian/patches/506_relaxed_usernames -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1927078 Title: Don't allow useradd to use fully numeric names Status in shadow package in Ubuntu: New Status in shadow source package in Focal: New Status in shadow source package in Groovy: New Status in shadow source package in Hirsute: New Status in shadow source package in Impish: New Bug description: [Description] Fully numeric names support in Ubuntu is inconsistent in Focal onwards because systemd does not like them[1] but are still allowed by default by useradd, leaving the session behavior in hands of the running applications. Two examples: 1. After creating a user named "0", the user can log in via ssh or console but loginctl won't create a session for it: root@focal:/home/ubuntu# useradd -m 0 root@focal:/home/ubuntu# id 0 uid=1005(0) gid=1005(0) groups=1005(0) .. 0@192.168.122.6's password: Welcome to Ubuntu 20.04.2 LTS (GNU/Linux 5.8.0-48-generic x86_64) Last login: Thu Apr 8 16:17:06 2021 from 192.168.122.1 $ loginctl No sessions. $ w 16:20:09 up 4 min, 1 user, load average: 0.03, 0.14, 0.08 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT 0pts/0192.168.122.116:170.00s 0.00s 0.00s w And pam-systemd shows the following message: Apr 08 16:17:06 focal sshd[1584]: pam_unix(sshd:session): session opened for user 0 by (uid=0) Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): pam-systemd initializing Apr 08 16:17:06 focal sshd[1584]: pam_systemd(sshd:session): Failed to get user record: Invalid argument 2. With that same username, every successful authentication in gdm will loop back to gdm again instead of starting gnome, making the user unable to login. Making useradd fail (unless --badnames is set) when a fully numeric name is used will make the default OS behavior consistent. [Other info] - Upstream does not support fully numeric usernames - useradd has a --badnames parameter that would still allow the use of these type of names To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1927078/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
