     [file version-es.texi not included]

Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019 Ludovic Courtès
 Copyright © 2013, 2014, 2016 Andreas Enge

Copyright © 2013 Nikita Karetnikov
 Copyright © 2014, 2015, 2016 Alex Kost
 Copyright © 2015, 2016 Mathieu Lirzin

Copyright © 2014 Pierre-Antoine Rault
 Copyright © 2015 Taylan Ulrich Bayırlı/Kammer
 Copyright © 2015, 2016, 2017 Leo Famulari
 Copyright © 2015, 2016, 2017, 2018, 2019 Ricardo Wurmus
 Copyright © 2016 Ben Woodcroft
 Copyright © 2016, 2017, 2018 Chris Marusich
 Copyright © 2016, 2017, 2018, 2019 Efraim Flashner
 Copyright © 2016 John Darrington

Copyright © 2016, 2017 ng0
 Copyright © 2016, 2017, 2018, 2019 Jan Nieuwenhuizen
 Copyright © 2016 Julien Lepiller

Copyright © 2016 Alex ter Weele
 Copyright © 2016, 2017, 2018, 2019 Christopher Baines
 Copyright © 2017, 2018 Clément Lassieur
 Copyright © 2017, 2018 Mathieu Othacehe

Copyright © 2017 Federico Beffa
 Copyright © 2017, 2018 Carlo Zancanaro
 Copyright © 2017 Thomas Danckaert

Copyright © 2017 humanitiesNerd
 Copyright © 2017 Christopher Allan Webber
 Copyright © 2017, 2018 Marius Bakke

Copyright © 2017 Hartmut Goebel
 Copyright © 2017 Maxim Cournoyer
 Copyright © 2017, 2018 Tobias Geerinckx-Rice

Copyright © 2017 George Clemmer
 Copyright © 2017 Andy Wingo
 Copyright © 2017, 2018, 2019 Arun Isaac
 Copyright © 2017 nee
 Copyright © 2018 Rutger Helling

Copyright © 2018 Oleg Pykhalov
 Copyright © 2018 Mike Gerwitz
 Copyright © 2018 Pierre-Antoine Rouby
 Copyright © 2018 Gábor Boskovits
 Copyright © 2018 Florian Pelz
 Copyright © 2018 Laura Lazzati
 Copyright © 2018 Alex Vong
 Copyright © 2019 Miguel Ángel Arruga Vivas (traducción)

Se garantiza el permiso de copia, distribución y/o modificación de este documento bajo los términos de la licencia de documentación libre de GNU (GNU Free Documentation License), versión 1.3 o cualquier versión posterior publicada por la Free Software Foundation; sin secciones invariantes, sin textos de cubierta delantera ni trasera. Una copia de la licencia está incluida en la sección titulada ``GNU Free Documentation License''.

GNU Guix
********

Este documento describe GNU Guix versión VERSION, una herramienta funcional de gestión de paquetes escrita para el sistema GNU.

Este manual también está disponible en Inglés (see GNU Guix Reference Manual), en Francés (see Manuel de référence de GNU Guix) y Alemán (see Referenzhandbuch zu GNU Guix). Si quiere traducirlo a su lengua nativa, considere unirse a Translation Project (https://translationproject.org/domain/guix-manual.html).

Introducción
************

GNU Guix (``Guix'' se pronuncia tal y como se escribe en castellano, ``gi:ks'' en el alfabeto fonético internacional (IPA).) es una herramienta de gestión de paquetes y una distribucion del sistema GNU. Guix facilita a usuarias sin privilegios la instalación, actualización o borrado de paquetes de software, la vuelta a un conjunto de paquetes previo atómicamente, la construcción de paquetes desde las fuentes, y ayuda de forma general en la creación y mantenimiento de entornos software.

Puede instalar GNU Guix sobre un sistema GNU/Linux existente, donde complementará las herramientas disponibles sin interferencias (see Instalación), o puede usarse como un sistema operativo en sí mismo, el sistema Guix (Solíamos referirnos al sistema Guix como ``Distribución de sistema Guix'' o ``GuixSD''. Ahora consideramos que tiene más sentido agrupar todo bajo la etiqueta ``Guix'' ya que, después de todo, el sistema Guix está inmediatamente disponible a través de la orden guix system, ¡incluso cuando usa una distribución distinta por debajo!). See Distribución GNU.

La forma de gestión de software de Guix
=======================================

Guix proporciona una interfaz de gestión de paquetes de línea de ordenes (see Gestión de paquetes), un conjunto de utilidades de línea de órdenes (see Utilidades), así como interfaces programáticas Scheme (see Interfaz programática). Su daemon de construcción es responsable de la construcción de paquetes en delegación de las usuarias (see Preparación del daemon) y de la descarga de binarios preconstruidos de fuentes autorizadas (see Sustituciones)

Guix incluye definiciones de paquetes para muchos paquetes GNU y no-GNU, todos los cuales respetan la libertad de computación de la usuaria (https://www.gnu.org/philosophy/free-sw.html). Es extensible: las usuarias pueden escribir sus propias definiciones de paquetes (see Definición de paquetes) y hacerlas disponibles como módulos independientes de paquetes (see Módulos de paquetes). También es personalizable: las usuarias pueden derivar definiciones de paquetes especializadas de las existentes, inclusive desde la línea de órdenes (see Opciones de transformación de paquetes).

En su implementación, Guix utiliza la disciplina de gestión de paquetes funcional en la que Nix fue pionero (see Reconocimientos). En Guix, el proceso de construcción e instalación es visto como una función, en el sentido matemático. Dicha función toma entradas, como los guiones de construcción, un compilador, unas bibliotecas y devuelve el paquete instalado. Como función pura, su resultado únicamente depende de sus entradas---por ejemplo, no puede hacer referencia a software o guiones que no fuesen pasados explícitamente como entrada. Una función de construcción siempre produce el mismo resultado cuando se le proporciona un conjunto de entradas dado. No puede modificar el entorno del sistema que la ejecuta de ninguna forma; por ejemplo, no puede crear, modificar o borrar archivos fuera de sus directorios de construcción e instalación. Esto se consigue ejecutando los procesos de construcción en entornos aislados (o contenedores), donde únicamente sus entradas explícitas son visibles.

El resultado de las funciones de construcción de paquetes es almacenado en la caché en el sistema de ficheros, en un directorio especial llamado el almacén (see El almacén). Cada paquete se instala en un directorio propio en el almacén---por defecto, bajo /gnu/store. El nombre del directorio contiene el hash de todas las entradas usadas para construir el paquete; por tanto, cambiar una entrada resulta en un nombre de directorio distinto.

Esta aproximación es el cimiento de las avanzadas características de Guix: capacidad para la actualización transaccional y vuelta-atrás de paquetes, instalación en el ámbito de la usuaria y recolección de basura de paquetes (see Características).

Distribución GNU
================

Guix viene con una distribución del sistema GNU consistente en su totalidad de software libre (El término ``libre'' aquí se refiere a la libertad proporcionada a las usuarias de dicho software (http://www.gnu.org/philosophy/free-sw.html).). La distribución puede instalarse independientemente (see Instalación del sistema), pero también es posible instalar Guix como un gestor de paquetes sobre un sistema GNU/Linux existente (see Instalación). Para distinguir entre las dos opciones, nos referimos a la distribución independiente como el sistema Guix.

La distribución proporciona paquetes principales de GNU como GNU libc, GCC y Binutils, así como muchas aplicaciones GNU y no-GNU. La lista completa de paquetes disponibles puede navegarse en línea (http://www.gnu.org/software/guix/packages) o ejecutando guix package (see Invocación de guix package):

     guix package --list-available

Nuestro objetivo es proporcionar una distribución práctica con 100% software libre basada en Linux y otras variantes de GNU, con un enfoque en la promoción y la alta integración de componentes GNU, y un énfasis en programas y herramientas que ayuden a las usuarias a ejercitar esa libertad.

Actualmente hay paquetes disponibles para las siguientes plataformas:

x86_64-linux
     arquitectura x86_64 de Intel/AMD, núcleo Linux-Libre;

i686-linux
     arquitectura de 32-bits Intel (IA32), núcleo Linux-Libre;

armhf-linux
     arquitectura ARMv7-A con coma flotante hardware, Thumb-2 y NEON, usando la interfaz binaria de aplicaciones (ABI) EABI con coma flotante hardware, y el núcleo Linux-Libre.

aarch64-linux
     procesadores de 64-bits ARMv8 little-endian, núcleo Linux-Libre. Está actualmente en una fase experimental, con soporte limitado. See Contribuir, para cómo ayudar.

mips64el-linux
     procesadores MIPS 64-bits little-endian, específicamente las series Loongson, n32 ABI, y núcleo Linux-Libre.

Con el sistema Guix, declara todos los aspectos de la configuración del sistema y Guix se hace cargo de instanciar la configuración de manera transaccional, reproducible y sin estado global (see Configuración del sistema). El sistema Guix usa el núcleo Linux-libre, el sistema de inicialización Shepherd (see Introducción (The GNU Shepherd Manual)), las conocidas utilidades y herramientas de compilación GNU, así como el entorno gráfico o servicios del sistema de su elección.

El sistema Guix está disponible en todas las plataformas previas excepto mips64el-linux.

Para información sobre el transporte a otras arquitecturas o núcleos, see Transportar.

La construcción de esta distribución es un esfuerzo cooperativo, ¡y esta invitada a unirse! See Contribuir, para información sobre cómo puede ayudar.

Instalación
***********

     Recomendamos el uso de este guión de shell de instalación (https://git.savannah.gnu.org/cgit/guix." "git/plain/etc/guix-install.sh) para instalar Guix sobre un sistema GNU/Linux en ejecución, de aquí en adelante referido como una distribución distinta. (Esta sección está dedicada a la instalación del gestor de paquetes, que puede realizarse sobre un sistema GNU/Linux ya en ejecución. Si, en vez de eso, desdea instalar el sistema operativo GNU completo, see Instalación del sistema.) El guión automatiza la descarga, instalación y configuración inicial de Guix. Debe ejecutarse como la usuaria de administración root.

Cuando está instalado sobre una distribución distinta, GNU Guix complementa las herramientas disponibles sin interferencias. Sus datos radican exclusivamente en dos directorios, normalmente /gnu/store y /var/guix; otros ficheros en su sistema, como /etc, permanecen intactos.

Una vez instalado, Guix puede ser actualizado ejecutando guix pull (see Invocación de guix pull.

Si prefiere realizar los pasos de instalación manualmente o desea personalizarlos, puede encontrar útiles las siguientes instrucciones. Describen los requisitos de software de Guix, así como su instalación manual y la preparación para su uso.

Instalación binaria
===================

Esta sección describe cómo instalar Guix en un sistema arbitrario desde un archivador autocontenido que proporciona los binarios para Guix y todas sus dependencias. Esto es normalmente más rápido que una instalación desde las fuentes, la cual es descrita en las siguientes secciones. El único requisito es tener GNU tar y Xz.

La instalación consiste más o menos en los siguientes pasos:

 1. Descargue el archivador con los binarios de https://alpha.gnu.org/gnu/guix/guix-binary-VERSION.SISTEMA.tar.xz, donde SISTEMA es x86_64-linux para una máquina x86_64 que ejecute el núcleo Linux, etcétera.

     Asegurese de descargar el fichero .sig asociado y de verificar la autenticidad del archivador con él, más o menos así:

          $ wget https://alpha.gnu.org/gnu/guix/guix-binary-VERSION.SISTEMA.tar.xz.sig
          $ gpg --verify guix-binary-VERSION.SISTEMA.tar.xz.sig

     Si la orden falla porque no dispone de la clave pública necesaria, entonces ejecute esta otra orden para importarla:

          $ gpg --keyserver pool.sks-keyservers.net \
                --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5

     y vuelva a ejecutar la orden gpg --verify.

 2. Ahora necesita convertirse en la usuaria root. Dependiendo de su distribución, puede que tenga que ejecutar su - o sudo -i. Como root, ejecute:

          # cd /tmp
          # tar --warning=no-timestamp -xf \
               guix-binary-VERSION.SISTEMA.tar.xz
          # mv var/guix /var/ && mv gnu /

     Esto crea /gnu/store (see El almacén) y /var/guix. El último contiene un perfil listo para usar para root (vea el siguiente paso).

     No extraiga el archivador en un sistema Guix ya funcionando ya que sobreescribiría sus propios ficheros esenciales.

     La opción --warning=no-timestamp asegura que GNU tar no emite avisos sobre ``marcas de tiempo imposibles'' (dichos avisos eran emitidos por GNU tar 1.26 y anteriores; las versiones recientes están bien). Parten del hecho de que todos los ficheros en el archivador tienen su tiempo de modificación fijado a cero (que significa el 1 de enero de 1970). Esto es hecho voluntariamente para asegurarse de que el contenido del archivador es independiente de su fecha de creación, haciendolo por tanto reproducible.

 3. Ponga disponible el perfil en ~root/.config/guix/current, que es donde guix pull instalará las actualizaciones (see Invocación de guix pull):

          # mkdir -p ~root/.config/guix
          # ln -sf /var/guix/profiles/per-user/root/current-guix \
                   ~root/.config/guix/current

     Cargue etc/profile para aumentar PATH y otras variables de entorno relevantes:

          # GUIX_PROFILE="`echo ~root`/.config/guix/current" ; \
            source $GUIX_PROFILE/etc/profile

 4. Cree el grupo y las cuentas de usuaria para las usuarias de construcción como se explica a continuación (see Configuración del entorno de construcción).

 5. Ejecute el daemon, y configurelo para iniciarse automáticamente al arranque.

     Si su distribución anfitriona usa el sistema de inicio systemd, puede conseguirlo con estas órdenes:

          # cp ~root/.config/guix/current/lib/systemd/system/guix-daemon.service \
               /etc/systemd/system/
          # systemctl start guix-daemon && systemctl enable guix-daemon

     Si su distribución anfitriona usa el sistema de inicio Upstart:

          # initctl reload-configuration
          # cp ~root/.config/guix/current/lib/upstart/system/guix-daemon.conf \
               /etc/init/
          # start guix-daemon

     En otro caso, todavía puede iniciar el daemon manualmente con:

          # ~root/.config/guix/current/bin/guix-daemon \
                 --build-users-group=guixbuild

 6. Haga accesible la orden guix a otras usuarias de la máquina, por ejemplo con:

          # mkdir -p /usr/local/bin
          # cd /usr/local/bin
          # ln -s /var/guix/profiles/per-user/root/current-guix/bin/guix

     Es también una buena idea poner disponible la versión Info de este manual ahí:

          # mkdir -p /usr/local/share/info
          # cd /usr/local/share/info
          # for i in /var/guix/profiles/per-user/root/current-guix/share/info/* ;
            do ln -s $i ; done

     De este modo, asumiendo que /usr/local/share/info está en la ruta de búsqueda, ejecutar info guix.es abrirá este manual (see Other Info Directories (GNU Texinfo), para más detalles sobre cómo cambiar la ruta de búsqueda de Info).

 7. Para usar sustituciones de ci.guix.es.info o uno de sus espejos (see Sustituciones), debe autorizarlas:

          # guix archive --authorize < \
               ~root/.config/guix/current/share/guix/ci.guix.es.info.pub

 8. Cada usuaria puede necesitar dar algunos pasos adicionales para prepar su entorno de Guix para el uso, see Configuración de la aplicación.

Voilà, ¡la instalación está completa!

Puede confirmar que Guix está funcionando instalando un paquete de ejemplo en su perfil de root:

     # guix package -i hello

El paquete guix debe permanecer disponible en el perfil de root, o podría verse sujeto a la recolección de basura---en cuyo caso se encontraría seriamente lastrada por la falta de la orden guix. En otras palabras, no borre guix ejecutando guix package -r guix.

El archivador de la instalación binaria puede ser (re)producido y verificado simplemente ejecutando la siguiente orden en el árbol de fuentes de Guix:

     make guix-binary.SISTEMA.tar.xz

... que a su vez ejecuta:

     guix pack -s SISTEMA --localstatedir \
       --profile-name=current-guix guix

See Invocación de guix pack, para más información sobre esta útil herramienta.

Requisitos
==========

Esta sección enumera los requisitos para construir Guix desde las fuentes. El procedimiento de construcción de Guix es el mismo que el de otro software GNU, y no está cubierto aquí. Por favor, eche un vistazo a los ficheros README y INSTALL en el árbol de fuentes de Guix para obtener detalles adicionales.

GNU Guix está disponible para descarga desde su página web en http://www.gnu.org/software/guix/.

GNU Guix depende de los siguientes paquetes:

  * GNU Guile (http://gnu.org/software/guile/), versión 2.2.x;

  * Guile-Gcrypt (https://notabug.org/cwebber/guile-gcrypt), versión 0.1.0 o posterior;

  * GnuTLS (http://gnutls.org/), específicamente su API Guile (see how to install the GnuTLS bindings for Guile (GnuTLS-Guile));

  * Guile-SQLite3 (https://notabug.org/guile-sqlite3/guile-sqlite3), versión 0.1.0 o posterior;

  * Guile-Git (https://gitlab.com/guile-git/guile-git), de agosto de 2017 o posterior;

  * Guile-JSON (https://savannah.nongnu.org/projects/guile-json/);

  * zlib (http://zlib.net);

  * GNU Make (http://www.gnu.org/software/make/).

Las siguientes dependencias son opcionales:

  * Las características de delegación de construcciones (see Configuración de delegación del daemon) y de guix copy (see Invocación de guix copy) dependen de Guile-SSH (https://github.com/artyom-poptsov/guile-ssh), versión 0.10.2 o posterior.

  * Cuando libbz2 (http://www.bzip.org) está disponible, guix daemon puede usarla para comprimir los log de construcción.

A menos que se pasase --disable-daemon a configure, los siguientes paquetes también son necesarios:

  * GNU libgcrypt (http://gnupg.org/);

  * SQLite 3 (http://sqlite.org);

  * g++ de GCC (http://gcc.gnu.org) con soporte para el estándar C++11

Cuando se configura Guix en un sistema que ya tiene una instalación de Guix, asegurese de especificar el mismo directorio de estado que el de la instalación existente usando la opción --localstatedir al guión configure (see localstatedir (GNU Coding Standards)). El guión configure le proteje ante una mala configuración no deseada de LOCALSTATEDIR de modo que no pueda corromper inadvertidamente su almacén (see El almacén).

Cuando está disponible una instalación en funcionamiento del gestor de paquetes Nix (http://nixos.org/nix/), puede a su vez configurar Guix con --disable-daemon. En ese caso, Nix reemplaza las tres dependencias anteriores.

Guix es compatible con Nix, así que es posible compartir el mismo almacén entre ambos. Para hacerlo debe pasar a configure no solo el mismo valor de --with-store-dir, sino también el mismo valor de --localstatedir. El último es esencial debido a que especifica la base de datos donde se encuentran almacenados los metadatos del almacén, entre otras cosas. Los valores predeterminados para Nix son --with-store-dir=/nix/store y --localstatedir=/nix/var. Fíjese que no se requiere --disable-daemon si su objetivo es compartir el almacén con Nix.

Ejecución de la batería de pruebas
==================================

Después de una ejecución exitosa de configure y make, es una buena idea ejecutar la batería de pruebas. Puede ayudar a encontrar problemas con la configuración o el entorno, o errores en el mismo Guix---e informar de fallos en las pruebas es realmente una buena forma de ayudar a mejorar el software. Para ejecutar la batería de pruebas, teclee:

     make check

Los casos de prueba pueden ejecutarse en paralelo: puede usar la opción -j de GNU make para acelerar las cosas. La primera ejecución puede tomar algunos minutos en una máquina reciente; las siguientes ejecuciones serán más rápidas puesto que el almacén creado para las pruebas ya tendrá varias cosas en la caché.

Tambien es posible ejecutar un subconjunto de las pruebas definiendo la variable de makefile TESTS como en el ejemplo:

     make check TESTS="tests/store.scm tests/cpio.scm"

Por defecto, los resultados de las pruebas se muestran a nivel de fichero. Para ver los detalles de cada caso de prueba individual, es posible definir la variable de makefile SCM_LOG_DRIVER_FLAGS como en el ejemplo:

     make check TESTS="tests/base64.scm" SCM_LOG_DRIVER_FLAGS="--brief=no"

En caso de fallo, le rogamos que envíe un correo a bug-guix@gnu.org y adjunte el fichero test-suite.log. Por favor, especifique la versión de Guix usada así como los números de versión de las dependencias (see Requisitos) en su mensaje.

Guix también viene como una batería de pruebas del sistema completo que prueban instancias completas del sistema Guix. Se puede ejecutar únicamente en sistemas donde Guix ya está instalado, usando:

     make check-system

o, de nuevo, definiendo TESTS para seleccionar un subconjunto de las pruebas a ejecutar:

     make check-system TESTS="basic mcron"

Estas pruebas de sistema están definidas en los módulos (gnu tests ...). Funcionan ejecutando el sistema operativo con una instrumentación ligera en una máquina virtual (VM). Pueden ser computacionalmente intensivas o bastante baratas, dependiendo de si hay sustituciones disponibles para sus dependencias (see Sustituciones). Algunas requieren mucho espacio de almacenamiento para alojar las imágenes de la máquina virtual.

De nuevo, en caso de fallos en las pruebas, le rogamos que envíe a bug-guix@gnu.org todos los detalles.

Preparación del daemon
======================

Operaciones como la construcción de un paquete o la ejecución del recolector de basura son realizadas por un proceso especializado, el daemon de construcción, en delegación de sus clientes. Únicamente el daemon puede acceder al almacén y su base de datos asociada. Por tanto, cualquier operación que manipula el almacén se realiza a través del daemon. Por ejemplo, las herramientas de línea de órdenes como guix package y guix build se comunican con el daemon (via llamadas a procedimientos remotos) para indicarle qué hacer.

Las siguientes secciones explican cómo preparar el entorno del daemon de construcción. Véase tambien Sustituciones, para información sobre cómo permitir al daemon descargar binarios pre-construidos.

Configuración del entorno de construcción
-----------------------------------------

En una configuración multiusuaria estándar, Guix y su daemon---el programa guix-daemon---son instalados por la administradora del sistema; /gnu/store pertenece a root y guix-daemon se ejecuta como root. Usuarias sin privilegios pueden usar las herramientas de Guix para construir paquetes o acceder al almacén de otro modo, y el daemon lo hará en delegación suya, asegurando que el almacén permanece en un estado consistente, y permitiendo compartir entre usuarias los paquetes construidos.

Mientras que guix-daemon se ejecuta como root, puede que no desee que los procesos de construcción de paquetes se ejecuten como root también, por razones de seguridad obvias. Para evitarlo, una reserva especial de usuarias de construcción debe ser creada para ser usada por los procesos de construcción iniciados por el daemon. Estas usuarias de construcción no necesitan tener un shell ni un directorio home: simplemente serán usadas cuando el daemon se deshaga de los privilegios de root en los procesos de construcción. Tener varias de dichas usuarias permite al daemon lanzar distintos procesos de construcción bajo UID separados, lo que garantiza que no interferirán entre ellos---una característica esencial ya que las construcciones se caracterizan como funciones puras (see Introducción).

En un sistema GNU/Linux, una reserva de usuarias de construcción puede ser creada así (usando la sintaxis de Bash y las órdenes de shadow):

     # groupadd --system guixbuild
     # for i in `seq -w 1 10`;
       do
         useradd -g guixbuild -G guixbuild                      \
                 -d /var/empty -s `which nologin`               \
                 -c "Usuaria de construcción Guix $i" --system  \
                 guixbuilder$i;
       done

El número de usuarias de construcción determina cuantos trabajos de construcción se pueden ejecutar en paralelo, especificado por la opción --max-jobs (see --max-jobs). Para usar guix system vm y las órdenes relacionadas, puede necesitar añadir las usuarias de construcción al grupo kvm para que puedan acceder a /dev/kvm, usando -G guixbuild,kvm en vez de -G guixbuild (see Invocación de guix system).

El programa guix-daemon puede ser ejecutado entonces como root con la siguiente orden (Si su máquina usa el sistema de inicio systemd, copiando el fichero PREFIX/lib/systemd/system/guix-daemon.service en /etc/systemd/system asegurará que guix-daemon se arranca automáticamente. De igual modo, si su máquina usa el sistema de inicio Upstart, copie el fichero PREFIX/lib/upstart/system/guix-daemon.conf en /etc/init.):

     # guix-daemon --build-users-group=guixbuild

De este modo, el daemon inicia los procesos de construcción en un ``chroot'', bajo una de las usuarias guixbuilder. En GNU/Linux, por defecto, el entorno ``chroot'' contiene únicamente:

  * un directorio /dev mínimo, creado en su mayor parte independientemente del /dev del sistema anfitrión (``En su mayor parte'', porque mientras el conjunto de ficheros que aparecen en /dev es fijo, la mayor parte de estos ficheros solo pueden ser creados si el sistema anfitrión los tiene.)

  * el directorio /proc; únicamente muestra los procesos del contenedor ya que se usa un espacio de nombres de PID separado.

  * /etc/passwd con una entrada para la usuaria actual y una entrada para la usuaria nobody;

  * /etc/groups con una entrada para el grupo de la usuaria;

  * /etc/hosts con una entrada que asocia localhost a 127.0.0.1;

  * un directorio /tmp con permisos de escritura.

Puede influir en el directorio que el daemon utiliza para almacenar los árboles de construcción via la variable de entorno TMPDIR. No obstante, el árbol de construcción en el ``chroot'' siempre se llama /tmp/guix-build-NOMBRE.drv-0, donde NOMBRE es el nombre de la derivación---por ejemplo, coreutils-8.24. De este modo, el valor de TMPDIR no se escapa a los entornos de construcción, lo que evita discrepancias en caso de que los procesos de construcción capturen el nombre de su árbol de construcción.

El daemon también respeta la variable de entorno http_proxy para las descargas HTTP que realiza, sea para derivaciones de salida fija (see Derivaciones) o para sustituciones (see Sustituciones).

Si está instalando Guix como una usuaria sin privilegios, es posible todavía ejecutar guix-daemon siempre que pase --disable-chroot. No obstante, los procesos de construcción no estarán aislados entre sí ni del resto del sistema. Por tanto, los procesos de construcción pueden interferir entre ellos y pueden acceder a programas, bibliotecas y otros ficheros disponibles en el sistema---haciendo mucho más difícil verlos como funciones puras.

Uso de la facilidad de descarga de trabajo
------------------------------------------

Cuando así se desee, el daemon de construcción puede delegar construcciones de derivación a otras máquinas ejecutando Guix, usando el hook de construcción offload (Esta característica está únicamente disponible cuando Guile-SSH (https://github.com/artyom-potsov/guile-ssh) está presente.). Cuando dicha característica es activada, una lista de máquinas de construcción especificadas por la usuaria es leída de /etc/guix/machines.scm; cada vez que se solicita una construcción, por ejemplo via guix build, el daemon intenta delegarla a una de las máquinas que satisfaga las condiciones de la derivación, en particular su tipo de sistema---por ejemplo, x86_64-linux. Los prerrequisitos restantes para la construcción son copiados por SSH a la máquina objetivo, la cual procede con la construcción; con un resultado satisfactorio la(s) salida(s) de la construcción son copiadas de vuelta a la máquina inicial.

El fichero /etc/guix/machines.scm normalmente tiene un contenido de este estilo:

     (list (build-machine
             (name "ochentayseis.example.org")
             (system "x86_64-linux")
             (host-key "ssh-ed25519 AAAAC3Nza...")
             (user "rober")
             (speed 2.))     ;¡increíblemente rápida!

           (build-machine
             (name "mimips.example.org")
             (system "mips64el-linux")
             (host-key "ssh-rsa AAAAB3Nza...")
             (user "alicia")
             (private-key
              (string-append (getenv "HOME")
                             "/.ssh/identidad-para-guix"))))

En el ejemplo anterior se especifica una lista de dos máquinas de construcción, una para la arquitectura x86_64 y otra para la arquitectura mips64el.

De hecho, este fichero es---¡sin sorpresa ninguna!---un fichero Scheme que se evalúa cuando el hook offload se inicia. El valor que devuelve debe ser una lista de objetos build-machine. Mientras que este ejemplo muestra una lista fija de máquinas de construcción, una puede imaginarse, digamos, el uso de DNS-SD para devolver una lista de máquinas de construcción potenciales descubierta en la red local (see Guile-Avahi (Using Avahi in Guile Scheme Programs)). El tipo de datos build-machine se detalla a continuación.

 -- Tipo de datos: build-machine
     Este tipo de datos representa las máquinas de construcción a las cuales el daemon puede delegar construcciones. Los campos importantes son:

     name
          El nombre de red de la máquina remota.

     system
          El sistema de la máquina remota---por ejemplo, "x86_64-linux".

     user
          La cuenta de usuaria a usar cuando se conecte a la máquina remota por SSH. Tenga en cuenta que el par de claves SSH no debe estar protegido por contraseña, para permitir ingresos al sistema no interactivos.

     host-key
          Este campo debe contener la clave pública de la máquina de SSH en formato OpenSSH. Es usado para autentificar la máquina cuando nos conectamos a ella. Es una cadena larga más o menos así:

               ssh-ed25519 AAAAC3NzaC...mde+UhL recordatorio@example.org

          Si la máquina está ejecutando el daemon OpenSSH, sshd, la clave pública de la máquina puede encontrarse en un fichero como /etc/ssh/ssh_host_ed25519_key.pub.

          Si la máquina está ejecutando el daemon SSH GNU lsh, lshd, la clave de la máquina está en /etc/lsh/host-key.pub o un fichero similar. Puede convertirse a formato OpenSSH usando lsh-export-key (see Converting keys (LSH Manual)):

               $ lsh-export-key --openssh < /etc/lsh/host-key.pub
               ssh-rsa AAAAB3NzaC1yc2EAAAAEOp8FoQAAAQEAs1eB46LV...

     Ciertos número de campos opcionales pueden ser especificados:

     port (predeterminado: 22)
          Número de puerto del servidor SSH en la máquina.

     private-key (predeterminada: ~root/.ssh/id_rsa)
          El fichero de clave privada SSH usado para conectarse a la máquina, en formato OpenSSH. Esta clave no debe estar protegida con una contraseña.

          Tenga en cuenta que el valor predeterminado es la clave privada de la cuenta de root. Asegurese de que existe si usa el valor predeterminado.

     compression (predeterminado: "zlib@openssh.com,zlib")
     compression-level (predeterminado: 3)
          Los métodos de compresión y nivel de compresión a nivel SSH solicitados.

          Tenga en cuenta que la delegación de carga depende de la compresión SSH para reducir el ancho de banda usado cuando se transfieren ficheros hacia y desde máquinas de construcción.

     daemon-socket (predeterminado: "/var/guix/daemon-socket/socket")
          Nombre de fichero del socket de dominio Unix en el que guix-daemon escucha en esa máquina.

     parallel-builds (predeterminadas: 1)
          El número de construcciones que pueden ejecutarse en paralelo en la máquina.

     speed (predeterminado: 1.0)
          Un ``factor de velocidad relativa''. El planificador de delegaciones tenderá a preferir máquinas con un factor de velocidad mayor.

     features (predeterminadas: '())
          Una lista de cadenas denotando las características específicas permitidas por la máquina. Un ejemplo es "kvm" para máquinas que tienen los módulos KVM de Linux y las correspondientes características hardware. Las derivaciones pueden solicitar las características por nombre, y entonces se planificarán en las máquinas adecuadas.

El ejecutable guix debe estar en la ruta de búsqueda de las máquinas de construcción. Puede comprobar si es el caso ejecutando:

     ssh build-machine guix repl --version

Hay una última cosa por hacer una vez machines.scm está en su lugar. Como se ha explicado anteriormente, cuando se delega, los ficheros se transfieren en ambas direcciones entre los almacenes de las máquinas. Para que esto funcione, primero debe generar un par de claves en cada máquina para permitir al daemon exportar los archivos firmados de ficheros en el almacén (see Invocación de guix archive):

     # guix archive --generate-key

Cada máquina de construcción debe autorizar a la clave de la máquina maestra para que acepte elementos del almacén que reciba de la maestra:

     # guix archive --authorize < clave-publica-maestra.txt

Del mismo podo, la máquina maestra debe autorizar la clave de cada máquina de construcción.

Todo este lío con claves está ahí para expresar las mutuas relaciones de confianza entre pares de la máquina maestra y las máquinas de construcción. Concretamente, cuando la maestra recibe ficheros de una máquina de construcción (y vice versa), su daemon de construcción puede asegurarse de que son genuinos, no han sido modificados, y que están firmados por una clave autorizada.

Para comprobar si su configuración es operacional, ejecute esta orden en el nodo maestro:

     # guix offload test

Esto intentará conectar con cada una de las máquinas de construcción especificadas en /etc/guix/machines.scm, comprobará que GUile y los módulos Guix están disponibles en cada máquina, intentará exportar a la máquina e importar de ella, e informará de cualquier error en el proceso.

Si quiere probar un fichero de máquinas diferente, simplemente especifiquelo en la línea de órdenes:

     # guix offload test otras-maquinas.scm

Por último, puede probar un subconjunto de máquinas cuyos nombres coincidan con una expresión regular así:

     # guix offload test maquinas.scm '\.gnu\.org$'

Para mostrar la carga actual de todas las máquinas de construcción, ejecute esta orden en el nodo principal:

     # guix offload status

Soporte de SELinux
------------------

Guix incluye un fichero de política SELinux en etc/guix-daemon.cil que puede ser instalado en un sistema donde SELinux está activado, para etiquetar los ficheros Guix y especificar el comportamiento esperado del daemon. Ya que el sistema Guix no proporciona una política base de SELinux, la política del daemon no puede usarse en el sistema Guix.

Instalación de la política de SELinux
.....................................

Para instalar la política ejecute esta orden como root:

     semodule -i etc/guix-daemon.cil

Una vez hecho, vuelva a etiquetar el sistema de ficheros con restorecon o con un mecanismo distinto que proporcione su sistema.

Una vez la política está instalada, el sistema de ficheros ha sido re-etiquetado, y el daemon ha sido reiniciado, debería ejecutarse en el contexto guix_daemon_t. Puede confirmarlo con la siguiente orden:

     ps -Zax | grep guix-daemon

Monitorice los ficheros de log de SELinux mientras ejecuta una orden como guix build hello para convencerse que SELinux permite todas las operaciones necesarias.

Limitaciones
............

Esta política no es perfecta. Aquí está una lista de limitaciones o comportamientos extraños que deben ser considerados al desplegar la política SELinux provista para el daemon Guix.

 1. guix_daemon_socket_t no se usa realmente. Ninguna de las operaciones del socket implica contextos que tengan algo que ver con guix_daemon_socket_t. No hace daño tener esta etiqueta sin usar, pero sería preferible definir reglas del socket únicamente para esta etiqueta.

 2. guix gc no puede acceder enlaces arbitrarios a los perfiles. Por diseño, la etiqueta del fichero del destino de un enlace simbólico es independiente de la etiqueta de fichero del fichero en sí. Aunque todos los perfiles bajo $localstatedir se etiquetan, los enlaces para estos perfiles heredan la etiqueta del directorio en el que están. Para enlaces en el directorio de la usuaria esto será user_home_t. Pero para los enlaces del directorio de root, o /tmp, o del directorio del servidor HTTP, etc., esto no funcionará. guix gc se verá incapacitado para leer y seguir dichos enlaces.

 3. La característica del daemon de esperar conexiones TCP puede que no funcione más. Esto puede requerir reglas extra, ya que SELinux trata los sockets de red de forma diferente a los ficheros.

 4. Actualmente todos los ficheros con un nombre coincidente con la expresión regular /gnu/store.+-(gux-.+|profile)/bin/guix-daemon tienen asignada la etiqueta guix_daemon_exec_t; esto significa que cualquier fichero con ese nombre en cualquier perfil tendrá permitida la ejecución en el dominio guix_daemon_t. Esto no es ideal. Una atacante podría construir un paquete que proporcione este ejecutable y convencer a la usuaria para instalarlo y ejecutarlo, lo que lo eleva al dominio guix_daemon_t. Llegadas a este punto, SELinux no puede prevenir que acceda a los ficheros permitidos para los procesos en dicho dominio.

     Podríamos generar una política mucho más restrictiva en tiempo de instalación, de modo que solo el nombre exacto del fichero del ejecutable de guix-daemon actualmente instalado sea marcado como guix_daemon_exec_t, en vez de usar una expresión regular amplia. La desventaja es que root tendría que instalar o actualizar la política en tiempo de instalación cada vez que se actualizase el paquete de Guix que proporcione el ejecutable de guix-daemon realmente en ejecución.

Invocación de guix-daemon
=========================

El programa guix-daemon implementa toda la funcionalidad para acceder al almacén. Esto incluye iniciar procesos de construcción, ejecutar el recolector de basura, comprobar la disponibilidad de un resultado de construcción, etc. Normalmente se ejecuta como root así:

     # guix-daemon --build-users-group=guixbuild

Para detalles obre como configurarlo, see Preparación del daemon.

Por defecto, guix-daemon inicia los procesos de construcción bajo distintos UIDs, tomados del grupo de construcción especificado con --build-users-group. Además, cada proceso de construcción se ejecuta en un entorno ``chroot'' que únicamente contiene el subconjunto del almacén del que depende el proceso de construcción, como especifica su derivación (see derivación), más un conjunto específico de directorios del sistema. Por defecto, estos directorios contienen /dev y /dev/pts. Es más, sobre GNU/Linux, el entorno de construcción es un contenedor: además de tener su propio árbol del sistema de ficheros, tiene un espacio de nombres de montado separado, su propio espacio de nombres de PID, de red, etc. Esto ayuda a obtener construcciones reproducibles (see Características).

Cuando el daemon realiza una construcción en delegación de la usuaria, crea un directorio de construcción bajo /tmp o bajo el directorio especificado por su variable de entorno TMPDIR. Este directorio se comparte con el contenedor durante toda la construcción, aunque dentro del contenedor el árbol de construcción siempre se llama /tmp/guix-build-NOMBRE.drv-0.

El directorio de construcción se borra automáticamente una vez completado el proceso, a menos que la construcción fallase y se especificase en el cliente --keep-failed (see --keep-failed).

El daemon espera conexiones y lanza un subproceso por sesión iniciada por cada cliente (una de las sub-órdenes de guix). La orden guix processes le permite tener una visión general de la actividad de su sistema mostrando clientes y sesiones activas. See Invocación de guix processes, para más información.

Se aceptan las siguientes opciones de línea de ordenes:

--build-users-group=GRUPO
     Toma las usuarias de GRUPO para ejecutar los procesos de construcción (see build users).

--no-substitutes
     No usa sustituciones para la construcción de productos. Esto es, siempre realiza las construcciones localmente en vez de permitir la descarga de binarios pre-construidos (see Sustituciones).

     Cuando el daemon se ejecuta con --no-substitutes, los clientes aún pueden activar explícitamente las sustituciones via la llamada de procedimiento remoto set-build-options (see El almacén).

--substitute-urls=URLS
     Considera URLS la lista separada por espacios predeterminada de URLs de sustituciones de fuentes. Cuando se omite esta opción, se usa https://ci.guix.es.info.

     Esto significa que las sustituciones puede ser descargadas de URLS, mientras estén firmadas por una firma de confianza (see Sustituciones).

--no-build-hook
     No usa el hook de construcción.

     El hook de construcción es un programa auxiliar que el daemon puede lanzar y al cual envía las peticiones de construcción. Este mecanismo se utiliza para delegar construcciones a otras máquinas (see Configuración de delegación del daemon).

--cache-failures
     Almacena en la caché los fallos de construcción. Por defecto, únicamente las construcciones satisfactorias son almacenadas en la caché.

     Cuando se usa esta opción, guix gc --list-failures puede usarse para consultar el conjunto de elementos del almacén marcados como fallidos; guix gc --clear-failures borra los elementos del almacén del conjunto de fallos existentes en la caché. See Invocación de guix gc.

--cores=N
-c N
     Usa N núcleos de la CPU para construir cada derivación; 0 significa tantos como haya disponibles.

     El valor predeterminado es 0, pero puede ser sobreescrito por los clientes, como la opción --cores de guix build (see Invocación de guix build).

     El efecto es definir la variable de entorno NIX_BUILD_CORES en el proceso de construcción, el cual puede usarla para explotar el paralelismo interno---por ejemplo, ejecutando make -j$NIX_BUILD_CORES.

--max-jobs=N
-M N
     Permite como máximo N trabajos de construcción en paralelo. El valor predeterminado es 1. Fijarlo a 0 significa que ninguna construcción se realizará localmente; en vez de eso, el daemon delegará las construcciones (see Configuración de delegación del daemon), o simplemente fallará.

--max-silent-time=SEGUNDOS
     Cuando la construcción o sustitución permanece en silencio más de SEGUNDOS, la finaliza e informa de un fallo de construcción.

     El valor predeterminado es 0, que deshabilita el plazo.

     El valor especificado aquí puede ser sobreescrito por clientes (see --max-silent-time).

--timeout=SEGUNDOS
     Del mismo modo, cuando el proceso de construcción o sustitución dura más de SEGUNDOS, lo termina e informa un fallo de construcción.

     El valor predeterminado es 0, que deshabilita el plazo.

     El valor especificado aquí puede ser sobreescrito por los clientes (see --timeout).

--rounds=N
     Construye cada derivación N veces seguidas, y lanza un error si los resultados de las construcciones consecutivas no son idénticos bit-a-bit. Fíjese que esta configuración puede ser sobreescrita por clientes como guix build (see Invocación de guix build).

     Cuando se usa conjuntamente con --keep-failed, la salida que difiere se mantiene en el almacén, bajo /gnu/store/...-check. Esto hace fácil buscar diferencias entre los dos resultados.

--debug
     Produce salida de depuración.

     Esto es útil para depurar problemas en el arranque del daemon, pero entonces puede ser cambiado el comportamiento por los clientes, por ejemplo la opción --verbosity de guix build (see Invocación de guix build).

--chroot-directory=DIR
     Añade DIR al chroot de construcción.

     Hacer esto puede cambiar el resultado del proceso de construcción---por ejemplo si usa dependencias opcionales, que se encuentren en DIR, cuando están disponibles, y no de otra forma. Por esa razón, no se recomienda hacerlo. En vez de eso, asegurese que cada derivación declara todas las entradas que necesita.

--disable-chroot
     Deshabilita las construcciones en un chroot.

     No se recomienda el uso de esta opción ya que, de nuevo, podría permitir a los procesos de construcción ganar acceso a dependencias no declaradas. Es necesario, no obstante, cuando guix-daemon se ejecuta bajo una cuenta de usuaria sin privilegios.

--log-compression=TIPO
     Comprime los logs de construcción de acuerdo a TIPO, que puede ser gzip, bzip2 o none.

     A menos que se use --lose-logs, todos los log de construcción se mantienen en LOCALSTATEDIR. Para ahorrar espacio, el daemon automáticamente los comprime con bzip2 por defecto.

--disable-deduplication
     Deshabilita la ``deduplicación'' automática en el almacén.

     Por defecto, los ficheros se añaden al almacén ``deduplicados'' automáticamente: si un nuevo fichero añadido es idéntico a otro que ya se encuentra en el almacén, el daemon introduce el nuevo fichero como un enlace duro al otro fichero. Esto puede reducir notablemente el uso del disco, a expensas de una carga de entrada/salida ligeramente incrementada al finalizar un proceso de construcción. Esta opción deshabilita esta optimización.

--gc-keep-outputs[=yes|no]
     Determina si el recolector de basura (GC) debe mantener salidas de las derivaciones vias.

     Cuando se usa ``yes'', el recolector de basura mantendrá las salidas de cualquier derivación viva disponible en el almacén---los ficheros .drv. El valor predeterminado es ``no'', lo que significa que las salidas de las derivaciones se mantienen únicamente si son alcanzables desde alguna raíz del recolector de basura. See Invocación de guix gc, para más información sobre las raices del recolector de basura.

--gc-keep-derivations[=yes|no]
     Determina si el recolector de basura (GC) debe mantener derivaciones correspondientes a salidas vivas.

     Cuando se usa ``yes'', como es el caso predeterminado, el recolector de basura mantiene derivaciones---es decir, ficheros .drv---mientras al menos una de sus salidas está viva. Esto permite a las usuarias seguir la pista de los orígenes de los elementos en el almacén. El uso de ``no'' aquí ahorra un poco de espacio en disco.

     De este modo, usar --gc-keep-derivations con valor ``yes'' provoca que la vitalidad fluya de salidas a derivaciones, y usar --gc-keep-outputs con valor ``yes'' provoca que la vitalidad fluya de derivaciones a salidas. Cuando ambas tienen valor ``yes'', el efecto es mantener todos los prerrequisitos de construcción (las fuentes, el compilador, las bibliotecas y otras herramientas de tiempo de construcción) de los objetos vivos del almacén, independientemente de que esos prerrequisitos sean alcanzables desde una raíz del recolector de basura. Esto es conveniente para desarrolladoras ya que ahorra reconstrucciones o descargas.

--impersonate-linux-2.6
     En sistemas basados en Linux, suplanta a Linux 2.6. Esto significa que la llamada del sistema uname del kernel indicará 2.6 como el número de publicación.

     Esto puede ser útil para construir programas que (habitualmente de forma incorrecta) dependen en el número de versión del núcleo.

--lose-logs
     No guarda logs de construcción. Por defecto se almacenan bajo LOCALSTATEDIR/guix/log.

--system=SISTEMA
     Asume SISTEMA como el tipo actual de sistema. Por defecto es el par de arquitectura/núcleo encontrado durante la configuración, como x86_64-linux.

--listen=DESTINO
     Escucha conexiones en DESTINO. DESTINO se interpreta como el nombre del fichero del socket de dominio Unix si comienza on / (barra a la derecha). En otro caso, DESTINO se interpreta como un nombre de máquina o un nombre de máquina y puerto a escuchar. Aquí van unos pocos ejemplos:

     --listen=/gnu/var/daemon
          Escucha por conexiones en el socket de dominio Unix /gnu/var/daemon, creandolo si es necesario.

     --listen=localhost
          Escucha conexiones TCP en la interfaz de red correspondiente a localhost, en el puerto 44146.

     --listen=128.0.0.42:1234
          Escucha conexiones TCP en la interfaz de red correspondiente a 128.0.0.42, en el puerto 1234.

     Esta opción puede repetirse múltiples veces, en cuyo caso guix-daemon acepta conexiones en todos los destinos especificados. Las usuarias pueden indicar a los clientes a qué destino conectarse fijando la variable de entorno GUIX_DAEMON_SOCKET (see GUIX_DAEMON_SOCKET).

          El protocolo del daemon no está autentificado ni cifrado. El uso de --listen=DIRECCIÓN es aceptable en redes locales, como clusters, donde únicamente los nodos de confianza pueden conectarse al daemon de construcción. En otros casos donde el acceso remoto al daemon es necesario, recomendamos usar sockets de dominio Unix junto a SSH.

     Cuando se omite --listen, guix-daemon escucha conexiones en el socket de dominio Unix que se encuentra en LOCALSTATEDIR/guix/daemon-socket/socket.

Configuración de la aplicación
==============================

Cuando se usa Guix sobre una distribución GNU/Linux distinta al sistema Guix---una distribución distinta---unos pocos pasos adicionales son necesarios para tener todo preparado. Aquí están algunos de ellos.

Localizaciones
--------------

Los paquetes instalados via Guix no usarán los datos de localización del sistema anfitrión. En vez de eso, debe primero instalar uno de los paquetes de localización disponibles con Guix y después definir la variable de entorno GUIX_LOCPATH:

     $ guix package -i glibc-locales
     $ export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale

Fíjese que el paquete glibc-locales contiene datos para todas las localizaciones que ofrece GNU libc y pesa alrededor de 110 MiB. Alternativamente, glibc-utf8-locales es más pequeño pero limitado a localizaciones UTF-8.

La variable GUIX_LOCPATH juega un rol similar a LOCPATH (see LOCPATH (The GNU C Library Reference Manual)). No obstante, hay dos diferencias importantes:

 1. GUIX_LOCPATH es respetada únicamente por la libc dentro de Guix, y no por la libc que proporcionan las distribuciones distintas. Por tanto, usar GUIX_LOCPATH le permite asegurarse de que los programas de la distribución distinta no cargarán datos de localización incompatibles.

 2. libc añade un sufijo a cada entrada de GUIX_LOCPATH con /X.Y, donde X.Y es la versión de libc---por ejemplo, 2.22. Esto significa que, en caso que su perfil Guix contenga una mezcla de programas enlazados contra diferentes versiones de libc, cada versión de libc únicamente intentará cargar datos de localización en el formato correcto.

Esto es importante porque el formato de datos de localización usado por diferentes versiones de libc puede ser incompatible.

Selector de servicios de nombres
--------------------------------

Cuando se usa Guix en una distribución distinta, recomendamos encarecidamente que el sistema ejecute el daemon de caché del servicio de nombres de la biblioteca de C de GNU, ncsd, que debe escuchar en el socket /var/run/nscd/socket. En caso de no hacerlo, las aplicaciones instaladas con Guix pueden fallar al buscar nombres de máquinas o cuentas de usuaria, o incluso pueden terminar abruptamente. Los siguientes párrafos explican por qué.

La biblioteca de C de GNU implementa un selector de servicios de nombres (NSS), que es un mecanismo extensible para ``búsquedas de nombres'' en general: resolución de nombres de máquinas, cuentas de usuaria y más (see Selector de servicios de nombres (The GNU C Library Reference Manual)).

Al ser extensible, NSS permite el uso de módulos, los cuales proporcionan nuevas implementaciones de búsqueda de nombres: por ejemplo, el módulo nss-mdns permite la resolución de nombres de máquina .local, el módulo nis permite la búsqueda de cuentas de usuaria usando el servicio de información de red (NIS), etc. Estos ``servicios de búsqueda'' extra se configuran para todo el sistema en /etc/nsswitch.conf, y todos los programas en ejecución respetan esta configuración (see NSS Configuration File (The GNU C Reference Manual)).

Cuando se realiza una búsqueda de nombres---por ejemplo, llamando a la función getaddrinfo en C---las aplicaciones primero intentarán conectar con nscd; en caso satisfactorio, nscd realiza la búsqueda de nombres en delegación suya. Si nscd no está ejecutándose, entonces realizan la búsqueda por ellas mismas, cargando los servicios de búsqueda de nombres en su propio espacio de direcciones y ejecutándola. Estos servicios de búsqueda de nombres---los ficheros libnss_*.so---son abiertos con dlopen, pero pueden venir de la biblioteca de C del sistema, en vez de la biblioteca de C contra la que la aplicación está enlazada (la biblioteca de C que viene en Guix).

Y aquí es donde está el problema: si su aplicación está enlazada contra la biblioteca de C de Guix (digamos, glibc 2.24) e intenta cargar módulos de otra biblioteca de C (digamos, libnss_mdns.so para glibc 2.22), probablemente terminará abruptamente o sus búsquedas de nombres fallarán inesperadamente.

Ejecutar nscd en el sistema, entre otras ventajas, elimina este problema de incompatibilidad binaria porque esos ficheros libnss_*.so se cargan en el proceso nscd, no en la aplicación misma.

Tipografías X11
---------------

La mayoría de aplicaciones gráficas usan Fontconfig para encontrar y cargar tipografías y realizar la renderización del lado del cliente X11. El paquete fontconfig en Guix busca tipografías en $HOME/.guix-profile por defecto. Por tanto, para permitir a aplicaciones gráficas instaladas con Guix mostrar tipografías, tiene que instalar las tipografías también con Guix. Paquetes esenciales de tipografías incluyen gs-fonts, font-dejavu y font-gnu-freefont-ttf.

Para mostrar texto escrito en lenguas chinas, Japonés o Coreano en aplicaciones gráficas, considere instalar font-adobe-source-han-sans o font-wqy-zenhei. La anterior tiene múltiples salidas, una por familia de lengua (see Paquetes con múltiples salidas). Por ejemplo, la siguiente orden instala tipografías para lenguas chinas:

     guix package -i font-adobe-source-han-sans:cn

Programas más antiguos como xterm no usan Fontconfig sino que dependen en el lado del servidor para realizar el renderizado de tipografías. Dichos programas requieren especificar un nombre completo de tipografía usando XLFD (Descripción lógica de tipografías X), como esta:

     -*-dejavu sans-medium-r-normal-*-*-100-*-*-*-*-*-1

Para ser capaz de usar estos nombres completos para las tipografías TrueType instaladas en su perfil Guix, necesita extender la ruta de fuentes del servidor X:

     xset +fp $(dirname $(readlink -f ~/.guix-profile/share/fonts/truetype/fonts.dir))

Después de eso, puede ejecutar xlsfonts (del paquete xlsfonts) para asegurarse que sus tipografías TrueType se enumeran aquí.

Después de instalar tipografías puede tener que refrescar la caché de tipografías para usarlas en las aplicaciones. Lo mismo aplica cuando las aplicaciones instaladas vía Guix no parecen encontrar tipografías. Para forzar la reconstrucción de la caché de tipografías ejecute fc-cache -f. La orden fc-cache es proporcionada por el paquete fontconfig.

Certificados X.509
------------------

El paquete nss-certs proporciona certificados X.509, que permiten a los programas verificar los servidores accedidos por HTTPS.

Cuando se usa Guix en una distribución distinta, puede instalar este paquete y definir las variables de entorno relevantes de modo que los paquetes sepan dónde buscar los certificados. See Certificados X.509, para información detallada.

Paquetes Emacs
--------------

Cuando instala paquetes Emacs con Guix, los ficheros elisp pueden estar tanto en $HOME/.guix-profile/share/emacs/site-lisp/ o en subdirectorios de $HOME/.guix-profile/share/emacs/site-lisp/guix.d/. El último directorio existe porque potencialmente pueden existir miles de paquetes Emacs, y almacenar todos sus ficheros en un directorio único puede no ser confiable (por conflictos de nombres). Por lo que pensamos que usar un directorio separado por cada paquete es una buena idea. Es muy similar a cómo el sistema de paquetes de Emacs organiza la estructura de ficheros (see Package Files (The GNU Emacs Manual)).

Por defecto, Emacs (el instalado con Guix) ``sabe'' donde se alojan estos paquetes, para que usted no tenga que realizar ninguna configuración. Si, por alguna razón, desea evitar la carga automática de paquetes Emacs instalados con Guix, puede hacerlo ejecutando Emacs con la opción --no-site-file (see Init File (The GNU Emacs Manual)).

La cadena de herramientas de GCC
--------------------------------

Guix ofrece paquetes de compiladores individuales como gcc, pero si necesita una cadena de herramientas completa para compilar y enlazar código fuente lo que realmente desea es el paquete gcc-toolchain. Este paquete proporciona una cadena de herramientas GCC para desarrollo C/C++, incluyendo el mismo GCC, la biblioteca de C GNU (cabeceras y binarios, más símbolos de desarrollo en la salida debug), Binutils y un recubrimiento del enlazador.

El propósito del recubrimiento es inspeccionar las opciones -L y -l proporcionadas al enlazador, y los correspondientes parámetros -rpath, y llamar al enlazador real con este nuevo conjunto de parámetros. Puede instruir al recubrimiento para rechazar el enlace contra bibliotecas que no se encuentren en el almacén fijando el valor de la variable de entorno GUIX_LD_WRAPPER_ALLOW_IMPURITIES a no.

Instalación del sistema
***********************

Esta sección explica cómo instalar el sistema Guix en una máquina. Guix, como gestor de paquetes, puede instalarse sobre un sistema GNU/Linux en ejecución, see Instalación.

     Está leyendo esta documentación con un lector Info. Para obtener detalles sobre su uso, presione la tecla RET (``retorno de carro'' o ``intro'') en el siguiente enlace: see Info reader (Stand-alone GNU Info). Presione después l para volver aquí.

     De manera alternativa, ejecute info info en otro terminal para mantener el manual disponible.

Limitaciones
============

We consider Guix System to be ready for a wide range of ``desktop'' and server use cases.  The reliability guarantees it provides---transactional upgrades and rollbacks, reproducibility---make it a solid foundation.

Nevertheless, before you proceed with the installation, be aware of the following noteworthy limitations applicable to version VERSION:

  * No está implementada la funcionalidad del gestor de volúmenes lógicos (LVM).

  * Se proporcionan más y más servicios del sistema (see Servicios), pero pueden faltar algunos.

  * GNOME, Xfce, LXDE, and Enlightenment are available (see Servicios de escritorio), as well as a number of X11 window managers.  However, KDE is currently missing.

More than a disclaimer, this is an invitation to report issues (and success stories!), and to join us in improving it.  See Contribuir, for more info.

Consideraciones sobre el hardware
=================================

GNU Guix se enfoca en respetar la libertad de computación de las usuarias. Se construye sobre el núcleo Linux-libre, lo que significa que únicamente funciona hardware para el que existen controladores y firmware libres. Hoy en día, un amplio rango del hardware común funciona con GNU/Linux-libre---desde teclados a tarjetas gráficas a escáneres y controladoras Ethernet. Desafortunadamente, todavía hay áreas donde los fabricantes de hardware deniegan a las usuarias el control de su propia computación, y dicho hardware no funciona en el sistema Guix.

One of the main areas where free drivers or firmware are lacking is WiFi devices.  WiFi devices known to work include those using Atheros chips (AR9271 and AR7010), which corresponds to the ath9k Linux-libre driver, and those using Broadcom/AirForce chips (BCM43xx with Wireless-Core Revision 5), which corresponds to the b43-open Linux-libre driver. Free firmware exists for both and is available out-of-the-box on Guix System, as part of %base-firmware (see firmware).

La Fundación del Software Libre (https://www.fsf.org/) patrocina Respeta Su Libertad (https://www.fsf.org/ryf) (RYF), un programa de certificación para productos hardware que respetan su libertad y su privacidad y se aseguran de que usted tenga el control sobre su dispositivo. Le recomendamos que compruebe la lista de dispositivos certificados RYF.

Otro recurso útil es el sitio web H-Node (https://wwww.h-node.org/). Contiene un catálogo de dispositivos hardware con información acerca su funcionalidad con GNU/Linux.

Instalación desde memoria USB y DVD
===================================

Se puede descargar una imagen de instalación ISO-9660 que puede ser escrita en una memoria USB o grabada en un DVD desde https://alpha.gnu.org/gnu/guix/guix-system-install-VERSION.SISTEMA.iso.xz, donde SISTEMA es uno de los siguientes valores:

x86_64-linux
     para un sistema GNU/Linux en CPUs compatibles con la arquitectura de 64-bits de Intel/AMD.

i686-linux
     para un sistema GNU/Linux en CPUs compatibles con la arquitectura de 32-bits de Intel.

Asegurese de descargar el fichero .sig asociado y de verificar la autenticidad de la imagen contra él, más o menos así:

     $ wget https://alpha.gnu.org/gnu/guix/guix-system-install-VERSION.SISTEMA.iso.xz.sig
     $ gpg --verify guix-system-install-VERSION.SISTEMA.iso.xz.sig

Si la orden falla porque no dispone de la clave pública necesaria, entonces ejecute esta otra orden para importarla:

     $ gpg --keyserver pool.sks-keyservers.net \
           --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5

y vuelva a ejecutar la orden gpg --verify.

Esta imagen contiene las herramientas necesarias para una instalación. Está pensada ara ser copiada tal cual a una memoria USB o DVD con espacio suficiente.

Copiado en una memoria USB
--------------------------

Para copiar la imagen en una memoria USB, siga estos pasos:

 1. Descomprima la imagen usando la orden xz:

          xz -d guix-system-install-VERSION.SISTEMA.iso.xz

 2. Conecte una memoria USB de 1 GiB o más a su máquina, y determine su nombre de dispositivo. Asumiendo que la memoria USB es /dev/sdX copie la imagen con:

          dd if=guix-system-install-VERSION.SISTEMA.iso of=/dev/sdX
          sync

     El acceso a /dev/sdX normalmente necesita privilegios de root.

Grabación en un DVD
-------------------

Para copiar la imagen a un DVD, siga estos pasos:

 1. Descomprima la imagen usando la orden xz:

          xz -d guix-system-install-VERSION.SISTEMA.iso.xz

 2. Introduzca un DVD escribible en su máquina, y determine el nombre del dispositivo. Asumiendo que la unidad DVD es /dev/srX, copie la imagen con:

          growisofs -dvd-compat -Z /dev/srX=guix-system-install-VERSION.SISTEMA.iso

     El acceso a /dev/srX normalmente necesita privilegios de root.

Arranque
--------

Una vez hecho esto, debe ser capaz de reiniciar el sistema y arrancar desde la memoria USB o el DVD. Lo primero habitualmente requiere que introducirse en la BIOS o en el menú de arranque UEFI, donde se puede seleccionar el arranque desde la memoria USB.

See Instalación de Guix en una máquina virtual, si, en vez de esto, desea instalar el sistema Guix en una máquina virtual (VM).

Preparación para la instalación
===============================

Una vez que haya arrancado, puede usar el instalador gráfico guiado, el cual facilita la introducción al sistema (see Instalación gráfica guiada). Alternativamente, si ya es está familiarizada con GNU/Linux y desea más control que el que proporciona el instalador gráfico, puede seleccionar el proceso de instalación ``manual'' (see Instalación manual).

El instalador gráfico está disponible en TTY1. Puede obtener consolas de root en los TTY 3 a 6 pulsando ctrl-alt-f3, ctrl-alt-f4, etc. TTY2 muestra esta documentación y se puede cambiar a dicha consola con ctrl-alt-f2. La documentación es explorable usando las órdenes del lector Info (see Stand-alone GNU Info). El sistema de instalación ejecuta el daemon GPM para ratones, el cual le permite seleccionar texto con el botón izquierdo y pegarlo con el botón central.

     La instalación requiere acceso a Internet de modo que cualquier dependencia de su configuración de sistema no encontrada pueda ser descargada. Véase la sección ``Red'' más adelante.

Instalación gráfica guiada
==========================

El instalador gráfico es una interfaz de usuaria basada en texto. Le guiará, con cajas de diálogo, a través de los pasos necesarios para instalar el sistema GNU Guix.

Las primeras cajas de diálogo le permiten configurar el sistema mientras lo usa durante la instalación: puede seleccionar el idioma, la distribución del teclado y configurar la red, la cual se usará durante la instalación. La siguiente imagen muestra el diálogo de configuración de red.

configuración de red en la instalación gráfica

Los siguientes pasos le permitirán particionar su disco duro, como se muestra en la siguiente imagen, elegir si se usarán o no sistemas de ficheros cifrados, introducir el nombre de la máquina, la contraseña de root y crear cuentas adicionales, entre otras cosas.

particionado en la instalación gráfica

Tenga en cuenta que, en cualquier momento, el instalador le permite salir de la instalación actual y retomarla en un paso previo, como se muestra en la siguiente imagen.

retomado del proceso de instalación

Una vez haya finalizado, el instalador produce una configuración de sistema operativo y la muestra (see Uso de la configuración del sistema). En este punto puede pulsar ``OK'' y la instalación procederá. En caso de finalización satisfactoria, puede reiniciar con el nuevo sistema y disfrutarlo. ¡See Tras la instalación del sistema para ver cómo proceder a continuación!

Instalación manual
==================

Esta sección describe como podría instalar ``manualmente'' el sistema GNU Guix en su máquina. Esta opción requiere familiaridad con GNU/Linux, con el shell y con las herramientas de administración comunes. Si puensa que no es para usted, considere el uso del instalador gráfico guiado (see Instalación gráfica guiada).

El sistema de instalación proporciona consolas de root en los terminales virtuales (TTY) 3 a 6; pulse ctrl-alt-f3, ctrl-alt-f4 y sucesivas teclas para abrirlas. Incluye muchas herramientas comunes necesarias para la instalación del sistema. Pero es también un sistema Guix completo, lo que significa que puede instalar paquetes adicionales, en caso de necesitarlos, mediante el uso de guix package (see Invocación de guix package).

Distribución de teclado, red y particionado
-------------------------------------------

Antes de instalar el sistema, puede desear ajustar la distribución del teclado, configurar la red y particionar el disco duro deseado. Esta sección le guiará durante este proceso.

Distribución de teclado
.......................

La imagen de instalación usa la distribución de teclado QWERTY de los EEUU. Si desea cambiarla, puede usar la orden loadkeys. Por ejemplo, la siguiente orden selecciona la distribución de teclado para el castellano:

     loadkeys es

Véanse los ficheros bajo /run/current-system/profile/share/keymaps para la obtención de una lista de distribuciones de teclado disponibles. Ejecute man loadkeys para más información.

Red
...

Ejecute la siguiente orden para ver los nombres asignados a sus interfaces de red:

     ifconfig -a

... o, usando la orden específica de GNU/Linux ip:

     ip a

El nombre de las interfaces de cable comienza con e; por ejemplo, la interfaz que corresponde a la primera controladora Ethernet en la placa se llama eno1. El nombre de las interfaces inalámbricas comienza con w, como w1p2s0.

Conexión por cable
     Para configurar una red por cable ejecute la siguiente orden, substituyendo INTERFAZ con el nombre de la interfaz de cable que desea usar.

          ifconfig INTERFAZ up

Conexión sin cable
     Para configurar una red inalámbrica, puede crear un fichero de configuración para la herramienta de configuración wpa_supplicant (su ruta no es importante) usando uno de los editores de texto disponibles como nano:

          nano wpa_supplicant.conf

     Como un ejemplo, la siguiente plantilla puede colocarse en este fichero y funcionará para muchas redes inalámbricas, siempre que se proporcione el SSID y la contraseña reales de la red a la que se va a conectar:

          network={
            ssid="MI-SSID"
            key_mgmt=WPA-PSK
            psk="la contraseña de la red"
          }

     Inicie el servicio inalámbrico y ejecutelo en segundo plano con la siguiente orden (sustituya INTERFAZ por el nombre de la interfaz de red que desea usar):

          wpa_supplicant -c wpa_supplicant.conf -i INTERFAZ -B

     Ejecute man wpa_supplicant para más información.

En este punto, necesita obtener una dirección IP. En una red donde las direcciones IP se asignan automáticamente mediante DHCP, puede ejecutar:

     dhclient -v INTERFAZ

Intente hacer ping a un servidor para comprobar si la red está funcionando correctamente:

     ping -c 3 gnu.org

Configurar el acceso por red es casi siempre un requisito debido a que la imagen no contiene todo el software y las herramientas que puedan ser necesarias.

Si lo desea, puede continuar la instalación de forma remota iniciando un servidor SSH:

     herd start ssh-daemon

Asegurese de fijar una contraseña con passwd, o configurar la verificación de clave pública de OpenSSH para la introducción en el sistema.

Particionado de discos
......................

A menos que se haya realizado previamente, el siguiente paso es el particionado, y después dar formato a la/s partición/es deseadas.

La imagen de instalación contiene varias herramientas de particionado, incluyendo Parted (see Overview (GNU Parted User Manual)), fdisk y cfdisk. Ejecutelo y configure el mapa de particiones deseado en su disco:

     cfdisk

Si su disco usa el formato de tabla de particiones GUID (GPT) y tiene pensado instalar GRUB basado en BIOS (la opción predeterminada), asegurese de tener una partición de arranque BIOS disponible (see BIOS installation (GNU GRUB manual)).

Si en vez de eso desea GRUB basado en EFI, se requiere una Partición del Sistema EFI (ESP) con formato FAT32. Esta partición puede montarse en /boot/efi y debe tener la opción esp activa. Por ejemplo, en parted:

     parted /dev/sda set 1 esp on

     ¿No esta segura si usar GRUB basado en EFI o en BIOS? Si el directorio /sys/firmware/efi existe en la imagen de instalación, probablemente debería realizar una instalación EFI, usando grub-efi-bootloader. En otro caso, debe usar GRUB basado en BIOS, conocido como grub-bootloader. See Configuración del gestor de arranque, para más información sobre cargadores de arranque.

Una vez haya terminado con el particionado de la unidad de disco deseada, tiene que crear un sistema de ficheros en la o las particiónes relevantes (Actualmente el sistema Guix únicamente permite sistemas de ficheros ext4 y btrfs. En particular, el código que lee UUIDs del sistema de ficheros y etiquetas únicamente funciona para dichos sistemas de ficheros.). Para la ESP, si tiene una y asumiendo que es /dev/sda1, ejecute:

     mkfs.fat -F32 /dev/sda1

Preferentemente, asigne una etiqueta a los sistemas de ficheros de modo que pueda referirse a ellos de forma fácil y precisa en las declaraciones file-system (see Sistemas de ficheros). Esto se consigue habitualmente con la opción -L de mkfs.ext4 y las ordenes relacionadas. Por tanto, asumiendo que la partición de la raíz es /dev/sda2, se puede crear un sistema de ficheros con la etiqueta mi-raiz de esta manera:

     mkfs.ext4 -L mi-raiz /dev/sda2

Si en vez de eso planea cifrar la partición raíz, puede usar las herramientas Crypsetup/LUKS para hacerlo (véase man cryptsetup para más información). Asumiendo que quiere almacenar la partición raíz en /dev/sda2, la secuencia de ordenes sería más o menos así:

     cryptsetup luksFormat /dev/sda2
     cryptsetup open --type luks /dev/sda1 mi-particion
     mkfs.ext4 -L mi-raiz /dev/mapper/mi-particion

Una vez hecho esto, monte el sistema de ficheros deseado bajo /mnt con una orden como (de nuevo, asumiendo que mi-raiz es la etiqueta del sistema de ficheros raíz):

     mount LABEL=mi-raiz /mnt

Monte también cualquier otro sistema de ficheros que desee usar en el sistema resultante relativamente a esta ruta. Si ha optado por /boot/efi como el punto de montaje de EFI, por ejemplo, ahora debe ser montada en /mnt/boot/efi para que guix system init pueda encontrarla más adelante.

Finalmente, si planea usar una o más particiones de intercambio (see swap space (The GNU C Library Reference Manual)), asegurese de inicializarla con mkswap. Asumiendo que tuviese una partición de intercambio en /dev/sda3, ejecutaría:

     mkswap /dev/sda3
     swapon /dev/sda3

De manera alternativa, puede usar un fichero de intercambio. Por ejemplo, asumiendo que en el nuevo sistema desea usar el fichero /fichero-de-intercambio como tal, ejecutaría (Este ejemplo funcionará para muchos tipos de sistemas de ficheros (por ejemplo, ext4). No obstante, para los sistemas de ficheros con mecanismos de copia-durante-escritura (por ejemplo, btrfs) los pasos pueden diferir. Para obtener más detalles, véanse las páginas de manual para mkswap y swapon.):

     # Esto son 10GiB de espacio de intercambio. Ajuste "count" para
     # cambiar el tamaño.
     dd if=/dev/zero of=/mnt/swapfile bs=1MiB count=10240
     # Por seguridad, se mantiene el fichero únicamente legible y
     # escribible por root.
     chmod 600 /mnt/swapfile
     mkswap /mnt/swapfile
     swapon /mnt/swapfile

Fijese que si ha cifrado la partición raíz y creado un fichero de intercambio en su sistema de ficheros como se ha descrito anteriormente, el cifrado también protege al fichero de intercambio, como a cualquier fichero en dicho sistema de ficheros.

Procedimiento de instalación
----------------------------

Con las particiones deseadas listas y la raíz deseada montada en /mnt, estamos preparadas para empezar. Primero, ejecute:

     herd start cow-store /mnt

Esto activa la copia-durante-escritura en /gnu/store, de modo que los paquetes que se añadan durante la fase de instalación se escriban en el disco montado en /mnt en vez de permanecer en memoria. Esto es necesario debido a que la primera fase de la orden guix system init (vea más adelante) implica descargas o construcciones en /gnu/store, el cual, inicialmente, está un sistema de ficheros en memoria.

Después debe editar un fichero y proporcionar la declaración de sistema operativo a instalar. Para dicho fin, el sistema de instalación viene con tres editores de texto. Recomendamos GNU nano (see GNU nano Manual), que permite el resaltado de sintaxis y correspondencia de paréntesis; los otros editores son GNU Zile (un clon de Emacs) y nvi (un clon del editor vi original de BSD). Le recomendamos encarecidamente almacenar ese fichero en el sistema de ficheros raíz, digamos, como /mnt/etc/config.scm. En caso de no hacerlo, habrá perdido su configuración del sistema una vez arranque en el sistema recién instalado.

See Uso de la configuración del sistema, para hacerse una idea del fichero de configuración. Las configuraciones de ejemplo mencionadas en esa sección están disponibles bajo /etc/configuration en la imagen de instalación. Por tanto, para empezar con una configuración del sistema que proporcione un servidor gráfico (un sistema de ``escritorio''), puede ejecutar algo parecido a estas órdenes:

     # mkdir /mnt/etc
     # cp /etc/configuration/desktop.scm /mnt/etc/config.scm
     # nano /mnt/etc/config.scm

Debe prestar atención a lo que su fichero de configuración contiene, y en particular:

  * Asegurese que la forma bootloader-configuration especifica la localización deseada de la instalación de GRUB. Debe mencionar grub-bootloader si está usando GRUB con el arranque antiguo, o grub-efi-bootloader para sistemas más nuevos UEFI. Para los sistemas antiguos, el campo target denomina un dispositivo, como /dev/sda; para los sistemas UEFI denomina la ruta de una partición EFI montada, como /boot/efi; asegurese de que la ruta está actualmente montada y haya una entrada file-system especificada en su configuración.

  * Asegurese que las etiquetas de su sistema de ficheros corresponden con el valor de sus campos device respectivos en su configuración file-system, asumiendo que su configuración file-system usa el procedimiento file-system-label en su campo device.

  * Si hay particiones cifradas o en RAID, asegurese de añadir un campo mapped-devices para describirlas (see Dispositivos traducidos).

Una vez haya terminado de preparar el fichero de configuración, el nuevo sistema debe ser inicializado (recuerde que el sistema de ficheros raíz deseado está montado bajo /mnt):

     guix system init /mnt/etc/config.scm /mnt

Esto copia todos los ficheros necesarios e instala GRUB en /dev/sdX, a menos que proporcione la opción --no-bootloader. Para más información, see Invocación de guix system. Esta orden puede desencadenar descargas o construcciones de paquetes no encontrados, lo cual puede tomar algún tiempo.

Una vez que la orden se complete---¡y, deseablemente, de forma satisfactoria!---puede ejecutar reboot y arrancar con el nuevo sistema. La contraseña de root en el nuevo sistema está vacía inicialmente; otras contraseñas de usuarias tienen que ser inicializadas ejecutando la orden passwd como root, a menos que en su configuración se especifique de otra manera (see contraseñas de cuentas de usuaria). ¡See Tras la instalación del sistema para proceder a continuación!

Tras la instalación del sistema
===============================

¡Éxito! ¡Ha arrancado en el sistema Guix! De ahora en adelante, puede actualizar el sistema cuando quiera mediante la ejecución de, digamos:

     guix pull
     sudo guix system reconfigure /etc/config.scm

Esto construye una nueva generación del sistema con los últimos paquetes y servicios (see Invocación de guix system). Recomendamos realizarlo de manera regular de modo que su sistema incluya las últimas actualizaciones de seguridad (see Actualizaciones de seguridad).

     Tenga en cuenta que sudo guix ejecuta el ejecutable guix de su usuaria y no el de root, ya que sudo no altera PATH. Para ejecutar explícitamente el ejecutable guix de root, escriba sudo -i guix ....

¡Unase a nosotras en #guix en la red IRC Freenode o en guix-devel@gnu.org para compartir su experiencia!

Instalación de Guix en una máquina virtual
==========================================

Si desea instalar el sistema Guix en una máquina virtual (VM) o en un servidor privado virtual (VPS) en vez de en su preciada máquina, esta sección es para usted.

Si quiere arrancar una VM QEMU (http://qemu.org/) para instalar el sistema Guix en una imagen de disco, siga estos pasos:

 1. Primero, obtenga y descomprima la imagen de instalación del sistema Guix como se ha descrito previamente (see Instalación desde memoria USB y DVD).

 2. Cree una imagen de disco que contendrá el sistema instalado. Para crear una imagen de disco con formato qcow2, use la orden qemu-img:

          qemu-img create -f qcow2 guixsd.img 50G

     El fichero que obtenga será mucho menor de 50GB (típicamente menos de 1MB), pero crecerá cuando el dispositivo de almacenamiento virtualizado se vaya llenando.

 3. Arranque la imagen de instalación USB en una máquina virtual:

          qemu-system-x86_64 -m 1024 -smp 1 \
            -net user -net nic,model=virtio -boot menu=on \
            -drive file=guix-system-install-VERSION.SISTEMA.iso \
            -drive file=guixsd.img

     El orden de las unidades importa.

     En la consola de la VM, pulse rápidamente la tecla F12 para entrar al menú de arranque. Pulse la tecla 2 y la tecla RET para confirmar su selección.

 4. Ahora es root en la VM, prosiga con el procedimiento de instalación. See Preparación para la instalación, y siga las instrucciones.

Una vez complete la instalación, puede arrancar el sistema que está en la imagen guixsd.img. See Ejecutar Guix en una máquina virtual, para información sobre cómo hacerlo.

Construcción de la imagen de instalación
========================================

La imagen de instalación descrita anteriormente se construyó usando la orden guix system, específicamente:

     guix system disk-image --file-system-type=iso9660 \
       gnu/system/install.scm

Eche un vistazo a gnu/system/install.scm en el árbol de fuentes, y vea también Invocación de guix system para más información acerca de la imagen de instalación.

Construcción de la imagen de instalación para placas ARM
========================================================

Muchas placas ARM necesitan una variante específica del cargador de arranque U-Boot (http://www.denx.de/wiki/U-Boot/).

Si construye una imagen de disco y el cargador de arranque no está disponible de otro modo (en otra unidad de arranque, etc.), es recomendable construir una imagen que incluya el cargador, específicamente:

     guix system disk-image --system=armhf-linux -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")'

A20-OLinuXino-Lime2 es el nombre de la placa. Si especifica una placa no válida, una lista de placas posibles será mostrada.

Gestión de paquetes
*******************

El propósito de GNU Guix es permitir a las usuarias instalar, actualizar y borrar fácilmente paquetes de software, sin tener que conocer acerca de sus procedimientos de construcción o dependencias. Guix también va más allá de este conjunto obvio de características.

Este capítulo describe las principales características de Guix, así como las herramientas de gestión de paquetes que ofrece. Junto a la interfaz de línea de órdenes descrita a continuación (see guix package, también puede usar la interfaz Emacs-Guix (see The Emacs Guix Reference Manual), tras la instalación del paquete emacs-guix (ejecute la orden M-x guix-help para iniciarse en su uso):

     guix package -i emacs-guix

Características
===============

Cuando se usa Guix, cada paquete se encuentra en el almacén de paquetes, en su propio directorio---algo que se asemeja a /gnu/store/xxx-paquete-1.2, donde xxx es una cadena en base32.

En vez de referirse a estos directorios, las usuarias tienen su propio perfil, el cual apunta a los paquetes que realmente desean usar. Estos perfiles se almacenan en el directorio de cada usuaria, en $HOME/.guix-profile.

Por ejemplo, alicia instala GCC 4.7.2. Como resultado, /home/alicia/.guix-profile/bin/gcc apunta a /gnu/store/...-gcc-4.7.2/bin/gcc. Ahora, en la misma máquina, rober ha instalado ya GCC 4.8.0. El perfil de rober simplemente sigue apuntando a /gnu/store/...-gcc-4.8.0/bin/gcc---es decir, ambas versiones de GCC pueden coexistir en el mismo sistema sin ninguna interferencia.

La orden guix package es la herramienta central para gestión de paquetes (see Invocación de guix package). Opera en los perfiles de usuaria, y puede ser usada con privilegios de usuaria normal.

La orden proporciona las operaciones obvias de instalación, borrado y actualización. Cada invocación es en realidad una transacción: o bien la operación especificada se realiza satisfactoriamente, o bien nada sucede. Por tanto, si el proceso guix package es finalizado durante una transacción, o un fallo eléctrico ocurre durante la transacción, el perfil de usuaria permanece en su estado previo, y permanece usable.

Además, cualquier transacción de paquetes puede ser vuelta atrás. Si, por ejemplo, una actualización instala una nueva versión de un paquete que resulta tener un error importante, las usuarias pueden volver a la instancia previa de su perfil, de la cual se tiene constancia que funcionaba bien. De igual modo, la configuración global del sistema en Guix está sujeta a actualizaciones transaccionales y vuelta atrás (see Uso de la configuración del sistema).

Todos los paquetes en el almacén de paquetes pueden ser eliminados por el recolector de basura. Guix puede determinar qué paquetes están siendo todavía referenciados por los perfiles de usuarias, y eliminar aquellos que, de forma demostrable, no están referenciados (see Invocación de guix gc). Las usuarias pueden también borrar explícitamente generaciones antiguas de su perfil para que los paquetes referenciados en ellas puedan ser recolectadas.

Guix toma una aproximación puramente funcional en la gestión de paquetes, como se describe en la introducción (see Introducción). Cada nombre de directorio de paquete en /gnu/store contiene un hash de todas las entradas que fueron usadas para construir el paquete---compilador, bibliotecas, guiones de construcción, etc. Esta correspondencia directa permite a las usuarias asegurarse que una instalación dada de un paquete corresponde al estado actual de su distribución. Esto también ayuda a maximizar la reproducibilidad de la construcción: gracias al uso de entornos aislados de construcción, una construcción dada probablemente generará ficheros idénticos bit-a-bit cuando se realice en máquinas diferentes (see container).

Estos cimientos permiten a Guix ofrecer despliegues transparentes de binarios/fuentes. Cuando un binario pre-construido para un elemento de /gnu/store está disponible para descarga de una fuente externa---una sustitución, Guix simplemente lo descarga y desempaqueta; en otro caso construye el paquete de las fuentes, localmente (see Sustituciones). Debido a que los resultados de construcción son normalmente reproducibles bit-a-bit, las usuarias no tienen que confiar en los servidores que proporcionan sustituciones: pueden forzar una construcción local y retar a las proveedoras (see Invocación de guix challenge).

El control sobre el entorno de construcción es una característica que también es útil para desarrolladoras. La orden guix environment permite a desarrolladoras de un paquete configurar rápidamente el entorno de desarrollo correcto para su paquete, sin tener que instalar manualmente las dependencias del paquete en su perfil (see Invocación de guix environment).

Todo Guix y sus definiciones de paquetes están bajo control de versiones, y guix pull le permite ``viajar en el tiempo'' por la historia del mismo Guix (see Invocación de guix pull). Esto hace posible replicar una instancia de Guix en una máquina diferente o en un punto posterior del tiempo, lo que a su vez le permite replicar entornos de software completos, mientras que mantiene un preciso seguimiento de la procedencia del software.

Invocación de guix package
==========================

La orden guix package es la herramienta que permite a las usuarias instalar, actualizar y borrar paquetes, así como volver a configuraciones previas. Opera únicamente en el perfil propio de la usuaria, y funciona con privilegios de usuaria normal (see Características). Su sintaxis es:

     guix package OPCIONES

Primariamente, OPCIONES especifica las operaciones a ser realizadas durante la transacción. Al completarse, un nuevo perfil es creado, pero las generaciones previas del perfil permanecen disponibles, en caso de que la usuaria quisiera volver atrás.

Por ejemplo, para borrar lua e instalar guile y guile-cairo en una única transacción:

     guix package -r lua -i guile guile-cairo

guix package también proporciona una aproximación declarativa, donde la usuaria especifica el conjunto exacto de paquetes a poner disponibles y la pasa a través de la opción --manifest (see --manifest).

Para cada usuaria, un enlace simbólico al perfil predeterminado de la usuaria es creado en $HOME/.guix-profile. Este enlace simbólico siempre apunta a la generación actual del perfil predeterminado de la usuaria. Por lo tanto, las usuarias pueden añadir $HOME/.guix-profile/bin a su variable de entorno PATH, y demás. Si no está usando la Distribución de Sistema Guix, considere añadir las siguientes líneas a su ~/.bash_profile (see Bash Startup Files (The GNU Bash Reference Manual)) de modo que los shell lanzados a partir de entonces obtengan todas las definiciones de variables de entorno correctas:

     GUIX_PROFILE="$HOME/.guix-profile" ; \
     source "$HOME/.guix-profile/etc/profile"

En una configuración multiusuaria, los perfiles de usuaria se almacenan en un lugar registrado como una raíz del sistema de ficheros, a la que apunta $HOME/.guix-profile (see Invocación de guix gc). Ese directorio normalmente es LOCALSTATEDIR/guix/profiles/per-user/USUARIA, donde LOCALSTATEDIR es el valor pasado a configure como --localstatedir y USUARIA es el nombre de usuaria. El directorio per-user se crea cuando se lanza guix-daemon, y el subdirectorio USUARIA es creado por guix package.

Las OPCIONES pueden ser las siguientes:

--install=PAQUETE ...
-i PAQUETE ...
     Instala los PAQUETEs especificados.

     Cada PAQUETE puede especificar un nombre simple de paquete, como por ejemplo guile, o un nombre de paquete seguido por una arroba y el número de versión, como por ejemplo guile@1.8.8 o simplemente guile@1.8 (en el último caso la última versión con 1.8 como prefijo es seleccionada).

     Si no se especifica un número de versión, la última versión disponible será seleccionada. Además, PAQUETE puede contener dos puntos, seguido por el nombre de una de las salidas del paquete, como en gcc:doc o binutils@2.22:lib (see Paquetes con múltiples salidas). Los paquetes con el nombre correspondiente (y opcionalmente la versión) se buscan entre los módulos de la distribución GNU (see Módulos de paquetes).

     A veces los paquetes tienen entradas propagadas: estas son las dependencias que se instalan automáticamente junto al paquete requerido (see propagated-inputs in package objects, para información sobre las entradas propagadas en las definiciones de paquete).

     Un ejemplo es la biblioteca GNU MPC: sus ficheros de cabecera C hacen referencia a los de la biblioteca GNU MPFR, que a su vez hacen referencia a los de la biblioteca GMP. Por tanto, cuando se instala MPC, las bibliotecas MPFR y GMP también se instalan en el perfil; borrar MPC también borra MPFR y GMP---a menos que también se hayan instalado explícitamente por la usuaria.

     Por otra parte, los paquetes a veces dependen de la definición de variables de entorno para sus rutas de búsqueda (véase a continuación la explicación de --seach-paths). Cualquier definición de variable de entorno que falte o sea posiblemente incorrecta se informa aquí.

--install-from-expression=EXP
-e EXP
     Instala el paquete al que EXP evalúa.

     EXP debe ser una expresión Scheme que evalue a un objeto <package>. Esta opción es notablemente útil para desambiguar entre variantes con el mismo nombre que un paquete, con expresiones como (@ (gnu packages base) guile-final).

     Fíjese que esta opción instala la primera salida del paquete especificado, lo cual puede ser insuficiente cuando se necesita una salida específica de un paquete con múltiples salidas.

--install-from-file=FICHERO
-f FICHERO
     Instala el paquete que resulta de evaluar el código en FICHERO.

     Como un ejemplo, FICHERO puede contener una definición como esta (see Definición de paquetes):

               [file package-hello.scm not included]

     Las desarrolladoras pueden encontrarlo útil para incluir un fichero guix.scm in la raíz del árbol de fuentes de su proyecto que puede ser usado para probar imágenes de desarrollo y crear entornos de desarrollo reproducibles (see Invocación de guix environment).

--remove=PAQUETE ...
-r PAQUETE ...
     Borra los PAQUETEs especificados.

     Como en --install, cada PAQUETE puede especificar un número de versión y/o un nombre de salida además del nombre del paquete. Por ejemplo, -r glibc:debug eliminaría la salida debug de glibc.

--upgrade[=REGEXP ...]
-u [REGEXP ...]
     Actualiza todos los paquetes instalados. Si se especifica una o más expresiones regular REGEXP, actualiza únicamente los paquetes instalados cuyo nombre es aceptado por REGEXP. Véase también la opción --do-not-upgrade más adelante.

     Tenga en cuenta que esto actualiza los paquetes a la última versión encontrada en la distribución instalada actualmente. Para actualizar su distribución, debe ejecutar regularmente guix pull (see Invocación de guix pull).

--do-not-upgrade[=REGEXP ...]
     Cuando se usa junto a la opción --upgrade, no actualiza ningún paquete cuyo nombre sea aceptado por REGEXP. Por ejemplo, para actualizar todos los paquetes en el perfil actual excepto aquellos que contengan la cadena ``emacs'':

          $ guix package --upgrade . --do-not-upgrade emacs

--manifest=FICHERO
-m FICHERO
     Crea una nueva generación del perfil desde el objeto de manifiesto devuelto por el código Scheme en FICHERO.

     Esto le permite declarar los contenidos del perfil en vez de construirlo a través de una secuencia de --install y órdenes similares. La ventaja es que FICHERO puede ponerse bajo control de versiones, copiarse a máquinas diferentes para reproducir el mismo perfil, y demás.

     FICHERO debe devolver un objeto manifest, que es básicamente una lista de paquetes:

          (use-package-modules guile emacs)

          (packages->manifest
           (list emacs
                 guile-2.0
                 ;; Usa una salida específica del paquete.
                 (list guile-2.0 "debug")))

     En este ejemplo tenemos que conocer qué módulos definen las variables emacs y guile-2.0 para proporcionar la línea use-package-modules correcta, lo cual puede ser complicado. En cambio podemos proporcionar especificaciones regulares de paquetes y dejar a specifications->manifest buscar los objetos de paquete correspondientes así:

          (specifications->manifest
           '("emacs" "guile@2.2" "guile@2.2:debug"))

--roll-back
     Vuelve a la generación previa del perfil---es decir, deshace la última transacción.

     Cuando se combina con opciones como --install, la vuelta atrás ocurre antes que cualquier acción.

     Cuando se vuelve atrás en la primera generación que realmente contiene paquetes instalados, se hace que el perfil apunte a la generación cero, la cual no contiene ningún fichero a excepción de sus propios metadatos.

     Después de haber vuelto atrás, instalar, borrar o actualizar paquetes sobreescribe las generaciones futuras previas. Por tanto, la historia de las generaciones en un perfil es siempre linear.

--switch-generation=PATRÓN
-S PATRÓN
     Cambia a una generación particular definida por el PATRÓN.

     PATRÓN puede ser tanto un número de generación como un número prefijado con ``+'' o ``-''. Esto último significa: mueve atrás/hacia delante el número especificado de generaciones. Por ejemplo, si quiere volver a la última generación antes de --roll-back, use --switch-generation=+1.

     La diferencia entre --roll-back y --switch-generation=-1 es que --switch-generation no creará una generación cero, así que si la generación especificada no existe, la generación actual no se verá cambiada.

--search-paths[=TIPO]
     Informa de variables de entorno, en sintaxis Bash, que pueden necesitarse para usar el conjunto de paquetes instalado. Estas variables de entorno se usan para especificar las rutas de búsqueda para ficheros usadas por algunos de los paquetes.

     Por ejemplo, GCC necesita que las variables de entorno CPATH y LIBRARY_PATH estén definidas para poder buscar cabeceras y bibliotecas en el perfil de la usuaria (see Environment Variables (Using the GNU Compiler Collection (GCC))). Si GCC y, digamos, la biblioteca de C están instaladas en el perfil, entonces --search-paths sugerirá fijar dichas variables a PERFIL/include y PERFIL/lib respectivamente.

     El caso de uso típico es para definir estas variables de entorno en el shell:

          $ eval `guix package --search-paths`

     TIPO puede ser exact, prefix o suffix, lo que significa que las definiciones de variables de entorno devueltas serán respectivamente las configuraciones exactas, prefijos o sufijos del valor actual de dichas variables. Cuando se omite, el valor predeterminado de TIPO es exact.

     Esta opción puede usarse para calcular las rutas de búsqueda combinadas de varios perfiles. Considere este ejemplo:

          $ guix package -p foo -i guile
          $ guix package -p bar -i guile-json
          $ guix package -p foo -p bar --search-paths

     La última orden informa sobre la variable GUILE_LOAD_PATH, aunque, tomada individualmente, ni foo ni bar hubieran llevado a esa recomendación.

--profile=PERFIL
-p PERFIL
     Usa PERFIL en vez del perfil predeterminado de la usuaria.

--allow-collisions
     Permite colisiones de paquetes en el nuevo perfil. ¡Úselo bajo su propio riesgo!

     Por defecto, guix package informa como un error las colisiones en el perfil. Las colisiones ocurren cuando dos o más versiones diferentes o variantes de un paquete dado se han seleccionado para el perfil.

--bootstrap
     Use el Guile usado para el lanzamiento para construir el perfil. Esta opción es util únicamente a las desarrolladoras de la distribución.

Además de estas acciones, guix package acepta las siguientes opciones para consultar el estado actual de un perfil, o la disponibilidad de paquetes:

--search=REGEXP
-s REGEXP
     Enumera los paquetes disponibles cuyo nombre, sinopsis o descripción corresponde con REGEXP (sin tener en cuenta la capitalización), ordenados por relevancia. Imprime todos los metadatos de los paquetes coincidentes en formato recutils (see GNU recutils databases (GNU recutils manual)).

     Esto permite extraer campos específicos usando la orden recsel, por ejemplo:

          $ guix package -s malloc | recsel -p name,version,relevance
          name: jemalloc
          version: 4.5.0
          relevance: 6

          name: glibc
          version: 2.25
          relevance: 1

          name: libgc
          version: 7.6.0
          relevance: 1

     De manera similar, para mostrar el nombre de todos los paquetes disponibles bajo los términos de la GNU LGPL versión 3:

          $ guix package -s "" | recsel -p name -e 'license ~ "LGPL 3"'
          name: elfutils

          name: gmp
          ...

     Es también posible refinar los resultados de búsqueda usando varias opciones -s. Por ejemplo, la siguiente orden devuelve un lista de juegos de mesa (board en inglés):

          $ guix package -s '\<board\>' -s game | recsel -p name
          name: gnubg
          ...

     Si omitimos -s game, también obtendríamos paquetes de software que tengan que ver con placas de circuitos impresos ("circuit board" en inglés); borrar los signos mayor y menor alrededor de board añadiría paquetes que tienen que ver con teclados (keyboard en inglés).

     Y ahora para un ejemplo más elaborado. La siguiente orden busca bibliotecas criptográficas, descarta bibliotecas Haskell, Perl, Python y Ruby, e imprime el nombre y la sinopsis de los paquetes resultantes:

          $ guix package -s crypto -s library | \
              recsel -e '! (name ~ "^(ghc|perl|python|ruby)")' -p name,synopsis

     See Selection Expressions (GNU recutils manual), para más información en expresiones de selección para recsel -e.

--show=PAQUETE
     Muestra los detalles del PAQUETE, tomado de la lista disponible de paquetes, en formato recutils (see GNU recutils databases (GNU recutils manual)).

          $ guix package --show=python | recsel -p name,version
          name: python
          version: 2.7.6

          name: python
          version: 3.3.5

     Tambien puede especificar el nombre completo de un paquete para únicamente obtener detalles sobre una versión específica:

          $ guix package --show=python@3.4 | recsel -p name,version
          name: python
          version: 3.4.3

--list-installed[=REGEXP]
-I [REGEXP]
     Enumera los paquetes actualmente instalados en el perfil especificado, con los últimos paquetes instalados mostrados al final. Cuando se especifica REGEXP, enumera únicamente los paquetes instalados cuyos nombres son aceptados por REGEXP.

     Por cada paquete instalado, imprime los siguientes elementos, separados por tabuladores: el nombre del paquete, la cadena de versión, la parte del paquete que está instalada (por ejemplo, out para la salida predeterminada, include para sus cabeceras, etc.), y la ruta de este paquete en el almacén.

--list-available[=REGEXP]
-A [REGEXP]
     Enumera los paquetes disponibles actualmente en la distribución para este sistema (see Distribución GNU). Cuando se especifica REGEXP, enumera únicamente paquetes instalados cuyo nombre coincide con REGEXP.

     Por cada paquete, imprime los siguientes elementos separados por tabuladores: su nombre, su cadena de versión, las partes del paquete (see Paquetes con múltiples salidas) y la dirección de las fuentes de su definición.

--list-generations[=PATRÓN]
-l [PATRÓN]
     Devuelve una lista de generaciones junto a sus fechas de creación; para cada generación, muestra los paquetes instalados, con los paquetes instalados más recientemente mostrados los últimos. Fíjese que la generación cero nunca se muestra.

     Por cada paquete instalado, imprime los siguientes elementos, separados por tabuladores: el nombre de un paquete, su cadena de versión, la parte del paquete que está instalada (see Paquetes con múltiples salidas), y la ruta de este paquete en el almacén.

     Cuando se usa PATRÓN, la orden devuelve únicamente las generaciones que se ajustan al patrón. Patrones válidos incluyen:

       * Enteros y enteros separados por comas. Ambos patrones denotan números de generación. Por ejemplo, --list-generations=1 devuelve la primera.

          Y --list-generations=1,8,2 devuelve las tres generaciones en el orden especificado. No se permiten ni espacios ni una coma al final.

       * Rangos.  --list-generations=2..9 imprime las generaciones especificadas y todas las intermedias. Fíjese que el inicio de un rango debe ser menor a su fin.

          También es posible omitir el destino final. Por ejemplo, --list-generations=2.. devuelve todas las generaciones empezando por la segunda.

       * Duraciones. Puede también obtener los últimos N días, semanas, o meses pasando un entero junto a la primera letra de la duración. Por ejemplo, --list-generations=20d enumera las generaciones que tienen hasta 20 días de antigüedad.

--delete-generations[=PATRÓN]
-d [PATRÓN]
     Cuando se omite PATRÓN, borra todas las generaciones excepto la actual.

     Esta orden acepta los mismos patrones que --list-generations. Cuando se especifica un PATRÓN, borra las generaciones coincidentes. Cuando el PATRÓN especifica una duración, las generaciones más antiguas que la duración especificada son las borradas. Por ejemplo, --delete-generations=1m borra las generaciones de más de un mes de antigüedad.

     Si la generación actual entra en el patrón, no es borrada. Tampoco la generación cero es borrada nunca.

     Fíjese que borrar generaciones previene volver atrás a ellas. Consecuentemente esta orden debe ser usada con cuidado.

Finalmente, ya que guix package puede lanzar procesos de construcción en realidad, acepta todas las opciones comunes de construcción (see Opciones comunes de construcción). También acepta opciones de transformación de paquetes, como --with-source (see Opciones de transformación de paquetes). No obstante, fíjese que las transformaciones del paquete se pierden al actualizar; para preservar las transformaciones entre actualizaciones, debe definir su propia variante del paquete en un módulo Guile y añadirlo a GUIX_PACKAGE_PATH (see Definición de paquetes).

Sustituciones
=============

Guix permite despliegues transparentes de fuentes/binarios, lo que significa que puede tanto construir cosas localmente, como descargar elementos preconstruidos de un servidor, o ambas. Llamamos a esos elementos preconstruidos sustituciones---son sustituciones de los resultados de construcciones locales. En muchos casos, descargar una sustitución es mucho más rápido que construirla localmente.

Las sustituciones pueden ser cualquier cosa que resulte de una construcción de una derivación (see Derivaciones). Por supuesto, en el caso común, son paquetes binarios preconstruidos, pero los archivos de fuentes, por ejemplo, que también resultan de construcciones de derivaciones, pueden estar disponibles como sustituciones.

Servidor oficial de sustituciones.
----------------------------------

El servidor ci.guix.es.info es una fachada a una granja de construcción oficial que construye paquetes de Guix continuamente para algunas arquitecturas, y los pone disponibles como sustituciones. Esta es la fuente predeterminada de sustituciones; puede ser forzada a cambiar pasando la opción --substitute-urls bien a guix-daemon (see guix-daemon --substitute-urls) o bien a herramientas cliente como guix package (see client --substitute-urls option).

Las URLs de sustituciones pueden ser tanto HTTP como HTTPS. Se recomienda HTTPS porque las comunicaciones están cifradas; de modo contrario, usar HTTP hace visibles todas las comunicaciones para alguien que las intercepte, quien puede usar la información obtenida para determinar, por ejemplo, si su sistema tiene vulnerabilidades de seguridad sin parchear.

Las sustituciones de la granja de construcción oficial están habilitadas por defecto cuando se usa la Distribución de sistema Guix (see Distribución GNU). No obstante, están deshabilitadas por defecto cuando se usa Guix en una distribución anfitriona, a menos que las haya habilitado explícitamente via uno de los pasos recomendados de instalación (see Instalación). Los siguientes párrafos describen como habilitar o deshabilitar sustituciones para la granja oficial de construcción; el mismo procedimiento puede usarse para habilitar sustituciones de cualquier otro servidor que las proporcione.

Autorización de servidores de sustituciones
-------------------------------------------

Para permitir a Guix descargar sustituciones de ci.guix.es.info o un espejo suyo, debe añadir su clave pública a la lista de control de acceso (ACL) de las importaciones de archivos, mediante el uso de la orden guix archive (see Invocación de guix archive). Hacerlo implica que confía que ci.guix.es.info no ha sido comprometido y proporciona sustituciones genuinas.

La clave pública para ci.guix.es.info se instala junto a Guix, en PREFIJO/share/guix/ci.guix.es.info.pub, donde PREFIJO es el prefij de instalación de Guix. Si ha instalado Guix desde las fuentes, debe asegurarse de que comprobó la firma GPG de guix-VERSION.tar.gz, el cual contiene el fichero de clave pública. Una vez hecho, puede ejecutar algo así:

     # guix archive --authorize < PREFIJO/share/guix/ci.guix.es.info.pub

     De manera similar, el fichero hydra.gnu.org.pub contiene la clave pública para una granja de construcción independiente que también es parte del proyecto, la cual se puede encontrar en https://mirror.hydra.gnu.org.

Una vez esté autorizada, la salida de una orden como guix build debería cambiar de algo como:

     $ guix build emacs --dry-run
     The following derivations would be built:
        /gnu/store/yr7bnx8xwcayd6j95r2clmkdl1qh688w-emacs-24.3.drv
        /gnu/store/x8qsh1hlhgjx6cwsjyvybnfv2i37z23w-dbus-1.6.4.tar.gz.drv
        /gnu/store/1ixwp12fl950d15h2cj11c73733jay0z-alsa-lib-1.0.27.1.tar.bz2.drv
        /gnu/store/nlma1pw0p603fpfiqy7kn4zm105r5dmw-util-linux-2.21.drv
     ...

a algo así:

     $ guix build emacs --dry-run
     112.3 MB would be downloaded:
        /gnu/store/pk3n22lbq6ydamyymqkkz7i69wiwjiwi-emacs-24.3
        /gnu/store/2ygn4ncnhrpr61rssa6z0d9x22si0va3-libjpeg-8d
        /gnu/store/71yz6lgx4dazma9dwn2mcjxaah9w77jq-cairo-1.12.16
        /gnu/store/7zdhgp0n1518lvfn8mb96sxqfmvqrl7v-libxrender-0.9.7
     ...

Esto indica que las sustituciones de ci.guix.es.info son usables y serán descargadas, cuando sea posible, para construcciones futuras.

El mecanismo de sustituciones puede ser deshabilitado globalmente ejecutando guix-daemon con --no-subsitutes (see Invocación de guix-daemon). También puede ser deshabilitado temporalmente pasando la opción --no-substitutes a guix package, guix build y otras herramientas de línea de órdenes.

Verificación de sustituciones
-----------------------------

Guix detecta y emite errores cuando se intenta usar una sustitución que ha sido adulterado. Del mismo modo, ignora las sustituciones que no están firmadas, o que no están firmadas por una de las firmas enumeradas en la ACL.

No obstante hay una excepción: si un servidor no autorizado proporciona sustituciones que son idénticas bit-a-bit a aquellas proporcionadas por un servidor autorizado, entonces el servidor no autorizado puede ser usado para descargas. Por ejemplo, asumiendo que hemos seleccionado dos servidores de sustituciones con esta opción:

     --substitute-urls="https://a.example.org https://b.example.org"

Si la ACL contiene únicamente la clave para b.example.org, y si a.example.org resulta que proporciona exactamente las mismas sustituciones, Guix descargará sustituciones de a.example.org porque viene primero en la lista y puede ser considerado un espejo de b.example.org. En la práctica, máquinas de construcción independientes producen habitualmente los mismos binarios, gracias a las construcciones reproducibles bit-a-bit (véase a continuación).

Cuando se usa HTTPS, el certificado X.509 del servidor no se valida (en otras palabras, el servidor no está verificado), lo contrario del comportamiento habitual de los navegadores Web. Esto es debido a que Guix verifica la información misma de las sustituciones, como se ha explicado anteriormente, lo cual nos concierne (mientras que los certificados X.509 tratan de verificar las conexiones entre nombres de dominio y claves públicas).

Configuración de la pasarela.
-----------------------------

Las sustituciones se descargan por HTTP o HTTPS. La variable de entorno http_proxy puede ser incluida en el entorno de guix-daemon y la respeta para las descargas de sustituciones. Fíjese que el valor de http_proxy en el entorno en que guix build, guix package y otras aplicaciones cliente se ejecuten no tiene ningún efecto.

Fallos en las sustituciones
---------------------------

Incluso cuando una sustitución de una derivación está disponible, a veces el intento de sustitución puede fallar. Esto puede suceder por varias razones: el servidor de sustituciones puede estar desconectado, la sustitución puede haber sido borrada, la conexión puede interrumpirse, etc.

Cuando las sustituciones están activadas y una sustitución para una derivación está disponible, pero el intento de sustitución falla, Guix intentará construir la derivación localmente dependiendo si se proporcionó la opción --fallback (see common build option --fallback). Específicamente, si no se pasó --fallback, no se realizarán construcciones locales, y la derivación se considera se considera fallida. No obstante, si se pasó --fallback, Guix intentará construir la derivación localmente, y el éxito o fracaso de la derivación depende del éxito o fracaso de la construcción local. Fíjese que cuando las sustituciones están deshabilitadas o no hay sustituciones disponibles para la derivación en cuestión, la construcción local se realizará siempre, independientemente de si se pasó la opción --fallback.

Para hacerse una idea de cuantas sustituciones hay disponibles en este momento, puede intentar ejecutar la orden guix weather (see Invocación de guix weather). Esta orden proporciona estadísticas de las sustituciones proporcionadas por un servidor.

Sobre la confianza en binarios
------------------------------

Hoy en día, el control individual sobre nuestra propia computación está a merced de instituciones, empresas y grupos con suficiente poder y determinación para subvertir la infraestructura de computación y explotar sus vulnerabilidades. Mientras que usar las sustituciones de ci.guix.es.info puede ser conveniente, recomendamos a las usuarias también construir sus paquetes, o incluso mantener su propia granja de construcción, de modo que ci.guix.es.info sea un objetivo menos interesante. Una manera de ayudar es publicando el software que construya usando guix publish de modo que otras tengan otro servidor más como opción para descargar sustituciones (see Invocación de guix publish).

Guix tiene los cimientos para maximizar la reproducibilidad de las construcciones (see Características). En la mayor parte de los casos, construcciones independientes de un paquete o derivación dada deben emitir resultados idénticos bit a bit. Por tanto, a través de un conjunto diverso de construcciones independientes de paquetes, podemos reforzar la integridad de nuestros sistemas. La orden guix challenge intenta ayudar a las usuarias en comprobar servidores de sustituciones, y asiste a las desarrolladoras encontrando construcciones no deterministas de paquetes (see Invocación de guix challenge). Similarmente, la opción --check de guix build permite a las usuarias si las sustituciones previamente instaladas son genuinas reconstruyendolas localmente (see guix build --check).

En el futuro, queremos que Guix permita la publicación y obtención de binarios hacia/desde otras usuarias, entre pares (P2P). En caso de interesarle hablar sobre este proyecto, unase a nosotras en guix-devel@gnu.org.

Paquetes con múltiples salidas
==============================

Habitualmente, los paquetes definidos en Guix tienen una salida única---es decir, el paquete de fuentes proporcionará exactamente un directorio en el almacén. Cuando se ejecuta guix package -i glibc, se instala la salida predeterminada del paquete GNU libc; la salida predeterminada se llama out, pero su nombre puede omitirse como se mostró en esta orden. En este caso particular, la salida predeterminada de glibc contiene todos ficheros de cabecera C, bibliotecas dinámicas, bibliotecas estáticas, documentación Info y otros ficheros auxiliares.

A veces es más apropiado separar varios tipos de ficheros producidos por un paquete único de fuentes en salidas separadas. Por ejemplo, la biblioteca C GLib (usada por GTK+ y paquetes relacionados) instala más de 20 MiB de documentación de referencia como páginas HTML. Para ahorrar espacio para usuarias que no la necesiten, la documentación va a una salida separada, llamada doc. Para instalar la salida principal de GLib, que contiene todo menos la documentación, se debe ejecutar:

     guix package -i glib

La orden que instala su documentación es:

     guix package -i glib:doc

Algunos paquetes instalan programas con diferentes ``huellas de dependencias''. Por ejemplo, el paquete WordNet instala tanto herramientas de línea de órdenes como interfaces gráficas de usuaria (IGU). Las primeras dependen únicamente de la biblioteca de C, mientras que las últimas dependen en Tcl/Tk y las bibliotecas de X subyacentes. En este caso, dejamos las herramientas de línea de órdenes en la salida predeterminada, mientras que las IGU están en una salida separada. Esto permite a las usuarias que no necesitan una IGU ahorrar espacio. La orden guix size puede ayudar a exponer estas situaciones (see Invocación de guix size). guix graph también puede ser útil (see Invocación de guix graph).

Hay varios de estos paquetes con salida múltiple en la distribución GNU. Otros nombres de salida convencionales incluyen lib para bibliotecas y posiblemente ficheros de cabecera, bin para programas independientes y debug para información de depuración (see Instalación de ficheros de depuración). La salida de los paquetes se enumera en la tercera columna del resultado de guix package --list-available (see Invocación de guix package).

Invocación de guix gc
=====================

Los paquetes instalados, pero no usados, pueden ser recolectados. La orden guix gc permite a las usuarias ejecutar explícitamente el recolector de basura para reclamar espacio del directorio /gnu/store---¡borrar ficheros o directorios manualmente puede dañar el almacén sin reparación posible!

El recolector de basura tiene un conjunto de raíces conocidas: cualquier fichero en /gnu/store alcanzable desde una raíz se considera vivo y no puede ser borrado; cualquier otro fichero se considera muerto y puede ser borrado. El conjunto de raíces del recolector de basura (``raíces del GC'' para abreviar) incluye los perfiles predeterminados de las usuarias; por defecto los enlaces bajo /var/guix/gcroots representan dichas raíces. Por ejemplo, nuevas raíces del GC pueden añadirse con guix build --root (see Invocación de guix build). La orden guix gc --list-roots las enumera.

Antes de ejecutar guix gc --collect-garbage para liberar espacio, habitualmente es útil borrar generaciones antiguas de los perfiles de usuaria; de ese modo, las construcciones antiguas de paquetes referenciadas por dichas generaciones puede ser reclamada. Esto se consigue ejecutando guix package --delete-generations (see Invocación de guix package).

Nuestra recomendación es ejecutar una recolección de basura periódicamente, o cuando tenga poco espacio en el disco. Por ejemplo, para garantizar que al menos 5 GB están disponibles en su disco, simplemente ejecute:

     guix gc -F 5G

Es completamente seguro ejecutarla como un trabajo periódico no-interactivo (see Ejecución de tareas programadas, para la configuración de un trabajo de ese tipo). La ejecución de guix gc sin ningún parámetro recolectará tanta basura como se pueda, pero eso es no es normalmente conveniente: puede encontrarse teniendo que reconstruir o volviendo a bajar software que está ``muerto'' desde el punto de vista del recolector pero que es necesario para construir otras piezas de software---por ejemplo, la cadena de herramientas de compilación.

La orden guix gc tiene tres modos de operación: puede ser usada para recolectar ficheros muertos (predeterminado), para borrar ficheros específicos (la opción --delete), para mostrar información sobre la recolección de basura o para consultas más avanzadas. Las opciones de recolección de basura son las siguientes:

--collect-garbage[=MIN]
-C [MIN]
     Recolecta basura---es decir, ficheros no alcanzables de /gnu/store y subdirectorios. Esta operación es la predeterminada cuando no se especifican opciones.

     Cuando se proporciona MIN, para una vez que MIN bytes han sido recolectados. MIN puede ser un número de bytes, o puede incluir una unidad como sufijo, como MiB para mebibytes y GB para gigabytes (see size specifications (GNU Coreutils)).

     Cuando se omite MIN, recolecta toda la basura.

--free-space=LIBRE
-F LIBRE
     Recolecta basura hasta que haya espacio LIBRE bajo /gnu/store, si es posible: LIBRE denota espacio de almacenamiento, por ejemplo 500MiB, como se ha descrito previamente.

     Cuando LIBRE o más está ya disponible en /gnu/store, no hace nada y sale inmediatamente.

--delete-generations[=DURACIÓN]
-d [DURACIÓN]
     Antes de comenzar el proceso de recolección de basura, borra todas las generaciones anteriores a DURACIÓN, para todos los perfiles de la usuaria; cuando se ejecuta como root esto aplica a los perfiles de todas las usuarias.

     Por ejemplo, esta orden borra todas las generaciones de todos sus perfiles que tengan más de 2 meses de antigüedad (excepto generaciones que sean las actuales), y una vez hecho procede a liberar espacio hasta que al menos 10 GiB estén disponibles:

          guix gc -d 2m -F 10G

--delete
-D
     Intenta borrar todos los ficheros del almacén y directorios especificados como parámetros. Esto falla si alguno de los ficheros no están en el almacén, o todavía están vivos.

--list-failures
     Enumera los elementos del almacén correspondientes a construcciones fallidas existentes en la caché.

     Esto no muestra nada a menos que el daemon se haya ejecutado pasando --cache-failures (see --cache-failures).

--list-roots
     Enumera las raices del recolector de basura poseidas por la usuaria; cuando se ejecuta como root, enumera todas las raices del recolector de basura.

--clear-failures
     Borra los elementos especificados del almacén de la caché de construcciones fallidas.

     De nuevo, esta opción únicamente tiene sentido cuando el daemon se inicia con --cache-failures. De otro modo, no hace nada.

--list-dead
     Muestra la lista de ficheros y directorios muertos todavía presentes en el almacén---es decir, ficheros y directorios que ya no se pueden alcanzar desde ninguna raíz.

--list-live
     Muestra la lista de ficheros y directorios del almacén vivos.

Además, las referencias entre los ficheros del almacén pueden ser consultadas:

--references
--referrers
     Enumera las referencias (o, respectivamente, los referentes) de los ficheros del almacén pasados como parámetros.

--requisites
-R
     Enumera los requistos los ficheros del almacén pasados como parámetros. Los requisitos incluyen los mismos ficheros del almacén, sus referencias, las referencias de estas, recursivamente. En otras palabras, la lista devuelta es la clausura transitiva de los ficheros del almacén.

     See Invocación de guix size, para una herramienta que perfila el tamaño de la clausura de un elemento. See Invocación de guix graph, para una herramienta de visualización del grafo de referencias.

--derivers
     Devuelve la/s derivación/es que conducen a los elementos del almacén dados (see Derivaciones).

     Por ejemplo, esta orden:

          guix gc --derivers `guix package -I ^emacs$ | cut -f4`

     devuelve el/los fichero/s .drv que conducen al paquete emacs instalado en su perfil.

     Fíjese que puede haber cero ficheros .drv encontrados, por ejemplo porque estos ficheros han sido recolectados. Puede haber más de un fichero .drv encontrado debido a derivaciones de salida fija.

Por último, las siguientes opciones le permiten comprobar la integridad del almacén y controlar el uso del disco.

--verify[=OPCIONES]
     Verifica la integridad del almacén.

     Por defecto, comprueba que todos los elementos del almacén marcados como válidos en la base de datos del daemon realmente existen en /gnu/store.

     Cuando se proporcionan, OPCIONES debe ser una lista separada por comas que contenga uno o más valores contents and repair.

     Cuando se usa --verify=contents, el daemon calcula el hash del contenido de cada elemento del almacén y lo compara contra el hash de su base de datos. Las incongruencias se muestran como corrupciones de datos. Debido a que recorre todos los ficheros del almacén, esta orden puede tomar mucho tiempo, especialmente en sistemas con una unidad de disco lenta.

     El uso de --verify=repair o --verify=contents,repair hace que el daemon intente reparar elementos corruptos del almacén obteniendo sustituciones para dichos elementos (see Sustituciones). Debido a que la reparación no es atómica, y por tanto potencialmente peligrosa, está disponible únicamente a la administradora del sistema. Una alternativa ligera, cuando sabe exactamente qué elementos del almacén están corruptos, es guix build --repair (see Invocación de guix build).

--optimize
     Optimiza el almacén sustituyendo ficheros idénticos por enlaces duros---esto es la deduplicación.

     El daemon realiza la deduplicación después de cada construcción satisfactoria o importación de archivos, a menos que se iniciase con --disable-deduplication (see --disable-deduplication). Por tanto, esta opción es útil primariamente cuando el daemon se estaba ejecutando con --disable-deduplication.

Invocación de guix pull
=======================

Los paquetes se instalan o actualizan con la última versión disponible en la distribución disponible actualmente en su máquina local. Para actualizar dicha distribución, junto a las herramientas de Guix, debe ejecutar guix pull: esta orden descarga el último código fuente de Guix y descripciones de paquetes, y lo despliega. El código fuente se descarga de un repositorio Git (https://git-scm.com), por defecto el repositorio oficial de GNU Guix, lo que no obstante puede ser personalizado.

Una vez completada, guix package usará paquetes y versiones de paquetes de esta copia recién obtenida de Guix. No solo eso, sino que todas las órdenes de Guix y los módulos Scheme también se tomarán de la última versión. Nuevas sub-órdenes guix incorporadas por la actualización también estarán disponibles.

Cualquier usuaria puede actualizar su copia de Guix usando guix pull, y el efecto está limitado a la usuaria que ejecutó guix pull. Por ejemplo, cuando la usuaria root ejecuta guix pull, esto no tiene ningún efecto en la versión del Guix que la usuaria alicia ve, y viceversa.

El resultado de ejecutar guix pull es un perfil disponible bajo ~/.config/guix/current conteniendo el último Guix. Por tanto, asegurese de añadirlo al inicio de sus rutas de búsqueda de modo que use la última versión, de modo similar para el manual Info(see Documentación).

     export PATH="$HOME/.config/guix/current/bin:$PATH"
     export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH"

Las opciones --list-generations o -l enumeran las generaciones pasadas producidas por guix pull, junto a detalles de su procedencia:

     $ guix pull -l
     Generation 1	Jun 10 2018 00:18:18
       guix 65956ad
         repository URL: https://git.savannah.gnu.org/git/guix.git
         branch: origin/master
         commit: 65956ad3526ba09e1f7a40722c96c6ef7c0936fe

     Generation 2	Jun 11 2018 11:02:49
       guix e0cc7f6
         repository URL: https://git.savannah.gnu.org/git/guix.git
         branch: origin/master
         commit: e0cc7f669bec22c37481dd03a7941c7d11a64f1d
       2 new packages: keepalived, libnfnetlink
       6 packages upgraded: emacs-nix-mode@2.0.4,
         guile2.0-guix@0.14.0-12.77a1aac, guix@0.14.0-12.77a1aac,
         heimdal@7.5.0, milkytracker@1.02.00, nix@2.0.4

     Generation 3	Jun 13 2018 23:31:07	(current)
       guix 844cc1c
         repository URL: https://git.savannah.gnu.org/git/guix.git
         branch: origin/master
         commit: 844cc1c8f394f03b404c5bb3aee086922373490c
       28 new packages: emacs-helm-ls-git, emacs-helm-mu, ...
       69 packages upgraded: borg@1.1.6, cheese@3.28.0, ...

guix describe, para otras formas de describir el estado actual de Guix.

El perfil ~/.config/guix/current funciona como cualquier otro perfil creado por guix package (see Invocación de guix package). Esto es, puede enumerar generaciones, volver a una generación previa---es decir, el Guix anterior---y más:

     $ guix package -p ~/.config/guix/current --roll-back
     switched from generation 3 to 2
     $ guix package -p ~/.config/guix/current --delete-generations=1
     deleting /var/guix/profiles/per-user/carlos/current-guix-1-link

La orden guix pull se invoca habitualmente sin parámetros, pero permite las siguientes opciones:

--url=URL
--commit=REVISIÓN
--branch=RAMA
     Download code for the guix channel from the specified URL, at the given COMMIT (a valid Git commit ID represented as a hexadecimal string), or BRANCH.

     Estas opciones se proporcionan por conveniencia, pero también puede especificar su configuración en el fichero ~/.config/guix/channels.scm o usando la opción --channels (vea más adelante).

--channels=FICHERO
-C FICHERO
     Lee la lista de canales de FICHERO en vez de ~/.config/guix/channels.scm. FICHERO debe contener código Scheme que evalue a una lista de objetos channel. See Canales, para más información.

--news
-N
     Display the list of packages added or upgraded since the previous generation.

     This is the same information as displayed upon guix pull completion, but without ellipses; it is also similar to the output of guix pull -l for the last generation (see below).

--list-generations[=PATRÓN]
-l [PATRÓN]
     Enumera todas las generaciones de ~/.config/guix/current o, si se proporciona un PATRÓN, el subconjunto de generaciones que correspondan con el PATRÓN. La sintaxis de PATRÓN es la misma que guix package --list-generations (see Invocación de guix package).

     Invocación de guix describe, para una forma de mostrar información sobre únicamente la generación actual.

--profile=PERFIL
-p PERFIL
     Usa PERFIL en vez de ~/.config/guix/current.

--dry-run
-n
     Muestra qué revisión/es del canal serían usadas y qué se construiría o sustituiría, sin efectuar ninguna acción real.

--system=SISTEMA
-s SISTEMA
     Intenta construir paquetes para SISTEMA---por ejemplo, x86_64-linux---en vez del tipo de sistema de la máquina de construcción.

--verbose
     Produce salida prolija, escribiendo los logs de construcción por la salida de error estándar.

--bootstrap
     Use el Guile usado para el lanzamiento para construir el último Guix. Esta opción es útil para las desarrolladoras de Guix únicamente.

El mecanismo de canales le permite instruir a guix pull de qué repositorio y rama obtener los datos, así como repositorios adicionales que contengan módulos de paquetes que deben ser desplegados. See Canales, para más información.

Además, guix pull acepta todas las opciones de construcción comunes (see Opciones comunes de construcción).

Canales
=======

Guix y su colección de paquetes son actualizados ejecutando guix pull (see Invocación de guix pull). Por defecto guix pull descarga y despliega el mismo Guix del repositorio oficial de GNU Guix. Esto puede ser personalizado definiendo canales en el fichero ~/.config/guix/channels.scm. Un canal especifica una URL y una rama de un repositorio Git para ser desplegado, y guix pull puede ser instruido para tomar los datos de uno o más canales. En otras palabras, los canales se pueden usar para personalizar y para extender Guix, como vemos a continuación.

Uso de un canal de Guix personalizado
-------------------------------------

El canal llamado guix especifica de donde el mismo Guix---sus herramientas de línea de órdenes y su colección de paquetes---debe ser descargado. Por ejemplo, suponga que quiere actualizar de su propia copia del repositorio Guix en example.org, y específicamente la rama super-hacks, para ello puede escribir en ~/.config/guix/channels.scm esta especificación:

     ;; Le dice a 'guix pull' que use mi propio repositorio.
     (list (channel
             (name 'guix)
             (url "https://example.org/mi-guix.git")
             (branch "super-hacks")))

De aquí en adelante, guix pull obtendrá el código de la rama super-hacks del repositorio en example.org.

Especificación de canales adicionales
-------------------------------------

También puede especificar canales adicionales de los que obtener datos. Digamos que tiene un montón de variaciones personalizadas de paquetes que piensa que no tiene mucho sentido contribuir al proyecto Guix, pero quiere tener esos paquetes disponibles transparentemente en su línea de órdenes. Primero escribiría módulos que contengan esas definiciones de paquete (see Módulos de paquetes), los mantendría en un repositorio Git, y entonces usted y cualquier otra persona podría usarlos como un canal adicional del que obtener paquetes. Limpio, ¿no?

     Antes de que, querida usuaria, grite---``¡Guau, esto es la caña!''---y publique su canal personal al mundo, nos gustaría compartir algunas palabras de precaución:

       * Antes de publicar un canal, por favor considere contribuir sus definiciones de paquete al propio Guix (see Contribuir). Guix como proyecto es abierto a software libre de todo tipo, y los paquetes en el propio Guix están disponibles para todas las usuarias de Guix y se benefician del proceso de gestión de calidad del proyecto.

       * Cuando mantiene definiciones de paquete fuera de Guix, nosotras, las desarrolladoras de Guix, consideramos que la carga de la compatibilidad cae de su lado. Recuerde que los módulos y definiciones de paquetes son solo código Scheme que usa varias interfaces programáticas (APIs). Queremos mantener la libertad de cambiar dichas interfaces para seguir mejorando Guix, posiblemente en formas que pueden romper su canal. Nunca cambiamos las interfaces gratuitamente, pero no vamos tampoco a congelar las interfaces.

       * Corolario: si está usando un canal externo y el canal se rompe, por favor informe del problema a las autoras del canal, no al proyecto Guix.

     ¡Ha quedado advertida! Habiendo dicho esto, creemos que los canales externos son una forma práctica de ejercitar su libertad para aumentar la colección de paquetes de Guix y compartir su mejoras, que son pilares básicos del software libre (https://www.gnu.org/philosophy/free-sw.html). Por favor, envíenos un correo a guix-devel@gnu.org si quiere hablar sobre esto.

Para usar un canal, escriba en ~/.config/guix/channels.scm para instruir a guix pull para obtener datos de él además de los canales Guix predeterminados:

     ;; Añade mis paquetes personales a aquellos que Guix provee.
     (cons (channel
             (name 'mis-paquetes-personales)
             (url "https://example.org/paquetes-personales.git"))
           %default-channels)

Fíjese que el fragmento previo es (¡como siempre!) código Scheme; usamos cons para añadir un canal a la lista de canales a la que la variable %default-channels hace referencia (see cons and lists (GNU Guile Reference Manual)). Con el fichero en este lugar, guix pull no solo construye Guix sino también los módulos de paquetes de su propio repositorio. El resultado en ~/.config/guix/current es la unión de Guix con sus propios módulos de paquetes:

     $ guix pull --list-generations
     ...
     Generation 19	Aug 27 2018 16:20:48
       guix d894ab8
         repository URL: https://git.savannah.gnu.org/git/guix.git
         branch: master
         commit: d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300
       mis-paquetes-personales dd3df5e
         repository URL: https://example.org/paquetes-personales.git
         branch: master
         commit: dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb
       11 new packages: mi-gimp, mi-emacs-con-cosas, ...
       4 packages upgraded: emacs-racket-mode@0.0.2-2.1b78827, ...

La salida de guix pull previa muestra que la generación 19 incluye tanto Guix como paquetes del canal mis-paquetes-personales. Entre los paquetes nuevos y actualizados que son enumerados, algunos como mi-gimp y mi-emacs-con-cosas pueden venir de mis-paquetes-personales, mientras que otros vienen del canal predeterminado de Guix.

Para crear uncanal, cree un repositorio Git que contenga sus propios módulos de paquetes y haga que esté disponible. El repositorio puede contener cualquier cosa, pero un canal útil contendrá módulos Guile que exportan paquetes. Una vez comience a usar un canal, Guix se comportará como si el directorio raíz del repositorio Git de dicho canal hubiese sido añadido a la ruta de carga de Guile (see Load Paths (GNU Guile Reference Manual)). Por ejemplo, si su canal contiene un fichero en mis-paquetes/mis-herramientas.scm que define un módulo, entonces dicho módulo estará disponible bajo el nombre (mis-paquetes mis-herramientas), y podrá usarlo como cualquier otro módulo (see Módulos (GNU Guile Reference Manual)).

Declaración de dependencias de canales
--------------------------------------

Las autoras de canales pueden decidir aumentar una colección de paquetes proporcionada por otros canales. Pueden declarar su canal como dependiente de otros canales en el fichero de metadatos .guix-channel, que debe encontrarse en la raíz del repositorio del canal.

Este fichero de metadatos debe contener una expresión-S simple como esta:

     (channel
      (version 0)
      (dependencies
       (channel
        (name una-coleccion)
        (url "https://example.org/primera-coleccion.git"))
       (channel
        (name otra-coleccion)
        (url "https://example.org/segunda-coleccion.git")
        (branch "pruebas"))))

En el ejemplo previo, este canal se declara como dependiente de otros dos canales, que se obtendrán de manera automática. Los módulos proporcionados por el canal se compilarán en un entorno donde los módulos de todos estos canales declarados estén disponibles.

De cara a la confianza proporcionada y el esfuerzo que supondrá su mantenimiento, debería evitar depender de canales que no controle, y debería intentar minimizar el número de dependencias.

Replicación de Guix
-------------------

La salida de guix pull --list-generations previa muestra precisamente qué revisiones se usaron para construir esta instancia de Guix. Por tanto podemos replicarla, digamos, en otra máquina, proporcionando una especificaciones de canales en ~/.config/guix/channels.scm que está ``clavada'' en estas revisiones:

     ;; Despliega unas revisiones específicas de mis canales de interés.
     (list (channel
            (name 'guix)
            (url "https://git.savannah.gnu.org/git/guix.git")
            (commit "d894ab8e9bfabcefa6c49d9ba2e834dd5a73a300"))
           (channel
            (name 'mis-paquetes-personales)
            (url "https://example.org/paquetes-personales.git")
            (branch "dd3df5e2c8818760a8fc0bd699e55d3b69fef2bb")))

La orden guix describe --format=channels puede incluso generar esta lista de canales directamente (see Invocación de guix describe).

En este punto las dos máquinas ejecutan exactamente el mismo Guix, con acceso a exactamente los mismos paquetes. La salida de guix build gimp en una máquina debe ser exactamente la misma, bit a bit, que la salida de la misma orden en la otra máquina. Esto también significa que ambas máquinas tienen acceso a todo el código fuente de Guix y, transitiamente, a todo el código fuente de cada paquete que define.

Esto le proporciona superpoderes, permitiendole seguir la pista de la procedencia de los artefactos binarios con un grano muy fino, y reproducir entornos de software a su voluntad---un tipo de capacidad de ``meta-reproducibilidad'', si lo desea. See Inferiores, para otro modo de tomar ventaja de estos superpoderes.

Inferiores
==========

     La funcionalidad descrita aquí es una ``versión de evaluación tecnológica'' en la versión VERSION. Como tal, la interfaz está sujeta a cambios.

A veces necesita mezclar paquetes de revisiones de la revisión de Guix que está ejecutando actualmente con paquetes disponibles en una revisión diferente. Los inferiores de Guix le permiten conseguirlo componiendo diferentes revisiones de Guix de modo arbitrario.

Técnicamente, un ``inferior'' es esencialmente un proceso Guix separado conectado con su Guix principal a través de una sesión interactiva (see Invocación de guix repl). El módulo (guix inferior) le permite crear inferiores y comunicarse con ellos. También proporciona una interfaz de alto nivel para buscar y manipular los paquetes que un inferior proporciona---paquetes de inferiores.

Cuando se combina con los canales (see Canales), los inferiores proporcionan una forma simple de interactuar con una revisión separada de Guix. Por ejemplo, asumamos que desea instalar en su perfil el paquete guile actual, junto al paquete guile-json como existía en una revisión más antigua de Guix---quizá porque las versiones nuevas de guile-json tienen un API incompatible y quiere ejecutar su código contra la API antigua. Para hacerlo, puede escribir un manifiesto para usarlo con guix package --manifest (see Invocación de guix package); en dicho manifiesto puede crear un inferior para esa versión antigua de Guix que le interesa, y buscará el paquete guile-json en el inferior:

     (use-modules (guix inferior) (guix channels)
                  (srfi srfi-1))   ;para 'first'

     (define channels
       ;; Esta es la revisión antigua de donde queremos
       ;; extraer guile-json.
       (list (channel
              (name 'guix)
              (url "https://git.savannah.gnu.org/git/guix.git")
              (commit
               "65956ad3526ba09e1f7a40722c96c6ef7c0936fe"))))

     (define inferior
       ;; Un inferior que representa la revisión previa.
       (inferior-for-channels channels))

     ;; Ahora crea un manifiesto con el paquete "guile" actual
     ;; y el antiguo paquete "guile-json".
     (packages->manifest
      (list (first (lookup-inferior-packages inferior "guile-json"))
            (specification->package "guile")))

En su primera ejecución, guix package --manifest puede tener que construir el canal que especificó antes de crear el inferior; las siguientes ejecuciones serán mucho más rápidas porque la revisión de Guix estará en la caché.

El módulo (guix inferior) proporciona los siguientes procedimientos para abrir un inferior:

 -- Procedimiento Scheme: inferior-for-channels CANALES
     [#:cache-directory] [#:ttl]
     Devuelve un inferior para CANALES, una lista de canales. Usa la caché en CACHE-DIRECTORY, donde las entradas pueden ser reclamadas después de TTL segundos. Este procedimiento abre una nueva conexión al daemon de construcción.

     Como efecto secundario, este procedimiento puede construir o sustituir binarios para CANALES, lo cual puede tomar cierto tiempo.

 -- Procedimiento Scheme: open-inferior DIRECTORIO
     [#:command "bin/guix"]
     Abre el Guix inferior en DIRECTORIO, ejecutando DIRECTORIO/COMMAND repl o su equivalente. Devuelve #f si el inferior no pudo ser ejecutado.

Los procedimientos enumerados a continuación le permiten obtener y manipular paquetes de inferiores.

 -- Procedimiento Scheme: inferior-packages INFERIOR
     Devuelve la lista de paquetes conocida por INFERIOR.

 -- Procedimiento Scheme: lookup-inferior-packages INFERIOR NOMBRE
     [VERSIÓN]
     Devuelve la lista ordenada de paquetes del inferior que corresponden con NOMBRE en INFERIOR, con los números de versión más altos primero. Si VERSIÓN tiene un valor verdadero, devuelve únicamente paquetes con un número de versión cuyo prefijo es VERSIÓN.

 -- Procedimiento Scheme: inferior-package? OBJ
     Devuelve verdadero si OBJ es un paquete inferior.

 -- Procedimiento Scheme: inferior-package-name PAQUETE
 -- Procedimiento Scheme: inferior-package-version PAQUETE
 -- Procedimiento Scheme: inferior-package-synopsis PAQUETE
 -- Procedimiento Scheme: inferior-package-description PAQUETE
 -- Procedimiento Scheme: inferior-package-home-page PAQUETE
 -- Procedimiento Scheme: inferior-package-location PAQUETE
 -- Procedimiento Scheme: inferior-package-inputs PAQUETE
 -- Procedimiento Scheme: inferior-package-native-inputs PAQUETE
 -- Procedimiento Scheme: inferior-package-propagated-inputs PAQUETE
 -- Procedimiento Scheme: inferior-package-transitive-propagated-inputs PAQUETE
 -- Procedimiento Scheme: inferior-package-native-search-paths PAQUETE
 -- Procedimiento Scheme: inferior-package-transitive-native-search-paths PAQUETE
 -- Procedimiento Scheme: inferior-package-search-paths PAQUETE
     Estos procedimientos son la contraparte de los accesos a los registros de pquete (see Referencia de ``package''). La mayor parte funcionan interrogando al inferior del que PAQUETE viene, por lo que el inferior debe estar vivo cuando llama a dichos procedimientos.

Los paquetes de inferiores pueden ser usados transparentemente como cualquier otro paquete u objeto-tipo-fichero en expresiones-G (see Expresiones-G). También se manejan transparentemente por el procedimiento packages->manifest, el cual se usa habitualmente en los manifiestos (see the --manifest option of guix package). Por tanto puede insertar un paquete de inferior prácticamente en cualquier lugar que pueda insertar un paquete normal: en manifiestos, en el campo packages de su declaración operating-system, etcétera.

Invocación de guix describe
===========================

A menudo desea responder a preguntas como: ``¿Qué revisión de Guix estoy usando?'' o ``¿Qué canales estoy usando?'' Esto es una información muy útil en muchas situaciones: si quiere replicar un entorno en una máquina diferente o cuenta de usuaria, si desea informar de un error o determinar qué cambio en los canales que usa lo causó, o si quiere almacenar el estado de su sistema por razones de reproducibilidad. La orden guix describe responde a estas preguntas.

Cuando se ejecuta desde un guix bajado con guix pull, guix describe muestra el/los canal/es desde el/los que se construyó, incluyendo la URL de su repositorio y los IDs de las revisiones (see Canales):

     $ guix describe
     Generation 10	Sep 03 2018 17:32:44	(current)
       guix e0fa68c
         repository URL: https://git.savannah.gnu.org/git/guix.git
         branch: master
         commit: e0fa68c7718fffd33d81af415279d6ddb518f727

Si está familiarizado con el sistema de control de versiones Git, esto es similar a git describe; la salida también es similar a la de guix pull --list-generations, pero limitada a la generación actual (see the --list-generations option). Debido a que el ID de revisión Git mostrado antes refiere sin ambigüedades al estado de Guix, esta información es todo lo necesario para describir la revisión de Guix que usa, y también para replicarla.

Para facilitar la replicación de Guix, también se le puede solicitar a guix describe devolver una lista de canales en vez de la descripción legible por humanos mostrada antes:

     $ guix describe -f channels
     (list (channel
             (name 'guix)
             (url "https://git.savannah.gnu.org/git/guix.git")
             (commit
               "e0fa68c7718fffd33d81af415279d6ddb518f727")))

Puede almacenar esto en un fichero y pasarselo a guix pull -C en otra máquina o en un momento futuro, lo cual instanciará esta revisión exacta de Guix (see the -C option). De aquí en adelante, ya que puede desplegar la misma revisión de Guix, puede también replicar un entorno completo de software. Nosotras humildemente consideramos que esto es impresionante, ¡y esperamos que le guste a usted también!

Los detalles de las opciones aceptadas por guix describe son las siguientes:

--format=FORMATO
-f FORMATO
     Produce salida en el FORMATO especificado, uno de:

     human
          produce salida legible por humanos;

     channels
          produce una lista de especificaciones de canales que puede ser pasada a guix pull -C o instalada como ~/.config/guix/channels.scm (see Invocación de guix pull);

     json
          produce una lista de especificaciones de canales en formato JSON;

     recutils
          produce una lista de especificaciones de canales en formato Recutils.

--profile=PERFIL
-p PERFIL
     Muestra información acerca del PERFIL.

Invocación de guix archive
==========================

La orden guix archive permite a las usuarias exportar ficheros del almacén en un único archivador, e importarlos posteriormente en una máquina que ejecute Guix. En particular, permite que los ficheros del almacén sean transferidos de una máquina al almacén de otra máquina.

     Si está buscando una forma de producir archivos en un formato adecuado para herramientas distintas a Guix, see Invocación de guix pack.

Para exportar ficheros del almacén como un archivo por la salida estándar, ejecute:

     guix archive --export OPCIONES ESPECIFICACIONES...

ESPECIFICACIONES deben ser o bien nombres de ficheros del almacén o especificaciones de paquetes, como las de guix package (see Invocación de guix package). Por ejemplo, la siguiente orden crea un archivo que contiene la salida gui del paquete git y la salida principal de emacs:

     guix archive --export git:gui /gnu/store/...-emacs-24.3 > great.nar

Si los paquetes especificados no están todavía construidos, guix archive los construye automáticamente. El proceso de construcción puede controlarse mediante las opciones de construcción comunes (see Opciones comunes de construcción).

Para transferir el paquete emacs a una máquina conectada por SSH, se ejecutaría:

     guix archive --export -r emacs | ssh otra-maquina guix archive --import

De manera similar, un perfil de usuaria completo puede transferirse de una máquina a otra de esta manera:

     guix archive --export -r $(readlink -f ~/.guix-profile) | \
       ssh otra-maquina guix-archive --import

No obstante, fíjese que, en ambos ejemplos, todo emacs y el perfil como también todas sus dependencias son transferidas (debido a la -r), independiente de lo que estuviese ya disponible en el almacén de la máquina objetivo. La opción --missing puede ayudar a esclarecer qué elementos faltan en el almacén objetivo. La orden guix copy simplifica y optimiza este proceso completo, así que probablemente es lo que debería usar en este caso (see Invocación de guix copy).

Los archivos se almacenan en el formato de ``archivo normalizado'' o ``nar'', el cual es comparable a `tar' en el espíritu, pero con diferencias que lo hacen más apropiado para nuestro propósito. Primero, en vez de almacenar todos los metadatos Unix de cada fichero, el formato nar solo menciona el tipo de fichero (normal, directorio o enlace simbólico); los permisos Unix y el par propietario/grupo se descartan. En segundo lugar, el orden en el cual las entradas de directorios se almacenan siempre siguen el orden de los nombres de ficheros de acuerdo a la ordenación de cadenas en la localización C. Esto hace la producción del archivo completamente determinista.

Durante la exportación, el daemon firma digitalmente los contenidos del archivo, y la firma digital se adjunta. Durante la importación, el daemon verifica la firma y rechaza la importación en caso de una firma inválida o si la clave firmante no está autorizada.

Las opciones principales son:

--export
     Exporta los ficheros del almacén o paquetes (véase más adelante). Escribe el archivo resultante a la salida estándar.

     Las dependencias no están incluidas en la salida, a menos que se use --recursive.

-r
--recursive
     Cuando se combina con --export, instruye a guix archive para incluir las dependencias de los elementos dados en el archivo. Por tanto, el archivo resultante está auto-contenido: contiene la clausura de los elementos exportados del almacén.

--import
     Lee un archivo de la entrada estándar, e importa los ficheros enumerados allí en el almacén. La operación se aborta si el archivo tiene una firma digital no válida, o si está firmado por una clave pública que no está entre las autorizadas (vea --authorize más adelante).

--missing
     Lee una lista de nombres de ficheros del almacén de la entrada estándar, uno por línea, y escribe en la salida estándar el subconjunto de estos ficheros que faltan en el almacén.

--generate-key[=PARÁMETROS]
     Genera un nuevo par de claves para el daemon. Esto es un prerrequisito antes de que los archivos puedan ser exportados con --export. Tenga en cuenta que esta operación normalmente toma tiempo, ya que se necesita obtener suficiente entropía para generar un par de claves.

     El par de claves generado se almacena típicamente bajo /etc/guix, en signing-key.pub (clave pública) y signing-key.sec (clave privada, que se debe mantener secreta). Cuando PARÁMETROS se omite, se genera una clave ECDSA usando la curva Ed25519, o, en versiones de Libgcrypt previas a la 1.6.0, es una clave RSA de 4096 bits. De manera alternativa, los PARÁMETROS pueden especificar parámetros genkey adecuados para Libgcrypt (see gcry_pk_genkey (The Libgcrypt Reference Manual)).

--authorize
     Autoriza importaciones firmadas con la clave pública pasada por la entrada estándar. La clave pública debe estar en el ``formato avanzado de expresiones-s''---es decir, el mismo formato que el fichero signing-key.pub.

     La lista de claves autorizadas se mantiene en el fichero editable por personas /etc/guix/acl. El fichero contiene ``expresiones-s en formato avanzado'' (http://people.csail.mit.edu/rivest/Sexp.text) y está estructurado como una lista de control de acceso en el formato Infraestructura Simple de Clave Pública (SPKI) (http://theworld.com/~cme/spki.txt).

--extract=DIRECTORIO
-x DIRECTORIO
     Lee un único elemento del archivo como es ofrecido por los servidores de sustituciones (see Sustituciones) y lo extrae a DIRECTORIO. Esta es una operación de bajo nivel necesitada únicamente para casos muy concretos; véase a continuación.

     Por ejemplo, la siguiente orden extrae la sustitución de Emacs ofrecida por ci.guix.es.info en /tmp/emacs:

          $ wget -O - \
            https://ci.guix.es.info/nar/...-emacs-24.5 \
            | bunzip2 | guix archive -x /tmp/emacs

     Los archivos de un único elemento son diferentes de los archivos de múltiples elementos producidos por guix archive --export; contienen un único elemento del almacén, y no embeben una firma. Por tanto esta operación no verifica la firma y su salida debe considerarse insegura.

     El propósito primario de esta operación es facilitar la inspección de los contenidos de un archivo que provenga probablemente de servidores de sustituciones en los que no se confía.

Desarrollo
**********

Si es una desarrolladora de software, Guix le proporciona herramientas que debería encontrar útiles---independientemente del lenguaje en el que desarrolle actualmente. Esto es sobre lo que trata este capítulo.

La orden guix environment proporciona una manera conveniente de configurar un entorno de desarrollo que contenga todas las dependencias y herramientas necesarias para trabajar en el paquete de software de su elección. La orden guix pack le permite crear aplicaciones empaquetadas que pueden ser distribuidas con facilidad a usuarias que no usen Guix.

Invocación de guix environment
==============================

El propósito de guix environment es ayudar a las hackers en la creación de entornos de desarrollo reproducibles sin modificar los paquetes de su perfil. La herramienta guix environment toma uno o más paquetes, construye todas sus entradas y crea un entorno shell para usarlos.

La sintaxis general es:

     guix environment OPCIONES PAQUETE...

El ejemplo siguiente lanza un nuevo shell preparado para el desarrollo de GNU Guile:

     guix environment guile

Si las dependencias necesarias no están construidas todavía, guix environment las construye automáticamente. El entorno del nuevo shell es una versión aumentada del entorno en el que guix environment se ejecutó. Contiene las rutas de búsqueda necesarias para la construcción del paquete proporcionado añadidas a las variables ya existentes. Para crear un entorno ``puro'', donde las variables de entorno previas no existen, use la opción --pure (Las usuarias habitualmente aumentan de forma incorrecta las variables de entorno como PATH en su fichero ~/.bashrc. Como consecuencia, cuando guix environment se ejecuta, Bash puede leer ~/.bashrc, por tanto introduciendo ``impurezas'' en esas variables de entorno. Es un error definir dichas variables de entorno en ~/.bashrc; en vez de ello deben definirse en .bash_profile, el cual es únicamente cargado por el shell de ingreso al sistema. See Bash Startup Files (The GNU Bash Reference Manual), para detalles sobre los ficheros de inicio de Bash.).

guix environment define la variable GUIX_ENVIRONMENT en el shell que lanza; su valor es el nombre de fichero del perfil para este entorno. Esto permite a las usuarias, digamos, definir un prompt para entornos de desarrollo en su .bashrc (see Bash Startup Files (The GNU Bash Reference Manual)):

     if [ -n "$GUIX_ENVIRONMENT" ]
     then
         export PS1="\u@\h \w [dev]\$ "
     fi

... o para explorar el perfil:

     $ ls "$GUIX_ENVIRONMENT/bin"

Adicionalmente, más de un paquete puede ser especificado, en cuyo caso se usa la unión de las entradas de los paquetes proporcionados. Por ejemplo, la siguiente orden lanza un shell donde todas las dependencias tanto de Guile como de Emacs están disponibles:

     guix environment guile emacs

A veces no se desea una sesión interactiva de shell. Una orden arbitraria puede invorcarse usando el valor -- para separar la orden del resto de los parámetros:

     guix environment guile -- make -j4

En otras situaciones, es más conveniente especificar una lista de paquetes necesarios en el entorno. Por ejemplo, la siguiente orden ejecuta python desde un entorno que contiene Python 2.7 y NumPy:

     guix environment --ad-hoc python2-numpy python-2.7 -- python

Más allá, se pueden desear las dependencias de un paquete y también algunos paquetes adicionales que no son dependencias ni en tiempo de construcción ni en el de ejecución, pero son útiles no obstante para el desarrollo. Por esta razón, la opción --ad-hoc es posicional. Los paquetes que aparecen antes de --ad-hoc se interpretan como paquetes cuyas dependencias se añadirán al entorno. Los paquetes que aparecen después se interpretan como paquetes que se añadirán directamente al entorno. Por ejemplo, la siguiente orden crea un entorno de desarrollo Guix que incluye adicionalmente Git y strace:

     guix environment guix --ad-hoc git strace

En ocasiones es deseable aislar el entorno tanto como sea posible, para obtener la máxima pureza y reproducibilidad. En particular, cuando se usa Guix en una distribución anfitriona que no es el sistema Guix, es deseable prevenir acceso a /usr/bin y otros recursos del sistema desde el entorno de desarrollo. Por ejemplo, la siguiente orden lanza un REPL Guile en un ``contenedor'' donde únicamente el almacén y el directorio actual están montados:

     guix environment --ad-hoc --container guile -- guile

     La opción --container requiere Linux-libre 3.19 o más nuevo.

Las opciones disponibles se resumen a continuación.

--root=FICHERO
-r FICHERO
     Hace que FICHERO sea un enlace simbólico al perfil para este entorno, y lo registra como una raíz del recolector de basura.

     Esto es útil si desea proteger su entorno de la recolección de basura, hacerlo ``persistente''.

     Cuando se omite esta opción, el entorno se protege de la recolección de basura únicamente por la duración de la sesión guix environment. Esto significa que la siguiente vez que vuelva a crear el mismo entorno, puede tener que reconstruir o volver a descargar paquetes. See Invocación de guix gc, para más información sobre las raices del recolector de basura.

--expression=EXPR
-e EXPR
     Crea un entorno para el paquete o lista de paquetes a los que evalúa EXPR.

     Por ejemplo, ejecutando:

          guix environment -e '(@ (gnu packages maths) petsc-openmpi)'

     inicia un shell con el entorno para esta variante específica del paquete PETSc.

     Ejecutar:

          guix environment --ad-hoc -e '(@ (gnu) %base-packages)'

     inicia un shell con todos los paquetes básicos del sistema disponibles.

     Las órdenes previas usan únicamente la salida predeterminada de los paquetes dados. Para seleccionar otras salidas, tuplas de dos elementos pueden ser especificadas:

          guix environment --ad-hoc -e '(list (@ (gnu packages bash) bash) "include")'

--load=FICHERO
-l FICHERO
     Crea un entorno para el paquete o la lista de paquetes a la que el código en FICHERO evalúa.

     Como un ejemplo, FICHERO puede contener una definición como esta (see Definición de paquetes):

               [file environment-gdb.scm not included]

--manifest=FICHERO
-m FICHERO
     Crea un entorno para los paquetes contenidos en el objeto manifest devuelto por el código Scheme en FILE.

     Esto es similar a la opción del mismo nombre en guix package (see --manifest) y usa los mismos ficheros de manifiesto.

--ad-hoc
     Incluye todos los paquetes especificados en el entorno resultante, como si un paquete ad hoc hubiese sido definido con ellos como entradas. Esta opción es útil para la creación rápida un entorno sin tener que escribir una expresión de paquete que contenga las entradas deseadas.

     Por ejemplo, la orden:

          guix environment --ad-hoc guile guile-sdl -- guile

     ejecuta guile en un entorno donde están disponibles Guile y Guile-SDL.

     Fíjese que este ejemplo solicita implícitamente la salida predeterminada de guile y guile-sdl, pero es posible solicitar una salida específica---por ejemplo, glib:bin solicita la salida bin de glib (see Paquetes con múltiples salidas).

     Esta opción puede componerse con el comportamiento predeterminado de guix environment. Los paquetes que aparecen antes de --ad-hoc se interpretan como paquetes cuyas dependencias se añadirán al entorno, el comportamiento predefinido. Los paquetes que aparecen después se interpretan como paquetes a añadir directamente al entorno.

--pure
     Olvida las variables de entorno existentes cuando se construye un nuevo entorno, excepto aquellas especificadas con --preserve (véase más adelante). Esto tiene el efecto de crear un entorno en el que las rutas de búsqueda únicamente contienen las entradas del paquete.

--preserve=REGEXP
-E REGEXP
     Cuando se usa junto a --pure, preserva las variables de entorno que corresponden con REGEXP---en otras palabras, las pone en una lista de variables de entorno que deben preservarse. Esta opción puede repetirse varias veces.

          guix environment --pure --preserve=^SLURM --ad-hoc openmpi ... \
            -- mpirun ...

     Este ejemplo ejecuta mpirun en un contexto donde las únicas variables de entorno definidas son PATH, variables de entorno cuyo nombre empiece con SLURM, así como las variables ``preciosas'' habituales (HOME, USER, etc.).

--search-paths
     Muestra las definiciones de variables de entorno que componen el entorno.

--system=SISTEMA
-s SISTEMA
     Intenta construir para SISTEMA---por ejemplo, i686-linux.

--container
-C
     Ejecuta la ORDEN en un contenedor aislado. El directorio actual fuera del contenedor es asociado al interior del contenedor. Adicionalmente, a menos que se fuerce con --user, un directorio de prueba de la usuaria se crea de forma que coincida con el directorio actual de la usuaria, y /etc/passwd se configura adecuadamente.

     El proceso lanzado se ejecuta como el usuario actual fuera del contenedor. Dentro del contenedor, tiene el mismo UID y GID que el usuario actual, a menos que se proporcione --user (véase más adelante).

--network
-N
     Para contenedores, comparte el espacio de nombres de red con el sistema anfitrión. Los contenedores creados sin esta opción únicamente tienen acceso a la red local.

--link-profile
-P
     Para contenedores, enlaza el perfil del entorno a ~/.guix-profile dentro del contenedor. Es equivalente a la ejecución de ln -s $GUIX_ENVIRONMENT ~/.guix-profile dentro del contenedor. El enlace fallará e interrumpirá el entorno si el directorio ya existe, lo cual será probablemente el caso si guix environment se invocó en el directorio de la usuaria.

     Determinados paquetes se configuran para buscar en ~/.guix-profile ficheros de configuración y datos; (Por ejemplo, el paquete fontconfig inspecciona ~/.guix-profile/share/fonts en busca de nuevas tipografías.) --link-profile permite a estos programas operar de la manera esperada dentro del entorno.

--user=USUARIA
-u USUARIA
     Para contenedores, usa el nombre de usuaria USUARIA en vez de la actual. La entrada generada en /etc/passwd dentro del contenedor contendrá el nombre USUARIA; su directorio será /home/USUARIA y ningún dato GECOS de la usuaria se copiará. Más aún, el UID y GID dentro del contenedor son 1000. USUARIA no debe existir en el sistema.

     Adicionalmente, cualquier ruta compartida o expuesta (véanse --share y --expose respectivamente) cuyo destino esté dentro de la carpeta actual de la usuaria será reasociada en relación a /home/USUARIA; esto incluye la relación automática del directorio de trabajo actual.

          # expondrá las rutas /home/foo/ddt, /home/foo/prueba y /home/foo/objetivo
          cd $HOME/ddt
          guix environment --container --user=foo \
               --expose=$HOME/prueba \
               --expose=/tmp/objetivo=$HOME/objetivo

     Mientras esto limita el escape de la identidad de la usuaria a través de las rutas de sus directorios y cada uno de los campos de usuaria, esto es únicamente un componente útil de una solución de privacidad/anonimato más amplia---no una solución completa.

--expose=FUENTE[=DESTINO]
     Para contenedores, expone el sistema de ficheros FUENTE del sistema anfitrión como un sistema de ficheros de solo-lectura DESTINO dentro del contenedor. Si no se especifica DESTINO, FUENTE se usa como el punto de montaje en el contenedor.

     El ejemplo a continuación lanza una sesión interactiva de Guile en un contenedor donde el directorio principal de la usuaria es accesible en modo solo-lectura a través del directorio /intercambio:

          guix environment --container --expose=$HOME=/intercambio --ad-hoc guile -- guile

--share=FUENTE[=DESTINO]
     Para contenedores, comparte el sistema de ficheros FUENTE del sistema anfitrión como el sistema de ficheros DESTINO con permisos de escritura dentro del contenedor. Si no se especifica DESTINO, FUENTE se usa como punto de montaje en el contenedor.

     El siguiente ejemplo lanza un entorno interactivo Guile en un contenedor en el que el directorio principal de la usuaria está disponible para tanto lectura como escritura via el directorio /intercambio:

          guix environment --container --share=$HOME=/intercambio --ad-hoc guile -- guile

Además, guix environment acepta todas las opciones comunes de construcción que permite guix build (see Opciones comunes de construcción) así como las opciones de transformación de paquetes (see Opciones de transformación de paquetes).

Invocación de guix pack
=======================

De manera ocasional querrá dar software a gente que (¡todavía!) no tiene la suerte de usar Guix. Usted les diría que ejecuten guix package -i ALGO, pero eso no es posible en este caso. Aquí es donde viene guix pack.

     Si está buscando formas de intercambiar binarios entre máquinas que ya ejecutan Guix, see Invocación de guix copy, Invocación de guix publish, y Invocación de guix archive.

La orden guix pack crea un paquete reducido o empaquetado de software: crea un archivador tar u otro tipo que contiene los binarios del software en el que está interesada y todas sus dependencias. El archivo resultante puede ser usado en una máquina que no tiene Guix, y la gente puede ejecutar exactamente los mismos binarios que usted tiene con Guix. El paquete en sí es creado de forma reproducible bit-a-bit, para que cualquiera pueda verificar que realmente contiene los resultados de construcción que pretende distribuir.

Por ejemplo, para crear un empaquetado que contenga Guile, Emacs, Geiser y todas sus dependencias, puede ejecutar:

     $ guix pack guile emacs geiser
     ...
     /gnu/store/...-pack.tar.gz

El resultado aquí es un archivador tar que contiene un directorio de /gnu/store con todos los paquetes relevantes. El archivador resultante contiene un perfil con los tres paquetes de interés; el perfil es el mismo que se hubiera creado por guix package -i. Este es el mecanismo usado para crear el propio archivador de binarios separado de Guix (see Instalación binaria).

Las usuarias de este empaquetad tendrán que ejecutar /gnu/store/...-profile/bin/guile para ejecutar guile, lo que puede resultar inconveniente. Para evitarlo, puede crear, digamos, un enlace simbólico /opt/gnu/bin al perfil:

     guix pack -S /opt/gnu/bin=bin guile emacs geiser

De este modo, las usuarias pueden escribir alegremente /opt/gnu/bin/guile y disfrutar.

¿Qué pasa se la receptora de su paquete no tiene privilegios de root en su máquina y por lo tanto no puede desempaquetarlo en la raíz del sistema de ficheros? En ese caso, lo que usted desea es usar la opción --relocatable (véase a continuación). Esta opción produce binarios relocalizables, significando que pueden ser colocados en cualquier lugar de la jerarquía del sistema de ficheros: en el ejemplo anterior, las usuarias pueden desempaquetar el archivador en su directorio de usuaria y ejecutar directamente ./opt/gnu/bin/guile.

De manera alternativa, puede producir un empaquetado en el formato de imagen Docker usando la siguiente orden:

     guix pack -f docker guile emacs geiser

El resultado es un archivador tar que puede ser pasado a la orden docker load. Véase la documentación de Docker (https://docs.docker.com/engine/reference/commandline/load/) para más información.

Otra opción más es producir una imagen SquashFS con la siguiente orden:

     guix pack -f squashfs guile emacs geiser

El resultado es una imagen de sistema de ficheros SquashFS que puede ser o bien montada, o bien usada directamente como una imagen contenedora de sistemas de ficheros con el entorno de ejecución de contenedores Singularity (http://singularity.lbl.gov), usando órdenes como singularity shell o singularity exec.

Varias opciones de la línea de órdenes le permiten personalizar su empaquetado:

--format=FORMATO
-f FORMATO
     Produce un empaquetado en el FORMATO específico.

     Los formatos disponibles son:

     tarball
          Es el formato predeterminado. Produce un archivador que contiene todos los binarios y enlaces simbólicos especificados.

     docker
          Produce un archivador que sigue la especificación de imágenes Docker (https://github.com/docker/docker/blob/master/image/spec/v1.2.md).

     squashfs
          Produce una imagen SquashFS que contiene todos los binarios y enlaces simbólicos especificados, así como puntos de montaje vacíos para sistemas de ficheros virtuales como procfs.

--relocatable
-R
     Produce binarios reposicionables---es decir, binarios que se pueden posicionar en cualquier lugar de la jerarquía del sistema de ficheros, y ejecutarse desde allí.

     When this option is passed once, the resulting binaries require support for user namespaces in the kernel Linux; when passed twice (Here's a trick to memorize it: -RR, which adds PRoot support, can be thought of as the abbreviation of ``Really Relocatable''.  Neat, isn't it?), relocatable binaries fall to back to PRoot if user namespaces are unavailable, and essentially work anywhere---see below for the implications.

     Por ejemplo, si crea un empaquetado que contiene Bash con:<

          guix pack -RR -S /mybin=bin bash

     ... puede copiar ese empaquetado a una máquina que no tiene Guix, y desde su directorio, como una usuaria normal, ejecutar:

          tar xf pack.tar.gz
          ./mibin/sh

     En ese shell, si escribe ls /gnu/store, notará que /gnu/store muestra y contiene todas las dependencias de bash, ¡incluso cuando la máquina no tiene el directorio /gnu/store! Esto es probablemente el modo más simple de desplegar software construido en Guix en una máquina no-Guix.

          No obstante hay un punto a tener en cuenta: esta técnica descansa en la característica de espacios de nombres de usuaria del núcleo Linux, la cual permite a usuarias no privilegiadas montar o cambiar la raíz. Versiones antiguas de Linux no los implementan, y algunas distribuciones GNU/Linux los deshabilitan.

          Para producir binarios reposicionables que funcionen incluso en ausencia de espacios de nombre de usuaria, proporcione --relocatable o -R dos veces. En ese caso, los binarios intentarán el uso de espacios de nombres de usuaria y usarán PRoot si no es posible.

          El programa PRoot (https://proot-me.github.io/) proporciona el soporte necesario para la virtualización del sistema de ficheros. Lo consigue mediante el uso de la llamada al sistema ptrace en el programa en ejecución. Esta aproximación tiene la ventaja de funcionar sin soporte especial en el núcleo, pero incurre en una sobrecarga en el tiempo de ejecución cada vez que se realiza una llamada al sistema.

--expression=EXPR
-e EXPR
     Considera el paquete al que evalúa EXPR

     Esto tiene el mismo propósito que la opción del mismo nombre en guix build (see --expression in guix build).

--manifest=FICHERO
-m FICHERO
     Usa los paquetes contenidos en el objeto manifest devuelto por el código Scheme en FILE.

     Esto tiene un propósito similar al de la opción del mismo nombre en guix package (see --manifest) y usa los mismos ficheros de manifiesto. Esto le permite definir una colección de paquetes una vez y usarla tanto para crear perfiles como para crear archivos en máquinas que no tienen instalado Guix. Fíjese que puede especificar o bien un fichero de manifiesto o bien una lista de paquetes, pero no ambas.

--system=SISTEMA
-s SISTEMA
     Intenta construir paquetes para SISTEMA---por ejemplo, x86_64-linux---en vez del tipo de sistema de la máquina de construcción.

--target=TRIPLETA
     Compilación cruzada para la TRIPLETA, que debe ser una tripleta GNU válida, cómo "mips64el-linux-gnu" (see GNU configuration triplets (Autoconf)).

--compression=HERRAMIENTA
-C HERRAMIENTA
     Comprime el archivador resultante usando HERRAMIENTA---un valor que puede ser gzip, bzip2, xz, lzip o none para no usar compresión.

--symlink=SPEC
-S SPEC
     Añade los enlaces simbólicos especificados por SPEC al empaquetado. Esta opción puede aparecer varias veces.

     La forma de SPEC es FUENTE=DESTINO, donde FUENTE es el enlace simbólico que será creado y DESTINO es el destino del enlace simbólico.

     Por ejemplo, -S /opt/gnu/bin=bin crea un enlace simbólico /opt/gnu/bin apuntando al subdirectorio bin del perfil.

--save-provenance
     Save provenance information for the packages passed on the command line. Provenance information includes the URL and commit of the channels in use (see Canales).

     Provenance information is saved in the /gnu/store/...-profile/manifest file in the pack, along with the usual package metadata---the name and version of each package, their propagated inputs, and so on.  It is useful information to the recipient of the pack, who then knows how the pack was (supposedly) obtained.

     This option is not enabled by default because, like timestamps, provenance information contributes nothing to the build process.  In other words, there is an infinity of channel URLs and commit IDs that can lead to the same pack.  Recording such ``silent'' metadata in the output thus potentially breaks the source-to-binary bitwise reproducibility property.

--localstatedir
--profile-name=NOMBRE
     Incluye el ``directorio de estado local'', /var/guix, en el empaquetado resultante, y notablemente el perfil /var/guix/profiles/per-user/root/NOMBRE---por defecto NOMBRE es guix-profile, que corresponde con ~root/.guix-profile.

     /var/guix contiene la base de datos del almacén (see El almacén) así como las raíces del recolector de basura (see Invocación de guix gc). Proporcionarlo junto al empaquetado significa que el almacén está ``completo'' y Guix puede trabajar con él; no proporcionarlo significa que el almacén está ``muerto'': no se pueden añadir o borrar nuevos elementos después de la extracción del empaquetado.

     Un caso de uso para esto es el archivador tar autocontenido de binarios de Guix (see Instalación binaria).

--bootstrap
     Usa los binarios del lanzamiento para construir el empaquetado. Esta opción es útil únicamente a las desarrolladoras de Guix.

Además, guix pack acepta todas las opciones comunes de construcción (see Opciones comunes de construcción) y todas las opciones de transformación de paquetes (see Opciones de transformación de paquetes).

Interfaz programática
*********************

GNU Guix proporciona viarias interfaces programáticas Scheme (APIs) para definir, construir y consultar paquetes. La primera interfaz permite a las usuarias escribir definiciones de paquetes a alto nivel. Estas definiciones referencian conceptos familiares de empaquetamiento, como el nombre y la versión de un paquete, su sistema de construcción y sus dependencias. Estas definiciones se pueden convertir en acciones concretas de construcción.

Las acciones de construcción son realizadas por el daemon Guix, en delegación de las usuarias. En una configuración estándar, el daemon tiene acceso de escritura al almacén---el directorio /gnu/store---mientras que las usuarias no. En la configuración recomendada el daemon también realiza las construcciones en chroots, bajo usuarias específicas de construcción, para minimizar la interferencia con el resto del sistema.

Las APIs de nivel más bajo están disponibles para interactuar con el daemon y el almacén. Para instruir al daemon para realizar una acción de construcción, las usuarias realmente proporcionan una derivación. Una derivación es una representación de bajo nivel de las acciones de construcción a tomar, y el entorno en el que deberían suceder---las derivaciones son a las definiciones de paquetes lo que es el ensamblador a los programas en C. El término ``derivación'' viene del hecho de que los resultados de la construcción derivan de ellas.

Este capítulo describe todas estas APIs en orden, empezando por las definiciones de alto nivel de paquetes.

Módulos de paquetes
===================

Desde un punto de vista programático, las definiciones de paquetes de la distribución GNU se proporcionan por módulos Guile en el espacio de nombres (gnu packages ...) (Fíjese que los paquetes bajo el espacio de nombres de módulo (gnu packages ...) no son necesariamente ``paquetes GNU''. Este esquema de nombrado de módulos sigue la convención habitual de Guile para el nombrado de módulos: gnu significa que estos módulos se distribuyen como parte del sistema GNU, y packages identifica módulos que definen paquetes.) (see Guile modules (GNU Guile Reference Manual)). Por ejemplo, el módulo (gnu packages emacs) exporta una variable con nombre emacs, que está asociada a un objeto <package> (see Definición de paquetes).

El espacio de nombres de módulos (gnu packages ...) se recorre automáticamente en busca de paquetes en las herramientas de línea de ordenes. Por ejemplo, cuando se ejecuta guix package -i emacs, todos los módulos (gnu packages ...) son procesados hasta encontrar uno que exporte un objeto de paquete cuyo nombre sea emacs. Esta búsqueda de paquetes se implementa en el módulo (gnu packages).

Las usuarias pueden almacenar definiciones de paquetes en módulos con nombres diferentes---por ejemplo, (mis-paquetes emacs) (Fíjese que el nombre de fichero y el nombre de módulo deben coincidir. Por ejemplo, el módulo (mis-paquetes emacs) debe almacenarse en el fichero mis-paquetes/emacs.scm en relación con la ruta de carga especificada con --load-path o GUIX_PACKAGE_PATH. See Modules and the File System (GNU Guile Reference Manual), para obtener detalles.). Existen dos maneras de hacer visibles estas definiciones de paquetes a las interfaces de usuaria:

 1. Mediante la adición del directorio que contiene sus módulos de paquetes a la ruta de búsqueda con la opción -L de guix package y otras órdenes (see Opciones comunes de construcción), o usando la variable de entorno GUIX_PACKAGE_PATH descrita más adelante.

 2. Mediante la definición de un canal y la configuración de guix pull de manera que se actualice desde él. Un canal es esencialmente un repositorio Git que contiene módulos de paquetes. See Canales, para más información sobre cómo definir y usar canales.

GUIX_PACKAGE_PATH funciona de forma similar a otras variables de rutas de búsqueda:

 -- Variable de entorno: GUIX_PACKAGE_PATH
     Es una lista separada por dos puntos de directorios en los que se buscarán módulos de paquetes adicionales. Los directorios enumerados en esta variable tienen preferencia sobre los propios módulos de la distribución.

La distribución es auto-contenida y completamente basada en el lanzamiento inicial: cada paquete se construye basado únicamente en otros paquetes de la distribución. La raíz de este grafo de dependencias es un pequeño conjunto de binarios del lanzamiento inicial, proporcionados por el módulo (gnu packages bootstrap). Para más información sobre el lanzamiento inicial, see Lanzamiento inicial.

Definición de paquetes
======================

La interfaz de alto nivel de las definiciones de paquetes está implementada en los módulos (guix packages) y (guix build-system). Como un ejemplo, la definición de paquete, o receta, para el paquete GNU Hello es como sigue:

     (define-module (gnu packages hello)
       #:use-module (guix packages)
       #:use-module (guix download)
       #:use-module (guix build-system gnu)
       #:use-module (guix licenses)
       #:use-module (gnu packages gawk))

     (define-public hello
       (package
         (name "hello")
         (version "2.10")
         (source (origin
                   (method url-fetch)
                   (uri (string-append "mirror://gnu/hello/hello-" version
                                       ".tar.gz"))
                   (sha256
                    (base32
                     "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
         (build-system gnu-build-system)
         (arguments '(#:configure-flags '("--enable-silent-rules")))
         (inputs `(("gawk" ,gawk)))
         (synopsis "Hello, GNU world: An example GNU package")
         (description "Guess what GNU Hello prints!")
         (home-page "http://www.gnu.org/software/hello/")
         (license gpl3+)))

Sin ser una experta en Scheme---pero conociendo un poco de inglés---, la lectora puede haber supuesto el significado de varios campos aquí. Esta expresión asocia la variable hello al objeto <package>, que esencialmente es un registro (see Scheme records (GNU Guile Reference Manual)). Este objeto de paquete puede ser inspeccionado usando los procedimientos encontrados en el módulo (guix packages); por ejemplo, (package-name hello) devuelve---¡sorpresa!---"hello".

Con suerte, puede que sea capaz de importar parte o toda la definición del paquete de su interés de otro repositorio, usando la orden guix import (see Invocación de guix import).

En el ejemplo previo, HELLO se define en un módulo para ella, (gnu packages hello). Técnicamente, esto no es estrictamente necesario, pero es conveniente hacerlo: todos los paquetes definidos en módulos bajo (gnu packages ...) se reconocen automáticamente en las herramientas de línea de órdenes (see Módulos de paquetes).

Hay unos pocos puntos que merece la pena destacar de la definición de paquete previa:

  * El campo source del paquete es un objeto <origin> (see Referencia de ``origin'', para la referencia completa). Aquí se usa el método url-fetch de (guix download), lo que significa que la fuente es un fichero a descargar por FTP o HTTP.

     El prefijo mirror://gnu instruye a url-fetch para usar uno de los espejos GNU definidos en (guix download).

     El campo sha256 especifica el hash SHA256 esperado del fichero descargado. Es obligatorio, y permite a Guix comprobar la integridad del fichero. La forma (base32 ...) introduce la representación base32 del hash. Puede obtener esta información con guix download (see Invocación de guix download) y guix hash (see Invocación de guix hash).

     Cuando sea necesario, la forma origin también puede tener un campo patches con la lista de parches a ser aplicados, y un campo snippet con una expresión Scheme para modificar el código fuente.

  * El campo build-system especifica el procedimiento de construcción del paquete (see Sistemas de construcción). Aquí, GNU-BUILD-SYSTEM representa el familiar sistema de construcción GNU, donde los paquetes pueden configurarse, construirse e instalarse con la secuencia de ordenes habitual ./configure && make && make check && make install.

  * El campo arguments especifica las opciones para el sistema de construcción (see Sistemas de construcción). Aquí son interpretadas por GNU-BUILD-SYSTEM como una petición de ejecutar configure con la opción --enable-silent-rules.

     ¿Qué son estas comillas simples (')? Son sintaxis Scheme para introducir una lista literal; ' es sinónimo de quote. See quoting (GNU Guile Reference Manual), para más detalles. Aquí el valor del campo arguments es una lista de parámetros pasada al sistema de construcción, como con apply (see apply (GNU Guile Reference Manual)).

     La secuencia almohadilla-dos puntos (#:) define una palabra clave Scheme (see Keywords (GNU Guile Reference Manual)), y #:configure-flags es una palabra clave usada para pasar un parámetro nominal al sistema de construcción (see Coding With Keywords (GNU Guile Reference Manual)).

  * El campo inputs especifica las entradas al proceso de construcción---es decir, dependencias de tiempo de construcción o ejecución del paquete. Aquí, definimos una entrada llamada "gawk", cuyo valor es el de la variable GAWK; GAWK en sí apunta a un objeto <package>.

     De nuevo, ` (un acento grave, sinónimo de quasiquote) nos permite introducir una lista literal en el campo inputs, mientras que , (una coma, sinónimo de unquote) nos permite insertar un valor en dicha lista (see unquote (GNU Guile Reference Manual)).

     Fíjese que no hace falta que GCC, Coreutils, Bash y otras herramientas esenciales se especifiquen como entradas aquí. En vez de eso, GNU-BUILD-SYSTEM se hace cargo de asegurar que están presentes (see Sistemas de construcción).

     No obstante, cualquier otra dependencia debe ser especificada en el campo inputs. Las dependencias no especificadas aquí simplemente no estarán disponibles para el proceso de construcción, provocando posiblemente un fallo de construcción.

See Referencia de ``package'', para una descripción completa de los campos posibles.

Una vez la definición de paquete esté en su lugar, el paquete puede ser construido realmente usando la herramienta de línea de órdenes guix build (see Invocación de guix build), pudiendo resolver cualquier fallo de construcción que encuentre (see Depuración de fallos de construcción). Puede volver a la definición del paquete fácilmente usando la orden guix edit (see Invocación de guix edit). See Guías de empaquetamiento, para más información sobre cómo probar definiciones de paquetes, y Invocación de guix lint, para información sobre cómo comprobar la consistencia del estilo de una definición. Por último, see Canales, para información sobre cómo extender la distribución añadiendo sus propias definiciones de paquetes en un ``canal''.

Finalmente, la actualización de la definición con una nueva versión oficial puede ser automatizada parcialmente por la orden guix refresh (see Invocación de guix refresh).

Tras el telón, una derivación correspondiente al objeto <package> es calculada mediante el procedimiento package-derivation. Esta derivación es almacenada en un fichero .drv bajo /gnu/store. Las acciones de construcción que prescribe pueden entonces llevarse a cabo usando el procedimiento build-derivations (see El almacén).

 -- Procedimiento Scheme: package-derivation ALMACÉN PAQUETE [SISTEMA]
     Devuelve el objeto <derivation> del PAQUETE pra el SISTEMA (see Derivaciones).

     PAQUETE debe ser un objeto <package> válido, y SISTEMA debe ser una cadena que denote el tipo de sistema objetivo---por ejemplo, "x86_64-linux" para un sistema GNU x86_64 basado en Linux. ALMACÉN debe ser una conexión al daemon, que opera en el almacén (see El almacén).

De manera similar, es posible calcular una derivación que construye de forma cruzada un paquete para otro sistema:

 -- Procedimiento Scheme: package-cross-derivation ALMACÉN
     PAQUETE PLATAFORMA [SISTEMA]
     Devuelve el objeto <derivation> de PAQUETE compilado de forma cruzada desde SISTEMA a PLATAFORMA.

     PLATAFORMA debe ser una tripleta GNU válida que denote el hardware y sistema operativo objetivo, como "mips64el-linux-gnu" (see GNU configuration triplets (GNU Configure and Build System)).

Los paquetes se pueden manipular de forma arbitraria. Un ejemplo de transformación útil es la reescritura de entradas, donde el árbol de dependencias de un paquete se reescribe reemplazando entradas específicas por otras:

 -- Procedimiento Scheme: package-input-rewriting REEMPLAZOS
     [NOMBRE-REESCRITO]
     Devuelve un procedimiento que, cuando se le pasa un paquete, reemplaza sus dependencias directas e indirectas (pero no sus entradas implícitas) de acuerdo a REEMPLAZOS. REEMPLAZOS es una lista de pares de paquetes; el primer elemento de cada par es el paquete a reemplazar, el segundo es el reemplazo.

     Opcionalmente, NOMBRE-REESCRITO es un procedimiento de un parámetro que toma el nombre del paquete y devuelve su nuevo nombre tras la reescritura.

Considere este ejemplo:

     (define libressl-en-vez-de-openssl
       ;; Esto es un procedimiento para reemplazar OPENSSL
       ;; por LIBRESSL, recursivamente.
       (package-input-rewriting `((,openssl . ,libressl))))

     (define git-con-libressl
       (libressl-en-vez-de-openssl git))

Aquí primero definimos un procedimiento de reescritura que substituye OPENSSL por LIBRESSL. Una vez hecho esto, lo usamos para definir una variante del paquete GIT que usa LIBRESSL en vez de OPENSSL. Esto es exactamente lo que hace la opción de línea de órdenes --with-input (see --with-input).

The following variant of package-input-rewriting can match packages to be replaced by name rather than by identity.

 -- Procedimiento Scheme: package-input-rewriting/spec REEMPLAZOS
     Return a procedure that, given a package, applies the given REPLACEMENTS to all the package graph (excluding implicit inputs). REPLACEMENTS is a list of spec/procedures pair; each spec is a package specification such as "gcc" or "guile@2", and each procedure takes a matching package and returns a replacement for that package.

The example above could be rewritten this way:

     (define libressl-en-vez-de-openssl
       ;; Reemplaza todos los paquetes llamados "openssl" con LibreSSL.
       (package-input-rewriting/spec `(("openssl" . ,(const libressl)))))

The key difference here is that, this time, packages are matched by spec and not by identity.  In other words, any package in the graph that is called openssl will be replaced.

Un procedimiento más genérico para reescribir el grafo de dependencias de un paquete es package-mapping: acepta cambios arbitrarios sobre nodos del grafo.

 -- Scheme Procedure: package-mapping PROC [CORTAR?]
     Devuelve un procedimiento que, dado un paquete, aplica PROC a todos los paquetes de los que depende y devuelve el paquete resultante. El procedimiento para la recursión cuando CORTAR? devuelve verdadero para un paquete dado.

Referencia de package
---------------------

Esta sección resume todas las opciones disponibles en declaraciones package (see Definición de paquetes).

 -- Tipo de datos: package
     Este es el tipo de datos que representa la receta de un paquete.

     name
          El nombre del paquete, como una cadena.

     version
          La versión del paquete, como una cadena.

     source
          Un objeto que determina cómo se debería obtener el código fuente del paquete. La mayor parte del tiempo, es un objeto origin, que denota un fichero obtenido de Internet (see Referencia de ``origin''). También puede ser cualquier otro objeto ``tipo-fichero'' como local-file, que denota un fichero del sistema local de ficheros (see local-file).

     build-system
          El sistema de construcción que debe ser usado para construir el paquete (see Sistemas de construcción).

     arguments (predeterminados: '())
          Los parámetros que deben ser pasados al sistema de construcción. Es una lista que normalmente contiene una secuencia de pares de palabra clave y valor.

     inputs (predeterminadas: '())
     native-inputs (predeterminadas: '())
     propagated-inputs (predeterminadas: '())
          Estos campos enumeran las dependencias del paquete. Cada uno es una lista de tuplas, donde cada tupla tiene una etiqueta para la entrada (una cadena) como su primer elemento, un paquete, origen o derivación como su segundo elemento, y opcionalmente el nombre de la salida que debe ser usada, cuyo valor predeterminado es "out" (see Paquetes con múltiples salidas, para más información sobre salidas de paquetes). Por ejemplo, la lista siguiente especifica tres entradas:

               `(("libffi" ,libffi)
                 ("libunistring" ,libunistring)
                 ("glib:bin" ,glib "bin"))  ;la salida "bin" de Glib

          La distinción entre native-inputs y inputs es necesaria cuando se considera la compilación cruzada. Cuando se compila cruzadamente, las dependencias enumeradas en inputs son construidas para la arquitectura objetivo; de modo contrario, las dependencias enumeradas en native-inputs se construyen para la arquitectura de la máquina de construcción.

          native-inputs se usa típicamente para enumerar herramientas necesarias en tiempo de construcción, pero no en tiempo de ejecución, como Autoconf, Automake, pkg-config, Gettext o Bison. guix lint puede informar de probables errores en este área (see Invocación de guix lint).

          Por último, propagated-inputs es similar a inputs, pero los paquetes especificados se instalarán automáticamente junto al paquete al que pertenecen (see guix package, para información sobre cómo guix package maneja las entradas propagadas).

          Por ejemplo esto es necesario cuando una biblioteca C/C++ necesita cabeceras de otra biblioteca para compilar, o cuando un fichero pkg-config se refiere a otro via su campo Requires.

          Otro ejemplo donde propagated-inputs es útil es en lenguajes que carecen de la facilidad de almacenar la ruta de búsqueda de tiempo de ejecución de la misma manera que el campo RUNPATH de los ficheros ELF; esto incluye Guile, Python, Perl y más. Para asegurarse que las bibliotecas escritas en esos lenguajes puedan encontrar en tiempo de ejecución el código de las bibliotecas de las que dependen, las dependencias de tiempo de ejecución deben enumerarse en propagated-inputs en vez de en inputs.

     outputs (predeterminada: '("out"))
          La lista de nombres de salidas del paquete. See Paquetes con múltiples salidas, para usos típicos de salidas adicionales.

     native-search-paths (predeterminadas: '())
     search-paths (predeterminadas: '())
          Una lista de objetos search-path-specification describiendo las variables de entorno de rutas de búsqueda respetadas por el paquete.

     replacement (predeterminado: 1.0)
          Esto debe ser o bien #f o bien un objeto package que será usado como reemplazo para ete paquete. See injertos, para más detalles.

     synopsis
          Una descripción en una línea del paquete.

     description
          Una descripción más elaborada del paquete.

     license
          La licencia del paquete; un valor de (guix licenses), o una lista de dichos valores.

     home-page
          La URL de la página principal del paquete, como una cadena.

     supported-systems (predeterminados: %supported-systems)
          La lista de sistemas en los que se mantiene el paquete, como cadenas de la forma arquitectura-núcleo, por ejemplo "x86_64-linux".

     maintainers (predeterminadas: '())
          La lista de responsables del paquete, como objetos maintainer.

     location (predeterminada: la localización de los fuentes de la forma package)
          La localización de las fuentes del paquete. Es útil forzar su valor cuando se hereda de otro paquete, en cuyo caso este campo no se corrige automáticamente.

 -- Scheme Syntax: this-package
     When used in the lexical scope of a package field definition, this identifier resolves to the package being defined.

     The example below shows how to add a package as a native input of itself when cross-compiling:

          (package
            (name "guile")
            ;; ...

            ;; When cross-compiled, Guile, for example, depends on
            ;; a native version of itself.  Add it here.
            (native-inputs (if (%current-target-system)
                               `(("self" ,this-package))
                               '())))

     It is an error to refer to this-package outside a package definition.

Referencia de origin
--------------------

Esta sección resume todas las opciones disponibles en declaraciones origin (see Definición de paquetes).

 -- Tipo de datos: origin
     Este es el tipo de datos que representa un origen de código fuente.

     uri
          Un objeto que contiene el URI de las fuentes. El tipo de objeto depende del valor de method (véase a continuación). Por ejemplo, cuando se usa el método URL-FETCH de (guix download), los valores válidos de uri son: una cadena que contiene una URL, o una lista de cadenas.

     method
          Un procedimiento que maneja el URI.

          Algunos ejemplos son:

          URL-FETCH de (guix download)
               descarga un fichero de la URL HTTP, HTTPS o FTP especificada en el campo uri;

          GIT-FETCH de (guix git-download)
               clona el repositorio de control de versiones Git, y prepara la revisión especificada en el campo uri como un objeto git-reference; una referencia git-reference tiene esta forma:

                    (git-reference
                      (url "git://git.debian.org/git/pkg-shadow/shadow")
                      (commit "v4.1.5.1"))

     sha256
          Un vector de bytes que contiene el hash SHA-256 de las fuentes. Típicamente la forma base32 se usa aquí para generar el vector de bytes de una cadena en base-32.

          Puede obtener esta información usando guix download (see Invocación de guix download) o guix hash (see Invocación de guix hash).

     file-name (predeterminado: #f)
          El nombre de fichero bajo el que el código fuente se almacenará. Cuando este es #f, un valor predeterminado sensato se usará en la mayor parte de casos. En caso de que las fuentes se obtengan de una URL, el nombre de fichero de la URL se usará. Para copias de trabajo de sistemas de control de versiones, se recomienda proporcionar el nombre de fichero explícitamente ya que el predeterminado no es muy descriptivo.

     patches (predeterminados: '())
          Una lista de nombres de ficheros, orígenes u objetos tipo-fichero (see objetos tipo-fichero) apuntando a parches que deben ser aplicados a las fuentes.

          La lista de parches debe ser incondicional. En particular, no puede depender del varlo de %current-system o %current-target-system.

     snippet (predeterminado: #f)
          Una expresión-G (see Expresiones-G) o expresión-S que se ejecutará en el directorio de fuentes. Esta es una forma conveniente de modificar el software, a veces más que un parche.

     patch-flags (predeterminadas: '("-p1"))
          Una lista de opciones de línea de órdenes que deberían ser pasadas a la orden patch.

     patch-inputs (predeterminada: #f)
          Paquetes o derivaciones de entrada al proceso de aplicación de los parches. Cuando es #f, se proporciona el conjunto habitual de entradas necesarias para la aplicación de parches, como GNU Patch.

     modules (predeterminados: '())
          Una lista de módulos Guile que debe ser cargada durante el proceso de aplicación de parches y mientras se ejecuta el código del campo snippet.

     patch-guile (predeterminado: #f)
          El paquete Guile que debe ser usado durante la aplicación de parches. Cuando es #f se usa un valor predeterminado.

Sistemas de construcción
========================

Cada definición de paquete especifica un sistema de construcción y parámetros para dicho sistema de construcción (see Definición de paquetes). Este campo build-system representa el procedimiento de construcción del paquete, así como las dependencias implícitas de dicho procedimiento de construcción.

Los sistemas de construcción son objetos <build-system>. La interfaz para crear y manipularlos se proporciona en el módulo (guix build-system), y otros módulos exportan sistemas de construcción reales.

En su implementación, los sistemas de construcción primero compilan los objetos package a objetos bag. Una bolsa (traducción de bag) es como un paquete, pero con menos ornamentos---en otras palabras, una bolsa es una representación a un nivel más bajo de un paquete, que contiene todas las entradas de dicho paquete, incluyendo algunas implícitamente añadidas por el sistema de construcción. Esta representación intermedia se compila entonces a una derivación (see Derivaciones).

Los sistemas de construcción aceptan una lista opcional de parámetros. En las definiciones de paquete, estos son pasados vía el campo arguments (see Definición de paquetes). Normalmente son parámetros con palabras clave (see keyword arguments in Guile (GNU Guile Reference Manual)). El valor de estos parámetros normalmente se evalúa en la capa de construcción---es decir, por un proceso Guile lanzado por el daemon (see Derivaciones).

El sistema de construcción principal es GNU-BUILD-SYSTEM, el cual implementa el procedimiento estándar de construcción para GNU y muchos otros paquetes. Se proporciona por el módulo (guix build-system gnu).

 -- Variable Scheme: gnu-build-system
     GNU-BUILD-SYSTEM representa el sistema de construcción GNU y sus variantes (see configuration and makefile conventions (GNU Coding Standards)).

     En resumen, los paquetes que lo usan se configuran, construyen e instalan con la habitual secuencia de órdenes ./configure && make && make check && make install. En la práctica, algunos pasos adicionales son necesarios habitualmente. Todos estos pasos se dividen en fases separadas, notablemente (Rogamos que se inspeccionen los módulos (guix build gnu-build-system) para más detalles sobre las fases de construcción):

     unpack
          Extrae el archivador tar de la fuente, y cambia el directorio actual al directorio recién extraído. Si la fuente es realmente un directorio, lo copia al árbol de construcción y entra en ese directorio.

     patch-source-shebangs
          Sustituye secuencias ``#!'' encontradas al inicio de los ficheros de fuentes para que hagan referencia a los nombres correctos de ficheros del almacén. Por ejemplo, esto cambia #!/bin/sh por #!/gnu/store/...-bash-4.3/bin/sh.

     configure
          Ejecuta el guión configure con algunas opciones predeterminadas, como --prefix=/gnu/store/..., así como las opciones especificadas por el parámetro #:configure-flags.

     build
          Ejecuta make con la lista de opciones especificadas en #:make-flags. Si el parámetro #:parallel-build? es verdadero (por defecto), construye con make -j.

     check
          Ejecuta make check, u otro objetivo especificado con #:test-target, a menos que se pasase #:tests? #f. Si el parámetro #:parallel-tests? es verdadero (por defecto), ejecuta make check -j.

     install
          Ejecuta make install con las opciones enumeradas en #:make-flags.

     patch-shebangs
          Sustituye las secuencias ``#!'' en los ficheros ejecutables instalados.

     strip
          Extrae los símbolos de depuración de ficheros ELF (a menos que el valor de #:strip-binaries? sea falso), copiandolos a la salida debug cuando esté disponible (see Instalación de ficheros de depuración).

     El módulo del lado de construcción (guix build gnu-build-system) define %STANDARD-PHASES como la lista predeterminada de fases de construcción. %STANDARD-PHASES es una lista de pares símbolo/procedimiento, donde el procedimiento implementa la fase real.

     La lista de fases usadas para un paquete particular se puede cambiar con el parámetro #:phases. Por ejemplo, pasar:

          #:phases (modify-phases %standard-phases (delete 'configure))

     significa que todas las fases descritas anteriormente serán usadas, excepto la fase configure.

     Además, este sistema de construcción asegura que el entorno ``estándar'' para paquetes GNU está disponible. Esto incluye herramientas como GCC, libc, Coreutils, Bash, Make, Diffutils, grep y sed (vea el módulo (guix build system gnu) para una lista completa). A estas las llamamos las entradas implícitas de un paquete, porque las definiciones de paquete no las mencionan.

Se han definido otros objetos <build-system> para implementar otras convenciones y herramientas usadas por paquetes de software libre. Heredan la mayor parte de GNU-BUILD-SYSTEM, y se diferencian principalmente en el conjunto de entradas implícitamente añadidas al proceso de construcción, y en la lista de fases ejecutadas. Algunos de estos sistemas de construcción se enumeran a continuación.

 -- Variable Scheme: ant-build-system
     (guix build-system ant) exporta esta variable. Implementa el procedimiento de construcción de paquetes Java que pueden construirse con la herramienta de construcción Ant (http://ant.apache.org/).

     Añade tanto ant como el kit de desarrollo Java (JDK), que proporciona el paquete icedtea, al conjunto de entradas. Se pueden especificar paquetes diferentes con los parámetros #:ant y #:jdk, respectivamente.

     Cuando el paquete original no proporciona un fichero Ant apropiado, el parámetro #:jar-name puede usarse para generar un fichero de construcción Ant build.xml mínimo con tareas para construir el archivo jar especificado. En este caso, el parámetro #:source-dir se puede usar para especificar el subdirectorio de fuentes, con ``src'' como valor predeterminado.

     El parámetro #:main-class puede usarse con el fichero de construcción Ant mínimo para especificar la clase main del archivo jar producido. Esto permite ejecutar el archivo jar. El parámetro #:test-include puede usarse para especificar la lista de tests junit a ejecutar. El valor predeterminado es (list "**/*Test.java"). #:test-exclude puede usarse para desactivar algunas pruebas. Su valor predeterminado es (list "**/Abstract*.java") ya que las clases abstractas no se pueden ejecutar como pruebas.

     El parámetro #:build-target se puede usar para especificar la tarea Ant que debe ser ejecutada durante la fase build. Por defecto se ejecuta la tarea ``jar''.

 -- Variable Scheme: androd-ndk-build-system
     Esta variable es exportada por (guix build-system android-ndk). Implementa un procedimiento de construcción para paquetes Android NDK (kit de desarrollo nativo) usando un proceso de construcción específico de Guix.

     El sistema de construcción asume que los paquetes instalan sus ficheros de interfaz pública (cabeceras) en el subdirectorio "include" de la salida "out" y sus bibliotecas en el subdirectorio "lib" de la salida "out".

     También se asume que la unión de todas las dependencias de un paquete no tiene ficheros en conflicto.

     En este momento no funciona la compilación cruzada - por lo que las bibliotecas y los ficheros de cabecera se asumen que son locales.

 -- Variable Scheme: asdf-build-system/source
 -- Variable Scheme: asdf-build-system/sbcl
 -- Variable Scheme: asdf-build-system/ecl

     Estas variables, exportadas por (guix build-system asdf), implementan procedimientos de construcción para paquetes Common Lisp usando ``ASDF''' (https://common-lisp.net/project/asdf). ASDF es una utilidad de definición de sistema para programas y bibliotecas Common Lisp.

     El sistema asdf-build-system/source instala los paquetes en forma de fuentes, y puede ser cargado usando cualquier implementación common lisp, vía ASDF. Los otros, como asdf-build-system/sbcl, instalan sistemas binarios en el formato entendido por una implementación particular. Estos sistemas de construcción también pueden usarse para producir programas ejecutables, o imágenes lisp que contengan un conjunto precargado de paquetes.

     El sistema de construcción usa convenciones de nombres. Para paquetes binarios, el paquete debería estar prefijado con la implementación lisp, como sbcl- para asdf-build-system/sbcl.

     Adicionalmente, el paquete de fuentes correspondiente debe etiquetarse usando la misma convención que los paquetes python (vea Módulos Python), usando el prefijo cl-.

     Para paquetes binarios, cada sistema debe definirse como un paquete Guix. Si el campo origin de un paquete contiene varios sistemas, las variaciones del paquete pueden crearse para construir todos los sistemas. Los paquetes de fuentes, los cuales usan asdf-build-system/source, pueden contener varios sistemas.

     Para crear programa ejecutables e imágenes, se pueden usar los procedimientos del lado de construcción build-program y build-image. Deben llamarse en la fase de construcción después de la fase create-symlinks, de modo que el sistema recién construido pueda ser usado dentro de la imagen resultante. build-program necesita una lista de expresiones Common Lisp a través del parámetro #:entry-prgogram.

     Si el sistema no está definido en su propio fichero .asd del mismo nombre, entonces se debe usar el parámetro #:asd-file para especificar el fichero en el que se define el sistema. Más allá, si el paquete define un sistema para sus pruebas en su fichero separado, se cargará antes de la ejecución de las pruebas si se especifica el parámetro #:test-asd-file. Si no se especifica, se probarán si existen los ficheros <sistema>-tests.asd, <system>-test.asd, tests.asd y test.asd.

     Si por alguna razón el paquete debe ser nombrado de una forma diferente a la sugerida por las convenciones de nombres, el parámetro #:asd-system-name puede usarse para especificar el nombre del sistema.

 -- Variable Scheme: cargo-build-system
     Esta variable se exporta en (guix build-system cargo). Permite la construcción de paquetes usando Cargo, la herramienta de construcción del lenguaje de programación Rust (https://www.rust-lang.org).

     En su fase configure, este sistema de construcción substituye las dependencias especificadas en el fichero Cargo.toml con entradas a los paquetes Guix. La fase install instala los binarios, y también instala el código fuente y el fichero Cargo.toml.

 -- Variable Scheme: clojure-build-system
     Esta variable se exporta en (guix build-system clojure). Implementa un procedimiento de construcción simple para paquetes Clojure (https://clojure.org/) usando directamente compile en Clojure. La compilación cruzada no está disponible todavía.

     Añade clojure, icedtea y zip al conjunto de entradas. Se pueden especificar paquetes diferentes con los parámetros #:clojure, #:jdk y #:zip, respectivamente.

     Una lista de directorios de fuentes, directorios de pruebas y nombres de jar pueden especificarse con los parámetros #:source-dirs, #:test-dirs y #:jar-names, respectivamente. El directorio de compilación y la clase principal pueden especificarse con los parámetros #:compile-dir y #:main-class, respectivamente. Otros parámetros se documentan más adelante.

     Este sistema de construcción es una extensión de ANT-BUILD-SYSTEM, pero con las siguientes fases cambiadas:

     build
          Esta fase llama compile en Clojure para compilar los ficheros de fuentes y ejecuta jar para crear archivadores jar tanto de ficheros de fuentes y compilados de acuerdo con las listas de inclusión y exclusión especificadas en #:aot-include y #:aot-exclude, respectivamente. La lista de exclusión tiene prioridad sobre la de inclusión. Estas listas consisten en símbolos que representan bibliotecas Clojure o la palabra clave especial #:all que representa todas las bibliotecas encontradas en los directorios de fuentes. El parámetro #:omit-source? determina si las fuentes deben incluirse en los archivadores jar.

     check
          Esta fase ejecuta las pruebas de acuerdo a las listas de inclusión y exclusión especificadas en #:test-include y #:test-exclude, respectivamente. Sus significados son análogos a los de #:aot-include y #:aot-exclude, excepto que la palabra clave especial #:all designa ahora a todas las bibliotecas Clojure encontradas en los directorios de pruebas. El parámetro #:tests? determina si se deben ejecutar las pruebas.

     install
          Esta fase instala todos los archivadores jar construidos previamente.

     Además de las previas, este sistema de construcción contiene una fase adicional:

     install-doc
          Esta fase instala todos los ficheros de nivel superior con un nombre que corresponda con %DOC-REGEX. Una expresión regular diferente se puede especificar con el parámetro #:doc-regex. Todos los ficheros dentro (recursivamente) de los directorios de documentación especificados en #:doc-dirs se instalan también.

 -- Variable Scheme: cmake-build-system
     Esta variable se exporta en (guix build-system cmake). Implementa el procedimiento de construcción para paquetes que usen la herramienta de construcción CMake (http://www.cmake.org).

     Automáticamente añade el paquete cmake al conjunto de entradas. El paquete usado se puede especificar con el parámetro #:cmake.

     El parámetro #:configure-flags se toma como una lista de opciones a pasar a cmake. El parámetro #:build-type especifica en términos abstractos las opciones pasadas al compilador; su valor predeterminado es "RelWithDebInfo" (quiere decir ``modo de entrega con información de depuración''), lo que aproximadamente significa que el código se compila con -O2 -g, lo cual es el caso predeterminado en paquetes basados en Autoconf.

 -- Variable Scheme: dune-build-system
     This variable is exported by (guix build-system dune).  It supports builds of packages using Dune (https://dune.build/), a build tool for the OCaml programming language.  It is implemented as an extension of the ocaml-build-system which is described below.  As such, the #:ocaml and #:findlib parameters can be passed to this build system.

     Automáticamente añade el paquete dune al conjunto de entradas. El paquete usado se puede especificar con el parámetro #:dune.

     There is no configure phase because dune packages typically don't need to be configured.  The #:build-flags parameter is taken as a list of flags passed to the dune command during the build.

     The #:jbuild? parameter can be passed to use the jbuild command instead of the more recent dune command while building a package.  Its default value is #f.

     The #:package parameter can be passed to specify a package name, which is useful when a package contains multiple packages and you want to build only one of them.  This is equivalent to passing the -p argument to dune.

 -- Variable Scheme: go-build-system
     Esta variable se exporta en (guix build-system go). Implementa el procedimiento de construcción para paquetes Go usando los mecanismos de construcción de Go (https://golang.org/cmd/go/#hdr-Compile_packages_and_dependencies) estándares.

     Se espera que la usuaria proporcione un valor para el parámetro #:import-path y, en algunos caso, #:unpack-path. La ruta de importación (https://golang.org/doc/code.html#ImportPaths) corresponde a la ruta del sistema de ficheros esperada por los guiones de construcción del paquete y los paquetes referenciados, y proporciona una forma de referenciar un paquete Go unívocamente. Está basado típicamente en una combinación de la URI remota del paquete de ficheros de fuente y la estructura jerárquica del sistema de ficheros. En algunos casos, necesitará desempaquetar el código fuente del paquete en una estructura de directorios diferente a la indicada en la ruta de importación, y #:unpack-path debe usarse en dichos casos.

     Los paquetes que proporcionan bibliotecas Go deben instalar su código fuente en la salida de la construcción. El parámetro #:install-source?, cuyo valor por defecto es #t, controla si se instalará o no el código fuente. Puede proporcionarse #f en paquetes que proporcionan únicamente ficheros ejecutables.

 -- Variable Scheme: glib-or-gtk-build-system
     Esta variable se exporta en (guix build-system glib-or-gtk). Está pensada para usarse con paquetes que usan GLib o GTK+.

     Este sistema de construcción añade las siguientes dos fases a las definidas en GNU-BUILD-SYSTEM:

     glib-or-gtk-wrap
          La fase glib-or-gtk-wrap se asegura de que los programas en bin/ son capaces de encontrar los ``esquemas'' GLib y los módulos GTK+ (https://developer.gnome.org/gtk3/stable/gtk-running.html). Esto se consigue recubriendo los programas en guiones de lanzamiento que establecen apropiadamente las variables de entorno GTK_PATH.

          Es posible excluir salidas específicas del paquete del proceso de recubrimiento enumerando sus nombres en el parámetro #:glib-org-gtk-wrap-excluded-outputs. Esto es útil cuando se sabe que una salida no contiene binarios GLib o GTK+, y cuando empaquetar gratuitamente añadiría una dependencia de dicha salida en GLib y GTK+.

     glib-or-gtk-compile-schemas
          La fase glib-or-gtk-compile-schemas se asegura que todos los esquemas GSettings (https://developer.gnome.org/gio/stable/glib-compile-schemas.html) o GLib se compilan. La compilación la realiza el programa glib-compile-schemas. Lo proporciona el paquete glib:bin que se importa automáticamente por el sistema de construcción. El paquete glib que proporciona glib-compile-schemas puede especificarse con el parámetro #:glib.

     Ambas fases se ejecutan tras la fase install.

 -- Variable Scheme: guile-build-system
     Este sistema de construcción es para paquetes Guile que consisten exclusivamente en código Scheme y son tan simples que no tienen ni siquiera un fichero Makefile, menos un guión configure. Compila código Scheme usando guild compile (see Compilation (GNU Guile Reference Manual)) e instala los ficheros .scm y .go en el lugar correcto. También instala documentación.

     Este sistema de construcción permite la compilación cruzada usando la opción --target de guild compile.

     Los paquetes construidos con guile-build-system deben proporcionar un paquete Guile en su campo native-inputs.

 -- Variable Scheme: minify-build-system
     Esta variable se exporta en (guix build-system minify). Implementa un procedimiento de minificación para paquetes JavaScript simples.

     Añade uglify-js al conjunto de entradas y lo utiliza para comprimir todos los ficheros JavaScript en el directorio src. Un paquete de minificación diferente puede especificarse con el parámetro #:uglify-js, pero se espera que el paquete escriba el código minificado en la salida estándar.

     Cuando los ficheros JavaScript de entrada no se encuentran en el directorio src, el parámetro #:javascript-files puede usarse para especificar una lista de nombres de fichero que proporcionar al minificador.

 -- Variable Scheme: ocaml-build-system
     Esta variable se exporta en (guix build-system ocaml). Implementa un procedimiento de construcción para paquetes OCaml (https://ocaml.org), que consiste en seleccionar el conjunto correcto de órdenes a ejecutar para cada paquete. Los paquetes OCaml pueden esperar la ejecución de muchas ordenes diferentes. Este sistema de construcción probará algunas de ellas.

     Cuando el paquete tiene un fichero setup.ml presente en el nivel superior, se ejecuta ocaml setup.ml -configure, ocaml setup.ml -build y ocaml setup.ml -install. El sistema de construcción asumirá que este fichero se generó con http://oasis.forge.ocamlcore.org/ OASIS y se encargará de establecer el prefijo y la habilitación de las pruebas si no están deshabilitadas. Puede pasar opciones de configuración y construcción con #:configure-flags y #:build-flags, respectivamente. El parámetro #:test-flags puede usarse para cambiar el conjunto de opciones usadas para activar las pruebas. El parámetro #:use-make? puede usarse para ignorar este sistema en las fases de construcción e instalación.

     Cuando el paquete tiene un fichero configure, se asume que es un guión de configuración hecho a mano que necesita un formato de parámetros diferente a los del sistema gnu-build-system. Puede añadir más opciones con el parámetro #:configure-flags.

     Cuando el paquete tiene un fichero Makefile (o #:use-make? es #t), será usado y se pueden proporcionar más opciones para las fases de construcción y e instalación con el parámetro #:make-flags.

     Por último, algunos paquetes no tienen estos ficheros y usan unas localizaciones de algún modo estándares para su sistema de construcción. En este caso, el sistema de construcción ejecutará ocaml pkg/pkg.ml o ocaml pkg/build.ml y se hará cargo de proporcionar la ruta del módulo findlib necesario. Se pueden pasar opciones adicionales con el parámetro #:build-flags. De la instalación se hace cargo opam-installer. En este caso, el paquete opam debe añadirse al campo native-inputs de la definición del paquete.

     Fíjese que la mayoría de los paquetes OCaml asumen su instalación en el mismo directorio que OCaml, que no es el comportamiento deseado en guix. En particular, intentarán instalar ficheros .so en su directorio de módulos, normalmente lo adecuado puesto que es el directorio del compilador de OCaml. No obstante, en guix estas bibliotecas no se pueden encontrar allí y usamos CAML_LD_LIBRARY_PATH. Esta variable apunta a lib/ocaml/site-lib/stubslibs y allí es donde las bibliotecas .so deben instalarse.

 -- Variable Scheme: python-build-system
     Esta variable se exporta en (guix build-system python). Implementa el procedimiento más o menos estándar de construcción usado por paquetes Python, que consiste en la ejecución de python setup.py build y python setup.py install --prefix=/gnu/store/....

     Para que instalan programas independientes Python bajo bin/, se encarga de envolver dichos programas de modo que su variable de entorno PYTHONPATH apunte a las bibliotecas Python de las que dependen.

     Se puede especificar el paquete Python usado para llevar a cabo la construcción con el parámetro #:python. Esta es habitualmente una forma de forzar la construcción de un paquete para una versión específica del intérprete Python, lo que puede ser necesario si el paquete es compatible únicamente con una versión del intérprete.

     Por defecto guix llama a setup.py bajo el control de setuptools de manera similar a pip. Algunos paquetes no son compatibles con setuptools (y pip), por lo que puede deshabilitar esta configuración estableciendo el parámetro #:use-setuptools a #f.

 -- Variable Scheme: perl-build-system
     Esta variable se exporta en (guix build-system perl). Implementa el procedimiento de construcción estándar para paquetes Perl, lo que o bien consiste en la ejecución de perl Build.PL --prefix=/gnu/store/..., seguido de Build y Build install; o en la ejecución de perl Makefile.PL PREFIX=/gnu/store/..., seguida de make y make install, dependiendo de si Build.PL o Makefile.PL están presentes en la distribución del paquete. El primero tiene preferencia si existen tanto Build.PL como Makefile.PL en la distribución del paquete. Esta preferencia puede invertirse especificando #t en el parámetro #:make-maker?.

     La invocación inicial de perl Makefile.PL o perl Build.PL pasa a su vez las opciones especificadas por los parámetros #:make-maker-flags o #:module-build-flags, respectivamente.

     El paquete Perl usado puede especificarse con #:perl.

 -- Variable Scheme: r-build-system
     Esta variable se exporta en (guix build-system r). Implementa el procedimiento de construcción usados por paquetes R (http://r-project.org), lo que esencialmente es poco más que la ejecución de R CMD INSTALL --library=/gnu/store/... en un entorno donde R_LIBS_SITE contiene las rutas de todos los paquetes R de entrada. Las pruebas se ejecutan tras la instalación usando la función R tools::testInstalledPackage.

 -- Variable Scheme: rakudo-build-system
     This variable is exported by (guix build-system rakudo) It implements the build procedure used by Rakudo (https://rakudo.org/) for Perl6 (https://perl6.org/) packages. It installs the package to /gnu/store/.../NAME-VERSION/share/perl6 and installs the binaries, library files and the resources, as well as wrap the files under the bin/ directory.  Tests can be skipped by passing #f to the tests? parameter.

     Which rakudo package is used can be specified with rakudo.  Which perl6-tap-harness package used for the tests can be specified with #:prove6 or removed by passing #f to the with-prove6? parameter.  Which perl6-zef package used for tests and installing can be specified with #:zef or removed by passing #f to the with-zef? parameter.

 -- Variable Scheme: texlive-build-system
     Esta variable se exporta en (guix build-system texlive). Se usa para construir paquetes TeX en modo de procesamiento de lotes con el motor especificado. El sistema de construcción fija la variable TEXINPUTS para encontrar todos los ficheros de fuentes TeX en las entradas.

     Por defecto ejecuta luatex en todos los ficheros que terminan en ins. Un motor y formato diferente puede especificarse con el parámetro #:tex-format. Los diferentes objetivos de construcción pueden especificarse con el parámetro #:build-targets, que espera una lista de nombres de fichero. El sistema de construcción añade únicamente texlive-bin y texlive-latex-base (ambos desde (gnu packages tex) a las entradas. Ambos pueden forzarse con los parámetros #:texlive-bin y #:texlive-latex-base respectivamente.

     El parámetro #:tex-directory le dice al sistema de construcción dónde instalar los ficheros construidos bajo el árbol texmf.

 -- Variable Scheme: ruby-build-system
     Esta variable se exporta en (guix build-system ruby). Implementa el procedimiento de construcción de RubyGems usado por los paquetes Ruby, que implica la ejecución de gem build seguida de gem install.

     El campo source de un paquete que usa este sistema de construcción típicamente se refiere a un archivo gem, ya que este es el formato usado por las desarrolladoras Ruby cuando publican su software. El sistema de construcción desempaqueta el archivo gem, potencialmente parchea las fuentes, ejecuta la batería de pruebas, vuelve a empaquetar el archivo gem y lo instala. Adicionalmente, directorios y archivadores tar pueden referenciarse para permitir la construcción de archivos gem no publicados desde Git o un archivador tar de publicación de fuentes tradicional.

     Se puede especificar el paquete Ruby usado mediante el parámetro #:ruby. Una lista de opciones adicionales pueden pasarse a la orden gem en el parámetro #:gem-flags.

 -- Variable Scheme: waf-build-system
     Esta variable se exporta en (guix build-system waf). Implementa un procedimiento de construcción alrededor del guión waf. Las fases comunes---configure, build y install---se implementan pasando sus nombres como parámetros al guión waf.

     El guión waf es ejecutado por el intérprete Python. El paquete Python usado para la ejecución puede ser especificado con el parámetro #:python.

 -- Variable Scheme: scons-build-system
     Esta variable se exporta en (guix build-system scons). Implementa en procedimiento de construcción usado por la herramienta de construcción de software SCons. Este sistema de construcción ejecuta scons para construir el paquete, scons test para ejecutar las pruebas y después scons install para instalar el paquete.

     Las opciones adicionales a pasar a scons se pueden especificar con el parámetro #:scons-flags. La versión de Python usada para ejecutar SCons puede especificarse seleccionando el paquete SCons apropiado con el parámetro #:scons.

 -- Variable Scheme: haskell-build-system
     Esta variable se exporta en (guix build-system haskell). Implementa el procedimiento de construcción Cabal usado por paquetes Haskell, el cual implica la ejecución de runhaskell Setup.hs configure --prefix=/gnu/store/... y runhaskell Setup.hs build. En vez de instalar el paquete ejecutando runhaskell Setup.hs install, para evitar el intento de registro de bibliotecas en el directorio de solo-lectura del compilador en el almacén, el sistema de construcción usa runhaskell Setup.hs copy, seguido de runhaskell Setup.hs register. Además, el sistema de construcción genera la documentación del paquete ejecutando runhaskell Setup.hs haddock, a menos que se pasase #:haddock? #f. Parámetros opcionales de Haddock pueden proporcionarse con la ayuda del parámetro #:haddock-flags. Si el fichero Setup.hs no es encontrado, el sistema de construcción busca Setup.lhs a su vez.

     El compilador Haskell usado puede especificarse con el parámetro #:haskell cuyo valor predeterminado es ghc.

 -- Variable Scheme: dub-build-system
     Esta variable se exporta en (guix build-system dub). Implementa el procedimiento de construcción Dub usado por los paquetes D, que implica la ejecución de dub build y dub run. La instalación se lleva a cabo con la copia manual de los ficheros.

     El compilador D usado puede ser especificado con el parámetro #:ldc cuyo valor predeterminado es ldc.

 -- Variable Scheme: emacs-build-system
     Esta variable se exporta en (guix build-system emacs). Implementa un procedimiento de instalación similar al propio sistema de empaquetado de Emacs (see Packages (The GNU Emacs Manual)).

     Primero crea el fichero PAQUETE-autoloads.el, tras lo que compila todos los ficheros Emacs Lisp. De manera diferente al sistema de paquetes de Emacs, los ficheros de documentación Info se mueven al directorio estándar de documentación y se borra el fichero dir. Cada paquete se instala en su propio directorio bajo share/emacs/site-lisp/guix.d.

 -- Variable Scheme: font-build-system
     Esta variable se exporta en (guix build-system font). Implementa un procedimiento de instalación para paquetes de fuentes donde las proveedoras originales proporcionan ficheros de tipografía TrueType, OpenType, etc. precompilados que simplemente necesitan copiarse en su lugar. Copia los ficheros de tipografías a las localizaciones estándar en el directorio de salida.

 -- Variable Scheme: meson-build-system
     Esta variable se exporta en (guix build-system meson). Implementa el procedimiento de construcción para paquetes que usan Meson (http://mesonbuild.com) como su sistema de construcción.

     Añade Meson y Ninja (https://ninja-build.org/) al conjunto de entradas, y pueden cambiarse con los parámetros #:meson y #:ninja en caso necesario. La versión de Meson predeterminada es meson-for-build, la cual es especial puesto que no limpia el RUNPATH de los binarios y bibliotecas durante la instalación.

     Este sistema de construcción es una extensión de GNU-BUILD-SYSTEM, pero con las siguientes fases cambiadas por otras específicas para Meson.

     configure
          Esta fase ejecuta meson con las opciones especificadas en #:configure-flags. La opción --build-type siempre se fija a plain a menos que se especifique algo distinto en #:build-type.

     build
          Esta fase ejecuta ninja para construir el paquete en paralelo por defecto, pero esto puede cambiarse con #:parallel-build?.

     check
          Esta fase ejecuta ninja con el objetivo especificado en #:test-target, cuyo valor predeterminado es "test".

     install
          Esta fase ejecuta ninja install y no puede cambiarse.

     Aparte de estas, el sistema de ejecución también añade las siguientes fases:

     fix-runpath
          Esta fase se asegura de que todos los binarios pueden encontrar las bibliotecas que necesitan. Busca las bibliotecas necesarias en subdirectorios del paquete en construcción, y añade estas a RUNPATH en caso necesario. También elimina referencias a bibliotecas introducidas en la fase de construcción por meson-for-build, como las dependencias de las pruebas, que no se necesitan realmente para la ejecución del programa.

     glib-or-gtk-wrap
          Esta fase es la fase proporcionada por glib-or-gtk-build-system, y no está activa por defecto. Puede activarse con #:glib-or-gtk.

     glib-or-gtk-compile-schemas
          Esta fase es la fase proporcionada por glib-or-gtk-build-system, y no está activa por defecto. Puede activarse con #:glib-or-gtk.

 -- Scheme Variable: linux-module-build-system
     LINUX-MODULE-BUILD-SYSTEM allows building Linux kernel modules.

     This build system is an extension of GNU-BUILD-SYSTEM, but with the following phases changed:

     configure
          This phase configures the environment so that the Linux kernel's Makefile can be used to build the external kernel module.

     build
          This phase uses the Linux kernel's Makefile in order to build the external kernel module.

     install
          This phase uses the Linux kernel's Makefile in order to install the external kernel module.

     It is possible and useful to specify the Linux kernel to use for building the module (in the "arguments" form of a package using the linux-module-build-system, use the key #:linux to specify it).

Por último, para paquetes que no necesiten nada tan sofisticado se proporciona un sistema de construcción ``trivial''. Es trivial en el sentido de que no proporciona prácticamente funcionalidad: no incorpora entradas implícitas y no tiene una noción de fases de construcción.

 -- Variable Scheme: trivial-build-system
     Esta variable se exporta en (guix build-system trivial).

     Este sistema de construcción necesita un parámetro #:builder. Este parámetro debe ser una expresión Scheme que construya la(s) salida(s) del paquete---como en build-expression->derivation (see build-expression->derivation).

El almacén
==========

Conceptualmente, el almacén es el lugar donde se almacenan las derivaciones cuya construcción fue satisfactoria---por defecto, /gnu/store. Los subdirectorios en el almacén se denominan elementos del almacén o rutas del almacén en ocasiones. El almacén tiene una base de datos asociada que contiene información como las rutas del almacén a las que referencia cada ruta del almacén, y la lista de elementos válidos del almacén---los resultados de las construcciones satisfactorias. Esta base de datos reside en LOCALSTATEDIR/guix/db, donde LOCALSTATEDIR es el directorio de estado especificado vía --localstatedir en tiempo de configuración, normalmente /var.

El almacén siempre es accedido a través del daemon en delegación de sus clientes (see Invocación de guix-daemon). Para manipular el almacén, los clientes se conectan al daemon por un socket de dominio Unix, le envían peticiones y leen el resultado---esto son llamadas a procedimientos remotos, o RPC.

     Las usuarias nunca deben modificar ficheros directamente bajo el directorio /gnu/store. Esto llevaría a inconsistencias y rompería las premisas de inmutabilidad del modelo funcional de Guix (see Introducción).

     See guix gc --verify, para información sobre cómo comprobar la integridad del almacén e intentar recuperarse de modificaciones accidentales.

El módulo (guix store) proporciona procedimientos para conectarse al daemon y realizar RPCs. Estos se describen más adelante.  Por defecto, open-connection, y por tanto todas las órdenes guix, se conectan al daemon local o a la URI especificada en la variable de entorno GUIX_DAEMON_SOCKET.

 -- Variable de entorno: GUIX_DAEMON_SOCKET
     Cuando se ha definido, el valor de esta variable debe ser un nombre de fichero o una URI designando el punto de conexión del daemon. Cuando es un nombre de fichero, denota un socket de dominio Unix al que conectarse. Además de nombres de ficheros, los esquemas de URI aceptados son:

     file
     unix
          Estos son equivalentes a los sockets de dominio Unix. file:///var/guix/daemon-socket/socket es equivalente a /var/guix/daemon-socket/socket.

     guix
          Estas URI denotan conexiones sobre TCP/IP, sin cifrado ni verificación de la máquina remota. La URI debe especificar el nombre de máquina y opcionalmente un número de puerto (por defecto se usa el puerto 44146):

               guix://principal.guix.example.org:1234

          Esta configuración es apropiada para redes locales, como clusters, donde únicamente los nodos de confianza pueden conectarse al daemon de construcción en principal.guix.example.org.

          La opción --listen de guix-daemon puede usarse para indicarle que escuche conexiones TCP (see --listen).

     ssh
          Estas URI le permiten conectarse a un daemon remoto sobre SSH (Esta característica necesita Guile-SSH (see Requisitos).). Una URL típica debería ser algo así:

               ssh://carlos@guix.example.org:22

          Como con guix copy, se tienen en cuenta los ficheros habituales de configuración del cliente OpenSSH (see Invocación de guix copy).

     Esquemas URI adicionales pueden ser aceptados en el futuro.

          La conexión con daemon de construcción remotos se considera experimental en VERSION. Por favor, contacte con nosotras para compartir cualquier problema o sugerencias que pueda tener (see Contribuir).

 -- Procedimiento Scheme: open-connection [URI] [#:reserve-space? #t]
     Abre una conexión al daemon a través del socket de dominio Unix apuntado por URI (una cadena). Cuando RESERVE-SPACE? es verdadero, le indica que reserve un poco de espacio extra en el sistema de ficheros de modo que el recolector de basura pueda operar incluso cuando el disco se llene. Devuelve un objeto servidor.

     El valor por defecto de URI es %DEFAULT-SOCKET-PATH, que ese la ruta esperada según las opciones pasadas a configure.

 -- Procedimiento Scheme: close-connection SERVIDOR
     Cierra la conexión al SERVIDOR.

 -- Variable Scheme: current-build-output-port
     Esta variable está enlazada a un parámetro SRFI-39, que referencia al puerto donde los logs de construcción y error enviados por el daemon deben escribirse.

Los procedimientos que realizan RPCs toman todos como primer parámetro un objeto servidor.

 -- Procedimiento Scheme: valid-path? SERVIDOR RUTA
     Devuelve #t cuando RUTA designa un elemento válido del almacén y #f en otro caso (un elemento no-válido puede existir en el disco pero aun así no ser válido, por ejemlo debido a que es el resultado de una construcción interumpida o fallida).

     Una condición &store-protocol-error se eleva si RUTA no contiene como prefijo el directorio del almacén (/gnu/store).

 -- Procedimiento Scheme: add-text-to-store SERVIDOR NOMBRE TEXTO [REFERENCIAS]
     Añade TEXTO bajo el fichero NOMBRE en el almacén, y devuelve su ruta en el almacén. REFERENCIAS es la lista de rutas del almacén referenciadas por la ruta del almacén resultante.

 -- Procedimiento Scheme: build-derivations SERVIDOR DERIVACIONES
     Construye DERIVACIONES (una lista de objetos <derivation> o rutas de derivaciones) y devuelve el control cuando se termina de construirlas. Devuelve #t en caso de éxito.

Fijese que el módulo (guix monads) proporciona una mónada así como versiones monádicas de los procedimientos previos, con el objetivo de hacer más conveniente el trabajo con código que accede al almacén (see La mónada del almacén).

Esta sección actualmente está incompleta.

Derivaciones
============

Las acciones de construcción a bajo nivel y el entorno en el que se realizan se representan mediante derivaciones. Una derivación contiene las siguientes piezas de información:

  * Las salidas de la derivación---las derivaciones producen al menos un fichero o directorio en el almacén, pero pueden producir más.

  * Las entradas de las derivaciones---es decir, sus dependencias de tiempo de construcción---, que pueden ser otras derivaciones o simples ficheros en el almacén (parches, guiones de construcción, etc.).

  * El tipo de sistema objetivo de la derivación---por ejemplo, x86_64-linux.

  * El nombre de fichero del guión de construcción en el almacén, junto a los parámetros que se le deben pasar.

  * Una lista de variables de entorno a ser definidas.

Las derivaciones permiten a los clientes del daemon comunicar acciones de construcción al almacén. Existen en dos formas: como una representación en memoria, tanto en el lado del cliente como el del daemon, y como ficheros en el almacén cuyo nombre termina en .drv---estos ficheros se conocen como rutas de derivación. Las rutas de derivación pueden pasarse al procedimiento build-derivations para realizar las acciones de construcción que prescriben (see El almacén).

Operaciones como la descarga de ficheros y las instantáneas de un control de versiones para las cuales el hash del contenido esperado se conoce previamente se modelan como derivaciones de salida fija. Al contrario que las derivaciones normales, las salidas de una derivación de salida fija son independientes de sus entradas---por ejemplo, la descarga del código fuente produce el mismo resultado independientemente del método de descarga y las herramientas usadas.

The outputs of derivations---i.e., the build results---have a set of references, as reported by the references RPC or the guix gc --references command (see Invocación de guix gc). References are the set of run-time dependencies of the build results. References are a subset of the inputs of the derivation; this subset is automatically computed by the build daemon by scanning all the files in the outputs.

El módulo (guix derivations) proporciona una representación de derivaciones como objetos Scheme, junto a procedimientos para crear y manipular de otras formas derivaciones. La primitiva de más bajo nivel para crear una derivación es el procedimiento derivation:

 -- Procedimiento Scheme: derivation ALMACÉN NOMBRE CONSTRUCTOR
     ARGS [#:outputs '("out")] [#:hash #f] [#:hash-algo #f]
     [#:recursive? #f] [#:inputs '()] [#:env-vars '()]
     [#:system (%current-system)] [#:references-graphs #f]
     [#:allowed-references #f] [#:disallowed-references #f]
     [#:leaked-env-vars #f] [#:local-build? #f]
     [#:substitutable? #t] [#:properties '()]
     Construye una derivación con los parámetros proporcionados, y devuelve el objeto <derivation> resultante.

     Cuando se proporcionan HASH y HASH-ALGO, una derivación de salida fija se crea---es decir, una cuyo resultado se conoce de antemano, como la descarga de un fichero. Si, además, RECURSIVE? es verdadero, entonces la salida fijada puede ser un fichero ejecutable o un directorio y HASH debe ser el hash de un archivador que contenga esta salida.

     Cuando REFERENCES-GRAPHS es verdadero, debe ser una lista de pares de nombre de fichero/ruta del almacén. En ese caso, el grafo de referencias de cada ruta del almacén se exporta en el entorno de construcción del fichero correspondiente, en un formato de texto simple.

     Cuando ALLOWED-REFERENCES es verdadero, debe ser una lista de elementos del almacén o salidas a las que puede hacer referencia la salida de la derivación. Del mismo modo, DISALLOWED-REFERENCES, en caso de ser verdadero, debe ser una lista de cosas a las que las salidas no pueden hacer referencia.

     Cuando LEAKED-ENV-VARS es verdadero, debe ser una lista de cadenas que denoten variables de entorno que se permite ``escapar'' del entorno del daemon al entorno de construcción. Esto es únicamente aplicable a derivaciones de salida fija---es decir, cuando HASH es verdadero. El uso principal es permitir que variables como http_proxy sean pasadas a las derivaciones que descargan ficheros.

     Cuando LOCAL-BUILD? es verdadero, declara que la derivación no es una buena candidata para delegación y debe ser construida localmente (see Configuración de delegación del daemon). Este es el caso para pequeñas derivaciones donde los costes de transferencia de datos sobrepasarían los beneficios.

     Cuando SUBSTITUTABLE? es falso, declara que las sustituciones de la salida de la derivación no deben usarse (see Sustituciones). Esto es útil, por ejemplo, cuando se construyen paquetes que capturan detalles sobre el conjunto de instrucciones de la CPU anfitriona.

     PROPERTIES debe ser una lista asociada que describe ``propiedades'' de la derivación. Debe mantenerse tal cual, sin interpretar, en la derivación.

Esto es un ejemplo con un guión de shell como constructor, asumiendo que ALMACÉN es una conexión abierta al daemon, BASH apunta al ejecutable Bash en el almacén:

     (use-modules (guix utils)
                  (guix store)
                  (guix derivations))

     (let ((constructor   ; añade el guión de Bash al almacén
             (add-text-to-store store "mi-constructor.sh"
                                "echo hola mundo > $out\n" '())))
       (derivation almacen "foo"
                   bash `("-e" ,builder)
                   #:inputs `((,bash) (,constructor))
                   #:env-vars '(("HOME" . "/sindirectorio"))))
     => #<derivation /gnu/store/...-foo.drv => /gnu/store/...-foo>

Como puede suponerse, el uso directo de esta primitiva es algo enrevesado. Una mejor aproximación es escribir guiones de construcción en Scheme, ¡por supuesto! La mejor forma de hacerlo es escribir el código de construcción como una ``expresión-G'', y pasarla a gexp->derivation. Para más información, see Expresiones-G.

En otros tiempos, gexp->derivation no existía y la creación de derivaciones con código de construcción escrito en Scheme se conseguía con build-expression->derivation, documentada más adelante. Este procedimiento está ahora obsoleto en favor del procedimiento gexp->derivation mucho más conveniente.

 -- Procedimiento Scheme: build-expression->derivation ALMACÉN
     NOMBRE EXP
     [#:system (%current-system)] [#:inputs '()]
     [#:outputs '("out")] [#:hash #f] [#:hash-algo #f]
     [#:recursive? #f] [#:env-vars '()] [#:modules '()]
     [#:references-graphs #f] [#:allowed-references #f]
     [#:disallowed-references #f]
     [#:local-build? #f] [#:substitutable? #t] [#:guile-for-build #f]
     Devuelve una derivación que ejecuta la expresión Scheme EXP como un constructor para la derivación NOMBRE. INPUTS debe ser una lista de tupletas (nombre ruta-drv sub-drv); cuando SUB-DRV se omite, se asume "out". MODULES es una lista de nombres de módulos Guile de la ruta actual de búsqueda a copiar en el almacén, compilados, y poner a disposición en la ruta de carga durante la ejecución de EXP---por ejemplo, ((guix build utils) (guix build gnu-build-system)).

     EXP se evalúa en un entorno donde %outputs está asociada a una lista de pares salida/ruta, y donde %build-inputs está asociada a una lista de pares cadena/ruta-de-salida que provienen de INPUTS. De manera opcional, ENV-VARS es una lista de pares de cadenas que especifican el nombre y el valor de las variables de entorno visibles al constructor. El constructor termina pasando el resultado de EXP a exit; por tanto, cuando EXP devuelve #f, la construcción se considera fallida.

     EXP se construye usando GUILE-FOR-BUILD (una derivación). Cuando GUILE-FOR-BUILD se omite o es #f, el valor del fluido %guile-for-build se usa en su lugar.

     Véase el procedimiento derivation para el significado de REFERENCES-GRAPHS, ALLOWED-REFERENCES, DISALLOWED-REFERENCES, LOCAL-BUILD? y SUBSTITUTABLE?.

Aquí está un ejemplo de derivación de salida única que crea un directorio que contiene un fichero:

     (let ((constructor '(let ((salida (assoc-ref %outputs "out")))
                           (mkdir salida)    ; crea /gnu/store/...-goo
                           (call-with-output-file (string-append salida "/prueba")
                             (lambda (p)
                               (display '(hola guix) p))))))
       (build-expression->derivation almacen "goo" constructor))

     => #<derivation /gnu/store/...-goo.drv => ...>

La mónada del almacén
=====================

Los procedimientos que operan en el almacén descritos en la sección previa toman todos una conexión abierta al daemon de construcción en su primer parámetro. Aunque el modelo subyacente es funcional, tienen o bien efectos secundarios o dependen del estado actual del almacén.

Lo anterior es inconveniente: la conexión al daemon de construcción tiene que proporcionarse en todas estas funciones, haciendo imposible la composición de funciones que no toman ese parámetro con funciones que sí lo hacen. Lo último puede ser problemático: ya que las operaciones del almacén tienen efectos secundarios y/o dependen del estado externo, deben ser secuenciadas de manera adecuada.

Aquí es donde entra en juego el módulo (guix monads). Este módulo proporciona un entorno para trabajar con mónadas, y una mónada particularmente útil para nuestros usos, la mónada del almacén. Las mónadas son una construcción que permite dos cosas: asociar ``contexto'' con valores (en nuestro caso, el contexto es el almacén), y la construcción de secuencias de computaciones (aquí computaciones incluye accesos al almacén). Los valores en una mónada---valores que transportan este contexto adicional---se llaman valores monádicos; los procedimientos que devuelven dichos valores se llaman procedimientos monádicos.

Considere este procedimiento ``normal'':

     (define (enlace-sh almacen)
       ;; Devuelve una derivación que enlaza el ejecutable 'bash'.
       (let* ((drv (package-derivation store bash))
              (out (derivation->output-path drv))
              (sh  (string-append out "/bin/bash")))
         (build-expression->derivation store "sh"
                                       `(symlink ,sh %output))))

Mediante el uso de (guix monads) y (guix gexp), puede reescribirse como una función monádica:

     (define (enlace-sh)
       ;; Lo mismo, pero devuelve un valor monádico.
       (mlet %store-monad ((drv (package->derivation bash)))
         (gexp->derivation "sh"
                           #~(symlink (string-append #$drv "/bin/bash")
                                      #$output))))

Hay varias cosas a tener en cuenta en la segunda versión: el parámetro store ahora es implícito y es ``hilado en las llamadas a los procedimientos monádicos package->derivation y gexp->derivation, y el valor monádico devuelto por package->derivation es asociado mediante el uso de mlet en vez de un simple let.

Al final, la llamada a package->derivation puede omitirse ya que tendrá lugar implícitamente, como veremos más adelante (see Expresiones-G):

     (define (enlace-sh)
       (gexp->derivation "sh"
                         #~(symlink (string-append #$bash "/bin/bash")
                                    #$output)))

La ejecución del procedimiento monádico enlace-para-sh no tiene ningún efecto. Como alguien dijo una vez, ``sales de una mónada como sales de un edificio en llamas: corriendo'' (run en inglés). Por tanto, para salir de la mónada y obtener el efecto deseado se debe usar run-with-store:

     (run-with-store (open-connection) (enlace-sh))
     => /gnu/store/...-enlace-para-sh

Fíjese que el módulo (guix monad-repl) extiende la sesión interactiva de Guile con nuevos ``meta-comandos'' para facilitar el trabajo con procedimientos monádicos: run-in-store y enter-store-monad. El primero se usa para ``ejecutar'' un valor monádico único a través del almacén:

     scheme@(guile-user)> ,run-in-store (package->derivation hello)
     $1 = #<derivation /gnu/store/...-hello-2.9.drv => ...>

El último entra en un entorno interactivo recursivo, donde todos los valores devueltos se ejecutan automáticamente a través del almacén:

     scheme@(guile-user)> ,enter-store-monad
     store-monad@(guile-user) [1]> (package->derivation hello)
     $2 = #<derivation /gnu/store/...-hello-2.9.drv => ...>
     store-monad@(guile-user) [1]> (text-file "foo" "Hello!")
     $3 = "/gnu/store/...-foo"
     store-monad@(guile-user) [1]> ,q
     scheme@(guile-user)>

Fijese que los valores no-monádicos no pueden devolverse en el entorno interactivo store-monad.

Las formas sintácticas principales para tratar con mónadas en general se proporcionan por el módulo (guix monads) y se describen a continuación.

 -- Sintaxis Scheme: with-monad MÓNADA CUERPO ...
     Evalua cualquier forma >>= o return en CUERPO como estando en MÓNADA.

 -- Sintaxis Scheme: return VAL
     Devuelve el valor monádico que encapsula VAL.

 -- Sintaxis Scheme: >>= MVAL MPROC ...
     Asocia el valor monádico MVAL, pasando su ``contenido'' a los procedimientos monádicos MPROC... (Esta operación es habitualmente conocida como ``bind'' (asociación), pero ese nombre denota un procedimiento no relacionado en Guile. Por tanto usamos este símbolo en cierto modo críptico heredado del lenguaje Haskell.). Puede haber un MPROC o varios, como en este ejemplo:

          (run-with-state
              (with-monad %state-monad
                (>>= (return 1)
                     (lambda (x) (return (+ 1 x)))
                     (lambda (x) (return (* 2 x)))))
            'un-estado)

          => 4
          => un-estado

 -- Sintaxis Scheme: mlet MÓNADA ((VAR MVAL) ...)
     CUERPO ...
 -- Sintaxis Scheme: mlet* MÓNADA ((VAR MVAL) ...)
     CUERPO ... Asocia las variables VAR a los valores monádicos
     MVAL en CUERPO, el cual es una secuencia de expresiones. Como con el operador bind, esto puede pensarse como el ``desempaquetado'' del valor crudo no-monádico dentro del ámbito del CUERPO. La forma (VAR -> VAL) asocia VAR al valor ``normal'' VAL, como en let. Las operaciones de asociación ocurren en secuencia de izquierda a derecha. La última expresión de CUERPO debe ser una expresión monádica, y su resultado se convertirá en el resultado de mlet o mlet* cuando se ejecute en la MÓNADA.

     mlet* es a mlet lo que let* es a let (see Local Bindings (GNU Guile Reference Manual)).

 -- Sistema Scheme: mbegin MÓNADA MEXP ...
     Asocia MEXP y las siguientes expresiones monádicas en secuencia, devolviendo el resultado de la última expresión. Cada expresión en la secuencia debe ser una expresión monádica.

     Esto es similar a mlet, excepto que los valores devueltos por las expresiones monádicas se ignoran. En ese sentido el funcionamiento es análogo a begin pero aplicado a expresiones monádicas.

 -- Sistema Scheme: mwhen CONDICIÓN MEXP0 MEXP* ...
     Cuando CONDICIÓN es verdadero, evalúa la secuencia de expresiones monádicas MEXP0..MEXP* como dentro de mbegin. Cuando CONDICIÓN es falso, devuelve *unespecified* en la mónada actual. Todas las expresiones en la secuencia deben ser expresiones monádicas.

 -- Sistema Scheme: munless CONDICIÓN MEXP0 MEXP* ...
     Cuando CONDICIÓN es falso, evalúa la secuencia de expresiones monádicas MEXP0..MEXP* como dentro de mbegin. Cuando CONDICIÓN es verdadero, devuelve *unespecified* en la mónada actual. Todas las expresiones en la secuencia deben ser expresiones monádicas.

El módulo (guix monads) proporciona la mónada de estado, que permite que un valor adicional---el estado---sea hilado a través de las llamadas a procedimientos monádicos.

 -- Variable Scheme: %state-monad
     La mónada de estado. Procedimientos en la mónada de estado pueden acceder y cambiar el estado hilado.

     Considere el siguiente ejemplo. El procedimiento cuadrado devuelve un valor en la mónada de estado.

          (define (cuadrado x)
            (mlet %state-monad ((count (current-state)))
              (mbegin %state-monad
                (set-current-state (+ 1 count))
                (return (* x x)))))

          (run-with-state (sequence %state-monad (map cuadrado (iota 3))) 0)
          => (0 1 4)
          => 3

     Cuando se ``ejecuta'' a través de %STATE-MONAD, obtenemos un valor adicional de estado, que ese el número de llamadas a cuadrado.

 -- Procedimiento monádico: current-state
     Devuelve el estado actual como un valor monádico.

 -- Procedimiento monádico: set-current-state VALOR
     Establece el estado actual a VALOR y devuelve el estado previo como un valor monádico.

 -- Procedimiento monádico: state-push VALOR
     Apila VALOR al estado actual, que se asume que es una lista, y devuelve el estado previo como un valor monádico.

 -- Procedimiento monádico: state-pop
     Desapila un valor del estado actual y lo devuelve como un valor monádico. El estado se asume que es una lista.

 -- Procedimiento Scheme: run-with-state MVAL [ESTADO]
     Ejecuta un valor monádico MVAL comenzando con ESTADO como el estado inicial. Devuelve dos valores: el valor resultante y el estado resultante.

La interfaz principal a la mónada del almacén, proporcionada por el módulo (guix store), es como sigue.

 -- Variable Scheme: %store-monad
     La mónada del almacén---un alias para %STATE-MONAD.

     Los valores en la mónada del almacén encapsulan los accesos al almacén. Cuando su efecto es necesario, un valor de la mónada del almacén será ``evaluado'' pasandolo al procedimiento run-with-store (vea más adelante).

 -- Procedimiento Scheme: run-with-store ALMACÉN MVAL [#:guile-for-build] [#:system (%current-system)]
     Ejecuta MVAL, un valor monádico en la mónada del almacén, en ALMACÉN, una conexión abierta al almacén.

 -- Procedimiento monádico: text-file NOMBRE TEXTO [REFERENCIAS]
     Devuelve como un valor monádico el nombre absoluto del fichero en el almacén del fichero que contiene ŦEXTO, una cadena. REFERENCIAS es una lista de elementos del almacén a los que el fichero de texto referencia; su valor predeterminado es la lista vacía.

 -- Procedimiento monádico: binary-file NOMBRE DATOS [REFERENCIAS]
     Devuelve como un valor monádico el nombre absoluto del fichero en el almacén del fichero que contiene DATOS, un vector de bytes. REFERENCIAS es una lista de elementos del almacén a los que el fichero binario referencia; su valor predeterminado es la lista vacía.

 -- Procedimiento monádico: interned-file FICHERO [NOMBRE]
     [#:recursive? #t] [#:select? (const #t)]
     Devuelve el nombre del FICHERO una vez internado en el almacén. Usa NOMBRE como su nombre del almacén, o el nombre base de FICHERO si NOMBRE se omite.

     Cuando RECURSIVE? es verdadero, los contenidos del FICHERO se añaden recursivamente; si FICHERO designa un fichero plano y RECURSIVE? es verdadero, sus contenidos se añaden, y sus bits de permisos se mantienen.

     Cuando RECURSIVE? es verdadero, llama a (SELECT? FICHERO STAT) por cada entrada del directorio, donde FICHERO es el nombre absoluto de fichero de la entrada y STAT es el resultado de lstat; excluyendo las entradas para las cuales SELECT? no devuelve verdadero.

     El ejemplo siguiente añade un fichero al almacén, bajo dos nombres diferentes:

          (run-with-store (open-connection)
            (mlet %store-monad ((a (interned-file "README"))
                                (b (interned-file "README" "LEGU-MIN")))
              (return (list a b))))

          => ("/gnu/store/rwm...-README" "/gnu/store/44i...-LEGU-MIN")

El módulo (guix packages) exporta los siguientes procedimientos monádicos relacionados con paquetes:

 -- Procedimiento monádico: package-file PAQUETE [FICHERO]
     [#:system (%current-system)] [#:target #f]
     [#:output "out"]
     Devuelve como un valor monádico el nombre absoluto de fichero de FICHERO dentro del directorio de salida OUTPUT del PAQUETE. Cuando se omite FICHERO, devuelve el nombre del directorio de salida OUTPUT del PAQUETE. Cuando TARGET es verdadero, se usa como una tripleta de compilación cruzada.

 -- Procedimiento monádico: package->derivation PAQUETE [SISTEMA]
 -- Procedimiento monádico: package->cross-derivation PAQUETE
     OBJETIVO [SISTEMA]
     Versión monádica de package-derivation y package-cross-derivation (see Definición de paquetes).

Expresiones-G
=============

Por tanto tenemos ``derivaciones'', que representan una secuencia de acciones de construcción a realizar para producir un elemento en el almacén (see Derivaciones). Estas acciones de construcción se llevan a cabo cuando se solicita al daemon construir realmente la derivación; se ejecutan por el daemon en un contenedor (see Invocación de guix-daemon).

No debería ser ninguna sorpresa que nos guste escribir estas acciones de construcción en Scheme. Cuando lo hacemos, terminamos con dos estratos de código Scheme (El término estrato en este contexto se debe a Manuel Serrano et al. en el contexto de su trabajo en Hop. Oleg Kiselyov, quien ha escrito profundos ensayos sobre el tema (http://okmij.org/ftp/meta-programming/#meta-scheme), se refiere a este tipo de generación de código como separación en etapas o staging.): el ``código anfitrión''---código que define paquetes, habla al daemon, etc.---y el ``código de construcción''---código que realmente realiza las acciones de construcción, como la creación de directorios, la invocación de make, etc.

Para describir una derivación y sus acciones de construcción, típicamente se necesita embeber código de construcción dentro del código anfitrión. Se resume en la manipulación de código de construcción como datos, y la homoiconicidad de Scheme---el código tiene representación directa como datos---es útil para ello. Pero necesitamos más que el mecanismo normal de quasiquote en Scheme para construir expresiones de construcción.

El módulo (guix gexp) implementa las expresiones-G, una forma de expresiones-S adaptada para expresiones de construcción. Las expresiones-G, o gexps, consiste esencialmente en tres formas sintácticas: gexp, ungexp y ungexp-splicing (o simplemente: #~, #$ y #$@), que son comparables a quasiquote, unquote y unquote-splicing, respectivamente (see quasiquote (GNU Guile Reference Manual)). No obstante, hay importantes diferencias:

  * Las expresiones-G están destinadas a escribirse en un fichero y ser ejecutadas o manipuladas por otros procesos.

  * Cuando un objeto de alto nivel como un paquete o una derivación se expande dentro de una expresión-G, el resultado es el mismo que la introducción de su nombre de fichero de salida.

  * Las expresiones-G transportan información acerca de los paquetes o derivaciones que referencian, y estas referencias se añaden automáticamente como entradas al proceso de construcción que las usa.

Este mecanismo no se limita a objetos de paquete ni derivación: pueden definirse compiladores capaces de ``bajar el nivel'' de otros objetos de alto nivel a derivaciones o ficheros en el almacén, de modo que esos objetos puedan introducirse también en expresiones-G. Por ejemplo, un tipo útil de objetos de alto nivel que pueden insertarse en una expresión-G son los ``objetos tipo-fichero'', los cuales facilitan la adición de ficheros al almacén y su referencia en derivaciones y demás (vea local-file y plain-file más adelante).

Para ilustrar la idea, aquí está un ejemplo de expresión-G:

     (define exp-construccion
       #~(begin
           (mkdir #$output)
           (chdir #$output)
           (symlink (string-append #$coreutils "/bin/ls")
                    "enumera-ficheros")))

Esta expresión-G puede pasarse a gexp->derivation; obtenemos una derivación que construye un directorio que contiene exactamente un enlace simbólico a /gnu/store/...-coreutils-8.22/bin/ls:

     (gexp->derivation "la-cosa" exp-construccion)

Como se puede esperar, la cadena "/gnu/store/...-coreutils-8.22" se sustituye por la referencia al paquete COREUTILS en el código de construcción real, y COREUTILS se marca automáticamente como una entrada a la derivación. Del mismo modo, #$output (equivalente a (ungexp output)) se reemplaza por una cadena que contiene el nombre del directorio de la salida de la derivación.

En un contexto de compilación cruzada, es útil distinguir entre referencias a construcciones nativas del paquete---que pueden ejecutarse en el sistema anfitrión---de referencias de compilaciones cruzadas de un paquete. Para dicho fin, #+ tiene el mismo papel que #$, pero es una referencia a una construcción nativa del paquete:

     (gexp->derivation "vi"
        #~(begin
            (mkdir #$output)
            (system* (string-append #+coreutils "/bin/ln")
                     "-s"
                     (string-append #$emacs "/bin/emacs")
                     (string-append #$output "/bin/vi")))
        #:target "mips64el-linux-gnu")

En el ejemplo previo, se usa la construcción nativa de COREUTILS, de modo que ln pueda realmente ejecutarse en el anfitrión; pero se hace referencia a la construcción de compilación cruzada de EMACS.

Otra característica de las expresiones-G son los módulos importados: a veces deseará ser capaz de usar determinados módulos Guile del ``entorno anfitrión'' en la expresión-G, de modo que esos módulos deban ser importados en el ``entorno de construcción''. La forma with-imported-modules le permite expresarlo:

     (let ((build (with-imported-modules '((guix build utils))
                    #~(begin
                        (use-modules (guix build utils))
                        (mkdir-p (string-append #$output "/bin"))))))
       (gexp->derivation "directorio-vacio"
                         #~(begin
                             #$build
                             (display "éxito!\n")
                             #t)))

En este ejemplo, el módulo (guix build utils) se incorpora automáticamente dentro del entorno de construcción aislado de nuestra expresión-G, de modo que (use-modules (guix build utils)) funciona como se espera.

De manera habitual deseará que la clausura del módulo se importe---es decir, el módulo en sí y todos los módulos de los que depende---en vez del módulo únicamente; si no se hace, cualquier intento de uso del módulo fallará porque faltan módulos dependientes. El procedimiento source-module-closure computa la clausura de un módulo mirando en las cabeceras de sus ficheros de fuentes, lo que es útil en este caso:

     (use-modules (guix modules))   ;para 'source-module-closure'

     (with-imported-modules (source-module-closure
                              '((guix build utils)
                                (gnu build vm)))
       (gexp->derivation "algo-con-maq-virtuales"
                         #~(begin
                             (use-modules (guix build utils)
                                          (gnu build vm))
                             ...)))

De la misma manera, a veces deseará importar no únicamente módulos puros de Scheme, pero también ``extensiones'' como enlaces Guile a bibliotecas C u otros paquetes ``completos''. Si, digamos, necesitase el paquete guile-json disponible en el lado de construcción, esta sería la forma de hacerlo:

     (use-modules (gnu packages guile))  ;para 'guile-json'

     (with-extensions (list guile-json)
       (gexp->derivation "algo-con-json"
                         #~(begin
                             (use-modules (json))
                             ...)))

La forma sintáctica para construir expresiones-G se resume a continuación.

 -- Sintaxis Scheme: #~EXP
 -- Sintaxis Scheme: (gexp EXP)
     Devuelve una expresión-G que contiene EXP. EXP puede contener una o más de las siguientes formas:

     #$OBJ
     (ungexp OBJ)
          Introduce una referencia a OBJ. OBJ puede tener uno de los tipos permitidos, por ejemplo un paquete o derivación, en cuyo caso la forma ungexp se substituye por el nombre de fichero de su salida---por ejemplo, "/gnu/store/...-coreutils-8.22.

          Si OBJ es una lista, se recorre y las referencias a objetos permitidos se substituyen de manera similar.

          Si OBJ es otra expresión-G, su contenido se inserta y sus dependencias se añaden a aquellas de la expresión-G que la contiene.

          Si OBJ es otro tipo de objeto, se inserta tal cual es.

     #$OBJ:SALIDA
     (ungexp OBJ SALIDA)
          Como la forma previa, pero referenciando explícitamente la SALIDA de OBJ---esto es útil cuando OBJ produce múltiples salidas (see Paquetes con múltiples salidas).

     #+OBJ
     #+OBJ:salida
     (ungexp-native OBJ)
     (ungexp-native OBJ SALIDA)
          Lo mismo que ungexp, pero produce una referencia a la construcción nativa de OBJ cuando se usa en un contexto de compilación cruzada.

     #$output[:SALIDA]
     (ungexp output [SALIDA])
          Inserta una referencia a la salida de la derivación SALIDA, o a la salida principal cuando SALIDA se omite.

          Esto únicamente tiene sentido para expresiones-G pasadas a gexp->derivation.

     #$@LST
     (ungexp-splicing LST)
          Lo mismo que la forma previa, pero expande el contenido de la lista LST como parte de la lista que la contiene.

     #+@LST
     (ungexp-native-splicing LST)
          Lo mismo que la forma previa, pero hace referencia a las construcciones nativas de los objetos listados en LST.

     Las expresiones-G creadas por gexp o #~ son objetos del tipo gexp? en tiempo de ejecución (vea más adelante).

 -- Sintaxis Scheme: with-imported-modules MÓDULOS CUERPO...
     Marca las expresiones-G definidas en el CUERPO... como si requiriesen MÓDULOS en su entorno de ejecución.

     Cada elemento en MÓDULOS puede ser el nombre de un módulo, como (guix build utils), o puede ser el nombre de un módulo, seguido de una flecha, seguido de un objeto tipo-fichero:

          `((guix build utils)
            (guix gcrypt)
            ((guix config) => ,(scheme-file "config.scm"
                                            #~(define-module ...))))

     En el ejemplo previo, los dos primeros módulos se toman de la ruta de búsqueda, y el último se crea desde el objeto tipo-fichero proporcionado.

     Esta forma tiene ámbito léxico: tiene efecto en las expresiones-G definidas en CUERPO..., pero no en aquellas definidas, digamos, en procedimientos llamados por CUERPO....

 -- Sintaxis Scheme: with-extensions EXTENSIONES CUERPO...
     Marca que las expresiones definidas en CUERPO... requieren EXTENSIONES en su entorno de construcción y ejecución. EXTENSIONES es típicamente una lista de objetos de paquetes como los que se definen en el módulo (gnu packages guile).

     De manera concreta, los paquetes listados en EXTENSIONES se añaden a la ruta de carga mientras se compilan los módulos importados en CUERPO...; también se añaden a la ruta de carga en la expresión-G devuelta por CUERPO....

 -- Procedimiento Scheme: gexp? OBJ
     Devuelve #t si OBJ es una expresión-G.

Las expresiones-G están destinadas a escribirse en disco, tanto en código que construye alguna derivación, como en ficheros planos en el almacén. Los procedimientos monádicos siguientes le permiten hacerlo (see La mónada del almacén, para más información sobre mónadas).

 -- Procedimiento monádico: gexp->derivation NOMBRE EXP
     [#:system (%current-system)] [#:target #f] [#:graft? #t]
     [#:hash #f] [#:hash-algo #f]
     [#:recursive? #f] [#:env-vars '()] [#:modules '()]
     [#:module-path %LOAD-PATH]
     [#:effective-version "2.2"]
     [#:references-graphs #f] [#:allowed-references #f]
     [#:disallowed-references #f]
     [#:leaked-env-vars #f]
     [#:script-name (string-append NAME "-builder")]
     [#:deprecation-warnings #f]
     [#:local-build? #f] [#:substitutable? #t]
     [#:properties '()] [#:guile-for-build #f]
     Devuelve una derivación NOMBRE que ejecuta EXP (una expresión-G) con GUILE-FOR-BUILD (una derivación) en el sistema SYSTEM; EXP se almacena en un fichero llamado SCRIPT-NAME. Cuando TARGET es verdadero, se usa como la tripleta de compilación cruzada para paquetes a los que haga referencia EXP.

     MODULES está obsoleto en favor de with-imported-modules. Su significado es hacer que los módulos MODULES estén disponibles en el contexto de evaluación de EXP; MODULES es una lista de nombres de módulos Guile buscados en MODULE-PATH para ser copiados al almacén, compilados y disponibles en la ruta de carga durante la ejecución de EXP---por ejemplo, ((guix build utils) (gui build gnu-build-system)).

     EFFECTIVE-VERSION determina la cadena a usar cuando se añaden las extensiones de EXP (vea with-extensions) a la ruta de búsqueda---por ejemplo, "2.2".

     GRAFT? determina si los paquetes a los que EXP hace referencia deben ser injertados cuando sea posible.

     Cuando REFERENCES-GRAPHS es verdadero, debe ser una lista de tuplas de una de las formas siguientes:

          (NOMBRE-FICHERO PAQUETE)
          (NOMBRE-FICHERO PAQUETE SALIDA)
          (NOMBRE-FICHERO DERIVACIÓN)
          (NOMBRE-FICHERO DERIVACIÓN SALIDA)
          (NOMBRE-FICHERO ELEMENTO-ALMACÉN)

     El lado derecho de cada elemento de REFERENCES-GRAPHS se convierte automáticamente en una entrada del proceso de construcción de EXP. En el entorno de construcción, cada NOMBRE-FICHERO contiene el grafo de referencias del elemento correspondiente, en un formato de texto simple.

     ALLOWED-REFERENCES debe ser o bien #f o una lista de nombres y paquetes de salida. En el último caso, la lista denota elementos del almacén a los que el resultado puede hacer referencia. Cualquier referencia a otro elemento del almacén produce un error de construcción. De igual manera con DISALLOWED-REFERENCES, que enumera elementos a los que las salidas no deben hacer referencia.

     DEPRECATION-WARNINGS determina si mostrar avisos de obsolescencia durante la compilación de los módulos. Puede ser #f, #t o 'detailed.

     El resto de parámetros funcionan como en derivation (see Derivaciones).

Los procedimientos local-file, plain-file, computed-file, program-file y scheme-file a continuación devuelven objetos tipo-fichero. Esto es, cuando se expanden en una expresión-G, estos objetos dirigen a un fichero en el almacén. Considere esta expresión-G:

     #~(system* #$(file-append glibc "/sbin/nscd") "-f"
                #$(local-file "/tmp/mi-nscd.conf"))

El efecto aquí es el ``internamiento'' de /tmp/mi-nscd.conf mediante su copia al almacén. Una vez expandida, por ejemplo vía gexp->derivation, la expresión-G hace referencia a la copia bajo /gnu/store; por tanto, la modificación o el borrado del fichero en /tmp no tiene ningún efecto en lo que la expresión-G hace. plain-file puede usarse de manera similar; se diferencia en que el contenido del fichero se proporciona directamente como una cadena.

 -- Procedimiento Scheme: local-file FICHERO [NOMBRE]
     [#:recursive? #f] [#:select? (const #t)]
     Devuelve un objeto que representa el fichero local FICHERO a añadir al almacén; este objeto puede usarse en una expresión-G. Si FICHERO es un nombre de fichero relativo, se busca de forma relativa al fichero fuente donde esta forma aparece. FICHERO se añadirá al almacén bajo NOMBRE---por defecto el nombre base de FICHERO.

     Cuando RECURSIVE? es verdadero, los contenidos del FICHERO se añaden recursivamente; si FICHERO designa un fichero plano y RECURSIVE? es verdadero, sus contenidos se añaden, y sus bits de permisos se mantienen.

     Cuando RECURSIVE? es verdadero, llama a (SELECT? FICHERO STAT) por cada entrada del directorio, donde FICHERO es el nombre absoluto de fichero de la entrada y STAT es el resultado de lstat; excluyendo las entradas para las cuales SELECT? no devuelve verdadero.

     Esta es la contraparte declarativa del procedimiento monádico interned-file (see interned-file).

 -- Procedimiento Scheme: plain-file NOMBRE CONTENIDO
     Devuelve un objeto que representa un fichero de texto llamado NOMBRE con el CONTENIDO proporcionado (una cadena o un vector de bytes) para ser añadido al almacén.

     Esta es la contraparte declarativa de text-file.

 -- Procedimiento Scheme: computed-file NOMBRE GEXP
     [#:options '(#:local-build? #t)]
     Devuelve un objeto que representa el elemento del almacén NOMBRE, un fichero o un directorio computado por GEXP. OPTIONS es una lista de parámetros adicionales a pasar a gexp->derivation.

     Esta es la contraparte declarativa de gexp->derivation.

 -- Procedimiento monádico: gexp->script NOMBRE EXP
     [#:guile (default-guile)] [#:module-path %load-path]
     Devuelve un guión ejecutable NOMBRE que ejecuta EXP usando GUILE, con los módulos importados por EXP en su ruta de búsqueda. Busca los módulos de EXP en MODULE-PATH.

     El ejemplo siguiente construye un guión que simplemente invoca la orden ls:

          (use-modules (guix gexp) (gnu packages base))

          (gexp->script "enumera-ficheros"
                        #~(execl #$(file-append coreutils "/bin/ls")
                                 "ls"))

     Cuando se ejecuta a través del almacén (see run-with-store), obtenemos una derivación que produce un fichero ejecutable /gnu/store/...-enumera-ficheros más o menos así:

          #!/gnu/store/...-guile-2.0.11/bin/guile -ds
          !#
          (execl "/gnu/store/...-coreutils-8.22"/bin/ls" "ls")

 -- Procedimiento Scheme: program-file NOMBRE EXP
     [#:guile #f] [#:module-path %load-path]
     Devuelve un objeto que representa el elemento ejecutable del almacén NOMBRE que ejecuta GEXP. GUILE es el paquete Guile usado para ejecutar el guión. Los módulos importados por GEXP se buscan en MODULE-PATH.

     Esta es la contraparte declarativa de gexp->script.

 -- Procedimiento monádico: gexp->file NOMBRE EXP
     [#:set-load-path? #t] [#:module-path %load-path]
     [#:splice? #f]
     [#:guile (default-guile)]
     Devuelve una derivación que construye un fichero NOMBRE que contiene EXP. Cuando SPLICE? es verdadero, se considera que EXP es una lista de expresiones que deben ser expandidas en el fichero resultante.

     Cuando SET-LOAD-PATH es verdadero, emite código en el fichero resultante para establecer %load-path y %load-compiled-path de manera que respeten los módulos importados por EXP. Busca los módulos de EXP en MODULE-PATH.

     El fichero resultante hace referencia a todas las dependencias de EXP o a un subconjunto de ellas.

 -- Procedimiento Scheme: scheme-file NOMBRE EXP [#:splice? #f]
     Devuelve un objeto que representa el fichero Scheme NOMBRE que contiene EXP.

     Esta es la contraparte declarativa de gexp->file.

 -- Procedimiento monádico: text-file* NOMBRE TEXTO ...
     Devuelve como un valor monádico una derivación que construye un fichero de texto que contiene todo TEXTO. TEXTO puede ser una lista de, además de cadenas, objetos de cualquier tipo que pueda ser usado en expresiones-G: paquetes, derivaciones, ficheros locales, objetos, etc. El fichero del almacén resultante hace referencia a todos ellos.

     Esta variante debe preferirse sobre text-file cuando el fichero a crear haga referencia a elementos del almacén. Esto es el caso típico cuando se construye un fichero de configuración que embebe nombres de ficheros del almacén, como este:

          (define (perfil.sh)
            ;; Devuelve el nombre de un guión shell en el almacén
            ;; que establece la variable de entorno 'PATH'
            (text-file* "perfil.sh"
                        "export PATH=" coreutils "/bin:"
                        grep "/bin:" sed "/bin\n"))

     En este ejemplo, el fichero /gnu/store/...-perfil.sh resultante hará referencia a COREUTILS, GREP y SED, por tanto evitando que se recolecten como basura durante su tiempo de vida.

 -- Procedimiento Scheme: mixed-text-file NOMBRE TEXTO ...
     Devuelve un objeto que representa el fichero del almacén NOMBRE que contiene TEXTO. TEXTO es una secuencia de cadenas y objetos tipo-fichero, como en:

          (mixed-text-file "perfil"
                           "export PATH=" coreutils "/bin:" grep "/bin")

     Esta es la contraparte declarativa de text-file*.

 -- Procedimiento Scheme: file-union NOMBRE FICHEROS
     Devuelve un <computed-file> que construye un directorio que contiene todos los FICHEROS. Cada elemento en FICHEROS debe ser una lista de dos elementos donde el primer elemento es el nombre de fichero a usar en el nuevo directorio y el segundo elemento es una expresión-G que denota el fichero de destino. Aquí está un ejemplo:

          (file-union "etc"
                      `(("hosts" ,(plain-file "hosts"
                                              "127.0.0.1 localhost"))
                        ("bashrc" ,(plain-file "bashrc"
                                               "alias ls='ls --color=auto'"))))

     Esto emite un directorio etc que contiene estos dos ficheros.

 -- Procedimiento Scheme: directory-union NOMBRE COSAS
     Devuelve un directorio que es la unión de COSAS, donde COSAS es una lista de objetos tipo-fichero que denotan directorios. Por ejemplo:

          (directory-union "guile+emacs" (list guile emacs))

     emite un directorio que es la unión de los paquetes guile y emacs.

 -- Procedimientos Scheme: file-append OBJ SUFIJO ...
     Devuelve un objeto tipo-fichero que se expande a la concatenación de OBJ y SUFIJO, donde OBJ es un objeto que se puede bajar de nivel y cada SUFIJO es una cadena.

     Como un ejemplo, considere esta expresión-G:

          (gexp->script "ejecuta-uname"
                        #~(system* #$(file-append coreutils
                                                  "/bin/uname")))

     El mismo efecto podría conseguirse con:

          (gexp->script "ejecuta-uname"
                        #~(system* (string-append #$coreutils
                                                  "/bin/uname")))

     Hay una diferencia no obstante: en el caso de file-append, el guión resultante contiene una ruta absoluta de fichero como una cadena, mientras que en el segundo caso, el guión resultante contiene una expresión (string-append ...) para construir el nombre de fichero en tiempo de ejecución.

Por supuesto, además de expresiones-G embebidas en código ``anfitrión'', hay también módulos que contienen herramientas de construcción. Para clarificar que están destinados para su uso en el estrato de construcción, estos módulos se mantienen en el espacio de nombres (guix build ...).

Internamente, los objetos de alto nivel se bajan de nivel, usando su compilador, a derivaciones o elementos del almacén. Por ejemplo, bajar de nivel un paquete emite una derivación, y bajar de nivel un PLAIN-FILE emite un elemento del almacén. Esto se consigue usando el procedimiento monádico lower-object.

 -- Procedimiento monádico: lower-object OBJ [SISTEMA]
     [#:target #f]
     Devuelve como un valor en %STORE-MONAD la derivación o elemento del almacén que corresponde a OBJ en SISTEMA, compilando de manera cruzada para TARGET si TARGET es verdadero. OBJ debe ser un objeto que tiene asociado un compilador de expresiones-G, como <package>.

Invocación de guix repl
=======================

La orden guix repl lanza un bucle de lectura-evaluación-impresión Guile (REPL) para programación interactiva (see Using Guile Interactively (GNU Guile Reference Manual)). Comparado a simplemente lanzar la orden guile, guix repl garantiza que todos los módulos Guix y todas sus dependencias están disponibles en la ruta de búsqueda. Puede usarla de esta manera:

     $ guix repl
     scheme@(guile-user)> ,use (gnu packages base)
     scheme@(guile-user)> coreutils
     $1 = #<package coreutils@8.29 gnu/packages/base.scm:327 3e28300>

Además, guix repl implementa un protocolo del REPL simple legible por máquinas para su uso por (guix inferior), una facilidad para interactuar con inferiores, procesos separados que ejecutan una revisión de Guix potencialmente distinta.

Las opciones disponibles son las siguientes:

--type=TIPO
-t TIPO
     Inicia un REPL del TIPO dado, que puede ser uno de los siguientes:

     guile
          Es el predeterminado, y lanza una sesión interactiva Guile estándar con todas las características.

     machine
          Lanza un REPL que usa el protocolo legible por máquinas. Este es el protocolo con el que el módulo (guix inferior) se comunica.

--listen=DESTINO
     Por defecto, guix repl lee de la entrada estándar y escribe en la salida estándar. Cuando se pasa esta opción, en vez de eso escuchará las conexiones en DESTINO. Estos son ejemplos de opciones válidas:

     --listen=tcp:37146
          Acepta conexiones locales por el puerto 37146.

     --listen=unix:/tmp/socket
          Acepta conexiones a través del socket de dominio Unix /tmp/socket.

Utilidades
**********

Esta sección describe las utilidades de línea de órdenes de Guix. Algunas de ellas están orientadas principalmente para desarrolladoras y usuarias que escriban definiciones de paquetes nuevas, mientras que otras son útiles de manera más general. Complementan la interfaz programática Scheme de Guix de modo conveniente.

Invocación de guix build
========================

La orden guix build construye paquetes o derivaciones y sus dependencias, e imprime las rutas del almacén resultantes. Fíjese que no modifica el perfil de la usuaria---este es el trabajo de la orden guix package (see Invocación de guix package). Por tanto, es útil principalmente para las desarrolladoras de la distribución.

La sintaxis general es:

     guix build OPCIONES PAQUETE-O-DERIVACIÓN...

Como ejemplo, la siguiente orden construye las últimas versiones de Emacs y Guile, muestra sus log de construcción, y finalmente muestra los directorios resultantes:

     guix build emacs guile

De forma similar, la siguiente orden construye todos los paquetes disponibles:

     guix build --quiet --keep-going \
       `guix package -A | cut -f1,2 --output-delimiter=@`

PAQUETE-O-DERIVACIÓN puede ser tanto el nombre de un paquete que se encuentra en la distribución de software como coreutils o coreutils@8.20, o una derivación como /gnu/store/...-coreutils-8.19.drv. En el primer caso, el paquete de nombre (y opcionalmente versión) correspondiente se busca entre los módulos de la distribución GNU (see Módulos de paquetes).

De manera alternativa, la opción --expression puede ser usada para especificar una expresión Scheme que evalúa a un paquete; esto es útil para la desambiguación entre varios paquetes del mismo nombre o si se necesitan variaciones del paquete.

Puede haber cero o más OPCIONES. Las opciones disponibles se describen en la subsección siguiente.

Opciones comunes de construcción
--------------------------------

Un número de opciones que controlan el proceso de construcción son comunes a guix build y otras órdenes que pueden lanzar construcciones, como guix package o guix archive. Son las siguientes:

--load-path=DIRECTORIO
-L DIRECTORIO
     Añade DIRECTORIO al frente de la ruta de búsqueda de módulos de paquetes (see Módulos de paquetes).

     Esto permite a las usuarias definir sus propios paquetes y hacerlos visibles a las herramientas de línea de órdenes.

--keep-failed
-K
     Mantiene los árboles de construcción de las construcciones fallidas. Por tanto, si una construcción falla, su árbol de construcción se mantiene bajo /tmp, en un directorio cuyo nombre se muestra al final del log de construcción. Esto es útil cuando se depuran problemas en la construcción. See Depuración de fallos de construcción, para trucos y consejos sobre cómo depurar problemas en la construcción.

     Esta opción no tiene efecto cuando se conecta a un daemon remoto con una URI guix:// (see the GUIX_DAEMON_SOCKET variable).

--keep-going
-k
     Seguir adelante cuando alguna de las derivaciones de un fallo durante la construcción; devuelve una única vez todas las construcciones que se han completado o bien han fallado.

     El comportamiento predeterminado es parar tan pronto una de las derivaciones especificadas falle.

--dry-run
-n
     No construye las derivaciones.

--fallback
     Cuando la sustitución de un binario preconstruido falle, intenta la construcción local de paquetes (see Fallos en las sustituciones).

--substitute-urls=URLS
     Considera URLS la lista separada por espacios de URLs de fuentes de sustituciones, anulando la lista predeterminada de URLs de guix-daemon (see guix-daemon URLs).

     Significa que las sustituciones puede ser descargadas de URLS, mientras que estén firmadas por una clave autorizada por la administradora del sistema (see Sustituciones).

     Cuando URLS es la cadena vacía, las sustituciones están efectivamente deshabilitadas.

--no-substitutes
     No usa sustituciones para la construcción de productos. Esto es, siempre realiza las construcciones localmente en vez de permitir la descarga de binarios pre-construidos (see Sustituciones).

--no-grafts
     No ``injerta'' paquetes. En la práctica esto significa que las actualizaciones de paquetes disponibles como injertos no se aplican. See Actualizaciones de seguridad, para más información sobre los injertos.

--rounds=N
     Construye cada derivación N veces seguidas, y lanza un error si los resultados de las construcciones consecutivas no son idénticos bit-a-bit.

     Esto es útil para la detección de procesos de construcción no-deterministas. Los procesos de construcción no-deterministas son un problema puesto que prácticamente imposibilitan a las usuarias la verificación de la autenticidad de binarios proporcionados por terceras partes. See Invocación de guix challenge, para más sobre esto.

     Fíjese que, actualmente, los resultados de las construcciones discordantes no se mantienen, por lo que debe que investigar manualmente en caso de un error---por ejemplo, mediante la extracción de uno de los resultados con guix archive --export (see Invocación de guix archive), seguida de una reconstrucción, y finalmente la comparación de los dos resultados.

--no-build-hook
     No intenta delegar construcciones a través del ``hook de construcción'' del daemon (see Configuración de delegación del daemon). Es decir, siempre realiza las construcciones de manera local en vez de delegando construcciones a máquinas remotas.

--max-silent-time=SEGUNDOS
     Cuando la construcción o sustitución permanece en silencio más de SEGUNDOS, la finaliza e informa de un fallo de construcción.

     Por defecto, se respeta la configuración del daemon (see --max-silent-time).

--timeout=SEGUNDOS
     Del mismo modo, cuando el proceso de construcción o sustitución dura más de SEGUNDOS, lo termina e informa un fallo de construcción.

     Por defecto, se respeta la configuración del daemon (see --timeout).

-v NIVEL
--verbosity=NIVEL
     Use the given verbosity LEVEL, an integer.  Choosing 0 means that no output is produced, 1 is for quiet output, and 2 shows all the build log output on standard error.

--cores=N
-c N
     Permite usar N núcleos de la CPU para la construcción. El valor especial 0 significa usar tantos como núcleos haya en la CPU.

--max-jobs=N
-M N
     Permite como máximo N trabajos de construcción en paralelo. See --max-jobs, para detalles acerca de esta opción y la opción equivalente de guix-daemon.

--debug=NIVEL
     Produce debugging output coming from the build daemon.  LEVEL must be an integer between 0 and 5; higher means more verbose output.  Setting a level of 4 or more may be helpful when debugging setup issues with the build daemon.

Tras las cortinas, guix build es esencialmente una interfaz al procedimiento package-derivation del módulo (guix packages), y al procedimiento build-derivations del módulo (guix derivations).

Además de las opciones proporcionadas explícitamente en la línea de órdenes, guix build y otras órdenes guix que permiten la construcción respetan el contenido de la variable de entorno GUIX_BUILD_OPTIONS.

 -- Variable de entorno: GUIX_BUILD_OPTIONS
     Las usuarias pueden definir esta variable para que contenga una lista de opciones de línea de órdenes que se usarán automáticamente por guix build y otras órdenes guix que puedan realizar construcciones, como en el ejemplo siguiente:

          $ export GUIX_BUILD_OPTIONS="--no-substitutes -c 2 -L /foo/bar"

     Estas opciones se analizan independientemente, y el resultado se añade a continuación de las opciones de línea de órdenes.

Opciones de transformación de paquetes
--------------------------------------

Otro conjunto de opciones de línea de órdenes permitidas por guix build y también guix package son las opciones de transformación de paquetes. Son opciones que hacen posible la definición de variaciones de paquetes---por ejemplo, paquetes construidos con un código fuente diferente. Es una forma conveniente de crear paquetes personalizados al vuelo sin tener que escribir las definiciones de las variaciones del paquete (see Definición de paquetes).

--with-source=FUENTE
--with-source=PAQUETE=FUENTE
--with-source=PAQUETE@VERSIÓN=FUENTE
     Usa FUENTE como la fuente de PAQUETE, y VERSIÓN como su número de versión. FUENTE debe ser un nombre de fichero o una URL, como en guix download (see Invocación de guix download).

     Cuando se omite PAQUETE, se toma el nombre de paquete especificado en la línea de ordenes que coincide con el nombre base de FUENTE---por ejemplo, si FUENTE fuese /src/guile-2.0.10.tar.gz, el paquete correspondiente sería guile.

     Del mismo modo, si se omite VERSIÓN, la cadena de versión se deduce de ĐUENTE; en el ejemplo previo sería 2.0.10.

     Esta opción permite a las usuarias probar versiones del paquete distintas a las proporcionadas en la distribución. El ejemplo siguiente descarga ed-1.7.tar.gz de un espejo GNU y lo usa como la fuente para el paquete ed:

          guix build ed --with-source=mirror://gnu/ed/ed-1.7.tar.gz

     Como desarrolladora, --with-source facilita la prueba de versiones candidatas para la publicación:

          guix build guile --with-source=../guile-2.0.9.219-e1bb7.tar.xz

     ... o la construcción desde una revisión en un entorno limpio:

          $ git clone git://git.sv.gnu.org/guix.git
          $ guix build guix --with-source=guix@1.0=./guix

--with-input=PAQUETE=REEMPLAZO
     Substituye dependencias de PAQUETE por dependencias de REEMPLAZO. PAQUETE debe ser un nombre de paquete, y REEMPLAZO debe ser una especificación de paquete como guile o guile@1.8.

     Por ejemplo, la orden siguiente construye Guix, pero substituye su dependencia de la versión estable actual de Guile con una dependencia en la versión antigua de Guile, guile@2.0:

          guix build --with-input=guile=guile@2.0 guix

     Esta sustitución se realiza de forma recursiva y en profundidad. Por lo que en este ejemplo, tanto guix como su dependencia guile-json (que también depende de guile) se reconstruyen contra guile@2.0.

     Se implementa usando el procedimiento Scheme package-input-rewriting (see package-input-rewriting).

--with-graft=PAQUETE=REEMPLAZO
     Es similar a --with-input pero con una diferencia importante: en vez de reconstruir la cadena de dependencias completa, REEMPLAZO se construye y se injerta en los binarios que inicialmente hacían referencia a PAQUETE. See Actualizaciones de seguridad, para más información sobre injertos.

     Por ejemplo, la orden siguiente injerta la versión 3.5.4 de GnuTLS en Wget y todas sus dependencias, substituyendo las referencias a la versión de GnuTLS que tienen actualmente:

          guix build --with-graft=gnutls=gnutls@3.5.4 wget

     Esta opción tiene la ventaja de ser mucho más rápida que la reconstrucción de todo. Pero hay una trampa: funciona si y solo si PAQUETE y REEMPLAZO son estrictamente compatibles---por ejemplo, si proporcionan una biblioteca, la interfaz binaria de aplicación (ABI) de dichas bibliotecas debe ser compatible. Si REEMPLAZO es incompatible de alguna manera con PAQUETE, el paquete resultante puede no ser usable. ¡Úsela con precaución!

--with-git-url=PAQUETE=URL
     Build PACKAGE from the latest commit of the master branch of the Git repository at URL.  Git sub-modules of the repository are fetched, recursively.

     For example, the following command builds the NumPy Python library against the latest commit of the master branch of Python itself:

          guix build python-numpy \
            --with-git-url=python=https://github.com/python/cpython

     This option can also be combined with --with-branch or --with-commit (see below).

     Obviously, since it uses the latest commit of the given branch, the result of such a command varies over time.  Nevertheless it is a convenient way to rebuild entire software stacks against the latest commit of one or more packages.  This is particularly useful in the context of continuous integration (CI).

     Checkouts are kept in a cache under ~/.cache/guix/checkouts to speed up consecutive accesses to the same repository.  You may want to clean it up once in a while to save disk space.

--with-branch=PAQUETE=RAMA
     Build PACKAGE from the latest commit of BRANCH.  If the source field of PACKAGE is an origin with the git-fetch method (see Referencia de ``origin'') or a git-checkout object, the repository URL is taken from that source.  Otherwise you have to use --with-git-url to specify the URL of the Git repository.

     For instance, the following command builds guile-sqlite3 from the latest commit of its master branch, and then builds guix (which depends on it) and cuirass (which depends on guix) against this specific guile-sqlite3 build:

          guix build --with-branch=guile-sqlite3=master cuirass

--with-commit=PAQUETE=REVISIÓN
     This is similar to --with-branch, except that it builds from COMMIT rather than the tip of a branch.  COMMIT must be a valid Git commit SHA1 identifier.

Opciones de construcción adicionales
------------------------------------

Las opciones de línea de ordenes presentadas a continuación son específicas de guix build.

--quiet
-q
     Build quietly, without displaying the build log; this is equivalent to --verbosity=0.  Upon completion, the build log is kept in /var (or similar) and can always be retrieved using the --log-file option.

--file=FICHERO
-f FICHERO
     Construye el paquete, derivación u otro objeto tipo-fichero al que evalúa el código en FICHERO (see file-like objects).

     Como un ejemplo, FICHERO puede contener una definición como esta (see Definición de paquetes):

               [file package-hello.scm not included]

--expression=EXPR
-e EXPR
     Construye el paquete o derivación al que EXPR evaulua.

     Por ejemplo, EXPR puede ser (@ (gnu packages guile) guile-1.8), que designa sin ambigüedad a esta variante específica de la versión 1.8 de Guile.

     De manera alternativa, EXPR puede ser una expresión-G, en cuyo caso se usa como un programa de construcción pasado a gexp->derivation (see Expresiones-G).

     Por último, EXPR puede hacer referencia a un procedimiento mónadico sin parámetros (see La mónada del almacén). El procedimiento debe devolver una derivación como un valor monádico, el cual después se pasa a través de run-with-store.

--source
-S
     Construye las derivaciones de las fuentes de los paquetes, en vez de los paquetes mismos.

     Por ejemplo, guix build -S gcc devuelve algo como /gnu/store/...-gcc-4.7.2.tar.bz2, el cual es el archivador tar de fuentes de GCC.

     El archivador tar devuelto es el resultado de aplicar cualquier parche y fragmento de código en el origen (campo origin) del paquete (see Definición de paquetes).

--sources
     Obtiene y devuelve las fuentes de PAQUETE-O-DERIVACIÓN y todas sus dependencias, recursivamente. Esto es útil para obtener una copia local de todo el código fuente necesario para construir los PAQUETES, permitiendole construirlos llegado el momento sin acceso a la red. Es una extensión de la opción --source y puede aceptar uno de los siguientes valores opcionales como parámetro:

     package
          Este valor hace que la opción --sources se comporte de la misma manera que la opción --source.

     all
          Construye las derivaciones de las fuentes de todos los paquetes, incluyendo cualquier fuente que pueda enumerarse como entrada (campo inputs). Este es el valor predeterminado.

               $ guix build --sources tzdata
               The following derivations will be built:
                  /gnu/store/...-tzdata2015b.tar.gz.drv
                  /gnu/store/...-tzcode2015b.tar.gz.drv

     transitive
          Construye las derivaciones de fuentes de todos los paquetes, así como todas las entradas transitivas de los paquetes. Esto puede usarse, por ejemplo, para obtener las fuentes de paquetes para una construcción posterior sin conexión a la red.

               $ guix build --sources=transitive tzdata
               The following derivations will be built:
                  /gnu/store/...-tzcode2015b.tar.gz.drv
                  /gnu/store/...-findutils-4.4.2.tar.xz.drv
                  /gnu/store/...-grep-2.21.tar.xz.drv
                  /gnu/store/...-coreutils-8.23.tar.xz.drv
                  /gnu/store/...-make-4.1.tar.xz.drv
                  /gnu/store/...-bash-4.3.tar.xz.drv
               ...

--system=SISTEMA
-s SISTEMA
     Attempt to build for SYSTEM---e.g., i686-linux---instead of the system type of the build host.  The guix build command allows you to repeat this option several times, in which case it builds for all the specified systems; other commands ignore extraneous -s options.

          La opción --system es para compilación nativa y no debe confundirse con la compilación cruzada. Véase --target más adelante para información sobre compilación cruzada.

     Un ejemplo de uso de esta opción es en sistemas basados en Linux, que pueden emular diferentes personalidades. Por ejemplo, pasar --system=i686-linux en un sistema x86_64-linux o --system=armhf-linux en un sistema aarch64-linux le permite construir paquetes en un entorno de 32-bits completo.

          La construcción para un sistema armhf-linux está habilitada incondicionalmente en máquinas aarch64-linux, aunque determinados procesadores aarch64 no permiten esta funcionalidad, notablemente el ThunderX.

     De manera similar, cuando la emulación transparente con QEMU y binfmt_misc está habilitada (see qemu-binfmt-service-type), puede construir para cualquier sistema para el que un manejador QEMU de binfmt_misc esté instalado.

     Las construcciones para un sistema distinto al de la máquina que usa pueden delegarse también a una máquina remota de la arquitectura correcta. See Configuración de delegación del daemon, para más información sobre delegación.

--target=TRIPLETA
     Compilación cruzada para la TRIPLETA, que debe ser una tripleta GNU válida, cómo "mips64el-linux-gnu" (see GNU configuration triplets (Autoconf)).

--check
     Reconstruye PAQUETE-O-DERIVACIÓN, que ya está disponible en el almacén, y emite un error si los resultados de la construcción no son idénticos bit-a-bit.

     Este mecanismo le permite comprobar si sustituciones previamente instaladas son genuinas (see Sustituciones), o si el resultado de la construcción de un paquete es determinista. See Invocación de guix challenge, para más información de referencia y herramientas.

     Cuando se usa conjuntamente con --keep-failed, la salida que difiere se mantiene en el almacén, bajo /gnu/store/...-check. Esto hace fácil buscar diferencias entre los dos resultados.

--repair
     Intenta reparar los elementos del almacén especificados, si están corruptos, volviendo a descargarlos o reconstruyendolos.

     Esta operación no es atómica y por lo tanto está restringida a root.

--derivations
-d
     Devuelve las rutas de derivación, no las rutas de salida, de los paquetes proporcionados.

--root=FICHERO
-r FICHERO
     Hace que FICHERO sea un enlace simbólico al resultado, y lo registra como una raíz del recolector de basura.

     Consecuentemente, los resultados de esta invocación de guix build se protegen de la recolección de basura hasta que FICHERO se elimine. Cuando se omite esa opción, los resultados son candidatos a la recolección de basura en cuanto la construcción se haya completado. See Invocación de guix gc, para más sobre las raíces del recolector de basura.

--log-file
     Devuelve los nombres de ficheros o URL de los log de construcción para el PAQUETE-O-DERIVACIÓN proporcionado, o emite un error si no se encuentran los log de construcción.

     Esto funciona independientemente de cómo se especificasen los paquetes o derivaciones. Por ejemplo, las siguientes invocaciones son equivalentes:

          guix build --log-file `guix build -d guile`
          guix build --log-file `guix build guile`
          guix build --log-file guile
          guix build --log-file -e '(@ (gnu packages guile) guile-2.0)'

     Si un log no está disponible localmente, y a menos que se proporcione --no-substitutes, la orden busca el log correspondiente en uno de los servidores de sustituciones (como se especificaron con --substitute-urls).

     Por lo que dado el caso, imaginese que desea ver el log de construcción de GDB en MIPS, pero realmente está en una máquina x86_64:

          $ guix build --log-file gdb -s mips64el-linux
          https://ci.guix.es.info/log/...-gdb-7.10

     ¡Puede acceder libremente a una biblioteca inmensa de log de construcción!

Depuración de fallos de construcción
------------------------------------

Cuando esté definiendo un paquete nuevo (see Definición de paquetes), probablemente se encuentre que dedicando algún tiempo a depurar y afinar la construcción hasta obtener un resultado satisfactorio. Para hacerlo, tiene que lanzar manualmente las órdenes de construcción en un entorno tan similar como sea posible al que el daemon de construcción usa.

Para ello, la primera cosa a hacer es usar la opción --keep-failed o -K de guix build, lo que mantiene el árbol de la construcción fallida en /tmp o el directorio que especificase con TMPDIR (see --keep-failed).

De ahí en adelante, puede usar cd para ir al árbol de la construcción fallida y cargar el fichero environment-variables, que contiene todas las definiciones de variables de entorno que existían cuando la construcción falló. Digamos que está depurando un fallo en la construcción del paquete foo; una sesión típica sería así:

     $ guix build foo -K
     ... build fails
     $ cd /tmp/guix-build-foo.drv-0
     $ source ./environment-variables
     $ cd foo-1.2

Ahora puede invocar órdenes (casi) como si fuese el daemon y encontrar los errores en su proceso de construcción.

A veces ocurre que, por ejemplo, las pruebas de un paquete pasan cuando las ejecuta manualmente pero fallan cuando el daemon las ejecuta. Esto puede suceder debido a que el daemon construye dentro de contenedores donde, al contrario que en nuestro entorno previo, el acceso a la red no está disponible, /bin/sh no existe, etc. (see Configuración del entorno de construcción).

En esos casos, puede tener que inspeccionar el proceso de construcción desde un contenedor similar al creado por el daemon de construcción:

     $ guix build -K foo
     ...
     $ cd /tmp/guix-build-foo.drv-0
     $ guix environment --no-grafts -C foo --ad-hoc strace gdb
     [env]# source ./environment-variables
     [env]# cd foo-1.2

Aquí, guix environment -C crea un contenedor y lanza un shell nuevo en él (see Invocación de guix environment). El fragmento --ad-hoc strace gdb añade las ordenes strace y gdb al contenedor, las cuales pueden resultar útiles durante la depuración. La opción --no-grafts asegura que obtenemos exactamente el mismo entorno, con paquetes sin injertos (see Actualizaciones de seguridad, para más información sobre los injertos).

Para acercarnos más al contenedor usado por el daemon de construcción, podemos eliminar /bin/sh:

     [env]# rm /bin/sh

(No se preocupe, es inocuo: todo esto ocurre en el contenedor de usar y tirar creado por guix environment).

La orden strace probablemente no esté en la ruta de búsqueda, pero podemos ejecutar:

     [env]# $GUIX_ENVIRONMENT/bin/strace -f -o log make check

De este modo, no solo habrá reproducido las variables de entorno que usa el daemon, también estará ejecutando el proceso de construcción en un contenedor similar al usado por el daemon.

Invocación de guix edit
=======================

¡Tantos paquetes, tantos ficheros de fuentes! La orden guix edit facilita la vida de las usuarias y empaquetadoras apuntando su editor al fichero de fuentes que contiene la definición de los paquetes especificados. Por ejemplo:

     guix edit gcc@4.9 vim

lanza el programa especificado en la variable de entorno VISUAL o en EDITOR para ver la receta de GCC 4.9.3 y la de Vim.

Si está usando una copia de trabajo de Git de Guix (see Construcción desde Git), o ha creado sus propios paquetes en GUIX_PACKAGE_PATH (see Módulos de paquetes), será capaz de editar las recetas de los paquetes. En otros casos, podrá examinar las recetas en modo de lectura únicamente para paquetes actualmente en el almacén.

Invocación de guix download
===========================

Durante la escritura de una definición de paquete, las desarrolladoras típicamente tienen que descargar un archivador tar de fuentes, calcular su hash SHA256 y escribir ese hash en la definición del paquete (see Definición de paquetes). La herramienta guix download ayuda con esta tarea: descarga un fichero de la URI proporcionada, lo añade al almacén e imprime tanto su nombre de fichero en el almacén como su hash SHA256.

El hecho de que el fichero descargado se añada al almacén ahorra ancho de banda: cuando el desarrollador intenta construir el paquete recién definido con guix build, el archivador de fuentes no tiene que descargarse de nuevo porque ya está en el almacén. También es una forma conveniente de conservar ficheros temporalmente, que pueden ser borrados en un momento dado (see Invocación de guix gc).

La orden guix download acepta las mismas URI que las usadas en las definiciones de paquetes. En particular, permite URI mirror://. Las URI https (HTTP sobre TLS) se aceptan cuando el enlace Guile con GnuTLS está disponible en el entorno de la usuaria; cuando no está disponible se emite un error. See how to install the GnuTLS bindings for Guile (GnuTLS-Guile), para más información.

guix download verifica los certificados del servidor HTTPS cargando las autoridades X.509 del directorio al que apunta la variable de entorno SSL_CERT_DIR (see Certificados X.509), a menos que se use --no-check-certificate.

Las siguientes opciones están disponibles:

--format=FMT
-f FMT
     Escribe el hash en el formato especificado por FMT. Para más información sobre los valores aceptados en FMT, see Invocación de guix hash.

--no-check-certificate
     No valida los certificados X.509 de los servidores HTTPS.

     Cuando se usa esta opción, no tiene absolutamente ninguna garantía de que está comunicando con el servidor responsable de la URL auténtico, lo que le hace vulnerables a ataques de intercepción (``man-in-the-middle'').

--output=FICHERO
-o FICHERO
     Almacena el fichero descargado en FICHERO en vez de añadirlo al almacén.

Invocación de guix hash
=======================

La orden guix hash calcula el hash SHA256 de un fichero. Es principalmente una conveniente herramienta para cualquiera que contribuya a la distribución: calcula el hash criptográfico de un fichero, que puede usarse en la definición de un paquete (see Definición de paquetes).

La sintaxis general es:

     guix hash OPCIONES FICHERO

Cuando FICHERO es - (un guión), guix hash calcula el hash de los datos leídos por la entrada estándar. guix hash tiene las siguientes opciones:

--format=FMT
-f FMT
     Escribe el hash en el formato especificado por FMT.

     Los formatos disponibles son: nix-base32, base32, base16 (se puede usar también hex y hexadecimal).

     Si no se especifica la opción --format, guix hash mostrará el hash en nix-base32. Esta representación es la usada en las definiciones de paquetes.

--recursive
-r
     Calcula el hash de FICHERO recursivamente.

     Es este caso el hash se calcula en un archivador que contiene FICHERO, incluyendo su contenido si es un directorio. Algunos de los metadatos de FICHERO son parte del archivador; por ejemplo, cuando FICHERO es un fichero normal, el hash es diferente dependiendo de si FICHERO es ejecutable o no. Los metadatos como las marcas de tiempo no influyen en el hash (see Invocación de guix archive).

--exclude-vcs
-x
     Cuando se combina con --recursive, excluye los directorios del sistema de control de versiones (.bzr, .git, .hg, etc.).

     Como un ejemplo, así es como calcularía el hash de una copia de trabajo Git, lo cual es útil cuando se usa el método git-fetch (see Referencia de ``origin''):

          $ git clone http://example.org/foo.git
          $ cd foo
          $ guix hash -rx .

Invocación de guix import
=========================

La orden guix import es útil para quienes desean añadir un paquete a la distribución con el menor trabajo posible---una demanda legítima. La orden conoce algunos repositorios de los que puede ``importar'' metadatos de paquetes. El resultado es una definición de paquete, o una plantilla de ella, en el formato que conocemos (see Definición de paquetes).

La sintaxis general es:

     guix import IMPORTADOR OPCIONES...

IMPORTADOR especifica la fuente de la que se importan los metadatos del paquete, OPCIONES especifica un identificador de paquete y otras opciones específicas del IMPORTADOR. Actualmente, los ``importadores'' disponibles son:

gnu
     Importa los metadatos del paquete GNU seleccionado. Proporciona una plantilla para la última versión de dicho paquete GNU, incluyendo el hash de su archivador tar de fuentes, y su sinopsis y descripción canónica.

     Información adicional como las dependencias del paquete y su licencia deben ser deducidas manualmente.

     Por ejemplo, la siguiente orden devuelve una definición de paquete para GNU Hello.

          guix import gnu hello

     Las opciones específicas de línea de ordenes son:

     --key-download=POLÍTICA
          Como en guix refresh, especifica la política de tratamiento de las claves OpenPGP no encontradas cuando se verifica la firma del paquete. See --key-download.

pypi
     Importa metadatos desde el índice de paquetes Python (PyPI) (https://pypi.python.org/). La información se toma de la descripción con formato JSON disponible en pypi.python.org y habitualmente incluye toda la información relevante, incluyendo las dependencias del paquete. Para una máxima eficiencia, se recomienda la instalación de la utilidad unzip, de manera que el importador pueda extraer los archivos wheel de Python y obtener datos de ellos.

     La siguiente orden importa los meta-datos para el paquete de Python itsdangerous:

          guix import pypi itsdangerous

     --recursive
     -r
          Recorre el grafo de dependencias del paquete original proporcionado recursivamente y genera expresiones de paquete para todos aquellos paquetes que no estén todavía en Guix.

gem
     Importa metadatos desde RubyGems (https://rubygems.org/). La información se extrae de la descripción en formato JSON disponible en rubygems.org e incluye la información más relevante, incluyendo las dependencias en tiempo de ejecución. Hay algunos puntos a tener en cuenta, no obstante. Los metadatos no distinguen entre sinopsis y descripción, por lo que se usa la misma cadena para ambos campos. Adicionalmente, los detalles de las dependencias no-Ruby necesarias para construir extensiones nativas no está disponible y se deja como ejercicio a la empaquetadora.

     La siguiente orden importa los meta-datos para el paquete de Ruby rails:

          guix import gem rails

     --recursive
     -r
          Recorre el grafo de dependencias del paquete original proporcionado recursivamente y genera expresiones de paquete para todos aquellos paquetes que no estén todavía en Guix.

cpan
     Importa metadatos desde MetaCPAN (https://www.metacpan.org/). La información se extrae de la descripción en formato JSON disponible a través del API de MetaCPAN (https://fastapi.metacpan.org/) e incluye la información más relevante, como las dependencias de otros módulos. La información de la licencia debe ser comprobada atentamente. Si Perl está disponible en el almacén, se usará la utilidad corelist para borrar los módulos básicos de la lista de dependencias.

     La siguiente orden importa los metadatos del módulo Perl Acme::Boolean:

          guix import cpan Acme::Boolean

cran
     Importa metadatos desde CRAN (https://cran.r-project.org/), el repositorio central para el entorno estadístico y gráfico GNU R (http://r-project.org).

     La información se extrae del fichero DESCRIPTION del paquete.

     La siguiente orden importa los metadatos del paquete de R Cairo:

          guix import cran Cairo

     Cuando se añade --recursive, el importador recorrerá el grafo de dependencias del paquete original proporcionado recursivamente y generará expresiones de paquetes para todos aquellos que no estén todavía en Guix.

     Cuando se agrega --archive=bioconductor, los metadatos se importan de Bioconductor (https://www.bioconductor.org), un repositorio de paquetes R para el análisis y comprensión de datos genéticos de alto caudal en bioinformática.

     La información se extrae del fichero DESCRIPTION del paquete publicado en la interfaz web del repositorio SVN de Bioconductor.

     La siguiente orden importa los metadatos del paquete de R GenomicRanges:

          guix import cran --archive=bioconductor GenomicRanges

texlive
     Importa metadatos desde CTAN (http://www.ctan.org/), la completa red de archivos TeX para paquetes TeX que son parte de la distribución TeX Live (https://www.tug.org/texlive/).

     La información del paquete se obtiene a través del API XML proporcionado por CTAN, mientras que el código fuente se descarga del repositorio SVN del proyecto TeX Live. Se hace porque CTAN no guarda archivos con versiones.

     La siguiente orden importa los metadatos del paquete de TeX fontspec:

          guix import texlive fontspec

     Cuando se añade --archive=DIRECTORIO, el código fuente no se descarga del subdirectorio latex del árbol texmf-dist/source en el repositorio SVN de Tex Live, sino de el directorio especificado bajo la misma raíz.

     La siguiente orden importa los metadatos del paquete ifxetex de CTAN mientras que obtiene las fuentes del directorio texmf/source/generic:

          guix import texlive --archive=generic ifxetex

json
     Importa metadatos de paquetes desde un fichero JSON local. Considere el siguiente ejemplo de definición de paquete en formato JSON:

          {
            "name": "hello",
            "version": "2.10",
            "source": "mirror://gnu/hello/hello-2.10.tar.gz",
            "build-system": "gnu",
            "home-page": "https://www.gnu.org/software/hello/",
            "synopsis": "Hello, GNU world: An example GNU package",
            "description": "GNU Hello prints a greeting.",
            "license": "GPL-3.0+",
            "native-inputs": ["gcc@6"]
          }

     Los nombres de los campos son los mismos que para el registro <package> (see Definición de paquetes). Las referencias a otros paquetes se proporcionan como listas JSON de cadenas de especificación de paquete entrecomilladas como guile o guile@2.0.

     El importador también permite una definición de fuentes más explícita usando los campos comunes de los registros <origin>:

          {
            ...
            "source": {
              "method": "url-fetch",
              "uri": "mirror://gnu/hello/hello-2.10.tar.gz",
              "sha256": {
                "base32": "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"
              }
            }
            ...
          }

     La siguiente orden importa los metadatos desde el fichero JSON hello.json y devuelve una expresión de ``package'':

          guix import json hello.json

nix
     Importa metadatos desde una copia local de las fuentes de la distribución Nixpkgs (http://nixos.org/nixpkgs/) (Esto depende de la orden nix-instantiate de Nix (http://nixos.org/nix/).). Las definiciones de paquete en Nixpkgs típicamente están escritas en una mezcla de lenguaje Nix y código Bash. Esta orden únicamente importa la estructura de alto nivel del paquete escrita en lenguaje Nix. Normalmente incluye todos los campos básicos de una definición de paquete.

     Cuando se importa un paquete GNU, la sinopsis y la descripción se substituyen por la variante canónica oficial.

     Habitualmente, tendrá que ejecutar primero:

          export NIX_REMOTE=daemon

     de modo que nix-instantiate no intente abrir la base de datos Nix.

     Como un ejemplo, la orden siguiente importa la definición de paquete de LibreOffice (más precisamente, importa la definición del paquete asociado al atributo de nivel superior libreoffice):

          guix import nix ~/path/to/nixpkgs libreoffice

hackage
     Importa metadatos desde el archivo central de paquetes de la comunidad Haskell Hackage (https://hackage.haskell.org/). La información se obtiene de ficheros Cabal e incluye toda la información relevante, incluyendo las dependencias del paquete.

     Las opciones específicas de línea de ordenes son:

     --stdin
     -s
          Lee un fichero Cabal por la entrada estándar.

     --no-test-dependencies
     -t
          No incluye las dependencias necesarias únicamente para las baterías de pruebas.

     --cabal-environment=ALIST
     -e ALIST
          ALIST es una lista asociativa Scheme que define el entorno en el que los condicionales Cabal se evalúan. Los valores aceptados son: os, arch, impl y una cadena que representa el nombre de la condición. El valor asociado a la condición tiene que ser o bien el símbolo true o bien false. Los valores predeterminados asociados a las claves os, arch y impl son linux, x86_64 y ghc, respectivamente.

     --recursive
     -r
          Recorre el grafo de dependencias del paquete original proporcionado recursivamente y genera expresiones de paquete para todos aquellos paquetes que no estén todavía en Guix.

     La siguiente orden importa los metadatos de la última versión del paquete Haskell HTTP sin incluir las dependencias de las pruebas y especificando la opción network-uri con valor false:

          guix import hackage -t -e "'((\"network-uri\" . false))" HTTP

     Se puede especificar opcionalmente una versión específica del paquete añadiendo al nombre del paquete una arroba y el número de versión como en el siguiente ejemplo:

          guix import hackage mtl@2.1.3.1

stackage
     El importador stackage es un recubrimiento sobre el de hackage. Toma un nombre de paquete, busca la versión de paquete incluida en una publicación de la versión de mantenimiento extendido (LTS) Stackage (https://www.stackage.org) y usa el importador hackage para obtener sus metadatos. Fíjese que es su decisión seleccionar una publicación LTS compatible con el compilador GHC usado en Guix.

     Las opciones específicas de línea de ordenes son:

     --no-test-dependencies
     -t
          No incluye las dependencias necesarias únicamente para las baterías de pruebas.

     --lts-version=VERSIÓN
     -l VERSIÓN
          VERSIÓN es la versión LTS de publicación deseada. Si se omite se usa la última publicación.

     --recursive
     -r
          Recorre el grafo de dependencias del paquete original proporcionado recursivamente y genera expresiones de paquete para todos aquellos paquetes que no estén todavía en Guix.

     La siguiente orden importa los metadatos del paquete Haskell HTTP incluido en la versión de publicación LTS de Stackage 7.18:

          guix import stackage --lts-version=7.18 HTTP

elpa
     Importa metadatos desde el repositorio de archivos de paquetes Emacs Lisp (ELPA) (see Packages (The GNU Emacs Manual)).

     Las opciones específicas de línea de ordenes son:

     --archive=REPO
     -a REPO
          REPO identifica el repositorio de archivos del que obtener la información. Actualmente los repositorios disponibles y sus identificadores son:

            - GNU (http://elpa.gnu.org/packages), seleccionado con el identificador gnu. Es el predeterminado.

               Los paquetes de elpa.gnu.org están firmados con una de las claves que contiene el anillo de claves GnuPG en share/emacs/25.1/etc/package-keyring.gpg (o similar) en el paquete emacs (see ELPA package signatures (The GNU Emacs Manual)).

            - MELPA-Stable (http://stable.melpa.org/packages), seleccionado con el identificador melpa-stable.

            - MELPA (http://melpa.org/packages), seleccionado con el identificador melpa.

     --recursive
     -r
          Recorre el grafo de dependencias del paquete original proporcionado recursivamente y genera expresiones de paquete para todos aquellos paquetes que no estén todavía en Guix.

crate
     Importa metadatos desde el repositorio de paquetes Rust crates.io (https://crates.io).

opam
     Importa metadatos desde el repositorio de paquetes OPAM (https://opam.ocaml.org/) usado por la comunidad OCaml.

La estructura del código de guix import es modular. Sería útil tener más importadores para otros formatos de paquetes, y su ayuda es bienvenida aquí (see Contribuir).

Invocación de guix refresh
==========================

La principal audiencia de guix refresh son desarrolladoras de la distribución de software GNU. Por defecto, informa de cualquier paquete proporcionado por la distribución que esté anticuado comparado con la última versión oficial, de esta manera:

     $ guix refresh
     gnu/packages/gettext.scm:29:13: gettext would be upgraded from 0.18.1.1 to 0.18.2.1
     gnu/packages/glib.scm:77:12: glib would be upgraded from 2.34.3 to 2.37.0

De manera alternativa, se pueden especificar los paquetes a considerar, en cuyo caso se emite un aviso para paquetes que carezcan de actualizador:

     $ guix refresh coreutils guile guile-ssh
     gnu/packages/ssh.scm:205:2: warning: no updater for guile-ssh
     gnu/packages/guile.scm:136:12: guile would be upgraded from 2.0.12 to 2.0.13

guix refresh navega por los repositorios oficiales de cada paquete y determina el número de versión mayor entre las publicaciones encontradas. La orden sabe cómo actualizar tipos específicos de paquetes: paquetes GNU, paquetes ELPA, etc.---vea la documentación de --type más adelante. Hay muchos paquetes, no obstante, para los que carece de un método para determinar si está disponible una versión oficial posterior. No obstante, el mecanismo es extensible, ¡no tenga problema en contactarnos para añadir un método nuevo!

--recursive
     Consider the packages specified, and all the packages upon which they depend.

          $ guix refresh --recursive coreutils
          gnu/packages/acl.scm:35:2: warning: no updater for acl
          gnu/packages/m4.scm:30:12: info: 1.4.18 is already the latest version of m4
          gnu/packages/xml.scm:68:2: warning: no updater for expat
          gnu/packages/multiprecision.scm:40:12: info: 6.1.2 is already the latest version of gmp
          ...

A veces el nombre oficial es diferente al nombre de paquete usado en Guix, y guix refresh necesita un poco de ayuda. La mayor parte de los actualizadores utilizan la propiedad upstream-name en las definiciones de paquetes, que puede usarse para obtener dicho efecto:

     (define-public network-manager
       (package
         (name "network-manager")
         ;; ...
         (properties '((upstream-name . "NetworkManager")))))

Cuando se proporciona --update, modifica los ficheros de fuentes de la distribución para actualizar los números de versión y hash de los archivadores tar de fuentes en las recetas de los paquetes (see Definición de paquetes). Esto se consigue con la descarga del último archivador de fuentes del paquete y su firma OpenPGP asociada, seguida de la verificación del archivador descargado y su firma mediante el uso de gpg, y finalmente con el cálculo de su hash. Cuando la clave pública usada para firmar el archivador no se encuentra en el anillo de claves de la usuaria, se intenta automáticamente su obtención desde un servidor de claves públicas; cuando se encuentra, la clave se añade al anillo de claves de la usuaria; en otro caso, guix refresh informa de un error.

Se aceptan las siguientes opciones:

--expression=EXPR
-e EXPR
     Considera el paquete al que evalúa EXPR

     Es útil para hacer una referencia precisa de un paquete concreto, como en este ejemplo:

          guix refresh -l -e '(@@ (gnu packages commencement) glibc-final)'

     Esta orden enumera los paquetes que dependen de la libc ``final'' (esencialmente todos los paquetes).

--update
-u
     Actualiza los ficheros fuente de la distribución (recetas de paquetes) en su lugar. Esto se ejecuta habitualmente desde una copia de trabajo del árbol de fuentes de Guix (see Ejecución de Guix antes de estar instalado):

          $ ./pre-inst-env guix refresh -s non-core -u

     See Definición de paquetes, para más información sobre la definición de paquetes.

--select=[SUBCONJUNTO]
-s SUBCONJUNTO
     Selecciona todos los paquetes en SUBCONJUNTO, o bien core o bien non-core.

     El subconjunto core hace referencia a todos los paquetes en el núcleo de la distribución---es decir, paquetes que se usan para construir ``todo lo demás''. Esto incluye GCC, libc, Binutils, Bash, etc. Habitualmente, cambiar uno de esos paquetes en la distribución conlleva la reconstrucción de todos los demás. Por tanto, esas actualizaciones son una inconveniencia para las usuarias en términos de tiempo de construcción o ancho de banda usado por la actualización.

     El subconjunto non-core hace referencia a los paquetes restantes. Es típicamente útil en casos donde una actualización de paquetes básicos no sería conveniente.

--manifest=FICHERO
-m FICHERO
     Selecciona todos los paquetes del manifiesto en FICHERO. Es útil para comprobar si algún paquete del manifiesto puede actualizarse.

--type=ACTUALIZADOR
-t ACTUALIZADOR
     Selecciona únicamente paquetes manejados por ACTUALIZADOR (puede ser una lista separada por comas de actualizadores). Actualmente, ACTUALIZADOR puede ser:

     gnu
          el actualizador de paquetes GNU;

     gnome
          el actualizador para paquetes GNOME;

     kde
          el actualizador para paquetes KDE;

     xorg
          el actualizador para paquetes X.org;

     kernel.org
          el actualizador para paquetes alojados en kernel.org;

     elpa
          el actualizador para paquetes ELPA (http://elpa.gnu.org/);

     cran
          el actualizador para paquetes CRAN (https://cran.r-project.org/);

     bioconductor
          el actualizador para paquetes R Bioconductor (https://www.bioconductor.org/);

     cpan
          el actualizador para paquetes CPAN (http://www.cpan.org/);

     pypi
          el actualizador para paquetes PyPI (https://pypi.python.org).

     gem
          el actualizador para paquetes RubyGems (https://rubygems.org).

     github
          el actualizador para paquetes GitHub (https://github.com).

     hackage
          el actualizador para paquetes Hackage (https://hackage.haskell.org).

     stackage
          el actualizador para paquetes Stackage (https://www.stackage.org).

     crate
          el actualizador para paquetes Crates (https://crates.io).

     launchpad
          el actualizador para paquetes Launchpad (https://launchpad.net).

     Por ejemplo, la siguiente orden únicamente comprueba actualizaciones de paquetes Emacs alojados en elpa.gnu.org y actualizaciones de paquetes CRAN:

          $ guix refresh --type=elpa,cran
          gnu/packages/statistics.scm:819:13: r-testthat would be upgraded from 0.10.0 to 0.11.0
          gnu/packages/emacs.scm:856:13: emacs-auctex would be upgraded from 11.88.6 to 11.88.9

Además, guix refresh puede recibir uno o más nombres de paquetes, como en este ejemplo:

     $ ./pre-inst-env guix refresh -u emacs idutils gcc@4.8

La orden previa actualiza específicamente los paquetes emacs y idutils. La opción --select no tendría efecto en este caso.

Cuando se considera la actualización de un paquete, a veces es conveniente conocer cuantos paquetes se verían afectados por la actualización y su compatibilidad debería comprobarse. Para ello la siguiente opción puede usarse cuando se proporcionan uno o más nombres de paquete a guix refresh:

--list-updaters
-L
     Enumera los actualizadores disponibles y finaliza (vea la opción previa --type).

     Para cada actualizador, muestra la fracción de paquetes que cubre; al final muestra la fracción de paquetes cubiertos por todos estos actualizadores.

--list-dependent
-l
     Enumera los paquetes de nivel superior dependientes que necesitarían una reconstrucción como resultado de la actualización de uno o más paquetes.

     See el tipo reverse-package de guix graph, para información sobre cómo visualizar la lista de paquetes que dependen de un paquete.

Sea consciente de que la opción --list-dependent únicamente aproxima las reconstrucciones necesarias como resultado de una actualización. Más reconstrucciones pueden ser necesarias bajo algunas circunstancias.

     $ guix refresh --list-dependent flex
     Building the following 120 packages would ensure 213 dependent packages are rebuilt:
     hop@2.4.0 geiser@0.4 notmuch@0.18 mu@0.9.9.5 cflow@1.4 idutils@4.6 ...

La orden previa enumera un conjunto de paquetes que puede ser construido para comprobar la compatibilidad con una versión actualizada del paquete flex.

--list-transitive
     Enumera todos los paquetes de los que uno o más paquetes dependen.

          $ guix refresh --list-transitive flex
          flex@2.6.4 depends on the following 25 packages: perl@5.28.0 help2man@1.47.6
          bison@3.0.5 indent@2.2.10 tar@1.30 gzip@1.9 bzip2@1.0.6 xz@5.2.4 file@5.33 ...

La orden previa enumera un conjunto de paquetes que, en caso de cambiar, causarían la reconstrucción de flex.

Las siguientes opciones pueden usarse para personalizar la operación de GnuPG:

--gpg=ORDEN
     Use ORDEN como la orden de GnuPG 2.x. Se busca ORDEN en PATH.

--keyring=FICHERO
     Usa FICHERO como el anillo de claves para claves de proveedoras. FICHERO debe estar en el formato keybox. Los ficheros Keybox normalmente tienen un nombre terminado en .kbx y GNU Privacy Guard (GPG) puede manipular estos ficheros (see kbxutil (Using the GNU Privacy Guard), para información sobre una herramienta para manipular ficheros keybox).

     Cuando se omite esta opción, guix refresh usa ~/.config/guix/upstream/trustedkeys.kbx como el anillo de claves para las firmas de proveedoras. Las firmas OpenPGP son comprobadas contra claves de este anillo; las claves que falten son descargadas a este anillo de claves también (véase --key-download a continuación).

     Puede exportar claves de su anillo de claves GPG predeterminado en un fichero keybox usando órdenes como esta:

          gpg --export rms@gnu.org | kbxutil --import-openpgp >> mianillo.kbx

     Del mismo modo, puede obtener claves de un archivo keybox específico así:

          gpg --no-default-keyring --keyring mianillo.kbx \
            --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5

     --keyring (Using the GNU Privacy Guard), para más información sobre la opción --keyring de GPG.

--key-download=POLÍTICA
     Maneja las claves no encontradas de acuerdo a la POLÍTICA, que puede ser una de:

     always
          Siempre descarga las claves OpenPGP no encontradas del servidor de claves, y las añade al anillo de claves GnuPG de la usuaria.

     never
          Nunca intenta descargar claves OpenPGP no encontradas. Simplemente propaga el error.

     interactive
          Cuando se encuentra un paquete firmado por una clave OpenPGP desconocida, pregunta a la usuaria si descargarla o no. Este es el comportamiento predeterminado.

--key-server=DIRECCIÓN
     Use DIRECCIÓN como el servidor de claves OpenPGP cuando se importa una clave pública.

The github updater uses the GitHub API (https://developer.github.com/v3/) to query for new releases.  When used repeatedly e.g. when refreshing all packages, GitHub will eventually refuse to answer any further API requests.  By default 60 API requests per hour are allowed, and a full refresh on all GitHub packages in Guix requires more than this. Authentication with GitHub through the use of an API token alleviates these limits.  To use an API token, set the environment variable GUIX_GITHUB_TOKEN to a token procured from https://github.com/settings/tokens or otherwise.

Invocación de guix lint
=======================

La orden guix lint sirve para ayudar a las desarrolladoras de paquetes a evitar errores comunes y usar un estilo consistente. Ejecuta un número de comprobaciones en un conjunto de paquetes proporcionado para encontrar errores comunes en sus definiciones. Los comprobadores disponibles incluyen (véase --list-checkers para una lista completa):

synopsis
description
     Valida ciertas reglas tipográficas y de estilo en la descripción y sinopsis de cada paquete.

inputs-should-be-native
     Identifica entradas que probablemente deberían ser entradas nativas.

source
home-page
mirror-url
github-url
source-file-name
     Comprueba las URL home-page y source e informa aquellas que no sean válidas. Sugiere una URL mirror:// cuando sea aplicable. Si la URL source redirecciona a una URL GitHub, recomienda el uso de la URL GitHub. Comprueba que el nombre de fichero de las fuentes es significativo, por ejemplo que no es simplemente un número de versión o revisión git, sin un nombre file-name declarado (see Referencia de ``origin'').

source-unstable-tarball
     Parse the source URL to determine if a tarball from GitHub is autogenerated or if it is a release tarball.  Unfortunately GitHub's autogenerated tarballs are sometimes regenerated.

cve
     Informa de vulnerabilidades encontradas en las bases de datos de vulnerabilidades y exposiciones comunes (CVE) del año actual y el pasado publicadas por el NIST de EEUU (https://nvd.nist.gov/download.cfm#CVE_FEED).

     Para ver información acerca de una vulnerabilidad particular, visite páginas como:

       * https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-YYYY-ABCD

       * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-YYYY-ABCD

     donde CVE-YYYY-ABCD es el identificador CVE---por ejemplo, CVE-2015-7554.

     Las desarrolladoras de paquetes pueden especificar en las recetas del paquete el nombre y versión en la plataforma común de enumeración (CPE) (https://nvd.nist.gov/cpe.cfm) del paquete cuando difieren del nombre o versión que usa Guix, como en este ejemplo:

          (package
            (name "grub")
            ;; ...
            ;; CPE llama a este paquete "grub2".
            (properties '((cpe-name . "grub2")
                          (cpe-version . "2.3")))

     Algunas entradas en la base de datos CVE no especifican a qué versión del paquete hacen referencia, y por lo tanto ``permanecen visibles'' para siempre. Las desarrolladoras de paquetes que encuentren alertas CVE y verifiquen que pueden ignorarse, pueden declararlas como en este ejemplo:

          (package
            (name "t1lib")
            ;; ...
            ;; Estas alertas de CVE no aplican y pueden ignorarse
            ;; con seguridad.
            (properties `((lint-hidden-cve . ("CVE-2011-0433"
                                              "CVE-2011-1553"
                                              "CVE-2011-1554"
                                              "CVE-2011-5244")))))

formatting
     Avisa de problemas de formato obvios en el código fuente: espacios en blanco al final de las líneas, uso de tabuladores, etc.

La sintaxis general es:

     guix lint OPCIONES PAQUETE...

Si no se proporciona ningún paquete en la linea de órdenes, todos los paquetes se comprueban. Las OPCIONES pueden ser cero o más de las siguientes:

--list-checkers
-l
     Enumera y describe todos los comprobadores disponibles que se ejecutarán sobre los paquetes y finaliza.

--checkers
-c
     Habilita únicamente los comprobadores especificados en una lista separada por comas que use los nombres devueltos por --list-checkers.

Invocación de guix size
=======================

La orden guix size ayuda a las desarrolladoras de paquetes a perfilar el uso de disco de los paquetes. Es fácil pasar por encima el impacto que produce añadir una dependencia adicional a un paquete, o el impacto del uso de una salida única para un paquete que puede ser dividido fácilmente (see Paquetes con múltiples salidas). Estos son los problemas típicos que guix size puede resaltar.

Se le pueden proporcionar una o más especificaciones de paquete como gcc@4.8 o guile:debug, o un nombre de fichero en el almacén. Considere este ejemplo:

     $ guix size coreutils
     store item                               total    self
     /gnu/store/...-gcc-5.5.0-lib           60.4    30.1  38.1%
     /gnu/store/...-glibc-2.27              30.3    28.8  36.6%
     /gnu/store/...-coreutils-8.28          78.9    15.0  19.0%
     /gnu/store/...-gmp-6.1.2               63.1     2.7   3.4%
     /gnu/store/...-bash-static-4.4.12       1.5     1.5   1.9%
     /gnu/store/...-acl-2.2.52              61.1     0.4   0.5%
     /gnu/store/...-attr-2.4.47             60.6     0.2   0.3%
     /gnu/store/...-libcap-2.25             60.5     0.2   0.2%
     total: 78.9 MiB

Los elementos del almacén enumerados aquí constituyen la clausura transitiva de Coreutils---es decir, Coreutils y todas sus dependencias, recursivamente---como sería devuelto por:

     $ guix gc -R /gnu/store/...-coreutils-8.23

Aquí la salida muestra tres columnas junto a los elementos del almacén. La primera columna, etiquetada ``total'', muestra el tamaño en mebibytes (MiB) de la clausura del elemento del almacén---es decir, su propio tamaño sumado al tamaño de todas sus dependencias. La siguiente columna, etiquetada ``self'', muestra el tamaño del elemento en sí. La última columna muestra la relación entre el tamaño del elemento en sí frente al espacio ocupado por todos los elementos enumerados.

En este ejemplo, vemos que la clausura de Coreutils ocupa 79 MiB, cuya mayor parte son libc y las bibliotecas auxiliares de GCC para tiempo de ejecución. (Que libc y las bibliotecas de GCC representen una fracción grande de la clausura no es un problema en sí, puesto que siempre están disponibles en el sistema de todas maneras).

Cuando los paquetes pasados a guix size están disponibles en el almacén (Más precisamente, guix size busca la variante sin injertos de los paquetes, como el devuelto por guix build PAQUETE --no-grafts. See Actualizaciones de seguridad, para información sobre injertos.) consultando al daemon para determinar sus dependencias, y mide su tamaño en el almacén, de forma similar a du -ms --apparent-size (see du invocation (GNU Coreutils)).

Cuando los paquetes proporcionados no están en el almacén, guix size informa en base de las sustituciones disponibles (see Sustituciones). Esto hace posible perfilar el espacio en disco incluso de elementos del almacén que no están en el disco, únicamente disponibles de forma remota.

Puede especificar también varios nombres de paquetes:

     $ guix size coreutils grep sed bash
     store item                               total    self
     /gnu/store/...-coreutils-8.24          77.8    13.8  13.4%
     /gnu/store/...-grep-2.22               73.1     0.8   0.8%
     /gnu/store/...-bash-4.3.42             72.3     4.7   4.6%
     /gnu/store/...-readline-6.3            67.6     1.2   1.2%
     ...
     total: 102.3 MiB

En este ejemplo vemos que la combinación de los cuatro paquetes toma 102.3 MiB en total, lo cual es mucho menos que la suma de cada clausura, ya que tienen muchas dependencias en común.

Las opciones disponibles son:

--substitute-urls=URLS
     Usa la información de sustituciones de URLS. See la misma opción en guix build.

--sort=CLAVE
     Ordena las líneas de acuerdo a CLAVE, una de las siguientes opciones:

     self
          el tamaño de cada elemento (predeterminada);

     clausura
          el tamaño total de la clausura del elemento.

--map-file=FICHERO
     Escribe un mapa gráfico del uso del disco en formato PNG en el FICHERO.

     Para el ejemplo previo, el mapa tiene esta pinta:

     mapa del uso del disco de Coreutils producido por guix size

     Esta opción necesita que la biblioteca Guile-Charting (http://wingolog.org/software/guile-charting/) esté instalada y visible en la ruta de búsqueda de módulos Guile. Cuando no es el caso, guix size produce un error al intentar cargarla.

--system=SISTEMA
-s SISTEMA
     Considera paquetes para SISTEMA---por ejemplo, x86_64-linux.

Invocación de guix graph
========================

Los paquetes y sus dependencias forman un grafo, específicamente un grafo acíclico dirigido (GAD, DAG en Inglés). Puede hacerse difícil rápidamente tener un modelo mental del GAD del paquete, por lo que la orden guix graph proporciona una representación virtual del GAD. Por defecto, guix graph emite una representación en GAD en el formato de entrada de Graphviz (http://graphviz.org/), por lo que su salida puede ser pasada directamente a la herramienta dot de Graphviz. También puede emitir una página HTMP con código JavaScript embebido para mostrar un ``diagrama de acorde'' en un navegador Web, usando la biblioteca d3.js (https://d3js.org/), o emitir consultas Cypher para construir un grafo en una base de datos de grafos que acepte el lenguaje de consultas openCypher (http://www.opencypher.org/). La sintaxis general es:

     guix graph OPCIONES PAQUETE...

Por ejemplo, la siguiente orden genera un fichero PDF que representa el GAD para GNU Core Utilities, mostrando sus dependencias en tiempo de construcción:

     guix graph coreutils | dot -Tpdf > gad.pdf

La salida es algo así:

Grafo de dependencias de GNU Coreutils

Bonito y pequeño grafo, ¿no?

¡Pero hay más de un grafo! El grafo previo es conciso: es el grafo de los objetos package, omitiendo las entradas implícitas como GCC, libc, grep, etc. Es habitualmente útil tener un grafo conciso así, pero a veces una puede querer ver más detalles. guix graph implementa varios tipos de grafos, permitiendole seleccionar el nivel de detalle:

package
     Este es el tipo por defecto usado en el ejemplo previo. Muestra el GAD de objetos package, excluyendo dependencias implícitas. Es conciso, pero deja fuera muchos detalles.

reverse-package
     Esto muestra el GAD inverso de paquetes. Por ejemplo:

          guix graph --type=reverse-package ocaml

     ... yields the graph of packages that explicitly depend on OCaml (if you are also interested in cases where OCaml is an implicit dependency, see reverse-bag below.)

     Fíjese que esto puede producir grafos inmensos para los paquetes básicos. Si todo lo que quiere saber es el número de paquetes que dependen de uno determinado, use guix refresh --list-dependent (see --list-dependent).

bag-emerged
     Este es el GAD del paquete, incluyendo entradas implícitas.

     Por ejemplo, la siguiente orden:

          guix graph --type=bag-emerged coreutils | dot -Tpdf > gad.pdf

     ... emite este grafo más grande:

     Grafo de dependencias detallado de GNU Coreutils

     En la parte inferior del grafo, vemos todas las entradas implícitas de GNU-BUILD-SYSTEM (see gnu-build-system).

     Ahora bien, fijese que las dependencias de estas entradas implícitas---es decir, las dependencias del lanzamiento inicial (see Lanzamiento inicial)---no se muestran aquí para mantener una salida concisa.

bag
     Similar a bag-emerged, pero esta vez incluye todas las dependencias del lanzamiento inicial.

bag-with-origins
     Similar a bag, pero también muestra los orígenes y sus dependencias.

reverse-bag
     This shows the reverse DAG of packages.  Unlike reverse-package, it also takes implicit dependencies into account. For example:

          guix graph -t reverse-bag dune

     ... yields the graph of all packages that depend on Dune, directly or indirectly.  Since Dune is an implicit dependency of many packages via dune-build-system, this shows a large number of packages, whereas reverse-package would show very few if any.

derivación
     Esta es la representación más detallada: muestra el GAD de derivaciones (see Derivaciones) y elementos simples del almacén. Comparada con las representaciones previas, muchos nodos adicionales son visibles, incluyendo los guiones de construcción, parches, módulos Guile, etc.

     Para este tipo de grafo, también es posible pasar un nombre de fichero .drv en vez del nombre del paquete, como en:

          guix graph -t derivation `guix system build -d mi-configuracion.scm`

module
     Este es el grafo de los módulos de paquete (see Módulos de paquetes). Por ejemplo, la siguiente orden muestra el grafo para el módulo de paquetes que define el paquete guile:

          guix graph -t module guile | dot -Tpdf > grafo-del-modulo.pdf

Todos los tipos previos corresponden a las dependencias durante la construcción. El grafo siguiente representa las dependencias en tiempo de ejecución:

references
     Este es el grafo de referencias de la salida de un paquete, como lo devuelve guix gc --references (see Invocación de guix gc).

     Si la salida del paquete proporcionado no está disponible en el almacén, guix graph intenta obtener la información de dependencias desde las sustituciones.

     Aquí también puede proporcionar un nombre de fichero del almacén en vez de un nombre de paquete. Por ejemplo, la siguiente orden produce el grafo de referencias de su perfil (¡el cuál puede ser grande!):

          guix graph -t references `readlink -f ~/.guix-profile`

referrers
     Este es el grafo de referentes de la salida de un paquete, como lo devuelve guix gc --referrers (see Invocación de guix gc).

     Depende exclusivamente de información en su almacén. Por ejemplo, supongamos que la versión actual de Inkscape está disponible en 10 perfiles en su máquina; guix graph -t referrers inkscape mostrará un grafo cuya raíz es Inkscape y con esos 10 perfiles enlazados a ella.

     Puede ayudar a determinar qué impide que un elemento del almacén sea recolectado.

Las opciones disponibles son las siguientes:

--type=TIPO
-t TIPO
     Produce un grafo de salida de TIPO, donde TIPO debe ser uno de los valores enumerados previamente.

--list-types
     Enumera los tipos de grafos implementados.

--backend=MOTOR
-b MOTOR
     Produce un grafo usando el MOTOR seleccionado.

--list-backends
     Enumera los motores de grafos implementados.

     Actualmente, los motores disponibles son Graphviz y d3.js.

--expression=EXPR
-e EXPR
     Considera el paquete al que evalúa EXPR

     Es útil para hacer una referencia precisa de un paquete concreto, como en este ejemplo:

          guix graph -e '(@@ (gnu packages commencement) gnu-make-final)'

--system=SISTEMA
-s SISTEMA
     Muestra el grafo para SISTEMA---por ejemplo, i686-linux.

     El grafo de dependencias del paquete es altamente independiente de la arquitectura, pero existen algunas partes dependientes de la arquitectura que esta opción le permite visualizar.

Invocación de guix publish
==========================

El propósito de guix publish es permitir a las usuarias compartir fácilmente su almacén con otras, quienes pueden usarlo como servidor de sustituciones (see Sustituciones).

Cuando guix publish se ejecuta, lanza un servidor HTTP que permite a cualquiera que tenga acceso a través de la red obtener sustituciones de él. Esto significa que cualquier máquina que ejecute Guix puede actuar como si fuese una granja de construcción, ya que la interfaz HTTP es compatible con Hydra, el software detrás de la granja de construcción ci.guix.es.info.

Por seguridad, cada sustitución se firma, permitiendo a las receptoras comprobar su autenticidad e integridad (see Sustituciones). Debido a que guix publish usa la clave de firma del sistema, que es únicamente legible por la administradora del sistema, debe iniciarse como root; la opción --user hace que renuncie a sus privilegios tan pronto como sea posible.

El par claves de firma debe generarse antes de ejecutar guix publish, usando guix archive --generate-key (see Invocación de guix archive).

La sintaxis general es:

     guix publish OPCIONES...

La ejecución de guix publish sin ningún parámetro adicional lanzará un servidor HTTP en el puerto 8080:

     guix publish

Una vez el servidor de publicación ha sido autorizado (see Invocación de guix archive), el daemon puede descargar sustituciones de él:

     guix-daemon --substitute-urls=http://example.org:8080

Por defecto, guix publish comprime los archivos al vuelo cuando es necesario. Este modo ``al vuelo'' es conveniente ya que no necesita configuración y está disponible inmediatamente. No obstante, cuando se proporciona servicio a muchos clientes, se recomienda usar la opción --cache, que habilita el almacenamiento en caché de los archivos antes de enviarlos a los clientes---véase a continuación para más detalles. La orden guix weather proporciona una forma fácil de comprobar lo que proporciona un servidor (see Invocación de guix weather).

Además guix publish también sirve como un espejo de acceso por contenido a ficheros de fuentes a los que los registros origin hacen referencia (see Referencia de ``origin''). Por ejemplo, si asumimos que guix publish se ejecuta en example.org, la siguiente URL devuelve directamente el fichero hello-2.10.tar.gz con el hash SHA256 proporcionado (representado en formato nix-base32, see Invocación de guix hash).

     http://example.org/file/hello-2.10.tar.gz/sha256/0ssi1...ndq1i

Obviamente estas URL funcionan solamente para ficheros que se encuentran en el almacén; en otros casos devuelven un 404 (``No encontrado'').

Los log de construcción están disponibles desde URL /log como:

     http://example.org/log/gwspk...-guile-2.2.3

Cuando guix-daemon está configurado para almacenar comprimidos los log de construcción, como sucede de forma predeterminada (see Invocación de guix-daemon), las URL /log devuelven los log igualmente comprimidos, con un Content-Type adecuado y/o una cabecera Content-Encoding. Recomendamos ejecutar guix-daemon con --log-compression=gzip ya que los navegadores Web pueden extraer el contenido automáticamente, lo cual no es el caso con la compresión bzip2.

Las siguientes opciones están disponibles:

--port=PUERTO
-p PUERTO
     Escucha peticiones HTTP en PUERTO.

--listen=DIRECCIÓN
     Escucha en la interfaz de red de la DIRECCIÓN. El comportamiento predeterminado es aceptar conexiones de cualquier interfaz.

--user=USUARIA
-u USUARIA
     Cambia los privilegios a los de USUARIA tan pronto como sea posible---es decir, una vez el socket del servidor esté abierto y la clave de firma haya sido leída.

--compression[=NIVEL]
-C [NIVEL]
     Comprime los datos con el NIVEL dado. Cuando el NIVEL es cero, deshabilita la compresión. El rango 1 a 9 corresponde a distintos niveles de compresión gzip: 1 es el más rápido, y 9 es el mejor (intensivo a nivel de CPU). El valor predeterminado es 3.

     A menos que se use --cache, la compresión ocurre al vuelo y los flujos comprimidos no se almacenan en caché. Por tanto, para reducir la carga en la máquina que ejecuta guix publish, puede ser una buena idea elegir un nivel de compresión bajo, ejecutar guix publish detrás de un proxy con caché o usar --cache. El uso de --cache tiene la ventaja de que permite a guix publish añadir la cabecera HTTP Content-Length a sus respuestas.

--cache=DIRECTORIO
-c DIRECTORIO
     Almacena en caché los archivos y metadatos (URL .narinfo) en DIRECTORIO y únicamente proporciona archivos que están en la caché.

     Cuando se omite esta opción, los archivos y metadatos se crean al vuelo. Esto puede reducir el ancho de banda disponible, especialmente cuando la compresión está habilitada, ya que se puede llegar al límite de la CPU. Otra desventaja del modo predeterminado es que la longitud de los archivos no se conoce con anterioridad, por lo que guix publish no puede añadir la cabecera HTTP Content-Length a sus respuestas, lo que a su vez previene que los clientes conozcan la cantidad de datos a descargar.

     De manera contraria, cuando se usa --cache, la primera petición de un elemento del almacén (a través de una URL .narinfo) devuelve 404 e inicia un proceso en segundo plano para cocinar el archivo---calcular su .narinfo y comprimirlo, en caso necesario. Una vez el archivo está alojado en la caché de DIRECTORIO, las siguientes peticiones obtendrán un resultado satisfactorio y se ofrecerá el contenido directamente desde la caché, lo que garantiza que los clientes obtienen el mejor ancho de banda posible.

     El proceso de ``cocinado'' se realiza por hilos de trabajo. Por defecto, se crea un hilo por núcleo de la CPU, pero puede ser personalizado. Véase --workers a continuación.

     Cuando se usa --ttl, las entradas en caché se borran automáticamente cuando hayan expirado.

--workers=N
     Cuando se usa --cache, solicita la creación de N hilos de trabajo para ``cocinar'' archivos.

--ttl=TTL
     Produce cabeceras HTTP Cache-Control que anuncian un tiempo-de-vida (TTL) de TTL. TTL debe indicar una duración: 5d significa 5 días, 1m significa un mes, etc.

     Esto permite a la usuaria de Guix mantener información de sustituciones en la caché durante TTL. No obstante, fíjese que guix publish no garantiza en sí que los elementos del almacén que proporciona de hecho permanezcan disponibles hasta que TTL expire.

     Adicionalmente, cuando se usa --cache, las entradas en caché que no hayan sido accedidas en TTL y no tengan un elemento correspondiente en el almacén pueden ser borradas.

--nar-path=RUTA
     Usa RUTA como el prefijo para las URL de los archivos ``nar'' (see archivadores normalizados).

     Por defecto, los archivos nar se proporcionan en una URL como /nar/gzip/...-coreutils-8.25. Esta opción le permite cambiar la parte /nar por RUTA.

--public-key=FICHERO
--private-key=FICHERO
     Usa los FICHEROs específicos como el par de claves pública y privada usadas para firmar los elementos del almacén publicados.

     Los ficheros deben corresponder al mismo par de claves (la clave privada se usa para la firma y la clave pública simplemente se anuncia en los metadatos de la firma). Deben contener claves en el formato canónico de expresiones-S como el producido por guix archive --generate-key (see Invocación de guix archive). Por defecto, se usan /etc/guix/signing-key.pub y /etc/guix/signing-key.sec.

--repl[=PUERTO]
-r [PUERTO]
     Lanza un servidor REPL Guile (see REPL Servers (GNU Guile Reference Manual)) en PUERTO (37146 por defecto). Esto se usa principalmente para la depuración de un servidor guix publish en ejecución.

Habilitar guix publish en el sistema Guix consiste en solo una línea: simplemente instancie un servicio guix-publish-service-type en el campo services de su declaración del sistema operativo operating-system (see guix-publish-service-type)

Si en vez de eso ejecuta Guix en una distribución distinta, siga estas instrucciones:

  * Si su distribución anfitriona usa el sistema de inicio systemd:

          # ln -s ~root/.guix-profile/lib/systemd/system/guix-publish.service \
                  /etc/systemd/system/
          # systemctl start guix-publish && systemctl enable guix-publish

  * Si su distribución anfitriona usa el sistema de inicio Upstart:

          # ln -s ~root/.guix-profile/lib/upstart/system/guix-publish.conf /etc/init/
          # start guix-publish

  * En otro caso, proceda de forma similar con el sistema de inicio de su distribución.

Invocación de guix challenge
============================

¿Los binarios que proporciona este servidor realmente corresponden al código fuente que dice construir? ¿Es determinista el proceso de construcción de un paquete? Estas son las preguntas que la orden guix challenge intenta responder.

La primera es obviamente una cuestión importante: antes de usar un servidor de sustituciones (see Sustituciones), es importante haber verificado que proporciona los binarios correctos, y por tanto ponerlo a prueba (NdT: challenge en inglés.). La segunda es lo que permite la primera: si las construcciones de los paquetes son deterministas, construcciones independientes deberían emitir el mismo resultado, bit a bit; si el servidor proporciona un binario diferente al obtenido localmente, o bien está corrupto o bien tiene intenciones perniciosas.

Sabemos que el hash que se muestra en los nombres de fichero en /gnu/store es el hash de todas las entradas del proceso que construyó el fichero o directorio---compiladores, bibliotecas, guiones de construcción, etc. (see Introducción). Asumiendo procesos de construcción deterministas, un nombre de fichero del almacén debe corresponder exactamente a una salida de construcción. guix challenge comprueba si existe, realmente, una asociación unívoca comparando la salida de la construcción de varias construcciones independientes de cualquier elemento del almacén proporcionado.

La salida de la orden muestra algo así:

     $ guix challenge --substitute-urls="https://ci.guix.es.info https://guix.example.org"
     updating list of substitutes from 'https://ci.guix.es.info'... 100.0%
     updating list of substitutes from 'https://guix.example.org'... 100.0%
     /gnu/store/...-openssl-1.0.2d contents differ:
       local hash: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q
       https://ci.guix.es.info/nar/...-openssl-1.0.2d: 0725l22r5jnzazaacncwsvp9kgf42266ayyp814v7djxs7nk963q
       https://guix.example.org/nar/...-openssl-1.0.2d: 1zy4fmaaqcnjrzzajkdn3f5gmjk754b43qkq47llbyak9z0qjyim
     /gnu/store/...-git-2.5.0 contents differ:
       local hash: 00p3bmryhjxrhpn2gxs2fy0a15lnip05l97205pgbk5ra395hyha
       https://ci.guix.es.info/nar/...-git-2.5.0: 069nb85bv4d4a6slrwjdy8v1cn4cwspm3kdbmyb81d6zckj3nq9f
       https://guix.example.org/nar/...-git-2.5.0: 0mdqa9w1p6cmli6976v4wi0sw9r4p5prkj7lzfd1877wk11c9c73
     /gnu/store/...-pius-2.1.1 contents differ:
       local hash: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax
       https://ci.guix.es.info/nar/...-pius-2.1.1: 0k4v3m9z1zp8xzzizb7d8kjj72f9172xv078sq4wl73vnq9ig3ax
       https://guix.example.org/nar/...-pius-2.1.1: 1cy25x1a4fzq5rk0pmvc8xhwyffnqz95h2bpvqsz2mpvlbccy0gs

     ...

     6,406 store items were analyzed:
       - 4,749 (74.1%) were identical
       - 525 (8.2%) differed
       - 1,132 (17.7%) were inconclusive

En este ejemplo, guix challenge primero recorre el almacén para determinar el conjunto de derivaciones construidas localmente---en oposición a elementos del almacén que fueron descargados de un servidor de sustituciones---y consulta a todos los servidores de sustituciones. Una vez hecho informa de los elementos del almacén para los cuales los servidores obtuvieron un resultado diferente de el obtenido en la construcción local.

Como un ejemplo, guix.example.org siempre obtiene una respuesta diferente. Por otro modo, ci.guix.es.info coincide con las construcciones locales, excepto en el caso de Git. Esto puede indicar que el proceso de construcción de Git no es determinista, lo que significa que su salida varia en función de varias cosas que Guix no controla completamente, aunque la construcción de paquetes se realice en entornos aislados (see Características). Las fuentes más comunes de indeterminismo incluyen la adición de marcas de tiempo en los resultados de la construcción, la inclusión de números aleatorios y las enumeraciones de directorios ordenadas por número de nodos-i. Véase https://reproducible-builds.org/docs/ para más información.

Para encontrar cuál es el problema con este binario Git, podemos hacer algo parecido a esto (see Invocación de guix archive):

     $ wget -q -O - https://ci.guix.es.info/nar/...-git-2.5.0 \
        | guix archive -x /tmp/git
     $ diff -ur --no-dereference /gnu/store/...-git.2.5.0 /tmp/git

Esta orden muestra la diferencia entre los ficheros resultantes de la construcción local y los ficheros resultantes de la construcción en ci.guix.es.info (see Comparing and Merging Files). La orden diff funciona muy bien en ficheros de texto. Cuando ficheros binarios difieren, una opción mejor es Diffoscope (https://diffoscope.org/), una herramienta que ayuda en la visualización de diferencias en todo tipo de ficheros.

Una vez haya realizado este trabajo, puede determinar si las diferencias son debidas a un procedimiento de construcción no-determinista o a un servidor con intenciones ocultas. Intentamos duramente eliminar las fuentes de indeterminismo en los paquetes para facilitar la verificación de sustituciones, pero por supuesto es un proceso que implica no solo a Guix, sino a una gran parte de la comunidad del software libre. Entre tanto, guix challenge es una herramienta para ayudar a afrontar el problema.

Si esta escribiendo paquetes para Guix, le recomendamos que compruebe si ci.guix.es.info y otros servidores de sustituciones obtienen el mismo resultado de construcción que el obtenido por usted:

     $ guix challenge PAQUETE

donde PAQUETE es una especificación de paquete como guile@2.0 o glibc:debug.

La sintaxis general es:

     guix challenge OPCIONES [PAQUETES...]

Cuando se encuentra una diferencia entre el hash de un elemento construido localmente y el proporcionado por un servidor de sustituciones; o entre las sustituciones proporcionadas por distintos servidores, esto es mostrado como en el ejemplo previo y el valor de salida es 2 (otros valores no-cero de la salida denominan otros tipos de error).

La única opción de importancia es:

--substitute-urls=URLS
     Considera URLS la lista separada por espacios de URL de fuentes de sustituciones con las que realizar la comparación.

--verbose
-v
     Muestra detalles sobre coincidencias (contenidos idénticos) además de información sobre las discrepancias.

Invocación de guix copy
=======================

La orden guix copy copia elementos del almacén de una máquina al de otra a través de una conexión de shell seguro (SSH) (Esta orden únicamente está disponible cuando ha encontrado Guile-SSH. See Requisitos, para detalles.). Por ejemplo, la siguiente orden copia el paquete coreutils, el perfil de la usuaria y todas sus dependencias a DIRECCIÓN, ingresando en el sistema como USUARIA:

     guix copy --to=USUARIA@DIRECCIÓN \
               coreutils `readlink -f ~/.guix-profile`

Si alguno de los elementos del almacén a copiar ya están presentes en DIRECCIÓN, no se envían realmente.

La siguiente orden obtiene libreoffice y gimp de DIRECCIÓN, asumiendo que estén disponibles allí:

     guix copy --from=DIRECCIÓN libreoffice gimp

La conexión SSH se establece usando el cliente Guile-SSH, que es compatible con OpenSSH: tiene en cuenta ~/.ssh/known_hosts y ~/.ssh/config, y usa el agente SSH para la identificación.

La clave usada para firmar los elementos enviados debe estar aceptada por la máquina remota. Del mismo modo, la clave usada por la máquina remota para firmar los elementos recibidos debe estar en /etc/guix/acl de modo que sea aceptada por su propio daemon. See Invocación de guix archive, para más información sobre la verificación de elementos del almacén.

La sintaxis general es:

     guix copy [--to=SPEC|--from=SPEC] ELEMENTOS...

Siempre debe especificar una de las siguientes opciones:

--to=SPEC
--from=SPEC
     Especifica la máquina a la que mandar o desde la que recibir.  SPEC debe ser una especificación SSH como example.org, carlos@example.org, or carlos@example.org:2222.

Los ELEMENTOS pueden ser tanto nombres de paquetes, como gimp, como elementos del almacén, como /gnu/store/...-idutils-4.6.

Cuando se especifica el nombre del paquete a enviar, primero se construye si es necesario, a menos que se use --dry-run. Se aceptan las opciones comunes de construcción (see Opciones comunes de construcción).

Invocación de guix container
============================

     En la versión VERSION, esta herramienta es experimental. La interfaz está sujeta a cambios radicales en el futuro.

El propósito de guix container es la manipulación de procesos en ejecución dentro de entornos aislados, normalmente conocido como un ``contenedor'', típicamente creado por las órdenes guix environment (see Invocación de guix environment) y guix system container (see Invocación de guix system).

La sintaxis general es:

     guix container ACCIÓN OPCIONES...

ACCIÓN especifica la operación a realizar con el contenedor, y OPCINES especifica los parámetros específicos del contexto para la acción.

Las siguientes acciones están disponibles:

exec
     Ejecute una orden en el contexto de un contenedor en ejecución.

     La sintaxis es:

          guix container exec PID PROGRAMA PARÁMETROS...

     PID especifica el ID del proceso del contenedor en ejecución. PROGRAMA especifica el nombre del fichero ejecutable dentro del sistema de ficheros raíz del contenedor. PARÁMETROS son opciones adicionales que se pasarán a PROGRAMA.

     La siguiente orden lanza un shell interactivo de ingreso al sistema dentro de un contenedor del sistema, iniciado por guix system container, y cuyo ID de proceso es 9001:

          guix container exec 9001 /run/current-system/profile/bin/bash --login

     Fíjese que el PID no puede ser el proceso creador del contenedor. Debe ser el PID 1 del contenedor o uno de sus procesos hijos.

Invocación de guix weather
==========================

De manera ocasional tendrá un mal día al no estar las sustituciones disponibles y le toque construir los paquetes a usted misma (see Sustituciones). La orden guix weather informa de la disponibilidad de sustituciones en los servidores especificados de modo que pueda tener una idea sobre cómo será su día hoy. A veces puede ser una información útil como usuaria, pero es principalmente útil para quienes ejecuten guix publish (see Invocación de guix publish).

Esta es una ejecución de ejemplo:

     $ guix weather --substitute-urls=https://guix.example.org
     computing 5,872 package derivations for x86_64-linux...
     looking for 6,128 store items on https://guix.example.org..
     updating list of substitutes from 'https://guix.example.org'... 100.0%
     https://guix.example.org
       43.4% substitutes available (2,658 out of 6,128)
       7,032.5 MiB of nars (compressed)
       19,824.2 MiB on disk (uncompressed)
       0.030 seconds per request (182.9 seconds in total)
       33.5 requests per second

       9.8% (342 out of 3,470) of the missing items are queued
       867 queued builds
           x86_64-linux: 518 (59.7%)
           i686-linux: 221 (25.5%)
           aarch64-linux: 128 (14.8%)
       build rate: 23.41 builds per hour
           x86_64-linux: 11.16 builds per hour
           i686-linux: 6.03 builds per hour
           aarch64-linux: 6.41 builds per hour

As you can see, it reports the fraction of all the packages for which substitutes are available on the server---regardless of whether substitutes are enabled, and regardless of whether this server's signing key is authorized.  It also reports the size of the compressed archives (``nars'') provided by the server, the size the corresponding store items occupy in the store (assuming deduplication is turned off), and the server's throughput. The second part gives continuous integration (CI) statistics, if the server supports it.  In addition, using the --coverage option, guix weather can list ``important'' package substitutes missing on the server (see below).

Para conseguirlo, guix weather consulta los metadatos HTTP(S) (narinfos) de todos los elementos relevantes del almacén. Como guix challenge, ignora las firmas en esas sustituciones, lo cual es inocuo puesto que la orden únicamente obtiene estadísticas y no puede instalar esas sustituciones.

Entre otras cosas, es posible consultar tipos específicos de sistema y conjuntos específicos de paquetes. Las opciones disponibles se enumeran a continuación.

--substitute-urls=URLS
     URLS es la lista separada por espacios de URL de servidores de sustituciones a consultar. Cuando se omite esta opción, el conjunto predeterminado de servidores de sustituciones es el consultado.

--system=SISTEMA
-s SISTEMA
     Consulta sustituciones para SISTEMA---por ejemplo, aarch64-linux. Esta opción se puede repetir, en cuyo caso guix weather consultará las sustituciones para varios tipos de sistema.

--manifest=FICHERO
     En vez de consultar las sustituciones de todos los paquetes, consulta únicamente los especificados en FICHERO. FICHERO debe contener un manifiesto, como el usado en la opción -m de guix package (see Invocación de guix package).

--coverage[=NUMERO]
-c [NUMERO]
     Report on substitute coverage for packages: list packages with at least COUNT dependents (zero by default) for which substitutes are unavailable.  Dependent packages themselves are not listed: if B depends on A and A has no substitutes, only A is listed, even though B usually lacks substitutes as well.  The result looks like this:

          $ guix weather --substitute-urls=https://ci.guix.es.info -c 10
          computing 8,983 package derivations for x86_64-linux...
          looking for 9,343 store items on https://ci.guix.es.info...
          updating substitutes from 'https://ci.guix.es.info'... 100.0%
          https://ci.guix.es.info
            64.7% substitutes available (6,047 out of 9,343)
          ...
          2502 packages are missing from 'https://ci.guix.es.info' for 'x86_64-linux', among which:
              58  kcoreaddons@5.49.0      /gnu/store/...-kcoreaddons-5.49.0
              46  qgpgme@1.11.1           /gnu/store/...-qgpgme-1.11.1
              37  perl-http-cookiejar@0.008  /gnu/store/...-perl-http-cookiejar-0.008
              ...

     What this example shows is that kcoreaddons and presumably the 58 packages that depend on it have no substitutes at ci.guix.es.info; likewise for qgpgme and the 46 packages that depend on it.

     If you are a Guix developer, or if you are taking care of this build farm, you'll probably want to have a closer look at these packages: they may simply fail to build.

Invocación de guix processes
============================

La orden guix processes puede ser útil a desarrolladoras y administradoras de sistemas, especialmente en máquinas multiusuaria y en granjas de construcción: enumera las sesiones actuales (conexiones al daemon), así como información sobre los procesos envueltos (Las sesiones remotas, cuando guix-daemon se ha iniciado con --listen especificando un punto de conexión TCP, no son enumeradas.). A continuación puede verse un ejemplo de la información que devuelve:

     $ sudo guix processes
     SessionPID: 19002
     ClientPID: 19090
     ClientCommand: guix environment --ad-hoc python

     SessionPID: 19402
     ClientPID: 19367
     ClientCommand: guix publish -u guix-publish -p 3000 -C 9 ...

     SessionPID: 19444
     ClientPID: 19419
     ClientCommand: cuirass --cache-directory /var/cache/cuirass ...
     LockHeld: /gnu/store/...-perl-ipc-cmd-0.96.lock
     LockHeld: /gnu/store/...-python-six-bootstrap-1.11.0.lock
     LockHeld: /gnu/store/...-libjpeg-turbo-2.0.0.lock
     ChildProcess: 20495: guix offload x86_64-linux 7200 1 28800
     ChildProcess: 27733: guix offload x86_64-linux 7200 1 28800
     ChildProcess: 27793: guix offload x86_64-linux 7200 1 28800

En este ejemplo vemos que guix-daemon tiene tres clientes: guix environment, guix publish y la herramienta de integración continua Cuirass; sus identificadores de proceso (PID) se muestran en el campo ClientPID. El campo SessionPID proporciona el PID del subproceso de guix-daemon de cada sesión en particular.

El campo LockHeld muestra qué elementos del almacén están bloqueados actualmente por cada sesión, lo que corresponde a elementos del almacén en construcción o sustitución (el campo LockHeld no se muestra cuando guix processes no se ejecutó como root). Por último, mediante el campo ChildProcess entendemos que esas tres construcciones están siendo delegadas (see Configuración de delegación del daemon).

La salida está en formato Recutils por lo que podemos usar la útil orden recsel para seleccionar sesiones de interés (see Selection Expressions (GNU recutils manual)). Como un ejemplo, la siguiente orden muestra la línea de órdenes y el PID del cliente que inició la construcción de un paquete Perl:

     $ sudo guix processes | \
         recsel -p ClientPID,ClientCommand -e 'LockHeld ~ "perl"'
     ClientPID: 19419
     ClientCommand: cuirass --cache-directory /var/cache/cuirass ...

Configuración del sistema
*************************

La Distribución de Sistema Guix permite un mecanismo de configuración del sistema completo consistente. Con esto queremos decir que todos los aspectos de la configuración global del sistema---como los servicios disponibles, la zona horaria y la configuración de localización, las cuentas de usuarias---se declaran en un lugar único. Dicha configuración del sistema puede ser instanciada---es decir, hecha efectiva.

Una de las ventajas de poner toda la configuración del sistema bajo el control de Guix es que permite actualizaciones transaccionales del sistema, y hace posible volver a una instanciación previa del sistema, en caso de que haya algún problema con la nueva (see Características). Otra ventaja es que hace fácil replicar exactamente la misma configuración entre máquinas diferentes, o en diferentes momentos, sin tener que utilizar herramientas de administración adicionales sobre las propias herramientas del sistema.

Esta sección describe este mecanismo. Primero nos enfocaremos en el punto de vista de la administradora del sistema---explicando cómo se configura e instancia el sistema. Después mostraremos cómo puede extenderse este mecanismo, por ejemplo para añadir nuevos servicios del sistema.

Uso de la configuración del sistema
===================================

El sistema operativo se configura proporcionando una declaración operating-system en un fichero que pueda ser proporcionado a la orden guix system (see Invocación de guix system). Una configuración simple, con los servicios predeterminados del sistema, el núcleo Linux-Libre predeterminado, un disco de RAM inicial y un cargador de arranque puede ser como sigue:

          [file os-config-bare-bones.texi not included]

Este ejemplo debería ser auto-descriptivo. Algunos de los campos definidos anteriormente, como host-name y bootloader, son necesarios. Otros como packages y services, pueden omitirse, en cuyo caso obtienen un valor por defecto.

Más adelante se muestran los efectos de algunos de los campos más importantes (see Referencia de ``operating-system'', para detalles acerca de todos los campos disponibles), y cómo instanciar el sistema operativo usando guix system.

Cargador de arranque
--------------------

El campo bootloader describe el método que será usado para arrancar su sistema. Las máquinas basadas en procesadores Intel pueden arrancar en el ``obsoleto'' modo BIOS, como en el ejemplo previo. No obstante, máquinas más recientes usan la Interfaz Unificada Extensible de Firmware (UEFI) para arrancar. En ese caso, el capo bootloader debe contener algo parecido a esto:

     (bootloader-configuration
       (bootloader grub-efi-bootloader)
       (target "/boot/efi"))

See Configuración del gestor de arranque, para más información sobre las opciones de configuración disponibles.

Paquetes visibles globalmente
-----------------------------

El campo packages enumera los paquetes que serán visibles globalmente en el sistema, para todas las cuentas de usuaria---es decir, en la variable de entorno PATH de cada usuaria---además de los perfiles por usuaria (see Invocación de guix package). La variable %BASE-PACKAGES proporciona todas las herramientas esperadas para tareas básicas y de administración---incluyendo las utilidades básicas GNU, las herramientas de red GNU, el editor de texto ligero GNU Zile, find, grep, etc. El ejemplo previo se añade GNU Screen a estos, tomado del módulo (gnu packages screen) (see Módulos de paquetes). La sintaxis (list package output) puede usarse para añadir una salida específica de un paquete:

     (use-modules (gnu packages))
     (use-modules (gnu packages dns))

     (operating-system
       ;; ...
       (packages (cons (list bind "utils")
                       %base-packages)))

Referirse a los paquetes por nombre de variable, como antes a bind, tiene la ventaja de evitar ambigüedades; también permite que errores tipográficos y demás obtengan un diagnóstico directo como ``variables sin definir''. La parte problemática es que se necesita conocer qué módulo define qué paquete, y aumentar adecuadamente la línea de use-package-modules. Para evitar esto, se puede usar el procedimiento specification->package del módulo (gnu packages), que devuelve el mejor paquete para un nombre dado, o nombre y versión:

     (use-modules (gnu packages))

     (operating-system
       ;; ...
       (packages (append (map specification->package
                              '("tcpdump" "htop" "gnupg@2.0"))
                         %base-packages)))

Servicios del sistema
---------------------

The services field lists system services to be made available when the system starts (see Servicios).  The operating-system declaration above specifies that, in addition to the basic services, we want the OpenSSH secure shell daemon listening on port 2222 (see openssh-service-type).  Under the hood, openssh-service-type arranges so that sshd is started with the right command-line options, possibly with supporting configuration files generated as needed (see Definición de servicios).

De manera ocasional, en vez de usar los servicios básicos tal y como vienen, puede querer personalizarlos. Para hacerlo, use modify-services (see modify-services) para modificar la lista.

Por ejemplo, supongamos que quiere modificar guix-daemon y Mingetty (el punto de acceso al sistema por consola) en la lista %BASE-SERVICES (see %base-services). Para hacerlo, puede escribir lo siguiente en su declaración de sistema operativo:

     (define %mis-servicios
       ;; Mi propia lista de servicios
       (modify-services %base-services
         (guix-service-type config =>
                            (guix-configuration
                             (inherit config)
                             (use-substitutes? #f)
                             (extra-options '("--gc-keep-derivations"))))
         (mingetty-service-type config =>
                                (mingetty-configuration
                                 (inherit config)))))

     (operating-system
       ;; ...
       (services %mis-servicios))

Esto modifica la configuración---es decir, los parámetros de los servicios---de la instancia guix-service-type, y de todas las instancias de mingetty-service-type en la lista %BASE-SERVICES. Observe cómo se consigue: primero, enlazamos la configuración actual al identificador config en el CUERPO, y entonces escribimos el CUERPO de manera que evalue a la configuración deseada. En particular, fíjese como se usa inherit para crear una nueva configuración que tiene los mismos valores que la configuración antigua, pero con unas pocas modificaciones.

La configuración para un uso típico de ``escritorio'', con una partición de raíz cifrada, el servidor gráfico X11, GNOME y Xfce (las usuarias pueden escoger cual de estos entornos de escritorio usarán en la pantalla de inicio de sesión pulsando F1), gestión de red, gestión de energía y más, podría ser así:

          [file os-config-desktop.texi not included]

Un sistema gráfico con una selección de gestores de ventanas ligeros en vez de entornos de escritorio completos podría ser así:

          [file os-config-lightweight-desktop.texi not included]

Este ejemplo se refiere al sistema de ficheros /boot/efi por su UUID 1234-ABCD. Substituya este UUID con el UUID correcto en su sistema, como el devuelto por la orden blkid.

See Servicios de escritorio, para la lista exacta de servicios proporcionados por %DESKTOP-SERVICES. See Certificados X.509, para información sobre el paquete nss-certs usado aquí.

De nuevo, %DESKTOP-SERVICES es simplemente una lista de objetos de servicios. Si desea borrar servicios de aquí, puede hacerlo usando procedimientos de filtrado de listas (see SRFI-1 Filtering and Partitioning (GNU Guile Reference Manual)). Por ejemplo, la siguiente expresión devuelve una lista que contiene todos los servicios en %DESKTOP-SERVICES excepto el servicio Avahi:

     (remove (lambda (service)
               (eq? (service-kind service) avahi-service-type))
             %desktop-services)

Instanciación del sistema
-------------------------

Asumiendo que la declaración de operating-system se encuentra en el fichero my-conf-del-sistema.scm, la orden guix system mi-conf-del-sistema.scm instancia esa configuración, y la convierte en la entrada predeterminada de GRUB en el arranque (see Invocación de guix system).

La manera habitual de cambiar la configuración del sistema es actualizar este fichero y volver a ejecutar guix system reconfigure. Nunca se deberían tocar los ficheros en /etc o ejecutar órdenes que modifiquen el estado del sistema como useradd o grub-install. De hecho, debe evitarlo ya que no únicamente anularía su garantía sino que también le impediría volver a una versión previa de su sistema, en caso de necesitarlo.

Hablando de vuelta atrás, cada vez que ejecuta guix system reconfigure se crea una nueva generación del sistema---sin modificar o borrar generaciones previas. Las generaciones previas tienen una entrada en el menú del cargador de arranque, permitiendole arrancarlas en caso de que algo funcionase mal en las últimas generaciones. Tranquilizador, ¿no? La orden guix system list-generations enumera las generaciones del sistema disponibles en el disco. Es también posible volver a una versión previa con las órdenes guix system roll-back y guix system switch-generation.

Aunque la orden guix system reconfigure no modificará las generaciones previas, debe tener cuidado cuando la generación actual no es la última (por ejemplo, después de invocar guix system roll-back), ya que la operación puede sobreescribir una generación posterior (see Invocación de guix system).

La interfaz programática
------------------------

A nivel Scheme, el grueso de una declaración operating-system se instancia con el siguiente procedimiento monádico (see La mónada del almacén):

 -- Procedimiento monádico: operating-system-derivation so
     Devuelve una derivación que construye SO, un objeto operating-system (see Derivaciones).

     La salida de la derivación es un único directorio que hace referencia a todos los paquetes, ficheros de configuración y otros ficheros auxiliares necesarios para instanciar SO.

This procedure is provided by the (gnu system) module.  Along with (gnu services) (see Servicios), this module contains the guts of Guix System.  Make sure to visit it!

Referencia de operating-system
==============================

Esta sección resume todas las opciones disponibles en las declaraciones de operating-system (see Uso de la configuración del sistema).

 -- Tipo de datos: operating-system
     Este es el tipo de datos que representa la configuración del sistema operativo. Con ello queremos decir toda la configuración global del sistema, no la configuración específica de las usuarias (see Uso de la configuración del sistema).

     kernel (predeterminado: linux-libre)
          El objeto del paquete del núcleo del sistema operativo usado (Actualmente únicamente está disponible el núcleo Linux-libre. En el futuro será posible usar GNU Hurd.).

     kernel-arguments (default: '("quiet"))
          Lista de cadenas o expresiones-G que representan parámetros adicionales a pasar en la línea de órdenes del núcleo---por ejemplo, ("console=ttyS0").

     bootloader
          El objeto de configuración del cargador de arranque del sistema. See Configuración del gestor de arranque.

     label
          This is the label (a string) as it appears in the bootloader's menu entry. The default label includes the kernel name and version.

     keyboard-layout (predeterminada: #f)
          This field specifies the keyboard layout to use in the console.  It can be either #f, in which case the default keyboard layout is used (usually US English), or a <keyboard-layout> record.

          This keyboard layout is in effect as soon as the kernel has booted.  For instance, it is the keyboard layout in effect when you type a passphrase if your root file system is on a luks-device-mapping mapped device (see Dispositivos traducidos).

               This does not specify the keyboard layout used by the bootloader, nor that used by the graphical display server.  See Configuración del gestor de arranque, for information on how to specify the bootloader's keyboard layout.  See Sistema X Window, for information on how to specify the keyboard layout used by the X Window System.

     initrd-modules (predeterminados: %base-initrd-modules)
          La lista de módulos del núcleo Linux que deben estar disponibles en el disco inicial de RAM. See Disco en RAM inicial.

     initrd (predeterminado: base-initrd)
          Un procedimiento que devuelve un disco inicial de RAM para el núcleo Linux. Este campo se proporciona para permitir personalizaciones de bajo nivel y no debería ser necesario para un uso habitual. See Disco en RAM inicial.

     firmware (predeterminado: %base-firmware)
          Lista de paquetes de firmware que pueden ser cargados por el núcleo del sistema operativo.

          El valor predeterminado incluye el firmware necesario para dispositivos WiFi basados en Atheros y Broadcom (módulos Linux-libre ath9k y b43-open, respectivamente). See Consideraciones sobre el hardware, para más información sobre hardware soportado.

     host-name
          El nombre de la máquina.

     hosts-file
          Un objeto tipo-fichero (see objetos tipo-fichero) para ser usado como /etc/hosts (see Host Names (The GNU C Library Reference Manual)). El predeterminado es un fichero con entradas para localhost y HOST-NAME.

     mapped-devices (predeterminados: '())
          Una lista de dispositivos traducidos. See Dispositivos traducidos.

     file-systems
          Una lista de sistemas de ficheros. See Sistemas de ficheros.

     swap-devices (predeterminados: '())
          Una lista de cadenas que identifiquen dispositivos o ficheros a usar como ``espacio de intercambio'' (see Memory Concepts (The GNU C Library Reference Manual)). Por ejemplo '("/dev/sda3") o '("/fichero-intercambio"). Es posible especificar un fichero de intercambio en un sistema de ficheros en un dispositivo traducido, siempre que la traducción y el sistema de ficheros se especifiquen también. See Dispositivos traducidos y Sistemas de ficheros.

     users (predeterminadas: %base-user-accounts)
     groups (predeterminados: %BASE-GROUPS)
          Lista de cuentas de usuaria y grupos. See Cuentas de usuaria.

          Si la lista de usuarias carece de una cuenta de usuaria con UID 0, una cuenta ``root'' con UID 0 se añade automáticamente.

     skeletons (predeterminados: (default-skeletons))
          Una lista de tuplas de nombre de fichero de destino/objeto tipo-fichero (see objetos tipo-fichero). Estos son los ficheros de esqueleto que se añadirán al directorio de las cuentas de usuaria que se creen.

          Por ejemplo, un valor válido puede parecer algo así:

               `((".bashrc" ,(plain-file "bashrc" "echo Hola\n"))
                 (".guile" ,(plain-file "guile"
                                        "(use-modules (ice-9 readline))
                                         (activate-readline)")))

     issue (predeterminado: %DEFAULT-ISSUE)
          Una cadena que denota el contenido del fichero /etc/issue, que se muestra cuando las usuarias ingresan al sistema en una consola de texto.

     packages (predeterminados: %BASE-PACKAGES)
          El conjunto de paquetes instalados en el perfil global, que es accesible en /run/current-system/profile.

          El conjunto predeterminado incluye utilidades básicas y es una buena práctica instalar utilidades no-básicas en los perfiles de las usuarias (see Invocación de guix package).

     timezone
          Una cadena que identifica la zona horaria---por ejemplo, "Europe/Paris".

          Puede ejecutar la orden tzselect para encontrar qué cadena de zona horaria corresponde con su región. Elegir una zona horaria no válida provoca un fallo en guix system.

     locale (predeterminado: "en_US.utf8")
          El nombre de la localización predeterminada (see Locale Names (The GNU C Library Reference Manual)). See Localizaciones, para más información.

     locale-definitions (predeterminadas: %DEFAULT-LOCALE-DEFINITIONS)
          La lista de definiciones de localizaciones a compilar y que puede ser usada en tiempo de ejecución. See Localizaciones.

     locale-libcs (predeterminadas: (list GLIBC))
          La lista de paquetes GNU libc cuyos datos de localización y herramientas son usadas para las definiciones de localizaciones. See Localizaciones, para consideraciones de compatibilidad que justifican esta opción.

     name-service-switch (predeterminado: %DEFAULT-NSS)
          Configuración del selector de servicios de nombres de libc (NSS)---un objeto <name-service-switch>. See Selector de servicios de nombres, para detalles.

     considera
          Una lista de objetos service denotando los servicios del sistema. See Servicios.

     essential-services (predeterminados: ...)
          The list of ``essential services''---i.e., things like instances of system-service-type and host-name-service-type (see Referencia de servicios), which are derived from the operating system definition itself. As a user you should never need to touch this field.

     pam-services (predeterminados: (base-pam-services))
          Servicios de los módulos de verificación conectables (PAM) de Linux.

     setuid-programs (predeterminados: %SETUID-PROGRAMS)
          Lista de expresiones-G con valores de cadena que denotan los programas setuid. See Programas con setuid.

     sudoers-file (predeterminado: %SUDOERS-SPECIFICATION)
          El contenido de /etc/sudoers como un objeto tipo-fichero (see local-file y plain-file).

          Este fichero especifica qué usuarias pueden usar la orden sudo, lo que se les permite hacer y qué privilegios pueden obtener. El comportamiento predefinido es que únicamente root y los miembros del grupo wheel pueden usar sudo.

      -- Scheme Syntax: this-operating-system
          When used in the lexical scope of an operating system field definition, this identifier resolves to the operating system being defined.

          The example below shows how to refer to the operating system being defined in the definition of the label field:

               (use-modules (gnu) (guix))

               (operating-system
                 ;; ...
                 (label (package-full-name
                         (operating-system-kernel this-operating-system))))

          It is an error to refer to this-operating-system outside an operating system definition.

Sistemas de ficheros
====================

La lista de sistemas de ficheros que deben montarse se especifica en el campo file-systems de la declaración del sistema operativo (see Uso de la configuración del sistema). Cada sistema de ficheros se declara usando la forma file-system, como en el siguiente ejemplo:

     (file-system
       (mount-point "/home")
       (device "/dev/sda3")
       (type "ext4"))

Como es habitual, algunos de los campos son obligatorios---aquellos mostrados en el ejemplo previo---mientras que otros pueden omitirse. Se describen a continuación.

 -- Tipo de datos: file-system
     Objetos de este tipo representan los sistemas de ficheros a montar. Contienen los siguientes campos:

     type
          Este campo es una cadena que especifica el tipo de sistema de ficheros---por ejemplo, "ext4".

     mount-point
          Designa la ruta donde el sistema de ficheros debe montarse.

     device
          Nombra la ``fuente'' del sistema de ficheros. Puede ser una de estas tres opciones: una etiqueta de sistema de ficheros, un UUID de sistema de ficheros o el nombre de un nodo /dev. Las etiquetas y UUID ofrecen una forma de hacer referencia a sistemas de ficheros sin codificar su nombre de dispositivo actual (Fijese que, aunque es tentador usa /dev/disk/by-uuid y nombres de dispositivo similares para obtener el mismo resultado, no es lo recomendado: estos nodo especiales de dispositivos se crean por el daemon udev y puede no estar disponible cuando el dispositivo sea montado.).

          Las etiquetas del sistema de ficheros se crean mediante el uso del procedimiento file-system-label, los UUID se crean mediante el uso de uuid y los nodos /dev son simples cadenas. A continuación se proporciona un ejemplo de un sistema de ficheros al que se hace referencia mediante su etiqueta, como es mostrada por la orden e2label:

               (file-system
                 (mount-point "/home")
                 (type "ext4")
                 (device (file-system-label "mi-home")))

          Los UUID se convierten dede su representación en forma de cadena (como se muestra con la orden tune2fs -l) mediante el uso de la forma uuid (La forma uuid espera un UUID de 16 bytes como se define en la RFC 4122 (https://tools.ietf.org/html/rfc4122). Este es el formato de UUID que usan la familia de sistemas de ficheros ext2 y otros, pero es diferente de los ``UUID'' de los sistemas de ficheros FAT, por ejemplo.), como sigue:

               (file-system
                 (mount-point "/home")
                 (type "ext4")
                 (device (uuid "4dab5feb-d176-45de-b287-9b0a6e4c01cb")))

          Cuando la fuente de un sistema de ficheros es un dispositivo traducido (see Dispositivos traducidos), su campo device debe hacer referencia al nombre del dispositivo traducido---por ejemplo, "/dev/mapper/particion-raiz". Esto es necesario para que el sistema sepa que el montaje del sistema de ficheros depende del establecimiento de la traducción de dispositivos correspondiente.

     flags (predeterminadas: '())
          Una lista de símbolos que denotan opciones del montaje. Las opciones reconocidas incluyen read-only (modo de sólo lectura), bind-mount (montaje enlazado), no-dev (prohibición del acceso a ficheros especiales), no-suid (ignora los bits setuid y setgid) y no-exec (prohibición de la ejecución de programas).

     options (predeterminadas: #f)
          Esto es o bien #f, o bien una cadena que contiene opciones de montaje.

     mount? (predeterminado: #t)
          Este valor indica si debe montarse el sistema de ficheros automáticamente al iniciar el sistema. Cuando se establece como #f, el sistema de ficheros tiene una entrada en /etc/fstab (el cual es leído por la orden mount) pero no se montará automáticamente.

     needed-for-boot? (predeterminado: #f)
          Este valor lógico indica si el sistema de ficheros es necesario para el arranque. Si es verdadero, el sistema de ficheros se monta al cargar el disco inicial de RAM (initrd). Este es siempre el caso, por ejemplo, para el sistema de ficheros raíz.

     check? (predeterminado: #t)
          Este valor lógico indica si el sistema de ficheros se debe comprobar en busca de errores antes de montarse.

     create-mount-point? (predeterminado: #f)
          Cuando es verdadero, el punto de montaje es creado si no existía previamente.

     dependencies (predeterminadas: '())
          Una lista de objetos <file-system> o <mapped-device> que representan sistemas de ficheros que deben montarse o dispositivos traducidos que deben abrirse antes (y desmontarse o cerrarse después) que el declarado.

          Como ejemplo, considere la siguiente jerarquía de montajes: /sys/fs/cgroup es una dependencia de /sys/fs/cgroup/cpu y /sys/fs/cgroup/memory.

          Otro ejemplo es un sistema de ficheros que depende de un dispositivo traducido, por ejemplo una partición cifrada (see Dispositivos traducidos).

El módulo (gnu system file-systems) exporta las siguientes variables útiles.

 -- Variable Scheme: %base-file-systems
     Estos son los sistemas de ficheros esenciales que se necesitan en sistemas normales, como %PSEUDO-TERMINAL-FILE-SYSTEM y %IMMUTABLE-STORE (véase a continuación). Las declaraciones de sistemas operativos deben contener siempre estos al menos.

 -- Variable Scheme: %pseudo-terminal-file-systems
     El sistema de ficheros que debe montarse como /dev/pts. Permite la creación de pseudoterminales a través de openpty y funciones similares (see Pseudo-Terminals (The GNU C Library Reference Manual)). Los pseudoterminales son usados por emuladores de terminales como xterm.

 -- Variable Scheme: %shared-memory-file-system
     Este sistema de ficheros se monta como /dev/shm y se usa para permitir el uso de memoria compartida entre procesos (see shm_open (The GNU C Library Reference Manual)).

 -- Variable Scheme: %immutable-store
     Este sistema de ficheros crea un montaje enlazado (``bind-mount'') de /gnu/store, permitiendo solo el acceso de lectura para todas las usuarias incluyendo a root. Esto previene modificaciones accidentales por software que se ejecuta como root o por las administradoras del sistema.

     El daemon sí es capaz de escribir en el almacén: vuelve a montar /gnu/store en modo lectura-escritura en su propio ``espacio de nombres''.

 -- Variable Scheme: %binary-format-file-system
     El sistema de ficheros binfmt_misc, que permite que el manejo de tipos de ficheros ejecutables arbitrarios se delegue al espacio de usuaria. Necesita la carga del módulo del núcleo binfmt.ko.

 -- Variable Scheme: %fuse-control-file-system
     El sistema de ficheros fusectl, que permite a usuarias sin privilegios montar y desmontar sistemas de ficheros de espacio de usuaria FUSE. Necesita la carga del módulo del núcleo fuse.ko.

Dispositivos traducidos
=======================

El núcleo Linux tiene una noción de traducción de dispositivos: un dispositivo de bloques, como una partición de disco duro, puede traducirse en otro dispositivo, habitualmente en /dev/mapper/, con un procesamiento adicional sobre los datos que fluyen a través de ella (Fíjese que GNU Hurd no diferencia entre el concepto de un ``dispositivo traducido'' y el de un sistema de ficheros: ambos se reducen a traducir operaciones de entrada/salida realizadas en un fichero a operaciones en su almacenamiento subyacente. Por tanto, Hurd implementa dispositivos traducidos, como sistemas de ficheros, usando el mecanismo genérico de traducción (see Translators (The GNU Hurd Reference Manual)).). Un ejemplo típico es la traducción de dispositivos para el cifrado: todas las escrituras en el dispositivo traducido se cifran, y todas las lecturas se descifran, de forma transparente. Guix extiende esta noción considerando cualquier dispositivo o conjunto de dispositivos que son transformados de alguna manera para crear un nuevo dispositivo; por ejemplo, los dispositivos RAID se obtienen ensamblando otros dispositivos, como discos duros o particiones, en uno nuevo que se comporta como una partición. Otros ejemplos, todavía no implementados, son los volúmenes lógicos LVM.

Los dispositivos traducidos se declaran mediante el uso de la forma mapped-device, definida a continuación; ejemplos más adelante.

 -- Tipo de datos: mapped-device
     Objetos de este tipo representan traducciones de dispositivo que se llevarán a cabo cuando el sistema arranque.

     source
          Puede ser tanto una cadena que especifica el nombre de un dispositivo de bloques a traducir, como "/dev/sda3", o una lista de dichas cadenas cuando varios dispositivos necesitan ser ensamblados para crear uno nuevo.

     target
          Esta cadena especifica el nombre del dispositivo traducido resultante. Para traductores del núcleo como dispositivos de cifrado del tipo luks-device-mapping, especificar "mi-particion" produce la creación del dispositivo "/dev/mapper/mi-particion". Para dispositivos RAID de tipo raid-device-mapping, el nombre del dispositivo completo como "/dev/md0" debe ser proporcionado.

     type
          Debe ser un objeto mapped-device-kind, que especifica cómo SOURCE se traduce a TARGET.

 -- Variable Scheme: luks-device-mapping
     Define el cifrado de bloques LUKS mediante el uso de la orden cryptsetup del paquete del mismo nombre. Depende del módulo dm-crypt del núcleo Linux.

 -- Variable Scheme: raid-device-mapping
     Define un dispositivo RAID, el cual se ensambla mediante el uso de la orden mdadm del paquete del mismo nombre. Requiere la carga del módulo del núcleo Linux para el nivel RAID apropiado, como raid456 para RAID-4, RAID-5 o RAID-6, o raid10 para RAID-10.

El siguiente ejemplo especifica una traducción de /dev/sda3 a /dev/mapper/home mediante el uso de LUKS---la configuración de claves unificada de Linux (https://gitlab.com/cryptsetup/cryptsetup), un mecanismo estándar para cifrado de disco. El dispositivo /dev/mapper/home puede usarse entonces como el campo device de una declaración file-system (see Sistemas de ficheros).

     (mapped-device
       (source "/dev/sda3")
       (target "home")
       (type luks-device-mapping))

De manera alternativa, para independizarse de la numeración de dispositivos, puede obtenerse el UUID LUKS (identificador único) del dispositivo fuente con una orden así:

     cryptsetup luksUUID /dev/sda3

y usarlo como sigue:

     (mapped-device
       (source (uuid "cb67fc72-0d54-4c88-9d4b-b225f30b0f44"))
       (target "home")
       (type luks-device-mapping))

También es deseable cifrar el espacio de intercambio, puesto que el espacio de intercambio puede contener información sensible. Una forma de conseguirlo es usar un fichero de intercambio en un sistema de ficheros en un dispositivo traducido a través del cifrado LUKS. See Particionado del disco, para un ejemplo.

Un dispositivo RAID formado por las particiones /dev/sda1 y /dev/sdb1 puede declararse como se muestra a continuación:

     (mapped-device
       (source (list "/dev/sda1" "/dev/sdb1"))
       (target "/dev/md0")
       (type raid-device-mapping))

El dispositivo /dev/md0 puede usarse entonces como el campo device de una declaración file-system (see Sistemas de ficheros). Fíjese que no necesita proporcionar el nivel RAID; se selecciona durante la creación inicial y formato del dispositivo RAID y después se determina automáticamente.

Cuentas de usuaria
==================

Los grupos y cuentas de usuaria se gestionan completamente a través de la declaración operating-system. Se especifican con las formas user-account y user-group:

     (user-account
       (name "alicia")
       (group "users")
       (supplementary-groups '("wheel"   ;permite usar sudo, etc.
                               "audio"   ;tarjeta de sonido
                               "video"   ;dispositivos de vídeo como cámaras
                               "cdrom")) ;el veterano CD-ROM
       (comment "hermana de Roberto")
       (home-directory "/home/alicia"))

Durante el arranque o tras la finalización de guix system reconfigure, el sistema se asegura de que únicamente las cuentas de usuaria y grupos especificados en la declaración operating-system existen, y con las propiedades especificadas. Por tanto, la creación o modificación de cuentas o grupos realizadas directamente invocando órdenes como useradd se pierden al reconfigurar o reiniciar el sistema. Esto asegura que el sistema permanece exactamente como se declaró.

 -- Tipo de datos: user-account
     Objetos de este tipo representan cuentas de usuaria. Los siguientes miembros pueden ser especificados:

     name
          El nombre de la cuenta de usuaria.

     group
          Este es el nombre (una cadena) o identificador (un número) del grupo de usuarias al que esta cuenta pertenece.

     supplementary-groups (predeterminados: '())
          Opcionalmente, esto puede definirse como una lista de nombres de grupo a los que esta cuenta pertenece.

     uid (predeterminado: #f)
          Este es el ID de usuaria para esta cuenta (un número), o #f. En el último caso, un número es seleccionado automáticamente por el sistema cuando la cuenta es creada.

     comment (predeterminado: "")
          Un comentario sobre la cuenta, como el nombre completo de la propietaria.

     home-directory
          Este es el nombre del directorio de usuaria de la cuenta.

     create-home-directory? (predeterminado: #t)
          Indica si el directorio de usuaria de esta cuenta debe ser creado si no existe todavía.

     shell (predeterminado: Bash)
          Esto es una expresión-G denotando el nombre de fichero de un programa que será usado como shell (see Expresiones-G).

     system? (predeterminado: #f)
          Este valor lógico indica si la cuenta es una cuenta ``del sistema''. Las cuentas del sistema se tratan a veces de forma especial; por ejemplo, los gestores gráficos de inicio no las enumeran.

     password (predeterminada: #f)
          Normalmente debería dejar este campo a #f, inicializar la contraseña de usuaria como root con la orden passwd, y entonces dejar a las usuarias cambiarla con passwd. Las contraseñas establecidas con passwd son, por supuesto, preservadas entre reinicios y reconfiguraciones.

          If you do want to set an initial password for an account, then this field must contain the encrypted password, as a string.  You can use the crypt procedure for this purpose:

               (user-account
                 (name "charlie")
                 (group "users")

                 ;; Specify a SHA-512-hashed initial password.
                 (password (crypt "InitialPassword!" "$6$abc")))

               The hash of this initial password will be available in a file in /gnu/store, readable by all the users, so this method must be used with care.

          See Passphrase Storage (The GNU C Library Reference Manual), for more information on password encryption, and Encryption (GNU Guile Reference Manual), for information on Guile's crypt procedure.

Las declaraciones de grupos son más simples incluso:

     (user-group (name "estudiantes"))

 -- Tipo de datos: user-group
     Este tipo es para grupos de usuarias. Hay únicamente unos pocos campos:

     name
          En nombre del grupo.

     id (predeterminado: #f)
          El identificador del grupo (un número). Si es #f, un nuevo número es reservado automáticamente cuando se crea el grupo.

     system? (predeterminado: #f)
          Este valor booleano indica si el grupo es un grupo ``del sistema''. Los grupos del sistema tienen identificadores numéricos bajos.

     password (predeterminada: #f)
          ¿Qué? ¿Los grupos de usuarias pueden tener una contraseña? Bueno, aparentemente sí. A menos que sea #f, este campo especifica la contraseña del grupo.

Por conveniencia, una variable contiene una lista con todos los grupos de usuarias básicos que se puede esperar:

 -- Variable Scheme: %base-groups
     Esta es la lista de grupos de usuarias básicos que las usuarias y/o los paquetes esperan que estén presentes en el sistema. Esto incluye grupos como ``root'', ``wheel'' y ``users'', así como grupos usados para controlar el acceso a dispositivos específicos como ``audio'', ``disk'' y ``cdrom''.

 -- Variable Scheme: %base-user-accounts
     Esta es la lista de cuentas de usuaria básicas que los programas pueden esperar encontrar en un sistema GNU/Linux, como la cuenta ``nobody''.

     Fíjese que la cuenta de ``root'' no se incluye aquí. Es un caso especial y se añade automáticamente esté o no especificada.

Distribución de teclado
=======================

To specify what each key of your keyboard does, you need to tell the operating system what keyboard layout you want to use.  The default, when nothing is specified, is the US English QWERTY layout for 105-key PC keyboards.  However, German speakers will usually prefer the German QWERTZ layout, French speakers will want the AZERTY layout, and so on; hackers might prefer Dvorak or bépo, and they might even want to further customize the effect of some of the keys.  This section explains how to get that done.

There are three components that will want to know about your keyboard layout:

  * The bootloader may want to know what keyboard layout you want to use (see keyboard-layout).  This is useful if you want, for instance, to make sure that you can type the passphrase of your encrypted root partition using the right layout.

  * The operating system kernel, Linux, will need that so that the console is properly configured (see keyboard-layout).

  * The graphical display server, usually Xorg, also has its own idea of the keyboard layout (see keyboard-layout).

Guix allows you to configure all three separately but, fortunately, it allows you to share the same keyboard layout for all three components.

Keyboard layouts are represented by records created by the keyboard-layout procedure of (gnu system keyboard).  Following the X Keyboard extension (XKB), each layout has four attributes: a name (often a language code such as ``fi'' for Finnish or ``jp'' for Japanese), an optional variant name, an optional keyboard model name, and a possibly empty list of additional options.  In most cases the layout name is all you care about.  Here are a few example:

     ;; The German QWERTZ layout.  Here we assume a standard
     ;; "pc105" keyboard model.
     (keyboard-layout "de")

     ;; The bépo variant of the French layout.
     (keyboard-layout "fr" "bepo")

     ;; The Catalan layout.
     (keyboard-layout "es" "cat")

     ;; The Latin American Spanish layout.  In addition, the
     ;; "Caps Lock" key is used as an additional "Ctrl" key,
     ;; and the "Menu" key is used as a "Compose" key to enter
     ;; accented letters.
     (keyboard-layout "latam"
                      #:options '("ctrl:nocaps" "compose:menu"))

     ;; The Russian layout for a ThinkPad keyboard.
     (keyboard-layout "ru" #:model "thinkpad")

     ;; The "US international" layout, which is the US layout plus
     ;; dead keys to enter accented characters.  This is for an
     ;; Apple MacBook keyboard.
     (keyboard-layout "us" "intl" #:model "macbook78")

See the share/X11/xkb directory of the xkeyboard-config package for a complete list of supported layouts, variants, and models.

Let's say you want your system to use the Turkish keyboard layout throughout your system---bootloader, console, and Xorg.  Here's what your system configuration would look like:

     ;; Using the Turkish layout for the bootloader, the console,
     ;; and for Xorg.

     (operating-system
       ;; ...
       (keyboard-layout (keyboard-layout "tr"))  ;for the console
       (bootloader (bootloader-configuration
                     (bootloader grub-efi-bootloader)
                     (target "/boot/efi")
                     (keyboard-layout keyboard-layout))) ;for GRUB
       (services (cons (set-xorg-configuration
                         (xorg-configuration             ;for Xorg
                           (keyboard-layout keyboard-layout)))
                       %desktop-services)))

In the example above, for GRUB and for Xorg, we just refer to the keyboard-layout field defined above, but we could just as well refer to a different layout.  The set-xorg-configuration procedure communicates the desired Xorg configuration to the graphical log-in manager, by default GDM.

We've discussed how to specify the default keyboard layout of your system when it starts, but you can also adjust it at run time:

  * If you're using GNOME, its settings panel has a ``Region & Language'' entry where you can select one or more keyboard layouts.

  * Under Xorg, the setxkbmap command (from the same-named package) allows you to change the current layout.  For example, this is how you would change the layout to US Dvorak:

          setxkbmap us dvorak

  * The loadkeys command changes the keyboard layout in effect in the Linux console.  However, note that loadkeys does not use the XKB keyboard layout categorization described above.  The command below loads the French bépo layout:

          loadkeys fr-bepo

Localizaciones
==============

Una localización define convenciones culturales para una lengua y región del mundo particular (see Localizaciones (The GNU C Library Reference Manual)). Cada localización tiene un nombre que típicamente tiene la forma de LENGUA_TERRITORIO.CODIFICACIÓN---por ejemplo, fr_LU.utf8 designa la localización para la lengua francesa, con las convenciones culturales de Luxemburgo, usando la codificación UTF-8.

Normalmente deseará especificar la localización predeterminada para la máquina usando el campo locale de la declaración operating-system (see locale).

La localización seleccionada es automáticamente añadida a las definiciones de localización conocidas en el sistema si es necesario, con su codificación inferida de su nombre---por ejemplo, se asume que bo_CN.utf8 usa la codificación UTF-8. Definiciones de localización adicionales pueden ser especificadas en el campo locale-definitions de operating-system---esto es util, por ejemplo, si la codificación no puede ser inferida del nombre de la localización. El conjunto predeterminado de definiciones de localización incluye algunas localizaciones ampliamente usadas, pero no todas las disponibles, para ahorrar espacio.

Por ejemplo, para añadir la localización del frisio del norte para Alemania, el valor de dicho campo puede ser:

     (cons (locale-definition
             (name "fy_DE.utf8") (source "fy_DE"))
           %default-locale-definitions)

De mismo modo, para ahorrar espacio, se puede desear que locale-definitions contenga únicamente las localizaciones que son realmente usadas, como en:

     (list (locale-definition
             (name "ja_JP.eucjp") (source "ja_JP")
             (charset "EUC-JP")))

Las definiciones de localización compiladas están disponibles en /run/current-system/locale/X.Y, donde X.Y es la versión de libc, que es la ruta donde la GNU libc contenida en Guix buscará los datos de localización. Esto puede ser sobreescrito usando la variable de entorno LOCPATH (see LOCPATH and locale packages).

La forma locale-definition es proporcionada por el módulo (gnu system locale). Los detalles se proporcionan a continuación.

 -- Tipo de datos: locale-definition
     Este es el tipo de datos de una definición de localización.

     name
          El nombre de la localización.  See Locale Names (The GNU C Library Reference Manual), para más información sobre nombres de localizaciones.

     source
          El nombre de la fuente para dicha localización. Esto típicamente es la parte IDIOMA_TERRITORIO del nombre de localización.

     charset (predeterminado: "UTF-8")
          La ``codificación de caracteres'' o ``conjunto de caracteres'' para dicha localización, como se define por IANA (http://www.iana.org/assignments/character-sets).

 -- Variable Scheme: %default-locale-definitions
     Una lista de localizaciones UTF-8 usadas de forma común, usada como valor predeterminado del campo locale-definitions en las declaraciones operating-system.

     Estas definiciones de localizaciones usan la codificación normalizada para el fragmento tras el punto en el nombre (see normalized codeset (The GNU C Library Reference Manual)). Por lo que por ejemplo es válido uk_UA.utf8 pero no, digamos, uk_UA.UTF-8.

Consideraciones sobre la compatibilidad de datos de localización
----------------------------------------------------------------

Las declaraciones operating-system proporcionan un campo locale-libcs para especificar los paquetes GNU libc que se usarán para compilar las declaraciones de localizaciones (see Referencia de ``operating-system''). ``¿Por qué debo preocuparme?'', puede preguntarse. Bueno, sucede que el formato binario de los datos de localización es ocasionalmente incompatible de una versión de libc a otra.

Por ejemplo, un programa enlazado con la versión 2.21 de libc no puede leer datos de localización producidos con libc 2.22; peor aún, ese programa aborta en vez de simplemente ignorar los datos de localización incompatibles (Las versiones 2.23 y posteriores de GNU libc simplemente ignorarán los datos de localización incompatibles, lo cual ya es un avance.). De manera similar, un programa enlazado con libc 2.22 puede leer la mayor parte, pero no todo, de los datos de localización de libc 2.21 (específicamente, los datos LC_COLLATE son incompatibles); por tanto las llamadas a setlocale pueden fallar, pero los programas no abortarán.

El ``problema'' con Guix es que las usuarias tienen mucha libertad: pueden elegir cuando e incluso si actualizar el software en sus perfiles, y pueden estar usando una versión de libc diferente de la que la administradora del sistema usó para construir los datos de localización comunes a todo el sistema.

Por suerte, las usuarias sin privilegios también pueden instalar sus propios datos de localización y definir GUIX_LOCPATH adecuadamente (see GUIX_LOCPATH y paquetes de localizaciones).

No obstante, es mejor si los datos de localización globales del sistema en /run/current-system/locale se construyen para todas las versiones de libc realmente en uso en el sistema, de manera que todos los programas puedan acceder a ellos---esto es especialmente crucial en un sistema multiusuaria. Para hacerlo, la administradora puede especificar varios paquetes libc en el campo locale-libcs de operating-system:

     (use-package-modules base)

     (operating-system
       ;; ...
       (locale-libcs (list glibc-2.21 (canonical-package glibc))))

Este ejemplo llevaría a un sistema que contiene definiciones de localización tanto para libc 2.21 como para la versión actual de libc en /run/current-system/locale.

Servicios
=========

Una parte importante de la preparación de una declaración operating-system es listar los servicios del sistema y su configuración (see Uso de la configuración del sistema). Los servicios del sistema típicamente son daemon lanzados cuando el sistema arrancha, u otras acciones necesarias en ese momento---por ejemplo, configurar el acceso de red.

Guix has a broad definition of ``service'' (see Composición de servicios), but many services are managed by the GNU Shepherd (see Servicios de Shepherd).  On a running system, the herd command allows you to list the available services, show their status, start and stop them, or do other specific operations (see Jump Start (The GNU Shepherd Manual)).  For example:

     # herd status

La orden previa, ejecutada como root, enumera los servicios actualmente definidos. La orden herd doc muestra una sinopsis del servicio proporcionado y sus acciones asociadas:

     # herd doc nscd
     Run libc's name service cache daemon (nscd).

     # herd doc nscd action invalidate
     invalidate: Invalidate the given cache--e.g., 'hosts' for host name lookups.

Las ordenes internas start, stop y restart tienen el efecto de arrancar, parar y reiniciar el servicio, respectivamente. Por ejemplo, las siguientes órdenes paran el servicio nscd y reinician el servidor gráfico Xorg:

     # herd stop nscd
     Service nscd has been stopped.
     # herd restart xorg-server
     Service xorg-server has been stopped.
     Service xorg-server has been started.

Las siguientes secciones documentan los servicios disponibles, comenzando con los servicios básicos, que pueden ser usados en una declaración operating-system.

Servicios base
--------------

El módulo (gnu services base) proporciona definiciones para los servicios básicos que se esperan en el sistema. Los servicios exportados por este módulo se enumeran a continuación.

 -- Variable Scheme: %base-services
     Esta variable contiene una lista de servicios básicos (see Tipos de servicios y servicios, para más información sobre los objetos servicio) que se pueden esperar en el sistema: un servicio de ingreso al sistema (mingetty) en cada tty, syslogd, el daemon de la caché del servicio de nombres (nscd), el gestor de dispositivos udev, y más.

     Este es el valor predeterminado del campo services de las declaraciones operating-system. De manera habitual, cuando se personaliza el sistema, es deseable agregar servicios a %BASE-SERVICES, de esta forma:

          (append (list (service avahi-service-type)
                        (service openssh-service-type))
                  %base-services)

 -- Variable Scheme: special-files-service-type
     El servicio que establece ``ficheros especiales'' como /bin/sh; una instancia suya es parte de %base-services.

     El valor asociado con servicios special-file-service-type debe ser una lista de tuplas donde el primer elemento es el ``fichero especial'' y el segundo elemento es su destino. El valor predeterminado es:

          `(("/bin/sh" ,(file-append BASH "/bin/sh")))

     Si quiere añadir, digamos, /usr/bin/env a su sistema, puede cambiar su valor por:

          `(("/bin/sh" ,(file-append BASH "/bin/sh"))
            ("/usr/bin/env" ,(file-append COREUTILS "/bin/env")))

     Ya que es parte de %base-services, puede usar modify-services para personalizar el conjunto de ficheros especiales (see modify-services). Pero una forma simple de añadir un fichero especial es usar el procedimiento extra-special-file (véase a continuación).

 -- Procedimiento Scheme: extra-special-file FICHERO DESTINO
     Usa DESTINO como el ``fichero especial'' FICHERO.

     Por ejemplo, la adición de las siguientes líneas al campo services de su declaración de sistema operativo genera /usr/bin/env como un enlace simbólico:

          (extra-special-file "/usr/bin/env"
                              (file-append coreutils "/bin/env"))

 -- Procedimiento Scheme: host-name-service NOMBRE
     Devuelve un servicio que establece el nombre de máquina a NOMBRE.

 -- Procedimiento Scheme: login-service CONFIG
     Devuelve un servicio para ejecutar el ingreso al sistema de acuerdo con CONFIG, un objeto <login-configuration>, que especifica el mensaje del día, entre otras cosas.

 -- Tipo de datos: login-configuration
     Este es el tipo de datos que representa la configuración del ingreso al sistema.

     motd
          Un objeto tipo-fichero que contiene el ``mensaje del día''.

     allow-empty-passwords? (predeterminado: #t)
          Permite contraseñas vacías por defecto para que las primeras usuarias puedan ingresar en el sistema cuando la cuenta de ``root'' está recién creada.

 -- Procedimiento Scheme: mingetty-service CONFIG
     Devuelve un servicio para ejecutar mingetty de acuerdo con CONFIG, un objeto <mingetty-configuration>, que especifica el tty a ejecutar entre otras cosas.

 -- Tipo de datos: mingetty-configuration
     Este es el tipo de datos que representa la configuración de Mingetty, el cual proporciona la implementación predeterminada de ingreso al sistema en las consolas virtuales.

     tty
          El sistema de la consola en la que se ejecuta este Mingetty---por ejemplo, "tty1".

     auto-login (predeterminado: #f)
          Cuando sea verdadero, este campo debe ser una cadena que denote el nombre de usuaria bajo el cual el sistema ingresa automáticamente. Cuando es #f, se deben proporcionar un nombre de usuaria y una contraseña para ingresar en el sistema.

     login-program (predeterminado: #f)
          Debe ser #f, en cuyo caso se usa el programa predeterminado de ingreso al sistema (login de las herramientas Shadow), o una expresión-G que determine el nombre del programa de ingreso al sistema.

     login-pause? (predeterminado: #f)
          Cuando es #t en conjunción con AUTO-LOGIN, la usuaria deberá presionar una tecla para lanzar el shell de ingreso al sistema.

     mingetty (predeterminado: MINGETTY)
          El paquete Mingetty usado.

 -- Procedure Scheme: agetty-service CONFIG
     Devuelve un servicio para ejecutar agetty de acuerdo con CONFIG, un objeto <agetty-configuration>, que especifica el tty a ejecutar entre otras cosas.<

 -- Tipo de datos: agetty-configuration
     Este es el tipo de datos que representa la configuración de agetty, que implementa el ingreso al sistema en las consolas virtuales y serie. Véase la página de manual agetty(8) para más información.

     tty
          The name of the console this agetty runs on, as a string---e.g., "ttyS0". This argument is optional, it will default to a reasonable default serial port used by the kernel Linux.

          For this, if there is a value for an option agetty.tty in the kernel command line, agetty will extract the device name of the serial port from it and use that.

          If not and if there is a value for an option console with a tty in the Linux command line, agetty will extract the device name of the serial port from it and use that.

          In both cases, agetty will leave the other serial device settings (baud rate etc.) alone---in the hope that Linux pinned them to the correct values.

     baud-rate (predeterminado: #f)
          A string containing a comma-separated list of one or more baud rates, in descending order.

     term (predeterminado: #f)
          A string containing the value used for the TERM environment variable.

     eight-bits? (predeterminado: #f)
          When #t, the tty is assumed to be 8-bit clean, and parity detection is disabled.

     auto-login (predeterminado: #f)
          When passed a login name, as a string, the specified user will be logged in automatically without prompting for their login name or password.

     no-reset? (predeterminado: #f)
          When #t, don't reset terminal cflags (control modes).

     host (predeterminado: #f)
          This accepts a string containing the "login_host", which will be written into the /var/run/utmpx file.

     remote? (predeterminado: #f)
          When set to #t in conjunction with HOST, this will add an -r fakehost option to the command line of the login program specified in LOGIN-PROGRAM.

     flow-control? (predeterminado: #f)
          When set to #t, enable hardware (RTS/CTS) flow control.

     no-issue? (predeterminado: #f)
          When set to #t, the contents of the /etc/issue file will not be displayed before presenting the login prompt.

     init-string (predeterminada: #f)
          This accepts a string that will be sent to the tty or modem before sending anything else.  It can be used to initialize a modem.

     no-clear? (predeterminado: #f)
          When set to #t, agetty will not clear the screen before showing the login prompt.

     login-program (predeterminado: (file-append shadow "/bin/login"))
          This must be either a gexp denoting the name of a log-in program, or unset, in which case the default value is the login from the Shadow tool suite.

     local-line (predeterminado: #f)
          Control the CLOCAL line flag.  This accepts one of three symbols as arguments, 'auto, 'always, or 'never. If #f, the default value chosen by agetty is 'auto.

     extract-baud? (predeterminado: #f)
          When set to #t, instruct agetty to try to extract the baud rate from the status messages produced by certain types of modems.

     skip-login? (predeterminado: #f)
          When set to #t, do not prompt the user for a login name.  This can be used with LOGIN-PROGRAM field to use non-standard login systems.

     no-newline? (predeterminado: #f)
          When set to #t, do not print a newline before printing the /etc/issue file.

     login-options (predeterminadas: #f)
          This option accepts a string containing options that are passed to the login program.  When used with the LOGIN-PROGRAM, be aware that a malicious user could try to enter a login name containing embedded options that could be parsed by the login program.

     login-pause (predeterminada: #f)
          When set to #t, wait for any key before showing the login prompt. This can be used in conjunction with AUTO-LOGIN to save memory by lazily spawning shells.

     chroot (predeterminado: #f)
          Change root to the specified directory.  This option accepts a directory path as a string.

     hangup? (predeterminado: #f)
          Use the Linux system call vhangup to do a virtual hangup of the specified terminal.

     keep-baud? (predeterminado: #f)
          When set to #t, try to keep the existing baud rate.  The baud rates from BAUD-RATE are used when agetty receives a BREAK character.

     timeout (predeterminado: #f)
          When set to an integer value, terminate if no user name could be read within TIMEOUT seconds.

     detect-case? (predeterminado: #f)
          When set to #t, turn on support for detecting an uppercase-only terminal.  This setting will detect a login name containing only uppercase letters as indicating an uppercase-only terminal and turn on some upper-to-lower case conversions.  Note that this will not support Unicode characters.

     wait-cr? (predeterminado: #f)
          When set to #t, wait for the user or modem to send a carriage-return or linefeed character before displaying /etc/issue or login prompt. This is typically used with the INIT-STRING option.

     no-hints? (predeterminado: #f)
          When set to #t, do not print hints about Num, Caps, and Scroll locks.

     no-hostname? (predeterminado: #f)
          By default, the hostname is printed.  When this option is set to #t, no hostname will be shown at all.

     long-hostname? (predeterminado: #f)
          By default, the hostname is only printed until the first dot.  When this option is set to #t, the fully qualified hostname by gethostname or getaddrinfo is shown.

     erase-characters (predeterminado: #f)
          This option accepts a string of additional characters that should be interpreted as backspace when the user types their login name.

     kill-characters (predeterminado: #f)
          This option accepts a string that should be interpreted to mean "ignore all previous characters" (also called a "kill" character) when the types their login name.

     chdir (predeterminado: #f)
          This option accepts, as a string, a directory path that will be changed to before login.

     delay (predeterminado: #f)
          This options accepts, as an integer, the number of seconds to sleep before opening the tty and displaying the login prompt.

     nice (predeterminado: #f)
          This option accepts, as an integer, the nice value with which to run the login program.

     extra-options (predeterminadas: '())
          This option provides an "escape hatch" for the user to provide arbitrary command-line arguments to agetty as a list of strings.

 -- Procedimiento Scheme: kmscon-service-type CONFIG
     Return a service to run kmscon (https://www.freedesktop.org/wiki/Software/kmscon) according to CONFIG, a <kmscon-configuration> object, which specifies the tty to run, among other things.

 -- Tipo de datos: kmscon-configuration
     Este es el tipo de datos que representa la configuración de Kmscon, que implementa el ingreso al sistema en consolas virtuales.

     virtual-terminal
          El sistema de la consola en la que se ejecuta este Kmscon---por ejemplo, "tty1".

     login-program (predeterminado: #~(string-append #$shadow "/bin/login"))
          A gexp denoting the name of the log-in program. The default log-in program is login from the Shadow tool suite.

     login-arguments (predeterminados: '("-p"))
          A list of arguments to pass to login.

     auto-login (predeterminado: #f)
          When passed a login name, as a string, the specified user will be logged in automatically without prompting for their login name or password.

     hardware-acceleration? (predeterminado: #f)
          Determina si se usará aceleración hardware.

     kmscon (predeterminado: KMSCON)
          El paquete Kmscon usado.

 -- Procedimiento Scheme: nscd-service [CONFIGURACIÓN] [#:glibc glibc]
     [#:name-services '()]
     Devuelve un servicio que ejecuta el daemon de la caché del servicio de nombres (nscd) con la CONFIGURACIÓN proporcionada---un objeto <nscd-configuration>. See Selector de servicios de nombres, para un ejemplo.

     Por conveniencia, el servicio ncsd de Shepherd proporciona las siguientes acciones:

     invalidate
          Esto invalida la caché dada. Por ejemplo, ejecutar:

               herd invalidate nscd hosts

          invalida la caché de búsqueda de nombres de máquinas de nscd.

     statistics
          Ejecutar herd statistics nscd muestra información del uso nscd y la caché.

 -- Variable Scheme: %nscd-default-configuration
     This is the default <nscd-configuration> value (see below) used by nscd-service.  It uses the caches defined by %NSCD-DEFAULT-CACHES; see below.

 -- Tipo de datos: nscd-configuration
     Este tipo de datos representa la configuración del daemon de caché del servicio de nombres (nscd).

     name-services (predeterminados: '())
          List of packages denoting name services that must be visible to the nscd---e.g., (list NSS-MDNS).

     glibc (predeterminada: GLIBC)
          Package object denoting the GNU C Library providing the nscd command.

     log-file (predeterminado: "/var/log/nscd.log")
          Name of the nscd log file.  This is where debugging output goes when debug-level is strictly positive.

     debug-level (predeterminado: 0)
          Integer denoting the debugging levels.  Higher numbers mean that more debugging output is logged.

     caches (predeterminadas: %NSCD-DEFAULT-CACHES)
          List of <nscd-cache> objects denoting things to be cached; see below.

 -- Tipo de datos: nscd-cache
     Tipo de datos que representa una base de datos de caché de nscd y sus parámetros.

     base de datos
          This is a symbol representing the name of the database to be cached.  Valid values are passwd, group, hosts, and services, which designate the corresponding NSS database (see NSS Basics (The GNU C Library Reference Manual)).

     positive-time-to-live
     negative-time-to-live (predeterminado: 20)
          A number representing the number of seconds during which a positive or negative lookup result remains in cache.

     check-files? (predeterminado: #t)
          Whether to check for updates of the files corresponding to DATABASE.

          For instance, when DATABASE is hosts, setting this flag instructs nscd to check for updates in /etc/hosts and to take them into account.

     persistent? (predeterminada: #t)
          Whether the cache should be stored persistently on disk.

     shared? (predeterminado: #t)
          Whether the cache should be shared among users.

     max-database-size (predeterminado: 32 MiB)
          Maximum size in bytes of the database cache.

 -- Variable Scheme: %nscd-default-caches
     List of <nscd-cache> objects used by default by nscd-configuration (see above).

     It enables persistent and aggressive caching of service and host name lookups.  The latter provides better host name lookup performance, resilience in the face of unreliable name servers, and also better privacy---often the result of host name lookups is in local cache, so external name servers do not even need to be queried.

 -- Tipo de datos: syslog-configuration
     Este tipo de datos representa la configuración del daemon syslog.

     syslogd (predeterminado: #~(string-append #$inetutils "/libexec/syslogd"))
          El daemon syslog usado.

     config-file (predeterminado: %default-syslog.conf)
          El fichero de configuración de syslog usado.

 -- Procedimiento Scheme: syslog-service CONFIG
     Return a service that runs a syslog daemon according to CONFIG.

     See syslogd invocation (GNU Inetutils), para más información sobre la sintaxis del fichero de configuración.

 -- Variable Scheme: guix-service-type
     This is the type of the service that runs the build daemon, guix-daemon (see Invocación de guix-daemon).  Its value must be a guix-configuration record as described below.

 -- Tipo de datos: guix-configuration
     This data type represents the configuration of the Guix build daemon. See Invocación de guix-daemon, for more information.

     guix (predeterminado: GUIX)
          El paquete Guix usado.

     build-group (predeterminado: "guixbuild")
          El nombre del grupo de las cuentas de usuarias de construcción.

     build-accounts (predeterminadas: 10)
          Número de cuentas de usuarias de construcción a crear.

     authorize-key? (predeterminado: #t)
          Determina si se autoriza las claves de sustituciones listadas en authorized-keys---predeterminada la de ci.guix.es.info (see Sustituciones).

     authorized-keys (predeterminadas: %DEFAULT-AUTHORIZED-GUIX-KEYS)
          La lista de ficheros de claves autorizadas para importaciones de archivos, como una lista de expresiones-G que evalúan a cadenas (see Invocación de guix archive). Por defecto, contiene las de ci.guix.es.info (see Sustituciones).

     use-substitutes? (predeterminado: #t)
          Determina si se usarán sustituciones.

     substitute-urls (predeterminado: %DEFAULT-SUBSTITUTE-URLS)
          La lista de URLs donde se buscarán sustituciones por defecto.

     max-silent-time (predeterminado: 0)
     timeout (predeterminado: 0)
          The number of seconds of silence and the number of seconds of activity, respectively, after which a build process times out.  A value of zero disables the timeout.

     log-compression (predeterminado: 'bzip2)
          El tipo de compresión usado en los log de construcción---o bien gzip, o bien bzip2 o none.

     extra-options (predeterminadas: '())
          Lista de opciones de línea de órdenes adicionales para guix-daemon.

     log-file (predeterminado: "/var/log/guix-daemon.log")
          Fichero al que se escriben la salida estándar y la salida estándar de error de guix-daemon.

     http-proxy (predeterminado: #f)
          El proxy HTTP que se usa para la descarga de derivaciones de salida fija y sustituciones.

     tmpdir (predeterminado: #f)
          Una ruta de directorio donde guix-daemon realiza las construcciones.

 -- Procedimiento Scheme: udev-service [#:udev EUDEV #:rules '()]
     Run UDEV, which populates the /dev directory dynamically.  udev rules can be provided as a list of files through the RULES variable. The procedures UDEV-RULE and FILE->UDEV-RULE from (gnu services base) simplify the creation of such rule files.

 -- Procedimiento Scheme: udev-rule [NOMBRE-FICHERO CONTENIDO]
     Devuelve un fichero de reglas de udev con nombre NOMBRE-FICHERO que contiene las reglas definidas en el literal CONTENIDO.

     En el ejemplo siguiente se define una regla para un dispositivo USB que será almacenada en el fichero 90-usb-cosa.rules. Esta regla ejecuta un script cuando se detecta un dispositivo USB con un identificador de producto dado.

          (define %regla-ejemplo-udev
            (udev-rule
              "90-usb-cosa.rules"
              (string-append "ACTION==\"add\", SUBSYSTEM==\"usb\", "
                             "ATTR{product}==\"Ejemplo\", "
                             "RUN+=\"/ruta/al/ejecutable\"")))

     The herd rules udev command, as root, returns the name of the directory containing all the active udev rules.

Here we show how the default UDEV-SERVICE can be extended with it.

     (operating-system
      ;; ...
      (services
      (modify-services %desktop-services
        (udev-service-type config =>
          (udev-configuration (inherit config)
           (rules (append (udev-configuration-rules config)
                          (list %regla-ejemplo-udev))))))))

 -- Procedimiento Scheme: file->udev-rule [NOMBRE-FICHERO FICHERO]
     Devuelve un fichero de udev con nombre NOMBRE-FICHERO que contiene las reglas definidas en FICHERO, un objeto tipo-fichero.

     El ejemplo siguiente muestra cómo podemos usar un fichero de reglas existente.

          (use-modules (guix download)     ;para url-fetch
                       (guix packages)     ;para origin
                       ;; ...)

          (define %reglas-android-udev
            (file->udev-rule
              "51-android-udev.rules"
              (let ((version "20170910"))
                (origin
                 (method url-fetch)
                 (uri (string-append "https://raw.githubusercontent.com/M0Rf30/"
                                     "android-udev-rules/" version "/51-android.rules"))
                 (sha256
                  (base32 "0lmmagpyb6xsq6zcr2w1cyx9qmjqmajkvrdbhjx32gqf1d9is003"))))))

Adicionalmente, las definiciones de paquete Gui pueden ser incluidas en RULES para extender las reglas udev con las definiciones encontradas bajo su subdirectorio lib/udev/rules.d. En vez del ejemplo previo de FILE->UDEV-RULE, podíamos haber usado el paquete ANDROID-UDEV-RULES que existe en Guix en el módulo (gnu packages android).

El siguiente ejemplo muestra cómo usar el paquete ANDROID-UDEV-RULES para que la herramienta de Android adb pueda detectar dispositivos sin privilegios de root. También detalla como crear el grupo adbusers, el cual se requiere para el funcionamiento correcto de las reglas definidas dentro del paquete ANDROID-UDEV-RULES. Para crear tal grupo, debemos definirlo tanto como parte de SUPPLEMENTARY-GROUPS de la declaración de nuestra cuenta de usuaria USER-ACCOUNT, así como en el campo GROUPS del registro OPERATING-SYSTEM.

     (use-modules (gnu packages android)  ;para android-udev-rules
                  (gnu system shadow)     ;para user-group
                  ;; ...)

     (operating-system
       ;; ...
       (users (cons (user-acount
                     ;; ...
                     (supplementary-groups
                      '("adbusers"   ;para adb
                        "wheel" "netdev" "audio" "video"))
                     ;; ...)))

       (groups (cons (user-group (system? #t) (name "adbusers"))
                     %base-groups))

       ;; ...

       (services
        (modify-services %desktop-services
          (udev-service-type
           config =>
           (udev-configuration (inherit config)
                               (rules (cons android-udev-rules
                                            (udev-configuration-rules config))))))))

 -- Variable Scheme: urandom-seed-service-type
     Save some entropy in %RANDOM-SEED-FILE to seed /dev/urandom when rebooting.  It also tries to seed /dev/urandom from /dev/hwrng while booting, if /dev/hwrng exists and is readable.

 -- Variable Scheme: %random-seed-file
     This is the name of the file where some random bytes are saved by URANDOM-SEED-SERVICE to seed /dev/urandom when rebooting.  It defaults to /var/lib/random-seed.

 -- Variable Scheme: gpm-service-type
     This is the type of the service that runs GPM, the general-purpose mouse daemon, which provides mouse support to the Linux console.  GPM allows users to use the mouse in the console, notably to select, copy, and paste text.

     The value for services of this type must be a gpm-configuration (see below).  This service is not part of %BASE-SERVICES.

 -- Tipo de datos: gpm-configuration
     Tipo de datos que representa la configuración de GPM.

     opciones (predeterminadas: %default-gpm-options)
          Command-line options passed to gpm.  The default set of options instruct gpm to listen to mouse events on /dev/input/mice. See Command Line (gpm manual), for more information.

     gpm (predeterminado: gpm)
          El paquete GPM usado.

 -- Variable Scheme: guix-publish-service-type
     This is the service type for guix publish (see Invocación de guix publish).  Its value must be a guix-configuration object, as described below.

     This assumes that /etc/guix already contains a signing key pair as created by guix archive --generate-key (see Invocación de guix archive).  If that is not the case, the service will fail to start.

 -- Tipo de datos: guix-publish-configuration
     Tipo de datos que representa la configuración del servicio guix publish.

     guix (predeterminado: guix)
          El paquete Guix usado.

     port (predeterminado: 80)
          El puerto TCP en el que se esperan conexiones.

     host (predeterminado: "localhost")
          The host (and thus, network interface) to listen to.  Use "0.0.0.0" to listen on all the network interfaces.

     compression-level (predeterminado: 3)
          The gzip compression level at which substitutes are compressed.  Use 0 to disable compression altogether, and 9 to get the best compression ratio at the expense of increased CPU usage.

     nar-path (predeterminado: "nar")
          The URL path at which ``nars'' can be fetched.  See --nar-path, for details.

     cache (predeterminado: #f)
          When it is #f, disable caching and instead generate archives on demand.  Otherwise, this should be the name of a directory---e.g., "/var/cache/guix/publish"---where guix publish caches archives and meta-data ready to be sent.  See --cache, for more information on the tradeoffs involved.

     workers (predeterminado: #f)
          When it is an integer, this is the number of worker threads used for caching; when #f, the number of processors is used.  See --workers, for more information.

     ttl (predeterminado: #f)
          When it is an integer, this denotes the time-to-live in seconds of the published archives.  See --ttl, for more information.

 -- Procedimiento Scheme: rngd-service [#:rng-tools RNG-TOOLS]
     [#:device "/dev/hwrng"] Return a service that runs the rngd
     program from RNG-TOOLS to add DEVICE to the kernel's entropy pool.  The service will fail if DEVICE does not exist.

 -- Procedimiento Scheme: pam-limits-service [#:limits '()]

     Return a service that installs a configuration file for the pam_limits module (http://linux-pam.org/Linux-PAM-html/sag-pam_limits.html).  The procedure optionally takes a list of pam-limits-entry values, which can be used to specify ulimit limits and nice priority limits to user sessions.

     The following limits definition sets two hard and soft limits for all login sessions of users in the realtime group:

          (pam-limits-service
           (list
            (pam-limits-entry "@realtime" 'both 'rtprio 99)
            (pam-limits-entry "@realtime" 'both 'memlock 'unlimited)))

     The first entry increases the maximum realtime priority for non-privileged processes; the second entry lifts any restriction of the maximum address space that can be locked in memory.  These settings are commonly used for real-time audio systems.

Ejecución de tareas programadas
-------------------------------

The (gnu services mcron) module provides an interface to GNU mcron, a daemon to run jobs at scheduled times (see GNU mcron).  GNU mcron is similar to the traditional Unix cron daemon; the main difference is that it is implemented in Guile Scheme, which provides a lot of flexibility when specifying the scheduling of jobs and their actions.

The example below defines an operating system that runs the updatedb (see Invoking updatedb (Finding Files))  and the guix gc commands (see Invocación de guix gc) daily, as well as the mkid command on behalf of an unprivileged user (see mkid invocation (ID Database Utilities)).  It uses gexps to introduce job definitions that are passed to mcron (see Expresiones-G).

     (use-modules (guix) (gnu) (gnu services mcron))
     (use-package-modules base idutils)

     (define trabajo-updatedb
       ;; Ejecuta 'updatedb' a las 3AM cada día. Aquí escribimos
       ;; las acciones del trabajo como un procedimiento Scheme.
       #~(job '(next-hour '(3))
              (lambda ()
                (execl (string-append #$findutils "/bin/updatedb")
                       "updatedb"
                       "--prunepaths=/tmp /var/tmp /gnu/store"))))

     (define trabajo-recolector-basura
       ;; Recolecta basura 5 minutos después de media noche,
       ;; todos los días. La acción del trabajo es una orden
       ;; del shell.
       #~(job "5 0 * * *"            ;sintaxis de Vixie cron
              "guix gc -F 1G"))

     (define trabajo-idutils
       ;; Actualiza el índice de la base de datos como "carlos" a las
       ;; 12:15 y a las 19:15.  Esto se ejecuta desde su directorio.
       #~(job '(next-minute-from (next-hour '(12 19)) '(15))
              (string-append #$idutils "/bin/mkid src")
              #:user "carlos"))

     (operating-system
       ;; ...
       (services (cons (service mcron-service-type
                                (mcron-configuration
                                 (jobs (list trabajo-recolector-basura
                                             trabajo-updatedb
                                             trabajo-idutils))))
                       %base-services)))

See mcron job specifications (GNU mcron), for more information on mcron job specifications.  Below is the reference of the mcron service.

On a running system, you can use the schedule action of the service to visualize the mcron jobs that will be executed next:

     # herd schedule mcron

The example above lists the next five tasks that will be executed, but you can also specify the number of tasks to display:

     # herd schedule mcron 10

 -- Variable Scheme: mcron-service-type
     This is the type of the mcron service, whose value is an mcron-configuration object.

     This service type can be the target of a service extension that provides it additional job specifications (see Composición de servicios).  In other words, it is possible to define services that provide additional mcron jobs to run.

 -- Tipo de datos: mcron-configuration
     Tipo de datos que representa la configuración de mcron.

     mcron (predeterminado: MCRON)
          El paquete mcron usado.

     jobs
          This is a list of gexps (see Expresiones-G), where each gexp corresponds to an mcron job specification (see mcron job specifications (GNU mcron)).

Rotación de logs
----------------

Log files such as those found in /var/log tend to grow endlessly, so it's a good idea to rotate them once in a while---i.e., archive their contents in separate files, possibly compressed.  The (gnu services admin) module provides an interface to GNU Rot[t]log, a log rotation tool (see GNU Rot[t]log Manual).

The example below defines an operating system that provides log rotation with the default settings, for commonly encountered log files.

     (use-modules (guix) (gnu))
     (use-service-modules admin mcron)
     (use-package-modules base idutils)

     (operating-system
       ;; ...
       (services (cons (service rottlog-service-type)
                       %base-services)))

 -- Variable Scheme: rottlog-service-type
     This is the type of the Rottlog service, whose value is a rottlog-configuration object.

     Other services can extend this one with new log-rotation objects (see below), thereby augmenting the set of files to be rotated.

     This service type can define mcron jobs (see Ejecución de tareas programadas) to run the rottlog service.

 -- Tipo de datos: rottlog-configuration
     Tipo de datos que representa la configuración de rottlog.

     rottlog (predeterminado: rottlog)
          El paquete Rottlog usado.

     rc-file (predeterminado: (file-append rottlog "/etc/rc"))
          The Rottlog configuration file to use (see Mandatory RC Variables (GNU Rot[t]log Manual)).

     rotations (predeterminadas: %default-rotations)
          A list of log-rotation objects as defined below.

     jobs
          This is a list of gexps where each gexp corresponds to an mcron job specification (see Ejecución de tareas programadas).

 -- Tipo de datos: log-rotation
     Tipo de datos que representa la rotación de un grupo de ficheros de log.

     Taking an example from the Rottlog manual (see Period Related File Examples (GNU Rot[t]log Manual)), a log rotation might be defined like this:

          (log-rotation
            (frequency 'daily)
            (files '("/var/log/apache/*"))
            (options '("storedir apache-archives"
                       "rotate 6"
                       "notifempty"
                       "nocompress")))

     La lista de campos es como sigue:

     frequency (predeterminada: 'weekly)
          La frecuencia de rotación de logs, un símbolo.

     files
          La lista de ficheros o patrones extendidos de fichero a rotar.

     options (predeterminadas: '())
          The list of rottlog options for this rotation (see Configuration parameters (GNU Rot[t]lg Manual)).

     post-rotate (predeterminado: #f)
          Either #f or a gexp to execute once the rotation has completed.

 -- Variable Scheme: %default-rotations
     Specifies weekly rotation of %ROTATED-FILES and a couple of other files.

 -- Variable Scheme: %rotated-files
     The list of syslog-controlled files to be rotated.  By default it is: '("/var/log/messages" "/var/log/secure").

Servicios de red
----------------

El módulo (gnu services networking) proporciona servicios para configurar la interfaz de red.

 -- Variable Scheme: dhcp-client-service-type
     This is the type of services that run DHCP, a Dynamic Host Configuration Protocol (DHCP) client, on all the non-loopback network interfaces.  Its value is the DHCP client package to use, isc-dhcp by default.

 -- Procedimiento Scheme: dhcpd-service-type
     This type defines a service that runs a DHCP daemon.  To create a service of this type, you must supply a <dhcpd-configuration>.  For example:

          (service dhcpd-service-type
                   (dhcpd-configuration
                    (config-file (local-file "mi-dhcpd.conf"))
                    (interfaces '("enp0s25"))))

 -- Tipo de datos: dhcpd-configuration

     package (predeterminado: isc-dhcp)
          The package that provides the DHCP daemon.  This package is expected to provide the daemon at sbin/dhcpd relative to its output directory. The default package is the ISC's DHCP server (http://www.isc.org/products/DHCP).

     config-file (predeterminado: #f)
          The configuration file to use.  This is required.  It will be passed to dhcpd via its -cf option.  This may be any ``file-like'' object (see file-like objects).  See man dhcpd.conf for details on the configuration file syntax.

     version (predeterminada: "4")
          The DHCP version to use.  The ISC DHCP server supports the values ``4'', ``6'', and ``4o6''.  These correspond to the dhcpd program options -4, -6, and -4o6.  See man dhcpd for details.

     run-directory (predeterminado: "/run/dhcpd")
          The run directory to use.  At service activation time, this directory will be created if it does not exist.

     pid-file (predeterminado: "/run/dhcpd/dhcpd.pid")
          The PID file to use.  This corresponds to the -pf option of dhcpd.  See man dhcpd for details.

     interfaces (predeterminadas: '())
          The names of the network interfaces on which dhcpd should listen for broadcasts.  If this list is not empty, then its elements (which must be strings) will be appended to the dhcpd invocation when starting the daemon.  It may not be necessary to explicitly specify any interfaces here; see man dhcpd for details.

 -- Variable Scheme: static-networking-service-type
     This is the type for statically-configured network interfaces.

 -- Procedimiento Scheme: static-networking-service INTERFAZ IP
     [#:netmask #f] [#:gateway #f] [#:name-servers '()]  [#:requirement
     '(udev)] Return a service that starts INTERFACE with address IP.  If NETMASK is true, use it as the network mask.  If GATEWAY is true, it must be a string specifying the default network gateway.  REQUIREMENT can be used to declare a dependency on another service before configuring the interface.

     This procedure can be called several times, one for each network interface of interest.  Behind the scenes what it does is extend static-networking-service-type with additional network interfaces to handle.

     Por ejemplo:

          (static-networking-service "eno1" "192.168.1.82"
                                     #:gateway "192.168.1.2"
                                     #:name-servers '("192.168.1.2"))

 -- Procedimiento Scheme: wicd-service [#:wicd WICD]
     Return a service that runs Wicd (https://launchpad.net/wicd), a network management daemon that aims to simplify wired and wireless networking.

     This service adds the WICD package to the global profile, providing several commands to interact with the daemon and configure networking: wicd-client, a graphical user interface, and the wicd-cli and wicd-curses user interfaces.

 -- Variable Scheme: modem-manager-service-type
     This is the service type for the ModemManager (https://wiki.gnome.org/Projects/ModemManager) service. The value for this service type is a modem-manager-configuration record.

     Este servicio es parte de %desktop-services (see Servicios de escritorio).

 -- Tipo de datos: modem-manager-configuration
     Tipo de datos que representa la configuración de ModemManager.

     modem-manager (predeterminado: modem-manager)
          El paquete de ModemManager usado.

 -- Variable Scheme: network-manager-service-type
     This is the service type for the NetworkManager (https://wiki.gnome.org/Projects/NetworkManager) service. The value for this service type is a network-manager-configuration record.

     Este servicio es parte de %desktop-services (see Servicios de escritorio).

 -- Tipo de datos: network-manager-configuration
     Tipo de datos que representa la configuración de NetworkManager.

     network-manager (predeterminado: network-manager)
          El paquete de NetworkManager usado.

     dns (predeterminado: "default")
          Processing mode for DNS, which affects how NetworkManager uses the resolv.conf configuration file.

          default
               NetworkManager will update resolv.conf to reflect the nameservers provided by currently active connections.

          dnsmasq
               NetworkManager will run dnsmasq as a local caching nameserver, using a "split DNS" configuration if you are connected to a VPN, and then update resolv.conf to point to the local nameserver.

          none
               NetworkManager will not modify resolv.conf.

     vpn-plugins (predeterminados: '())
          This is the list of available plugins for virtual private networks (VPNs). An example of this is the network-manager-openvpn package, which allows NetworkManager to manage VPNs via OpenVPN.

 -- Variable Scheme: connman-service-type
     This is the service type to run Connman (https://01.org/connman), a network connection manager.

     Its value must be an connman-configuration record as in this example:

          (service connman-service-type
                   (connman-configuration
                     (disable-vpn? #t)))

     See below for details about connman-configuration.

 -- Tipo de datos: connman-configuration
     Tipo de datos que representa la configuración de connman.

     connman (predeterminado: CONNMAN)
          El paquete connman usado.

     disable-vpn? (predeterminado: #f)
          Cuando es verdadero, deshabilita el módulo vpn de connman.

 -- Variable Scheme: wpa-supplicant-service-type
     This is the service type to run WPA supplicant (https://w1.fi/wpa_supplicant/), an authentication daemon required to authenticate against encrypted WiFi or ethernet networks.

 -- Tipo de datos: wpa-supplicant-configuration
     Tipo de datos que representa la configuración de WPA Supplicant.

     Toma los siguientes parámetros:

     wpa-supplicant (predeterminado: wpa-supplicant)
          El paquete de WPA Supplicant usado.

     dbus? (predeterminado: #t)
          Si se escuchan o no peticiones en D-Bus.

     pid-file (predeterminado: "/var/run/wpa_supplicant.pid")
          Dónde se almacena el fichero con el PID.

     interface (predeterminado: #f)
          If this is set, it must specify the name of a network interface that WPA supplicant will control.

     config-file (predeterminado: #f)
          Fichero de configuración opcional usado.

     extra-options (predeterminadas: '())
          Lista de parámetros adicionales a pasar al daemon en la línea de órdenes.

 -- Variable Scheme: iptables-service-type
     This is the service type to set up an iptables configuration.  iptables is a packet filtering framework supported by the Linux kernel.  This service supports configuring iptables for both IPv4 and IPv6.  A simple example configuration rejecting all incoming connections except those to the ssh port 22 is shown below.

          (service iptables-service-type
                   (iptables-configuration
                    (ipv4-rules (plain-file "iptables.rules" "*filter
          :INPUT ACCEPT
          :FORWARD ACCEPT
          :OUTPUT ACCEPT
          -A INPUT -p tcp --dport 22 -j ACCEPT
          -A INPUT -j REJECT --reject-with icmp-port-unreachable
          COMMIT
          "))
                    (ipv6-rules (plain-file "ip6tables.rules" "*filter
          :INPUT ACCEPT
          :FORWARD ACCEPT
          :OUTPUT ACCEPT
          -A INPUT -p tcp --dport 22 -j ACCEPT
          -A INPUT -j REJECT --reject-with icmp6-port-unreachable
          COMMIT
          "))))

 -- Tipo de datos: iptables-configuration
     El tipo de datos que representa la configuración de iptables.

     iptables (predeterminado: iptables)
          The iptables package that provides iptables-restore and ip6tables-restore.

     ipv4-rules (predeterminado: %iptables-accept-all-rules)
          The iptables rules to use.  It will be passed to iptables-restore. This may be any ``file-like'' object (see file-like objects).

     ipv6-rules (predeterminadas: %iptables-accept-all-rules)
          The ip6tables rules to use.  It will be passed to ip6tables-restore. This may be any ``file-like'' object (see file-like objects).

 -- Variable Scheme: ntp-service-type
     This is the type of the service running the Network Time Protocol (NTP) (http://www.ntp.org) daemon, ntpd.  The daemon will keep the system clock synchronized with that of the specified NTP servers.

     The value of this service is an ntpd-configuration object, as described below.

 -- Tipo de datos: ntp-configuration
     Este es el tipo de datos para la configuración del servicio NTP.

     servers (predeterminados: %ntp-servers)
          This is the list of servers (host names) with which ntpd will be synchronized.

     allow-large-adjustment? (predeterminado: #f)
          This determines whether ntpd is allowed to make an initial adjustment of more than 1,000 seconds.

     ntp (predeterminado: ntp)
          El paquete NTP usado.

 -- Variable Scheme: %ntp-servers
     List of host names used as the default NTP servers.  These are servers of the NTP Pool Project (https://www.ntppool.org/en/).

 -- Procedimiento Scheme: openntpd-service-type
     Run the ntpd, the Network Time Protocol (NTP) daemon, as implemented by OpenNTPD (http://www.openntpd.org).  The daemon will keep the system clock synchronized with that of the given servers.

          (service
           openntpd-service-type
           (openntpd-configuration
            (listen-on '("127.0.0.1" "::1"))
            (sensor '("udcf0 correction 70000"))
            (constraint-from '("www.gnu.org"))
            (constraints-from '("https://www.google.com/"))
            (allow-large-adjustment? #t)))

 -- Tipo de datos: openntpd-configuration

     openntpd (predeterminado: (file-append openntpd "/sbin/ntpd"))
          El ejecutable openntpd usado.

     listen-on (predeterminadas: '("127.0.0.1" "::1"))
          Una lista de direcciones IP o nombres de máquina en los que el daemon ntpd debe escuchar conexiones.

     query-from (predeterminadas: '())
          Una lista de direcciones IP locales que el daemon ntpd debe usar para consultas salientes.

     sensor (predeterminados: '())
          Specify a list of timedelta sensor devices ntpd should use.  ntpd will listen to each sensor that acutally exists and ignore non-existant ones.  See upstream documentation (https://man.openbsd.org/ntpd.conf) for more information.

     server (predeterminadas: %NTP-SERVERS)
          Specify a list of IP addresses or hostnames of NTP servers to synchronize to.

     servers (predeterminados: '())
          Specify a list of IP addresses or hostnames of NTP pools to synchronize to.

     constraint-from (predeterminado: '())
          ntpd can be configured to query the ‘Date’ from trusted HTTPS servers via TLS.  This time information is not used for precision but acts as an authenticated constraint, thereby reducing the impact of unauthenticated NTP man-in-the-middle attacks.  Specify a list of URLs, IP addresses or hostnames of HTTPS servers to provide a constraint.

     constraints-from (predeterminadas: '())
          As with constraint from, specify a list of URLs, IP addresses or hostnames of HTTPS servers to provide a constraint.  Should the hostname resolve to multiple IP addresses, ntpd will calculate a median constraint from all of them.

     allow-large-adjustment? (predeterminado: #f)
          Determines if ntpd is allowed to make an initial adjustment of more than 180 seconds.

 -- Variable Scheme: inetd-service-type
     This service runs the inetd (see inetd invocation (GNU Inetutils)) daemon.  inetd listens for connections on internet sockets, and lazily starts the specified server program when a connection is made on one of these sockets.

     The value of this service is an inetd-configuration object.  The following example configures the inetd daemon to provide the built-in echo service, as well as an smtp service which forwards smtp traffic over ssh to a server smtp-server behind a gateway hostname:

          (service
           inetd-service-type
           (inetd-configuration
            (entries (list
                      (inetd-entry
                       (name "echo")
                       (socket-type 'stream)
                       (protocol "tcp")
                       (wait? #f)
                       (user "root"))
                      (inetd-entry
                       (node "127.0.0.1")
                       (name "smtp")
                       (socket-type 'stream)
                       (protocol "tcp")
                       (wait? #f)
                       (user "root")
                       (program (file-append openssh "/bin/ssh"))
                       (arguments
                        '("ssh" "-qT" "-i" "/ruta/a/la/clave_ssh"
                          "-W" "smtp-server:25" "usuaria@máquina")))))

     See below for more details about inetd-configuration.

 -- Tipo de datos: inetd-configuration
     Tipo de datos que representa la configuración de inetd.

     program (predeterminado: (file-append inetutils "/libexec/inetd"))
          El ejecutable inetd usado.

     entries (predeterminadas: '())
          A list of inetd service entries.  Each entry should be created by the inetd-entry constructor.

 -- Tipo de datos: inetd-entry
     Data type representing an entry in the inetd configuration.  Each entry corresponds to a socket where inetd will listen for requests.

     node (predeterminado: #f)
          Optional string, a comma-separated list of local addresses inetd should use when listening for this service.  See Configuration file (GNU Inetutils) for a complete description of all options.

     name
          A string, the name must correspond to an entry in /etc/services.

     socket-type
          One of 'stream, 'dgram, 'raw, 'rdm or 'seqpacket.

     protocol
          A string, must correspond to an entry in /etc/protocols.

     wait? (predeterminado: #t)
          Whether inetd should wait for the server to exit before listening to new service requests.

     user
          A string containing the user (and, optionally, group) name of the user as whom the server should run.  The group name can be specified in a suffix, separated by a colon or period, i.e. "user", "user:group" or "user.group".

     program (predeterminado: "internal")
          The server program which will serve the requests, or "internal" if inetd should use a built-in service.

     arguments (predeterminados: '())
          A list strings or file-like objects, which are the server program's arguments, starting with the zeroth argument, i.e. the name of the program itself.  For inetd's internal services, this entry must be '() or '("internal").

     See Configuration file (GNU Inetutils) for a more detailed discussion of each configuration field.

 -- Variable Scheme: tor-service-type
     This is the type for a service that runs the Tor (https://torproject.org) anonymous networking daemon.  The service is configured using a <tor-configuration> record.  By default, the Tor daemon runs as the tor unprivileged user, which is a member of the tor group.

 -- Tipo de datos: tor-configuration

     tor (predeterminado: tor)
          The package that provides the Tor daemon.  This package is expected to provide the daemon at bin/tor relative to its output directory.  The default package is the Tor Project's (https://www.torproject.org) implementation.

     config-file (predeterminado: (plain-file "empty" ""))
          The configuration file to use.  It will be appended to a default configuration file, and the final configuration file will be passed to tor via its -f option.  This may be any ``file-like'' object (see file-like objects).  See man tor for details on the configuration file syntax.

     hidden-services (predeterminados: '())
          The list of <hidden-service> records to use.  For any hidden service you include in this list, appropriate configuration to enable the hidden service will be automatically added to the default configuration file.  You may conveniently create <hidden-service> records using the tor-hidden-service procedure described below.

     socks-socket-type (predeterminado: 'tcp)
          The default socket type that Tor should use for its SOCKS socket.  This must be either 'tcp or 'unix.  If it is 'tcp, then by default Tor will listen on TCP port 9050 on the loopback interface (i.e., localhost).  If it is 'unix, then Tor will listen on the UNIX domain socket /var/run/tor/socks-sock, which will be made writable by members of the tor group.

          If you want to customize the SOCKS socket in more detail, leave socks-socket-type at its default value of 'tcp and use config-file to override the default by providing your own SocksPort option.

 -- Procedimiento Scheme: tor-hidden-service NOMBRE RELACIÓN
     Define un servicio oculto Tor llamado NOMBRE y que implementa la ¶ELACIÓN. RELACIÓN es una lista de tuplas puerto/máquina, como:

           '((22 "127.0.0.1:22")
             (80 "127.0.0.1:8080"))

     En este ejemplo, el puerto 22 del servicio oculto se asocia con el puerto 22 local, y el puerto 80 se asocia con el puerto 8080 local.

     Esto crea un directorio /var/lib/tor/hidden-services/NOMBRE, donde el fichero hostname contiene el nombre de máquina .onion para el servicio oculto.

     Véase la documentación del proyecto Tor (https://www.torproject.org/docs/tor-hidden-service.html.en) para más información.

El módulo (gnu services rsync) proporciona los siguientes servicios:

You might want an rsync daemon if you have files that you want available so anyone (or just yourself) can download existing files or upload new files.

 -- Variable Scheme: rsync-service-type
     This is the type for the rsync (https://rsync.samba.org) rsync daemon, rsync-configuration record as in this example:

          (service rsync-service-type)

     See below for details about rsync-configuration.

 -- Tipo de datos: rsync-configuration
     Tipo de datos que representa la configuración para rsync-service.

     package (predeterminado: RSYNC)
          Paquete rsync usado.

     port-number (predeterminado: 873)
          TCP port on which rsync listens for incoming connections.  If port is less than 1024 rsync needs to be started as the root user and group.

     pid-file (predeterminado: "/var/run/rsyncd/rsyncd.pid")
          Name of the file where rsync writes its PID.

     lock-file (predeterminado: "/var/run/rsyncd/rsyncd.lock")
          Name of the file where rsync writes its lock file.

     log-file (predeterminado: "/var/log/rsyncd.log")
          Name of the file where rsync writes its log file.

     use-chroot? (predeterminado: #T)
          Whether to use chroot for rsync shared directory.

     share-path (predeterminado: /srv/rsync)
          Location of the rsync shared directory.

     share-comment (predeterminado: "Rsync share")
          Comment of the rsync shared directory.

     read-only? (predeterminado: #F)
          Read-write permissions to shared directory.

     timeout (predeterminado: 300)
          I/O timeout in seconds.

     user (predeterminada: "ROOT")
          Propietaria del proceso rsync.

     group (predeterminado: "ROOT")
          Grupo del proceso rsync.

     uid (predeterminado: "RSYNCD")
          Nombre o ID de usuaria bajo la cual se efectúan las transferencias desde y hacia el módulo cuando el daemon se ejecuta como root.

     gid (predeterminado: "RSYNCD")
          Nombre o ID de grupo que se usa cuando se accede al módulo.

Es más, (gnu services ssh) proporciona los siguientes servicios.

 -- Procedimiento Scheme: lsh-service [#:host-key "/etc/lsh/host-key"]
     [#:daemonic? #t] [#:interfaces '()] [#:port-number 22]
     [#:allow-empty-passwords? #f] [#:root-login? #f]
     [#:syslog-output? #t] [#:x11-forwarding? #t]
     [#:tcp/ip-forwarding? #t] [#:password-authentication? #t]
     [#:public-key-authentication? #t] [#:initialize? #t]
     Ejecuta el programa lshd de LSH para escuchar en el puerto PORT-NUMBER. HOST-KEY debe designar a un fichero que contiene la clave de la máquina, y que sea legible únicamente por root.

     When DAEMONIC? is true, lshd will detach from the controlling terminal and log its output to syslogd, unless one sets SYSLOG-OUTPUT? to false.  Obviously, it also makes lsh-service depend on existence of syslogd service.  When PID-FILE? is true, lshd writes its PID to the file called PID-FILE.

     When INITIALIZE? is true, automatically create the seed and host key upon service activation if they do not exist yet.  This may take long and require interaction.

     When INITIALIZE? is false, it is up to the user to initialize the randomness generator (see lsh-make-seed (LSH Manual)), and to create a key pair with the private key stored in file HOST-KEY (see lshd basics (LSH Manual)).

     When INTERFACES is empty, lshd listens for connections on all the network interfaces; otherwise, INTERFACES must be a list of host names or addresses.

     ALLOW-EMPTY-PASSWORDS? specifies whether to accept log-ins with empty passwords, and ROOT-LOGIN? specifies whether to accept log-ins as root.

     The other options should be self-descriptive.

 -- Variable Scheme: openssh-service-type
     This is the type for the OpenSSH (http://www.openssh.org) secure shell daemon, sshd.  Its value must be an openssh-configuration record as in this example:

          (service openssh-service-type
                   (openssh-configuration
                     (x11-forwarding? #t)
                     (permit-root-login 'without-password)
                     (authorized-keys
                       `(("alicia" ,(local-file "alicia.pub"))
                         ("rober" ,(local-file "rober.pub"))))))

     See below for details about openssh-configuration.

     This service can be extended with extra authorized keys, as in this example:

          (service-extension openssh-service-type
                             (const `(("carlos"
                                       ,(local-file "carlos.pub")))))

 -- Tipo de datos: openssh-configuration
     Este es el registro de configuración para sshd de OpenSSH.

     pid-file (predeterminado: "/var/run/sshd.pid")
          Name of the file where sshd writes its PID.

     port-number (predeterminado: 22)
          TCP port on which sshd listens for incoming connections.

     permit-root-login (predeterminado: #f)
          This field determines whether and when to allow logins as root.  If #f, root logins are disallowed; if #t, they are allowed.  If it's the symbol 'without-password, then root logins are permitted but not with password-based authentication.

     allow-empty-passwords? (predeterminado: #f)
          When true, users with empty passwords may log in.  When false, they may not.

     password-authentication? (predeterminado: #t)
          When true, users may log in with their password.  When false, they have other authentication methods.

     public-key-authentication? (predeterminado: #t)
          When true, users may log in using public key authentication.  When false, users have to use other authentication method.

          Authorized public keys are stored in ~/.ssh/authorized_keys.  This is used only by protocol version 2.

     x11-forwarding? (predeterminado: #f)
          When true, forwarding of X11 graphical client connections is enabled---in other words, ssh options -X and -Y will work.

     allow-agent-forwarding? (predeterminado: #t)
          Whether to allow agent forwarding.

     allow-tcp-forwarding? (predeterminado: #t)
          Whether to allow TCP forwarding.

     gateway-ports? (predeterminado: #f)
          Whether to allow gateway ports.

     challenge-response-authentication? (predeterminado: #f)
          Specifies whether challenge response authentication is allowed (e.g. via PAM).

     use-pam? (predeterminado: #t)
          Enables the Pluggable Authentication Module interface.  If set to #t, this will enable PAM authentication using challenge-response-authentication? and password-authentication?, in addition to PAM account and session module processing for all authentication types.

          Because PAM challenge response authentication usually serves an equivalent role to password authentication, you should disable either challenge-response-authentication? or password-authentication?.

     print-last-log? (predeterminado: #t)
          Especifica si sshd debe imprimir la fecha y hora del último ingreso al sistema de la usuaria cuando una usuaria ingresa interactivamente.

     subsystems (predeterminados: '(("sftp" "internal-sftp")))
          Configures external subsystems (e.g. file transfer daemon).

          This is a list of two-element lists, each of which containing the subsystem name and a command (with optional arguments) to execute upon subsystem request.

          The command internal-sftp implements an in-process SFTP server. Alternately, one can specify the sftp-server command:

               (service openssh-service-type
                        (openssh-configuration
                         (subsystems
                          `(("sftp" ,(file-append openssh "/libexec/sftp-server"))))))

     accepted-environment (predeterminado: '())
          List of strings describing which environment variables may be exported.

          Each string gets on its own line.  See the AcceptEnv option in man sshd_config.

          This example allows ssh-clients to export the COLORTERM variable.  It is set by terminal emulators, which support colors.  You can use it in your shell's ressource file to enable colors for the prompt and commands if this variable is set.

               (service openssh-service-type
                        (openssh-configuration
                          (accepted-environment '("COLORTERM"))))

     authorized-keys (predeterminadas: '())
          This is the list of authorized keys.  Each element of the list is a user name followed by one or more file-like objects that represent SSH public keys.  For example:

               (openssh-configuration
                 (authorized-keys
                   `(("rekado" ,(local-file "rekado.pub"))
                     ("chris" ,(local-file "chris.pub"))
                     ("root" ,(local-file "rekado.pub") ,(local-file "chris.pub")))))

          registers the specified public keys for user accounts rekado, chris, and root.

          Additional authorized keys can be specified via service-extension.

          Note that this does not interfere with the use of ~/.ssh/authorized_keys.

     log-level (predeterminado: 'info)
          This is a symbol specifying the logging level: quiet, fatal, error, info, verbose, debug, etc.  See the man page for sshd_config for the full list of level names.

     extra-content (predeterminado: "")
          This field can be used to append arbitrary text to the configuration file. It is especially useful for elaborate configurations that cannot be expressed otherwise.  This configuration, for example, would generally disable root logins, but permit them from one specific IP address:

               (openssh-configuration
                 (extra-content "\
               Match Address 192.168.0.1
                 PermitRootLogin yes"))

 -- Procedimiento Scheme: dropbear-service [CONFIG]
     Run the Dropbear SSH daemon (https://matt.ucc.asn.au/dropbear/dropbear.html) with the given CONFIG, a <dropbear-configuration> object.

     For example, to specify a Dropbear service listening on port 1234, add this call to the operating system's services field:

          (dropbear-service (dropbear-configuration
                              (port-number 1234)))

 -- Tipo de datos: dropbear-configuration
     This data type represents the configuration of a Dropbear SSH daemon.

     dropbear (predeterminado: DROPBEAR)
          El paquete de Dropbear usado.

     port-number (predeterminado: 22)
          Puerto TCP donde el daemon espera conexiones entrantes.

     syslog-output? (predeterminado: #t)
          Whether to enable syslog output.

     pid-file (predeterminado: "/var/run/dropbear.pid")
          File name of the daemon's PID file.

     root-login? (predeterminado: #f)
          Whether to allow root logins.

     allow-empty-passwords? (predeterminado: #f)
          Whether to allow empty passwords.

     password-authentication? (predeterminado: #t)
          Whether to enable password-based authentication.

 -- Variable Scheme: %facebook-host-aliases
     This variable contains a string for use in /etc/hosts (see Host Names (The GNU C Library Reference Manual)).  Each line contains a entry that maps a known server name of the Facebook on-line service---e.g., www.facebook.com---to the local host---127.0.0.1 or its IPv6 equivalent, ::1.

     This variable is typically used in the hosts-file field of an operating-system declaration (see /etc/hosts):

          (use-modules (gnu) (guix))

          (operating-system
            (host-name "micompu")
            ;; ...
            (hosts-file
              ;; Crea un fichero /etc/hosts file con alias para "localhost"
              ;; y "micompu", así como los servidores de facebook.
              (plain-file "hosts"
                          (string-append (local-host-aliases host-name)
                                         %facebook-host-aliases))))

     Este mecanismo puede impedir a los programas que se ejecutan localmente, como navegadores Web, el acceso a Facebook.

El módulo (gnu services avahi) proporciona la siguiente definición.

 -- Scheme Variable: avahi-service-type
     This is the service that runs avahi-daemon, a system-wide mDNS/DNS-SD responder that allows for service discovery and ``zero-configuration'' host name lookups (see http://avahi.org/). Its value must be a zero-configuration record---see below.

     This service extends the name service cache daemon (nscd) so that it can resolve .local host names using nss-mdns (http://0pointer.de/lennart/projects/nss-mdns/).  See Selector de servicios de nombres, for information on host name resolution.

     Additionally, add the AVAHI package to the system profile so that commands such as avahi-browse are directly usable.

 -- Data Type: avahi-configuration
     Data type representation the configuration for Avahi.

     host-name (default: #f)
          If different from #f, use that as the host name to publish for this machine; otherwise, use the machine's actual host name.

     publish? (default: #t)
          When true, allow host names and services to be published (broadcast) over the network.

     publish-workstation? (default: #t)
          When true, avahi-daemon publishes the machine's host name and IP address via mDNS on the local network.  To view the host names published on your local network, you can run:

               avahi-browse _workstation._tcp

     wide-area? (default: #f)
          When true, DNS-SD over unicast DNS is enabled.

     ipv4? (default: #t)
     ipv6? (default: #t)
          These fields determine whether to use IPv4/IPv6 sockets.

     domains-to-browse (default: '())
          This is a list of domains to browse.

 -- Variable Scheme: openvswitch-service-type
     This is the type of the Open vSwitch (http://www.openvswitch.org) service, whose value should be an openvswitch-configuration object.

 -- Tipo de datos: openvswitch-configuration
     Data type representing the configuration of Open vSwitch, a multilayer virtual switch which is designed to enable massive network automation through programmatic extension.

     package (predeterminado: OPENVSWITCH)
          Package object of the Open vSwitch.

Sistema X Window
----------------

Support for the X Window graphical display system---specifically Xorg---is provided by the (gnu services xorg) module.  Note that there is no xorg-service procedure.  Instead, the X server is started by the login manager, by default the GNOME Display Manager (GDM).

GDM of course allows users to log in into window managers and desktop environments other than GNOME; for those using GNOME, GDM is required for features such as automatic screen locking.

To use X11, you must install at least one window manager---for example the windowmaker or openbox packages---preferably by adding it to the packages field of your operating system definition (see system-wide packages).

 -- Scheme Variable: gdm-service-type
     This is the type for the GNOME Desktop Manager (https://wiki.gnome.org/Projects/GDM/) (GDM), a program that manages graphical display servers and handles graphical user logins.  Its value must be a gdm-configuration (see below.)

     GDM looks for session types described by the .desktop files in /run/current-system/profile/share/xsessions and allows users to choose a session from the log-in screen.  Packages such as gnome, xfce, and i3 provide .desktop files; adding them to the system-wide set of packages automatically makes them available at the log-in screen.

     In addition, ~/.xsession files are honored.  When available, ~/.xsession must be an executable that starts a window manager and/or other X clients.

 -- Data Type: gdm-configuration

     auto-login? (predeterminado: #f)
     default-user (default: #f)
          When auto-login? is false, GDM presents a log-in screen.

          When auto-login? is true, GDM logs in directly as default-user.

     gnome-shell-assets (default: ...)
          List of GNOME Shell assets needed by GDM: icon theme, fonts, etc.

     xorg-configuration (default: (xorg-configuration))
          Configuration of the Xorg graphical server.

     xsession (default: (xinitrc))
          Script to run before starting a X session.

     dbus-daemon (default: dbus-daemon-wrapper)
          File name of the dbus-daemon executable.

     gdm (default: gdm)
          The GDM package to use.

 -- Variable Scheme: slim-service-type
     Este es el tipo para el gestor de ingreso al sistema gráfico para X11 SLiM.

     Like GDM, SLiM looks for session types described by .desktop files and allows users to choose a session from the log-in screen using F1. It also honors ~/.xsession files.

 -- Tipo de datos: slim-configuration
     Data type representing the configuration of slim-service-type.

     allow-empty-passwords? (predeterminado: #t)
          Whether to allow logins with empty passwords.

     auto-login? (predeterminado: #f)
     default-user (predeterminado: "")
          When auto-login? is false, SLiM presents a log-in screen.

          When auto-login? is true, SLiM logs in directly as default-user.

     theme (predeterminado: %default-slim-theme)
     theme-name (predeterminado: %default-slim-theme-name)
          The graphical theme to use and its name.

     auto-login-session (predeterminado: #f)
          If true, this must be the name of the executable to start as the default session---e.g., (file-append windowmaker "/bin/windowmaker").

          If false, a session described by one of the available .desktop files in /run/current-system/profile and ~/.guix-profile will be used.

               You must install at least one window manager in the system profile or in your user profile.  Failing to do that, if auto-login-session is false, you will be unable to log in.

     xorg-configuration (default (xorg-configuration))
          Configuration of the Xorg graphical server.

     xauth (predeterminado: xauth)
          El paquete XAuth usado.

     shepherd (predeterminado: shepherd)
          The Shepherd package used when invoking halt and reboot.

     sessreg (predeterminado: sessreg)
          The sessreg package used in order to register the session.

     slim (predeterminado: slim)
          El paquete SLiM usado.

 -- Variable Scheme: %default-theme
 -- Variable Scheme: %default-theme-name
     The default SLiM theme and its name.

 -- Tipo de datos: sddm-configuration
     This is the data type representing the sddm service configuration.

     display-server (predeterminado: "x11")
          Select display server to use for the greeter. Valid values are "x11" or "wayland".

     numlock (predeterminado: "on")
          Valid values are "on", "off" or "none".

     halt-command (predeterminado #~(string-apppend #$shepherd "/sbin/halt"))
          Command to run when halting.

     reboot-command (predeterminado #~(string-append #$shepherd "/sbin/reboot"))
          Command to run when rebooting.

     theme (predeterminado "maldives")
          Theme to use. Default themes provided by SDDM are "elarun" or "maldives".

     themes-directory (predeterminado "/run/current-system/profile/share/sddm/themes")
          Directory to look for themes.

     faces-directory (predeterminado "/run/current-system/profile/share/sddm/faces")
          Directory to look for faces.

     default-path (predeterminado "/run/current-system/profile/bin")
          Default PATH to use.

     minimum-uid (predeterminado 1000)
          Minimum UID to display in SDDM.

     maximum-uid (predeterminado 2000)
          Maximum UID to display in SDDM

     remember-last-user? (predeterminado #t)
          Remember last user.

     remember-last-session? (predeterminado #t)
          Remember last session.

     hide-users (predeterminado "")
          Usernames to hide from SDDM greeter.

     hide-shells (predeterminado #~(string-append #$shadow "/sbin/nologin"))
          Users with shells listed will be hidden from the SDDM greeter.

     session-command (predeterminado #~(string-append #$sddm "/share/sddm/scripts/wayland-session"))
          Script to run before starting a wayland session.

     sessions-directory (predeterminado "/run/current-system/profile/share/wayland-sessions")
          Directory to look for desktop files starting wayland sessions.

     xorg-configuration (default (xorg-configuration))
          Configuration of the Xorg graphical server.

     xauth-path (predeterminado #~(string-append #$xauth "/bin/xauth"))
          Path to xauth.

     xephyr-path (predeterminado #~(string-append #$xorg-server "/bin/Xephyr"))
          Path to Xephyr.

     xdisplay-start (predeterminado #~(string-append #$sddm "/share/sddm/scripts/Xsetup"))
          Script to run after starting xorg-server.

     xdisplay-stop (predeterminado #~(string-append #$sddm "/share/sddm/scripts/Xstop"))
          Script to run before stopping xorg-server.

     xsession-command (predeterminado: xinitrc)
          Script to run before starting a X session.

     xsessions-directory (predeterminado: "/run/current-system/profile/share/xsessions")
          Directory to look for desktop files starting X sessions.

     minimum-vt (predeterminado: 7)
          Minimum VT to use.

     auto-login-user (predeterminado "")
          User to use for auto-login.

     auto-login-session (predeterminado "")
          Desktop file to use for auto-login.

     relogin? (predeterminado #f)
          Relogin after logout.

 -- Procedimiento Scheme: sddm-service config
     Return a service that spawns the SDDM graphical login manager for config of type <sddm-configuration>.

            (sddm-service (sddm-configuration
                           (auto-login-user "Alicia")
                           (auto-login-session "xfce.desktop")))

 -- Data Type: xorg-configuration
     This data type represents the configuration of the Xorg graphical display server.  Note that there is not Xorg service; instead, the X server is started by a ``display manager'' such as GDM, SDDM, and SLiM.  Thus, the configuration of these display managers aggregates an xorg-configuration record.

     modules (default: %default-xorg-modules)
          This is a list of module packages loaded by the Xorg server---e.g., xf86-video-vesa, xf86-input-keyboard, and so on.

     fonts (default: %default-xorg-fonts)
          This is a list of font directories to add to the server's font path.

     drivers (default: '())
          This must be either the empty list, in which case Xorg chooses a graphics driver automatically, or a list of driver names that will be tried in this order---e.g., ("modesetting" "vesa").

     resolutions (default: '())
          When resolutions is the empty list, Xorg chooses an appropriate screen resolution.  Otherwise, it must be a list of resolutions---e.g., ((1024 768) (640 480)).

     keyboard-layout (predeterminada: #f)
          If this is #f, Xorg uses the default keyboard layout---usually US English (``qwerty'') for a 105-key PC keyboard.

          Otherwise this must be a keyboard-layout object specifying the keyboard layout in use when Xorg is running.  See Distribución de teclado, for more information on how to specify the keyboard layout.

     extra-config (default: '())
          This is a list of strings or objects appended to the configuration file.  It is used to pass extra text to be added verbatim to the configuration file.

     server (default: xorg-server)
          This is the package providing the Xorg server.

     server-arguments (default: %default-xorg-server-arguments)
          This is the list of command-line arguments to pass to the X server.  The default is -nolisten tcp.

 -- Scheme Procedure: set-xorg-configuration CONFIG
     [LOGIN-MANAGER-SERVICE-TYPE] Tell the log-in manager (of type
     LOGIN-MANAGER-SERVICE-TYPE) to use CONFIG, an <xorg-configuration> record.

     Since the Xorg configuration is embedded in the log-in manager's configuration---e.g., gdm-configuration---this procedure provides a shorthand to set the Xorg configuration.

 -- Scheme Procedure: xorg-start-command [CONFIG]
     Return a startx script in which the modules, fonts, etc. specified in CONFIG, are available.  The result should be used in place of startx.

     Usually the X server is started by a login manager.

 -- Procedimiento Scheme: screen-locker-service PAQUETE [PROGRAMA]
     Añade PAQUETE, un paquete para un bloqueador de sesión o un salvapantallas cuya orden es PROGRAMA, al conjunto de programas setuid y añade una entrada PAM para él. Por ejemplo:

          (screen-locker-service xlockmore "xlock")

     permite usar el viejo XlockMore.

Servicios de impresión
----------------------

The (gnu services cups) module provides a Guix service definition for the CUPS printing service.  To add printer support to a Guix system, add a cups-service to the operating system definition:

 -- Variable Scheme: cups-service-type
     The service type for the CUPS print server.  Its value should be a valid CUPS configuration (see below).  To use the default settings, simply write:

          (service cups-service-type)

The CUPS configuration controls the basic things about your CUPS installation: what interfaces it listens on, what to do if a print job fails, how much logging to do, and so on.  To actually add a printer, you have to visit the http://localhost:631 URL, or use a tool such as GNOME's printer configuration services.  By default, configuring a CUPS service will generate a self-signed certificate if needed, for secure connections to the print server.

Suppose you want to enable the Web interface of CUPS and also add support for Epson printers via the escpr package and for HP printers via the hplip-minimal package.  You can do that directly, like this (you need to use the (gnu packages cups) module):

     (service cups-service-type
              (cups-configuration
                (web-interface? #t)
                (extensions
                  (list cups-filters escpr hplip-minimal))))

Note: If you wish to use the Qt5 based GUI which comes with the hplip package then it is suggested that you install the hplip package, either in your OS configuration file or as your user.

The available configuration parameters follow.  Each parameter definition is preceded by its type; for example, string-list foo indicates that the foo parameter should be specified as a list of strings.  There is also a way to specify the configuration as a string, if you have an old cupsd.conf file that you want to port over from some other system; see the end for more details.

Available cups-configuration fields are:

 -- cups-configuration parameter: package cups
     El paquete CUPS.

 -- cups-configuration parameter: package-list extensions
     Drivers and other extensions to the CUPS package.

 -- cups-configuration parameter: files-configuration files-configuration
     Configuration of where to write logs, what directories to use for print spools, and related privileged configuration parameters.

     Available files-configuration fields are:

      -- files-configuration parameter: log-location access-log
          Defines the access log filename.  Specifying a blank filename disables access log generation.  The value stderr causes log entries to be sent to the standard error file when the scheduler is running in the foreground, or to the system log daemon when run in the background.  The value syslog causes log entries to be sent to the system log daemon. The server name may be included in filenames using the string %s, as in /var/log/cups/%s-access_log.

          Defaults to "/var/log/cups/access_log".

      -- files-configuration parameter: file-name cache-dir
          Where CUPS should cache data.

          Defaults to "/var/cache/cups".

      -- files-configuration parameter: string config-file-perm
          Specifies the permissions for all configuration files that the scheduler writes.

          Note that the permissions for the printers.conf file are currently masked to only allow access from the scheduler user (typically root).  This is done because printer device URIs sometimes contain sensitive authentication information that should not be generally known on the system.  There is no way to disable this security feature.

          Defaults to "0640".

      -- files-configuration parameter: log-location error-log
          Defines the error log filename.  Specifying a blank filename disables access log generation.  The value stderr causes log entries to be sent to the standard error file when the scheduler is running in the foreground, or to the system log daemon when run in the background.  The value syslog causes log entries to be sent to the system log daemon.  The server name may be included in filenames using the string %s, as in /var/log/cups/%s-error_log.

          Defaults to "/var/log/cups/error_log".

      -- files-configuration parameter: string fatal-errors
          Specifies which errors are fatal, causing the scheduler to exit.  The kind strings are:

          none
               No errors are fatal.

          all
               All of the errors below are fatal.

          browse
               Browsing initialization errors are fatal, for example failed connections to the DNS-SD daemon.

          config
               Configuration file syntax errors are fatal.

          listen
               Listen or Port errors are fatal, except for IPv6 failures on the loopback or any addresses.

          log
               Log file creation or write errors are fatal.

          permissions
               Bad startup file permissions are fatal, for example shared TLS certificate and key files with world-read permissions.

          Defaults to "all -browse".

      -- files-configuration parameter: boolean file-device?
          Specifies whether the file pseudo-device can be used for new printer queues.  The URI file:///dev/null is always allowed.

          El valor predeterminado es #f

      -- files-configuration parameter: string group
          Specifies the group name or ID that will be used when executing external programs.

          Defaults to "lp".

      -- files-configuration parameter: string log-file-perm
          Specifies the permissions for all log files that the scheduler writes.

          Defaults to "0644".

      -- files-configuration parameter: log-location page-log
          Defines the page log filename.  Specifying a blank filename disables access log generation.  The value stderr causes log entries to be sent to the standard error file when the scheduler is running in the foreground, or to the system log daemon when run in the background.  The value syslog causes log entries to be sent to the system log daemon.  The server name may be included in filenames using the string %s, as in /var/log/cups/%s-page_log.

          Defaults to "/var/log/cups/page_log".

      -- files-configuration parameter: string remote-root
          Specifies the username that is associated with unauthenticated accesses by clients claiming to be the root user.  The default is remroot.

          Defaults to "remroot".

      -- files-configuration parameter: file-name request-root
          Specifies the directory that contains print jobs and other HTTP request data.

          Defaults to "/var/spool/cups".

      -- files-configuration parameter: sandboxing sandboxing
          Specifies the level of security sandboxing that is applied to print filters, backends, and other child processes of the scheduler; either relaxed or strict.  This directive is currently only used/supported on macOS.

          Defaults to strict.

      -- files-configuration parameter: file-name server-keychain
          Specifies the location of TLS certificates and private keys.  CUPS will look for public and private keys in this directory: a .crt files for PEM-encoded certificates and corresponding .key files for PEM-encoded private keys.

          Defaults to "/etc/cups/ssl".

      -- files-configuration parameter: file-name server-root
          Specifies the directory containing the server configuration files.

          Defaults to "/etc/cups".

      -- files-configuration parameter: boolean sync-on-close?
          Specifies whether the scheduler calls fsync(2) after writing configuration or state files.

          El valor predeterminado es #f

      -- files-configuration parameter: space-separated-string-list system-group
          Specifies the group(s) to use for @SYSTEM group authentication.

      -- files-configuration parameter: file-name temp-dir
          Specifies the directory where temporary files are stored.

          Defaults to "/var/spool/cups/tmp".

      -- files-configuration parameter: string user
          Specifies the user name or ID that is used when running external programs.

          Defaults to "lp".

 -- cups-configuration parameter: access-log-level access-log-level
     Specifies the logging level for the AccessLog file.  The config level logs when printers and classes are added, deleted, or modified and when configuration files are accessed or updated.  The actions level logs when print jobs are submitted, held, released, modified, or canceled, and any of the conditions for config.  The all level logs all requests.

     Defaults to actions.

 -- cups-configuration parameter: boolean auto-purge-jobs?
     Specifies whether to purge job history data automatically when it is no longer required for quotas.

     El valor predeterminado es #f

 -- cups-configuration parameter: browse-local-protocols browse-local-protocols
     Specifies which protocols to use for local printer sharing.

     Defaults to dnssd.

 -- cups-configuration parameter: boolean browse-web-if?
     Specifies whether the CUPS web interface is advertised.

     El valor predeterminado es #f

 -- cups-configuration parameter: boolean browsing?
     Specifies whether shared printers are advertised.

     El valor predeterminado es #f

 -- cups-configuration parameter: string classification
     Specifies the security classification of the server.  Any valid banner name can be used, including "classified", "confidential", "secret", "topsecret", and "unclassified", or the banner can be omitted to disable secure printing functions.

     El valor predeterminado es "".

 -- cups-configuration parameter: boolean classify-override?
     Specifies whether users may override the classification (cover page) of individual print jobs using the job-sheets option.

     El valor predeterminado es #f

 -- cups-configuration parameter: default-auth-type default-auth-type
     Specifies the default type of authentication to use.

     Defaults to Basic.

 -- cups-configuration parameter: default-encryption default-encryption
     Specifies whether encryption will be used for authenticated requests.

     Defaults to Required.

 -- cups-configuration parameter: string default-language
     Specifies the default language to use for text and web content.

     Defaults to "en".

 -- cups-configuration parameter: string default-paper-size
     Specifies the default paper size for new print queues.  "Auto" uses a locale-specific default, while "None" specifies there is no default paper size.  Specific size names are typically "Letter" or "A4".

     Defaults to "Auto".

 -- cups-configuration parameter: string default-policy
     Specifies the default access policy to use.

     Defaults to "default".

 -- cups-configuration parameter: boolean default-shared?
     Specifies whether local printers are shared by default.

     Defaults to #t.

 -- cups-configuration parameter: non-negative-integer dirty-clean-interval
     Specifies the delay for updating of configuration and state files, in seconds.  A value of 0 causes the update to happen as soon as possible, typically within a few milliseconds.

     El valor predeterminado es 30.

 -- cups-configuration parameter: error-policy error-policy
     Specifies what to do when an error occurs.  Possible values are abort-job, which will discard the failed print job; retry-job, which will retry the job at a later time; retry-this-job, which retries the failed job immediately; and stop-printer, which stops the printer.

     Defaults to stop-printer.

 -- cups-configuration parameter: non-negative-integer filter-limit
     Specifies the maximum cost of filters that are run concurrently, which can be used to minimize disk, memory, and CPU resource problems.  A limit of 0 disables filter limiting.  An average print to a non-PostScript printer needs a filter limit of about 200.  A PostScript printer needs about half that (100).  Setting the limit below these thresholds will effectively limit the scheduler to printing a single job at any time.

     El valor predeterminado es 0.

 -- cups-configuration parameter: non-negative-integer filter-nice
     Specifies the scheduling priority of filters that are run to print a job. The nice value ranges from 0, the highest priority, to 19, the lowest priority.

     El valor predeterminado es 0.

 -- cups-configuration parameter: host-name-lookups host-name-lookups
     Specifies whether to do reverse lookups on connecting clients.  The double setting causes cupsd to verify that the hostname resolved from the address matches one of the addresses returned for that hostname.  Double lookups also prevent clients with unregistered addresses from connecting to your server.  Only set this option to #t or double if absolutely required.

     El valor predeterminado es #f

 -- cups-configuration parameter: non-negative-integer job-kill-delay
     Specifies the number of seconds to wait before killing the filters and backend associated with a canceled or held job.

     El valor predeterminado es 30.

 -- cups-configuration parameter: non-negative-integer job-retry-interval
     Specifies the interval between retries of jobs in seconds.  This is typically used for fax queues but can also be used with normal print queues whose error policy is retry-job or retry-current-job.

     El valor predeterminado es 30.

 -- cups-configuration parameter: non-negative-integer job-retry-limit
     Specifies the number of retries that are done for jobs.  This is typically used for fax queues but can also be used with normal print queues whose error policy is retry-job or retry-current-job.

     Defaults to 5.

 -- cups-configuration parameter: boolean keep-alive?
     Specifies whether to support HTTP keep-alive connections.

     Defaults to #t.

 -- cups-configuration parameter: non-negative-integer keep-alive-timeout
     Specifies how long an idle client connection remains open, in seconds.

     El valor predeterminado es 30.

 -- cups-configuration parameter: non-negative-integer limit-request-body
     Specifies the maximum size of print files, IPP requests, and HTML form data.  A limit of 0 disables the limit check.

     El valor predeterminado es 0.

 -- cups-configuration parameter: multiline-string-list listen
     Listens on the specified interfaces for connections.  Valid values are of the form ADDRESS:PORT, where ADDRESS is either an IPv6 address enclosed in brackets, an IPv4 address, or * to indicate all addresses.  Values can also be file names of local UNIX domain sockets.  The Listen directive is similar to the Port directive but allows you to restrict access to specific interfaces or networks.

 -- cups-configuration parameter: non-negative-integer listen-back-log
     Specifies the number of pending connections that will be allowed.  This normally only affects very busy servers that have reached the MaxClients limit, but can also be triggered by large numbers of simultaneous connections.  When the limit is reached, the operating system will refuse additional connections until the scheduler can accept the pending ones.

     Defaults to 128.

 -- cups-configuration parameter: location-access-control-list location-access-controls
     Specifies a set of additional access controls.

     Available location-access-controls fields are:

      -- location-access-controls parameter: file-name path
          Specifies the URI path to which the access control applies.

      -- location-access-controls parameter: access-control-list access-controls
          Access controls for all access to this path, in the same format as the access-controls of operation-access-control.

          Defaults to ().

      -- location-access-controls parameter: method-access-control-list method-access-controls
          Access controls for method-specific access to this path.

          Defaults to ().

          Available method-access-controls fields are:

           -- method-access-controls parameter: boolean reverse?
               If #t, apply access controls to all methods except the listed methods.  Otherwise apply to only the listed methods.

               El valor predeterminado es #f

           -- method-access-controls parameter: method-list methods
               Methods to which this access control applies.

               Defaults to ().

           -- method-access-controls parameter: access-control-list access-controls
               Access control directives, as a list of strings.  Each string should be one directive, such as "Order allow,deny".

               Defaults to ().

 -- cups-configuration parameter: non-negative-integer log-debug-history
     Specifies the number of debugging messages that are retained for logging if an error occurs in a print job.  Debug messages are logged regardless of the LogLevel setting.

     Defaults to 100.

 -- cups-configuration parameter: log-level log-level
     Specifies the level of logging for the ErrorLog file.  The value none stops all logging while debug2 logs everything.

     Defaults to info.

 -- cups-configuration parameter: log-time-format log-time-format
     Specifies the format of the date and time in the log files.  The value standard logs whole seconds while usecs logs microseconds.

     Defaults to standard.

 -- cups-configuration parameter: non-negative-integer max-clients
     Specifies the maximum number of simultaneous clients that are allowed by the scheduler.

     Defaults to 100.

 -- cups-configuration parameter: non-negative-integer max-clients-per-host
     Specifies the maximum number of simultaneous clients that are allowed from a single address.

     Defaults to 100.

 -- cups-configuration parameter: non-negative-integer max-copies
     Specifies the maximum number of copies that a user can print of each job.

     Defaults to 9999.

 -- cups-configuration parameter: non-negative-integer max-hold-time
     Specifies the maximum time a job may remain in the indefinite hold state before it is canceled.  A value of 0 disables cancellation of held jobs.

     El valor predeterminado es 0.

 -- cups-configuration parameter: non-negative-integer max-jobs
     Specifies the maximum number of simultaneous jobs that are allowed.  Set to 0 to allow an unlimited number of jobs.

     Defaults to 500.

 -- cups-configuration parameter: non-negative-integer max-jobs-per-printer
     Specifies the maximum number of simultaneous jobs that are allowed per printer.  A value of 0 allows up to MaxJobs jobs per printer.

     El valor predeterminado es 0.

 -- cups-configuration parameter: non-negative-integer max-jobs-per-user
     Specifies the maximum number of simultaneous jobs that are allowed per user.  A value of 0 allows up to MaxJobs jobs per user.

     El valor predeterminado es 0.

 -- cups-configuration parameter: non-negative-integer max-job-time
     Specifies the maximum time a job may take to print before it is canceled, in seconds.  Set to 0 to disable cancellation of "stuck" jobs.

     Defaults to 10800.

 -- cups-configuration parameter: non-negative-integer max-log-size
     Specifies the maximum size of the log files before they are rotated, in bytes.  The value 0 disables log rotation.

     Defaults to 1048576.

 -- cups-configuration parameter: non-negative-integer multiple-operation-timeout
     Specifies the maximum amount of time to allow between files in a multiple file print job, in seconds.

     Defaults to 300.

 -- cups-configuration parameter: string page-log-format
     Specifies the format of PageLog lines.  Sequences beginning with percent (%) characters are replaced with the corresponding information, while all other characters are copied literally.  The following percent sequences are recognized:

     %%
          insert a single percent character

     %{name}
          insert the value of the specified IPP attribute

     %C
          insert the number of copies for the current page

     %P
          insert the current page number

     %T
          insert the current date and time in common log format

     %j
          insert the job ID

     %p
          insert the printer name

     %u
          insert the username

     A value of the empty string disables page logging.  The string %p %u %j %T %P %C %{job-billing} %{job-originating-host-name} %{job-name} %{media} %{sides} creates a page log with the standard items.

     El valor predeterminado es "".

 -- cups-configuration parameter: environment-variables environment-variables
     Passes the specified environment variable(s) to child processes; a list of strings.

     Defaults to ().

 -- cups-configuration parameter: policy-configuration-list policies
     Specifies named access control policies.

     Available policy-configuration fields are:

      -- policy-configuration parameter: string name
          Name of the policy.

      -- policy-configuration parameter: string job-private-access
          Specifies an access list for a job's private values.  @ACL maps to the printer's requesting-user-name-allowed or requesting-user-name-denied values.  @OWNER maps to the job's owner.  @SYSTEM maps to the groups listed for the system-group field of the files-config configuration, which is reified into the cups-files.conf(5) file.  Other possible elements of the access list include specific user names, and @GROUP to indicate members of a specific group.  The access list may also be simply all or default.

          Defaults to "@OWNER @SYSTEM".

      -- policy-configuration parameter: string job-private-values
          Specifies the list of job values to make private, or all, default, or none.

          Defaults to "job-name job-originating-host-name job-originating-user-name phone".

      -- policy-configuration parameter: string subscription-private-access
          Specifies an access list for a subscription's private values.  @ACL maps to the printer's requesting-user-name-allowed or requesting-user-name-denied values.  @OWNER maps to the job's owner.  @SYSTEM maps to the groups listed for the system-group field of the files-config configuration, which is reified into the cups-files.conf(5) file.  Other possible elements of the access list include specific user names, and @GROUP to indicate members of a specific group.  The access list may also be simply all or default.

          Defaults to "@OWNER @SYSTEM".

      -- policy-configuration parameter: string subscription-private-values
          Specifies the list of job values to make private, or all, default, or none.

          Defaults to "notify-events notify-pull-method notify-recipient-uri notify-subscriber-user-name notify-user-data".

      -- policy-configuration parameter: operation-access-control-list access-controls
          Access control by IPP operation.

          Defaults to ().

 -- cups-configuration parameter: boolean-or-non-negative-integer preserve-job-files
     Specifies whether job files (documents) are preserved after a job is printed.  If a numeric value is specified, job files are preserved for the indicated number of seconds after printing.  Otherwise a boolean value applies indefinitely.

     Defaults to 86400.

 -- cups-configuration parameter: boolean-or-non-negative-integer preserve-job-history
     Specifies whether the job history is preserved after a job is printed.  If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing.  If #t, the job history is preserved until the MaxJobs limit is reached.

     Defaults to #t.

 -- cups-configuration parameter: non-negative-integer reload-timeout
     Specifies the amount of time to wait for job completion before restarting the scheduler.

     El valor predeterminado es 30.

 -- cups-configuration parameter: string rip-cache
     Specifies the maximum amount of memory to use when converting documents into bitmaps for a printer.

     Defaults to "128m".

 -- cups-configuration parameter: string server-admin
     Specifies the email address of the server administrator.

     Defaults to "root@localhost.localdomain".

 -- cups-configuration parameter: host-name-list-or-* server-alias
     The ServerAlias directive is used for HTTP Host header validation when clients connect to the scheduler from external interfaces.  Using the special name * can expose your system to known browser-based DNS rebinding attacks, even when accessing sites through a firewall.  If the auto-discovery of alternate names does not work, we recommend listing each alternate name with a ServerAlias directive instead of using *.

     Defaults to *.

 -- cups-configuration parameter: string server-name
     Specifies the fully-qualified host name of the server.

     Defaults to "localhost".

 -- cups-configuration parameter: server-tokens server-tokens
     Specifies what information is included in the Server header of HTTP responses.  None disables the Server header.  ProductOnly reports CUPS.  Major reports CUPS 2.  Minor reports CUPS 2.0.  Minimal reports CUPS 2.0.0. OS reports CUPS 2.0.0 (UNAME) where UNAME is the output of the uname command.  Full reports CUPS 2.0.0 (UNAME) IPP/2.0.

     Defaults to Minimal.

 -- cups-configuration parameter: string set-env
     Set the specified environment variable to be passed to child processes.

     Defaults to "variable value".

 -- cups-configuration parameter: multiline-string-list ssl-listen
     Listens on the specified interfaces for encrypted connections.  Valid values are of the form ADDRESS:PORT, where ADDRESS is either an IPv6 address enclosed in brackets, an IPv4 address, or * to indicate all addresses.

     Defaults to ().

 -- cups-configuration parameter: ssl-options ssl-options
     Sets encryption options.  By default, CUPS only supports encryption using TLS v1.0 or higher using known secure cipher suites.  The AllowRC4 option enables the 128-bit RC4 cipher suites, which are required for some older clients that do not implement newer ones.  The AllowSSL3 option enables SSL v3.0, which is required for some older clients that do not support TLS v1.0.

     Defaults to ().

 -- cups-configuration parameter: boolean strict-conformance?
     Specifies whether the scheduler requires clients to strictly adhere to the IPP specifications.

     El valor predeterminado es #f

 -- cups-configuration parameter: non-negative-integer timeout
     Specifies the HTTP request timeout, in seconds.

     Defaults to 300.

 -- cups-configuration parameter: boolean web-interface?
     Specifies whether the web interface is enabled.

     El valor predeterminado es #f

At this point you're probably thinking ``oh dear, Guix manual, I like you but you can stop already with the configuration options''.  Indeed. However, one more point: it could be that you have an existing cupsd.conf that you want to use.  In that case, you can pass an opaque-cups-configuration as the configuration of a cups-service-type.

Available opaque-cups-configuration fields are:

 -- opaque-cups-configuration parameter: package cups
     El paquete CUPS.

 -- opaque-cups-configuration parameter: string cupsd.conf
     The contents of the cupsd.conf, as a string.

 -- opaque-cups-configuration parameter: string cups-files.conf
     The contents of the cups-files.conf file, as a string.

For example, if your cupsd.conf and cups-files.conf are in strings of the same name, you could instantiate a CUPS service like this:

     (service cups-service-type
              (opaque-cups-configuration
                (cupsd.conf cupsd.conf)
                (cups-files.conf cups-files.conf)))

Servicios de escritorio
-----------------------

The (gnu services desktop) module provides services that are usually useful in the context of a ``desktop'' setup---that is, on a machine running a graphical display server, possibly with graphical user interfaces, etc. It also defines services that provide specific desktop environments like GNOME, Xfce or MATE.

To simplify things, the module defines a variable containing the set of services that users typically expect on a machine with a graphical environment and networking:

 -- Variable Scheme: %desktop-services
     This is a list of services that builds upon %BASE-SERVICES and adds or adjusts services for a typical ``desktop'' setup.

     In particular, it adds a graphical login manager (see gdm-service-type), screen lockers, a network management tool (see network-manager-service-type), energy and color management services, the elogind login and seat manager, the Polkit privilege service, the GeoClue location service, the AccountsService daemon that allows authorized users change system passwords, an NTP client (see Servicios de red), the Avahi daemon, and has the name service switch service configured to be able to use nss-mdns (see mDNS).

The %DESKTOP-SERVICES variable can be used as the services field of an operating-system declaration (see services).

Additionally, the gnome-desktop-service-type, xfce-desktop-service, mate-desktop-service-type and enlightenment-desktop-service-type procedures can add GNOME, Xfce, MATE and/or Enlightenment to a system.  To ``add GNOME'' means that system-level services like the backlight adjustment helpers and the power management utilities are added to the system, extending polkit and dbus appropriately, allowing GNOME to operate with elevated privileges on a limited number of special-purpose system interfaces. Additionally, adding a service made by gnome-desktop-service-type adds the GNOME metapackage to the system profile.  Likewise, adding the Xfce service not only adds the xfce metapackage to the system profile, but it also gives the Thunar file manager the ability to open a ``root-mode'' file management window, if the user authenticates using the administrator's password via the standard polkit graphical interface.  To ``add MATE'' means that polkit and dbus are extended appropriately, allowing MATE to operate with elevated privileges on a limited number of special-purpose system interfaces.  Additionally, adding a service of type mate-desktop-service-type adds the MATE metapackage to the system profile.  ``Adding Enlightenment'' means that dbus is extended appropriately, and several of Enlightenment's binaries are set as setuid, allowing Enlightenment's screen locker and other functionality to work as expetected.

The desktop environments in Guix use the Xorg display server by default.  If you'd like to use the newer display server protocol called Wayland, you need to use the sddm-service instead of GDM as the graphical login manager.  You should then select the ``GNOME (Wayland)'' session in SDDM. Alternatively you can also try starting GNOME on Wayland manually from a TTY with the command ``XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session``.  Currently only GNOME has support for Wayland.

 -- Scheme Variable: gnome-desktop-service-type
     This is the type of the service that adds the GNOME (https://www.gnome.org) desktop environment.  Its value is a gnome-desktop-configuration object (see below.)

     This service adds the gnome package to the system profile, and extends polkit with the actions from gnome-settings-daemon.

 -- Data Type: gnome-desktop-configuration
     Configuration record for the GNOME desktop environment.

     gnome (default gnome)
          The GNOME package to use.

 -- Scheme Variable: xfce-desktop-service-type
     This is the type of a service to run the https://xfce.org/ (Xfce) desktop environment.  Its value is an xfce-desktop-configuration object (see below.)

     This service that adds the xfce package to the system profile, and extends polkit with the ability for thunar to manipulate the file system as root from within a user session, after the user has authenticated with the administrator's password.

 -- Data Type: xfce-desktop-configuration
     Configuration record for the Xfce desktop environment.

     xfce (default xfce)
          The Xfce package to use.

 -- Scheme Variable: mate-desktop-service-type
     This is the type of the service that runs the MATE desktop environment (https://mate-desktop.org/).  Its value is a mate-desktop-configuration object (see below.)

     This service adds the mate package to the system profile, and extends polkit with the actions from mate-settings-daemon.

 -- Data Type: mate-desktop-configuration
     Configuration record for the MATE desktop environment.

     mate (default mate)
          The MATE package to use.

 -- Scheme Variable: enlightenment-desktop-service-type
     Return a service that adds the enlightenment package to the system profile, and extends dbus with actions from efl.

 -- Tipo de datos: enlightenment-desktop-service-configuration

     enlightenment (predeterminado enlightenment)
          El paquete enlightenment usado.

Because the GNOME, Xfce and MATE desktop services pull in so many packages, the default %desktop-services variable doesn't include any of them by default.  To add GNOME, Xfce or MATE, just cons them onto %desktop-services in the services field of your operating-system:

     (use-modules (gnu))
     (use-service-modules desktop)
     (operating-system
       ...
       ;; cons* adds items to the list given as its last argument.
       (services (cons* (service gnome-desktop-service-type)
                        (service xfce-desktop-service)
                        %desktop-services))
       ...)

These desktop environments will then be available as options in the graphical login window.

The actual service definitions included in %desktop-services and provided by (gnu services dbus) and (gnu services desktop) are described below.

 -- Procedimiento Scheme: dbus-service [#:dbus DBUS] [#:services '()]
     Return a service that runs the ``system bus'', using DBUS, with support for SERVICES.

     D-Bus (http://dbus.freedesktop.org/) is an inter-process communication facility.  Its system bus is used to allow system services to communicate and to be notified of system-wide events.

     SERVICES must be a list of packages that provide an etc/dbus-1/system.d directory containing additional D-Bus configuration and policy files.  For example, to allow avahi-daemon to use the system bus, SERVICES must be equal to (list avahi).

 -- Procedimiento Scheme: elogind-service [#:config CONFIG]
     Return a service that runs the elogind login and seat management daemon.  Elogind (https://github.com/elogind/elogind) exposes a D-Bus interface that can be used to know which users are logged in, know what kind of sessions they have open, suspend the system, inhibit system suspend, reboot the system, and other tasks.

     Elogind handles most system-level power events for a computer, for example suspending the system when a lid is closed, or shutting it down when the power button is pressed.

     The CONFIG keyword argument specifies the configuration for elogind, and should be the result of an (elogind-configuration (PARAMETER VALUE)...) invocation.  Available parameters and their default values are:

     kill-user-processes?
          #f

     kill-only-users
          ()

     kill-exclude-users
          ("root")

     inhibit-delay-max-seconds
          5

     handle-power-key
          poweroff

     handle-suspend-key
          suspend

     handle-hibernate-key
          hibernate

     handle-lid-switch
          suspend

     handle-lid-switch-docked
          ignore

     power-key-ignore-inhibited?
          #f

     suspend-key-ignore-inhibited?
          #f

     hibernate-key-ignore-inhibited?
          #f

     lid-switch-ignore-inhibited?
          #t

     holdoff-timeout-seconds
          30

     idle-action
          ignore

     idle-action-seconds
          (* 30 60)

     runtime-directory-size-percent
          10

     runtime-directory-size
          #f

     remove-ipc?
          #t

     suspend-state
          ("mem" "standby" "freeze")

     suspend-mode
          ()

     hibernate-state
          ("disk")

     hibernate-mode
          ("platform" "shutdown")

     hybrid-sleep-state
          ("disk")

     hybrid-sleep-mode
          ("suspend" "platform" "shutdown")

 -- Procedimiento Scheme: accountsservice-service
     [#:accountsservice ACCOUNTSSERVICE] Return a service that runs
     AccountsService, a system service that can list available accounts, change their passwords, and so on.  AccountsService integrates with PolicyKit to enable unprivileged users to acquire the capability to modify their system configuration. the accountsservice web site (https://www.freedesktop.org/wiki/Software/AccountsService/) for more information.

     The ACCOUNTSSERVICE keyword argument is the accountsservice package to expose as a service.

 -- Procedimiento Scheme: polkit-service
     [#:polkit POLKIT] Return a service that runs the
     Polkit privilege management service (http://www.freedesktop.org/wiki/Software/polkit/), which allows system administrators to grant access to privileged operations in a structured way.  By querying the Polkit service, a privileged system component can know when it should grant additional capabilities to ordinary users.  For example, an ordinary user can be granted the capability to suspend the system if the user is logged in locally.

 -- Scheme Variable: upower-service-type
     Service that runs upowerd (http://upower.freedesktop.org/), a system-wide monitor for power consumption and battery levels, with the given configuration settings.

     It implements the org.freedesktop.UPower D-Bus interface, and is notably used by GNOME.

 -- Data Type: upower-configuration
     Data type representation the configuration for UPower.

     upower (default: UPOWER)
          Package to use for upower.

     watts-up-pro? (default: #f)
          Enable the Watts Up Pro device.

     poll-batteries? (default: #t)
          Enable polling the kernel for battery level changes.

     ignore-lid? (default: #f)
          Ignore the lid state, this can be useful if it's incorrect on a device.

     use-percentage-for-policy? (default: #f)
          Whether battery percentage based policy should be used.  The default is to use the time left, change to #t to use the percentage.

     percentage-low (default: 10)
          When use-percentage-for-policy? is #t, this sets the percentage at which the battery is considered low.

     percentage-critical (default: 3)
          When use-percentage-for-policy? is #t, this sets the percentage at which the battery is considered critical.

     percentage-action (default: 2)
          When use-percentage-for-policy? is #t, this sets the percentage at which action will be taken.

     time-low (default: 1200)
          When use-time-for-policy? is #f, this sets the time remaining in seconds at which the battery is considered low.

     time-critical (default: 300)
          When use-time-for-policy? is #f, this sets the time remaining in seconds at which the battery is considered critical.

     time-action (default: 120)
          When use-time-for-policy? is #f, this sets the time remaining in seconds at which action will be taken.

     critical-power-action (default: 'hybrid-sleep)
          The action taken when percentage-action or time-action is reached (depending on the configuration of use-percentage-for-policy?).

          Possible values are:

            * 'power-off

            * 'hibernate

            * 'hybrid-sleep.

 -- Procedimiento Scheme: udisks-service [#:udisks UDISKS]
     Return a service for UDisks (http://udisks.freedesktop.org/docs/latest/), a disk management daemon that provides user interfaces with notifications and ways to mount/unmount disks.  Programs that talk to UDisks include the udisksctl command, part of UDisks, and GNOME Disks.

 -- Procedimiento Scheme: colord-service [#:colord COLORD]
     Return a service that runs colord, a system service with a D-Bus interface to manage the color profiles of input and output devices such as screens and scanners.  It is notably used by the GNOME Color Manager graphical tool.  See the colord web site (http://www.freedesktop.org/software/colord/) for more information.

 -- Scheme Procedure: geoclue-application name [#:allowed? #t] [#:system? #f] [#:users '()]
     Return a configuration allowing an application to access GeoClue location data.  NAME is the Desktop ID of the application, without the .desktop part.  If ALLOWED? is true, the application will have access to location information by default.  The boolean SYSTEM? value indicates whether an application is a system component or not.  Finally USERS is a list of UIDs of all users for which this application is allowed location info access.  An empty users list means that all users are allowed.

 -- Variable Scheme: %standard-geoclue-applications
     The standard list of well-known GeoClue application configurations, granting authority to the GNOME date-and-time utility to ask for the current location in order to set the time zone, and allowing the IceCat and Epiphany web browsers to request location information.  IceCat and Epiphany both query the user before allowing a web page to know the user's location.

 -- Procedimiento Scheme: geoclue-service [#:colord COLORD]
     [#:whitelist '()]  [#:wifi-geolocation-url
     "https://location.services.mozilla.com/v1/geolocate?key=geoclue"] [#:submit-data? #f] [#:wifi-submission-url "https://location.services.mozilla.com/v1/submit?key=geoclue"] [#:submission-nick "geoclue"]  [#:applications %standard-geoclue-applications] Return a service that runs the GeoClue location service.  This service provides a D-Bus interface to allow applications to request access to a user's physical location, and optionally to add information to online location databases.  See the GeoClue web site (https://wiki.freedesktop.org/www/Software/GeoClue/) for more information.

 -- Procedimiento Scheme: bluetooth-service [#:bluez BLUEZ]
     [#:auto-enable? #f] Return a service that runs the bluetoothd
     daemon, which manages all the Bluetooth devices and provides a number of D-Bus interfaces.  When AUTO-ENABLE? is true, the bluetooth controller is powered automatically at boot, which can be useful when using a bluetooth keyboard or mouse.

     Users need to be in the lp group to access the D-Bus service.

Servicios de sonido
-------------------

The (gnu services sound) module provides a service to configure the Advanced Linux Sound Architecture (ALSA) system, which makes PulseAudio the preferred ALSA output driver.

 -- Variable Scheme: alsa-service-type
     This is the type for the Advanced Linux Sound Architecture (https://alsa-project.org/) (ALSA) system, which generates the /etc/asound.conf configuration file.  The value for this type is a alsa-configuration record as in this example:

          (service alsa-service-type)

     See below for details about alsa-configuration.

 -- Tipo de datos: alsa-configuration
     Data type representing the configuration for alsa-service.

     alsa-plugins (predeterminados: ALSA-PLUGINS)
          El paquete alsa-plugins usado.

     pulseaudio? (predeterminado: #T)
          Whether ALSA applications should transparently be made to use the PulseAudio (http://www.pulseaudio.org/) sound server.

          Using PulseAudio allows you to run several sound-producing applications at the same time and to individual control them via pavucontrol, among other things.

     extra-options (predeterminado: "")
          String to append to the /etc/asound.conf file.

Individual users who want to override the system configuration of ALSA can do it with the ~/.asoundrc file:

     # In guix, we have to specify the absolute path for plugins.
     pcm_type.jack {
       lib "/home/alice/.guix-profile/lib/alsa-lib/libasound_module_pcm_jack.so"
     }

     # Routing ALSA to jack:
     # <http://jackaudio.org/faq/routing_alsa.html>.
     pcm.rawjack {
       type jack
       playback_ports {
         0 system:playback_1
         1 system:playback_2
       }

       capture_ports {
         0 system:capture_1
         1 system:capture_2
       }
     }

     pcm.!default {
       type plug
       slave {
         pcm "rawjack"
       }
     }

See https://www.alsa-project.org/main/index.php/Asoundrc for the details.

Servicios de bases de datos
---------------------------

El módulo (gnu services databases) proporciona los siguientes servicios.

 -- Procedimiento Scheme: postgresql-service [#:postgresql postgresql]
     [#:config-file] [#:data-directory ``/var/lib/postgresql/data'']  [#:port
     5432] [#:locale ``en_US.utf8''] [#:extension-packages '()] Return a service that runs POSTGRESQL, the PostgreSQL database server.

     The PostgreSQL daemon loads its runtime configuration from CONFIG-FILE, creates a database cluster with LOCALE as the default locale, stored in DATA-DIRECTORY.  It then listens on PORT.

     Additional extensions are loaded from packages listed in EXTENSION-PACKAGES.  Extensions are available at runtime.  For instance, to create a geographic database using the postgis extension, a user can configure the postgresql-service as in this example:

          (use-package-modules databases geo)

          (operating-system
            ...
            ;; postgresql is required to run `psql' but postgis is not required for
            ;; proper operation.
            (packages (cons* postgresql %base-packages))
            (services
              (cons*
                (postgresql-service #:extension-packages (list postgis))
                %base-services)))

     Then the extension becomes visible and you can initialise an empty geographic database in this way:

          psql -U postgres
          > create database postgistest;
          > \connect postgistest;
          > create extension postgis;
          > create extension postgis_topology;

     There is no need to add this field for contrib extensions such as hstore or dblink as they are already loadable by postgresql.  This field is only required to add extensions provided by other packages.

 -- Procedimiento Scheme: mysql-service [#:config (mysql-configuration)]
     Return a service that runs mysqld, the MySQL or MariaDB database server.

     El parámetro opcional CONFIG especifica la configuración para mysqld, que debe ser un objeto <mysql-configuration>.

 -- Tipo de datos: mysql-configuration
     Data type representing the configuration of MYSQL-SERVICE.

     mysql (predeterminado: MARIADB)
          Package object of the MySQL database server, can be either MARIADB or MYSQL.

          For MySQL, a temporary root password will be displayed at activation time. For MariaDB, the root password is empty.

     port (predeterminado: 3306)
          TCP port on which the database server listens for incoming connections.

 -- Variable Scheme: memcached-service-type
     This is the service type for the Memcached (https://memcached.org/) service, which provides a distributed in memory cache.  The value for the service type is a memcached-configuration object.

     (service memcached-service-type)

 -- Tipo de datos: memcached-configuration
     Data type representing the configuration of memcached.

     memcached (predeterminado: memcached)
          El paquete de Memcached usado.

     interfaces (predeterminadas: '("0.0.0.0"))
          Network interfaces on which to listen.

     tcp-port (predeterminado: 11211)
          Port on which to accept connections on,

     udp-port (predeterminado: 11211)
          Port on which to accept UDP connections on, a value of 0 will disable listening on a UDP socket.

     additional-options (predeterminadas: '())
          Additional command line options to pass to memcached.

 -- Variable Scheme: mongodb-service-type
     This is the service type for MongoDB (https://www.mongodb.com/).  The value for the service type is a mongodb-configuration object.

     (service mongodb-service-type)

 -- Tipo de datos: mongodb-configuration
     Tipo de datos que representa la configuración de GPM.

     mongodb (predeterminado: mongodb)
          El paquete MongoDB usado.

     config-file (predeterminado: %default-mongodb-configuration-file)
          The configuration file for MongoDB.

     data-directory (predeterminado: "/var/lib/mongodb")
          This value is used to create the directory, so that it exists and is owned by the mongodb user.  It should match the data-directory which MongoDB is configured to use through the configuration file.

 -- Variable Scheme: redis-service-type
     This is the service type for the Redis (https://redis.io/) key/value store, whose value is a redis-configuration object.

 -- Tipo de datos: redis-configuration
     Data type representing the configuration of redis.

     redis (predeterminado: redis)
          The Redis package to use.

     bind (predeterminada: "127.0.0.1")
          La interfaz de red en la que se escucha.

     port (predeterminado: 6379)
          Port on which to accept connections on, a value of 0 will disable listening on a TCP socket.

     working-directory (predeterminado: "/var/lib/redis")
          Directory in which to store the database and related files.

Servicios de correo
-------------------

The (gnu services mail) module provides Guix service definitions for email services: IMAP, POP3, and LMTP servers, as well as mail transport agents (MTAs).  Lots of acronyms! These services are detailed in the subsections below.

Servicio Dovecot
................

 -- Procedimiento Scheme: dovecot-service [#:config (dovecot-configuration)]
     Return a service that runs the Dovecot IMAP/POP3/LMTP mail server.

By default, Dovecot does not need much configuration; the default configuration object created by (dovecot-configuration) will suffice if your mail is delivered to ~/Maildir.  A self-signed certificate will be generated for TLS-protected connections, though Dovecot will also listen on cleartext ports by default.  There are a number of options, though, which mail administrators might need to change, and as is the case with other services, Guix allows the system administrator to specify these parameters via a uniform Scheme interface.

Por ejemplo, para especificar que el correo se encuentra en maildir:~/.correo, se debe instanciar el servicio de Dovecot de esta manera:

     (dovecot-service #:config
                      (dovecot-configuration
                       (mail-location "maildir:~/.correo")))

The available configuration parameters follow.  Each parameter definition is preceded by its type; for example, string-list foo indicates that the foo parameter should be specified as a list of strings.  There is also a way to specify the configuration as a string, if you have an old dovecot.conf file that you want to port over from some other system; see the end for more details.

Available dovecot-configuration fields are:

 -- dovecot-configuration parameter: package dovecot
     El paquete dovecot.

 -- dovecot-configuration parameter: comma-separated-string-list listen
     A list of IPs or hosts where to listen for connections.  * listens on all IPv4 interfaces, :: listens on all IPv6 interfaces.  If you want to specify non-default ports or anything more complex, customize the address and port fields of the inet-listener of the specific services you are interested in.

 -- dovecot-configuration parameter: protocol-configuration-list protocols
     List of protocols we want to serve.  Available protocols include imap, pop3, and lmtp.

     Available protocol-configuration fields are:

      -- protocol-configuration parameter: string name
          El nombre del protocolo.

      -- protocol-configuration parameter: string auth-socket-path
          UNIX socket path to the master authentication server to find users.  This is used by imap (for shared users) and lda.  It defaults to "/var/run/dovecot/auth-userdb".

      -- protocol-configuration parameter: space-separated-string-list mail-plugins
          Space separated list of plugins to load.

      -- protocol-configuration parameter: non-negative-integer mail-max-userip-connections
          Maximum number of IMAP connections allowed for a user from each IP address. NOTE: The username is compared case-sensitively.  Defaults to 10.

 -- dovecot-configuration parameter: service-configuration-list services
     List of services to enable.  Available services include imap, imap-login, pop3, pop3-login, auth, and lmtp.

     Available service-configuration fields are:

      -- service-configuration parameter: string kind
          The service kind.  Valid values include director, imap-login, pop3-login, lmtp, imap, pop3, auth, auth-worker, dict, tcpwrap, quota-warning, or anything else.

      -- service-configuration parameter: listener-configuration-list listeners
          Listeners for the service.  A listener is either a unix-listener-configuration, a fifo-listener-configuration, or an inet-listener-configuration.  Defaults to ().

          Available unix-listener-configuration fields are:

           -- unix-listener-configuration parameter: string path
               Path to the file, relative to base-dir field.  This is also used as the section name.

           -- unix-listener-configuration parameter: string mode
               The access mode for the socket.  Defaults to "0600".

           -- unix-listener-configuration parameter: string user
               The user to own the socket.  Defaults to "".

           -- unix-listener-configuration parameter: string group
               The group to own the socket.  Defaults to "".

          Available fifo-listener-configuration fields are:

           -- fifo-listener-configuration parameter: string path
               Path to the file, relative to base-dir field.  This is also used as the section name.

           -- fifo-listener-configuration parameter: string mode
               The access mode for the socket.  Defaults to "0600".

           -- fifo-listener-configuration parameter: string user
               The user to own the socket.  Defaults to "".

           -- fifo-listener-configuration parameter: string group
               The group to own the socket.  Defaults to "".

          Available inet-listener-configuration fields are:

           -- inet-listener-configuration parameter: string protocol
               The protocol to listen for.

           -- inet-listener-configuration parameter: string address
               The address on which to listen, or empty for all addresses.  Defaults to "".

           -- inet-listener-configuration parameter: non-negative-integer port
               The port on which to listen.

           -- inet-listener-configuration parameter: boolean ssl?
               Whether to use SSL for this service; yes, no, or required.  Defaults to #t.

      -- service-configuration parameter: non-negative-integer client-limit
          Maximum number of simultaneous client connections per process.  Once this number of connections is received, the next incoming connection will prompt Dovecot to spawn another process.  If set to 0, default-client-limit is used instead.

          El valor predeterminado es 0.

      -- service-configuration parameter: non-negative-integer service-count
          Number of connections to handle before starting a new process.  Typically the only useful values are 0 (unlimited) or 1.  1 is more secure, but 0 is faster.  <doc/wiki/LoginProcess.txt>.  Defaults to 1.

      -- service-configuration parameter: non-negative-integer process-limit
          Maximum number of processes that can exist for this service.  If set to 0, default-process-limit is used instead.

          El valor predeterminado es 0.

      -- service-configuration parameter: non-negative-integer process-min-avail
          Number of processes to always keep waiting for more connections.  Defaults to 0.

      -- service-configuration parameter: non-negative-integer vsz-limit
          If you set service-count 0, you probably need to grow this.  Defaults to 256000000.

 -- dovecot-configuration parameter: dict-configuration dict
     Dict configuration, as created by the dict-configuration constructor.

     Available dict-configuration fields are:

      -- dict-configuration parameter: free-form-fields entries
          A list of key-value pairs that this dict should hold.  Defaults to ().

 -- dovecot-configuration parameter: passdb-configuration-list passdbs
     A list of passdb configurations, each one created by the passdb-configuration constructor.

     Available passdb-configuration fields are:

      -- passdb-configuration parameter: string driver
          The driver that the passdb should use.  Valid values include pam, passwd, shadow, bsdauth, and static.  Defaults to "pam".

      -- passdb-configuration parameter: space-separated-string-list args
          Space separated list of arguments to the passdb driver.  Defaults to "".

 -- dovecot-configuration parameter: userdb-configuration-list userdbs
     List of userdb configurations, each one created by the userdb-configuration constructor.

     Available userdb-configuration fields are:

      -- userdb-configuration parameter: string driver
          The driver that the userdb should use.  Valid values include passwd and static.  Defaults to "passwd".

      -- userdb-configuration parameter: space-separated-string-list args
          Space separated list of arguments to the userdb driver.  Defaults to "".

      -- userdb-configuration parameter: free-form-args override-fields
          Override fields from passwd.  Defaults to ().

 -- dovecot-configuration parameter: plugin-configuration plugin-configuration
     Plug-in configuration, created by the plugin-configuration constructor.

 -- dovecot-configuration parameter: list-of-namespace-configuration namespaces
     List of namespaces.  Each item in the list is created by the namespace-configuration constructor.

     Available namespace-configuration fields are:

      -- namespace-configuration parameter: string name
          Name for this namespace.

      -- namespace-configuration parameter: string type
          Namespace type: private, shared or public.  Defaults to "private".

      -- namespace-configuration parameter: string separator
          Hierarchy separator to use. You should use the same separator for all namespaces or some clients get confused.  / is usually a good one. The default however depends on the underlying mail storage format.  Defaults to "".

      -- namespace-configuration parameter: string prefix
          Prefix required to access this namespace.  This needs to be different for all namespaces. For example Public/.  Defaults to "".

      -- namespace-configuration parameter: string location
          Physical location of the mailbox. This is in the same format as mail_location, which is also the default for it.  Defaults to "".

      -- namespace-configuration parameter: boolean inbox?
          There can be only one INBOX, and this setting defines which namespace has it.  Defaults to #f.

      -- namespace-configuration parameter: boolean hidden?
          If namespace is hidden, it's not advertised to clients via NAMESPACE extension. You'll most likely also want to set list? #f.  This is mostly useful when converting from another server with different namespaces which you want to deprecate but still keep working.  For example you can create hidden namespaces with prefixes ~/mail/, ~%u/mail/ and mail/.  Defaults to #f.

      -- namespace-configuration parameter: boolean list?
          Show the mailboxes under this namespace with the LIST command. This makes the namespace visible for clients that do not support the NAMESPACE extension.  The special children value lists child mailboxes, but hides the namespace prefix.  Defaults to #t.

      -- namespace-configuration parameter: boolean subscriptions?
          Namespace handles its own subscriptions.  If set to #f, the parent namespace handles them.  The empty prefix should always have this as #t).  Defaults to #t.

      -- namespace-configuration parameter: mailbox-configuration-list mailboxes
          List of predefined mailboxes in this namespace.  Defaults to ().

          Available mailbox-configuration fields are:

           -- mailbox-configuration parameter: string name
               Name for this mailbox.

           -- mailbox-configuration parameter: string auto
               create will automatically create this mailbox.  subscribe will both create and subscribe to the mailbox.  Defaults to "no".

           -- mailbox-configuration parameter: space-separated-string-list special-use
               List of IMAP SPECIAL-USE attributes as specified by RFC 6154.  Valid values are \All, \Archive, \Drafts, \Flagged, \Junk, \Sent, and \Trash.  Defaults to ().

 -- dovecot-configuration parameter: file-name base-dir
     Base directory where to store runtime data.  Defaults to "/var/run/dovecot/".

 -- dovecot-configuration parameter: string login-greeting
     Greeting message for clients.  Defaults to "Dovecot ready.".

 -- dovecot-configuration parameter: space-separated-string-list login-trusted-networks
     List of trusted network ranges.  Connections from these IPs are allowed to override their IP addresses and ports (for logging and for authentication checks).  disable-plaintext-auth is also ignored for these networks. Typically you would specify your IMAP proxy servers here.  Defaults to ().

 -- dovecot-configuration parameter: space-separated-string-list login-access-sockets
     List of login access check sockets (e.g. tcpwrap).  Defaults to ().

 -- dovecot-configuration parameter: boolean verbose-proctitle?
     Show more verbose process titles (in ps).  Currently shows user name and IP address.  Useful for seeing who is actually using the IMAP processes (e.g. shared mailboxes or if the same uid is used for multiple accounts). Defaults to #f.

 -- dovecot-configuration parameter: boolean shutdown-clients?
     Should all processes be killed when Dovecot master process shuts down. Setting this to #f means that Dovecot can be upgraded without forcing existing client connections to close (although that could also be a problem if the upgrade is e.g. due to a security fix).  Defaults to #t.

 -- dovecot-configuration parameter: non-negative-integer doveadm-worker-count
     If non-zero, run mail commands via this many connections to doveadm server, instead of running them directly in the same process.  Defaults to 0.

 -- dovecot-configuration parameter: string doveadm-socket-path
     UNIX socket or host:port used for connecting to doveadm server.  Defaults to "doveadm-server".

 -- dovecot-configuration parameter: space-separated-string-list import-environment
     List of environment variables that are preserved on Dovecot startup and passed down to all of its child processes.  You can also give key=value pairs to always set specific settings.

 -- dovecot-configuration parameter: boolean disable-plaintext-auth?
     Disable LOGIN command and all other plaintext authentications unless SSL/TLS is used (LOGINDISABLED capability).  Note that if the remote IP matches the local IP (i.e. you're connecting from the same computer), the connection is considered secure and plaintext authentication is allowed.  See also ssl=required setting.  Defaults to #t.

 -- dovecot-configuration parameter: non-negative-integer auth-cache-size
     Authentication cache size (e.g. #e10e6).  0 means it's disabled. Note that bsdauth, PAM and vpopmail require cache-key to be set for caching to be used.  Defaults to 0.

 -- dovecot-configuration parameter: string auth-cache-ttl
     Time to live for cached data.  After TTL expires the cached record is no longer used, *except* if the main database lookup returns internal failure. We also try to handle password changes automatically: If user's previous authentication was successful, but this one wasn't, the cache isn't used. For now this works only with plaintext authentication.  Defaults to "1 hour".

 -- dovecot-configuration parameter: string auth-cache-negative-ttl
     TTL for negative hits (user not found, password mismatch).  0 disables caching them completely.  Defaults to "1 hour".

 -- dovecot-configuration parameter: space-separated-string-list auth-realms
     List of realms for SASL authentication mechanisms that need them.  You can leave it empty if you don't want to support multiple realms.  Many clients simply use the first one listed here, so keep the default realm first. Defaults to ().

 -- dovecot-configuration parameter: string auth-default-realm
     Default realm/domain to use if none was specified.  This is used for both SASL realms and appending @domain to username in plaintext logins. Defaults to "".

 -- dovecot-configuration parameter: string auth-username-chars
     List of allowed characters in username.  If the user-given username contains a character not listed in here, the login automatically fails.  This is just an extra check to make sure user can't exploit any potential quote escaping vulnerabilities with SQL/LDAP databases.  If you want to allow all characters, set this value to empty.  Defaults to "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@".

 -- dovecot-configuration parameter: string auth-username-translation
     Username character translations before it's looked up from databases.  The value contains series of from -> to characters.  For example #@/@ means that # and / characters are translated to @. Defaults to "".

 -- dovecot-configuration parameter: string auth-username-format
     Username formatting before it's looked up from databases.  You can use the standard variables here, e.g. %Lu would lowercase the username, %n would drop away the domain if it was given, or %n-AT-%d would change the @ into -AT-.  This translation is done after auth-username-translation changes.  Defaults to "%Lu".

 -- dovecot-configuration parameter: string auth-master-user-separator
     If you want to allow master users to log in by specifying the master username within the normal username string (i.e. not using SASL mechanism's support for it), you can specify the separator character here. The format is then <username><separator><master username>.  UW-IMAP uses * as the separator, so that could be a good choice.  Defaults to "".

 -- dovecot-configuration parameter: string auth-anonymous-username
     Username to use for users logging in with ANONYMOUS SASL mechanism. Defaults to "anonymous".

 -- dovecot-configuration parameter: non-negative-integer auth-worker-max-count
     Maximum number of dovecot-auth worker processes.  They're used to execute blocking passdb and userdb queries (e.g. MySQL and PAM).  They're automatically created and destroyed as needed.  Defaults to 30.

 -- dovecot-configuration parameter: string auth-gssapi-hostname
     Host name to use in GSSAPI principal names.  The default is to use the name returned by gethostname().  Use $ALL (with quotes) to allow all keytab entries.  Defaults to "".

 -- dovecot-configuration parameter: string auth-krb5-keytab
     Kerberos keytab to use for the GSSAPI mechanism.  Will use the system default (usually /etc/krb5.keytab) if not specified.  You may need to change the auth service to run as root to be able to read this file. Defaults to "".

 -- dovecot-configuration parameter: boolean auth-use-winbind?
     Do NTLM and GSS-SPNEGO authentication using Samba's winbind daemon and ntlm-auth helper.  <doc/wiki/Authentication/Mechanisms/Winbind.txt>. Defaults to #f.

 -- dovecot-configuration parameter: file-name auth-winbind-helper-path
     Path for Samba's ntlm-auth helper binary.  Defaults to "/usr/bin/ntlm_auth".

 -- dovecot-configuration parameter: string auth-failure-delay
     Time to delay before replying to failed authentications.  Defaults to "2 secs".

 -- dovecot-configuration parameter: boolean auth-ssl-require-client-cert?
     Require a valid SSL client certificate or the authentication fails. Defaults to #f.

 -- dovecot-configuration parameter: boolean auth-ssl-username-from-cert?
     Take the username from client's SSL certificate, using X509_NAME_get_text_by_NID() which returns the subject's DN's CommonName.  Defaults to #f.

 -- dovecot-configuration parameter: space-separated-string-list auth-mechanisms
     List of wanted authentication mechanisms.  Supported mechanisms are: plain, login, digest-md5, cram-md5, ntlm, rpa, apop, anonymous, gssapi, otp, skey, and gss-spnego.  NOTE: See also disable-plaintext-auth setting.

 -- dovecot-configuration parameter: space-separated-string-list director-servers
     List of IPs or hostnames to all director servers, including ourself.  Ports can be specified as ip:port.  The default port is the same as what director service's inet-listener is using.  Defaults to ().

 -- dovecot-configuration parameter: space-separated-string-list director-mail-servers
     List of IPs or hostnames to all backend mail servers.  Ranges are allowed too, like 10.0.0.10-10.0.0.30.  Defaults to ().

 -- dovecot-configuration parameter: string director-user-expire
     How long to redirect users to a specific server after it no longer has any connections.  Defaults to "15 min".

 -- dovecot-configuration parameter: string director-username-hash
     How the username is translated before being hashed.  Useful values include %Ln if user can log in with or without @domain, %Ld if mailboxes are shared within domain.  Defaults to "%Lu".

 -- dovecot-configuration parameter: string log-path
     Log file to use for error messages.  syslog logs to syslog, /dev/stderr logs to stderr.  Defaults to "syslog".

 -- dovecot-configuration parameter: string info-log-path
     Log file to use for informational messages.  Defaults to log-path. Defaults to "".

 -- dovecot-configuration parameter: string debug-log-path
     Log file to use for debug messages.  Defaults to info-log-path. Defaults to "".

 -- dovecot-configuration parameter: string syslog-facility
     Syslog facility to use if you're logging to syslog.  Usually if you don't want to use mail, you'll use local0..local7.  Also other standard facilities are supported.  Defaults to "mail".

 -- dovecot-configuration parameter: boolean auth-verbose?
     Log unsuccessful authentication attempts and the reasons why they failed. Defaults to #f.

 -- dovecot-configuration parameter: boolean auth-verbose-passwords?
     In case of password mismatches, log the attempted password.  Valid values are no, plain and sha1.  sha1 can be useful for detecting brute force password attempts vs.  user simply trying the same password over and over again.  You can also truncate the value to n chars by appending ":n" (e.g. sha1:6).  Defaults to #f.

 -- dovecot-configuration parameter: boolean auth-debug?
     Even more verbose logging for debugging purposes.  Shows for example SQL queries.  Defaults to #f.

 -- dovecot-configuration parameter: boolean auth-debug-passwords?
     In case of password mismatches, log the passwords and used scheme so the problem can be debugged.  Enabling this also enables auth-debug. Defaults to #f.

 -- dovecot-configuration parameter: boolean mail-debug?
     Enable mail process debugging.  This can help you figure out why Dovecot isn't finding your mails.  Defaults to #f.

 -- dovecot-configuration parameter: boolean verbose-ssl?
     Show protocol level SSL errors.  Defaults to #f.

 -- dovecot-configuration parameter: string log-timestamp
     Prefix for each line written to log file.  % codes are in strftime(3) format.  Defaults to "\"%b %d %H:%M:%S \"".

 -- dovecot-configuration parameter: space-separated-string-list login-log-format-elements
     List of elements we want to log.  The elements which have a non-empty variable value are joined together to form a comma-separated string.

 -- dovecot-configuration parameter: string login-log-format
     Login log format.  %s contains login-log-format-elements string, %$ contains the data we want to log.  Defaults to "%$: %s".

 -- dovecot-configuration parameter: string mail-log-prefix
     Log prefix for mail processes.  See doc/wiki/Variables.txt for list of possible variables you can use.  Defaults to "\"%s(%u)<%{pid}><%{session}>: \"".

 -- dovecot-configuration parameter: string deliver-log-format
     Format to use for logging mail deliveries.  You can use variables:

     %$
          Delivery status message (e.g. saved to INBOX)

     %m
          Message-ID

     %s
          Subject

     %f
          From address

     %p
          Tamaño físico

     %w
          Tamaño virtual.

     Defaults to "msgid=%m: %$".

 -- dovecot-configuration parameter: string mail-location
     Location for users' mailboxes.  The default is empty, which means that Dovecot tries to find the mailboxes automatically.  This won't work if the user doesn't yet have any mail, so you should explicitly tell Dovecot the full location.

     If you're using mbox, giving a path to the INBOX file (e.g. /var/mail/%u) isn't enough.  You'll also need to tell Dovecot where the other mailboxes are kept.  This is called the "root mail directory", and it must be the first path given in the mail-location setting.

     There are a few special variables you can use, eg.:

     %u
          username

     %n
          user part in user@domain, same as %u if there's no domain

     %d
          domain part in user@domain, empty if there's no domain

     %h
          home director

     See doc/wiki/Variables.txt for full list.  Some examples:

     maildir:~/Maildir

     mbox:~/mail:INBOX=/var/mail/%u

     mbox:/var/mail/%d/%1n/%n:INDEX=/var/indexes/%d/%1n/%

     El valor predeterminado es "".

 -- dovecot-configuration parameter: string mail-uid
     System user and group used to access mails.  If you use multiple, userdb can override these by returning uid or gid fields.  You can use either numbers or names.  <doc/wiki/UserIds.txt>.  Defaults to "".

 -- dovecot-configuration parameter: string mail-gid

     El valor predeterminado es "".

 -- dovecot-configuration parameter: string mail-privileged-group
     Group to enable temporarily for privileged operations.  Currently this is used only with INBOX when either its initial creation or dotlocking fails. Typically this is set to "mail" to give access to /var/mail.  Defaults to "".

 -- dovecot-configuration parameter: string mail-access-groups
     Grant access to these supplementary groups for mail processes.  Typically these are used to set up access to shared mailboxes.  Note that it may be dangerous to set these if users can create symlinks (e.g. if "mail" group is set here, ln -s /var/mail ~/mail/var could allow a user to delete others' mailboxes, or ln -s /secret/shared/box ~/mail/mybox would allow reading it).  Defaults to "".

 -- dovecot-configuration parameter: boolean mail-full-filesystem-access?
     Allow full file system access to clients.  There's no access checks other than what the operating system does for the active UID/GID.  It works with both maildir and mboxes, allowing you to prefix mailboxes names with e.g. /path/ or ~user/.  Defaults to #f.

 -- dovecot-configuration parameter: boolean mmap-disable?
     Don't use mmap() at all.  This is required if you store indexes to shared file systems (NFS or clustered file system).  Defaults to #f.

 -- dovecot-configuration parameter: boolean dotlock-use-excl?
     Rely on O_EXCL to work when creating dotlock files.  NFS supports O_EXCL since version 3, so this should be safe to use nowadays by default.  Defaults to #t.

 -- dovecot-configuration parameter: string mail-fsync
     When to use fsync() or fdatasync() calls:

     optimized
          Whenever necessary to avoid losing important data

     always
          Useful with e.g. NFS when write()s are delayed

     never
          Never use it (best performance, but crashes can lose data).

     Defaults to "optimized".

 -- dovecot-configuration parameter: boolean mail-nfs-storage?
     Mail storage exists in NFS.  Set this to yes to make Dovecot flush NFS caches whenever needed.  If you're using only a single mail server this isn't needed.  Defaults to #f.

 -- dovecot-configuration parameter: boolean mail-nfs-index?
     Mail index files also exist in NFS.  Setting this to yes requires mmap-disable? #t and fsync-disable? #f.  Defaults to #f.

 -- dovecot-configuration parameter: string lock-method
     Locking method for index files.  Alternatives are fcntl, flock and dotlock. Dotlocking uses some tricks which may create more disk I/O than other locking methods.  NFS users: flock doesn't work, remember to change mmap-disable.  Defaults to "fcntl".

 -- dovecot-configuration parameter: file-name mail-temp-dir
     Directory in which LDA/LMTP temporarily stores incoming mails >128 kB. Defaults to "/tmp".

 -- dovecot-configuration parameter: non-negative-integer first-valid-uid
     Valid UID range for users.  This is mostly to make sure that users can't log in as daemons or other system users.  Note that denying root logins is hardcoded to dovecot binary and can't be done even if first-valid-uid is set to 0.  Defaults to 500.

 -- dovecot-configuration parameter: non-negative-integer last-valid-uid

     El valor predeterminado es 0.

 -- dovecot-configuration parameter: non-negative-integer first-valid-gid
     Valid GID range for users.  Users having non-valid GID as primary group ID aren't allowed to log in.  If user belongs to supplementary groups with non-valid GIDs, those groups are not set.  Defaults to 1.

 -- dovecot-configuration parameter: non-negative-integer last-valid-gid

     El valor predeterminado es 0.

 -- dovecot-configuration parameter: non-negative-integer mail-max-keyword-length
     Maximum allowed length for mail keyword name.  It's only forced when trying to create new keywords.  Defaults to 50.

 -- dovecot-configuration parameter: colon-separated-file-name-list valid-chroot-dirs
     List of directories under which chrooting is allowed for mail processes (i.e. /var/mail will allow chrooting to /var/mail/foo/bar too).  This setting doesn't affect login-chroot mail-chroot or auth chroot settings.  If this setting is empty, "/./" in home dirs are ignored. WARNING: Never add directories here which local users can modify, that may lead to root exploit.  Usually this should be done only if you don't allow shell access for users.  <doc/wiki/Chrooting.txt>.  Defaults to ().

 -- dovecot-configuration parameter: string mail-chroot
     Default chroot directory for mail processes.  This can be overridden for specific users in user database by giving /./ in user's home directory (e.g. /home/./user chroots into /home).  Note that usually there is no real need to do chrooting, Dovecot doesn't allow users to access files outside their mail directory anyway.  If your home directories are prefixed with the chroot directory, append "/." to mail-chroot. <doc/wiki/Chrooting.txt>.  Defaults to "".

 -- dovecot-configuration parameter: file-name auth-socket-path
     UNIX socket path to master authentication server to find users.  This is used by imap (for shared users) and lda.  Defaults to "/var/run/dovecot/auth-userdb".

 -- dovecot-configuration parameter: file-name mail-plugin-dir
     Directory where to look up mail plugins.  Defaults to "/usr/lib/dovecot".

 -- dovecot-configuration parameter: space-separated-string-list mail-plugins
     List of plugins to load for all services.  Plugins specific to IMAP, LDA, etc. are added to this list in their own .conf files.  Defaults to ().

 -- dovecot-configuration parameter: non-negative-integer mail-cache-min-mail-count
     The minimum number of mails in a mailbox before updates are done to cache file.  This allows optimizing Dovecot's behavior to do less disk writes at the cost of more disk reads.  Defaults to 0.

 -- dovecot-configuration parameter: string mailbox-idle-check-interval
     When IDLE command is running, mailbox is checked once in a while to see if there are any new mails or other changes.  This setting defines the minimum time to wait between those checks.  Dovecot can also use dnotify, inotify and kqueue to find out immediately when changes occur.  Defaults to "30 secs".

 -- dovecot-configuration parameter: boolean mail-save-crlf?
     Save mails with CR+LF instead of plain LF.  This makes sending those mails take less CPU, especially with sendfile() syscall with Linux and FreeBSD. But it also creates a bit more disk I/O which may just make it slower.  Also note that if other software reads the mboxes/maildirs, they may handle the extra CRs wrong and cause problems.  Defaults to #f.

 -- dovecot-configuration parameter: boolean maildir-stat-dirs?
     By default LIST command returns all entries in maildir beginning with a dot.  Enabling this option makes Dovecot return only entries which are directories.  This is done by stat()ing each entry, so it causes more disk I/O.  (For systems setting struct dirent->d_type this check is free and it's done always regardless of this setting).  Defaults to #f.

 -- dovecot-configuration parameter: boolean maildir-copy-with-hardlinks?
     When copying a message, do it with hard links whenever possible.  This makes the performance much better, and it's unlikely to have any side effects. Defaults to #t.

 -- dovecot-configuration parameter: boolean maildir-very-dirty-syncs?
     Assume Dovecot is the only MUA accessing Maildir: Scan cur/ directory only when its mtime changes unexpectedly or when we can't find the mail otherwise.  Defaults to #f.

 -- dovecot-configuration parameter: space-separated-string-list mbox-read-locks
     Which locking methods to use for locking mbox.  There are four available:

     dotlock
          Create <mailbox>.lock file.  This is the oldest and most NFS-safe solution. If you want to use /var/mail/ like directory, the users will need write access to that directory.

     dotlock-try
          Same as dotlock, but if it fails because of permissions or because there isn't enough disk space, just skip it.

     fcntl
          Use this if possible.  Works with NFS too if lockd is used.

     flock
          May not exist in all systems.  Doesn't work with NFS.

     lockf
          May not exist in all systems.  Doesn't work with NFS.

     You can use multiple locking methods; if you do the order they're declared in is important to avoid deadlocks if other MTAs/MUAs are using multiple locking methods as well.  Some operating systems don't allow using some of them simultaneously.

 -- dovecot-configuration parameter: space-separated-string-list mbox-write-locks

 -- dovecot-configuration parameter: string mbox-lock-timeout
     Maximum time to wait for lock (all of them) before aborting.  Defaults to "5 mins".

 -- dovecot-configuration parameter: string mbox-dotlock-change-timeout
     If dotlock exists but the mailbox isn't modified in any way, override the lock file after this much time.  Defaults to "2 mins".

 -- dovecot-configuration parameter: boolean mbox-dirty-syncs?
     When mbox changes unexpectedly we have to fully read it to find out what changed.  If the mbox is large this can take a long time.  Since the change is usually just a newly appended mail, it'd be faster to simply read the new mails.  If this setting is enabled, Dovecot does this but still safely fallbacks to re-reading the whole mbox file whenever something in mbox isn't how it's expected to be.  The only real downside to this setting is that if some other MUA changes message flags, Dovecot doesn't notice it immediately.  Note that a full sync is done with SELECT, EXAMINE, EXPUNGE and CHECK commands.  Defaults to #t.

 -- dovecot-configuration parameter: boolean mbox-very-dirty-syncs?
     Like mbox-dirty-syncs, but don't do full syncs even with SELECT, EXAMINE, EXPUNGE or CHECK commands.  If this is set, mbox-dirty-syncs is ignored.  Defaults to #f.

 -- dovecot-configuration parameter: boolean mbox-lazy-writes?
     Delay writing mbox headers until doing a full write sync (EXPUNGE and CHECK commands and when closing the mailbox).  This is especially useful for POP3 where clients often delete all mails.  The downside is that our changes aren't immediately visible to other MUAs.  Defaults to #t.

 -- dovecot-configuration parameter: non-negative-integer mbox-min-index-size
     If mbox size is smaller than this (e.g. 100k), don't write index files. If an index file already exists it's still read, just not updated.  Defaults to 0.

 -- dovecot-configuration parameter: non-negative-integer mdbox-rotate-size
     Maximum dbox file size until it's rotated.  Defaults to 10000000.

 -- dovecot-configuration parameter: string mdbox-rotate-interval
     Maximum dbox file age until it's rotated.  Typically in days.  Day begins from midnight, so 1d = today, 2d = yesterday, etc.  0 = check disabled. Defaults to "1d".

 -- dovecot-configuration parameter: boolean mdbox-preallocate-space?
     When creating new mdbox files, immediately preallocate their size to mdbox-rotate-size.  This setting currently works only in Linux with some file systems (ext4, xfs).  Defaults to #f.

 -- dovecot-configuration parameter: string mail-attachment-dir
     sdbox and mdbox support saving mail attachments to external files, which also allows single instance storage for them.  Other backends don't support this for now.

     WARNING: This feature hasn't been tested much yet.  Use at your own risk.

     Directory root where to store mail attachments.  Disabled, if empty. Defaults to "".

 -- dovecot-configuration parameter: non-negative-integer mail-attachment-min-size
     Attachments smaller than this aren't saved externally.  It's also possible to write a plugin to disable saving specific attachments externally. Defaults to 128000.

 -- dovecot-configuration parameter: string mail-attachment-fs
     File system backend to use for saving attachments:

     posix
          No SiS done by Dovecot (but this might help FS's own deduplication)

     sis posix
          SiS with immediate byte-by-byte comparison during saving

     sis-queue posix
          SiS with delayed comparison and deduplication.

     Defaults to "sis posix".

 -- dovecot-configuration parameter: string mail-attachment-hash
     Hash format to use in attachment filenames.  You can add any text and variables: %{md4}, %{md5}, %{sha1}, %{sha256}, %{sha512}, %{size}.  Variables can be truncated, e.g. %{sha256:80} returns only first 80 bits. Defaults to "%{sha1}".

 -- dovecot-configuration parameter: non-negative-integer default-process-limit

     Defaults to 100.

 -- dovecot-configuration parameter: non-negative-integer default-client-limit

     Defaults to 1000.

 -- dovecot-configuration parameter: non-negative-integer default-vsz-limit
     Default VSZ (virtual memory size) limit for service processes.  This is mainly intended to catch and kill processes that leak memory before they eat up everything.  Defaults to 256000000.

 -- dovecot-configuration parameter: string default-login-user
     Login user is internally used by login processes.  This is the most untrusted user in Dovecot system.  It shouldn't have access to anything at all.  Defaults to "dovenull".

 -- dovecot-configuration parameter: string default-internal-user
     Internal user is used by unprivileged processes.  It should be separate from login user, so that login processes can't disturb other processes.  Defaults to "dovecot".

 -- dovecot-configuration parameter: string ssl?
     SSL/TLS support: yes, no, required.  <doc/wiki/SSL.txt>.  Defaults to "required".

 -- dovecot-configuration parameter: string ssl-cert
     PEM encoded X.509 SSL/TLS certificate (public key).  Defaults to "</etc/dovecot/default.pem".

 -- dovecot-configuration parameter: string ssl-key
     PEM encoded SSL/TLS private key.  The key is opened before dropping root privileges, so keep the key file unreadable by anyone but root.  Defaults to "</etc/dovecot/private/default.pem".

 -- dovecot-configuration parameter: string ssl-key-password
     If key file is password protected, give the password here.  Alternatively give it when starting dovecot with -p parameter.  Since this file is often world-readable, you may want to place this setting instead to a different. Defaults to "".

 -- dovecot-configuration parameter: string ssl-ca
     PEM encoded trusted certificate authority.  Set this only if you intend to use ssl-verify-client-cert? #t.  The file should contain the CA certificate(s) followed by the matching CRL(s).  (e.g. ssl-ca </etc/ssl/certs/ca.pem).  Defaults to "".

 -- dovecot-configuration parameter: boolean ssl-require-crl?
     Require that CRL check succeeds for client certificates.  Defaults to #t.

 -- dovecot-configuration parameter: boolean ssl-verify-client-cert?
     Request client to send a certificate.  If you also want to require it, set auth-ssl-require-client-cert? #t in auth section.  Defaults to #f.

 -- dovecot-configuration parameter: string ssl-cert-username-field
     Which field from certificate to use for username.  commonName and x500UniqueIdentifier are the usual choices.  You'll also need to set auth-ssl-username-from-cert? #t.  Defaults to "commonName".

 -- dovecot-configuration parameter: string ssl-min-protocol
     Minimum SSL protocol version to accept.  Defaults to "TLSv1".

 -- dovecot-configuration parameter: string ssl-cipher-list
     SSL ciphers to use.  Defaults to "ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH".

 -- dovecot-configuration parameter: string ssl-crypto-device
     SSL crypto device to use, for valid values run "openssl engine".  Defaults to "".

 -- dovecot-configuration parameter: string postmaster-address
     Address to use when sending rejection mails.  %d expands to recipient domain.  Defaults to "postmaster@%d".

 -- dovecot-configuration parameter: string hostname
     Hostname to use in various parts of sent mails (e.g. in Message-Id)  and in LMTP replies.  Default is the system's real hostname@domain.  Defaults to "".

 -- dovecot-configuration parameter: boolean quota-full-tempfail?
     If user is over quota, return with temporary failure instead of bouncing the mail.  Defaults to #f.

 -- dovecot-configuration parameter: file-name sendmail-path
     Binary to use for sending mails.  Defaults to "/usr/sbin/sendmail".

 -- dovecot-configuration parameter: string submission-host
     If non-empty, send mails via this SMTP host[:port] instead of sendmail. Defaults to "".

 -- dovecot-configuration parameter: string rejection-subject
     Subject: header to use for rejection mails.  You can use the same variables as for rejection-reason below.  Defaults to "Rejected: %s".

 -- dovecot-configuration parameter: string rejection-reason
     Human readable error message for rejection mails.  You can use variables:

     %n
          CRLF

     %r
          reason

     %s
          original subject

     %t
          recipient

     Defaults to "Your message to <%t> was automatically rejected:%n%r".

 -- dovecot-configuration parameter: string recipient-delimiter
     Delimiter character between local-part and detail in email address. Defaults to "+".

 -- dovecot-configuration parameter: string lda-original-recipient-header
     Header where the original recipient address (SMTP's RCPT TO: address) is taken from if not available elsewhere.  With dovecot-lda -a parameter overrides this.  A commonly used header for this is X-Original-To.  Defaults to "".

 -- dovecot-configuration parameter: boolean lda-mailbox-autocreate?
     Should saving a mail to a nonexistent mailbox automatically create it?. Defaults to #f.

 -- dovecot-configuration parameter: boolean lda-mailbox-autosubscribe?
     Should automatically created mailboxes be also automatically subscribed?. Defaults to #f.

 -- dovecot-configuration parameter: non-negative-integer imap-max-line-length
     Maximum IMAP command line length.  Some clients generate very long command lines with huge mailboxes, so you may need to raise this if you get "Too long argument" or "IMAP command line too large" errors often.  Defaults to 64000.

 -- dovecot-configuration parameter: string imap-logout-format
     IMAP logout format string:

     %i
          número total de bytes leídos del cliente

     %o
          número total de bytes enviados al cliente.

     See doc/wiki/Variables.txt for a list of all the variables you can use.  Defaults to "in=%i out=%o deleted=%{deleted} expunged=%{expunged} trashed=%{trashed} hdr_count=%{fetch_hdr_count} hdr_bytes=%{fetch_hdr_bytes} body_count=%{fetch_body_count} body_bytes=%{fetch_body_bytes}".

 -- dovecot-configuration parameter: string imap-capability
     Override the IMAP CAPABILITY response.  If the value begins with '+', add the given capabilities on top of the defaults (e.g. +XFOO XBAR).  Defaults to "".

 -- dovecot-configuration parameter: string imap-idle-notify-interval
     How long to wait between "OK Still here" notifications when client is IDLEing.  Defaults to "2 mins".

 -- dovecot-configuration parameter: string imap-id-send
     ID field names and values to send to clients.  Using * as the value makes Dovecot use the default value.  The following fields have default values currently: name, version, os, os-version, support-url, support-email. Defaults to "".

 -- dovecot-configuration parameter: string imap-id-log
     ID fields sent by client to log.  * means everything.  Defaults to "".

 -- dovecot-configuration parameter: space-separated-string-list imap-client-workarounds
     Workarounds for various client bugs:

     delay-newmail
          Send EXISTS/RECENT new mail notifications only when replying to NOOP and CHECK commands.  Some clients ignore them otherwise, for example OSX Mail (<v2.1).  Outlook Express breaks more badly though, without this it may show user "Message no longer in server" errors.  Note that OE6 still breaks even with this workaround if synchronization is set to "Headers Only".

     tb-extra-mailbox-sep
          Thunderbird gets somehow confused with LAYOUT=fs (mbox and dbox) and adds extra / suffixes to mailbox names.  This option causes Dovecot to ignore the extra / instead of treating it as invalid mailbox name.

     tb-lsub-flags
          Show \Noselect flags for LSUB replies with LAYOUT=fs (e.g. mbox).  This makes Thunderbird realize they aren't selectable and show them greyed out, instead of only later giving "not selectable" popup error.

     Defaults to ().

 -- dovecot-configuration parameter: string imap-urlauth-host
     Host allowed in URLAUTH URLs sent by client.  "*" allows all.  Defaults to "".

Whew! Lots of configuration options.  The nice thing about it though is that Guix has a complete interface to Dovecot's configuration language.  This allows not only a nice way to declare configurations, but also offers reflective capabilities as well: users can write code to inspect and transform configurations from within Scheme.

However, it could be that you just want to get a dovecot.conf up and running.  In that case, you can pass an opaque-dovecot-configuration as the #:config parameter to dovecot-service.  As its name indicates, an opaque configuration does not have easy reflective capabilities.

Available opaque-dovecot-configuration fields are:

 -- opaque-dovecot-configuration parameter: package dovecot
     El paquete dovecot.

 -- opaque-dovecot-configuration parameter: string string
     The contents of the dovecot.conf, as a string.

For example, if your dovecot.conf is just the empty string, you could instantiate a dovecot service like this:

     (dovecot-service #:config
                      (opaque-dovecot-configuration
                       (string "")))

Servicio OpenSMTPD
..................

 -- Variable Scheme: opensmtpd-service-type
     This is the type of the OpenSMTPD (https://www.opensmtpd.org) service, whose value should be an opensmtpd-configuration object as in this example:

          (service opensmtpd-service-type
                   (opensmtpd-configuration
                     (config-file (local-file "./mi-smtpd.conf"))))

 -- Tipo de datos: opensmtpd-configuration
     Data type representing the configuration of opensmtpd.

     package (predeterminado: OPENSMTPD)
          El objeto paquete del servidor SMTP OpenSMTPD.

     config-file (predeterminado: %DEFAULT-OPENSMTPD-FILE)
          File-like object of the OpenSMTPD configuration file to use.  By default it listens on the loopback network interface, and allows for mail from users and daemons on the local machine, as well as permitting email to remote servers.  Run man smtpd.conf for more information.

Servicio Exim
.............

 -- Variable Scheme: exim-service-type
     This is the type of the Exim (https://exim.org) mail transfer agent (MTA), whose value should be an exim-configuration object as in this example:

          (service exim-service-type
                   (exim-configuration
                     (config-file (local-file "./mi-exim.conf"))))

In order to use an exim-service-type service you must also have a mail-aliases-service-type service present in your operating-system (even if it has no aliases).

 -- Tipo de datos: exim-configuration
     Tipo de datos que representa la configuración de exim.

     package (predeterminado: EXIM)
          Package object of the Exim server.

     config-file (predeterminado: #f)
          File-like object of the Exim configuration file to use. If its value is #f then use the default configuration file from the package provided in package. The resulting configuration file is loaded after setting the exim_user and exim_group configuration variables.

Servicios de alias de correo
............................

 -- Variable Scheme: mail-aliases-service-type
     This is the type of the service which provides /etc/aliases, specifying how to deliver mail to users on this system.

          (service mail-aliases-service-type
                   '(("postmaster" "rober")
                     ("rober" "rober@example.com" "rober@example2.com")))

The configuration for a mail-aliases-service-type service is an association list denoting how to deliver mail that comes to this system. Each entry is of the form (alias addresses ...), with alias specifying the local alias and addresses specifying where to deliver this user's mail.

The aliases aren't required to exist as users on the local system. In the above example, there doesn't need to be a postmaster entry in the operating-system's user-accounts in order to deliver the postmaster mail to bob (which subsequently would deliver mail to bob@example.com and bob@example2.com).

GNU Mailutils IMAP4 Daemon
..........................

 -- Scheme Variable: imap4d-service-type
     This is the type of the GNU Mailutils IMAP4 Daemon (see imap4d (GNU Mailutils Manual)), whose value should be an imap4d-configuration object as in this example:

          (service imap4d-service-type
                   (imap4d-configuration
                     (config-file (local-file "imap4d.conf"))))

 -- Data Type: imap4d-configuration
     Data type representing the configuration of imap4d.

     package (default: mailutils)
          The package that provides imap4d.

     config-file (default: %default-imap4d-config-file)
          File-like object of the configuration file to use, by default it will listen on TCP port 143 of localhost.  See Conf-imap4d (GNU Mailutils Manual), for details.

Servicios de mensajería
-----------------------

The (gnu services messaging) module provides Guix service definitions for messaging services: currently only Prosody is supported.

Servicio Prosody
................

 -- Variable Scheme: prosody-service-type
     This is the type for the Prosody XMPP communication server (https://prosody.im).  Its value must be a prosody-configuration record as in this example:

          (service prosody-service-type
                   (prosody-configuration
                    (modules-enabled (cons "groups" "mam" %default-modules-enabled))
                    (int-components
                     (list
                      (int-component-configuration
                       (hostname "conference.example.net")
                       (plugin "muc")
                       (mod-muc (mod-muc-configuration)))))
                    (virtualhosts
                     (list
                      (virtualhost-configuration
                       (domain "example.net"))))))

     See below for details about prosody-configuration.

By default, Prosody does not need much configuration.  Only one virtualhosts field is needed: it specifies the domain you wish Prosody to serve.

You can perform various sanity checks on the generated configuration with the prosodyctl check command.

Prosodyctl will also help you to import certificates from the letsencrypt directory so that the prosody user can access them.  See https://prosody.im/doc/letsencrypt.

     prosodyctl --root cert import /etc/letsencrypt/live

The available configuration parameters follow.  Each parameter definition is preceded by its type; for example, string-list foo indicates that the foo parameter should be specified as a list of strings.  Types starting with maybe- denote parameters that won't show up in prosody.cfg.lua when their value is 'disabled.

There is also a way to specify the configuration as a string, if you have an old prosody.cfg.lua file that you want to port over from some other system; see the end for more details.

The file-object type designates either a file-like object (see file-like objects) or a file name.

Available prosody-configuration fields are:

 -- prosody-configuration parameter: package prosody
     El paquete Prosody.

 -- prosody-configuration parameter: file-name data-path
     Location of the Prosody data storage directory.  See https://prosody.im/doc/configure.  Defaults to "/var/lib/prosody".

 -- prosody-configuration parameter: file-object-list plugin-paths
     Additional plugin directories.  They are searched in all the specified paths in order.  See https://prosody.im/doc/plugins_directory.  Defaults to ().

 -- prosody-configuration parameter: file-name certificates
     Every virtual host and component needs a certificate so that clients and servers can securely verify its identity.  Prosody will automatically load certificates/keys from the directory specified here.  Defaults to "/etc/prosody/certs".

 -- prosody-configuration parameter: string-list admins
     This is a list of accounts that are admins for the server.  Note that you must create the accounts separately.  See https://prosody.im/doc/admins and https://prosody.im/doc/creating_accounts.  Example: (admins '("user1@example.com" "user2@example.net")) Defaults to ().

 -- prosody-configuration parameter: boolean use-libevent?
     Enable use of libevent for better performance under high load.  See https://prosody.im/doc/libevent.  Defaults to #f.

 -- prosody-configuration parameter: module-list modules-enabled
     This is the list of modules Prosody will load on startup.  It looks for mod_modulename.lua in the plugins folder, so make sure that exists too.  Documentation on modules can be found at: https://prosody.im/doc/modules.  Defaults to ("roster" "saslauth" "tls" "dialback" "disco" "carbons" "private" "blocklist" "vcard" "version" "uptime" "time" "ping" "pep" "register" "admin_adhoc").

 -- prosody-configuration parameter: string-list modules-disabled
     "offline", "c2s" and "s2s" are auto-loaded, but should you want to disable them then add them to this list.  Defaults to ().

 -- prosody-configuration parameter: file-object groups-file
     Path to a text file where the shared groups are defined.  If this path is empty then mod_groups does nothing.  See https://prosody.im/doc/modules/mod_groups.  Defaults to "/var/lib/prosody/sharedgroups.txt".

 -- prosody-configuration parameter: boolean allow-registration?
     Disable account creation by default, for security.  See https://prosody.im/doc/creating_accounts.  Defaults to #f.

 -- prosody-configuration parameter: maybe-ssl-configuration ssl
     These are the SSL/TLS-related settings.  Most of them are disabled so to use Prosody's defaults.  If you do not completely understand these options, do not add them to your config, it is easy to lower the security of your server using them.  See https://prosody.im/doc/advanced_ssl_config.

     Available ssl-configuration fields are:

      -- ssl-configuration parameter: maybe-string protocol
          This determines what handshake to use.

      -- ssl-configuration parameter: maybe-file-name key
          Path to your private key file.

      -- ssl-configuration parameter: maybe-file-name certificate
          Path to your certificate file.

      -- ssl-configuration parameter: file-object capath
          Path to directory containing root certificates that you wish Prosody to trust when verifying the certificates of remote servers.  Defaults to "/etc/ssl/certs".

      -- ssl-configuration parameter: maybe-file-object cafile
          Path to a file containing root certificates that you wish Prosody to trust. Similar to capath but with all certificates concatenated together.

      -- ssl-configuration parameter: maybe-string-list verify
          A list of verification options (these mostly map to OpenSSL's set_verify() flags).

      -- ssl-configuration parameter: maybe-string-list options
          A list of general options relating to SSL/TLS.  These map to OpenSSL's set_options().  For a full list of options available in LuaSec, see the LuaSec source.

      -- ssl-configuration parameter: maybe-non-negative-integer depth
          How long a chain of certificate authorities to check when looking for a trusted root certificate.

      -- ssl-configuration parameter: maybe-string ciphers
          An OpenSSL cipher string.  This selects what ciphers Prosody will offer to clients, and in what order.

      -- ssl-configuration parameter: maybe-file-name dhparam
          A path to a file containing parameters for Diffie-Hellman key exchange.  You can create such a file with: openssl dhparam -out /etc/prosody/certs/dh-2048.pem 2048

      -- ssl-configuration parameter: maybe-string curve
          Curve for Elliptic curve Diffie-Hellman. Prosody's default is "secp384r1".

      -- ssl-configuration parameter: maybe-string-list verifyext
          A list of "extra" verification options.

      -- ssl-configuration parameter: maybe-string password
          Password for encrypted private keys.

 -- prosody-configuration parameter: boolean c2s-require-encryption?
     Whether to force all client-to-server connections to be encrypted or not. See https://prosody.im/doc/modules/mod_tls.  Defaults to #f.

 -- prosody-configuration parameter: string-list disable-sasl-mechanisms
     Set of mechanisms that will never be offered.  See https://prosody.im/doc/modules/mod_saslauth.  Defaults to ("DIGEST-MD5").

 -- prosody-configuration parameter: boolean s2s-require-encryption?
     Whether to force all server-to-server connections to be encrypted or not. See https://prosody.im/doc/modules/mod_tls.  Defaults to #f.

 -- prosody-configuration parameter: boolean s2s-secure-auth?
     Whether to require encryption and certificate authentication.  This provides ideal security, but requires servers you communicate with to support encryption AND present valid, trusted certificates.  See https://prosody.im/doc/s2s#security.  Defaults to #f.

 -- prosody-configuration parameter: string-list s2s-insecure-domains
     Many servers don't support encryption or have invalid or self-signed certificates.  You can list domains here that will not be required to authenticate using certificates.  They will be authenticated using DNS.  See https://prosody.im/doc/s2s#security.  Defaults to ().

 -- prosody-configuration parameter: string-list s2s-secure-domains
     Even if you leave s2s-secure-auth? disabled, you can still require valid certificates for some domains by specifying a list here.  See https://prosody.im/doc/s2s#security.  Defaults to ().

 -- prosody-configuration parameter: string authentication
     Select the authentication backend to use.  The default provider stores passwords in plaintext and uses Prosody's configured data storage to store the authentication data.  If you do not trust your server please see https://prosody.im/doc/modules/mod_auth_internal_hashed for information about using the hashed backend.  See also https://prosody.im/doc/authentication Defaults to "internal_plain".

 -- prosody-configuration parameter: maybe-string log
     Set logging options.  Advanced logging configuration is not yet supported by the Prosody service.  See https://prosody.im/doc/logging.  Defaults to "*syslog".

 -- prosody-configuration parameter: file-name pidfile
     File to write pid in.  See https://prosody.im/doc/modules/mod_posix. Defaults to "/var/run/prosody/prosody.pid".

 -- prosody-configuration parameter: maybe-non-negative-integer http-max-content-size
     Maximum allowed size of the HTTP body (in bytes).

 -- prosody-configuration parameter: maybe-string http-external-url
     Some modules expose their own URL in various ways.  This URL is built from the protocol, host and port used.  If Prosody sits behind a proxy, the public URL will be http-external-url instead.  See https://prosody.im/doc/http#external_url.

 -- prosody-configuration parameter: virtualhost-configuration-list virtualhosts
     A host in Prosody is a domain on which user accounts can be created.  For example if you want your users to have addresses like "john.smith@example.com" then you need to add a host "example.com".  All options in this list will apply only to this host.

     Note: the name "virtual" host is used in configuration to avoid confusion with the actual physical host that Prosody is installed on.  A single Prosody instance can serve many domains, each one defined as a VirtualHost entry in Prosody's configuration.  Conversely a server that hosts a single domain would have just one VirtualHost entry.

     See https://prosody.im/doc/configure#virtual_host_settings.

     Available virtualhost-configuration fields are:

     all these prosody-configuration fields: admins, use-libevent?, modules-enabled, modules-disabled, groups-file, allow-registration?, ssl, c2s-require-encryption?, disable-sasl-mechanisms, s2s-require-encryption?, s2s-secure-auth?, s2s-insecure-domains, s2s-secure-domains, authentication, log, http-max-content-size, http-external-url, raw-content, plus:
      -- virtualhost-configuration parameter: string domain
          Domain you wish Prosody to serve.

 -- prosody-configuration parameter: int-component-configuration-list int-components
     Components are extra services on a server which are available to clients, usually on a subdomain of the main server (such as "mycomponent.example.com").  Example components might be chatroom servers, user directories, or gateways to other protocols.

     Internal components are implemented with Prosody-specific plugins.  To add an internal component, you simply fill the hostname field, and the plugin you wish to use for the component.

     See https://prosody.im/doc/components.  Defaults to ().

     Available int-component-configuration fields are:

     all these prosody-configuration fields: admins, use-libevent?, modules-enabled, modules-disabled, groups-file, allow-registration?, ssl, c2s-require-encryption?, disable-sasl-mechanisms, s2s-require-encryption?, s2s-secure-auth?, s2s-insecure-domains, s2s-secure-domains, authentication, log, http-max-content-size, http-external-url, raw-content, plus:
      -- int-component-configuration parameter: string hostname
          Hostname of the component.

      -- int-component-configuration parameter: string plugin
          Plugin you wish to use for the component.

      -- int-component-configuration parameter: maybe-mod-muc-configuration mod-muc
          Multi-user chat (MUC) is Prosody's module for allowing you to create hosted chatrooms/conferences for XMPP users.

          General information on setting up and using multi-user chatrooms can be found in the "Chatrooms" documentation (https://prosody.im/doc/chatrooms), which you should read if you are new to XMPP chatrooms.

          See also https://prosody.im/doc/modules/mod_muc.

          Available mod-muc-configuration fields are:

           -- mod-muc-configuration parameter: string name
               The name to return in service discovery responses.  Defaults to "Prosody Chatrooms".

           -- mod-muc-configuration parameter: string-or-boolean restrict-room-creation
               If #t, this will only allow admins to create new chatrooms. Otherwise anyone can create a room.  The value "local" restricts room creation to users on the service's parent domain.  E.g. user@example.com can create rooms on rooms.example.com.  The value "admin" restricts to service administrators only.  Defaults to #f.

           -- mod-muc-configuration parameter: non-negative-integer max-history-messages
               Maximum number of history messages that will be sent to the member that has just joined the room.  Defaults to 20.

 -- prosody-configuration parameter: ext-component-configuration-list ext-components
     External components use XEP-0114, which most standalone components support. To add an external component, you simply fill the hostname field.  See https://prosody.im/doc/components.  Defaults to ().

     Available ext-component-configuration fields are:

     all these prosody-configuration fields: admins, use-libevent?, modules-enabled, modules-disabled, groups-file, allow-registration?, ssl, c2s-require-encryption?, disable-sasl-mechanisms, s2s-require-encryption?, s2s-secure-auth?, s2s-insecure-domains, s2s-secure-domains, authentication, log, http-max-content-size, http-external-url, raw-content, plus:
      -- ext-component-configuration parameter: string component-secret
          Password which the component will use to log in.

      -- ext-component-configuration parameter: string hostname
          Hostname of the component.

 -- prosody-configuration parameter: non-negative-integer-list component-ports
     Port(s) Prosody listens on for component connections.  Defaults to (5347).

 -- prosody-configuration parameter: string component-interface
     Interface Prosody listens on for component connections.  Defaults to "127.0.0.1".

 -- prosody-configuration parameter: maybe-raw-content raw-content
     Raw content that will be added to the configuration file.

It could be that you just want to get a prosody.cfg.lua up and running.  In that case, you can pass an opaque-prosody-configuration record as the value of prosody-service-type.  As its name indicates, an opaque configuration does not have easy reflective capabilities. Available opaque-prosody-configuration fields are:

 -- opaque-prosody-configuration parameter: package prosody
     El paquete prosody.

 -- opaque-prosody-configuration parameter: string prosody.cfg.lua
     The contents of the prosody.cfg.lua to use.

For example, if your prosody.cfg.lua is just the empty string, you could instantiate a prosody service like this:

     (service prosody-service-type
              (opaque-prosody-configuration
               (prosody.cfg.lua "")))

Servicio BitlBee
................

BitlBee (http://bitlbee.org) is a gateway that provides an IRC interface to a variety of messaging protocols such as XMPP.

 -- Variable Scheme: bitlbee-service-type
     This is the service type for the BitlBee (http://bitlbee.org) IRC gateway daemon.  Its value is a bitlbee-configuration (see below).

     To have BitlBee listen on port 6667 on localhost, add this line to your services:

          (service bitlbee-service-type)

 -- Tipo de datos: bitlbee-configuration
     This is the configuration for BitlBee, with the following fields:

     interface (predeterminada: "127.0.0.1")
     port (predeterminado: 6667)
          Escucha en la interfaz de red correspondiente a la dirección IP especificada en INTERFACE, en el puerto PORT.

          When INTERFACE is 127.0.0.1, only local clients can connect; when it is 0.0.0.0, connections can come from any networking interface.

     package (predeterminado: bitlbee)
          El paquete BitlBee usado.

     plugins (predeterminados: '())
          List of plugin packages to use---e.g., bitlbee-discord.

     extra-settings (predeterminado: "")
          Configuration snippet added as-is to the BitlBee configuration file.

Quassel Service
...............

Quassel (https://quassel-irc.org/) is a distributed IRC client, meaning that one or more clients can attach to and detach from the central core.

 -- Scheme Variable: quassel-service-type
     This is the service type for the Quassel (https://quassel-irc.org/) IRC backend daemon.  Its value is a quassel-configuration (see below).

 -- Data Type: quassel-configuration
     This is the configuration for Quassel, with the following fields:

     quassel (default: quassel)
          The Quassel package to use.

     interface (default: "::,0.0.0.0")

     port (default: 4242)
          Listen on the network interface(s) corresponding to the IPv4 or IPv6 interfaces specified in the comma delimited INTERFACE, on PORT.

     loglevel (default: "Info")
          The level of logging desired.  Accepted values are Debug, Info, Warning and Error.

Servicios de telefonía
----------------------

This section describes how to set up and run a Murmur server.  Murmur is the server of the Mumble (https://mumble.info) voice-over-IP (VoIP) suite.

 -- Tipo de datos: murmur-configuration
     The service type for the Murmur server.  An example configuration can look like this:

          (service murmur-service-type
                   (murmur-configuration
                    (welcome-text
                      "Welcome to this Mumble server running on Guix!")
                    (cert-required? #t) ;disallow text password logins
                    (ssl-cert "/etc/letsencrypt/live/mumble.example.com/fullchain.pem")
                    (ssl-key "/etc/letsencrypt/live/mumble.example.com/privkey.pem")))

     After reconfiguring your system, you can manually set the murmur SuperUser password with the command that is printed during the activation phase.

     It is recommended to register a normal Mumble user account and grant it admin or moderator rights.  You can use the mumble client to login as new normal user, register yourself, and log out.  For the next step login with the name SuperUser use the SuperUser password that you set previously, and grant your newly registered mumble user administrator or moderator rights and create some channels.

     Available murmur-configuration fields are:

     package (predeterminado: mumble)
          Package that contains bin/murmurd.

     user (predeterminado: "murmur")
          User who will run the Murmur server.

     group (predeterminado: "murmur")
          Group of the user who will run the murmur server.

     port (predeterminado: 64738)
          Puerto en el que escucha el servidor.

     welcome-text (predeterminado: "")
          Welcome text sent to clients when they connect.

     server-password (predeterminada: "")
          Password the clients have to enter in order to connect.

     max-users (predeterminados: 100)
          Maximum of users that can be connected to the server at once.

     max-user-bandwidth (predeterminado: #f)
          Maximum voice traffic a user can send per second.

     database-file (predeterminado: "/var/lib/murmur/db.sqlite")
          File name of the sqlite database.  The service's user will become the owner of the directory.

     log-file (predeterminado: "/var/log/murmur/murmur.log")
          File name of the log file.  The service's user will become the owner of the directory.

     autoban-attempts (predeterminados: 10)
          Maximum number of logins a user can make in autoban-timeframe without getting auto banned for autoban-time.

     autoban-timeframe (predeterminado: 120)
          Timeframe for autoban in seconds.

     autoban-time (predeterminado: 300)
          Amount of time in seconds for which a client gets banned when violating the autoban limits.

     opus-threshold (predeterminado: 100)
          Percentage of clients that need to support opus before switching over to opus audio codec.

     channel-nesting-limit (predeterminado: 10)
          How deep channels can be nested at maximum.

     channelname-regex (predeterminado: #f)
          A string in form of a Qt regular expression that channel names must conform to.

     username-regex (predeterminado: #f)
          A string in form of a Qt regular expression that user names must conform to.

     text-message-length (predeterminado: 5000)
          Maximum size in bytes that a user can send in one text chat message.

     image-message-length (predeterminado: (* 128 1024))
          Maximum size in bytes that a user can send in one image message.

     cert-required? (predeterminado: #f)
          If it is set to #t clients that use weak password authentification will not be accepted. Users must have completed the certificate wizard to join.

     remember-channel? (predeterminado: #f)
          Should murmur remember the last channel each user was in when they disconnected and put them into the remembered channel when they rejoin.

     allow-html? (predeterminado: #f)
          Should html be allowed in text messages, user comments, and channel descriptions.

     allow-ping? (predeterminado: #f)
          Setting to true exposes the current user count, the maximum user count, and the server's maximum bandwidth per client to unauthenticated users. In the Mumble client, this information is shown in the Connect dialog.

          Disabling this setting will prevent public listing of the server.

     bonjour? (predeterminado: #f)
          Should the server advertise itself in the local network through the bonjour protocol.

     send-version? (predeterminado: #f)
          Should the murmur server version be exposed in ping requests.

     log-days (predeterminado: 31)
          Murmur also stores logs in the database, which are accessible via RPC.  The default is 31 days of months, but you can set this setting to 0 to keep logs forever, or -1 to disable logging to the database.

     obfuscate-ips? (predeterminado: #t)
          Should logged ips be obfuscated to protect the privacy of users.

     ssl-cert (predeterminado: #f)
          File name of the SSL/TLS certificate used for encrypted connections.

               (ssl-cert "/etc/letsencrypt/live/example.com/fullchain.pem")

     ssl-key (predeterminada: #f)
          Filepath to the ssl private key used for encrypted connections.

               (ssl-key "/etc/letsencrypt/live/example.com/privkey.pem")

     ssl-dh-params (predeterminado: #f)
          File name of a PEM-encoded file with Diffie-Hellman parameters for the SSL/TLS encryption.  Alternatively you set it to "@ffdhe2048", "@ffdhe3072", "@ffdhe4096", "@ffdhe6144" or "@ffdhe8192" to use bundled parameters from RFC 7919.

     ssl-ciphers (predeterminado: #f)
          The ssl-ciphers option chooses the cipher suites to make available for use in SSL/TLS.

          This option is specified using OpenSSL cipher list notation (https://www.openssl.org/docs/apps/ciphers.html#CIPHER-LIST-FORMAT).

          It is recommended that you try your cipher string using 'openssl ciphers <string>' before setting it here, to get a feel for which cipher suites you will get.  After setting this option, it is recommend that you inspect your Murmur log to ensure that Murmur is using the cipher suites that you expected it to.

          Note: Changing this option may impact the backwards compatibility of your Murmur server, and can remove the ability for older Mumble clients to be able to connect to it.

     public-registration (predeterminado: #f)
          Must be a <murmur-public-registration-configuration> record or #f.

          You can optionally register your server in the public server list that the mumble client shows on startup.  You cannot register your server if you have set a server-password, or set allow-ping to #f.

          It might take a few hours until it shows up in the public list.

     file (predeterminado: #f)
          Optional alternative override for this configuration.

 -- Tipo de datos: murmur-public-registration-configuration
     Configuration for public registration of a murmur service.

     name
          This is a display name for your server. Not to be confused with the hostname.

     password
          A password to identify your registration.  Subsequent updates will need the same password. Don't lose your password.

     url
          This should be a http:// or https:// link to your web site.

     hostname (predeterminado: #f)
          By default your server will be listed by its IP address.  If it is set your server will be linked by this host name instead.

Servicios de monitorización
---------------------------

Servicio Tailon
...............

Tailon (https://tailon.readthedocs.io/) is a web application for viewing and searching log files.

The following example will configure the service with default values.  By default, Tailon can be accessed on port 8080 (http://localhost:8080).

     (service tailon-service-type)

The following example customises more of the Tailon configuration, adding sed to the list of allowed commands.

     (service tailon-service-type
              (tailon-configuration
                (config-file
                  (tailon-configuration-file
                    (allowed-commands '("tail" "grep" "awk" "sed"))))))

 -- Tipo de datos: tailon-configuration
     Data type representing the configuration of Tailon.  This type has the following parameters:

     config-file (predeterminado: (tailon-configuration-file))
          The configuration file to use for Tailon. This can be set to a tailon-configuration-file record value, or any gexp (see Expresiones-G).

          For example, to instead use a local file, the local-file function can be used:

               (service tailon-service-type
                        (tailon-configuration
                          (config-file (local-file "./mi-tailon.conf"))))

     package (predeterminado: tailon)
          El paquete tailon usado.

 -- Tipo de datos: tailon-configuration-file
     Tipo de datos que representa las opciones de configuración de Tailon. Este tipo tiene los siguientes parámetros:

     files (predeterminados: (list "/var/log"))
          List of files to display. The list can include strings for a single file or directory, or a list, where the first item is the name of a subsection, and the remaining items are the files or directories in that subsection.

     bind (predeterminado: "localhost:8080")
          Address and port to which Tailon should bind on.

     relative-root (predeterminado: #f)
          URL path to use for Tailon, set to #f to not use a path.

     allow-transfers? (predeterminado: #t)
          Allow downloading the log files in the web interface.

     follow-names? (predeterminado: #t)
          Allow tailing of not-yet existent files.

     tail-lines (predeterminado: 200)
          Number of lines to read initially from each file.

     allowed-commands (predeterminadas: (list "tail" "grep" "awk"))
          Órdenes cuya ejecución está permitida. Por defecto, sed está deshabilitado.

     debug? (predeterminado: #f)
          Set debug? to #t to show debug messages.

     wrap-lines (predeterminado: #t)
          Initial line wrapping state in the web interface. Set to #t to initially wrap lines (the default), or to #f to initially not wrap lines.

     http-auth (predeterminado: #f)
          HTTP authentication type to use. Set to #f to disable authentication (the default). Supported values are "digest" or "basic".

     users (predeterminado: #f)
          If HTTP authentication is enabled (see http-auth), access will be restricted to the credentials provided here. To configure users, use a list of pairs, where the first element of the pair is the username, and the 2nd element of the pair is the password.

               (tailon-configuration-file
                 (http-auth "basic")
                 (users     '(("usuaria1" . "contraseña1")
                              ("usuaria2" . "contraseña2"))))

Servicio Darkstat
.................

Darkstat is a packet sniffer that captures network traffic, calculates statistics about usage, and serves reports over HTTP.

 -- Variable: Variable Scheme darkstat-service-type
     This is the service type for the darkstat (https://unix4lyfe.org/darkstat/) service, its value must be a darkstat-configuration record as in this example:

          (service darkstat-service-type
                   (darkstat-configuration
                     (interface "eno1")))

 -- Tipo de datos: darkstat-configuration
     Tipo de datos que representa la configuración de darkstat.

     package (predeterminado: darkstat)
          El paquete darkstat usado.

     interface
          Captura el tráfico en la interfaz de red especificada.

     port (predeterminado: "667")
          Bind the web interface to the specified port.

     bind-address (predeterminada: "127.0.0.1")
          Bind the web interface to the specified address.

     base (predeterminada: "/")
          Specify the path of the base URL.  This can be useful if darkstat is accessed via a reverse proxy.

Servicio del exportador de nodos Prometheus
...........................................

The Prometheus ``node exporter'' makes hardware and operating system statistics provided by the Linux kernel available for the Prometheus monitoring system.  This service should be deployed on all physical nodes and virtual machines, where monitoring these statistics is desirable.

 -- Variable: Variable Scheme prometheus-node-exporter-service-type
     This is the service type for the prometheus-node-exporter (https://github.com/prometheus/node_exporter/) service, its value must be a prometheus-node-exporter-configuration record as in this example:

          (service prometheus-node-exporter-service-type
                   (prometheus-node-exporter-configuration
                     (web-listen-address ":9100")))

 -- Tipo de datos: prometheus-node-exporter-configuration
     Tipo de datos que representa la configuración de node_exporter.

     package (predeterminado: go-github-com-prometheus-node-exporter)
          El paquete prometheus-node-exporter usado.

     web-listen-address (predeterminada: ":9100")
          Bind the web interface to the specified address.

Zabbix server
.............

Zabbix provides monitoring metrics, among others network utilization, CPU load and disk space consumption:

  * High performance, high capacity (able to monitor hundreds of thousands of devices).

  * Auto-discovery of servers and network devices and interfaces.

  * Low-level discovery, allows to automatically start monitoring new items, file systems or network interfaces among others.

  * Distributed monitoring with centralized web administration.

  * Native high performance agents.

  * SLA, and ITIL KPI metrics on reporting.

  * High-level (business) view of monitored resources through user-defined visual console screens and dashboards.

  * Remote command execution through Zabbix proxies.

Available zabbix-server-configuration fields are:

 -- zabbix-server-configuration parameter: package zabbix-server
     The zabbix-server package.

 -- zabbix-server-configuration parameter: string user
     User who will run the Zabbix server.

     Defaults to "zabbix".

 -- zabbix-server-configuration parameter: group group
     Group who will run the Zabbix server.

     Defaults to "zabbix".

 -- zabbix-server-configuration parameter: string db-host
     Database host name.

     Defaults to "127.0.0.1".

 -- zabbix-server-configuration parameter: string db-name
     Database name.

     Defaults to "zabbix".

 -- zabbix-server-configuration parameter: string db-user
     Database user.

     Defaults to "zabbix".

 -- zabbix-server-configuration parameter: string db-password
     Database password.  Please, use include-files with DBPassword=SECRET inside a specified file instead.

     El valor predeterminado es "".

 -- zabbix-server-configuration parameter: number db-port
     Database port.

     Defaults to 5432.

 -- zabbix-server-configuration parameter: string log-type
     Specifies where log messages are written to:

       * system - syslog.

       * file - file specified with log-file parameter.

       * console - standard output.

     El valor predeterminado es "".

 -- zabbix-server-configuration parameter: string log-file
     Log file name for log-type file parameter.

     Defaults to "/var/log/zabbix/server.log".

 -- zabbix-server-configuration parameter: string pid-file
     Name of PID file.

     Defaults to "/var/run/zabbix/zabbix_server.pid".

 -- zabbix-server-configuration parameter: string ssl-ca-location
     The location of certificate authority (CA) files for SSL server certificate verification.

     Defaults to "/etc/ssl/certs/ca-certificates.crt".

 -- zabbix-server-configuration parameter: string ssl-cert-location
     Location of SSL client certificates.

     Defaults to "/etc/ssl/certs".

 -- zabbix-server-configuration parameter: string extra-options
     Extra options will be appended to Zabbix server configuration file.

     El valor predeterminado es "".

 -- zabbix-server-configuration parameter: include-files include-files
     You may include individual files or all files in a directory in the configuration file.

     Defaults to ().

Zabbix agent
............

Zabbix agent gathers information for Zabbix server.

Available zabbix-agent-configuration fields are:

 -- zabbix-agent-configuration parameter: package zabbix-agent
     The zabbix-agent package.

 -- zabbix-agent-configuration parameter: string user
     User who will run the Zabbix agent.

     Defaults to "zabbix".

 -- zabbix-agent-configuration parameter: group group
     Group who will run the Zabbix agent.

     Defaults to "zabbix".

 -- zabbix-agent-configuration parameter: string hostname
     Unique, case sensitive hostname which is required for active checks and must match hostname as configured on the server.

     Defaults to "Zabbix server".

 -- zabbix-agent-configuration parameter: string log-type
     Specifies where log messages are written to:

       * system - syslog.

       * file - file specified with log-file parameter.

       * console - standard output.

     El valor predeterminado es "".

 -- zabbix-agent-configuration parameter: string log-file
     Log file name for log-type file parameter.

     Defaults to "/var/log/zabbix/agent.log".

 -- zabbix-agent-configuration parameter: string pid-file
     Name of PID file.

     Defaults to "/var/run/zabbix/zabbix_agent.pid".

 -- zabbix-agent-configuration parameter: list server
     List of IP addresses, optionally in CIDR notation, or hostnames of Zabbix servers and Zabbix proxies.  Incoming connections will be accepted only from the hosts listed here.

     Defaults to ("127.0.0.1").

 -- zabbix-agent-configuration parameter: list server-active
     List of IP:port (or hostname:port) pairs of Zabbix servers and Zabbix proxies for active checks.  If port is not specified, default port is used. If this parameter is not specified, active checks are disabled.

     Defaults to ("127.0.0.1").

 -- zabbix-agent-configuration parameter: string extra-options
     Extra options will be appended to Zabbix server configuration file.

     El valor predeterminado es "".

 -- zabbix-agent-configuration parameter: include-files include-files
     You may include individual files or all files in a directory in the configuration file.

     Defaults to ().

Zabbix front-end
................

This service provides a WEB interface to Zabbix server.

Available zabbix-front-end-configuration fields are:

 -- zabbix-front-end-configuration parameter: nginx-server-configuration-list nginx
     Configuración de NGINX.

 -- zabbix-front-end-configuration parameter: string db-host
     Database host name.

     Defaults to "localhost".

 -- zabbix-front-end-configuration parameter: number db-port
     Database port.

     Defaults to 5432.

 -- zabbix-front-end-configuration parameter: string db-name
     Database name.

     Defaults to "zabbix".

 -- zabbix-front-end-configuration parameter: string db-user
     Database user.

     Defaults to "zabbix".

 -- zabbix-front-end-configuration parameter: string db-password
     Database password.  Please, use db-secret-file instead.

     El valor predeterminado es "".

 -- zabbix-front-end-configuration parameter: string db-secret-file
     Secret file which will be appended to zabbix.conf.php file.  This file contains credentials for use by Zabbix front-end.  You are expected to create it manually.

     El valor predeterminado es "".

 -- zabbix-front-end-configuration parameter: string zabbix-host
     Zabbix server hostname.

     Defaults to "localhost".

 -- zabbix-front-end-configuration parameter: number zabbix-port
     Zabbix server port.

     Defaults to 10051.

Servicios Kerberos
------------------

The (gnu services kerberos) module provides services relating to the authentication protocol Kerberos.

Servicio Krb5
.............

Programs using a Kerberos client library normally expect a configuration file in /etc/krb5.conf.  This service generates such a file from a definition provided in the operating system declaration.  It does not cause any daemon to be started.

No ``keytab'' files are provided by this service---you must explicitly create them.  This service is known to work with the MIT client library, mit-krb5.  Other implementations have not been tested.

 -- Variable Scheme: krb5-service-type
     A service type for Kerberos 5 clients.

Este es un ejemplo de su uso:

     (service krb5-service-type
              (krb5-configuration
               (default-realm "EXAMPLE.COM")
               (allow-weak-crypto? #t)
               (realms (list
                        (krb5-realm
                         (name "EXAMPLE.COM")
                         (admin-server "groucho.example.com")
                         (kdc "karl.example.com"))
                        (krb5-realm
                         (name "ARGRX.EDU")
                         (admin-server "kerb-admin.argrx.edu")
                         (kdc "keys.argrx.edu"))))))

This example provides a Kerberos 5 client configuration which:

  * Recognizes two realms, viz: ``EXAMPLE.COM'' and ``ARGRX.EDU'', both of which have distinct administration servers and key distribution centers;

  * Will default to the realm ``EXAMPLE.COM'' if the realm is not explicitly specified by clients;

  * Accepts services which only support encryption types known to be weak.

The krb5-realm and krb5-configuration types have many fields. Only the most commonly used ones are described here.  For a full list, and more detailed explanation of each, see the MIT krb5.conf documentation.

 -- Tipo de datos: krb5-realm

     name
          This field is a string identifying the name of the realm.  A common convention is to use the fully qualified DNS name of your organization, converted to upper case.

     admin-server
          This field is a string identifying the host where the administration server is running.

     kdc
          This field is a string identifying the key distribution center for the realm.

 -- Tipo de datos: krb5-configuration

     allow-weak-crypto? (predeterminado: #f)
          If this flag is #t then services which only offer encryption algorithms known to be weak will be accepted.

     default-realm (predeterminado: #f)
          This field should be a string identifying the default Kerberos realm for the client.  You should set this field to the name of your Kerberos realm.  If this value is #f then a realm must be specified with every Kerberos principal when invoking programs such as kinit.

     realms
          This should be a non-empty list of krb5-realm objects, which clients may access.  Normally, one of them will have a name field matching the default-realm field.

Servicio PAM krb5
.................

The pam-krb5 service allows for login authentication and password management via Kerberos.  You will need this service if you want PAM enabled applications to authenticate users using Kerberos.

 -- Variable Scheme: pam-krb5-service-type
     A service type for the Kerberos 5 PAM module.

 -- Tipo de datos: pam-krb5-configuration
     Data type representing the configuration of the Kerberos 5 PAM module This type has the following parameters:

     pam-krb5 (predeterminado: pam-krb5)
          El paquete pam-krb5 usado.

     minimum-uid (predeterminado: 1000)
          The smallest user ID for which Kerberos authentications should be attempted.  Local accounts with lower values will silently fail to authenticate.

Servicios LDAP
--------------

The (gnu services authentication) module provides the nslcd-service-type, which can be used to authenticate against an LDAP server.  In addition to configuring the service itself, you may want to add ldap as a name service to the Name Service Switch. See Selector de servicios de nombres for detailed information.

Here is a simple operating system declaration with a default configuration of the nslcd-service-type and a Name Service Switch configuration that consults the ldap name service last:

     (use-service-modules authentication)
     (use-modules (gnu system nss))
     ...
     (operating-system
       ...
       (services
         (cons*
           (service nslcd-service-type)
           (service dhcp-client-service-type)
           %base-services))
       (name-service-switch
        (let ((services (list (name-service (name "db"))
                              (name-service (name "files"))
                              (name-service (name "ldap")))))
          (name-service-switch
           (inherit %mdns-host-lookup-nss)
           (password services)
           (shadow   services)
           (group    services)
           (netgroup services)
           (gshadow  services)))))

Available nslcd-configuration fields are:

 -- nslcd-configuration parameter: package nss-pam-ldapd
     The nss-pam-ldapd package to use.

 -- nslcd-configuration parameter: maybe-number threads
     The number of threads to start that can handle requests and perform LDAP queries.  Each thread opens a separate connection to the LDAP server.  The default is to start 5 threads.

     Defaults to disabled.

 -- nslcd-configuration parameter: string uid
     This specifies the user id with which the daemon should be run.

     Defaults to "nslcd".

 -- nslcd-configuration parameter: string gid
     This specifies the group id with which the daemon should be run.

     Defaults to "nslcd".

 -- nslcd-configuration parameter: log-option log
     This option controls the way logging is done via a list containing SCHEME and LEVEL.  The SCHEME argument may either be the symbols "none" or "syslog", or an absolute file name.  The LEVEL argument is optional and specifies the log level.  The log level may be one of the following symbols: "crit", "error", "warning", "notice", "info" or "debug".  All messages with the specified log level or higher are logged.

     Defaults to ("/var/log/nslcd" info).

 -- nslcd-configuration parameter: list uri
     The list of LDAP server URIs.  Normally, only the first server will be used with the following servers as fall-back.

     Defaults to ("ldap://localhost:389/").

 -- nslcd-configuration parameter: maybe-string ldap-version
     The version of the LDAP protocol to use.  The default is to use the maximum version supported by the LDAP library.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string binddn
     Specifies the distinguished name with which to bind to the directory server for lookups.  The default is to bind anonymously.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string bindpw
     Specifies the credentials with which to bind.  This option is only applicable when used with binddn.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string rootpwmoddn
     Specifies the distinguished name to use when the root user tries to modify a user's password using the PAM module.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string rootpwmodpw
     Specifies the credentials with which to bind if the root user tries to change a user's password.  This option is only applicable when used with rootpwmoddn

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string sasl-mech
     Specifies the SASL mechanism to be used when performing SASL authentication.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string sasl-realm
     Specifies the SASL realm to be used when performing SASL authentication.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string sasl-authcid
     Specifies the authentication identity to be used when performing SASL authentication.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string sasl-authzid
     Specifies the authorization identity to be used when performing SASL authentication.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-boolean sasl-canonicalize?
     Determines whether the LDAP server host name should be canonicalised.  If this is enabled the LDAP library will do a reverse host name lookup.  By default, it is left up to the LDAP library whether this check is performed or not.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string krb5-ccname
     Set the name for the GSS-API Kerberos credentials cache.

     Defaults to disabled.

 -- nslcd-configuration parameter: string base
     The directory search base.

     Defaults to "dc=example,dc=com".

 -- nslcd-configuration parameter: scope-option scope
     Specifies the search scope (subtree, onelevel, base or children).  The default scope is subtree; base scope is almost never useful for name service lookups; children scope is not supported on all servers.

     Defaults to (subtree).

 -- nslcd-configuration parameter: maybe-deref-option deref
     Specifies the policy for dereferencing aliases.  The default policy is to never dereference aliases.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-boolean referrals
     Specifies whether automatic referral chasing should be enabled.  The default behaviour is to chase referrals.

     Defaults to disabled.

 -- nslcd-configuration parameter: list-of-map-entries maps
     This option allows for custom attributes to be looked up instead of the default RFC 2307 attributes.  It is a list of maps, each consisting of the name of a map, the RFC 2307 attribute to match and the query expression for the attribute as it is available in the directory.

     Defaults to ().

 -- nslcd-configuration parameter: list-of-filter-entries filters
     A list of filters consisting of the name of a map to which the filter applies and an LDAP search filter expression.

     Defaults to ().

 -- nslcd-configuration parameter: maybe-number bind-timelimit
     Specifies the time limit in seconds to use when connecting to the directory server.  The default value is 10 seconds.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-number timelimit
     Specifies the time limit (in seconds) to wait for a response from the LDAP server.  A value of zero, which is the default, is to wait indefinitely for searches to be completed.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-number idle-timelimit
     Specifies the period if inactivity (in seconds) after which the con‐ nection to the LDAP server will be closed.  The default is not to time out connections.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-number reconnect-sleeptime
     Specifies the number of seconds to sleep when connecting to all LDAP servers fails.  By default one second is waited between the first failure and the first retry.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-number reconnect-retrytime
     Specifies the time after which the LDAP server is considered to be permanently unavailable.  Once this time is reached retries will be done only once per this time period.  The default value is 10 seconds.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-ssl-option ssl
     Specifies whether to use SSL/TLS or not (the default is not to).  If 'start-tls is specified then StartTLS is used rather than raw LDAP over SSL.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-tls-reqcert-option tls-reqcert
     Specifies what checks to perform on a server-supplied certificate.  The meaning of the values is described in the ldap.conf(5) manual page.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string tls-cacertdir
     Specifies the directory containing X.509 certificates for peer authen‐ tication.  This parameter is ignored when using GnuTLS.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string tls-cacertfile
     Specifies the path to the X.509 certificate for peer authentication.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string tls-randfile
     Specifies the path to an entropy source.  This parameter is ignored when using GnuTLS.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string tls-ciphers
     Specifies the ciphers to use for TLS as a string.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string tls-cert
     Specifies the path to the file containing the local certificate for client TLS authentication.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string tls-key
     Specifies the path to the file containing the private key for client TLS authentication.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-number pagesize
     Set this to a number greater than 0 to request paged results from the LDAP server in accordance with RFC2696.  The default (0) is to not request paged results.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-ignore-users-option nss-initgroups-ignoreusers
     This option prevents group membership lookups through LDAP for the specified users.  Alternatively, the value 'all-local may be used.  With that value nslcd builds a full list of non-LDAP users on startup.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-number nss-min-uid
     This option ensures that LDAP users with a numeric user id lower than the specified value are ignored.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-number nss-uid-offset
     This option specifies an offset that is added to all LDAP numeric user ids. This can be used to avoid user id collisions with local users.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-number nss-gid-offset
     This option specifies an offset that is added to all LDAP numeric group ids.  This can be used to avoid user id collisions with local groups.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-boolean nss-nested-groups
     If this option is set, the member attribute of a group may point to another group.  Members of nested groups are also returned in the higher level group and parent groups are returned when finding groups for a specific user.  The default is not to perform extra searches for nested groups.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-boolean nss-getgrent-skipmembers
     If this option is set, the group member list is not retrieved when looking up groups.  Lookups for finding which groups a user belongs to will remain functional so the user will likely still get the correct groups assigned on login.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-boolean nss-disable-enumeration
     If this option is set, functions which cause all user/group entries to be loaded from the directory will not succeed in doing so.  This can dramatically reduce LDAP server load in situations where there are a great number of users and/or groups.  This option is not recommended for most configurations.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string validnames
     This option can be used to specify how user and group names are verified within the system.  This pattern is used to check all user and group names that are requested and returned from LDAP.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-boolean ignorecase
     This specifies whether or not to perform searches using case-insensitive matching.  Enabling this could open up the system to authorization bypass vulnerabilities and introduce nscd cache poisoning vulnerabilities which allow denial of service.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-boolean pam-authc-ppolicy
     This option specifies whether password policy controls are requested and handled from the LDAP server when performing user authentication.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string pam-authc-search
     By default nslcd performs an LDAP search with the user's credentials after BIND (authentication) to ensure that the BIND operation was successful.  The default search is a simple check to see if the user's DN exists.  A search filter can be specified that will be used instead.  It should return at least one entry.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string pam-authz-search
     This option allows flexible fine tuning of the authorisation check that should be performed.  The search filter specified is executed and if any entries match, access is granted, otherwise access is denied.

     Defaults to disabled.

 -- nslcd-configuration parameter: maybe-string pam-password-prohibit-message
     If this option is set password modification using pam_ldap will be denied and the specified message will be presented to the user instead.  The message can be used to direct the user to an alternative means of changing their password.

     Defaults to disabled.

 -- nslcd-configuration parameter: list pam-services
     List of pam service names for which LDAP authentication should suffice.

     Defaults to ().

Servicios Web
-------------

El módulo (gnu services web) proporciona el servidor HTTP Apache, el servidor web nginx y también un recubrimiento del daemon de fastcgi.

Servidor HTTP Apache
....................

 -- Variable Scheme: httpd-service-type
     Service type for the Apache HTTP (https://httpd.apache.org/) server (httpd).  The value for this service type is a httpd-configuration record.

     A simple example configuration is given below.

          (service httpd-service-type
                   (httpd-configuration
                     (config
                       (httpd-config-file
                         (server-name "www.example.com")
                         (document-root "/srv/http/www.example.com")))))

     Other services can also extend the httpd-service-type to add to the configuration.

          (simple-service 'mi-servidor-extra httpd-service-type
                          (list
                            (httpd-virtualhost
                              "*:80"
                              (list (string-append
                                     "ServerName "www.example.com
                                      DocumentRoot \"/srv/http/www.example.com\"")))))

The details for the httpd-configuration, httpd-module, httpd-config-file and httpd-virtualhost record types are given below.

 -- Tipo de datos: httpd-configuration
     This data type represents the configuration for the httpd service.

     package (predeterminado: httpd)
          El paquete httpd usado.

     pid-file (predeterminado: "/var/run/httpd")
          El fichero pid usado por el servicio de Shepherd.

     config (predeterminado: (httpd-config-file))
          The configuration file to use with the httpd service. The default value is a httpd-config-file record, but this can also be a different G-expression that generates a file, for example a plain-file. A file outside of the store can also be specified through a string.

 -- Tipo de datos: httpd-module
     This data type represents a module for the httpd service.

     name
          The name of the module.

     file
          The file for the module. This can be relative to the httpd package being used, the absolute location of a file, or a G-expression for a file within the store, for example (file-append mod-wsgi "/modules/mod_wsgi.so").

 -- Variable Scheme: %default-httpd-modules
     A default list of httpd-module objects.

 -- Tipo de datos: httpd-config-file
     This data type represents a configuration file for the httpd service.

     modules (predeterminados: %default-httpd-modules)
          The modules to load. Additional modules can be added here, or loaded by additional configuration.

          For example, in order to handle requests for PHP files, you can use Apache’s mod_proxy_fcgi module along with php-fpm-service-type:

               (service httpd-service-type
                        (httpd-configuration
                         (config
                          (httpd-config-file
                           (modules (cons*
                                     (httpd-module
                                      (name "proxy_module")
                                      (file "modules/mod_proxy.so"))
                                     (httpd-module
                                      (name "proxy_fcgi_module")
                                      (file "modules/mod_proxy_fcgi.so"))
                                     %default-httpd-modules))
                           (extra-config (list "\
               <FilesMatch \\.php$>
                   SetHandler \"proxy:unix:/var/run/php-fpm.sock|fcgi://localhost/\"
               </FilesMatch>"))))))
               (service php-fpm-service-type
                        (php-fpm-configuration
                         (socket "/var/run/php-fpm.sock")
                         (socket-group "httpd")))

     server-root (predeterminado: httpd)
          The ServerRoot in the configuration file, defaults to the httpd package. Directives including Include and LoadModule are taken as relative to the server root.

     server-name (predeterminado: #f)
          The ServerName in the configuration file, used to specify the request scheme, hostname and port that the server uses to identify itself.

          This doesn't need to be set in the server config, and can be specifyed in virtual hosts. The default is #f to not specify a ServerName.

     document-root (predeterminado: "/srv/http")
          The DocumentRoot from which files will be served.

     listen (predeterminado: '("80"))
          The list of values for the Listen directives in the config file. The value should be a list of strings, when each string can specify the port number to listen on, and optionally the IP address and protocol to use.

     pid-file (predeterminado: "/var/run/httpd")
          The PidFile to use. This should match the pid-file set in the httpd-configuration so that the Shepherd service is configured correctly.

     error-log (predeterminado: "/var/log/httpd/error_log")
          The ErrorLog to which the server will log errors.

     user (predeterminada: "httpd")
          La usuaria como la que el servidor responderá a las peticiones.

     group (predeterminado: "httpd")
          El grupo como el que el servidor responderá a las peticiones.

     extra-config (predeterminadas: (list "TypesConfig etc/httpd/mime.types"))
          A flat list of strings and G-expressions which will be added to the end of the configuration file.

          Any values which the service is extended with will be appended to this list.

 -- Tipo de datos: httpd-virtualhost
     This data type represents a virtualhost configuration block for the httpd service.

     These should be added to the extra-config for the httpd-service.

          (simple-service 'mi-servidor-extra httpd-service-type
                          (list
                            (httpd-virtualhost
                              "*:80"
                              (list (string-append
                                     "ServerName "www.example.com
                                      DocumentRoot \"/srv/http/www.example.com\"")))))

     addresses-and-ports
          The addresses and ports for the VirtualHost directive.

     contents
          The contents of the VirtualHost directive, this should be a list of strings and G-expressions.

NGINX
.....

 -- Variable Scheme: nginx-service-type
     Service type for the NGinx (https://nginx.org/) web server.  The value for this service type is a <nginx-configuration> record.

     A simple example configuration is given below.

          (service nginx-service-type
                   (nginx-configuration
                     (server-blocks
                       (list (nginx-server-configuration
                               (server-name '("www.example.com"))
                               (root "/srv/http/www.example.com"))))))

     In addition to adding server blocks to the service configuration directly, this service can be extended by other services to add server blocks, as in this example:

          (simple-service 'mi-servidor-extra nginx-service-type
                          (list (nginx-server-configuration
                                  (root "/srv/http/sitio-extra")
                                  (try-files (list "$uri" "$uri/index.html")))))

At startup, nginx has not yet read its configuration file, so it uses a default file to log error messages.  If it fails to load its configuration file, that is where error messages are logged.  After the configuration file is loaded, the default error log file changes as per configuration.  In our case, startup error messages can be found in /var/run/nginx/logs/error.log, and after configuration in /var/log/nginx/error.log.  The second location can be changed with the LOG-DIRECTORY configuration option.

 -- Tipo de datos: nginx-configuration
     This data type represents the configuration for NGinx. Some configuration can be done through this and the other provided record types, or alternatively, a config file can be provided.

     nginx (predeterminado: nginx)
          El paquete nginx usado.

     log-directory (predeterminado: "/var/log/nginx")
          The directory to which NGinx will write log files.

     run-directory (predeterminado: "/var/run/nginx")
          The directory in which NGinx will create a pid file, and write temporary files.

     server-blocks (predeterminados: '())
          A list of server blocks to create in the generated configuration file, the elements should be of type <nginx-server-configuration>.

          The following example would setup NGinx to serve www.example.com from the /srv/http/www.example.com directory, without using HTTPS.

               (service nginx-service-type
                        (nginx-configuration
                          (server-blocks
                            (list (nginx-server-configuration
                                    (server-name '("www.example.com"))
                                    (root "/srv/http/www.example.com"))))))

     upstream-blocks (predeterminados: '())
          A list of upstream blocks to create in the generated configuration file, the elements should be of type <nginx-upstream-configuration>.

          Configuring upstreams through the upstream-blocks can be useful when combined with locations in the <nginx-server-configuration> records.  The following example creates a server configuration with one location configuration, that will proxy requests to a upstream configuration, which will handle requests with two servers.

               (service
                 nginx-service-type
                 (nginx-configuration
                   (server-blocks
                     (list (nginx-server-configuration
                             (server-name '("www.example.com"))
                             (root "/srv/http/www.example.com")
                             (locations
                               (list
                                 (nginx-location-configuration
                                 (uri "/path1")
                                 (body '("proxy_pass http://server-proxy;"))))))))
                   (upstream-blocks
                     (list (nginx-upstream-configuration
                             (name "server-proxy")
                             (servers (list "server1.example.com"
                                            "server2.example.com")))))))

     file (predeterminado: #f)
          If a configuration FILE is provided, this will be used, rather than generating a configuration file from the provided log-directory, run-directory, server-blocks and upstream-blocks.  For proper operation, these arguments should match what is in FILE to ensure that the directories are created when the service is activated.

          This can be useful if you have an existing configuration file, or it's not possible to do what is required through the other parts of the nginx-configuration record.

     server-names-hash-bucket-size (predeterminado: #f)
          Bucket size for the server names hash tables, defaults to #f to use the size of the processors cache line.

     server-names-hash-bucket-max-size (predeterminado: #f)
          Maximum bucket size for the server names hash tables.

     extra-content (predeterminado: "")
          Extra content for the http block.  Should be string or a string valued G-expression.

 -- Tipo de datos: nginx-server-configuration
     Data type representing the configuration of an nginx server block.  This type has the following parameters:

     listen (predeterminadas: '("80" "443 ssl"))
          Each listen directive sets the address and port for IP, or the path for a UNIX-domain socket on which the server will accept requests.  Both address and port, or only address or only port can be specified.  An address may also be a hostname, for example:

               '("127.0.0.1:8000" "127.0.0.1" "8000" "*:8000" "localhost:8000")

     server-name (predeterminados: (list 'default))
          A list of server names this server represents. 'default represents the default server for connections matching no other server.

     root (predeterminada: "/srv/http")
          Raíz del sitio web que nginx proporcionará.

     locations (predeterminado: '())
          A list of nginx-location-configuration or nginx-named-location-configuration records to use within this server block.

     index (predeterminado: (list "index.html"))
          Index files to look for when clients ask for a directory.  If it cannot be found, Nginx will send the list of files in the directory.

     try-files (predeterminado: '())
          A list of files whose existence is checked in the specified order. nginx will use the first file it finds to process the request.

     ssl-certificate (predeterminado: #f)
          Where to find the certificate for secure connections.  Set it to #f if you don't have a certificate or you don't want to use HTTPS.

     ssl-certificate-key (predeterminado: #f)
          Where to find the private key for secure connections.  Set it to #f if you don't have a key or you don't want to use HTTPS.

     server-tokens? (predeterminado: #f)
          Whether the server should add its configuration to response.

     raw-content (predeterminado: '())
          A list of raw lines added to the server block.

 -- Tipo de datos: nginx-upstream-configuration
     Data type representing the configuration of an nginx upstream block. This type has the following parameters:

     name
          Name for this group of servers.

     servers
          Specify the addresses of the servers in the group.  The address can be specified as a IP address (e.g. 127.0.0.1), domain name (e.g. backend1.example.com) or a path to a UNIX socket using the prefix unix:.  For addresses using an IP address or domain name, the default port is 80, and a different port can be specified explicitly.

 -- Tipo de datos: nginx-location-configuration
     Data type representing the configuration of an nginx location block. This type has the following parameters:

     uri
          URI which this location block matches.

     body
          Body of the location block, specified as a list of strings. This can contain many configuration directives.  For example, to pass requests to a upstream server group defined using an nginx-upstream-configuration block, the following directive would be specified in the body (list "proxy_pass http://upstream-name;").

 -- Tipo de datos: nginx-named-location-configuration
     Data type representing the configuration of an nginx named location block. Named location blocks are used for request redirection, and not used for regular request processing.  This type has the following parameters:

     name
          Name to identify this location block.

     body
          See nginx-location-configuration body, as the body for named location blocks can be used in a similar way to the nginx-location-configuration body.  One restriction is that the body of a named location block cannot contain location blocks.

Varnish Cache
.............

Varnish is a fast cache server that sits in between web applications and end users.  It proxies requests from clients and caches the accessed URLs such that multiple requests for the same resource only creates one request to the back-end.

 -- Variable Scheme: varnish-service-type
     Service type for the Varnish daemon.

 -- Tipo de datos: varnish-configuration
     Data type representing the varnish service configuration.  This type has the following parameters:

     package (predeterminado: varnish)
          El paquete Varnish usado.

     name (predeterminado: "default")
          A name for this Varnish instance.  Varnish will create a directory in /var/varnish/ with this name and keep temporary files there.  If the name starts with a forward slash, it is interpreted as an absolute directory name.

          Pass the -n argument to other Varnish programs to connect to the named instance, e.g. varnishncsa -n default.

     backend (predeterminado: "localhost:8080")
          The backend to use.  This option has no effect if vcl is set.

     vcl (predeterminado: #f)
          The VCL (Varnish Configuration Language) program to run.  If this is #f, Varnish will proxy backend using the default configuration.  Otherwise this must be a file-like object with valid VCL syntax.

          For example, to mirror www.gnu.org (http://www.gnu.org) with VCL you can do something along these lines:

               (define %espejo-gnu
                 (plain-file
                  "gnu.vcl"
                  "vcl 4.1;
               backend gnu { .host = "www.gnu.org"; }"))

               (operating-system
                 ...
                 (services (cons (service varnish-service-type
                                          (varnish-configuration
                                           (listen '(":80"))
                                           (vcl %espejo-gnu)))
                                 %base-services)))

          The configuration of an already running Varnish instance can be inspected and changed using the varnishadm program.

          Consult the Varnish User Guide (https://varnish-cache.org/docs/) and Varnish Book (https://book.varnish-software.com/4.0/) for comprehensive documentation on Varnish and its configuration language.

     listen (predeterminada: '("localhost:80"))
          Lista de direcciones en las que Varnish escucha.

     storage (predeterminado: '("malloc,128m"))
          List of storage backends that will be available in VCL.

     parameters (predeterminados: '())
          List of run-time parameters in the form '(("parameter" . "value")).

     extra-options (predeterminadas: '())
          Additional arguments to pass to the varnishd process.

FastCGI
.......

FastCGI is an interface between the front-end and the back-end of a web service.  It is a somewhat legacy facility; new web services should generally just talk HTTP between the front-end and the back-end.  However there are a number of back-end services such as PHP or the optimized HTTP Git repository access that use FastCGI, so we have support for it in Guix.

To use FastCGI, you configure the front-end web server (e.g., nginx) to dispatch some subset of its requests to the fastcgi backend, which listens on a local TCP or UNIX socket.  There is an intermediary fcgiwrap program that sits between the actual backend process and the web server. The front-end indicates which backend program to run, passing that information to the fcgiwrap process.

 -- Variable Scheme: fcgiwrap-service-type
     A service type for the fcgiwrap FastCGI proxy.

 -- Tipo de datos: fcgiwrap-configuration
     Data type representing the configuration of the fcgiwrap service. This type has the following parameters:

     package (predeterminado: fcgiwrap)
          El paquete fcgiwrap usado.

     socket (predeterminado: tcp:127.0.0.1:9000)
          The socket on which the fcgiwrap process should listen, as a string. Valid SOCKET values include unix:/PATH/TO/UNIX/SOCKET, tcp:DOT.TED.QU.AD:PORT and tcp6:[IPV6_ADDR]:port.

     user (predeterminado: fcgiwrap)
     group (predeterminado: fcgiwrap)
          The user and group names, as strings, under which to run the fcgiwrap process.  The fastcgi service will ensure that if the user asks for the specific user or group names fcgiwrap that the corresponding user and/or group is present on the system.

          It is possible to configure a FastCGI-backed web service to pass HTTP authentication information from the front-end to the back-end, and to allow fcgiwrap to run the back-end process as a corresponding local user. To enable this capability on the back-end., run fcgiwrap as the root user and group.  Note that this capability also has to be configured on the front-end as well.

PHP-FPM (FastCGI Process Manager) is an alternative PHP FastCGI implementation with some additional features useful for sites of any size.

These features include:

  * Adaptive process spawning

  * Basic statistics (similar to Apache's mod_status)

  * Advanced process management with graceful stop/start

  * Ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode)

  * Stdout & stderr logging

  * Emergency restart in case of accidental opcode cache destruction

  * Accelerated upload support

  * Support for a "slowlog"

  * Enhancements to FastCGI, such as fastcgi_finish_request() - a special function to finish request & flush all data while continuing to do something time-consuming (video converting, stats processing, etc.)

... and much more.

 -- Variable Scheme: php-fpm-service-type
     Un tipo de servicio para php-fpm.

 -- Tipo de datos: php-fpm-configuration
     Tipo de datos para la configuración del servicio php-fpm.

     php (predeterminado: php)
          El paquete php usado.

     socket (predeterminado: (string-append "/var/run/php" (version-major (package-version php)) "-fpm.sock"))
          La dirección desde la que FastCGI acepta peticiones. Las sintaxis válidas son:

          "dir.ecc.ión.ip:puerto"
               Escucha con un socket TCP en la dirección especificada en un puerto específico.

          "puerto"
               Escucha en un socket TCP en todas las direcciones sobre un puerto específico.

          "/ruta/a/socket/unix"
               Escucha en un socket Unix.

     user (predeterminada: php-fpm)
          User who will own the php worker processes.

     group (predeterminado: php-fpm)
          Group of the worker processes.

     socket-user (predeterminado: php-fpm)
          User who can speak to the php-fpm socket.

     socket-group (predeterminado: php-fpm)
          Group that can speak to the php-fpm socket.

     pid-file (predeterminado: (string-append "/var/run/php" (version-major (package-version php)) "-fpm.pid"))
          The process id of the php-fpm process is written to this file once the service has started.

     log-file (predeterminado: (string-append "/var/log/php" (version-major (package-version php)) "-fpm.log"))
          Log for the php-fpm master process.

     process-manager (predeterminado: (php-fpm-dynamic-process-manager-configuration))
          Detailed settings for the php-fpm process manager.  Must be either:

          <php-fpm-dynamic-process-manager-configuration>

          <php-fpm-static-process-manager-configuration>

          <php-fpm-on-demand-process-manager-configuration>

     display-errors (predeterminado #f)
          Determines whether php errors and warning should be sent to clients and displayed in their browsers.  This is useful for local php development, but a security risk for public sites, as error messages can reveal passwords and personal data.

     timezone (default #f)
          Specifies php_admin_value[date.timezone] parameter.

     workers-logfile (predeterminado (string-append "/var/log/php" (version-major (package-version php)) "-fpm.www.log"))
          This file will log the stderr outputs of php worker processes.  Can be set to #f to disable logging.

     file (predeterminado #f)
          An optional override of the whole configuration.  You can use the mixed-text-file function or an absolute filepath for it.

 -- Tipo de datos: php-fpm-dynamic-process-manager-configuration
     Data Type for the dynamic php-fpm process manager.  With the dynamic process manager, spare worker processes are kept around based on it's configured limits.

     max-children (predeterminados: 5)
          Maximum of worker processes.

     start-servers (predeterminados: 2)
          How many worker processes should be started on start-up.

     min-spare-servers (predeterminado: 1)
          How many spare worker processes should be kept around at minimum.

     max-spare-servers (predeterminados: 3)
          How many spare worker processes should be kept around at maximum.

 -- Tipo de datos: php-fpm-static-process-manager-configuration
     Data Type for the static php-fpm process manager.  With the static process manager, an unchanging number of worker processes are created.

     max-children (predeterminados: 5)
          Maximum of worker processes.

 -- Tipo de datos: php-fpm-on-demand-process-manager-configuration
     Data Type for the on-demand php-fpm process manager.  With the on-demand process manager, worker processes are only created as requests arrive.

     max-children (predeterminados: 5)
          Maximum of worker processes.

     process-idle-timeout (predeterminado: 10)
          The time in seconds after which a process with no requests is killed.

 -- Procedimiento Scheme: nginx-php-fpm-location
     [#:nginx-package nginx]  [socket (string-append "/var/run/php"
     (version-major (package-version php))  "-fpm.sock")] A helper function to
     quickly add php to an nginx-server-configuration.

A simple services setup for nginx with php can look like this:

     (services (cons* (service dhcp-client-service-type)
                      (service php-fpm-service-type)
                      (service nginx-service-type
                               (nginx-server-configuration
                                (server-name '("example.com"))
                                (root "/srv/http/")
                                (locations
                                 (list (nginx-php-location)))
                                (listen '("80"))
                                (ssl-certificate #f)
                                (ssl-certificate-key #f)))
                      %base-services))

The cat avatar generator is a simple service to demonstrate the use of php-fpm in Nginx.  It is used to generate cat avatar from a seed, for instance the hash of a user's email address.

 -- Scheme Procedure: cat-avatar-generator-service
     [#:cache-dir "/var/cache/cat-avatar-generator"]  [#:package
     cat-avatar-generator]  [#:configuration (nginx-server-configuration)] Returns an nginx-server-configuration that inherits configuration. It extends the nginx configuration to add a server block that serves package, a version of cat-avatar-generator.  During execution, cat-avatar-generator will be able to use cache-dir as its cache directory.

A simple setup for cat-avatar-generator can look like this:

     (services (cons* (cat-avatar-generator-service
                       #:configuration
                       (nginx-server-configuration
                         (server-name '("example.com"))))
                      ...
                      %base-services))

Hpcguix-web
...........

The https://github.com/UMCUGenetics/hpcguix-web/ (hpcguix-web) program is a customizable web interface to browse Guix packages, initially designed for users of high-performance computing (HPC)  clusters.

 -- Variable Scheme: hpcguix-web-service-type
     El tipo de servicio para hpcguix-web.

 -- Tipo de datos: hpcguix-web-configuration
     El tipo de datos para la configuración del servicio hpcguix-web.

     specs
          A gexp (see Expresiones-G) specifying the hpcguix-web service configuration.  The main items available in this spec are:

          title-prefix (predeterminado: "hpcguix | ")
               El prefijo del título de la página.

          guix-command (predeterminada: "guix")
               La orden guix.

          package-filter-proc (predeterminado: (const #t))
               A procedure specifying how to filter packages that are displayed.

          package-page-extension-proc (predeterminado: (const '()))
               Extension package for hpcguix-web.

          menu (predeterminadas: '())
               Entradas adicionales en el menú de la página.

          channels (predeterminados: %default-channels)
               List of channels from which the package list is built (see Canales).

          package-list-expiration (predeterminado: (* 12 3600))
               The expiration time, in seconds, after which the package list is rebuilt from the latest instances of the given channels.

          See the hpcguix-web repository for a complete example (https://github.com/UMCUGenetics/hpcguix-web/blob/master/hpcweb-configuration.scm).

     package (predeterminado: hpcguix-web)
          The hpcguix-web package to use.

A typical hpcguix-web service declaration looks like this:

     (service hpcguix-web-service-type
              (hpcguix-web-configuration
               (specs
                #~(define site-config
                    (hpcweb-configuration
                     (title-prefix "Guix-HPC - ")
                     (menu '(("/about" "ABOUT"))))))))

     The hpcguix-web service periodically updates the package list it publishes by pulling channels from Git.  To that end, it needs to access X.509 certificates so that it can authenticate Git servers when communicating over HTTPS, and it assumes that /etc/ssl/certs contains those certificates.

     Thus, make sure to add nss-certs or another certificate package to the packages field of your configuration.  Certificados X.509, for more information on X.509 certificates.

Servicios de certificados
-------------------------

The (gnu services certbot) module provides a service to automatically obtain a valid TLS certificate from the Let's Encrypt certificate authority.  These certificates can then be used to serve content securely over HTTPS or other TLS-based protocols, with the knowledge that the client will be able to verify the server's authenticity.

Let's Encrypt (https://letsencrypt.org/) provides the certbot tool to automate the certification process.  This tool first securely generates a key on the server.  It then makes a request to the Let's Encrypt certificate authority (CA) to sign the key.  The CA checks that the request originates from the host in question by using a challenge-response protocol, requiring the server to provide its response over HTTP.  If that protocol completes successfully, the CA signs the key, resulting in a certificate. That certificate is valid for a limited period of time, and therefore to continue to provide TLS services, the server needs to periodically ask the CA to renew its signature.

The certbot service automates this process: the initial key generation, the initial certification request to the Let's Encrypt service, the web server challenge/response integration, writing the certificate to disk, the automated periodic renewals, and the deployment tasks associated with the renewal (e.g. reloading services, copying keys with different permissions).

Certbot is run twice a day, at a random minute within the hour.  It won't do anything until your certificates are due for renewal or revoked, but running it regularly would give your service a chance of staying online in case a Let's Encrypt-initiated revocation happened for some reason.

By using this service, you agree to the ACME Subscriber Agreement, which can be found there: https://acme-v01.api.letsencrypt.org/directory.

 -- Variable Scheme: certbot-service-type
     A service type for the certbot Let's Encrypt client.  Its value must be a certbot-configuration record as in this example:

          (define %nginx-deploy-hook
            (program-file
             "nginx-deploy-hook"
             #~(let ((pid (call-with-input-file "/var/run/nginx/pid" read)))
                 (kill pid SIGHUP))))

          (service certbot-service-type
                   (certbot-configuration
                    (email "foo@example.net")
                    (certificates
                     (list
                      (certificate-configuration
                       (domains '("example.net" "www.example.net"))
                       (deploy-hook %nginx-deploy-hook))
                      (certificate-configuration
                       (domains '("bar.example.net")))))))

     See below for details about certbot-configuration.

 -- Tipo de datos: certbot-configuration
     Data type representing the configuration of the certbot service. This type has the following parameters:

     package (predeterminado: certbot)
          El paquete certbot usado.

     webroot (predeterminado: /var/www)
          The directory from which to serve the Let's Encrypt challenge/response files.

     certificates (predeterminados: ())
          A list of certificates-configurations for which to generate certificates and request signatures.  Each certificate has a name and several domains.

     email
          Mandatory email used for registration, recovery contact, and important account notifications.

     rsa-key-size (predeterminado: 2048)
          Tamaño de la clave RSA.

     default-location (predeterminada: vea a continuación)
          The default nginx-location-configuration.  Because certbot needs to be able to serve challenges and responses, it needs to be able to run a web server.  It does so by extending the nginx web service with an nginx-server-configuration listening on the DOMAINS on port 80, and which has a nginx-location-configuration for the /.well-known/ URI path subspace used by Let's Encrypt.  See Servicios Web, for more on these nginx configuration data types.

          Requests to other URL paths will be matched by the default-location, which if present is added to all nginx-server-configurations.

          By default, the default-location will issue a redirect from http://DOMAIN/... to https://DOMAIN/..., leaving you to define what to serve on your site via https.

          Pass #f to not issue a default location.

 -- Tipo de datos: certificate-configuration
     Data type representing the configuration of a certificate.  This type has the following parameters:

     name (predeterminado: vea a continuación)
          This name is used by Certbot for housekeeping and in file paths; it doesn't affect the content of the certificate itself.  To see certificate names, run certbot certificates.

          Its default is the first provided domain.

     domains (predeterminado: ())
          The first domain provided will be the subject CN of the certificate, and all domains will be Subject Alternative Names on the certificate.

     deploy-hook (predeterminado: #f)
          Command to be run in a shell once for each successfully issued certificate. For this command, the shell variable $RENEWED_LINEAGE will point to the config live subdirectory (for example, "/etc/letsencrypt/live/example.com") containing the new certificates and keys; the shell variable $RENEWED_DOMAINS will contain a space-delimited list of renewed certificate domains (for example, "example.com www.example.com".

For each certificate-configuration, the certificate is saved to /etc/letsencrypt/live/NAME/fullchain.pem and the key is saved to /etc/letsencrypt/live/NAME/privkey.pem.

Servicios DNS
-------------

The (gnu services dns) module provides services related to the domain name system (DNS).  It provides a server service for hosting an authoritative DNS server for multiple zones, slave or master.  This service uses Knot DNS (https://www.knot-dns.cz/).  And also a caching and forwarding DNS server for the LAN, which uses dnsmasq (http://www.thekelleys.org.uk/dnsmasq/doc.html).

Servicio Knot
.............

An example configuration of an authoritative server for two zones, one master and one slave, is:

     (define-zone-entries example.org.zone
     ;; Name TTL Class Type Data
       ("@"  ""  "IN"  "A"  "127.0.0.1")
       ("@"  ""  "IN"  "NS" "ns")
       ("ns" ""  "IN"  "A"  "127.0.0.1"))

     (define master-zone
       (knot-zone-configuration
         (domain "example.org")
         (zone (zone-file
                 (origin "example.org")
                 (entries example.org.zone)))))

     (define slave-zone
       (knot-zone-configuration
         (domain "plop.org")
         (dnssec-policy "default")
         (master (list "plop-master"))))

     (define plop-master
       (knot-remote-configuration
         (id "plop-master")
         (address (list "208.76.58.171"))))

     (operating-system
       ;; ...
       (services (cons* (service knot-service-type
                          (knot-configuration
                            (remotes (list plop-master))
                            (zones (list master-zone slave-zone))))
                        ;; ...
                        %base-services)))

 -- Variable Scheme: knot-service-type
     This is the type for the Knot DNS server.

     Knot DNS is an authoritative DNS server, meaning that it can serve multiple zones, that is to say domain names you would buy from a registrar.  This server is not a resolver, meaning that it can only resolve names for which it is authoritative.  This server can be configured to serve zones as a master server or a slave server as a per-zone basis.  Slave zones will get their data from masters, and will serve it as an authoritative server.  From the point of view of a resolver, there is no difference between master and slave.

     The following data types are used to configure the Knot DNS server:

 -- Tipo de datos: knot-key-configuration
     Data type representing a key.  This type has the following parameters:

     id (predeterminado: "")
          An identifier for other configuration fields to refer to this key. IDs must be unique and must not be empty.

     algorithm (predeterminado: #f)
          The algorithm to use.  Choose between #f, 'hmac-md5, 'hmac-sha1, 'hmac-sha224, 'hmac-sha256, 'hmac-sha384 and 'hmac-sha512.

     secret (predeterminado: "")
          The secret key itself.

 -- Tipo de datos: knot-acl-configuration
     Data type representing an Access Control List (ACL) configuration.  This type has the following parameters:

     id (predeterminado: "")
          An identifier for ether configuration fields to refer to this key. IDs must be unique and must not be empty.

     address (predeterminada: '())
          An ordered list of IP addresses, network subnets, or network ranges represented with strings.  The query must match one of them.  Empty value means that address match is not required.

     key (predeterminada: '())
          An ordered list of references to keys represented with strings.  The string must match a key ID defined in a knot-key-configuration.  No key means that a key is not require to match that ACL.

     action (predeterminada: '())
          An ordered list of actions that are permitted or forbidden by this ACL. Possible values are lists of zero or more elements from 'transfer, 'notify and 'update.

     deny? (predeterminado: #f)
          When true, the ACL defines restrictions.  Listed actions are forbidden. When false, listed actions are allowed.

 -- Tipo de datos: zone-entry
     Data type represnting a record entry in a zone file.  This type has the following parameters:

     name (predeterminado: "@")
          The name of the record.  "@" refers to the origin of the zone. Names are relative to the origin of the zone.  For example, in the example.org zone, "ns.example.org" actually refers to ns.example.org.example.org.  Names ending with a dot are absolute, which means that "ns.example.org." refers to ns.example.org.

     ttl (predeterminado: "")
          The Time-To-Live (TTL) of this record.  If not set, the default TTL is used.

     class (predeterminada: "IN")
          The class of the record.  Knot currently supports only "IN" and partially "CH".

     type (predeterminado: "A")
          The type of the record.  Common types include A (IPv4 address), AAAA (IPv6 address), NS (Name Server) and MX (Mail eXchange).  Many other types are defined.

     data (predeterminados: "")
          The data contained in the record.  For instance an IP address associated with an A record, or a domain name associated with an NS record.  Remember that domain names are relative to the origin unless they end with a dot.

 -- Tipo de datos: zone-file
     Data type representing the content of a zone file.  This type has the following parameters:

     entries (predeterminadas: '())
          The list of entries.  The SOA record is taken care of, so you don't need to put it in the list of entries.  This list should probably contain an entry for your primary authoritative DNS server.  Other than using a list of entries directly, you can use define-zone-entries to define a object containing the list of entries more easily, that you can later pass to the entries field of the zone-file.

     origin (predeterminado: "")
          The name of your zone.  This parameter cannot be empty.

     ns (predeterminado: "ns")
          The domain of your primary authoritative DNS server.  The name is relative to the origin, unless it ends with a dot.  It is mandatory that this primary DNS server corresponds to an NS record in the zone and that it is associated to an IP address in the list of entries.

     mail (predeterminado: "hostmaster")
          An email address people can contact you at, as the owner of the zone.  This is translated as <mail>@<origin>.

     serial (predeterminado: 1)
          The serial number of the zone.  As this is used to keep track of changes by both slaves and resolvers, it is mandatory that it never decreases. Always increment it when you make a change in your zone.

     refresh (predeterminado: (* 2 24 3600))
          The frequency at which slaves will do a zone transfer.  This value is a number of seconds.  It can be computed by multiplications or with (string->duration).

     retry (predeterminado: (* 15 60))
          The period after which a slave will retry to contact its master when it fails to do so a first time.

     expiry (predeterminado: (* 14 24 3600))
          Default TTL of records.  Existing records are considered correct for at most this amount of time.  After this period, resolvers will invalidate their cache and check again that it still exists.

     nx (predeterminado: 3600)
          Default TTL of inexistant records.  This delay is usually short because you want your new domains to reach everyone quickly.

 -- Tipo de datos: knot-remote-configuration
     Data type representing a remote configuration.  This type has the following parameters:

     id (predeterminado: "")
          An identifier for other configuration fields to refer to this remote. IDs must be unique and must not be empty.

     address (predeterminada: '())
          An ordered list of destination IP addresses.  Addresses are tried in sequence.  An optional port can be given with the @ separator.  For instance: (list "1.2.3.4" "2.3.4.5@53").  Default port is 53.

     via (predeterminada: '())
          An ordered list of source IP addresses.  An empty list will have Knot choose an appropriate source IP.  An optional port can be given with the @ separator.  The default is to choose at random.

     key (predeterminada: #f)
          A reference to a key, that is a string containing the identifier of a key defined in a knot-key-configuration field.

 -- Tipo de datos: knot-keystore-configuration
     Data type representing a keystore to hold dnssec keys.  This type has the following parameters:

     id (predeterminado: "")
          The id of the keystore.  It must not be empty.

     backend (predeterminado: 'pem)
          El motor en el que se almacenan las claves. Puede ser 'pem o 'pkcs11.

     config (predeterminada: "/var/lib/knot/keys/keys")
          The configuration string of the backend.  An example for the PKCS#11 is: "pkcs11:token=knot;pin-value=1234 /gnu/store/.../lib/pkcs11/libsofthsm2.so".  For the pem backend, the string reprensents a path in the file system.

 -- Tipo de datos: knot-policy-configuration
     Data type representing a dnssec policy.  Knot DNS is able to automatically sign your zones.  It can either generate and manage your keys automatically or use keys that you generate.

     Dnssec is usually implemented using two keys: a Key Signing Key (KSK) that is used to sign the second, and a Zone Signing Key (ZSK) that is used to sign the zone.  In order to be trusted, the KSK needs to be present in the parent zone (usually a top-level domain).  If your registrar supports dnssec, you will have to send them your KSK's hash so they can add a DS record in their zone.  This is not automated and need to be done each time you change your KSK.

     The policy also defines the lifetime of keys.  Usually, ZSK can be changed easily and use weaker cryptographic functions (they use lower parameters) in order to sign records quickly, so they are changed often.  The KSK however requires manual interaction with the registrar, so they are changed less often and use stronger parameters because they sign only one record.

     Este tipo tiene los siguientes parámetros:

     id (predeterminado: "")
          The id of the policy.  It must not be empty.

     keystore (predeterminado: "default")
          A reference to a keystore, that is a string containing the identifier of a keystore defined in a knot-keystore-configuration field.  The "default" identifier means the default keystore (a kasp database that was setup by this service).

     manual? (predeterminado: #f)
          Whether the key management is manual or automatic.

     single-type-signing? (predeterminado: #f)
          When #t, use the Single-Type Signing Scheme.

     algorithm (predeterminado: "ecdsap256sha256")
          An algorithm of signing keys and issued signatures.

     ksk-size (predeterminado: 256)
          The length of the KSK.  Note that this value is correct for the default algorithm, but would be unsecure for other algorithms.

     zsk-size (predeterminado: 256)
          The length of the ZSK.  Note that this value is correct for the default algorithm, but would be unsecure for other algorithms.

     dnskey-ttl (predeterminado: 'default)
          The TTL value for DNSKEY records added into zone apex.  The special 'default value means same as the zone SOA TTL.

     zsk-lifetime (predeterminado: (* 30 24 3600))
          The period between ZSK publication and the next rollover initiation.

     propagation-delay (predeterminado: (* 24 3600))
          An extra delay added for each key rollover step.  This value should be high enough to cover propagation of data from the master server to all slaves.

     rrsig-lifetime (predeterminado: (* 14 24 3600))
          A validity period of newly issued signatures.

     rrsig-refresh (predeterminado: (* 7 24 3600))
          A period how long before a signature expiration the signature will be refreshed.

     nsec3? (predeterminado: #f)
          When #t, NSEC3 will be used instead of NSEC.

     nsec3-iterations (predeterminado: 5)
          The number of additional times the hashing is performed.

     nsec3-salt-length (predeterminado: 8)
          The length of a salt field in octets, which is appended to the original owner name before hashing.

     nsec3-salt-lifetime (predeterminado: (* 30 24 3600))
          The validity period of newly issued salt field.

 -- Tipo de datos: knot-zone-configuration
     Data type representing a zone served by Knot.  This type has the following parameters:

     domain (predeterminado: "")
          The domain served by this configuration.  It must not be empty.

     file (predeterminado: "")
          The file where this zone is saved.  This parameter is ignored by master zones.  Empty means default location that depends on the domain name.

     zone (predeterminado: (zone-file))
          The content of the zone file.  This parameter is ignored by slave zones.  It must contain a zone-file record.

     master (predeterminado: '())
          A list of master remotes.  When empty, this zone is a master.  When set, this zone is a slave.  This is a list of remotes identifiers.

     ddns-master (predeterminado: #f)
          The main master.  When empty, it defaults to the first master in the list of masters.

     notify (predeterminado: '())
          A list of slave remote identifiers.

     acl (predeterminado: '())
          A list of acl identifiers.

     semantic-checks? (predeterminado: #f)
          When set, this adds more semantic checks to the zone.

     disable-any? (predeterminado: #f)
          When set, this forbids queries of the ANY type.

     zonefile-sync (predeterminado: 0)
          The delay between a modification in memory and on disk.  0 means immediate synchronization.

     serial-policy (predeterminado: 'increment)
          A policy between 'increment and 'unixtime.

 -- Tipo de datos: knot-configuration
     Data type representing the Knot configuration.  This type has the following parameters:

     knot (predeterminado: knot)
          El paquete Knot.

     run-directory (predeterminado: "/var/run/knot")
          The run directory.  This directory will be used for pid file and sockets.

     listen-v4 (predeterminada: "0.0.0.0")
          La dirección IP en la que escuchar.

     listen-v6 (predeterminada: "::")
          La dirección IP en la que escuchar.

     listen-port (predeterminado: 53)
          El puerto en el que escuchar.

     keys (predeterminada: '())
          The list of knot-key-configuration used by this configuration.

     acls (predeterminado: '())
          The list of knot-acl-configuration used by this configuration.

     remotes (predeterminada: '())
          The list of knot-remote-configuration used by this configuration.

     zones (predeterminada: '())
          The list of knot-zone-configuration used by this configuration.

Servicio Dnsmasq
................

 -- Variable Scheme: dnsmasq-service-type
     This is the type of the dnsmasq service, whose value should be an dnsmasq-configuration object as in this example:

          (service dnsmasq-service-type
                   (dnsmasq-configuration
                     (no-resolv? #t)
                     (servers '("192.168.1.1"))))

 -- Tipo de datos: dnsmasq-configuration
     Data type representing the configuration of dnsmasq.

     package (predeterminado: DNSMASQ)
          Package object of the dnsmasq server.

     no-hosts? (predeterminado: #f)
          When true, don't read the hostnames in /etc/hosts.

     port (predeterminado: 53)
          The port to listen on.  Setting this to zero completely disables DNS responses, leaving only DHCP and/or TFTP functions.

     local-service? (predeterminado: #t)
          Accept DNS queries only from hosts whose address is on a local subnet, ie a subnet for which an interface exists on the server.

     listen-addresses (predeterminadas: '())
          Escucha en las direcciones IP proporcionadas.

     resolv-file (predeterminado: "/etc/resolv.conf")
          The file to read the IP address of the upstream nameservers from.

     no-resolv? (predeterminado: #f)
          When true, don't read RESOLV-FILE.

     servers (predeterminados: '())
          Specify IP address of upstream servers directly.

     cache-size (predeterminado: 150)
          Set the size of dnsmasq's cache.  Setting the cache size to zero disables caching.

     negative-cache? (predeterminado: #t)
          When false, disable negative caching.

Servicio ddclient
.................

The ddclient service described below runs the ddclient daemon, which takes care of automatically updating DNS entries for service providers such as Dyn (https://dyn.com/dns/).

The following example show instantiates the service with its default configuration:

     (service ddclient-service-type)

Note that ddclient needs to access credentials that are stored in a secret file, by default /etc/ddclient/secrets (see secret-file below.)  You are expected to create this file manually, in an ``out-of-band'' fashion (you could make this file part of the service configuration, for instance by using plain-file, but it will be world-readable via /gnu/store.)  See the examples in the share/ddclient directory of the ddclient package.

Los campos disponibles de ddclient-configuration son:

 -- ddclient-configuration parameter: package ddclient
     El paquete ddclient.

 -- ddclient-configuration parameter: integer daemon
     The period after which ddclient will retry to check IP and domain name.

     Defaults to 300.

 -- ddclient-configuration parameter: boolean syslog
     Use syslog for the output.

     Defaults to #t.

 -- ddclient-configuration parameter: string mail
     Mail to user.

     Defaults to "root".

 -- ddclient-configuration parameter: string mail-failure
     Mail failed update to user.

     Defaults to "root".

 -- ddclient-configuration parameter: string pid
     The ddclient PID file.

     Defaults to "/var/run/ddclient/ddclient.pid".

 -- ddclient-configuration parameter: boolean ssl
     Enable SSL support.

     Defaults to #t.

 -- ddclient-configuration parameter: string user
     Specifies the user name or ID that is used when running ddclient program.

     Defaults to "ddclient".

 -- ddclient-configuration parameter: string group
     Group of the user who will run the ddclient program.

     Defaults to "ddclient".

 -- ddclient-configuration parameter: string secret-file
     Secret file which will be appended to ddclient.conf file.  This file contains credentials for use by ddclient.  You are expected to create it manually.

     Defaults to "/etc/ddclient/secrets.conf".

 -- ddclient-configuration parameter: list extra-options
     Extra options will be appended to ddclient.conf file.

     Defaults to ().

Servicios VPN
-------------

The (gnu services vpn) module provides services related to virtual private networks (VPNs).  It provides a client service for your machine to connect to a VPN, and a servire service for your machine to host a VPN.  Both services use OpenVPN (https://openvpn.net/).

 -- Procedimiento Scheme: openvpn-client-service
     [#:config (openvpn-client-configuration)]

     Devuelve un servicio que ejecuta openvpn, un daemon VPN, como cliente.

 -- Procedimiento Scheme: openvpn-server-service
     [#:config (openvpn-server-configuration)]

     Devuelve un servicio que ejecuta openvpn, un daemon VPN, como servidor.

     Pueden ejecutarse simultáneamente.

Los campos disponibles de openvpn-client-configuration son:

 -- openvpn-client-configuration parameter: package openvpn
     El paquete OpenVPN.

 -- openvpn-client-configuration parameter: string pid-file
     The OpenVPN pid file.

     Defaults to "/var/run/openvpn/openvpn.pid".

 -- openvpn-client-configuration parameter: proto proto
     The protocol (UDP or TCP) used to open a channel between clients and servers.

     Defaults to udp.

 -- openvpn-client-configuration parameter: dev dev
     The device type used to represent the VPN connection.

     Defaults to tun.

 -- openvpn-client-configuration parameter: string ca
     The certificate authority to check connections against.

     Defaults to "/etc/openvpn/ca.crt".

 -- openvpn-client-configuration parameter: string cert
     The certificate of the machine the daemon is running on.  It should be signed by the authority given in ca.

     Defaults to "/etc/openvpn/client.crt".

 -- openvpn-client-configuration parameter: string key
     The key of the machine the daemon is running on.  It must be the key whose certificate is cert.

     Defaults to "/etc/openvpn/client.key".

 -- openvpn-client-configuration parameter: boolean comp-lzo?
     Whether to use the lzo compression algorithm.

     Defaults to #t.

 -- openvpn-client-configuration parameter: boolean persist-key?
     Don't re-read key files across SIGUSR1 or --ping-restart.

     Defaults to #t.

 -- openvpn-client-configuration parameter: boolean persist-tun?
     Don't close and reopen TUN/TAP device or run up/down scripts across SIGUSR1 or --ping-restart restarts.

     Defaults to #t.

 -- openvpn-client-configuration parameter: number verbosity
     Verbosity level.

     Defaults to 3.

 -- openvpn-client-configuration parameter: tls-auth-client tls-auth
     Add an additional layer of HMAC authentication on top of the TLS control channel to protect against DoS attacks.

     El valor predeterminado es #f

 -- openvpn-client-configuration parameter: key-usage verify-key-usage?
     Whether to check the server certificate has server usage extension.

     Defaults to #t.

 -- openvpn-client-configuration parameter: bind bind?
     Bind to a specific local port number.

     El valor predeterminado es #f

 -- openvpn-client-configuration parameter: resolv-retry resolv-retry?
     Retry resolving server address.

     Defaults to #t.

 -- openvpn-client-configuration parameter: openvpn-remote-list remote
     A list of remote servers to connect to.

     Defaults to ().

     Los campos disponibles de openvpn-remote-configuration son:

      -- openvpn-remote-configuration parameter: string name
          Nombre del servidor.

          Defaults to "my-server".

      -- openvpn-remote-configuration parameter: number port
          Port number the server listens to.

          Defaults to 1194.

Available openvpn-server-configuration fields are:

 -- openvpn-server-configuration parameter: package openvpn
     El paquete OpenVPN.

 -- openvpn-server-configuration parameter: string pid-file
     The OpenVPN pid file.

     Defaults to "/var/run/openvpn/openvpn.pid".

 -- openvpn-server-configuration parameter: proto proto
     The protocol (UDP or TCP) used to open a channel between clients and servers.

     Defaults to udp.

 -- openvpn-server-configuration parameter: dev dev
     The device type used to represent the VPN connection.

     Defaults to tun.

 -- openvpn-server-configuration parameter: string ca
     The certificate authority to check connections against.

     Defaults to "/etc/openvpn/ca.crt".

 -- openvpn-server-configuration parameter: string cert
     The certificate of the machine the daemon is running on.  It should be signed by the authority given in ca.

     Defaults to "/etc/openvpn/client.crt".

 -- openvpn-server-configuration parameter: string key
     The key of the machine the daemon is running on.  It must be the key whose certificate is cert.

     Defaults to "/etc/openvpn/client.key".

 -- openvpn-server-configuration parameter: boolean comp-lzo?
     Whether to use the lzo compression algorithm.

     Defaults to #t.

 -- openvpn-server-configuration parameter: boolean persist-key?
     Don't re-read key files across SIGUSR1 or --ping-restart.

     Defaults to #t.

 -- openvpn-server-configuration parameter: boolean persist-tun?
     Don't close and reopen TUN/TAP device or run up/down scripts across SIGUSR1 or --ping-restart restarts.

     Defaults to #t.

 -- openvpn-server-configuration parameter: number verbosity
     Verbosity level.

     Defaults to 3.

 -- openvpn-server-configuration parameter: tls-auth-server tls-auth
     Add an additional layer of HMAC authentication on top of the TLS control channel to protect against DoS attacks.

     El valor predeterminado es #f

 -- openvpn-server-configuration parameter: number port
     Specifies the port number on which the server listens.

     Defaults to 1194.

 -- openvpn-server-configuration parameter: ip-mask server
     An ip and mask specifying the subnet inside the virtual network.

     Defaults to "10.8.0.0 255.255.255.0".

 -- openvpn-server-configuration parameter: cidr6 server-ipv6
     A CIDR notation specifying the IPv6 subnet inside the virtual network.

     El valor predeterminado es #f

 -- openvpn-server-configuration parameter: string dh
     The Diffie-Hellman parameters file.

     Defaults to "/etc/openvpn/dh2048.pem".

 -- openvpn-server-configuration parameter: string ifconfig-pool-persist
     The file that records client IPs.

     Defaults to "/etc/openvpn/ipp.txt".

 -- openvpn-server-configuration parameter: gateway redirect-gateway?
     When true, the server will act as a gateway for its clients.

     El valor predeterminado es #f

 -- openvpn-server-configuration parameter: boolean client-to-client?
     When true, clients are allowed to talk to each other inside the VPN.

     El valor predeterminado es #f

 -- openvpn-server-configuration parameter: keepalive keepalive
     Causes ping-like messages to be sent back and forth over the link so that each side knows when the other side has gone down.  keepalive requires a pair.  The first element is the period of the ping sending, and the second element is the timeout before considering the other side down.

 -- openvpn-server-configuration parameter: number max-clients
     The maximum number of clients.

     Defaults to 100.

 -- openvpn-server-configuration parameter: string status
     The status file.  This file shows a small report on current connection.  It is truncated and rewritten every minute.

     Defaults to "/var/run/openvpn/status".

 -- openvpn-server-configuration parameter: openvpn-ccd-list client-config-dir
     The list of configuration for some clients.

     Defaults to ().

     Available openvpn-ccd-configuration fields are:

      -- openvpn-ccd-configuration parameter: string name
          Nombre del cliente.

          Defaults to "client".

      -- openvpn-ccd-configuration parameter: ip-mask iroute
          Client own network

          El valor predeterminado es #f

      -- openvpn-ccd-configuration parameter: ip-mask ifconfig-push
          Client VPN IP.

          El valor predeterminado es #f

Sistema de ficheros en red
--------------------------

The (gnu services nfs) module provides the following services, which are most commonly used in relation to mounting or exporting directory trees as network file systems (NFS).

RPC Bind Service
................

The RPC Bind service provides a facility to map program numbers into universal addresses.  Many NFS related services use this facility.  Hence it is automatically started when a dependent service starts.

 -- Variable Scheme: rpcbind-service-type
     A service type for the RPC portmapper daemon.

 -- Tipo de datos: rpcbind-configuration
     Data type representing the configuration of the RPC Bind Service.  This type has the following parameters:

     rpcbind (default: rpcbind)
          The rpcbind package to use.

     warm-start? (default: #t)
          If this parameter is #t, then the daemon will read a state file on startup thus reloading state information saved by a previous instance.

Pipefs Pseudo File System
.........................

The pipefs file system is used to transfer NFS related data between the kernel and user space programs.

 -- Variable Scheme: pipefs-service-type
     A service type for the pipefs pseudo file system.

 -- Tipo de datos: pipefs-configuration
     Data type representing the configuration of the pipefs pseudo file system service.  This type has the following parameters:

     mount-point (default: "/var/lib/nfs/rpc_pipefs")
          The directory to which the file system is to be attached.

Servicio del daemon GSS
.......................

The global security system (GSS) daemon provides strong security for RPC based protocols.  Before exchanging RPC requests an RPC client must establish a security context.  Typically this is done using the Kerberos command kinit or automatically at login time using PAM services (see Servicios Kerberos).

 -- Variable Scheme: gss-service-type
     Un tipo de servicio para el daemon del sistema de seguridad global (GSS).

 -- Tipo de datos: gss-configuration
     Data type representing the configuration of the GSS daemon service.  This type has the following parameters:

     nfs-utils (predeterminado: nfs-utils)
          The package in which the rpc.gssd command is to be found.

     pipefs-directory (predeterminado: "/var/lib/nfs/rpc_pipefs")
          The directory where the pipefs file system is mounted.

Servicio del daemon IDMAP
.........................

The idmap daemon service provides mapping between user IDs and user names. Typically it is required in order to access file systems mounted via NFSv4.

 -- Variable Scheme: idmap-service-type
     A service type for the Identity Mapper (IDMAP) daemon.

 -- Tipo de datos: idmap-configuration
     Data type representing the configuration of the IDMAP daemon service.  This type has the following parameters:

     nfs-utils (predeterminado: nfs-utils)
          The package in which the rpc.idmapd command is to be found.

     pipefs-directory (predeterminado: "/var/lib/nfs/rpc_pipefs")
          The directory where the pipefs file system is mounted.

     domain (predeterminado: #f)
          The local NFSv4 domain name.  This must be a string or #f.  If it is #f then the daemon will use the host's fully qualified domain name.

Integración continua
--------------------

Cuirass (https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git) is a continuous integration tool for Guix.  It can be used both for development and for providing substitutes to others (see Sustituciones).

El módulo (gnu services cuirass) proporciona el siguiente servicio.

 -- Procedimiento Scheme: cuirass-service-type
     The type of the Cuirass service.  Its value must be a cuirass-configuration object, as described below.

To add build jobs, you have to set the specifications field of the configuration.  Here is an example of a service that polls the Guix repository and builds the packages from a manifest.  Some of the packages are defined in the "custom-packages" input, which is the equivalent of GUIX_PACKAGE_PATH.

     (define %cuirass-specs
       #~(list
          '((#:name . "my-manifest")
            (#:load-path-inputs . ("guix"))
            (#:package-path-inputs . ("custom-packages"))
            (#:proc-input . "guix")
            (#:proc-file . "build-aux/cuirass/gnu-system.scm")
            (#:proc . cuirass-jobs)
            (#:proc-args . ((subset . "manifests")
                            (systems . ("x86_64-linux"))
                            (manifests . (("config" . "guix/manifest.scm")))))
            (#:inputs . (((#:name . "guix")
                          (#:url . "git://git.savannah.gnu.org/guix.git")
                          (#:load-path . ".")
                          (#:branch . "master")
                          (#:no-compile? . #t))
                         ((#:name . "config")
                          (#:url . "git://git.example.org/config.git")
                          (#:load-path . ".")
                          (#:branch . "master")
                          (#:no-compile? . #t))
                         ((#:name . "custom-packages")
                          (#:url . "git://git.example.org/custom-packages.git")
                          (#:load-path . ".")
                          (#:branch . "master")
                          (#:no-compile? . #t)))))))

     (service cuirass-service-type
              (cuirass-configuration
               (specifications %cuirass-specs)))

While information related to build jobs is located directly in the specifications, global settings for the cuirass process are accessible in other cuirass-configuration fields.

 -- Tipo de datos: cuirass-configuration
     Data type representing the configuration of Cuirass.

     log-file (predeterminado: "/var/log/cuirass.log")
          Location of the log file.

     cache-directory (predeterminado: "/var/cache/cuirass")
          Location of the repository cache.

     user (predeterminado: "cuirass")
          Owner of the cuirass process.

     group (predeterminado: "cuirass")
          Owner's group of the cuirass process.

     interval (predeterminado: 60)
          Number of seconds between the poll of the repositories followed by the Cuirass jobs.

     database (predeterminada: "/var/lib/cuirass/cuirass.db")
          Location of sqlite database which contains the build results and previously added specifications.

     ttl (predeterminado: (* 30 24 3600))
          Specifies the time-to-live (TTL) in seconds of garbage collector roots that are registered for build results.  This means that build results are protected from garbage collection for at least TTL seconds.

     port (predeterminado: 8081)
          Número de puerto usado por el servidor HTTP.

     --listen=DIRECCIÓN
          Listen on the network interface for HOST.  The default is to accept connections from localhost.

     specifications (predeterminada: #~'())
          A gexp (see Expresiones-G) that evaluates to a list of specifications, where a specification is an association list (see Associations Lists (GNU Guile Reference Manual)) whose keys are keywords (#:keyword-example) as shown in the example above.

     use-substitutes? (predeterminado: #f)
          This allows using substitutes to avoid building every dependencies of a job from source.

     one-shot? (predeterminado: #f)
          Only evaluate specifications and build derivations once.

     fallback? (predeterminado: #f)
          When substituting a pre-built binary fails, fall back to building packages locally.

     cuirass (predeterminado: cuirass)
          El paquete Cuirass usado.

Servicios de gestión de energía
-------------------------------

Daemon TLP
..........

El módulo (gnu services pm) proporciona una definición de servicio Guix para la herramienta de gestión de energía de Linux TLP.

TLP enables various powersaving modes in userspace and kernel.  Contrary to upower-service, it is not a passive, monitoring tool, as it will apply custom settings each time a new power source is detected.  More information can be found at TLP home page (http://linrunner.de/en/tlp/tlp.html).

 -- Variable Scheme: tlp-service-type
     The service type for the TLP tool.  Its value should be a valid TLP configuration (see below).  To use the default settings, simply write:

          (service tlp-service-type)

By default TLP does not need much configuration but most TLP parameters can be tweaked using tlp-configuration.

Each parameter definition is preceded by its type; for example, boolean foo indicates that the foo parameter should be specified as a boolean.  Types starting with maybe- denote parameters that won't show up in TLP config file when their value is 'disabled.

Available tlp-configuration fields are:

 -- tlp-configuration parameter: package tlp
     El paquete TLP.

 -- tlp-configuration parameter: boolean tlp-enable?
     Set to true if you wish to enable TLP.

     Defaults to #t.

 -- tlp-configuration parameter: string tlp-default-mode
     Default mode when no power supply can be detected.  Alternatives are AC and BAT.

     Defaults to "AC".

 -- tlp-configuration parameter: non-negative-integer disk-idle-secs-on-ac
     Number of seconds Linux kernel has to wait after the disk goes idle, before syncing on AC.

     El valor predeterminado es 0.

 -- tlp-configuration parameter: non-negative-integer disk-idle-secs-on-bat
     Same as disk-idle-ac but on BAT mode.

     Defaults to 2.

 -- tlp-configuration parameter: non-negative-integer max-lost-work-secs-on-ac
     Dirty pages flushing periodicity, expressed in seconds.

     Defaults to 15.

 -- tlp-configuration parameter: non-negative-integer max-lost-work-secs-on-bat
     Same as max-lost-work-secs-on-ac but on BAT mode.

     Defaults to 60.

 -- tlp-configuration parameter: maybe-space-separated-string-list cpu-scaling-governor-on-ac
     CPU frequency scaling governor on AC mode.  With intel_pstate driver, alternatives are powersave and performance.  With acpi-cpufreq driver, alternatives are ondemand, powersave, performance and conservative.

     Defaults to disabled.

 -- tlp-configuration parameter: maybe-space-separated-string-list cpu-scaling-governor-on-bat
     Same as cpu-scaling-governor-on-ac but on BAT mode.

     Defaults to disabled.

 -- tlp-configuration parameter: maybe-non-negative-integer cpu-scaling-min-freq-on-ac
     Set the min available frequency for the scaling governor on AC.

     Defaults to disabled.

 -- tlp-configuration parameter: maybe-non-negative-integer cpu-scaling-max-freq-on-ac
     Set the max available frequency for the scaling governor on AC.

     Defaults to disabled.

 -- tlp-configuration parameter: maybe-non-negative-integer cpu-scaling-min-freq-on-bat
     Set the min available frequency for the scaling governor on BAT.

     Defaults to disabled.

 -- tlp-configuration parameter: maybe-non-negative-integer cpu-scaling-max-freq-on-bat
     Set the max available frequency for the scaling governor on BAT.

     Defaults to disabled.

 -- tlp-configuration parameter: maybe-non-negative-integer cpu-min-perf-on-ac
     Limit the min P-state to control the power dissipation of the CPU, in AC mode.  Values are stated as a percentage of the available performance.

     Defaults to disabled.

 -- tlp-configuration parameter: maybe-non-negative-integer cpu-max-perf-on-ac
     Limit the max P-state to control the power dissipation of the CPU, in AC mode.  Values are stated as a percentage of the available performance.

     Defaults to disabled.

 -- tlp-configuration parameter: maybe-non-negative-integer cpu-min-perf-on-bat
     Same as cpu-min-perf-on-ac on BAT mode.

     Defaults to disabled.

 -- tlp-configuration parameter: maybe-non-negative-integer cpu-max-perf-on-bat
     Same as cpu-max-perf-on-ac on BAT mode.

     Defaults to disabled.

 -- tlp-configuration parameter: maybe-boolean cpu-boost-on-ac?
     Enable CPU turbo boost feature on AC mode.

     Defaults to disabled.

 -- tlp-configuration parameter: maybe-boolean cpu-boost-on-bat?
     Same as cpu-boost-on-ac? on BAT mode.

     Defaults to disabled.

 -- tlp-configuration parameter: boolean sched-powersave-on-ac?
     Allow Linux kernel to minimize the number of CPU cores/hyper-threads used under light load conditions.

     El valor predeterminado es #f

 -- tlp-configuration parameter: boolean sched-powersave-on-bat?
     Same as sched-powersave-on-ac? but on BAT mode.

     Defaults to #t.

 -- tlp-configuration parameter: boolean nmi-watchdog?
     Enable Linux kernel NMI watchdog.

     El valor predeterminado es #f

 -- tlp-configuration parameter: maybe-string phc-controls
     For Linux kernels with PHC patch applied, change CPU voltages.  An example value would be "F:V F:V F:V F:V".

     Defaults to disabled.

 -- tlp-configuration parameter: string energy-perf-policy-on-ac
     Set CPU performance versus energy saving policy on AC.  Alternatives are performance, normal, powersave.

     Defaults to "performance".

 -- tlp-configuration parameter: string energy-perf-policy-on-bat
     Same as energy-perf-policy-ac but on BAT mode.

     Defaults to "powersave".

 -- tlp-configuration parameter: space-separated-string-list disks-devices
     Dispositivos de disco duro.

 -- tlp-configuration parameter: space-separated-string-list disk-apm-level-on-ac
     Hard disk advanced power management level.

 -- tlp-configuration parameter: space-separated-string-list disk-apm-level-on-bat
     Same as disk-apm-bat but on BAT mode.

 -- tlp-configuration parameter: maybe-space-separated-string-list disk-spindown-timeout-on-ac
     Hard disk spin down timeout.  One value has to be specified for each declared hard disk.

     Defaults to disabled.

 -- tlp-configuration parameter: maybe-space-separated-string-list disk-spindown-timeout-on-bat
     Same as disk-spindown-timeout-on-ac but on BAT mode.

     Defaults to disabled.

 -- tlp-configuration parameter: maybe-space-separated-string-list disk-iosched
     Select IO scheduler for disk devices.  One value has to be specified for each declared hard disk.  Example alternatives are cfq, deadline and noop.

     Defaults to disabled.

 -- tlp-configuration parameter: string sata-linkpwr-on-ac
     SATA aggressive link power management (ALPM) level.  Alternatives are min_power, medium_power, max_performance.

     Defaults to "max_performance".

 -- tlp-configuration parameter: string sata-linkpwr-on-bat
     Same as sata-linkpwr-ac but on BAT mode.

     Defaults to "min_power".

 -- tlp-configuration parameter: maybe-string sata-linkpwr-blacklist
     Exclude specified SATA host devices for link power management.

     Defaults to disabled.

 -- tlp-configuration parameter: maybe-on-off-boolean ahci-runtime-pm-on-ac?
     Enable Runtime Power Management for AHCI controller and disks on AC mode.

     Defaults to disabled.

 -- tlp-configuration parameter: maybe-on-off-boolean ahci-runtime-pm-on-bat?
     Same as ahci-runtime-pm-on-ac on BAT mode.

     Defaults to disabled.

 -- tlp-configuration parameter: non-negative-integer ahci-runtime-pm-timeout
     Seconds of inactivity before disk is suspended.

     Defaults to 15.

 -- tlp-configuration parameter: string pcie-aspm-on-ac
     PCI Express Active State Power Management level.  Alternatives are default, performance, powersave.

     Defaults to "performance".

 -- tlp-configuration parameter: string pcie-aspm-on-bat
     Same as pcie-aspm-ac but on BAT mode.

     Defaults to "powersave".

 -- tlp-configuration parameter: string radeon-power-profile-on-ac
     Radeon graphics clock speed level.  Alternatives are low, mid, high, auto, default.

     Defaults to "high".

 -- tlp-configuration parameter: string radeon-power-profile-on-bat
     Same as radeon-power-ac but on BAT mode.

     Defaults to "low".

 -- tlp-configuration parameter: string radeon-dpm-state-on-ac
     Radeon dynamic power management method (DPM).  Alternatives are battery, performance.

     Defaults to "performance".

 -- tlp-configuration parameter: string radeon-dpm-state-on-bat
     Same as radeon-dpm-state-ac but on BAT mode.

     Defaults to "battery".

 -- tlp-configuration parameter: string radeon-dpm-perf-level-on-ac
     Radeon DPM performance level.  Alternatives are auto, low, high.

     Defaults to "auto".

 -- tlp-configuration parameter: string radeon-dpm-perf-level-on-bat
     Same as radeon-dpm-perf-ac but on BAT mode.

     Defaults to "auto".

 -- tlp-configuration parameter: on-off-boolean wifi-pwr-on-ac?
     Wifi power saving mode.

     El valor predeterminado es #f

 -- tlp-configuration parameter: on-off-boolean wifi-pwr-on-bat?
     Same as wifi-power-ac? but on BAT mode.

     Defaults to #t.

 -- tlp-configuration parameter: y-n-boolean wol-disable?
     Disable wake on LAN.

     Defaults to #t.

 -- tlp-configuration parameter: non-negative-integer sound-power-save-on-ac
     Timeout duration in seconds before activating audio power saving on Intel HDA and AC97 devices.  A value of 0 disables power saving.

     El valor predeterminado es 0.

 -- tlp-configuration parameter: non-negative-integer sound-power-save-on-bat
     Same as sound-powersave-ac but on BAT mode.

     Defaults to 1.

 -- tlp-configuration parameter: y-n-boolean sound-power-save-controller?
     Disable controller in powersaving mode on Intel HDA devices.

     Defaults to #t.

 -- tlp-configuration parameter: boolean bay-poweroff-on-bat?
     Enable optical drive in UltraBay/MediaBay on BAT mode.  Drive can be powered on again by releasing (and reinserting) the eject lever or by pressing the disc eject button on newer models.

     El valor predeterminado es #f

 -- tlp-configuration parameter: string bay-device
     Name of the optical drive device to power off.

     Defaults to "sr0".

 -- tlp-configuration parameter: string runtime-pm-on-ac
     Runtime Power Management for PCI(e) bus devices.  Alternatives are on and auto.

     Defaults to "on".

 -- tlp-configuration parameter: string runtime-pm-on-bat
     Same as runtime-pm-ac but on BAT mode.

     Defaults to "auto".

 -- tlp-configuration parameter: boolean runtime-pm-all?
     Runtime Power Management for all PCI(e) bus devices, except blacklisted ones.

     Defaults to #t.

 -- tlp-configuration parameter: maybe-space-separated-string-list runtime-pm-blacklist
     Exclude specified PCI(e) device addresses from Runtime Power Management.

     Defaults to disabled.

 -- tlp-configuration parameter: space-separated-string-list runtime-pm-driver-blacklist
     Exclude PCI(e) devices assigned to the specified drivers from Runtime Power Management.

 -- tlp-configuration parameter: boolean usb-autosuspend?
     Enable USB autosuspend feature.

     Defaults to #t.

 -- tlp-configuration parameter: maybe-string usb-blacklist
     Exclude specified devices from USB autosuspend.

     Defaults to disabled.

 -- tlp-configuration parameter: boolean usb-blacklist-wwan?
     Exclude WWAN devices from USB autosuspend.

     Defaults to #t.

 -- tlp-configuration parameter: maybe-string usb-whitelist
     Include specified devices into USB autosuspend, even if they are already excluded by the driver or via usb-blacklist-wwan?.

     Defaults to disabled.

 -- tlp-configuration parameter: maybe-boolean usb-autosuspend-disable-on-shutdown?
     Enable USB autosuspend before shutdown.

     Defaults to disabled.

 -- tlp-configuration parameter: boolean restore-device-state-on-startup?
     Restore radio device state (bluetooth, wifi, wwan) from previous shutdown on system startup.

     El valor predeterminado es #f

Daemon Thermald
...............

El módulo (gnu services pm) proporciona una interfaz con thermald, un servicio de escalado de frecuencia de la CPU que ayuda a prevenir el sobrecalentamiento.

 -- Variable Scheme: thermald-service-type
     This is the service type for thermald (https://01.org/linux-thermal-daemon/), the Linux Thermal Daemon, which is responsible for controlling the thermal state of processors and preventing overheating.

 -- Tipo de datos: thermald-configuration
     Tipo de datos que representa la configuración de thermald-service-type.

     ignore-cpuid-check? (predeterminado: #f)
          Ignore cpuid check for supported CPU models.

     thermald (predeterminado: THERMALD)
          Package object of thermald.

Servicios de audio
------------------

El módulo (gnu services audio) proporciona un servicio para iniciar MPD (el daemon de reproducción de música).

Daemon de reproducción de música (MPD)
......................................

El daemon de reproducción de música (MPD) es un servicio que puede reproducir música mientras se controla desde la máquina local o sobre una red por una multitud de clientes.

El siguiente ejemplo muestra como se puede ejecutar mpd como "rober" en el puerto 6666. Usa pulseaudio para su salida.

     (service mpd-service-type
              (mpd-configuration
               (user "rober")
               (port "6666")))

 -- Variable Scheme: mpd-service-type
     El tipo de servicio para mpd.

 -- Tipo de datos: mpd-configuration
     Data type representing the configuration of mpd.

     user (predeterminada: "mpd")
          Usuaria que ejecuta mpd.

     music-dir (predeterminado: "~/Music")
          The directory to scan for music files.

     playlist-dir (predeterminado: "~/.mpd/playlists")
          The directory to store playlists.

     db-file (default: "~/.mpd/tag_cache")
          The location of the music database.

     state-file (default: "~/.mpd/state")
          The location of the file that stores current MPD's state.

     sticker-file (default: "~/.mpd/sticker.sql")
          The location of the sticker database.

     port (predeterminado: "6600")
          Puerto sobre el que se ejecuta mpd.

     address (predeterminada: "any")
          The address that mpd will bind to.  To use a Unix domain socket, an absolute path can be specified here.

Servicios de virtualización
---------------------------

The (gnu services virtualization) module provides services for the libvirt and virtlog daemons, as well as other virtualization-related services.

Demonio Libvirt
...............

libvirtd is the server side daemon component of the libvirt virtualization management system. This daemon runs on host servers and performs required management tasks for virtualized guests.

 -- Variable Scheme: libvirt-service-type
     This is the type of the libvirt daemon (https://libvirt.org).  Its value must be a libvirt-configuration.

          (service libvirt-service-type
                   (libvirt-configuration
                    (unix-sock-group "libvirt")
                    (tls-port "16555")))

Available libvirt-configuration fields are:

 -- libvirt-configuration parameter: package libvirt
     Paquete libvirt.

 -- libvirt-configuration parameter: boolean listen-tls?
     Flag listening for secure TLS connections on the public TCP/IP port.  must set listen for this to have any effect.

     It is necessary to setup a CA and issue server certificates before using this capability.

     Defaults to #t.

 -- libvirt-configuration parameter: boolean listen-tcp?
     Listen for unencrypted TCP connections on the public TCP/IP port.  must set listen for this to have any effect.

     Using the TCP socket requires SASL authentication by default.  Only SASL mechanisms which support data encryption are allowed.  This is DIGEST_MD5 and GSSAPI (Kerberos5)

     El valor predeterminado es #f

 -- libvirt-configuration parameter: string tls-port
     Port for accepting secure TLS connections This can be a port number, or service name

     Defaults to "16514".

 -- libvirt-configuration parameter: string tcp-port
     Port for accepting insecure TCP connections This can be a port number, or service name

     Defaults to "16509".

 -- libvirt-configuration parameter: string listen-addr
     IP address or hostname used for client connections.

     Defaults to "0.0.0.0".

 -- libvirt-configuration parameter: boolean mdns-adv?
     Flag toggling mDNS advertisement of the libvirt service.

     Alternatively can disable for all services on a host by stopping the Avahi daemon.

     El valor predeterminado es #f

 -- libvirt-configuration parameter: string mdns-name
     Default mDNS advertisement name.  This must be unique on the immediate broadcast network.

     Defaults to "Virtualization Host <hostname>".

 -- libvirt-configuration parameter: string unix-sock-group
     UNIX domain socket group ownership.  This can be used to allow a 'trusted' set of users access to management capabilities without becoming root.

     Defaults to "root".

 -- libvirt-configuration parameter: string unix-sock-ro-perms
     UNIX socket permissions for the R/O socket.  This is used for monitoring VM status only.

     Defaults to "0777".

 -- libvirt-configuration parameter: string unix-sock-rw-perms
     UNIX socket permissions for the R/W socket.  Default allows only root.  If PolicyKit is enabled on the socket, the default will change to allow everyone (eg, 0777)

     Defaults to "0770".

 -- libvirt-configuration parameter: string unix-sock-admin-perms
     UNIX socket permissions for the admin socket.  Default allows only owner (root), do not change it unless you are sure to whom you are exposing the access to.

     Defaults to "0777".

 -- libvirt-configuration parameter: string unix-sock-dir
     The directory in which sockets will be found/created.

     Defaults to "/var/run/libvirt".

 -- libvirt-configuration parameter: string auth-unix-ro
     Authentication scheme for UNIX read-only sockets.  By default socket permissions allow anyone to connect

     Defaults to "polkit".

 -- libvirt-configuration parameter: string auth-unix-rw
     Authentication scheme for UNIX read-write sockets.  By default socket permissions only allow root.  If PolicyKit support was compiled into libvirt, the default will be to use 'polkit' auth.

     Defaults to "polkit".

 -- libvirt-configuration parameter: string auth-tcp
     Authentication scheme for TCP sockets.  If you don't enable SASL, then all TCP traffic is cleartext.  Don't do this outside of a dev/test scenario.

     Defaults to "sasl".

 -- libvirt-configuration parameter: string auth-tls
     Authentication scheme for TLS sockets.  TLS sockets already have encryption provided by the TLS layer, and limited authentication is done by certificates.

     It is possible to make use of any SASL authentication mechanism as well, by using 'sasl' for this option

     Defaults to "none".

 -- libvirt-configuration parameter: optional-list access-drivers
     API access control scheme.

     By default an authenticated user is allowed access to all APIs.  Access drivers can place restrictions on this.

     Defaults to ().

 -- libvirt-configuration parameter: string key-file
     Server key file path.  If set to an empty string, then no private key is loaded.

     El valor predeterminado es "".

 -- libvirt-configuration parameter: string cert-file
     Server key file path.  If set to an empty string, then no certificate is loaded.

     El valor predeterminado es "".

 -- libvirt-configuration parameter: string ca-file
     Server key file path.  If set to an empty string, then no CA certificate is loaded.

     El valor predeterminado es "".

 -- libvirt-configuration parameter: string crl-file
     Certificate revocation list path.  If set to an empty string, then no CRL is loaded.

     El valor predeterminado es "".

 -- libvirt-configuration parameter: boolean tls-no-sanity-cert
     Disable verification of our own server certificates.

     When libvirtd starts it performs some sanity checks against its own certificates.

     El valor predeterminado es #f

 -- libvirt-configuration parameter: boolean tls-no-verify-cert
     Disable verification of client certificates.

     Client certificate verification is the primary authentication mechanism. Any client which does not present a certificate signed by the CA will be rejected.

     El valor predeterminado es #f

 -- libvirt-configuration parameter: optional-list tls-allowed-dn-list
     Whitelist of allowed x509 Distinguished Name.

     Defaults to ().

 -- libvirt-configuration parameter: optional-list sasl-allowed-usernames
     Whitelist of allowed SASL usernames.  The format for username depends on the SASL authentication mechanism.

     Defaults to ().

 -- libvirt-configuration parameter: string tls-priority
     Override the compile time default TLS priority string.  The default is usually "NORMAL" unless overridden at build time.  Only set this is it is desired for libvirt to deviate from the global default settings.

     Defaults to "NORMAL".

 -- libvirt-configuration parameter: integer max-clients
     Maximum number of concurrent client connections to allow over all sockets combined.

     Defaults to 5000.

 -- libvirt-configuration parameter: integer max-queued-clients
     Maximum length of queue of connections waiting to be accepted by the daemon.  Note, that some protocols supporting retransmission may obey this so that a later reattempt at connection succeeds.

     Defaults to 1000.

 -- libvirt-configuration parameter: integer max-anonymous-clients
     Maximum length of queue of accepted but not yet authenticated clients.  Set this to zero to turn this feature off

     Defaults to 20.

 -- libvirt-configuration parameter: integer min-workers
     Number of workers to start up initially.

     Defaults to 5.

 -- libvirt-configuration parameter: integer max-workers
     Maximum number of worker threads.

     If the number of active clients exceeds min-workers, then more threads are spawned, up to max_workers limit.  Typically you'd want max_workers to equal maximum number of clients allowed.

     Defaults to 20.

 -- libvirt-configuration parameter: integer prio-workers
     Number of priority workers.  If all workers from above pool are stuck, some calls marked as high priority (notably domainDestroy) can be executed in this pool.

     Defaults to 5.

 -- libvirt-configuration parameter: integer max-requests
     Total global limit on concurrent RPC calls.

     Defaults to 20.

 -- libvirt-configuration parameter: integer max-client-requests
     Limit on concurrent requests from a single client connection.  To avoid one client monopolizing the server this should be a small fraction of the global max_requests and max_workers parameter.

     Defaults to 5.

 -- libvirt-configuration parameter: integer admin-min-workers
     Same as min-workers but for the admin interface.

     Defaults to 1.

 -- libvirt-configuration parameter: integer admin-max-workers
     Same as max-workers but for the admin interface.

     Defaults to 5.

 -- libvirt-configuration parameter: integer admin-max-clients
     Same as max-clients but for the admin interface.

     Defaults to 5.

 -- libvirt-configuration parameter: integer admin-max-queued-clients
     Same as max-queued-clients but for the admin interface.

     Defaults to 5.

 -- libvirt-configuration parameter: integer admin-max-client-requests
     Same as max-client-requests but for the admin interface.

     Defaults to 5.

 -- libvirt-configuration parameter: integer log-level
     Logging level.  4 errors, 3 warnings, 2 information, 1 debug.

     Defaults to 3.

 -- libvirt-configuration parameter: string log-filters
     Filtros de log.

     A filter allows to select a different logging level for a given category of logs The format for a filter is one of:

       * x:nombre

       * x:+nombre

     where name is a string which is matched against the category given in the VIR_LOG_INIT() at the top of each libvirt source file, e.g., "remote", "qemu", or "util.json" (the name in the filter can be a substring of the full category name, in order to match multiple similar categories), the optional "+" prefix tells libvirt to log stack trace for each message matching name, and x is the minimal level where matching messages should be logged:

       * 1: DEBUG

       * 2: INFO

       * 3: WARNING

       * 4: ERROR

     Multiple filters can be defined in a single filters statement, they just need to be separated by spaces.

     Defaults to "3:remote 4:event".

 -- libvirt-configuration parameter: string log-outputs
     Logging outputs.

     An output is one of the places to save logging information The format for an output can be:

     x:stderr
          output goes to stderr

     x:syslog:name
          use syslog for the output and use the given name as the ident

     x:file:file_path
          output to a file, with the given filepath

     x:journald
          output to journald logging system

     In all case the x prefix is the minimal level, acting as a filter

       * 1: DEBUG

       * 2: INFO

       * 3: WARNING

       * 4: ERROR

     Multiple outputs can be defined, they just need to be separated by spaces.

     Defaults to "3:stderr".

 -- libvirt-configuration parameter: integer audit-level
     Allows usage of the auditing subsystem to be altered

       * 0: disable all auditing

       * 1: enable auditing, only if enabled on host

       * 2: enable auditing, and exit if disabled on host.

     Defaults to 1.

 -- libvirt-configuration parameter: boolean audit-logging
     Send audit messages via libvirt logging infrastructure.

     El valor predeterminado es #f

 -- libvirt-configuration parameter: optional-string host-uuid
     Host UUID.  UUID must not have all digits be the same.

     El valor predeterminado es "".

 -- libvirt-configuration parameter: string host-uuid-source
     Source to read host UUID.

       * smbios: fetch the UUID from dmidecode -s system-uuid

       * machine-id: fetch the UUID from /etc/machine-id

     If dmidecode does not provide a valid UUID a temporary UUID will be generated.

     Defaults to "smbios".

 -- libvirt-configuration parameter: integer keepalive-interval
     A keepalive message is sent to a client after keepalive_interval seconds of inactivity to check if the client is still responding.  If set to -1, libvirtd will never send keepalive requests; however clients can still send them and the daemon will send responses.

     Defaults to 5.

 -- libvirt-configuration parameter: integer keepalive-count
     Maximum number of keepalive messages that are allowed to be sent to the client without getting any response before the connection is considered broken.

     In other words, the connection is automatically closed approximately after keepalive_interval * (keepalive_count + 1) seconds since the last message received from the client.  When keepalive-count is set to 0, connections will be automatically closed after keepalive-interval seconds of inactivity without sending any keepalive messages.

     Defaults to 5.

 -- libvirt-configuration parameter: integer admin-keepalive-interval
     Same as above but for admin interface.

     Defaults to 5.

 -- libvirt-configuration parameter: integer admin-keepalive-count
     Same as above but for admin interface.

     Defaults to 5.

 -- libvirt-configuration parameter: integer ovs-timeout
     Timeout for Open vSwitch calls.

     The ovs-vsctl utility is used for the configuration and its timeout option is set by default to 5 seconds to avoid potential infinite waits blocking libvirt.

     Defaults to 5.

Daemon Virtlog
..............

The virtlogd service is a server side daemon component of libvirt that is used to manage logs from virtual machine consoles.

This daemon is not used directly by libvirt client applications, rather it is called on their behalf by libvirtd. By maintaining the logs in a standalone daemon, the main libvirtd daemon can be restarted without risk of losing logs. The virtlogd daemon has the ability to re-exec() itself upon receiving SIGUSR1, to allow live upgrades without downtime.

 -- Variable Scheme: virtlog-service-type
     This is the type of the virtlog daemon.  Its value must be a virtlog-configuration.

          (service virtlog-service-type
                   (virtlog-configuration
                    (max-clients 1000)))

 -- virtlog-configuration parameter: integer log-level
     Logging level.  4 errors, 3 warnings, 2 information, 1 debug.

     Defaults to 3.

 -- virtlog-configuration parameter: string log-filters
     Filtros de log.

     A filter allows to select a different logging level for a given category of logs The format for a filter is one of:

       * x:nombre

       * x:+nombre

     where name is a string which is matched against the category given in the VIR_LOG_INIT() at the top of each libvirt source file, e.g., "remote", "qemu", or "util.json" (the name in the filter can be a substring of the full category name, in order to match multiple similar categories), the optional "+" prefix tells libvirt to log stack trace for each message matching name, and x is the minimal level where matching messages should be logged:

       * 1: DEBUG

       * 2: INFO

       * 3: WARNING

       * 4: ERROR

     Multiple filters can be defined in a single filters statement, they just need to be separated by spaces.

     Defaults to "3:remote 4:event".

 -- virtlog-configuration parameter: string log-outputs
     Logging outputs.

     An output is one of the places to save logging information The format for an output can be:

     x:stderr
          output goes to stderr

     x:syslog:name
          use syslog for the output and use the given name as the ident

     x:file:file_path
          output to a file, with the given filepath

     x:journald
          output to journald logging system

     In all case the x prefix is the minimal level, acting as a filter

       * 1: DEBUG

       * 2: INFO

       * 3: WARNING

       * 4: ERROR

     Multiple outputs can be defined, they just need to be separated by spaces.

     Defaults to "3:stderr".

 -- virtlog-configuration parameter: integer max-clients
     Maximum number of concurrent client connections to allow over all sockets combined.

     Defaults to 1024.

 -- virtlog-configuration parameter: integer max-size
     Maximum file size before rolling over.

     Defaults to 2MB

 -- virtlog-configuration parameter: integer max-backups
     Maximum number of backup files to keep.

     Defaults to 3

Transparent Emulation with QEMU
...............................

qemu-binfmt-service-type provides support for transparent emulation of program binaries built for different architectures---e.g., it allows you to transparently execute an ARMv7 program on an x86_64 machine.  It achieves this by combining the QEMU (https://www.qemu.org) emulator and the binfmt_misc feature of the kernel Linux.

 -- Variable Scheme: qemu-binfmt-service-type
     This is the type of the QEMU/binfmt service for transparent emulation.  Its value must be a qemu-binfmt-configuration object, which specifies the QEMU package to use as well as the architecture we want to emulated:

          (service qemu-binfmt-service-type
                   (qemu-binfmt-configuration
                     (platforms (lookup-qemu-platforms "arm" "aarch64" "mips64el"))))

     In this example, we enable transparent emulation for the ARM and aarch64 platforms.  Running herd stop qemu-binfmt turns it off, and running herd start qemu-binfmt turns it back on (see the herd command (The GNU Shepherd Manual)).

 -- Tipo de datos: qemu-binfmt-configuration
     This is the configuration for the qemu-binfmt service.

     platforms (predeterminadas: '())
          The list of emulated QEMU platforms.  Each item must be a platform object as returned by lookup-qemu-platforms (see below).

     guix-support? (predeterminado: #f)
          When it is true, QEMU and all its dependencies are added to the build environment of guix-daemon (see --chroot-directory option).  This allows the binfmt_misc handlers to be used within the build environment, which in turn means that you can transparently build programs for another architecture.

          For example, let's suppose you're on an x86_64 machine and you have this service:

               (service qemu-binfmt-service-type
                        (qemu-binfmt-configuration
                          (platforms (lookup-qemu-platforms "arm"))
                          (guix-support? #t)))

          You can run:

               guix build -s armhf-linux inkscape

          and it will build Inkscape for ARMv7 as if it were a native build, transparently using QEMU to emulate the ARMv7 CPU.  Pretty handy if you'd like to test a package build for an architecture you don't have access to!

     qemu (predeterminado: qemu)
          El paquete QEMU usado.

 -- Procedimiento Scheme: lookup-qemu-platforms PLATAFORMAS...
     Return the list of QEMU platform objects corresponding to PLATFORMS....  PLATFORMS must be a list of strings corresponding to platform names, such as "arm", "sparc", "mips64el", and so on.

 -- Procedimiento Scheme: qemu-platform? OBJ
     Devuelve verdadero si OBJ es un objeto plataforma.

 -- Procedimiento Scheme: qemu-platform-name PLATAFORMA
     Devuelve el nombre de PLATAFORMA---una cadena como "arm".

Servicios de control de versiones
---------------------------------

The (gnu services version-control) module provides a service to allow remote access to local Git repositories.  There are three options: the git-daemon-service, which provides access to repositories via the git:// unsecured TCP-based protocol, extending the nginx web server to proxy some requests to git-http-backend, or providing a web interface with cgit-service-type.

 -- Procedimiento Scheme: git-daemon-service [#:config (git-daemon-configuration)]

     Devuelve un servicio que ejecuta git daemon, un servidor TCP simple para exponer repositorios con el protocolo Git para acceso anónimo.

     The optional CONFIG argument should be a <git-daemon-configuration> object, by default it allows read-only access to exported (By creating the magic file "git-daemon-export-ok" in the repository directory.) repositories under /srv/git.

 -- Tipo de datos: git-daemon-configuration
     Tipo de datos que representa la configuración para git-daemon-service.

     package (predeterminado: GIT)
          Package object of the Git distributed version control system.

     export-all? (predeterminado: #F)
          Whether to allow access for all Git repositories, even if they do not have the git-daemon-export-ok file.

     base-path (predeterminado: /srv/git)
          Whether to remap all the path requests as relative to the given path.  If you run git daemon with (BASE-PATH "/SRV/GIT") on example.com, then if you later try to pull git://example.com/hello.git, git daemon will interpret the path as /srv/git/hello.git.

     user-path (predeterminado: #F)
          Whether to allow ~user notation to be used in requests.  When specified with empty string, requests to git://host/~alice/foo is taken as a request to access foo repository in the home directory of user alice.  If (USER-PATH "PATH") is specified, the same request is taken as a request to access path/foo repository in the home directory of user alice.

     listen (predeterminado: '())
          Whether to listen on specific IP addresses or hostnames, defaults to all.

     port (predeterminado: #F)
          Whether to listen on an alternative port, which defaults to 9418.

     whitelist (predeterminado: '())
          If not empty, only allow access to this list of directories.

     extra-options (predeterminadas: '())
          Extra options will be passed to git daemon, please run man git-daemon for more information.

The git:// protocol lacks authentication.  When you pull from a repository fetched via git://, you don't know that the data you receive was modified is really coming from the specified host, and you have your connection is subject to eavesdropping.  It's better to use an authenticated and encrypted transport, such as https.  Although Git allows you to serve repositories using unsophisticated file-based web servers, there is a faster protocol implemented by the git-http-backend program.  This program is the back-end of a proper Git web service.  It is designed to sit behind a FastCGI proxy.  See Servicios Web, for more on running the necessary fcgiwrap daemon.

Guix has a separate configuration data type for serving Git repositories over HTTP.

 -- Tipo de datos: git-http-configuration
     Data type representing the configuration for git-http-service.

     package (predeterminado: GIT)
          Package object of the Git distributed version control system.

     git-root (predeterminada: /srv/git)
          Directory containing the Git repositories to expose to the world.

     export-all? (predeterminado: #F)
          Whether to expose access for all Git repositories in GIT-ROOT, even if they do not have the git-daemon-export-ok file.

     uri-path (predeterminada: /git/)
          Path prefix for Git access.  With the default /git/ prefix, this will map http://SERVER/git/REPO.git to /srv/git/REPO.git.  Requests whose URI paths do not begin with this prefix are not passed on to this Git instance.

     fcgiwrap-socket (predeterminado: 127.0.0.1:9000)
          The socket on which the fcgiwrap daemon is listening.  See Servicios Web.

There is no git-http-service-type, currently; instead you can create an nginx-location-configuration from a git-http-configuration and then add that location to a web server.

 -- Procedimiento Scheme: git-http-nginx-location-configuration
     [config=(git-http-configuration)] Compute an
     nginx-location-configuration that corresponds to the given Git http configuration.  An example nginx service definition to serve the default /srv/git over HTTPS might be:

          (service nginx-service-type
                   (nginx-configuration
                    (server-blocks
                     (list
                      (nginx-server-configuration
                       (listen '("443 ssl"))
                       (server-name "git.my-host.org")
                       (ssl-certificate
                        "/etc/letsencrypt/live/git.my-host.org/fullchain.pem")
                       (ssl-certificate-key
                        "/etc/letsencrypt/live/git.my-host.org/privkey.pem")
                       (locations
                        (list
                         (git-http-nginx-location-configuration
                          (git-http-configuration (uri-path "/"))))))))))

     This example assumes that you are using Let's Encrypt to get your TLS certificate.  See Servicios de certificados.  The default certbot service will redirect all HTTP traffic on git.my-host.org to HTTPS. You will also need to add an fcgiwrap proxy to your system services. See Servicios Web.

Servicio Cgit
.............

Cgit (https://git.zx2c4.com/cgit/) is a web frontend for Git repositories written in C.

The following example will configure the service with default values.  By default, Cgit can be accessed on port 80 (http://localhost:80).

     (service cgit-service-type)

The file-object type designates either a file-like object (see file-like objects) or a string.

Available cgit-configuration fields are:

 -- cgit-configuration parameter: package package
     El paquete CGIT.

 -- cgit-configuration parameter: nginx-server-configuration-list nginx
     Configuración de NGINX.

 -- cgit-configuration parameter: file-object about-filter
     Specifies a command which will be invoked to format the content of about pages (both top-level and for each repository).

     El valor predeterminado es "".

 -- cgit-configuration parameter: string agefile
     Specifies a path, relative to each repository path, which can be used to specify the date and time of the youngest commit in the repository.

     El valor predeterminado es "".

 -- cgit-configuration parameter: file-object auth-filter
     Specifies a command that will be invoked for authenticating repository access.

     El valor predeterminado es "".

 -- cgit-configuration parameter: string branch-sort
     Flag which, when set to age, enables date ordering in the branch ref list, and when set name enables ordering by branch name.

     Defaults to "name".

 -- cgit-configuration parameter: string cache-root
     Path used to store the cgit cache entries.

     Defaults to "/var/cache/cgit".

 -- cgit-configuration parameter: integer cache-static-ttl
     Number which specifies the time-to-live, in minutes, for the cached version of repository pages accessed with a fixed SHA1.

     Defaults to -1.

 -- cgit-configuration parameter: integer cache-dynamic-ttl
     Number which specifies the time-to-live, in minutes, for the cached version of repository pages accessed without a fixed SHA1.

     Defaults to 5.

 -- cgit-configuration parameter: integer cache-repo-ttl
     Number which specifies the time-to-live, in minutes, for the cached version of the repository summary page.

     Defaults to 5.

 -- cgit-configuration parameter: integer cache-root-ttl
     Number which specifies the time-to-live, in minutes, for the cached version of the repository index page.

     Defaults to 5.

 -- cgit-configuration parameter: integer cache-scanrc-ttl
     Number which specifies the time-to-live, in minutes, for the result of scanning a path for Git repositories.

     Defaults to 15.

 -- cgit-configuration parameter: integer cache-about-ttl
     Number which specifies the time-to-live, in minutes, for the cached version of the repository about page.

     Defaults to 15.

 -- cgit-configuration parameter: integer cache-snapshot-ttl
     Number which specifies the time-to-live, in minutes, for the cached version of snapshots.

     Defaults to 5.

 -- cgit-configuration parameter: integer cache-size
     The maximum number of entries in the cgit cache.  When set to 0, caching is disabled.

     El valor predeterminado es 0.

 -- cgit-configuration parameter: boolean case-sensitive-sort?
     Sort items in the repo list case sensitively.

     Defaults to #t.

 -- cgit-configuration parameter: list clone-prefix
     List of common prefixes which, when combined with a repository URL, generates valid clone URLs for the repository.

     Defaults to ().

 -- cgit-configuration parameter: list clone-url
     List of clone-url templates.

     Defaults to ().

 -- cgit-configuration parameter: file-object commit-filter
     Command which will be invoked to format commit messages.

     El valor predeterminado es "".

 -- cgit-configuration parameter: string commit-sort
     Flag which, when set to date, enables strict date ordering in the commit log, and when set to topo enables strict topological ordering.

     Defaults to "git log".

 -- cgit-configuration parameter: file-object css
     URL which specifies the css document to include in all cgit pages.

     Defaults to "/share/cgit/cgit.css".

 -- cgit-configuration parameter: file-object email-filter
     Specifies a command which will be invoked to format names and email address of committers, authors, and taggers, as represented in various places throughout the cgit interface.

     El valor predeterminado es "".

 -- cgit-configuration parameter: boolean embedded?
     Flag which, when set to #t, will make cgit generate a HTML fragment suitable for embedding in other HTML pages.

     El valor predeterminado es #f

 -- cgit-configuration parameter: boolean enable-commit-graph?
     Flag which, when set to #t, will make cgit print an ASCII-art commit history graph to the left of the commit messages in the repository log page.

     El valor predeterminado es #f

 -- cgit-configuration parameter: boolean enable-filter-overrides?
     Flag which, when set to #t, allows all filter settings to be overridden in repository-specific cgitrc files.

     El valor predeterminado es #f

 -- cgit-configuration parameter: boolean enable-follow-links?
     Flag which, when set to #t, allows users to follow a file in the log view.

     El valor predeterminado es #f

 -- cgit-configuration parameter: boolean enable-http-clone?
     If set to #t, cgit will act as an dumb HTTP endpoint for Git clones.

     Defaults to #t.

 -- cgit-configuration parameter: boolean enable-index-links?
     Flag which, when set to #t, will make cgit generate extra links "summary", "commit", "tree" for each repo in the repository index.

     El valor predeterminado es #f

 -- cgit-configuration parameter: boolean enable-index-owner?
     Flag which, when set to #t, will make cgit display the owner of each repo in the repository index.

     Defaults to #t.

 -- cgit-configuration parameter: boolean enable-log-filecount?
     Flag which, when set to #t, will make cgit print the number of modified files for each commit on the repository log page.

     El valor predeterminado es #f

 -- cgit-configuration parameter: boolean enable-log-linecount?
     Flag which, when set to #t, will make cgit print the number of added and removed lines for each commit on the repository log page.

     El valor predeterminado es #f

 -- cgit-configuration parameter: boolean enable-remote-branches?
     Flag which, when set to #t, will make cgit display remote branches in the summary and refs views.

     El valor predeterminado es #f

 -- cgit-configuration parameter: boolean enable-subject-links?
     Flag which, when set to 1, will make cgit use the subject of the parent commit as link text when generating links to parent commits in commit view.

     El valor predeterminado es #f

 -- cgit-configuration parameter: boolean enable-html-serving?
     Flag which, when set to #t, will make cgit use the subject of the parent commit as link text when generating links to parent commits in commit view.

     El valor predeterminado es #f

 -- cgit-configuration parameter: boolean enable-tree-linenumbers?
     Flag which, when set to #t, will make cgit generate linenumber links for plaintext blobs printed in the tree view.

     Defaults to #t.

 -- cgit-configuration parameter: boolean enable-git-config?
     Flag which, when set to #f, will allow cgit to use Git config to set any repo specific settings.

     El valor predeterminado es #f

 -- cgit-configuration parameter: file-object favicon
     URL used as link to a shortcut icon for cgit.

     Defaults to "/favicon.ico".

 -- cgit-configuration parameter: string footer
     The content of the file specified with this option will be included verbatim at the bottom of all pages (i.e. it replaces the standard "generated by..." message).

     El valor predeterminado es "".

 -- cgit-configuration parameter: string head-include
     The content of the file specified with this option will be included verbatim in the HTML HEAD section on all pages.

     El valor predeterminado es "".

 -- cgit-configuration parameter: string header
     The content of the file specified with this option will be included verbatim at the top of all pages.

     El valor predeterminado es "".

 -- cgit-configuration parameter: file-object include
     Name of a configfile to include before the rest of the current config- file is parsed.

     El valor predeterminado es "".

 -- cgit-configuration parameter: string index-header
     The content of the file specified with this option will be included verbatim above the repository index.

     El valor predeterminado es "".

 -- cgit-configuration parameter: string index-info
     The content of the file specified with this option will be included verbatim below the heading on the repository index page.

     El valor predeterminado es "".

 -- cgit-configuration parameter: boolean local-time?
     Flag which, if set to #t, makes cgit print commit and tag times in the servers timezone.

     El valor predeterminado es #f

 -- cgit-configuration parameter: file-object logo
     URL which specifies the source of an image which will be used as a logo on all cgit pages.

     Defaults to "/share/cgit/cgit.png".

 -- cgit-configuration parameter: string logo-link
     URL loaded when clicking on the cgit logo image.

     El valor predeterminado es "".

 -- cgit-configuration parameter: file-object owner-filter
     Command which will be invoked to format the Owner column of the main page.

     El valor predeterminado es "".

 -- cgit-configuration parameter: integer max-atom-items
     Number of items to display in atom feeds view.

     Defaults to 10.

 -- cgit-configuration parameter: integer max-commit-count
     Number of entries to list per page in "log" view.

     Defaults to 50.

 -- cgit-configuration parameter: integer max-message-length
     Number of commit message characters to display in "log" view.

     Defaults to 80.

 -- cgit-configuration parameter: integer max-repo-count
     Specifies the number of entries to list per page on the repository index page.

     Defaults to 50.

 -- cgit-configuration parameter: integer max-repodesc-length
     Specifies the maximum number of repo description characters to display on the repository index page.

     Defaults to 80.

 -- cgit-configuration parameter: integer max-blob-size
     Specifies the maximum size of a blob to display HTML for in KBytes.

     El valor predeterminado es 0.

 -- cgit-configuration parameter: string max-stats
     Maximum statistics period.  Valid values are week,month, quarter and year.

     El valor predeterminado es "".

 -- cgit-configuration parameter: mimetype-alist mimetype
     Mimetype for the specified filename extension.

     Defaults to ((gif "image/gif") (html "text/html") (jpg "image/jpeg") (jpeg "image/jpeg") (pdf "application/pdf") (png "image/png") (svg "image/svg+xml")).

 -- cgit-configuration parameter: file-object mimetype-file
     Specifies the file to use for automatic mimetype lookup.

     El valor predeterminado es "".

 -- cgit-configuration parameter: string module-link
     Text which will be used as the formatstring for a hyperlink when a submodule is printed in a directory listing.

     El valor predeterminado es "".

 -- cgit-configuration parameter: boolean nocache?
     If set to the value #t caching will be disabled.

     El valor predeterminado es #f

 -- cgit-configuration parameter: boolean noplainemail?
     If set to #t showing full author email addresses will be disabled.

     El valor predeterminado es #f

 -- cgit-configuration parameter: boolean noheader?
     Flag which, when set to #t, will make cgit omit the standard header on all pages.

     El valor predeterminado es #f

 -- cgit-configuration parameter: project-list project-list
     A list of subdirectories inside of repository-directory, relative to it, that should loaded as Git repositories.  An empty list means that all subdirectories will be loaded.

     Defaults to ().

 -- cgit-configuration parameter: file-object readme
     Text which will be used as default value for cgit-repo-readme.

     El valor predeterminado es "".

 -- cgit-configuration parameter: boolean remove-suffix?
     If set to #t and repository-directory is enabled, if any repositories are found with a suffix of .git, this suffix will be removed for the URL and name.

     El valor predeterminado es #f

 -- cgit-configuration parameter: integer renamelimit
     Maximum number of files to consider when detecting renames.

     Defaults to -1.

 -- cgit-configuration parameter: string repository-sort
     The way in which repositories in each section are sorted.

     El valor predeterminado es "".

 -- cgit-configuration parameter: robots-list robots
     Text used as content for the robots meta-tag.

     Defaults to ("noindex" "nofollow").

 -- cgit-configuration parameter: string root-desc
     Text printed below the heading on the repository index page.

     Defaults to "a fast webinterface for the git dscm".

 -- cgit-configuration parameter: string root-readme
     The content of the file specified with this option will be included verbatim below thef "about" link on the repository index page.

     El valor predeterminado es "".

 -- cgit-configuration parameter: string root-title
     Text printed as heading on the repository index page.

     El valor predeterminado es "".

 -- cgit-configuration parameter: boolean scan-hidden-path
     If set to #t and repository-directory is enabled, repository-directory will recurse into directories whose name starts with a period.  Otherwise, repository-directory will stay away from such directories, considered as "hidden".  Note that this does not apply to the ".git" directory in non-bare repos.

     El valor predeterminado es #f

 -- cgit-configuration parameter: list snapshots
     Text which specifies the default set of snapshot formats that cgit generates links for.

     Defaults to ().

 -- cgit-configuration parameter: repository-directory repository-directory
     Name of the directory to scan for repositories (represents scan-path).

     Defaults to "/srv/git".

 -- cgit-configuration parameter: string section
     The name of the current repository section - all repositories defined after this option will inherit the current section name.

     El valor predeterminado es "".

 -- cgit-configuration parameter: string section-sort
     Flag which, when set to 1, will sort the sections on the repository listing by name.

     El valor predeterminado es "".

 -- cgit-configuration parameter: integer section-from-path
     A number which, if defined prior to repository-directory, specifies how many path elements from each repo path to use as a default section name.

     El valor predeterminado es 0.

 -- cgit-configuration parameter: boolean side-by-side-diffs?
     If set to #t shows side-by-side diffs instead of unidiffs per default.

     El valor predeterminado es #f

 -- cgit-configuration parameter: file-object source-filter
     Specifies a command which will be invoked to format plaintext blobs in the tree view.

     El valor predeterminado es "".

 -- cgit-configuration parameter: integer summary-branches
     Specifies the number of branches to display in the repository "summary" view.

     Defaults to 10.

 -- cgit-configuration parameter: integer summary-log
     Specifies the number of log entries to display in the repository "summary" view.

     Defaults to 10.

 -- cgit-configuration parameter: integer summary-tags
     Specifies the number of tags to display in the repository "summary" view.

     Defaults to 10.

 -- cgit-configuration parameter: string strict-export
     Filename which, if specified, needs to be present within the repository for cgit to allow access to that repository.

     El valor predeterminado es "".

 -- cgit-configuration parameter: string virtual-root
     URL which, if specified, will be used as root for all cgit links.

     Defaults to "/".

 -- cgit-configuration parameter: repository-cgit-configuration-list repositories
     A list of cgit-repo records to use with config.

     Defaults to ().

     Available repository-cgit-configuration fields are:

      -- repository-cgit-configuration parameter: repo-list snapshots
          A mask of snapshot formats for this repo that cgit generates links for, restricted by the global snapshots setting.

          Defaults to ().

      -- repository-cgit-configuration parameter: repo-file-object source-filter
          Override the default source-filter.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-string url
          The relative URL used to access the repository.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-file-object about-filter
          Override the default about-filter.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-string branch-sort
          Flag which, when set to age, enables date ordering in the branch ref list, and when set to name enables ordering by branch name.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-list clone-url
          A list of URLs which can be used to clone repo.

          Defaults to ().

      -- repository-cgit-configuration parameter: repo-file-object commit-filter
          Override the default commit-filter.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-string commit-sort
          Flag which, when set to date, enables strict date ordering in the commit log, and when set to topo enables strict topological ordering.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-string defbranch
          The name of the default branch for this repository.  If no such branch exists in the repository, the first branch name (when sorted) is used as default instead.  By default branch pointed to by HEAD, or "master" if there is no suitable HEAD.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-string desc
          The value to show as repository description.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-string homepage
          The value to show as repository homepage.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-file-object email-filter
          Override the default email-filter.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: maybe-repo-boolean enable-commit-graph?
          A flag which can be used to disable the global setting enable-commit-graph?.

          Defaults to disabled.

      -- repository-cgit-configuration parameter: maybe-repo-boolean enable-log-filecount?
          A flag which can be used to disable the global setting enable-log-filecount?.

          Defaults to disabled.

      -- repository-cgit-configuration parameter: maybe-repo-boolean enable-log-linecount?
          A flag which can be used to disable the global setting enable-log-linecount?.

          Defaults to disabled.

      -- repository-cgit-configuration parameter: maybe-repo-boolean enable-remote-branches?
          Flag which, when set to #t, will make cgit display remote branches in the summary and refs views.

          Defaults to disabled.

      -- repository-cgit-configuration parameter: maybe-repo-boolean enable-subject-links?
          A flag which can be used to override the global setting enable-subject-links?.

          Defaults to disabled.

      -- repository-cgit-configuration parameter: maybe-repo-boolean enable-html-serving?
          A flag which can be used to override the global setting enable-html-serving?.

          Defaults to disabled.

      -- repository-cgit-configuration parameter: repo-boolean hide?
          Flag which, when set to #t, hides the repository from the repository index.

          El valor predeterminado es #f

      -- repository-cgit-configuration parameter: repo-boolean ignore?
          Flag which, when set to #t, ignores the repository.

          El valor predeterminado es #f

      -- repository-cgit-configuration parameter: repo-file-object logo
          URL which specifies the source of an image which will be used as a logo on this repo’s pages.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-string logo-link
          URL loaded when clicking on the cgit logo image.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-file-object owner-filter
          Override the default owner-filter.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-string module-link
          Text which will be used as the formatstring for a hyperlink when a submodule is printed in a directory listing.  The arguments for the formatstring are the path and SHA1 of the submodule commit.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: module-link-path module-link-path
          Text which will be used as the formatstring for a hyperlink when a submodule with the specified subdirectory path is printed in a directory listing.

          Defaults to ().

      -- repository-cgit-configuration parameter: repo-string max-stats
          Override the default maximum statistics period.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-string name
          El valor a mostrar como nombre del repositorio.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-string owner
          A value used to identify the owner of the repository.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-string path
          La ruta absoluta al directorio del repositorio.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-string readme
          A path (relative to repo) which specifies a file to include verbatim as the "About" page for this repo.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-string section
          The name of the current repository section - all repositories defined after this option will inherit the current section name.

          El valor predeterminado es "".

      -- repository-cgit-configuration parameter: repo-list extra-options
          Extra options will be appended to cgitrc file.

          Defaults to ().

 -- cgit-configuration parameter: list extra-options
     Extra options will be appended to cgitrc file.

     Defaults to ().

However, it could be that you just want to get a cgitrc up and running.  In that case, you can pass an opaque-cgit-configuration as a record to cgit-service-type.  As its name indicates, an opaque configuration does not have easy reflective capabilities.

Available opaque-cgit-configuration fields are:

 -- opaque-cgit-configuration parameter: package cgit
     El paquete cgit.

 -- opaque-cgit-configuration parameter: string string
     The contents of the cgitrc, as a string.

For example, if your cgitrc is just the empty string, you could instantiate a cgit service like this:

     (service cgit-service-type
              (opaque-cgit-configuration
               (cgitrc "")))

Servicio Gitolite
.................

Gitolite (http://gitolite.com/gitolite/) is a tool for hosting Git repositories on a central server.

Gitolite can handle multiple repositories and users, and supports flexible configuration of the permissions for the users on the repositories.

The following example will configure Gitolite using the default git user, and the provided SSH public key.

     (service gitolite-service-type
              (gitolite-configuration
                (admin-pubkey (plain-file
                                "sunombre.pub"
                                "ssh-rsa AAAA... guix@example.com"))))

Gitolite is configured through a special admin repository which you can clone, for example, if you setup Gitolite on example.com, you would run the following command to clone the admin repository.

     git clone git@example.com:gitolite-admin

When the Gitolite service is activated, the provided admin-pubkey will be inserted in to the keydir directory in the gitolite-admin repository.  If this results in a change in the repository, it will be committed using the message ``gitolite setup by GNU Guix''.

 -- Tipo de datos: gitolite-configuration
     Tipo de datos que representa la configuración de gitolite-service-type.

     package (predeterminado: GITOLITE)
          Paquete Gitolite usado.

     user (predeterminado: GIT)
          User to use for Gitolite.  This will be user that you use when accessing Gitolite over SSH.

     group (predeterminado: GIT)
          Grupo usado por Gitolite.

     home-directory (predeterminado: "/VAR/LIB/GITOLITE")
          Directory in which to store the Gitolite configuration and repositories.

     rc-file (predeterminado: (GITOLITE-RC-FILE))
          A ``file-like'' object (see file-like objects), representing the configuration for Gitolite.

     admin-pubkey (predeterminada: #F)
          A ``file-like'' object (see file-like objects) used to setup Gitolite.  This will be inserted in to the keydir directory within the gitolite-admin repository.

          To specify the SSH key as a string, use the plain-file function.

               (plain-file "yourname.pub" "ssh-rsa AAAA... guix@example.com")

 -- Tipo de datos: gitolite-rc-file
     Tipo de datos que representa el fichero RC de Gitolite.

     umask (predeterminada: #o0077)
          This controls the permissions Gitolite sets on the repositories and their contents.

          A value like #o0027 will give read access to the group used by Gitolite (by default: git). This is necessary when using Gitolite with software like cgit or gitweb.

     git-config-keys (predeterminadas: "")
          Gitolite allows you to set git config values using the "config" keyword. This setting allows control over the config keys to accept.

     roles (predeterminados: '(("READERS" . 1) ("WRITERS" . )))
          Set the role names allowed to be used by users running the perms command.

     enable (default: '("help" "desc" "info" "perms" "writable" "ssh-authkeys" "git-config" "daemon" "gitweb"))
          This setting controls the commands and features to enable within Gitolite.

Servicios de juegos
-------------------

El servicio de La batalla por Wesnoth
.....................................

La batalla por Wesnoth (https://wesnoth.org) es un juego de estrategia táctica, de fantasía y basado en turnos, con varias campañas de una jugadora, y partidas para múltiples jugadoras (tanto en red como localmente).

 -- Variable: Variable Scheme wesnothd-service-type
     Service type for the wesnothd service.  Its value must be a wesnothd-configuration object.  To run wesnothd in the default configuration, instantiate it as:

          (service wesnothd-service-type)

 -- Tipo de datos: wesnothd-configuration
     Tipo de datos que representa la configuración de wesnothd.

     package (predeterminado: wesnoth-server)
          El paquete del servidor wesnoth usado.

     port (predeterminado: 15000)
          Número de puerto usado por el servidor.

Servicios misceláneos
---------------------

Servicios de huella dactilar
............................

The (gnu services authentication) module provides a DBus service to read and identify fingerprints via a fingerprint sensor.

 -- Variable Scheme: fprintd-service-type
     The service type for fprintd, which provides the fingerprint reading capability.

          (service fprintd-service-type)

Servicios de control del sistema
................................

The (gnu services sysctl) provides a service to configure kernel parameters at boot.

 -- Variable Scheme: sysctl-service-type
     The service type for sysctl, which modifies kernel parameters under /proc/sys/.  To enable IPv4 forwarding, it can be instantiated as:

          (service sysctl-service-type
                   (sysctl-configuration
                     (settings '(("net.ipv4.ip_forward" . "1")))))

 -- Tipo de datos: sysctl-configuration
     Tipo de datos que representa la configuración de sysctl.

     sysctl (predeterminado: (file-append procps "/sbin/sysctl")
          El ejecutable sysctl usado.

     settings (predeterminados: '())
          An association list specifies kernel parameters and their values.

Servicio del daemon de tarjetas inteligentes PC/SC
..................................................

The (gnu services security-token) module provides the following service to run pcscd, the PC/SC Smart Card Daemon. pcscd is the daemon program for pcsc-lite and the MuscleCard framework. It is a resource manager that coordinates communications with smart card readers, smart cards and cryptographic tokens that are connected to the system.

 -- Variable Scheme: pcscd-service-type
     Service type for the pcscd service.  Its value must be a pcscd-configuration object.  To run pcscd in the default configuration, instantiate it as:

          (service pcscd-service-type)

 -- Tipo de datos: pcscd-configuration
     The data type representing the configuration of pcscd.

     pcsc-lite (predeterminado: pcsc-lite)
          The pcsc-lite package that provides pcscd.

     usb-drivers (predeterminado: (list ccid))
          List of packages that provide USB drivers to pcscd. Drivers are expected to be under pcsc/drivers in the store directory of the package.

Servicio Lirc
.............

El módulo (gnu services lirc) proporciona el siguiente servicio.

 -- Procedimiento Scheme: lirc-service [#:lirc lirc]
     [#:device #f] [#:driver #f] [#:config-file #f]  [#:extra-options '()]
     Return a service that runs LIRC (http://www.lirc.org), a daemon that decodes infrared signals from remote controls.

     Optionally, DEVICE, DRIVER and CONFIG-FILE (configuration file name) may be specified.  See lircd manual for details.

     Finally, EXTRA-OPTIONS is a list of additional command-line options passed to lircd.

Servicio Spice
..............

El módulo (gnu services spice) proporciona el siguiente servicio.

 -- Procedimiento Scheme: spice-vdagent-service [#:spice-vdagent]
     Returns a service that runs VDAGENT (http://www.spice-space.org), a daemon that enables sharing the clipboard with a vm and setting the guest display resolution when the graphical console window resizes.

inputattach Service
...................

The inputattach (https://linuxwacom.github.io/) service allows you to use input devices such as Wacom tablets, touchscreens, or joysticks with the Xorg display server.

 -- Scheme Variable: inputattach-service-type
     Type of a service that runs inputattach on a device and dispatches events from it.

 -- Data Type: inputattach-configuration

     device-type (default: "wacom")
          The type of device to connect to.  Run inputattach --help, from the inputattach package, to see the list of supported device types.

     device (default: "/dev/ttyS0")
          The device file to connect to the device.

     log-file (default: #f)
          If true, this must be the name of a file to log messages to.

Servicios de diccionario
------------------------

El módulo (gnu services dict) proporciona el servicio siguiente:

 -- Procedimiento Scheme: dicod-service [#:config (dicod-configuration)]
     Devuelve un servicio que ejecuta el daemon dicod, una implementación del servidor DICT (see Dicod (GNU Dico Manual)).

     El parámetro opcional CONFIG especifica la configuración para dicod, que debe ser un objeto <dicod-configuration>, por defecto proporciona el diccionario colaborativo internacional de Inglés de GNU.

     You can add open localhost to your ~/.dico file to make localhost the default server for dico client (see Initialization File (GNU Dico Manual)).

 -- Tipo de datos: dicod-configuration
     Tipo de datos que representa la configuración de dicod.

     dico (predeterminado: DICO)
          Package object of the GNU Dico dictionary server.

     interfaces (predeterminada: '("LOCALHOST"))
          This is the list of IP addresses and ports and possibly socket file names to listen to (see listen directive (GNU Dico Manual)).

     handlers (predeterminados: '())
          List of <dicod-handler> objects denoting handlers (module instances).

     databases (predeterminada: (LIST %DICOD-DATABASE:GCIDE))
          List of <dicod-database> objects denoting dictionaries to be served.

 -- Tipo de datos: dicod-handler
     Data type representing a dictionary handler (module instance).

     name
          Name of the handler (module instance).

     module (predeterminado: #F)
          Name of the dicod module of the handler (instance).  If it is #f, the module has the same name as the handler.  (see Módulos (GNU Dico Manual)).

     options
          List of strings or gexps representing the arguments for the module handler

 -- Tipo de datos: dicod-database
     Tipo de datos que representa una base de datos de diccionario.

     name
          Nombre de la base de datos, será usada en las órdenes DICT.

     handler
          Name of the dicod handler (module instance) used by this database (see Handlers (GNU Dico Manual)).

     complex? (predeterminado: #F)
          Whether the database configuration complex.  The complex configuration will need a corresponding <dicod-handler> object, otherwise not.

     options
          List of strings or gexps representing the arguments for the database (see Databases (GNU Dico Manual)).

 -- Variable Scheme: %dicod-database:gcide
     A <dicod-database> object serving the GNU Collaborative International Dictionary of English using the gcide package.

The following is an example dicod-service configuration.

     (dicod-service #:config
       (dicod-configuration
        (handlers (list (dicod-handler
                         (name "wordnet")
                         (module "dictorg")
                         (options
                          (list #~(string-append "dbdir=" #$wordnet))))))
        (databases (list (dicod-database
                          (name "wordnet")
                          (complex? #t)
                          (handler "wordnet")
                          (options '("database=wn")))
                         %dicod-database:gcide))))

Docker Service
..............

The (gnu services docker) module provides the following service.

 -- Scheme Variable: docker-service-type

     This is the type of the service that runs Docker (http://www.docker.com), a daemon that can execute application bundles (sometimes referred to as ``containers'') in isolated environments.

 -- Data Type: docker-configuration
     This is the data type representing the configuration of Docker and Containerd.

     package (default: docker)
          The Docker package to use.

     containerd (default: CONTAINERD)
          The Containerd package to use.

Programas con setuid
====================

Algunos programas necesitan ejecutarse con privilegios de ``root'', incluso cuando se ejecutan por usuarias sin privilegios. Un ejemplo notable es el programa passwd, que las usuarias ejecutan para cambiar su contraseña, y que necesita acceso a los ficheros /etc/passwd y /etc/shadow---algo normalmente restringido a root, por razones de seguridad obvias. Para solventarlo, estos ejecutables tienen setuid de root, lo que significa que siempre se ejecutan con privilegios de root (see How Change Persona (The GNU C Library Reference Manual), para más información sobre el mecanismo setuid).

El almacén en sí no puede contener programas setuid: sería un problema de seguridad puesto que cualquier usuaria del sistema puede escribir derivaciones que pueblen el almacén (see El almacén). Por tanto, se usa un mecanismo diferente: en vez de cambiar el bit de setuid directamente en los ficheros que se encuentran en el almacén, se permite que la administradora del sistema declare qué programas deberían tener setuid de root.

El campo setuid-programs de una declaración operating-system contiene una lista de expresiones-G que denotan nombres de programas que tendrán setuid de root (see Uso de la configuración del sistema). Por ejemplo, el programa passwd, que es parte del paquete Shadow, puede designarse con esta expresión-G (see Expresiones-G):

     #~(string-append #$shadow "/bin/passwd")

Un conjunto predeterminado de programas con el bit setuid se define en la variable %setuid-programs del módulo (gnu system).

 -- Variable Scheme: %setuid-programs
     Una lista de expresiones-G que denotan programas comunes que se marcan con setuid de root.

     La lista incluye órdenes como passwd, ping, su y sudo.

Para su implementación, los programas con setuid reales se crean en el directorio /run/setuid-programs durante la activación del sistema. Los ficheros en este directorio hacen referencia a los binarios ``reales'', que estan en el almacén.

Certificados X.509
==================

En las conexiones HTTPS a servidores Web (esto es, HTTP sobre el mecanismo de seguridad de la capa de transporte, TLS) se envía a los programas clientes un certificado X.509 que el cliente puede usar para autentificar al servidor. Para hacerlo, los clientes verifican que el certificado del servidor está firmado por una de las llamadas autoridades de certificación (AC, CA en inglés). Pero para verificar la firma de una AC, los clientes deben haber obtenido previamente el certificado de dicha AC.

Los navegadores Web como GNU IceCat incluyen su propio conjunto de certificados de AC, de manera que pueden verificar las firmas independientemente.

No obstante, a la mayor parte de otros programas que pueden comunicarse a través de HTTPS---wget, git, w3m, etc.---se les debe informar de dónde pueden encontrar los certificados de CA.

In Guix, this is done by adding a package that provides certificates to the packages field of the operating-system declaration (see Referencia de ``operating-system'').  Guix includes one such package, nss-certs, which is a set of CA certificates provided as part of Mozilla's Network Security Services.

Fíjese que no es parte de %BASE-PACKAGES, por lo que debe ser añadido explícitamente. El directorio /etc/ssl/certs, donde la mayor parte de las aplicaciones y bibliotecas buscarán los certificados de manera predeterminada, enlaza a los certificados instalados de manera global.

Las usuarias sin privilegios, incluyendo a usuarias de Guix en una distribución distinta, pueden también instalar su propio paquete de certificados en su perfil. Es necesario definir cierto número de variables de entorno de manera que las aplicaciones y bibliotecas sepan dónde encontrarlos. Por ejemplo, la biblioteca OpenSSL inspecciona las variables SSL_CERT_DIR y SSL_CERT_FILE. Algunas aplicaciones añaden sus variables de entorno propias; por ejemplo, el sistema de control de versiones Git inspecciona el empaquetado de certificados al que apunta la variable de entorno GIT_SSL_CAINFO. Por tanto, en el caso típico se debe ejecutar algo parecido a esto:

     $ guix package -i nss-certs
     $ export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs"
     $ export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt"
     $ export GIT_SSL_CAINFO="$SSL_CERT_FILE"

Como otro ejemplo, R necesita que la variable de entorno CURL_CA_BUNDLE apunte al empaquetado de certificados, de manera que se debe ejecutar algo parecido a esto:

     $ guix package -i nss-certs
     $ export CURL_CA_BUNDLE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt"

Para otras aplicaciones puede tener que buscar la variable de entorno necesaria en la documentación relevante.

Selector de servicios de nombres
================================

El módulo (gnu system nss) proporciona una interfaz con el fichero de configuración del selector de servicios de nombres o NSS (see NSS Configuration File (The GNU C Library Reference Manual)). En resumen, NSS es un mecanismo que permite la extensión de libc con nuevos métodos de búsqueda de ``nombres'', lo que incluye nombres de máquinas, nombres de servicios, cuentas de usuaria y más (see System Databases and Name Service Switch (The GNU C Library Reference Manual)).

La configuración de NSS especifica, para cada base de datos del sistema, que método de búsqueda debe ser usado, y cómo los varios métodos se enlazan entre sí---por ejemplo, bajo qué circunstancias NSS deberá probar con el siguiente método en la lista. La configuración de NSS se proporciona en el campo name-service-switch de las declaraciones operating-system (see name-service-switch).

Como ejemplo, la siguiente declaración configura NSS para usar el motor nss-mdns (http://0pointer.de/lennart/projects/nss-mdns/), que permite las búsquedas de nombres de máquinas sobre DNS multicast (mDNS) para nombres de máquinas terminados en .local:

     (name-service-switch
        (hosts (list %files    ;primero, comprueba /etc/hosts

                     ;; Si lo anterior no funcionó, prueba
                     ;; con 'mdns_minimal'.
                     (name-service
                       (name "mdns_minimal")

                       ;; 'mdns_minimal' tiene autoridad sobre
                       ;; '.local'.  Cuando devuelve 'not-found,
                       ;; no es necesario intentarlo con los
                       ;; métodos siguientes.
                       (reaction (lookup-specification
                                  (not-found => return))))

                     ;; Si no, usa DNS.
                     (name-service
                       (name "dns"))

                     ;; Finalmente, prueba con 'mdns' "al completo".
                     (name-service
                       (name "mdns")))))

No se preocupe: la variable %mdns-host-lookup-nss (véase a continuación) contiene esta configuración, de manera que no tiene que escribirla si todo lo que desea es que funcione la búsqueda de nombres de máquina en .local.

Note that, in this case, in addition to setting the name-service-switch of the operating-system declaration, you also need to use avahi-service-type (see avahi-service-type), or %DESKTOP-SERVICES, which includes it (see Servicios de escritorio).  Doing this makes nss-mdns accessible to the name service cache daemon (see nscd-service).

Por conveniencia, las siguientes variables proporcionan configuraciones NSS típicas.

 -- Variable Scheme: %default-nss
     Esta es la configuración predeterminada del selector de servicios de nombres, un objeto name-service-switch.

 -- Variable Scheme: %mdns-host-lookup-nss
     Esta es la configuración del selector de servicios de nombres que permite la búsqueda de nombres de máquinas por DNS multicast (mDNS) para nombres de máquinas terminados en .local.

La referencia de la configuración del selector de servicios de nombres se proporciona a continuación. Tiene una asociación directa con el formato del fichero de configuración de la biblioteca C, por lo que se recomienda el manual de la biblioteca C para obtener más información (see NSS Configuration File (The GNU C Library Reference Manual)). En comparación con el formato del fichero de configuración del NSS de libc, no solo tiene solo la ventaja de la cálida sensación proporcionada por la adición de paréntesis que tanto nos gustan, sino que también tiene comprobaciones estáticas: conocerá los errores sintácticos y tipográficos con la ejecución de guix system.

 -- Tipo de datos: name-service-switch

     El tipo de datos que representa la configuración del selector de servicios de nombres (NSS). Cada campo a continuación representa una de las bases de datos del sistema admitidas.

     aliases
     ethers
     group
     gshadow
     hosts
     initgroups
     netgroup
     networks
     password
     public-key
     rpc
     services
     shadow
          Las bases de datos del sistema que maneja el NSS. Cada uno de estos campos debe ser una lista de objetos <name-service> (véase a continuación).

 -- Tipo de datos: name-service

     Este es el tipo de datos que representa un servicio de nombres real y la acción de búsqueda asociada.

     name
          Una cadena que denota el nombre de servicio (see Services in the NSS configuration (The GNU C Library Reference Manual)).

          Fijese que los servicios de nombres enumerados aquí deben ser visibles para nscd. Esto se consigue mediante la adición del parámetro #:name-services a nscd-service con la lista de paquetes que proporcionan los servicios de nombres necesarios (see nscd-service).

     reaction
          Una acción especificada mediante el uso del macro lookup-specification (see Actions in the NSS configuration (The GNU C Library Reference Manual)). Por ejemplo:

               (lookup-specification (unavailable => continue)
                                     (success => return))

Disco en RAM inicial
====================

Para el propósito del arranque inicial, se le proporciona al núcleo Linux-libre un disco inicial de RAM, o initrd. Un initrd contiene un sistema de ficheros raíz temporal así como un guión de inicialización. Este último es responsable del montaje del sistema de ficheros raíz real, así como de la carga de cualquier módulo del núcleo que pueda ser necesario para esta tarea.

El campo initrd-modules de una declaración operating-system le permite especificar qué módulos del nucleo Linux-libre deben estar disponibles en el initrd. En particular, aquñi es donde se debe enumerar los módulos que controlen realmente el disco duro deonde su partición raíz se encuentre---aunque el valor predeterminado de initrd-modules debería cubrir la mayor parte de casos de uso. Por ejemplo, en caso de necesitar el módulo megaraid_sas además de los módulos predeterminados para poder acceder a sistema de ficheros raíz, se podría escribir:

     (operating-system
       ;; ...
       (initrd-modules (cons "megaraid_sas" %base-initrd-modules)))

 -- Variable Scheme: %base-initrd-modules
     Esta es la lista de módulos del nucleo que se incluyen en el initrd predeterminado.

Más allá, si necesita personalizaciones de un nivel más bajo, el campo initrd de una declaración operating-system le permite especificar qué initrd desea usar. El módulo (gnu system linux-initrd) proporciona tres formas de construir un initrd: el procedimiento de alto nivel base-initrd y los procedimientos de bajo nivel raw-initrd y expression->initrd.

El procedimiento base-initrd está pensado para cubrir la mayor parte de usos comunes. Por ejemplo, si desea añadir algunos módulos del nucleo que deben cargarse durante el arranque, puede definir el campo initrd de la declaración de sistema operativo de esta forma:

     (initrd (lambda (sistemas-de-ficheros . resto)
               ;; Crea un initrd estándar pero configura la red
               ;; con los parámetros que QEMU espera por omisión.
               (apply base-initrd sistemas-de-ficheros
                      #:qemu-networking? #t
                      resto)))

El procedimiento base-initrd también maneja casos de uso comunes que implican el uso del sistema en un anfitrión QEMU, o como un sistema ``live'' con un sistema de ficheros raíz volátil.

El procedimiento base-initrd se construye sobre el procedimiento raw-initrd. Al contrario que base-initrd, raw-initrd no funciona a alto nivel, como sería intentar deducir qué módulos del nucleo y paquetes deben incluirse en el initrd. Un ejemplo de uso de raw-initrd es cuando una usuaria tiene personalizada una configuración del nucleo Linux y los módulos predeterminados del núcleo que incluye base-initrd no están disponibles.

El disco inicial de RAM producido por base-initrd o raw-initrd inspecciona varias opciones proporcionadas por la línea de órdenes al núcleo Linux (esto es, argumentos pasados a través de la orden linux de GRUB, o de la opción -append de QEMU), notablemente:

--load=ARRANQUE
     Indica al disco de RAM inicial que cargue ARRANQUE, un fichero que contiene un programa Scheme, una vez haya montado el sistema de ficheros raíz.

     Guix uses this option to yield control to a boot program that runs the service activation programs and then spawns the GNU Shepherd, the initialization system.

--root=RAÍZ
     Monta RAÍZ como el sistema de ficheros raíz. RAÍZ puede ser un nombre de dispositivo como /dev/sda1, una etiqueta del sistema de ficheros o un UUID del sistema de ficheros.

--system=SISTEMA
     Hace que /run/booted-system y /run/current-system apunten a SISTEMA.

modprobe.blacklist=MÓDULOS...
     Indica al disco inicial de RAM así como a la orden modprobe (del paquete kmod) que deben negarse a cargar MÓDULOS. MÓDULOS debe ser una lista separada por comas de nombres de módulos---por ejemplo, usbkbd,9pnet.

--repl
     Inicia una sesión interactiva (REPL) desde el disco inicial de RAM antes de que intente cargar los módulos del núcleo y del montaje del sistema de ficheros raíz. Nuestro departamento comercial lo llama arranca-en-Guile. Como amante de Scheme, lo adorará. See Using Guile Interactively (GNU Guile Reference Manual), para más información sobre sesiones interactivas Guile.

Now that you know all the features that initial RAM disks produced by base-initrd and raw-initrd provide, here is how to use it and customize it further.

 -- Procedimiento Scheme: raw-initrd SISTEMAS-DE-FICHEROS
     [#:linux-modules '()] [#:mapped-devices '()]  [#:keyboard-layout #f]
     [#:helper-packages '()] [#:qemu-networking? #f] [#:volatile-root? #f] Return
     a derivation that builds a raw initrd.  FILE-SYSTEMS is a list of file systems to be mounted by the initrd, possibly in addition to the root file system specified on the kernel command line via --root. LINUX-MODULES is a list of kernel modules to be loaded at boot time. MAPPED-DEVICES is a list of device mappings to realize before FILE-SYSTEMS are mounted (see Dispositivos traducidos). HELPER-PACKAGES is a list of packages to be copied in the initrd. It may include e2fsck/static or other packages needed by the initrd to check the root file system.

     When true, KEYBOARD-LAYOUT is a <keyboard-layout> record denoting the desired console keyboard layout.  This is done before MAPPED-DEVICES are set up and before FILE-SYSTEMS are mounted such that, should the user need to enter a passphrase or use the REPL, this happens using the intended keyboard layout.

     Cuando QEMU-NETWORKING? es verdadero, configura la red con los parámetros QEMU estándar. Cuando VIRTIO? es verdadero, carga módulos adicionales para que la imagen en RAM pueda ser usada como un sistema virtualizado por QEMU con controladores paravirtualizados de E/S.

     Cuando VOLATILE-ROOT? es verdadero, el sistema de ficheros raíz tiene permisos de escritura pero cualquier cambio realizado se perderá.

 -- Procedimiento Scheme: base-initrd SISTEMAS-DE-FICHEROS
     [#:mapped-devices '()] [#:keyboard-layout #f]  [#:qemu-networking? #f]
     [#:volatile-root? #f]  [#:linux-modules '()] Return as a file-like object a generic initrd, with kernel modules taken from LINUX. FILE-SYSTEMS is a list of file-systems to be mounted by the initrd, possibly in addition to the root file system specified on the kernel command line via --root.  MAPPED-DEVICES is a list of device mappings to realize before FILE-SYSTEMS are mounted.

     When true, KEYBOARD-LAYOUT is a <keyboard-layout> record denoting the desired console keyboard layout.  This is done before MAPPED-DEVICES are set up and before FILE-SYSTEMS are mounted such that, should the user need to enter a passphrase or use the REPL, this happens using the intended keyboard layout.

     QEMU-NETWORKING? y VOLATILE-ROOT? funcionan como en raw-initrd.

     El initrd incorpora automáticamente todos los módulos del nucleo necesarios para SISTEMAS-DE-FICHEROS y para las opciones proporcionadas. Módulos del nucleo adicionales pueden proporcionarse a través de LINUX-MODULES. Se añadirán al initrd y se cargarán en tiempo de arranque en el orden que aparezcan.

No es necesario decir que los initrd que producimos y usamos embeben un Guile enlazado estáticamente, y que el programa de inicialización es un programa Guile. Esto proporciona mucha flexibilidad. El procedimiento expression->initrd construye un initrd de ese tipo, una vez proporcionado el programa a ejecutar en dicho initrd.

 -- Procedimiento Scheme: expression->initrd EXP
     [#:guile %guile-static-stripped] [#:name "guile-initrd"]
     Devuelve como un objeto tipo-fichero el initrd de Linux (un archivador cpio comprimido con gzip) que contiene GUILE y que evalua a EXP, una expresión-G, al arranque. Todas las derivaciones a las que EXP hace referencia se copian automáticamente en el initrd.

Configuración del gestor de arranque
====================================

El sistema operativo permite varios cargadores de arranque. El cargador de arranque se configura mediante el uso de la declaración bootloader-configuration. Todos los campos de esta estructura son independientes del cargador de arranque excepto uno, bootloader, que indica el cargador de arranque a configurar e instalar.

Algunos de los cargadores de arranque no inspeccionan todos los campos de bootloader-configuration. Por ejemplo, el cargador de arranque extlinux no permite temas y por lo tanto ignora el campo theme.

 -- Tipo de datos: bootloader-configuration
     El tipo de una declaración de configuración del cargador de arranque.

     bootloader
          El cargador de arranque a usar, como un objeto bootloader. De momento se aceptan grub-bootloader, grub-efi-bootloader, extlinux-bootloader y u-boot-bootloader.

          grub-efi-bootloader permite el arranque en sistemas modernos que usan la interfaz extendida de firmware unificada (UEFI). Es el que debería ser usado si la imagen de instalación contiene un directorio /sys/firmware/efi cuando la arranca en su sistema.

          grub-bootloader permite el arranque en máquinas basadas en Intel en modo ``antiguo'' BIOS.

          Los cargadores de arranque se describen en los módulos (gnu bootloader ...). En particular, (gnu bootloader u-boot) contiene definiciones de cargadores de arranque para un amplio rango de sistemas ARM y AArch64, mediante el uso del cargador de arranque U-Boot (http://www.denx.de/wiki/U-Boot/).

     target
          Una cadena que indica donde se instalará el cargador de arranque.

          La interpretación depende del cargador de arranque en cuestión. Para grub-bootloader, por ejemplo, debe ser un nombre de dispositivo que entienda la orden install del cargador de arranque, como /dev/sda o (hd0) (see Invoking grub-install (GNU GRUB Manual)). Para grub-efi-bootloader, debe apuntar al punto de montaje del sistema de ficheros EFI, habitualmente /boot/efi.

     menu-entries (predeterminadas: ())
          Una lista posiblemente vacia de objetos menu-entry (véase a continuación), que indican entradas que deben aparecer en el menú del cargador de arranque, además de la entrada del sistema actual y la entrada que apunta a generaciones previas del sistema.

     default-entry (predeterminada: 0)
          El índice de la entrada del menú de arranque por omisión. El índice 0 es para la entrada del sistema actual.

     timeout (predeterminado: 5)
          El número de segundos que se esperará entrada por el teclado antes de arrancar. El valor 0 indica que se debe arrancar de forma inmediata, y -1 que se debe esperar indefinidamente.

     keyboard-layout (predeterminada: #f)
          If this is #f, the bootloader's menu (if any) uses the default keyboard layout, usually US English (``qwerty'').

          Otherwise, this must be a keyboard-layout object (see Distribución de teclado).

               This option is currently ignored by bootloaders other than grub and grub-efi.

     theme (predeterminado: #F)
          El objeto del tema del cargador de arranque que describa el tema a usar. Si no se proporciona ningún tema, algunos cargadores de arranque pueden usar un tema por omisión, lo cual es cierto en GRUB.

     terminal-outputs (predeterminada: 'gfxterm)
          Los terminales de salida que se usarán para el menú de arranque, como una lista de símbolos. GRUB acepta los valores: console, serial, serial_{0-3}, gfxterm, vga_text, mda_text, morse y pkmodem. Este campo corresponde con la variable GRUB_TERMINAL_OUTPUT (see Simple configuration (GNU GRUB manual)).

     terminal-inputs (predeterminadas: '())
          Los terminales de entrada que se usarán para el menú de arranque, como una lista de símbolos. Para GRUB, el valor predeterminado es el terminal nativo de la platafroma determinado en tiempo de ejecución. GRUB acepta los valores: console, serial, serial{0-3}, at_keyboard y usb_keyboard. Este campo corresponde a la variable GRUB GRUB_TERMINAL_INPUT (see Simple configuration (GNU GRUB manual)).

     serial-unit (predeterminada: #f)
          La unidad serie usada por el cargador de arranque, como un entero del 0 al 3. Para GRUB, se selecciona en tiempo de ejecución; actualmente GRUB selecciona 0 lo que corresponde a COM1 (see Serial terminal (GNU GRUB manual)).

     serial-speed (predeterminada: #f)
          La velocidad de la interfaz serie, como un entero. Para GRUB, el valor predeterminado se selecciona en tiempo de ejecución, actualmente GRUB selecciona 9600 bps (see Serial terminal (GNU GRUB manual)).

Si desease listar entradas adicionales para el menú de arranque a través del campo menu-entries mostrado previamente, deberá crearlas con la forma menu-entry. Por ejemplo, imagine que desea ser capaz de arrancar otra distribución (¡difícil de imaginar!), puede definir una entrada de menú de esta forma:

     (menu-entry
       (label "La otra distribución")
       (linux "/boot/old/vmlinux-2.6.32")
       (linux-arguments '("root=/dev/sda2"))
       (initrd "/boot/old/initrd"))

Los detalles se encuentran a continuación.

 -- Tipo de datos: menu-entry
     El tipo de una entrada en el menú del cargador de arranque.

     label
          La etiqueta a mostrar en el menú---por ejemplo, "GNU".

     linux
          La imagen del núcleo Linux a arrancar, por ejemplo:

               (file-append linux-libre "/bzImage")

          Con GRUB, también es posible especificar un dispositivo explícitamente mediante el uso de la convención de nombres de dispositivo de GRUB (see Naming convention (GNU GRUB manual)), por ejemplo:

               "(hd0,msdos1)/boot/vmlinuz"

          Si se especifica el dispositivo explícitamente como en el ejemplo anterior, el campo device se ignora completamente.

     linux-arguments (predeterminados: ())
          La lista de parámetros extra de línea de órdenes para el núcleo Linux---por ejemplo, ("console=ttyS0").

     initrd
          Una expresión-G o una cadena que contiene el nombre de fichero del disco inicial en RAM a usar (see Expresiones-G).

     device (predeterminado: #f)
          El dispositivo donde se encuentran el núcleo y el initrd---es decir, para GRUB, raíz de esta entrada de menú (see root (GNU GRUB manual)).

          Puede ser una etiqueta de sistema de ficheros (una cadena), un UUID de sistema de ficheros (un vector de bytes, see Sistemas de ficheros), o #f, en cuyo caso el cargador de arranque buscará el dispositivo que contenga el fichero especificado por el campo linux (see search (GNU GRUB manual)). No debe ser un nombre de dispositivo del SO como /dev/sda1.

For now only GRUB has theme support. GRUB themes are created using the grub-theme form, which is not documented yet.

 -- Variable Scheme: %default-theme
     Este es el tema predeterminado de GRUB que usa el sistema operativo si no se especifica el campo theme en el registro bootloader-configuration.

     Viene con una bonita imagen de fondo que muestra los logos de GNU y Guix.

Invocación de guix system
=========================

Una vez haya escrito la declaración de sistema operativo como se ha visto en la sección previa, puede instanciarse mediante el uso de la orden guix system. Su sinopsis es:

     guix system OPCIONES... ACCIÓN FICHERO

FICHERO debe ser el nombre de un fichero que contenga una declaración operating-system. ACCIÓN especifica cómo se instancia el sistema operativo. Actualmente se permiten los siguientes valores:

search
     Muestra las definiciones de tipos de servicio disponibles que corresponden con las expresiones regulares proporcionadas, ordenadas por relevancia:

          $ guix system search console font
          name: console-fonts
          location: gnu/services/base.scm:729:2
          extends: shepherd-root
          description: Install the given fonts on the specified ttys (fonts are
          + per virtual console on GNU/Linux).  The value of this service is a list
          + of tty/font pairs like:
          +
          +      '(("tty1" . "LatGrkCyr-8x16"))
          relevance: 20

          name: mingetty
          location: gnu/services/base.scm:1048:2
          extends: shepherd-root
          description: Provide console login using the `mingetty' program.
          relevance: 2

          name: login
          location: gnu/services/base.scm:775:2
          extends: pam
          description: Provide a console log-in service as specified by its
          + configuration value, a `login-configuration' object.
          relevance: 2

          ...

     Como con guix package --search, el resultado se obtiene en formato recutils, lo que facilita el filtrado de la salida (see GNU recutils databases (GNU recutils manual)).

reconfigure
     Build the operating system described in FILE, activate it, and switch to it (This action (and the related actions switch-generation and roll-back) are usable only on systems already running Guix System.).

     This effects all the configuration specified in FILE: user accounts, system services, global package list, setuid programs, etc.  The command starts system services specified in FILE that are not currently running; if a service is currently running this command will arrange for it to be upgraded the next time it is stopped (e.g. by herd stop X or herd restart X).

     Esta orden crea una nueva generación cuyo número es el sucesor de la siguiente generación (como lo muestra guix system list-generations). Si esa generación ya existe, será sobreescrita. Este comportamiento es el mismo que el de guix package (see Invocación de guix package).

     También añade una entrada al cargador de arranque para la nueva configuración del sistema operativo---en caso de que no se proporcione la opción --no-bootloader. Con GRUB, mueve las entradas de configuraciones antiguas a un submenú, permitiendo la selección de una generación previa del sistema en tiempo de arranque en caso necesario.

          Es altamente recomendable ejecutar guix pull antes de la primera ejecución de guix system reconfigure (see Invocación de guix pull). No hacerlo puede ocasionar que se obtenga una versión más antigua de Guix una vez que reconfigure se haya completado.

switch-generation
     Cambia a una generación existente del sistema. Esta acción cambia atómicamente el perfil del sistema a la generación del sistema especificada. También redistribuye las entradas de sistema del menú de arranque existentes. Marca como predeterminada la entrada de la generación de sistema especificada y mueve las entradas de otras generaciones a un submenú, si el cargador de arranque lo permite. La próxima vez que se arranque el sistema, se usará la generación de sistema especificada.

     El cargador de arranque en sí no se reinstala durante esta orden. Por tanto, el cargador de arranque instalado se usa con un fichero de configuración actualizado.

     La generación deseada puede especificarse explícitamente con su numero de generación. Por ejemplo, la siguiente invocación cambiaría a la generación 7 del sistema:

          guix system switch-generation 7

     La generación deseada puede especificarse también de forma relativa a la generación actual con la forma +N o -N, donde +3 significa ``3 generaciones después de la generación actual'', y -1 significa ``1 generación antes de la generación actual''. Cuando se especifica un valor negativo como -1 debe ir precedido de -- para evitar que se analice como una opción. Por ejemplo:

          guix system switch-generation -- -1

     Actualmente, el efecto de la invocación de esta acción es únicamente cambiar el perfil del sistema a una generación existente y redistribuir las entradas del menú de arranque. Para realmente empezar a usar la generación deseada del sistema, debe reiniciar tras esta acción. En el futuro, se actualizará para hacer lo mismo que reconfigure, como activación y desactivación de servicios.

     Esta acción fallará si la generación especificada no existe.

roll-back
     Cambia a la generación de sistema previa. Tras el siguiente arranque del sistema, usará la generación de sistema precedente. Es la operación inversa de reconfigure, y es equivalente a la invocación de switch-generation con -1 como parámetro.

     Actualmente, como con switch-generation, debe reiniciar tras la ejecución de esta acción para realmente empezar a usar la generación de sistema precedente.

delete-generations
     Delete system generations, making them candidates for garbage collection (see Invocación de guix gc, for information on how to run the ``garbage collector'').

     This works in the same way as guix package --delete-generations (see --delete-generations).  With no arguments, all system generations but the current one are deleted:

          guix system delete-generations

     You can also select the generations you want to delete.  The example below deletes all the system generations that are more than two month old:

          guix system delete-generations 2m

     Running this command automatically reinstalls the bootloader with an updated list of menu entries---e.g., the ``old generations'' sub-menu in GRUB no longer lists the generations that have been deleted.

build
     Construye la derivación del sistema operativo, que incluye todos los ficheros de configuración y programas necesarios para el arranque y la ejecución del sistema. Esta acción no instala nada en realidad.

init
     Populate the given directory with all the files necessary to run the operating system specified in FILE.  This is useful for first-time installations of Guix System.  For instance:

          guix system init mi-conf-del-so.scm /mnt

     copia a /mnt todos los elementos del almacén necesarios para la configuración especificada en mi-conf-del-so.scm. Esto incluye los ficheros de configuración, paquetes y demás. También crea otros ficheros esenciales necesarios para la correcta operación del sistema---por ejemplo, los directorios /etc, /var y /run, y el fichero /bin/sh.

     Esta orden también instala el cargador de arranque en el destino especificado en mi-conf-del-so.scm, siempre que no se proporcione la opción --no-bootloader.

vm
     Build a virtual machine that contains the operating system declared in FILE, and return a script to run that virtual machine (VM).

          The vm action and others below can use KVM support in the Linux-libre kernel.  Specifically, if the machine has hardware virtualization support, the corresponding KVM kernel module should be loaded, and the /dev/kvm device node must exist and be readable and writable by the user and by the build users of the daemon (see Configuración del entorno de construcción).

     Arguments given to the script are passed to QEMU as in the example below, which enables networking and requests 1 GiB of RAM for the emulated machine:

          $ /gnu/store/...-run-vm.sh -m 1024 -net user

     La VM comparte su almacén con el sistema anfitrión.

     Sistemas de ficheros adicionales pueden compartirse entre la máquina anfitriona y la virtual mediante el uso de las opciones --share y --expose: la primera especifica un directorio a compartir con acceso de escritura, mientras que la última proporciona solo acceso de lectura al directorio compartido.

     El siguiente ejemplo crea una máquina virtual en la que el directorio de la usuaria es accesible en modo solo-lecture, y donde el directorio /intercambio esta asociado de forma lectura-escritura con $HOME/tmp en el sistema anfitrión:

          guix system vm mi-configuracion.scm \
             --expose=$HOME --share=$HOME/tmp=/intercambio

     En GNU/Linux, lo predeterminado es arrancar directamente el núcleo; esto posee la ventaja de necesitar únicamente una pequeña imagen del disco raíz pequeña ya el el almacén de la anfitriona puede montarse.

     La opción --full-boot fuerza una secuencia de arranque completa, desde el cargador de arranque. Esto necesita más espacio en disco ya que la imagen raíz que contiene el núcleo, initrd y los ficheros de datos del cargador de arranque deben crearse. La opción --image-size puede usarse para especificar el tamaño de la imagen.

vm-image
disk-image
docker-image
     Devuelve una máquina virtual, imagen de disco o imagen Docker del sistema operativo declarado en FICHERO que es independiente. Por omisión, guix system estima el tamaño de la imagen necesario para almacenar el sistema, pero puede usar la opción --image-size para especificar un valor. Las imagenes Docker se construyen para que contengan exactamente lo que necesitan, por lo que la opción --image-size se ignora en el caso de docker-image.

     Puede especificar el sistema de ficheros raíz mediante el uso de la opción --file-system-type. Su valor predeterminado es ext4.

     When using vm-image, the returned image is in qcow2 format, which the QEMU emulator can efficiently use. See Ejecutar Guix en una máquina virtual, for more information on how to run the image in a virtual machine.

     Con disk-image se produce una imagen de disco cruda; puede copiarse tal cual en una memoria USB, por ejemplo. Asumiendo que /dev/sdc es el dispositivo que corresponde a la memoria USB, se podría copiar la imagen con la siguiente orden:

          # dd if=$(guix system disk-image mi-so.scm) of=/dev/sdc

     Con docker-image se produce una imagen Docker. Guix construye la imagen de cero, no de una imagen Docker base preexistente. Como resultado, contiene exactamente lo definido en el fichero de configuración del sistema operativo. Puede cargar la imagen y ejecutar un contenedor Docker mediante el uso de ordenes como las siguientes:

          image_id="$(docker load < guix-system-docker-image.tar.gz)"
          docker run -e GUIX_NEW_SYSTEM=/var/guix/profiles/system \\
              --entrypoint /var/guix/profiles/system/profile/bin/guile \\
              $image_id /var/guix/profiles/system/boot

     This command starts a new Docker container from the specified image.  It will boot the Guix system in the usual manner, which means it will start any services you have defined in the operating system configuration.  Depending on what you run in the Docker container, it may be necessary to give the container additional permissions.  For example, if you intend to build software using Guix inside of the Docker container, you may need to pass the --privileged option to docker run.

container
     Devuelve un guión de la ejecución del sistema operativo declarado en FICHERO dentro de un contenedor. Los contenedores son un conjunto de mecanismos de aislamiento ligeros que proporciona el núcleo Linux-libre. Los contenedores necesitan sustancialmente menos recursos que máquinas virtuales completas debido a que el núcleo, los objetos compartidos y otros recursos pueden compartirse con el sistema anfitrión; esto también significa que proporcionan un menor aislamiento.

     En este momento, el guión debe ejecutarse como root para permitir más de una única usuaria y grupo. El contenedor comparte su almacén con la máquina anfitriona.

     Como con la acción vm (see guix system vm), sistemas de ficheros adicionales a compartir entre la máquina anfitriona y el contenedor pueden especificarse mediante el uso de las opciones --share y --expose:

          guix system container mi-configuracion.scm \
             --expose=$HOME --share=$HOME/tmp=/intercambio

          Esta opción requiere Linux-libre 3.19 o posterior.

OPCIONES puede contener cualquiera de las opciones de construcción comunes (see Opciones comunes de construcción). Además, OPCIONES puede contener una de las siguientes:

--expression=EXPR
-e EXPR
     Consider the operating-system EXPR evaluates to.  This is an alternative to specifying a file which evaluates to an operating system. This is used to generate the Guix system installer see Construcción de la imagen de instalación).

--system=SISTEMA
-s SISTEMA
     Intenta la construcción para SISTEMA en vez de para el tipo de la máquina anfitriona. Funciona como en guix build (see Invocación de guix build).

--derivation
-d
     Devuelve el nombre de fichero de la derivación del sistema operativo proporcionado sin construir nada.

--file-system-type=TIPO
-t TIPO
     Para la acción disk-image, crea un sistema de ficheros del TIPO proporcionado en la imagen.

     Cuando se omite esta opción, guix system usa ext4.

     --file-system-type=iso9660 produce una imagen ISO-9660, que puede ser grabada en CD y DVD.

--image-size=TAMAÑO
     Junto a las acciones vm-image y disk-image, crea una imagen del ŦAMAÑO proporcionado. TAMAÑO debe ser un número de bytes o puede incluir una unidad como sufijo (see size specifications (GNU Coreutils)).

     Cuando se omite esta opción, guix system calcula una estimación del tamaño de la imagen en función del tamaño del sistema declarado en FICHERO.

--root=FICHERO
-r FICHERO
     Hace que FICHERO sea un enlace simbólico al resultado, y lo registra como una raíz del recolector de basura.

--skip-checks
     Omite las comprobaciones de seguridad previas a la instalación.

     Por omisión, guix system init y guix system reconfigure realizan comprobaciones de seguridad: se aseguran de que los sistemas de ficheros que aparecen en la declaración operating-system realmente existen (see Sistemas de ficheros) y que cualquier módulo del núcleo Linux que pudiese necesitarse durante el arranque se encuentre en initrd-modules (see Disco en RAM inicial). El uso de esta opción omite todas estas comprobaciones.

--on-error=ESTRATEGIA
     Aplica ESTRATEGIA cuando ocurre un error durante la lectura de FICHERO. ESTRATEGIA puede ser uno de los siguientes valores:

     nothing-special
          Informa concisamente del error y termina la ejecución. Es la estrategia predeterminada.

     backtrace
          Del mismo modo, pero también muestra la secuencia de llamadas.

     debug
          Informa del error y entra en el depurador de Guile. A partir de ahí, puede ejecutar órdenes como ,bt para obtener la secuencia de llamads, ,locals para mostrar los valores de las variables locales, e inspeccionar el estado del programa de forma más general. See Debug Commands (GNU Guile Reference Manual), para una lista de órdenes de depuración disponibles.

Once you have built, configured, re-configured, and re-re-configured your Guix installation, you may find it useful to list the operating system generations available on disk---and that you can choose from the bootloader boot menu:

list-generations
     Muestra un resumen de cada generación del sistema operativo disponible en el disco, de manera legible por humanos. Es similar a la opción --list-generations de guix package (see Invocación de guix package).

     De manera opcional, se puede especificar un patrón, con la misma sintaxis que la usada en guix package --list-generations, para restringir la lista de generaciones mostradas. Por ejemplo, la siguiente orden muestra generaciones que tienen hasta 10 días de antigüedad:

          $ guix system list-generations 10d

¡La orden guix system tiene aún más que ofrecer! Las siguientes ordenes le permiten visualizar cual es la relación entre los servicios del sistema:

extension-graph
     Emite en formato Dot/Graphviz por la salida estándar el grafo de extensiones de servicio del sistema operativo definido en FICHERO (see Composición de servicios, para más información sobre extensiones de servicio).

     La orden:

          $ guix system extension-graph FICHERO | dot -Tpdf > servicios.pdf

     produce un fichero PDF que muestra las relaciones de extensiones entre los servicios.

shepherd-graph
     Emite en formato Dot/Graphviz por la salida estándar el grafo de dependencias de los servicios shepherd del sistema operativo definido en FICHERO. See Servicios de Shepherd, para más información y un grafo de ejemplo.

Ejecución de Guix en una máquina virtual
========================================

To run Guix in a virtual machine (VM), one can either use the pre-built Guix VM image distributed at https://alpha.gnu.org/gnu/guix/guix-system-vm-image-VERSION.SYSTEM.xz , or build their own virtual machine image using guix system vm-image (see Invocación de guix system).  The returned image is in qcow2 format, which the QEMU emulator (http://qemu.org/) can efficiently use.

Si ha construido su propia imagen, debe copiarla fuera del almacén y proporcionarse a sí misma permisos de escritura sobre dicha copia antes de usarla. En la invocación de QEMU debe elegir un emulador de sistema que sea adecuado para su plataforma hardware. Esta es una invocación de QEMU mínima que arrancará el resultado de guix system vm-image en hardware x86_64:

     $ qemu-system-x86_64 \
        -net user -net nic,model=virtio \
        -enable-kvm -m 256 /tmp/imagen-qemu

Aquí está el significado de cada una de esas opciones:

qemu-system-x86_64
     Esto especifica la plataforma hardware a emular. Debe corresponder con el anfitrión.

-net user
     Habilita la pila de red en modo de usuaria sin privilegios. El SO virtualizado puede acceder al anfitrión pero no al revés. Esta es la forma más simple de poner en línea un SO virtualizado.

-net nic,model=virtio
     Debe crear una interfaz de red del modelo proporcionado. Si la crea, el arranque fallará. Asumiendo que su plataforma hardware sea x86_64, puede obtener una lista de modelos de interfaz de red disponibles ejecutando qemu-system-x86_64 -net nic,model=help.

-enable-kvm
     Si su sistema tiene extensiones de virtualización por hardware, la activación de la implementación de máquinas virtuales (KVM) del núcleo Linux hará que la ejecución sea más rápida.

-m 256
     RAM disponible para el sistema operativo virtualizado, en mebibytes. El valor predeterminado es 128 MiB, que puede ser insuficiente para algunas operaciones.

/tmp/imagen-qemu
     El nombre de fichero de la imagen qcow2.

El guión run-vm.sh predeterminado que devuelve la invocación de guix system vm no añade una opción -net user por defecto. Para obtener acceso a la red desde la máquina virtual añada el servicio (dhcp-client-service) a su definición de sistema y arranque la máquina virtual mediante el uso de `guix system vm config.scm` -net user. Un punto importante a tener en cuenta del uso de -net user para la obtención de red es que ping no funcionará, puesto que usa el protocolo ICMP. Deberá usar una orden diferente para comprobar la conectividad a la red, por ejemplo guix download.

Conexión a través de SSH
------------------------

Para activar SSH dentro de una máquina virtual debe añadir un servidor SSH como (dropbear-service) o (lsh-service) en su máquina virtual. El servicio (lsh-service) no arranca actualmente sin supervisión, ya que precisa de entrada para inicializar el generador de aleatoriedad. Además tiene que redirigir el puerto SSH, 22 el predeterminado, a la máquina anfitriona. Puede hacerlo con

     `guix system vm config.scm` -net user,hostfwd=tcp::10022-:22

Para conectarse a la máquina virtual puede ejecutar

     ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 10022

La -p indica a ssh el puerto al que se debe conectar. -o UserKnownHostsFile=/dev/null evita que ssh se queje cada vez que modifique su fichero config.scm y la orden -o StrictHostKeyChecking=no evita que tenga que autorizar la conexión a una máquina desconocida cada vez que se conecte.

Uso de virt-viewer con Spice
----------------------------

Como alternativa al cliente gráfico predeterminado de qemu puede usar remote-viewer del paquete virt-viewer. Para conectarse proporcione la opción -spice port=5930,disable-ticketing a qemu. Véase la sección previa para más información sobre cómo hacer esto.

Spice también le permite hacer cosas como compartir su portapapeles con su máquina virtual. Para activarlo debe proporcionar también las siguientes opciones a qemu:

     -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x5
     -chardev spicevmc,name=vdagent,id=vdagent
     -device virtserialport,nr=1,bus=virtio-serial0.0,chardev=vdagent,
     name=com.redhat.spice.0

También debe añadir el see servicio Spice.

Definición de servicios
=======================

Las secciones anteriores muestran los servicios disponibles y cómo se pueden combinar en una declaración operating-system. ¿Pero cómo las definimos en primer lugar? ¿Y qué es un servicio en cualquier caso?

Composición de servicios
------------------------

Definimos un servicio como, grosso modo, algo que extiende la funcionalidad del sistema operativo. Habitualmente un servicio es un proceso---un daemon---iniciado cuando el sistema arranca: un servidor de shell seguro, un servidor Web, el daemon de construcción de Guix, etc. A veces un servicio es un daemon cuya ejecución puede ser iniciada por otro daemon---por ejemplo, un servidor FTP iniciado por inetd o un servicio D-Bus activado por dbus-daemon. De manera ocasional, un servicio no se puede asociar a un daemon. Por ejemplo, el servicio ``account'' recopila cuentas de usuaria y se asegura que existen cuando el sistema se ejecuta; el servicio ``udev'' recopila reglas de gestión de dispositivos y los pone a disposición del daemon eudev; el servicio /etc genera el contenido del directorio /etc del sistema.

Guix system services are connected by extensions.  For instance, the secure shell service extends the Shepherd---the initialization system, running as PID 1---by giving it the command lines to start and stop the secure shell daemon (see openssh-service-type); the UPower service extends the D-Bus service by passing it its .service specification, and extends the udev service by passing it device management rules (see upower-service); the Guix daemon service extends the Shepherd by passing it the command lines to start and stop the daemon, and extends the account service by passing it a list of required build user accounts (see Servicios base).

Al fin y al cabo, los servicios y sus relaciones de ``extensión'' forman un grafo acíclico dirigido (GAD). Si representamos los servicios como cajas y las extensiones como flechas, un sistema típico puede proporcionar algo de este estilo:

Grafo típico de extensiones de servicios.

En la base, podemos ver el servicio del sistema, el cual produce el directorio que contiene todo lo necesario para ejecutar y arrancar el sistema, como es devuelto por la orden guix system build. See Referencia de servicios, para aprender acerca de otros servicios mostrados aquí. See la orden guix system extension-graph, para información sobre cómo generar esta representación para una definición particular de sistema operativo.

Technically, developers can define service types to express these relations.  There can be any number of services of a given type on the system---for instance, a system running two instances of the GNU secure shell server (lsh) has two instances of lsh-service-type, with different parameters.

La siguiente sección describe la interfaz programática para tipos de servicio y servicios.

Tipos de servicios y servicios
------------------------------

Un tipo de servicio es un nodo en el GAD descrito previamente. Empecemos con un ejemplo simple, el tipo de servicio para el daemon de construcción Guix (see Invocación de guix-daemon):

     (define guix-service-type
       (service-type
        (name 'guix)
        (extensions
         (list (service-extension shepherd-root-service-type guix-shepherd-service)
               (service-extension account-service-type guix-accounts)
               (service-extension activation-service-type guix-activation)))
        (default-value (guix-configuration))))

Define tres cosas:

 1. Un nombre, cuyo único propósito es facilitar la inspección y la depuración.

 2. Una lista de extensiones de servicio, donde cada extensión designa el tipo de servicio a extender y un procedimiento que, dados los parámetros del servicio, devuelve una lista de objetos para extender el servicio de dicho tipo.

     Cada tipo de servicio tiene al menos una extensión de servicio. La única excepción es el tipo de servicio de arranque, que es el último servicio.

 3. De manera opcional, un valor predeterminado para instancias de este tipo.

In this example, guix-service-type extends three services:

shepherd-root-service-type
     The guix-shepherd-service procedure defines how the Shepherd service is extended.  Namely, it returns a <shepherd-service> object that defines how guix-daemon is started and stopped (see Servicios de Shepherd).

account-service-type
     This extension for this service is computed by guix-accounts, which returns a list of user-group and user-account objects representing the build user accounts (see Invocación de guix-daemon).

activation-service-type
     Here guix-activation is a procedure that returns a gexp, which is a code snippet to run at ``activation time''---e.g., when the service is booted.

Un servicio de este tipo se puede instanciar de esta manera:

     (service guix-service-type
              (guix-configuration
                (build-accounts 5)
                (use-substitutes? #f)))

El segundo parámetro a la forma service es un valor que representa los parámetros de esta instancia específica del servicio. See guix-configuration, para información acerca del tipo de datos guix-configuration. Cuando se omite el valor, se usa el valor predeterminado por guix-service-type:

     (service guix-service-type)

guix-service-type is quite simple because it extends other services but is not extensible itself.

El tipo de servicio para un servicio extensible puede tener esta forma:

     (define udev-service-type
       (service-type (name 'udev)
                     (extensions
                      (list (service-extension shepherd-root-service-type
                                               udev-shepherd-service)))

                     (compose concatenate)       ;concatena la lista de reglas
                     (extend (lambda (config rules)
                               (match config
                                 (($ <udev-configuration> udev initial-rules)
                                  (udev-configuration
                                   (udev udev)   ;el paquete udev a usar
                                   (rules (append initial-rules rules)))))))))

This is the service type for the eudev device management daemon (https://wiki.gentoo.org/wiki/Project:Eudev).  Compared to the previous example, in addition to an extension of shepherd-root-service-type, we see two new fields:

compose
     Este es el procedimiento para componer la lista de extensiones en servicios de este tipo.

     Los servicios pueden extender el servicio udev proporcionandole una lista de reglas; componemos estas extensiones simplemente concatenandolas.

extend
     Este procedimiento define cómo el valor del servicio se extiende con la composición de la extensión.

     Las extensiones de udev se componen en una lista de reglas, pero el valor del servicio udev es en sí un registro <udev-configuration>. Por tanto aquí extendemos el registro agregando la lista de reglas que contiene al final de la lista de reglas que se contribuyeron.

description
     Es una cadena que proporciona una descripción del tipo de servicio. Dicha cadena puede contener lenguaje de marcado Texinfo (see Overview (GNU Texinfo)). La orden guix system search busca estas cadenas y las muestra (see Invocación de guix system).

There can be only one instance of an extensible service type such as udev-service-type.  If there were more, the service-extension specifications would be ambiguous.

¿Todavía aquí? La siguiente sección proporciona una referencia de la interfaz programática de los servicios.

Referencia de servicios
-----------------------

Ya hemos echado un vistazo a los tipos de servicio (see Tipos de servicios y servicios). Esta sección proporciona referencias sobre cómo manipular servicios y tipos de servicio. Esta interfaz se proporciona en el módulo (gnu services).

 -- Procedimiento Scheme: service TIPO [VALOR]
     Devuelve un nuevo servicio de TIPO, un objeto <service-type> (véase a continuación). VALOR puede ser cualquier objeto; represental los parámetros de esta instancia de servicio particular.

     Cuando se omite VALOR, se usa el valor predeterminado especificado por TIPO; si TYPE no especifica ningún valor, se produce un error.

     Por ejemplo, esto:

          (service openssh-service-type)

     es equivalente a esto:

          (service openssh-service-type
                   (openssh-configuration))

     En ambos casos el resultado es una instancia de openssh-service-type con la configuración predeterminada.

 -- Procedimiento Scheme: service? OBJ
     Devuelve verdadero si OBJ es un servicio.

 -- Procedimiento Scheme: service-kind SERVICIO
     Devuelve el tipo de SERVICIO---es decir, un objeto <service-type>.

 -- Procedimiento Scheme: service-value SERVICIO
     Devuelve el valor asociado con SERVICIO. Representa sus parámetros.

Este es un ejemplo de creación y manipulación de un servicio:

     (define s
       (service nginx-service-type
                (nginx-configuration
                 (nginx nginx)
                 (log-directory log-directory)
                 (run-directory run-directory)
                 (file config-file))))

     (service? s)
     => #t

     (eq? (service-kind s) nginx-service-type)
     => #t

The modify-services form provides a handy way to change the parameters of some of the services of a list such as %base-services (see %base-services).  It evaluates to a list of services.  Of course, you could always use standard list combinators such as map and fold to do that (see List Library (GNU Guile Reference Manual)); modify-services simply provides a more concise form for this common pattern.

 -- Sintaxis Scheme: modify-services SERVICIOS
     (TIPO VARIABLE => CUERPO) ...

     Modifica los servicios listados en SERVICIOS de acuerdo a las cláusulas proporcionadas. Cada cláusula tiene la forma:

          (TIPO VARIABLE => CUERPO)

     donde TIPO es un tipo de servicio---por ejemplo, guix-service-type---y VARIABLE es un identificador que se asocia dentro del CUERPO a los parámetros del servicio---por ejemplo, una instancia guix-configuration---del servicio original de dicho ŦIPO.

     El CUERPO deve evaluar a los nuevos parámetros del servicio, que serán usados para configurar el nuevo servicio. Este nuevo servicio reemplaza el original en la lista resultante. Debido a que los parámetros de servicio de un servicio se crean mediante el uso de define-record-type*, puede escribir un breve CUERPO que evalúe a los nuevos parámetros del servicio mediante el uso de la característica inherit que proporciona define-record-type* para heredar los valores antiguos.

     See Uso de la configuración del sistema, para ejemplos de uso.

A continuación se procede con la interfaz programática de los tipos de servicios. Es algo que debe conocer para escribir definiciones de nuevos servicios, pero no es cuando busque formas de personalizar su declaración operating-system.

 -- Tipo de datos: service-type
     Esta es la representación de un tipo de servicio (see Tipos de servicios y servicios).

     name
          Es un símbolo, usado únicamente para simplificar la inspección y la depuración.

     extensions
          Una lista no vacía de objetos <service-extension> (véase a continuación).

     compose (predeterminado: #f)
          Si es #f, entonces el tipo de servicio denota servicios que no pueden extenderse---es decir, servicios que no pueden recibir ``valores'' de otros servicios.

          En otro caso, debe ser un procedimiento de un único parámetro. El procedimiento es invocado en fold-services y se le proporciona una lista de valores recibidos de las extensiones. Puede devolver un valor único.

     extend (predeterminado: #f)
          Si es #f, los servicios de este tipo no pueden extenderse.

          En otro caso, debe ser un procedimiento que acepte dos parámetros: fold-services lo invoca, proporcionandole el valor inicial del servicio como el primer parámetro y el resultado de aplicar compose a los valores de las extensiones como segundo parámetro. Debe devolver un valor que es un parámetro válido para la instancia del servicio.

     See Tipos de servicios y servicios, para ejemplos.

 -- Procedimiento Scheme: service-extension TIPO-DESEADO
     CALCULA

     Devuelve una nueva extensión para servicios del tipo TIPO-DESEADO. CALCULA debe ser un procedimiento de un único parámetro: es llamado en fold-services, proporcionandole el valor asociado con el servicio que proporciona la extensión; debe devolver un valor válido para el servicio deseado.

 -- Procedimiento Scheme: service-extension? OBJ
     Devuelve verdadero si OBJ es una expresión-G.

De manera ocasional, puede desear simplemente extender un servicio existente. Esto implica la creación de un nuevo tipo de servicio y la especificación de la extensión deseada, lo cual puede ser engorroso; el procedimiento simple-service proporciona un atajo para ello.

 -- Procedimiento Scheme: simple-service NOMBRE DESEADO VALOR
     Devuelve un servicio que extiende DESEADO con VALOR. Esto funciona creando una instancia única del tipo de servicio NOMBRE, de la cual el servicio devuelto es una instancia.

     Por ejemplo, esto extiende mcron (see Ejecución de tareas programadas) con una tarea adicional:

          (simple-service 'mi-tarea-mcron mcron-service-type
                          #~(job '(next-hour (3)) "guix gc -F 2G"))

En el núcleo de la abstracción de los servicios se encuentra el procedimiento fold-services, que es responsable de la ``compilación'' de una lista de servicios en un único directorio que contiene todo lo necesario para arrancar y ejecutar el sistema---el directorio mostrado por la orden guix system build (see Invocación de guix system). En esencia, propaga las extensiones de servicios a través del grafo de servicios, actualizando los parámetros de cada nodo en el camino, hasta que alcanza el nodo raíz.

 -- Procedimiento Scheme: fold-services SERVICIOS
     [#:target-type SYSTEM-SERVICE-TYPE]
     Recorre SERVICIOS propagando sus extensiones hasta la raíz del tipo TARGET-TYPE; devuelve el servicio raíz tratado de la manera apropiada.

Por último, el módulo (gnu services) también define varios tipos esenciales de servicios, algunos de los cuales se enumeran a continuación.

 -- Variable Scheme: system-service-type
     Esta es la raíz del grafo de servicios. Produce el directorio del sistema como lo devuelve la orden guix system build.

 -- Variable Scheme: boot-service-type
     El tipo del ``servicio de arranque'', que produce un guión de arranque. El guión de arranque es lo que ejecuta el disco inicial de RAM cuando se arranca.

 -- Variable Scheme: etc-service-type
     El tipo del servicio /etc. Este servicio se usa para crear los ficheros en /etc y puede extenderse proporcionandole pares nombre/fichero como estas:

          (list `("issue" ,(plain-file "issue" "¡Bienvenida!\n")))

     En este ejemplo, el ejecto sería la adición de un fichero /etc/issue que apunta al fichero proporcionado.

 -- Variable Scheme: setuid-program-service-type
     Tipo para el ``servicio de programas setuid''. Este servicio recopila listas de nombres de ficheros ejecutables, proporcionados como expresiones-G, y los añade al conjunto de programas con setuid de root en el sistema (see Programas con setuid).

 -- Variable Scheme: profile-service-type
     Tipo del servicio que genera el perfil del sistema---es decir, los programas en /run/current-system/profile. Otros servicios pueden extenderlo proporcionandole listas de paquetes a añadir al perfil del sistema.

Servicios de Shepherd
---------------------

The (gnu services shepherd) module provides a way to define services managed by the GNU Shepherd, which is the initialization system---the first process that is started when the system boots, also known as PID 1 (see Introducción (The GNU Shepherd Manual)).

Los servicios en Shepherd pueden depender de otros servicios. Por ejemplo, el daemon SSH puede tener que arrancarse tras el arranque del daemon syslog, lo cual a su vez puede suceder únicamente tras el montaje de todos los sistemas de ficheros. El sistema operativo simple definido previamente (see Uso de la configuración del sistema) genera un grafo de servicios como este:

Grafo típico de servicios de shepherd.

En realidad puede generar dicho grafo para cualquier definición de sistema operativo mediante el uso de la orden guix system shepherd-graph (see guix system shepherd-graph).

The %shepherd-root-service is a service object representing PID 1, of type shepherd-root-service-type; it can be extended by passing it lists of <shepherd-service> objects.

 -- Tipo de datos: shepherd-service
     El tipo de datos que representa un servicio gestionado por Shepherd.

     provision
          Una lista de símbolos que indican lo que proporciona el servicio.

          Esto son nombres que pueden proporcionarse a herd start, herd status y órdenes similares (see Invoking herd (The GNU Shepherd Manual)). See the provides slot (The GNU Shepherd Manual), para más detalles.

     requirements (predeterminados: '())
          Lista de símbolos que indican los servicios Shepherd de los que este depende.

     one-shot? (predeterminado: #f)
          Whether this service is one-shot.  One-shot services stop immediately after their start action has completed.  See Slots of services (The GNU Shepherd Manual), for more info.

     respawn? (predeterminado: #t)
          Indica si se debe reiniciar el servicio cuando se para, por ejemplo cuando el proceso subyacente muere.

     start
     stop (predeterminado: #~(const #f))
          Los campos start y stop hacen referencia a las características de Shepherd de arranque y parada de procesos respectivamente (see Service De- and Constructors (The GNU Shepherd Manual)). Se proporcionan como expresiones-G que se expandirán en el fichero de configuración de Shepherd (see Expresiones-G).

     actions (predeterminadas: '())
          Esta es la lista de objetos shepherd-action (véase a continuación) que definen las acciones permitidas por el servicio, además de las acciones estándar start y stop. Las acciones que se listan aquí estarán disponibles como ordenes de herd:

               herd ACCIÓN SERVICIO [PARÁMETROS...]

     documentación
          Una cadena de documentación, que se mostrará al ejecutar:

               herd doc NOMBRE-DEL-SERVICIO

          where SERVICE-NAME is one of the symbols in provision (see Invoking herd (The GNU Shepherd Manual)).

     modules (default: %default-modules)
          Esta es la lista de módulos que deben estar dentro del ámbito cuando start y stop son evaluados.

 -- Tipo de datos: shepherd-action
     Este es el tipo de datos que define acciones adicionales implementadas por un servicio Shepherd (vea previamente).

     name
          Símbolo que nombra la acción.

     documentación
          Esta es una cadena de documentación para la acción. Puede verse ejecutando:

               herd doc SERVICIO action ACCIÓN

     procedure
          Debe ser una expresión-G que evalua a un procedimiento de al menos un parámetro, el cual es el ``valor de ejecución'' del servicio (see Slots of services (The GNU Shepherd Manual)).

     El siguiente ejemplo define una acción llamada di-hola que saluda amablemente a la usuaria:

          (shepherd-action
            (name 'di-hola)
            (documentation "¡Di hola!")
            (procedure #~(lambda (running . args)
                           (format #t "¡Hola, compa! parámetros: ~s\n"
                                   args)
                           #t)))

     Asumiendo que esta acción se añade al servicio ejemplo, puede ejecutar:

          # herd di-hola ejemplo
          ¡Hola, compa! parámetros: ()
          # herd di-hola ejemplo a b c
          ¡Hola, compa! parámetros: ("a" "b" "c")

     Esta, como puede ver, es una forma un tanto sofisticada de decir hola. See Service Convenience (The GNU Shepherd Manual), para más información sobre acciones.

 -- Variable Scheme: shepherd-root-service-type
     El tipo de servicio para el ``servicio raíz'' de Shepherd---es decir, PID 1.

     El tipo de servicio que las extensiones declaran cuando desean crear servicios shepherd (see Tipos de servicios y servicios, para un ejemplo). Cada extensión debe pasar una lista de <shepherd-service>.

 -- Variable Scheme: %shepherd-root-service
     Este servicio representa el PID 1.

Documentación
*************

En la mayor parte de casos, los paquetes instalados con Guix contienen documentación. Hay dos formatos principales de documentación: ``Info'', un formato hipertextual navegable usado para software GNU, y ``páginas de manual'' (o ``páginas man''), la documentación lineal encontrada tradicionalmente en Unix. Se accede a los manuales Info con la orden info o con Emacs, y las páginas man con man.

Puede buscar documentación de software instalado en su sistema por palabras clave. Por ejemplo, la siguiente orden busca información sobre ``TLS'' en manuales Info:

     $ info -k TLS
     "(emacs)Network Security" -- STARTTLS
     "(emacs)Network Security" -- TLS
     "(gnutls)Core TLS API" -- gnutls_certificate_set_verify_flags
     "(gnutls)Core TLS API" -- gnutls_certificate_set_verify_function
     ...

La orden siguiente busca por la misma palabra clave en páginas man:

     $ man -k TLS
     SSL (7)              - OpenSSL SSL/TLS library
     certtool (1)         - GnuTLS certificate tool
     ...{}

Estas búsquedas son completamente locales en su máquina de modo que tiene la garantía de que la documentación que encuentre corresponde con lo que está realmente instalado, puede acceder a ella sin conexión a la red, y se respeta su privacidad.

Una vez tenga estos resultados, puede ver la documentación relevante mediante la ejecución de, digamos:

     $ info "(gnutls)Core TLS API"

o:

     $ man certtool

Los manuales Info contienen secciones e índices, así como enlaces como aquellos encontrados en páginas Web. El lector info (see Info reader (Stand-alone GNU Info)) y su contraparte en Emacs (see Misc Help (The GNU Emacs Manual)) proporcionan combinaciones de teclas intuitivas para la navegación en los manuales. See Getting Started (Info: An Introduction), para una introducción a la navegación en Info.

Instalación de ficheros de depuración
*************************************

Los programas binarios, como los producidos por los compiladores GCC por ejemplo, se escriben típicamente en el formato ELF, con una sección que contiene información de depuración. La información de depuración es lo que permite que el depurador, GDB, asocie código binario a código fuente; es necesaria para depurar un programa compilado en condiciones adecuadas.

El problema con la información de depuración es que ocupa un espacio considerable en el disco. Por ejemplo, la información de depuración de la biblioteca C de GNU ocupa más de 60 MiB. Por tanto, como usuaria, mantener toda la información de depuración de todos los programas instalados no es habitualmente una opción. No obstante, el ahorro de espacio no debe ser impedir la depuración---especialmente en el sistema GNU, que debería facilitar a sus usuarias ejercitar su libertad de computación (see Distribución GNU).

Afortunadamente, las utilidades binarias GNU (Binutils) y GDB proporcionan un mecanismo que permite a las usuarias obtener lo mejor de ambos mundos: la información de depuración puede extraerse de los binarios y almacenarse en ficheros separados. GDB es capaz entonces de cargar la información de depuración desde esos ficheros, cuando estén disponibles (see Separate Debug Files (Debugging with GDB)).

La distribución GNU toma ventaja de este hecho almacenando la información de depuración en el subdirectorio lib/debug de una salida separada del paquete llamada debug (see Paquetes con múltiples salidas). Las usuarias pueden elegir si instalan la salida debug de un paquete cuando la necesitan. Por ejemplo, la siguiente orden instala la información de depuración para la biblioteca C de GNU y para GNU Guile.

     guix package -i glibc:debug guile:debug

Se debe decir entonces a GDB que busque los ficheros de depuración en el perfil de la usuaria, proporcionando un valor a la variable debug-file-directory (considere hacerlo en el fichero ~/.gdbinit, see Startup (Debugging with GDB)):

     (gdb) set debug-file-directory ~/.guix-profile/lib/debug

A partir de ese momento GDB obtendrá la información de depuración de los ficheros .debug bajo ~/.guix-profile/lib/debug.

Además, probablemente desee que GDB sea capaz de mostrar el código fuente que está depurando. Para hacerlo, tiene que desempaquetar el código fuente del paquete de su interés (obtenido con guix build --source, see Invocación de guix build) e indicar a GDB cual es el directorio de fuentes mediante el uso de la orden directory (see directory (Debugging with GDB)).

El mecanismo de la salida debug en Guix se implementa por el sistema de construcción gnu-build-system (see Sistemas de construcción). Ahora mismo necesita una activación explícita---la información de depuración está disponible únicamente para paquetes con definiciones que declaren explícitamente una salida debug. Esto puede cambiarse por una activación implícita en el futuro si nuestras granjas de construcción pueden soportar la carga. Para comprobar si un paquete tiene una salida debug, use guix package --list-available (see Invocación de guix package).

Actualizaciones de seguridad
****************************

De manera ocasional, vulnerabilidades importantes de seguridad se descubren en los paquetes de software y deben parchearse. Las desarrolladoras de Guix tratan de seguir las vulnerabilidades conocidas y aplicar parches tan pronto como sea posible en la rama master de Guix (todavía no proporcionamos una rama ``estable'' que contenga únicamente actualizaciones de seguridad). La herramienta guix lint ayuda a las desarrolladoras a encontrar versiones vulnerables de paquetes de software en la distribución:

     $ guix lint -c cve
     gnu/packages/base.scm:652:2: glibc@2.21: probably vulnerable to CVE-2015-1781, CVE-2015-7547
     gnu/packages/gcc.scm:334:2: gcc@4.9.3: probably vulnerable to CVE-2015-5276
     gnu/packages/image.scm:312:2: openjpeg@2.1.0: probably vulnerable to CVE-2016-1923, CVE-2016-1924
     ...

See Invocación de guix lint, para más información.

     En la versión VERSION, esta característica descrita a continuación se considera en estado ``beta''.

Guix sigue una disciplina funcional de gestión de paquetes (see Introducción), lo que implica que, cuando se cambia un paquete, todos los paquetes que dependen de él deben ser reconstruidos. Esto puede ralentizar de manera significativa el despliegue de correcciones en paquetes básicos como libc o Bash, ya que básicamente la distribución al completo debe reconstruirse. El uso de binarios preconstruidos ayuda (see Sustituciones), pero el despliegue aún puede tomar más tiempo del deseado.

Para afrontar esto, Guix implementa injertos, un mecanismo que permite un rápido despliegue de actualizaciones críticas sin los costes asociados con una reconstrucción completa de la distribución. La idea es reconstruir únicamente el paquete que hace falta parchear, y entonces ``injertarlo'' en los paquetes explícitamente instalados por la usuaria y que previamente hacían referencia al paquete original. El coste de realizar un injerto es menor que una reconstrucción completa de la cadena de dependencias.

For instance, suppose a security update needs to be applied to Bash.  Guix developers will provide a package definition for the ``fixed'' Bash, say bash-fixed, in the usual way (see Definición de paquetes).  Then, the original package definition is augmented with a replacement field pointing to the package containing the bug fix:

     (define bash
       (package
         (name "bash")
         ;; ...
         (replacement bash-fixed)))

From there on, any package depending directly or indirectly on Bash---as reported by guix gc --requisites (see Invocación de guix gc)---that is installed is automatically ``rewritten'' to refer to bash-fixed instead of bash.  This grafting process takes time proportional to the size of the package, usually less than a minute for an ``average'' package on a recent machine.  Grafting is recursive: when an indirect dependency requires grafting, then grafting ``propagates'' up to the package that the user is installing.

Currently, the length of the name and version of the graft and that of the package it replaces (bash-fixed and bash in the example above) must be equal.  This restriction mostly comes from the fact that grafting works by patching files, including binary files, directly.  Other restrictions may apply: for instance, when adding a graft to a package providing a shared library, the original shared library and its replacement must have the same SONAME and be binary-compatible.

La opción de línea de órdenes --no-grafts le permite anular voluntariamente el proceso de injerto (see --no-grafts). Por tanto, la orden:

     guix build bash --no-grafts

devuelve el nombre de fichero del almacén de la versión original de Bash, mientras que:

     guix build bash

devuelve el nombre de fichero del almacén de la versión ``corregida'', reemplazo de Bash. Esto le permite distinguir entre las dos variantes de Bash.

Para verificar a qué Bash hace referencia su perfil al completo, puede ejecutar (see Invocación de guix gc):

     guix gc -R `readlink -f ~/.guix-profile` | grep bash

... y compare los nombres de fichero del almacén que obtendrá con los ejemplos previos. Del mismo modo, para una generación completa del sistema Guix:

     guix gc -R `guix system build mi-configuracion.scm` | grep bash

Por último, para comprobar qué versión de Bash están usando los procesos en ejecución, puede usar la orden lsof:

     lsof | grep /gnu/store/.*bash

Lanzamiento inicial
*******************

El lanzamiento inicial en nuestro contexto hace referencia a cómo la distribución se construye ``de la nada''. Recuerde que el entorno de construcción de una derivación no contiene más que sus entradas declaradas (see Introducción). Por lo que hay un evidente problema ``del huevo y la gallina'': ¿cómo se construye el primer paquete? ¿Cómo se compila el primer compilador? Fíjese que esta es una cuestión de interés únicamente para la hacker curiosa, no para la usuaria normal, así que puede pasar por encima está sección sin ninguna vergüenza si se considera una ``usuaria normal''.

El sistema GNU está compuesto principalmente de código C, con libc en su base. El sistema de construcción GNU en sí asume la disponibilidad del shell Bourne y las herramientas de línea de órdenes proporcionadas por GNU Coreutils, Awk, Findutils, `sed' y `grep'. Además, los programas de construcción---programas que ejecutan ./configure, make, etc.---están escritos en Scheme Guile (see Derivaciones). Consecuentemente, para ser capaz de construir cualquier cosa, desde cero, Guix depende en binarios preconstruidos de Guile, GCC, Binutils, libc y otros paquetes mencionados anteriormente---los binarios del lanzamiento inicial.

Estos binarios del lanzamiento inicial se ``dan por supuestos'', aunque se pueden volver a crear si se necesita (más sobre esto más adelante).

Preparación para usar los binarios del lanzamiento inicial
==========================================================

Grafo de dependencias de las derivaciones del lanzamiento inicial temprano

La figura previa muestra el auténtico inicio del grafo de dependencias de la distribución, correspondiente a las definiciones de paquete del módulo (gnu packages bootstrap). Un gráfico similar puede generarse con guix graph (see Invocación de guix graph), más o menos así:

     guix graph -t derivation \
       -e '(@@ (gnu packages bootstrap) %bootstrap-gcc)' \
       | dot -Tps > t.ps

En este nivel de detalle, las cosas son ligeramente complejas. Primero, Guile en sí consiste en un ejecutable ELF, junto a muchas fuentes y ficheros compilados Scheme que se cargan dinámicamente durante la ejecución. Esto se almacena en el archivador tar guile-2.0.7.tar.xz mostrado en este grafo. Este archivador es parte de la distribución de ``fuentes'' de Guix, y se inserta en el almacén con add-to-store (see El almacén).

¿Pero cómo escribimos una derivación que extraiga este archivador y lo añada al almacén? Para resolver este problema, la derivación guile-bootstrap-2.0.drv---la primera en construirse---usa bash como su constructor, que ejecuta build-bootstrap-guile.sh, que a su vez llama a tar para extraer el archivador. Por tanto, bash, tar, xz y mkdir son binarios enlazados estáticamente, también parte de la distribución de fuentes de Guix, cuyo único propósito es permitir la extracción del archivador de Guile.

Una vez queguile-bootstrap-2.0.drv se ha construido, tenemos un Guile funcional que se puede usar para ejecutar los programas de construcción siguientes. Su primera tarea es descargar los archivadores qu contienen los otros binarios preconstruidos---esto es lo que las derivaciones .tar.xz.drv hacen. Módulos Guix como ftp-client.scm se usan para este propósito. Las derivaciones module-import.drv importan esos módulos en un directorio del almacén, manteniendo la distribución de carpetas. Las derivaciones module-import-compiled.drv compilan esos módulos, y los escriben en un directorio con la distribución de carpetas correcta. Esto corresponde al parámetro #:modules de build-expression->derivation (see Derivaciones).

Finalmente, los archivadores tar son extraídos por las derivaciones gcc-bootstrap-0.drv, glibc-bootstrap-0.drv, etcétera, hasta el punto en el que disponemos de una cadena de herramientas C funcional.

Construcción de las herramientas de construcción
================================================

El lanzamiento inicial está completo cuando tenemos una cadena de herramientas completa que no depende en las herramientas preconstruidas del lanzamiento inicial descritas previamente. Este requisito de no-dependencia se verifica comprobando si los ficheros de la cadena de herramientas final contienen referencias a directorios de /gnu/store de las entradas del lanzamiento. El proceso que lleva a esta cadena de herramientas ``final'' es descrito por las definiciones de paquetes encontradas en el módulo (gnu packages commencement).

La orden guix graph nos permite ``distanciarnos'' en comparación con el grafo previo, mirando al nivel de objetos de paquetes en vez de derivaciones individuales---recuerde que un paquete puede traducirse en varias derivaciones, típicamente una derivación para descargar sus fuentes, una para construir los módulos Guile que necesita y uno para realmente construir el paquete de las fuentes. La orden:

     guix graph -t bag \
       -e '(@@ (gnu packages commencement)
               glibc-final-with-bootstrap-bash)' | dot -Tps > t.ps

produce el grafo de dependencias que lleva a la biblioteca C ``final'' (Puede haberse dado cuenta de la etiqueta glibc-intermediate, sugiriendo que no es completamente final, pero como es una buena aproximación, la consideraremos final), mostrado a continuación.

Grafo de dependencias de los primeros paquetes

La primera herramienta que se construye con los binarios del lanzamiento inicial es GNU Make---marcado como make-boot0 en el grafo---, que es un pre-requisito para todos los paquetes siguientes. Una vez hecho se construyen Findutils y Diffutils.

Después viene la primera fase de Binutils y GCC, construidas como herramientas pseudo-cruzadas---es decir, con --target igual a --host. Se usan para construir libc. Gracias a este truco de compilación cruzada, se garantiza que esta libc no tendrá ninguna referencia a la cadena de herramientas inicial.

Posteriormente se construyen las herramientas Binutils y GCC (no mostradas previamente) finales, y enlazan los programas contra la libc recién construía. Esta cadena de herramientas se usa para construir otros paquetes usados por Guix y el sistema de construcción GNU: Guile, Bash, Coreutils, etc.

¡Y voilà! En este punto tenemos un conjunto completo de herramientas de construcción esperadas por el sistema de construcción GNU. Están en la variable %final-inputs del módulo (gnu packages commencement), y se usan implícitamente por cualquier paquete que use gnu-build-system (see gnu-build-system).

Construir los binarios de lanzamiento
=====================================

Debido a que la cadena de herramientas final no depende de los binarios de lanzamiento, estos rara vez necesitan ser actualizados. No obstante, es útil tener una forma automatizada de producirlos en caso de que se dé una actualización, y esto es lo que proporciona el módulo (gnu packages make-bootstrap).

La siguiente orden construye los archivadores que contienen los binarios de lanzamiento (Guile, Binutils, GCC, libc, y un archivador que contiene una mezcla de Coreutils y otras herramientas básicas de línea de órdenes):

     guix build bootstrap-tarballs

Los archivadores generados son aquellos que son referenciados en el módulo (gnu packages bootstrap) mencionado al inicio de esta sección.

¿Todavía aquí? Entonces quizá se habrá empezado a preguntar: ¿cuándo llegamos a un punto fijo? ¡Esa es una pregunta interesante! La respuesta es desconocida, pero si pudiese investigar más a fondo (y tiene unos recursos computacionales y de almacenamiento significativos para hacerlo) háganoslo saber.

Reducción del conjunto de binarios de lanzamiento
=================================================

Nuestros binarios de lanzamiento actualmente incluyen GCC, Guile, etc. ¡Eso es un montón de código binario! ¿Por qué es eso un problema? Es un problema porque esos chorros de código binario no son auditables en la práctica, lo que hace difícil establecer qué código fuente los produjo. Cada binario no-auditable también nos deja vulnerables a puertas traseras en los compiladores, como describió Ken Thompson en su publicación de 1984 Reflections on Trusting Trust.

Esto se mitiga por el hecho de que nuestros binarios de lanzamiento fueron generados por una revisión anterior de Guix. No obstante, esto no posee el nivel de transparencia que obtenemos en el resto del grado de dependencias de los paquetes, donde Guix siempre nos da una asociación de fuente-a-binario. Por lo tanto, nuestro objetivo es reducir el conjunto de binarios de lanzamiento al mínimo posible.

El sitio web Bootstrappable.org (http://bootstrappable.org) enumera proyectos en activo realizándolo. Uno de ellos está a punto de sustituir el GCC de lanzamiento con una secuencia de ensambladores, interpretes y compiladores de complejidad incremental, que pueden ser construidos desde las fuentes empezando con un código ensamblador simple y auditable. ¡Su ayuda es bienvenida!

Transportar a una nueva plataforma
**********************************

Como se explicó previamente, la distribución GNU es autocontenida, lo cual se consigue dependiendo de unos ``binarios del lanzamiento inicial'' preconstruidos (see Lanzamiento inicial). Estos binarios son específicos para un núcleo del sistema operativo, arquitectura de la CPU e interfaz binaria de aplicaciones (ABI). Por tanto, para transportar la distribución a una nueva plataforma que no está soportada todavía, se deben construir estos binarios del lanzamiento inicial, y actualizar el módulo (gnu packages bootstrap) para usarlos en dicha plataforma.

Por suerte, Guix puede compilar de forma cruzada esos binarios del lanzamiento inicial. Cuando todo va bien, y asumiendo que la cadena de herramientas GNU soporta para la plataforma deseada, esto puede ser tan simple como ejecutar una orden así:

     guix build --target=armv5tel-linux-gnueabi bootstrap-tarballs

Para que esto funcione, el procedimiento glibc-dynamic-linker en (gnu packages bootstrap) debe aumentarse para devolver el nombre de fichero correcto para el enlazador dinámico de libc en dicha plataforma; de igual manera, system->linux-architecture en (gnu packages linux) debe modificarse para la nueva plataforma.

Una vez construidos, el módulo (gnu packages bootstrap) debe ser actualizado para hacer referencia a estos binarios en la plataforma deseada. Esto es, los hash y las URL de los archivadores del lanzamiento inicial de la nueva plataforma deben añadirse junto a aquellos de las plataformas disponibles actualmente. El archivador tar del Guile usado para el lanzamiento inicial se trata de forma especial: se espera que esté disponible localmente, y gnu/local.mk tiene reglas que lo descargan para las arquitecturas disponibles; se debe añadir una regla para la nueva plataforma también.

En la práctica puede haber algunas complicaciones. Primero, puede ser que la tripleta extendida GNU que especifica un ABI (como el sufijo eabi previamente) no es reconocida por todas las herramientas GNU. Típicamente, glibc reconoce algunas de ellas, mientras que GCC usa una opción de configuración extra --with-abi (vea gcc.scm para ejemplos de como manejar este caso). En segundo lugar, algunos de los paquetes necesarios pueden fallar en su construcción para dicha plataforma. Por último, los binarios generados pueden estar defectuosos por alguna razón.

     [file contributing.es.texi not included]

Reconocimientos
***************

Guix está basado en el gestor de paquetes Nix (http://nixops.org/nix), que fue diseñado e implementado por Eelco Dolstra, con contribuciones de otra gente (véase el fichero nix/AUTHORS en Guix). Nix fue pionero en la gestión de paquetes funcional, y promovió características sin precedentes, como las actualizaciones de paquetes transaccionales y vuelta atrás, perfiles por usuaria y un proceso de compilación referencialmente transparente. Sin este trabajo, Guix no existiría.

Las distribuciones de software basadas en Nix, Nixpkgs y NixOS, también han sido una inspiración para Guix.

GNU Guix en sí es un trabajo colectivo con contribuciones de un número de gente. Mire el fichero AUTHORS en Guix para más información sobre esa gente maja. El fichero THANKS enumera personas que han ayudado informando de errores, haciendose cargo de la infraestructura, proporcionando arte y temas, haciendo sugerencias, y más---¡gracias!

Licencia de documentación libre GNU
***********************************

     [file fdl-1.3.texi not included]