NUEVO TALLER. INSTALACIÓN Y CONFIGURACIÓN DE CLIENTES LIGEROS CON TCOS


!Bienvenido al taller de clientes ligeros con Tcos!

A los largo de los años los clientes ligeros han aparecido y desaparecido de los escritorios. Ahora han venido debido los crecientes costos de mantenimiento de las redes actuales. Un cliente ligero es una computadora conectada a la red (cliente) en una arquitectura cliente servidor que tiene muy poca o ninguna lógica del programa, por tanto depende principalmente del servidor central para las tareas de procesamiento.

La palabra liviano se refiere a lo pequeña que es la imagen de arranque, quizá no más grande que la requerida para conectar a la red y arrancar un navegador web.

En este taller tendrán la oportunidad de aprender a instalar y configurar una red de clientes ligeros usando Tcos en un servidor Debian Lenny 5.0

Acceda al Taller

Como autenticar maquinas linux (ubuntu) contra un servidor PDC Samba


Hola, despues de tanto navegar, por fin encontre la receta, aqui les va:

1. Necesitamos instalar los siguientes paquetes:

sudo apt-get install libnss-ldap libpam-ldap nscd

Nos saldrá una ventana de configuración, dende:

* Establecemos el servidor LDAP. aquí ponemos la dirección ip del server que corre el servicio LDAP de la forma:

ldap://192.168.0.1 y presionamos Enter

* Posteriormente entramos el (Distinguished name of the search base), en mi caso dc=vn,dc=pri,dc=jovenclub,dc=cu
* Establecemos la versión de LDAP, (3).
* En la opción (Make local root Database admin) le decimos NO
* En la opción (Does the LDAP database require login?) le decimos NO

2. Ahora necesitamos configurar los pam.d

* Editamos el fichero /etc/pam.d/common-account y nos aseguramos de que tenga la siguiente configuración:

account required pam_unix.so
account sufficient pam_ldap.so

NOTA: En mi experiencia, el orden de las opciones creo es importante. En caso de exitir alguna de las opciones que debemos adicionar, las comentamos y las ordenamos segun aparece en este tutorial.

* Editamos el fichero /etc/pam.d/common-auth y nos aseguramos de que quede de la siguiente forma:

auth sufficient pam_unix.so
auth sufficient pam_ldap.so try_first_pass
auth required pam_unix_auth.so

* Editamos /etc/pam.d/common-password y nos aseguramos que quede de la siguiente forma:

password required pam_unix.so nullok obscure min=4 max=8 md5
password sufficient pam_unix.so use_authtok md5 shadow
password sufficient pam_ldap.so use_authtok

* Editamos /etc/pam.d/common-session y nos aseguramos que quede de la siguiente forma:

session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
session required pam_unix.so
session optional pam_ldap.so

Ya tenemos todos los ficheros pam.d necesarios para la autenticacion contra el dominio.

3. Ahora Modificar el Nsswitch que se encuentra en /etc/nsswitch.conf y nos aseguramos que quede de la siguiente forma:

passwd: compat ldap
group: compat ldap
shadow: compat ldap

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis

En Ubuntu 8.04 solo hay que añador ldap en las tres primeras opciones, lo dema viene por defecto.

4. Por ultimos reiniciamos nscd /etc/init.d/nscd restart y a disfrutar de la autenticación contra el pdc

Configurar CVS para el control y desarrollo de Proyectos


Hola!!!

Siempre me pregntaba como un grupo de programadores juntaban todo el codigo mientras desarrollaban una aplicacion.

Bueno, ayer un colega y yo comenzamos a realizar un proyecto en Django y nos pruntamos como hacerlo, investigamos un poco por la red y rapido encontramos a CVS. Esto nos permitiría implementar un sistema de control de versiones: mantiener el registro de todo el trabajo y los cambios en los ficheros (código fuente principalmente) que forman el proyecto (de programa) y permite que distintos desarrolladores (potencialmente situados a gran distancia) colaboren.

Basicamente se utiliza en el desarrollo de un proyecto informatico para llevar un control de los ficheros del codigo y evitar por ejemplo que el codigo que escribe un usuario sea “machacado” con el codigo de otro usuario. Ademas con un sistema de control de versiones, el programador siempre puede disponer de la ultima version del codigo lo que ayuda a continuar con el desarrollo del proyecto.

Te pondre un ejemplo de para que sirve todo esto.

Imagina dos programadores que estan trabajando en el mismo proyecto, y casualmente ambos estan modificando el mismo fichero de codigo. Cuando uno de ellos actualice ese fichero en el repositorio se queda marcado, de tal manera que cuando el otro intente subir al repositorio de codigo ya ve, que ese fichero ha sufrido una modificacion desde la ultima vez que el se actualizo, lo que le obliga, a traerse de nuevo ese fichero (con los cambios que haya realizado el primer programador), añadir los suyos y volver a subir el fichero. Sin un mecanismo de control de versiones, ese cambio se perderia, el primer desarrollador subiria el fichero y el segundo subiria su version. Esto para un fichero es controlable, pero cuando tienes miles de ficheros y miles de lineas de codigo significa un desastre total. Por eso el control de versiones es necesario.

Para instalar el servidor y el cliente cvs ejecutamos:

sudo apt-get install cvs cvsd

En un momento determinado nos pedira la ruta para el repositorio, pon por ejemplo /cvsrepo. Este es el directorio a partir del cual se ira colgando todos aquellos modulos/proyectos que administremos con el CVS.

Este directorio lo vamos a definir a partir de /var/lib/cvsd, asi que realmente el path completo seria:

/var/lib/cvsd/cvsrepo

Ejecutamos las siguientes secuencias de comandos:

$ sudo cvsd-buildroot /var/lib/cvsd

Si la carpeta cvsrepo no existe, la creamos

$ cd /var/lib/cvsd
$ sudo mkdir cvsrepo

Le damos permisos sobre la carpeta al usuario cvsd

$ sudo chown -R cvsd:cvsd cvsrepo

Inicializamos el repositorio

$ sudo cvs -d /var/lib/cvsd/cvsrepo init

creamos un usuario cvs y le damos una password.

$ sudo cvsd-passwd /var/lib/cvsd/cvsrepo <username>

por ejemplo:

sudo cvsd-passwd /var/lib/cvsd/cvsrepo papo

Ahora editamos el fichero:

sudo vi /var/lib/cvsd/cvsrepo/CVSROOT/config

Cambiamos “#SystemAuto=no” a “#SystemAuto=yes”

Ya tenemos todo funcionando. Para comprobar que accedemos:

cvs -d :pserver:username@localhost:/cvsrepo login
cvs -d :pserver:username@localhost:/cvsrepo checkout .

Por ejemplo:

cvs -d :pserver:papo@localhost:/cvsrepo login

Seria adecuado exportar la variable CVSROOT del siguiente modo:

export CVSROOT=:pserver:papo@localhost:/cvsrepo

o el valor que fuera, de esta manera ya no necesitariamos especificarla cada vez que fueramos a usar un comando “cvs”.

Ahora podriamos logarnos con:

cvs login

y por ejemplo colocarnos en la carpeta (dentro) de un proyecto que quisieramos subir al CVS y ejecutar:

cvs import -m “ficheros iniciales” MiProyecto HEAD MAIN

Con esto importamos el proyecto a CVS

Ahora podemos usar algun cliente CVS para descargar el proyecto desde el repositorio, yo estoy usando Cervisia que se integra muy bien a Quanta.

Espero que esto les sea de ayuda.

Perfil mandatorio en linux.


Hola.

En este artículo explicaré como crear un perfil mandatorio en una maquina linux, en este caso el perfil no se descarga del servidor ni tampoc funciona como en los Window$, pero por lo menos se logra mantener un escritorio limpio y organizado en un laboratorio donde acceden numerosas personas cada dia.

Utilizaremos los archivos temporales del sistema operativo, asi nos aseguramos que cuando se reinicie la maquina se borren todos loa archivos que el usuario a dejado.

Primero debemos un script que cree una carpeta llamada usuario en el directorio /tmp del sistema

#!/bin/bash
# script sencillo para generar carpetas temporales
# Crea carpeta temporal llamada usuario
mkdir /tmp/usuario
# Crea sub carpetas dentro de usuario
mkdir /tmp/usuario/documentos
mkdir /tmp/usuario/videos
mkdir /tmp/usuario/canciones
#Crea enlace simbolico en /home/usuario
ln -s /tmp/usuario /home/estudiante/Escritorio/usuario

La última línea crea un enlace simbolico al Escritorio del estudiante, que sera donde unico tendrá permisos de escritura.

El script que lo podemos guardar con el nombre perfil, y lo podemos guardar en /usr/bin

Ahora para que este script se inicie cada vez que arranque la sesion del usuario estudiante usando gnome debemos de ir a :

Sistema –> Preferencias —>Sesiones

en la pestaña Programas de Inicio hacemos clix en el boton Añadir, luego donde dice Orden pongo la ruta completa donde guarde mi script en este caso:

/usr/bin/perfil

Luego abro terminal le doy permisos de ejecucion al script
$chmod +x /usr/bin/perfil

Ahora como root le doy permisos de solo lectura a /home/estudiante (para evitar que el usuario pueda escribir, guardar y/o modificar archivos en /home/estudiante)

Como se han dado cuenta estoy forzando a que se guarden los documentos en /tmp/usuario

Es cuestion de poner un aviso y decir que pueden guardar sus documentos en la carpeta usuario.

Listo cada vez que se reinicia el sistema se borran todos los archivos que estan dentro de /tmp/usuario y la carpeta usuario se vuelve a crear cada vez que se reinicia el sistema.

Es solo un pequeno ejemplo de lo que se puede hacer. Espero que sea de utilidad.

Linvix

Clientes Ligeros con TCOS y Ubuntu


En esta guie explicare como logre instalar Tcos para clientes ligeros usando como servidor una maquina con Ubuntu 8.04.

1. Lo primero que debemos hacer es importa la clave GPG de TCOS

# wget http://www.tcosproject.org/mariodebian-pub.key
# apt-key add mariodebian-pub.key

2. Despues debemos agregar al sources.list el siguiente repo:

deb http://www.tcosproject.org/ hardy main

NOTA: En mi caso uso Hardy (8.04)

3. Actualizamos con:

# apt-get update

4. Posteriormente instalamos Tcos

# apt-get install tcos

Nos pedirá instalar otras aplicaciones, le decimos que “Sí” y esperamos que bajen los paquetes y se instalen.

5. Creamos el directorio /tftpboot

# mkdir /tftpboot

6. Luego se corre el siguiente comando:

# dpkg-reconfigure initramfs-tools-tcos

Estos dos últimos comandos deben correrse ya que tcos nunca creará directorios no-standard por su cuenta. Bien, ya casi  estamos listos, necesitamos verificar mediante synaptic (por ejemplo) que las siguientes aplicaciones estén instaladas:

1. x11vnc
2. freenx
3. alsa-base alsa-utils
4. pulseaudio pulseaudio-utils libflashsupport
5. paman pavucontrol pavumeter
6. ltspfs-client
7. ltspfs-server
8. tcos-server-utils
9. tcosmonitor (Remote management support)
10. tcosconfig (GUI Wizard to build images)
11. dhcp3-server | dhcp-server
12. atftpd
13. openbsd-inetd
14. syslinux
15. xfs
16. tcos-etherboot
17. discover | discover2

7. TCOS Config

Bien, comenzamos corriendo la herramienta tcosconfig, que será la encargada de preparar las imágenes que luego descargarán los clientes. Hay una excelente galería de imágenes para seguir paso a paso (http://wiki.tcosproject.org/Utils/TcosConfig/es). Por lo general la plantilla tcos.conf.all activa la mayoria de las opciones necesaria. Esta herramienta gráfica nos ayuda muchísimo ya que con unos pocos clics podemos llegar a obtene en pocos minutos las imágenes del kernel de los clientes aún sin saber mucho de cuestiones técnicas.

NOTA 1:Durante e proceso de creacion de la imagen debemos observar bien el log que se genera mientras se crea la imagen, es posible que necesitemos instalar otros paquetes (como se puede observar en el Warning), debemos fijarnos bien en el log, y generar la imagen nuevamente si es necesario la instalacion de algun paquete

Warning: PulseAudio overwrite /usr/bin/esd
and cache package not found.
# gentcos -instpkg esound libesd0

Esto se soluciona tan solo con ejeutar el comando q nos muestra: # gentcos -instpkg esound libesd0

Siempre debemos leer bien el log de la creacion de la imagen para solucionar cualquier problema.

8. GDM

Hay que tocar el archivo de configuración de GDM (En caso de usar Gnome, el gestor de escritorio que viene por default en Ubuntu). Simplemente cargamos este archivo

# nano /etc/gdm/gdm.conf

y cambiamos las siguientes líneas a fin de obtener lo siguiente:

[security]
DisallowTCP=false

[xdmcp]
Enable=true

Y grabamos y salimos

Luego debemos reiniciar gdm para que tome los cambios (se nos va a ir todo el entorno gráfico!, no preocuparse)

# /etc/init.d/gdm restart

9. XDM

Editamos ahora el archivo del servidor de fuentes.

# nano /etc/X11/fs/config

Y comentamos la línea que dice:

no-listen = tcp

a fin de dejarla así:

#no-listen = tcp

Grabamos y salimos.

10. DHCP

Debemos configurar dhcp3-server para que asigne las direcciones ip a los clientes.

editatamos /etc/dhcp3/dhcpd.conf

INTERFACES=”eth0″;
#Configurando la primera subred la cual escucha en eth1 (192.168.0.0/24)(RED LOCAL JC)
authoritative;
# Si se desea que el servidor DHCP actualize automaticamente la zona DNS Utilizar ddns-update-style interim;
ddns-update-style none;
subnet 192.168.0.0 netmask 255.255.255.0 {
use-host-decl-names on;
range dynamic-bootp 192.168.0.240 192.168.0.250;
default-lease-time 1800;
max-lease-time 3600;
get-lease-hostnames   true;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.0.255;
#option routers 192.168.0.1;
option domain-name-servers 192.168.0.1;
option domain-name “vn.pri.jovenclub.cu”;
option netbios-name-servers 192.168.0.1;
option netbios-node-type 8;
option ntp-servers 192.168.0.1;
option time-offset 3600;
option tftp-server-name “server-tcos”; #Este parametro indica el nombre del servidor TCOS
next-server 192.168.0.61;              #Este parametro debe indicar la IP del servidor TCOS
filename “/tftpboot/tcos/pxelinux.0”;  #LA ruta donde esta la imagen de arranque, por defecto es esta
}

#Aqui establecemos IP por MAC a los clientes
host pc1 {
hardware ethernet 00:16:76:B3:49:8B;
fixed-address 192.168.0.50;
}
host pc2 {
hardware ethernet 00:16:76:B3:3A:67;
fixed-address  192.168.0.51;
}
host cliente {
hardware ethernet 00:19:D1:E0:9C:A5;
fixed-address 192.168.0.70;
}
host server-tcos {
hardware ethernet 00:19:D1:E0:9C:A5;
fixed-address 192.168.0.61;
}

Ahora podemos reiniciar dhcp

# /etc/init.d/dhcp3-server restart
Si el servidor Tcos y DHCP no residen enla misma maquina entonces hay que decirle a tcos donde debe de ir a buscar la informacion que necesita, en este caso el servidor tcos tiene ip 192.168.0.61 y el servidor dhcp 192.168.0.1

Debemos editar el fichero /etc/tcos/pxelinux.cfg.tpl y en la etiqueta “label tcos” anadir al final, despues de splash lo siguiente:

tftpserver=192.168.0.61 xserver=192.168.0.61 fontserver=192.168.0.61

Y debemos volver a generar la Imagen con TcosConfig como se describio en el paso 7

esto hace que el cliente ligero utilice este servidor(192.168.0.61) para cargar todos los parametros correctamente, de lo contrario se intentaran cargar desde el servidor dhcp(192.168.0.1) y el cliente ligero no lograra iniciar correctamente.

11. Reiniciamos la maquina y todo debe de salir perfecto

Sugerencias Adicionales

Si el servidor Tcos que tenemos no dispone de mucha RAM podemos instalar el entorno de escritorio Xfce4, que es mas ligero y aumentara el rendimiento. Si lo instalamos y no incia el cliente ligero, vamos Sistema –> Administracion –> Ventana de Entrada y en Remota seleccionamos Igual que la Entrada Local

Bueno. Con esta guia he realizado la instalcion en dos ocaciones en ubuntu, escucho musica, navego por la red,etc… aunque mi servidor tcos no dispone de mucha RAM me siento muy contento por el logro de poder darle vida a equipos viejos.

Agradecimientos a Mariodebia, que es el encargado del proyecto Tcos por su activa colaboracion en la lista y felicitarlo ademas por tan buen trabajo.

Bibliografia:

La pagina del proyecto Tcos es ( La documentacion esta en espanol)

http://wiki.tcosproject.org/
http://wiki.gleducar.org.ar/wiki/Instalaci%C3%B3n_tcos

PAM como mecanismo de autenticación centralizada.


PAM como mecanismo de autenticación centralizada.

Los programas que conceden accesos a usuarios en un sistema utilizan autenticación para verificar sus identidades.

Históricamente, cada programa tiene su forma particular de realizar la autenticación. Bajo FreeBSD muchos programas son configurados para usar un proceso de autenticación centralizado llamado PAM (Pluggable Authentication Modules).

PAM utiliza una arquitectura conectable y modular, que otorga al administrador del sistema de una gran flexibilidad en establecer las políticas de autenticación para el sistema.

En la mayoría de los casos, el archivo de configuración PAM predeterminado para una aplicación que soporta PAM es suficiente. Sin embargo, a veces queremos almacenar los usuarios en una base de datos para centralizar algunos servicios.

Ventajas PAM

PAM ofrece las ventajas siguientes:

  • Un esquema de autenticación común que se puede usar con una gran variedad de aplicaciones.
  • Gran flexibilidad y control de la autentificación tanto para los administradores de sistemas como para los desarrolladores de la aplicación.
  • PAM es un mecanismo flexible para la autenticación de usuarios.
  • Permite el desarrollo de programas independientes del mecanismo de autenticación
  • Ofrece al administrador la posibilidad de implementar complejas políticas de autenticación para cada servicio.
  • Ofrece un esquema de autenticación centralizado.
  • Permite a los desarrolladores de aplicaciones abstraerse de los mecanismos de autenticación.
  • Facilita el mantenimiento de las aplicaciones

Como podemos ver PAM ofrece muchas ventajas que en ocasiones los administradores ignoramos.

Archivos de configuración y servicios PAM

El directorio /etc/pam.d/ contiene los archivos de configuración de PAM para cada aplicación tipo PAM. En versiones antiguas de PAM se utilizaba /etc/pam.conf, pero este archivo ya no se utiliza y solamente es usado si el directorio /etc/pam.d/ no existe.

Cada aplicación tipo PAM o servicios tiene un archivo dentro del directorio /etc/pam.d/. Cada uno de estos archivos lleva el nombre del servicio para el cual controla el acceso. Depende del programa tipo PAM definir el nombre de su servicio e instalar su archivo de configuración en el directorio /etc/pam.d/. Por ejemplo, el programa login define su nombre de servicio como login e instala el archivo de configuración PAM /etc/pam.d/login, el programa squid necesita el archivo /etc/pam.d/squid y asi con cada uno de los servicios.

Un ejemplo para aprender

Para comprender mejor el uso de PAM, en este ejemplo veremos como podemos autenticar Squid contra una Base de Datos de MySql. Daremos por sentado que tenemos pam, mysql y squid instalados y configurados correctamente.

1. Por lo general PAM viene por defecto en todos los sistemas FreeBSD.

2. Necesitamos instalar pam_mysql. Un modulo para autenticar contra mysql

# cd /usr/ports/security/pam-mysql
# make install clean

3. También es necesario tener instalado mysql-server, en mi caso tengo la version 5.0, que nos servirá para almacenar el nombre de usuario y contraseña de cada usuario.

# cd /usr/ports/databases/mysql50-server
# make install clean

Tambien podemos instalar phpmyadmin para que nos ayude a gestionar la base de datos de usuarios:

# cd /usr/ports/databases/phpmyadmin
# make install clean

4. Vamos a suponer que tenemos una Base de datos con la siguiente estructura:

Nombre Base de Datos: bd_usuarios
Tabla de usuarios: usuarios
Campo de Usuario: n_usuarios
Campo de Password: p_usuario

Como es lógico el password debe estar encriptado. Para este ejemplo nos sirve cualquier BD siempre que tenga un campo usuario y password.

5. Nos vamos al directorio /etc/pam.d/ y creamos un fichero llamado squid, en caso de que no exista

# cd /etc/pam.d
# touch squid

Lo editamos con el editor favorito y añadimos el siguiente texto:

auth required /usr/local/lib/pam_mysql.so user=user_mysql passwd=clave_mysql host=localhost db=bd_usuarios table=usuarios usercolumn=n_usuario passwdcolumn=p_usuario crypt=1

account required /usr/local/lib/pam_mysql.so user=user_mysql passwd=clave_mysql host=localhost db=bd_usuarios table=usuarios usercolumn=n_usuario passwdcolumn=p_usuario crypt=1

session required /usr/local/lib/pam_mysql.so user=user_mysql passwd=clave_mysql host=localhost db=bd_usuarios table=usuarios usercolumn=n_usuario passwdcolumn=p_usuario crypt=1

Como podemos ver este fichero esta compuesto por 3 lineas, solo explicare una, ya que es valido para las demás.

auth: comprobación de que el usuario es realmente quien dice ser.

required: Es necesario tener éxito. Aunque falle la autenticación se sigue la pila

/usr/local/lib/pam_mysql.so: indica la ruta de la librería pam_mysql. Cambia en otros SO.
user=user_mysql: Indica un usuario valido de mysql con acceso a la Base de Datos de usuarios (bd_usuarios)

passwd=clave_mysql: La clave de acceso a mysql del usuario explicado en el paso anterior.

host=localhost: El servidor que aloja la base de datos.

db=bd_usuario: La base datos de usuarios.

table=usuarios: La tabla que almacena los campos de usuario y password

usercolumn=n_usuario: el nombre del campo que almacena los nombre de los usuarios

passwdcolumn=p_usuario: El nombre del campo que almace el password del usuario.

crypt=1 : El tipo de encriptación de la clave del usuario (0= texto plano) (1=crypt) (2=Crypt mysql) (3=md5)

6. Con esto ya tenemos ha PAM listo para actuar como un mecanismo de autenticación de squid..

7. Ahora debemos configurar squid, solamente modificaremos el siguiente parámetro de squid:

auth_param basic program /usr/local/squid/libexec/pam_auth

8. Ahora podemos reiniciar la maquina e intentar acceder a Internet, si tenemos algún problema podemos verificar en los logs y comprobar. También podemos crear una pequeña página en php para que los usuarios tengan la posibilidad de cambiar el password.

Espero que les sea util….

Cómo realizar copias de seguridad con rsyncd


Una de las tareas más importantes de un administrador, y muchas veces olvidada, es la realización de copias de seguridad. Hay multitud de aplicaciones comerciales y open source que nos permiten realizarlas de una forma más o menos potente o sencilla. En este artículo vamos a explicar mediante un ejemplo práctico como obtener una réplica de la información de un servidor mediante el comando rsync. Para ello antes de nada vamos a dar una breve introducción a este comando y sus características fundamentales, las cuales nos permitirán montar el sistema de réplica en muy pocos pasos y de forma sencilla. Dejamos al interés del usuario el ir más allá y montar sistemas más potentes aprovechando todas las posibilidades existentes.

Introduction a rsync
La utilidad rsync, escrita inicialmente por Andrew Tridgell y Paul Mackerras, viene prácticamente con la totalidad de distribuciones Linux y sistemas Unix. En caso de no ser así se dispone del código fuente en rsync.samba.org. La principal utilidad de rsync es la de sincronizar estructuras de árboles de directorios a través de la red, aunque puede ser utilizado perfectamente también dentro de una máquina de forma local.
Es muy fácil de utilizar y configurar, y al contrario que la utilización de programas de script basados en FTP, ofrece una serie de funcionalidades que lo diferencian claramente. El algoritmo que utiliza envía únicamente la información que ha cambiado dentro de cada archivo, evitando enviar el archivo completo, y permite comprimirla para reducir la utilización de ancho de banda, o enviarlo a través de ssh si se requiere un nivel extra de seguridad en la transmisión.
Hay diferentes maneras de utilizar rsync en función de lo que necesitemos. Permite realizar copias locales, copias desde y hasta un servidor que corra un demonio de rsync, copias desde y hasta un servidor utilizando un shell remoto como transporte, y por último nos permite listar archivos de un servidor remoto. Todas estas características nos permiten realizar multitud de posibilidades como copias locales, copias de servidores remotos, sistemas de mirroring, mantenimiento sincronizado de sistemas de preproducción y producción, etc…

Qué es lo que queremos hacer
En el ejemplo que desarrollaremos esta basado en un servidor remoto que que corre un demonio rsync, que exporta diferentes arboles de directorios llamados modulos. y utilizaremos otra maquina que actuara como backup, donde salvaremos toda la informacion del servidor.

Los backups que se realizan de esta forma son realmente una réplica de lo que hay en el servidor, por lo que si tenemos algún problema bastará con subir los archivos o carpetas directamente.

Estas son las carpetas del servidor de las que queremos hacer copias:

/usr/local/www/ (Directorio raiz de apache)
/var/lib/mysql/ (Directorio raiz de mysql)

Esta es la carpeta donde haremos las copias de seguridad en la maquina que actua como backup.

/var/salvas/

Esta carpeta debemos de crearla con permiso 600 en la maquina backup para que solo sea accesible por el root de ese sistema.Debemos de tener en cuenta que hay espacio suficiente en la particion donde realizaremos las copias.

Configuración del servidor

Debemos instalar rsync en el servidor.

Para preparar la configuración del servidor debemos editar/crear dos archivos:

/usr/local/etc/rsyncd.conf
/usr/local/etc/rsyncd.secrets.

El primero de ellos contiene la configuración de los módulos exportados, mientras que el segundo contiene la información de los usuarios que tienen permisos para realizar conexiones. Estos son los contenidos de cada archivo:

rsyncd.conf

uid = nobody
use chroot = yes
max connections = 1
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid

#Modulo MySql
[mysql]
#Directorio que vamos ha exportar
path = /var/lib/mysql/
#Un comentario
comment = Directorio de las Bases de Datos
#Enjaular para no escalar directorios
use chroot = true
#Una sola conexion permitida
max connections = 1
#Solamente leer
read only = true
#No se permite listar
list = false
#Un usuario con permiso sobre este directorio, puede ser root, pero no es recomendable
uid = mysql
#Usuario de autenticacion contra el servidor rsyncd
auth users = backup
#Donde se encuentra el fichero que contiene el password
secrets file = /usr/local/etc/rsyncd.secrets
strict modes = true
#Solo permitido desde esta ip
hosts allow = 172.16.7.1

#Modulo de WWW
[www]
path = /usr/local/www
comment = Directorio del web
use chroot = true
max connections = 1
read only = true
list = false
uid = www-data
auth users = backup
secrets file = /usr/local/etc/rsyncd.secrets
strict modes = true
hosts allow = 172.16.7.1

El archivo rsyncd.conf se puede observar que se compone de una primera parte en la que se configuran parámetros genéricos del servidor, y una segunda parte donde se muestra la configuración exacta de cada módulo exportado. En la configuración se ha puesto por defecto que se use como usuario local nobody, y que se haga bajo un entorno chroot por seguridad. Esto hace que por defecto cuando nos conectemos a un módulo lo hagamos con ese usuario, y no podamos salir de él a otras zonas del servidor. Dentro de cada módulo se indica la carpeta a la que apunta, se dice que únicamente se pueden leer archivos, mediante read only = true, pero no modificarlos ni crear nuevos. Se dice también que si se socilita un listado de módulos al servidor estos estén ocultos, que se utilice como datos de conexión un usuario de nombre backup cuyo password está en el archivo /usr/local/etc/rsyncd.secrets, y que únicamente se permitan conexiones desde la ip 172.16.7.1

Editamos el fichero /usr/local/etc/rsyncd.secrets y dentro escribimos el usuario y la clave de conexion de la siguiente forma:

backup:clave

backup: es el usuario que hemos declarado en cada modulo, donde dice:

auth users = backup

clave: puede ser cualquiera.

Estos deben ser lor permisos para ambos archivos:

-rw-r–r– 1 root root 472 Dec 31 14:01 rsyncd.conf
-rw——- 1 root root 21 Dec 31 14:00 rsyncd.secrets

Solo falta añadir el servicio para que se inicie con el sistema. Editamos el fichero /etc/rc.conf y añadirmos.

rsyncd_enable=”YES”

Ahora podemos dar un rehash para actualizar el path del sistema.

Configuración del Cliente

Nos vamos ha la maquina que actuara de respaldo de nuestros ficheros e instalamos el rsyncd de la misma forma que en el servidor.

Despues el directorio /var/salvas/ lo debemos de crear con permiso 600, tambien podemos seleccionar otra ubicacion, siempre teniendo en cuenta el espacio que necesitaremos.

Dentro de la carpeta /var/salvas/ creamos el archivo password.rsync, en el que escribimos el password con el que queremos conectarnos al servidor rsync:

clave

Esta clave debe ser identica ha la escrita en el fichero rsyncd.secrets en el servidor, de lo contrario las copias no se realizaran.

Debemos darle permisos de sólo lectura para el usuario que vaya a ejecutar la copia.

# chmod 600 password.rsync

ademas de presionar enter al final de la clave para que funcione correctamente.

Ahora ya podemos probar la conexión al servidor, para ello lo más sencillo es pedirle que nos dé un listado de lo exportable en uno de de los módulos, por ejemplo :

rsync –password-file=/var/salvas/password.rsync rsync://backup@server.dominio.cu/www

Con esta orden el servidor nos contestará con el conjunto de archivos y carpetas disponibles en el módulo www. Si quisiéramos que lo hiciera de manera recursiva, recorriendo las subcarpetas, deberíamos haberle pasado el parámetro -r. Hay que prestar atención a como acaba la información que pedimos al servidor.

Si el servicio no funciona disponemos de la opción de mirar el log del servidor /var/log/rsyncd.log para investigar las posibles causas del problema. Conviene asegurarse de que el servicio está disponible en xinetd reiniciando éste si es necesario, y que los datos de usuario son correctos.

Una vez probado que funciona el servicio podemos preparar un pequeño script que ejecute la petición al servidor para cada módulo disponible. Este script podríamos luego incorporarlo a un cron, o modificarlo lo que hiciera falta para montar copias totales semanales e incrementales diarias.

Creamos el archivo replica.sh:

#!/bin/sh
#Carpeta www
rsync –delete -arzvl –password-file=/var/salvas/password.rsync rsync://backup@server.dominio.cu/www /var/salvas/www

#Carpeta mysql
rsync –delete -arzvl –password-file=/var/salvas/password.rsync rsync://backup@server.vn.pri.jovenclub.cu/mysql /var/salvas/mysql

Dándole permisos de ejecución ya es suficiente para lanzar el script y obtener una copia de toda la información del servidor. Sucesivas ejecuciones del script producirán que se actualice la información existente en base al algoritmo de rsync, consiguiendo una replica actualizada con un consumo de ancho de banda óptimo.

La opcion –delete hace que se borren los fichero que han cambiado, dando la posibilidad de tener una replica bien actualizada.

La opcion del final, /var/salva/www hace que la salva se realice justo en esa ruta.

Para finalizar

# chmod 755 replica.sh
#./replica.sh

Ahora podemos ejecutar el scrip ./replica.sh y veremos como se crea una replica de los directorios que tenemos en el servidor en la carpeta /var/salva/, la proxima ves que se ejecute el script solo se transferiran los ficheros que cambien en el servidor. de esta forma podemos tener una replica de todos los datos que deseemos actualizada