Re: Customizing /etc

[Alex Kost <alezost@gmail.com>]

Ludovic Courtès (2015-11-27 17:58 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
[...]
>> I like the idea of separating /etc/environment and /etc/profile, but my
>> main concern is to have a possibility to change /etc files the way I
>> want, as I explained in the reply to Ludovic.
>
> I agree that specifying what goes into /etc is something we want to
> allow (though not directly related to the /etc/profile issue.)

Oof, that's a relief for me!  I had an impression that you are against
giving a user a full control over /etc files.

> What about exposing the name/file-like pairs that are passed to
> ‘etc-service’?  That way, one could write:
>
>   (define os
>     (operating-system
>       ;; …
>       (etc-files `(("hosts" ,(local-file "my-hosts-file"))
>                    ("issue" ,(plain-file "Hello!\n"))
>                    ("sudoers" ,(local-file "sudoers"))
>                    ("profile" ,(local-file "myprofile"))
>                    ,@(fold alist-delete
>                            (default-etc-files os)
>                            '("hosts" "issue" "sudoers" "profile"))))))

Yes, changing /etc files is exactly what I want!

> We may remove the ‘hosts-file’ and ‘sudoers-file’ fields, but keep
> higher-level things like ‘name-service-switch’ because they’re more
> convenient.

Yes, I agree; if this will be accepted, keeping '<foo>-file' fields (for
hosts, sudoers and future files) is probably not needed.

> The difficulty is that some of the default files, such as /etc/hosts,
> are generated as a function of the ‘operating-system’ declaration.  Thus
> I think we need ‘default-etc-files’ to be a procedure as shown above,
> and the ‘etc-files’ field must be thunked or delayed.  Hmm not fully
> sure this is the right interface.
>
> WDYT?

Yes, this will probably not be an easy-to-use interface, but to have it
is better than to have nothing.  So I am totally for it!

> The bottom line is that /etc is not a great configuration interface
> because it’s all flat and GuixSD has no idea of the meaning of those
> files and their relationship.  So the preferred approach remains
> configuration via services and high-level configuration objects.

Yes, I agree; but if a user is not satisfied by the result of these
high-level services, I think (s)he should have a fallback way to
change/override the resulting /etc file.

-- 
Alex