[Touch-packages] [Bug 2063898] [NEW] broken doc symlinks after t64 transition in noble
Public bug reported: $ pwd /usr/share/doc/openssl $ ls -l total 52 lrwxrwxrwx 1 root root30 mars 31 08:42 changelog.Debian.gz -> ../libssl3/changelog.Debian.gz lrwxrwxrwx 1 root root23 mars 31 08:42 changelog.gz -> ../libssl3/changelog.gz lrwxrwxrwx 1 root root20 mars 31 08:42 copyright -> ../libssl3/copyright libssl3 doenst exist anymore, it is now libssl3t64 $ apt-cache policy openssl libssl3t64 openssl: Installed: 3.0.13-0ubuntu3 Candidate: 3.0.13-0ubuntu3 Version table: *** 3.0.13-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages 100 /var/lib/dpkg/status libssl3t64: Installed: 3.0.13-0ubuntu3 Candidate: 3.0.13-0ubuntu3 Version table: *** 3.0.13-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages 100 /var/lib/dpkg/status ** Affects: openssl (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2063898 Title: broken doc symlinks after t64 transition in noble Status in openssl package in Ubuntu: New Bug description: $ pwd /usr/share/doc/openssl $ ls -l total 52 lrwxrwxrwx 1 root root30 mars 31 08:42 changelog.Debian.gz -> ../libssl3/changelog.Debian.gz lrwxrwxrwx 1 root root23 mars 31 08:42 changelog.gz -> ../libssl3/changelog.gz lrwxrwxrwx 1 root root20 mars 31 08:42 copyright -> ../libssl3/copyright libssl3 doenst exist anymore, it is now libssl3t64 $ apt-cache policy openssl libssl3t64 openssl: Installed: 3.0.13-0ubuntu3 Candidate: 3.0.13-0ubuntu3 Version table: *** 3.0.13-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages 100 /var/lib/dpkg/status libssl3t64: Installed: 3.0.13-0ubuntu3 Candidate: 3.0.13-0ubuntu3 Version table: *** 3.0.13-0ubuntu3 500 500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2063898/+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 2059874] Re: on upgrade sshd-socket-generator conversion does not respect administrator intent
I'm not that invested in the having openssh-server installed but not running use-case, but in general people do not like their local configuration beeing overridden on package upgrades in this manner. I could image people having it installed for the man-pages, or maybe using other units for it (per VRF instances or something), having the main service and socket units disabled, but I doubt that happens that much in practice. For me the biggest problem was the socket unit beeing re-enabled when I had it disabled it but still running sshd.service (ie without socket activation) - now you're unexpectidly switched back to using socket activation - something I explicitly opted out of. I could also see this causing problems if you have the socket unit masked (dont see why you would want that however) but the the service is enabled, now you are without sshd. Actually I think the postinst would also fail in that case, as systemctl enable fails enabling masked units. -- 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/2059874 Title: on upgrade sshd-socket-generator conversion does not respect administrator intent Status in openssh package in Ubuntu: Incomplete Bug description: the openssh-server 1:9.6p1-3ubuntu11 postinst contains this code snippet: if [ "$action" == configure ]; then ..snip.. if dpkg --compare-versions "$2" lt-nl 1:9.6p1-3ubuntu3~; then ..snip.. if [ -d /run/systemd/system ]; then # Make sure ssh.service is disabled. systemctl unmask ssh.service systemctl disable --now ssh.service > /dev/null 2>&1 # sshd-socket-generator is invoked on daemon-reload. systemctl daemon-reload systemctl enable ssh.socket fi fi fi This does not respect existing service and socket unit configuration, it effectively re-enables a disabled ssh.service (and even a masked one), and a manually disabled socket unit. I strongly suspect it does not respect systemd presets either. This is unexpected behaviour. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2059874/+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 2059874] [NEW] on upgrade sshd-socket-generator conversion does not respect administrator intent
Public bug reported: the openssh-server 1:9.6p1-3ubuntu11 postinst contains this code snippet: if [ "$action" == configure ]; then ..snip.. if dpkg --compare-versions "$2" lt-nl 1:9.6p1-3ubuntu3~; then ..snip.. if [ -d /run/systemd/system ]; then # Make sure ssh.service is disabled. systemctl unmask ssh.service systemctl disable --now ssh.service > /dev/null 2>&1 # sshd-socket-generator is invoked on daemon-reload. systemctl daemon-reload systemctl enable ssh.socket fi fi fi This does not respect existing service and socket unit configuration, it effectively re-enables a disabled ssh.service (and even a masked one), and a manually disabled socket unit. I strongly suspect it does not respect systemd presets either. This is unexpected behaviour. ** Affects: openssh (Ubuntu) Importance: Undecided Status: New -- 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/2059874 Title: on upgrade sshd-socket-generator conversion does not respect administrator intent Status in openssh package in Ubuntu: New Bug description: the openssh-server 1:9.6p1-3ubuntu11 postinst contains this code snippet: if [ "$action" == configure ]; then ..snip.. if dpkg --compare-versions "$2" lt-nl 1:9.6p1-3ubuntu3~; then ..snip.. if [ -d /run/systemd/system ]; then # Make sure ssh.service is disabled. systemctl unmask ssh.service systemctl disable --now ssh.service > /dev/null 2>&1 # sshd-socket-generator is invoked on daemon-reload. systemctl daemon-reload systemctl enable ssh.socket fi fi fi This does not respect existing service and socket unit configuration, it effectively re-enables a disabled ssh.service (and even a masked one), and a manually disabled socket unit. I strongly suspect it does not respect systemd presets either. This is unexpected behaviour. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2059874/+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 2059872] [NEW] Unable to listen on port 22 if multiple Port= present in sshd configuration
Public bug reported: Recently introduced sshd-socket-generator for socket activation in openssh 1:9.6p1-3ubuntu3 has a bug when dealing with multiple Port or ListenAddress entries in the sshd configuration. If you have multiple Port or ListenAddress and one of them is for port 22, it just skips it. To show it clearly, here is an example: Port 22 Port 1024 It generates: ListenStream= ListenStream=1024 Now nothing is listening to port 22, hence breaking existing configurations. This was tested on 1:9.6p1-3ubuntu11. The intention seems to be to not generate the drop-in if only port 22 is in use, but it does not account for the case of multiple Port or ListenAddress where one of them is for port 22. ** Affects: openssh (Ubuntu) Importance: Undecided Status: New -- 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/2059872 Title: Unable to listen on port 22 if multiple Port= present in sshd configuration Status in openssh package in Ubuntu: New Bug description: Recently introduced sshd-socket-generator for socket activation in openssh 1:9.6p1-3ubuntu3 has a bug when dealing with multiple Port or ListenAddress entries in the sshd configuration. If you have multiple Port or ListenAddress and one of them is for port 22, it just skips it. To show it clearly, here is an example: Port 22 Port 1024 It generates: ListenStream= ListenStream=1024 Now nothing is listening to port 22, hence breaking existing configurations. This was tested on 1:9.6p1-3ubuntu11. The intention seems to be to not generate the drop-in if only port 22 is in use, but it does not account for the case of multiple Port or ListenAddress where one of them is for port 22. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2059872/+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 1959475] Re: "machinectl shell" connections immediately terminated
Please consider backporting for Focal (20.04) at least. The backport is trivial and applies cleanly as-is except for patch offsets. Might be wise to test some other combinations though. For example hosts without this commit, running nspawn containers with it. -- 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/1959475 Title: "machinectl shell" connections immediately terminated Status in systemd package in Ubuntu: Confirmed Bug description: The command "machinectl shell" does not work in systemd 249.9-0ubuntu2: $ sudo machinectl shell ns-xxx Connected to machine ns-xxx. Press ^] three times within 1s to exit session. Connection to machine ns-xxx terminated. The issue seems to be described here: https://forum.manjaro.org/t/the-machinectl-shell-command-stopped-working-after-systemd-upgrade-to-250-2-1/99899 https://github.com/systemd/systemd/issues/22234 and solved here: https://github.com/systemd/systemd/commit/e8cf09b2a2ad0d48e5493050d54251d5f512d9b6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1959475/+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 1959475] Re: "machinectl shell" connections immediately terminated
Just tested, and can confirm backporting e8cf09b2a2ad0d48e5493050d54251d5f512d9b6 to focal's systemd fixes the segfaults when using machinectl shell on a Jammy host trying to start a shell in a Focal nspawn container. -- 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/1959475 Title: "machinectl shell" connections immediately terminated Status in systemd package in Ubuntu: Confirmed Bug description: The command "machinectl shell" does not work in systemd 249.9-0ubuntu2: $ sudo machinectl shell ns-xxx Connected to machine ns-xxx. Press ^] three times within 1s to exit session. Connection to machine ns-xxx terminated. The issue seems to be described here: https://forum.manjaro.org/t/the-machinectl-shell-command-stopped-working-after-systemd-upgrade-to-250-2-1/99899 https://github.com/systemd/systemd/issues/22234 and solved here: https://github.com/systemd/systemd/commit/e8cf09b2a2ad0d48e5493050d54251d5f512d9b6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1959475/+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 1618188] Re: systemd journal should be persistent by default: /var/log/journal should be created
systemd upgrades are now failing in my build chroots, and I suspect it is related to this change. Setting up systemd (234-2ubuntu12.3) ... addgroup: The group `systemd-journal' already exists as a system group. Exiting. [/usr/lib/tmpfiles.d/tmp.conf:15] Failed to replace specifiers: /tmp/systemd-private-%b-* [/usr/lib/tmpfiles.d/tmp.conf:16] Failed to replace specifiers: /tmp/systemd-private-%b-*/tmp [/usr/lib/tmpfiles.d/tmp.conf:17] Failed to replace specifiers: /var/tmp/systemd-private-%b-* [/usr/lib/tmpfiles.d/tmp.conf:18] Failed to replace specifiers: /var/tmp/systemd-private-%b-*/tmp ACL operation on "/var/log/journal" failed: No such file or directory ACL operation on "/var/log/journal" failed: No such file or directory chmod() of /var/log/journal via /proc/self/fd/3 failed: No such file or directory dpkg: error processing package systemd (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: systemd E: Sub-process /usr/bin/dpkg returned an error code (1) -- 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/1618188 Title: systemd journal should be persistent by default: /var/log/journal should be created Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: In Progress Status in systemd source package in Zesty: Won't Fix Status in systemd source package in Artful: Fix Released Status in systemd source package in Bionic: Fix Released Bug description: [Impact] * System logs are lost across reboots because they are not stored persistently. [Test Case] * Fresh installations, or upgrades to this version of systemd, should create /var/log/journal and trigger automatic persistent logs. * Users may choose to remove said directory, or disable persistent logging in /etc/systemd/journald.conf [Regression Potential] * Persistent logging by default will cause logs to be flushed from /run to /var/log, meaning there will be less RAM used (/run is tmpfs backed), but increased disk usage (in /var/log). The journald daemon has limits set for logs, meaning they will be rotated and discarded and should not cause out of disk-space errors. [Other Info] * Original bug report After upgrading 14.04 -> 16.04, key services are now running on systemd and using the systemd journal for logging. In 14.04, key system logs like /var/log/messages and /var/log/syslog were persistent, but after the upgrade to 16.04 there has a been a regression of sorts: Logs sent to systemd's journald are now being thrown away during reboots. This behavior is controlled by the `Storage=` option in `/etc/systemd/journald.conf`. The default setting is `Storage=auto` which will persist logs in `/var/log/journal/`, *only if the directory already exists*. But the directory was not created as part of the 14.04 -> 16.04 upgrade, so logging was being lost for a while before I realized what was happening. This issue could be solved by either creating /var/log/journal or changing the default Storage behavior to `Storage=persistent`, which would create the directory if need be. ## Related reference * `systemd` currently compounds the issue by having ["journal --disk-usage" report memory usage as disk usage](https://github.com/systemd/systemd/issues/4059), giving the impression that the disk is being used for logging when it isn't. * [User wonders where to find logs from previous boots, unaware that the logs were thrown away](http://askubuntu.com/questions/765315/how-to-find-previous-boot-log-after-ubuntu-16-04-restarts) ## Recommended fix Restoring persistent logging as the default is recommended. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1618188/+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 1717714] Re: @{pid} variable broken on systems with pid_max more than 6 digits
Sorry, a correction (copy paste error):
Which should be matched by
owner @{PROC}/@{pid}/task/[0-9]*/comm rw,
in /etc/apparmor.d/abstractions/libvirt-qemu
--
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/1717714
Title:
@{pid} variable broken on systems with pid_max more than 6 digits
Status in apparmor package in Ubuntu:
New
Bug description:
If your kernel.pid_max sysctl is set higher than the default, say at 7
digits, the @{pid} variable no longer matches all pids, causing some
breakage in any profile using it.
@{pid} is defined in /etc/apparmor.d/tunables:
@{pid}={[1-9],[1-9][0-9],[1-9][0-9][0-9],[1-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9][0-9]}
It only covers up to 6 digits.
This Ubuntu 17.04 system has:
kernel.pid_max = 4194303
And is showing
type=1400 audit(1505588857.828:792): apparmor="DENIED" operation="open"
profile="libvirt-55e9e12c-e6dc-4f56-a547-8514cf7d9bf3"
name="/proc/2168180/task/2769256/comm" pid=2168180 comm="qemu-system-x86"
requested_mask="wr" denied_mask="wr" fsuid=111 ouid=111
Which should be matched by
@{PROC}/sys/vm/overcommit_memory r,
in /etc/apparmor.d/abstractions/libvirt-qemu
I'm seeing similar failures on 16.04 (2.10.95-0ubuntu2.7), 17.04
(2.11.0-2ubuntu4) and 17.10 (2.11.0-2ubuntu17)
I am aware this is a non-default configuration, but I think this
should work.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1717714/+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 1717714] [NEW] @{pid} variable broken on systems with pid_max more than 6 digits
Public bug reported:
If your kernel.pid_max sysctl is set higher than the default, say at 7
digits, the @{pid} variable no longer matches all pids, causing some
breakage in any profile using it.
@{pid} is defined in /etc/apparmor.d/tunables:
@{pid}={[1-9],[1-9][0-9],[1-9][0-9][0-9],[1-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9][0-9]}
It only covers up to 6 digits.
This Ubuntu 17.04 system has:
kernel.pid_max = 4194303
And is showing
type=1400 audit(1505588857.828:792): apparmor="DENIED" operation="open"
profile="libvirt-55e9e12c-e6dc-4f56-a547-8514cf7d9bf3"
name="/proc/2168180/task/2769256/comm" pid=2168180 comm="qemu-system-x86"
requested_mask="wr" denied_mask="wr" fsuid=111 ouid=111
Which should be matched by
@{PROC}/sys/vm/overcommit_memory r,
in /etc/apparmor.d/abstractions/libvirt-qemu
I'm seeing similar failures on 16.04 (2.10.95-0ubuntu2.7), 17.04
(2.11.0-2ubuntu4) and 17.10 (2.11.0-2ubuntu17)
I am aware this is a non-default configuration, but I think this should
work.
** Affects: apparmor (Ubuntu)
Importance: Undecided
Status: New
--
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/1717714
Title:
@{pid} variable broken on systems with pid_max more than 6 digits
Status in apparmor package in Ubuntu:
New
Bug description:
If your kernel.pid_max sysctl is set higher than the default, say at 7
digits, the @{pid} variable no longer matches all pids, causing some
breakage in any profile using it.
@{pid} is defined in /etc/apparmor.d/tunables:
@{pid}={[1-9],[1-9][0-9],[1-9][0-9][0-9],[1-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9],[1-9][0-9][0-9][0-9][0-9][0-9]}
It only covers up to 6 digits.
This Ubuntu 17.04 system has:
kernel.pid_max = 4194303
And is showing
type=1400 audit(1505588857.828:792): apparmor="DENIED" operation="open"
profile="libvirt-55e9e12c-e6dc-4f56-a547-8514cf7d9bf3"
name="/proc/2168180/task/2769256/comm" pid=2168180 comm="qemu-system-x86"
requested_mask="wr" denied_mask="wr" fsuid=111 ouid=111
Which should be matched by
@{PROC}/sys/vm/overcommit_memory r,
in /etc/apparmor.d/abstractions/libvirt-qemu
I'm seeing similar failures on 16.04 (2.10.95-0ubuntu2.7), 17.04
(2.11.0-2ubuntu4) and 17.10 (2.11.0-2ubuntu17)
I am aware this is a non-default configuration, but I think this
should work.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1717714/+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
