SUSE anunció SLES 16.0 el 4 de noviembre de 2025, con SELinux reemplazando a AppArmor como marco de control de acceso obligatorio predeterminado. Si su servidor ejecuta SLES 16, no dé por sentado que AppArmor está instalado o activo: confirme el marco compatible con esa implementación antes de usar estos comandos. El procedimiento que se describe a continuación sigue la documentación de AppArmor de SUSE para SLES 15 SP7, donde AppArmor está instalado y en ejecución de forma predeterminada.
En SLES 15 SP7, la ruta práctica para una aplicación personalizada consiste en aa-genprofcrear un perfil inicial, probar la aplicación en modo de queja, revisar cada solicitud registrada y, finalmente, confirmar que el perfil se está aplicando correctamente. El ejemplo utiliza un ejecutable hipotético en /usr/local/bin/report-worker; reemplácelo con la ruta real del ejecutable de su aplicación.
Los perfiles de AppArmor son políticas de texto almacenadas en /etc/apparmor.d. El apparmor-utilspaquete proporciona las herramientas de creación de perfiles. Compruebe el host e identifique el ejecutable real, incluyendo si una unidad systemd inicia un proceso contenedor o un proceso hijo:
sudo aa-status
command -v aa-genprof
systemctl status apparmor
readlink -f /usr/local/bin/report-worker
SUSE indica que AppArmor está habilitado por defecto en las instalaciones de SLES 15. Si faltan las herramientas o el patrón completo de AppArmor, instálelo con sudo zypper in -t pattern apparmor. Si AppArmor no está activo, averigüe la causa antes de crear un perfil, en lugar de asumir que un archivo de perfil por sí solo proporciona protección. Un perfil se adjunta a una ruta ejecutable; crear un perfil de un contenedor cuando la carga de trabajo real se ejecuta como otro binario puede dejar el proceso importante sin protección.
Inicie el generador. Detenga la aplicación si ya se está ejecutando y, a continuación, inicie la generación del perfil:
sudo systemctl stop report-worker
sudo aa-genprof /usr/local/bin/report-worker
El nombre del servicio es un ejemplo. Use el nombre real de la unidad o omita el comando de parada si el programa no se está ejecutando. aa-genprofCrea un perfil aproximado cuando no existe, lo pone en modo de queja (aprendizaje), lo recarga y marca el registro. El modo de queja registra las solicitudes que no cumplen con la política, pero las permite; es un estado de aprendizaje temporal, no de aplicación de la normativa.
Simula el comportamiento de una aplicación real. Mantén el generador abierto. En otra terminal, inicia el servicio y ejecuta trabajos o funciones representativas:
sudo systemctl start report-worker
sudo journalctl -f
Cubre el inicio normal, las rutas de entrada y salida esperadas, las tareas programadas, el manejo de errores y cualquier programa auxiliar que la aplicación inicie. Un perfil solo puede aprender las solicitudes generadas durante la prueba. No uses cargas de trabajo sensibles a la producción solo para generar eventos; es preferible un entorno de prueba seguro y datos de prueba representativos.
Revise cada solicitud de acceso. Vuelva a la pantalla anterior aa-genprofy pulse Spara escanear el rango de registros marcado. Para cada solicitud, determine si la aplicación realmente necesita ese archivo, capacidad o transición de programa secundario. Permita la ruta y el permiso útiles más limitados. Acepte una abstracción cuando cubra con precisión una tarea común; utilice un patrón solo cuando los archivos coincidentes compartan los mismos requisitos de confianza y acceso. Deniegue u omita las solicitudes que sean incidentales o inexplicables.
Preste especial atención a la ejecución de las solicitudes. Una transición sin restricciones puede permitir que un elemento secundario eluda la política del elemento principal; úsela solo cuando exista una necesidad de diseño justificada. Repita el ejercicio y el ciclo de escaneo después de agregar reglas legítimas. Cuando el perfil cubra el comportamiento probado, finalice el generador. SUSE indica que completar un nuevo aa-genprofciclo de aprendizaje normalmente activa el modo de aplicación del perfil.
Inspeccione la política generada. Para esta ruta de ejemplo, la convención de nomenclatura de SUSE convierte las barras diagonales en la ruta del ejecutable en puntos, produciendo /etc/apparmor.d/usr.local.bin.report-worker. Revise el resultado en lugar de tratar las reglas generadas como automáticamente seguras:
sudo less /etc/apparmor.d/usr.local.bin.report-worker
Verifique que el perfil nombre el ejecutable previsto, utilice las inclusiones necesarias y otorgue acceso únicamente a la configuración, los datos, los registros, los sockets y los programas auxiliares que la aplicación realmente necesita. Evite reglas generales, como el acceso sin restricciones a un /árbol de directorios completo o a todo un árbol de directorios con permisos de escritura, solo para evitar una denegación. La aplicación sigue dependiendo de la propiedad y los permisos habituales de Unix; AppArmor añade una capa de restricción independiente.
Establezca explícitamente el modo deseado. Tras la revisión, aplique el perfil al programa personalizado:
sudo aa-enforce /usr/local/bin/report-worker
Si editaste el perfil manualmente después de que el generador finalizara, vuelve a cargar el conjunto de perfiles con sudo systemctl reload apparmor. Los documentos de SUSE se recargan como perfiles que vuelven a escanear sin liberar los procesos en ejecución. Reinicia el servicio de la aplicación para que la nueva política se aplique a su proceso.
Vuelva a ejecutar las mismas tareas representativas mientras el perfil esté en modo de aplicación. Confirme que el servicio se inicia, lee las entradas previstas, escribe la salida esperada y puede realizar las operaciones auxiliares o de red necesarias. A continuación, inspeccione tanto el estado del perfil como los mensajes recientes del kernel.
sudo aa-status
sudo journalctl -k -g apparmor --since today
El ejecutable personalizado debería aparecer como cargado y en modo de aplicación. Las denegaciones de AppArmor en el registro del kernel identifican las solicitudes que la política bloqueó; úselas para diagnosticar un fallo real de la aplicación, no como motivo para permitir todas las rutas registradas. Para un permiso faltante legítimo, ejecute sudo aa-logprof, revise la sugerencia, actualice la regla de forma específica, recargue si la editó manualmente y vuelva a ejecutar la ruta de la aplicación afectada.
Para un servicio en ejecución continua cuyo análisis de rendimiento debe abarcar reinicios o periodos de observación prolongados, SUSE documenta un flujo de trabajo sistémico independiente que utiliza aa-autodepescaneos aa-complainrepetidos aa-logprof. El método independiente aa-genprofes más sencillo cuando la ejecución de aprendizaje puede permanecer abierta durante toda la prueba. Ninguno de los flujos de trabajo puede inferir el comportamiento de la aplicación que nunca se ha probado, por lo que es importante revisar el perfil cuando se produzcan cambios en el software o la configuración.
Configure Nextcloud para que elimine los archivos borrados después de un período de retención definido, programe tareas en segundo plano de forma fiable y evite comandos que vacíen la papelera de todos los usuarios.
Ejecuta la reparación de OCC de Nextcloud de forma segura, previsualiza los cambios en la base de datos y comprueba por qué persiste la advertencia.
Permita la carga de archivos más grandes en el navegador Nextcloud alineando la configuración de PHP, Nginx o Apache, el almacenamiento temporal y el tiempo de espera, y verifique qué límite está bloqueando el archivo.
Establezca el límite de memoria PHP que Nextcloud utiliza realmente, reinicie el servicio correcto y confirme la configuración de 512 MB en la Vista general de administración.
Monta un bucket de almacenamiento de objetos compatible en Nextcloud utilizando su backend S3, con el punto final, las credenciales, el ámbito de acceso y los pasos de verificación correctos.
Traslada de forma segura un directorio de datos de Linux Nextcloud a una unidad externa utilizando un montaje UUID persistente, el modo de mantenimiento, una copia verificada y el enlace simbólico de la ruta original.
Restaure el acceso a Nextcloud después de una actualización diagnosticando errores SQL, comprobando la conectividad de la base de datos y completando de forma segura las migraciones interrumpidas.
Utilice el comando OCC de Nextcloud para restablecer la contraseña de administrador desde la consola del servidor, con instrucciones sobre nombres de usuario, permisos y proveedores de inicio de sesión externos.
Elimine la advertencia HSTS de Nextcloud configurando el encabezado en Apache, NGINX o su proxy TLS, y luego verifique la respuesta HTTPS pública de forma segura.
Identificar los fallos de instalación de la App Store y determinar si se deben a problemas de DNS, HTTPS, proxy, TLS o configuración del propio servidor Nextcloud.
