On Friday 26 October 2007, Dan Farrell wrote:
> On Fri, 26 Oct 2007 09:55:04 +0200
>
> Etaoin Shrdlu <[EMAIL PROTECTED]> wrote:
> > On Friday 26 October 2007, Dan Farrell wrote:
> > > On Thu, 25 Oct 2007 13:55:45 +0200
> > >
> > > Etaoin Shrdlu <[EMAIL PROTECTED]> wrote:
> > > > Why can't you speci
On Fri, 26 Oct 2007 09:55:04 +0200
Etaoin Shrdlu <[EMAIL PROTECTED]> wrote:
> On Friday 26 October 2007, Dan Farrell wrote:
>
> > On Thu, 25 Oct 2007 13:55:45 +0200
> >
> > Etaoin Shrdlu <[EMAIL PROTECTED]> wrote:
> > > Why can't you specify the "-g users" when running useradd?
> > > --
> >
> > g
On Friday 26 October 2007, Dan Farrell wrote:
> On Thu, 25 Oct 2007 13:55:45 +0200
>
> Etaoin Shrdlu <[EMAIL PROTECTED]> wrote:
> > Why can't you specify the "-g users" when running useradd?
> > --
>
> guess: scripted?
And scripts can be changed, can't they?
--
[EMAIL PROTECTED] mailing list
On Thu, 25 Oct 2007 13:55:45 +0200
Etaoin Shrdlu <[EMAIL PROTECTED]> wrote:
> Why can't you specify the "-g users" when running useradd?
> --
guess: scripted?
--
[EMAIL PROTECTED] mailing list
On Fri, 2007-10-26 at 00:02 +0200, Florian Philipp wrote:
> I'm wondering what's the advantage of using a special group for each
> user. Doesn't it just make user administration more complicated?
It's explained here http://tinyurl.com/4bn9h
Basically it aids in the sharing of files/directories
Albert Hopkins schrieb:
On Thu, 2007-10-25 at 14:35 +0300, Daniel Iliev wrote:
Hi, ppl
I have the habit of imposing some limitations over all users via
/etc/security/limits.conf. For example I used to limit the number of
concurrent processes one can execute to prevent the system from simple
m
On Thu, 25 Oct 2007 06:45:49 -0500
Albert Hopkins <[EMAIL PROTECTED]> wrote:
> >
> > Now that the behaviour of "useradd -m xyz" has changed from putting
> > the newuser in group "users" ("xyz:users") to putting the user in a
> > group with same name ("xyz:xyz") I would appreciate any advice on
>
On Thursday 25 October 2007, Etaoin Shrdlu wrote:
> After a little search, it seems that the USERGROUPS_ENAB directive
> in /etc/login.defs, although not explicitly mentioning this issue, is
> the culprit. Setting it to "no" restores the old behavior (putting the
> new users into group "users").
On Thu, 25 Oct 2007 06:45:49 -0500
Albert Hopkins <[EMAIL PROTECTED]> wrote:
> >
> > Now that the behaviour of "useradd -m xyz" has changed from putting
> > the newuser in group "users" ("xyz:users") to putting the user in a
> > group with same name ("xyz:xyz") I would appreciate any advice on
>
On Thursday 25 October 2007, Albert Hopkins wrote:
> Oh do they do that now? That was that nasty Red Hat extension.
While one might agree or disagree about that, IMHO the problem now is
that the options in /etc/default/useradd are ignored. If I run
useradd -D it shows GROUP=100, but running us
Am Donnerstag, 25. Oktober 2007 schrieb ext Daniel Iliev:
> Now that the behaviour of "useradd -m xyz" has changed from putting the
> newuser in group "users" ("xyz:users") to putting the user in a group
> with same name ("xyz:xyz") I would appreciate any advice on getting the
> old behavior back o
On Thursday 25 October 2007, Daniel Iliev wrote:
> Now that the behaviour of "useradd -m xyz" has changed from putting
> the newuser in group "users" ("xyz:users") to putting the user in a
> group with same name ("xyz:xyz") I would appreciate any advice on
> getting the old behavior back or any wo
On Thu, 2007-10-25 at 14:35 +0300, Daniel Iliev wrote:
> Hi, ppl
>
> I have the habit of imposing some limitations over all users via
> /etc/security/limits.conf. For example I used to limit the number of
> concurrent processes one can execute to prevent the system from simple
> misuses like for
Hi, ppl
I have the habit of imposing some limitations over all users via
/etc/security/limits.conf. For example I used to limit the number of
concurrent processes one can execute to prevent the system from simple
misuses like fork bombs by putting a limit (nproc) for group "users"
and all other c
14 matches
Mail list logo