Re: Customizing /etc

[Alex Kost]

Ludovic Courtès (2017-05-17 10:28 +0200) wrote:

> Hi Alex,
>
> Alex Kost  skribis:
>
>> This is almost the same message as:
>>
>>   http://lists.gnu.org/archive/html/guix-devel/2016-09/msg01570.html
>>
>> I mean this is a reminder on the subject.
>
> Yes, I haven’t forgotten about it, contrary to what one might think.
> ;-)

Oh, great!  (you're right, that's what I thought :-))

>> Ludovic, I think you suggested a good solution to a "Customizing
>> /etc/profile" problem.  Since I will no longer be a blocker of
>> <http://bugs.gnu.org/20255> after this fix, would you like to commit
>> that change, or are there any issues with that?
>
> In the message you cite above, I proposed to hack etc-service-type in
> the same way we did for PAM.
>
> But then I think we’d better have the generic solution in place (where
> any service could be extended “at the end”, i.e., after it’s ‘compose’
> and ‘extend’ procedures have been called) before people start relying on
> the hack.  I even started working on it long ago, and then moved on to
> something else.

Wow, a general solution for any service sounds really great!

> I’m sorry that this has not happened yet.  I hope to resume work on it
> after the release, but if someone wants to give it a shot, I will
> definitely not block it.

I see :-)  No hurry, I just was a bit concerned that your solution was
lost, but now I know that it's not, thanks!

-- 
Alex

Re: Customizing /etc

[Ludovic Courtès]

Hi Alex,

Alex Kost  skribis:

> This is almost the same message as:
>
>   http://lists.gnu.org/archive/html/guix-devel/2016-09/msg01570.html
>
> I mean this is a reminder on the subject.

Yes, I haven’t forgotten about it, contrary to what one might think.
;-)

> Ludovic, I think you suggested a good solution to a "Customizing
> /etc/profile" problem.  Since I will no longer be a blocker of
> <http://bugs.gnu.org/20255> after this fix, would you like to commit
> that change, or are there any issues with that?

In the message you cite above, I proposed to hack etc-service-type in
the same way we did for PAM.

But then I think we’d better have the generic solution in place (where
any service could be extended “at the end”, i.e., after it’s ‘compose’
and ‘extend’ procedures have been called) before people start relying on
the hack.  I even started working on it long ago, and then moved on to
something else.

I’m sorry that this has not happened yet.  I hope to resume work on it
after the release, but if someone wants to give it a shot, I will
definitely not block it.

Thanks,
Ludo’.

Customizing /etc

[Alex Kost]

This is almost the same message as:

  http://lists.gnu.org/archive/html/guix-devel/2016-09/msg01570.html

I mean this is a reminder on the subject.

Ludovic, I think you suggested a good solution to a "Customizing
/etc/profile" problem.  Since I will no longer be a blocker of
<http://bugs.gnu.org/20255> after this fix, would you like to commit
that change, or are there any issues with that?

-- 
Thanks,
Alex

Re: Customizing /etc

[Alex Kost]

Ludovic Courtès (2016-09-19 23:08 +0900) wrote:

> Alex Kost  skribis:
>
>> Ludovic Courtès (2016-09-14 16:58 +0200) wrote:
[...]
>>> However, we failed to build consensus around the approach of this patch,
>>> so we did not apply it.  If you have ideas, please email
>>> 20...@debbugs.gnu.org.  :-)
>>
>> I think I was the one who prevents the consensus.  To make it clear, I'm
>> for the suggested solution, but only *after* giving a user a freedom to
>> avoid loading such a heavy command as "guix package --search-paths".  On
>> a "usual" GNU/Linux distro a user can edit /etc/profile, but on GuixSD
>> it is not possible currently.  That's why I think there should be
>> provided a possibility to override /etc/profile at first.
>
> Indeed, thanks for the reminder!
>
> In fact, we have this through ‘etc-service-type’, except that currently
> /etc/profile is systematically added.
>
> So an idea that comes to mind is to allow ‘etc-service-type’ to be
> extended with procedures that would be able to filter or otherwise
> change the /etc entries (similar to what we do for PAM):
>
> diff --git a/gnu/services.scm b/gnu/services.scm
> index 7e322c5..9397232 100644
> --- a/gnu/services.scm
> +++ b/gnu/services.scm
> @@ -426,9 +426,13 @@ directory."
>  (extensions
>   (list
>(service-extension activation-service-type
> - (lambda (files)
> -   (let ((etc
> -  (files->etc-directory files)))
> + (lambda (files+procs)
> +   (let* ((proc (apply compose
> +   (filter procedure?
> +   
> files+procs)))
> +  (files (filter pair? 
> files+procs))
> +  (etc
> +   (files->etc-directory (proc 
> files
>   #~(activate-etc #$etc
>(service-extension system-service-type etc-entry)))
>  (compose concatenate)
>
>
> In your config, you could have something like:
>
>   (services (cons (simple-service 'rm-/etc/profile etc-service-type
>   (const (lambda (files)
>(assoc-delete "profile" files
>   %base-services))
>
> WDYT?

I think it would be great!  I didn't realize it can be implemented this
way.

> In fact I think we would need to have a more generic mechanism to hook
> into ‘fold-services’, but I’m not sure what it should look like.

Yeah, a more generic way would be better of course, but I think this
mixing of files and procedures is already good enough for now, as it
provides a freedom in customizing a system that we didn't have before.
Besides I will no longer object against the "search-paths" fix for the
bug 20255 :-)

-- 
Alex

Customizing /etc

[Ludovic Courtès]

Alex Kost  skribis:

> Ludovic Courtès (2016-09-14 16:58 +0200) wrote:
>
>> Hello,
>>
>> csanchez...@gmail.com (Carlos Sánchez de La Lama) skribis:
>>
>>> I have an interesting case here. I have guile installed in my system
>>> profile, so that
>>>
>>> /var/guix/profiles/system/profile/share/aclocal/guile.m4
>>>
>>> is there. However, autoconf is installed in my *user* profile, so
>>> ACLOCAL_PATH is augmented in ~/.guix-profile/etc/profile to include
>>>
>>> ~/.guix-profile/share/aclocal
>>>
>>> But not the system-profile aclocal directory, which would be put into
>>> ACLOCAL_PATH by /var/guix/profiles/system/profile/etc/profile if
>>> autoconf was installed in the systme profile as well.
>>>
>>> Is this the intended behaviour? I am wondering whether packages with
>>> search paths should include both the user-profile directories and the
>>> system-profile ones.
>>
>> I think you’re right.  This was discussed at
>> , leading to a patch (for GuixSD).
>>
>> However, we failed to build consensus around the approach of this patch,
>> so we did not apply it.  If you have ideas, please email
>> 20...@debbugs.gnu.org.  :-)
>
> I think I was the one who prevents the consensus.  To make it clear, I'm
> for the suggested solution, but only *after* giving a user a freedom to
> avoid loading such a heavy command as "guix package --search-paths".  On
> a "usual" GNU/Linux distro a user can edit /etc/profile, but on GuixSD
> it is not possible currently.  That's why I think there should be
> provided a possibility to override /etc/profile at first.

Indeed, thanks for the reminder!

In fact, we have this through ‘etc-service-type’, except that currently
/etc/profile is systematically added.

So an idea that comes to mind is to allow ‘etc-service-type’ to be
extended with procedures that would be able to filter or otherwise
change the /etc entries (similar to what we do for PAM):

diff --git a/gnu/services.scm b/gnu/services.scm
index 7e322c5..9397232 100644
--- a/gnu/services.scm
+++ b/gnu/services.scm
@@ -426,9 +426,13 @@ directory."
 (extensions
  (list
   (service-extension activation-service-type
- (lambda (files)
-   (let ((etc
-  (files->etc-directory files)))
+ (lambda (files+procs)
+   (let* ((proc (apply compose
+   (filter procedure?
+   files+procs)))
+  (files (filter pair? files+procs))
+  (etc
+   (files->etc-directory (proc files
  #~(activate-etc #$etc
   (service-extension system-service-type etc-entry)))
 (compose concatenate)

In your config, you could have something like:

  (services (cons (simple-service 'rm-/etc/profile etc-service-type
  (const (lambda (files)
   (assoc-delete "profile" files
  %base-services))

WDYT?

In fact I think we would need to have a more generic mechanism to hook
into ‘fold-services’, but I’m not sure what it should look like.

Ludo’.

Re: Customizing /etc

[Alex Kost]

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

> Alex Kost  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 '-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

Customizing /etc

[Ludovic Courtès]

Alex Kost  skribis:

> 宋文武 (2015-11-24 18:22 +0300) wrote:

[...]

>> So, the plan is add /etc/environment and only use /etc/profile for 2.
>> then, a sh-profile file-like configuration can be added.  WDYT?
>
> 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.)

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"))

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

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?

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.

Thanks,
Ludo’.