23 Preguntas de Práctica de Resolución de problemas: arranque, almacenamiento y permisos con Respuestas

1. 1. El servicio web de un servidor de la familia dpkg falla desde primera hora de la mañana. `journalctl -u nginx -xe` llena la pantalla con una sola línea repetida: `nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)`. El administrador necesita la entrada que inició la secuencia de fallos, no la más reciente. ¿Qué enfoque la encuentra?

   • A.Ejecutar `journalctl -u nginx -p err --since 05:00` y leer primero la entrada más antigua de esa ventana.✓ Respuesta
   • B.Ejecutar `journalctl -xe` otra vez y bajar hasta el final, porque esa última línea nombra el fallo de origen.
   • C.Ejecutar `journalctl --vacuum-size=100M` antes, para que los registros antiguos de la unidad quepan en una página.
   • D.Ejecutar `systemctl restart nginx` y leer solo lo que aparezca después, porque los registros previos ya caducaron.

   El journal se escribe en orden cronológico, así que el primer error de una ventana suele ser la causa y lo posterior es consecuencia. `-u` limita la salida a esa unidad, `-p err` descarta el ruido informativo y `--since` acota la ventana, mientras que `-xe` salta a propósito a la entrada más nueva, que aquí es solo la última repetición del síntoma.

   Ref. QB-SYDJHMFuente: journalctl(1) manual page: --unit, --priority and --since/--until filteringReportar un problema con esta pregunta

2. 2. Se informa que una unidad de systemd está caída. `systemctl status billing.service` muestra: ``` Active: failed (Result: exit-code) since Tue 03:14:07 UTC; 21min ago Main PID: 1841 (code=exited, status=1/FAILURE) Tue 01:02:55 host systemd[1]: Started Billing API. Tue 03:14:07 host systemd[1]: billing.service: Main process exited, code=exited, status=1/FAILURE ``` ¿Qué establece esta evidencia?

   • A.La unidad nunca ejecutó ExecStart, así que la ruta del programa indicada en el archivo de unidad es errónea.
   • B.La unidad arrancó bien y corrió dos horas antes de que su proceso saliera con fallo; hay que leer el log de la aplicación.✓ Respuesta
   • C.La unidad no está habilitada al arranque, así que systemd la detuvo al pasar la máquina a su target por defecto.
   • D.La unidad quedó frenada por una dependencia Requires= que nunca subió, así que hay que arrancar esa dependencia.

   Las marcas de tiempo separan los dos casos: systemd registró `Started` a las 01:02 y el proceso principal salió a las 03:14, así que el arranque funcionó y el programa murió después por su cuenta. Una unidad que no logra arrancar nunca registra `Started` y su estado nombra la etapa que falló en lugar de un PID principal que salió, así que hay que mirar el log de la aplicación.

   Ref. QB-9G8DXKFuente: systemctl(1) and systemd.service(5) manual pages: Active state, Result and main process exit reportingReportar un problema con esta pregunta

3. 3. En un servidor de la familia RPM, /var está lleno. `df -h /var` informa 0 disponible, `df -i /var` informa un 6% de inodos usados, `du -sh /var/log/*` informa un único archivo de 38G en /var/log/app/app.log, `ls /etc/logrotate.d` no tiene ninguna entrada para esa aplicación y `lsof +L1 /var` no devuelve nada. ¿A qué apunta la evidencia?

   • A.El log de la aplicación nunca tuvo una regla de rotación y creció sin límite; añádale una configuración de logrotate.✓ Respuesta
   • B.Los inodos de /var se agotaron, así que la escritura falla aunque queden bloques libres; hay que recrear el sistema.
   • C.Un archivo borrado sigue abierto por un proceso, así que el espacio vuelve en cuanto se reinicie ese proceso.
   • D.El journal superó su límite de tamaño, así que `journalctl --vacuum-size=1G` es lo que recupera el espacio.

   Cada causa rival queda descartada por una pieza de la evidencia: el 6% de inodos descarta el agotamiento de inodos, un `lsof +L1` vacío descarta un archivo borrado pero abierto, y `du` señala un log normal en disco y no el journal. Un archivo de log solo deja de crecer cuando una regla de rotación lo renombra, lo comprime y lo caduca, así que un archivo sin entrada en /etc/logrotate.d crece hasta llenar el sistema de archivos.

   Ref. QB-RY28CKFuente: logrotate(8) manual page: rotation rules in /etc/logrotate.conf and /etc/logrotate.dReportar un problema con esta pregunta

4. 4. Un administrador que revisa un host con systemd ejecuta `journalctl -b -p warning`. ¿Qué registros devuelve ese comando?

   • A.Solo los registros de severidad exactamente warning, filtrando los de error y los críticos.
   • B.Los registros de severidad warning y de toda severidad más grave que ella, hasta emergency.✓ Respuesta
   • C.Solo los registros de unidades cuyo archivo de unidad fija un umbral warning, en este arranque.
   • D.Los registros de severidad warning y por debajo, incluyendo notice, informativos y de depuración.

   `-p` fija un techo y no una coincidencia exacta: el journal conserva la escala clásica de severidades de syslog, donde emergency es la más grave y debug la menor, y pedir un nivel devuelve ese nivel y todo lo más grave. `-b` restringe la salida al arranque actual, que es como se separan los fallos de este arranque de los de uno anterior.

   Ref. QB-8GV2SJFuente: journalctl(1) manual page: --priority and the syslog severity levels it acceptsReportar un problema con esta pregunta

5. 5. En un servidor de la familia dpkg, un administrador fija `GRUB_CMDLINE_LINUX_DEFAULT="quiet elevator=none"` en /etc/default/grub y reinicia, pero `cat /proc/cmdline` sigue mostrando los parámetros antiguos. ¿Por qué?

   • A.El comando de regeneración en esta familia es `grub2-mkconfig -o /boot/grub2/grub.cfg`, y no se ejecutó.
   • B.La configuración generada del gestor de arranque nunca se reconstruyó; `update-grub` escribe el nuevo ajuste.✓ Respuesta
   • C.Los parámetros del kernel solo surten efecto tras `systemctl daemon-reload`, que relee la configuración de arranque.
   • D./etc/default/grub rige solo las entradas de rescate; las normales exigen editar a mano /boot/grub/grub.cfg.

   /etc/default/grub es un archivo de entrada, no el que lee el gestor de arranque: un generador lo convierte en la configuración propia del gestor, y hasta que ese generador se ejecuta sigue arrancando el archivo generado antiguo. En la familia dpkg el envoltorio es `update-grub`; el archivo generado no se edita a mano porque la siguiente regeneración lo sobrescribe.

   Ref. QB-QYPV6JFuente: GNU GRUB manual and grub-mkconfig(8); the update-grub wrapper on dpkg-based distributionsReportar un problema con esta pregunta

6. 6. Tras mover el sistema de archivos raíz a un nuevo volumen lógico LVM en un servidor de la familia RPM, el arranque se detiene con `ALERT! /dev/mapper/vg0-root does not exist. Dropping to a shell!` y un prompt `(initramfs)`. Arrancando desde el medio de instalación, el volumen y su sistema de archivos están intactos. ¿Cuál es la causa más probable y su arreglo?

   • A.La entrada del menú de arranque nombra el dispositivo equivocado; hay que editar a mano /boot/grub2/grub.cfg.
   • B.El sistema de archivos del volumen está corrupto; ejecute `xfs_repair` desde el prompt `(initramfs)`.
   • C.El sistema de archivos inicial en RAM carece de lo necesario para activar el volumen; reconstrúyalo con `dracut --force`.✓ Respuesta
   • D.La entrada raíz de /etc/fstab usa un nombre de dispositivo y no un UUID; corríjala con el valor de `blkid`.

   El propio prompt localiza el fallo: el kernel y el sistema de archivos inicial en RAM se cargaron y corrieron, así que el gestor de arranque está bien, pero el código de esa imagen no pudo ensamblar el dispositivo que contiene la raíz. Activar una raíz sobre LVM, RAID o cifrado exige los módulos y herramientas dentro de la imagen, y añadir esa capa después de la instalación obliga a regenerarla antes del siguiente arranque.

   Ref. QB-7GHQKHFuente: dracut(8) manual page: regenerating the initramfs so required modules are present at bootReportar un problema con esta pregunta

7. 7. Se añadió una entrada de disco de datos a /etc/fstab y ese disco se recreó más tarde. El servidor arranca ahora en `Welcome to emergency mode!` y el journal muestra `Timed out waiting for device /dev/disk/by-uuid/3f2a9c1e-...`, `Dependency failed for /data.` y `Dependency failed for Local File Systems.` ¿Qué debe hacer el administrador?

   • A.Leer el identificador real con `blkid`, corregir la entrada de /etc/fstab y verificar con `mount -a` antes de reiniciar.✓ Respuesta
   • B.Reconstruir el sistema de archivos inicial en RAM con `dracut --force`, porque el montaje falló antes de PID 1.
   • C.Añadir `noexec,nosuid` a la entrada de /data para que el montaje fallido se omita y el arranque siga su curso.
   • D.Ejecutar `fsck` sobre el dispositivo de datos desde el shell de emergencia, porque ese modo indica corrupción.

   Recrear el disco le dio un identificador nuevo, así que la entrada de la tabla de montaje apunta a algo que ya no existe, el target de sistemas de archivos locales falla y PID 1 recurre al shell de emergencia. `blkid` informa el identificador que el dispositivo tiene ahora y `mount -a` procesa toda la tabla en el momento, que es como se comprueba la corrección antes de que un reinicio dependa de ella. La opción que evita que un dispositivo opcional tumbe el arranque es `nofail`, no las de endurecimiento.

   Ref. QB-PYBJZGFuente: fstab(5) and mount(8) manual pages: device identifiers, the nofail option, and mount -aReportar un problema con esta pregunta

8. 8. Tras actualizar el kernel en un servidor de la familia RPM, el arranque termina en `Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)`. El menú de GRUB sigue listando el kernel anterior y su initramfs. Hay que restaurar el servicio ya. ¿Cuál es la primera acción?

   • A.Elegir la entrada del kernel anterior en el menú de arranque para restaurar el servicio y luego revisar el initramfs.✓ Respuesta
   • B.Añadir `systemd.unit=emergency.target` a la entrada del kernel nuevo para llegar a un shell y reparar unidades.
   • C.Reinstalar el sistema operativo desde el medio, porque un panic previo a PID 1 no deja configuración recuperable.
   • D.Arrancar el medio de instalación en modo rescate y restablecer la contraseña de root, ya que el panic bloquea el acceso.

   Este panic ocurre antes de que exista el espacio de usuario, así que no hay target, unidad ni solicitud de contraseña alcanzable y añadir un target de systemd no cambia nada. Los gestores de paquetes conservan el kernel anterior y su imagen inicial en RAM como entradas de menú justo para poder volver atrás eligiendo la entrada previa, lo que restaura el servicio y deja el par averiado disponible para repararlo.

   Ref. QB-EGZ2TSFuente: GNU GRUB manual, menu entry selection; Linux kernel root filesystem mount panic messagesReportar un problema con esta pregunta

9. 9. Se desconoce la contraseña de root en un servidor de la familia RPM que usa dracut y tiene SELinux en modo enforcing, y ninguna otra cuenta tiene sudo. El administrador tiene acceso a la consola en el menú de GRUB. ¿Qué secuencia la restablece?

   • A.Arrancar normalmente y ejecutar `passwd root` desde cualquier sesión, porque la consola es un terminal de confianza.
   • B.Añadir `systemd.unit=rescue.target` y ejecutar después `passwd` en el shell que el target de rescate presenta.
   • C.Añadir `selinux=0` y vaciar el segundo campo de la línea de root en /etc/passwd para no exigir contraseña.
   • D.Añadir `rd.break`, remontar /sysroot en lectura-escritura, `chroot /sysroot`, ejecutar `passwd` y `touch /.autorelabel`.✓ Respuesta

   Interrumpir el arranque antes de entregar la raíz real da un shell que no pide credenciales, y esa raíz está en /sysroot, que empieza en solo lectura y hay que remontar en lectura-escritura antes de cambiar el archivo de contraseñas. Escribirlo desde el entorno de arranque lo deja con el contexto de seguridad equivocado, así que el archivo indicador que pide un reetiquetado en el siguiente arranque es lo que mantiene el sistema usable; el target de rescate no sirve porque pide justo la contraseña que falta.

   Ref. QB-WYTV7SFuente: dracut.cmdline(7) manual page (rd.break), passwd(1), and the SELinux /.autorelabel relabel flagReportar un problema con esta pregunta

10. 10. La entrega de correo en una instancia en la nube falla con `No space left on device`: ``` $ df -h /var/spool Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg0-spool 20G 8.2G 11G 44% /var/spool $ df -i /var/spool Filesystem Inodes IUsed IFree IUse% Mounted on /dev/mapper/vg0-spool 1310720 1310720 0 100% /var/spool ``` ¿Qué muestra esta evidencia?

    • A.El sistema de archivos se remontó en solo lectura tras un error de E/S, que el kernel informa como falta de espacio.
    • B.Un archivo borrado sigue abierto, por eso `df` y `du` discrepan; el espacio vuelve al reiniciar quien lo retiene.
    • C.Los inodos de ese sistema de archivos se agotaron, así que no se crea ningún archivo aunque queden bloques libres.✓ Respuesta
    • D.Al volumen lógico no le quedan extents libres, así que el sistema de archivos ya no puede asignar bloques nuevos.

    Un sistema de archivos contabiliza bloques e inodos por separado, y cada archivo, directorio o enlace simbólico consume un inodo sea cual sea su tamaño, así que un spool lleno de mensajes diminutos puede quedarse sin inodos con casi toda su capacidad libre. El error `No space left on device` cubre ambas escaseces, y por eso `df -i` es el paso que las distingue; en un sistema cuyo número de inodos se fija al crearlo, las únicas curas reales son borrar archivos o recrearlo mayor.

    Ref. QB-7M8USMFuente: df(1) manual page: --inodes reporting, and inode allocation fixed at filesystem creationReportar un problema con esta pregunta

11. 11. /var está lleno en un servidor de la familia dpkg: ``` $ df -h /var /dev/sda3 50G 47G 0 100% /var $ du -sh /var 9.8G /var $ sudo lsof +L1 /var COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME rsyslogd 912 root 7w REG 8,3 39421337600 0 418 /var/log/syslog.1 (deleted) ``` ¿Cómo se recupera el espacio?

    • A.Ejecutar otra vez `rm -f /var/log/syslog.1`, porque la entrada de directorio sobrevivió al primer borrado.
    • B.Ejecutar `fsck` sobre /var en el siguiente reinicio para corregir el recuento de bloques que `df` y `du` discuten.
    • C.Agrandar el sistema de archivos con `lvextend -r`, porque el uso que informa `df` es real y permanente.
    • D.Reiniciar rsyslogd para que se libere el descriptor del archivo borrado y el kernel libere esos bloques.✓ Respuesta

    Desenlazar un archivo solo borra su entrada de directorio; el inodo y sus bloques sobreviven mientras algún proceso mantenga un descriptor abierto, que es justo la entrada con `NLINK 0` que `+L1` está pensada para mostrar. `df` cuenta esos bloques porque el sistema de archivos sigue reteniéndolos y `du` no ve un archivo sin nombre, así que la brecha se cierra solo cuando el proceso que lo retiene libera el descriptor al reiniciarse.

    Ref. QB-Q4EZCNFuente: lsof(8) manual page: +L link-count selection for unlinked open files; unlink(2) semanticsReportar un problema con esta pregunta

12. 12. Los usuarios de /data en un servidor de la familia RPM informan `Read-only file system` aunque son dueños de los archivos y el modo es 0775. `dmesg` termina con: ``` blk_update_request: critical medium error, dev sdb, sector 41945280 EXT4-fs error (device sdb1): ext4_journal_check_start:83: Detected aborted journal EXT4-fs (sdb1): Remounting filesystem read-only ``` ¿Cuál es la causa?

    • A.El directorio perdió su bit de ejecución, que el kernel informa a quien escribe como sistema de solo lectura.
    • B.El kernel encontró errores de medio y abortó el journal, así que remontó el sistema de archivos en solo lectura.✓ Respuesta
    • C.La entrada de /etc/fstab lleva la opción `ro`, así que `mount -o remount,rw /data` devuelve la escritura al volumen.
    • D.Una denegación de SELinux bloquea las escrituras y `restorecon -Rv /data` devolvería el contexto correcto.

    Un error de sistema de archivos en solo lectura no es una decisión de permisos: el kernel retiró todo el sistema de archivos del servicio de escritura después de que la capa de bloques devolviera un error de medio y el journal dejara de ser fiable, que es el comportamiento protector que pide una política de error de remontar en solo lectura. Los bits de permiso, las opciones de montaje y el control de acceso obligatorio darían `Permission denied`, y aquí el arreglo empieza por el dispositivo averiado.

    Ref. QB-6MVGMKFuente: mount(8) manual page (ext4 errors=remount-ro) and the ext4 administration documentation in the Linux kernel treeReportar un problema con esta pregunta

13. 13. Una alerta de almacenamiento señala md0 en un servidor de la familia dpkg: ``` $ cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdc1[2](F) sdb1[0] 2930134016 blocks super 1.2 [2/1] [U_] ``` ¿Qué muestra esto y qué viene después?

    • A.Ambos miembros están fuera de línea y los datos son inalcanzables, así que restaure el volumen desde la copia.
    • B.El arreglo se está resincronizando tras un reinicio; espere a que termine la reconstrucción antes de tocar los miembros.
    • C.La versión de metadatos no coincide con este kernel, así que hay que detener el arreglo y reensamblarlo a mano.
    • D.Un miembro está marcado como defectuoso y el espejo corre degradado; confirme con `mdadm --detail` y añada un reemplazo.✓ Respuesta

    Tres detalles de esa línea concuerdan: el sufijo `(F)` marca al miembro que el kernel dio por fallado, `[2/1]` dice que hay uno de dos miembros esperados y `[U_]` dibuja un dispositivo activo y uno ausente. El arreglo sigue sirviendo datos sin redundancia, así que lo correcto es identificar con precisión el miembro fallado y añadir un dispositivo sano para que el espejo se reconstruya; una resincronización en curso mostraría además una línea de recuperación con porcentaje.

    Ref. QB-P43P7MFuente: mdadm(8) manual page and the md driver documentation in the Linux kernel tree: /proc/mdstat status fieldsReportar un problema con esta pregunta

14. 14. En un servidor de la familia RPM: ``` $ sudo lvextend -L +5G /dev/vg0/data Insufficient free space: 1280 extents needed, but only 0 available $ sudo vgs VG #PV #LV #SN Attr VSize VFree vg0 1 3 0 wz--n- 99.00g 0 ``` ¿Qué tiene que ocurrir primero?

    • A.Ejecutar `lvextend -r` para que el sistema de archivos cambie junto al volumen y libere los extents.
    • B.Ejecutar `xfs_growfs /data` primero, ya que el sistema de archivos debe reclamar espacio antes.
    • C.Ejecutar `pvresize` sobre el miembro actual, reservando más extents de los metadatos del grupo.
    • D.Añadir capacidad al grupo primero: `pvcreate` un dispositivo nuevo, luego `vgextend vg0` y extender.✓ Respuesta

    Un volumen lógico solo puede extenderse con extents que su grupo de volúmenes ya tenga libres, y un `VFree` de cero dice que el grupo no tiene ninguno que dar, así que ninguna opción del comando de extensión fabrica capacidad. El orden que añade capacidad va de abajo hacia arriba: inicializar un volumen físico nuevo, unirlo al grupo y después extender el volumen lógico y agrandar su sistema de archivos.

    Ref. QB-9MXG5QFuente: lvextend(8), vgextend(8) and pvcreate(8) manual pages: extent allocation within a volume groupReportar un problema con esta pregunta

15. 15. Un servidor de la familia RPM registra corrupción de metadatos XFS en /data, un sistema de archivos XFS sobre /dev/vg0/data. El administrador desmonta /data, ejecuta `xfs_growfs /data` y obtiene `xfs_growfs: /data is not a mounted XFS filesystem`. ¿Cuál es el manejo correcto?

    • A.Montar /data primero y ejecutar `xfs_repair` sobre el punto de montaje, porque la herramienta necesita metadatos vivos.
    • B.Ejecutar `fsck.xfs /dev/vg0/data`, que hace la comprobación completa de metadatos que `xfs_repair` omite a propósito.
    • C.Reparar con `xfs_repair /dev/vg0/data` mientras sigue desmontado; solo agrandar exige que esté montado.✓ Respuesta
    • D.Encoger el sistema de archivos con `xfs_growfs -D` para descartar la región dañada y luego agrandarlo ya montado.

    Las dos operaciones tienen requisitos opuestos, y de ahí viene el error: una reparación reescribe metadatos y debe poseer el sistema de archivos en exclusiva, así que se ejecuta sobre el dispositivo sin nada montado, mientras que agrandar es una operación en línea que se hace por el punto de montaje de un sistema vivo. XFS además solo crece en una dirección y no se puede encoger, y el ayudante `fsck.xfs` existe solo para satisfacer la comprobación de arranque y no hace nada.

    Ref. QB-S45PQQFuente: xfs_repair(8), xfs_growfs(8) and fsck.xfs(8) manual pages: mount-state requirementsReportar un problema con esta pregunta

16. 16. Un volumen nuevo se particionó como /dev/sdc1 en un servidor de la familia dpkg. `mount /dev/sdc1 /srv/data` devuelve `mount: /srv/data: wrong fs type, bad option, bad superblock on /dev/sdc1, missing codepage or helper program, or other error`, y `blkid /dev/sdc1` no imprime nada. ¿Cuál es la causa más probable?

    • A.La tabla de particiones es MBR y el volumen excede lo que MBR direcciona, así que hay que convertirla a GPT.
    • B.El punto de montaje /srv/data no existe, y mount informa un directorio ausente como superbloque erróneo.
    • C.No se ha creado ningún sistema de archivos en la partición, así que no hay superbloque ni tipo que mount encuentre.✓ Respuesta
    • D.El módulo del kernel para ese sistema de archivos no está cargado, así que `modprobe` debe insertarlo antes.

    La evidencia decisiva es el `blkid` silencioso: esa herramienta informa la firma que un sistema de archivos escribe en su superbloque, así que sin salida no hay firma y por tanto no hay sistema de archivos en la partición. Particionar solo reserva espacio; hay que crear el sistema de archivos con el comando `mkfs` adecuado antes de que cualquier montaje funcione, y un punto de montaje ausente da otro mensaje que nombra el directorio.

    Ref. QB-8MK6YNFuente: mount(8), mkfs(8) and blkid(8) manual pages: superblock detection and filesystem signaturesReportar un problema con esta pregunta

17. 17. Un integrante del grupo analysts informa un fallo: ``` $ ls -l /data/reports/q3.csv -rw-r--r--. 1 root analysts 18422 Sep 2 09:11 /data/reports/q3.csv $ ls -ld /data/reports drw-r-----. 2 root analysts 4096 Sep 2 09:10 /data/reports $ cat /data/reports/q3.csv cat: /data/reports/q3.csv: Permission denied ``` ¿Cuál es la causa?

    • A.El grupo no tiene permiso de ejecución en el directorio, así que la ruta no puede recorrerse hasta el archivo.✓ Respuesta
    • B.Un contexto de SELinux en el archivo bloquea la lectura, y `restorecon -v` sobre él lo repararía.
    • C.El archivo es legible por otros pero no por el grupo, así que la entrada de grupo niega a analysts.
    • D.El directorio tiene el atributo inmutable, que `lsattr` muestra y `chattr -i` podría quitar.

    En un directorio, el bit de ejecución significa el derecho a recorrerlo y resolver un nombre dentro de él, y es distinto del de lectura, que solo permite listar los nombres. Aquí el campo de grupo del directorio es `r--`, así que un integrante de analysts puede listar el directorio pero no atravesarlo, y el modo generoso del archivo nunca entra en juego; la comprobación de recorrido se aplica a cada directorio de la ruta.

    Ref. QB-R4SBJPFuente: chmod(1) manual page and POSIX file permission semantics: directory search (execute) permissionReportar un problema con esta pregunta

18. 18. En un servidor web de la familia RPM con SELinux en enforcing, /srv/www/upload tiene modo 0777 y pertenece a apache:apache, pero las subidas fallan con `Permission denied`. /var/log/audit/audit.log contiene `avc: denied { write } for pid=2210 comm="httpd" name="upload" scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=dir`. ¿Cuál es el arreglo correcto?

    • A.Ejecutar `chcon -t httpd_sys_rw_content_t` en el directorio, el único cambio que sobrevive al próximo reetiquetado.
    • B.Ejecutar `setenforce 0` para detener la denegación y anotarlo en /etc/selinux/config para que sobreviva al reinicio.
    • C.Registrar el contexto esperado con `semanage fcontext -a -t` y aplicarlo luego con `restorecon -Rv` en esa ruta.✓ Respuesta
    • D.Ampliar el modo de forma recursiva y añadir la cuenta apache al grupo wheel para que se permita la escritura.

    Un modo amplio con el dueño correcto y aun así una denegación es la firma del control de acceso obligatorio, y el registro de auditoría dice qué combinación se rechazó: un proceso del dominio del servidor web escribiendo en un directorio con tipo por defecto. El arreglo duradero declara el tipo esperado de esa ruta en la política local y después reetiqueta la ruta, porque un reetiquetado manual se descarta en el siguiente reetiquetado del sistema de archivos, y apagar el modo enforcing quita la protección en vez de corregir la etiqueta.

    Ref. QB-BMN6GSFuente: semanage-fcontext(8) and restorecon(8) manual pages; SELinux audit AVC denial recordsReportar un problema con esta pregunta

19. 19. Trabajando como root en un servidor de la familia RPM: ``` # echo "nameserver 10.0.0.53" >> /etc/resolv.conf -bash: /etc/resolv.conf: Operation not permitted # lsattr /etc/resolv.conf ----i---------e------- /etc/resolv.conf ``` ¿Qué lo explica y qué lo elimina?

    • A.El archivo pertenece a otro usuario, así que hay que corregir la propiedad con `chown root:root` antes de escribir.
    • B.El atributo inmutable está puesto y bloquea incluso a root hasta que `chattr -i` lo quita del archivo.✓ Respuesta
    • C.Hay una denegación de SELinux en vigor, y `restorecon -v` sobre el archivo lo devuelve al contexto que espera la política.
    • D.El sistema de archivos raíz está montado en solo lectura, y `mount -o remount,rw /` devuelve el acceso de escritura.

    Dos pistas descartan por completo el modelo de permisos: el error es `Operation not permitted` y no `Permission denied`, y `lsattr` muestra la marca `i` en la cadena de atributos. Un archivo inmutable no puede modificarse, renombrarse, borrarse ni recibir enlaces nuevos por ningún usuario, root incluido, y solo un proceso con la capacidad de cambiar atributos puede quitar la marca, que es lo que hace `chattr -i` antes de reintentar la edición.

    Ref. QB-U4UB3TFuente: chattr(1) and lsattr(1) manual pages: the immutable attributeReportar un problema con esta pregunta

20. 20. La cuenta deploy no puede escribir un archivo cuya ACL dice: ``` $ getfacl /srv/app/config.yml # owner: root # group: root user::rw- user:deploy:rw- #effective:r-- group::r-- mask::r-- other::r-- ``` ¿Qué lo explica y qué lo arregla?

    • A.La entrada nombrada nunca se aplicó, así que hay que ejecutar `setfacl -m u:deploy:rw` sobre el archivo otra vez.
    • B.Falta una ACL por defecto en el directorio padre, así que hay que fijar `setfacl -d -m u:deploy:rw` en él.
    • C.La entrada `other` prevalece sobre las nombradas, así que `chmod o+w` en el archivo es lo que da escritura a deploy.
    • D.La máscara de la ACL limita las entradas nombradas a lectura; súbala con `setfacl -m m::rw /srv/app/config.yml`.✓ Respuesta

    La máscara es un límite superior para cada entrada de usuario nombrado, cada entrada de grupo nombrado y la entrada del grupo propietario, así que un permiso concedido que la máscara no incluye queda registrado pero inutilizable. `getfacl` lo deja explícito con el comentario `#effective:`, que aquí muestra la escritura concedida a deploy y luego recortada por una máscara de solo lectura, así que subir la máscara es lo que activa la concesión existente.

    Ref. QB-P96A2JFuente: acl(5) and setfacl(1) manual pages: the mask entry and effective permissionsReportar un problema con esta pregunta

21. 21. En un servidor de la familia RPM, un programa de un proveedor debe ejecutarse con los privilegios de su dueño, pero corre sin privilegios: ``` $ ls -l /opt/tools/bin/netcheck -rwsr-xr-x. 1 root root 48120 Aug 14 10:02 /opt/tools/bin/netcheck $ findmnt /opt TARGET SOURCE FSTYPE OPTIONS /opt /dev/mapper/vg0-opt xfs rw,nosuid,nodev,relatime ``` ¿Cuál es la causa?

    • A.Al programa le falta el bit set-user-ID y hay que restaurarlo con `chmod u+s` sobre el archivo.
    • B.El sistema de archivos está montado con `nosuid`, y esa opción hace que el kernel ignore el bit set-user-ID.✓ Respuesta
    • C.SELinux está confinando el programa, y `setsebool -P` en el booleano correspondiente lo dejaría correr.
    • D.El programa está en XFS, y XFS no guarda el bit set-user-ID en los metadatos que almacena del archivo.

    La `s` en el campo del dueño prueba que el bit está puesto en el archivo, así que no es el bit lo que falta; la decisión se toma un nivel más arriba, en el montaje. Un sistema de archivos montado con `nosuid` indica al kernel que desatienda los bits set-user-ID y set-group-ID de todo lo que contiene, que es una decisión deliberada de endurecimiento, así que el programa debe mudarse a otro montaje o cambiarse la opción por política.

    Ref. QB-6SY4FHFuente: mount(8) manual page: the nosuid mount option and set-user-ID handlingReportar un problema con esta pregunta

22. 22. El inicio de sesión por clave en un servidor de la familia RPM vuelve a pedir contraseña. /var/log/secure registra `Authentication refused: bad ownership or modes for directory /home/deploy/.ssh`. `ls -ld` de ese directorio muestra `drwxrwxr-x` y `authorized_keys` muestra `-rw-rw-r--`. ¿Qué debe corregirse?

    • A.Generar un par de claves más largo para la cuenta, porque el servidor rechazó el algoritmo que ofreció el cliente.
    • B.Poner PasswordAuthentication en no en sshd_config, con lo que el servidor aceptará la clave que acaba de rechazar.
    • C.Poner el directorio en 700 y authorized_keys en 600, porque StrictModes rechaza rutas escribibles por el grupo.✓ Respuesta
    • D.Añadir la cuenta a AllowUsers en sshd_config, porque el servidor rechaza las claves de cuentas no listadas ahí.

    La línea del log nombra la comprobación que falló y no la clave en sí: con la comprobación estricta activada, el servidor no confía en un archivo de claves cuyo directorio o propiedad pueda alterar alguien distinto del dueño, porque una ruta escribible por el grupo permitiría a otra cuenta instalar su propia clave. Ajustar el directorio y el archivo a acceso exclusivo del dueño restaura la confianza, y volver a pedir contraseña es la consecuencia normal de que la clave se ignore.

    Ref. QB-N9TXUGFuente: sshd_config(5) and sshd(8) manual pages: StrictModes ownership and mode checks on ~/.sshReportar un problema con esta pregunta

23. 23. En un servidor de la familia RPM, /etc/sudoers.d/devops.conf contiene `%devops ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart app`. El archivo tiene modo 0440 y dueño root, `visudo -c` no informa errores de sintaxis y el usuario pertenece a devops, pero `sudo -l` no lista la regla. ¿Cuál es la causa más probable?

    • A.El nombre del archivo lleva un punto, y sudo omite los complementos con punto o que acaban en tilde.✓ Respuesta
    • B.El grupo debe escribirse `devops ALL=(ALL)` sin el signo de porcentaje, que en cambio marca un alias de host.
    • C.NOPASSWD no puede combinarse con una ruta de comando concreta, así que la regla se analiza y se descarta.
    • D.La regla necesita `systemctl daemon-reload` antes de que sudo relea el directorio de complementos en su caché.

    La inclusión del directorio de complementos ignora a propósito cualquier archivo cuyo nombre contenga un punto o acabe en tilde, para que las copias de paquetes y los restos del editor no cambien en silencio las reglas de privilegio. El archivo aquí es sintácticamente válido y tiene el dueño correcto, por eso el verificador no se queja, pero nunca se lee; renombrarlo sin el punto activa la regla y `sudo -l` la lista.

    Ref. QB-5SMS9GFuente: sudoers(5) manual page: #includedir and drop-in file names that are ignoredReportar un problema con esta pregunta

Preguntas de práctica redactadas según los objetivos publicados del examen CompTIA Linux+ y la práctica estándar de administración de Linux. CompTIA y Linux+ son marcas de CompTIA, y Linux es una marca registrada de Linus Torvalds; este sitio no está afiliado ni respaldado por CompTIA. El examen real combina preguntas de opción múltiple con preguntas basadas en desempeño que piden ejecutar una tarea en un entorno simulado: eso no puede reproducirse en un formato de cuatro opciones, así que este banco cubre la mitad teórica y conviene practicar en un sistema real en paralelo. CompTIA revisa y numera las versiones de los objetivos periódicamente: confirma los objetivos, el código de examen y los requisitos vigentes con CompTIA antes de examinarte. Sobre la certificación CompTIA Linux+ →