Archive
You are currently browsing the archives for the GNU/Linux category.
By Jose Antonio Cely Saidiza
Fail2ban ( http://www.fail2ban.org/ ) es una aplicaci?n que se usa para bloquear conexiones remotas despu?s de una cantidad de intentos fallidos. El funcionamiento de Fail2ban es muy simple, comprueba archivos de log y si detecta registros de intentos fallidos, ejecuta autom?ticamente los comandos de IPTables para bloquear al host que esta intentando realizar la conexi?n. Fail2ban soporta muchos servicios como lo son ftp, apache, imap, pop, etc; incluso tambi?n aplicaciones web.
Para este caso documentar? el t?pico escenario, donde tenemos un servidor Linux conectado a internet permanente y por cuestiones administrativas tenemos el servicio SSH abierto a cualquier IP (!!!). Un servidor de este tipo es muy atacado por robots o creckers con t?cnicas de fuerza bruta, usando sencillamente un script que mediante un diccionario de claves o generador de palabras intenta frecuentemente autenticarse como usuario root.
Por ejemplo viendo los logs de un servidor personal que mont? hace poco, v? como tengo miles de intentos de login remoto. Por ejemplo viendo los ?ltimos intentos de login mediante el comando:
# tail /var/log/auth.log
Veo como un hijo de puta con la direcci?n IP 116.31.116.28 se est? intentando conectar como root. Por los tiempos de diferencia entre cada conexi?n de pocos segundos seguramente es un robot. As? pues, a instalar fail2ban!.
Instalaci?n y configuraci?n
Los siguiente comando se ejecutan como usuario root en el servidor. Si usa sudo antepongalo a los comandos.
Instalamos el paquete est?ndar de Debian Jessie estable:
# apt-get install fail2ban
Una vez instalado copiamos el archivo de configuraci?n para crear una configuraci?n local:
# cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Ahora editamos el archivo recientemente copiado /etc/fail2ban/jail.local, el archivo es extenso y viene casi listo y documentado. Un par?metro t?pico por ejemplo para cambiar es ?bantime?, que es el tiempo que el host remoto tardar? bloqueado hasta que nuevamente fail2ban permita el intento de conexi?n, en mi caso lo edit? para 1200 segundos, es decir, 20 minutos:
bantime = 1200
Por otro lado, confirm? que el servicio SSH este activado y en el caso de esta versi?n de Jessie viene activado por default la supervisi?n:
[ssh]
enabled = true
Si hicimos alg?n cambio, se puede reiniciar fail2ban mediante el comando:
# service fail2ban restart
Esto es todo, failban inciar? a supervisar y bloquear los servicios que hemos definido. Por ejemplo en la siguiente captura realic? tres intentos intencionalmente fallidos al servidor y vemos como en el tercer intento me bloquea:
Ante este caso solo queda esperar el ?bantime? para poder volver intentar a conectarme. Como vemos muy facilmente se puede aumentar la seguridad de nuestros servidores.
??
?Dudas, comentarios, sugerencias?
Sigueme en twitter?@josecely
By Jose Antonio Cely Saidiza
El presente artículo explica paso a paso como montar un servidor de repositorios de código fuente con Git (SCV). Hace años escribí sobre los sistemas de control de versiones, aunque ese artículo hablaba sobre el difunto subversion los conceptos de versionamiento son los mismos. Vale la pena aclarar que Git es mucho más avanzado en funcionalidades respecto a Subversion, una de las principales ventajas de Git, es que este es descentralizado, es decir que cada copia o checkout de código fuente puede ser un repositorio independiente. En este caso el servidor es simplemente el oficial para un proyecto, por decirlo así.
Ahora bien, si estamos hablando de un proyecto de desarrollo en el que hay múltiples desarrolladores, ejemplo en un entorno corporativo; tenemos que poder controlar usuarios, grupos, proyectos, ramas, forks, etc. y en este caso es donde la aplicación Gitlab facilita toda esta administración con una fácil interfaz web. Además esta interfaz es muy similar a el práctico (y no tan económico) GitHub Enterprise.
Instalando el servidor
Para la instalación solo necesitamos un sistema debian Wheezy recién instalado lo más limpio posible.
Actualizamos paquetes
# apt-get update -y
# apt-get upgrade -y
Instalamos dependencias
# apt-get install -y build-essential zlib1g-dev libyaml-dev libssl-dev libgdbm-dev libreadline-dev libncurses5-dev libffi-dev curl openssh-server redis-server checkinstall libxml2-dev libxslt-dev libcurl4-openssl-dev libicu-dev logrotate mysql-server mysql-client libmysqlclient-dev sudo python-docutils
Mysql pedirá password de administrador, poner algo seguro y no olvidarlo!
Instalamos el core git
# apt-get install -y git-core
Instalamos Ruby
Removemos viejas versiones de Ruby 1.8 en caso de tenerlo instalado
# apt-get remove ruby1.8
Bajamos Ruby y lo compilamos:
# mkdir /tmp/ruby && cd /tmp/ruby
# curl –progress ftp://ftp.ruby-lang.org/pub/ruby/2.0/ruby-2.0.0-p353.tar.gz | tar xz
# cd ruby-2.0.0-p353
# ./configure –disable-install-rdoc
# make
# make install
# gem install bundler –no-ri –no-rdoc
Creamos el usuario necesario
# adduser –disabled-login –gecos ‘GitLab’ git
Instalamos GitLab shell
# cd /home/git # su git
# git clone https://gitlab.com/gitlab-org/gitlab-shell.git -b v1.9.1
# cd gitlab-shell
# cp config.yml.example config.yml
Editamos el archivo de configuración con el dominio de nuestro servidor (Ej. suservidordecodigo.com)
# vi config.yml
Después instalamos
# ./bin/install
# exit
Base de datos
Aseguaramos MySQL con el siguiente comando (responder si a todo)
# mysql_secure_installation
Luego nos logueamos como administrador de MySQL
# mysql -u root -p
Creamos el usuario para gitlab (No olvidar cambiar el password por algo más seguro)
mysql> CREATE USER ‘git’@’localhost’ IDENTIFIED BY ‘$password’;
mysql> SET storage_engine=INNODB;
mysql> CREATE DATABASE IF NOT EXISTS `gitlabhq_production` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;
mysql> GRANT SELECT, LOCK TABLES, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `gitlabhq_production`.* TO ‘git’@’localhost’;
mysql> exit;
Comprobamos que podamos ingresar como el usuario git de mysql
# mysql -u git -p -D gitlabhq_production
Si todo es correcto obtendremos el prompot de Mysql después de ingresar el password
mysql>
Salimos
mysql> exit;
GitLab
Nos ubicamos en el directorio de gitlab
# cd /home/git
Hacemos un clone del código fuente
# su git
# git clone https://gitlab.com/gitlab-org/gitlab-ce.git -b 6-7-stable gitlab
Nos ubicamos en el directorio de git
# cd /home/git/gitlab
Copiamos el archivo de configuración de ejemplo
# cp config/gitlab.yml.example config/gitlab.yml
Editamos el dominio cambiando «localhost» por el que corresponda
# vi config/gitlab.yml
Salimos del usuario git
# exit
# cd /home/git/gitlab
Aseguramos permisos en log/ y tmp/
# chown -R git log/
# chown -R git tmp/
# chmod -R u+rwX log/
# chmod -R u+rwX tmp/
# su git
# mkdir /home/git/gitlab-satellites
# exit
# chmod u+rwx,g+rx,o-rwx /home/git/gitlab-satellites
# cd /home/git/gitlab
# chmod -R u+rwX tmp/pids/
# chmod -R u+rwX tmp/sockets/
# chmod -R u+rwX public/uploads
Copiamos el archivo de configuración de Unicorn
# su git
# cp config/unicorn.rb.example config/unicorn.rb
# cp config/initializers/rack_attack.rb.example config/initializers/rack_attack.rb
Configuramos las variables para el usuario git y editamos user.email tal cual como este en gitlab.yml
# git config –global user.name «GitLab»
# git config –global user.email «alfuncorreo@algundominio»
# git config –global core.autocrlf input
Editamos para que el email de gitlab coincida con el usuario git (## Email settings)
# vi config/gitlab.yml
Copiamos archivo de configuración de git
# cp config/database.yml.mysql config/database.yml
# chmod o-rwx config/database.yml
Editamos el archivo de configuración con las credenciales establecidas de mysql
# vi config/database.yml
Instalamos
# cd /home/git/gitlab
# bundle install –deployment –without development test postgres aws
# bundle exec rake gitlab:setup RAILS_ENV=production
# exit
Script de inicio
# cp lib/support/init.d/gitlab /etc/init.d/gitlab
# cp lib/support/logrotate/gitlab /etc/logrotate.d/gitlab
Comprobamos que funciona la aplicación
# su git
# bundle exec rake gitlab:env:info RAILS_ENV=production
Si todo está bien
# bundle exec rake assets:precompile RAILS_ENV=production
# exit
Reiniciamos gitlab
# /etc/init.d/gitlab restart
Servidor web Nginx
# apt-get install -y nginx
# cp lib/support/nginx/gitlab /etc/nginx/sites-available/gitlab
# ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab
Editamos el archivo de configuración para que coincida con la configuración (server_name)
# vi /etc/nginx/sites-available/gitlab
Reiniciamos Nginx para que tome los cambios
# service nginx restart
Primer login
En un navegaor accedemos a la URL de nuestro servidor
El usuario y contraseña por defecto son:
root
5iveL!fe
La primera página nos envía a un formulario para actualizar el password. Obviamente se debe editar por algo seguro.
Después de esto ya podremos acceder a gitlab, crear proyectos, usuarios, etc.
———————————————–
Dudas, comentarios, sugerencias? Sigueme en twitter @josecely
Links
https://www.gitlab.com/
https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/installation.md
By Jose Antonio Cely Saidiza
A la fecha Dropbox no tiene cliente para *BSD, aunque muy solicitado, no hay fechas de RELEASE.
Buscando alternativas en las que no perdiera la sensación de tiempo real con Dropbox en mi Gnome en FreeBSD 9.1, y pensando en no tener que ejecutar comandos constantes para sincronizar, e inspirado en algunas búsquedas; encontré una técnica para que funcione de la manera más transparente Dropbpx en mi Gnome. Supongo con un par de cambios aplica a OpenBSD.
La técnica guerrillera consiste en instalar una máquina virtual (con VirtualBOX, KVM, etc) o usar un computador viejo, y en este montar un Linux y Dropbox, a este combo lo llamaré «servidor Dropbox» (Para Linux si hay daemon oficial para Dropbox). Entonces en FreeBSD solo es montar la partición remota.
Si eres usuario avanzado BSD y lees esto, tal vez te sientas engañado el título del artículo, mis disculpas :)
Hay varias formas de montar la partición remota (NFS, SMB, FUSE, etc); en este caso opté por usar SSHFS (fuse), pues es la más «limpia», por decirlo así, de configurar el pequeño «servidor» Dropbox, solo se instala el sistema base, el servicio ssh y el sistema Dropbox en modo daemon, lo cual es muy «light». Además se puede montar como usuario, nada de editar el fstab o cosas similares.
En mi caso el servidor virtualizado es un i386, con 128Mb RAM, y Debian wheezy y corre como perfectamente bien.
Entonces, primero explicaré como instalar el servidor Dropbox, y luego como configurar FreeBSD para que monte la partición.
Instalando Dropbox en un servidor Linux sin entorno gráfico:
Para el servidor, sirve cualquier Debian básico, entorno mínimo, con sshd. Con el sistema básico, solo hay que seguir las instrucciones para la instalación en la página oficial de www.dropbox.com, con unos pequeños ajustes.
TODOS estos pasos se ejecutan como usuario (en mi caso josecely), ajustenlo a su usuario y por favor… no usen el root para estos menesteres!
Descargamos el instalador de Dropbox de https://www.dropbox.com/install2.
En mi caso para el «servidor Dropbox» virtualicé una máquina de 32 bit, por lo tanto descargue
$cd ~ && wget -O – «https://www.dropbox.com/download?plat=lnx.x86» > dropbox.tar
Descomprimo el instalador:
$tar xf dropbox.tar
Eso es todo, al descomprimir crea una carpeta oculta llamada
~/.dropbox-dist/
En esta carpeta esta el ejecutable y archivos de configuración, no hay que compilar, en hora buena!
Ahora a configurar con su cuenta de Dropbox,. Para esto ejecuto el demonio Dropbox por primera vez manualmente, para que me cree el vínculo temporal de configuración y autorización del servdor.
$~/.dropbox-dist/dropboxd
El comando me informa:
Este cliente no está vinculado a una cuenta…
Visita https://www.dropbox.com/cli_link?host_id=xxxxxxxxxxxxxxxxxxxxxxxxxxe para vincular este equipo.
Tal cual como lo dice, copie y pegué el vínculo en un navegador, ingresé la contraseña de mi cuenta en Dropbox
De esta manera se autorizó la cuenta para el sevidor «El cliente se vinculó correctamente. Te damos la bienvenida, Jose Antonio.»
Ahora descargo el script CLI oficial de Dropbox, una herramienta muy útil para administrar Dropbox desde el shell.
$wget https://www.dropbox.com/download?dl=packages/dropbox.py
Le asigno permisos de ejecución:
$chmod +x dropbox.py
Lo ejecuto para confirmar que funciona correctamente:
$./dropbox.py
Dropbox command-line interface
commands:
Note: use dropbox help <command> to view usage for a specific command.
status get current status of the dropboxd
help provide help
puburl get public url of a file in your dropbox
stop stop dropboxd
running return whether dropbox is running
start start dropboxd
filestatus get current sync status of one or more files
ls list directory contents with current sync status
autostart automatically start dropbox at login
exclude ignores/excludes a directory from syncing
lansync enables or disables LAN sync
Por ejemplo para arrancarlo ejecuto:
$~/dropbox.py start
Starting Dropbox…Done!
Como ya esta autorizada la máquina y tenemos un útil scrip CLI, lo siguiente es configurar el «servidor» para que arranque siempre Dropbox como el usuario. (No olvidar ajustarlo a su usuario). De las cincuenta mil formas de hacerlo, lo agregaremos al arranque CRON:
$crontab -e -u josecely
Agregamos la linea
@reboot ~/dropbox.py start
Reiniciamos el servidor, y comprobamos que arrancó el demonio Dropbox bajo el respectivo usuario, esto lo podemos comprobar con:
$ps aux | grep dropbox
josecely 2900 37.0 15.4 267652 56948 ? Ssl 01:27 1:18 /home/josecely/.dropbox-dist/dropbox
Montando la carpeta remota Dropbox en FreeBSD
Secure SHell FileSystem (SSHFS) es un sistema de archivos para FreeBSD, Linux y otros. Permite montar de modo seguro (sobre ssh) un directorio remoto, como si fuera local, además del lado del servidor, no necesita instalar ni configurar nada especial, el módulo FUSE solo se necesita en el cliente que va a montar el directorio remoto. El servidor remoto solo necesita tener el servicio sshd corriendo.
Los siguientes comandos y configuraciones se probaron en FreeBSD 9.1.
Como usuario root, en la máquina FreeBSD agregamos el package sshfs:
#pkg_add -r fusefs-sshfs
Editamos el archivo /etc/sysctl.conf, agredando la línea:
vfs.usermount=1
Editamos el archivo /etc/rc.conf, agredando la línea:
fusefs_enable=»YES»
Ahora agregamos el usuario que montará la partición al grupo operator, para que quede habilitado para montar y desmontar (No olvidar ajustarlo a su usuario):
#pw usermod josecely -G operator,wheel
Sería prudente, un reinicio:
# reboot
Una vez reiniciado, como usuario en la máquina FreeBSD, creamos el directorio para montar la carpeta Dropbox:
$ cd ~
$mkdir Dropbox
Y viene la magia!, montamos la carpeta remota del «servidor» Dropbox.
$ sshfs -o idmap=user josecely@10.0.0.4:/home/josecely/Dropbox Dropbox
Nótese el «-o idmap=user», es necesario para evitar errores del tipo «Bad file descriptor».
Ingresamos la contraseña del usuario remoto, y listo, la carpeta remota se ve como local, y es transparente para nuestro sistema operativo!
Podemos automatizar aun más, por ejemplo creando un par de llaves para que no pida contraseña, y pegando el comando de montaje al arranque de Gnome.
Dudas, comentarios, sugerencias?
Sigueme en twitter @josecely
——
Links
http://www.freebsd.org/
http://forums.freebsd.org/showthread.php?t=36449
By Jose Antonio Cely Saidiza
Después de 6 años con este weblog abandonado, con tan solo 45 publicaciones, he decidido dar un cambio radical!. En realidad solo 5 publicaciones son relevantes, de resto material de relleno o series de palabras articulando frases que dan la sensación de contenido…
Hace 6 años no existia facebook, twitter, xing, y el único desenfoque y desahogo social, era este weblog… ahora, después de años perdidos en redes sociales que NO facturan (facebook), uso twitter, que por su simplicidad, sirve para calmar mi síndrome de abstinencia de dejar de usar otras redes sociales e interacciones insípidas… Facebook, siempre lo abres, constantemente, aun sabiendo que esta vacío de contenido, como una nevera de pobres!!!
Volviendo al tema del weblog, atrás quedo el diseño Matrixiano extremista que tenía. Muy geek y verde!. No es que ahora este cansando de los documentales «Matrix», el objetivo ahora es aumentar el público lector (Si, duplicar las 3 visitas diarias XD )… os adjunto un resumen estadístico de historial de acceso.
Instale el típico wordpress, con un tema típico y en la barra lateral use plugins genéricos, con algunas pequeñas modificaciones… nada de desarrollar mis propios plugins y tratar de impresionar a un par de geeks, 6 años después ya me da mamera hacer eso… es más, trataré de dejar de hablar del pinguino (Linux) y sus compinches, trataré de enfocarme (si es que escribo algo al respecto de sistemas operativos) en *BSD o alguno de esos unices (por eso el favicon ahora es el logo de FreeBSD), documentación sobre el pinguino hay bastante, creo que ya no puedo aportar algo relevante ahí. Tal vez la parte dos del manual de Nagios, que prometí hace 4 años (y aun preguntan!!!), sea sobre FreeBSD!
Para rematar, y lo más inesperado para algunos, ingresa una nueva temática, y son las ciencias sociales, con nuevas categorías, la «Economía» y el «Análisis financiero»… Un poco cansado de la ciencias exactas, 10 años de investigar y documentar procedimientos, tecnologías, para algunos abstractas, es bueno mirar otros rumbos.
Procuraré un enfoque más conservador, trataré de dejar el humor ácido, el extremismo Linuxero, pero eso si, mantendré la arrogancia u_u. … no se, tal vez sea el acercarme a la crisis de los 30 años, a veces el ser humano se obsesiona con el paso del tiempo y también con su temporalidad… Por eso, como dijo Steve Jobs (aunque fue en referencia a un libro) «Stay hungry, stay foolish«, algo así como «seguid hambrientos, seguid alocados«.
Saludos!
PD.
EL logo del actual weblog (parte superior izquierda) lo puse en base a una INOCENTADA de el 1 de Abril, (día de los inocentes en varios lugares del mundo), las distribuciones de los logos que aparecen la imagen y algunos medios se pusieron de acuerdo para publicar la siguiente noticia:
»
Debian, Arch Linux, openSUSE, grml y gentoo se fusionan. Estamos satisfechos de anunciar el nacimiento de la nueva distribución Canterbury. Canterbury es una combinación de los esfuerzos de la comunidad anteriormente conocida como Debian, Gentoo, Grml, OpenSUSE y Arch Linux para producir un esfuerzo realmente unificado y ser capaces de actualizar un esfuerzo combinado contra los sistemas operativos propietarios, para mostrar que la comunidad de software libre puede realmente ser capaz de trabajar de forma conjunta por un bien común, en lugar de crear una mayor diversidad. Canterbury será más simple tecnológicamente, tan estable como Debian, maleable como Gentoo, con un marco sólido en vivo como grml, y será tan abierta de mente como openSUSE. El desarrollador Arch Linux, Pierre Schmitz explicó: «Arch Linux siempre ha sido favorable de mantener su distribución tan simple como sea posible. «
A una gran mayoria nos hubiera gustado que hubiera sido verdad… Entonces, busque el logo, y le agregue el logo de FreeBSD en la mitad de la mesa, mandando al papayo al resto de distribuciones XD!!!
By Jose Antonio Cely Saidiza
El presente tutorial explica como configurar en servidor de correo por default en Debian (exim), par a que envíe correos a través de una cuenta de gmail. (smarthost on email Google servers).
No es necesario tener IP publica, solo tu cuenta de Gmail!, y un sistema operativo decente (Debian Lenny).
Entre las utilidades, podemos citar la creación de scripts que nos envien información del estado de la máquina. También se podría aprovechar para que nuestros scripts en php envíen email, o aplicaciones que hacen uso intensivo de correo (Ej. Nagios, Asterisk, Gforge, etc).
Además, tienes el registro de email enviados, bien sea con los logs, o en los correos enviados de tu cuenta de Gmail ;) .
INSTALACION Y CONFIGURACION
Ejecutamos:
dpkg-reconfigure exim4-config
(Si no esta instalado, lo sintalamos con apt-get install exim4)
En la reconfiguración/instalación seleccionamos:
* El correo se envía mediante un «smarthost»; se recibe a través de SMTP
* Nombre del sistema de correo: tudominio.xxx
* Direcciones IP en las que recibir conexiones SMTP entrantes: 127.0.0.1
* Otros dominios para los que se acepta el correo: en blanco
* Máquinas para las cuales reenviar correo: en blanco
* Direccion IP o nombre del equipo (smarthost) saliente: smtp.gmail.com::587
* Desea ocultar el nombre de correo local en los mensajes salientes? NO
* Limitar el numero de consultas DNS (Marcación bajo demanda)? NO
* Dividir la configuración en pequeños ficheros? Sí
Ahora editamos el archivo /etc/exim4/passwd.client
vi /etc/exim4/passwd.client
# password file used when the local exim is authenticating to a remote
# host as a client.
#
# see exim4_passwd_client(5) for more documentation
#
# Example:
### target.mail.server.example:login:password
gmail-smtp.l.google.com:yourAccountName@gmail.com:y0uRpaSsw0RD
*.google.com:yourAccountName@gmail.com:y0uRpaSsw0RD
smtp.gmail.com:yourAccountName@gmail.com:y0uRpaSsw0RD
Cambiamos permisos del archivo
chown root:Debian-exim /etc/exim4/passwd.client
Reiniciamos el servidor de correo
/etc/init.d/exim4 restart
Con esto hemos finalizado la configuración, ahora nuestro sistema tendrá la capacidad de enviar email!
EJEMPLO DE USO
* No hay nada mas elegante que enviar un email a traves del shell XD, con el comando mail:
mail jose.cely@xxxx.xxx
Subject: Hola, email enviado desde el Shell
Esto es el cuerpo del mensaje. Es una prueba de mailx.
Un mensaje se acaba con un punto (.) al principio de línea.
.
Cc:
Se podrían hacer scripts para que nos envíen información automática y periódica del estado del estado de la máquina donde corre el servidor!
Para depurar errores en configuraciones, o ver en más detalle que esta pasando, no existe mejor alternativa que ver los logs!
tail /var/log/exim4/mainlog
Dudas, comentarios, sugerencias?
By Jose Antonio Cely Saidiza
La gran mayoría de servidores actuales, posee la potencia suficiente y cantidad de memoria, para poder virtualizar máquinas y en estas correr instancias de sistemas operativos. De esta manera podremos sacarle más provecho a nuestro hardware, y posiblemente reducir costos.
En mi caso de ejemplo, antes usaba 3 máquinas para mi trabajo de desarrollo de software, (1) Mi portátil, en el cual tengo todo lo de producción, el código final, las release oficiales. (2) El servidor de pruebas, (3) El servidor de integración. Pero eso, es historia pasada XD, ahora las dos últimas corren virtualizadas en el portátil (DELL inspiron, 2Gb RAM, Athlon 64 X2).
El siguiente articulo explicará como instalar, crear y configurar maquinas virtuales en un servidor Debian GNU/Linux, utilizando KVM. Estas maquinas virtuales se podrán usar y serán visibles como cualquier otro host de la red.
Para este tutorial necesitamos
1 – Servidor con el sistema Debian (Lenny) base instalado, no es necesario entorno gráfico
2 – Computador con cliente VNC (vncviewer, xtightvncviewer, etc), y cliente ssh.
POR QUE KVM
Las alternativas libres de alto rendimiento que tenemos son 3 (En mi opinión las más importantes):
1 – Virtual Box: Desarrollado por la empresa innotek GmbH, pero SUN Microsystems lo compro, y ahora Oracle compro a SUN… mmmm.. muchos intereses de por medio, no quiero correr riesgos, descarte su uso sin probarlo :D.
2 – XEN: Desarrollado por la Universidad de Cambridge. En este caso Citrix lo compro en el 2007. Citrix cerro el proyecto, tiene un producto gratuito, el XenServer Express Edition, aunque solo puede soportar cuatro máquinas virtuales.
Las versiones actuales se basan en el código ante de su cierre. XEN es el de más alto rendimiento (sin embargo KVM lo supera en varios aspectos).
En el caso de Debian requiere unas versiones empaquetadas especiales del Kernel:
Etch: xen-linux-system-2.6.18-6-xen-686 and xen-linux-system-2.6.18-6-xen-amd64.
Lenny: xen-linux-system-2.6.26-2-xen-686 and xen-linux-system-2.6.26-2-xen-amd64
Y esto fue lo que no me convenció, tener que usar un kernel especifico, en algunas pruebas, después de instalar el kernel el sistema no arranco! Se imaginan si hubiese sido en un servidor remoto!!!. Obviamente buscando en Internet encontré bastante documentación a los problemas que se me presentaban (que fueron bastantes), entonces eran muchos riesgos para una instalación remota, descarte su uso.
3 – KVM (Kernel virtual Machine): Desarrollado por la empresa Qumranet. KVM, como su nombre lo indica, hace parte del núcleo (desde la versión 2.6.20) y herramientas en el espacio de usuario. Por lo tanto no tengo que cambiar el Kernel en ejecución!. La única pega es que requiere un procesador x86 con soporte Virtualization Technology. Sin embargo la mayoría de los procesadores actuales lo soportan, sin embargo si tu procesador es anterior al 2008, lo más probables es que no funcione.
Se está trabajando para utilizar más características de la Virtualization Technology, por lo tanto el tema de rendimiento (que en mis pruebas es más que satisfactorio para usar en producción) mejorara constantemente.
INSTALACIÓN DE KVM Y CONFIGURACIÓN DE RED EN EL SERVIDOR
Asumimos que el servidor tiene el servicio ssh, y podemos acceder a él.
Desde el computador cliente accederemos al servidor para configurar todo lo que necesitamos, aunque esto se puede hacer desde el propio servidor, incluso con herramientas gráficas. Este tutorial esta previsto para el caso que solo tengamos acceso ssh al servidor, es un servidor decente, por ende, no tiene entorno gráfico XD.
Una vez el en servidor;
Detectamos si nuestro procesador soporta virtualización de Hardware
egrep '(vmx|svm)' --color=always /proc/cpuinfo
En mi caso, tengo un procesador AMD Athlon(tm) 64 X2 Dual-Core (se puede ver con cat /proc/cpuinfo), y la salida es la siguiente:
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch
Lo cual significa que si soporta virtualización. Si al ejecutar el comando no produce ninguna salida, puede llorar, su hardware no soporta virtualización y NO HAY NADA QUE HACER!
, lo más probable es que estés trabajan en un procesador un poco viejo, por ejemplo el procesador de mi Desktop ( AMD Sempron) no lo soporta :'( …
Si tenemos suerte, continuamos
// Como buenos Debianitas, primero actualizamos lista de paquetes
apt-get update
// luego instalamos el módulo y utilidades de red
apt-get install kvm bridge-utils
Ahora tenemos que establecer un puente (bridgue) de red en nuestro servidor, para que nuestras máquinas virtuales se puede acceder desde otros hosts como si se trataran de sistemas físicos de red.
Para eso editamos el clásico archivo /etc/network/interfaces:
Por ejemplo, en mi caso esta asi
cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.0.2
netmask 255.255.255.0
gateway 192.168.0.1
Lo editamos ( vi /etc/network/interfaces), modificando algunas lineas para que quede así:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet manual
auto br0
iface br0 inet static
address 192.168.0.2
netmask 255.255.255.0
gateway 192.168.0.1
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off
Obviamente, se debe acondicionar los archivos a su direccionamiento IP.
Después de editado, reiniciamos la red
/etc/init.d/networking restart
Y listo, si ejecutáramos el comando ifconfig, veríamos algo como esto (atención a la interfaz br0):
br0 Link encap:Ethernet HWaddr 00:1c:23:92:4e:d8
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::21c:23ff:fe92:4ed8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:18143 errors:0 dropped:0 overruns:0 frame:0
TX packets:27478 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1084126 (1.0 MiB) TX bytes:16915847 (16.1 MiB)
eth0 Link encap:Ethernet HWaddr 00:1c:23:92:4e:d8
inet6 addr: fe80::21c:23ff:fe92:4ed8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:112400 errors:0 dropped:0 overruns:0 frame:0
TX packets:92086 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:144800236 (138.0 MiB) TX bytes:22306616 (21.2 MiB)
Interrupt:21
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:42 errors:0 dropped:0 overruns:0 frame:0
TX packets:42 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2908 (2.8 KiB) TX bytes:2908 (2.8 KiB)
TRABAJANDO CON MAQUINAS VIRTUALES
Antes que nada necesitamos una partición, o un archivo para que sea usado por la máquina virtual como disco duro, en el caso de usar un archivo, ejecutamos:
qemu-img create disk.deb 4G
El anterior comando crea un archivo, que la maquina virtual interpretara como un disco de 4Gb. Por cada máquina que virtualicemos, obiamente debemos crear su archivo
En nuestro ejemplo, instalaremos un sistema Debian en nuestra maquina virtual (Debian virtualizando Debian, que bonito :P ). Para eso necesitamos descargar una imagen ISO del instalador, en mi caso descargue la ISO del netinstall en la carpeta /home
El comando kvm, trae infinidad de opciones interesantes ( man kvm-qemu ).
Para virtualizar una máquina con 256Mb de Ram, con un adaptador de red Realtek compatible, que arranque desde CDROM, y que el CDROM sea nuestra imagen ISO, ejecutamos:
kvm -hda disk.deb -cdrom /home/debian-501-i386-netinst.iso -boot d -m 256 -net nic,vlan=0,model=rtl8139 -net tap,vlan=0 -vnc :0
Como podemos ver, el final agregamos –vnc :0, lo cual significa que podremos desde ya conectarnos vía VNC al servidor como nuestro cliente de preferencia, desde aca podremos seguir la instalación de Debian sin ninguna novedad! En hora buena.
Después de haber instalado el sistema base, ya no es necesario arrancar desde el CDROM, por lo tanto, siempre que se quiera arrancar esta máquina y acceder desde VNC, ejecutamos:
kvm -hda disk.deb -boot c -m 256 -net nic,vlan=0,model=rtl8139 -net tap,vlan=0 -vnc :0
Nótese que al parametro -boot, se cambio por “c “,. Boot permite los siguiente parametros:
Boot on floppy (a), hard disk (c), CD-ROM (d), or Etherboot (n).
Muy seguramente después de configurada nuestra máquina, algunas veces necesitamos iniciarla sin sesión VNC, o por cuestiones de seguridad. Además también podremos necesitar que corra en modo daemon, entonces ejecutamos:
kvm -hda disk.deb -boot c -m 256 -net nic,vlan=0,model=rtl8139 -net tap,vlan=0 -vnc none -daemonize
Este comando lo podríamos poner (tantas veces como sea necesario por cada maquina) en los scripts de arranque del sistema para que inicien siempre junto con el servidor.
NOTA FINAL
Vimos el funcionamiento básico de virtualización con KVM, para casos de manejar muchas maquinas virtuales, existen front-ends que facilitan mucho el trabajo (virt-install, virt-manager, etc). Tambien se pueden setear inumerables parametros en las maquinas a virtualizar, como en numero de cores del procesador, parametros avanzados de red, más seguridad a VNC, etc.
Dudas, comentarios, sugerencias?
http://www.linux-kvm.org
http://blog.bodhizazen.net/linux/how-to-run-kvm-without-x/
http://www.phoronix.com/scan.php?page=article&item=623&num=4
Consultor, unixero, desarrollador.
