sbin or bin?

[Keith Rarick]

Serafeim Zanikolas is packaging beanstalkd for Debian, and he's
suggested that beanstalkd should go in sbin, because it's a system
program rather than an end-user program. I tend to think of beanstalkd
as an end-user program.

With his permission, I'm forwarding our conversation here.

Sreafeim Zanikolas wrote:
> > > binary in /usr/sbin (not /usr/bin) as it's a system program.
> >
> > That's an interesting point. I've never thought of beanstalkd as a
> > system program. Although it's a daemon, it isn't part of the OS. It is
> > a tool that people use to help them build applications.
> >
> > It would be essentially impossible to run beanstalkd as a system
> > service shared between all users -- they would wind up stepping all
> > over each other. Usually, each user runs her own instance of
> > beanstalkd.
> >
> > But I haven't actually thought about this very much. With a good
> > argument I could be persuaded otherwise.
>
> According to the FHS, /usr/bin is for user commands whereas /usr/sbin for
> system commands. IMHO any deamon (that's not related to desktop or end user
> stuff) is clearly a system command. But maybe that's just me :)

What is the right thing to do?

kr

[Jeremy Hinegardner]

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

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. Programs executed after /usr is known
to be mounted (when there are no problems) are generally placed into
/usr/sbin. Locally-installed system administration programs should be placed
into /usr/local/sbin.

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

[19] Deciding what things go into "sbin" directories is simple: if a normal
(not a system administrator) user will ever run it directly, then it must be
placed in one of the "bin" directories. Ordinary users should not have to
place any of the sbin directories in their path.

For example, files such as chfn which users only occasionally use must still
be placed in /usr/bin. ping, although it is absolutely necessary for root
(network recovery and diagnosis) is often used by users and must live in
/bin for that reason.

We recommend that users have read and execute permission for everything in
/sbin except, perhaps, certain setuid and setgid programs. The division
between /bin and /sbin was not created for security reasons or to prevent
users from seeing the operating system, but to provide a good partition
between binaries that everyone uses and ones that are primarily used for
administration tasks. There is no inherent security advantage in making
/sbin off-limits for users.

To me this does not apply to beanstalkd since it is not used for system
administration and will often be executed by users, it is NOT root-only.
That is I used for deciding that beanstalkd should go in /usr/bin for
Fedora and EPEL.

enjoy,

-jeremy

--
========================================================================
Jeremy Hinegardner jer...@hinegardner.org

[Jaume Sabater]

On Wed, Nov 25, 2009 at 2:10 AM, Jeremy Hinegardner
<jer...@hinegardner.org> wrote:

> To me this does not apply to beanstalkd since it is not used for system
> administration and will often be executed by users, it is NOT root-only.
> That is I used for deciding that beanstalkd should go in /usr/bin for
> Fedora and EPEL.

*agrees* IMHO, it should go to /bin.

--
Jaume Sabater
http://linuxsilo.net/

"Ubi sapientas ibi libertas"

[Al-Faisal El-Dajani]

I agree with the above mentioned argument by Jeremy.

--

You received this message because you are subscribed to the Google Groups "beanstalk-talk" group.
To post to this group, send email to beansta...@googlegroups.com.
To unsubscribe from this group, send email to beanstalk-tal...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en.

--
Al-Faisal El-Dajani
10/6

[Jaume Sabater]

On Wed, Nov 25, 2009 at 9:44 AM, Al-Faisal El-Dajani
<faisal...@gmail.com> wrote:

> I agree with the above mentioned argument by Jeremy.

On the other hand, I was thinking, what about /usr/bin/ and /usr/sbin?
Just checked apache2, postgresql-8.4 and other packages and, suddenly,
I don't feel so sure about what I said before. After all, any user is
meant to be able to run its own beanstalkd process in a non-privileged
port, isn't he/she?

[Andreas Bolka]

On Wed Nov 25 01:28:05 +0100 2009, Keith Rarick wrote:
> What is the right thing to do?

+1 for /usr/bin.

Unless beanstalkd ever gains multi-user facilities, putting it in
/usr/sbin is basically wrong, as it simply is no system binary and is
_not_ intended to be used as system-wide service daemon.

Two other programs with similar characteristics that come to mind are nc
and stunnel, both in /usr/bin, both allowing users to set up ad-hoc
network services (amongst other things).

--
Regards,
Andreas

[Ryan C. Payne]

I concur. /usr/bin seems to feel the most correct to me as well.

--sent from the iPhone

On Nov 25, 2009, at 11:24 AM, Andreas Bolka <andrea...@gmx.net>
wrote:

[Serafeim Zanikolas]

Hi all,

It seems to be a borderline case between /usr/bin and /usr/sbin but here goes
anyway.

It's been pointed that the FHS recommends that if an ordinary user needs to
run the command, then it should be placed in /usr/bin. So the answer then
depends on what is an ordinary user. To me, a user that starts up the queueing
facilities of whatever application is not an ordinary one (regardless of what
account is actually used, that user has either a sysadmin, a dev or a devop
role).

On Wed, Nov 25, 2009 at 05:24:33PM +0100, Andreas Bolka wrote:
> On Wed Nov 25 01:28:05 +0100 2009, Keith Rarick wrote:
> > What is the right thing to do?
>
> +1 for /usr/bin.
>
> Unless beanstalkd ever gains multi-user facilities, putting it in
> /usr/sbin is basically wrong, as it simply is no system binary and is
> _not_ intended to be used as system-wide service daemon.

The upstream tarball comes with a sysv init script that assumes that there is
a single instance per host (it uses a lock file). Sure, one may want to run
several instances in a single host but that doesn't make the program less of a
service. The fact that I can run several httpds as an ordinary user in
unprivileged ports doesn't make the httpd an end user program. Whether a
beanstalkd instance is used system-wide is a matter of choice.

> Two other programs with similar characteristics that come to mind are nc
> and stunnel, both in /usr/bin, both allowing users to set up ad-hoc
> network services (amongst other things).

They're not comparable: nc and stunell operate at the transport level (ie. are
application-unaware) whereas beanstalkd requires clients to talk its protocol

Cheers,
Serafeim

--
debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp

[Keith Rarick]

On Wed, Nov 25, 2009 at 3:25 PM, Serafeim Zanikolas <ser...@hellug.gr> wrote:
> It's been pointed that the FHS recommends that if an ordinary user needs to
> run the command, then it should be placed in /usr/bin. So the answer then
> depends on what is an ordinary user. To me, a user that starts up the queueing
> facilities of whatever application is not an ordinary one (regardless of what
> account is actually used, that user has either a sysadmin, a dev or a devop
> role).

The FHS provides a definition of this, too: "if a normal (not a system

administrator) user will ever run it directly, then it must be placed

in one of the "bin" directories". A developer is not a system
administrator, and so is a "normal" user for our purposes. This means
beanstalkd must be placed in a "bin" directory.

If there is any doubt left, we can just ask: "Hey, all you
non-system-admins out there! Do any of you run the 'beanstalkd'
command?"

On a more practical note, it seems likely that plenty of our users
will become frustrated if we move beanstalkd into sbin. Let's be nice
to them and avoid that. :)

kr

[Andreas Bolka]

On Thu Nov 26 00:25:40 +0100 2009, Serafeim Zanikolas wrote:
> On Wed, Nov 25, 2009 at 05:24:33PM +0100, Andreas Bolka wrote:
> > On Wed Nov 25 01:28:05 +0100 2009, Keith Rarick wrote:
> > > What is the right thing to do?
> >
> > +1 for /usr/bin.
> >
> > Unless beanstalkd ever gains multi-user facilities, putting it in
> > /usr/sbin is basically wrong, as it simply is no system binary and is
> > _not_ intended to be used as system-wide service daemon.
>
> The upstream tarball comes with a sysv init script that assumes that there is
> a single instance per host (it uses a lock file).

Ah, I forgot about the init script.

> Whether a beanstalkd instance is used system-wide is a matter of
> choice.

I guess it then boils down to how you are about to package beanstalkd
and for what target audience.

If the package intends to mainly install beanstalkd as a system service
(maybe with a sane default to listen only on the local interface), then
/usr/sbin is certainly the correct place for the binary.

If the package is intended to quickly make the binary and manpage
available to discerning developers, then go with /usr/bin.

--
Andreas

[Serafeim Zanikolas]

On Thu, Nov 26, 2009 at 03:10:29AM +0100, Andreas Bolka wrote:
> I guess it then boils down to how you are about to package beanstalkd
> and for what target audience.

I'm packaging beanstalkd to satisfy a dependency of flapjack, a service
monitoring framework (think nagios). So the primary use case is indirect users
of beanstalkd, not devs.

> If the package intends to mainly install beanstalkd as a system service
> (maybe with a sane default to listen only on the local interface), then
> /usr/sbin is certainly the correct place for the binary.

That's precisely the idea.

[Keith Rarick]

On Fri, Nov 27, 2009 at 10:35 AM, Serafeim Zanikolas <ser...@hellug.gr> wrote:
> On Thu, Nov 26, 2009 at 03:10:29AM +0100, Andreas Bolka wrote:
>> I guess it then boils down to how you are about to package beanstalkd
>> and for what target audience.
>
> I'm packaging beanstalkd to satisfy a dependency of flapjack, a service
> monitoring framework (think nagios). So the primary use case is indirect users
> of beanstalkd, not devs.

The FHS seems pretty clear about this. The "primary" use case doesn't
matter; we only care whether any normal users will want to run
beanstalkd. By analogy, ping is primarily for admins to diagnose
network problems, but it goes in bin because normal users run it too.

Having said all that, I won't argue any more if you still want to
package it in sbin, but I think beanstalkd's own makefile should stick
with bin.

kr