unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
* bug#19795: Allow for stateless users and groups in GuixSD
@ 2015-02-06 17:13 Thompson, David
  2015-02-06 17:24 ` Alex Sassmannshausen
  2015-02-07  9:10 ` Andreas Enge
  0 siblings, 2 replies; 6+ messages in thread
From: Thompson, David @ 2015-02-06 17:13 UTC (permalink / raw)
  To: 19795

Currently, removing a user account from the users list in an OS config
does not remove the user account from a system when 'guix system
reconfigure' is run.  I think that user accounts not specified in the
user accounts list should be invalidated and that /etc/passwd and
other files be fully rebuilt each time.  In other words, I want a
stateless /etc/passwd, not a stateful one.

As Mark brought up on IRC, this proposed change in behavior may very
well surprise and frustrate another subset of users, so perhaps the
existing behavior should be preserved, with a bit that can be flipped
for stateless user accounts.

Thoughts?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#19795: Allow for stateless users and groups in GuixSD
  2015-02-06 17:13 bug#19795: Allow for stateless users and groups in GuixSD Thompson, David
@ 2015-02-06 17:24 ` Alex Sassmannshausen
  2015-02-07  9:10 ` Andreas Enge
  1 sibling, 0 replies; 6+ messages in thread
From: Alex Sassmannshausen @ 2015-02-06 17:24 UTC (permalink / raw)
  To: Thompson, David; +Cc: 19795

Hello,

My 2c:

In short +1!

Thompson, David writes:

> Currently, removing a user account from the users list in an OS config
> does not remove the user account from a system when 'guix system
> reconfigure' is run.  I think that user accounts not specified in the
> user accounts list should be invalidated and that /etc/passwd and
> other files be fully rebuilt each time.  In other words, I want a
> stateless /etc/passwd, not a stateful one.

I would love this functionality: it feels intuitive for a functional
package manager.

> As Mark brought up on IRC, this proposed change in behavior may very
> well surprise and frustrate another subset of users, so perhaps the
> existing behavior should be preserved, with a bit that can be flipped
> for stateless user accounts.

I agree that perhaps statefulness should be the default for now, as that
seems the "common way to do things".

Alex

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#19795: Allow for stateless users and groups in GuixSD
  2015-02-06 17:13 bug#19795: Allow for stateless users and groups in GuixSD Thompson, David
  2015-02-06 17:24 ` Alex Sassmannshausen
@ 2015-02-07  9:10 ` Andreas Enge
  2015-02-08  3:07   ` Mark H Weaver
  1 sibling, 1 reply; 6+ messages in thread
From: Andreas Enge @ 2015-02-07  9:10 UTC (permalink / raw)
  To: Thompson, David; +Cc: 19795

Hello,

I agree, it is rather surprising that removing a user does not remove it.
So I think it should be fully stateless (as long as the user's home
directory is not erased, of course; so this should remain as a state and
be reactivated once the user is available again, which could cause problems
with user names vs. numbers).

Andreas

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#19795: Allow for stateless users and groups in GuixSD
  2015-02-07  9:10 ` Andreas Enge
@ 2015-02-08  3:07   ` Mark H Weaver
  2015-02-08 14:32     ` Ludovic Courtès
  0 siblings, 1 reply; 6+ messages in thread
From: Mark H Weaver @ 2015-02-08  3:07 UTC (permalink / raw)
  To: Andreas Enge; +Cc: 19795

Andreas Enge <andreas@enge.fr> writes:

> I agree, it is rather surprising that removing a user does not remove it.
> So I think it should be fully stateless (as long as the user's home
> directory is not erased, of course; so this should remain as a state and
> be reactivated once the user is available again, which could cause problems
> with user names vs. numbers).

If we do this, I think we should take steps to prevent users+groups from
being added, removed, group memberships changed, setting of passwords,
etc, outside of 'guix system reconfigure'.  I think that users will be
very unhappy with us if commands like 'passwd' and 'useradd' work as
expected, but are undone the next time they update their system.

My position is that we should support both stateful or stateless
operation for some aspects of our configuration.

For example, consider wireless network configuration.  Most casual users
want this to be stateful.  They will want to be able to use a nice GUI
applet to connect to a wireless network, and have the system remember
the authentication info and to connect to that network automatically in
the future, etc.  I don't want GuixSD to forget that information the
next time I update, or if I roll-back, etc.

However, for some applications it may be preferable to have the wireless
configuration completely stateless and specified in the OS config,
e.g. for a headless server that's connected via wireless.

I think it's the same way with users+groups.  For my personal system, I
might want to be able to add a user without updating its software at the
same time (which might involve a lot of downloading and/or compiling),
and I don't want the new user to be erased if I roll-back.

Even for many kinds of servers, I don't think it makes sense to tie the
users+groups to the system configuration.  Most of the time I don't want
that.  But for some other kinds of servers, I think I would want it.

So, I think we should support both modes.

My two cents...

     Mark

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#19795: Allow for stateless users and groups in GuixSD
  2015-02-08  3:07   ` Mark H Weaver
@ 2015-02-08 14:32     ` Ludovic Courtès
  2015-04-08 19:43       ` Ludovic Courtès
  0 siblings, 1 reply; 6+ messages in thread
From: Ludovic Courtès @ 2015-02-08 14:32 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: 19795

Mark H Weaver <mhw@netris.org> skribis:

> If we do this, I think we should take steps to prevent users+groups from
> being added, removed, group memberships changed, setting of passwords,
> etc, outside of 'guix system reconfigure'.  I think that users will be
> very unhappy with us if commands like 'passwd' and 'useradd' work as
> expected, but are undone the next time they update their system.

Just to be clear about the current situation: everything is stateless,
with the exception of passwords (‘reconfigure’ does not alter them) and
user accounts that are not removed (the crux of this report.)

Apart from passwords, any modification is undoed on the next
‘reconfigure’ or on the next reboot.  See notably e2b464b7, which took a
step to ensure that user account settings in the OS declaration are
fully honored.

In response to this bug report, I would just add activation code that
removes any unknown user accounts.

Thanks,
Ludo’.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#19795: Allow for stateless users and groups in GuixSD
  2015-02-08 14:32     ` Ludovic Courtès
@ 2015-04-08 19:43       ` Ludovic Courtès
  0 siblings, 0 replies; 6+ messages in thread
From: Ludovic Courtès @ 2015-04-08 19:43 UTC (permalink / raw)
  To: Mark H Weaver; +Cc: 19795-done

ludo@gnu.org (Ludovic Courtès) skribis:

> In response to this bug report, I would just add activation code that
> removes any unknown user accounts.

Commit 9bea87a does that.

Let me know if it wipes all your user accounts or anything!  :-)

(Seriously though, I’ve run it on my machine and everything is fine.)

Ludo’.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2015-04-08 19:45 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-06 17:13 bug#19795: Allow for stateless users and groups in GuixSD Thompson, David
2015-02-06 17:24 ` Alex Sassmannshausen
2015-02-07  9:10 ` Andreas Enge
2015-02-08  3:07   ` Mark H Weaver
2015-02-08 14:32     ` Ludovic Courtès
2015-04-08 19:43       ` Ludovic Courtès

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).