[Pkg-zfsonlinux-devel] WIP branch for ZFS 0.7.0
f.gruenbichler at proxmox.com
Fri Aug 11 09:13:47 UTC 2017
On Fri, Aug 11, 2017 at 07:46:15AM +0200, Petter Reinholdtsen wrote:
> No one replied so far, so I guess I could chip in a bit. :)
> [Fabian Grünbichler]
> > - incorporate man page fixes I submitted upstream to get rid of some
> > lintian warnings
> Perhaps best to wait for upstream to include these, to not divert
> further from upstream than necessary? What are the upstream issue URLs?
sorry for not making this clear - I did not incorporate them yet because
they are just for cleanliness' sake, and I wanted to wait for upstream
to at least merge them into master before adding the patches to
still up for discussion is one related to dracut in ZFS, but as I a
have no experience with dracut I am not sure whether I am the right
person to follow through with that one ;)
> > 1.) /bin vs /sbin
> > how should we handle /dev/zfs and the read-only zfs/zpool commands being
> > user accessible upstream since 0.7? moving the zfs and zpool binaries to
> > /bin and putting a compat symlink in /sbin should work AFAICT
> I'd say the binaries have not changed in nature, and still belong in
> sbin/ even if they now also work without root privileges.
> <URL: https://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SBINSYSTEMBINARIES >
> state that sbin/ should contain "utilities used for system
> administration (and other root-only commands) are stored in /sbin,
> /usr/sbin, and /usr/local/sbin. /sbin contains binaries essential for
> booting, restoring, recovering, and/or repairing the system in addition
> to the binaries in /bin.", which still seem correct for the zfs/zpool
I am not sure as it seems to fall into a grey area of sorts. e.g. there
is already stuff like 'ip' and 'udevadm' which IMHO are in a similar
category, and both ship symlinks in /sbin and the actual binaries in
the new 'zpool status/iostat -c SOMETHING' option is not allowed to be
used as root unless overruled via an environment variable (for IMHO
valid security reasons).
I think this has some potential for confusion of the following sort:
user at sid-zfs:~$ sudo zpool status -c
[sudo] password for user:
Available 'zpool status -c' commands:
fault_led Show value of the disk enclosure slot fault LED.
upath Show the underlying path for a device.
pwr_cyc Show SMART power cycle count (ATA).
media Show whether a vdev is a file, hdd, or ssd.
user at sid-zfs:~$ sudo zpool status -c serial
Can't run -c with root privileges unless ZPOOL_SCRIPTS_AS_ROOT is set.
user at sid-zfs:~$ zpool status -c serial
-bash: zpool: command not found
more experienced users will probably know about sbin and $PATH or maybe
how to find where a binary is located:
user at sid-zfs:~$ whereis zpool
zpool: /sbin/zpool /usr/share/man/man8/zpool.8.gz
user at sid-zfs:~$ /sbin/zpool status -c serial
scan: none requested
NAME STATE READ WRITE CKSUM serial
rpool ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-part1 ONLINE 0 0 0 -
scsi-0QEMU_QEMU_HARDDISK_drive-scsi1-part1 ONLINE 0 0 0 -
scsi-0QEMU_QEMU_HARDDISK_drive-scsi2-part1 ONLINE 0 0 0 -
scsi-0QEMU_QEMU_HARDDISK_drive-scsi3-part1 ONLINE 0 0 0 -
errors: No known data errors
but we'd probably teach some other users to set the environment variable
and expose themselves to unnecessary risk in the course.
all that said I have no very strong feelings on this, so keeping them in
sbin is fine as well. dropping the old (deprecated upstream) sudoers
file probably warrants a NEWS entry anyway, and that could be used to
point people to the new way of accessing some ZFS stuff with
> I have no idea about the test stuff.
neither do I - it just got a lot more than in 0.6.5, so carrying it in
zfsutils-linux got 'wronger' IMHO.
More information about the Pkg-zfsonlinux-devel