unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: Andreas Enge <andreas@enge.fr>
Cc: 19795@debbugs.gnu.org
Subject: bug#19795: Allow for stateless users and groups in GuixSD
Date: Sat, 07 Feb 2015 22:07:59 -0500	[thread overview]
Message-ID: <87iofd14og.fsf@netris.org> (raw)
In-Reply-To: <20150207091023.GA12524@debian> (Andreas Enge's message of "Sat, 7 Feb 2015 10:10:23 +0100")

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

  reply	other threads:[~2015-02-08  3:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2015-02-08 14:32     ` Ludovic Courtès
2015-04-08 19:43       ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87iofd14og.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=19795@debbugs.gnu.org \
    --cc=andreas@enge.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).