Acceso a Anaconda

Yohaan Vakil, Frank Sträter, Ben Cotton Versión unspecified Last review: 2022-05-04

Introducción

Anaconda hace un seguimiento de todas sus actividades en las bitácoras. Esto incluye:

  • cambiar pasos de instalación (que corresponden aproximadamente a diferentes pantallas del instalador gráfico)

  • almacena detección y manipulación de dispositivos

  • detección de medios de instalación

  • inicialización de red

  • mensajes del kernel

  • invocaciones a métodos críticos dentro de anaconda

  • invocaciones a programas externos

Acceso al sistema instalado

Durante la instalación las bitácoras son almacenadas en el directorio /tmp:

Archivos bitácora

/tmp/anaconda.log

la información de la instalación usual, particularmente los campos de paso.

/tmp/storage.log

análisis y manipulación de dispositivos de almacenaje (discos duros, particiones, LVM, RAID), particionado

/tmp/program.log

invoca a programas externos, sus salidas

/tmp/packaging.log

DNF mensajes de instalación de paquete

/tmp/syslog

mensajes del sistema relativos al hardware

Ciertos mensajes de bitácora son también escritos a los terminales:

Dispositivos TTL

/dev/tty3

los mensajes desde anaconda.log, storage.log y packaging.log.

/dev/tty4

lo mismo que syslog

/dev/tty5

stdout y stderr desde programas externos

tty3 y tty4 refleja ciertos archivos de bitácora. Archivos bitácora siempre contienen mensajes desde todos los niveles de bitácora, incluyendo depuración, pero el nivel de bitácora minimal sobre los terminales pueden estar controlados con el enlace loglevel opción de línea de instrucción.

Hay otros dos archivos de bitácora creados sobre el sistema de archivos destino, en el directorio /root, además accesible en /mnt/sysimage/root durante la instalación:

/mnt/sysimage/root/install.log

bitácora del proceso de instalación de paquete.

/mnt/sysimage/root/install.log.syslog

los mensajes desde chroot de instalación con bitácora realizada a través del syslog del sistema.

Principalmente información sobre usuarios y grupos creados durante la instalación de paquetes de dnf.

Formato de bitácora

En archivos el formato de mensajes de bitácora es como sigue:

 H:M:S,ms LOGLEVEL capacidad:mensaje

donde:

  • H:M:S es la marca de tiempo del mensaje

  • ms es la parte en milisegundos de la marca de tiempo. No que esto usualmente se convertirá en una bitácora de sistema syslog remota.

  • LOGLEVEL es el nibel de bitácora del mensaje. En teoría, porque los mensajes del kernel son parte de las bitácoras de anaconda, todos los niveles de bitácora que están definidos en rsyslog pueden aparecer dentro de los archivos de bitácora. El mismo Anaconda sin embargo la misma bitácora solo registra en los niveles de bitácora siguientes:

    • DEBUG

    • INFO

    • WARN

    • ERR

    • CRIT

  • facility es el programa o componente que ha creado el mensaje. Pudo ser para instancia de kernel, anaconda, storage o similar.

  • message es el mismo mensaje de la bitácora.

Para las bitácoras en ejecución en terminales, el formato simple es:

 LOGLEVEL capacidad:mensaje

Acceso remoto por TCP

Anaconda admite manipulación de acceso remoto a través del demonio rsyslog ejecutándose en el sistema instalado. Puede ser configurado para traslado a través de TCP a una máquina arbitraria en red que también esté ejecutando un demonio syslog. Esto está controlado con la `syslog`opción de línea de instrucción.

No olvide habilitar el puerto que está ejecutando en su demonio syslog local en su cortafuegos.

Qué es acceder remotamente

Todo que está directamente accedido por anaconda además aparecería dentro de las bitácoras remotas. Esto incluye mensajes emitidos por el cargador y el subsistema de almacenaje. Todas las trazas devueltas de anaconda (/tmp/anaconda-tb-xyz) están concatenaas en un archivo único en /tmp/anaconda-tb-all.log y entonces tranferido. Además, /tmp/x.log es transferido.

La bitácora remota solo funciona cuando el instalador inicia la red. Una vez que la red está activa, toma un par de minutos para que rsyslogd realice esto. Rsyslog tiene una cola para mensajes que no pudieron ser reenviados debido a red inaccesible y eventualmente re-envía todos ellos, en el orden correcto.

Configuración

Depende de ti cómo esté configurado el demonio de registro remoto, puedes por ejemplo registrar todos los mensajes entrantes en un archivo u ordenarlos en directorios según la dirección IP del sistema remoto.

El RPM de anaconda proporciona el script analog, que genera un archivo de configuración de rsyslogd adecuado basándose en un par de parámetros de instalación. También puede generar una instrucción bash para iniciar rsyslogd con la configuración generada. Por lo tanto, puede hacerlo desde una consola: $ eval scripts/analog -p 6080 -s -o ./someconf /home/akozumpl/remote_inst Esto inicia un demonio de rsyslog que escuchará en el puerto 6080. Los registros de la máquina remota con IP 10.34.33.221 se almacenarán en /home/akozumpl/remote_inst/10.34.33.221/, por ejemplo, /home/akozumpl/remote_inst/10.34.33.221/anaconda.log.

La configuración remota syslog explota varias características de mensaje de bitácora para ser capaz de ordenarlos en los archivos correctos: * la IP del remite del mensaje para conocer cual máquina generó el mensaje y por tanto que directorio hace que el mensaje pertenece. * anaconda.log, storage.log y program.log tiene el nombre embebido en ellos como programname. * los mensajes syslog vienen desde capacidades de kernel y del demonio, tan solo como se hace en el sistema instalado * install.log.syslog creado durante la instalación del paquete está acedido como un nombre de host de sysimage especial.

Ejecuta analog sin la opción -o para ver como exactamente hace un archivo de configuración que quepa. Además dese cuenta que utililiza el mismo formato de mensaje para accedo remoto como lo hace anaconda, pero puede por supuesto modificar esto para especificar cualqueir formato de desea.

Consulte además

Bitácora remota por medio de virtio

QEMU/KVM en Fedora 13 y posteriores permite crear máquinas virtuales con múltiples dispositivos virtio char expuestos a la máquina huésped. Uno de estos dispositivos se puede utilizar para reenviar los registros de anaconda a la máquina huésped. De esta forma podemos obtener los registros en tiempo real, tan pronto como el subsistema de registro de anaconda se inicialice (temprano) y no tener que esperar a que la red se active. Además, es la única manera de reenviar los registros en una configuración sin red.

Configuración de Acceso Remoto

Anaconda reenviará las birácoras logs a través de virtio automáticamente si es capaz de encontrar el puerto /dev/virtio-ports/org.fedoraproject.anaconda.log.0". Este puerto se crea usando una directiva libvirt XML que lo conecta a un socket TCP en el host. Entonces es posible leer los registros desde allí directamente, o hacer una instancia rsyslog para analizarlos y archivarlos en los archivos respectivos. Consulte la tabla ascii a continuación para el conjunto completo:

Anaconda--->rsyslog(guest)--->virtio(guest char device)--->kvm hypervisor--->virtio(TCP socket)
                                                                                                                                                                                  |
                                                                                                                                                                                  v
                                                                                                 archivos bitácora reenviados<---rsyslog(host)

Instrucciones paso a paso para establecer todo así:

  1. Crea una máquina virtual de pruebas, p.e. utilizando Gestor Virtual </li>

  2. Añada el puerto virtio-serial a su máquina virtual, direcciónelo al puerto TCP 6080 en el huesped. Inicie editando la configuración de invitado: virsh edit <machine name>

  3. Dentro del editor anfitrión, añada información siguiente en la sección <devices>:

<channel type='tcp'>
  <source mode='connect' host='127.0.0.1' service='6080'/>
  <target type='virtio' name='org.fedoraproject.anaconda.log.0'/>
</channel>

  1. Inicia la escucha del proceso rsyslogd en el hospedaje, utiliando el guion analog descrito [[#Remote_logging_via_TCP|anterior]]:

evalua `analog -p 6080 -o rsyslogd.conf -s /home/akozumpl/remote_inst`

  1. Inicie la máquina virtual.

  2. Continúe con la instalación. Inmediatamente tras el saludo de Anaconda sea exhibido apareceán los mensajes de log (bitácora) dentro del directorio dado en el guion analog, dentro del subdirectorio 127.0.0.1.

virt-install

Si está utilizando virt-install puede configurarlo con la opción --channel:

--channel tcp,host=127.0.0.1:6080,mode=connect,target_type=virtio,name=org.fedoraproject.anaconda.log.0

Problemas y soluciones conocidos

  • funciona en libvirt>=0.8.2

  • el chroot de mensajes de syslog desde /mnt/sysimage/root/install.log.syslog no son reenviados.

  • no es posible iniciar la máquina a no ser que algo está escuchando sobre el puerto TCP donde esté conectado virtio-serial.

  • si desea probar que la conexión virtio está funcionando, en vez de utilizar analog y rsyslog tan solo deje a una utilidad netcar escuche en el puerto dado, p.ej. nc -l 0.0.0.0 6080. Iniciaría ver bitácoras en crudo en el terminal una vez que inicie el arranque la máquina invitada.

  • si ambos TCP remotos de la bitácora por medio de syslog= y virtio remoto de bitácora por medio de virtiolog= están especificados en la línea de instrucción, una tiene que configurar instancias rsyslogd en el servidor/huésped para escuchar a ambos las conexiones en otro caso el envío de colas de rsyslog obtienen completo y la detención de re-envío.

Consulte además

Las bitácoras de Anaconda en el sistema en ejecución

Tras cada instalación correcta, se copian las bitácoras de Anaconda a /var/log en el sistema que acaba de instalar. Para evitar choques de nombres con otros archivos de bitácora allí, las bitácoras son renombradas:

Nombre durante la instalación Nombre en el destino del sistema

/tmp/anaconda.log

/var/log/anaconda/anaconda.log

/tmp/program.log

/var/log/anaconda/program.log

/tmp/storage.log

/var/log/anaconda/storage.log

/tmp/packaging.log

/var/log/anaconda/packaging.log

Consejos de bitácora

Si está preguntando proporcionar bitácoras para un bugzilla, la mejor opción es intercambiar desde el IGU anaconda al tty2 y después utilice scp para copiar los archivos a su equipo, p.ej.:

$ cd /tmp
$ scp anaconda.log aklap:/home/akozumpl/
bash

Además es posible crear un volcado completo de un estado de ejecución del proceso anaconda (en mismo volcado que es automáticamente compilado si sucede una excepción no manipulada). Para hacer esto envíe el proceso de anaconda principal SIGUSR2:

$ kill -USR2 `cat /var/run/anaconda.pid``
bash

Esto crea un archivo /tmp/anaconda-tb-????? que además contiene anaconda.log, storage.log y syslog.

Si está en una máquina virtual KVM y no hay disponible scp (stage1), puede (tras configurar la red si no está activa ya) redireccionar a un archivo tcp especial, en hospedaje:

$ nc -l 4444 > syslog.log
bash

en invitado:

$ ifconfig eth0 10.0.2.10/24 up
$ grep "" /tmp/syslog > /dev/tcp/10.0.2.2/4444
bash

Want to help? Learn how to contribute to Fedora Docs ›