Results of 1 - 1 of about 98 for keyserver (0.004 sec.)
- guix.es.txt
- #score: 12976
- @digest: d479a2ca96d9bac402e486639a443108
- @id: 73886
- @mdate: 2019-05-01T21:31:17Z
- @size: 1312298
- @type: text/plain
- #keywords: invocacion (149271), construccion (130424), sustituciones (116768), instalacion (100665), almacen (96427), paquetes (95541), usuarias (76072), perfil (73159), usuaria (72340), generaciones (69660), construcciones (68374), ficheros (67306), ‘-- (58507), ‘/ (56150), paquete (55122), configuracion (52165), derivacion (51041), basura (48686), maquina (47121), servicios (42856), orden (41737), entorno (40099), guix (38982), fichero (38854), sistema (36109), arranque (33268), distribucion (32089), herramientas (31140), imagen (30076), maquinas (29792), ejemplo (29490), opcion (28147)
- GNU Guix 1 Introducción 1.1 La forma de gestión de software de Guix 1.2 Distribución GNU 2 Instalación 2.1 Instalación binaria 2.2 Requisitos 2.3 Ejecución de la batería de pruebas 2.4 Preparación del daemon 2.4.1 Configuración del entorno de construcción 2.4.2 Uso de la facilidad de descarga de trabajo 2.4.3 Soporte de SELinux 2.4.3.1 Instalación de la política de SELinux 2.4.3.2 Limitaciones 2.5 Invocación de ‘guix-daemon' 2.6 Configuración de la aplicación 2.6.1 Localizaciones 2.6.2 Selector de servicios de nombres 2.6.3 Tipografías X11 2.6.4 Certificados X.509 2.6.5 Paquetes Emacs 2.6.6 La cadena de herramientas de GCC 3 Instalación del sistema 3.1 Limitaciones 3.2 Consideraciones sobre el hardware 3.3 Instalación desde memoria USB y DVD Copiado en una memoria USB Grabación en un DVD Arranque 3.4 Preparación para la instalación 3.5 Instalación gráfica guiada 3.6 Instalación manual 3.6.1 Distribución de teclado, red y particionado 3.6.1.1 Distribución de teclado 3.6.1.2 Red 3.6.1.3 Particionado de discos 3.6.2 Procedimiento de instalación 3.7 Tras la instalación del sistema 3.8 Instalación de Guix en una máquina virtual 3.9 Construcción de la imagen de instalación 3.10 Construcción de la imagen de instalación para placas ARM 4 Gestión de paquetes 4.1 Características 4.2 Invocación de ‘guix package' 4.3 Sustituciones 4.3.1 Servidor oficial de sustituciones. 4.3.2 Autorización de servidores de sustituciones 4.3.3 Verificación de sustituciones 4.3.4 Configuración de la pasarela. 4.3.5 Fallos en las sustituciones 4.3.6 Sobre la confianza en binarios 4.4 Paquetes con múltiples salidas 4.5 Invocación de ‘guix gc' 4.6 Invocación de ‘guix pull' 4.7 Canales 4.7.1 Uso de un canal de Guix personalizado 4.7.2 Especificación de canales adicionales 4.7.3 Declaración de dependencias de canales 4.7.4 Replicación de Guix 4.8 Inferiores 4.9 Invocación de ‘guix describe' 4.10 Invocación de ‘guix archive' 5 Desarrollo 5.1 Invocación de ‘guix environment' 5.2 Invocación de ‘guix pack' 6 Interfaz programática 6.1 Módulos de paquetes 6.2 Definición de paquetes 6.2.1 Referencia de ‘package' 6.2.2 Referencia de ‘origin' 6.3 Sistemas de construcción 6.4 El almacén 6.5 Derivaciones 6.6 La mónada del almacén 6.7 Expresiones-G 6.8 Invocación de ‘guix repl' 7 Utilidades 7.1 Invocación de ‘guix build' 7.1.1 Opciones comunes de construcción 7.1.2 Opciones de transformación de paquetes 7.1.3 Opciones de construcción adicionales 7.1.4 Depuración de fallos de construcción 7.2 Invocación de ‘guix edit' 7.3 Invocación de ‘guix download' 7.4 Invocación de ‘guix hash' 7.5 Invocación de ‘guix import' 7.6 Invocación de ‘guix refresh' 7.7 Invocación de ‘guix lint' 7.8 Invocación de ‘guix size' 7.9 Invocación de ‘guix graph' 7.10 Invocación de ‘guix publish' 7.11 Invocación de ‘guix challenge' 7.12 Invocación de ‘guix copy' 7.13 Invocación de ‘guix container' 7.14 Invocación de ‘guix weather' 7.15 Invocación de ‘guix processes' 8 Configuración del sistema 8.1 Uso de la configuración del sistema Cargador de arranque Paquetes visibles globalmente Servicios del sistema Instanciación del sistema La interfaz programática 8.2 Referencia de ‘operating-system' 8.3 Sistemas de ficheros 8.4 Dispositivos traducidos 8.5 Cuentas de usuaria 8.6 Distribución de teclado 8.7 Localizaciones 8.7.1 Consideraciones sobre la compatibilidad de datos de localización 8.8 Servicios 8.8.1 Servicios base 8.8.2 Ejecución de tareas programadas 8.8.3 Rotación del registro de mensajes 8.8.4 Servicios de red 8.8.5 Sistema X Window 8.8.6 Servicios de impresión 8.8.7 Servicios de escritorio 8.8.8 Servicios de sonido 8.8.9 Servicios de bases de datos 8.8.10 Servicios de correo 8.8.11 Servicios de mensajería 8.8.12 Servicios de telefonía 8.8.13 Servicios de monitorización 8.8.14 Servicios Kerberos 8.8.15 Servicios LDAP 8.8.16 Servicios Web 8.8.17 Servicios de certificados 8.8.18 Servicios DNS 8.8.19 Servicios VPN 8.8.20 Sistema de ficheros en red 8.8.21 Integración continua 8.8.22 Servicios de gestión de energía 8.8.23 Servicios de audio 8.8.24 Servicios de virtualización 8.8.25 Servicios de control de versiones 8.8.26 Servicios de juegos 8.8.27 Servicios misceláneos 8.8.28 Servicios de diccionario 8.9 Programas con setuid 8.10 Certificados X.509 8.11 Selector de servicios de nombres 8.12 Disco en RAM inicial 8.13 Configuración del gestor de arranque 8.14 Invocación de ‘guix system' 8.15 Ejecución de Guix en una máquina virtual 8.15.1 Conexión a través de SSH 8.15.2 Uso de ‘virt-viewer' con Spice 8.16 Definición de servicios 8.16.1 Composición de servicios 8.16.2 Tipos de servicios y servicios 8.16.3 Referencia de servicios 8.16.4 Servicios de Shepherd 9 Documentación 10 Instalación de ficheros de depuración 11 Actualizaciones de seguridad 12 Lanzamiento inicial Preparación para usar los binarios del lanzamiento inicial Construcción de las herramientas de construcción Construir los binarios de lanzamiento Reducción del conjunto de binarios de lanzamiento 13 Transportar a una nueva plataforma 14 Contribuir 14.1 Construcción desde Git 14.2 Ejecución de Guix antes de estar instalado 14.3 La configuración perfecta 14.4 Guías de empaquetamiento 14.4.1 Libertad del software 14.4.2 Nombrado de paquetes 14.4.3 Versiones numéricas 14.4.4 Sinopsis y descripciones 14.4.5 Módulos Python 14.4.5.1 Especificación de dependencias 14.4.6 Módulos Perl 14.4.7 Paquetes Java 14.4.8 Tipografías 14.5 Estilo de codificación 14.5.1 Paradigma de programación 14.5.2 Módulos 14.5.3 Tipos de datos y reconocimiento de patrones 14.5.4 Formato del código 14.6 Envío de parches Envío de una serie de parches 15 Reconocimientos Apéndice A Licencia de documentación libre GNU Índice de conceptos Índice programático GNU Guix ******** Este documento describe GNU Guix versión 1.0.0, una herramienta funcional de gestión de paquetes escrita para el sistema GNU. Este manual también está disponible en chino simplificado (*note (guix.zh_CN)Top::), francés (*note (guix.fr)Top::), alemán (*note (guix.de)Top::) e inglés (*note (guix)Top::). Si desea traducirlo en su lengua nativa, considere unirse al Translation Project (https://translationproject.org/domain/guix-manual.html). Actualmente este manual no está completamente traducido y varias secciones de servicios prácticamente se encuentran al completo en inglés. En versiones posteriores se irá completando la traducción, a la vez que adaptando la evolución de su fuente original en inglés. Si encuentra fallos en esta traducción le rogamos que nos lo comunique mediante la información de contacto del equipo de traducción (https://translationproject.org/team/es.html). 1 Introducción ************** GNU Guix(1) 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 (*note Instalación::), o puede usarse como un sistema operativo en sí mismo, el “sistema Guix”(2). *Note Distribución GNU::. ---------- Footnotes ---------- (1) «Guix» se pronuncia tal y como se escribe en castellano, «ɡiːks» en el alfabeto fonético internacional (IPA). (2) 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! 1.1 La forma de gestión de software de Guix =========================================== Guix proporciona una interfaz de gestión de paquetes de línea de ordenes (*note Gestión de paquetes::), un conjunto de utilidades de línea de órdenes (*note Utilidades::), así como interfaces programáticas Scheme (*note Interfaz programática::). Su “daemon de construcción” es responsable de la construcción de paquetes en delegación de las usuarias (*note Preparación del daemon::) y de la descarga de binarios preconstruidos de fuentes autorizadas (*note 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 (*note Definición de paquetes::) y hacerlas disponibles como módulos independientes de paquetes (*note 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 (*note 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 (*note 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” (*note 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 (*note Características::). 1.2 Distribución GNU ==================== Guix viene con una distribución del sistema GNU consistente en su totalidad de software libre(1). La distribución puede instalarse independientemente (*note Instalación del sistema::), pero también es posible instalar Guix como un gestor de paquetes sobre un sistema GNU/Linux existente (*note 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' (*note 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. *Note 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 (*note Configuración del sistema::). El sistema Guix usa el núcleo Linux-libre, el sistema de inicialización Shepherd (*note (shepherd)Introducción::), 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, *note Transportar::. La construcción de esta distribución es un esfuerzo cooperativo, ¡y esta invitada a unirse! *Note Contribuir::, para información sobre cómo puede ayudar. ---------- Footnotes ---------- (1) 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). 2 Instalación ************* Nota: 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”.(1) 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' (*note 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. ---------- Footnotes ---------- (1) 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, *note Instalación del sistema::. 2.1 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. Nota: We recommend the use of this shell installer script (https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh). The script automates the download, installation, and initial configuration steps described below. It should be run as the root user. La instalación consiste más o menos en los siguientes pasos: 1. Download the binary tarball from ‘https://ftp.gnu.org/gnu/guix/guix-binary-1.0.0.SYSTEM.tar.xz', where SYSTEM is ‘x86_64-linux' for an ‘x86_64' machine already running the kernel Linux, and so on. Asegurese de descargar el fichero ‘.sig' asociado y de verificar la autenticidad del archivador con él, más o menos así: $ wget https://ftp.gnu.org/gnu/guix/guix-binary-1.0.0.SYSTEM.tar.xz.sig $ gpg --verify guix-binary-1.0.0.SYSTEM.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-1.0.0.SISTEMA.tar.xz # mv var/guix /var/ && mv gnu / Esto crea ‘/gnu/store' (*note 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 (*note 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 (*note 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 (*note (texinfo)Other Info Directories::, para más detalles sobre cómo cambiar la ruta de búsqueda de Info). 7. Para usar sustituciones de ‘ci.guix.gnu.org' o uno de sus espejos (*note Sustituciones::), debe autorizarlas: # guix archive --authorize < \ ~root/.config/guix/current/share/guix/ci.guix.gnu.org.pub 8. Cada usuaria puede necesitar dar algunos pasos adicionales para prepar su entorno de Guix para el uso, *note 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 install hello 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 *Note Invocación de guix pack::, para más información sobre esta útil herramienta. 2.2 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 (*note how to install the GnuTLS bindings for Guile: (gnutls-guile)Guile Preparations.); • 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 (*note Configuración de delegación del daemon::) y de ‘guix copy' (*note 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' (*note ‘localstatedir': (standards)Directory Variables.). 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 (*note 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. 2.3 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 (*note 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 (*note 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. 2.4 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 *note Sustituciones::, para información sobre cómo permitir al daemon descargar binarios pre-construidos. 2.4.1 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 (*note 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' (*note ‘--max-jobs': Invocación de guix-daemon.). 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' (*note Invocación de guix system::). El programa ‘guix-daemon' puede ser ejecutado entonces como ‘root' con la siguiente orden(1): # 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(2); • 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 (*note Derivaciones::) o para sustituciones (*note 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_. ---------- Footnotes ---------- (1) 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'. (2) «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. 2.4.2 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 “procedimiento de extensión de construcción” ‘offload'(1). 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 procedimiento de extensión ‘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 (*note Guile-Avahi: (guile-avahi)Introducción.). 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' (*note (lsh)Converting keys::): $ 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 (*note 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 ---------- Footnotes ---------- (1) Esta característica está únicamente disponible cuando Guile-SSH (https://github.com/artyom-potsov/guile-ssh) está presente. 2.4.3 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. 2.4.3.1 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. 2.4.3.2 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 adicionales, 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. 2.5 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, *note 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 (*note derivación: Interfaz programática.), 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 (*note 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' (*note ‘--keep-failed': Invocación de guix build.). 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. *Note 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 (*note build users: Preparación del daemon.). ‘--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 (*note 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' (*note 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.gnu.org'. Esto significa que las sustituciones puede ser descargadas de URLS, mientras estén firmadas por una firma de confianza (*note Sustituciones::). ‘--no-build-hook' No usa el “procedimiento de extensión de construcción”. El procedimiento de extensión 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 (*note 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é. *Note 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' (*note 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 (*note 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 (*note ‘--max-silent-time': Opciones comunes de construcción.). ‘--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 (*note ‘--timeout': Opciones comunes de construcción.). ‘--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' (*note 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' (*note 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. *Note 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' Espera 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' Espera conexiones en el socket de dominio Unix ‘/gnu/var/daemon', creandolo si es necesario. ‘--listen=localhost' Espera conexiones TCP en la interfaz de red correspondiente a ‘localhost', en el puerto 44146. ‘--listen=128.0.0.42:1234' Espera 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' (*note ‘GUIX_DAEMON_SOCKET': El almacén.). Nota: 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'. 2.6 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. 2.6.1 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 install 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' (*note ‘LOCPATH': (libc)Locale Names.). 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. 2.6.2 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 (*note (libc)Selector de servicios de nombres::). 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 (*note (libc)NSS Configuration File::). 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. 2.6.3 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 (*note Paquetes con múltiples salidas::). Por ejemplo, la siguiente orden instala tipografías para lenguas chinas: guix install 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'. 2.6.4 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. *Note Certificados X.509::, para información detallada. 2.6.5 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 (*note (emacs)Package Files::). 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' (*note (emacs)Init File::). 2.6.6 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'. 3 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, *note Instalación::. Nota: 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: *note Info reader: (info-stnd)Top. Presione después ‘l' para volver aquí. De manera alternativa, ejecute ‘info info' en otro terminal para mantener el manual disponible. 3.1 Limitaciones ================ Consideramos que el sistema Guix está listo para un amplio rango de casos de uso, tanto de servidor como de escritorio. Las garantías que proporciona—actualizaciones transaccionales y vuelta atrás atómica, reproducibilidad—lo convierten en un cimiento sólido. No obstante, antes de que proceda con la instalación, sea consciente de las siguientes limitaciones apreciables que se conocen en la versión 1.0.0: • No está implementada la funcionalidad del gestor de volúmenes lógicos (LVM). • Se proporcionan más y más servicios del sistema (*note Servicios::), pero pueden faltar algunos. • Están disponibles GNOME, Xfce, LXDE y Enlightenment (*note Servicios de escritorio::), así como un número de gestores de ventanas X11. No obstante, actualmente falta KDE. Más que una descarga de responsabilidades es una invitación a informar de problemas (¡e historias satisfactorias!), y para unirse a nosotras en su mejora. *Note Contribuir::, para más información. 3.2 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. Una de las áreas principales donde faltan controladores o firmware libre son los dispositivos WiFi. Los dispositivos WiFi que se sabe que funcionan incluyen aquellos que usan los chips Atheros (AR9271 y AR7010), que corresponden al controlador ‘ath9k' de Linux-libre, y aquellos que usan los chips Broadcom/AirForce (BCM43xx con Wireless-Core Revisión 5), que corresponden al controlador ‘b43-open' de Linux-libre. Existe firmware libre para ambos, y está disponible por defecto en el sistema Guix, como parte de ‘%base-firmware' (*note ‘firmware': Referencia de «operating-system».). 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. 3.3 Instalación desde memoria USB y DVD ======================================= An ISO-9660 installation image that can be written to a USB stick or burnt to a DVD can be downloaded from ‘https://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.SYSTEM.iso.xz', where SYSTEM is one of: ‘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://ftp.gnu.org/gnu/guix/guix-system-install-1.0.0.SYSTEM.iso.xz.sig $ gpg --verify guix-system-install-1.0.0.SYSTEM.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-1.0.0.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-1.0.0.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-1.0.0.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-1.0.0.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. *Note 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). 3.4 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 (*note 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” (*note 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 (*note (info-stnd)Top::). 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. Nota: 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. 3.5 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 (*note 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. ¡*Note Tras la instalación del sistema:: para ver cómo proceder a continuación! 3.6 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 (*note 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' (*note Invocación de guix package::). 3.6.1 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. 3.6.1.1 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. 3.6.1.2 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. 3.6.1.3 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 (*note (parted)Overview::), ‘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 (*note (grub)BIOS installation::). 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 Nota: ¿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'. *Note 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(1). 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' (*note 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 (*note swap space: (libc)Memory Concepts.), 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(2): # 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. ---------- Footnotes ---------- (1) 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. (2) 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'. 3.6.2 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 (*note (nano)Top::), 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. *Note 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 (*note 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, *note 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 (*note contraseñas de cuentas de usuaria: user-account-password.). ¡*Note Tras la instalación del sistema:: para proceder a continuación! 3.7 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 (*note Invocación de guix system::). Recomendamos realizarlo de manera regular de modo que su sistema incluya las últimas actualizaciones de seguridad (*note Actualizaciones de seguridad::). Nota: 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! 3.8 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 (*note 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-1.0.0.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. *Note 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'. *Note Ejecutar Guix en una máquina virtual::, para información sobre cómo hacerlo. 3.9 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 *note Invocación de guix system:: para más información acerca de la imagen de instalación. 3.10 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. 4 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 (*note ‘guix package': Invocación de guix package, también puede usar la interfaz Emacs-Guix (*note (emacs-guix)Top::), tras la instalación del paquete ‘emacs-guix' (ejecute la orden ‘M-x guix-help' para iniciarse en su uso): guix install emacs-guix 4.1 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 (*note 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 (*note 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 (*note 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 (*note 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 (*note container: Invocación de guix-daemon.). 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 (*note 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 (*note 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 (*note 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 (*note 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. 4.2 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 (*note 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 For your convenience, we also provide the following aliases: • ‘guix search' is an alias for ‘guix package -s', • ‘guix install' is an alias for ‘guix package -i', • ‘guix remove' is an alias for ‘guix package -r', • and ‘guix upgrade' is an alias for ‘guix package -u'. These aliases are less expressive than ‘guix package' and provide fewer options, so in some cases you'll probably want to use ‘guix package' directly. ‘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' (*note ‘--manifest': profile-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. If you are not using Guix System, consider adding the following lines to your ‘~/.bash_profile' (*note (bash)Bash Startup Files::) so that newly-spawned shells get all the right environment variable definitions: 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' (*note 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' (*note 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 (*note Módulos de paquetes::). A veces los paquetes tienen “entradas propagadas”: estas son las dependencias que se instalan automáticamente junto al paquete requerido (*note ‘propagated-inputs' in ‘package' objects: package-propagated-inputs, 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 (*note Definición de paquetes::): (use-modules (guix) (guix build-system gnu) (guix licenses)) (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) (synopsis "Hello, GNU world: An example GNU package") (description "Guess what GNU Hello prints!") (home-page "http://www.gnu.org/software/hello/") (license gpl3+)) 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 (*note 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' (*note 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 (*note (gcc)Environment Variables::). 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' (*note GNU recutils databases: (recutils)Top.). 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 ... It is also possible to refine search results using several ‘-s' flags to ‘guix package', or several arguments to ‘guix search'. For example, the following command returns a list of board games (this time using the ‘guix search' alias): $ guix search '\<board\>' 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 search crypto library | \ recsel -e '! (name ~ "^(ghc|perl|python|ruby)")' -p name,synopsis *Note (recutils)Selection Expressions::, 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' (*note GNU recutils databases: (recutils)Top.). $ 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 (*note 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 (*note 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 (*note 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 (*note Opciones comunes de construcción::). También acepta opciones de transformación de paquetes, como ‘--with-source' (*note 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' (*note Definición de paquetes::). 4.3 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 (*note 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. 4.3.1 Servidor oficial de sustituciones. ---------------------------------------- El servidor ‘ci.guix.gnu.org' 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' (*note ‘guix-daemon --substitute-urls': daemon-substitute-urls.) o bien a herramientas cliente como ‘guix package' (*note client ‘--substitute-urls' option: client-substitute-urls.). 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. Substitutes from the official build farm are enabled by default when using Guix System (*note Distribución GNU::). However, they are disabled by default when using Guix on a foreign distribution, unless you have explicitly enabled them via one of the recommended installation steps (*note Instalación::). The following paragraphs describe how to enable or disable substitutes for the official build farm; the same procedure can also be used to enable substitutes for any other substitute server. 4.3.2 Autorización de servidores de sustituciones ------------------------------------------------- Para permitir a Guix descargar sustituciones de ‘ci.guix.gnu.org' 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' (*note Invocación de guix archive::). Hacerlo implica que confía que ‘ci.guix.gnu.org' no ha sido comprometido y proporciona sustituciones genuinas. La clave pública para ‘ci.guix.gnu.org' se instala junto a Guix, en ‘PREFIJO/share/guix/ci.guix.gnu.org.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-1.0.0.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.gnu.org.pub Nota: 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.gnu.org' 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' (*note 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. 4.3.3 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). 4.3.4 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_. 4.3.5 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' (*note common build option ‘--fallback': fallback-option.). 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' (*note Invocación de guix weather::). Esta orden proporciona estadísticas de las sustituciones proporcionadas por un servidor. 4.3.6 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.gnu.org' 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.gnu.org' 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 (*note Invocación de guix publish::). Guix tiene los cimientos para maximizar la reproducibilidad de las construcciones (*note 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 (*note 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 (*note ‘guix build --check': 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>. 4.4 Paquetes con múltiples salidas ================================== Often, packages defined in Guix have a single “output”—i.e., the source package leads to exactly one directory in the store. When running ‘guix install glibc', one installs the default output of the GNU libc package; the default output is called ‘out', but its name can be omitted as shown in this command. In this particular case, the default output of ‘glibc' contains all the C header files, shared libraries, static libraries, Info documentation, and other supporting files. 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 install glib La orden que instala su documentación es: guix install 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 (*note Invocación de guix size::). ‘guix graph' también puede ser útil (*note 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 (*note 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' (*note Invocación de guix package::). 4.5 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' (*note 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' (*note 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 (*note 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 (*note size specifications: (coreutils)Block size.). 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' (*note ‘--cache-failures': Invocación de guix-daemon.). ‘--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. *Note Invocación de guix size::, para una herramienta que perfila el tamaño de la clausura de un elemento. *Note 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 (*note 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 (*note 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' (*note 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' (*note ‘--disable-deduplication': Invocación de guix-daemon.). Por tanto, esta opción es útil primariamente cuando el daemon se estaba ejecutando con ‘--disable-deduplication'. 4.6 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
...
-
http://www.gnu.org/savannah-checkouts/gnu/guix/manual/es/guix.es.txt
- [detail]
- [similar]
PREV
NEXT