Acceso a Anaconda
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
ypackaging.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 dekernel
,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.
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í:
-
Crea una máquina virtual de pruebas, p.e. utilizando Gestor Virtual </li>
-
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>
-
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>
-
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`
-
Inicie la máquina virtual.
-
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 subdirectorio127.0.0.1
.
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 devirtiolog=
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.
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 |
---|---|
|
|
|
|
|
|
|
|
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/
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``
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
en invitado:
$ ifconfig eth0 10.0.2.10/24 up
$ grep "" /tmp/syslog > /dev/tcp/10.0.2.2/4444
Want to help? Learn how to contribute to Fedora Docs ›