Bug#1018846: libvirt-daemon: Cannot start QEMU VM when host only has IPv6 address(es)
Hello, I've ran into the same issue, not sure on the exact fix yet. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910857 could be the same issue. https://forums.debian.net/viewtopic.php?t=155857 and https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1492621 have more context. Best, Jonathan -- bauen1
Bug#1051793: simple-cdd: GNUPGHOME is not always passed correctly to gpg
Package: simple-cdd Version: 0.6.9 Severity: normal X-Debbugs-Cc: j24...@gmail.com, j24...@gmail.com Dear simple-cdd Authors and/or Maintainers, When `GNUPGHOME` is not set, simple-cdd defaults it to `$PWD/tmp/gpg-keyring`, this is done in <https://salsa.debian.org/debian/simple-cdd/-/blob/e94dd3303ef9c3ae6815bb3df76355613296cd40/build-simple-cdd#L165-167>. However if `GNUPGHOME` is set internally like this, then it is not always passed along to all calls to `gpg` in <https://salsa.debian.org/debian/simple-cdd/-/blob/e94dd3303ef9c3ae6815bb3df76355613296cd40/simple_cdd/gnupg.py>. For example running `simple-cdd` in a rootless podman container where only parts of my home directory are mounted in, leaving ~ as a read-only empty directory. Because `GNUPGHOME` is not passed a long in at least <https://salsa.debian.org/debian/simple-cdd/-/blob/e94dd3303ef9c3ae6815bb3df76355613296cd40/simple_cdd/gnupg.py#L82-88>, this results in the following error: > gpg: Fatal: can't create directory '/home/jh/.gnupg': Read-only file system > Traceback (most recent call last): > File "/usr/bin/simple-cdd", line 674, in > scdd.read_configuration() > File "/usr/bin/simple-cdd", line 179, in read_configuration > verify_release_keys.extend(gnupg.list_valid_keys(keyring_file)) > File "/usr/lib/python3/dist-packages/simple_cdd/gnupg.py", line 82, in > list_valid_keys > keys_raw = subprocess.check_output(["gpg", >^^^ > File "/usr/lib/python3.11/subprocess.py", line 466, in check_output > return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, >^ > File "/usr/lib/python3.11/subprocess.py", line 571, in run > raise CalledProcessError(retcode, process.args, > subprocess.CalledProcessError: Command '['gpg', '--batch', > '--no-default-keyring', '--keyring', > '/usr/share/keyrings/debian-archive-keyring.gpg', '--list-keys', > '--with-colons']' returned non-zero exit status 2. I suspect the same is also true for <https://salsa.debian.org/debian/simple-cdd/-/blob/e94dd3303ef9c3ae6815bb3df76355613296cd40/simple_cdd/gnupg.py#L40>. Thanks a lot, Jonathan Hettwer (bauen1) -- System Information: Debian Release: 12.0 Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy
Bug#1042094: initramfs-tools: Please support systemd-cryptsetup unlocked root filesystem
Package: initramfs-tools Version: 0.142 Severity: normal X-Debbugs-Cc: j24...@gmail.com Dear Maintainer, I want to utilize systemd-cryptsetup to unlock an encrypted root filesystem using e.g. a TPM2.0, or one of the other options offered by systemd-cryptsetup. This is supported by dracut, since it uses systemd in the initramfs. Supporting this would require (optionally) including systemd-cryptsetup in the initramfs and running it to potentially unlock some devices automatically. However, I am not sure if systemd-cryptsetup requires systemd to be running, so this may or may not depend on #717429 which is unlikely to be implemented. -- System Information: Debian Release: 12.0 Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy Versions of packages initramfs-tools depends on: ii initramfs-tools-core 0.142 ii linux-base4.9 initramfs-tools recommends no packages. Versions of packages initramfs-tools suggests: ii bash-completion 1:2.11-6
Bug#824651: ostree: initramfs-tools integration
Hi,
I've been successfully experimenting with ostree-ifying debian, using the
attached script with initramfs-tools.
It's not particularly polished, and essentially assumes:
- The `systemd-remount-fs.service` unit is masked
- You passed `boot=ostree` on the cmdline, so initramfs-tools sources the script
- That you want to use the `sysroot.readonly=true` option
Ideally the `/usr/lib/ostree/ostree-prepare-root` utility could be used, but I
found it easier start experimenting with manually mounting everything.
Perhaps that script is of use to someone.
I'm not sure how much interest there is in building something similar to Fedora
Silverblue using Debian, but there are a couple of other things, that would be
useful:
- A udeb with just the ostree utility for use in the installer, that would
allow building a installer using the existing d-i components.
I currently use the `copy_exec` function from initramfs-tools to build such a
udeb, and while some libraries are already packaged as udeb, ostree has a lot
of dependencies, and gpg verification doesn't work.
- Shipping sysuser and tmpfiles for every debian package
--
bauen1#!/bin/sh
# Author: Jonathan Hettwer (bauen1)
PREREQS=""
prereqs() {
echo "$PREREQS" ;
}
case "$1" in
prereqs)
prereqs
exit 0
;;
esac
# The local script is sourced unconditionally, so in most places we defer to it.
ostree_top()
{
local_top
}
ostree_block()
{
local_block
}
ostree_premount()
{
local_premount
}
ostree_bottom()
{
local_bottom
}
ostree_mount_root()
{
# Force the initial mount to be read-only
readonly=y
# First use the local boot script to mount the actual $rootmnt
log_warning_msg "ostree: before local_mount_root"
local_mount_root
log_warning_msg "ostree: after local_mount_root"
# FIXME: this may not be the most appropiate place to parse the cmdline:
export ostree_deploy_tree=
for x in $(cat /proc/cmdline); do
case $x in
ostree=*)
ostree_deploy_tree=${x#ostree=}
;;
esac
done
if [ -z "${ostree_deploy_tree}" ]; then
panic "No ostree deployment path specified!"
fi
log_warning_msg "ostree_deploy_tree: ${ostree_deploy_tree}"
# TODO: We don't really respect the rw cmdline argument, or the
sysroot.readonly configuration
# in the ostree repository, we simply assume that
sysroot.readonly is set and mount accordingly
# TODO: Most of this could be replaced by the
/usr/lib/ostree/ostree-prepare-root
# XXX: The ostree system I'm using this has the
`systemd-remount-fs.service` unit masked, enabling it could mess up the mount
setup, see the ostree-boot package.
# Bind mount the ostree deployment in preparation of moving it onto /
if ! mount -o bind "${rootmnt}${ostree_deploy_tree}"
"${rootmnt}${ostree_deploy_tree}"; then
panic "Failed to bind mount ${rootmnt}${ostree_deploy_tree}"
fi
if ! mount -o remount,ro dummy "${rootmnt}${ostree_deploy_tree}"; then
panic "Failed to make ${rootmnt}${ostree_deploy_tree} mount
read-only"
fi
# Bind mount the actual root onto the /sysroot directory in the
deployment
if ! mount -o bind "${rootmnt}"
"${rootmnt}${ostree_deploy_tree}/sysroot"; then
panic "Failed to bind mount the physical root (${rootmnt}) onto
the ostree deployment /sysroot directory
(${rootmnt}${ostree_deploy_tree}/sysroot)"
fi
# Prepare /boot
if ! read_fstab_entry /boot; then
log_warning_msg "Found /boot entry in fstab, not mounting"
# If we where to bind-mount here, systemd would not mount /boot
itself
else
log_warning "Found no /boot entry in fstab, bind mounting"
if ! mount -o bind "${rootmnt}/boot"
"${rootmnt}${ostree_deploy_tree}/boot"; then
panic "Failed to bind mount /boot from physical root to
deployment root /boot!"
fi
fi
# Prepare /etc
log_warning_msg "ostree: attempting to bind mount
${rootmnt}${ostree_deploy_tree}/etc"
if ! mount -o bind "${rootmnt}${ostree_deploy_tree}"/etc
"${rootmnt}${ostree_deploy_tree}"/etc ; then
panic "Failed to bind mount /etc while preparing /sysroot"
fi
if ! mount -o remount,rw dummy "${rootmnt}${ostree_deploy_tree}"/etc ;
then
# It might be possible to continue at this point
panic "Failed to make /etc read-write"
Bug#1016807: linux-image-5.18.0-3-arm64: Please enable CONFIG_SPI_GPIO, CONFIG_SPI_SUN6I for arm64 (Allwinner A64)
Source: linux Severity: wishlist X-Debbugs-Cc: j24...@gmail.com Dear Linux Maintainers, I have a pine a64-lts SBC running arm64 debian unstable. A SPI NOR flash and a TPM2.0 are connected over SPI, but the kernel is currently build without the modules required to access them. To access both, I need the CONFIG_SPI_SUN6I as module for the builtin SPI bus, and CONFIG_SPI_GPIO for accessing the TPM connected over a non-standard SPI bus. Thanks in advance. -- System Information: Debian Release: bookworm/sid Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy
Bug#1009002: simple-cdd: Upcoming change to debian-cd will break BOOT_TIMEOUT parameter
Package: simple-cdd Severity: normal X-Debbugs-Cc: j24...@gmail.com Hi, An upcoming change in debian-cd makes changes to the isolinux configuration, thus simple-cdds BOOT_TIMEOUT no longer has the expected effect. The commit is https://salsa.debian.org/installer-team/debian-installer/-/commit/3010162acb02dae36db6354e9ad13891dff980c2 After this change specifying BOOT_TIMEOUT no longer changes the actual timeout, it will be 30s regardless of the value specified. The default boot option will also not be the "Graphic Installation", but the speech synthesis installation. I was asked on the #debian-boot irc channel to report this here. Thanks, Jonathan Hettwer -- System Information: Debian Release: bookworm/sid Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy Versions of packages simple-cdd depends on: pn dctrl-tools pn debian-cd pn lsb-release ii python3 3.9.8-1 pn python3-simple-cdd pn reprepro ii rsync 3.2.3-8 ii wget1.21.2-2+b1 Versions of packages simple-cdd recommends: ii dose-distcheck 7.0.0-1+b1 Versions of packages simple-cdd suggests: ii qemu-system 1:6.2+dfsg-3 ii qemu-system-x86 [qemu-kvm] 1:6.2+dfsg-3
Bug#972459: linux: Reenable CONFIG_IMA
Hi, Has there been any development on this ? I've been meaning to try IMA / EMV along with SELinux, but that's currently not easy to do as it's disabled. As the issue appears to have been resolved, could this maybe be added to the next kernel going to experimental (but not the current/next debian release) ? Thanks, bauen1 -- bauen1 https://dn42.bauen1.xyz/
Bug#986757: partman-auto-lvm: Allow reuse of existing PVs / VGs / LVs when using expert_recipe
Source: partman-auto-lvm Version: 84 Severity: wishlist X-Debbugs-Cc: j24...@gmail.com Dear Maintainer, Please allow the use of existing Physical / Logical Volumes and Volume Groups when using expert_recipe similar to normal partitions. This allows the preseeding of installations where an existing LVM Volume contains Data that should be kept intact, e.g. for multi boot setups, or a seperate /, /var, /home on LVM where only / should be erased. Currently this is not possible, as auto-lvm wipes any existing PVs, VGs, LVs unconditionally, even if the expert_recipe results in them being recreated in the exact same way immediately. This was already requested / asked a few times: https://lists.debian.org/debian-boot/2015/05/msg00339.html https://lists.debian.org/debian-boot/2013/08/msg00275.html -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy
Bug#986693: sbuild: unshare chroot: support unsharing network
Thank you for the quick reply. On 4/9/21 8:46 PM, Johannes Schauer Marin Rodrigues wrote: > Hi, > > Quoting bauen1 (2021-04-09 18:58:37) >> Please add support to the unshare chroot backend to unshare the network >> namespace. >> >> As per debian policy v4.5.1.0 >> https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules: >> >>> For packages in the main archive, no required targets may attempt network >>> access, except, via the loopback interface, to services on the build host >>> that have been started by the build. >> >> For these and similar scenarios It would be useful if sbuild unshare could be >> configured to prevent network access except for the loopback interface, by >> unsharing the network namespace and bringing up the loopback interface while >> still root. > > I don't understand. What bug do you see? The network namespace is already > unshared and only the loopback interface active in the unshare backend: > > https://sources.debian.org/src/sbuild/0.81.2/lib/Sbuild/Build.pm/?hl=2470#L2470 I'm sorry, I missed that. > Where is the bug? You can close it then :) > Thanks! -- bauen1 https://dn42.bauen1.xyz/
Bug#986694: sbuild: unshare: allow access to local repositories or bind mounting additional directories
Package: sbuild Version: 0.81.2 Severity: wishlist X-Debbugs-Cc: j24...@gmail.com Dear Maintainer, I'm currently using sbuild with the unshare chroot backend with a local repository. Currently this means running a webserver and pointing sbuilds mirror at localhost, this is annoying and unnecessary. It would be nice if sbuild with the unshare backend would support a filesystem mirror or bind mounting arbitrary paths into the chroot. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy Versions of packages sbuild depends on: ii adduser 3.118 ii libsbuild-perl 0.81.2 ii perl5.32.1-3 Versions of packages sbuild recommends: ii autopkgtest 5.16 ii debootstrap 1.0.123 ii schroot 1.6.10-12 Versions of packages sbuild suggests: pn deborphan ii e2fsprogs 1.46.2-1 ii kmod 28-1 ii wget 1.21-1+b1 -- no debconf information
Bug#986693: sbuild: unshare chroot: support unsharing network
Package: sbuild Version: 0.81.2 Severity: wishlist Justification: wishlist X-Debbugs-Cc: j24...@gmail.com Dear Maintainer, Please add support to the unshare chroot backend to unshare the network namespace. As per debian policy v4.5.1.0 https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules: > For packages in the main archive, no required targets may attempt network > access, except, via the loopback interface, to services on the build host > that have been started by the build. For these and similar scenarios It would be useful if sbuild unshare could be configured to prevent network access except for the loopback interface, by unsharing the network namespace and bringing up the loopback interface while still root. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy Versions of packages sbuild depends on: ii adduser 3.118 ii libsbuild-perl 0.81.2 ii perl5.32.1-3 Versions of packages sbuild recommends: ii autopkgtest 5.16 ii debootstrap 1.0.123 ii schroot 1.6.10-12 Versions of packages sbuild suggests: pn deborphan ii e2fsprogs 1.46.2-1 ii kmod 28-1 ii wget 1.21-1+b1 -- no debconf information
Bug#986209: debian-cd: Please provide symlinks for stable, unstable, etc...
Package: debian-cd Version: 3.1.33 Severity: wishlist X-Debbugs-Cc: j24...@gmail.com Dear Maintainer, While building my own CDs I've discovered that while most tools, e.g. debootstrap, allow using `unstable` / `sid` with the same results, debian-cd does not. This could be handled by adding symlinks, like for sid, to data, tasks, tools/boot , thus allowing the user to specify CODENAME=unstable to build a sid installer cd. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy Versions of packages debian-cd depends on: ii apt2.2.2 ii bc 1.07.1-2+b2 ii bzip2 1.0.8-4 ii cpp4:10.2.1-1 ii curl 7.74.0-1.1 ii dctrl-tools [grep-dctrl] 2.24-3+b1 ii dpkg-dev 1.20.7.1 ii genisoimage9:1.1.11-3.2 pn libcompress-zlib-perl pn libdigest-md5-perl ii libdpkg-perl 1.20.7.1 ii lynx 2.9.0dev.6-2 ii make 4.3-4 ii perl [libdigest-sha-perl] 5.32.1-3 ii tofrodos 1.7.13+ds-5 ii wget 1.21-1+b1 ii xorriso1.5.2-1 Versions of packages debian-cd recommends: ii dosfstools 4.2-1 ii hfsutils 3.2.6-15 ii isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3 ii mtools 4.0.26-1 ii netpbm 2:10.0-15.4 ii syslinux-common 3:6.04~git20190206.bf6db5b4+dfsg1-3 ii syslinux-utils 3:6.04~git20190206.bf6db5b4+dfsg1-3 debian-cd suggests no packages. -- no debconf information
Bug#986178: debian-cd: Pass DEBOOTSTRAP_OPTS to all debootstrap calls
Package: debian-cd Version: 3.1.33 Severity: normal X-Debbugs-Cc: j24...@gmail.com Dear Maintainer, Building my own customised installers has lead me to discover that DEBOOTSTRAP_OPTS isn't passed to debootstrap in tools/make_disc_trees.pl , this breaks some more exotic use cases where passing options to DEBOOTSTRAP is required / wanted. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy Versions of packages debian-cd depends on: ii apt2.2.2 ii bc 1.07.1-2+b2 ii bzip2 1.0.8-4 ii cpp4:10.2.1-1 ii curl 7.74.0-1.1 ii dctrl-tools [grep-dctrl] 2.24-3+b1 ii dpkg-dev 1.20.7.1 ii genisoimage9:1.1.11-3.2 pn libcompress-zlib-perl pn libdigest-md5-perl ii libdpkg-perl 1.20.7.1 ii lynx 2.9.0dev.6-2 ii make 4.3-4 ii perl [libdigest-sha-perl] 5.32.1-3 ii tofrodos 1.7.13+ds-5 ii wget 1.21-1+b1 ii xorriso1.5.2-1 Versions of packages debian-cd recommends: ii dosfstools 4.2-1 ii hfsutils 3.2.6-15 ii isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3 ii mtools 4.0.26-1 ii netpbm 2:10.0-15.4 ii syslinux-common 3:6.04~git20190206.bf6db5b4+dfsg1-3 ii syslinux-utils 3:6.04~git20190206.bf6db5b4+dfsg1-3 debian-cd suggests no packages. -- no debconf information
Bug#985888: dpkg: Add new option to skip all sync / fsync calls (Emulate libeatmydata)
Source: dpkg Severity: wishlist Tags: d-i Justification: wishlist X-Debbugs-Cc: j24...@gmail.com Dear Maintainer, Please provide a new option in dpkg 1.21.x that allows disabling all sync / fsync calls similar to how currently done by libeatmydata. There are more and more use cases that benefit from a faster dpkg but don't need any protection against sudden shutdowns or terminations of dpkg, some examples include the debian installer, building containers, temporary chroots (sbuild), temporary VMs. Currently eatmydata can be used to achive this and it has the benefit of also disabling all sync / fsync calls in maintainer scripts, triggers, ... But eatmydata uses LD_PRELOAD, which in my opinion is a hack and won't work on some hardened systems, it also adds a lot of complexity and extra steps in many different places. A new option --force-dangerous-io would allow tools to easily capture most of the performance benefits where appropiate. Of course add some big and scary warnings in the manual about how this should never be used on a system you care about. (Also discussed with guillem on irc #debian-dpkg oftc 2021-03-25)
Bug#983447: policycoreutils: Regression breaks selinux-autorelabel on boot due to wrong argument passing to fixfiles
Package: policycoreutils Version: 3.1-2 Severity: grave Justification: renders package unusable User: selinux-de...@lists.alioth.debian.org Usertags: selinux X-Debbugs-Cc: j24...@gmail.com Dear Maintainer, A recent change (commit 6a36aa28c on salsa.debian.org/selinux-team/policycoreutils) breaks relabling on boot. In the selinux-autorelabel script, the contents of "/.autorelabel" are passed as arguments to fixfiles, but the quotations break fixfiles argument parsing, e.g. `/sbin/fixfiles "" restore` or `/sbin/fixfiles "-F "` (note the extra space). This means that SELinux enabled systems can no longer be relabeled using `fixfiles onboot` or `fixfiles -F onboot`. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy Versions of packages policycoreutils depends on: ii libaudit1 1:3.0-2 ii libc6 2.31-9 ii libselinux13.1-3 ii libsemanage1 3.1-1+b2 ii libsepol1 3.1-1 ii lsb-base 11.1.0 ii selinux-utils 3.1-3 policycoreutils recommends no packages. policycoreutils suggests no packages. -- no debconf information
Bug#982906: base-passwd: Please create passwd, group, shadow with the default SELinux context
Package: base-passwd
Version: 3.5.49
Severity: wishlist
User: selinux-de...@lists.alioth.debian.org
Usertags: selinux selinux-aware
X-Debbugs-Cc: j24...@gmail.com
Dear Maintainer,
When running update-passwd, it creates /etc/{passwd,group,shadow}.upwd-write
with the default SELinux context, before moving these files to their correct
location, without restoring the SELinux context.
This can leave an SELinux system in a broken state, so it would be nice if
update-passwd would reset the context of these files.
I'm working on a patch to fix this.
Bug#981666: cdrom-detect: Preseeding cdrom-detect/load_media and a high-enough priority lead to failure
Package: cdrom-detect Version: 1.92 Severity: normal X-Debbugs-Cc: j24...@gmail.com Dear Maintainer, Recently experimenting with a rather obscure setup that involves running the installer from a non-cdrom device and preseeding, I've discovered that cdrom-detect doesn't allow cdrom-detect/load_media to be preseeded. This is caused by debconf returning code 30 if the question isn't shown, this error code should be ignored to allow preseeding, the attached patch fixes the issue. It has been tested by hand editing the postinst script on a live system, as I don't know how to rebuild the debian installer initrd. - Jonathan Hettwer (bauen1) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy >From b4a968def3fe7cc16bdbc68427634ca457efcfd0 Mon Sep 17 00:00:00 2001 From: bauen1 Date: Tue, 2 Feb 2021 18:11:01 +0100 Subject: [PATCH] allow preseeding cdrom-detect/load_media --- debian/cdrom-detect.postinst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/cdrom-detect.postinst b/debian/cdrom-detect.postinst index 6bf2454..4b99d66 100755 --- a/debian/cdrom-detect.postinst +++ b/debian/cdrom-detect.postinst @@ -153,7 +153,7 @@ while true; do # If no device was detected, perhaps a driver floppy is needed. if [ -e /usr/lib/debian-installer/retriever/media-retriever ]; then - db_input critical cdrom-detect/load_media + db_input critical cdrom-detect/load_media || [ $? -eq 30 ] db_go db_get cdrom-detect/load_media if [ "$RET" = true ]; then -- 2.30.0
Bug#978547: fontconfig: Please create /var/cache/fontconfig with the default SELinux context
Package: fontconfig Version: 2.13.1-4.2 Severity: wishlist X-Debbugs-Cc: j24...@gmail.com Dear Maintainer, On an SELinux enabled system installing fontconfig results in the postinst script creating `/var/cache/fontconfig` . However the postinst script doesn't reset the SELinux label to the default context like e.g. dpkg does when extracting packages, depending on the SELinux policy used, this could prevent legitimate access to `/var/cache/fontconfig` . This minor annoyance could be fixed by using `mkdir -Z` instead of `mkdir` when creating `/var/cache/fontconfig` . -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: bauen1-policy Versions of packages fontconfig depends on: ii fontconfig-config 2.13.1-4.2 ii libc6 2.31-6 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 fontconfig recommends no packages. fontconfig suggests no packages. -- no debconf information
Bug#976996: qemu-system: qemu doesn't support video mode qxl anymore and fails to load spice libraries
Package: qemu-system Version: 1:5.2+dfsg-1 Severity: important X-Debbugs-Cc: j24...@gmail.com Dear Maintainer, I've just upgraded qemu-system and related packages, now I can't launch any libvirt virtual machiness with the virtual machine manager frontend anymore. It appears that this is caused by qemu no longer being build with support for the qxl video mode, or at least not advertising it anymore. When ran with spice qemu now also fails to load the /usr/lib/x86_64-linux-gnu/qemu/ui-spice-core.so library due to unresolved symbols `console_gl_check_format`. This appears to be a regression from 1:5.1+dfsg-4+b2 -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: bauen1-policy Versions of packages qemu-system depends on: ii qemu-system-arm1:5.2+dfsg-1 ii qemu-system-mips 1:5.2+dfsg-1 ii qemu-system-misc 1:5.2+dfsg-1 ii qemu-system-ppc1:5.2+dfsg-1 ii qemu-system-sparc 1:5.2+dfsg-1 ii qemu-system-x861:5.2+dfsg-1 qemu-system recommends no packages. qemu-system suggests no packages. -- no debconf information
Bug#906729: Please fix SELinux labels of /vmlinuz symlink after kernel update
On Sat, 25 Jan 2020 19:42:53 +0100 =?UTF-8?Q?Christian_G=C3=B6ttsche?= wrote: > It is not needed for anything to work correctly; it is just that > objects should have the context defined by the SELinux policy. The > root_t context should only be used by the root path directory, > anything else is suspicious and should be avoided. Also if one sets up > an alert for incorrect labeled objects (e.g. via repeatedly running > restorecon -v -R -n /) this mislabeling would trigger. Even better would be if the linux-update-symlinks perl script fixed the symlinks label before replacing it in an atomic operation in https://salsa.debian.org/kernel-team/linux-base/-/blob/master/bin/linux-update-symlinks#L49-76 -- bauen1 https://dn42.bauen1.xyz/
Bug#966822: systemd: user-runtime-dir service crashes the kernel under SELinux
Hi, I've already reported this bug in the kernel audit system upstream, see https://lore.kernel.org/linux-audit/20200723200041.7yinlklts47pz...@madcap2.tricolour.ca/T/#t for details. A revert (8ac68dc455d9d18241d44b96800d73229029ed34) of the commit that caused this regression in 5.7 is already in 5.7.13 (https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.7.13) This bug should be reassigned to the kernel package.
Bug#965973: bird2: Make use of systemd service options to remove unecessary permissions
Hi, On 7/21/20 10:09 PM, Ondřej Surý wrote: >> I'm sorry for sending you a poor and untested patch, if you're not generally >> opposed to this sort of change I will create a proper patch and test it >> before sending it. > > No, I am not generally opposed to the change, I am just generally opposed to > "throw in everything and let's see what breaks" in a routing daemon :). > > I would even suggest fixing `birdc configure` to return non-zero status > instead of circumventing it via `bird -p`. I can send a feature request to upstream, the closest to this is probably https://marc.info/?l=bird-users&m=156025841523803&w=2 (and perhaps https://marc.info/?l=bird-users&m=158806824301303&w=2). > Let's start with a minimal patch - if you have account on salsa.debian.org > <http://salsa.debian.org>, I can setup https://salsa.debian.org/debian/bird2, > so you can submit MRs to the packaging there. Thanks, I've created an account (https://salsa.debian.org/bauen1) -- bauen1 https://dn42.bauen1.xyz/
Bug#965973: bird2: Make use of systemd service options to remove unecessary permissions
Hi, > so, I’ve seen this before with a different package (bind9) and I’ve seen > this to gloriously fail because the systemd file was overzealous and > obviously even you didn’t test it before you sent it to me. I'm sorry, I hit send prematurely, and it was meant as a sort of RFC. I've been using a very similar service file for at least a few months pn a few systems running BGP and OSPF so this isn't completely untested. > Unless the changed systemd file is extensively tested with ALL routing > protocols, there’s no way I am applying this as it is. I will reduce the patch to things that should be uncontroversial (you're right about overzealous being a bad thing). Bird already drops capabilities itself almost directly after startup (see https://salsa.debian.org/debian/bird2/-/blob/master/sysdep/linux/syspriv.h#L54-79) this would be the same as: User=bird Group=bird AmbientCapabilities=CAP_NET_RAW CAP_NET_BIND CAP_NET_BROADCAST CAP_NET_ADMIN CAP_NET_BIND_SERVICE I believe that if bird is configured to log to a file inaccessible to bird:bird this might break, but bird might break anyway in that case if a reload is triggered. I will look into this. prepare-environment creates the runtime directory and fixes the ownership, this is equivalent to: RuntimeDirectory=bird These sandbox options should also not cause any trouble: # prevent access to /home ProtectHome=true # mount /usr, /boot, /efi read-only ProtectSystem=yes Some of the other options could be added and some of the others might introduce breakages in very rare cases or future changes to bird. Verifying the configuration as part of the reload works around `birdc configure` always exiting with 0 even if the configuration has an error. ExecReload=/usr/sbin/bird -p > Also, the package still supports sysv-rc, and I have no intention for > dropping the support and I would pretty much would like to keep the > configuration same for the time being. I don't want to suggest dropping support for sysv-rc. But yes, this change would duplicate the user and group name into systemd service file and that isn't ideal. I'm sorry for sending you a poor and untested patch, if you're not generally opposed to this sort of change I will create a proper patch and test it before sending it. bauen1 -- bauen1 https://dn42.bauen1.xyz/
Bug#965973: bird2: Make use of systemd service options to remove unecessary permissions
I'm sorry, I was under the illusion that environment variables could be used for User= and Group=, so these lines should be: User=bird Group=bird -- bauen1 https://dn42.bauen1.xyz/
Bug#965973: bird2: Make use of systemd service options to remove unecessary permissions
Package: bird2 Version: 2.0.7-4 Severity: wishlist Tags: patch X-Debbugs-Cc: j24...@gmail.com Dear Maintainer, It would be nice if systemds service file could use the appropriate options instead of relying on an additional shell script (at least when systemd is used). This also allows to enable additional sand boxing options, e.g. prevent read access to /home. The attached patch is a suggestions and has been used in a similar form on my systems for quite a while now. Thanks for maintaining this package, bauen1 -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Enforcing - Policy name: refpolicy Versions of packages bird2 depends on: ii adduser 3.118 ii init-system-helpers 1.58 ii libc62.31-1 ii libreadline8 8.0-4 ii libssh-gcrypt-4 0.9.4-1 ii libtinfo66.2-1 ii lsb-base 11.1.0 ii ucf 3.0043 bird2 recommends no packages. Versions of packages bird2 suggests: pn bird2-doc -- Configuration Files: /etc/init.d/bird [Errno 13] Permission denied: '/etc/init.d/bird' -- no debconf information >From 1b531d931d5f0556099cc2168de115e4e5da89dc Mon Sep 17 00:00:00 2001 From: bauen1 Date: Tue, 21 Jul 2020 19:23:41 +0200 Subject: [PATCH] Make use of systemd options instead of using a shell script This allows a more tight sandbox (e.g. preventing access to /home). --- debian/bird2.bird.service | 38 +++--- 1 file changed, 35 insertions(+), 3 deletions(-) diff --git a/debian/bird2.bird.service b/debian/bird2.bird.service index 37e75fb..e0a9b47 100644 --- a/debian/bird2.bird.service +++ b/debian/bird2.bird.service @@ -1,13 +1,45 @@ [Unit] -Description=BIRD Internet Routing Daemon +Description=BIRD 2.0 Internet Routing Daemon After=network.target [Service] EnvironmentFile=/etc/bird/envvars -ExecStartPre=/usr/lib/bird/prepare-environment + +User=$BIRD_RUN_USER +Group=$BIRD_RUN_GROUP +RuntimeDirectory=bird +NoNewPrivileges=true +AmbientCapabilities=CAP_NET_RAW CAP_NET_BIND CAP_NET_BROADCAST CAP_NET_ADMIN CAP_NET_BIND_SERVICE + +ProtectClock=true +ProtectControlGroups=true +ProtectHome=true +ProtectHostname=true +ProtectKernelLogs=true +ProtectKernelModules=true +ProtectKernelTunables=true +ProtectSystem=full +LockPersonality=true +RestrictNamespaces=true +RestrictRealtime=true +RestrictSUIDSGID=true +SystemCallArchitectures=native +ProtectSystem=full +LockPersonality=true +RestrictNamespaces=true +RestrictRealtime=true +RestrictSUIDSGID=true +SystemCallArchitectures=native + ExecStartPre=/usr/sbin/bird -p + +# birdc configure does not correctly set the exit code if the reload failed +# so by running `bird -p` the config is checked for errors and a correct error +# code is set +ExecReload=/usr/sbin/bird -p ExecReload=/usr/sbin/birdc configure -ExecStart=/usr/sbin/bird -f -u $BIRD_RUN_USER -g $BIRD_RUN_GROUP $BIRD_ARGS + +ExecStart=/usr/sbin/bird -f $BIRD_ARGS Restart=on-abort [Install] -- 2.28.0.rc1
Bug#958520: lighttpd: remove usage of 'su' in crontab
Package: lighttpd Version: 1.4.55-1 Severity: wishlist Tags: patch Dear Maintainer, While improving my SELinux policy, I've stumbled across the cron job installed by lighttpd. It's usage of 'su' to run commands under the 'www-data' isn't optimal: Excerpt from su(1) > su is mostly designed for unprivileged users, the recommended solution for > privileged users (e.g. scripts executed by root) is to use non-set-user-ID > command runuser(1) that does not require authentication and provide separate > PAM configuration. If the PAM session is not required at all then the > recommend solution is to use command setpriv(1). This also causes a full session to be started, along with 'systemd --user', socket activation and possibly services starting under the 'www-data' user. I've attached my modified crontab, that uses 'runuser' instread of 'su', this results in no session being started. - bauen1 -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect LSM: SELinux: enabled - Mode: Enforcing - Policy name: refpolicy Versions of packages lighttpd depends on: hi libattr1 1:2.4.48-5 hi libbz2-1.0 1.0.8-2 ii libc6 2.30-4 ii libcrypt1 1:4.4.16-1 hi libfam0 2.7.0-17.3 hi libpcre3 2:8.39-12+b1 ii libssl1.1 1.1.1g-1 ii lsb-base 11.1.0 ii mime-support 3.64 hi zlib1g 1:1.2.11.dfsg-2 Versions of packages lighttpd recommends: ii perl 5.30.0-10 ii spawn-fcgi 1.6.4-2 Versions of packages lighttpd suggests: ii apache2-utils 2.4.43-1 pn lighttpd-doc pn lighttpd-mod-authn-gssapi pn lighttpd-mod-authn-pam pn lighttpd-mod-authn-sasl pn lighttpd-mod-cml pn lighttpd-mod-geoip pn lighttpd-mod-magnet pn lighttpd-mod-maxminddb pn lighttpd-mod-trigger-b4-dl pn lighttpd-mod-vhostdb-dbi pn lighttpd-mod-vhostdb-pgsql pn lighttpd-mod-webdav ii lighttpd-modules-ldap 1.4.55-1 ii lighttpd-modules-mysql 1.4.55-1 ii openssl 1.1.1g-1 pn php-cgi pn rrdtool -- Configuration Files: /etc/cron.daily/lighttpd changed: # this might not be required: # under my test setup find (www-data) failed to change directory out of /root # this might have been due SELinux or DAC cd / cache=/var/cache/lighttpd if test -d "$cache/compress"; then runuser -u www-data -- /bin/sh -c "find $cache/compress -type f -atime +30 -print0 | xargs -0 -r rm" fi if test -d "$cache/uploads"; then runuser -u www-data -- /bin/sh -c "find $cache/uploads -type f -atime +1 -print0 | xargs -0 -r rm" fi /etc/init.d/lighttpd [Errno 13] Permission denied: '/etc/init.d/lighttpd' /etc/lighttpd/conf-available/05-auth.conf [Errno 13] Permission denied: '/etc/lighttpd/conf-available/05-auth.conf' /etc/lighttpd/conf-available/05-setenv.conf [Errno 13] Permission denied: '/etc/lighttpd/conf-available/05-setenv.conf' /etc/lighttpd/conf-available/10-accesslog.conf [Errno 13] Permission denied: '/etc/lighttpd/conf-available/10-accesslog.conf' /etc/lighttpd/conf-available/10-cgi.conf [Errno 13] Permission denied: '/etc/lighttpd/conf-available/10-cgi.conf' /etc/lighttpd/conf-available/10-dir-listing.conf [Errno 13] Permission denied: '/etc/lighttpd/conf-available/10-dir-listing.conf' /etc/lighttpd/conf-available/10-evasive.conf [Errno 13] Permission denied: '/etc/lighttpd/conf-available/10-evasive.conf' /etc/lighttpd/conf-available/10-evhost.conf [Errno 13] Permission denied: '/etc/lighttpd/conf-available/10-evhost.conf' /etc/lighttpd/conf-available/10-expire.conf [Errno 13] Permission denied: '/etc/lighttpd/conf-available/10-expire.conf' /etc/lighttpd/conf-available/10-fastcgi.conf [Errno 13] Permission denied: '/etc/lighttpd/conf-available/10-fastcgi.conf' /etc/lighttpd/conf-available/10-flv-streaming.conf [Errno 13] Permission denied: '/etc/lighttpd/conf-available/10-flv-streaming.conf' /etc/lighttpd/conf-available/10-no-www.conf [Errno 13] Permission denied: '/etc/lighttpd/conf-available/10-no-www.conf' /etc/lighttpd/conf-available/10-proxy.conf [Errno 13] Permission denied: '/etc/lighttpd/conf-available/10-proxy.conf' /etc/lighttpd/conf-available/10-rewrite.conf [Errno 13] Permission denied: '/etc/lighttpd/conf-available/10-rewrite.conf' /etc/lighttpd/conf-available/10-rrdtool.conf [Errno 13] Permission denied: '/etc/lighttpd/conf-available/10-rrdtool.conf' /etc/
Bug#919871: ceph-mgr: missing systemd files
Package: ceph-mgr Version: 12.2.10+dfsg1-1~bpo9+1 Severity: important Hello, It appears to me that debian currently doesn't ship the systemd units needed to setup a manager node (ceph-mgr.target and ceph-mgr@.service) Upstream has the needed unit files: https://github.com/ceph/ceph/blob/v12.2.10/systemd/ceph-mgr.target https://github.com/ceph/ceph/blob/v12.2.10/systemd/ceph-mgr%40.service Since ceph version 12.2 mgr is required as part of any ceph deployment: http://docs.ceph.com/docs/master/releases/luminous/#v12-2-0-luminous The packages in testing and unstable seem to suffer from the same problem. Sadly I currently don't have the time to do extensive testing. Cheers - bauen1 -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-0.bpo.1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ceph-mgr depends on: ii ceph-base 12.2.10+dfsg1-1~bpo9+1 ii libboost-iostreams1.67.0 1.67.0-7~bpo9+1 ii libboost-python1.67.0 1.67.0-7~bpo9+1 ii libboost-regex1.67.0 1.67.0-7~bpo9+1 ii libboost-system1.67.0 1.67.0-7~bpo9+1 ii libboost-thread1.67.0 1.67.0-7~bpo9+1 ii libc6 2.24-11+deb9u3 ii libgcc1 1:6.3.0-18+deb9u1 ii libgoogle-perftools4 2.5-2.2 ii libibverbs1 1.2.1-2 ii libnspr4 2:4.12-6 ii libnss3 2:3.26.2-1.1+deb9u1 ii libpython2.7 2.7.13-2+deb9u3 ii libstdc++66.3.0-18+deb9u1 ii python-cherrypy3 3.5.0-2 ii python-openssl16.2.0-1 ii python-pecan 1.1.2-3 ii python-werkzeug 0.11.15+dfsg1-1 ceph-mgr recommends no packages. ceph-mgr suggests no packages. -- no debconf information
