Services and packages in GuixSD

Services and packages in GuixSD

[Andy Wingo]

Hi,

There are a few services whose behavior depends on the set of installed
packages or services, or which should depend on those sets.  For example
with %desktop-services specified, udev should be adding rules for upower
and colord, AFAIU.  Likewise for dbus: it would be nice if the set of
selected packages and services were grovelled for dbus files.

For example this is my current services definition:

    (services
     (let ((motd (text-file "motd" "
       This is the GNU operating system, welcome!\n\n")))
       (list (console-font-service "tty1")
             (console-font-service "tty2")
             (console-font-service "tty3")
             (console-font-service "tty4")
             (console-font-service "tty5")
             (console-font-service "tty6")

             (mingetty-service "tty1" #:motd motd)
             (mingetty-service "tty2" #:motd motd)
             (mingetty-service "tty3" #:motd motd)
             (mingetty-service "tty4" #:motd motd)
             (mingetty-service "tty5" #:motd motd)
             (mingetty-service "tty6" #:motd motd)
             (static-networking-service
              "lo" "127.0.0.1" #:provision '(loopback))
             (syslog-service)
             (guix-service)
             (nscd-service #:name-services (list nss-mdns))

             (slim-service)
             (lsh-service)
             (wicd-service)
             (avahi-service)
             (dbus-service
              (list avahi wicd upower colord geoclue polkit))
             (upower-service)
             ;; FIXME: Can be bus-activated; just need to make the config
             ;; and the user.
             (geoclue-service)
             ;; FIXME: Doesn't need to be run at startup; can be activated
             ;; via dbus.  However we do it here in order to create
             ;; /var/lib/colord.
             (colord-service)
             ;; FIXME: Can be bus-activated; just need to make the user.
             (polkit-service)
             ;; The LVM2 rules are needed as soon as LVM2 or the
             ;; device-mapper is used, so enable them by default.  The FUSE
             ;; and ALSA rules are less critical, but handy.
             (udev-service
              #:rules (list lvm2 fuse alsa-utils upower colord)))))

I can't switch to use %base-services or %desktop-services because of the
udev-service and dbus-service configurations.  That's the bug I'm trying
to solve here.

Would it be possible to allow services to grovel the set of installed
packages and services to "finalize" their configuration?  We might have
to take care to avoid service configuration depending on service
configuration, but I reckon that's possible to take into account.

Regards,

Andy

Re: Services and packages in GuixSD

[宋文武]

Andy Wingo <wingo@igalia.com> writes:

> Hi,
>
> There are a few services whose behavior depends on the set of installed
> packages or services, or which should depend on those sets.  For example
> with %desktop-services specified, udev should be adding rules for upower
> and colord, AFAIU.  Likewise for dbus: it would be nice if the set of
> selected packages and services were grovelled for dbus files.
>
> For example this is my current services definition:
>
> [...]
>
> I can't switch to use %base-services or %desktop-services because of the
> udev-service and dbus-service configurations.  That's the bug I'm trying
> to solve here.
>
> Would it be possible to allow services to grovel the set of installed
> packages and services to "finalize" their configuration?  We might have
> to take care to avoid service configuration depending on service
> configuration, but I reckon that's possible to take into account.
IIUC, the packages in profile need to be known by those services.
I think two ways can do this:
1. Build a configuration file for the service with packages listed explicitly.
2. Use a configuration file for the service with respect to profile.

Currently, most services go for 1 (eg: dbus, udev). And I don't know a
clear way to pass packages field to the monadic service procedure.

I did use 2 for slim, by using '/run/current-system/profile/share/xsessions'
in its configuration file.

How about go with 2 for dbus-service too?
By using '/run/current-system/profile/share/dbus-1/system-services' in
its configuration file.

Re: Services and packages in GuixSD

[Andy Wingo]

On Wed 12 Aug 2015 03:13, 宋文武 <iyzsong@gmail.com> writes:

> Andy Wingo <wingo@igalia.com> writes:
>
>> it would be nice if the set of selected packages and services were
>> grovelled for dbus files.
>
> IIUC, the packages in profile need to be known by those services.
> I think two ways can do this:
> 1. Build a configuration file for the service with packages listed explicitly.
> 2. Use a configuration file for the service with respect to profile.
>
> Currently, most services go for 1 (eg: dbus, udev). And I don't know a
> clear way to pass packages field to the monadic service procedure.
>
> I did use 2 for slim, by using '/run/current-system/profile/share/xsessions'
> in its configuration file.
>
> How about go with 2 for dbus-service too?
> By using '/run/current-system/profile/share/dbus-1/system-services' in
> its configuration file.

Sounds reasonable to me.

This approach introduces a degree of dynamic scoping: the set of
services that d-bus knows about is dynamically scoped relative to the
current profile, whatever the current profile is.  So you could do a
"guix system reconfigure" and then the old d-bus daemon would be able to
launch new services, without rebooting.  Some people might not like that
but it sounds fine to me.

Andy

Re: Services and packages in GuixSD

[Ludovic Courtès]

Andy Wingo <wingo@igalia.com> skribis:

> For example this is my current services definition:
>
>     (services
>      (let ((motd (text-file "motd" "
>        This is the GNU operating system, welcome!\n\n")))
>        (list (console-font-service "tty1")
>              (console-font-service "tty2")
>              (console-font-service "tty3")
>              (console-font-service "tty4")
>              (console-font-service "tty5")
>              (console-font-service "tty6")
>
>              (mingetty-service "tty1" #:motd motd)
>              (mingetty-service "tty2" #:motd motd)
>              (mingetty-service "tty3" #:motd motd)
>              (mingetty-service "tty4" #:motd motd)
>              (mingetty-service "tty5" #:motd motd)
>              (mingetty-service "tty6" #:motd motd)
>              (static-networking-service
>               "lo" "127.0.0.1" #:provision '(loopback))
>              (syslog-service)
>              (guix-service)
>              (nscd-service #:name-services (list nss-mdns))
>
>              (slim-service)
>              (lsh-service)
>              (wicd-service)
>              (avahi-service)
>              (dbus-service
>               (list avahi wicd upower colord geoclue polkit))
>              (upower-service)
>              ;; FIXME: Can be bus-activated; just need to make the config
>              ;; and the user.
>              (geoclue-service)
>              ;; FIXME: Doesn't need to be run at startup; can be activated
>              ;; via dbus.  However we do it here in order to create
>              ;; /var/lib/colord.
>              (colord-service)
>              ;; FIXME: Can be bus-activated; just need to make the user.
>              (polkit-service)
>              ;; The LVM2 rules are needed as soon as LVM2 or the
>              ;; device-mapper is used, so enable them by default.  The FUSE
>              ;; and ALSA rules are less critical, but handy.
>              (udev-service
>               #:rules (list lvm2 fuse alsa-utils upower colord)))))
>
> I can't switch to use %base-services or %desktop-services because of the
> udev-service and dbus-service configurations.  That's the bug I'm trying
> to solve here.

You can but it’s inconvenient: You could use a trick similar to the
‘%my-base-services’ example given at

  https://www.gnu.org/software/guix/manual/html_node/Name-Service-Switch.html

I think we should probably change service procedures to return
first-class objects rather than monadic values (by defining a gexp
expander).  That would make such customization easier.

Additionally, we should arrange so we don’t have to define dmd services
do D-Bus services, because the system bus already takes care of them.
Presumably that means that we need a <dbus-service> type, which would
encompass a package (e.g., GeoClue) and its associated config (e.g., a
record or a file-like object.)

WDYT?

Thanks,
Ludo’.

Re: Services and packages in GuixSD

[Ludovic Courtès]

Andy Wingo <wingo@igalia.com> skribis:

> On Wed 12 Aug 2015 03:13, 宋文武 <iyzsong@gmail.com> writes:
>
>> Andy Wingo <wingo@igalia.com> writes:
>>
>>> it would be nice if the set of selected packages and services were
>>> grovelled for dbus files.
>>
>> IIUC, the packages in profile need to be known by those services.
>> I think two ways can do this:
>> 1. Build a configuration file for the service with packages listed explicitly.
>> 2. Use a configuration file for the service with respect to profile.
>>
>> Currently, most services go for 1 (eg: dbus, udev). And I don't know a
>> clear way to pass packages field to the monadic service procedure.
>>
>> I did use 2 for slim, by using '/run/current-system/profile/share/xsessions'
>> in its configuration file.
>>
>> How about go with 2 for dbus-service too?
>> By using '/run/current-system/profile/share/dbus-1/system-services' in
>> its configuration file.
>
> Sounds reasonable to me.
>
> This approach introduces a degree of dynamic scoping: the set of
> services that d-bus knows about is dynamically scoped relative to the
> current profile, whatever the current profile is.  So you could do a
> "guix system reconfigure" and then the old d-bus daemon would be able to
> launch new services, without rebooting.  Some people might not like that
> but it sounds fine to me.

Not having to reboot after ‘reconfigure’ is generally desirable, of
course (it just happens to not be fully implemented yet.)  However, the
above means that the reconfigure-but-don’t-switch-until-reboot behavior
would no longer be possible.  So I think we should try to avoid #2 in
most cases.

Ludo’.

Re: Services and packages in GuixSD

[Ludovic Courtès]

Andy Wingo <wingo@igalia.com> skribis:

> On Wed 12 Aug 2015 03:13, 宋文武 <iyzsong@gmail.com> writes:
>
>> Andy Wingo <wingo@igalia.com> writes:
>>
>>> it would be nice if the set of selected packages and services were
>>> grovelled for dbus files.
>>
>> IIUC, the packages in profile need to be known by those services.
>> I think two ways can do this:
>> 1. Build a configuration file for the service with packages listed explicitly.
>> 2. Use a configuration file for the service with respect to profile.
>>
>> Currently, most services go for 1 (eg: dbus, udev). And I don't know a
>> clear way to pass packages field to the monadic service procedure.
>>
>> I did use 2 for slim, by using '/run/current-system/profile/share/xsessions'
>> in its configuration file.
>>
>> How about go with 2 for dbus-service too?
>> By using '/run/current-system/profile/share/dbus-1/system-services' in
>> its configuration file.
>
> Sounds reasonable to me.
>
> This approach introduces a degree of dynamic scoping: the set of
> services that d-bus knows about is dynamically scoped relative to the
> current profile, whatever the current profile is.  So you could do a
> "guix system reconfigure" and then the old d-bus daemon would be able to
> launch new services, without rebooting.  Some people might not like that
> but it sounds fine to me.

Not having to reboot after ‘reconfigure’ is generally desirable, of
course (it just happens to not be fully implemented yet.)  However, the
above means that the reconfigure-but-don’t-switch-until-reboot behavior
would no longer be possible.  So I think we should try to avoid #2 in
most cases.

Ludo’.

Re: Services and packages in GuixSD

[Andy Wingo]

On Tue 25 Aug 2015 22:36, ludo@gnu.org (Ludovic Courtès) writes:

> However, the above means that the
> reconfigure-but-don’t-switch-until-reboot behavior would no longer be
> possible.

Not sure what this case is for -- either you want to expose the newly
reconfigured apps to the user or you don't, right?  In the former case
it seems that really what you want is to prepare everything for reboot
but only switch the profile on boot.  Dunno, I don't have the tao of
guix yet :)

A

Re: Services and packages in GuixSD

[Ludovic Courtès]

Andy Wingo <wingo@igalia.com> skribis:

> On Tue 25 Aug 2015 22:36, ludo@gnu.org (Ludovic Courtès) writes:
>
>> However, the above means that the
>> reconfigure-but-don’t-switch-until-reboot behavior would no longer be
>> possible.
>
> Not sure what this case is for -- either you want to expose the newly
> reconfigured apps to the user or you don't, right?  In the former case
> it seems that really what you want is to prepare everything for reboot
> but only switch the profile on boot.  Dunno, I don't have the tao of
> guix yet :)

It can be useful if you want to install a new configuration to make it
effective at the next reboot, but don’t want to make any change until
then.

Dunno, maybe this is a uncommon use case, but I think it’s good if we
make connections between various components explicit rather than
implicit.

Thanks,
Ludo’.

Re: Services and packages in GuixSD

[Andy Wingo]

On Wed 26 Aug 2015 12:54, ludo@gnu.org (Ludovic Courtès) writes:

> Andy Wingo <wingo@igalia.com> skribis:
>
>> On Tue 25 Aug 2015 22:36, ludo@gnu.org (Ludovic Courtès) writes:
>>
>>> However, the above means that the
>>> reconfigure-but-don’t-switch-until-reboot behavior would no longer be
>>> possible.
>>
>> Not sure what this case is for -- either you want to expose the newly
>> reconfigured apps to the user or you don't, right?  In the former case
>> it seems that really what you want is to prepare everything for reboot
>> but only switch the profile on boot.  Dunno, I don't have the tao of
>> guix yet :)
>
> It can be useful if you want to install a new configuration to make it
> effective at the next reboot, but don’t want to make any change until
> then.

Oh I agree with you -- but if you switch the system profile before the
reboot (/run/current-system, not /run/booted-system) but you have
various things pointing into /run/current-system like user $PATH and
what-not, it seems like this case is already not being served correctly.
Dunno.

It seems like you want two kinds of reconfigure: one that just adds the
grub entry to make a new system the default on the next boot, and
another kind of reconfigure that also mutates /run/current-system.  Does
that make sense?

Andy

Re: Services and packages in GuixSD

[Ludovic Courtès]

Andy Wingo <wingo@igalia.com> skribis:

> It seems like you want two kinds of reconfigure: one that just adds the
> grub entry to make a new system the default on the next boot, and
> another kind of reconfigure that also mutates /run/current-system.  Does
> that make sense?

Yes, exactly.

Ludo’.