Re: _<service> users [Was: startup error for pflogd]

From: Garance A Drosihn <drosih_at_rpi.edu>
Date: Mon, 21 Jun 2004 20:43:00 -0400
At 1:56 AM +0200 6/22/04, Max Laier wrote:
>On Monday 21 June 2004 18:46, David O'Brien wrote:
>  > On Mon, Jun 21, 2004 at 04:39:10PM +0200, Max Laier wrote:
>  > >
>  > > If there is no resistance against "yet another user", I will
>  > > add _pflogd.
>  >
>  > I would prefer just 'pflogd' until it is discussed if we want to
>  > follow the _<service> way.
>
>Okay, let's talk about this then: Any strong optionions one way
>or the other?
>
>There is no technical argument (to my knowledge) that suggests
>either. My vote is for "_<service>" to keep the diff down, but
>that is not an argument of course. Others have said that it:
>  - helps to recognize system processes
>  - helps to see "bad things" happening (1000 _pflogd is not a
>    good sign)
>  - resolves possible namespace problems

I like _pflogd

I think it can be _pflogd even if we do not explicitly decide to
use _<service> for usernames added by other services.  To claim
otherwise is like saying you can't end the username in 'd' unless
we decide that 'd' should be the last letter for userids added
for all future service names.  "_" is legal as the first letter
in a userid.  You should not need to get permission to use any
legal letter in a userid that you want the system to add.

Whether we DO decide to use _<service> for future services is
perhaps worth debating.  It sounds like a good idea to me, if
for no other reason than to avoid namespace problems.  However
I do not think we should require it.  The wish to "keep the diff
down" would be just as valid when importing some other package
as it is here for adding _pflogd.

-- 
Garance Alistair Drosehn            =   gad_at_gilead.netel.rpi.edu
Senior Systems Programmer           or  gad_at_freebsd.org
Rensselaer Polytechnic Institute    or  drosih_at_rpi.edu
Received on Mon Jun 21 2004 - 22:43:02 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:58 UTC