Next: Servicios de control de versiones, Previous: Servicios de audio, Up: Servicios [Contents][Index]
El módulo (gnu services virtualization) proporciona servicios para
los daemon libvirt y virtlog, así como otros servicios relacionados con la
virtualización.
libvirtd is the server side daemon component of the libvirt
virtualization management system. This daemon runs on host servers and
performs required management tasks for virtualized guests. To connect to
the libvirt daemon as an unprivileged user, it must be added to the
‘libvirt’ group, as shown in the example below.
Este es el tipo para el daemon de libvirt. Su
valor debe ser un objeto libvirt-configuration.
(users (cons (user-account (name "user") (group "users") (supplementary-groups '("libvirt" "audio" "video" "wheel"))) %base-user-accounts)) (service libvirt-service-type (libvirt-configuration (tls-port "16555")))
Los campos disponibles de libvirt-configuration son:
libvirt-configuration: package libvirt ¶Paquete libvirt.
libvirt-configuration: boolean listen-tls? ¶Opción para la escucha de conexiones seguras TLS en el puerto TCP/IP
público. Debe haberse proporcionado valor a listen para que tenga
algún efecto.
Es necesario configurar una autoridad de certificación (CA) y emitir certificados de servidor antes de usar esta característica.
El valor predeterminado es ‘#t’
libvirt-configuration: boolean listen-tcp? ¶Escucha de conexiones TCP sin cifrar en el puerto TCP/IP público. Debe
haberse proporcionado valor a listen para que tenga algún efecto.
El uso del socket TCP necesita de manera predeterminada identificación SASL. Únicamente se permiten mecanismos SASL que implementen cifrado de datos. Estos son DIGEST_MD5 y GSSAPI (Kerberos5).
El valor predeterminado es ‘#f’
libvirt-configuration: string tls-port ¶Puerto en el que se aceptan conexiones seguras. Puede ser un número de puerto o un nombre de servicio.
El valor predeterminado es ‘"16514"’.
libvirt-configuration: string tcp-port ¶Puerto en el que se aceptan conexiones inseguras. Puede ser un número de puerto o un nombre de servicio.
El valor predeterminado es ‘"16509"’.
libvirt-configuration: string listen-addr ¶Dirección IP o nombre de máquina usado para las conexiones de clientes.
El valor predeterminado es ‘"0.0.0.0"’.
libvirt-configuration: boolean mdns-adv? ¶Opción que determina el anuncio mDNS del servicio libvirt.
De manera alternativa puede desactivarse para todos los servicios en una máquina parando el daemon Avahi.
El valor predeterminado es ‘#f’
libvirt-configuration: string mdns-name ¶Nombre predeterminado del anuncio mDNS. Debe ser único en la red de distribución inmediata.
El valor predeterminado es ‘"Virtualization Host <hostname>"’.<
libvirt-configuration: string unix-sock-group ¶Grupo propietario del socket de dominio de UNIX. Puede usarse para permitir a un conjunto de usuarias “de confianza” acceso a las funcionalidades de gestión sin convertirse en root.
Defaults to ‘"libvirt"’.
libvirt-configuration: string unix-sock-ro-perms ¶Permisos del socket UNIX de sólo lectura44. Se usa únicamente para monitorizar el estado de las máquinas virtuales.
El valor predeterminado es ‘"0777"’.
libvirt-configuration: string unix-sock-rw-perms ¶Permisos del socket UNIX de lectura/escritura45. El valor predeterminado únicamente permite acceso a root. Si PolicyKit se encuentra activo en el socket, el valor predeterminado cambiará para permitir acceso universal (es decir, 0777).
El valor predeterminado es ‘"0770"’.
libvirt-configuration: string unix-sock-admin-perms ¶Permisos del socket UNIX de administración. El valor predeterminado únicamente permite acceso a la propietaria (root), no lo cambie a menos que esté completamente segura de a quién expone el acceso.
El valor predeterminado es ‘"0777"’.
libvirt-configuration: string unix-sock-dir ¶Directorio en el que los sockets se encuentran/crean.
El valor predeterminado es ‘"/var/run/libvirt"’.
libvirt-configuration: string auth-unix-ro ¶Esquema de identificación para los sockets de solo-lectura de UNIX. Los permisos predeterminados del socket permiten la conexión de cualquier usuaria.
El valor predeterminado es ‘"polkit"’.
libvirt-configuration: string auth-unix-rw ¶Esquema de identificación para los sockets de lectura/escritura de UNIX. Los permisos predeterminados del socket permiten la conexión únicamente a root. Si se activó en la compilación de libvirt la interoperabilidad con PolicyKit, el valor predeterminado es usar la identificación “policykit”.
El valor predeterminado es ‘"polkit"’.
libvirt-configuration: string auth-tcp ¶Esquema de identificación para los sockets TCP. Si no activa SASL, todo el tráfico TCP estará en texto plano. No lo haga más allá de un escenario de desarrollo/pruebas.
El valor predeterminado es ‘"sasl"’.
libvirt-configuration: string auth-tls ¶Esquema de identificación para los sockets TLS. Los sockets TLS ya se encuentran cifrados gracias a la capa TLS, y una identificación limitada se realiza con los certificados.
También es posible hacer uso de cualquier mecanismo de identificación SASL proporcionando “sasl” en esta opción.
El valor predeterminado es ‘"none"’.
libvirt-configuration: lista-opcional access-drivers ¶Esquema de la API de control de acceso.
De manera predeterminada una usuaria identificada puede acceder a todas las API. Los controladores de acceso pueden incluir restricciones de acceso sobre ello.
El valor predeterminado es ‘'()’.
libvirt-configuration: string key-file ¶Ruta del archivo con la clave del servidor. Si se proporciona una cadena vacía, no se carga ninguna clave privada.
El valor predeterminado es ‘""’.
libvirt-configuration: string cert-file ¶Ruta del archivo con la clave del servidor. Si se proporciona una cadena vacía, no se carga ningún certificado.
El valor predeterminado es ‘""’.
libvirt-configuration: string ca-file ¶Ruta del archivo con la clave del servidor. Si se proporciona una cadena vacía, no se carga ningún certificado de CA.
El valor predeterminado es ‘""’.
libvirt-configuration: string crl-file ¶Ruta de la lista de revocaciones de certificado. Si se proporciona una cadena vacía, no se carga ninguna lista.
El valor predeterminado es ‘""’.
libvirt-configuration: boolean tls-no-sanity-cert ¶Desactiva la verificación de los propios certificados del servidor.
Cuando libvirtd arranca, realiza algunas comprobaciones básicas sobre sus propios certificados.
El valor predeterminado es ‘#f’
libvirt-configuration: boolean tls-no-verify-cert ¶Desactiva la verificación de certificados de clientes.
La verificación de certificados de cliente es el mecanismo primario de identificación. Se rechazará cualquier cliente que no presente un certificado firmado por la autoridad de certificación (CA).
El valor predeterminado es ‘#f’
libvirt-configuration: lista-opcional tls-allowed-dn-list ¶Lista de nombres distinguidos (DN) x509 permitidos.
El valor predeterminado es ‘'()’.
libvirt-configuration: lista-opcional sasl-allowed-usernames ¶Lista de nombres de usuaria SASL permitidos. El formato para el nombre de la usuaria depende del mecanismo de identificación SASL.
El valor predeterminado es ‘'()’.
libvirt-configuration: string tls-priority ¶Cambia el valor de la cadena de prioridad de TLS predeterminada en tiempo de compilación. El valor predeterminado habitualmente es ‘"NORMAL"’ a menos que se cambiase en tiempo de compilación. Proporcione este valor únicamente si desea que libvirt se desvíe de la configuración global predeterminada.
El valor predeterminado es ‘"NORMAL"’.
libvirt-configuration: integer max-clients ¶Número máximo de conexiones concurrentes de clientes permitidas en todos los sockets combinados.
El valor predeterminado es ‘5000’.
libvirt-configuration: integer max-queued-clients ¶Longitud máxima de la cola de conexiones a la espera de ser aceptadas por el daemon. Fíjese que algunos protocolos que implementan la retransmisión pueden obedecer esto de manera que un intento posterior de conexión tenga éxito.
El valor predeterminado es ‘1000’.
libvirt-configuration: integer max-anonymous-clients ¶Longitud máxima de la cola de clientes aceptados pero no identificados todavía. Proporcione el valor cero para desactivar esta característica.
El valor predeterminado es ‘20’.
libvirt-configuration: integer min-workers ¶Número de procesos de trabajo que se lanzarán inicialmente.
El valor predeterminado es ‘5’.
libvirt-configuration: integer max-workers ¶Número máximo de hilos de trabajo.
Si el número de clientes excede min-workers, se lanzan más hilos,
hasta el límite max-workers. Habitualmente se desea que
max-workers sea igual al número máximo de clientes permitido.
El valor predeterminado es ‘20’.
libvirt-configuration: integer prio-workers ¶Número de procesos de trabajo prioritarios. Si todos los hilos de trabajo del conjunto previo se encuentran bloqueados, algunas llamadas marcadas como de alta prioridad (notablemente domainDestroy) pueden ejecutarse en este conjunto de hilos.
El valor predeterminado es ‘5’.
libvirt-configuration: integer max-requests ¶Límite global total de llamadas RPC concurrentes.
El valor predeterminado es ‘20’.
libvirt-configuration: integer max-client-requests ¶Límite de peticiones concurrentes desde una única conexión de cliente. Para evitar que un cliente monopolice el servidor esto debe ser una pequeña fracción de los parámetros globales “max_requests” y “max_workers”.
El valor predeterminado es ‘5’.
libvirt-configuration: integer admin-min-workers ¶Igual que min-workers pero para la interfaz de administración.
El valor predeterminado es ‘1’.
libvirt-configuration: integer admin-max-workers ¶Igual que max-workers pero para la interfaz de administración.
El valor predeterminado es ‘5’.
libvirt-configuration: integer admin-max-clients ¶Igual que max-clients pero para la interfaz de administración.
El valor predeterminado es ‘5’.
libvirt-configuration: integer admin-max-queued-clients ¶Igual que max-queued-clients pero para la interfaz de administración.
El valor predeterminado es ‘5’.
libvirt-configuration: integer admin-max-client-requests ¶Igual que max-client-requests pero para la interfaz de
administración.
El valor predeterminado es ‘5’.
libvirt-configuration: integer log-level ¶Nivel de registro. 4 errores, 3 avisos, 2 información, 1 depuración.
El valor predeterminado es ‘3’.
libvirt-configuration: string log-filters ¶Filtros del registro.
Un filtro permite la selección de un nivel de registro diferente para una categoría dada de registros. El formato del filtro es uno de los siguientes:
donde nombre es una cadena contra la que se compara la categoría
proporcionada en la llamada VIR_LOG_INIT() al principio de cada
archivo de fuentes de libvirt, por ejemplo ‘"remote"’, ‘"qemu"’ o
‘"util.json"’ (el nombre en el filtro puede ser una subcadena del
nombre completo de la categoría, para aceptar múltiples categorías con
nombres similares), el prefijo opcional ‘"+"’ indica a libvirt que
registre la pila de llamadas en cada mensaje con el nombre correspondiente,
y x es el nivel mínimo de los mensajes que deben registrarse:
Se pueden definir en una única sentencia múltiples filtros, únicamente hace falta separarlos por espacios.
El valor predeterminado es ‘"3:remote 4:event"’.
libvirt-configuration: string log-outputs ¶Salidas de log.
Una salida es uno de esos lugares para almacenar información de logging. El formato para una salida puede ser:
x:stderrla salida va a stderr
x:syslog:nombreusa syslog para la salida y usa el nombre proporcionado como identificador
x:file:ruta_archivoencamina la salida a un archivo, con la ruta proporcionada
x:journaldusa el sistema de logging journald
En todos los casos el prefijo x es el nivel mínimo, que actúa como filtro
Se pueden definir salidas múltiples, únicamente deben separarse por espacios.
El valor predeterminado es ‘"3:stderr"’.
libvirt-configuration: integer audit-level ¶Permite la alteración del uso del sistema de auditoría.
El valor predeterminado es ‘1’.
libvirt-configuration: boolean audit-logging ¶Envía los mensajes de auditoría a través de la infraestructura de registro de libvirt.
El valor predeterminado es ‘#f’
libvirt-configuration: string-opcional host-uuid ¶Host UUID. UUID must not have all digits be the same.
El valor predeterminado es ‘""’.
libvirt-configuration: string host-uuid-source ¶Fuente de lectura del UUID de la máquina anfitriona.
smbios: obtiene el UUID de dmidecode -s system-uuid
machine-id: obtiene el UUID de /etc/machine-id
Si dmidecode no proporciona un UUID válido, se generará un UUID
temporal.
El valor predeterminado es ‘"smbios"’.
libvirt-configuration: integer keepalive-interval ¶Un mensaje “keepalive” se envía al cliente tras keepalive_interval
segundos de inactividad para comprobar si el cliente todavía responde. Si se
proporciona el valor -1, libvirtd nunca enviará peticiones “keepalive”; no
obstante los clientes todavía pueden mandarlas y el daemon enviará las
respuestas.
El valor predeterminado es ‘5’.
libvirt-configuration: integer keepalive-count ¶Número máximo de mensajes “keepalive” que se permite enviar a un cliente sin obtener respuesta antes de considerar que se ha roto la conexión.
En otras palabras, la conexión se cierra automáticamente tras
keepalive_interval * (keepalive_count + 1) segundos tras la última
recepción de un mensaje desde el cliente. Cuando keepalive_count
tiene valor 0, las conexiones se cerrarán automáticamente tras
keepalive-interval segundos de inactividad sin mandar ningún mensaje
“keepalive”.
El valor predeterminado es ‘5’.
libvirt-configuration: integer admin-keepalive-interval ¶Igual que la opción anterior pero para la interfaz de administración.
El valor predeterminado es ‘5’.
libvirt-configuration: integer admin-keepalive-count ¶Igual que la opción anterior pero para la interfaz de administración.
El valor predeterminado es ‘5’.
libvirt-configuration: integer ovs-timeout ¶Plazo máximo para las llamadas a Open vSwitch.
La utilidad ovs-vsctl se usa para la configuración y su opción de
plazo máximo (timeout) tiene un valor de 5 segundos de manera predeterminada
para evitar que esperas potencialmente infinitas bloqueen libvirt.
El valor predeterminado es ‘5’.
El servicio virtlogd es un daemon del que se compone el lado servidor de libvirt cuya finalidad es la gestión del registro de las consolas de las máquinas virtuales.
This daemon is not used directly by libvirt client applications, rather it
is called on their behalf by libvirtd. By maintaining the logs in a
standalone daemon, the main libvirtd daemon can be restarted without
risk of losing logs. The virtlogd daemon has the ability to
re-exec() itself upon receiving SIGUSR1, to allow live upgrades
without downtime.
Este es el tipo del daemon virtlog. Su valor debe ser un objeto
virtlog-configuration.
(service virtlog-service-type
(virtlog-configuration
(max-clients 1000)))
libvirt parameter: package libvirt ¶Paquete libvirt.
virtlog-configuration: integer log-level ¶Nivel de registro. 4 errores, 3 avisos, 2 información, 1 depuración.
El valor predeterminado es ‘3’.
virtlog-configuration: string log-filters ¶Filtros del registro.
Un filtro permite la selección de un nivel de registro diferente para una categoría dada de registros. El formato del filtro es uno de los siguientes:
donde nombre es una cadena contra la que se compara la categoría
proporcionada en la llamada VIR_LOG_INIT() al principio de cada
archivo de fuentes de libvirt, por ejemplo "remote", "qemu" o "util.json"
(el nombre en el filtro puede ser una subcadena del nombre completo de la
categoría, para aceptar múltiples categorías con nombres similares), el
prefijo opcional "+" indica a libvirt que registre la pila de llamadas en
cada mensaje con el nombre correspondiente, y x es el nivel mínimo de
los mensajes que deben registrarse:
Se pueden definir en una única sentencia múltiples filtros, únicamente hace falta separarlos por espacios.
El valor predeterminado es ‘"3:remote 4:event"’.
virtlog-configuration: string log-outputs ¶Salidas de log.
Una salida es uno de esos lugares para almacenar información de logging. El formato para una salida puede ser:
x:stderrla salida va a stderr
x:syslog:nombreusa syslog para la salida y usa el nombre proporcionado como identificador
x:file:ruta_archivoencamina la salida a un archivo, con la ruta proporcionada
x:journaldusa el sistema de logging journald
En todos los casos el prefijo x es el nivel mínimo, que actúa como filtro
Se pueden definir salidas múltiples, únicamente deben separarse por espacios.
El valor predeterminado es ‘"3:stderr"’.
virtlog-configuration: integer max-clients ¶Número máximo de conexiones concurrentes de clientes permitidas en todos los sockets combinados.
El valor predeterminado es ‘1024’.
virtlog-configuration: integer max-size ¶Tamaño máximo del archivo antes de pasar al siguiente.
El valor predeterminado es ‘2MB’.
virtlog-configuration: integer max-backups ¶Número máximo de archivos de backup que se deben mantener.
El valor predeterminado es ‘3’.
qemu-binfmt-service-type proporciona la capacidad de emular
transparentemente programas binarios construidos para arquitecturas
diferentes—por ejemplo, le permite ejecutar de manera transparente un
programa de ARMv7 en una máquina x86_64. Esto se consigue mediante la
combinación del emulador QEMU y la
característica binfmt_misc del núcleo Linux. Esta característica
únicamente le permite emular GNU/Linux en una arquitectura diferente, pero
más adelante puede ver como implementar también GNU/Hurd.
Este es el tipo del servicio de emulación transparente QEMU/binfmt. Su valor
debe ser un objeto qemu-binfmt-configuration, que especifica el
paquete QEMU usado así como las arquitecturas que se desean emular:
(service qemu-binfmt-service-type
(qemu-binfmt-configuration
(platforms (lookup-qemu-platforms "arm" "aarch64"))))
En este ejemplo se activa la emulación transparente para las plataformas ARM
y aarch64. La ejecución de herd stop qemu-binfmt la desactiva, y la
ejecución de herd start qemu-binfmt la vuelve a activar
(see the herd command in The GNU
Shepherd Manual).
Esta es la configuración para el servicio qemu-binfmt.
platforms (predeterminadas: '())Lista de plataformas de QEMU emuladas. Cada elemento debe ser un objeto
de plataforma como los devueltos por lookup-qemu-platforms (véase a
continuación).
Por ejemplo, supongamos que está en una máquina x86_64 y tiene este servicio:
(service qemu-binfmt-service-type
(qemu-binfmt-configuration
(platforms (lookup-qemu-platforms "arm"))))
Puede ejecutar:
guix build -s armhf-linux inkscape
and it will build Inkscape for ARMv7 as if it were a native build, transparently using QEMU to emulate the ARMv7 CPU. Pretty handy if you’d like to test a package build for an architecture you don’t have access to!
qemu (predeterminado: qemu)El paquete QEMU usado.
Devuelve la lista de objetos de plataforma de QEMU que corresponden a
plataformas…. plataformas debe ser una lista de cadenas
que correspondan con nombres de plataforma, como "arm",
"sparc", "mips64el", etcétera.
Devuelve verdadero si obj es un objeto de plataforma.
Devuelve el nombre de plataforma—una cadena como "arm".
The QEMU guest agent provides control over the emulated system to the host.
The qemu-guest-agent service runs the agent on Guix guests. To
control the agent from the host, open a socket by invoking QEMU with the
following arguments:
qemu-system-x86_64 \ -chardev socket,path=/tmp/qga.sock,server=on,wait=off,id=qga0 \ -device virtio-serial \ -device virtserialport,chardev=qga0,name=org.qemu.guest_agent.0 \ ...
This creates a socket at /tmp/qga.sock on the host. Once the guest
agent is running, you can issue commands with socat:
$ guix shell socat -- socat unix-connect:/tmp/qga.sock stdio
{"execute": "guest-get-host-name"}
{"return": {"host-name": "guix"}}
See QEMU guest agent documentation for more options and commands.
Service type for the QEMU guest agent service.
Configuration for the qemu-guest-agent service.
qemu (predeterminado: qemu-minimal)El paquete QEMU usado.
device (default: "")File name of the device or socket the agent uses to communicate with the host. If empty, QEMU uses a default file name.
Virtual build machines or “build VMs” let you offload builds to a fully controlled environment. “How can it be more controlled than regular builds? And why would it be useful?”, you ask. Good questions.
Builds spawned by guix-daemon indeed run in a controlled environment;
specifically the daemon spawns build processes in separate namespaces and in
a chroot, such as that build processes only see their declared dependencies
and a well-defined subset of the file system tree (see Configuración del entorno de construcción, for details). A few aspects of the environments are not controlled
though: the operating system kernel, the CPU model, and the date. Most of
the time, these aspects have no impact on the build process: the level of
isolation guix-daemon provides is “good enough”.
However, there are occasionally cases where those aspects do influence the build process. A typical example is time traps: build processes that stop working after a certain date46. Another one is software that optimizes for the CPU microarchitecture it is built on or, worse, bugs that manifest only on specific CPUs.
To address that, virtual-build-machine-service-type lets you add a
virtual build machine on your system, as in this example:
(use-modules (gnu services virtualization)) (operating-system ;; … (services (append (list (service virtual-build-machine-service-type)) %base-services)))
By default, you have to explicitly start the build machine when you need it, at which point builds may be offloaded to it (see Uso de la facilidad de delegación de trabajo):
herd start build-vm
With the default setting shown above, the build VM runs with its clock set to a date several years in the past, and on a CPU model that corresponds to that date—a model possibly older than that of your machine. This lets you rebuild today software from the past that would otherwise fail to build due to a time trap or other issues in its build process. You can view the VM’s config like this:
herd configuration build-vm
You can configure the build VM, as in this example:
(service virtual-build-machine-service-type
(virtual-build-machine
(cpu "Westmere")
(cpu-count 8)
(memory-size (* 1 1024))
(auto-start? #t)))
The available options are shown below.
This is the service type to run virtual build machines. Virtual build machines are configured so that builds are offloaded to them when they are running.
This is the data type specifying the configuration of a build machine. It contains the fields below:
name (default: 'build-vm)The name of this build VM. It is used to construct the name of its Shepherd service.
imageThe image of the virtual machine (see Creating System Images). This notably
specifies the virtual disk size and the operating system running into it
(see Referencia de operating-system). The default value is a minimal
operating system image.
qemu (predeterminado: qemu-minimal)The QEMU package to run the image.
cpuThe CPU model being emulated as a string denoting a model known to QEMU.
The default value is a model that matches date (see below). To see
what CPU models are available, run, for example:
qemu-system-x86_64 -cpu help
cpu-count (default: 4)The number of CPUs emulated by the virtual machine.
memory-size (default: 2048)Size in mebibytes (MiB) of the virtual machine’s main memory (RAM).
date (default: a few years ago)Date inside the virtual machine when it starts; this must be a SRFI-19 date object (see SRFI-19 Date in GNU Guile Reference Manual).
port-forwardings (default: 11022 and 11004)TCP ports of the virtual machine forwarded to the host. By default, the SSH and secrets ports are forwarded into the host.
systems (default: (list (%current-system)))List of system types supported by the build VM—e.g.,
"x86_64-linux".
auto-start? (default: #f)Whether to start the virtual machine when the system boots.
In the next section, you’ll find a variant on this theme: GNU/Hurd virtual machines!
El servicio hurd-vm implementa la ejecución de GNU/Hurd en una
máquina virtual (VM), llamado childhurd. Este servicio está destinado
para su uson GNU/Linux y la configuración de sistema operativo de GNU/Hurd
se compila de manera cruzada. La máquina virtual es un servicio de Shepherd
al que se puede hacer referencia a través de los nombres hurd-vm y
childhurd y se puede controlar mediante órdenes como las siguientes:
herd start hurd-vm herd stop childhurd
Cuando el servicio se encuentra en ejecución, puede ver su consola a través de una conexión con un cliente VNC, por ejemplo con:
guix shell tigervnc-client -- vncviewer localhost:5900
The default configuration (see hurd-vm-configuration below) spawns a
secure shell (SSH) server in your GNU/Hurd system, which QEMU (the virtual
machine emulator) redirects to port 10022 on the host. By default, the
service enables offloading such that the host guix-daemon
automatically offloads GNU/Hurd builds to the childhurd (see Uso de la facilidad de delegación de trabajo). This is what happens when running a command like the
following one, where i586-gnu is the system type of 32-bit GNU/Hurd:
guix build emacs-minimal -s i586-gnu
childhurd es volátil y carece de estado: comienza con un sistema de archivos
raíz creado de cero cada vez que lo reinicia. No obstante de manera
predeterminada todos los archivos en la ruta /etc/childhurd de la
máquina anfitriona se copian al sistema de archivos raíz de childhurd cuando
arranca. Esto permite que configure “secretos” dentro de la máquina
virtual: claves de SSH de la máquina, claves de sustituciones autorizadas,
etcétera—véase la explicación de secret-root a continuación.
You will probably find it useful to create an account for you in the
GNU/Hurd virtual machine and to authorize logins with your SSH key. To do
that, you can define the GNU/Hurd system in the usual way (see Uso de la configuración del sistema), and then pass that operating system as the os
field of hurd-vm-configuration, as in this example:
(define childhurd-os ;; Definition of my GNU/Hurd system, derived from the default one. (operating-system (inherit %hurd-vm-operating-system) ;; Add a user account. (users (cons (user-account (name "charlie") (comment "This is me!") (group "users") (supplementary-groups '("wheel"))) ;for 'sudo' %base-user-accounts)) (services ;; Modify the SSH configuration to allow login as "root" ;; and as "charlie" using public key authentication. (modify-services (operating-system-user-services %hurd-vm-operating-system) (openssh-service-type config => (openssh-configuration (inherit config) (authorized-keys `(("root" ,(local-file "/home/charlie/.ssh/id_rsa.pub")) ("charlie" ,(local-file "/home/charlie/.ssh/id_rsa.pub")))))))))) (operating-system ;; … (services ;; Add the 'hurd-vm' service, configured to use the ;; operating system configuration above. (append (list (service hurd-vm-service-type (hurd-vm-configuration (os %childhurd-os)))) %base-services)))
That’s it! The remainder of this section provides the reference of the service configuration.
El tipo del servicio que ejecuta Hurd en una máquina virtual. Su valor debe
ser un objeto hurd-vm-configuration, que especifica el sistema
operativo (see Referencia de operating-system) y el tamaño del disco para la
máquina virtual de Hurd, el paquete de QEMU usado así como las opciones de
ejecución.
Por ejemplo:
(service hurd-vm-service-type (hurd-vm-configuration (disk-size (* 5000 (expt 2 20))) ;5G (memory-size 1024))) ;1024MiB
crearía una imagen de disco suficientemente grande para construir GNU Hello, con algo de memoria adicional.
Tipo de datos que representa la configuración de
hurd-vm-service-type.
os (predeterminado: %hurd-vm-operating-system)El sistema operativo instanciado. El valor predeterminado es un sistema
mínimo con un daemon del intérprete de comandos seguro OpenSSH configurado
de forma permisiva asociado al puerto 2222 (see openssh-service-type).
qemu (predeterminado: qemu-minimal)El paquete QEMU usado.
image (predeterminado: hurd-vm-disk-image)The image object representing the disk image of this virtual machine (see Creating System Images).
disk-size (predeterminado: 'guess)El tamaño de la imagen de disco.
memory-size (predeterminado: 512)El tamaño de la memoria de la máquina virtual en mebibytes.
options (predeterminadas: '("--snapshot"))Opciones adicionales para ejecutar QEMU.
id (predeterminado: #f)Si se proporciona un valor, debe ser un entero positivo no nulo usado para
parametrizar las instancias Childhurd. Se añade al nombre del servicio, por
ejemplo childhurd1.
net-options (predeterminado: hurd-vm-net-options)El procedimiento usado para producir la lista de opciones de red para QEMU.
De manera predeterminada produce
'("--device" "rtl8139,netdev=net0" "--netdev" (string-append "user,id=net0," "hostfwd=tcp:127.0.0.1:secrets-port-:1004," "hostfwd=tcp:127.0.0.1:ssh-port-:2222," "hostfwd=tcp:127.0.0.1:vnc-port-:5900"))
con los siguientes puertos redirigidos:
secrets-port:(+ 11004 (* 1000 ID))ssh-port:(+ 10022 (* 1000 ID))vnc-port:(+ 15900 (* 1000 ID))
offloading? (default: #t)Whether to automatically set up offloading of builds to the childhurd.
When enabled, this lets you run GNU/Hurd builds on the host and have them transparently offloaded to the VM, for instance when running a command like this:
guix build coreutils -s i586-gnu
This option automatically sets up offloading like so:
guix archive --authorize, for more
on that).
offloading dedicated to offloading in
the childhurd.
offloading account in the childhurd.
secret-root (predeterminado: /etc/childhurd)El directorio raíz que contiene los secretos fuera-de-banda que serán instalados en childhurd cuando se ejecute. Los childhurd son volátiles lo que significa que cada arranque los secretos como las claves de SSH de la máquina y la clave de firma de Guix se regeneran.
Si el directorio /etc/childhurd no existe, el servicio
secret-service que se ejecuta en childhurd recibirá una lista vacía
de secretos.
De manera predeterminada el servicio crea /etc/childhurd con los siguientes secretos no volátiles, a no ser que ya existan:
/etc/childhurd/etc/guix/acl /etc/childhurd/etc/guix/signing-key.pub /etc/childhurd/etc/guix/signing-key.sec /etc/childhurd/etc/ssh/authorized_keys.d/offloading /etc/childhurd/etc/ssh/ssh_host_ed25519_key /etc/childhurd/etc/ssh/ssh_host_ecdsa_key /etc/childhurd/etc/ssh/ssh_host_ed25519_key.pub /etc/childhurd/etc/ssh/ssh_host_ecdsa_key.pub
Tenga en cuenta que la imagen de la máquina virtual es volátil, es decir,
los contenidos se pierden cuando se para. Si desea una imagen que mantenga
el estado puede modificar la configuración de image y options
sin la opción --snapshot usando algo parecido a esto:
(service hurd-vm-service-type
(hurd-vm-configuration
(image (const "/no/almacen/y/perm/escritura/hurd.img"))
(options '())))
Nota: Este servicio se considera experimental. Las opciones de configuración pueden cambiar de manera incompatible con versiones previas, y no todas las características han sido probadas en profundidad. Se recomienda a quienes usen este servicio que compartan su experiencia en guix-devel@gnu.org.
Ganeti is a virtual machine management system. It is designed to keep
virtual machines running on a cluster of servers even in the event of
hardware failures, and to make maintenance and recovery tasks easy. It
consists of multiple services which are described later in this section. In
addition to the Ganeti service, you will need the OpenSSH service
(see openssh-service-type), and update the
/etc/hosts file (see hosts-service-type) with the cluster name and address (or use a DNS
server).
Todos los nodos que participan en el cluster de Ganeti deben tener la misma
configuración de Ganeti y en el archivo /etc/hosts. A continuación se
encuentra un ejemplo de configuración para un nodo del cluster de Ganeti que
implementa varios motores de almacenamiento, e instala los proveedores
de sistema operativo debootstrap y guix:
(use-package-modules virtualization) (use-service-modules base ganeti networking ssh) (operating-system ;; … (host-name "node1") ;; Install QEMU so we can use KVM-based instances, and LVM, DRBD and Ceph ;; in order to use the "plain", "drbd" and "rbd" storage backends. (packages (append (map specification->package '("qemu" "lvm2" "drbd-utils" "ceph" ;; Add the debootstrap and guix OS providers. "ganeti-instance-guix" "ganeti-instance-debootstrap")) %base-packages)) (services (append (list (service static-networking-service-type (list (static-networking (addresses (list (network-address (device "eth0") (value "192.168.1.201/24")))) (routes (list (network-route (destination "default") (gateway "192.168.1.254")))) (name-servers '("192.168.1.252" "192.168.1.253"))))) ;; Ganeti uses SSH to communicate between nodes. (service openssh-service-type (openssh-configuration (permit-root-login 'prohibit-password))) (simple-service 'ganeti-hosts-entries hosts-service-type (list (host "192.168.1.200" "ganeti.example.com") (host "192.168.1.201" "node1.example.com" '("node1")) (host "192.168.1.202" "node2.example.com" '("node2")))) (service ganeti-service-type (ganeti-configuration ;; Esta lista especifica las rutas del ;; sistema de archivos permitidas para el ;; almacenamiento de imágenes de máquinas ;; viruales. (file-storage-paths '("/srv/ganeti/almacenamiento")) ;; Esta variable configura una única ;; "variación" tanto para Debootstrap como ;; Guix que funciona con KVM. (os %default-ganeti-os)))) %base-services)))
Users are advised to read the Ganeti administrators guide to learn about the various cluster options and day-to-day operations. There is also a blog post describing how to configure and initialize a small cluster.
Tipo de servicio que incluye todos los distintos servicios que los nodos Ganeti deben ejecutar.
Su valor es un objeto ganeti-configuration que define usado para las
operaciones de línea de órdenes, así como la configuración para varios
daemon. Las rutas de almacenamiento permitidas y los sistemas operativos
disponibles para hospedar también se configuran a través de este tipo de
datos.
El servicio ganeti proporciona las siguientes opciones de
configuración:
ganeti (predeterminado: ganeti)El paquete ganeti usado. Dicho paquete se instala en el perfil del
sistema y hace que las órdenes gnt-cluster,
gnt-instance, etcétera, estén disponibles. Tenga en cuenta que el
valor especificado aquí no afecta a otros servicios ya que cada uno hace
referencia a su paquete ganeti específico (véase a continuación).
noded-configuration (predeterminado: (ganeti-noded-configuration))confd-configuration (predeterminado: (ganeti-confd-configuration))wconfd-configuration (predeterminado: (ganeti-wconfd-configuration))luxid-configuration (predeterminado: (ganeti-luxid-configuration))rapi-configuration (predeterminado: (ganeti-rapi-configuration))kvmd-configuration (predeterminado: (ganeti-kvmd-configuration))mond-configuration (predeterminado: (ganeti-mond-configuration))metad-configuration (predeterminado: (ganeti-metad-configuration))watcher-configuration (predeterminado: (ganeti-watcher-configuration))cleaner-configuration (predeterminado: (ganeti-cleaner-configuration))Estas opciones controlan los distintos daemon y trabajos de cron que se distribuyen con Ganeti. Los posibles valores se describen en detalle a continuación. Para modificar el valor de un elemento de la configuración se debe usar el tipo de configuración para dicho servicio:
(service ganeti-service-type
(ganeti-configuration
(rapi-configuration
(ganeti-rapi-configuration
(interface "eth1"))))
(watcher-configuration
(ganeti-watcher-configuration
(rapi-ip "10.0.0.1"))))
file-storage-paths (predeterminada: '())Lista de directorios permitidos para el motor de almacenamiento de archivos.
hooks (default: #f)When set, this should be a file-like object containing a directory with cluster execution hooks.
os (predeterminado: %default-ganeti-os)Lista de registros <ganeti-os>.
En esencia ganeti-service-type es una abreviación para declara cada
uno de los servicios individualmente:
(service ganeti-noded-service-type) (service ganeti-confd-service-type) (service ganeti-wconfd-service-type) (service ganeti-luxid-service-type) (service ganeti-kvmd-service-type) (service ganeti-mond-service-type) (service ganeti-metad-service-type) (service ganeti-watcher-service-type) (service ganeti-cleaner-service-type)
Además de una extensión del servicio etc-service-type que configura
el motor de almacenamiento de archivos y las variantes de sistema operativo.
Tipo de datos adecuado para proporcionarse como parámetro os de
ganeti-configuration. Tiene los siguientes parámetros:
nameNombre para este proveedor de sistema operativo. Solo se usa para especificar dónde termina la configuración. Proporcionar el valor “debootstrap” indica la creación de /etc/ganeti/instance-debootstrap.
extension (default: #f)The file extension for variants of this OS type. For example .conf or .scm. It will be appended to the variant file name if set.
variants (predeterminadas: '())This must be either a list of ganeti-os-variant objects for this OS,
or a “file-like” object (see file-like objects)
representing the variants directory.
To use the Guix OS provider with variant definitions residing in a local directory instead of declaring individual variants (see guix-variants below), you can do:
(ganeti-os
(name "guix")
(variants (local-file "ganeti-guix-variants"
#:recursive? #true)))
Note that you will need to maintain the variants.list file (see
ganeti-os-interface(7)) manually in this case.
Tipo de datos que representa una variante de SO Ganeti. Este tipo tiene los siguientes parámetros:
nameEl nombre de esta variación.
configurationUn archivo de configuración para esta variación.
Esta variable contiene extensiones (“hook”) para la configuración de la red y el cargador de arranque GRUB.
Esta variable contiene una lista de paquetes adecuada para una máquina completamente virtualizada.
Este tipo de datos crea archivos de configuración adecuados para la orden de generación de sistemas operativos debootstrap.
hooks (predeterminada: %default-debootstrap-hooks)Cuando no es #f debe ser una expresión-G que especifique el
directorio con los guiones que deberán ejecutarse cuando se instale el
sistema operativo. También puede ser una lista de pares (nombre
. obj-tipo-archivo). Por ejemplo:
`((99-hola-mundo . ,(plain-file "#!/bin/sh\necho '¡Hola mundo!'")))
Esto crea un directorio con un ejecutable que se llama 99-hola-mundo
y se ejecuta cada vez que se instale esta variación. Si se proporciona
#f, se usarán los archivos del directorio
/etc/ganeti/instance-debootstrap/hooks, si existe alguno.
proxy (predeterminado: #f)Valor opcional de la pasarela HTTP usada.
mirror (predeterminado: #f)El servidor espejo de Debian. Habitualmente es algo como
http://ftp.no.debian.org/debian. El valor predeterminado cambia
dependiendo de la distribución.
arch (predeterminada: #f)La arquitectura de dpkg. Proporcione armhf para generar con
debootstrap una instancia de ARMv7 en una máquina AArch64. El valor
predeterminado corresponde a la arquitectura del sistema en uso.
suite (predeterminada: "stable")Si se proporciona debe ser el identificador de una entrega o “suite” de
distribución de Debian, como por ejemplo buster o focal. Si se
proporciona #f, se usael valor predeterminado del proveedor de
sistema operativo.
extra-pkgs (predeterminados: %default-debootstrap-extra-pkgs)Lista de paquetes adicionales que dpkg instala junto al sistema mínimo.
components (predeterminado: #f)Si se proporciona un valor debe ser una lista de “componentes” de
repositorio de Debian. Por ejemplo '("main" "contrib").
generate-cache? (predeterminado: #t)Determina si se almacena en caché de manera automática el archivo de debootstrap que se haya generado.
clean-cache (predeterminado: 14)Descarta el contenido de la caché tras este número de días. Use #f
para no descartar contenido de la caché nunca.
partition-style (predeterminado: 'msdos)Tipo de partición creado. Cuando se proporciona un valor debe ser
'msdos, 'none o una cadena.
partition-alignment (predeterminada: 2048)Alineación de la partición en sectores.
Procedimiento auxiliar que crea un registro ganeti-os-variant. Toma
dos parámetros: un nombre y un objeto debootstrap-configuration.
Procedimiento auxiliar que crea un registro ganeti-os. Toma como
parámetro una lista de variaciones creada con debootstrap-variant.
Procedimiento auxiliar que crea un registro ganeti-os-variant para
ser usado por el proveedor de sistema operativo Guix. Toma como parámetros
un nombre y una expresión-G que devuelve un objeto “tipo-archivo”
(see objetos “tipo-archivo”) que contiene configuración
para el sistema Guix.
Procedimiento auxiliar que crea un registro ganeti-os. Toma como
parámetros una lista de variaciones producida por guix-variant.
Variable de conveniencia para que el proveedor debootstrap funcione “automágicamente” sin que quienes lo usan tengan que declarar variaciones manualmente. Contiene una única variación de debootstrap con la configuración predeterminada:
(list (debootstrap-variant
"default"
(debootstrap-configuration)))
Variable de conveniencia para que el proveedor de sistema operativo Guix funcione sin ninguna configuración adicional. Crea una máquina virtual que tiene un servidor SSH, consola serie y autoriza las claves de SSH de las máquinas de Ganeti.
(list (guix-variant
"default"
(file-append ganeti-instance-guix
"/share/doc/ganeti-instance-guix/examples/dynamic.scm")))
Se pueden implementar proveedores de SO no disponibles en Guix mediante la
extensión de los registros ganeti-os y ganeti-os-variant de
manera apropiada. Por ejemplo:
(ganeti-os
(name "personalizado")
(extension ".conf")
(variants
(list (ganeti-os-variant
(name "cosa")
(configuration (plain-file "archivo" "Esto va bien"))))))
Este ejemplo crearía
/etc/ganeti/instance-personalizado/variants/cosa.conf, el cual apunta
a un archivo en el almacén cuyo contenido es esto va bien. También se
crearía /etc/ganeti/instance-personalizado/variants/variants.list con
el contenido cosa.
Obviamente es posible que esto no funcione con todos los proveedores de sistema operativo existentes. Si está interfaz le está limitando en su implementación, por favor, contacte con guix-devel@gnu.org.
El resto de esta sección documenta los distintos servicios incluidos en
ganeti-service-type.
ganeti-noded es el daemon responsable de las funciones específicas
del nodo dentro del sistema Ganeti. El valor de este servicio debe ser un
objeto ganeti-noded-configuration.
Esta es la configuración para el servicio ganeti-noded.
ganeti (predeterminado: ganeti)El paquete ganeti usado para este servicio.
port (predeterminado: 1811)Puerto TCP en el que escucha el daemon del nodo a la espera de peticiones a través de la red.
address (predeterminado: "0.0.0.0")La dirección de red a la que el daemon se enlaza. La dirección predeterminada significa que el daemon se enlaza a todas las direcciones disponibles.
interface (predeterminado: #f)En caso de proporcionarse un valor, debe especificar el nombre de la
interfaz de red (por ejemplo, eth0 a la que el daemon se enlaza.
max-clients (predeterminado: 20)Establece un límite en el número máximo de conexiones simultaneas de clientes que el daemon manejará. Las conexiones que excedan dicho número se aceptan, pero no se envía respuesta hasta que hayan cerrado suficientes conexiones.
ssl? (predeterminado: #t)Determina si se usa SSL/TLS para cifrar las comunicaciones a través de la
red. El cluster proporciona automáticamente el certificado y se puede rotar
con gnt-cluster renew-crypto.
ssl-key (predeterminado: "/var/lib/ganeti/server.pem")Puede usarse para proporcionar una clave de cifrado específica para comunicaciones TLS.
ssl-cert (predeterminado: "/var/lib/ganeti/server.pem")Puede usarse para proporcionar un certificado específico para comunicaciones TLS.
debug? (predeterminado: #f)Cuando es verdadero, el daemon almacena registros adicionales con propósitos de depuración. Tenga en cuenta que esto puede exponer detalles de cifrado en los archivos de registro, por lo que debe usarse con precaución.
ganeti-confd responde a las consultas relacionadas con la
configuración del cluster Ganeti. El propósito de este daemon es tener una
forma rápida y con alta disponibilidad de consultar los valores de
configuración del cluster. Se activa de manera automática en todas las
máquinas candidatas de ser coordinadoras. El valor de este servicio
debe ser un objeto ganeti-confd-configuration.
Esta es la configuración para el servicio ganeti-confd.
ganeti (predeterminado: ganeti)El paquete ganeti usado para este servicio.
port (predeterminado: 1814)El puerto UDP en el que esperarán peticiones a través de la red.
address (predeterminado: "0.0.0.0")Dirección de red a la que el daemon se asocia.
debug? (predeterminado: #f)Cuando es verdadero, el daemon almacena registros adicionales con propósitos de depuración.
ganeti-wconfd es el daemon que proporciona una autoridad de
conocimiento sobre la configuración del cluster y es la única entidad que
puede aceptar cambios sobre ella. Todos las trabajos que necesiten modificar
la configuración deben hacerlo enviando las peticiones adecuadas a este
daemon. Únicamente se ejecuta en el nodo coordinador y se desactiva
automáticamente en otros nodos.
El valor de este servicio debe ser un objeto
ganeti-wconfd-configuration.
Esta es la configuración para el servicio ganeti-wconfd.
ganeti (predeterminado: ganeti)El paquete ganeti usado para este servicio.
no-voting? (predeterminado: #f)El daemon se negará a arrancar si la mayoría de los nodos del cluster no
coinciden en que se está ejecutando en el nodo coordinador. Proporcione
#t para arrancar incluso cuando no se puede alcanzar dicha mayoría
(peligroso, úsese con precaución).
debug? (predeterminado: #f)Cuando es verdadero, el daemon almacena registros adicionales con propósitos de depuración.
ganeti-luxid es un daemon que responde a las peticiones
relacionadas con la configuración del estado actual del cluster Ganeti. De
manera adicional, es el daemon que tiene el control sobre la cola de
trabajos de Ganeti. Los trabajos se pueden emitir a través de este daemon y
éste los planifica y arranca.
Recibe un objeto ganeti-luxid-configuration.
This is the configuration for the ganeti-luxid service.
ganeti (predeterminado: ganeti)El paquete ganeti usado para este servicio.
no-voting? (predeterminado: #f)El daemon se negará a arrancar si no puede verificar que la mayoría de los
nodos del cluster creen que éste se está ejecutando en el nodo
coordinador. Proporcione #t para ignorar dichas comprobaciones y
arrancar en cualquier caso (puede ser peligroso).
debug? (predeterminado: #f)Cuando es verdadero, el daemon almacena registros adicionales con propósitos de depuración.
ganeti-rapi proporciona una API remota para cluster de Ganeti. Se
ejecuta en el nodo coordinador y se puede usar para realizar programática
acciones en el cluster a través de un protocolo de llamada de procedimientos
remotos (RPC) basado en JSON.
Se permiten la mayoría de las operaciones de consulta sin identificación (a no ser que se especifique require-authentication?), mientras que las operaciones de escritura necesitan autorización explícita a través del archivo /var/lib/ganeti/rapi/users. Véase la documentación de la API remota de Ganeti para obtener más información.
El valor de este servicio debe ser un objeto
ganeti-rapi-configuration.
Configuración para el servicio ganeti-rapi.
ganeti (predeterminado: ganeti)El paquete ganeti usado para este servicio.
require-authentication? (predeterminado: #f)Determina si se requiere identificación incluso para operaciones únicamente de lectura.
port (predeterminado: 5080)El puerto TCP en el que esperarán peticiones de la API.
address (predeterminado: "0.0.0.0")La dirección de red a la que se asocia el servicio. De manera predeterminada el servicio se asocia a todas las direcciones configuradas.
interface (predeterminado: #f)Si se proporciona un valor, debe especificar el nombre de la interfaz de
red, como por ejemplo eth0, a la que el daemon se asocia.
max-clients (predeterminado: 20)Número máximo de conexiones simultaneas de clientes que se manejan. Las conexiones que excedan dicho número se aceptan, pero no se envía respuesta hasta que hayan cerrado suficientes conexiones.
ssl? (predeterminado: #t)Determina si se usa cifrado SSL/TLS en el puerto de la API remota.
ssl-key (predeterminado: "/var/lib/ganeti/server.pem")Puede usarse para proporcionar una clave de cifrado específica para comunicaciones TLS.
ssl-cert (predeterminado: "/var/lib/ganeti/server.pem")Puede usarse para proporcionar un certificado específico para comunicaciones TLS.
debug? (predeterminado: #f)Cuando es verdadero, el daemon almacena registros adicionales con propósitos de depuración. Tenga en cuenta que esto puede exponer detalles de cifrado en los archivos de registro, por lo que debe usarse con precaución.
ganeti-kvmd es responsable de determinar si una instancia KVM
determinada ha sido apagada por una usuaria o una
administradora. Normalmente Ganeti reiniciará una instancia que no se haya
parado a través de Ganeti. Si la opción del cluster user_shutdown es
verdadera, este daemon monitoriza el puerto QMP que proporciona QEMU
y escucha eventos de apagado en él, y marca la instancia como
USER_down en vez de ERROR_down cuando el daemon la apaga de
manera adecuada.
Recibe un objeto ganeti-kvmd-configuration.
ganeti (predeterminado: ganeti)El paquete ganeti usado para este servicio.
debug? (predeterminado: #f)Cuando es verdadero, el daemon almacena registros adicionales con propósitos de depuración.
ganeti-mond es un daemon opcional que proporciona la funcionalidad
de monitorización de Ganeti. Es responsable de la ejecución de los
recolectores de datos y la publicación de la información obtenida a través
de una interfaz HTTP.
Recibe un objeto ganeti-mond-configuration.
ganeti (predeterminado: ganeti)El paquete ganeti usado para este servicio.
port (predeterminado: 1815)Puerto en el que el daemon espera conexiones.
address (predeterminado: "0.0.0.0")La dirección de red a la que se asocia el daemon. De manera predeterminada se asocia a todas las interfaces disponibles.
debug? (predeterminado: #f)Cuando es verdadero, el daemon almacena registros adicionales con propósitos de depuración.
ganeti-metad es un daemon opcional que se puede usar para
proporcionar información del cluster a instancias o guiones de instalación
de sistema operativo.
Recibe un objeto ganeti-metad-configuration.
ganeti (predeterminado: ganeti)El paquete ganeti usado para este servicio.
port (predeterminado: 80)Puerto en el que el daemon espera conexiones.
address (predeterminada: #f)Si se proporciona un valor el daemon se asociará únicamente a esta dirección. Si no se proporciona valor el comportamiento depende de la configuración del cluster.
debug? (predeterminado: #f)Cuando es verdadero, el daemon almacena registros adicionales con propósitos de depuración.
ganeti-watcher es un guión diseñado para su ejecución periódica en
la que comprueba el estado la salud del cluster. Reinicia automáticamente
las instancias que se han parado sin el consentimiento de Ganeti, y repara
los enlaces DRBD en caso de que un nodo se haya reiniciado. También archiva
los trabajos antiguos del cluster y reinicia los daemon de Ganeti si no se
están ejecutando. Si se ha proporcionado valor al parámetro del cluster
ensure_node_health, este proceso también apagará las instancias y
dispositivos DRBD si el nodo que las ejecute se ha declarado fuera de línea
por alguna de las máquinas candidatas de coordinación conocidas.
Se puede pausar en todos los nodos con gnt-cluster watcher pause.
Este servicio toma como valor un objeto ganeti-watcher-configuration.
ganeti (predeterminado: ganeti)El paquete ganeti usado para este servicio.
schedule (predeterminado: '(next-second-from (next-minute (range 0 60 5))))Cada cuanto se ejecuta el guión. El valor predeterminado es cada 5 minutos.
rapi-ip (predeterminada: #f)Esta opción se debe especificar únicamente si el daemon de API remota se ha configurado para usar una interfaz o dirección de red concreta. De manera predeterminada se usa la dirección del cluster.
job-age (predeterminados: (* 6 3600))Archiva los trabajos del cluster cuya antigüedad sea mayor que el el número
de segundos proporcionado. El valor predeterminado son 6 horas. Esto
mantiene la lista proporcionada gnt-job list dentro de límites
gestionables.
verify-disks? (predeterminado: #t)Si es #f, el proceso de vigilancia (“watcher”) no intentará reparar
los enlaces de DRBD rotos de manera automática. Esto significa que quienes
administren el sistema deberán usar gnt-cluster verify-disks
manualmente para realizar dicha tarea.
debug? (predeterminado: #f)Cuando es #t, el guión registra información adicional para facilitar
la depuración.
ganeti-cleaner es un guión diseñado para su ejecución periódica en
la que elimina archivos antiguos del cluster. Este tipo de servicio controla
dos trabajos de cron: uno para el nodo coordinador que elimina de
manera permanente trabajos antiguos del cluster, y otro para todos los nodos
que elimina certificados X509 y claves que hayan expirado así como
información desactualizada de ganeti-watcher. Como todos los
servicios de Ganeti, se puede incluir también en los nodos que no son
coordinadores y se desactivará por si mismo si es necesario.
Recibe un objeto ganeti-cleaner-configuration.
ganeti (predeterminado: ganeti)El paquete ganeti usado para la orden gnt-cleaner.
master-schedule (predeterminado: "45 1 * * *")Cada cuanto se ejecuta el trabajo principal de limpieza. El valor predeterminado representa su ejecución una vez al día, a las 01:45:00.
node-schedule (predeterminada: "45 2 * * *")La frecuencia del trabajo de limpieza del nodo. El valor predeterminado es una vez al día, a las 02:45:00.
R/O: Read-Only en inglés.
R/W: Read-Write en inglés.
The most widespread example of time traps is test suites that involve checking the expiration date of a certificate. Such tests exists in TLS implementations such as OpenSSL and GnuTLS, but also in high-level software such as Python.
Next: Servicios de control de versiones, Previous: Servicios de audio, Up: Servicios [Contents][Index]