[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Help with preparing to move from Arch Linux to Guix

From: Ricardo Wurmus
Subject: Re: Help with preparing to move from Arch Linux to Guix
Date: Sat, 11 May 2019 08:25:31 +0200
User-agent: mu4e 1.2.0; emacs 26.2

Hi Doron,

> Anyway, to come to the bottom of it, I've searched the documentation and
> couldn't find an answer regarding what-so-ever configurations in `/etc/`.
> Pretty much everything that makes Arch Linux impressive, is it's
> documentation on the aspect of everything that is needed to be put in
> every file in `/etc/` so the system can be tweaked exactly the way one
> wishes.
> I noticed that in Guix, all the files in /etc/ are read only. I
> understand why - `guix system` is responsible for reading a Scheme file
> that will create an etc store that will be used for the configuration of
> the whole system and I'm not supposed to touch anything in /etc/
> manually..  But, I couldn't find how to generally do stuff there.

For those packages where files in /etc do have an effect you can
generate these files with the etc-service-type.  For many packages,
however, it won’t be enough to place files in /etc; often that’s because
the packages have their sysconf directory set to be a sub-directory in
the read-only store.  You may need to figure out alternative ways to
tell the target software about your configuration files — in some cases
you may need to patch the package to make it look in the global /etc
directory; in others you may need to write a service to run a daemon
with an option that points to the generated configuration file; in yet
others a one-shot service may be enough.

If you find that some packages need to be modified to accomodate
customizations: that’s fine and we’d love to discuss patches!

Everything about how the system is set up is done via system services.
A system service is not the equivalent of a systemd service, it is
broader than that.  The system services framework in Guix is used

1) to generate files (e.g. in /etc)
2) to run arbitrary code for setting up directories before running daemons
3) to create service specific user accounts and groups

Services can extend one another, which allows us to define ways to set
up complex applications, for example, that require a web server, user
accounts, application-specific daemons, a database, udev rules, etc —
all with just one service type.

I recommend taking a look at the section “Defining Services” (and
especially “Service Composition”) in the manual, as well as the
“Services” section, which introduces existing services.

> I have dozens of very personal configurations I've done in my current
> Arch system's /etc/ which I have no clue how to port them all and make
> sure all of them are picked in the transition. Here are just a few
> examples:
> - tinc (VPN software): This one expects to find cryptographic key files
>   to in `/etc/tinc/`.

If that’s the only place where it can look for these files you can place
them there manually.  The store is not a suitable location for secrets
so it’s best not to have secrets in the configuration file.

> - samba: Where do I define my shares?

In my experience our support for configuring Samba is rather poor.  I
guess here the best way is to extend the etc-service-type to dump the
configuration string in /etc.

> - pam: gnome keyring daemon autostart on login (Arch documents how to
>   achieve this without a login manager, see

The operating-system record has a field “pam-services” which has a
default of “(base-pam-services)”.  I’m afraid PAM services are a little
special and don’t all that nicely fit into the general service
framework, which can be a bit frustrating.  (I hope we can generalize
this more in the future.)  Documentation on the pam-services is rather
sparse, unfortunately.

“base-pam-services” is a procedure in (gnu system pam) that returns a
list of “pam-service” values.  These values are constructed with the
“pam-service” constructor, which defines a record with a bunch of
fields, such as “name”, “account”, “auth”, “password”, and “session”.

The “pam-root-service-type” can be extended to modify existing pam
entries, which is what you’d want to do to extend the “login” and
“passwd” files.

I would try to extend the pam-root-service-type with a procedure that
checks if the argument is a <pam-service> with pam-service-name equal to
“login” or “passwd” and then return a modified <pam-service> value with
your extra fields.

Something roughly like this:

--8<---------------cut here---------------start------------->8---
(define (pam-extension-procedure config)
  "Return an extension for PAM-ROOT-SERVICE-TYPE that ensures that the PAM
services for login and passwd use ''."
  (define pam-gnome-keyring
     ;; TODO: I don't know how to pass "auto_start"
     (control "optional")
     (module (file-append gnome-keyring

  (list (lambda (pam)
          (if (member (pam-entry-name pam)
                      '("login" "passwd"))
               (inherit pam)
               (auth (cons pam-gnome-keyring (pam-service-auth pam)))
               (session (cons pam-gnome-keyring (pam-service-session pam))))
              ;; Don't modify the other pam files

(define pam-gnome-keyring-service-type
  (service-type (name 'pam-gnome-keyring)
                 (list ;; Extend PAM with
                       (service-extension pam-root-service-type
                (default-value #f)))
--8<---------------cut here---------------end--------------->8---

> - vconsole.conf: just another example for a file I've put some stuff in.

I guess you can extend the etc-service-type here to generate that file.

Hope this helps!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]