[Nix-dev] [PATCH] authorized_keys in users.extraUsers

[Nicolas Pierron]

Hi Rickard,

On Sun, Oct 23, 2011 at 14:56, Rickard Nilsson
<rickard.nilsson at telia.com> wrote:
> On Thu, 20 Oct 2011 16:51:04 +0200, Nicolas Pierron
> <nicolas.b.pierron at gmail.com> wrote:
>>
>> Hi Rickard,
>>
>> On Thu, Oct 20, 2011 at 00:11, Rickard Nilsson
>> <rickard.nilsson at telia.com> wrote:
>>>
>>> Hi Nicolas,
>>>
>>> Den 2011-10-19 01:21:02 skrev Nicolas Pierron
>>> <nicolas.b.pierron at gmail.com>:
>>>
>>>> Hi Rickard,
>>>>
>>>> On Tue, Oct 18, 2011 at 00:40, Rickard Nilsson
>>>> <rickard.nilsson at telia.com> wrote:
>>>>
>>>> This is the way to proceed, may be the error messages are not
>>>> extremelly explicit about the corner cases.  Not many users end-up
>>>> working with such (nice) features of the NixOS module system.  I am
>>>> happy to see that you are going into the right way with a few examples
>>>> :)
>>>>
>>>>>   users = mkOption {
>>>>>     default = {};
>>>>>     description = ''
>>>>>     '';
>>>>>     type = types.loaOf types.optionSet;
>>>>>     options = [ usersOptions ];
>>>>>   };
>>>>>
>>>>> However, this made Nix complain about types. If I renamed "users" to
>>>>> something that isn't already defined it worked fine though.
>>>>
>>>> You should not redefine the type, default and the description.  Such
>>>> things are only accepted once per option declarations.
>>>>
>>>> The following should work, any changes of the type should be done in
>>>> the original declaration.
>>>>
>>>>   users = mkOption {
>>>>     options = [ usersOptions ];
>>>>   };
>>>
>>> I see, that makes sense. Thinking about it, I probably can't put the
>>> configuration in users.<name?>.xx anyway, since it will collide with
>>> a lot of other stuff (like users.ldap.xx for example). Would it make
>>> sense to put it in user.<name?>.openssh.xx instead?
>>> Or is "user" and "users" too easy to mix up?
>>
>> Oh, my fault.  What I meant was
>>
>> users.extraUsers.<name?>.openssh.authorizedKeys ;)
>>
>> You will need to add a type to the extraUsers option, and use listOf
>> in your first essay ;)
>> listOf is bad and would be deprecated for optionSet, so I will try to
>> make a fork of loaOf where is name is extracted from the attribute set
>> ;)
>
> Hmm, the type of users.extraUsers is a list of attribute sets today. Do you
> mean I should rewrite it into something like this:
>
>  users.extraUsers.myuser = {
>    name = "myuser";
>    extraGroups = [];
>    home = "/home/myuser";
>    .
>    .
>    .
>    openssh.authorizedKeys = [];
>  }
>
> I can try to do that, but I guess there is a lot of stuff that uses
> "users.extraUsers = [ {...} {...} ... ]" today which would need to be
> rewritten. Or is it possible to support both ways?

Yes, this is the reason why I introduced loaOf type (List Or Attribute
Of ...).  To be able to migrate from "foo.*.bar" to "foo.<name>.bar".
The notation of loaOf options is "foo.<name?>.bar".
Later I will deprecate listOf option for attributeSet and optionSet.

The reason is that listOf is not modular enough.  In your case for
example, a user may want to have a separated module for indexing the
authorized keys for a bunch of users across multiple machines while
being able to set a different extra groups on each machine.  This
cannot be achieved with listOf.

> Or has I simply misunderstood you again?
>
> For the moment, I have a working implementation of user.<name?>.openssh.*,
> this should not be too hard to rewrite into something else.

Great.

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/