Entradas etiquetadas con servidor

Subversion y Apache, corregir el error 413 Request Entity Too Large
0Algunas veces, cuando realizamos commits con muchos archivos, Subversion no es capaz de procesar el commit y nos devuelve el error «413 Request Entity Too Large». Este error se produce porque el commit que estás realizando tiene un tamaño superior al que tiene configurado Subversion al hacer la petición.
Para corregirlo hay que añadir los siguientes parámetros al virtual host del servidor de Subversion:
- LimitXMLRequestBody 0
- LimitRequestBody 0
Con estos dos parámetros eliminarás el límite impuesto por Subversion.
Si lo deseas, en vez de eliminar el límite puedes aumentarlo a 64MB,256MB, etc.
Cómo crear un servidor REST en PHP
0Un servidor REST es una aplicación que nos permite crear, actualizar, eliminar y recuperar datos de forma remota siguiendo el estandar de diseño REST. Lo habitual cuando programamos, por ejemplo peticiones ajax, es nombrar las urls como «/obtenerProducto», «/crearProducto», etc. En REST los verbos «obtener» o «crear» no se usan, ya que se utiliza una única url para todas las acciones, en nuestro ejemplo «/producto». Además, REST nombra a estas urls como recursos.
Para poder diferenciar la acción que se está realizando sobre un recurso concreto se utiliza un método u otro en la petición: GET, POST, PUT o DELETE.

Integración continua: Instalando la herramienta Selenium para ejecutar test funcionales
0Selenium (http://www.seleniumhq.org/) es un conjunto de herramientas que permiten automatizar ciertas acciones en los navegadores. Esta automatización nos permite crear test funcionales, para probar formularios, enlaces, etc., tareas muy repetitivas y muy poco agradables de llevar a cabo.
Si lo único que necesitas es saber como crear y automatizar en local los test funcionales puedes usar el plugin de Firefox que explico en el apartado «Creando los test funcionales».

Digital Ocean, servidores privados virtuales con discos SSD
0Es curioso cómo ha avanzado el alojamiento web en los últimos diez años: de pasar a ofertas de hostings y servidores dedicados desatendidos o no, a disponer de una amplia oferta en la que tú decides cuántos núcleos del microprocesador quieres tener, cuanta RAM, cuanto espacio de almacenamiento, etc.
Si nos retrotraemos, podremos ver como la virtualización ha cambiado completamente la forma de ver y entender tanto el negocio del alojamiento web, como el desarrollo y despliegue de aplicaciones web.
Aplicaciones. Cuando yo empecé a programar eran páginas web o sites. Hasta el vocabulario que usamos en el día a día no está exento de evolución.
Nos profesionalizamos.
Y esa profesionalización implica adaptarse a los nuevos cambios, ya que o evolucionas o te extingues.
Continue reading “Digital Ocean, servidores privados virtuales con discos SSD” »
Integración continua: instalando y configurando Jenkins
0Ya vistes la checklist del último post: http://www.interadictos.es/2014/08/11/integracion-continua-primeros-pasos/, ahora vamos a empezar a instalar y configurar algunas herramientas, para ir poco a poco uniéndolas.
¿Qué es Jenkins?
Jenkins es nuestro servidor de integración continua. Es una aplicación que permite automatizar una lista de tareas que le indiquemos. Estas tareas pueden ser iniciadas de forma manual, pero lo habitual será llamar a la primera tarea de la lista cada vez que se realice un commit en el repositorio, e ir concatenando tareas hasta finalizar la lista completa. Tranquilo si no te haces aun a la idea, a medida que vayamos avanzando con esta guía lo iras entendiendo.
Instalando Jenkins
Primero descargamos la key del servidor de Jenkins, que nos permitirá añadirlo al archivo sources.list:
wget −q −O − class="external free" style="color: #663366;" href="http://pkg.jenkins−ci.org/debian/jenkins−ci.org.key" rel="nofollow">http://pkg.jenkins−ci.org/debian/jenkins−ci.org.key | sudo apt−key add −
A continuación lo añadimos al archivo sources.list. Puedes añadirlo de esta manera o añadirlo a mano:
sudo sh −c 'echo deb class="external free" style="color: #663366;" href="http://pkg.jenkins−ci.org/debian" rel="nofollow">http://pkg.jenkins−ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
Actuliazamos la lista de paquetes e instalamos:
sudo apt−get update sudo apt−get install jenkins
Ahora necesitamos poder acceder a él a través de la red, para ello vamos a crear el subdominio jenkins.ic.net. Para poder acceder por el subdominio jenkins.ic.net es necesario crear un virtual host con proxy inverso, para ello instalamos varios módulos de Apache2 necesarios:
sudo a2enmod proxy sudo a2enmod headers sudo a2enmod deflate sudo a2enmod proxy_http
Ahora creamos un virtualhost en /etc/apache2/sites-available llamado 001-jenkins.ic.net.conf (Podeis usar el nombre que quieras), con el siguiente contenido
*:80> ServerName jenkins.ic.net *> Order deny,allow Allow from all ProxyPreserveHost On ProxyPass / class="external free" style="color: #663366;" href="http://localhost:8080/" rel="nofollow">http://localhost:8080/ ProxyPassReverse / class="external free" style="color: #663366;" href="http://localhost:8080/" rel="nofollow">http://localhost:8080/
La ruta habitual para acceder a Jenkins sería http://localhost:8080, si pudieramos acceder desde el mismo servidor de integración continua, si lo hicieramos desde fuera sería http://ic.net:8080. Para evitar tener que recordar el número de puerto utilizamos el archivo anterior. Nos facilitará la vida.
Ahora creamos un enlace simbólico de este archivo en /etc/apache2/sites-enabled.
sudo ln −s /etc/apache2/sites−available/001−jenkins.ic.net.conf /etc/apache2/sites−enabled/001−jenkins.ic.net.conf
Reiniciamos apache con:
sudo /etc/init.d/apache2 reload
En nuestro ordenador tendremos que editar el archivo hosts, para indicarle al pc a qué ip debe dirigirse para encontrar el alojamiento de jenkins.ic.net. Añadimos la siguiente línea al archivo (sustituye la IP por la de tu servidor de integración continua):
192.168.1.40 jenkins.ic.net
Ahora podrás escribir el subdominio en el navegador para acceder a la página principal de Jenkins.
A partir de aquí te recomiendo que explores todas las opciones de Jenkins, además de echarle un ojo a la documentación: https://wiki.jenkins-ci.org/display/JENKINS/Use+Jenkins
En la administración de Jenkins puedes acceder al apartado de plugins, revísalos y podrás hacerte una idea de las posibilidades de esta herramienta.

Cambiando todo el hardware del ordenador en Debian 7 Wheezy
0Después de unos cuantos años sin renovar el hardware del pc, este mes tocó renovación, y a lo grande. Principalmente por el final de soporte de Windows XP y que para algunos proyectos (y juegos… ejem, ejem) necesitaba más memoria RAM.
He dedicado bastantes horas a valorar que hardware comprar y que no se me fuese de presupuesto. Al final me decidí por lo siguiente:
– Micro AMD FX 8350 Black Edition (8 nucleos)
– Placa base ASUS M5A99FX PRO R2.0
– Tarjeta gráfica ASUS GeForce NVIDIA GTX 780
– Fuente de alimentación Aerocool Strike-X 800
– Y torre nueva: Aerocool Strike-X Advance
Los discos duros, aunque ya han superado su edad de vida media, aun funcionan, así que de momento no se tocan.
La instalación fue relativamente sencilla, aunque como ocurre siempre en un equipo de hace seis años, siempre hay algo que no funciona en el hardware nuevo. Uno de ellos fue uno de los discos duros, que por alguna extraña razón la placa no me lo reconocía. Por suerte solo era un disco para almacenar chorradillas que no se donde meterlas.
Una vez conectados los discos duros y que todo estuviera bien conectado, crucé los dedos y pulse el interruptor de la torre… se encendió a la primera, la placa base, los leds azules de la la torre, los ventiladores, el cooler, la gráfica, los discos duros,… espera… ¿Y ese pantallazo azul?… Mierda, Windows XP ha cascao, seguro que tenía alguna librería en el disco duro que no reconocía la placa, en fin, ¡Larga vida a Debian 7!
La verdad es que no fue un gran problema que Windows XP muriese en el proceso, al fin y al cabo llevaba tiempo queriendo cambiar definitivamente a Debian, así que fue una razón más para abandonar Windows por algo mucho mejor.
Aunque leí que cambiar el hardware en Debian no tenía por qué suponer un problema, es decir, que al entrar en el Sistema Operativo todo funcionaría igual; mi experiencia me decía que esto iba a cascar por todos lados.
Bueno pues me equivoqué a medias: el cambio de hardware hizo que se mostrasen algunos fallos (el módulo del kernel para la tarjeta de red, por ejemplo), pero solo fallo por un lado: la tarjeta gráfica, que impedía que se iniciase el servidor gráfico.
Y es que Debian 7 Wheezy no reconocía la gráfica debido a que los drivers de nvidia en Wheezy solo llegan hasta la 302, y para que me la reconociese necesitaba mínimo la 319, que es la que da soporte a la GTX 780.
¿Solución? Actualizar a Debian 8 Jessie, o lo que es lo mismo: pasar de stable a testing. He de decir que Jessie es bastante estable, y sabiendo que está previsto que se congele la inclusión de nuevos paquetes en esta rama hacia Noviembre de 2014, no había riesgo de que fallase por otro lado.
En primer lugar hay que editar el archivo /etc/apt/sources.list y sustituir la palabra «wheezy» por «jessie«, y «stable» por «testing«.
Hacemos un apt-get update, y si todo ha ido bien ejecutamos apt-get dist-upgrade, y a esperar que se descargue e instale todo.
Una vez instalado todo, seguiremos sin gráfica y sin servidor gráfico. Primero comprobamos que ahora sí reconoce la gráfica escribiendo en la consola el siguiente comando: lspci | grep «VGA».
Este comando nos debe mostrar el modelo de tarjeta gráfica que tenemos.
Y a partir de aquí es hora de configurar la gráfica. Para ello os voy a dejar un artículo que me ha ayudado muchísimo a la hora de configurarla y se merece que le enlace; los pasos a seguir ya sea en Debian 7 Wheezy o Debian 8 Jessie son los mismos, con lo que espero que este tutorial os valga tanto como me ha servido a mí:

Pasar un repositorio Subversion a otro servidor
0Hay veces en las que es necesario pasar nuestro repositorio Subversion a otro servidor, bien por falta de espacio o recursos, bien por cambio de proveedor. Para ello subversion nos ofrece varios comandos para realizar el proceso.
Como esta información ya existe en la red prefiero enlazaros al contenido original (mientras sea legal en España), en el que está muy bien explicado y me fue de mucha utilidad en su momento:
http://blog.wlacruz.com.ve/2011/10/migrar-o-mover-repositorio-de.html

Cassandra 1.x y PHP para desarrolladores SQL: Clusters
2Cassandra permite crear anillos o clusters de servidores de una forma muy sencilla, esto nos permitirá levantar nuevos servidores dentro de un cluster en cuestión de varios minutos.
Para ello tendremos que modificar la configuración de la BD.
En /etc/cassandra modificamos el archivo cassandra.yaml. Buscaremos la siguiente línea:
- seeds: "localhost"
Y sustituimos localhost por la ip local del servidor, en mi caso 192.168.1.10.
- seeds: "192.168.1.10"
A continuación modificamos las siguientes líneas:
listen_address: localhost [...] rpc_address: localhost
Por:
listen_address: 192.168.1.10 [...] rpc_address: 192.168.1.10
Guardamos y reiniciamos el servidor.
Ahora el servidor con esta configuración será al que se conecten el resto de servidores del cluster.
Para el resto de servidores la configuración es parecida. En seeds mantenemos la ip del servidor principal y en listen_address y rpc_address ponemos la ip del servidor a unir al cluster:
- seeds: "192.168.1.10" [...] listen_address: 192.168.1.103 [...] rpc_address: 192.168.1.103
Utilizo la ip 192.168.1.103 ya que es la que tengo configurada en mi cluster de prueba, tu deberías poner la ip correspondiente a la máquina donde estés configurando Cassandra.
Guardamos y reiniciamos la BD.
Esto es todo lo que hay que hacer para crear un cluster con Cassandra

Cassandra y PHP para desarrolladores SQL: Clusters
0Cassandra permite crear anillos o clusters de servidores de una forma muy sencilla, esto nos permitirá levantar nuevos servidores dentro de un cluster en cuestión de varios minutos.
Para ello tendremos que modificar la configuración de la BD.
En /etc/cassandra modificamos el archivo cassandra.yaml. Buscaremos la siguiente línea:
– seeds: «localhost»
Y sustituimos localhost por la ip local del servidor, en mi caso 192.168.1.10.
– seeds: «192.168.1.10»
A continuación modificamos las siguientes líneas:
listen_address: localhost
[…]
rpc_address: localhost
Por:
listen_address: 192.168.1.10
[…]
rpc_address: 192.168.1.10
Guardamos y reiniciamos el servidor.
Ahora el servidor con esta configuración será al que se conecten el resto de servidores del cluster.
Para el resto de servidores la configuración es parecida. En seeds mantenemos la ip del servidor principal y en listen_address y rpc_address ponemos la ip del servidor a unir al cluster:
– seeds: «192.168.1.10»
[…]
listen_address: 192.168.1.103
[…]
rpc_address: 192.168.1.103
Utilizo la ip 192.168.1.103 ya que es la que tengo configurada en mi cluster de prueba, tu deberías poner la ip correspondiente a la máquina donde estés configurando Cassandra.
Guardamos y reiniciamos la BD.
Esto es todo lo que hay que hacer para crear un cluster con Cassandra