Otro excelente tutorial que encontramos en la sección de Tutoriales de nuestro Foro, de la mano de SuperYo
Ayer descubrí por las malas una de las “features” del sistema de archivos btrfs. Se trata de que por motivos que desconozco de su funcionamiento, btrfs tiende a llenar más el disco de lo que suelen indicar comandos como dd o los medidores de llenado de disco de los gestores de archivos habituales.
Quien tenga un sistema de archivos con btrfs podrá saber cuánto espacio adicional están ocupando sus datos escribiendo en consola (como root creo):
btrfs filesystem show /
(Sustituir / por otro punto de montaje si se que quisiera saber el espacio ocupado en otra partición btrfs)
En una partición grande este llenado adicional no supone un gran problema, pues es muy poco espacio comparado con el total. Pero en mi caso, donde / tiene 22GB (ocupa un ssd cache), se me llenó el disco duro con 8 GB libres, rompiendo las bases de datos rpm e inutilizando por ello el gestor de paquetes. Por lo que me vi obligado a formatear con otro sistema de archivos.
Pero no quería reinstalar. Está claro que se pueden conservar fácilmente los datos de /home, pero uno tiene muchos programas instalados en / y muchas configuraciones que también residen allí, así que decidí simplemente conservar la instalación pero cambiar el sistema de archivos.
La razón por la que escribo esto es porque no encontré nada de documentación acerca de cómo proceder en estos casos. Supongo que la mayoría de gente se conforma con reinstalar.
Tuve que estar como unas 7 horas buscando y rebuscando información en manuales en inglés que en realidad tenían que ver con otras cosas y juntando piezas intuitivamente; prueba y error todo el rato, reiniciando decenas de veces para comprobar que cada cosa que intentaba fracasaba una tras otra. Cuando el proceso en realidad no hubiera sido para tanto de haber dispuesto de un manual dedicado a ello.
Vamos pues a ello.
Primero: Yo realicé este procedimiento en Fedora. Supongo que vale igual para todas las distribuciones que compartan principalmente el tener como gestor de arranque GRUB2.
Segundo: Este proceso es difícil para el usuario común (los que lean esto y piensen que es una chorrada sabed que no sois usuarios comunes) La gente suele tener cosas mejores que hacer que cambiar el sistema de archivos de la partición raíz. Si no sabéis seguir este manual corréis el riesgo de perder vuestra instalación, y si conseguís llevarlo a cabo descubriréis que el cambio de rendimiento no es tan espectacular (Bueno, para algunos sí, pero no sois usuarios comunes) Yo en concreto lo hice por necesidad, aunque he de reconocer que soy de los que le ponen que su ordenador inicie un segundo más rápido.
Tercero: Como este procedimiento no es para usuarios comunes, supondré que el lector posee algunos conocimientos de GNU/Linux y que no le va a dar pereza buscar más información.
Ya queráis cambiar el sistema de archivos por necesidad o por aburrimiento, este es el procedimiento:
1.- Es obvio que para que nuestro nuevo sistema de archivos funcione tenemos que tener las herramientas que nos ayuden a manejarlo, así que es lo primero que haremos. El sistema de archivos que escogí por cierto, fue xfs, así que me tocó instalar “xfsprogs” y “xfsdump”. Vosotros instalaréis lo que os toque en función del sistema de archivos que queráis usar.
2.- Iniciar desde un livecd/usb y copiar todo el contenido de la partición raíz a otra partición o disco. El método que elijáis no importa, pero lo suyo es hacerlo con privilegios de root, para no encontrarse con archivos o directorios con permisos especiales.
3.- El paso donde propiamente se formatea “/” con el sistema de archivos que prefiramos. Hay multitud de métodos, elegid el que más os guste.
4.- Se restaura la copia que hicimos de la partición raíz a la partición recién formateada.
5.- Es el momento en el que el usuario tiene que empezar a poner de su parte. Al formatear la partición se modifica un identificador que usa el sistema operativo para saber qué partición tiene que montar. Esto es el UUID, y necesitamos conocer ese código.
Hay múltiples métodos, pero por ejemplo, en “Gparted”, lo sabremos haciendo click derecho sobre la nueva partición “/” y haciendo click en “Información”. Ese código lo copiamos y es cuando nos vamos a editar el archivo /etc/fstab:
UUID=36f3ce91-5138-4293-8571-b5b43f6b4646 / xfs defaults,noatime,discard,nobarrier
Esto es un ejemplo en el que aparece la línea que corresponde a mi flamante nueva partición raíz. El código que aparece a la derecha de UUID= es lo que sustituiremos por nuestro UUID.
Una vez que lo hayamos hecho, por supuesto tenemos que indicar el nuevo sistema de archivos de nuestra partición, xfs en mi caso o sustituidla por la vuestra en el caso de que sea otro sistema de archivos. También tenéis que poner las nuevas opciones de montaje: Si no sabéis que poner, poned “defaults”; noatime aumenta el rendimiento al disminuir las escrituras, discard disminuye las escrituras en los discos ssd, aumentando su longevidad.
6.- Aquí empieza lo jodido de verdad y es donde me atasqué. En realidad no es tan difícil, pero no hay casi documentación a partir de este punto.
Necesitamos reconstruir el menú de Grub para que inicie correctamente el sistema operativo. No sabría cómo hacerlo a mano, lo podéis intentar como yo lo hice (cambiado UUIDs y tal) pero lo normal será que el inicio del SO se detenga en una agradable y esperanzadora “emergency shell”
Afortunadamente, grub2 posee la herramienta “grub2-mkconfig” que realiza automáticamente esta tarea tomando como referencia las características del sistema donde se esté ejecutando. El problema es que, mira por donde, el sistema donde se está ejecutando no es el sistema del destino, y este último esta temporalmente fuera de servicio.
Por ello necesitamos hacer chroot y montar una serie de particiones especiales para ejecutar esta herramienta, sin las cuales no funciona. El procedimiento para hacer esto está mal explicado en casi todos sitios (lo cual no significa que no lo sepan hacer, si no que se piensan que somos supercracks de la computación)
Por suerte aquí: http://askubuntu.com/questions/28099/ho … ll-kernels encontré una explicación cojonudísima acerca del tema, que paso a resumir y a traducir:
mount /dev/sda1 /mnt
mount --bind /dev /mnt/dev
Donde “sda1″ se sustituye por la correspondiente a la partición raíz, si no es “sda1″
mount /dev/sda2 /mnt/boot
Donde “sda2″ se sustituye por la correspondiente a la partición boot, si no es “sda2″
El montaje de efi no viene en el link de arriba, es cosa mía pero en este caso lo necesitaba. Si no tenéis partición EFI, no hagáis caso de esto.
mount /dev/sda3 /mnt/boot/efi
Donde “sda3″ se sustituye por la correspondiente a la partición boot, si no es “sda3″
chroot /mnt
mount -t proc none /proc
mount -t sysfs none /sys
mount -t devpts none /dev/pts
export HOME=/root
export LC_ALL=C
Esto es añadido mío, puede ser necesario para una cosa más adelante:
mount -t tmpfs tmpfs /run
7.- grub2-mkconfig
Pues es el momento estrella casi. Tenemos que buscar un archivo que se llama “grub.cfg” dentro de la partición boot. En mi caso su ruta es /boot/efi/EFI/fedora/grub.cfg
Cuando lo hayamos encontrado, corremos en el entorno chroot:
grub2-mkconfig -o /ruta/a/grub.cfg
Y ya tenemos el menú de grub listo por fin.
8.- Regenerar el initramfs.
Este paso creo que es necesario, pero no estoy estrictamente seguro. No obstante, basta con reinstalar el kernel que queramos o con ejecutar:
dracut --force /ruta/al/archivo/initramfs/que/queramos/sustituir
por ejemplo:
dracut --force /boot/initramfs-3.15.9-200.fc20.x86_64.img
Por supuesto, todo esto dentro del entorno chroot. (y si no, vuelta a la casilla de salida, estoo… a la “emergency shell”)
PD: Se me olvidó poner lo que hay que hacer para tener acceso a Internet en el entorno chroot, por si queréis reinstalar el kernel. En el link de arriba se explica muy bien: Tenéis que abrir una nueva terminal y copiar estos archivos:
cp /mnt/etc/hosts /mnt/etc/hosts.old
cp /etc/hosts /mnt/etc/hosts
cp /etc/resolv.conf /mnt/etc/resolv.conf
9.- Obtener acceso a internet:
Simplemente hay que copiar los siguientes archivos, gráficamente o mediante consola, en este último caso fuera del entorno chroot. Se puede hacer desde otra terminal o bien saliendo del entorno chroot, y luego volviendo a entrar.
cp /mnt/etc/hosts /mnt/etc/hosts.old
cp /etc/hosts /mnt/etc/hosts
cp /etc/resolv.conf /mnt/etc/resolv.conf
10.- Reinstalar el kernel:
Reinstalamos el kernel dentro del entorno chroot con nuestro gestor de paquetes
11.- REINICIAAAR:
D
Este punto debería de ser el final para distribuciones “normales”, para distribuciones con SELinux, como es mi caso, la cosa se alargó un poco más.
A pesar de que el inicio llegaba hasta el final y trataba de iniciar el sistema gráfico, no lo hacía, y cuando trataba de loguearme como usuario o como root me soltaba “permission denied”.
Leí algo al respecto y según una persona el problema podía ser de selinux, y sugirió poner selinux=0 al final de una línea de arranque en grub.cfg, de esta manera:
menuentry 'Fedora, with Linux 3.15.9-200.fc20.x86_64' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.15.9-200..fc20.x86_64-advanced-36f3ce91-5138-4293-8571-b5b43f6b4646' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
set root='hd1,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 --hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2 1cd04509-ab7c-4074-8bab-e170c29fe08e
else
search --no-floppy --fs-uuid --set=root 1cd04509-ab7c-4074-8bab-e170c29fe08e
fi
linuxefi /vmlinuz-3.15.9-200.fc20.x86_64 root=UUID=36f3ce91-5138-4293-8571-b5b43f6b4646 ro rd.md=0 rd.lvm=0 rd.dm=0 vconsole.keymap=es rd.luks=0 vconsole.font=latarcyrheb-sun16 rhgb quiet selinux=0
initrdefi /initramfs-3.15.9-200.fc20.x86_64.img
Fijaos en la penúltima línea a la derecha del todo.
Yo no lo hice directamente, si no que simplemente edité la entrada de arranque en el propio menú de grub, de manera que fuese una modificación temporal, creo que se hacía pulsando “c” o “e”, en el menú de grub os lo pone.
Pues hacemos eso y reiniciamos, o continuamos con el arranque.
12.- La luz al final del túnel.
Si no pudimos en el paso anterior directamente, es en este penúltimo paso donde podremos acceder a nuestro escritorio habitual. Un brindis por nuestra gran hazaña, pero si SELinux ha fastidiado, aún no hemos acabado.
Tenemos que volver a editar el grub.cfg para quitar el “selinux=0″ o simplemente volver a reiniciar normalmente si lo que hemos hecho ha sido editar la entrada en el menú de grub. El caso es que reiniciamos con SELinux activado.
Entonces al terminar el inicio sale algo de que tiene que reetiquetar la política de SELinux targeted, le dejamos solito y al terminar se reiniciará.
Veremos que nuestro sistema se iniciará, mostrando nuestro escritorio habitual, con SELinux activado, nuestro sistema de archivos cambiado y todos nuestros programas plenamente funcionales.
Este es el fin del manual, espero que os sirva
ACTUALIZACIÓN: Cuando hice esto por primera vez no tenía ni idea e hice el paso de regenerar el initramfs y luego reinstalé el kernel y fue todo muy lioso y al final funcionó casi sin saber por qué, y di ambas opciones por igual de buenas, sin embargo regenerar el initramfs no sirve y lo he tachado. Lo único que vale es reinstalar el kernel (intuyo que los paquetes kernel y kernel-core en Fedora) y así he modificado el manual.
Y también quiero añadir que para cambiar el formato del sistema de archivos de la partición /home son necesarios los mismos pasos, no sé si lo de selinux es necesario, pero si no funciona con selinux se quita temporalmente y ya está.
Imagen destacada tomada de acá.
Continúar leyendo...
Ayer descubrí por las malas una de las “features” del sistema de archivos btrfs. Se trata de que por motivos que desconozco de su funcionamiento, btrfs tiende a llenar más el disco de lo que suelen indicar comandos como dd o los medidores de llenado de disco de los gestores de archivos habituales.
Quien tenga un sistema de archivos con btrfs podrá saber cuánto espacio adicional están ocupando sus datos escribiendo en consola (como root creo):
btrfs filesystem show /
(Sustituir / por otro punto de montaje si se que quisiera saber el espacio ocupado en otra partición btrfs)
En una partición grande este llenado adicional no supone un gran problema, pues es muy poco espacio comparado con el total. Pero en mi caso, donde / tiene 22GB (ocupa un ssd cache), se me llenó el disco duro con 8 GB libres, rompiendo las bases de datos rpm e inutilizando por ello el gestor de paquetes. Por lo que me vi obligado a formatear con otro sistema de archivos.
Pero no quería reinstalar. Está claro que se pueden conservar fácilmente los datos de /home, pero uno tiene muchos programas instalados en / y muchas configuraciones que también residen allí, así que decidí simplemente conservar la instalación pero cambiar el sistema de archivos.
La razón por la que escribo esto es porque no encontré nada de documentación acerca de cómo proceder en estos casos. Supongo que la mayoría de gente se conforma con reinstalar.
Tuve que estar como unas 7 horas buscando y rebuscando información en manuales en inglés que en realidad tenían que ver con otras cosas y juntando piezas intuitivamente; prueba y error todo el rato, reiniciando decenas de veces para comprobar que cada cosa que intentaba fracasaba una tras otra. Cuando el proceso en realidad no hubiera sido para tanto de haber dispuesto de un manual dedicado a ello.
Vamos pues a ello.
Primero: Yo realicé este procedimiento en Fedora. Supongo que vale igual para todas las distribuciones que compartan principalmente el tener como gestor de arranque GRUB2.
Segundo: Este proceso es difícil para el usuario común (los que lean esto y piensen que es una chorrada sabed que no sois usuarios comunes) La gente suele tener cosas mejores que hacer que cambiar el sistema de archivos de la partición raíz. Si no sabéis seguir este manual corréis el riesgo de perder vuestra instalación, y si conseguís llevarlo a cabo descubriréis que el cambio de rendimiento no es tan espectacular (Bueno, para algunos sí, pero no sois usuarios comunes) Yo en concreto lo hice por necesidad, aunque he de reconocer que soy de los que le ponen que su ordenador inicie un segundo más rápido.
Tercero: Como este procedimiento no es para usuarios comunes, supondré que el lector posee algunos conocimientos de GNU/Linux y que no le va a dar pereza buscar más información.
Ya queráis cambiar el sistema de archivos por necesidad o por aburrimiento, este es el procedimiento:
1.- Es obvio que para que nuestro nuevo sistema de archivos funcione tenemos que tener las herramientas que nos ayuden a manejarlo, así que es lo primero que haremos. El sistema de archivos que escogí por cierto, fue xfs, así que me tocó instalar “xfsprogs” y “xfsdump”. Vosotros instalaréis lo que os toque en función del sistema de archivos que queráis usar.
2.- Iniciar desde un livecd/usb y copiar todo el contenido de la partición raíz a otra partición o disco. El método que elijáis no importa, pero lo suyo es hacerlo con privilegios de root, para no encontrarse con archivos o directorios con permisos especiales.
3.- El paso donde propiamente se formatea “/” con el sistema de archivos que prefiramos. Hay multitud de métodos, elegid el que más os guste.
4.- Se restaura la copia que hicimos de la partición raíz a la partición recién formateada.
5.- Es el momento en el que el usuario tiene que empezar a poner de su parte. Al formatear la partición se modifica un identificador que usa el sistema operativo para saber qué partición tiene que montar. Esto es el UUID, y necesitamos conocer ese código.
Hay múltiples métodos, pero por ejemplo, en “Gparted”, lo sabremos haciendo click derecho sobre la nueva partición “/” y haciendo click en “Información”. Ese código lo copiamos y es cuando nos vamos a editar el archivo /etc/fstab:
UUID=36f3ce91-5138-4293-8571-b5b43f6b4646 / xfs defaults,noatime,discard,nobarrier
Esto es un ejemplo en el que aparece la línea que corresponde a mi flamante nueva partición raíz. El código que aparece a la derecha de UUID= es lo que sustituiremos por nuestro UUID.
Una vez que lo hayamos hecho, por supuesto tenemos que indicar el nuevo sistema de archivos de nuestra partición, xfs en mi caso o sustituidla por la vuestra en el caso de que sea otro sistema de archivos. También tenéis que poner las nuevas opciones de montaje: Si no sabéis que poner, poned “defaults”; noatime aumenta el rendimiento al disminuir las escrituras, discard disminuye las escrituras en los discos ssd, aumentando su longevidad.
6.- Aquí empieza lo jodido de verdad y es donde me atasqué. En realidad no es tan difícil, pero no hay casi documentación a partir de este punto.
Necesitamos reconstruir el menú de Grub para que inicie correctamente el sistema operativo. No sabría cómo hacerlo a mano, lo podéis intentar como yo lo hice (cambiado UUIDs y tal) pero lo normal será que el inicio del SO se detenga en una agradable y esperanzadora “emergency shell”
Afortunadamente, grub2 posee la herramienta “grub2-mkconfig” que realiza automáticamente esta tarea tomando como referencia las características del sistema donde se esté ejecutando. El problema es que, mira por donde, el sistema donde se está ejecutando no es el sistema del destino, y este último esta temporalmente fuera de servicio.
Por ello necesitamos hacer chroot y montar una serie de particiones especiales para ejecutar esta herramienta, sin las cuales no funciona. El procedimiento para hacer esto está mal explicado en casi todos sitios (lo cual no significa que no lo sepan hacer, si no que se piensan que somos supercracks de la computación)
Por suerte aquí: http://askubuntu.com/questions/28099/ho … ll-kernels encontré una explicación cojonudísima acerca del tema, que paso a resumir y a traducir:
- Montar / y /dev:
mount /dev/sda1 /mnt
mount --bind /dev /mnt/dev
Donde “sda1″ se sustituye por la correspondiente a la partición raíz, si no es “sda1″
- Montar /boot y /boot/efi , este último si teníamos partición EFI.
mount /dev/sda2 /mnt/boot
Donde “sda2″ se sustituye por la correspondiente a la partición boot, si no es “sda2″
El montaje de efi no viene en el link de arriba, es cosa mía pero en este caso lo necesitaba. Si no tenéis partición EFI, no hagáis caso de esto.
mount /dev/sda3 /mnt/boot/efi
Donde “sda3″ se sustituye por la correspondiente a la partición boot, si no es “sda3″
- Chroot y algunas cosillas más, que en realidad lo único que sé de esas cosillas es que son necesarias:
chroot /mnt
mount -t proc none /proc
mount -t sysfs none /sys
mount -t devpts none /dev/pts
export HOME=/root
export LC_ALL=C
Esto es añadido mío, puede ser necesario para una cosa más adelante:
mount -t tmpfs tmpfs /run
7.- grub2-mkconfig
Pues es el momento estrella casi. Tenemos que buscar un archivo que se llama “grub.cfg” dentro de la partición boot. En mi caso su ruta es /boot/efi/EFI/fedora/grub.cfg
Cuando lo hayamos encontrado, corremos en el entorno chroot:
grub2-mkconfig -o /ruta/a/grub.cfg
Y ya tenemos el menú de grub listo por fin.
8.- Regenerar el initramfs.
Este paso creo que es necesario, pero no estoy estrictamente seguro. No obstante, basta con reinstalar el kernel que queramos o con ejecutar:
dracut --force /ruta/al/archivo/initramfs/que/queramos/sustituir
por ejemplo:
dracut --force /boot/initramfs-3.15.9-200.fc20.x86_64.img
Por supuesto, todo esto dentro del entorno chroot. (y si no, vuelta a la casilla de salida, estoo… a la “emergency shell”)
PD: Se me olvidó poner lo que hay que hacer para tener acceso a Internet en el entorno chroot, por si queréis reinstalar el kernel. En el link de arriba se explica muy bien: Tenéis que abrir una nueva terminal y copiar estos archivos:
cp /mnt/etc/hosts /mnt/etc/hosts.old
cp /etc/hosts /mnt/etc/hosts
cp /etc/resolv.conf /mnt/etc/resolv.conf
9.- Obtener acceso a internet:
Simplemente hay que copiar los siguientes archivos, gráficamente o mediante consola, en este último caso fuera del entorno chroot. Se puede hacer desde otra terminal o bien saliendo del entorno chroot, y luego volviendo a entrar.
cp /mnt/etc/hosts /mnt/etc/hosts.old
cp /etc/hosts /mnt/etc/hosts
cp /etc/resolv.conf /mnt/etc/resolv.conf
10.- Reinstalar el kernel:
Reinstalamos el kernel dentro del entorno chroot con nuestro gestor de paquetes
11.- REINICIAAAR:
DEste punto debería de ser el final para distribuciones “normales”, para distribuciones con SELinux, como es mi caso, la cosa se alargó un poco más.
A pesar de que el inicio llegaba hasta el final y trataba de iniciar el sistema gráfico, no lo hacía, y cuando trataba de loguearme como usuario o como root me soltaba “permission denied”.
Leí algo al respecto y según una persona el problema podía ser de selinux, y sugirió poner selinux=0 al final de una línea de arranque en grub.cfg, de esta manera:
menuentry 'Fedora, with Linux 3.15.9-200.fc20.x86_64' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.15.9-200..fc20.x86_64-advanced-36f3ce91-5138-4293-8571-b5b43f6b4646' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
set root='hd1,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 --hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2 1cd04509-ab7c-4074-8bab-e170c29fe08e
else
search --no-floppy --fs-uuid --set=root 1cd04509-ab7c-4074-8bab-e170c29fe08e
fi
linuxefi /vmlinuz-3.15.9-200.fc20.x86_64 root=UUID=36f3ce91-5138-4293-8571-b5b43f6b4646 ro rd.md=0 rd.lvm=0 rd.dm=0 vconsole.keymap=es rd.luks=0 vconsole.font=latarcyrheb-sun16 rhgb quiet selinux=0
initrdefi /initramfs-3.15.9-200.fc20.x86_64.img
Fijaos en la penúltima línea a la derecha del todo.
Yo no lo hice directamente, si no que simplemente edité la entrada de arranque en el propio menú de grub, de manera que fuese una modificación temporal, creo que se hacía pulsando “c” o “e”, en el menú de grub os lo pone.
Pues hacemos eso y reiniciamos, o continuamos con el arranque.
12.- La luz al final del túnel.
Si no pudimos en el paso anterior directamente, es en este penúltimo paso donde podremos acceder a nuestro escritorio habitual. Un brindis por nuestra gran hazaña, pero si SELinux ha fastidiado, aún no hemos acabado.
Tenemos que volver a editar el grub.cfg para quitar el “selinux=0″ o simplemente volver a reiniciar normalmente si lo que hemos hecho ha sido editar la entrada en el menú de grub. El caso es que reiniciamos con SELinux activado.
Entonces al terminar el inicio sale algo de que tiene que reetiquetar la política de SELinux targeted, le dejamos solito y al terminar se reiniciará.
Veremos que nuestro sistema se iniciará, mostrando nuestro escritorio habitual, con SELinux activado, nuestro sistema de archivos cambiado y todos nuestros programas plenamente funcionales.
Este es el fin del manual, espero que os sirva
ACTUALIZACIÓN: Cuando hice esto por primera vez no tenía ni idea e hice el paso de regenerar el initramfs y luego reinstalé el kernel y fue todo muy lioso y al final funcionó casi sin saber por qué, y di ambas opciones por igual de buenas, sin embargo regenerar el initramfs no sirve y lo he tachado. Lo único que vale es reinstalar el kernel (intuyo que los paquetes kernel y kernel-core en Fedora) y así he modificado el manual.
Y también quiero añadir que para cambiar el formato del sistema de archivos de la partición /home son necesarios los mismos pasos, no sé si lo de selinux es necesario, pero si no funciona con selinux se quita temporalmente y ya está.
Imagen destacada tomada de acá.
Continúar leyendo...