Ir al contenido principal

[linux] Error 404 al usar reglas de .htaccess en Apache

Hola a tod@s.

Los últimos días estuvimos luchando con mi compañero de pega, intentando averiguar por qué los enlaces bonitos de Wordpress no funcionaban en el nuevo servidor RedHat que mi amigo levantó para el efecto.

Les cuento la historia desde el principio. 

Hice una instalación de Wordpress 6.2.2 en mi servidor local (mi pc con Xampp) para poder desarrollar un Theme acorde al requerimiento que me habían dado de hacer una web con x características. Todo bien ahí.

Los problemas comenzaron cuando repliqué mi desarrollo en el servidor remoto. No hablaré del primer problema que tuvimos, porque no viene a cuento en el actual tema. Tal vez otro día escriba sobre eso. Pero sí decir que nos tomó tiempo solucionarlo, y cuando por fin lo logramos, y veíamos todo color de rosa, apareció este otro desgraciado a matarnos la felicidad: los enlaces formateados que nos ofrece Wordpress no funcionaban en el servidor remoto.

El camino para darle explicación y solución daba comienzo:

Revisión de permisos de usuario a los archivos: 

Modifiqué los permisos y la propiedad de los archivos de la web a fin de que pudieran ser leídos y sobreescritos por el usuario propietario de los procesos del servidor, vale decir, por el usuario "apache". Pero no bastó: por más entregados que dejara a los pobres archivos, "apache" no podía tocarlos -_-.

Revisión de las directivas de seguridad de SELinux: 

Este señor es muy estricto, y ya nos había dado la lucha con el primer obstáculo que tuvimos al mudar el sitio web a este servidor remoto. Pensando que también tendría que ver con el embrollo, volví a investigar, y me encontré con que efectivamente existía un bloqueo de parte de él. Lo bueno es que era solucionable mediante la activación de los permisos de lectura/escritura de los archivos, vía los comandos:

chcon -R -t httpd_sys_rw_content_t /var/www/html

semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/html(/.*)?"

El primer comando se supone que habilita recursivamente la lectura/escritura sobre los archivos de la carpeta de mi instalación de Wordpress. El segundo comando hace lo mismo, pero permanente.

Gracias a este comando, ahora Wordpress podía leer, escribir y hacer lo que quisiera con el .htaccess :D

Pensé que por fin todos mis problemas se habían solucionado, hasta que me encontré con que al navegar por el sitio web, seguía saliendo el "Error 404" al entrar a los pretty links de Wordpress ¬_¬...

Configuración de Directivas de Apache:

Y ya cuando me estaba por dar por vencida, tocaba subir el último peldaño del esfuerzo: revisar la configuración de Apache. Respirando profundo, me puse a comparar línea por línea los archivos "conf" de mi localhost y del servidor remoto, comparándolos en lo que debiera ser idéntico. Pero no encontré diferencias...

Googleando, algunos decían que sus problemas se solucionaron al darle a la directiva de Apache "AllowOverride" el valor de "All": pero esto no me daba confianza alguna, y seguía buscando una alternativa segura.

Hasta que encontré a otro usuario de los foros que indicaba que, en vez de usar "All", él había usado "FileInfo" como valor de la directiva... Fue entonces que me di cuenta (¡por todos los cielos, cuánto nos nubla el cansancio, que no lo vi antes!) que en mi propio archivo "conf", el de mi localhost, la directiva siempre estuvo en "All", y no en "None" como lo estaba en el servidor remoto: por eso era que los enlaces bonitos funcionaban en mi localhost 🤦x1000

Pero no sólo esto: en los comentarios del mismo archivo "conf" se explicaba que esa directiva era usada precisamente para el caso de .htaccess , y yo no lo había leído antes! Me hubiera ahorrado otro par de horas de búsqueda si hubiese leído todo con atención, jajaja!

En fin, que cambié la directiva a "FileInfo", et voilà! Los enlaces bonitos de Wordpress comenzaron a funcionar! XDDDD

<Directory "/var/www/html">

  # Otras directivas...

    AllowOverride FileInfo

  # Más directivas...

<//Directory>


Pues eso. Espero que les ayude en sus propios devaneos mentales cuando quieran habilitar los pretty links en sus sitios web en servidores Linux con SELinux activado. Gracias por leer y hasta pronto!


Referencias:

Comentarios

Entradas populares de este blog

[tsql] Error: La instrucción INSERT EXEC no se puede anidar

Holas a todos. Mientras programaba un procedimiento almacenado, intenté obtener los datos de otro procedimiento, como lo he venido haciendo desde que descubrí tamaña maravilla de la programación sql. Pero hoy me topé con este extraño error: La instrucción INSERT EXEC no se puede anidar . Tras investigar por algunos lados, di con la respuesta: no se puede almacenar en una tabla temporal de procedimiento almacenado, el resultado de otro procedimiento que también esté realizando una inserción de este tipo. Esto es algo como tener: CREATE PROCEDURE miProcedimiento AS  INSERT INTO #tablita EXEC otroProcedimiento;  SELECT * FROM #tablita; END; CREATE PROCEDURE nuevoProcedimiento AS  INSERT INTO #tabla1 EXEC miProcedimiento; END; Esto significará que si ejecuto: EXEC nuevoProcedimiento; ...SQL me arrojará el error antes mencionado. La solución al problema es no llamar a un procedimiento que esté llamando a otro ya en su interior. En algunos lados leí que transf

[mysql] Pasar array a parámetro de procedimiento almacenado (Mysql)

Me tocó hacer una consulta que retornaba una lista de items relacionados con una lista de usuarios que podían o no tener registros en común (vale decir, tabla de quiebre). La lista debía retornar siempre la lista de items, independiente de si había usuarios por los cuales consultar y/o si los usuarios tenían relación con ellos, pero debía mostrarme el status de los usuarios por cada item, de haberlos, esto es, una lista de nombres con una columna que podía estar vacía o no. Para el caso de tener que consultar los items relacionados con usuarios, al hacer la consulta utilizando un LEFT JOIN, me daba resultados si los usuarios tenían relación con los ítems, pero no si los usuarios no tenían items asociados pues, obviamente, al no estar relacionados, la consulta retorna vacío. Por ello, la solución era hacer la consulta de los items primero, y luego por cada item preguntar el status del usuario por cada uno. Para ello, tenía dos alternativas: hacerlo por programación o hacerlo por bas

[php] NuSOAP HTTP Error: socket read of headers timed out

Holas a todos. Este es para comentar un problema que he tenido al trabajar un servicio web montado en PHP con la clase NuSOAP. El problema surgió cuando intenté llamar al servicio web desde el otro servidor, pero se caía a los exactos 30 segundos de ejecución, mostrando el mensaje que titula este registro: HTTP Error: socket read of headers timed out Sabía que el problema era el timeout, pero ¿el timeout de qué? En los servidores y páginas web hay timeouts por todos lados: el de la Conexión a internet o la red, el del Servidor (hardware), el del Servidor Web en sí (Apache, mi caso), el de PHP (mi caso)... Pero nunca se me habría ocurrido que las Aplicaciones o frameworks también pudieran tener :o Por eso, tras buscar por la red la solución a mi problema, la respuesta vino precisamente de alguien que señaló sencillamente que había que modificar el timeout de la clase NuSOAP. Y dicho y hecho, eso solucionó el problema. Si están usando en su servidor y/o cliente la clase NuSOAP, y d