Configurar bien una máquina puede ser una tarea tediosa, especialmente por el hecho de que muchas veces nos podemos olvidar de más de algún detalle.

La presente es una instalación de PHP 5.3.3 en una máquina CentOS 64 bits limpia (instalación servidor) que implementa además dos extensiones fundamentales a mi parecer: APC y Suhosin. El primero sirve como opcode cache y el segundo funciona para frenar algunas malas prácticas en la programación de PHP, especialmente aquellas que tienen que ver con overflows. También le agrega una capa adicional de seguridad que predeterminadamente no viene integrada a PHP.

Sin embargo, no hay que olvidar que los repositorios oficiales todavía están con PHP 5.1.6 así que hay que habilitar un repositorio que tenga la última versión de PHP. Para este how-to, voy a ocupar el repositorio de remi, aunque cualquier otro también puede servir. (Sé que Webtatic también tiene la última versión, tanto en rama 5.2 como en 5.3). Por último, también aprovecho de instalar el repositorio de rpmforge por tener mucho software adicional que no viene en la base.

Estaba instalando un servidor hoy y lo principal es la seguridad en esa máquina. Por lo tanto, hay que restringirlo lo más posible; lo cual implica desde cambiar el puerto predeterminado en el cual SSH escucha hasta los usuarios que pueden invocar su.

Tocaremos principalmente dos archivos por mientras: /etc/ssh/sshd_config y /etc/pam.d/su

Para los primeros pasos, hacemos todo con nuestra cuenta de root.

Una de las cosas que más me desconcertó cuando empecé a trabajar con Mac, fue la ubicación de las teclas. Y es que, desde que entré a estudiar informática, siempre había elegido la distribución mexicana del teclado, por la simplicidad con la cual se pueden escribir caracteres como < y >, y también las infaltables {} y [], sin olvidar la ubicación del tilde, al lado de la P y no de la Ñ. Más grande aún fue mi sorpresa al ver que sólo estaba el teclado Español de España (discúlpenme mis lectores españoles, pero su configuración de teclado es lo más incómodo que hay para programar) y que simplemente no podía elegir otra distribución. Así que la hice corta: Googleé de inmediato y encontré la solución. Sin embargo, esa misma solución ahora está offline, así que acá tienen un respaldo, esta vez escrito por este humilde servidor.

Desde que empecé en esto de la Web, siempre tuve un problema: las tildes. O me salía el típico signo de pregunta o bien me salían caracteres extraños, que intentando por aquí y por allá siempre lograba evitar, aunque a veces me superaba y optaba simplemente por terminar escribiendo su entidad.

Aunque no pretendo arreglarle la vida a todo el mundo, en este post sí les dejaré algunos tips para asegurarse de que todo funciona como debería: se verán algunas funciones de PHP que sirven harto y se verá superficialmente la interacción con bases de datos. Dato rosa antes de continuar: la diferencia entre acento y tilde, es que tilde representa el signo “ ´ “ mientras que acento se refiere a la fuerza que se le impregna a la sílaba específica. De esta manera, en la palabra “sílaba”, el tilde está en la letra “i”, mientras que el acento está en la sílaba “sí”.

Hace un tiempo atrás, necesitaba que todos los links externos fueran abiertos en una nueva ventana. Primero hice una función en PHP que cuando construía el link, detectaba si el mismo era interno o externo y si era externo, lo dejaba con el famoso target=”_BLANK”. Sin embargo, al poco tiempo después me di cuenta que ésta no era la solución ideal ya que fallaba en dos aspectos fundamentales: Si el link era construido mediante TinyMCE (o sea, por el usuario), no pasaba por el “constructor” de links. Por otro lado, el código generado no era compatible con la W3C en el modo estricto (En este modo, se elimina el atributo “target”). Así que me puse a investigar qué necesitaba para que cumpliera con los dos propósitos… ¿La respuesta? JavaScript, y si podía utilizar el poder de selección de la librería jQuery, aún mejor. El resultado fue que todos los links externos de la página, independiente de quién las haya creado, se abren en otra ventana y lo mejor de todo es que el código de la página es compatible con la W3C.

$(document).ready(
    function(){
        $('a:not([href^="http://blog.unreal4u.com/"])')
            .attr("target","_BLANK");
    }
);

Obviamente tiene que reemplazar http://blog.unreal4u.com/ con la ruta de su aplicación.

Hace ya cerca de un mes atrás, publiqué una nueva Class en phpClasses. Esta class posteriormente fue nominada en un sitio del cual todavía no cacho cuál es el propósito, pero la imagen se ve genial:

Famous Software Download

Los detalles de la class están después del salto.

Frecuentemente me he dado cuenta de que sobretodo en algunos hostings masivos, la configuración de PHP quizás no es la más adecuada en cuanto a rendimiento y seguridad. Lo primero por lo general es por un tema de retrocompatibilidad, mientras que lo segundo es para que no los tapen a llamadas debido a que algo no funciona como debe (y no revisan los logs).

Este post tratará fundamentalmente de este tema: se explicarán algunas de las opciones más extrañas o menos documentadas de PHP (última versión de la rama 5.2) y se comparará su uso en un ambiente de testing versus un ambiente de producción. Así que dale a “continuar leyendo” que esto no es fácil de encontrar!

Históricamente, siempre he tenido problemas con estas dos funciones. De repente está desactivada la directiva de poder obtener contenido remoto y eso producirá un montón de problemas si dependemos de file_get_contents() para nuestro sitio. Por otro lado, también es bastante inseguro y por lo mismo se le desactiva. Las directivas que controlan en php.ini la inclusión de archivos remotos son dos:
allow_url_fopen = Off
allow_url_include = Off

Que por lo general se encuentran predeterminadamente en Off, especialmente en las últimas versiones de PHP. La diferencia entre ambas es que la primera permite tratar archivos con un protocolo determinado (tal como http:// o ftp://) como un archivo, y la segunda directiva establece si acaso se puede ocupar la función include() o require() con este tipo de archivos.

Hoy me di cuenta de algo que no me había dado cuenta. (duuuh) Siempre, cuando necesitaba buscar alguna función en PHP.net, hacía la típica: iba a Google, tipeaba el nombre de la función, ubicaba PHP.net y hacía click. Bueno, como casi todos los grandes descubrimientos de la humanidad, estaba en la portada de PHP.net y por accidente hice clic donde no debía. Descubrí esto:

Sin embargo, el verdadero potencial de este post está por verse, veamos algunos comandos semi-avanzados de vim que nos hará la vida mucho más fácil al trabajar con este editor.

Pensando en qué truco podría ser útil, me acordé de los famosos ob_* que en un principio me parecían bastante complicados e inútiles.

Sin embargo, hoy constituyen un pilar fundamental en mi ambiente de desarrollo, puesto que me permiten ejecutar código, y poder redirigir a alguna página en específico incluso después de haberse ejecutado la página completa. Por supuesto, también me permite insertar contenido Javascript en los headers después de haber ejecutado la página.

¿Pero cómo se ocupa? Para esto es este post.

u
n
r
e
a
l
4
u
.
c
o
m

Camilo Sperberg es Ingeniero Informático especializado en Linux y PHP. Éste es su blog oficial y aquí podrá leer mucha más información acerca de temáticas variadas en el bajo mundillo de la informática relacionada con esos tópicos

Because my reality... is just your virtuality

Camilo Sperberg

Debido a la gran cantidad de guiños y referencias relacionadas con el mundo informático, esta sección permanecerá siempre incompleta, al menos hasta que se complete

Futurama fan page

Oh, i'm very confortable with my sexuality, i just don't want to be slapped in the face with THEIR sexuality

Roy Trenneman en The IT Crowd S02E01