Blog de Javi

Proxmox VE (entorno virtual), una plataforma de virtualización de código abierto, muy fácil de usar al ejecutar accesorios y máquinas virtuales, acaba de alcanzar la versión 2.0.

Proxmox VE 2.0 está finalmente disponible, después del lanzamiento de una versión Beta y una versión Release Candidate. Podemos asumir sin dar lugar a dudas que esta versión presenta muchas mejoras y actualizaciones importantes.

Puntos destacados de Proxmox VE 2.0:

• Linux Kernel 2.6.32
• La distribución se basa en Debian Squeeze
• Se implementó una nueva GUI basada en el marco JavaScript Ext JS 4
• Se agregó soporte para múltiples fuentes de autenticación (MS Active Directory, LDAP, Linux PAM, autenticación de Proxmox VE)
• Se han agregado agentes de recursos para KVM y OpenVZ
• Las copias de seguridad se pueden realizar a través de la GUI
• Todos los trabajos pueden controlarse como «tareas recientes»
• Soporte High Availability Cluster para los huéspedes KVM y los contenedores OpenVZ

Hoy vamos a instalar un servidor secundario/failover del servicio DHCP de nuestra red Linux. Como todos sabemos, una simple caida del servidor DHCP puede dejar a toda la red sin funcionar ya que nuestros clientes (si usan el servicio de DHCP), no podran obtener una dirección IP válida y seria imposible que les funcionase algo. Para evitar posibles caidas de este servicio, vamos a instalar un segundo servidor failover.

Suponemos que ya tenemos el servidor principal funcionando en la subred 192.168.200.0/24 como se puede ver en el ejemplo. Tan solo tenemos poner las primeras lineas que estan entre los corchetes de failover, poniendo en address la IP del servidor principal, y en peer adress la IP del servidor failover. Aqui lo vemos:

#
# /etc/dhcpd.conf for primary DHCP server
#
 
authoritative;
ddns-update-style none;
 
failover peer "dhcp-failover" {
   primary; # declare this to be the primary server
   address 192.168.200.2;
   port 647;
   peer address 192.168.200.3;
   peer port 647;
   max-response-delay 30;
   max-unacked-updates 10;
   load balance max seconds 3;
   mclt 1800;
   split 128;
   }
 
subnet 192.168.200.0 netmask 255.255.255.0 {
   option subnet-mask 255.255.255.0;
   option broadcast-address 192.168.200.255;
   option routers 192.168.200.1;
   option domain-name-servers 192.168.200.1;
   pool {
      failover peer "dhcp-failover";
      max-lease-time 1800; # 30 minutes
      range 192.168.200.100 192.168.200.254;
      }
   }

En el servidor secundario quedaria algo asi como lo siguiente. Fijaros que en address pone la IP del servidor secundario, y en peer address la IP del servidor principal:

#
# /etc/dhcpd.conf for secondary DHCP server
#
 
authoritative;
ddns-update-style none;
 
failover peer "dhcp-failover" {
   secondary; # declare this to be the secondary server
   address 192.168.200.3;
   port 647;
   peer address 192.168.200.2;
   peer port 647;
   max-response-delay 30;
   max-unacked-updates 10;
   load balance max seconds 3;
   }
 
subnet 192.168.200.0 netmask 255.255.255.0 {
   option subnet-mask 255.255.255.0;
   option broadcast-address 192.168.200.255;
   option routers 192.168.200.1;
   option domain-name-servers 192.168.200.1;
   pool {
      failover peer "dhcp-failover";
      max-lease-time 1800; # 30 minutes
      range 192.168.200.100 192.168.200.254;
      }
   }

Lo respecto a la declaracion de las subredes, es exactamente igual en un servidor que en otro, por lo que tenemos que tener cuidado al hacer un cambio en un servidor, sea exactamente igual que en otro. Para solucionar esto podemos sacar todo el bloque subnet a un archivo y hacer un include de ese archivo, asi sincronizando el archivo de la subred entre los servidores no hay posible error.

Usando bash uno se acostumbra muy fácilmente al tabulador para autocompletar comandos y ficheros. Pero también podemos autocompletar usuarios y hosts en bash.

La combinación para autocompletar usuarios es la siguiente: Alt-AlGr-4 (Alt-~). En caso que no autocomplete si repetimos la combinación nos dará las opciones disponibles, deberemos añadir más caracteres ya que existe más de una posibilidad:

$ a
abrt adm apache avahi avahi-autoipd

Podemos hacer lo mismo para los hosts con la combinación Alt-AlGr-2 (Alt-@) que igualmente con dos veces nos indicará las opciones:

$ a
adama  apolo

Fuente: Systemadmin

Hoy voy a explicar como hacer una conexion SSH sin necesidad de meter la clave en cada conexion. Esto puede ser util para conexiones desde servidores de Backup, RSYNC, etc…

Lo primero de todo, ejecutamos en el «cliente» el siguiente comando:

javier@gedeon:~$ ssh-keygen -t dsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/javier/.ssh/id_rsa):
/home/javier/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/javie/.ssh/id_dsa.
Your public key has been saved in /home/javier/.ssh/id_dsa.pub.
The key fingerprint is: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Si os fijais, no pongo una clave «passphrase», porque sino en cada conexion, nos pediria la clave del certificado. Una vez hecho esto, lo unico que nos queda por hacer es añadir el contenido del archivo ~/.ssh/id_dsa.pub en el servidor o servidores a los que nos vayamos a conectar en ~/.ssh/authorized_keys

Con esta sencilla operación ya podemos conectarnos sin necesidad de utilizar claves.

Si alguien quiere conocer mas acerca del metodo de autenticación mediante certificados, le invito a que busque sobre ello por Internet, ya que es muy interesante y se usa en muchos campos, tales como firmar digitalmente correo electronico y encriptarlo, conexiones SSL a servidores Web, DNIe, etc…

Para todo aquel que necesite hacer un script en bash y quiera meter la clave de una conexión SSH en línea de comandos para ejecutar scripts, la solución es sshpass. No recomiendo este método, ya que una clave en un script puede ser un problema de seguridad, para ello podemos realizar la conexión SSH con certificados que ya explicaré en otro momento. La idea de esta entrada es para usos puntuales.

wget http://heanet.dl.sourceforge.net/project/sshpass/sshpass/1.05/sshpass-1.05.tar.gz
tar xvf sshpass-1.05.tar.gz
cd sshpass-1.05
./configure
make
make install

Ahora una vez instalado sshpass en nuestro sistema o servidor, la sentencia para conectarnos a ssh es la siguiente:

sshpass -p 'passwd' ssh root@172.25.0.1