Unknown's avatar

About hvivani

Systems Engineer, Developer, Technical Leader, IT Manager

Migración de Usuarios Linux


Aplicable a: Redhat/CentOS/Fedora.

Los archivos y directorios que referencian a los usuarios son los siguientes:
/etc/passwd – Información de las cuentas de usuario del sistema.
/etc/shadow – Contraseñas encriptadas para cada usuario.
/etc/group – Grupos a los cuales pertenecen los usuarios.
/etc/gshadow – Archivo shadow de los grupos.
/home – Archivos de los usuarios.
Ojo: En el servidor destino no deben existir cuentas de usuario.

En el servidor de origen de las cuentas, creamos un directorio para ir guardando los datos:
# mkdir /root/backuser

Para extraer los usuarios del passwd vamos a usar el gran awk:
# awk -F: ‘($3>=500) && ($3!=65534)’ /etc/passwd > /root/backuser/passwd

El -F es para decirle que el field separator es el “:”.
Luego filtra que $3 (posición 3 en el passwd) sea >=500 y != de 65534. En toda la línea Redhat, los UID y los GID arrancan en el 500.
El resultado lo redirigimos ( > ) al nuevo archivo /root/backuser/passwd

Ahora extraemos los grupos:
awk -F: ‘($3>=500) && ($3!=65534)’ /etc/group > /root/backuser/group

Con el shadow hacemos algo parecido, pero en el awk debemos obtener el nombre de usuario, dado que en el shadow ese es el campo clave:
# awk -F: ‘($3>=500) && ($3!=65534) {print $1}’ /etc/passwd | tee – | egrep -f – /etc/shadow > /root/backuser/shadow

Si existe el gshadow, lo copiamos directamente:
# cp /etc/gshadow /root/backuser

Copiamos estos archivos con scp u otro medio al servidor destino. Es decir, a donde queremos migrar los usuarios:
# scp /root/backuser/passwd root@destino:/root/passwd.bak
# scp /root/backuser/group root@destino:/root/group.bak
# scp /root/backuser/shadow root@destino:/root/shadow.bak
# scp /root/backuser/gshadow root@destino:/root/gshadow.bak

Luego, en el servidor destino, previo backup de los archivos originales en el /etc, “cateamos” los archivos obtenidos con el awk dentro de los del sistema:

# cat /root/passwd.bak >> /etc/passwd
# cat /root/shadow.bak >> /etc/shadow
# cat /root/group.bak >> /etc/group
# cat /root/gshadow.bak >> /etc/gshadow

Con esto tendríamos los usuarios migrados. Ahora nos falta migrar la data contenida en los home’s:

Para esto, lo mas práctico es hacer un rsync, por ejemplo:
# /usr/bin/rsync -vah root@serverorigen:/home/ /home/

Ahora crucen los dedos y reinicien…

Backup de Volúmenes Lógicos en servidor remoto / LVM Snapshot to Remote


Tengo varias máquinas virtuales KVM corriendo en un CentOS. Estas VMs trabajan sobre volúmenes LVM almacenados en /dev/VolGroup01/vm01 , /dev/VolGroup01/vm02, etc
El tema es que necesitaba realizar backups de estos LVMs para tenerlos como respaldo en un equipo backup , y en caso de contingencia levantar la máquina virtual en dicho equipo.
El CentOS que administra todas estas máquinas virtuales, no tiene mas espacio en disco como para hacer snapshots locales de los LVM para luego transferirlos a otro equipo.
Como hacer para mandar estos snapshots a otro equipo? La opción que encontré hasta ahora es la siguiente:

# dd if=/dev/VolGoup01/vm01 | ssh root@equiporemoto “dd of=/var/lib/libvirt/images/vm01.img”

opcionalmente , puedo poner un gzip en el medio para reducir el tamaño del archivo y el tráfico:

# dd if=/dev/VolGoup01/vm01 | gzip |ssh root@equiporemoto “dd of=/var/lib/libvirt/images/vm01.img.gz”

Con esto, teniendo preconfigurada la máquina en el KVM del equipo backup, en caso de necesidad, solo debo descomprimir el archivo y ponerla en marcha.

Si alguien tiene una sicutación similar y le encontró otra vuelta lo escucho ansioso !!!

Crear claves RSA para autenticar por SSH / SSH with RSA key authentication


Material de consulta frecuente, como crear las claves para autenticar SSH y copiarlas al host destino:
Generar la clave:
 $ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/usuario/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/usuario/.ssh/id_rsa.
Your public key has been saved in /home/usuario/.ssh/id_rsa.pub.
The key fingerprint is:
49:6d:6f:08:7b:89:53:a0:67:c9:d3:c0:ff:fd:1c:27 usuario@host
The key’s randomart image is:
+–[ RSA 2048]—-+
|       .o         |
|       o.*       |
|      . O.=     |
|       + O.+   |
|        S +.o.  |
|         o .. E..|
|               +o|
|                o |
|                    |
+————-+

Copiar la clave generada:
$ ssh-copy-id -i /home/usuario/.ssh/id_rsa usuario@hostdestino

Configurar autenticación mysql en ejabberd – ejabberd mysql auth


Si tienen un servidor jabber funcionando, es muy probable que tarde o temprano tengan que cambiar el modo de autenticación por mysql.

Para esto debemos tener instalado el Erlang Sql Native Driver, que lo podemos descargar desde aquí Erlang Mysql Driver.

En el Mysql creamos el usuario ejabberd :

$ mysql -h localhost -u root
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2 to server version: 4.1.16-max

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

mysql> GRANT ALL ON ejabberd.* TO ‘ejabberd’@’localhost’ IDENTIFIED BY ‘password’;
Query OK, 0 rows affected (0.00 sec)

Creamos la base de datos ejabberd :

$ mysql -h localhost -u ejabberd
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 4 to server version: 4.1.16-max

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

mysql> CREATE DATABASE ejabberd;
Query OK, 1 row affected (0.00 sec)

Descargamos el schema (puede descargarse desde otros servidores):

$ wget https://git.process-one.net/ejabberd/mainline/blobs/raw/2.1.x/src/odbc/mysql.sql

Importamos el schema en la base ejabberd:

$ mysql -D ejabberd -h localhost -p -u ejabberd < mysql.sql

Chequeamos la estructura de tablas en la base ejabberd:

$ echo “show tables;” | mysql -D ejabberd -h localhost -p -u ejabberd

Tables_in_ejabberd
last
privacy_default_list
privacy_list
privacy_list_data
private_storage
pubsub_item
pubsub_node
pubsub_node_option
pubsub_node_owner
pubsub_state
pubsub_subscription_opt
rostergroups
rosterusers
roster_version
spool
users
vcard
vcard_search

Ahora en el /etc/ejabberd/ejabberd.cfg modificamos la siguiente configuración (si instalaron el ejabberd desde los fuentes, el cfg puede estar en /opt/ejabberd/etc/):

Comentamos la siguiente línea:

{auth_method, internal}.

Agregamos las siguientes líneas:

{auth_method, odbc}.
{odbc_server, {mysql, “localhost”, “ejabberd”, “ejabberd”, “password”}}.

La configuración del mysql tiene el siguiente formato:

{mysql, Server, DB, Username, Password}

Adicionalmente cambiamos la siguiente configuración:

mod_last a mod_last_odbc

mod_offline a mod_offline_odbc (almacena mensajes offline en el mysql)

mod_roster a mod_roster_odbc (almacena lista de contactos en el mysql)

mod_private a mod_private_odbc

mod_privacy a mod_privacy_odbc

mod_pubsub a mod_pubsub_odbc

mod_vcard a mod_vcard_odbc (almacena descripcion de usuarios en mysql)

Restarteamos el ejabberd por las dudas:

# service ejabberd restart

Con esto cambios tendremos al ejabberd autenticando contra una base de datos mysql.

Como el metodo de conexión es por odbc, es posible aplicarlo a otros motores de base de datos como por ejemplo SQL Server.

Si alguien lo probó con SQL Server puede decirme como les fué…

LVM: Reducir Volúmen Lógico


LVM: Reducir Volúmen Lógico
Como es material de consulta frecuente, aquí va este ayuda memoria:

El filesystem debe estar desmontado, por lo que deberemos bootear en modo “linux rescue” o con un Live CD.
En este ejemplo achicaremos el espacio del filesystem de 60Gb a 50Gb.

Es muy recomendable hacer un chequeo del filesystem antes de achicarlo:

# umount /dev/VolGroup00/LogVol01

# e2fsck -f /dev/VolGroup00/LogVol01

Ojo que el tamaño (50 G)  es el tamaño total del nuevo volúmen lógico.

Redimensionamos el filesystem:

# resize2fs /dev/VolGroup00/LogVol01 50G

Redimensionamos el volúmen lógico:

# lvreduce -L 50G /dev/VolGroup00/LogVol01

Volvemos a montar:

# mount /dev/VolGroup00/LogVol01 /mnt/sysimage

Physical to Virtual with rsync – Migrar Servidores Fisicos a Virtuales


Resulta que me encuentro con un gran tema: como pasar un servidor (linux por supuesto) de físico a virtual sin tener que reinstalarlo por completo.

Un opción que evalúe fué: http://www.mondorescue.org/ (gracias Mauro) esta aplicación (excelente por cierto) permite realizar un backup completo del sistema operativo y lo almacena en archivos .ISO, uno o varios, del tamaño que le indiquemos.
Esta opción no debe descartarse para esta taréa, aunque merece que sea evaluada en otro post.

La opción que hoy nos interesa es la del rsync.
(Vale la aclaración de que hay cientos de maneras de hacer esta taréa. Yo les planteo la que se me ocurrió a mi y dió resultado.)

Para pasar un equipo fisico a virtual con rsync, lo que hice fué lo siguiente:
Crear la maquina virtual destino con los parámetros adecuados, e instalando el mismo sistema operativo base que el servidor físico (en mi caso un CentOS 5.5).
Para que? Para que el filesystem sea lo mas parecido entre el orígen y el destino.

En el equipo físico realice un rsync como el siguiente:
# rsync -vah –exclude-from=excludes.cfg / root@equipo-virtual:/

En el excludes.cfg puse lo siguiente:

/proc/
/tmp/
/mnt/
/mirror/
/etc/fstab
/etc/grub/
/etc/sysconfig/network-scripts/ifcfg-eth0

En el equipo virtual necesito que el fstab mantenga la configuración original, al igual que la placa de red y el grub. Es por eso que están en la exclusión.

Una vez realizado el rsync, y verificado que se hayan copiado todos los directorios, en la maquina virtual, necesitamos bootear con el CD de intalación en modo rescate “linux rescue” para hacer la reinstalación del grub:

# grub-install /dev/hdc

Si el grub-install nos da el error:
“/dev/hdc does not have any corresponding BIOS drive”
Lo resolvemos agregando la siguiente línea en el /boot/grub/device.map:
(hd2) /dev/hdc

Un detalle muy importante:
Va a ser necesario generar una nueva imagen de los módulos del kernel dado que el initrd del equipo fisico, tiene una entrada (init) donde guarda los nombres de los dispositivos de disco en uso (sda, sdb, etc) y por mas que hayamos guardado el fstab de la máquina virtual, en el momento de booteo va a buscar estos dispositivos definidos en el initrd.
Para crear un nuevo initrd que se utilizará en el booteo hagamos lo siguiente:
Hacemos un backup primero del actual en uso:
# cp initrd-$(uname -r).img initrd-$(uname -r).img.back

Compilamos uno nuevo:
# mkinitrd initrd-$(uname -r).img $(uname -r)

Con esto, la máquina virtual debería reinicar correctamente y deberíamos tener el sistema operativo funcionando igual que en el equipo físico.

KVM: Configurar Bridged Networking – Adaptador Puente


Bueno, resulta que entrando en el mundo de la virtualización, este es un tema de consulta permanente, así que merece la presente entrada.

Aplicable a: Fedora / CentOS / Redhat con KVM / qemu / libvirt

– Deshabilitar el Network Manager. Aparentemente el Network Manager no soporta el bridging.

# chkconfig NetworkManager off
# chkconfig network on
# service NetworkManager stop
# service network start

Otra opción para no deshabilitar el servicio es editar el /etc/sysconfig/network-scripts/ifcfg-eth0 y agregar la entrada: “NM_CONTROLLED=no”.

– Creamos las interfaces bridge:

Editar el /etc/sysconfig/network-scripts/ifcfg-eth0 y agregar la entrada:

BRIDGE=br0

Crear el archivo /etc/sysconfig/network-scripts/ifcfg-br0

con un contenido similar a este:

DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0

Ojo que “Bridge” es case-sensitive y va como en el ejemplo.

– Restarteamos la red

# service network restart

– Configuramos las iptables para que permitan que el trafico sea redirigido forwarded a través del bridge:

# iptables -I FORWARD -m physdev –physdev-is-bridged -j ACCEPT
# service iptables save
# service iptables restart

Opcionalemente podemos evitar que el trafico del puente sea procesado por las reglas de las iptables. Esto lo hacemos modificando los parámetros del kernel en el /etc/sysctl.conf y agregando las siguientes líneas:

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

Luego, releemos los parametros del kernel:

# sysctl -p /etc/sysctl.conf

– Restarteamos el libvirt daemon:

# service libvirtd reload

Ahora, debería aparecer el “shared physical device” habilitado.

– Podemos chequear el bridge de la siguiente manera:

# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes
br0             8000.000e0cb30550       no              eth0

Ojo que este bridge es completamente independiente del virbr0.

El virbr0 se utiliza unicamente para hacer NAT.

Configurando Quotas de disco


Para poder establecer quotas de disco en una determinada partición debemos indicar un parametro adicional en el momento del montaje de la partición.
Esto lo hacemos agregando el parametro “usrquota” (para usuarios) o el parametro “grpquota” (para grupos) en el /etc/fstab.
Por ejemplo, para establecer las quotas de usuario y grupo en el punto de montaje “home”:
/dev/hda2 /home ext3 defaults, usrquota 1 1

Remontamos la partición para que tengan efectos los cambios que hicimos en el fstab:
# mount -o remount /home

Creamos la base de datos de quotas en el filesystem:
# quotacheck -vcugm /home

Iniciamos las quotas:
# quotaon -a /home

Para establecer las quotas:
# edquota usuario

Disk quotas for user usuario (uid 500):
  Filesystem                                               blocks       soft       hard     inodes     soft     hard
  /dev/mapper/VolGroup00-LogVol00    2044          0          0           315         0         0

Significado de cada campo:
Blocks: Son bloques utilizados. 1k blocks.
soft: Limite Soft, a partir de donde avisa.
hard: Limite Hard, a partir de donde niega la escritura.
Inodes: Limite de inodos utilizados.
soft: Limite Soft, a partir de donde avisa.
hard: Limite Hard, a partir de donde niega la escritura.

O podemos hacer directamente 
# setquota usuario 4096 5120 40 50 /home

Para consultar las quotas podemos usar los comandos quota o repquota entre otros.

Configurar iJab chat client con ejabberd


Bueno, como esta configuración me dió bastante laburito, acá vamos con los detalles.
Primero vale la pena aclarar que lo que vamos a hacer es instalar el cliente jabber iJab, que es un cliente web que se posiciona en la parte inferior del navegador y se asemeja mucho al cliente de chat web de gmail o de facebook.

Consideremos además que, independientemente del cliente que usemos, debemos instalar un servidor jabber. Yo he instalado el ejabberd sobre CentOS.

El servidor jabber se puede descargar desde aqui: http://www.ejabberd.im/
El cliente web iJab se puede descargar desde aqui: http://code.google.com/p/ijab/

Puertos: en el dominio donde se instale el jabber, debe abrirse los siguientes puertos para que puedan funcionar con el cliente iJab y el jabber: 5222, 5280, 5269.

Respecto de la instalación del servidor jabber, es bastante intuitiva, solo remarcaré los puntos importantes en el archivo de configuración para que el servidor funcione correctamente con este servicio:
En el ejabberd.cfg, asegurarse de que las siguientes secciones están habilitadas y seteadas:

{hosts, [“jabber.example.com”]}.


{listen,
{5280, ejabberd_http, [
                       %%{request_handlers,
                       %% [
                       %%  {[“pub”, “archive”], mod_http_fileserver}
                       %% ]},
                       %%captcha,
                       http_bind,
                       http_poll,
                       web_admin
                      ]}


{modules,
      {mod_http_bind, []},

Teniendo esto configurado, si apunto el navegador a: http://jabber.example.com:5280/http-bind/

Debería tener como respuesta una página con algo así:
ejabberd mod_http_bind
An implementation of XMPP over BOSH (XEP-0206)
This web page is only informative. To use HTTP-Bind you need a Jabber/XMPP client that supports it.

Yendo a la configuración del iJab, vamos a descomprimir el paquete directamente dentro de /var/www/html/ijab.

En dicho directorio, configuramos un .htaccess con el siguiente contenido:
AddDefaultCharset UTF-8
Options +MultiViews

        RewriteEngine On
        RewriteRule http-bind/ http://jabber.example.com:5280/http-bind/ [P]

En el paquete del iJab hay un archivo a configurar: el ijab_config.js
Dentro hay que modificar las siguientes líneas:
        domain:”example.com”,
        http_bind:”http://jabber.example.com/http-bind/&#8221;,
        host:”localhost@jabber.example.com”,
        port:5222,
        server_type:”ejabberd”,

 
Luego, en el /etc/httpd/conf/httpd.conf creamos el siguiente directorio virtual:
VirtualHost *:80>
  ServerName jabber.example.com
  DocumentRoot /var/www/html
 
     Options +Indexes +Multiviews
     AllowOverride all
 
  AddDefaultCharset UTF-8
  RewriteEngine on
  RewriteLogLevel 9
  RewriteRule http-bind/ http://jabber.example.com:5280/http-bind/ [P]
  CustomLog /etc/httpd/logs/http-bind_access.log combined
  ErrorLog /etc/httpd/logs/http-bind_error.log

Restarteamos el apache y listo.
# service httpd restart

Con esta configuración en el apache estamos seteando los archivos de log para poder verificar cualquier problema. En principio, antes de configurar el apache hay que verificar que el http-bind esté funcionando correctamente en la dirección http://jabber.example.com:5280/http-bind/

Si esto no devuelve la respuesta del servidor jabber, hay algo mal configurado en el mismo.

Lentitud en Mysql


El tema es que por una situación muuuuyyy particular, un cliente me pidió sacar el Mysql que tenía funcionando perfectamente en un linux CentOS para pasarlo a un Windows 2003 Server …!!! WTF !!

Entonces, me pongo manos a la obra, le instalo el motor, le instalo el repositorio de datos en un storage externo que tenía, restauro los datos, etc, etc, etc.
La cuestión es que cuando va a levantar los sitios que laburan con ese mysql, las primeras consultas funcionan, pero luego se pone cada vez mas lento hasta ya no responde para nada….
Buscando el motivo por todos lados, mientras el cliente me putea en todos los lenguajes que conoce, encuentro en los logs del mysql “unauthenticated user”. Prácticamente una línea por cada consulta emitida contra el servidor.
Buscando info por ahí encuentro que no es un problema con el usuario del mysql sino que es un tema de resolución de nombres (DNS’s). Resulta que el mysql además de comprobar el usuario, trata de resolver el host. Al estar en un windows sin DNS, no tenía manera de resolver el nombre del host.
Hay varias maneras de solucionarlo: Hacer resolver el windows instalando un DNS, utilizar todas las referencias con IPs en vez de nombres de host, o agregar en el my.cnf una línea: “skip-name-resolv”.
Espero haber llegado a tiempo para alguno con el mismo problema.