Bug#548230: dropbear: configuration in /etc/<package> does not follow FHS

[Jari Aalto-5]

Package: tech-ctte
Severity: normal

CONCERNING

    "dropbear: Please patch sources not to use /etc/dropbear/{log,run}"
    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545242

SUMMARY

    I'm calling for a decision of reported bug in dropbear: "not to
    install anything else than configuration files to /etc."

    Maintainer has reject a proposal to move the scrips from
    /etc/<package>/ and to remove symlink pointing to directory /var/log

A REQUEST

    I'm hoping the committee to examine the FHS and it's appliance in
    Debian when there are no strong technical reasons to deviate from
    it. I feel that the decision is important and that it will set the
    direction how the FHS is to be interpreted in Debian.

    I believe, in technical wise, the issues itself are easily
    correctable in the package.

DETAILS

    The problems in the package were identified as follows:

    (1) /etc/dropbear/run is an executable
    (2) /etc/dropbear/log is a symlink pointing to /var/log/dropbear

    Suggestions made in the bug report to:

    (1) Move /etc/dropbear/run to /var/lib/dropbear/run and read
    configuration file /etc/dropbear/run.conf. A skeleton code to do
    this was provided in the bug report.

    (2) Remove /etc/dropbear/log. There is a separate FHS directory
    /var/log dedicated for this purpose. If a configurable location for
    log files is needed, add a configuration file to control the
    location.

RELATED STANDARDS

    http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCHOSTSPECIFICSYSTEMCONFIGURATION

        The /etc hierarchy contains configuration files. A
        "configuration file" is a local file used to control the
        operation of a program; it must be static and cannot be an
        executable binary.

AGREEMENTS

    Both I and maintainer acknowledge that /etc/init.d/ directory is
    special and is used for scripts, so the FHS, due to de facto
    history, does not apply there.

DISAGREEMENTS

1) Symlinks

    I: Symlinks are "not real configuration files" as per FHS. They
    can't be put under version control (not all VCS support symlinks).
    They can't be "diffed" e.g. to compare two setups. The program can
    be designed to read the log directory location from a separate file
    that can cotain a line like "logdir = /var/log".

    Maintainer: There is no problem. "A symlink" is a valid
    configuration file:

        /etc/dropbear/log -> /var/log/dropbear

2) Executables

    I: Excutables should not apperar under "/etc/<package>" as per FHS.
    Similar problems as above. Not all tools can preserve executable
    flags: version control, use of zip for backups etc. The executables
    can be placed elsewhere; like /var/lib/<package>. The program can
    read /etc/<package>/run.conf.

    Maintainer: There is no problem. Scripts are "configuration files"
    and can be stored in /etc/<package>, They are not FHS-incompatible;
    see the precedence e.g. in cases of /etc/init.d.

Jari



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Don Armstrong]

reassign 545242 tech-ctte
forcemerge 548230 545242
thanks

On Thu, 24 Sep 2009, Jari Aalto wrote:
>     The problems in the package were identified as follows:
>
>     (1) /etc/dropbear/run is an executable

There's nothing wrong with having executables in /etc, so long as they
are not binaries. /etc/dropbear/run is "a local file used to control
the operation of a program",[1] so it's perfectly reasonable to have
it in /etc.

>     (2) /etc/dropbear/log is a symlink pointing to /var/log/dropbear

If /etc/dropbear/log is a file controling the location of the log
files (and thus, controling the operation of the program), I don't see
the problem with the FHS.

> 1) Symlinks
>
>     I: Symlinks are "not real configuration files" as per FHS.

The FHS doesn't address this point at all; while it may be problematic
technically for VCS systems without support for symlinks, it's not
precluded by the FHS. [And given how many symlinks are in /etc, (on my
laptop, I cound 1430[2]), a VCS which can't handle it isn't going to
be particularly useful for managing /etc.]

> 2) Executables
>
>     I: Excutables should not apperar under "/etc/<package>" as per FHS.

The FHS precludes executable binaries from appearing under /etc, not
executables: "it must be static and cannot be an executable binary".[1]


Don Armstrong

1: http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCHOSTSPECIFICSYSTEMCONFIGURATION
2: $ sudo find /etc -type l|wc -l
1432
--
Physics is like sex. Sure, it may give some practical results, but
that's not why we do it.
 -- Richard Feynman

http://www.donarmstrong.com              http://rzlab.ucr.edu



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Debian Bug Tracking System]

Processing commands for control@...:

> reassign 545242 tech-ctte
Bug #545242 {Done: Gerrit Pape <pape@...>} [dropbear] dropbear: Please patch sources not to use /etc/dropbear/{log,run}
Bug reassigned from package 'dropbear' to 'tech-ctte'.
Bug No longer marked as found in versions dropbear/0.52-2.
> forcemerge 548230 545242
Bug#548230: dropbear: configuration in /etc/<package> does not follow FHS
Bug#545242: dropbear: Please patch sources not to use /etc/dropbear/{log,run}
Forcibly Merged 545242 548230.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Russ Allbery-2]

Don Armstrong <don@...> writes:
> On Thu, 24 Sep 2009, Jari Aalto wrote:

>>     The problems in the package were identified as follows:
>>
>>     (1) /etc/dropbear/run is an executable

> There's nothing wrong with having executables in /etc, so long as they
> are not binaries. /etc/dropbear/run is "a local file used to control
> the operation of a program",[1] so it's perfectly reasonable to have
> it in /etc.

>>     (2) /etc/dropbear/log is a symlink pointing to /var/log/dropbear

> If /etc/dropbear/log is a file controling the location of the log
> files (and thus, controling the operation of the program), I don't see
> the problem with the FHS.

I agree.  This type of configuration is the best way of handling software
run by daemontools or any of its variations that I think we've come up
with, and seems like a reasonable approach to me.  (Better, for instance,
than putting all of the configuration into /var.)

>> 1) Symlinks
>>
>>     I: Symlinks are "not real configuration files" as per FHS.

> The FHS doesn't address this point at all; while it may be problematic
> technically for VCS systems without support for symlinks, it's not
> precluded by the FHS. [And given how many symlinks are in /etc, (on my
> laptop, I cound 1430[2]), a VCS which can't handle it isn't going to be
> particularly useful for managing /etc.]

Yup.  There are *many* packages in the archive that use symlinks in /etc.

--
Russ Allbery (rra@...)               <http://www.eyrie.org/~eagle/>



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Don Armstrong]

tag 548230 moreinfo
thanks

Have Russ's and my comments on this bug made clear the rationale
behind why it doesn't appear to be an FHS violation?

Jari: if you no longer feel that it is an FHS violation, feel free to
reassign this bug back to dropbear and close it; otherwise we'll start
the process of coming to a decision.


Don Armstrong

--
"A one-question geek test. If you get the joke, you're a geek: Seen on
a California license plate on a VW Beetle: 'FEATURE'..."
 -- Joshua D. Wachs - Natural Intelligence, Inc.

http://www.donarmstrong.com              http://rzlab.ucr.edu



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Debian Bug Tracking System]

Processing commands for control@...:

> tag 548230 moreinfo
Bug #548230 [tech-ctte] dropbear: configuration in /etc/<package> does not follow FHS
Bug #545242 [tech-ctte] dropbear: Please patch sources not to use /etc/dropbear/{log,run}
Added tag(s) moreinfo.
Added tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Bdale Garbee]

On Thu, 2009-09-24 at 21:36 +0300, Jari Aalto wrote:

> CONCERNING
>
>     "dropbear: Please patch sources not to use /etc/dropbear/{log,run}"
>     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545242

Jari, it's not a big deal, but for something like this it might be
easier in the future if you re-assigned the existing bug to the
tech-ctte pseudo-package instead of creating a new bug number.

Gerrit, in reviewing the dropbear package source, I couldn't help but
wonder why /etc/dropbear/log/run specifies ./main as the log file?  That
motivates use of a symlink to point /etc/dropbear/log/main
to /var/log/dropbear.  Wouldn't it be simpler and cleaner to just
specify /var/log/dropbear as the last argument to svlogd in that script,
and thus avoid another level of useless indirection?

I don't immediately see any problem with the other files that are
delivered to /etc/dropbear from an FHS / Debian policy perspective.

Gerrit, in reviewing other instances of runit support, I do find some
inconsistency in where things are delivered.  The fact that dropbear is
delivering these files to /etc/dropbear but git-daemon-run
uses /etc/sv/git-daemon seems inconsistent to me, for example.  While
that's completely orthogonal to this request of the Tech Ctte, settling
on one approach might make it easier for others like me to read and
comprehend what's being delivered.

Bdale





--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Gerrit Pape-2]

On Tue, Sep 29, 2009 at 04:39:43PM -0600, Bdale Garbee wrote:
> Gerrit, in reviewing the dropbear package source, I couldn't help but
> wonder why /etc/dropbear/log/run specifies ./main as the log file?  That
> motivates use of a symlink to point /etc/dropbear/log/main
> to /var/log/dropbear.  Wouldn't it be simpler and cleaner to just
> specify /var/log/dropbear as the last argument to svlogd in that script,
> and thus avoid another level of useless indirection?

Yes, possibly.  But it's not completely useless, with the symlink in
log/, all service related data is consolidated in one directory.  With
runit and daemontools managed services, you can cd into the service
directory, and have all data you need conveniently available without
looking up where which data actually is saved in the filesystem.  You
have the service configuration in ./run (and possibly ./config or
similar), the log service configuration in ./log/run, the logs in
./log/main/, and optionally log specific configuration in
./log/main/config.  If that's consistent throughout all supervised
services, I personally find that useful.

> Gerrit, in reviewing other instances of runit support, I do find some
> inconsistency in where things are delivered.  The fact that dropbear is
> delivering these files to /etc/dropbear but git-daemon-run
> uses /etc/sv/git-daemon seems inconsistent to me, for example.  While
> that's completely orthogonal to this request of the Tech Ctte, settling
> on one approach might make it easier for others like me to read and
> comprehend what's being delivered.

True, you're right.  I did the dropbear package in 2004, and introduced
/etc/sv/ not before 2006.  I didn't move the directory because of two
reasons.  (1) moving conffiles was not trivial (in the meantime I have
code in some packages that do that), (2) the dropbear package ships
both, a sysv init script and a runit service directory.  sysv users
look for the configuration in /etc/dropbear/, and runit users in
/etc/sv/dropbear/.  /etc/dropbear/ holds the host keys which are used
by both service startup methods.  I'm not sure whether a symlink
/etc/sv/dropbear -> /etc/dropbear would help, or rather complicate
things again.

Regards, Gerrit.


--
To UNSUBSCRIBE, email to debian-ctte-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...