Instalación de PHP

La instalación de PHP no tiene mucha ciencia en GNU/Linux:
$ sudo apt-get install php5-cli php5-cgi php5-mysql
$ php -v
PHP 5.2.0-8+etch9 (cli) (built: Dec 29 2007 14:49:25)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies

Instalación de FastCGI

Ya que nginx no cuenta con módulo integrado de php, precisamente porque no encuadra en su arquitectura, la ejecución del código PHP lo vamos a hacer a través de FastCGI. Para eso  utilizaremos la implementación que viene con lighttpd. Lo que haremos será compilar lighttpd, para luego copiar simplemente el spawn-fcgi
wget http://www.lighttpd.net/download/lighttpd-1.4.18.tar.gz
gunzip lighttpd-1.4.18.tar.gz
tar xvf lighttpd-1.4.18.tar
cd lighttpd-1.4.18/
./configure
make
sudo cp src/spawn-fcgi /usr/bin/spawn-fcgi
Ahora tendremos que crear un ejecutable:
#!/bin/sh
/usr/bin/spawn-fcgi -a 127.0.0.1 -p 9000 -u www-data -f /usr/bin/php5-cgi
Y su script de control

que arreglamos sus permisos y lo hacemos ejecutar al inicio del sistema:
sudo chmod 755 /etc/init.d/php-fastcgi
sudo chmod 755 /usr/bin/php-fastcgi
sudo /usr/sbin/update-rc.d -f php-fastcgi defaults
bastaría añadir la configuración a nuestro virtual host

y hacer que carge una serie de parámetros que necesita el spawn para hacer que todo funcione correcto en la comunicación con nginx

La verdad es que es muy cómodo, y no tienes que recurrir a el conocido `gem server`, el cual tiene que levantar un servidor webrick para acceder a toda la documentación. Con este hack no se consumen recursos adicionales y exprimir todavía más nuestro equipo para otras tareas.

El único problema que tiene el post de Sergio es que es dedicado a bash, y hace algún tiempo que proceso amor por zsh, por lo que he hecho la modificación para que rule en la misma.

Simplemente copiad el siguiente código en vuestro ~/.zshrc y ya teneis el comnado gemdoc con autocompletado.

Por lo tanto solo habría que escribir en terminal
gemdoc
y se autocompletan los nombres de las gemas con sus respectivas versiones, si no proporcionas la version se cogerá la última versión.

En este sentido escribiré algunos de los parámetros que podemos monitorear para el caso de bases de datos MySQL.

Básicamente MySQL nos proporciona una serie de instrucciones SQL que nos devuelve información de estado y rendimiento del servidor, para que luego las evaluemos y decidamos que acción pertinente se lleva a cabo.

La instrucción básica que se usa en MySQL es

la cual nos devuelve una cantidad importante de estados de variables. Aquí explico las más importantes.

Threads_connected

Esta variable indica el número total de clientes que tienen una conexión abierta actualmente con el servidor.
Proporciona información en tiempo real de cuantos clientes están conectados con el servidor. Esto puede ser de ayuda para analizar el tráfico o decidir cuando es el mejor instante para reiniciar un servidor.

Created_tmp_disk_tables

Esta variable indica el número de tablas temporales que han sido creadas en disco frente a hacerlo en memoria.
El acceso a tablas en disco normalmente es más lento que acceder a ellas en memoria. Por tanto las consultas que usan la sintaxis CREATE TEMPORARY TABLE son más lentas si el valor de la esta variable es superior.

Handler_read_first

Esta variable indica el número de veces que un gestor de tabla hace una petición de lectura a la primera fila del índice de la tabla.
Si MySQL accede frecuentemente a la primera fila de un índice de tabla, sugiere que está llevando a cabo un escaneo secuencial al índice completo. Esto indica que la tabla correspondiente no está correctamente indexada.

Innodb_buffer_pool_wait_free

Esta variable indica el número de veces que MySQL tienen que esperar por páginas de memoria que tienen que ser purgadas.
Si esta variable es alta, sugiere que el buffer de memoria de MySQL está configurado incorrectamente de acuerdo con la cantidad de escrituras que el servidor está llevando a cabo actualmente.

Key_reads

Esta variable indica el número de accesos al sistema de archivos que lleva a cabo MySQL para recoger índices de bases de datos.
La lectura de índices de bases de datos en el sistema de archivos ralentiza el rendimiento de las consultas. Si esta variable es alta, indica que la cache de keys de MySQL’s está sobrecargada y debe ser reconfigurada.

Max_used_connections

Esta variable indica el número máximo de conexiones que MySQL ha tenido que abrir al mismo tiempo desde que el servidor fue reiniciado.
Este valor proporciona un punto de referencia en la ayuda a decidir el número máximo de conexiones que tu servidor debería soportar. También ayuda al análisis de tráfico.

Open_tables

Esta variable indica el número de tablas que están actualmente abiertas.
Este valor es el mejor analizador en combinación con el tamaño de la cache de tablas. Si el valor es bajo y el valor de table_cache es alto, probablemente es bueno reducir el tamaño de caché sin afectar al rendimiento. Por otra parte, si el valor es alto y cercano al valor de table_cache, puede suponer beneficioso incrementar el tamaño de la caché de tabla.

Select_full_join

Esta variable indica el número de full joins que MySQL ha tenido que llevar a cabo para satisfacer las consultas de los clientes.
Un valor alto indica que MySQL está siendo forzado a hacer full joins de tablas (que tienen un rendimiento intensivo) en lugar de utilizar índices. Esto sugiere la necesidad de una mayor indexación de las tablas correspondientes.

Slow_queries

Esta variable indica el número de consultas que han sido más largas de lo normal.
Un alto valor indica que muchas consultas no están siendo ejecutadas de forma óptima. Un próximo paso necesario sería examinar el log de consultas lentas e identificar estas para la optimización

Uptime

Esta variable indica el número de segundos desde que el servidor fue reiniciado.
Este valor es útil para analizar el tiempo de actividad del servidor, así como para generar informes sobre el rendimiento general del sistema. Un valor bajo de consistencia indica que el servidor se ha reiniciado con frecuencia, lo que ha provocado frecuentes interrupciones del servicio al cliente.

Con toda esta información el analisis de rendimiento y estado del servidor MySQL se hace mucho más llevadera. Espero os sea de ayuda.
Tabla extraída y traducida de http://blogs.techrepublic.com.com/opensource/?p=56.

 Y aquí el código CSS:

Es algo común que estés desarrollando contra un gestor de bases de datos de “juguete” como puede ser sqlite3 y en un momento dado querer pasar a uno “de verdad” para probar cuanto rendimiento tiene tu app.

En este caso y como reza el título explico como hacer la migración de sqlite3 a MySQL, que resulta bastante trivial.

SQLite a MySql

1. Se hace un dump de la bbdd que queremos
   sqlite3 BasedeDatosaExportar .dump .quit >>fichero-dump.sql
2. Ahora toca adaptarla a la sintaxis expecial de MySQL
   - Reemplazar ” (comillas dobles) por ` (acento grave)
   - Elimina “BEGIN TRANSACTION;” “COMMIT;“, y las líneas “sqlite_sequence”
   - Substituye “autoincrement” con “auto_increment“
3. Y el fichero ya está listo para importar en MySQL.

Facil y bonito oye.

A veces encuentras perlas por internet gracias a las cuales aprendes más que leyendo libros.

En esta ocasión he encontrado una web que recompila ficheros de configuración de muchísima gente con buscador incorporado. http://dotfiles.org/

Ya conocía en GitHub un proyecto conjunto donde todos los usuarios creaban un repositorio en git donde colgaban sus ficheros .files, y la verdad es que ayuda mucho sobre todo encontrar ficheros de configuración de autenticos gurús en distintos campos. Si os interesa aquí teneis una lista en github.

Internalidades de Git

Git internamente gestiona los distintos commits en forma de arbol, donde cada “hoja”, que el llama blob son los distintos archivos en un instante determinado y los “nodos”, que llama tree son los distintos directorios. Siguiendo este esquema la gestión del repositorio se simplifica mucho.
En el esquema anterior podemos ver como se pueden diferenciar 2 arboles de objetos y nodos distintos, el primero que referenciamos mediante un tag (con una rama descendente única y que contiene dos directorios y un archivo), y el segundo sería exactamente el mismo arbol anterior pero añadiendole un nuevo archivo. Además el segundo es la copia actual en nuestro directorio de trabajo.

Creación de Tags

Entonces y deduciendo un poco la creación de tags en Git es inmediata, basta crear un “puntero” que nos apunte, valga la redundancia, a el commit deseado.
$git-tag -a nombre-tag -m "Creación de Tag nombre-tag"
Si no proporcionas el parámetro -m, simplemente se abrirá tu editor $EDITOR y podrás proporcionar una descripción a el tag en cuestión.
Se pueden hacer múltiples acciones sobre un tag, en el caso anterior se crea un tag sin firmar con GPG pero podemos hacerlo firmado (con el parametro -s) para la posterior identificación de su creador. Para llevar a cabo el firmado se usa el parámetro signingkey de nuestro .gitconfig

También podemos eliminar un tag con el parámetro -d, y demás. git-tag(1)
Por lo tanto la creación de Tags como hemos visto es sencilla y directa, y lo más importante sin crear copias innecesarias de archivos.

Creación de Branches

Ahora imaginad el estado del arbol del repositorio de la imagen. En este caso hay dos commits de los cuales hemos omitido toda la estructura. El segundo commit es nuestra copia de trabajo actual y realmente podemos tratar como el branch “master”. En este caso y para crear un nuevo branch lo que hacemos es crear un nuevo puntero (que no un commit nuevo) a el último commit, como muestro en el siguiente gráfico, a partir de ese momento los nuevos commits que hagamos se van a hacer sobre ese branch. Por lo tanto para crear un nuevo branch y hacerlo nuestra copia lo que haremos es ejecutar lo siguiente:
$ git branch master <nuevo-branch> #creamos el branch a partir de master
$ git checkout <nuevo-branch> # hacemos que ese branch sea nuestra copia en nuestro directorio de trabajo
En este gráfico por fin vemos que hemos creado un nuevo commit y se ha creado bajo nuestro branch y no sobre master. Si luego queremos retomar el branch master no tenemos más que hacer un checkout como en el ejemplo anterior y ya sería nuestra copia.

En la próxima entrega hablaré de como podemos hacer de distintas formas merges de los branches, y de como Git de nuevo nos facilita la tarea.

Uso de Git

El primer paso despues de instalar Git es configurarlo para identificarnos, para eso con un simple
$ git config --global user.name "Tu nombre"
$ git config --global user.email "direccion@dominio.tld"

configuramos nuestro nombre. Para ver más parametros de configuración pasaros por aquí git-config(1).

Para configurar un poco el comportamiento de git y sus diferentes acciones podeis editar el archivo general ~/.gitconfig que teneis en vuestro directorio home:

Para la creación de un repositorio git simlemente tenemos que ejecutar en consola el siguiente comando dentro de la carpeta que queremos controlar:
$mkdir repositorio; cd repositorio;
$ git init

A continuación podemos editar o generar los archivos dentro de dicho directorio que luego añadiremos al repositorio:
$ touch fichero.example
$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# fichero.txt
nothing added to commit but untracked files present (use "git add" to track)
Como vemos el sistema se da cuenta que no tiene traceado el archivo que acabamos de crear, por lo que el estado nos notifica dicho evento. En este momento podemos hacer distintos eventos, eliminarlo (git rm fichero.example), añadirlo:
$git add fichero.txt
$git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached < file >..." to unstage)
#
# new file: fichero.txt
#
$git rm
o ignorarlo que es una de las features que más me han gustado de Git, para eso se edita el archivo .gitignore dentro del directorio para especificar eso, por ejemplo para aplicaciones rails se puede especificar lo siguiente:

Gracias a este fichero habilitamos unos filtros que necesitan pasar todos y cada uno de los archivos y directorios que se quieran que sean gestionados por Git.

Quiero commitear!

Llegados a este punto queremos hacer un commit al repositorio local, para eso simplemente se ejecuta:
$ git commit
Podemos evitarnos el tener que hacer el “git add < elemento >” para eso el commit podemos hacerlo así:
$ $git commit -a
Created initial commit 5a5b3af: initial import
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 fichero.txt


Hecho esto, se ha creado un commit con un número de identificación que es un hash y que es siempre distinto. Despues de proporcionar un mensaje identificativo del commit, el commit estará hecho.
Pero este commit es local, esto es, no se hace el commit a un repositorio externo, y esta es otra de las funcionalidades que diferencian a git del resto, ya que tienes control de versiones local.

Para hacer commits a un repositorio remoto hay que generar una copia de nuestro repositorio pero de una forma especial:
~ $git clone --bare repo/ repo.git
Initialized empty Git repository in /Users/fran/repo.git/
Con esto tenemos un directorio nuevo donde tenemos solo los objetos del repositorio y no la copia directa de cada archivo del repositorio. Este copia bare lo subimos a nuestro servidor externo:

scp repo.git ssh://user@server:/path/al/repo/
A partir de este momento si queremos hacer y recibir commits en el repositorio externo, para eso tendremos que añadirlo a la configuración:
$git remote add origin ssh://user@server:/path/al/repo.git
para posteriormente hacer pulls o pushes cuando queramos actualizar nuestra copia local con la remota en el primer caso y actualizar el server remoto en el segundo caso:

$git push #(empujar) enviar el branch actual local al server remoto
$git pull #(tirar) sincronizar nuestra branch actual con los cambios del server remoto

Si quieres en este momento recoger una fila de la base de datos con información del usuario insertada debes reemplazar “Pepito” con la cadena proporcionada por el usuario.
En PHP se vé tal que así:

El problema es simple: si el usuario inserta una cadena formateada especialmente como el nombre de usuario el puede modificar tu consulta para ejecutar lo que el desee.

Por ejemplo si inserta esto:

Ahora la consulta se verá así:

Hay varias formas con las que alguien puede atacar nuestra base de datos mediante sql injection. Las más rudimentarias son escapar los caracteres ‘, pero no siempre funcionan correctamente ya que hay otras formas de alterar la consulta. Echemos un vistazo a esto.

Hay una solucion muy simple a este problema. No concatenes texto proporcionado por el usuario en una consulta, vinculalo. La mayoría de las bases de datos soportan bindings, mysql es una de ellas, postgresql, oracle y la lista crece. La idea es simple: proporcionas un marcador en tu consulta que será reemplazado con la variable actual, por lo que no es posible ninguna modificación posible.

Nuestra anterior consulta se puede escribir tal que así:
Mysql (en php con la extensión mysqli)

Oracle

Ejemplo de la extensión mysqli PHP (para más información lee la función de mysqli_stmt bind_param

Ejemplo con la extensión PHP PDO (para más información lee la función prepare de PDO

Por lo tanto es muy facil para nosotros evitar la reescritura evitando que concatenar los datos proporcionados por el usuario con nuestra consulta, pero hay escenarios donde debes generar una consulta con los datos del usuario, no solo enviando una consulta. Por ejemplo, quieres mostrar diferentes tipos de libros basados en lo que inserta el usuario. El usuario puede elegir ver libros de ciencia ficción, literatura o libros de cocina.

Podrías estar tentado a escribir algo como esto:

¿Pero, que pasa si el usuario quiere modificar tu script e inserta ‘users’ como una categoría? En ese caso podrá ver el contenido de la tabla de usuarios. La solución para este problema es comprobar la categoría proporcionada por el usuario en vez de la cadena directamente.

En php deberías hacer algo como esto:

Si escribes tu script de esta forma, cuando el usuario inserte ‘users’ como una categoría, el verá los libros de cocina, o puedes elegir mostrar un error, esa es tu elección.
Para resumir este post, quiero decir que deberías utilizar el binding de variables cuando quieras enviar datos a la base de datos que proporciona el usuario. Y si formas tus consultas según la entrada de usuario, simpre compara lo que inserta con algun valor predefinido y usa el valor por defecto.
Nunca concatenes entrada de usuario en tus consultas, sin excepciones

Configuramos nginx para virtualhosts utilizando ficheros separados para cada uno de ellos:

mkdir -p /usr/local/nginx/conf/{sites-available,sites-enabled}

Substituímos con lo siguiente en el fichero /usr/local/nginx/conf/nginx.conf, para que lea todos los ficheros en sites-enabled y de paso lo limpiamos:

LLegados a este punto ya tenemos nuestro nginx preparado para servir cualquiera de los distintos tipos de servidores que soporta (web, proxy web inverso, mail, balanceo de carga). Como aquí nos centraremos en configurar un servidor web con virtualhosts, sigo relatando las operaciones.

Como dije suelo poner mis webs en /opt por lo que crearé el “raiz” del servidor con toda su estructura interna

#Creamos carpeta general y la default donde alvergar los estáticos por defecto del servidor
mkdir -p /opt/sites/default
#Creamos la estructura interna virtualhost default
mkdir -p /opt/sites/default/{public,private,logs,cgi-bin,backup}

Ahora tenemos que configurar el virtualhost con sus parámetros y configuracion, he aquí el mio con soporte para php5: