Linux

Running php-fpm and nginx processes in the same container with supervisord

Yes, I know…. containers are not meant to be used like this, running two processes within a single container. Ideally, one container runs only one process.

But, what if we want to have php-fpm + nginx on the same container? since we do need both processes running for serving our website, we may say that there is no benefit in having them in two separate containers, and in case one fails, the other is useless and the whole container should be restarted.

So, we decide to have them both in the same container. How to do it properly?? with supervisord

supervisord

It is a process management daemon that will allow us to monitor and control processes on Linux.
It is quite extensive but we are not going to use all of it. we just need to run two freaking processes.

How to do it?

Dockerfile:

FROM debian:stretch

# make sure you install supervisord
RUN apt-get -qq update > /dev/null && apt-get -qq upgrade -y > /dev/null; \
    apt-get -qq install -y ... supervisor  > /dev/null;

# do your stuff, install php, nginx, whatever do you need.
# .
# .
# after you did everything, set up supervisord

COPY supervisord.conf /etc/supervisor/conf.d/supervisord.conf

CMD ["/usr/bin/supervisord"]

The changes in the Dockerfile are straight forward, just:

  • install supervisord
  • copy the config file
  • make docker CMD run supervisord

supervisord.conf:

[supervisord]
nodaemon=true

[program:nginx]
command=nginx -g "daemon off;"
autostart=true
autorestart=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0

[program:php-fpm]
command=/bin/bash -c "mkdir -p /var/run/php && php-fpm7.1 --nodaemonize --fpm-config /etc/php/7.1/fpm/php-fpm.conf"
autostart=true
autorestart=true
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0

Now things are interesting….. let’s break them up:

  • nodaemon=true we tell supervisord to run as a foreground process.
  • program:nginx we run nginx with the “daemon off” directive, we set it to auto-restart in case it fails and most importantly, we redirect logs to stdout and stderr so that docker can pick them up.
  • program:php-fpm we first create the /var/run/php folder, so php doesn’t fail to start, then we run php-fpm as a foreground process too. We do the same thing we did for nginx, redirecting the logs to stdout and stderr

And…. that is all! you now have php-fpm and nginx running on the same container, in the proper manner, with supervisord supervising them!

Configurando un Reverse Proxy con Apache

Un Proxy es un servicio que actúa como intermediario entre una comunicación del tipo Cliente-Servidor.

Mientras que un proxy normal (Forward Proxy) hace que un servidor no te contacte directamente, sino que es el proxy quien se conecta con el servidor, manteniendo al cliente en el anonimato, un Reverse Proxy, mantiene al servidor en el anonimato para con sus clientes…

 

Éstas imágenes lo aclaran muy bien:

Forward Proxy:

Forward Proxy

Reverse Proxy:Reverse Proxy

(Gracias Wikipedia por las imágenes)

 

Para qué podemos utilizar un Reverse Proxy?

Los usos son muchos, pero el clásico es el siguiente:

Supongamos que instalamos un servicio en nuestro servidor, este servicio responde al puerto 8080, es decir, accedemos a este servicio mediante http://www.example.com:8080.

Pero queremos acceder al servicio mediante http://servicio.example.com porque es más fácil para los usuarios.

Obviamente, no podemos configurar el puerto del servicio para que use el 80 porque tenemos un Apache o que ya está corriendo en ese puerto…

Entonces, “enmascaramos” la verdadera URL con el Reverse Proxy…

 

Como configurar un Reverse Proxy en Apache:

Primero instalamos un paquete que nos va a servir:

apt-get-install libapache2-mod-proxy-html

Luego, activamos los módulos de apache:

a2enmod proxy 

a2enmod proxy_html

service apache2 restart

Con eso, ya estamos listos para crear el proxy.

Es muy sencillo:

NameVirtualHost *:80
<VirtualHost *:80>
	ServerName service.example.com

	ProxyPreserveHost On
	ProxyRequests Off	

	ProxyPass / http://www.example.com:8080/
	ProxyPassReverse / http://www.example.com:8080/
</VirtualHost>

Esas lineas dentro de un Virtual Host de Apache, son suficientes para que el proxy funcione

Pero, si el servicio que esta detrás del proxy utiliza mucho Ajax/JavaScript/CSS, vamos a notar un rendimiento muy pobre, en otras palabras, si accedemos al sitio desde la URL original: www.example.com:8080 tendremos una respuesta normal, pero si accedemos mediante la URL enmascarada, service.example.com, podemos llegar a tener demoras de 10 a 20 segundos!! inclusive puede ocasionar Time-Outs…

Es decir, un sitio web detrás del Reverse Proxy, se va a notar muy muy lento. Mucho más lento que accediendo desde la URL original.

Esto sucede porque por defecto, el mod_proxy solo re-mapea las URLs en los headers, no en el contenido de la página, además el modulo mod_proxy_html tampoco parsea CSS o JavaScript, entonces las URLs que se encuentran dentro de esos archivos y el contenido de la página, no son re-mapeadas, provocando una serie de Lookups que demoran mucho tiempo

 

Entonces, el código final, con lo  anterior solucionado sería el siguiente:

NameVirtualHost *:80
<VirtualHost *:80>
	ServerName sub.example.com

	ProxyPreserveHost On
	ProxyRequests Off	

	ProxyPass / http://127.0.0.1:8040/
	ProxyPassReverse / http://127.0.0.1:8040/
	ProxyHTMLURLMap http://127.0.0.1 /

	SetOutputFilter  proxy-html
	RequestHeader    unset  Accept-Encoding

</VirtualHost>

 

Luego, hacemos un último:

service apache2 restart

Y ya estamos listos….

 

Con eso deberiamos poder acceder a http://service.example.com exactamente igual que si accediéramos por la URL original!!!

 

Saludos!!

MySQL: Analizando la performance de un SELECT

Me encontré con la necesidad de saber con exactitud cuánto demora un SELECT de una fila cuando el campo que buscamos no es un índice, o si es un índice secundario o uno primario.

Para explicar mejor la situación, propongo el siguiente ejemplo:

Tenemos la siguiente Tabla de Usuarios:

Id Name UserName Telephone Notes

 

La configuración que primero se nos ocurre es que el campo “Id” sea un índice primario, pero qué sucede si por alguna razón, tenemos que hacer siempre un SELECT donde en el WHERE se use con la columna UserName, por ejemplo, si tenemos que loguear al usuario y el dato que tenemos es el username, la consulta sería:

SELECT * FROM Users WHERE UserName=’pepe’;

En cualquier sistema, hasta en un servidor con escasos recursos, esta consulta no tarda mucho y poco importa si tarda unos milisegundos más o menos…  pero en ciertas ocasiones, con tablas de miles de registros,  dependiendo del entorno,  los milisegundos comienzan a tomar importancia, sobre todo si no tenemos mucho poder de procesamiento, el timing comienza a ser de mucha importancia.

Las bases de datos actuales, para resumirlo de una forma brutal y básica, guardan la información en estructuras de datos ordenadas (árboles avanzados) por índices, lo cual nos hace pensar que si buscamos por el campo “Id” es más rápido que si buscamos por el campo “UserName” ya que el campo “Id” está indexado.

Qué podemos hacer entonces??

Hagamos que UserName sea un índice!!!  Muy bonito, pero, cuando la base de datos busca, comparar un INTEGER (“Id”) es muchísimo más rápido que comparar un VARCHAR (“UserName”) de unos 20 caracteres de longitud, por lo tanto, cualquier operación en la tabla se vuelve un poco más lenta…

Entonces, que conviene más?  Usar un índice que haga la tabla más lenta en general, pero que devuelva una fila mucho más rápido? o usar un índice ágil, pero luego tendremos demoras al buscar una sola fila por otro campo?

La respuesta a esta última pregunta, depende un 100% del entorno del sistema en el que estemos…
En un sistema con pocos usuarios, podría no ser un inconveniente, pero cuando tenemos un servidor con escasos recursos, como por ejemplo la Raspberry Pi o similares y en nuestra aplicación una diferencia de milisegundos importa, se convierte en un inconveniente.

Se me ocurrieron algunas opciones para medir el rendimiento y realizar algunos benchmarks de MySQL corriendo con bajos recursos…

  • Comparar los resultados usando:

    • a)  El campo Id como Índice Primario y el resto campos comunes. (Situación normal)
    • b)  El campo Id como Índice Primario y el campo UserName como Índice Secundario
    • c)  El campo UserName como Índice Primario y el campo Id como Índice Secundario
  • Comparar el comportamiento de las configuraciones anteriores con distintas cantidades de registros:

    • a)  100 (cien) registros
    • b)  1000 (mil) registros
    • c)  10000 (diez mil) registros
    • d)  100000 (cien mil) registros
    • f )  1000000 (un millón) de registros
  • Ya que estamos haciendo benchmarks, comparemos los resultados anteriores con los dos motores más populares de MySQL:

    • a)  MyISAM
    • b)  InnoDB

Cómo hago estos benchmarks???

Para ello, escribí unas pocas lineas en PHP, que me permitieron llenar una BD de pruebas con información aleatoria y precisa para las pruebas…  si, en total generé más de 6.500.00 filas! casi 1GB de registros aleatorios. (demoró varios minutos)
Por si a alguien le interesa, al final del post les dejo la descarga del archivo PHP utilizado para generar los datos aleatorios, la estructura de la base de datos sin registros y la bd llena de datos.

Condiciones de las pruebas:

  • Las consultas se hacen en PhpMyAdmin.
  • Se busca un registro a la mitad del total de la tabla.
  • El tiempo es obtenido de PhpMyAdmin.
  • El servidor MySQL corre en una Raspberry Pi.
  • El sistema operativo es Raspbian ‘Wheezy’.
  • Las configuraciones de Apache/PHP/MySQL son las que vienen por defecto al instalarlos.
  • El cache MySQL es reseteado antes de cada prueba.
  • El campo UserName es un VARCHAR de 25 caracteres.
Ejemplo de consultas:
SELECT * FROM  `innodb_100_usuarios_noindex` WHERE id=50;
/*
(1 total, Query took 0.0061 sec)
id	name	           username	                 telephone	      notes
50	7Rge46fiCLEp8Au	84cdde86a4560c10000000050	vjA0WXmydgFTLf1	84cdde86a4560c10000000050 - 50
*/

SELECT * FROM  `innodb_100_usuarios_noindex` WHERE username='84cdde86a4560c10000000050'
/*
(1 total, Query took 0.0073 sec)
id	name	           username	                 telephone	      notes
50	7Rge46fiCLEp8Au	84cdde86a4560c10000000050	vjA0WXmydgFTLf1	84cdde86a4560c10000000050 - 50
*/

Basta de palabras!!!   quiero ver los números!

Todos los valores de tiempos están expresados en mS (milisegundos).

Aquí tenemos dos tablas, una con los resultados de MyISAM y otra con los de InnoDB. En ambos casos comparamos las tres configuraciones de índices mencionadas anteriormente (a, b, c) en distintas cantidades de registros. Primero buscando por el campo ID y luego por el campo UserName.

MyISAM

[table id=1 /]

InnoDB

[table id=2 /]

Resultados:

A primera vista, podemos notar la diferencia entre InnoDB y MyISAM en cuanto a la performance de los SELECTs.  Si tomamos como referencia las primer columna, donde ID es un Índice Primario, en InnoDB buscar un indice en 1.000.000 de registros, es un 35% más lento, pero si buscamos un registro no indexado, InnoDB es un 440% más lento que MyISAM.

Entonces, descartamos InnoDB para el resto de las comparaciones.

Evidentemente, buscar un registro que no es un índice, en un millón de filas, demora 8158.8 milisegundos, eso es es más de 8 segundos!!!  De hecho en 10.000 filas, demora casi 100 milisegundos, lo cual, en algunos casos, puede ocasionar problemas. Obviamente y como podíamos imaginar, si el tiempo es clave, ésta es la peor configuración.

Nos quedan dos opciones, utilizar el campo UserName como un indice secundario, o como un indice primario.

Como se puede ver en la tabla, si buscamos la mejor velocidad, nos conviene hacerlo un índice primario, pero en contra, la busqueda por ‘Id’ demora un par de milisegundos más.

Conclusión Final:

Como conclusión final, voy a elegir la configuración de “UserName como índice secundario“.  Porqué? Porque en promedio, parece tener los mejores tiempos, ningun tiempo supera los 6ms, sin importar si es índice primario o secundario. Realmente, muy buenos timings.

Iniciar y apagar Máquina virtual VirtualBox autoáticamente junto con el SO. (Ubuntu)

La mejor forma de iniciar una maquina virtual de VirtualBox al iniciar el sistema operativo host, y a su vez, apagarla cuando éste se apague, es con un script de init.d

Creamos un archivo para guardar el script:

sudo nano /etc/init.d/VM

Copiamos el siguiente contenido en el archivo y guardamos con F2.

#! /bin/sh
# /etc/init.d/VM
#

#Editar las siguientes variables
VMUSER=vbox
VMNAME="NombreDeLaVM"

case "$1" in
  start)
    echo "Starting VirtualBox VM..."
    sudo -H -b -u $VMUSER vboxmanage startvm "$VMNAME" --type headless 
    ;; 
  stop) 
    echo "Saving state of Virtualbox VM..." 
    sudo -H -b -u $VMUSER vboxmanage controlvm "$VMNAME" savestate
    ;; 
  *) 
    echo "Usage: /etc/init.d/VM {start|stop}" 
    exit 1 
    ;; 
  esac 

exit 0

Nota: la acción de stop del script, no apaga la VM, sino que guarda el estado y la cierra.

Le damos permisos de ejecución al script:

sudo chmod +x /etc/init.d/VM

Ahora, le decimos al script que la máquina virtual sea lo último que se inicie, y lo primero en apagarse.

sudo update-rc.d VM defaults 99 01

PD: Encontré este script acá, pero le hice un par de modificaciones para mejorarlo.

Como hacer backups completos en linux

A veces, nos encontramos con la necesidad de hacer una copia de seguridad a un equipo linux, ya sea desktop o server, podemos backupear directorios importantes, o hacer un full backup de todo el sistema.

Siempre es recomendable hacer backups, de todo, aunque no sea lo mas divertido hacerlos, créeme, la perdida de información es una de las peores catástrofes en el mundo informático, no solo la pérdida de datos en una DB, sino también podemos perder código/scripts/diseños etc, que nos demandará tiempo volver a escribir.

La forma más fácil de hacer un backup de forma manual, es con el comando tar que nos crea un archivo comprimido y es fácil de usar.

La sintaxis es la siguiente:

tar [parámetros]

Las operaciones mas usadas son:

  • -z: Comprime usando gzip
  • -c: Crea el archivo
  • -v: Verbose mode. (Muestra el progreso mientras se crea el archivo)
  • -f: Para indicar el nombre del archivo
  • -p Conserva los permisos de los archivos
  • -x Extraer

Ejemplo de uso:

Para comprimir un directorio completo, usamos lo siguiente:

tar -zcvf backup-home.tar.gz /home/*  –> Hace un backup de todos los archivos que estan en el directorio home.

Backup del sistema completo:

Si queremos hacer un backup completo del sistema, para que en caso de una perdida total podamos restaurar nuestro servidor de manera completa, datos/programas/configs…  TODO…  debemos ejecutar esto:

tar cvpzf /backup-full.tar.gz –exclude=/proc –exclude=/lost+found –exclude=/backup-full.tar.gz –exclude=/mnt –exclude=/sys –exclude=dev/pts /

Importante: la barra del final “/” no es un error, eso le dice haga el backup desde el root “/”.
Todos esos “exclude” son, como su nombre lo dice, para excluir directorios que el sistema llena con archivos dinamicos, que van a producir errores a la hora del backup, y no son importante.

Como restaurar los backups:

Para restaurar un backup, se utiliza el comando -x

tar -zxvpf /fullbackup.tar.gz  –> extrae los contenidos en el directorio actual, conservando los permisos (-p) .

tar -zxvf backup-home.tar.gz  –> extrae los contenidos en el directorio actual.

tar -zxvf backup-home.tar.gz /home –> extrae los contenidos en /home.

Vulnerabilidad en WordPress Superpuperdomain2.com

Vulnerabilidad en timthumb.php

Sintomas

Lo más probable es que cuando quieras entrar al sitio, tu antivirus, o tu navegador te avisen de que tu sitio esta cargando contenido de superpuperdomain2.com y éste es un sitio maligno. Sino, fijate el codigo fuente de tu web, y al final debes tener algo asi:

<script language=”javascript” SRC=”http://superpuperdomain2.com/count.php?ref=”>

¿Cómo solucionarlo?

Primero, el codigo malicioso, fue insertado en el index.php  de tu blog. Lo debes borrar de ahi.

En segundo lugar, corrige el problema para que no vuelva a suceder…  descarga la ultima version de timthum.php antes de reemplazarlo por el existente en tu theme, hazle los siguientes cambios:

Cambia define( ‘ALLOW_EXTERNAL’, TRUE);  por  define( ‘ALLOW_EXTERNAL’, false);

Y tambien cambia ésto:

$allowedSites = array ( ‘flickr.com’,
‘picasa.com’,
‘img.youtube.com’,
‘upload.wikimedia.org’,
);

Por ésto:

$allowedSites = array();

Para encontrar todos los timthumb.php que puedes tener, (uno por theme, aunque no todos lo usan) pudes hacer desde la consola:
find . | grep timthumb.php

 

Como montar un Servidor Ubuntu Server COMPLETO, con ISPConfig 3 Parte 1

Este post está dedicado a instalar un servidor para hosting multi-cuentas, en una VPS, por ello, no explicare temas relacionados al hardware ni a la instalación del sistema operativo.

Si quieres saber mas sobre las VPS, y cómo elegir una VPS, mira este link.

Este post, está basado en las guías Perfect Server de HowToForge, pero con algunas mejoras.

Ubuntu Server

Para mi, Ubuntu Server, es uno de las mejores distros para iniciarse en el tema de servidores linux, debido a la gran cantidad de información y tutoriales que hay sobre el en la red.

Bueno, en este tutorial usaremos lo siguiente:

  • Ubuntu Server 11.04 como sistema operativo.
  • ISPConfig 3 como panel de administración para cuentas de Hosting.
  • Apache, PHP, MySQL
  • SquirreMail, PostFix
  • PureFTP
  • BIND 9

Comencemos…

Antes que nada, para este tutorial, usaremos server1.example.com como hostname, y supondremos que yas estamos logueados como root. (sino, anteponer sudo a cada comando)

Yo uso nano para editar los archivos, pero pueden usar vi, o cualquier otro.

Para instalar nano, hacemos:
apt-get install nano
Para utilizar nano, se abren los archivos con nano archivo luego, para guardar, se presiona F2, luego decimos que si, (Y) y luego aceptamos con ENTER.

Ahora, cambiamos el hostname:

echo server1.example.com > /etc/hostname
hostname server1.example.com
/etc/init.d/hostname restart

Click Aqui para ver la Parte 2 | Click Aqui para ver la Parte 3

Como montar un Servidor Ubuntu Server COMPLETO, con ISPConfig 3 Parte 2

Parte 2

Procederemos a editar la lista de repositorios, para poder tener los paquetes mas actualizados…
nano /etc/apt/sources.list
Borramos todo el contenido, y copiamos allí el contenido de este archivo.

Ahora, para actualizar nuestra BD de paquetes, y de paso, actualizar algunas versiones de los mismos, hacemos:
apt-get update
apt-get upgrade
Responder que si (Y) a cualquier pregunta.

Configuramos la hora del sistema:
dpkg-reconfigure tzdata
Seguir las instrucciones en pantalla.

Ahora, empezamos a instalar algunos paquetes:
apt-get install postfix postfix-mysql postfix-doc mysql-client mysql-server courier-authdaemon courier-authlib-mysql courier-pop courier-pop-ssl courier-imap courier-imap-ssl libsasl2-2 libsasl2-modules libsasl2-modules-sql sasl2-bin libpam-mysql openssl getmail4 rkhunter binutils maildrop

El sistema nos va a hacer las siguientes preguntas:

New password for the MySQL “root” user: tucontraseñasql
Repeat password for the MySQL “root” user: tucontraseñasql
General type of mail configuration: Internet Site
System mail name: server1.example.com
Create directories for web-based administration? No
SSL certificate required Ok

Preparamos y optimizamos MySQL para una VPS con pocos recursos de RAM:
nano /etc/mysql/my.cnf 
Comentar la linea bind-address=127.0.0.1, tiene que quedar asi: #bind-address = 127.0.0.1 (esto es para poder acceder al servidor MySQL desde otros servers/hosts.)
y cambiar los valores  de algunas de las variables, por los de aqui abajo:

[mysqld]
key_buffer = 16K
max_allowed_packet = 1M
table_cache = 4
sort_buffer_size = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
net_buffer_length = 2K
thread_stack = 64K

También, si no vamos a usar innodb ni Berkeley DB, o ni sabes lo que es eso, agrega estas dos lineas al final del my.conf:
skip-bdb
skip-innodb

Y ahora, reiniciamos el servicio MySQL:
/etc/init.d/mysql restart

Ahora, prepararemos las claves SSL para el servicio de Mail.
cd /etc/courier
rm -f /etc/courier/imapd.pem
rm -f /etc/courier/pop3d.pem

nano /etc/courier/imapd.cnf
Cambiar CN=server1.example.com por tu hostname real

nano /etc/courier/pop3d.cnf
Cambiar CN=server1.example.com por tu hostname real

Ahora, generamos los certificados
mkimapdcert
mkpop3dcert

Y luego reiniciamos los servicios:
/etc/init.d/courier-imap-ssl restart
/etc/init.d/courier-pop-ssl restart

Ahora, instalamos apache, php y algunos modulos y paquetes extras que neesitaremos como phpMyAdmin, suExec, Pear y mcrypt:
apt-get install apache2 apache2.2-common apache2-doc apache2-mpm-prefork apache2-utils libexpat1 ssl-cert libapache2-mod-php5 php5 php5-common php5-gd php5-mysql php5-imap phpmyadmin php5-cli php5-cgi libapache2-mod-fcgid apache2-suexec php-pear php-auth php5-mcrypt mcrypt php5-imagick imagemagick libapache2-mod-suphp libruby libapache2-mod-ruby sudo zip

El sistema nos va a hacer las siguientes preguntas:

Web server to reconfigure automatically: apache2
Configure database for phpmyadmin with dbconfig-common? No

Ahora, ejecutamos los siguientes comandos para habilitar los modulos de apache:
a2enmod suexec rewrite ssl actions include
a2enmod dav_fs dav auth_digest
/etc/init.d/apache2 restart

Click Aqui para ver la Parte 1 Click Aqui para ver la Parte 3

Como montar un Servidor Ubuntu Server COMPLETO, con ISPConfig 3 Parte 3

Parte 3

Continuando con la parte 3 de este tutorial, Instalamos el FTP

apt-get install pure-ftpd-common pure-ftpd-mysql quota quotatool
nano /etc/default/pure-ftpd-common
Cambiar a STANDALONE_OR_INETD=standalone
Cambiar a VIRTUALCHROOT=true

Ahora, habilitamos TLS, y generamos su certificado SSL:

echo 1 > /etc/pure-ftpd/conf/TLS
mkdir -p /etc/ssl/private/
openssl req -x509 -nodes -days 7300 -newkey rsa:2048 -keyout /etc/ssl/private/pure-ftpd.pem -out /etc/ssl/private/pure-ftpd.pem

chmod 600 /etc/ssl/private/pure-ftpd.pem
/etc/init.d/pure-ftpd-mysql restart

Continuamos instalando BIND, y las web stats:

apt-get install bind9 dnsutils
apt-get install vlogger webalizer awstats

Editamos el archivo cron.d,  y eliminamos awstats, ya que luego, ISPConfig 3, insertará sus propias lineas en el cron.d
nano  /etc/cron.d/awstats

(hay que comentar las unicas 2 lineas del archivo, y tiene que quedar asi:)

#*/10 * * * * www-data [ -x /usr/share/awstats/tools/update.sh ] && /usr/share/awstats/tools/update.sh
# Generate static reports:
#10 03 * * * www-data [ -x /usr/share/awstats/tools/buildstatic.sh ] && /usr/share/awstats/tools/buildstatic.sh

Ahora, instalamos Jailkit, que sirve para que cada usuario SSH, no se pueda salir de su directorio /home propio.
apt-get install build-essential autoconf automake1.9 libtool flex bison debhelper

cd /tmp
wget http://olivier.sessink.nl/jailkit/jailkit-2.14.tar.gz
tar xvfz jailkit-2.14.tar.gz

cd jailkit-2.14
./debian/rules binary
cd ..
dpkg -i jailkit_2.14-1_*.deb
rm -rf jailkit-2.14*

Instalamos y configuramos SquirreMail, para poder acceder a nuestros webmails:

apt-get install squirrelmail
ln -s /usr/share/squirrelmail/ /var/www/webmail
squirrelmail-configure 

Aqui, sigue las instrucciones de este archivo, para contestar las preguntas del sistema y configurar el squirreMail.

Una vez configurado el cliente para el webmail, antes de probarlo, configuraremos un par de cosas para hacer que el email funcione sin amavis y clamd, que son sumamente pesados para VPS con bajos recursos.
nano /etc/postfix/main.cf
Comentamos las siguientes lineas:

content_filter = amavis:[127.0.0.1]:10024
receive_override_options = no_address_mappings

Tienen que quedar asi:

#content_filter = amavis:[127.0.0.1]:10024
#receive_override_options = no_address_mappings

nano /etc/postfix/master.cf

Comentamos todas las lineas debajo de  amavis unix – – – – 2 smtp

Tiene que quedar asi:
#amavis unix – – – – 2 smtp
# -o smtp_data_done_timeout=1200
# -o smtp_send_xforward_command=yes

#127.0.0.1:10025 inet n – – – – smtpd
# -o content_filter=
# -o local_recipient_maps=
# -o relay_recipient_maps=
# -o smtpd_restriction_classes=
# -o smtpd_client_restrictions=
# -o smtpd_helo_restrictions=
# -o smtpd_sender_restrictions=
# -o smtpd_recipient_restrictions=permit_mynetworks,rej ect
# -o mynetworks=127.0.0.0/8
# -o strict_rfc821_envelopes=yes
# -o receive_override_options=no_unknown_recipient_chec ks,no_header_body_checks
# -o smtpd_bind_address=127.0.0.1

Y por ultimo reiniciamos postfix:
/etc/init.d/postfix restart

Bueno, hemos llegado al ultimo paso, instalar ISPConfig 3. Si todo ha salido bien, con ejecutar estas ultimas 5 lineas, nuestro servidor estará perfectamente configurado, y listo para alojar paginas web!

cd /tmp
wget http://www.ispconfig.org/downloads/ISPConfig-3-stable.tar.gz
tar xfz ISPConfig-3-stable.tar.gz
cd ispconfig3_install/install/
php -q install.php 
 

Ahora, se ejecutara el instalador de ISPConfig3, hay que presionar enter para dejar los valores por defecto, menos cuando nos pida la clave para MySQL, ahi hay que escribirla, y luego presionar enter…

Y eso es todo! 

Ya podemos acceder a nuestro hosting desde el navegador,  mediante la IP de nuestro server, y al puerto 8080, http://xxx.xxx.xxx.xxx:8080 ahi, hay que loguearse con admin:admin

Bueno gente, espero que les haya servido este tutorial…

Acepto comentarios y criticas!

Saludos

Click Aqui para ver la Parte 1Click Aqui para ver la Parte 2

¿Qué es una VPS?

VPS, o Virtual Private Server, en español significa, Servidor Privado Virtual.

Que es una VPS

¿Qué es una VPS?

Una VPS, es un servidor virtual, que corre en un servidor físico que a su vez también alberga otras VPS. Cada VPS esta completamente aislada de las demás, tanto como de espacio en disco, como en uso del CPU. El manejo de la RAM en una VPS puede ser un poco mas complejo…  lo explico mas adelante en este post.

Una VPS es un paso intermedio, entre un hosting comun, y un servidor dedicado, hay mucha variedad de VPS, la mayor ventaja es que son completamente upgradeables es decir, que en la medida que el servidor fisico lo soporte, podemos aumentar la RAM, la velocidad del CPU, o la velocidad del puerto ethernet, con un par de clicks, instantaneamente.

Otra ventaja con respecto a un hosting compartido comun, es que en el 99% de los casos, NO dependemos de otros usuarios y somos completamente responsables de el uptime del server, ya que si una VPS está usando el CPU al 100%, ésto no afecta a las otras VPS.

Otra ventaja, es la cantidad de sistemas operativos que hay para elegir, también, con solo dos clicks, podemos elegir que distro de linux usaremos, e inclusive versiones de windows server.

 

Sistemas Operativos

¿Cómo elegir una VPS?

Hay dos tipos de VPS, Managed, y Unmanaged, cada una tiene sus ventajas, que explicare ahora, pero  un gran porcentaje de la desicion se basa en el conocimiento de linux (o windows server) que tengamos.

Ventajas de una VPS “Managed“:

  • No necesitas tener conocimientos de servidores.
  • Puedes tener tu hosting online en pocos minutos.
  • Por lo general, el soporte tecnico es mejor que en las Unmanaged.

 

Desventajas de una VPS “Managed“:
  • No tienes acceso al 100% de tu VPS.
  • Dependes del software que te instalen.
  • El precio.

 

Antes de pasar a las VPS “Unmanaged” aclaremos el tema del precio. En general, las “Managed” arrancan en 15 dolares al mes, mientras que “Unmanaged” hay desde 3 dolares al mes.

 

Ventajas de una VPS “Unmanaged“:
  • Acceso al 100% a la VPS.
  • Podemos elegir que programas instalar, y cuales no.
  • El precio.

 

Desventajas de una VPS “Unmanaged“:
  • Necesitas tener conocimientos de Linux o Windows Server.
  • Poco soporte técnico.

 

RAM

Como dije anteriormente, la decisión entre una VPS Managed y una UnManaged, pasa por tus conocimientos de linux.
Cuando ya tengas decidido que tipo de VPS deseas tener, el factor mas importante para la eleccion del plan de VPS, será la memoria RAM.

 

Aqui, tambien tenemos dos puntos a considerar:
  • RAM Dedicada
  • Burstable RAM

La primera, es la RAM que tendremos disponible físicamente garantizada SIEMPRE en nuestra VPS, y la segunda es una RAM compartida entre VPS, que no siempre tendremos disponible, y que solo se usará en casos de urgencia, por ejemplo, cuando un sitio a cierta hora del día, tiene muchas visitas.

 

Algunos de los vendedores, ofrecen burstable RAM, pero otros NO. Por eso, ésta gran ventaja que supone tener más RAM cuando se necesite, puede ser otro factor a tener en cuenta a la hora de elegir una VPS.
Espero sus comentarios, con respecto al tema. En lo personal, a mi me gustan las VPS UnManaged, y en un próximo Post, voy a explicar como montar un Servidor Web COMPLETO, desde cero.

 

Saludos!