[Touch-packages] [Bug 2038662] Re: systemd-nspawn error: "Failed to mount image file system: Value too large for defined data type"
I note that the issue *doesn't* occur with 23.10 (which has systemd 253.5), tested using an lxd VM: $ lxc launch --vm images:ubuntu/23.10/cloud mythic $ lxc shell mythic # apt-get install systemd-container ... # machinectl pull-raw http://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img jammy-rootfs ... # machinectl start jammy-rootfs # -- 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/2038662 Title: systemd-nspawn error: "Failed to mount image file system: Value too large for defined data type" Status in systemd package in Ubuntu: New Bug description: Two-line reproducer: run this on an Ubuntu 22.04 server. sudo machinectl pull-raw http://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img jammy-rootfs sudo machinectl start jammy-rootfs Response: Job for systemd-nspawn@jammy-rootfs.service failed because the control process exited with error code. Here's the relevant output from "journalctl -xeu systemd-nspawn@jammy-rootfs.service" ░░ A start job for unit systemd-nspawn@jammy-rootfs.service has begun execution. ░░ ░░ The job identifier is 3223. Oct 06 13:13:21 brian-kit systemd-nspawn[36720]: Failed to mount image file system: Value too large for defined data type Oct 06 13:13:21 brian-kit systemd-nspawn[36688]: Short read while reading cgroup mode (0 bytes). The child is most likely dead. Oct 06 13:13:21 brian-kit systemd[1]: systemd-nspawn@jammy-rootfs.service: Main process exited, code=exited, status=1/FAILURE ░░ Subject: Unit process exited ░░ Defined-By: systemd ░░ Support: http://www.ubuntu.com/support ░░ ░░ An ExecStart= process belonging to unit systemd-nspawn@jammy-rootfs.service has exited. ░░ ░░ The process' exit code is 'exited' and its exit status is 1. Oct 06 13:13:21 brian-kit systemd[1]: systemd-nspawn@jammy-rootfs.service: Failed with result 'exit-code'. This appears to be similar to https://github.com/systemd/systemd/issues/20989 If so, a fix was committed in March 2022: https://github.com/systemd/systemd/pull/22774 but maybe that was too late for 22.04? Or this is a different problem? EDIT: the reproducer from https://github.com/systemd/systemd/issues/20989#issuecomment-997024152 also reproduces the problem. # rm -rf /var/lib/machines/my-container/ # mkdir -p /var/lib/machines/my-container/etc # cp /etc/os-release /var/lib/machines/my-container/etc/ # systemd-nspawn -U -b -D /var/lib/machines/my-container/ Spawning container my-container on /var/lib/machines/my-container. Press ^] three times within 1s to kill container. Selected user namespace base 972619776 and range 65536. Failed to create directory at /var/lib/machines/my-container/usr: Value too large for defined data type ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: systemd-container 249.11-0ubuntu3.10 ProcVersionSignature: Ubuntu 5.15.0-84.93-generic 5.15.116 Uname: Linux 5.15.0-84-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CloudArchitecture: x86_64 CloudID: none CloudName: none CloudPlatform: none CloudSubPlatform: config Date: Fri Oct 6 13:10:41 2023 InstallationDate: Installed on 2022-11-04 (335 days ago) InstallationMedia: Ubuntu-Server 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2038662/+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 2038662] Re: systemd-nspawn error: "Failed to mount image file system: Value too large for defined data type"
Grr... it works if I first run a dummy command within the machine: systemd-nspawn -M jammy-rootfs --as-pid2 passwd root machinectl start jammy-rootfs # it's working now! machinectl login jammy-rootfs (Even just "echo hello world" does the job) However if you go back to a *fresh* image then it fails: machinectl stop jammy-rootfs machinectl remove jammy-rootfs machinectl pull-raw http://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img jammy-rootfs # Both of these commands consistently fail: machinectl start jammy-rootfs systemd-nspawn -M jammy-rootfs -U -b -n Conclusion: this is confusing. The solution is to manually spawn any command within the image, *before* attempting to start the image with --boot. -- 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/2038662 Title: systemd-nspawn error: "Failed to mount image file system: Value too large for defined data type" Status in systemd package in Ubuntu: New Bug description: Two-line reproducer: run this on an Ubuntu 22.04 server. sudo machinectl pull-raw http://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img jammy-rootfs sudo machinectl start jammy-rootfs Response: Job for systemd-nspawn@jammy-rootfs.service failed because the control process exited with error code. Here's the relevant output from "journalctl -xeu systemd-nspawn@jammy-rootfs.service" ░░ A start job for unit systemd-nspawn@jammy-rootfs.service has begun execution. ░░ ░░ The job identifier is 3223. Oct 06 13:13:21 brian-kit systemd-nspawn[36720]: Failed to mount image file system: Value too large for defined data type Oct 06 13:13:21 brian-kit systemd-nspawn[36688]: Short read while reading cgroup mode (0 bytes). The child is most likely dead. Oct 06 13:13:21 brian-kit systemd[1]: systemd-nspawn@jammy-rootfs.service: Main process exited, code=exited, status=1/FAILURE ░░ Subject: Unit process exited ░░ Defined-By: systemd ░░ Support: http://www.ubuntu.com/support ░░ ░░ An ExecStart= process belonging to unit systemd-nspawn@jammy-rootfs.service has exited. ░░ ░░ The process' exit code is 'exited' and its exit status is 1. Oct 06 13:13:21 brian-kit systemd[1]: systemd-nspawn@jammy-rootfs.service: Failed with result 'exit-code'. This appears to be similar to https://github.com/systemd/systemd/issues/20989 If so, a fix was committed in March 2022: https://github.com/systemd/systemd/pull/22774 but maybe that was too late for 22.04? Or this is a different problem? EDIT: the reproducer from https://github.com/systemd/systemd/issues/20989#issuecomment-997024152 also reproduces the problem. # rm -rf /var/lib/machines/my-container/ # mkdir -p /var/lib/machines/my-container/etc # cp /etc/os-release /var/lib/machines/my-container/etc/ # systemd-nspawn -U -b -D /var/lib/machines/my-container/ Spawning container my-container on /var/lib/machines/my-container. Press ^] three times within 1s to kill container. Selected user namespace base 972619776 and range 65536. Failed to create directory at /var/lib/machines/my-container/usr: Value too large for defined data type ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: systemd-container 249.11-0ubuntu3.10 ProcVersionSignature: Ubuntu 5.15.0-84.93-generic 5.15.116 Uname: Linux 5.15.0-84-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CloudArchitecture: x86_64 CloudID: none CloudName: none CloudPlatform: none CloudSubPlatform: config Date: Fri Oct 6 13:10:41 2023 InstallationDate: Installed on 2022-11-04 (335 days ago) InstallationMedia: Ubuntu-Server 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2038662/+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 2038662] Re: systemd-nspawn error: "Failed to mount image file system: Value too large for defined data type"
** Description changed: Two-line reproducer: run this on an Ubuntu 22.04 server. sudo machinectl pull-raw http://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img jammy-rootfs sudo machinectl start jammy-rootfs Response: Job for systemd-nspawn@jammy-rootfs.service failed because the control process exited with error code. Here's the relevant output from "journalctl -xeu systemd-nspawn@jammy-rootfs.service" ░░ A start job for unit systemd-nspawn@jammy-rootfs.service has begun execution. ░░ ░░ The job identifier is 3223. Oct 06 13:13:21 brian-kit systemd-nspawn[36720]: Failed to mount image file system: Value too large for defined data type Oct 06 13:13:21 brian-kit systemd-nspawn[36688]: Short read while reading cgroup mode (0 bytes). The child is most likely dead. Oct 06 13:13:21 brian-kit systemd[1]: systemd-nspawn@jammy-rootfs.service: Main process exited, code=exited, status=1/FAILURE ░░ Subject: Unit process exited ░░ Defined-By: systemd ░░ Support: http://www.ubuntu.com/support ░░ ░░ An ExecStart= process belonging to unit systemd-nspawn@jammy-rootfs.service has exited. ░░ ░░ The process' exit code is 'exited' and its exit status is 1. Oct 06 13:13:21 brian-kit systemd[1]: systemd-nspawn@jammy-rootfs.service: Failed with result 'exit-code'. This appears to be similar to - https://github.com/systemd/systemd/issues/20989 + https://github.com/systemd/systemd/issues/20989#issuecomment-997024152 If so, a fix was committed in March 2022: https://github.com/systemd/systemd/pull/22774 but maybe that was too late for 22.04? Or this is a different problem? ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: systemd-container 249.11-0ubuntu3.10 ProcVersionSignature: Ubuntu 5.15.0-84.93-generic 5.15.116 Uname: Linux 5.15.0-84-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CloudArchitecture: x86_64 CloudID: none CloudName: none CloudPlatform: none CloudSubPlatform: config Date: Fri Oct 6 13:10:41 2023 InstallationDate: Installed on 2022-11-04 (335 days ago) InstallationMedia: Ubuntu-Server 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809) ProcEnviron: - TERM=xterm-256color - PATH=(custom, no user) - LANG=en_GB.UTF-8 - SHELL=/bin/bash + TERM=xterm-256color + PATH=(custom, no user) + LANG=en_GB.UTF-8 + SHELL=/bin/bash SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) ** Description changed: Two-line reproducer: run this on an Ubuntu 22.04 server. sudo machinectl pull-raw http://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img jammy-rootfs sudo machinectl start jammy-rootfs Response: Job for systemd-nspawn@jammy-rootfs.service failed because the control process exited with error code. Here's the relevant output from "journalctl -xeu systemd-nspawn@jammy-rootfs.service" ░░ A start job for unit systemd-nspawn@jammy-rootfs.service has begun execution. ░░ ░░ The job identifier is 3223. Oct 06 13:13:21 brian-kit systemd-nspawn[36720]: Failed to mount image file system: Value too large for defined data type Oct 06 13:13:21 brian-kit systemd-nspawn[36688]: Short read while reading cgroup mode (0 bytes). The child is most likely dead. Oct 06 13:13:21 brian-kit systemd[1]: systemd-nspawn@jammy-rootfs.service: Main process exited, code=exited, status=1/FAILURE ░░ Subject: Unit process exited ░░ Defined-By: systemd ░░ Support: http://www.ubuntu.com/support ░░ ░░ An ExecStart= process belonging to unit systemd-nspawn@jammy-rootfs.service has exited. ░░ ░░ The process' exit code is 'exited' and its exit status is 1. Oct 06 13:13:21 brian-kit systemd[1]: systemd-nspawn@jammy-rootfs.service: Failed with result 'exit-code'. This appears to be similar to - https://github.com/systemd/systemd/issues/20989#issuecomment-997024152 + https://github.com/systemd/systemd/issues/20989 If so, a fix was committed in March 2022: https://github.com/systemd/systemd/pull/22774 but maybe that was too late for 22.04? Or this is a different problem? + + EDIT: the reproducer from + https://github.com/systemd/systemd/issues/20989#issuecomment-997024152 + also reproduces the problem. + + # rm -rf /var/lib/machines/my-container/ + # mkdir -p /var/lib/machines/my-container/etc + # cp /etc/os-release /var/lib/machines/my-container/etc/ + # systemd-nspawn -U -b -D /var/lib/machines/my-container/ + Spawning container my-container on /var/lib/machines/my-container. + Press ^] three times within 1s to kill container. + Selected user namespace base 972619776 and range 65536. + Failed to create directory at /var/lib/machines/my-container/usr: Value too large for defined data type + ProblemType: Bug DistroRelease: Ubuntu
[Touch-packages] [Bug 2038662] [NEW] systemd-nspawn error: "Failed to mount image file system: Value too large for defined data type"
Public bug reported: Two-line reproducer: run this on an Ubuntu 22.04 server. sudo machinectl pull-raw http://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img jammy-rootfs sudo machinectl start jammy-rootfs Response: Job for systemd-nspawn@jammy-rootfs.service failed because the control process exited with error code. Here's the relevant output from "journalctl -xeu systemd-nspawn@jammy-rootfs.service" ░░ A start job for unit systemd-nspawn@jammy-rootfs.service has begun execution. ░░ ░░ The job identifier is 3223. Oct 06 13:13:21 brian-kit systemd-nspawn[36720]: Failed to mount image file system: Value too large for defined data type Oct 06 13:13:21 brian-kit systemd-nspawn[36688]: Short read while reading cgroup mode (0 bytes). The child is most likely dead. Oct 06 13:13:21 brian-kit systemd[1]: systemd-nspawn@jammy-rootfs.service: Main process exited, code=exited, status=1/FAILURE ░░ Subject: Unit process exited ░░ Defined-By: systemd ░░ Support: http://www.ubuntu.com/support ░░ ░░ An ExecStart= process belonging to unit systemd-nspawn@jammy-rootfs.service has exited. ░░ ░░ The process' exit code is 'exited' and its exit status is 1. Oct 06 13:13:21 brian-kit systemd[1]: systemd-nspawn@jammy-rootfs.service: Failed with result 'exit-code'. This appears to be similar to https://github.com/systemd/systemd/issues/20989 If so, a fix was committed in March 2022: https://github.com/systemd/systemd/pull/22774 but maybe that was too late for 22.04? Or this is a different problem? ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: systemd-container 249.11-0ubuntu3.10 ProcVersionSignature: Ubuntu 5.15.0-84.93-generic 5.15.116 Uname: Linux 5.15.0-84-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CloudArchitecture: x86_64 CloudID: none CloudName: none CloudPlatform: none CloudSubPlatform: config Date: Fri Oct 6 13:10:41 2023 InstallationDate: Installed on 2022-11-04 (335 days ago) InstallationMedia: Ubuntu-Server 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy uec-images -- 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/2038662 Title: systemd-nspawn error: "Failed to mount image file system: Value too large for defined data type" Status in systemd package in Ubuntu: New Bug description: Two-line reproducer: run this on an Ubuntu 22.04 server. sudo machinectl pull-raw http://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img jammy-rootfs sudo machinectl start jammy-rootfs Response: Job for systemd-nspawn@jammy-rootfs.service failed because the control process exited with error code. Here's the relevant output from "journalctl -xeu systemd-nspawn@jammy-rootfs.service" ░░ A start job for unit systemd-nspawn@jammy-rootfs.service has begun execution. ░░ ░░ The job identifier is 3223. Oct 06 13:13:21 brian-kit systemd-nspawn[36720]: Failed to mount image file system: Value too large for defined data type Oct 06 13:13:21 brian-kit systemd-nspawn[36688]: Short read while reading cgroup mode (0 bytes). The child is most likely dead. Oct 06 13:13:21 brian-kit systemd[1]: systemd-nspawn@jammy-rootfs.service: Main process exited, code=exited, status=1/FAILURE ░░ Subject: Unit process exited ░░ Defined-By: systemd ░░ Support: http://www.ubuntu.com/support ░░ ░░ An ExecStart= process belonging to unit systemd-nspawn@jammy-rootfs.service has exited. ░░ ░░ The process' exit code is 'exited' and its exit status is 1. Oct 06 13:13:21 brian-kit systemd[1]: systemd-nspawn@jammy-rootfs.service: Failed with result 'exit-code'. This appears to be similar to https://github.com/systemd/systemd/issues/20989 If so, a fix was committed in March 2022: https://github.com/systemd/systemd/pull/22774 but maybe that was too late for 22.04? Or this is a different problem? ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: systemd-container 249.11-0ubuntu3.10 ProcVersionSignature: Ubuntu 5.15.0-84.93-generic 5.15.116 Uname: Linux 5.15.0-84-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 CasperMD5CheckResult: pass CloudArchitecture: x86_64 CloudID: none CloudName: none CloudPlatform: none CloudSubPlatform: config Date: Fri Oct 6 13:10:41 2023 InstallationDate: Installed on 2022-11-04 (335 days ago) InstallationMedia: Ubuntu-Server 22.04.1
[Touch-packages] [Bug 1866573] Re: rsyslog does not contain pmciscoios module
This module is now present in Ubuntu 22.04, so this issue can be closed. $ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=22.04 DISTRIB_CODENAME=jammy DISTRIB_DESCRIPTION="Ubuntu 22.04.1 LTS" $ dpkg-query -L rsyslog | grep pmciscoios /usr/lib/x86_64-linux-gnu/rsyslog/pmciscoios.so -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1866573 Title: rsyslog does not contain pmciscoios module Status in rsyslog package in Ubuntu: New Bug description: rsyslog has a parser module for Cisco IOS formatted syslog messages: https://www.rsyslog.com/doc/master/configuration/modules/pmciscoios.html https://github.com/rsyslog/rsyslog/tree/master/plugins/pmciscoios It has been in rsyslog since early days (8.3.4); Bionic has 8.16.0. However, the Ubuntu Bionic package of rsyslog neither compiles pmciscoios into the binary, nor includes it as a loadable module. To replicate, try these lines in /etc/rsyslog.conf: module(load="pmciscoios") $RulesetParser rsyslog.ciscoios and restart rsyslog; you get these errors Mar 8 21:54:39 noc rsyslogd-2066: could not load module '/usr/lib/rsyslog/pmciscoios.so', dlopen: /usr/lib/rsyslog/pmciscoios.so: cannot open shared object file: No such file or directory [v8.16.0 try http://www.rsyslog.com/e/2066 ] Mar 8 21:54:39 noc rsyslogd-2159: error: parser 'rsyslog.ciscoios' unknown at this time (maybe defined too late in rsyslog.conf?) [v8.16.0 try http://www.rsyslog.com/e/2159 ] There is "pmcisconames.so", but that is something else: https://github.com/rsyslog/rsyslog/blob/master/contrib/pmcisconames/pmcisconames.c # dpkg-query -L rsyslog | grep pm.*so /usr/lib/rsyslog/pmaixforwardedfrom.so /usr/lib/rsyslog/pmlastmsg.so /usr/lib/rsyslog/pmsnare.so /usr/lib/rsyslog/pmcisconames.so There doesn't appear to be a separate package with the module: # apt-cache search rsyslog ... Upstream Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929608 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: rsyslog 8.16.0-1ubuntu3.1 ProcVersionSignature: Ubuntu 4.4.0-166.195-generic 4.4.194 Uname: Linux 4.4.0-166-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.19 Architecture: amd64 Date: Sun Mar 8 21:53:43 2020 ProcEnviron: SHELL=/bin/bash TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SourcePackage: rsyslog UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.rsyslog.conf: 2020-03-08T21:53:39.943611 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1866573/+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 1667016] Re: tcpdump in lxd container: apparmor blocks writing to stdout/stderr
*** This bug is a duplicate of bug 1641236 *** https://bugs.launchpad.net/bugs/1641236 The duplicate status of this bug is still wrong. A workaround has been provided at https://github.com/lxc/lxd/issues/2930#issuecomment-1418752618 Inside the container: ### Ubuntu 18.04, 20.04 echo "/dev/pts/* rw," >/etc/apparmor.d/local/usr.sbin.tcpdump systemctl reload apparmor ### Ubuntu 22.04 echo "/dev/pts/* rw," >/etc/apparmor.d/local/usr.bin.tcpdump systemctl reload apparmor -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1667016 Title: tcpdump in lxd container: apparmor blocks writing to stdout/stderr Status in apparmor package in Ubuntu: Confirmed Bug description: [ubuntu 16.04, lxd 2.0.8 or 2.0.9, tcpdump 4.7.4 or 4.9.0] If you ssh into an lxd container as a normal user, and inside that container run "sudo tcpdump", the tcpdump process is blocked from writing to stdout/stderr. This appears to be due to apparmor: disabling apparmor for tcpdump makes the problem go away. ln -s /etc/apparmor.d/usr.sbin.tcpdump /etc/apparmor.d/disable/ Note: this is a different bug from #1641236. In that bug, the user did "lxc exec bash" to get a shell in the container; the stdout fd was being passed from the outer host to the container. But in this case, the pty is being created entirely inside the container by sshd. Details copied from https://github.com/lxc/lxd/issues/2930 # Steps to reproduce 1. Create two Ubuntu 16.04 lxd containers, one privileged, one not. 2. ssh into each one, and then use `sudo -s` to get root. (Do not use `lxc exec` because of issue #1641236) 3. Inside one run `tcpdump -i eth0 -nn not tcp port 22`, and ping from the other. tcpdump in the privileged container works just fine. tcpdump in the unprivileged container does not show any output. But if I run strace on it I see errors attempting to access stdout and stderr: ~~~ ioctl(1, TCGETS, 0x7fff97c8d680)= -1 ENOTTY (Inappropriate ioctl for device) ... write(2, "tcpdump: verbose output suppress"..., 75) = -1 EACCES (Permission denied) write(2, "listening on eth0, link-type EN1"..., 74) = -1 EACCES (Permission denied) ~~~ This is very weird. Even more weird: the following command *does* capture packets: ~~~ tcpdump -i eth0 -nn -w foo.pcap ~~~ The file foo.pcap grows. This proves it's nothing to do with network capture perms. But the following command shows no output: ~~~ tcpdump -r foo.pcap -nn ~~~ And again it's because it can't write to stdout: ~~~ fstat(1, 0x7ffe2fb5eb10)= -1 EACCES (Permission denied) read(3, "", 4096) = 0 write(1, "14:34:30.618180 IP6 fe80::c609:6"..., 1740) = -1 EACCES (Permission denied) ~~~ I had originally thought this was to do with capabilities. But if I run `capsh --print` inside both containers, they both have `cap_net_raw` and `cap_net_admin`. In fact, the unprivileged container has two additional capabilities! (`cap_mac_override` and `cap_mac_admin`) So now I suspect that apparmor is at fault. dmesg dmesg output generated by the following steps: * start tcpdump * wait 5 seconds * send 1 ping from other side * wait 5 seconds * stop tcpdump ~~~ [429020.685987] audit: type=1400 audit(1487774339.708:3597): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="/dev/pts/0" pid=12539 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=10 ouid=101001 [429020.686000] audit: type=1400 audit(1487774339.708:3598): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="/dev/pts/0" pid=12539 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=10 ouid=101001 [429020.686013] audit: type=1400 audit(1487774339.708:3599): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="/dev/pts/0" pid=12539 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=10 ouid=101001 [429020.686022] audit: type=1400 audit(1487774339.708:3600): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="/dev/pts/0" pid=12539 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=10 ouid=101001 [429020.716725] device eth0 entered promiscuous mode [429020.741308] audit: type=1400 audit(1487774339.764:3601): apparmor="DENIED" operation="file_perm" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="apparmor/.null" pid=12539 comm="tcpdump" requested_mask="w" denied_mask="w" fsuid=10 ouid=0 [429020.741330] audit: type=1400 audit(1487774339.764:3602):
[Touch-packages] [Bug 1956039] Re: BADSIG 871920D1991BC93C Ubuntu Archive Automatic Signing Key (2018)
I got the same error, also going via apt-cacher-ng: $ sudo apt-get update Hit:1 http://gb.archive.ubuntu.com/ubuntu jammy InRelease Get:2 http://gb.archive.ubuntu.com/ubuntu jammy-updates InRelease [114 kB] Get:3 http://gb.archive.ubuntu.com/ubuntu jammy-backports InRelease [99.8 kB] Hit:4 https://ppa.launchpadcontent.net/gns3/ppa/ubuntu jammy InRelease Hit:5 https://download.docker.com/linux/ubuntu jammy InRelease Get:6 http://gb.archive.ubuntu.com/ubuntu jammy-security InRelease [110 kB] Err:2 http://gb.archive.ubuntu.com/ubuntu jammy-updates InRelease The following signatures were invalid: BADSIG 871920D1991BC93C Ubuntu Archive Automatic Signing Key (2018) Hit:7 https://packagecloud.io/netdata/netdata/ubuntu jammy InRelease Hit:8 https://packagecloud.io/netdata/netdata-repoconfig/ubuntu jammy InRelease Hit:9 https://apt.syncthing.net syncthing InRelease Fetched 324 kB in 2s (148 kB/s) Reading package lists... Done W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://gb.archive.ubuntu.com/ubuntu jammy-updates InRelease: The following signatures were invalid: BADSIG 871920D1991BC93C Ubuntu Archive Automatic Signing Key (2018) W: Failed to fetch http://gb.archive.ubuntu.com/ubuntu/dists/jammy-updates/InRelease The following signatures were invalid: BADSIG 871920D1991BC93C Ubuntu Archive Automatic Signing Key (2018) W: Some index files failed to download. They have been ignored, or old ones used instead. Note that in my case the error was for "jammy-updates". The solution for me was: $ sudo rm -rf /var/cache/apt-cacher-ng/uburep/dists/jammy-updates/ Then: $ sudo apt-get update Hit:1 http://gb.archive.ubuntu.com/ubuntu jammy InRelease Get:2 http://gb.archive.ubuntu.com/ubuntu jammy-backports InRelease [99.8 kB] Get:3 http://gb.archive.ubuntu.com/ubuntu jammy-security InRelease [110 kB] Get:4 http://gb.archive.ubuntu.com/ubuntu jammy-updates InRelease [114 kB] Hit:5 https://ppa.launchpadcontent.net/gns3/ppa/ubuntu jammy InRelease Hit:6 https://download.docker.com/linux/ubuntu jammy InRelease Hit:7 https://apt.syncthing.net syncthing InRelease Get:8 http://gb.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages [795 kB] Get:9 http://gb.archive.ubuntu.com/ubuntu jammy-updates/main Translation-en [177 kB] Get:10 http://gb.archive.ubuntu.com/ubuntu jammy-updates/restricted amd64 Packages [521 kB] Get:11 http://gb.archive.ubuntu.com/ubuntu jammy-updates/restricted Translation-en [79.7 kB] Hit:12 https://packagecloud.io/netdata/netdata/ubuntu jammy InRelease Hit:13 https://packagecloud.io/netdata/netdata-repoconfig/ubuntu jammy InRelease Fetched 1,897 kB in 2s (938 kB/s) Reading package lists... Done $ Hence getting into this bad state looks like some internal problem with apt-cacher-ng. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1956039 Title: BADSIG 871920D1991BC93C Ubuntu Archive Automatic Signing Key (2018) Status in apt package in Ubuntu: Confirmed Bug description: Updating Jammy fails with: Get:2 http://archive.ubuntu.com/ubuntu jammy InRelease [270 kB] Err:2 http://archive.ubuntu.com/ubuntu jammy InRelease The following signatures were invalid: BADSIG 871920D1991BC93C Ubuntu Archive Automatic Signing Key (2018) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1956039/+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 1866573] [NEW] rsyslog does not contain pmciscoios module
Public bug reported: rsyslog has a parser module for Cisco IOS formatted syslog messages: https://www.rsyslog.com/doc/master/configuration/modules/pmciscoios.html https://github.com/rsyslog/rsyslog/tree/master/plugins/pmciscoios It has been in rsyslog since early days (8.3.4); Bionic has 8.16.0. However, the Ubuntu Bionic package of rsyslog neither compiles pmciscoios into the binary, nor includes it as a loadable module. To replicate, try these lines in /etc/rsyslog.conf: module(load="pmciscoios") $RulesetParser rsyslog.ciscoios and restart rsyslog; you get these errors Mar 8 21:54:39 noc rsyslogd-2066: could not load module '/usr/lib/rsyslog/pmciscoios.so', dlopen: /usr/lib/rsyslog/pmciscoios.so: cannot open shared object file: No such file or directory [v8.16.0 try http://www.rsyslog.com/e/2066 ] Mar 8 21:54:39 noc rsyslogd-2159: error: parser 'rsyslog.ciscoios' unknown at this time (maybe defined too late in rsyslog.conf?) [v8.16.0 try http://www.rsyslog.com/e/2159 ] There is "pmcisconames.so", but that is something else: https://github.com/rsyslog/rsyslog/blob/master/contrib/pmcisconames/pmcisconames.c # dpkg-query -L rsyslog | grep pm.*so /usr/lib/rsyslog/pmaixforwardedfrom.so /usr/lib/rsyslog/pmlastmsg.so /usr/lib/rsyslog/pmsnare.so /usr/lib/rsyslog/pmcisconames.so There doesn't appear to be a separate package with the module: # apt-cache search rsyslog ... Upstream Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929608 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: rsyslog 8.16.0-1ubuntu3.1 ProcVersionSignature: Ubuntu 4.4.0-166.195-generic 4.4.194 Uname: Linux 4.4.0-166-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.19 Architecture: amd64 Date: Sun Mar 8 21:53:43 2020 ProcEnviron: SHELL=/bin/bash TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SourcePackage: rsyslog UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.rsyslog.conf: 2020-03-08T21:53:39.943611 ** Affects: rsyslog (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug third-party-packages uec-images xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1866573 Title: rsyslog does not contain pmciscoios module Status in rsyslog package in Ubuntu: New Bug description: rsyslog has a parser module for Cisco IOS formatted syslog messages: https://www.rsyslog.com/doc/master/configuration/modules/pmciscoios.html https://github.com/rsyslog/rsyslog/tree/master/plugins/pmciscoios It has been in rsyslog since early days (8.3.4); Bionic has 8.16.0. However, the Ubuntu Bionic package of rsyslog neither compiles pmciscoios into the binary, nor includes it as a loadable module. To replicate, try these lines in /etc/rsyslog.conf: module(load="pmciscoios") $RulesetParser rsyslog.ciscoios and restart rsyslog; you get these errors Mar 8 21:54:39 noc rsyslogd-2066: could not load module '/usr/lib/rsyslog/pmciscoios.so', dlopen: /usr/lib/rsyslog/pmciscoios.so: cannot open shared object file: No such file or directory [v8.16.0 try http://www.rsyslog.com/e/2066 ] Mar 8 21:54:39 noc rsyslogd-2159: error: parser 'rsyslog.ciscoios' unknown at this time (maybe defined too late in rsyslog.conf?) [v8.16.0 try http://www.rsyslog.com/e/2159 ] There is "pmcisconames.so", but that is something else: https://github.com/rsyslog/rsyslog/blob/master/contrib/pmcisconames/pmcisconames.c # dpkg-query -L rsyslog | grep pm.*so /usr/lib/rsyslog/pmaixforwardedfrom.so /usr/lib/rsyslog/pmlastmsg.so /usr/lib/rsyslog/pmsnare.so /usr/lib/rsyslog/pmcisconames.so There doesn't appear to be a separate package with the module: # apt-cache search rsyslog ... Upstream Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929608 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: rsyslog 8.16.0-1ubuntu3.1 ProcVersionSignature: Ubuntu 4.4.0-166.195-generic 4.4.194 Uname: Linux 4.4.0-166-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.19 Architecture: amd64 Date: Sun Mar 8 21:53:43 2020 ProcEnviron: SHELL=/bin/bash TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SourcePackage: rsyslog UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.rsyslog.conf: 2020-03-08T21:53:39.943611 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1866573/+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 1667016] Re: tcpdump in lxd container: apparmor blocks writing to stdout/stderr
*** This bug is a duplicate of bug 1641236 *** https://bugs.launchpad.net/bugs/1641236 I believe this bug has been wrongly marked as a duplicate of #1641236. I described in the second paragraph of the bug report why this is *not* a duplicate. #1641236 is when lxc exec passes an open pty from the host to the container. This bug (#1667016) is specifically when the pty is opened within the container, by connecting to sshd inside the container. See also: https://github.com/lxc/lxd/issues/2930 ** Bug watch added: LXD bug tracker #2930 https://github.com/lxc/lxd/issues/2930 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1667016 Title: tcpdump in lxd container: apparmor blocks writing to stdout/stderr Status in apparmor package in Ubuntu: Confirmed Bug description: [ubuntu 16.04, lxd 2.0.8 or 2.0.9, tcpdump 4.7.4 or 4.9.0] If you ssh into an lxd container as a normal user, and inside that container run "sudo tcpdump", the tcpdump process is blocked from writing to stdout/stderr. This appears to be due to apparmor: disabling apparmor for tcpdump makes the problem go away. ln -s /etc/apparmor.d/usr.sbin.tcpdump /etc/apparmor.d/disable/ Note: this is a different bug from #1641236. In that bug, the user did "lxc exec bash" to get a shell in the container; the stdout fd was being passed from the outer host to the container. But in this case, the pty is being created entirely inside the container by sshd. Details copied from https://github.com/lxc/lxd/issues/2930 # Steps to reproduce 1. Create two Ubuntu 16.04 lxd containers, one privileged, one not. 2. ssh into each one, and then use `sudo -s` to get root. (Do not use `lxc exec` because of issue #1641236) 3. Inside one run `tcpdump -i eth0 -nn not tcp port 22`, and ping from the other. tcpdump in the privileged container works just fine. tcpdump in the unprivileged container does not show any output. But if I run strace on it I see errors attempting to access stdout and stderr: ~~~ ioctl(1, TCGETS, 0x7fff97c8d680)= -1 ENOTTY (Inappropriate ioctl for device) ... write(2, "tcpdump: verbose output suppress"..., 75) = -1 EACCES (Permission denied) write(2, "listening on eth0, link-type EN1"..., 74) = -1 EACCES (Permission denied) ~~~ This is very weird. Even more weird: the following command *does* capture packets: ~~~ tcpdump -i eth0 -nn -w foo.pcap ~~~ The file foo.pcap grows. This proves it's nothing to do with network capture perms. But the following command shows no output: ~~~ tcpdump -r foo.pcap -nn ~~~ And again it's because it can't write to stdout: ~~~ fstat(1, 0x7ffe2fb5eb10)= -1 EACCES (Permission denied) read(3, "", 4096) = 0 write(1, "14:34:30.618180 IP6 fe80::c609:6"..., 1740) = -1 EACCES (Permission denied) ~~~ I had originally thought this was to do with capabilities. But if I run `capsh --print` inside both containers, they both have `cap_net_raw` and `cap_net_admin`. In fact, the unprivileged container has two additional capabilities! (`cap_mac_override` and `cap_mac_admin`) So now I suspect that apparmor is at fault. dmesg dmesg output generated by the following steps: * start tcpdump * wait 5 seconds * send 1 ping from other side * wait 5 seconds * stop tcpdump ~~~ [429020.685987] audit: type=1400 audit(1487774339.708:3597): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="/dev/pts/0" pid=12539 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=10 ouid=101001 [429020.686000] audit: type=1400 audit(1487774339.708:3598): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="/dev/pts/0" pid=12539 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=10 ouid=101001 [429020.686013] audit: type=1400 audit(1487774339.708:3599): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="/dev/pts/0" pid=12539 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=10 ouid=101001 [429020.686022] audit: type=1400 audit(1487774339.708:3600): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="/dev/pts/0" pid=12539 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=10 ouid=101001 [429020.716725] device eth0 entered promiscuous mode [429020.741308] audit: type=1400 audit(1487774339.764:3601): apparmor="DENIED" operation="file_perm" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="apparmor/.null" pid=12539 comm="tcpdump" requested_mask="w"
[Touch-packages] [Bug 1630946] Re: ubuntu-server depends on open-iscsi and runs iscsid
Awesome, thanks again! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1630946 Title: ubuntu-server depends on open-iscsi and runs iscsid Status in ubuntu-meta package in Ubuntu: Fix Released Bug description: ubuntu-server has a hard dependency on open-iscsi, which means there is a daemon running (iscsid), and the package cannot be removed. All unnecessary daemons are a cause of concern when auditing a system. Propose moving this to "Recommends" instead, which currently has: Recommends: lxd, snapd Related bugs: * bug 1755858: iscsid autostarts on all servers when it has nothing to do ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ubuntu-server 1.361 ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19 Uname: Linux 4.4.0-38-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 Date: Thu Oct 6 10:43:04 2016 Ec2AMI: ami-c06b1eb3 Ec2AMIManifest: (unknown) Ec2AvailabilityZone: eu-west-1a Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable ProcEnviron: TERM=xterm-256color SHELL=/bin/bash PATH=(custom, user) LANG=en_US.UTF-8 XDG_RUNTIME_DIR= SourcePackage: ubuntu-meta UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1630946/+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 1630946] Re: ubuntu-server depends on open-iscsi and runs iscsid
> no matter if we succeed/fail there one can at least later remove open- iscsid if he wants without taking out the ubuntu-server meta. That's perfect - thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1630946 Title: ubuntu-server depends on open-iscsi and runs iscsid Status in ubuntu-meta package in Ubuntu: Confirmed Bug description: ubuntu-server has a hard dependency on open-iscsi, which means there is a daemon running (iscsid), and the package cannot be removed. All unnecessary daemons are a cause of concern when auditing a system. Propose moving this to "Recommends" instead, which currently has: Recommends: lxd, snapd ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ubuntu-server 1.361 ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19 Uname: Linux 4.4.0-38-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 Date: Thu Oct 6 10:43:04 2016 Ec2AMI: ami-c06b1eb3 Ec2AMIManifest: (unknown) Ec2AvailabilityZone: eu-west-1a Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable ProcEnviron: TERM=xterm-256color SHELL=/bin/bash PATH=(custom, user) LANG=en_US.UTF-8 XDG_RUNTIME_DIR= SourcePackage: ubuntu-meta UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1630946/+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 1630946] Re: ubuntu-server depends on open-iscsi and runs iscsid
Workaround: systemctl stop iscsid systemctl disable iscsid ... but I still object to not being able to remove it without also removing ubuntu-server. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1630946 Title: ubuntu-server depends on open-iscsi and runs iscsid Status in ubuntu-meta package in Ubuntu: Confirmed Bug description: ubuntu-server has a hard dependency on open-iscsi, which means there is a daemon running (iscsid), and the package cannot be removed. All unnecessary daemons are a cause of concern when auditing a system. Propose moving this to "Recommends" instead, which currently has: Recommends: lxd, snapd ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ubuntu-server 1.361 ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19 Uname: Linux 4.4.0-38-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 Date: Thu Oct 6 10:43:04 2016 Ec2AMI: ami-c06b1eb3 Ec2AMIManifest: (unknown) Ec2AvailabilityZone: eu-west-1a Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable ProcEnviron: TERM=xterm-256color SHELL=/bin/bash PATH=(custom, user) LANG=en_US.UTF-8 XDG_RUNTIME_DIR= SourcePackage: ubuntu-meta UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1630946/+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 591823] Re: "File descriptor \d+ (\S+) leaked on lvs invocation."
Just doing an "apt-get dist-upgrade" on a 16.04 VM: ... Setting up grub-common (2.02~beta2-36ubuntu3.11) ... Installing new version of config file /etc/grub.d/10_linux ... update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults Setting up grub-pc-bin (2.02~beta2-36ubuntu3.11) ... Setting up grub2-common (2.02~beta2-36ubuntu3.11) ... Setting up grub-pc (2.02~beta2-36ubuntu3.11) ... Installing for i386-pc platform. File descriptor 3 (pipe:[136263]) leaked on vgs invocation. Parent PID 18940: grub-install File descriptor 3 (pipe:[136263]) leaked on vgs invocation. Parent PID 18940: grub-install File descriptor 3 (pipe:[136263]) leaked on vgs invocation. Parent PID 18940: grub-install Installation finished. No error reported. Generating grub configuration file ... Found linux image: /boot/vmlinuz-4.4.0-83-generic Found initrd image: /boot/initrd.img-4.4.0-83-generic Found linux image: /boot/vmlinuz-4.4.0-21-generic Found initrd image: /boot/initrd.img-4.4.0-21-generic done ... Setting up initramfs-tools-core (0.122ubuntu8.8) ... Setting up initramfs-tools (0.122ubuntu8.8) ... update-initramfs: deferring update (trigger activated) Setting up mdadm (3.3-2ubuntu7.2) ... update-initramfs: deferring update (trigger activated) Generating grub configuration file ... File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 19859: grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 19859: grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 19899: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 19899: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 19909: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 19909: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 19919: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 19919: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 19929: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 19929: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 19979: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 19979: /usr/sbin/grub-probe Found linux image: /boot/vmlinuz-4.4.0-83-generic Found initrd image: /boot/initrd.img-4.4.0-83-generic File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 20061: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 20061: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 20072: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 20072: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 20082: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 20082: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 20092: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 20092: /usr/sbin/grub-probe Found linux image: /boot/vmlinuz-4.4.0-21-generic Found initrd image: /boot/initrd.img-4.4.0-21-generic File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 20335: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on vgs invocation. Parent PID 20335: /usr/sbin/grub-probe File descriptor 3 (pipe:[140340]) leaked on lvs invocation. Parent PID 20417: /bin/sh done update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults ... It updated 119 packages, but lvm2 was not one of them. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/591823 Title: "File descriptor \d+ (\S+) leaked on lvs invocation." Status in aptitude: Fix Released Status in lvm2: Fix Released Status in lvm2 package in Ubuntu: Opinion Bug description: If you see messages like these: File descriptor 40 (/var/lib/dpkg/status) leaked on lvs invocation. Parent PID 1854: /bin/sh File descriptor 41 (/var/lib/dpkg/status) leaked on lvs invocation. Parent PID 1854: /bin/sh File descriptor 42 (/var/lib/dpkg/status) leaked on lvs invocation. Parent PID 1854: /bin/sh File descriptor 43 (/var/lib/dpkg/status) leaked on lvs invocation. Parent PID 1854: /bin/sh You can set LVM_SUPPRESS_FD_WARNINGS to suppress these warnings. Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581339 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432986
[Touch-packages] [Bug 1688034] Re: 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd
I guess this also makes 1.8.16-0ubuntu1.3 a "security" update, since sudo+sssd now enforces policy which it should have done before, but didn't. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1688034 Title: 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd Status in sudo package in Ubuntu: New Bug description: ubuntu 16.04, enrolled with freeipa-client to FreeIPA 4.4.0 (under CentOS 7) With sudo 1.8.16-0ubuntu1, everything is fine: brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: root@api-dev:~# After update to 1.8.16-0ubuntu1.3, it no longer works: brian.candler@api-dev:~$ sudo -k brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: brian.candler is not allowed to run sudo on api-dev.int.example.com. This incident will be reported. This is repeatable: downgrade sudo and it works again. Seems very likely related to change made as part of #1607666, which changes how sudo policies are matched, but has unexpected regression. --- Additional info --- The sudo policy in IPA is extremely simple. It has a single rule, which says: - applies to users in groups "system_administrators" and "security_administrators" - applies to any host - applies to any command In LDAP under ou=sudoers tree, the groups are flattened out: # system administrators on all hosts, sudoers, ipa.example.com dn: cn=system administrators on all hosts,ou=sudoers,dc=ipa,dc=example,dc=com sudoRunAsGroup: ALL objectClass: sudoRole objectClass: top sudoUser: brian.candler sudoUser: ... sudoUser: ... list more users sudoUser: ... sudoRunAsUser: ALL sudoCommand: ALL sudoHost: ALL cn: system administrators on all hosts Under cn=sudorules,cn=sudo it refers to the groups rather than the individuals: # 59ffb10a-9c61-11e6-b5b8-00163efd5284, sudorules, sudo, ipa.example.com dn: ipaUniqueID=59ffb10a-9c61-11e6-b5b8-00163efd5284,cn=sudorules,cn=sudo,dc=ipa,dc=example,dc=com ipaSudoRunAsUserCategory: all ipaSudoRunAsGroupCategory: all description: admins have full sudo access on any host they can ssh into cmdCategory: all hostCategory: all memberUser: cn=system_administrators,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com memberUser: cn=security_administrators,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com objectClass: ipasudorule objectClass: ipaassociation ipaEnabledFlag: TRUE cn: system administrators on all hosts ipaUniqueID: 59ffb10a-9c61-11e6-b5b8-00163efd5284 I have no workaround other than downgrade. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: sudo 1.8.16-0ubuntu1.3 ProcVersionSignature: Ubuntu 4.4.0-1016.25-aws 4.4.59 Uname: Linux 4.4.0-1016-aws x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 Date: Wed May 3 16:01:23 2017 Ec2AMI: ami-a8d2d7ce Ec2AMIManifest: (unknown) Ec2AvailabilityZone: eu-west-1a Ec2InstanceType: t2.small Ec2Kernel: unavailable Ec2Ramdisk: unavailable ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: sudo UpgradeStatus: No upgrade log present (probably fresh install) VisudoCheck: /etc/sudoers: parsed OK /etc/sudoers.d/90-cloud-init-users: parsed OK /etc/sudoers.d/README: parsed OK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1688034/+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 1688034] Re: 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd
I found out how to enable debugging for sudoers: Debug sudo /var/log/sudo-debug all@info Debug sudoers.so /var/log/sudoers-debug all@info With the *new* sudo I get the following logged matching 'sssd': May 5 12:40:06 sudo[17912] sssd/ldap sudoHost 'ALL' ... MATCH! May 5 12:40:06 sudo[17912] sssd/ldap sudoUser '%system_administrators' ... not (brian.candler) May 5 12:40:06 sudo[17912] sssd/ldap sudoUser '%security_administrators' ... not (brian.candler) But with the *old* sudo I get: May 5 12:41:48 sudo[18384] sssd/ldap sudoHost 'ALL' ... MATCH! May 5 12:41:48 sudo[18384] sssd/ldap sudoRunAsUser 'ALL' ... MATCH! May 5 12:41:48 sudo[18384] sssd/ldap sudoCommand 'ALL' ... MATCH! It seems to be a behaviour change with group checking. The 'brian.candler' user *is* a member of one of those groups in IPA; but those groups are not posix groups so they are not visible using (e.g.) "id" I was able to solve the problem by adding objectClass: posixgroup gidNumber: to those group objects. After this, the sudoers log shows: May 5 13:11:50 sudo[19545] sssd/ldap sudoHost 'ALL' ... MATCH! May 5 13:11:50 sudo[19545] sssd/ldap sudoUser '%system_administrators' ... not (brian.candler) May 5 13:11:50 sudo[19545] sssd/ldap sudoUser '%security_administrators' ... MATCH! (brian.candler) May 5 13:11:50 sudo[19545] sssd/ldap sudoRunAsUser 'ALL' ... MATCH! May 5 13:11:50 sudo[19545] sssd/ldap sudoCommand 'ALL' ... MATCH! So: arguably this is not a bug, but a bug fix. Still, it would be nice if the release notes explained the potential for regression. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1688034 Title: 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd Status in sudo package in Ubuntu: New Bug description: ubuntu 16.04, enrolled with freeipa-client to FreeIPA 4.4.0 (under CentOS 7) With sudo 1.8.16-0ubuntu1, everything is fine: brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: root@api-dev:~# After update to 1.8.16-0ubuntu1.3, it no longer works: brian.candler@api-dev:~$ sudo -k brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: brian.candler is not allowed to run sudo on api-dev.int.example.com. This incident will be reported. This is repeatable: downgrade sudo and it works again. Seems very likely related to change made as part of #1607666, which changes how sudo policies are matched, but has unexpected regression. --- Additional info --- The sudo policy in IPA is extremely simple. It has a single rule, which says: - applies to users in groups "system_administrators" and "security_administrators" - applies to any host - applies to any command In LDAP under ou=sudoers tree, the groups are flattened out: # system administrators on all hosts, sudoers, ipa.example.com dn: cn=system administrators on all hosts,ou=sudoers,dc=ipa,dc=example,dc=com sudoRunAsGroup: ALL objectClass: sudoRole objectClass: top sudoUser: brian.candler sudoUser: ... sudoUser: ... list more users sudoUser: ... sudoRunAsUser: ALL sudoCommand: ALL sudoHost: ALL cn: system administrators on all hosts Under cn=sudorules,cn=sudo it refers to the groups rather than the individuals: # 59ffb10a-9c61-11e6-b5b8-00163efd5284, sudorules, sudo, ipa.example.com dn: ipaUniqueID=59ffb10a-9c61-11e6-b5b8-00163efd5284,cn=sudorules,cn=sudo,dc=ipa,dc=example,dc=com ipaSudoRunAsUserCategory: all ipaSudoRunAsGroupCategory: all description: admins have full sudo access on any host they can ssh into cmdCategory: all hostCategory: all memberUser: cn=system_administrators,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com memberUser: cn=security_administrators,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com objectClass: ipasudorule objectClass: ipaassociation ipaEnabledFlag: TRUE cn: system administrators on all hosts ipaUniqueID: 59ffb10a-9c61-11e6-b5b8-00163efd5284 I have no workaround other than downgrade. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: sudo 1.8.16-0ubuntu1.3 ProcVersionSignature: Ubuntu 4.4.0-1016.25-aws 4.4.59 Uname: Linux 4.4.0-1016-aws x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 Date: Wed May 3 16:01:23 2017 Ec2AMI: ami-a8d2d7ce Ec2AMIManifest: (unknown) Ec2AvailabilityZone: eu-west-1a Ec2InstanceType: t2.small Ec2Kernel: unavailable Ec2Ramdisk: unavailable ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: sudo UpgradeStatus: No upgrade log present (probably fresh install) VisudoCheck: /etc/sudoers: parsed OK /etc/sudoers.d/90-cloud-init-users: parsed OK /etc/sudoers.d/README: parsed OK To manage notifications about this bug go to:
[Touch-packages] [Bug 1688034] Re: 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd
Now trying with @debug instead of @info Slight munging of output to make it diffable, then diff -u: --- v1.debug.trim 2017-05-03 20:28:07.78400 + +++ v2.debug.trim 2017-05-03 20:28:14.03200 + @@ -38,87 +38,6 @@ -> parse_args @ /build/sudo-XX/sudo-1.8.16/src/parse_args.c:172 -> get_net_ifs @ /build/sudo-XX/sudo-1.8.16/src/net_ifs.c:120 <- get_net_ifs @ /build/sudo-XX/sudo-1.8.16/src/net_ifs.c:205 := 3 -<- parse_args @ /build/sudo-XX/sudo-1.8.16/src/parse_args.c:512 := 8 -sudo_mode 8 --> sudo_load_plugins @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:283 --> sudo_load_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:160 --> sudo_check_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:112 --> sudo_stat_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:46 -<- sudo_stat_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:104 := 0 -<- sudo_check_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:137 := true --> sudo_conf_debug_files_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/sudo_conf.c:509 -<- sudo_conf_debug_files_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/sudo_conf.c:535 := (nil) -<- sudo_load_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:255 := true --> sudo_load_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:160 --> sudo_check_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:112 --> sudo_stat_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:46 -<- sudo_stat_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:104 := 0 -<- sudo_check_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:137 := true --> sudo_conf_debug_files_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/sudo_conf.c:509 -<- sudo_conf_debug_files_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/sudo_conf.c:535 := (nil) -<- sudo_load_plugin @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:255 := true -<- sudo_load_plugins @ /build/sudo-XX/sudo-1.8.16/src/load_plugins.c:352 := true --> policy_open @ /build/sudo-XX/sudo-1.8.16/src/sudo.c:1231 --> format_plugin_settings @ /build/sudo-XX/sudo-1.8.16/src/sudo.c:1175 --> sudo_new_key_val_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/key_val.c:44 -<- sudo_new_key_val_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/key_val.c:56 := plugin_path=/usr/lib/sudo/sudoers.so -settings: progname=sudo --> sudo_new_key_val_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/key_val.c:44 -<- sudo_new_key_val_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/key_val.c:56 := progname=sudo -settings: network_addrs=10.0.0.230/255.255.255.0 :::::230/::::::: fe80::1:::/::::: --> sudo_new_key_val_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/key_val.c:44 -<- sudo_new_key_val_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/key_val.c:56 := network_addrs=10.0.0.230/255.255.255.0 :::::230/::::::: fe80::1:::/::::: -settings: plugin_dir=/usr/lib/sudo/ --> sudo_new_key_val_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/key_val.c:44 -<- sudo_new_key_val_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/key_val.c:56 := plugin_dir=/usr/lib/sudo/ -<- format_plugin_settings @ /build/sudo-XX/sudo-1.8.16/src/sudo.c:1217 := 0x -<- policy_open @ /build/sudo-XX/sudo-1.8.16/src/sudo.c:1261 := 1 --> init_signals @ /build/sudo-XX/sudo-1.8.16/src/signal.c:121 --> pipe_nonblock @ /build/sudo-XX/sudo-1.8.16/src/exec.c:975 -<- pipe_nonblock @ /build/sudo-XX/sudo-1.8.16/src/exec.c:993 := 0 -<- init_signals @ /build/sudo-XX/sudo-1.8.16/src/signal.c:154 --> policy_invalidate @ /build/sudo-XX/sudo-1.8.16/src/sudo.c:1350 -<- policy_invalidate @ /build/sudo-XX/sudo-1.8.16/src/sudo.c:1358 --> sudo_check_suid @ /build/sudo-XX/sudo-1.8.16/src/sudo.c:828 -<- sudo_check_suid @ /build/sudo-XX/sudo-1.8.16/src/sudo.c:872 --> save_signals @ /build/sudo-XX/sudo-1.8.16/src/signal.c:64 -<- save_signals @ /build/sudo-XX/sudo-1.8.16/src/signal.c:71 --> sudo_conf_read_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/sudo_conf.c:562 --> sudo_secure_path @ /build/sudo-XX/sudo-1.8.16/lib/util/secure_path.c:43 -<- sudo_secure_path @ /build/sudo-XX/sudo-1.8.16/lib/util/secure_path.c:62 := 0 --> sudo_parseln_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/parseln.c:55 -<- sudo_parseln_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/parseln.c:118 := 40 --> sudo_parseln_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/parseln.c:55 -<- sudo_parseln_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/parseln.c:118 := 46 --> sudo_parseln_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/parseln.c:55 -<- sudo_parseln_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/parseln.c:117 := -1 -<- sudo_conf_read_v1 @ /build/sudo-XX/sudo-1.8.16/lib/util/sudo_conf.c:651 := 1 --> get_user_info @
[Touch-packages] [Bug 1688034] Re: 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd
Some additional info. I enabled sudo debugging by creating /etc/sudo.conf containing: Debug sudo /var/log/sudo-debug all@info Debug sudoers /var/log/sudoers-debug all@info With the newer (non-functioning) sudo, /var/log/sudo-debug contains: May 3 18:55:50 sudo[8003] comparing dev 34817 to /dev/pts/1: match! @ sudo_ttyname_dev() /build/sudo-40pSZP/sudo-1.8.16/src/ttyname.c:336 May 3 18:55:50 sudo[8003] settings: run_shell=true May 3 18:55:50 sudo[8003] settings: progname=sudo May 3 18:55:50 sudo[8003] settings: network_addrs=10.0.0.230/255.255.255.0 :::::230/::::::: fe80::1:::/::::: May 3 18:55:50 sudo[8003] settings: plugin_dir=/usr/lib/sudo/ May 3 18:55:51 sudo[8003] policy plugin returns 0 With the older (working) sudo, /var/log/sudo-debug contains: May 3 19:00:19 sudo[8746] comparing dev 34817 to /dev/pts/1: match! @ sudo_ttyname_dev() /build/sudo-g3ghsu/sudo-1.8.16/src/ttyname.c:336 May 3 19:00:19 sudo[8746] settings: run_shell=true May 3 19:00:19 sudo[8746] settings: progname=sudo May 3 19:00:19 sudo[8746] settings: network_addrs=10.0.0.230/255.255.255.0 :::::230/::::::: fe80::1:::/::::: May 3 19:00:19 sudo[8746] settings: plugin_dir=/usr/lib/sudo/ May 3 19:00:22 sudo[8746] policy plugin returns 1 May 3 19:00:22 sudo[8746] settings: run_shell=true May 3 19:00:22 sudo[8746] settings: progname=sudo May 3 19:00:22 sudo[8746] settings: network_addrs=10.0.0.230/255.255.255.0 :::::230/::::::: fe80::1:::/::::: May 3 19:00:22 sudo[8746] settings: plugin_dir=/usr/lib/sudo/ May 3 19:00:22 sudo[8746] command info from plugin: May 3 19:00:22 sudo[8746] 0: command=/bin/bash May 3 19:00:22 sudo[8746] 1: runas_uid=0 May 3 19:00:22 sudo[8746] 2: runas_gid=0 May 3 19:00:22 sudo[8746] 3: runas_groups=0 May 3 19:00:22 sudo[8746] 4: closefrom=3 May 3 19:00:22 sudo[8746] 5: set_utmp=true May 3 19:00:22 sudo[8746] 6: umask=022 May 3 19:00:22 sudo[8746] executed /bin/bash, pid 8754 May 3 19:00:22 sudo[8746] sudo_ev_add_v1: adding event 0x55e83b06c630 to base 0x55e83b07ea40 May 3 19:00:22 sudo[8746] sudo_ev_add_v1: adding event 0x55e83b078180 to base 0x55e83b07ea40 May 3 19:00:22 sudo[8746] signal pipe fd 10 May 3 19:00:22 sudo[8746] backchannel fd 5 May 3 19:00:22 sudo[8754] exec /bin/bash [/bin/bash] May 3 19:00:22 sudo[8746] sudo_ev_scan_impl: 1 fds ready May 3 19:00:22 sudo[8746] failed to read child status: EOF May 3 19:00:22 sudo[8746] sudo_ev_del_v1: removing event 0x55e83b078180 from base 0x55e83b07ea40 (/var/log/sudoers-debug is not created in either case) Note "policy plugin returns 0" in the first case. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1688034 Title: 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd Status in sudo package in Ubuntu: New Bug description: ubuntu 16.04, enrolled with freeipa-client to FreeIPA 4.4.0 (under CentOS 7) With sudo 1.8.16-0ubuntu1, everything is fine: brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: root@api-dev:~# After update to 1.8.16-0ubuntu1.3, it no longer works: brian.candler@api-dev:~$ sudo -k brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: brian.candler is not allowed to run sudo on api-dev.int.example.com. This incident will be reported. This is repeatable: downgrade sudo and it works again. Seems very likely related to change made as part of #1607666, which changes how sudo policies are matched, but has unexpected regression. --- Additional info --- The sudo policy in IPA is extremely simple. It has a single rule, which says: - applies to users in groups "system_administrators" and "security_administrators" - applies to any host - applies to any command In LDAP under ou=sudoers tree, the groups are flattened out: # system administrators on all hosts, sudoers, ipa.example.com dn: cn=system administrators on all hosts,ou=sudoers,dc=ipa,dc=example,dc=com sudoRunAsGroup: ALL objectClass: sudoRole objectClass: top sudoUser: brian.candler sudoUser: ... sudoUser: ... list more users sudoUser: ... sudoRunAsUser: ALL sudoCommand: ALL sudoHost: ALL cn: system administrators on all hosts Under cn=sudorules,cn=sudo it refers to the groups rather than the individuals: # 59ffb10a-9c61-11e6-b5b8-00163efd5284, sudorules, sudo, ipa.example.com dn: ipaUniqueID=59ffb10a-9c61-11e6-b5b8-00163efd5284,cn=sudorules,cn=sudo,dc=ipa,dc=example,dc=com ipaSudoRunAsUserCategory: all ipaSudoRunAsGroupCategory: all description: admins have full sudo access on any host they can ssh into cmdCategory: all
[Touch-packages] [Bug 1688034] [NEW] 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd
Public bug reported: ubuntu 16.04, enrolled with freeipa-client to FreeIPA 4.4.0 (under CentOS 7) With sudo 1.8.16-0ubuntu1, everything is fine: brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: root@api-dev:~# After update to 1.8.16-0ubuntu1.3, it no longer works: brian.candler@api-dev:~$ sudo -k brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: brian.candler is not allowed to run sudo on api-dev.int.example.com. This incident will be reported. This is repeatable: downgrade sudo and it works again. Seems very likely related to change made as part of #1607666, which changes how sudo policies are matched, but has unexpected regression. --- Additional info --- The sudo policy in IPA is extremely simple. It has a single rule, which says: - applies to users in groups "system_administrators" and "security_administrators" - applies to any host - applies to any command In LDAP under ou=sudoers tree, the groups are flattened out: # system administrators on all hosts, sudoers, ipa.example.com dn: cn=system administrators on all hosts,ou=sudoers,dc=ipa,dc=example,dc=com sudoRunAsGroup: ALL objectClass: sudoRole objectClass: top sudoUser: brian.candler sudoUser: ... sudoUser: ... list more users sudoUser: ... sudoRunAsUser: ALL sudoCommand: ALL sudoHost: ALL cn: system administrators on all hosts Under cn=sudorules,cn=sudo it refers to the groups rather than the individuals: # 59ffb10a-9c61-11e6-b5b8-00163efd5284, sudorules, sudo, ipa.example.com dn: ipaUniqueID=59ffb10a-9c61-11e6-b5b8-00163efd5284,cn=sudorules,cn=sudo,dc=ipa,dc=example,dc=com ipaSudoRunAsUserCategory: all ipaSudoRunAsGroupCategory: all description: admins have full sudo access on any host they can ssh into cmdCategory: all hostCategory: all memberUser: cn=system_administrators,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com memberUser: cn=security_administrators,cn=groups,cn=accounts,dc=ipa,dc=example,dc=com objectClass: ipasudorule objectClass: ipaassociation ipaEnabledFlag: TRUE cn: system administrators on all hosts ipaUniqueID: 59ffb10a-9c61-11e6-b5b8-00163efd5284 I have no workaround other than downgrade. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: sudo 1.8.16-0ubuntu1.3 ProcVersionSignature: Ubuntu 4.4.0-1016.25-aws 4.4.59 Uname: Linux 4.4.0-1016-aws x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 Date: Wed May 3 16:01:23 2017 Ec2AMI: ami-a8d2d7ce Ec2AMIManifest: (unknown) Ec2AvailabilityZone: eu-west-1a Ec2InstanceType: t2.small Ec2Kernel: unavailable Ec2Ramdisk: unavailable ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: sudo UpgradeStatus: No upgrade log present (probably fresh install) VisudoCheck: /etc/sudoers: parsed OK /etc/sudoers.d/90-cloud-init-users: parsed OK /etc/sudoers.d/README: parsed OK ** Affects: sudo (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug ec2-images xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sudo in Ubuntu. https://bugs.launchpad.net/bugs/1688034 Title: 1.8.16-0ubuntu1.3 update breaks sudo with freeipa-client / sssd Status in sudo package in Ubuntu: New Bug description: ubuntu 16.04, enrolled with freeipa-client to FreeIPA 4.4.0 (under CentOS 7) With sudo 1.8.16-0ubuntu1, everything is fine: brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: root@api-dev:~# After update to 1.8.16-0ubuntu1.3, it no longer works: brian.candler@api-dev:~$ sudo -k brian.candler@api-dev:~$ sudo -s [sudo] password for brian.candler: brian.candler is not allowed to run sudo on api-dev.int.example.com. This incident will be reported. This is repeatable: downgrade sudo and it works again. Seems very likely related to change made as part of #1607666, which changes how sudo policies are matched, but has unexpected regression. --- Additional info --- The sudo policy in IPA is extremely simple. It has a single rule, which says: - applies to users in groups "system_administrators" and "security_administrators" - applies to any host - applies to any command In LDAP under ou=sudoers tree, the groups are flattened out: # system administrators on all hosts, sudoers, ipa.example.com dn: cn=system administrators on all hosts,ou=sudoers,dc=ipa,dc=example,dc=com sudoRunAsGroup: ALL objectClass: sudoRole objectClass: top sudoUser: brian.candler sudoUser: ... sudoUser: ... list more users sudoUser: ... sudoRunAsUser: ALL sudoCommand: ALL sudoHost: ALL cn: system administrators on all hosts Under cn=sudorules,cn=sudo it refers to the groups rather than the individuals: # 59ffb10a-9c61-11e6-b5b8-00163efd5284, sudorules, sudo, ipa.example.com dn: ipaUniqueID=59ffb10a-9c61-11e6-b5b8-00163efd5284,cn=sudorules,cn=sudo,dc=ipa,dc=example,dc=com ipaSudoRunAsUserCategory: all
[Touch-packages] [Bug 1670303] Re: dhcpd does not respect ip_local_port _range or ip_local_reserved_ports
WORKAROUND: if the other application which needs to bind to a UDP port can be configured to bind to a specific interface, then you can make isc-dhcp-server bind to a different interface in dhcpd.conf. e.g. ddns-local-address4 127.0.0.1; ddns-local-address6 ::1; -- 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/1670303 Title: dhcpd does not respect ip_local_port _range or ip_local_reserved_ports Status in isc-dhcp package in Ubuntu: New Bug description: When isc-dhcp-server starts up, in addition to listening on port 67, it binds to a random UDP port on an IPv4 socket and another on an IPv6 socket: # netstat -naup | grep dhcp udp0 0 0.0.0.0:11075 0.0.0.0:* 8188/dhcpd udp0 0 0.0.0.0:67 0.0.0.0:* 8188/dhcpd udp6 0 0 :::10800:::* 8188/dhcpd # (I am guessing this is for making outbound DNS queries?) However, this prevented a later application of mine from working, as it wanted to bind to port 11075 for accepting incoming data. Simply doing "service isc-dhcp-server restart" makes it choose new ports, but this problem may occur again in the future. In the default configuration, I believe ephemeral ports should only use 32768 and above: # cat /proc/sys/net/ipv4/ip_local_port_range 3276860999 # cat /proc/sys/net/ipv4/ip_local_reserved_ports # I also tried setting a reservation, and this was not respected either. # sysctl net.ipv4.ip_local_reserved_ports="1-5" net.ipv4.ip_local_reserved_ports = 1-5 After restarting dhcpd: # netstat -naup | grep dhcp udp0 0 0.0.0.0:50610 0.0.0.0:* 4592/dhcpd udp0 0 0.0.0.0:67 0.0.0.0:* 4592/dhcpd udp6 0 0 :::28891:::* 4592/dhcpd I can find no way to tell isc-dhcp-server which port range to use. Setting "omapi-port" in dhcpd.conf makes it listen for *TCP* connections on the given port, and does not affect the UDP behaviour. I don't know if this is a problem with the application (explicitly picking a local port), the resolver library (ditto), or the kernel (ignoring its own ip_local_port_range) ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: isc-dhcp-server 4.3.3-5ubuntu12.6 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 Date: Mon Mar 6 09:30:29 2017 DhServerLeases: InstallationDate: Installed on 2017-03-04 (2 days ago) InstallationMedia: Ubuntu-Server 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.8) ProcEnviron: SHELL=/bin/bash TERM=xterm-256color PATH=(custom, no user) LANG=en_US LANGUAGE=en_US: SourcePackage: isc-dhcp UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.dhcp.dhcpd.conf: 2017-03-04T09:46:07.987046 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1670303/+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 1670303] Re: dhcpd does not respect ip_local_port _range or ip_local_reserved_ports
strace shows that dhcpd is binding to explicit ports which it has chosen
itself:
setsockopt(20, SOL_SOCKET, SO_TIMESTAMP, [1], 4) = 0
setsockopt(20, SOL_IP, IP_MTU_DISCOVER, [0], 4) = 0
getsockopt(20, SOL_SOCKET, SO_RCVBUF, [212992], [4]) = 0
setsockopt(20, SOL_IP, IP_RECVTOS, [1], 4) = 0
bind(20, {sa_family=AF_INET, sin_port=htons(15101),
sin_addr=inet_addr("0.0.0.0")}, 16) = 0
socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDP) = 5
fcntl(5, F_DUPFD, 20) = 21
close(5)= 0
fcntl(21, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(21, F_SETFL, O_RDWR|O_NONBLOCK) = 0
setsockopt(21, SOL_IPV6, IPV6_MTU, [1280], 4) = 0
setsockopt(21, SOL_SOCKET, SO_TIMESTAMP, [1], 4) = 0
setsockopt(21, SOL_IPV6, IPV6_RECVPKTINFO, [1], 4) = 0
setsockopt(21, SOL_IPV6, IPV6_MTU_DISCOVER, [0], 4) = 0
getsockopt(21, SOL_SOCKET, SO_RCVBUF, [212992], [4]) = 0
setsockopt(21, SOL_IPV6, IPV6_RECVTCLASS, [1], 4) = 0
setsockopt(21, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
bind(21, {sa_family=AF_INET6, sin6_port=htons(11709), inet_pton(AF_INET6, "::",
_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
Aha - from man dhcpd:
When DDNS is enabled at compile time (see includes/site.h)
the server will open both a v4 and a v6 UDP socket on
random ports. These ports are opened even if DDNS is disabled
in the configuration file.
In the source code, the README says:
A fully-featured implementation of dynamic DNS updates is included in
this release. It uses libraries from BIND and, to avoid issues with
different versions, includes the necessary BIND version. The appropriate
BIND libraries will be compiled and installed in the bind subdirectory
as part of the make step.
However, debian/patches/system-bind.patch causes it to link against the
system bind library; this seems to be -ldns-export from package libdns-
export162
apt-get source libdns-export162 pulls in bind9. The CHANGES file says:
4109. [port] linux: support reading the local port range from
net.ipv4.ip_local_port_range. [RT # 39379]
However, the strace output from dhcpd shows no attempt to read
ip_local_port_range.
I see the bind code includes these fallback values:
#define ISC_NET_PORTRANGELOW 1024
#define ISC_NET_PORTRANGEHIGH 65535
ISTM that a safer bound would be 49152-65535 (IANA dynamic port range),
or at least the linux default of "32768 60999"
But the fundamental problem here is that for some reason, when dhcpd
links into this code, it isn't making use of the detection of available
Linux port range.
--
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/1670303
Title:
dhcpd does not respect ip_local_port _range or ip_local_reserved_ports
Status in isc-dhcp package in Ubuntu:
New
Bug description:
When isc-dhcp-server starts up, in addition to listening on port 67,
it binds to a random UDP port on an IPv4 socket and another on an IPv6
socket:
# netstat -naup | grep dhcp
udp0 0 0.0.0.0:11075 0.0.0.0:*
8188/dhcpd
udp0 0 0.0.0.0:67 0.0.0.0:*
8188/dhcpd
udp6 0 0 :::10800:::*
8188/dhcpd
#
(I am guessing this is for making outbound DNS queries?) However,
this prevented a later application of mine from working, as it wanted
to bind to port 11075 for accepting incoming data.
Simply doing "service isc-dhcp-server restart" makes it choose new
ports, but this problem may occur again in the future.
In the default configuration, I believe ephemeral ports should only
use 32768 and above:
# cat /proc/sys/net/ipv4/ip_local_port_range
3276860999
# cat /proc/sys/net/ipv4/ip_local_reserved_ports
#
I also tried setting a reservation, and this was not respected either.
# sysctl net.ipv4.ip_local_reserved_ports="1-5"
net.ipv4.ip_local_reserved_ports = 1-5
After restarting dhcpd:
# netstat -naup | grep dhcp
udp0 0 0.0.0.0:50610 0.0.0.0:*
4592/dhcpd
udp0 0 0.0.0.0:67 0.0.0.0:*
4592/dhcpd
udp6 0 0 :::28891:::*
4592/dhcpd
I can find no way to tell isc-dhcp-server which port range to use. Setting
"omapi-port" in dhcpd.conf makes it listen for *TCP* connections on the given
port, and does not affect the UDP behaviour.
I don't know if this is a problem with the application (explicitly
picking a local port), the resolver library (ditto), or the kernel
(ignoring its own ip_local_port_range)
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: isc-dhcp-server 4.3.3-5ubuntu12.6
ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44
Uname: Linux 4.4.0-64-generic x86_64
[Touch-packages] [Bug 1670303] [NEW] dhcpd does not respect ip_local_port _range or ip_local_reserved_ports
Public bug reported: When isc-dhcp-server starts up, in addition to listening on port 67, it binds to a random UDP port on an IPv4 socket and another on an IPv6 socket: # netstat -naup | grep dhcp udp0 0 0.0.0.0:11075 0.0.0.0:* 8188/dhcpd udp0 0 0.0.0.0:67 0.0.0.0:* 8188/dhcpd udp6 0 0 :::10800:::* 8188/dhcpd # (I am guessing this is for making outbound DNS queries?) However, this prevented a later application of mine from working, as it wanted to bind to port 11075 for accepting incoming data. Simply doing "service isc-dhcp-server restart" makes it choose new ports, but this problem may occur again in the future. In the default configuration, I believe ephemeral ports should only use 32768 and above: # cat /proc/sys/net/ipv4/ip_local_port_range 3276860999 # cat /proc/sys/net/ipv4/ip_local_reserved_ports # I also tried setting a reservation, and this was not respected either. # sysctl net.ipv4.ip_local_reserved_ports="1-5" net.ipv4.ip_local_reserved_ports = 1-5 After restarting dhcpd: # netstat -naup | grep dhcp udp0 0 0.0.0.0:50610 0.0.0.0:* 4592/dhcpd udp0 0 0.0.0.0:67 0.0.0.0:* 4592/dhcpd udp6 0 0 :::28891:::* 4592/dhcpd I can find no way to tell isc-dhcp-server which port range to use. Setting "omapi-port" in dhcpd.conf makes it listen for *TCP* connections on the given port, and does not affect the UDP behaviour. I don't know if this is a problem with the application (explicitly picking a local port), the resolver library (ditto), or the kernel (ignoring its own ip_local_port_range) ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: isc-dhcp-server 4.3.3-5ubuntu12.6 ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44 Uname: Linux 4.4.0-64-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.5 Architecture: amd64 Date: Mon Mar 6 09:30:29 2017 DhServerLeases: InstallationDate: Installed on 2017-03-04 (2 days ago) InstallationMedia: Ubuntu-Server 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.8) ProcEnviron: SHELL=/bin/bash TERM=xterm-256color PATH=(custom, no user) LANG=en_US LANGUAGE=en_US: SourcePackage: isc-dhcp UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.dhcp.dhcpd.conf: 2017-03-04T09:46:07.987046 ** Affects: isc-dhcp (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug xenial -- 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/1670303 Title: dhcpd does not respect ip_local_port _range or ip_local_reserved_ports Status in isc-dhcp package in Ubuntu: New Bug description: When isc-dhcp-server starts up, in addition to listening on port 67, it binds to a random UDP port on an IPv4 socket and another on an IPv6 socket: # netstat -naup | grep dhcp udp0 0 0.0.0.0:11075 0.0.0.0:* 8188/dhcpd udp0 0 0.0.0.0:67 0.0.0.0:* 8188/dhcpd udp6 0 0 :::10800:::* 8188/dhcpd # (I am guessing this is for making outbound DNS queries?) However, this prevented a later application of mine from working, as it wanted to bind to port 11075 for accepting incoming data. Simply doing "service isc-dhcp-server restart" makes it choose new ports, but this problem may occur again in the future. In the default configuration, I believe ephemeral ports should only use 32768 and above: # cat /proc/sys/net/ipv4/ip_local_port_range 3276860999 # cat /proc/sys/net/ipv4/ip_local_reserved_ports # I also tried setting a reservation, and this was not respected either. # sysctl net.ipv4.ip_local_reserved_ports="1-5" net.ipv4.ip_local_reserved_ports = 1-5 After restarting dhcpd: # netstat -naup | grep dhcp udp0 0 0.0.0.0:50610 0.0.0.0:* 4592/dhcpd udp0 0 0.0.0.0:67 0.0.0.0:* 4592/dhcpd udp6 0 0 :::28891:::* 4592/dhcpd I can find no way to tell isc-dhcp-server which port range to use. Setting "omapi-port" in dhcpd.conf makes it listen for *TCP* connections on the given port, and does not affect the UDP behaviour. I don't know if this is a problem with the application (explicitly picking a local port), the resolver library (ditto), or the kernel (ignoring its own ip_local_port_range) ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: isc-dhcp-server
[Touch-packages] [Bug 1667016] [NEW] tcpdump in lxd container: apparmor blocks writing to stdout/stderr
Public bug reported: [ubuntu 16.04, lxd 2.0.8 or 2.0.9, tcpdump 4.7.4 or 4.9.0] If you ssh into an lxd container as a normal user, and inside that container run "sudo tcpdump", the tcpdump process is blocked from writing to stdout/stderr. This appears to be due to apparmor: disabling apparmor for tcpdump makes the problem go away. ln -s /etc/apparmor.d/usr.sbin.tcpdump /etc/apparmor.d/disable/ Note: this is a different bug from #1641236. In that bug, the user did "lxc exec bash" to get a shell in the container; the stdout fd was being passed from the outer host to the container. But in this case, the pty is being created entirely inside the container by sshd. Details copied from https://github.com/lxc/lxd/issues/2930 # Steps to reproduce 1. Create two Ubuntu 16.04 lxd containers, one privileged, one not. 2. ssh into each one, and then use `sudo -s` to get root. (Do not use `lxc exec` because of issue #1641236) 3. Inside one run `tcpdump -i eth0 -nn not tcp port 22`, and ping from the other. tcpdump in the privileged container works just fine. tcpdump in the unprivileged container does not show any output. But if I run strace on it I see errors attempting to access stdout and stderr: ~~~ ioctl(1, TCGETS, 0x7fff97c8d680)= -1 ENOTTY (Inappropriate ioctl for device) ... write(2, "tcpdump: verbose output suppress"..., 75) = -1 EACCES (Permission denied) write(2, "listening on eth0, link-type EN1"..., 74) = -1 EACCES (Permission denied) ~~~ This is very weird. Even more weird: the following command *does* capture packets: ~~~ tcpdump -i eth0 -nn -w foo.pcap ~~~ The file foo.pcap grows. This proves it's nothing to do with network capture perms. But the following command shows no output: ~~~ tcpdump -r foo.pcap -nn ~~~ And again it's because it can't write to stdout: ~~~ fstat(1, 0x7ffe2fb5eb10)= -1 EACCES (Permission denied) read(3, "", 4096) = 0 write(1, "14:34:30.618180 IP6 fe80::c609:6"..., 1740) = -1 EACCES (Permission denied) ~~~ I had originally thought this was to do with capabilities. But if I run `capsh --print` inside both containers, they both have `cap_net_raw` and `cap_net_admin`. In fact, the unprivileged container has two additional capabilities! (`cap_mac_override` and `cap_mac_admin`) So now I suspect that apparmor is at fault. dmesg dmesg output generated by the following steps: * start tcpdump * wait 5 seconds * send 1 ping from other side * wait 5 seconds * stop tcpdump ~~~ [429020.685987] audit: type=1400 audit(1487774339.708:3597): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="/dev/pts/0" pid=12539 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=10 ouid=101001 [429020.686000] audit: type=1400 audit(1487774339.708:3598): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="/dev/pts/0" pid=12539 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=10 ouid=101001 [429020.686013] audit: type=1400 audit(1487774339.708:3599): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="/dev/pts/0" pid=12539 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=10 ouid=101001 [429020.686022] audit: type=1400 audit(1487774339.708:3600): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="/dev/pts/0" pid=12539 comm="tcpdump" requested_mask="wr" denied_mask="wr" fsuid=10 ouid=101001 [429020.716725] device eth0 entered promiscuous mode [429020.741308] audit: type=1400 audit(1487774339.764:3601): apparmor="DENIED" operation="file_perm" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="apparmor/.null" pid=12539 comm="tcpdump" requested_mask="w" denied_mask="w" fsuid=10 ouid=0 [429020.741330] audit: type=1400 audit(1487774339.764:3602): apparmor="DENIED" operation="file_perm" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="apparmor/.null" pid=12539 comm="tcpdump" requested_mask="w" denied_mask="w" fsuid=10 ouid=0 [429021.716785] audit: type=1400 audit(1487774340.740:3603): apparmor="DENIED" operation="getattr" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="apparmor/.null" pid=12539 comm="tcpdump" requested_mask="r" denied_mask="r" fsuid=10 ouid=0 [429030.630448] audit: type=1400 audit(1487774349.652:3604): apparmor="DENIED" operation="file_perm" info="Failed name lookup - disconnected path" error=-13 namespace="root//lxd-srv2-campus1_" profile="/usr/sbin/tcpdump" name="apparmor/.null" pid=12539 comm="tcpdump" requested_mask="w" denied_mask="w" fsuid=10 ouid=0
[Touch-packages] [Bug 1566930] Re: wget does not support IPv6 address with scoped zone (RFC 4007)
Workaround is to use IPv4/NAT networking instead of link-local
IPv6/http_proxy.
1. configure your lxdbr0 network with (private) IPv4 addresses and DHCP
pool in /etc/default/lxd-bridge. Also set LXD_IPV4_NAT="true" and
LXD_IPV6_PROXY="false". Restart.
2. "lxc profile edit default" to no longer use the IPv6 proxy.
name: default
config: {}
description: Default LXD profile
devices:
eth0:
name: eth0
nictype: bridged
parent: lxdbr0
type: nic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to wget in Ubuntu.
https://bugs.launchpad.net/bugs/1566930
Title:
wget does not support IPv6 address with scoped zone (RFC 4007)
Status in wget package in Ubuntu:
Confirmed
Bug description:
IMPACT: wget is not usable in the default configuration for LXD
containers in Xenial
Summary: A scoped zone address in the form [%
[Touch-packages] [Bug 1630946] [NEW] ubuntu-server depends on open-iscsi and runs iscsid
Public bug reported: ubuntu-server has a hard dependency on open-iscsi, which means there is a daemon running (iscsid), and the package cannot be removed. All unnecessary daemons are a cause of concern when auditing a system. Propose moving this to "Recommends" instead, which currently has: Recommends: lxd, snapd ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ubuntu-server 1.361 ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19 Uname: Linux 4.4.0-38-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 Date: Thu Oct 6 10:43:04 2016 Ec2AMI: ami-c06b1eb3 Ec2AMIManifest: (unknown) Ec2AvailabilityZone: eu-west-1a Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable ProcEnviron: TERM=xterm-256color SHELL=/bin/bash PATH=(custom, user) LANG=en_US.UTF-8 XDG_RUNTIME_DIR= SourcePackage: ubuntu-meta UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: ubuntu-meta (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug ec2-images xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1630946 Title: ubuntu-server depends on open-iscsi and runs iscsid Status in ubuntu-meta package in Ubuntu: New Bug description: ubuntu-server has a hard dependency on open-iscsi, which means there is a daemon running (iscsid), and the package cannot be removed. All unnecessary daemons are a cause of concern when auditing a system. Propose moving this to "Recommends" instead, which currently has: Recommends: lxd, snapd ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ubuntu-server 1.361 ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19 Uname: Linux 4.4.0-38-generic x86_64 NonfreeKernelModules: zfs zunicode zcommon znvpair zavl ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 Date: Thu Oct 6 10:43:04 2016 Ec2AMI: ami-c06b1eb3 Ec2AMIManifest: (unknown) Ec2AvailabilityZone: eu-west-1a Ec2InstanceType: t2.medium Ec2Kernel: unavailable Ec2Ramdisk: unavailable ProcEnviron: TERM=xterm-256color SHELL=/bin/bash PATH=(custom, user) LANG=en_US.UTF-8 XDG_RUNTIME_DIR= SourcePackage: ubuntu-meta UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1630946/+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 1357093] Re: Kernels not autoremoving, causing out of space error on LVM or Encrypted installation or on any installation, when /boot partition gets full
I have two Precise (12.04) servers with Unattended-Upgrade::Remove-Unused-Dependencies "true"; in 50unattended-upgrades. One of them cleans up its kernels and only keeps the last two; one of them accumulates kernels over time, and I occasionally get alerts about /boot filling up. On the latter machine, "apt-get autoremove --purge" doesn't remove them. I end up removing the packages individually; the script "purge-old- kernels" referred to above doesn't seem to exist. The main difference I can see is that the latter machine has linux- image-generic-lts-trusty, whereas the first machine has linux-image- server. Both machines have in /etc/apt/apt.conf.d/05aptitude: aptitude::Keep-Unused-Pattern "^linux-image.*$ | ^linux-restricted- modules.*$ | ^linux-ubuntu-modules.*$"; So I don't think that's it. I suppose there won't be too many kernel updates for Precise before it goes end of life now though... -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1357093 Title: Kernels not autoremoving, causing out of space error on LVM or Encrypted installation or on any installation, when /boot partition gets full Status in unattended-upgrades package in Ubuntu: Fix Released Bug description: Currently if one chooses to use LVM or encrypted install, a /boot partition is created of 236Mb Once kernel updates start being released this partition soon fills until people are left unable to upgrade. While you and I might know that we need to watch partition space, many of the people we have installing think that a windows disk is a disk and not a partition, education is probably the key - but in the meantime support venues keep needing to deal with the fact the partition is too small and/or old kernels are not purged as new ones install. For workaround and sytem repair, see https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1357093/+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 1519120] Re: NetworkManager VLAN support fails unless vlan package is manually installed
The second issue (not matching predictable NIC names) is #1541678 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1519120 Title: NetworkManager VLAN support fails unless vlan package is manually installed Status in network-manager package in Ubuntu: Confirmed Bug description: I tried to use the network manager UI to define a VLAN interface, and nothing happened. There are a few bugs here: (1) When creating a VLAN interface through the UI, the "vlan interface name" must be filled in. This should just default to ., rather than being a required field. (I typed in "vlan100" to get the "Save" button to activate.) (2) After creating my VLAN interface, nothing happened. No new interface appeared. I then realized that I had not installed the "vlan" package, and assumed that NetworkManager therefore could not complete configuration of the interface. (3) After installing the 'vlan' package (and then telling NetworkManager to disconnect and reconnect my Ethernet interface from the UI, just for good measure), still no VLAN interfaces were present on my system. I also tried editing the VLAN interface in the UI, and specifying "enp4s0f1.100", but still no VLAN interface came online. # apt-cache policy network-manager network-manager: Installed: 1.0.4-0ubuntu6 Candidate: 1.0.4-0ubuntu6 Version table: *** 1.0.4-0ubuntu6 0 500 http://172.16.42.88/ubuntu/ xenial/main amd64 Packages 100 /var/lib/dpkg/status # apt-cache policy vlan vlan: Installed: 1.9-3.2ubuntu1 Candidate: 1.9-3.2ubuntu1 Version table: *** 1.9-3.2ubuntu1 0 500 http://172.16.42.88/ubuntu/ xenial/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1519120/+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 1580521] Re: wget does not support link-scoped IPv6 literal addresses
*** This bug is a duplicate of bug 1566930 ***
https://bugs.launchpad.net/bugs/1566930
** This bug has been marked a duplicate of bug 1566930
wget does not support IPv6 address with scoped zone (RFC 4007)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to wget in Ubuntu.
https://bugs.launchpad.net/bugs/1580521
Title:
wget does not support link-scoped IPv6 literal addresses
Status in wget package in Ubuntu:
New
Bug description:
Inside an lxd container with default profile you get this error with
wget:
root@first:~# wget http://nsrc.org/
Error parsing proxy URL http://[fe80::1%eth0]:13128: Invalid IPv6 numeric
address.
root@first:~# echo $http_proxy
http://[fe80::1%eth0]:13128
The underlying issue is that wget does not support IPv6 literals of
the form [address%interface] as used by lxd(*). You can demonstrate
this without lxd:
$ wget http://[fe80::1%eth0]/
http://[fe80::1%eth0]/: Invalid IPv6 numeric address.
$ http_proxy=http://[fe80::1%eth0]:13128 wget http://nsrc.org/
Error parsing proxy URL http://[fe80::1%eth0]:13128: Invalid IPv6 numeric
address.
(*)
=== /etc/default/lxd ===
# Run a minimal HTTP PROXY server
LXD_IPV6_PROXY="true"
=== /usr/lib/lxd/lxd-bridge ===
[ "${HAS_IPV6}" = "true" ] && [ "${LXD_IPV6_PROXY}" = "true" ] &&
ip addr add fe80::1/64 dev "${1}"
=== /usr/lib/lxd/profile-config ===
if [ "${LXD_IPV6_PROXY}" = "true" ]; then
lxc profile set default environment.http_proxy
"http://[fe80::1%eth0]:13128; --force-local || true
fi
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: wget 1.17.1-1ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8
Uname: Linux 4.4.0-22-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
Date: Wed May 11 10:29:40 2016
InstallationDate: Installed on 2016-05-06 (4 days ago)
InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Release amd64
(20160420.3)
SourcePackage: wget
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wget/+bug/1580521/+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 270512] Re: openssh-client could suggest xauth rather than recommend it
This is still an issue with xenial. The problem this causes is that on an Ubuntu Server system, installing any package which depends on openssh-client will also pull in pretty much the whole X11 system. Example: root@xenial1:~# apt-get install rancid Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: expect fontconfig-config fonts-dejavu-core libdrm-amdgpu1 libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libfontconfig1 libfontenc1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libice6 libllvm3.8 libpciaccess0 libperl4-corelibs-perl libsm6 libtcl8.6 libtk8.6 libtxc-dxtn-s2tc0 libx11-xcb1 libxaw7 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-shape0 libxcb-sync1 libxcomposite1 libxdamage1 libxfixes3 libxft2 libxi6 libxinerama1 libxmu6 libxpm4 libxrandr2 libxrender1 libxshmfence1 libxss1 libxt6 libxtst6 libxv1 libxxf86dga1 libxxf86vm1 tcl-expect tcl8.6 tk8.6 x11-common x11-utils xbitmaps xterm Suggested packages: diffstat tcl-tclreadline mesa-utils xfonts-cyrillic The following NEW packages will be installed expect fontconfig-config fonts-dejavu-core libdrm-amdgpu1 libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libfontconfig1 libfontenc1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libice6 libllvm3.8 libpciaccess0 libperl4-corelibs-perl libsm6 libtcl8.6 libtk8.6 libtxc-dxtn-s2tc0 libx11-xcb1 libxaw7 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-shape0 libxcb-sync1 libxcomposite1 libxdamage1 libxfixes3 libxft2 libxi6 libxinerama1 libxmu6 libxpm4 libxrandr2 libxrender1 libxshmfence1 libxss1 libxt6 libxtst6 libxv1 libxxf86dga1 libxxf86vm1 rancid tcl-expect tcl8.6 tk8.6 x11-common x11-utils xbitmaps xterm 0 to upgrade, 53 to newly install, 0 to remove and 0 not to upgrade. Need to get 20.1 MB of archives. After this operation, 172 MB of additional disk space will be used. Do you want to continue? [Y/n] n This is silly. But: root@xenial1:~# apt-get install rancid --no-install-recommends Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: expect libperl4-corelibs-perl libtcl8.6 tcl-expect Suggested packages: tcl8.6 diffstat Recommended packages: tcl8.6 tk8.6 The following NEW packages will be installed expect libperl4-corelibs-perl libtcl8.6 rancid tcl-expect That's what I expected. It seems to me that: * if the system you are using a client is graphical (e.g. Ubuntu desktop), then you will probably have xauth already * if the system you are using is text-based, then you definitely don't want xauth/X11 just to have an ssh client. So if anything "recommends" xauth, shouldn't it be X11 or the desktop environment, not the openssh client? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/270512 Title: openssh-client could suggest xauth rather than recommend it Status in openssh package in Ubuntu: Confirmed Bug description: openssh-client is in the standard seed. It recommends xauth, which as of intrepid pulls the following packages in a basic server install : xauth |- libxext6 |- libxmuu1 |- x11-common It would pull even more if there wasn't already another Recommend bug in the minimal seed that pulled other X libraries (see bug 270500). Server systems do pretty well without those packages installed by default. Solution: drop the xauth "Recommends" and make it a "Suggests" instead. Note that xauth gets pulled in in desktop installs through a xorg Depends, and that in Hardy xauth wasn't in the standard seed. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/270512/+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 1580521] [NEW] wget does not support link-scoped IPv6 literal addresses
Public bug reported:
Inside an lxd container with default profile you get this error with
wget:
root@first:~# wget http://nsrc.org/
Error parsing proxy URL http://[fe80::1%eth0]:13128: Invalid IPv6 numeric
address.
root@first:~# echo $http_proxy
http://[fe80::1%eth0]:13128
The underlying issue is that wget does not support IPv6 literals of the
form [address%interface] as used by lxd(*). You can demonstrate this
without lxd:
$ wget http://[fe80::1%eth0]/
http://[fe80::1%eth0]/: Invalid IPv6 numeric address.
$ http_proxy=http://[fe80::1%eth0]:13128 wget http://nsrc.org/
Error parsing proxy URL http://[fe80::1%eth0]:13128: Invalid IPv6 numeric
address.
(*)
=== /etc/default/lxd ===
# Run a minimal HTTP PROXY server
LXD_IPV6_PROXY="true"
=== /usr/lib/lxd/lxd-bridge ===
[ "${HAS_IPV6}" = "true" ] && [ "${LXD_IPV6_PROXY}" = "true" ] && ip
addr add fe80::1/64 dev "${1}"
=== /usr/lib/lxd/profile-config ===
if [ "${LXD_IPV6_PROXY}" = "true" ]; then
lxc profile set default environment.http_proxy
"http://[fe80::1%eth0]:13128; --force-local || true
fi
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: wget 1.17.1-1ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8
Uname: Linux 4.4.0-22-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
Date: Wed May 11 10:29:40 2016
InstallationDate: Installed on 2016-05-06 (4 days ago)
InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Release amd64
(20160420.3)
SourcePackage: wget
UpgradeStatus: No upgrade log present (probably fresh install)
** Affects: wget (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug xenial
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to wget in Ubuntu.
https://bugs.launchpad.net/bugs/1580521
Title:
wget does not support link-scoped IPv6 literal addresses
Status in wget package in Ubuntu:
New
Bug description:
Inside an lxd container with default profile you get this error with
wget:
root@first:~# wget http://nsrc.org/
Error parsing proxy URL http://[fe80::1%eth0]:13128: Invalid IPv6 numeric
address.
root@first:~# echo $http_proxy
http://[fe80::1%eth0]:13128
The underlying issue is that wget does not support IPv6 literals of
the form [address%interface] as used by lxd(*). You can demonstrate
this without lxd:
$ wget http://[fe80::1%eth0]/
http://[fe80::1%eth0]/: Invalid IPv6 numeric address.
$ http_proxy=http://[fe80::1%eth0]:13128 wget http://nsrc.org/
Error parsing proxy URL http://[fe80::1%eth0]:13128: Invalid IPv6 numeric
address.
(*)
=== /etc/default/lxd ===
# Run a minimal HTTP PROXY server
LXD_IPV6_PROXY="true"
=== /usr/lib/lxd/lxd-bridge ===
[ "${HAS_IPV6}" = "true" ] && [ "${LXD_IPV6_PROXY}" = "true" ] &&
ip addr add fe80::1/64 dev "${1}"
=== /usr/lib/lxd/profile-config ===
if [ "${LXD_IPV6_PROXY}" = "true" ]; then
lxc profile set default environment.http_proxy
"http://[fe80::1%eth0]:13128; --force-local || true
fi
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: wget 1.17.1-1ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8
Uname: Linux 4.4.0-22-generic x86_64
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
Date: Wed May 11 10:29:40 2016
InstallationDate: Installed on 2016-05-06 (4 days ago)
InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Release amd64
(20160420.3)
SourcePackage: wget
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wget/+bug/1580521/+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 1287222] Re: openssh-client 6.5 regression bug with certain servers
The workaround is fine, but if you want more detailed description about the underlying issues (there are more than one) see the Red Hat bug: https://bugzilla.redhat.com/show_bug.cgi?id=1026430 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1287222 Title: openssh-client 6.5 regression bug with certain servers Status in openssh package in Ubuntu: Confirmed Status in openssh package in Debian: New Status in openssh package in Fedora: Unknown Bug description: Previous working versions of SSH (6.2p2) work fine on certain host machines as follows: penSSH_6.2p2 Ubuntu-6, OpenSSL 1.0.1f 6 Jan 2014 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to hostname [IPAddress] port 22. debug1: Connection established. debug1: identity file /home/nelsot08/.ssh/identity type -1 debug1: identity file /home/nelsot08/.ssh/identity-cert type -1 debug1: identity file /home/nelsot08/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /home/nelsot08/.ssh/id_rsa-cert type -1 debug1: identity file /home/nelsot08/.ssh/id_dsa type -1 debug1: identity file /home/nelsot08/.ssh/id_dsa-cert type -1 debug1: identity file /home/nelsot08/.ssh/id_ecdsa type -1 debug1: identity file /home/nelsot08/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version Cisco-1.25 debug1: no match: Cisco-1.25 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server-client aes128-cbc hmac-md5 none debug1: kex: client-server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA 24:75:76:a1:80:0e:6c:4e:a8:c4:a6:a9:d3:34:98:18 Warning: Permanently added 'hostname,IPAddress' (RSA) to the list of known hosts. debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received But in 6.5p1 the following bug occurs: OpenSSH_6.5, OpenSSL 1.0.1f 6 Jan 2014 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to hostname [IPAddress] port 22. debug1: Connection established. debug1: identity file /home/nelsot08/.ssh/identity type -1 debug1: identity file /home/nelsot08/.ssh/identity-cert type -1 debug1: identity file /home/nelsot08/.ssh/id_rsa type 1 debug1: identity file /home/nelsot08/.ssh/id_rsa-cert type -1 debug1: identity file /home/nelsot08/.ssh/id_dsa type -1 debug1: identity file /home/nelsot08/.ssh/id_dsa-cert type -1 debug1: identity file /home/nelsot08/.ssh/id_ecdsa type -1 debug1: identity file /home/nelsot08/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/nelsot08/.ssh/id_ed25519 type -1 debug1: identity file /home/nelsot08/.ssh/id_ed25519-cert type -1 debug1: Remote protocol version 2.0, remote software version Cisco-1.25 debug1: no match: Cisco-1.25 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.5p1 Ubuntu-4 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server-client aes128-cbc hmac-md5 none debug1: kex: client-server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102430728192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP Connection closed by IPAddress This is a regression and there are multiple references to this bug occurring previously: http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh- client-connection-reset-by-peer/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1287222/+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 1342856] Re: No stopping messages shown during shutdown
Workaround confirmed: console stays on tty1, and the shutdown messages are shown there. Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to upstart in Ubuntu. https://bugs.launchpad.net/bugs/1342856 Title: No stopping messages shown during shutdown Status in upstart package in Ubuntu: Confirmed Bug description: ubuntu 14.04 server amd64 (running on a Mac Mini FWIW) During shutdown, no messages are displayed as daemons are being stopped. This makes it almost impossible to debug problems where a daemon is causing the shutdown to freeze. How to demonstrate: (1) Ctrl-F7 to show the virtual console where the bootup messages are. The last message seen is: * Stopping System V runlevel compatibility (2) Ctrl-F1 to get back to first virtual console. (3) Add a divider to the bootup messages: echo --- /dev/tty7 (4) sudo reboot The console switches to VC7, but in general, no further messages are displayed after the divider. Exception: when I have NFS packages installed, I do see * rpcbind terminating on signal. Restart with rpcbind -w but that's it. The only way I've been able to find out what's causing the system to hang at shutdown is to reinstall the system from scratch and keep adding packages until I find the one causing the problem. (Specifically it turned out to be avahi-daemon, but that's the subject of a separate bug report) At http://upstart.ubuntu.com/wiki/Debugging it says you can run initctl events to see what's happening, but that command-line option is not supported in the Upstart included in Ubuntu 14.04. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: upstart 1.12.1-0ubuntu4 ProcVersionSignature: Ubuntu 3.13.0-30.55-generic 3.13.11.2 Uname: Linux 3.13.0-30-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.2 Architecture: amd64 Date: Wed Jul 16 17:11:16 2014 InstallationDate: Installed on 2014-07-16 (0 days ago) InstallationMedia: Ubuntu-Server 14.04 LTS Trusty Tahr - Release amd64 (20140416.2) ProcEnviron: LANGUAGE=en_GB:en TERM=xterm PATH=(custom, no user) LANG=en_GB.UTF-8 SHELL=/bin/bash ProcKernelCmdline: BOOT_IMAGE=/vmlinuz-3.13.0-30-generic.efi.signed root=/dev/mapper/hostname--vg-root ro SourcePackage: upstart UpgradeStatus: No upgrade log present (probably fresh install) UpstartBugCategory: System UpstartRunningSystemVersion: init (upstart 1.12.1) modified.conffile..etc.dhcp.dhcpd.conf: [modified] modified.conffile..etc.modprobe.d.blacklist.conf: [modified] modified.conffile..etc.sysctl.conf: [modified] mtime.conffile..etc.dhcp.dhcpd.conf: 2014-07-16T17:07:07.863506 mtime.conffile..etc.modprobe.d.blacklist.conf: 2014-07-16T16:26:11.252552 mtime.conffile..etc.sysctl.conf: 2014-07-16T16:22:29.256880 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1342856/+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
