En este apéndice, se resumen las herramientas, los consejos y las técnicas para solucionar problemas en ACSLS. El rango de recursos de resolución de problemas incluye logs, puntos de observación clave y sondeos de diagnóstico.
El log de eventos de ACSLS es el punto de partida para obtener información útil en caso de que surjan problemas con el funcionamiento de la biblioteca. Este log incluye información sobre eventos, cambios de estado y errores de la biblioteca. Todos los subcomponentes dentro de ACSLS informarán eventos a acsss_event.log mediante el envío de mensajes a un proceso llamado Event Logger (Registrador de eventos). El log de eventos estándar, que se crea automáticamente cuando se instala ACSLS, está incluido en el archivo $ACS_HOME/log/acsss_event.log, donde $ACS_HOME, por lo general, es /export/home/ACSSS/.
Entre los eventos registrados, se incluyen:
Eventos significativos
Los eventos significativos son eventos normales que pueden ayudar a gestionar la biblioteca. Por ejemplo, se registran eventos cuando se inicia o cancela una auditoría, cuando cambia el estado de un dispositivo o cuando se abre o cierra un CAP.
Errores de biblioteca
Los errores de biblioteca son eventos en los que se registran errores de hardware y software recuperables e irrecuperables. Entre los ejemplos, se incluyen: fallos de LSM, problemas con cartuchos, errores de base de datos, fallos de proceso y fallos de comunicaciones de la biblioteca.
Cada mensajes del log de eventos incluye un registro de hora, el nombre del componente que informa el mensaje y una descripción del evento. Para obtener una explicación completa de cada mensaje, consulte el manual ACSLS Messages (Mensajes de ACSLS).
Una ventana de la consola de ACSLS muestra una cola de ejecución del log de eventos. Puede generar una vista similar a partir de cualquier ventana de shell.
Como usuario acsss, ejecute el siguiente comando:
acs_tail $ACS_HOME/log/acsss_event.log
Para ver todo el log de eventos, use un editor de texto, como vi, que le permite desplazarse por el log, buscar errores específicos o seguir secuencias de eventos específicas.
ACSLS continúa enviando mensaje a acsss_event.log.
Cuando este archivo alcanza un tamaño de umbral (por defecto, 500 KB), el archivo cambia su nombre a event0.log y se guarda en el directorio de logs. Luego, acsss_event.log continúa como un archivo nuevo.
Cuando acsss_event.log alcanza una vez más el tamaño de umbral, event0.log cambia su nombre a event1.log y acsss_event.log cambia su nombre a event0.log.
Este proceso continúa para todos los archivos log configurados para retención.
Por defecto, se retienen nueve archivos de log de eventos en el directorio de logs. Con cada umbral subsiguiente, el archivo más antiguo se elimina y se cambian los nombres de todos los archivos restantes de manera secuencial.
Puede configurar el tamaño máximo de acsss_event.log y la cantidad de archivos log que se deben retener mediante acsss_config, opción 2. Consulte Configuración de variables de ajuste de CSI.
La herramienta de diagnóstico, greplog, le permite realizar búsquedas de palabras clave en la cantidad deseada de archivos de log de eventos. Con un uso muy similar a la utilidad grep de UNIX, greplog devuelve el mensaje de log completo asociado a una expresión de palabra clave determinada. Esto le permite ver el registro de hora de los mensajes, el número de mensaje y el texto de función relacionado con cada mensaje que incluye esa expresión.
-i indica a greplog que omita la distinción de mayúsculas/minúsculas en la expresión del patrón de búsqueda.
-v indica a greplog que filtre todos los mensajes que incluyen la expresión y muestre todas las entradas del archivo log. La excepción son las entradas que coinciden con la expresión del patrón.
pattern (patrón): el patrón son los criterios de búsqueda que se deben utilizar.
file_1 file_2 ... file_n
La herramienta greplog acepta varios parámetros de archivo y expresiones de comodín en la lista de archivos.
Para mostrar todas las incidencias dentro de una secuencia de eventos, use el número de secuencia.
greplog 1392 acsss_event.log
Para buscar todos los mensajes sobre el volumen CART89 en el log de eventos:
greplog CART89 acsss_event.log
Para buscar mensajes sobre montajes de cinta en todas las copias archivadas del log de eventos:
greplog -i mount event*.log
En acsss_event.log, se incluyen todos los mensajes relacionados con cualquier aspecto de los procesos en ejecución de ACSLS. No obstante, hay otros archivos en el directorio de logs que incluyen información de estado sobre las utilidades externas, como las utilidades de copia de seguridad, restauración e instalación.
acsss.pid: almacena el ID del proceso de acsss_daemon que está en ejecución actualmente.
acsss_config.log: incluye un resumen de cada configuración de biblioteca.
acsss_config_event.log: incluye los mensajes de evento que publicó la rutina acsss_config.
bdb_event.log: incluye mensajes de eventos publicó la utilidad de copia de seguridad de base de datos, bdb.acsss.
cron_event.log: incluye mensajes que publicaron las utilidades cron. Para ver el programa de cron, ejecute el comando crontab -l.
acsls_start.log: incluye mensajes de inicio o cierre relacionados con el servicio acsls.
di_trace.log: incluye información de rastreo en relación con la interfaz de base de datos.
ejectingLogs: un directorio que contiene información de resumen de las operaciones ejecting.sh de los últimos diez días.
install.log: incluye mensajes de eventos publicados durante la ejecución de la secuencia de comandos de instalación, install.sh.
ipc_trace.log: incluye información de rastreo vinculada a las comunicaciones entre procesos de ACSLS.
rdb_event.log: incluye mensajes de eventos que publicó la utilidad de restauración de base de datos, rdb.acsss.
timed_bkup.sh.log: incluye mensajes de eventos en relación con la utilidad de copia de seguridad automática de la base de datos.
Es posible encontrar logs de rastreo adicionales en el directorio de logs según el rastreo específico que ha activado en el sistema. Entre los logs, se incluyen los siguientes:
acsss_stats.log: el rastreo de las estadísticas de volumen se activa mediante acsss_config.
acsss_trace.log: el rastreo de cliente-servidor se activa mediante una solicitud del personal de soporte de software.
acslh.log: el rastreo de host-LMU se activa mediante una solicitud del personal de soporte de software.
scsilh.log, mchangerX.log, scsipkt.log: todos incluyen rastreos de comunicaciones SCSI a una biblioteca conectada a SCSI y se activan mediante una solicitud del soporte de software.
Los logs de rastreo que se activan mediante una solicitud del soporte de software pueden crecer bastante rápido. Estos logs deben supervisarse y gestionarse para mitigar los problemas de un disco lleno.
La utilidad monitor.sh se proporciona para llevar a cabo la gestión automática de logs y los servicios de archivo. La sintaxis es la siguiente:
monitor.sh <nombre del log>
Cuando se activa esta utilidad para supervisar un log específico, se permite que el log crezca hasta alcanzar un tamaño de 1 MB (por defecto) y luego se lo comprime mediante gzip y se coloca el archivo log comprimido en el subdirectorio ACSSS/log/log_archives con un nombre que incluye el registro de hora. Esta operación continuará si el rastreo permanece activado.
Los componentes de Java en ACSLS, incluidos los componentes de GUI de ACSLS y del software de biblioteca lógica, mantienen algunos logs. Estos logs se encuentran en el directorio $ACS_HOME/log/sslm.
Los procedimientos de instalación de WebLogic se registran en weblogic.log. Las operaciones de WebLogic y de la GUI de ACSLS se registran en AcslsDomain.log y AdminServer.log.
Se puede encontrar una pista de auditoría de la actividad de usuario en la GUI web en guiAccess.log.
Las transacciones entre los componentes de Java y los componentes de ACSLS heredados se registran en surrogate_trace.0.log.
Los paquetes de IPC entre los componentes del cliente Java y el servidor de ACSLS se rastrean en acslm_ipc_trace.0.log.
Los errores que encuentra la GUI de ACSLS se registran en gui_trace.0.log.
La comunicación de bajo nivel entre el cliente SCSI (de fibra) y SMCE se registra en smce_trace.0.log.
Estos logs se encuentran en el directorio $ACS_HOME/log/sslm.
Hay gran cantidad de utilidades que le permiten verificar el estado de distintos aspectos de ACSLS.
psacs: muestra un resumen de todos los procesos en ejecución de ACSLS. Es la mejor indicación de si ACSLS se está ejecutando o no. Una salida típica no debe mostrar menos de doce procesos diferentes, todos los cuales deben ser procesos secundarios de un proceso principal común.
acsss status: comprueba si se está ejecutando el servicio de base de datos acsdb.
Para mostrar la versión y el nivel de mantenimiento de ACSLS:
Analice acsss_event.log.
Analice acsls_start.log.
Lea el final de acsss_event.log para buscar mensajes que expliquen el problema.
Consulte la Guía de mensajes de ACSLS para obtener una explicación de los mensajes y lo que puede hacer para resolverlos.
Muestre el estado de los servicios de ACSLS con acsss l-status.
Ejecute acsss l-status para mostrar un resumen de estado de los servicios de ACSLS. Para cada servicio, la entrada logfile hace referencia a datos de log que pueden incluir mensajes detallados que expliquen la condición que impidió que se inicie ACSLS.
Se agota el timeout de ACSLS durante el inicio.
En Solaris, para mostrar el período de timeout de inicio de ACSLS calculado según su configuración, use acsss timeout.
ACSLS proporciona utilidades para verificar que existe una buena conexión física a la biblioteca. La herramienta que se debe seleccionar depende especialmente del contexto de la actividad.
Esta utilidad prueba la conexión a cada biblioteca que se ha configurado en StorageTek ACSLS. También es la más fácil de usar y la más completa. La prueba no provoca interrupciones y no afecta las operaciones normales de la biblioteca. Dado que testports usa la base de datos de StorageTek ACSLS para determinar el nombre de puerto de biblioteca y el tipo de biblioteca, la biblioteca ya debe estar configurada en StorageTek ACSLS a fin de que testports funcione.
Para bibliotecas TCP/IP, testports verifica la conexión y si la biblioteca está en línea y en uso por StorageTek ACSLS.
Para bibliotecas conectadas a SCSI y en serie, 'acs' y 'port' deben estar fuera de línea para que testports abra la conexión de prueba.
Para ejecutar esta utilidad, la sintaxis del comando es:
testports
Se muestra el nivel de compatibilidad o de microcódigo de la biblioteca.
Esta utilidad envía un paquete TCP/IP a una biblioteca conectada a la red.
Para probar la conexión de la biblioteca, incluya el nombre de host o la dirección IP de la biblioteca en la línea de comandos:
testlmutcp <ip_address> o
testlmutcp <hostname>
Para probar la conexión mientras la biblioteca está en línea en ACSLS, especifique un número de socket no utilizado entre 50002 y 50016. Por ejemplo:
testlmutcp <ip_address>:50002
Una respuesta correcta incluye el nivel de compatibilidad de la biblioteca conectada.
Esta utilidad puede usarse para probar la conectividad entre ACSLS y las bibliotecas conectadas en serie StorageTek heredadas. Para ejecutar esta utilidad, envíe la ruta de devlink al nodo del dispositivo de puerto serie:
testlmu /dev/term/0
La biblioteca debe estar fuera de línea en ACSLS para que testlmu abra la conexión serie.
Esta utilidad le permite verificar la comunicación entre ACSLS y una biblioteca conectada en serie mientras la biblioteca está en línea en ACSLS. Una respuesta correcta incluye el nivel de compatibilidad de la biblioteca.
Esta utilidad prueba la conexión entre el servidor de ACSLS y una biblioteca conectada por SCSI o fibra. Para ejecutar esta utilidad, especifique la ruta de devlink al dispositivo mchanger. La sintaxis es la siguiente:
probescsi.sh /dev/mchangerX
donde X es la instancia de mchanger específica de la biblioteca que se prueba.
La biblioteca debe estar fuera de línea en ACSLS para que probescsi abra la conexión SCSI. Una respuesta correcta incluye el nivel de microcódigo de la biblioteca conectada.
Esta utilidad descubre todas las bibliotecas conectadas por fibra que son accesibles desde el servidor de ACSLS. La sintaxis es la siguiente:
probeFibre.sh
Una respuesta correcta muestra el número de modelo de cada biblioteca conectada por fibra junto con su destino, los ID de LUN y el World Wide Port Name (WWPN).
Utilice la opción -v para mostrar también el número de modelo del adaptador de bus de host.
probeFibre.sh -v
Esta utilidad revela detalles sobre cada dispositivo mchanger para el que se ha creado un enlace de mchanger.
showDevs.sh
Muestra el modelo de biblioteca, el nivel de revisión y la capacidad de cada biblioteca de mchanger conectada.
showDevs.sh -w
Esta opción también incluye el WWPN de cada biblioteca.
showDevs.sh -s
Esta opción también incluye el número de serie de cada biblioteca.
Las aplicaciones de cliente se comunican con ACSLS mediante TCP/IP usando el protocolo RPC (llamada de procedimiento remoto). Si un sistema cliente no puede comunicarse con ACSLS, se puede usar rpcinfo para probar si ACSLS es accesible desde el equipo cliente.
Desde el servidor de ACSLS, verifique que ACSLS se está ejecutando.
psacs
Desde el servidor de ACSLS, verifique que el daemon de RPC se esté ejecutando.
ps -ef | grep rpc
Desde el servidor de ACSLS, verifique que el número de programa 300031 esté registrado para TCP e IDP.
rpcinfo | grep 300031
Este número de programa confirma que ACSLS se está ejecutando y que ACSLS se ha registrado con RPC.
Desde el equipo cliente, o desde cualquier equipo UNIX de la red, ejecute rpcinfo para intercambiar un paquete con el número de programa 300031 en el servidor de ACSLS.
Especifique la dirección IP del servidor de ACSLS junto con el número de programa.
rpcinfo -t <ip address> 300031
Si el intercambio de comunicación se realiza correctamente, la utilidad rpcinfo muestra el siguiente mensaje:
program 300031 version 1 ready and waiting
program 300031 version 2 ready and waiting
Esto confirma que ACSLS está disponible para las conexiones de cliente en toda la red.
Un CAP de una biblioteca conectada por fibra que está conectada mediante una unidad con puente puede bloquearse cuando una instancia distinta de ACSLS toma el control de la gestión de la biblioteca. Para obtener información detallada acerca de este problema y las soluciones posibles, consulte CAP (ranura de correo) no se abre durante una expulsión en el apéndice de SL150.
Como parte de la llamada de servicio, es posible que el personal de soporte de Oracle le solicite que envíe el juego completo de logs de diagnóstico y otra información de diagnóstico para el análisis. Puede recopilar todos estos datos con un único comando:
get_diags
Cuando esta utilidad haya recopilado toda la información, le solicitará que envíe los datos por correo electrónico o que los ponga a disposición para transferencia manual.
Si decide enviar los datos por correo electrónico directamente desde el equipo ACSLS, asegúrese de que la comunicación por correo electrónico se pueda establecer entre el equipo ACSLS e Internet. Es posible que su empresa tenga un firewall para evitar que el correo electrónico entre directamente desde el equipo de destino. En este caso, puede enviar la información por correo electrónico a su propia casilla dentro de la empresa y luego reenviar los datos de diagnóstico al soporte de Oracle.
De manera alternativa, puede elegir transferir la información manualmente. La utilidad get_diags le aconsejará dónde encontrar los paquetes tar en espera para la transferencia. Por lo general, el área temporal para los datos de diagnóstico es /export/backup/diag/acsss.
SELinux está activado por defecto en Oracle Linux. Más allá del control de acceso de niveles de Unix estándar, SELinux aplica el acceso a los recursos del sistema según el rol del usuario y el dominio de contexto inmediato. Cuando se activa el cumplimiento de SELinux, la capacidad de ACSLS para acceder a su propia base de datos PostgreSQL se anularía sin una política especial que establezca el rol y el contexto de ese acceso.
Cuando instala ACSLS, se cargan tres módulos de política de SELinux en el núcleo: allowPostgr, acsdb y acsdb1. Estos módulos proporcionan definiciones y excepciones de aplicación que son necesarias para que ACSLS tenga acceso a su propia base de datos y a otros recursos del sistema, mientras la aplicación de SELinux está activa. Con estos módulos instalados, debe poder ejecutar las operaciones normales de ACSLS, incluidas las operaciones de la base de datos, como bdb.acsss, rdb.acsss, db_export.sh y db_import.sh, sin la necesidad de desactivar la aplicación de SELinux.
Para permitir actualizaciones de software más rápidas, los módulos de política de SELinux que ACSLS cargó no se eliminan automáticamente cuando desinstala el paquete de ACSLS. Para eliminarlos manualmente, obtenga una lista de los módulos de ACSLS:
# semodule -l | grep acsdb
# semodule -l | grep allowPostgr
Para cada módulo, elimine el módulo de la siguiente manera:
# semodule -r <module name>
Después de instalar ACSLS, si encuentra problemas relacionados con el acceso, y el sistema responde 'permission denied' aunque la configuración de permisos de archivo tradicional parece válida, es posible que el origen de la denegación de acceso sea SELinux.
Para verificar la aplicación de SELinux está activada, ejecute el comando sestatus.
# sestatus SELinux status: enabled Current mode: enforcing
Puede desactivar la aplicación de SELinux temporalmente usando el comando: setenforce:
# setenforce Permissive
Con la aplicación de SELinux en el modo permisivo, ahora puede comprobar si se puede restaurar el acceso al recurso con errores. Si el recurso necesario está disponible para el usuario autorizado en el modo permisivo pero no en el modo de aplicación, esto sugiere la necesidad de una política de SELinux actualizada.
Para desactivar la seguridad de SELinux de forma permanente (entre inicios):
Edite el archivo: /etc/selinux/config
Cambie SELINUX=enforcing por SELINUX=permissive.
Para volver a activar la aplicación de SELinux, root debe tener el rol sysadm_r.
# newrole -r sysadm_r # setenforce enforcing
Después de haber verificado que SELinux era la causa de la restricción aparente, puede ver las reglas específicas que impidieron el acceso al recurso necesario observando el log de auditoría de SELinux.
# vi /var/log/audit/audit.log
En audit.log, se proporciona un resumen sobre cada intento de acceso que finalizó correctamente o no la aplicación de SE. Debe analizar los eventos que no finalizaron correctamente. Para ACSLS, observe específicamente los eventos relacionados con los usuarios acsss y acsdb.
Puede ver los atributos de contexto de SELinux asociados a cualquier archivo o directorio determinado:
# ls -Z <file name>
Puede ver los atributos de contexto de un proceso dado o los del shell actual usando el comando secon. Es posible cambiar los atributos de contexto de un archivo o directorio usando el comando chcon. Consulte las páginas del comando man para estas operaciones.
Es posible crear un módulo de política en respuesta a las operaciones con errores encontradas en audit.log.
# cd /var/log/audit # audit2allow -a -M <ModuleName>
Esto evalúa los fallos que registró SELinux y crea un archivo de módulo de política <ModuleName>.pp. Este archivo ahora puede cargarse en el núcleo de Linux para permitir las operaciones que se habían bloqueado.
# semodule -i <ModuleName>.pp
Dado que audit2allow crea una política que activa todas las restricciones identificadas en audit.log, se recomienda asegurarse de que audit.log incluya solo las operaciones que desea permitir específicamente. Puede guardar el archivo audit.log original y crear uno nuevo.
# mv audit.log audit1.log # touch audit.log
Continúe con las operaciones que desea capturar antes de crear un módulo de política para ellas.
Para obtener más información sobre SELinux, consulte la página del comando man:
# man selinux
La utilidad checkGui.sh comprueba los factores comunes para evaluar si la GUI funciona correctamente. En el caso de que la GUI no funcione, esta utilidad puede ofrecer orientación a los usuarios respecto de la causa probable del problema.
Esta utilidad comprueba lo siguiente:
¿WebLogic está activado en el sistema?
¿Hay procesos fantasma o desactualizados que puedan impedir el funcionamiento de WebLogic?
¿Se desplegó correctamente la aplicación SlimGUI?
¿WebLogic y la GUI pueden responder a una solicitud http enviada al host local?
¿WebLogic puede responder a una solicitud http enviada a la dirección de Internet del host?
¿El servicio de firewall está activado en el servidor? De ser así, ¿existe una política para aceptar las solicitudes entrantes a los puertos 7001 y 7002 de WebLogic?
En sistemas Linux, puede descubrir que el firewall llamado iptables está activado por defecto. Puede desactivar iptables por completo o puede agregar una política para aceptar el tráfico entrante a los puertos 7001 y 7002.
Para activar estos puertos (como root), edite el archivo /etc/sysconfig/iptables. Agregue las siguientes dos líneas:
-A INPUT -p tco --dport 7001 -j ACCEPT -A INPUT -p tco --dport 7002 -j ACCEPT
Asegúrese de no insertar estas reglas después de otra regla que coincida con los paquetes entrantes antes de analizarlos. Por ejemplo, no las agregue al final de una cadena de iptables después de una regla REJECT all.
Si está usando el comando iptables para agregar estas reglas:
Enumere (iptables -L) o imprima (iptables -S) la tabla.
Agregue las reglas.
Si solo agrega (iptables –A) las reglas al final de una cadena, es posible que no se logre el resultado deseado, dado que las reglas previas pueden evitar que las reglas nuevas coincidan con alguna entrada.
Puede insertar la regla (iptables -I) mediante rulenum.
Enumere (iptables -L) o imprima (iptables -S) la tabla después del cambio y asegúrese de que las reglas existentes no impidan que se analicen las reglas nuevas para los puertos 7001 y 7002.
Esto garantiza que las reglas nuevas puedan coincidir con un paquete entrante.
La utilidad checkGui.sh comprueba la existencia de reglas ACCEPT para aceptar la entrada en los puertos 7001 y 7002. No verifica que estas reglas estén en la cadena de iptables adecuada ni si las reglas nuevas realmente se procesan. En otras palabras, checkGui.sh no verifica que no haya reglas previas que impidan el análisis de las reglas nuevas.
Reinicie iptables:
service iptables restart
Un servicio similar de Solaris es ipfilter, que no suele estar activado por defecto.
En la tabla siguiente, se proporcionan algunos consejos para la resolución de problemas de la GUI.
Tabla J-1 Consejos de resolución de problemas de la GUI
| Problema | Solución |
|---|---|
|
Introduje https://<hostname> en el navegador, pero la página de respuesta indica "Unable to connect" (No se puede establecer la conexión). |
La URL correcta es: https://hostname.domain:7002/SlimGUI/faces/Slim.jsp. |
|
La página de la GUI de ACSLS está incompleta. Algunos marcos están incompletos o faltan secciones enteras. |
Haga clic en el botón de refrescamiento del navegador. |
|
Java WebLogic rechaza un ID de usuario y una contraseña que sé que son válidos. No puedo iniciar sesión. |
Consulte a su administrador de ACSLS local. Si es el administrador, use la utilidad userAdmin.sh para mostrar los usuarios, agregar un usuario o cambiar la contraseña de un usuario. Si los usuarios continúan teniendo problemas para iniciar sesión, compruebe si el sistema tiene memoria suficiente y luego reinicie la GUI de ACSLS con la opción 5 de userAdmin.sh. Como alternativa, puede reiniciar WebLogic usando svcadm disable weblogic y svcadm enable weblogic. |
|
Se muestra un rastreo de pila de error de Java en una o más ventanas de la GUI. |
Pulse el botón de refrescamiento del navegador. Si el problema persiste, ejecute Si los servicios no se están ejecutando, actívelos mediante Si los servicios de ACSLS se están ejecutando, reinicie la GUI mediante userAdmin.sh. Como alternativa, puede reiniciar WebLogic mediante svcadm disable weblogic y svcadm enable weblogic. Si no tiene acceso |
|
Falta la selección de "Logical Libraries" (Bibliotecas lógicas) en el marco del árbol de índice. |
Primero debe crear una biblioteca lógica. Seleccione: Configuration and Administration (Configuración y administración) -> Logical Library Configuration (Configuración de biblioteca lógica) -> Create Logical Library (Crear biblioteca lógica). |
|
No se muestran volúmenes en la página Volumes (Volúmenes) en Tape Library Operations (Operaciones de biblioteca de cintas) ni en Tape Libraries & Drives (Unidades y bibliotecas de cintas). |
Esta es una indicación de que la auditoría inicial no se ha llevado a cabo para la biblioteca. Seleccione: Tape Library Operations (Operaciones de biblioteca de cintas) -> Audit (Auditoría) |
|
No se muestran volúmenes en la página Volumes (Volúmenes) en Logical Libraries (Bibliotecas lógicas). |
Este es un signo de que todavía no se han asignado volúmenes a la biblioteca lógica. Seleccione: Logical Library Configuration (Configuración de biblioteca lógica) -> Assign Volumes (Asignar volúmenes). |
|
El tiempo de respuesta de la GUI es excesivo. |
Aumente el intervalo de actualización de alertas en el botón Preferences (Preferencias) de la cabecera de la GUI. |
|
Necesito agregar usuarios de GUI, cambiar las contraseñas de usuarios de GUI o establecer la contraseña de |
Consulte userAdmin.sh. Esta utilidad le permite agregar usuarios y cambiar las contraseñas de usuario, y le indica cómo restablecer la contraseña de |
|
El navegador requiere un certificado de seguridad. |
Consulte Configuración de un certificado digital autofirmado para HTTPS |