Bug#969606: bilibop: lockfs autopkgtest is not portable, consistently fails in Ubuntu

[quidame]

Hi Steve,

> [...]
> # df --output=source,fstype,target
> Filesystem Type Mounted on
> udev   devtmpfs /dev
> tmpfs  tmpfs/run
> tmpfs  tmpfs/aufs/rw
> /dev/vda1  ext4 /aufs/ro
> aufs   aufs /
> tmpfs  tmpfs/dev/shm
> tmpfs  tmpfs/run/lock
> tmpfs  tmpfs/sys/fs/cgroup
> tmpfs  tmpfs/aufs/rw/boot/efi
> /dev/vda15 vfat /aufs/ro/boot/efi
> aufs   aufs /boot/efi
> tmpfs  tmpfs/run/user/1000

sounds good, until there...

> STAGE 1: unexpected error

you're right, there is a lack of portability in the autopkgtest script:
only 'overlay' is expected somewhere, not 'aufs', and so the test script
fails even if the bootscripts did the job.

This will be fixed soon.

Thank you for this report.
quidame



signature.asc
Description: OpenPGP digital signature

Bug#960003: iptables-restore --test FILE reports segfault if FILE has more than 2 tables

[quidame]

Package: iptables
Version: 1.8.4-3
Severity: normal

Dear Maintainer,

Wanting to validate changes in a file previously created by
iptables-save, I experienced a segmentation fault with the
iptables-restore command. It appears that the error doesn't come from
the changes in the file, but from the iptables-nft-restore binary.

Steps to reproduce:

1. Create a file with 3 tables (any of filter, nat, mangle, raw and
security):

# cat > ruleset <

Versions of packages iptables suggests:
pn  firewalld  
ii  kmod   27+20200310-2

-- no debconf information

Bug#934589: udev: net.ifnames is wrongly imported as a property for any/all devices

[quidame]

On 13/08/2019 17:44, Michael Biebl wrote:
> 
> --export says
> 
>   -x, --export
>Print output as key/value pairs. Values are enclosed in
> single quotes. This takes effects only when --query=property or
> --device-id-of-file=FILE is
>specified.
> 
> It doesn't claim that this is a shell parseable format which can be run
> through eval, so I don't think you can rely on that.

The --export option has been implemented to be shell parseable. The
bugfix https://bugzilla.redhat.com/show_bug.cgi?id=644330 claims:

-->8--
Previously, the output of the command "udevadm info --query=property"
could not be used as input to shell interpreters. This update adds
"--query=property --export", which changes the output to be shell parseable.
--8<--

So the IMPORT{cmdline}="net.ifnames" is a kind of regression. If it is
absolutely necessary, at least should it be mitigated and restricted to
the relevant devices, and only them. No ?

Thanks,
quidame




signature.asc
Description: OpenPGP digital signature

Bug#929892: vfat mounts are not protected

[quidame]

Hi,

Thank you for the report.

On 02/06/2019 20:43, Dark Penguin wrote:
> In lockfs mode, if there are any vfat mounts to be protected, they are
> ignored and simply mounted as read-write. Everything else is properly
> protected with overlayfs.
> 
> Isn't it kind of dangerous?.. The user is expecting everything to be safe!

Currently, lockfs-notify is expected to advertise the user that some
mounts are not locked.

> If it is not possible to protect a vfat filesystem due to overlayfs
> limitations, then maybe it should be mounted read-only instead of
> read-write? At least then the user will notice it before breaking
> something, and add it to the whitelist if they want it read-write,
> easily replicating the current behaviour. And currently, there is no way
> to do the opposite - which is, "in lockfs mode, mount everything that
> can not be properly protected as read-only".

Yes, it is not possible to protect a vfat filesystem due to overlayfs
limitations. Installing aufs-dkms, and automatically using aufs module
instead of overlay module solves the issue.

But you're right, this points to a more general issue about the mount
fallback implementation: in case of mount error, the filesystem is
mounted as is (i.e. as it were without lockfs). But blindly mount it
read-only may also break things, and the user should keep the last word.

So this issue will probably be fixed in the next release of bilibop,
with a bilibop.conf option (and its corresponding boot commandline
parameter to override it), as for example:
BILIBOP_LOCKFS_MOUNT_FALLBACK="ro" (or 'rw' or 'skip' or...)

Thanks,
quidame



signature.asc
Description: OpenPGP digital signature

Bug#929893: Emergency shell due to broken parsing

[quidame]

Hi,

Thanks for the report.

On 02/06/2019 20:50, Dark Penguin wrote:
> 
> /sbin/mount.lockfs: 1: eval: net.ifnames=0: not found
> 
> This is apparently a part of my kernel command line. Here it is, just in
> case:
> 
> # cat /proc/cmdline
> BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64
> root=UUID=64e67ea6-1627-4258-9c70-8bcc120daf86 ro console=tty1
> console=ttyS0 ipv6.disable=1 net.ifnames=0 consoleblank=0 lockfs

It is in fact due to a bug in udev:
https://bugs.debian.org/934589 (udev: net.ifnames is wrongly imported as
a property for any/all devices)

As a workaroud, you can:
- Copy /lib/udev/rules.d/73-usb-net-by-mac.rules in /etc/udev/rules.d
- Add the following directive as the first one in the copy:
  SUBSYSTEM=="block", GOTO="usb_net_by_mac_end"

Or create an empty file at /etc/udev/rules.d/73-usb-net-by-mac.rules to
disable the one in /lib/udev/rules.d

I'm waiting for the result of the pending bug #934589, to state about
this one.

Thanks,
quidame



signature.asc
Description: OpenPGP digital signature

Bug#929891: Error message about udev rules not found

[quidame]

Hi,

On 02/06/2019 20:39, Dark Penguin wrote:
> After installing bilibop, even without enabling lockfs, I see this error
> message during the boot process:
> 
> ---
> Begin: Running /scripts/local-bottom ... Warning: bilibop-lockfs:
> Nothing to do.
> ls: /root/etc/udev/rules.d/70-persistent-cd.rules: No such file or directory
> ls: /root/etc/udev/rules.d/70-persistent-net.rules: No such file or
> directory
> done.
> ---

Thanks for the report. This will be fixed in the next release.

For the record:

The issue comes from the '-a' (AND) operator of the command 'test', that
is not very strict: in 'test condition1 -a condition2', condition2 is
evaluated even if condition1 is false. Using 'test condition1 && test
condition2' (with &&, the AND operator of the shell, more strict) will
solve this.

quidame



signature.asc
Description: OpenPGP digital signature

Bug#934589: udev: net.ifnames is wrongly imported as a property for any/all devices

[quidame]

Hi,

On 12/08/2019 13:14, Michael Biebl wrote:
> Control: tags -1 + moreinfo unreproducible

To reproduce it, as said in the report, net.ifnames MUST BE SET in the
boot commandline.

$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 root=/dev/mapper/luks-root ro
net.ifnames=0 quiet

The bug is fully reproducible on fresh installs of debian stable (udev
241-5), testing (udev 241-7) and sid (udev 241-7).

> I don't use LVM, but running that e.g. on /dev/sda5, I get

LVM doesn't matter here, as the property is imported to ALL devices,
including /dev/null !!! (as said in the report)

> What do you get if you run
> grep ifnames /etc/udev/rules.d/* /lib/udev/rules.d/*

I already did this before reporting the bug, and pointed to the first
line of /lib/udev/rules.d/73-usb-net-by-mac.rules, that is shipped with
the udev package:

IMPORT{cmdline}="net.ifnames"

As said in udev(7):

IMPORT{type}
Import a set of variables as device properties, depending on "type":
[...]
"cmdline"
Import a single property from the kernel command line. For
simple flags the value of the property is set to "1".


And again, for me the culprit is a missing block of filters **before**
this IMPORT directive,

> Can you tar up all files in /etc/udev/rules.d and /lib/udev/rules.d and
> attach it to this bug report.

My /etc/udev/rules.d is empty.
The only relevant file in /lib/udev/rules.d is 73-usb-net-by-mac.rules
(attached, unchanged)

Thanks,
quidame
# Use MAC based names for network interfaces which are directly or indirectly
# on USB and have an universally administered (stable) MAC address (second bit
# is 0). Don't do this when ifnames is disabled via kernel command line or
# customizing/disabling 99-default.link (or previously 80-net-setup-link.rules).

IMPORT{cmdline}="net.ifnames"
ENV{net.ifnames}=="0", GOTO="usb_net_by_mac_end"

ACTION=="add", SUBSYSTEM=="net", SUBSYSTEMS=="usb", NAME=="", \
ATTR{address}=="?[014589cd]:*", \
TEST!="/etc/udev/rules.d/80-net-setup-link.rules", \
TEST!="/etc/systemd/network/99-default.link", \
IMPORT{builtin}="net_id", NAME="$env{ID_NET_NAME_MAC}"

LABEL="usb_net_by_mac_end"


signature.asc
Description: OpenPGP digital signature

Bug#934589: udev: net.ifnames is wrongly imported as a property for any/all devices

[quidame]

Package: udev
Version: 241-7
Severity: normal

Dear Maintainer,

When running a command such as:

udevadm info --query property --export --name /dev/dm-2

I expect to get a list of properties of the device (/dev/dm-2) in a
shell-parsable format - that is the purpose of the --export option.

So I could do, in a shell script:

eval $(udevadm info --query property --export --name /dev/dm-2)


This works fine, except when net.ifnames is set as a kernel commandline
parameter. In that case, net.ifnames is added as a property for the
devicei, and the same udevadm command gives...

DEVPATH='/devices/virtual/block/dm-2'
DEVNAME='/dev/dm-2'
DEVTYPE='disk'
MAJOR='253'
MINOR='2'
SUBSYSTEM='block'
USEC_INITIALIZED='2145169'
DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG='1'
DM_UDEV_PRIMARY_SOURCE_FLAG='1'
DM_UDEV_RULES='1'
DM_UDEV_RULES_VSN='2'
DM_NAME='test1_vg-var'

DM_UUID='LVM-JDjOejCnj59z49qRaUFXieNPfyeJvWmzfVc31bebpEfCIHd3H3aJmgJbt9od0QGf'
DM_SUSPENDED='0'
DM_VG_NAME='test1_vg'
DM_LV_NAME='var'
ID_FS_UUID='1acc2657-541f-4226-97aa-58183b5e38dc'
ID_FS_UUID_ENC='1acc2657-541f-4226-97aa-58183b5e38dc'
ID_FS_VERSION='1.0'
ID_FS_TYPE='ext4'
ID_FS_USAGE='filesystem'
=>  net.ifnames='1'
DEVLINKS='/dev/test1_vg/var 
/dev/disk/by-uuid/1acc2657-541f-4226-97aa-58183b5e38dc 
/dev/disk/by-id/dm-name-test1_vg-var /dev/mapper/test1_vg-var 
/dev/disk/by-id/dm-uuid-LVM-JDjOejCnj59z49qRaUFXieNPfyeJvWmzfVc31bebpEfCIHd3H3aJmgJbt9od0QGf'
TAGS=':systemd:'

...making the output unparsable, due to the invalid format of the
variable: in shell, a dot (.) is not a valid character for a variable
name !

This is due to the udev rules file
/usr/lib/udev/rules.d/73-usb-net-by-mac.rules, in which net.ifnames is
blindly imported as a property for any device, even /dev/null !!!

$ udevadm info --query property --export --name /dev/null
DEVPATH='/devices/virtual/mem/null'
DEVNAME='/dev/null'
DEVMODE='0666'
MAJOR='1'
MINOR='3'
SUBSYSTEM='mem'
USEC_INITIALIZED='844981'
=>  net.ifnames='1'

I think the mistake comes from the first line of the rules file:

IMPORT{cmdline}="net.ifnames"

The rules file should start with some filters instead, to not import a
property that is irrelevant for almost all devices. For example:

SUBSYSTEM=="mem|block", GOTO="usb_net_by_mac_end"

See also:
https://bugs.debian.org/929893

Thanks,
quidame


-- Package-specific info:

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages udev depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libacl1   2.2.53-4
ii  libblkid1 2.34-0.1
ii  libc6 2.28-10
ii  libkmod2  26-1
ii  libselinux1   2.9-2+b2
ii  libudev1  241-7
ii  lsb-base  10.2019051400
ii  systemd-sysv  241-7
ii  util-linux2.34-0.1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  241-7

-- no debconf information
P: /devices/LNXSYSTM:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXSYSTM:
E: USEC_INITIALIZED=801089
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: net.ifnames=1

P: /devices/LNXSYSTM:00/LNXPWRBN:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00
E: SUBSYSTEM=acpi
E: DRIVER=button
E: MODALIAS=acpi:LNXPWRBN:
E: USEC_INITIALIZED=801232
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: net.ifnames=1

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
E: SUBSYSTEM=input
E: PRODUCT=19/0/1/0
E: NAME="Power Button"
E: PHYS="LNXPWRBN/button/input0"
E: PROP=0
E: EV=3
E: KEY=10 0
E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw
E: USEC_INITIALIZED=2004372
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: ID_FOR_SEAT=input-acpi-LNXPWRBN_00
E: net.ifnames=1
E: TAGS=:seat:

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4/event3
N: input/event3
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4/event3
E: SUBSYSTEM=input
E: DEVNAME=/dev/input/event3
E: MAJOR=13
E: MINOR=67
E: USEC_INITIALIZED=2041766
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: net.ifnames=1
E: TAGS=:power-switch:

P: /devices/LNXSYSTM:00/LNXSYBUS:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00
E: SUBSYSTEM=acpi
E: MODALIAS=acpi:LNXSYBUS:
E: USEC_INITIALIZED=801351
E: ID_VENDOR_FROM_DATABASE=The Linux Foundation
E: net.ifnames=1

P: /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0010:00
L: 0
E: DEVPATH=/devic

Bug#928780: bilibop-lockfs: fail to boot: mount error in case of read-only filesystem

[quidame]

Package: bilibop-lockfs
Version: 0.5.5
Severity: important
Tags: upstream

A user reported me that:

> After installing the package and configuring the wanted behavior over
> the configuration file I have restarted my system but it ran into a
> mount error.
> My analysis revealed that one of my filesystems couldn't be mounted
> because of the fact that the underlying tmpfs filesystem has been
> mounted read-only and so the needed subdirectories ro,rw and.rw
> couldn't be created to mount the different branches. The reason why
> the tmpfs filesystem has been mounted read-only was the fact that the
> original filesystem was marked as read-only in the fstab either.
> So I have looked into the mount-helper script and I have noticed that
> you apply the mount options of the original filesystem to the writable
> branch and so you apply the read-only option either but this prevents
> the creation of the needed subdirectories.

This is reproducible. A 'ro' mount option in fstab that is applied
without error when bilibop-lockfs is disabled, breaks the boot sequence
(to recovery mode) when bilibop-lockfs is enabled.


-- no system information

-- no debconf information

Bug#928658: bilibop-lockfs: Mounting /boot fails, mount.lockfs is broken

[quidame]

Hi,

On 08/05/2019 14:57, Alan wrote:
> 
> The system fails to boot after installing bilibop-lockfs and activating it on 
> a freshly installed Debian (Buster/testing).

Yes, I reproduced it.

> Please note that this was tested on a encrypted LVM created during Debian 
> installation.

It doesn't matter. As said in the bug title, mount.lockfs is broken,
you're right. A test against mount path has not been updated, and fails
on buster fresh installs - it doesn't on buster upgraded from stretch.

The culprit test in the script expects /proc/${PPID}/exe points to
/bin/mount (i.e. the parent process of mount.lockfs is /bin/mount). But
on buster, /bin is a symlink to /usr/bin so the actual executable is
/usr/bin/mount instead.

The bug is fixed upstream now, and the fix will be released soon. A
quick workaround (tested) is to turn "/bin/mount" into "/usr/bin/mount"
in /lib/bilibop/lockfs_mount_helper (line 58).

Thank you for the report,
quidame



signature.asc
Description: OpenPGP digital signature

Bug#870214: backupninja: sys handler wrongly reports warning due to wrong devices list

[quidame]

Package: backupninja
Version: 1.0.1-2
Severity: normal
Tags: upstream

Hi,

After upgrading to Stretch, backupninja's sys handler reports
warnings saying that "the partition table for /dev/mapper/vg-lv
could not be saved" (one warning per Logical Volume)

Reading in /usr/share/backupninja/sys, it appears that the
devices list is filtered from the 'sfdisk -l' output. Then
devices are processed by 'sfdisk -d'.

But the behavior of 'sfdisk -d' has changed:

- Jessie:
root@host:~# sfdisk -d /dev/mapper/vg0-lv0; echo $?
0

- Stretch:
root@host:~# sfdisk -d /dev/mapper/vg0-lv0; echo $?
sfdisk: /dev/mapper/vg0-lv0: does not contain a recognized partition table
1

It means that what was silently ignored is now clearly a case of
failure. But as 'sfdisk -d' by itsel is a purpose of the sys
plugin, and so can't be changed, the way devices are listed
should probably be changed.

Parsing 'lsblk -o kname,type' instead of 'sfdisk -l' to build
the devices list fixed the problem on our server.

Cheers,
quidame



-- System Information:
Debian Release: 8.9
  APT prefers oldstable
  APT policy: (990, 'oldstable'), (500, 'oldstable-updates'), (500, 
'oldstable-proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages backupninja depends on:
ii  bash4.3-11+deb8u1
ii  bsd-mailx [mailx]   8.1.2-0.20141216cvs-2
ii  dialog  1.2-20140911-1
ii  gawk1:4.1.1+dfsg-1
ii  heirloom-mailx [mailx]  12.5-4
ii  mawk1.3.3-17

backupninja recommends no packages.

Versions of packages backupninja suggests:
ii  bzip2  1.0.6-7+b3
ii  debconf-utils  1.5.56+deb8u1
ii  duplicity  0.6.24-1
ii  genisoimage9:1.1.11-3
ii  hwinfo 21.6-1
ii  mdadm  3.3.2-5+deb8u2
pn  rdiff-backup   
ii  rsync  3.1.1-3
ii  subversion 1.8.10-6+deb8u4
pn  trickle
ii  wodim  9:1.1.11-3

-- Configuration Files:
/etc/backupninja.conf changed [not included]

-- no debconf information

Bug#863222: unblock: bilibop/0.5.2.1

[quidame]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi,

Please unblock package bilibop, as it meets the
following unblock requirements:

Version 0.5.2 (currently in testing) is affected
by a bug [1] with severity "important", which now
is fixed in version 0.5.2.1 (currently in unstable).

The package is optional, and builds fine on all
applicable architectures, as shown there [2].

Also please consider the attached debdiff.

[1] https://bugs.debian.org/861685
[2] https://buildd.debian.org/status/package.php?p=bilibop

unblock bilibop/0.5.2.1

-- System Information:
Debian Release: 8.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
diff -Nru bilibop-0.5.2/debian/changelog bilibop-0.5.2.1/debian/changelog
--- bilibop-0.5.2/debian/changelog	2017-01-17 00:29:07.0 +0100
+++ bilibop-0.5.2.1/debian/changelog	2017-05-18 17:20:24.0 +0200
@@ -1,3 +1,11 @@
+bilibop (0.5.2.1) unstable; urgency=high
+
+  * bilibop-common:
+- modify underlying_device_from_aufs() to support multiple read-only
+  branches. Closes: #861685.
+
+ -- Yann Amar   Thu, 18 May 2017 15:20:24 +
+
 bilibop (0.5.2) unstable; urgency=low
 
   * bilibop-rules: add brazilian portuguese translation for debconf templates.
diff -Nru bilibop-0.5.2/lib/bilibop/common.sh bilibop-0.5.2.1/lib/bilibop/common.sh
--- bilibop-0.5.2/lib/bilibop/common.sh	2015-12-07 17:19:52.0 +0100
+++ bilibop-0.5.2.1/lib/bilibop/common.sh	2017-05-18 17:17:24.0 +0200
@@ -513,24 +513,31 @@
 # branch of an aufs mountpoint given as argument. We assume that there is only
 # and at least one physical device used to build the aufs (but the directory
 # is not necessarly the mountpoint of this device), other branch(s) being
-# virtual fs.
+# virtual fs. Note that if there are more than one readonly branch, the first
+# block device found wins.
 underlying_device_from_aufs() {
 ${DEBUG} && echo "> underlying_device_from_aufs $@" >&2
-local   dir="$(aufs_readonly_branch "${1}")"
-local   dev="$(device_id_of_file "${dir}")"
-case "${dev}" in
-"")
-;;
-0:*)
-# aufs mounts can't be nested; but this may be btrfs
-dev="$(underlying_device_from_file "${dir}")"
-;;
-*)
-dev="$(device_node_from_major_minor "${dev}")"
-;;
-esac
-
-[ -b "${dev}" ] && readlink -f "${dev}"
+local dev dir
+for dir in $(aufs_readonly_branch "${1}"); do
+dev="$(device_id_of_file "${dir}")"
+case "${dev}" in
+"")
+continue
+;;
+0:*)
+# aufs mounts can't be nested; but this may be btrfs
+dev="$(underlying_device_from_file "${dir}")"
+;;
+*)
+dev="$(device_node_from_major_minor "${dev}")"
+;;
+esac
+if [ -b "${dev}" ]; then
+readlink -f "${dev}"
+return 0
+fi
+done
+return 1
 }
 # ===}}}
 # underlying_device_from_overlayfs() {{{

Bug#861685: bilibop-common: Fails to detect boot device on systems with 2+ aufs read-only branches

[quidame]

Hi,

On 02/05/2017 19:50, intrig...@debian.org wrote:
> 
> It seems that some part of bilibop got confused and we get a string
> with two paths separated by a newline, where there should be only one
> path, no?

Yes. It seems the bug has been introduced at commit 03a49203282, between
versions 0.4.23 (in jessie) and 0.5.0.

> Downgrading to Jessie's bilibop fixes the problem… but it might
> introduce other problems, can't it?

Probably not in this case. Changes since 0.4.23 are about overlayfs
support, btrfs support, and documentation updates, typos, packaging and
so on. If you use aufs to manage incremental upgrades, I suppose you
don't use overlayfs ?

For the case you have an entry point to easily add a patch in your build
process, try the attached file. It may also be tested quickly from a
Tails session with:
# cd /
# patch -p1 < /path/to/bilibop-bugfix861685-01.patch
# /lib/bilibop/disk /
# /lib/bilibop/test /

I will test it too in a few days.

Thanks for your detailed bug report,
quidame
diff --git a/lib/bilibop/common.sh b/lib/bilibop/common.sh
index 5f9e4bb..589f177 100644
--- a/lib/bilibop/common.sh
+++ b/lib/bilibop/common.sh
@@ -513,24 +513,31 @@ underlying_device_from_loop() {
 # branch of an aufs mountpoint given as argument. We assume that there is only
 # and at least one physical device used to build the aufs (but the directory
 # is not necessarly the mountpoint of this device), other branch(s) being
-# virtual fs.
+# virtual fs. Note that if there are more than one readonly branch, the first
+# block device found wins.
 underlying_device_from_aufs() {
 ${DEBUG} && echo "> underlying_device_from_aufs $@" >&2
-local   dir="$(aufs_readonly_branch "${1}")"
-local   dev="$(device_id_of_file "${dir}")"
-case "${dev}" in
-"")
-;;
-0:*)
-# aufs mounts can't be nested; but this may be btrfs
-dev="$(underlying_device_from_file "${dir}")"
-;;
-*)
-dev="$(device_node_from_major_minor "${dev}")"
-;;
-esac
-
-[ -b "${dev}" ] && readlink -f "${dev}"
+local dev dir
+for dir in $(aufs_readonly_branch "${1}"); do
+dev="$(device_id_of_file "${dir}")"
+case "${dev}" in
+"")
+continue
+;;
+0:*)
+# aufs mounts can't be nested; but this may be btrfs
+dev="$(underlying_device_from_file "${dir}")"
+;;
+*)
+dev="$(device_node_from_major_minor "${dev}")"
+;;
+esac
+if [ -b "${dev}" ]; then
+readlink -f "${dev}"
+return 0
+fi
+done
+return 1
 }
 # ===}}}
 # underlying_device_from_overlayfs() {{{


signature.asc
Description: OpenPGP digital signature

Bug#800456: [INTL:da] Danish translation of the debconf templates bilibop

[quidame]

Hello,

On 29/09/2015 18:29, Joe Dalton wrote:
> Please include the attached Danish bilibop translation

It will be added in the next release. Thank you for your contribution.
quidame



signature.asc
Description: OpenPGP digital signature

Bug#778497: bilibop: Lacks support for overlay filesystem

[quidame]

Hi,

On 12/07/2015 11:35, intrigeri wrote:
 Hi,
 
 note that Linux 4.x, that replaces aufs with overlayfs, has entered
 sid two months ago. It still didn't migrate to testing, but I guess
 that it's a matter of days or weeks now.
 
 Of course bilibop has features that don't rely on any union FS, but
 still it would be good to avoid regressions for users of Debian
 testing.
 
 What's your current ETA regarding putting a new upstream release out
 that supports overlayfs? Anything I can do to help, e.g. by testing
 the (limited) codepaths we use in Tails?

It's almost ready for a new release. I'm updating the doc.

Cheers,
quidame



signature.asc
Description: OpenPGP digital signature

Bug#778497: bilibop: Lacks support for overlay filesystem

[quidame]

Hi,

On 15/02/2015 23:12, intrig...@debian.org wrote:
 
 the aufs patch set is going away from Debian, e.g. it's been removed
 in Linux 3.18 as found in experimental. It's being superseded by
 overlay FS.

Oh, yes, I didn't notice

 On a Debian Live system with Linux 3.18 and union=overlayfs,
 /lib/bilibop/test fails to identify the (USB) boot device as being on
 the same underlying device as the root FS, and in turn bilibop fails
 to tweak the ownership of the device nodes as it's supposed to do.
 
 I've only tested with bilibop 0.4.21~bpo70+1, as that's what we're
 using, and I've not seen any obviously related change in the
 newest releases.

You're right. bilibop-common and -udev are not affected by changes from
0.4.21. The fact is that overlayfs is currently not supported at all by
bilibop. It's not by design, just a missing support that I'll try to
provide soon.

 This is one of the blockers for Tails to upgrade its kernel to 3.18+.
 
 For your convenience, a test ISO will soon be available there:
 http://nightly.tails.boum.org/build_Tails_ISO_feature-linux-3.18/
 
 To reproduce, install it to a USB stick with Tails Installer, or just
 `dd' it to a USB stick (it's a hybrid ISO). I've not tested the
 latter, but I guess it'll produce the same results.

I confirm, dd it to a USB stick produces the same results. But it gives
me a working environment to modify-and-test bilibop-common, thank you.

My first experiments show that this is not obvious to find the device
mounted on the 'lowerdir' component of the overlay filesystem. The value
found in /proc/mounts (lowerdir=//filesystem.squashfs/) comes from the
initrd environment; it does not exist anymore at runtime as the
mountpoint has been moved to
'/lib/live/mount/rootfs/filesystem.squashfs'. These paths entirely
depend on live-boot (5.0~a1-1 in experimental). So I try to figure how
to find the lowerdir without previous knowledge of what it could be, and
fallback to live-boot usecases. This means that portable code is not yet
written, but some changes usable by debian-based live systems (at least
Tails) have already been tested and work. I will push them soon, follow
the branch 'experimental/overlayfs_support' [1].

Cheers,
quidame

[1] https://un.poivron.org/~quidame/git/bilibop.git



signature.asc
Description: OpenPGP digital signature

Bug#766647: bilibop: [INTL:nl] Dutch translation of debconf messages

[quidame]

Hi,

On 24/10/2014 17:45, Frans Spiesschaert wrote:
 
 Please find attached the Dutch translation of bilibop debconf messages.

Nice, thanks.

 Please add it to your next package revision.

It will be. Time is short now to include it in jessie before the freeze
(2014-11-05), but maybe...

Cheers,
quidame



signature.asc
Description: OpenPGP digital signature

Bug#756086: bilibop: [INTL:ru] Russian debconf templates translation

[quidame]

Hi,

On 26/07/2014 05:51, Yuri Kozlov wrote:
 Package: bilibop
 Version: 0.4.21
 Severity: wishlist
 Tags: l10n patch
 
 Russian debconf templates translation is attached.

This will be added soon, thanks for your contribution.
quidame



signature.asc
Description: OpenPGP digital signature

Bug#751892: udev: external media belong to disk group

[quidame]

Hi,

On 17/06/2014 17:28, Michael Biebl wrote:
 Am 17.06.2014 17:04, schrieb Yann Amar:

 Knowing that the default user created during installation is member of
 secondary groups 'floppy' and 'plugdev', and knowing that making this user a
 member of the 'disk' group will only lead to security issues, wouldn't be
 possible to (re)introduce specific rules to manage external/removable devices
 differently than the internal ones, and make them readable and writable by 
 any
 member of 'floppy' or 'plugdev'? Or is there a plan to work around this 
 issue?
 
 Static groups are a workaround, not very flexible and an all-or-nothing
 approach.

I disagree: making all block devices owned by the same group than the
system's disk is the real all-or-nothing approach, as explained just
above. See also old bugs against udev ([1] and [2]). I know that setting
removable devices to belong to floppy or plugdev group is an issue in
some specific cases [3], but there is now a small package in Debian [4]
to avoid that, by using udev to set UNIX group and udisks properties in
a per device basis.

Even if static groups are not very flexible, there are programs based on
or using static groups to build fine grained solutions: udev, sudo, acl,
policykit, between others. Saying that static groups (and UNIX
permissions) are not very flexible does not mean that they are obsolete.

 Use a tool like udisks if you need a more dynamic solution.

I doubt that udisks has been designed and can be used as a wrapper
around any arbitrary command. How to obtain a result similar to, say,
'dd if=mini.iso of=/dev/sdb' with udisks, and without typing an admin
password to do that on the USB stick I just come to plug in? Is this
kind of action not considered as legitime?

Cheers,
quidame

[1] https://bugs.debian.org/402622
[2] https://bugs.debian.org/402649
[3] https://bugs.debian.org/645466
[4] https://packages.debian.org/search?searchon=sourcenameskeywords=bilibop



signature.asc
Description: OpenPGP digital signature

Bug#738781: bilibop: [INTL:de] Initial German debconf translation

[quidame]

Hi,

On 12/02/2014 22:48, Chris Leick wrote:
 
 please find attached the initial German debconf translation of bilibop.
 
This will be included in the next release, thanks for your contribution.
quidame



signature.asc
Description: OpenPGP digital signature

Bug#733867: [INTL:es] Spanish debconf template translation for bilibop

[quidame]

Hi,

On 01/01/2014 17:03, Camaleón wrote:
 Package: bilibop
 Version: 0.4.20
 Severity: wishlist
 Tags: l10n patch
 
 Greetings,

Your po file will be included in the next release, thanks for your
contribution.

--
quidame



signature.asc
Description: OpenPGP digital signature

Bug#730000: bilibop: [INTL:pt] Updated Portuguese translation for debconf messages

[quidame]

Hi,

On 20/11/2013 01:22, Américo Monteiro wrote:
 
 Updated Portuguese translation for bilibop's debconf messages.
 Translator: Américo Monteiro a_monte...@gmx.com
 Feel free to use it.

This will be included in the next release. Thanks for your contribution.
quidame



signature.asc
Description: OpenPGP digital signature

Bug#727755: bilibop: [INTL:it] Italian translation of debconf messages

[quidame]

Hello,

On 26/10/2013 10:54, Beatrice Torracca wrote:
 
 Please find attached the Italian translation of bilibop debconf messages
 proofread by the Italian localization team.
 
 Please include it in your next upload.

For sure, I will! Thanks for your contribution.
quidame



signature.asc
Description: OpenPGP digital signature

Bug#727682: bilibop-rules: Fails to configure: lsbilibop calls udevadm in an unsupported way

[quidame]

Hi,

On 25/10/2013 12:24, Axel Beckert wrote:
 
 But bilibop-rules fails to install during configure phase. I've added a
 set -x to the package's postinst script to see where it exactly fails:
 
 [...]
 
 /bin/lsbilibop seems to call udevadm in line 44 as follows:
 
 udev_root=$(udevadm info --root)
 
 But calling udevadm info --root manually on the commandline throws
 exactly the above error message. According to the man-page, the --root
 option is only thought as additional option for two query types:

Oh my bad, you're right. This no more works since udev is now a part of
systemd. I wil fix it today, thanks for your detailed report.

Cheers,
quidame



signature.asc
Description: OpenPGP digital signature

Bug#726975: bilibop: [INTL:ja] New Japanese translation

[quidame]

Hi,

On 21/10/2013 07:51, victory wrote:
 
  Here's Japanese po-debconf template translation (ja.po) file that 
  reviewed by several Japanese Debian developers and users.
 
  Could you apply it, please?

Oh yes, I will! Thanks for your contribution.
quidame



signature.asc
Description: OpenPGP digital signature

Bug#675532: RFS: bilibop/0.1 (ITP #675467)

[quidame]

Hi,

On 10/09/2013 12:40, intrigeri wrote:
 
 Thanks for all the fixes. I've just reviewed and built 0.4.15 and
 hoped to upload right away, but Lintian is still not happy:
 
 W: bilibop-rules: extended-description-contains-empty-paragraph
 N: 
 N:The extended description (the lines after the first line of the
 N:Description: field) contains an empty paragraph.
 N:
 N:Severity: normal, Certainty: certain
 N:
 N:Check: description, Type: binary, udeb
 N: 
 W: bilibop: extended-description-contains-empty-paragraph
 W: bilibop-lockfs: extended-description-contains-empty-paragraph
 W: bilibop-common: extended-description-contains-empty-paragraph
 W: bilibop-udev: extended-description-contains-empty-paragraph
 
 Looks like some buggy variable substitution.

Oops, you're right.
It is due to a trailing ${Newline} in the Description variable.
It was added to work around a bug [1] affecting dpkg-dev; but this bug
having been fixed recently... the workaround becomes a bug :)

So, fixed:
http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.4.16.dsc

Cheers,
quidame

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659814



signature.asc
Description: OpenPGP digital signature

Bug#714455: molly-guard: Add debconf support

[quidame]

Hi,

On 08/08/2013 12:35, martin f krafft wrote:
 
 [2] Instead of setting env_keep globally, I suggest to create
 a Cmnd_Alias for the commands molly-guard protects, and then to use
 this syntax:
 
   Defaults!MOLLY_GUARD_COMMANDS env_keep+=SSH_CONNECTION

hmm... finally, I'm not sure it is a so good idea:

user@debian:~$ sudo cat /etc/sudoers.d/molly-guard
# /etc/sudoers.d/molly-guard
# [...]
Cmnd_Alias MOLLY_GUARD_COMMANDS = /usr/sbin/halt, /sbin/halt, [...]
Defaults!MOLLY_GUARD_COMMANDS env_keep += SSH_CONNECTION

user@debian:~$ echo $SSH_CONNECTION
(source_ip source_port dest_ip dest_port)
user@debian:~$ sudo halt
(molly-guard prompts for the hostname)
user@debian:~$ sudo -s
root@debian:/home/user# echo $SSH_CONNECTION

root@debian:/home/user# halt
(unguarded; end of story)

In this example, I invoke directly a root shell; but the same happens if
I invoke another command that provides a shell, either directly (screen
or tmux), or by escaping to a shell or running a shell command (vim,
emacs, mc...)

So I would prefer: Defaults env_keep+=SSH_CONNECTION
Otherwise, the usecases for which shutdown commands are protected are
too specific and then these restricted sudoers settings provide no real
benefit.

There are some other pros:
- I don't think the export of SSH_CONNEXION into sudo environment is
  able to introduce a security issue; it is even not a pathname.
- Knowing that a lot of users use 'sudo -E' when they need to use such
  or such variable into sudo environment, provide some useful variable
  in the env_keep whitelist can refrain them to use the (unsecure) -E
  option.
- SSH_CONNECTION is exported in 'su', why not to export it in 'sudo' ?

Cheers,
quidame



signature.asc
Description: OpenPGP digital signature

Bug#714455: molly-guard: Add debconf support

[quidame]

Hi,

On 08/08/2013 12:35, martin f krafft wrote:
 
 [1] I am really not comfortable with diverting these integral
 commands. The reason is that there might well be other tools that
 rely on these and might trip over the requirement for a tty, or
 unexpected output to stdout.

hm... maybe, maybe not. What do you mean about requirement for a tty?
I read test -t 0 || exit 0 (in 30-query-hostname): so tty is required
to protect a command, not to execute it. The only one side effect I have
found comes from molly-guard itself (needs to export MOLLYGUARD_CMD
earlier in the shutdown script to avoid infinite loops with 'shutdown
-c'). But as you suggest below, this should be heavily tested.

 Don't you think this is too intrusive?

No. In the provided patch, sysvinit's commands are not diverted by
default, and the question is asked with debconf priority low. So the
diversion should be rare and only done by experienced users. Side
effects (if any) should be clearly exposed by debconf, with the question.

Additionally, when a command is diverted, this is generally to replace
it by another one; for example, if you install gnu-fdisk, this will
divert fdisk and cfdisk; then if you invoke 'cfdisk', the diverted
command will not be executed; here, the diversion is used to add a
check-point before the execution of the diverted command, and then call
it or exit. Finally, this is always the sysvinit's commands that are
used to halt/reboot/poweroff/shutdown the system. Maybe this usage of
dpkg-divert is a little bit hackish or not very canonical, but I don't
feel it so intrusive.

The global scheme is the following:

root@debian:~# halt (is /usr/sbin/halt)
then:
- /usr/sbin/halt: *CHECK*
- exit, or exec /sbin/halt
- exec /sbin/halt.real

user@debian:~$ halt (is alias halt='sudo /sbin/halt')
then:
- /sbin/halt (test the value of $MOLLYGUARD_CMD)
- exec /usr/sbin/halt: *CHECK* (and export MOLLYGUARD_CMD)
- exit, or exec /sbin/halt (test the value of $MOLLYGUARD_CMD)
- exec /sbin/halt.real

If /usr/sbin/halt is not executable (/usr not mounted...), then:
- /sbin/halt
- exec /sbin/halt.real

 [2] Instead of setting env_keep globally, I suggest to create
 a Cmnd_Alias for the commands molly-guard protects, and then to use
 this syntax:
 
   Defaults!MOLLY_GUARD_COMMANDS env_keep+=SSH_CONNECTION

Oh, yes (even if I think there is no need to be so precautionous with a
such variable)

 In general, this looks well done. I am really just hesitant to make
 such changes at the moment, and this is mainly because I know I will
 not be able to deal with bug reports if they come in over the next
 months.

I hear. But as I would be the author of such bugs, I should be able to
deal with reports about them. And I have enough time for that.

 How would you feel taking over molly-guard maintenance? Then I would
 suggest that we upload a new package to experimental and get some
 testers.

Alright. Sounds good to me. I'm not very experienced as a package
maintainer, so my question is: how to proceed ? (I suppose I have to
bump to compat 9 and update the Standards-Version to the current one,
add my name and email address here and there, create the missing
debian/source/format as quilt, provide fr.po for debconf as proposed
in a previous email, fix lintian warnings and so on, and finally add an
entry in the changelog to report that and close the related bugs; but
after ?)

And for the tests... maybe the author of #660064 could be interested ?

Cheers,
quidame



signature.asc
Description: OpenPGP digital signature

Bug#675532: RFS: bilibop/0.1 (ITP #675467)

[quidame]

Hi,
and thanks for this review

On 19/07/2013 20:25, intrigeri wrote:

 First, was the target distribution change in debian/changelog
 intentional? (0.4.12 has experimental, 0.4.13 has unstable.)

Yes it is; the target distribution was set to experimental for the
wheezy's freeze duration... after what it was forgotten. Do you think
I should revert to experimental ?

 Second, it looks like important changes and refactoring are flowing in
 rather quickly, so I'd like to check that you are confident with the
 current state of bilibop, and believe it is stable enough to be part
 of a Debian release. Do you confirm this?

The most important changes are about debconf support, which has been
added to bilibop-rules. I consider this as an improvement. Maintainer
scripts are idempotent. I have tested bilibop-rules 0.4.13 installation
in several ways: fresh install (with or without preseeding it), upgrade
from 0.4.11, remove, reinstall, purge: all seems to work as expected.

Other things are mainly addition of comments in the shell library,
update of the documentation, and some changes in the code to take into
account some very specific usecases.

So yes, I am confident with the current state of bilibop (but yes, this
was not the case with 0.4.12 - less than one day of lifetime!). Also
note that bilibop is still in active development, and some enhancements
are planned for the next months or even next years; of course, important
attention is given to not break existing things.

 Also, please keep in mind that once bilibop is uploaded to Debian, the
 responsibility of backward compatibility will be yours, as the
 maintainer. This being said, while I certainly wouldn't mind a bit
 more abstraction / factorization at some places, the code looks solid
 enough :)
 
 Some nitpicking follows, that should be fixed before the initial
 upload IMHO:
 
 +myshell=$(awk -F: \$1 ~ /$(whoami)/ {print \$NF} /etc/passwd)
 
 Maybe use `getent' instead?

Fixed.

 Also Lintian says:
 
   I: bilibop-common: spelling-error-in-manpage
   usr/share/man/man1/drivemap.1.gz informations information
 
 ... and a few others, so you probably want to run it in verbose /
 pedantic mode and take the results into account.

Mh... I already used '--info --verbose --pedantic' in my script. I
thought it was enough, as mentors.debian.net/package/bilibop says
'Package is lintian clean'.

The tags you mention are catched by '--display-info'. Fixed.

So, here is the new version:
http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.4.14.dsc

Cheers
quidame



signature.asc
Description: OpenPGP digital signature

Bug#675532: RFS: bilibop/0.1 (ITP #675467)

[quidame]

Hi,

On 04/07/2013 08:49, intrigeri wrote:
 Hi,
 
 I plan to review, and hopefully upload bilibop next week.

Nice to hear :)
The last bilibop version is 0.4.13 [1].
The git repository [2] is ahead of 2 commits (fix minor errors).

Thank you
quidame

[1]:
http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.4.13.dsc
[2]: http://un.poivron.org/~quidame/git/bilibop.git



signature.asc
Description: OpenPGP digital signature

Bug#703747: netcfg: preseed netcfg: confusion or regression about disable_dhcp, disable_autoconfig and use_autoconfig

[quidame]

Le 2013-03-26 02:11, Samuel Thibault a écrit :

I have uploaded a fixed version on:

http://dept-info.labri.fr/~thibault/tmp/mini.iso

Could you check that just netcfg/disable_autoconfig=true works for 
you

too?

The uploaded iso image is for amd64 computers; but I only own a i386 
PC.

So, I can't check it, sorry.


Not a problem, now it's an i386 image, please try :)


OK. I have tried with:
1. Nothing
- DHCP autoconfig

2. netcfg/disable_autoconfig=true (on boot cmdline)
- prompt for static IP configuration

3. netcfg/disable_dhcp=true (on bootcmdline):
- prompt for static IP configuration

4. In /preseed.cfg (into the initrd):
d-i netcfg/disable_autoconfig boolean true
- prompt for static IP configuration

5. In /preseed.cfg (into the initrd):
d-i netcfg/disable_dhcp boolean true
- prompt for static IP configuration

Nice. For me, this bug can be closed now.

Thanks,
quidame


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#703747: netcfg: preseed netcfg: confusion or regression about disable_dhcp, disable_autoconfig and use_autoconfig

[quidame]

Hi,

Le 2013-03-26 00:03, Samuel Thibault a écrit :

Control: tags 703747 + pending
Control: found 703747 1.101
Control: tags 688273 + pending

Hello,

It seems the issue is merely that:

/* always always always default back to autoconfig, unless you've
specified
 * disable_autoconfig on the command line. */
debconf_get(client, netcfg/disable_autoconfig);

if (!strcmp(client-value, true))
debconf_set(client, netcfg/use_autoconfig, false);
else
debconf_set(client, netcfg/use_autoconfig, true);

/* also support disable_dhcp for compatibility */
debconf_get(client, netcfg/disable_dhcp);

if (!strcmp(client-value, true))
debconf_set(client, netcfg/use_autoconfig, false);
else
debconf_set(client, netcfg/use_autoconfig, true);

netcfg/disable_autoconfig has no effect of course, since
netcfg/disable_dhcp gets over it in all cases.


Right. Now it's very clear.


I have dropped the else part here, so disable_dhcp only has effect if
set to the non-default true.


Yes, that one gets the last word, whatever is before.  That should 
now
be fixed in the git tree, so disable_autoconfig will really be the 
right
way.  Until that gets uploaded you can use the disable_dhcp 
compatibility

debconf.


Nice.

use_autoconfig shouldn't have to be set to false. Both disable_dhcp 
(for

squeeze and earlier) and disable_autoconfig (for wheezy and later)
should be enough alone.


OK. Maybe this part of the documentation should be updated, to avoid 
confusing

other users ?
http://www.debian.org/releases/wheezy/example-preseed.txt
http://www.debian.org/releases/wheezy/${ARCH}/apbs04.html.en#preseed-network


I have uploaded a fixed version on:

http://dept-info.labri.fr/~thibault/tmp/mini.iso

Could you check that just netcfg/disable_autoconfig=true works for 
you

too?


The uploaded iso image is for amd64 computers; but I only own a i386 
PC.
So, I can't check it, sorry. But your explanations are very clear, 
thanks.


quidame


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#671546: udev: loop device: add backing file in udev database

[quidame]

Hi,

Le 2012-06-28 01:02, Marco d'Itri a écrit :

Then I recommend that you propose this change to the upstream
maintainer.


Done.

Thanks,
quidame



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#671546: udev: loop device: add backing file in udev database

[quidame]

Le 2012-06-27 14:40, m...@linux.it a écrit :

On May 05, bilibop quid...@poivron.org wrote:


ENV{BACKING_FILE}=%c

What uses this variable?


I have built a source package bilibop (RFS #675532). One of the 
binary packages is called bilibop-rules and is mainly a workaround of 
the bug #645466 (When running from removable media, udev allows direct 
access by floppy group):


some bilibop rules override 91-permissions.rules and fix the removable 
media hosting the running system, and all its partitions, as owned by 
the 'disk' group instead of 'floppy'. Because it supports multi-layered 
block devices (dm-crypt, LVM and loop devices), I have introduced this 
variable to ease the work.


But thinking that BACKING_FILE can be managed by the udev package 
instead of bilibop, the bilibop udev rules file has been splitted:

- 60-loopback.rules (the sample given in this bug report)
- 66-bilibop.rules
If the BACKING_FILE variable is introduced in udev, I will remove 
60-loopback.rules from bilibop; otherwise I keep it. That's all.


Additionally,

What uses this variable?
as it does not exist, nothing uses this variable, of course. But if it 
exists, maybe it can interest other people.


Cheers,
quidame




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#675532: RFS: bilibop/0.3.2 (ITP #675467)

[quidame]

Hi,

Le 2012-06-17 19:42, intrigeri a écrit :

Hopefully, I'll review this before the end of the month.
Other potential sponsors: if you can be faster than me, please do.


There is a new version (after tests on freshly installed systems):
http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.3.2.dsc

Thanks,
quidame




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#675532: RFS: bilibop/0.1 (ITP #675467)

[quidame]

Hi,

Le 2012-06-09 15:01, intrigeri a écrit :

quid...@poivron.org wrote (08 Jun 2012 22:35:21 GMT) :

I am waiting:
- for new comments from you or another DD
- to find by myself something to optimize in the code


How long do you intend to wait?


This was not a question of time. Here is the new version:

http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.3.0.dsc

Another possibility would be to move to non-native and increment 
the
Debian revision number only. In the present case, we would move 
from
0.2-1 to 0.2-2, which would reflect the actual changes quite 
better.



For me, this solution, if it is one, implies a lot of issues:
For bilibop-common, of course, no problem. With some minor changes,
maybe bilibop-rules could be fully portable too. But bilibop-lockfs,
in its actual state, is distribution dependent; it depends on
initramfs-tools, which is a Debian native source package. If I 
rewrite

bilibop-lockfs to make it more portable (i.e to integrate it in the
'dracut' infrastructure) it will never be installed on Debian, 
because

the default initramdisk builder is initramfs-tools, which conflicts
with dracut. But maybe I'm wrong and I have a bad overview on this
issue. Maybe bilibop-lockfs could be only a debian patch. Or what ?


I think it is entirely possible, even though not perfectly elegant, 
to

turn the package into a non-native one without immediately making the
code distro-independent and well separated between the Debian patch
and the upstream code.


Some tests with other distributions and some investigations in the udev
source package have shown that bilibop-rules is distribution dependant
too: for example, with CentOS or OpenSUSE, usb drives are owned by the
'disk' group.

Bilibop-common is the result of the split of bilibop into
bilibop-rules and bilibop-lockfs (because the first one can be used
only on removable devices, including LiveUSB; and the second one can
be used on any internal or external system except Live). So, I don't
understand the interest/benefit to build a non-native source package
that would be used only on Debian. Surely it is entirely possible,
but I don't think everything possible must be done.

Cheers,
quidame




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#675532: RFS: bilibop/0.1 (ITP #675467)

[quidame]

Hi,

Le 2012-06-08 04:06, intrigeri a écrit :

Hi,


http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.2.dsc


Great!


+  * New OpenPGP key.


I doubt this is relevant to debian/changelog.

+  * debian/control: change 'Achitecture: all' to 'Architecture: 
linux-any' for

+all binaries.


I think you mean all binary packages, right?

+  * debian/control: more precise description of the packages, their 
purposes
+and features. Add a statement about the required kernel 
version.


I doubt this statement is in debian/control.


Excuse me, I don't understand: do you mean:
- this statement should not be in debian/control
or:
- this statement is missing in debian/control

The first paragraph of the description and the requirement, which are
common to all binary packages, are included with ${Description} and
${Requirement}, defined in debian/substvars. Not good ?


+  * Clean debian/rules.


Without specifics, this is mostly useless noise.

s/an heuristic/a heuristic/
s/an udev/a udev/


normal users


Perhaps non-priviledged users instead?
I'm not sure I like the concept of normality involved here.

A initramfs-hook was moved from bilibop-common to bilibop-lockfs.
AFAICT, this is not mentionned in debian/changelog (which is the main
place where changes must be documented, given this is a native
package, and you use no VCS to explain the rationale of each
atomic change.)

Things are progressing! :)


OK, what is the best way, now ?
1. Fix typos and other errors you mention above, modify the existing
   changelog entry and keep the version number (0.2) ? In that case,
   is it possible to put the 'new' version to mentors.debian.org and
   overwrite the previous one ?
2. Fix typos and other things, add a new changelog entry and increment
   the version number (0.2.1) ? In that case, how to deal with the
   irrelevant or useless informations of the actual changelog ?
3. ?

Thanks for your attention
quidame




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#675532: RFS: bilibop/0.1 (ITP #675467)

[quidame]

Hi,

Le 2012-06-08 14:14, intrigeri a écrit :


quid...@poivron.org wrote (08 Jun 2012 10:46:14 GMT) :


2. Fix typos and other things, add a new changelog entry and 
increment

   the version number (0.2.1) ?


Yes.


   In that case, how to deal with the irrelevant or useless
   informations of the actual changelog ?


Forget it :)


OK. But packaging is not a goal in itself, so I think I will
not send a new version with just (in the changelog):
  * Fix typos, unclear sentences and language errors in
debian/control, in the documentation and in the comments
of the scripts and functions.

I am waiting:
- for new comments from you or another DD
- to find by myself something to optimize in the code


Another possibility would be to move to non-native and increment the
Debian revision number only. In the present case, we would move from
0.2-1 to 0.2-2, which would reflect the actual changes quite better.


For me, this solution, if it is one, implies a lot of issues:
For bilibop-common, of course, no problem. With some minor changes,
maybe bilibop-rules could be fully portable too. But bilibop-lockfs,
in its actual state, is distribution dependent; it depends on
initramfs-tools, which is a Debian native source package. If I rewrite
bilibop-lockfs to make it more portable (i.e to integrate it in the
'dracut' infrastructure) it will never be installed on Debian, because
the default initramdisk builder is initramfs-tools, which conflicts
with dracut. But maybe I'm wrong and I have a bad overview on this
issue. Maybe bilibop-lockfs could be only a debian patch. Or what ?

Cheers,
quidame




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#675532: RFS: bilibop/0.1 (ITP #675467)

[quidame]

Le 2012-06-05 20:57, intrigeri a écrit :

Here is a first, quick review.


Thank you.


The whole thing is arch:all, but some shell functions require a Linux
kernel shouldn't bilibop-common have a versioned dependency on Linux
kernel = 2.6.37 (needed by backing_file_from_loop), and be
arch:linux-any instead?


I don't know exactly how to do a versioned dependency on the kernel.
With a list of alternatives of *generic* (meta or dummy) packages?
like:
linux-image-486 (= 2.6.37) | linux-image-686 (= 2.6.37) |
linux-image-686-bigmem (= 2.6.37) | linux-image-686-pae (= 2.6.37) |
linux-image-amd64 (= 2.6.37) ... linux-image-itanium (= 2.6.37) |
and so on with 'powerpc', 'sparc64', 'sparc64-smp', plus the 'openvz'
and 'vserver' variants, the list is very long... Should I give an
exhaustive list of kernels, including all exotic achitectures, some
of them being relative to computers having even no USB, FireWire or
eSATA ports (but I don't know which), or what?
I'm looking for another package that could provide me an usable
example of such versioned kernel dependency, but I fail.

I've tried with just 'linux-image (= 2.6.37)', but lintian sends a
warning: virtual-package-depends-without-real-package-depends. Can
I override it (with override_dh_lintian in the rules) ?
I think I need help.

Additionally, changing 'all' by 'linux-any' leads to the creation
of architecture dependent binaries (formally, by their names), but
with exactly the same contents: shell scripts, udev rules, manpages
and other plain text documents.
So, I'm not sure that it is the best way. Maybe, for bilibop-common,
Architecture: linux-any, and for the others, Architecture: all ?

Do you think a NOTE in the extended description and/or in the README
could be sufficient ? (due to the fact that bilibop-* already depend
on base-files (= 6.4) and could be available from Wheezy or even
later, is there really a chance that it can be installed on systems
with a kernel older than 3.0 ?)


Quotes such as in « disk » are no international symbols, and I've
seen English native speakers misinterpret those.


Fixed.


You want an URI to a versioned copyright format:
Format: 
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

(catched by lintian --pedantic).


Fixed.


Any Vcs-Git / Vcs-Browser field? If you have none ready, I suggest
setting up a Git repository in collab-maint on Alioth.


I will think about it, later (I have to learn git before).


Given the Maintainer is a collective email address, we need at least
one human listed in the Uploaders: field (Debian Policy §3.3) -- note
that this field has nothing to do with who actually sponsors the
uploads; either put yourself, a co-maintainer, or the first sponsor 
if

they are willing to take the responsibility to act as co-maintainers.


Fixed.


Why does bilibop-common's postinst and postrm run update-initramfs?


Ooops... yes, this is an error (remaining files from old version).
Fixed.


The debian/changelog entry must close the ITP bug.


OK


The debian/rules header about Sample debian/rules that uses
debhelper should be removed.


Removed.


Why the need to disable override_dh_pysupport by hand?


The need ? None. Removed

Cheers,
quidame




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#675532: Fwd: Re: Bug#675532: RFS: bilibop/0.1 (ITP #675467)

[quidame]

 Message original 
Objet: Re: Bug#675532: RFS: bilibop/0.1 (ITP #675467)
Date: 2012-06-08 02:28
De: quid...@poivron.org
À: intrigeri intrig...@boum.org

Hi,

Le 2012-06-07 15:05, intrigeri a écrit :
So, really, I think the only sane way is to move everything (that is 
or

depends on bilibop-common) to arch:linux-any.


Done.


Do you think a NOTE in the extended description and/or in the README
could be sufficient ?


It would be sufficient to address the minimal Linux kernel version
requirement, but certainly not to address the needs Linux one.


Done.

A new version is available now:
http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.2.dsc

Cheers,
quidame




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#675467: ITP: bilibop -- run Debian from external media

[quidame]

 you would have posted this ITP quite 
sooner,

but who knows, I myself have not uploaded yet all new packages I want
to see in Wheezy -- the difference being I won't have to argue with
myself about packaging style and tools ;)


Yes, who knows. I wanted to post ITP and RFS sooner, but I have spent
last weeks to learn how to build debian packages...
Now I think bilibop (the source and the binaries) is in a good
shape and can interest people, at least for a review. If bilibop is
shipped in Wheezy, I will be happy; and I will include it in a
preseed file for further installations of Debian on removable media.
But what seems so good for me, maybe is not so good for the community?

Cheers,
quidame
# /lib/bilibop/common.sh
# vim: set et sw=4 sts=4 ts=4 fdm=marker fcl=all:

# For tests and debug purposes, set it to 'true':
DEBUG=false

# README {{{
#
# We assume that the commands in /usr/bin are not available (awk, cut, tail,
#  and others), and then are replaced by grep and sed euristics.
# We assume, even if it is not often, that /etc/udev/udev.conf can have been
#  modified and that 'udev_root' can be something else than '/dev'.
# dm-crypt/LUKS, LVM, loopback and aufs root filesystems (and combinations
#  of them) are now fully supported.
# Functions that just output informations about devices/filesystems can be
#  called by any unprivileged user.

# Variable subtitutions and builtin commands: ==={{{
# The bilibop shell functions use a lot of variable subtitutions. Some of them
# (bashisms?) can not work with some shells. For:
# - 'id=fe:00', we can use:
#   echo $((0x${id%:*})):$((${id#*:}))
#   (this is equivalent to: printf %d:%d\n 0x${id%:*} 0x${id#*:})
# - 'dm=/dev/mapper/system', we can use:
#   echo ${dm##*/}
# and other things like that.
#
# They have been tested (and work) with:
# - /bin/bash
# - /bin/dash
# - /bin/busybox sh
# - /usr/lib/klibc/bin/sh.shared
# - /bin/ksh93
# - /bin/mksh
# - /bin/zsh4
#
# They have been tested and don't work with:
# /bin/pdksh(this shell has even no 'printf' builtin!)
#
# Because the 'echo' builtin command is not samely implemented in all shells
# (especially the '-e' option is implicit in dash's echo), we never use this
# command with options, and never use escaped characters (\t, \n, \c...) in
# the string to echo.
# }}}
# Needed external commands: ={{{
# Here is a table of external GNU commands used in the following functions.
# Some of them having different options and behaviors when they are provided
# by 'busybox' or 'klibc', we note here which are working or not in the context
# of these functions (this is a base to write an initramfs-tools hook). 'YES'
# means it works, 'NO' means it don't, and '-' means it is not provided.
#
# GNU tools busybox builtinsklibc commands
# --
# /bin/cat  YES YES
# /bin/df   YES -
# /bin/grep YES -
# /bin/readlink YES NO
# /bin/sed  YES -
# /sbin/udevadm -   -
#
# Now we can say:
# - there is no need to add 'cat'.
# - 'udevadm' must be added (we assume udev provides a hook to do that).
# - if 'busybox' is not added into the initramdisk, we have to use the 'df',
#   'grep', 'readlink' and 'sed' GNU commands.
#   So, if busybox is not available into the initramdisk:
#   * add 'df', 'grep' and 'sed'
#   * replace the klibc's 'readlink' by the GNU one
#
# }}}
# Needed files: ={{{
# To run correctly, the bilibop functions need to read informations into some
# virtual files or directory, especially:
#
# /dev/* (or ${udev_root}/*)
# /dev/block/*
# /proc/cmdline
# /proc/filesystems
# /proc/mounts
# /proc/partitions
# /sys/block/sd?/removable
# /sys/block/dm-?/slaves
# /sys/block/loop?/loop/backing_file
# /sys/class/block/*/dev
# /sys/fs/aufs/si_*/br?
#
# So we assume that /dev, /proc and /sys are mounted. If you have to use this
# file from into a chrooted environment, you have to do something like that:
#
# # mount DEVICE /mnt
# # mount -t sysfs -o nodev,noexec,nosuid sysfs /mnt/sys
# # mount -t proc -o nodev,noexec,nosuid proc /mnt/proc
# # mount -t devtmpfs -o mode=0755 udev /mnt/dev
# and optionally:
# # mount -t tmpfs -o nosuid,nodev tmpfs /mnt/tmp
# # mount -t tmpfs -o nosuid,size=10%,mode=0755 tmpfs /mnt/run
# # mkdir -p /mnt/dev/pts /mnt/run/lock /mnt/run/shm
# # mount -t devpts -o noexec,nosuid,gid=5,mode=0620 devpts /mnt/dev/pts
# # mount -t tmpfs -o noexec,nodev,nosuid,size=10% tmpfs /mnt/run/lock
# # mount -t tmpfs -o nosuid,nodev tmpfs /mnt/run/shm
# and finally:
# # chroot /mnt
# }}}

# }}}

# bilibop_common_functions

Bug#675467: ITP: bilibop -- run Debian from external media

[quidame]

Le 2012-06-01 23:53, intrigeri a écrit :

Hi,

This looks pretty interesting and exciting to me!
Hence, a few inline questions follow.

bilibop project wrote (01 Jun 2012 13:10:51 GMT) :

One of its main goals is to fix security issues or harden standard
rules and policies to make the system more robust in this
particular situation.


This sounds awesome, but pretty vague, so I'm curious:
What security issues?
What hardening?
How more robust?

This is what i explain below...


bilibop-common: shell functions to find the drive hosting the root
filesystem (dm-crypt, LVM, loop devices, aufs and any combination of
them are supported)


This might be useful for Tails' implementation of wipe memory on
shutdown.
I have Tails installed on a USB key; the wipe memory on shutdown 
seems to work well,

without need of bilibop-common or whatever.

bilibop-rules: udev rules to fix the removable drive hosting the 
running
system, and all its partitions, as members of the 'disk' group 
(fixes bug

#645466).


I fail to understand how a drive can be a member of the 'disk' group.
Please enlighten me. (Being offline, I can't read the mentionned bug
right now, but still, the package description should make sense by
itself, without needing to access online resources.)

Boot on Debian, plug a USB/FireWire drive (key or HDD) on, and execute
'ls -l /dev/sd*':
You should see /dev/sda and its partitions as members of the 'disk' 
group

(and maybe also /dev/sdb* if there is a second internal HDD). And you
should see the USB drives and their partitions as members of the 
'floppy'
group. Now type, from your user account: 'groups'. If 'floppy' is in 
the
list, it means you have low-level write access on devices of this 
group.

You should not be member of the 'disk' group.

For example, you told me about Tails. So, boot on it (the LiveUSB, of 
course)
find the drive which your system is running from (here, we say 
/dev/sdb),
and, as the normal user, just type 'shred -vzn0 /dev/sdb'. Now your 
'secured'

system is lost.

So, find the drive hosting the running system and protect it from user
mistakes is what I call 'fix a security issue' or 'make the system more 
robust'.



Other optional features for the desktop environment (based on
Udisks).


Such as?

By setting:
 UDISKS_SYSTEM_INTERNAL
 UDISKS_PRESENTATION_HIDE
 UDISKS_PRESENTATION_ICON_NAME
 UDISKS_PRESENTATION_NAME
for devices listed in BILIBOP_RULES_* variables in 
/etc/bilibop/bilibop.conf
(see udisks(7) for some details). As said above, this is optional, and 
only

for convenience: hide partitions, or show them with icons and/or names
different than the defaults, or make the user able or not to mount them 
from

the filemanager with or without su/sudo password.
As said in the documentation of the package, all this can be bypassed 
with

pmount(1). This is not a security layer.


bilibop-lockfs: make a standard installation to behave like
a LiveUSB. Can be used as an alternative (and enhancement) of the
fsprotect package.


Interesting.
What makes it different from (or better than) fsprotect and 
live-boot?
In comparison with fsprotect, bilibop-lockfs has the following 
features:
1. whitelist based configuration: when bilibop-lockfs is enabled, all 
local

   fs are protected.
2. not only filesystems are set readonly, but also block devices
3. swap device management/policy (use it, don't use it, use it noauto, 
or

   use it only if encrypted)
4. notifications are send to the user at startup to say her if 
temporary

   or permanent changes are allowed or not, and where (mountpoints)

The section 2 is one of the features that hardens the standard rules 
and

policies: it makes the system unbreakable (unless with a hammer?).

For live-boot, I don't know. I've not studied the question: can it be 
used

on a standard system ? I use 'LiveUSB' comparison because the system is
running from a USB key/HDD, and nothing is written on the partition 
containing

the system.

The main difference is that a standard system (I say 'standard' by 
opposition
with 'live') is easier to maintain than a live system. For that, boot 
in
'recovery mode' (this disables 'lockfs'), update your system or 
reconfigure

such or such application, and reboot.


For more info about bilibop, please see
http://mentors.debian.net/package/bilibop

You can download the source with:
dget -x 
http://mentors.debian.net/debian/pool/main/b/bilibop/bilibop_0.1.dsc


I have send a RFS: #675532


Cheers,

Regards,
quidame



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org