:: [devuan-dev] bug#550: marked as don…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Devuan bug Tracking System
Fecha:  
A: Bob Proulx
Asunto: [devuan-dev] bug#550: marked as done (Unconditional addgroup kvm trouble)
Your message dated Wed, 17 Feb 2021 14:53:18 -0700
with message-id <20210217145011741276571@???>
and subject line Re: bug#550: Unconditional addgroup kvm trouble
has caused the Devuan bug report #550,
regarding Unconditional addgroup kvm trouble
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@???
immediately.)


--
550: https://bugs.devuan.org/cgi/bugreport.cgi?bug=550
Devuan Bug Tracking System
Contact owner@??? with problems
Package: eudev
Version: 3.2.9-8~beowulf1

The recent eudev 3.2.9-8~beowulf1 arrive on my systems and I noticed
that it configured two new groups "kvm" and "renderer". Which is
okay. And I note that libvirt-daemon-system also creates "kvm".

But the code used in the postinst is problematic. The code is this.

    #!/bin/sh
    set -e
    ...
    case "$1" in
        configure)
        ...
        # Add new system group used by udev rules
        addgroup --quiet --system input


        # Make /dev/kvm accessible to kvm group
        addgroup --quiet --system kvm


        # Make /dev/dri/renderD* accessible to render group
        addgroup --quiet --system render


Those are unconditional additions. Which means that if the group
already exists then there is an error. And due to the set -e this
error prevents installation. Problem reported by user DeepDive on
the #devuan IRC channel.

The group addition should not be unconditional. It should be
conditional upon the group not already existing. I present two
alternative examples.

The first from postfix. The "try it and see" method.

    cd ${CHROOT}
    # make sure that the postfix user exists.  Simplest portable way to check is to
    # chown something, so we'll create the directories that we need here.
    makedir private         root:root 700
    chgrp postfix private 2>/dev/null ||
        addgroup --system postfix
    chown postfix private 2>/dev/null ||
        adduser --system --home ${CHROOT} --no-create-home --disabled-password --ingroup postfix postfix


The second from libvirt-daemon-system. The "check it and see" method.

    if ! getent group libvirt >/dev/null; then
        addgroup --quiet --system libvirt
    fi
    if ! getent group kvm >/dev/null; then
        addgroup --quiet --system kvm
    fi


And so either way seems good and acceptable. I would probably do the
same thing libvirt-daemon-system is doing as that is simple enough.
Here is a suggested fix for this.

    # Add new system group used by udev rules
    if ! getent group input >/dev/null; then
        addgroup --quiet --system input
    fi


    # Make /dev/kvm accessible to kvm group
    if ! getent group kvm >/dev/null; then
        addgroup --quiet --system kvm
    fi


    # Make /dev/dri/renderD* accessible to render group
    if ! getent group render >/dev/null; then
        addgroup --quiet --system render
    fi


Thank you for maintaining eudev in Devuan! :-)

Bob
I just now discovered Bug#548 https://bugs.devuan.org/548 which I did
not originally see. I haven't ever really liked how the BTS handles
merges. Therefore I am simply going to close my report now with this
message and then add additional information to the original report.
That's simplest all around for everyone. :-)

Bob