[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: user/group -- compromise proposal -- __DOCUMENTATION__

I'm going to beat a large bass drum about __DOCUMENTATION__ a bit here.


iwj10@cus.cam.ac.uk (Ian Jackson) said:

> [...]
> Turning it on by default solves this problem.

And it needs to be turned on in such a way that it's straightforward
to find out what default was chosen and what needs to be done to change
it later.  This has been mostly bypassed in past discussion with remarks
like "that's easily handled in a FAQ".  I don't think that's sufficient.

Even if an FAQ is sufficient, this doesn't become a non-issue until the
FAQ with this item sufficiently covered is part of the distribution.

I'd say that if debian is going to present special admin issues which
are not covered in the Linux SAG, then the debian project needs to produce
an addendum or appendix to the Linux SAG which covers those issues in the
same depth and with the same quality of presentation as the Linux SAG.

> A way to turn private group creation off and on globally would be very
> useful, of course - I don't imagine that many systems would want a
> half hearted scheme.
> That would probably go a long way to keeping both sides happy - even
> the side that doesn't get their way on the default.
> Incidentally, while we're on the subject of adduser, a place to
> configure the default location of home directories would be nice (and
> a bit more interaction on the part of adduser before it goes and does
> it's stuff).

All of this stuff falls into the category of what I was talking about above.
If we're going to twiddle this and twiddle that and create special admin
issues here and and special user issues there there, we need to be thinking
about documenting all this.

No, strike that.  We need to be documenting it as we are implementing it,
not thinking about documenting it; and we should not be releasing it with 
the special issues in it unless it is accompanied by documentation of the 
special issues.


Any nontraditional umask usage needs to be prominently documented.  This
goes beyond the SAG, it's something that'll need to be documented clearly
at the user level.  This probably means a debian addendum to the Linux
Installation and Getting Started document.  Hmmmmm..... that document includes
sections on
  1) Introduction to Linux
  2) Obtaining and Installing Linux
  3) Linux Tutorial
  4) System Administration
  5) Advanced Features 
I haven't looked at a copy of this document lately but, from the section
titles, it seems like there might be debian-specific issues in section 2
in any case, and issues specific to this user/group (or whatever this week's
politically correct nomenclature for it is) proposal in sections 3 and/or 4.

> Starting user UIDs at 1000 is indeed a good idea.  Also, Paul Vojta's
> comments on the desirable behaviour of adduser under certain
> conditions are well considered (labelled C' in his message.)

And if we're going to start UIDs at 1000 (or whatever) we need to explain
why we did that, explain it well, and and explain it prominently.  This
probably means explaing why in a debian SAG addendum, _and_ in a note on the
adduser manpage, _and_ (if adduser is a script -- I don't have a debian system
handy to look at) in comments inside the adduser script.


I know, it's easy to pass this off with a "that's just a documentation issue",
and presume that it'll be dealt with later.  I'm concerned that anything which
is regarded as _just_ a documentation issue, and OK to put off until later
simple because it's _just_ a documentation issue, might never get dealt with
properly (or at all).

I'm getting the feeling that it's likely debian will implement something
in this area in 0.92.  If so, debian 0.92 should include at least half-assed
documentation of what's been done, of the effects it'll have on sysadmin, and
of the effects it'll have on Joe User (who won't care) and Jane User (who
will find it useful once she understands it and understands how to take
advantage of it).

Before debian goes into general non-beta release, the documentation needs
to be better than half-assed.  That means getting a documentation project
going -- probably in close cooperation with the individuals producing
general Linux documentation.

-- (Returns large bass drum to storage) --

Reply to: