Ir al contenido principal

[linux] file_get_contents de PHP no puede acceder a otro servidor de la misma LAN

Acabo de escribir sobre nuestros devaneos neuronales para lograr hacer funcionar los enlaces permanentes de Wordpress en un servidor remoto RedHat. Y ahí mencioné que antes de dicho problema, habíamos tenido que luchar con otro igual de porfiado y jaquecoso.

La situación era esta: Tenía un script que solicitaba información a un servidor remoto. Valiéndome de file_get_contents(), en mi instalación de localhost lograba conectar con el servidor remoto, pues estábamos en la misma LAN, o red local. Pero, claro, mi servidor local es un Windows 10 con Xampp, que prácticamente no tiene inhibiciones ^^U Por lo que la comunicación era directa y sin tapujos.

Pero cuando subí mi sitio web al servidor de desarrollo, al que llamaré "Servidor A", la cosa ya no funcionó tan bonita.

Pues, aun estando en la misma LAN, el servidor remoto, que llamaré "Servidor B", no contestaba las solicitudes del nuevo chico del barrio, "Servidor A". 

No profundizaré en todos los caminos que tomamos con mi compañero de pega para encontrar la solución, pues a estas alturas no me vale la pena y en verdad fue un tortuoso camino que prefiero olvidar, jajaja...

Por eso, les dejo el desenlace directo, sin preámbulos:

El culpable de todas nuestras penas y horas de funcionamiento cerebral al 1000% fue el señor don SELinux.

Si ya lo conocen, sabrán que se encarga de reforzar la seguridad de los servidores Linux. Y este fue el caso en este pequeño Servidor A, de desarrollo, montado en RedHat. 

Don señor SELinux nos bloqueaba cada acción que necesitábamos hacer. No dejaba que Servidor A pudiera comunicarse con ningún otro servidor de la cuadra. Casi me recordó a las madrastras o tías malas de las telenovelas mexicanas de los años 80s... Pero lo bueno (y a diferencia de las villanas de las teleseries), fue que de a poco fuimos descubriendo sus mañas, y al final, entendimos que no era cosa de puertos, ni de librerías sin activar en PHP lo que producía la incomunicación... El señor SELinux sólo necesitaba que le dijéramos que Apache del señor Servidor A quería conversar con el señor Servidor B, que no fuera malito y lo dejara enviarle mensajitos, que a nadie hacía daño con esa pequeña comunicación... Y accedió :) Claro, que usando el comando:

setsebool -P httpd_can_network_connect on


Y esop. Otro día coloco las referencias, pues ahora estoy apurada, y sólo quería dejar el registro de este tip antes de que se me olvidara todo lo sucedido (ya saben, con el internet no sé lo que pasó hace 30 segundos...).

Gracias por leer y hasta pronto! 

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