Fin de Semana en el Centro de Servidores (Parte 2: Acceso SSH y Backup de VMWare ESX 3i)

Bueno, siguiendo con la historia que empecé en el pasado post, les voy a hablar ahora de como hacer Backups o copias de seguridad de las maquinas virtuales en VMWare ESX 3i. Como les había dicho en el post anterior, una vez había encontrado que lo que estaba provocando el problema de performance en el servidor era el hecho de que estaba utilizando discos SATA en lugar de SAS, debía reemplazar los discos del equipo, por lo cual necesitaba sacar primero los archivos de las maquinas virtuales para luego copiarlas nuevamente al servidor una vez haya reemplazado los discos. A continuación los pasos:

• Habilitando SSH en VMWare ESX 3i

Para poder hacer backup de las maquinas virtuales en ESX 3i, debemos primero habilitar el acceso SSH, para esto:

1. En la consola del equipo con VMWare ESX (en mi caso el servidor al que le debía reemplazar los discos), presionamos ALT+F1 y luego escribimos "unsupported".
2. Nos presentara una advertencia y un promp donde introduciremos el password de "root" (este es el password que utilizamos con el cliente de VMWare para crear las maquinas virtuales y demas funciones).
3. Una vez hayamos introducido el password de root, editamos el archivo inetd.conf. Para esto ejecutamos "vi /etc/inetd.conf".
4. Dentro de este archivo buscaremos la linea que empieza con #ssh y presionamos la tecla "Insert", luego nos ponemos enfrente del signo de numero ("#") y presionamos backspace para borrarlo.
5. Cuando lo hayamos borrado, presionamos la tecla "ESC" y luego escribimos ":wq" y presionamos "ENTER" para salvar los cambios y salir del editor. En caso de que hayan cometido algún error en la edición y quieran salir sin guardar cambios, en lugar de escribir ":wq" pueden escribir ":q!" para salir del editor sin guardar los cambios.
6. Ejecutamos entonces "/sbin/services.sh restart" y ya con esto hemos habilitado SSH en nuestro VMWare ESX 3i

Para hacer la copia de las maquinas virtuales que residían en el equipo utilice un programa llamado Veeam FastSCP que permite hacer copias atraves de SSH, es rápido, fácil de usar y lo mas interesante es que es gratis!! Pueden descargarlo haciendo clic aqui, (necesitaran registrarse). El proceso de instalación es bastante sencillo, lo que deben tener pendiente es que en la instalación le solicitara las credenciales de un usuario con el privilegio "Log on as a Service", el cual podrían o agregarselo a su propio usuario o crear un nuevo usuario y asignarle ese permiso, de esta forma esta aplicacion correra bajo las credenciales del nuevo usuario. Una vez hayan instalado y ejecutado Veeam FastSCP les abrirá la siguiente ventana:

Para agregar nuestro equipo VMWare y empezar el proceso de copia, hacemos clic en el icono "Add Server" (encerrado en el circulo rojo en el gráfico). En la siguiente ventana escribimos el nombre o dirección IP del equipo donde se encuentran las maquinas virtuales. Como podrán ver nos presenta varias opciones de Servidor: VirtualCenter, ESX o ESXi y también Linux Server, ya que podríamos usar este programa como un "scp" grafico y copiar datos desde cualquier equipo Linux a traves de SSH. En mi caso, y seguro también el de ustedes, elegiremos "ESX or ESXi host" y hacemos clic en Next.



Luego tenemos que escribir el username y password para conectarnos al equipo VMWare, el cual es el mismo que utilizamos para conectarnos al equipo via la consola y que utilizamos para logearnos y habilitar SSH.

Si escribimos bien las credenciales de "root", al hacer clic en Next el programa intentara conectarse al equipo y veremos una ventana como la siguiente, la cual nos muestra un resumen de la información del equipo al cual estamos conectado (donde se encuentran las VM's), diciendo el nombre o IP del equipo, el tipo de servidor y versión, el usuario con el cual estamos conectados y el puerto. Seleccionaremos entonces en esa ventana el cuadro "Connect when I click Finish" y luego hacemos clic en Finish.

Ya que hemos agregado nuestro equipo VMWare a Veeam FasSCP, lo único que tenemos que hacer es movernos hacia los archivos de la maquina virtual que queremos copiar y moverlos hacia nuestra computadora, como cuando transferimos archivos vía FTP o SCP. Cuando la ventana de Veeam FastSCP abre nos mostrará a mano izquierda el servidor VMWare que hemos agregado y los discos que posee nuestra computadora, hacia los cuales podemos arrastrar los archivos de las VM's.

Como se puede ver en el grafico, el programa nos presenta debajo del nombre del servidor las maquinas virtuales presentes. En el caso del server del ejemplo, tiene 2 maquinas virtuales. A mano derecha nos presenta un archivo representando el "Data Storage" (vmDisk1) que fue creado en VMWare. Solamente tenemos que arrastrar las carpetas con el nombre de la maquina virtual que queremos hacia uno de nuestros discos y listo, al finalizar ya tenemos nuestro backup.

Y bueno, volviendo a mi historia, el proceso descrito anteriormente me tomo varias horas porque una de las maquinas virtuales que estaba copiando tenia mas de 1TB y la otra algunos 80GB. Luego de concluir esta fase y tener mis maquinas virtuales seguras en una unidad externa, procedí entonces a apagar el servidor, reemplazar los discos SATA por los nuevos SAS y crear la nueva unidad RAID10 donde copiaría devuelta las maquinas virtuales. En el próximo post les diré entonces como crear estas unidades en los servidores Dell PowerEdge 2950 y el proceso de restauración de las maquinas virtuales. Espero como siempre que esto les haya sido de utilidad.

Fin de Semana en el Centro de Servidores (Parte 1: Desempeño de discos en Linux)

Hola nuevamente!

Lo que les voy a narrar a continuación lo hago con la intensión no solo de desahogarme y de  tener escrito las cosas que hice ese fin de semana en caso que tenga que repetirlo, sino también para evitarles a ustedes algunos de mis errores. Si les contara todo en un solo post seria un cuento demasiado largo, por eso la dividire en base a las tareas principales que realice y que creo podrían ser de utilidad para ustedes, por ejemplo, en este les hablare acerca del monitoreo del desempeño de equipos Linux,  en el proximo como hacer un Backup de las maquinas virtuales de VMWare ESX 3i, y quizás algunas otras cosas que espero les sea de importancia. Es posible que en algún momento necesiten hacer lo que yo estuve haciendo, aunque seguramente ustedes tienen mejor planeacion que yo y mas experiencia. Pero quizás haya algún otro "Tipo de Informática" que necesite esta información, así que aquí les va.

Recientemente, tuve uno de esos "fines de semana con todo pago" en el cuarto de servidores haciendo un upgrade a uno de los servidores, bueno, quizás se podría decir a 3 servidores, porque era un servidor de Virtualizacion en el cual residen 2 maquinas virtuales. El upgrade consistía en reemplazar los 6 discos duros SATA a 7.2K rpm de este servidor por discos SAS 15K rpm debido a un problema de Performance que se venia presentando hacía unos meses atras. Este upgrade también incluía cambiar el nivel RAID que estábamos utilizando (RAID 5) por RAID 10 para obtener todavía mejor desempeño de los nuevos discos. El sistema operativo que utilizamos para la virtualizacion es VMWare ESX 3i, el cual esta instalado en un stick USB interno del servidor, por lo que la unidad RAID se utiliza para almacenamiento, o sea, crear en ella las maquinas virtuales. Para hacer este upgrade debía primero hacer un backup de las maquinas virtuales, luego reemplazar los discos, crear la nueva unidad RAID10 en el servidor, restaurar los backups de las maquinas virtuales a la nueva unidad RAID, arrancarlas y listo! así de simple. y habia que hacerlo en ese fin de semana, de viernes a domingo a mas tardar. Pero como siempre aparece Murphy y sus leyes y con ellas las complicaciones, además claro de los errores de un "Tipo de Informática" inexperto.

Creo que seria bueno empezar desde el principio y contarles como conseguí mi ticket para este fin de semana. Hace poco mas de un año, se decidió comprar un servidor en la compañía donde trabajo. Este servidor se utilizaría básicamente para alojar un Mail Server, pero se decidió también que este mail server corra virtualizado sobre el equipo que se iba a adquirir, asi que debia cotizar y presentar una propuesta de servidor para estos fines. Bueno, me decido por un Dell PowerEdge 2950 III, con 2 procesadores Intel Xeon Quad Core, 16 GB de RAM y 6 discos SATA a 7.2 K rpm, y esto ultimo fue lo que pago el fin de semana que da origen a este post. Para disminuir el costo del servidor y hacer el presupuesto un poco mas atractivo para la Gerencia, me decidí por los discos SATA en lugar de los discos SAS, claro, en ese tiempo no le daba mucha importancia a los discos y a su velocidad, en ese momento me preocupe mas por el espacio de almacenamiento y el presupuesto. El software que se iba a utilizar como servidor de Email es un programa llamado Kerio MailServer, es un software de colaboración, parecido a Microsoft Exchange, que permite a los usuarios tener sus buzones sincronizados con el servidor a través de un programa cliente que trabaja junto a Microsoft Outlook. Este tipo de softwares (Mail servers) requieren de mucha velocidad de acceso a los discos en el servidor, porque realiza muuuchas operaciones I/O (o lectura/escritura) en los discos, y aquí es donde radica la diferencia entre los discos SATA y SAS: los discos SAS ofrecen mucho mas operaciones I/O y a mayor velocidad (15,000 revoluciones por segundo) que los discos SATA (7,000 revoluciones), y también tienen un tiempo de vida mas largo. Los discos SATA pueden utilizarse en servidores, digamos de Backups, o servidores que demanden de mas capacidad de almacenaje que velocidad. Así que ahí esta la primera lección de este post, elegir bien el hardware que se utilizara tomando en cuenta la función que el servidor desempeñara.

• Determinando el Problema

Comando top

Ahora se que mi problema eran los discos que estaba utilizando, pero en esos días no tenia una idea clara del problema, solo sabia que el trabajar con emails se había puesto bastante lento. Cada vez que un usuario intentaba moverse de folder en el Outlook, o simplemente abrir un mensaje, moverlo, borrarlo, etc, tenían que esperar varios minutos para poder realizar la tarea. Así que empecé a revisar que estaba pasando en el servidor, con la herramienta que empecé fue el muy conocido comando "top",este comando nos muestra en tiempo real todos los procesos que que esta ejecutando el servidor y nos muestra, entre muchas otras cosas, el porciento de CPU y memoria que estos están utilizando. A continuación les muestro lo que me devolvió "top" cuando lo ejecute en el servidor:

Este screenshot fue tomado en un momento en que el servidor estaba bastante ocupado (y bastante lento). Como pueden ver el comando top muestra todos los procesos corriendo así también como los recursos que están consumiendo (en cuanto a memoria y procesador), también muestra el PID de los procesos. Como se imaginaran el proceso "mailserver" es el correspondiente al servidor de email que esta corriendo en el servidor y como se ve en el gráfico esta consumiendo el 191% del CPU. Al principio pensé que el problema estaba aquí, en el quizás la capacidad de procesamiento del servidor no era suficiente para el software, pero vi que en otras ocasiones el uso del CPU estaba bajo y de todas formas había lentitud en el servidor. Así que seguí buscando e incluso envié el screenshot al foro de usuarios del Mailserver y alguien me señalo algo en lo que no me había fijado en la salida de este comando; el "Load Average" (parte superior derecha del gráfico). Si se fijan este indicador muestra un "porcentaje de carga" de 68. Comencé a investigar en Internet para ver que significaba este medidor y mas o menos lo que pude entender es que esto muestra el porcentaje de procesos en cola esperando por recursos del sistema, por ejemplo, esperando tiempo del CPU, esperando acceso al sistema de discos, etc. y que lo recomendable es que se encuentre por debajo del 10%. Si se fijan este medidor esta separado en 3, lo cual expresa el valor del momento actual, la carga en los próximos 5 minutos y luego en los próximo 15 minutos. En el gráfico se ven los números 68.37, 61.71 y 55.27. Una lectura alta en ese medidor generalmente indica un cuello de botella, o sea, que algún recurso del sistema esta, digamos, quedando pequeño o que no esta respondiendo a tiempo las solicitudes, por esta razón empecé entonces a monitorear la actividad en el sistema de discos para ver si el "cuello de botella" se encontraba en los discos.

Comando iostat

Fue entonces cuando empecé a utilizar la herramienta "iostat". El comando iostat brinda "las métricas de desempeño de las interfaces de almacenamiento". Este comando, entre otras informaciones, nos muestra el porcentaje de utilizacion del disco o partición (%b), el tiempo que tarda en responder a una solicitud (service time o svc_t),  y la longitud promedio de la cola de solicitudes para el dispositivo monitoreado (queue). Ejecute iostat con las siguientes opciones:

# iostat sda7 -x 3

Esto le indica a iostat que nos muestre información extendida (-x) de la partición sda7 y que muestre la información en intervalos de 3 segundos hasta que cancelemos el comando con CTRL-C. A continuación lo que me mostró iostat al ejecutarlo en el servidor:

Como se puede ver en el gráfico, iostat me mostró que el cuello de botella se encontraba realmente en el sistema de discos: el porciento de utilizacion (%b) no bajaba de un 100%, la cola de procesos siempre se encontraba por encima de los 100 (actualmente difícilmente llega a 10). Claro, esta lectura también podría indicar que uno de los discos del arreglo (RAID5 en ese momento) estaba defectuoso o algún problema en la partición, por lo que primero me asegure de que este no sea el problema (usando fsck). Al comprobar que tanto los discos como la partición estaban funcionando correctamente, solo quedaba la opción de hacer un upgrade al sistema de discos reemplazando los discos actuales, SATA 7.2K RPM, por discos SAS a 15K RPM y gracias a la información provista por iostat ya tenia las pruebas para solicitar el cambio.

Creo que la moraleja es que a la hora de hacer una recomendación, debemos siempre recomendar lo óptimo para el trabajo y no basarnos solamente en lo económico, debemos presentar, claro esta, la justificacion de porque se recomienda tal o cual dispositivo (o servidor en este caso) y las consecuencias de inclinar la balanza solamente por el lado económico, que fue el error que yo cometí. En caso de que la gerencia o las personas que deben tomar la decisión se inclinen por la solución mas barata pero no la mas óptima para el trabajo, bueno, eso ya debe quedar a responsabilidad de ellos, pero por lo menos nosotros cumplimos con recomendar el equipo adecuado, y hay que tratar de hacer la recomendación por escrito como evidencia para cuando explote el problema :D. Claro, a fin de cuentas de todas formas nos tocara a nosotros, los "Tipos de Informática", cargar con las consecuencias de su elección, pero por lo menos podremos decir (aunque sea solo en nuestra mente) "Se lo dije!!"

Bueno, todo esto fue lo que motivo que me pasara el fin de semana aquí en el cuarto de los Servidores haciendo el trabajo de Upgrade de los discos. En los próximos post les contare entonces el proceso de cambio y algunos problemas que se presentaron. Espero como siempre que esto les haya sido de provecho y que no hayan perdido su tiempo leyendome. Hasta el próximo!!

(Fin de Semana en el Centro de Servidores Parte 2)

Un Poco de IPTables (Parte 1)

Hace un par de años, cuando empezaba a dar mis primeros pasos en Linux (en los cuales todavia estoy), escuchaba a algunas personas que hablaban de IPTables como algo dificil y complicado, no muy facil de entender por los simples mortales. Hasta que me toco (al mas simple de los mortales) empezar a estudiar sobre IPTables y note que no existia tal complejidad, claro, afortunadamente antes de empezar a "meter mano" con IPTables ya habia aprendido algo de redes y sobre todo de TCP/IP, entonces me di cuenta de que talves la razon por la que algunas personas encuentran complicado IPTables es porque no saben como trabaja TCP/IP o saben muy poco sobre el protocolo. Asi que creo que antes de empezar a hablar de IPTables debemos entender lo basico TCP/IP y entender como viajan los datos a traves de la red, asi entenderemos el trabajo de IPTables y veremos que el configurar sus reglas no es nada del otro mundo. 

Empecemos entonces con lo basico, una breve y resumida explicacion de TCP/IP. TCP/IP es un conjunto de protocolos que permite la transmision de datos en una red. Este es el protocolo en el cual esta basado Internet. En las redes TCP/IP la informacion es transmitida en "paquetes", o sea, los datos que se van a transmitir por la red son separados en "pedacitos" y transmitidos a traves del cable. TCP/IP esta divido en 4 capas, en cada una de estas capas de agrupan diferentes protocolos (de ahi el hecho de que es un "Conjunto" de protocolos). La primera capa (de arriba hacia abajo) es la capa de aplicacion, esta es la capa donde se generan los datos. Se encuentran los protocolos HTTP, POP3, FTP, DNS, etc. como pueden ver, son los protocolos que a diario utilizamos para navegar, descargar emails, descargar o transmitir archivos, etc. Luego se encuentra la capa de "Transporte". Esta capa se encargar de gestionar el transporte de los datos y asegurarse de que no hayan errores en la transmision, se encarga de crear una especie de "circuito virtual" con el equipo que recibira o transmitira la informacion. En esta capa se encuentran los protocolos TCP y UDP. Luego sigue la capa de "Red". Esta capa se encarga del enrutamiento o encaminamiento de los paquetes y de su direccionamiento. En esta capa  trabaja el procolo IP (me imagino que muchos de ustedes han configurado "direcciones IP"). Por ultimo, se encuentra la capa de "Acceso al medio" o capa "Fisica". Esta es la capa que se encarga de, digamos, "escribir" los datos en el cable. En esta capa se encuentra, por ejemplo, el protocolo Ethernet.

A medida que los paquetes pasan de una capa a la otra, los protocolos que trabajan en las capas le agregan informacion al paquete, la cual sera leida por los protocolos de la misma capa del equipo que recibira el paquete que se esta enviando. A esta informacion se le llama "header" o "cabecera". Cada capa "encapsula" o "reempaqueta" la data que proviene de la capa de aplicacion dentro de otro paquete que contiene la cabecera del protocolo de la capa.

Por ejemplo, TCP, en la capa de transporte, utiliza el concepto de "numero de puerto" para diferenciar las aplicaciones de la capa superior, de esta forma es que podemos recibir informacion desde diferentes sitios de internet hacia diferentes aplicaciones en nuestros equipos, de esta forma TCP sabe a cual aplicacion enviar los datos que recibe desde la red, ya sea al browser de Internet, al cliente de email o a nuestro programa de Chat. Y como TCP necesita esta informacion (entre otras mas), agrega un "numero de puerto de origen", que es el puerto que le asigna a la aplicacion que solicita o transmite la informacion desde nuestra computadora, y un "numero de puerto de destino", que es el puerto de la aplicacion al que va dirigido el paquete en el equipo remoto. De esta forma de establece una especie de circuito entre los 2 puertos (origen y destino). Pero ademas de esto, TCP tambien numera los paquetes para establecer una secuencia y mantener control sobre la transmision, asi que tambien agrega dentro de la cabecera un "numero de secuencia". A continuacion un grafico que muestra la cabecera que agrega TCP al paquete original con todos sus campos.

 Como pueden ver, luego de todos los campos de la cabecera TCP se encuentra la Data del paquete. Luego que el paquete sale de la capa de transporte, se dirige a la capa de red, donde el protocolo IP se encarga tambien de agregar otra cabecera al paquete, pero esta vez con informacion concerniente a IP. Como mencionamos anteriormente una de las funciones de IP es direccionar los paquetes, por esto la informacion que agrega al paquete es informacion que se utilizara para hacer llegar el paquete hacia el equipo destino y tambien informara cual equipo envio el paquete, de modo que el equipo receptor pueda contestar o confirmar su recepcion. Parte de la informacion que se encuentra en la cabecera IP es, por ejemplo, la direccion IP del equipo al que va dirigido el paquete (IP Destino) y la direccion IP del equipo que emite el paquete (IP origen), entre otros. A continuacion la cabecera IP con todos sus campos:

Cuando el paquete sale de esta capa, pasa a la capa fisica. En esta capa tambien se agrega otra cabecera al paquete, pero esta vez lo hace el protocolo Ethernet (para el caso de las redes Ethernet, que son las mas comunes hoy dia). Entre la informacion que le agrega este protocolo al paquete se encuentra el MAC Address de origen y el MAC Address de destino. Como saben el MAC Address es la direccion fisica y unica de cada tarjeta de red. No abundaremos mucho en esta capa, ya que mayormente trabajaremos con IPTables con las capas de Tranporte (TCP y UDP) y la capa de Red (IP).

Ahora que ya sabemos como viajan los datos a traves de la red, podemos empezar a hablar sobre IPTables. IPTables es capaz de leer toda la informacion en la cabecera de los paquetes segun van entrando al equipo, incluso antes de que la misma pila TCP/IP pueda tener acceso a ellos. Entonces, al ser capaz de leer y analizar toda la informacion de cabecera del paquete, como IP de origen y destino, puerto de origen y destino, tipo de protocolo (TCP o UDP), y practicamente todos los otros campos de cabecera, pueden establecerse "reglas" o "filtros" en base a esa informacion. De esa forma, podemos hacer que IPTables bloquee o no permita el acceso de paquetes que en su cabecera TCP indiquen que  se dirigen hacia un "puerto 80" de algun equipo remoto, o que en la cabecera IP indique que se dirige a un IP destino en especifico.

Bueno, creo que por ahora esta bien como introduccion a IPTables, basicamente porque ya me esta ganando el sueño (son las 1 y tanto de la mañana) y porque se haria muy extenso este post.  En el proximo post hablaremos en mas detalle de que es IPTables, su funcionamiento y como configurarlo.

Un Poco de IPTables (Parte 2)

Resetar Password Router Cisco 800

No se si les ha pasado esto, configuran su Router con un muy buen password (mas de 8 caracteres, mayuscalas, minusculas y algun numero o caracter especial), pero mientras estan pensando "oye, que buen password me acabo de inventar" se les olvida escribirlo en algun documento (seguro y encriptado , claro esta). Bueno no se a ustedes pero a mi me paso ayer. Tuve que hacer unos cambios en un router ADSL Cisco 800 y cuando voy muy confiado a buscar mi password en el documento me "acuerdo que se me olvido" anotar el password. Por suerte, hay un procedimiento para resetar los password de los routers cisco, y de esto se tratara el post de hoy. Si, lo se, hay un monton de sitios y blogs que describen este procedimiento pero,ey?! porque no puedo subirlo yo tambien en mi blog??

Como seguramente saben, cuando un router Cisco bootea, busca lee un registro en el router que apunta hacia la configuracion del router, el archivo "startup-config". Este archivo contiene toda las configuraciones que hemos hecho en el router, incluyendo el password o "secret" que hayamos configurado en este. Lo que haremos sera interrumpir esta secuencia de modo que el Router no lea el registro que lo enviara hacia el "startup-config", con esto tambien interrumpiremos la carga del IOS (el sistema operativo de nuestro Router Cisco) pero podremos entrar al router en "modo de recuperacion de emergencia" el cual no contiene todas las opciones del sistema operativo normal, pero contiene algunas herramientas que nos seran de gran utilidad para esta tarea de recuperacion de password.

Lo primero que tenemos que hacer para entrar en este modo es conectarnos al Router por consola (usando por ejemplo, Hyperterminal en Windows XP). Una vez estamos conectados al router, reiniciamos el equipo, cuando este en el proceso de booteo presionamos las teclas "CTRL + Pause/Break" hasta que nos aparezca un promp como el siguiente:

ROMMON >

Esto nos indica que estamos en el modo de recuperacion. Aqui escribiremos el comando "confreg 0x2142" y presionamos "Enter". Lo que le estamos diciendo al router con esto es que al momento de hacer el booteo y la carga del IOS busque la configuracion en el registro 0x2142 en lugar del registro 0x2102 que es el registro del cual router el Cisco 800 obtiene la configuracion, por lo cual la proxima ver que el router inicie subira sin ninguna configuracion, como de fabrica. Una vez hayamos insertado este comando, ejecutamos "reset" para que el router se reinicie, esta vez dejamos que cargue completamente. El router nos preguntara si queremos usar la "Auto-confguracion" a lo que responderemos "NO". Esta vez, el router subira con este promp:

ROUTER >

Aqui ya estamos en nuestro router y el sistema operativo esta cargado, lo primero que haremos sera entrar al "modo privilegiado" y como no esta cargada la configuracion no necesitaremos especificar ningun password. Una vez hemos entrado al modo privilegiado procederemos a cargar el "startup-config" al "running-config" para modificar el password. A continuacion los pasos:

ROUTER > ena
ROUTER# copy startup-config running-config
ROUTER# config t
ROUTER(Config)# line console 0
ROUTER(config-line)# enable password nuevopassword
ROUTER(config-line)# login
ROUTER(config-line)# exit
ROUTER(config)# enable secret nuevopassword

Creo que esta de mas decir que en lugar de "nuevopassword" deben escribir el nuevo password que queieren en el Router. En este caso le cambiamos el password primero para el acceso por consola (line console 0) y luego establecemos el password tambien para acceso al modo privilegiado (enable). Luego de haber completado estas tareas procedemos a reestablecer registro de configuracion original de modo que la proxima vez que el router suba cargue la configuracion (startup-config) que acabamos de modificar, luego salimos del modo de configuracion y pasamos al modo privilegiado donde guaremos los cambios que hemos hecho utilizando el comando "wr". Por ultimo ejecutamos "reload" para reiniciar el router, como se muestra a continuacion:

ROUTER(config)# config-register 0x2102
ROUTER(config)# exit
ROUTER# wr
ROUTER# reload

Cuando nuestro router reinicie, tendra configurado el password que acabamos de configurarle. Bueno hasata aqui el post, espero que esto les haya servido, o que por lo menos lo hayan entendido mejor que en otro de los blogs donde aparece, o bueno, si les aparecio de primero en Google (ojala!) hayan encontrado lo que necesitaban. Hasta el proximo!

Correr Aplicaciones como Servicios en Windows Server 2003

Recientemente en el trabajo se me presento el siguiente caso: Debia instalar en uno de los servidores un programa que usarian un grupo de usuarios, este programa revisaria periodicamente un sitio FTP y si habia algun archivo nuevo lo descargaria a un determinado folder, con el que los usuarios luego trabajarian. El problema es que el sistema con el que trabajarian los usuarios se a traves Terminal Services, y el programa que alimentaria a este sistema a traves de la descarga de archivos FTP no estaba diseñado para trabajar como servicio, lo que significa que cada usuario debia iniciar la aplicacion FTP una vez logeado al servidor.

Bueno, no es tan problematico el hecho de que los usuarios tengan que iniciar ellos mismos esa aplicacion, el problema es que si 15 usuarios se logeaban al servidor e iniciaban la aplicacion, tendria 15 instancias de la misma aplicacion corriendo en el servidor de Terminal Services, y todos haciendo la misma tarea. La solucion: hacerlo correr como un servicio, asi los usuarios no tendrian que lidiar con abrir la aplicacion [mientas menos hagan los usuarios en el servidor mejor] y tendria una sola instancia de la aplicacion corriendo. Para hacer esto, utilizamos los comandos INSTSRV.EXE y SRVANY.EXE, ambos incluidos en el Windows Server 2003 Resource Kit Tools. Instsrv.exe crea o remueve servicios en el sistema y Srvany.exe nos permite correr las aplicaciones como servicio. Para crear entonces nuestro nuevo servicio ejecutamos:

ruta-al-comando-INSTSRV.EXE Mi Servicio ruta-al-comando-SRVANY.EXE

Donde "ruta-al-comando-instsrv.exe" es, como ya se habran imaginado, la ruta donde se encuentra dicho comando. Claro, esto tenemos que especificarlo en caso de que no hayamos incluido ese comando comando en la variable del sistema "PATH". Luego escribimos el nombre que queremos dar a nuestro nuevo servicio ("Mi Servicio"). Y por ultimo la ruta hacia el comando "srvany.exe". Por ejemplo, supongamos que llamaremos a nuestro nuevo servicio "Sftp", el comando seria de esta forma:

C:\Program Files\Windows\windows Resource Kits\Tools\instsrv.exe Sftp C:\Program Files\Windows\windows Resource Kits\Tools\srvany.exe

Con esto hemos creado nuestro servicio, ahora debemos indicar en el registro la ruta hacia la aplicacion. Para esto abrimos en editor del registro (regedit.exe). Y nos movemos hacia la siguiente clave del registro:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\

Aqui buscamos la clave correspondiente al servicio que acabamos de crear, de acuerdo a este ejemplo debe llamarse "Sftp". Una vez estemos sobre esta clave, crearemos una nueva sub-clave haciendo clic derecho encima de "Sftp", moviendonos hacia "New" y luego seleccionando "Key", a la que renombraremos "Parameters". Hacemos clic derecho nuevamente encima de "Parameters", nos movemos encima de "New" y seleccionamos "String Value", a esta estrada la llamaremos "Application". Esta clave del registro sera la que indicara la ruta hacia el ejecutable de la aplicacion que queremos correr como servicio, asi que haremos doble clic enicima de "Application" y escribiremos la ruta hacia nuestro ejecutable, por ejemplo, C:\Program Files\Sftp\Sftp.exe".

El grafico anterior muestra los cambios dentro de la clave del registro correspondiente a nuestro nuevo servicio. Una vez hemos hecho estos cambios, solo nos resta iniciar nuestro servicio, para esto nos vamos a la consola de administracion de servicios (podemos acceder ejecutando services.msc) e iniciandolo como cualquier otro servicio (clic derecho encima del servicio y seleccionando "start").

Ya con esto tenemos nuestra aplicacion corriendo como servicio. Espero que esta informacion les haya sido de utilidad. Hasta el Proximo!

Instalacion y Configuracion Squid con Active Directory

En esta ocasion continuaremos con la preparacion de nuestro Web Proxy Linux con autenticación en Active Directory en el que hemos trabajado en posts anterioes. En este mostraremos la instalación y configuracion de Squid utilizando nuestro recien instalado y configurado Samba/Winbind. En esta entrada haremos una configuracion sencilla de Squid, solo configuraremos lo necesario para que permita el acceso a Internet. No configuraremos filtro de contenido, ni bloqueo de extensiones ni nada por el estilo. Simplemente se mostrara la forma de utilizar Active Directory para autenticar las solicitudes de acceso a Internet basados en la membresia de un determinado grupo del dominio.

Bueno, vamos a entrar en materia inmediatamente y vamos a instalar Squid. La version que instalaremos sera la version 3.1 y al igual como hicimos con Samba compilaremos sus fuentes, ya que tenemos que especificar algunas opciones que normalmente no se encuentran en los paquetes de instalacion.

Instalacion Squid

Bien, para descargar la versión mas reciente al momento de este post pueden hacer clic en este link o pueden acceder directamente al sitio web (http://www.squid-cache.org/). Este archivo se descomprime de la misma manera que lo hicimos con los fuentes de samba (tar -xzf). Entramos a la carpeta con los fuentes de squid y ejecutamos el comando "configure" con las siguientes opciones:

[root@centos-box squid-3.1.1]# ./configure --enable-auth-helpers="winbind,SMB" --enable-external-acl-helpers="unix_group,wbinfo_group" --enable-auth="ntlm,basic" --with-winbind-auth-challenge --with-samba-sources="ruta-a-los-fuentes-de-samba" --sysconfdir=/etc/squid

Como se puede ver en la línea anterior, estamos especificando que utilizaremos a Winbind y Samba ("SMB" va escrito en mayuscula como se muestra). Tambien es necesario indicar en esta linea la ruta a los fuentes de Samba que utilizamos para su instalacion, en la opcion "--with-samba-source". Si este comando finaliza sin presentarnos ningun error podemos seguir adelante con la instalacion ejecutando el camando "make" y luego "make install", justo como lo hicimos en la instalacion anterior de Samba:

[root@centos-box squid-3.1.1]# make
[root@centos-box squid-3.1.1]# make install

Ambos comandos tomaran unos minutos en completar, una vez hayan terminado ya tendremos Squid 3.1 instalado en nuestro equipo, podemos pasar entonces a la parte interesante: la configuracion.

Configuración

Empezaremos la configuracion creando un usuario en el sistema (en el equipo Centos) llamado "squid", el cual utilizaremos para iniciar el Squid Proxy, tambien crearemos un grupo con el mismo nombre e insertaremos al usuario creado en este:

[root@centos-box ~]# useradd squid
[root@centos-box ~]# groupaddad squid
[root@centos-box ~]# usermod squid -g squid
[root@centos-box ~]# usermod -s /bin/false squid
[root@centos-box ~]# passwd -l squid

Los 2 ultimos comandos ejecutados anteriormente lo utilizamos para impedir que alguien pueda logearse localmente al equipo utilizando esta cuenta de usuario. A continuacion crearemos una carpeta que Squid utilizara para almacenar los archivos de CACHE, y agregaremos al usuario squid como dueño de esta carpeta y tambien como dueño de la carpeta en la que se almacenaran los logs.

[root@centos-box ~]# mkdir /var/spool/squid
[root@centos-box ~]# chown squid:squid /var/spool/squid
[root@centos-box ~]# chown squid:squid /usr/local/squid/var/logs

Como utilizaremos el tipo de autenticacion NTLM a traves de Winbind, debemos darle acceso al usuario "squid" a utilizar el "pipe" winbindd_privileged. Para esto, utilizaremos los siguientes comandos:

[root@centos-box ~]# chgrp squid /var/lib/samba/winbindd_privileged

[root@centos-box ~]# chmod 750 /var/lib/samba/winbindd_privileged

Con esto, el usuario "squid" con el que correra nuestro Proxy, tendra acceso al pipe de Winbind. Ahora podemos pasar al archivo de configuracion de Squid, "/etc/squid/squid.conf". Haremos una configuracion sencilla en nuestro Proxy, donde permitiremos el acceso a Internet a los miembros del grupo de Active Directory "Internet_Users" y le denegaremos el acceso a todos los usuarios que no pertenezcan a este. Nuestro proxy escuchara en el puerto 8080 y correra bajo los privilegios del usuario "squid". Indicaremos donde se almacenara la Cache de Squid. Para eso agregaremos las siguientes lineas a nuestro archivo de configuracion:

Con la siguiente linea le indicamos a Squid en que direccion IP y puerto escuchara, en este ejemplo, la IP de nuestro Proxy es 10.0.1.71.

http_port 10.0.1.71:8080

Luego le indicamos el usuario y grupo bajo los cuales correra, aqui utilizamos el usuario y grupo que creamos anteriormente:

cache_effective_user squid
cache_effective_group squid

A continuacion indicamos la ruta donde se encuentra el directorio en el que se ubicara la cache de Squid, el tipo (ufs) y el tamaño:

cache_dir ufs /var/spool/squid/ 900 16 256

Indicaremos tambien servidor DNS que utilizara nuestro proxy (utilizaremos la ip del domain controller)

dns_nameservers 10.0.1.70

En la siguiente linea le indicamos a Squid el tipo de autenticacion que utilizara, en este caso utilizaremos NTLM

auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp

auth_param ntlm children 30

A continuacion definiremos una ACL externa llamada "wb_group" que utilizara el script "wbinfo_group" y le indicamos a Squid la ubicacion de este script. Este se utilizara para determinar la membresia de un usuario a un determinado grupo de Active Directory, en nuestro caso este grupo se llamara "Internet_Users".

external_acl_type wb_group %LOGIN /usr/local/squid/libexec/wbinfo_group.pl

Ahora crearemos una ACL llamada "grupo-internet" utilizando "wb_group" definida anteriormente. En esta  indicaremos el grupo del dominio Active Directory que tendra acceso a Internet. Cuando un usuario solicite a Squid una determinada pagina Web, Squid le solicitara su username del dominio, y junto al grupo que especificaremos en esta ACL, lo enviara como parametro al script "wbinfo_group.pl" para determinar si el usuario pertenece a dicho grupo. Si el usuario pertenece al grupo indicado, wbinfo_group.pl le devolvera a Squid una respuesta positiva y se le permitira al usuario el acceso al web site, de lo contrario se le denegara.

acl grupo-internet external wb_group internet_users

En este caso especificamos el grupo del dominio "Internet_Users", el cual ya he creado previamente en mi Domain Controller y del cual es miembro un usuario de prueba del dominio llamado "winuser". Note que en la definicion de este ACL se escribe el nombre del grupo en letras minusculas completo. Definiremos otra ACL que llamaremos "autenticacion" donde le indicaremos a Squid la autenticacion de los usuarios es requerida, esta la utilizamos para denegar el acceso a todo usuario no autenticado:

acl autorizacion proxy_auth REQUIRED

Ahora crearemos las reglas que permitiran el acceso a Internet a los usuarios en base a las ACL que hemos creado:

http_access allow grupo-internet all
http_access deny !autorizacion

Por ultimo dentro del archivo squid.conf insertaremos la siguiente linea donde especificaremos el nombre de nuestro proxy, en este caso utilizaremos SQUID-PROXY. Este nombre no tiene necesariamente que coincidir con el nombre real del equipo o con el nombre del dominio.

visible_hostname SQUID-PROXY

Luego de insertar esta linea, guardamos y cerramos en archivo. Luego ejecutamos "/usr/local/squid/sbin/squid -z", para que Squid cree los directorios necesarios para almacenar los archivos de cache, o "Swap Directories". Ahora solo nos resta iniciar nuestro Proxy, pero vamos a iniciarlo en modo "debug", de esta forma podemos ver las actividades que va realizando Squid al momento de cargar y podremos detectar rapidamente cualquier fallo en la configuracion, en algun modulo o cualquier error en los permisos de las carpetas en las cuales Squid intente escribir. Para inciarlo de este modo utilizamos el siguiente comando:

[root@centos-box ~]# /usr/local/squid/sbin/squid -NCd1

Si nuestra configuracion de Squid esta correcta, asi como los permisos en las carpetas que este utiliza, en la salida de este comando deberiamos tener algo como esto:

Para salir de este modo presionamos "CTRL+C", y para iniciar Squid en modo normal como servicio utilizamos:

[root@centos-box ~]# /usr/local/squid/sbin/squid

Podemos confirmar que nuestro proxy esta corriendo y esperando solicitudes ejecutando el comando "netstat -nat", el cual deberia devolvernos una ventana como la siguiente:

Como se puede ver en el circulo rojo, Squid esta corriendo y escuchando peticiones en el puerto 8080. Ahora podemos probar nuestro proxy desde un equipo Windows en el dominio y con Internet Explorer configurado para utilizar como proxy nuestro equipo y claro, con un usuario que pertenezca al grupo que configuramos para tener acceso a Internet, que para el caso de este ejemplo es "Internet Users".

Bueno, hasta aqui este post. Recuerden que el proposito de este post no es una hacer una configuracion normal o completa de Squid, solo especifico lo necesario para permitir el acceso a Internet a traves de Active Directory, todavia hay muchisimas cosas mas que se pueden hacer con Squid. Para una referencia de las demas opciones de Squid pueden visitar esta pagina. Espero que esta informacion les haya sido de utilidad.

Consultas de DNSBL con OpenDNS y SpamHaus

Este fin de semana tuve un pequeño problema con SpamHaus, de repente el servidor de email de la compañía donde trabajo dejo de bloquear la mayoría de los Spam que constantemente intentan entrar a los buzones de los usuarios. Esto hizo que entraran un montón de emails basura que provocaron una congestión en la cola de mensajes del servidor, esta congestión a su vez provoco un "delay" o retardo en el envio/recepción de mensajes, y también provoco una congestión en las líneas del departamento... porque todo el mundo llamaba preguntando por sus preciados mensajes.

Como muchos de ustedes sabran, SpamHaus es un "DNSBL" o también llamado "Blacklist" (lista negra) las cuales son consultadas generalmente por servidores de emails para consultar la reputación de las direcciones IP de los servidores SMTP que intenten conectarse a ellos para entregar algún email. Si la IP del equipo aparece en esa base de datos, el servidor rechazara la conexión. Con esto se evita una gran parte de los mensajes SPAM que a diario intentan, y muchas veces logran, entrar a nuestros buzones. En esta pagina pueden encontrar mas información de como trabajan los DNSBL. La mayoría de estos DNSBL ofrecen servicios gratuitos pero solo hasta un numero limitado de consultas, por ejemplo, SpamHaus te permite utilizar su base de datos gratis siempre y cuando no recibas mas de 100,000 conexiones SMTP al día y no excedas 300,000 consultas diarias a su listado, lo que para la mayoría nosotros los mortales es mas que suficiente. Las consultas a estas blacklist no las hace el servidor de correo directamente, quien las realiza es el servidor DNS que utilice nuestro servidor, porque realmente es una consulta DNS que se hace a los servidores de SpamHaus o cualquier otro DNSBL. Esto trabaja de esta forma: supongamos que a nuestro servidor de correo se conecta un servidor intentando enviar un correo a nuestro dominio, digamos que la IP de este servidor externo es 115.184.193.167. Nuestro servidor de correo capturara esta IP y le enviara la siguiente consulta a su servidor DNS:
 

167.193.184.115.xbl.spamhaus.org

Como pueden ver, el orden de la dirección IP se invierte. Esta solicitud le indica al DNS que consulte esta IP en la base de datos "xbl" de SpamHaus, y si esta IP se encuentra en la lista le devolvera al DNS una respuesta, generalmente esta respuesta es "127.0.0.4". Este resultado es entonces devuelto al servidor de correo y este tumba la conexión con el servidor externo. Bueno, volviendo a mi problema, al revisar los logs del servidor de correo encontré el siguiente error: "DNS Failure while trying to find address 167.193.184.115.xbl.spamhaus.org", como ven, el error que retorna es un error de DNS. empecé entonces a probar manualmente las consultas al DNSBL, ejecutando en el mismo servidor de correos (el cual corre en Linux) el siguiente comando:

dig 167.193.184.115.xbl.spamhaus.org
 

Este comando no me retornaba ningún resultado y en la sección "status" me presentaba "REJECTED", o sea que estaban rechazando mis consultas. Luego de varios intentos con diferentes bases de datos de SpamHaus (xbl, sbl-xbl, zen) decidí probar hacer la consulta apuntando a otro servidor DNS que no fuera el que tenia configurado el servidor, así que utilice el mismo comando "dig" pero de esta forma:

dig @ip-dns-interno 167.193.184.114.xbl.spamhaus.org
 

El "@" después del comando dig le indica que haga la consulta al servidor especificado después del arroba y esta vez si devolvió el resultado esperado:

El problema estaba prácticamente resuelto, solo tenia que cambiar el DNS que estaba utilizando el servidor y utilizar el interno, pero porque? nisiquiera habia llegado cerca de la mitad del limite de consultas que permite SpamHaus, porque con el otro DNS las consultas no funcionaban? Bueno, el problema era que estaba utilizando los DNS's de OpenDNS, no habia llegado al limite de consultas en SpamHaus y tampoco en OpenDNS, pero como OpenDNS es un servicio DNS publico y muchas otras personas y servidores lo utilizan, aparentemente estos servidores ya habían sobrepasado el limite de consultas permitidas por SpamHause. Bueno, todo este palabrerio es para decirles que si utilizan o piensan utilizar DNSBL en sus servidores de correo, no utilicen DNS's públicos y utilicen en ellos DNS's internos. así se evitaran una situación como las que les narre y también de seguro ganaran unos cuantos milisegundos en la resolución de nombres. Espero les sea de utilidad esta información.

 

Manejando los Servicios de Windows desde la consola con Sc

Vamos a hacer una pequeña pausa en la instalación de nuestro “Proxy Linux con Autenticación en Active Directory” del que hemos estado hablando en los últimos 3 post, y vamos a ver una utilidad de Windows que nos permite manejar los servicios de este. Y cuando digo "manejar" no me refiero a solo iniciarlos o detenerlos como hacemos con el comando "net start" y "net stop", sino también a listar todos los servicios, modificar su forma de inicio e incluso modificar la acción a tomar en caso de que el servicio presente algún error y hasta la descripción del servicio, en fin, todo lo que podemos hacer con los servicios desde la consola grafica (services.msc), pero desde una ventana de comandos.

SC es un comando utilizado para comunicarnos con el administrador de servicios, lo que nos permite manejar los estados de los servicios rápidamente. También tiene la ventaja de poder integrarlo en scripts. SC contiene también una serie de subcomandos, los cuales se utilizan dependiendo del tipo de acción que se realizaran en el servicio. Para ver el listado ejecutamos “sc /?”, al lado de los subcomandos veremos una descripción de lo que hace el comando.

Ejemplos de SC

Vamos a ver ejemplos de algunas de las funciones que podemos hacer con “Sc”. Vamos a empezar con el uso más simple, iniciar o detener un servicio. Para este ejemplo utilizaremos el servicio “Spooler”, para detenerlo utilizando “Sc”, ejecutamos:

C:\> sc stop spooler

Y si queremos iniciarlo:

C:\> sc stop spooler

También con “Sc” podemos conseguir el listado de los servicios de nuestro sistema y sus estados actuales, para lo utilizamos:

C:\> sc query

Esto nos devolverá el siguiente resultado:

Como pueden ver, en este listado nos aparece el nombre del servicio (Service_Name) y, digamos, el nombre completo del servicio o “Dsiplay_Name”. Para trabajar con SC, usaremos el nombre del servicio o “Service_Name”. Podemos también conseguir el estado de un servicio en particular usando, por ejemplo, “sc query spooler” en caso del servicio Spooler. También podemos exportar esta lista de servicios a un archivo .txt usando: “sq query > lista.txt”. Otro uso de “Sc” es cambiar la forma de inicio del servicio, o sea, si queremos hacer que el servicio inicie al bootear el equipo, hacemos:
 

C:\ sc config spooler start= auto

 

Bueno, creo que con esto ya tienen una idea de lo que pueden hacer con “Sc”, esto es solo lo básico que podemos hacer. Espero que esto les haya sido de utilidad, en el próximo post volveremos al tema de prepara el Web Proxy con Squid, asi que hasta el próximo!

Instalacion de Samba en Centos y Conexion con Active Directory (Parte 2)

Hola nuevamente!

Como recordaran, en el post anterior instalamos Samba y otros paquetes y librerias necesarios para hacer que nuestro Centos participe en un dominio Active Directory, pero no hicimos ninguna configuracion en ninguno de los paquetes porque.... bueno, porque generalmente escribo de noche y me estaba cayendo del sueno. En esta ocasion haremos las configuraciones necesarias y dejaremos nuestro equipo siento parte del dominio Windows. El escenario que utilizaremos sera el siguiente:

Un dominio Active Directory llamado "TEST-LAB.COM"

Un controlador de dominio y DNS Server llamado "DC-SRV01", con la IP 10.0.1.70

Un equipo Linux (Centos) que sera parte del dominio, y utilizara la IP 10.0.1.71

La version de Windows que usare en este ejemplo es Windows Server 2003, pero se puede hacer tambien sin problemas con Windows 2000 Server. Bueno, habiendo dicho esto, podemos empezar con las configuraciones en nuestro equipo. Lo primero que debemos comprobar, y creo que no hace falta mencionarlo, es que nuestro equipo Centos tenga conectividad con el controlador de dominio, esto lo comprabamos haciendo un simple "ping" hacia el servidor. Una vez comprobamos que estamos conectados, indicamos al equipo Centos que utilice al controlador del dominio como DNS Server, para esto modificamos el archivo "/etc/resolv.conf" e incluimos la IP del servidor de dominio (10.0.1.70).

Como ven, tambien incluimos el nombre del dominio local al lado de "search". Tambien modificaremos en archivo "/etc/hosts" e incluiremos el nombre del controlador del dominio y su direccion IP, esto en caso de que la resolucion de nombres por DNS falle en algun momento. Luego de modificado el archivo "hosts" debe verse de esta manera:

Ahora pasaremos a modificar el archivo "/etc/nsswitch.conf", en este agregaremos o editaremos (si ya estan presentes) las siguientes lineas de manera que queden de esta forma:

passwd: files winbind
shadow: files winbind
group: files winbind
protocols: files winbind
rcp: files winbind
netgroup: files winbind
hosts: files winbind dns

Lo siguiente es configurar Kerberos, para esto modificamos el archivo "/etc/krb5.conf". Si no vamos a utilizar otro Servidor Kerberos a parte de nuestro controlador de dominio, podemos elimiar todas las lineas de este archivo y dejar solo las lineas que nos interesan. El archivo luego de modificado debe quedar de esta forma:

Como pueden ver, en la seccion "default_realm" se especifica el nombre del domino al cual queremos pertenecer (en letras mayusculas). Mas abajo se especifica el nombre completo del controlador de dominio (FQDN) en letras minusculas. Ahora pasamos a configurar Samba. Como hicimos la configuracion de Samba compilando los fuentes, es muy posible que la carpeta "/etc/samba/" (que fue la carpeta que especificamos para guardar la configuracion) este vacia. Nos moveremos a esta carpeta y crearemos un archivo llamado "smb.conf", en este incluiremos las siguientes lineas:

[global]

security = ads

password server = 10.0.1.70

encrypt passwords = true

workgroup = test-lab

realm = TEST-LAB.COM

netbios name = Centos-Box

idmap uid = 10000-20000

idmap gid = 10000-20000

winbind enum users = yes

winbind enum groups = yes

winbind use default domain = yes

winbind separator = +

Lo mas importante a tener en cuenta en estas lineas es que en la linea "password server" especificamos la direccion IP de nuestro controlador de dominio, en la linea "realm" insertamos el nombre del dominio tal y como lo especificamos en el archivo de configuracion de Kerberos. Y en la linea "netbios name" especificaremos el nombre con el cual queremos que nuestro equipo sea insertado al domino, este nombre no tiene que coincidir necesariamente con el nombre de nuestro equipo Centos. Ahora, lo que haremos sera iniciar Samba y Winbind, ya que como no los hemos configurado para iniciar durante la carga del sistema, deben estar desactivados. Para activarlos ejecutamos los siguientes comandos:

[localhost@root ~]# smbd start
[localhost@root ~]# nmbd start
[localhost@root ~] winbindd start

Podemos confirmar que Samba ya esta en ejecucion ejecutando el comando "netstat -nat", la salida de este comando debe mostrarnos que los puertos 445 y 139 estan en estado "LISTENNING", tambien lo comprobamos ejecutando "ps -aux", en este listado deben aparecer los servicios smbd y nmbd. Lo que sigue ahora es solicitar un "Ticket" al servidor Kerveros, que es nuestro controlador de dominio, para ejecutamos el comando "kinit" y le proporcionamos credenciales validas en el dominio, o sea, un usuario y un password, en este caso usuaremos el usuario "Administrator". Antes de solicitar el ticket, debemos asegurarnos que ambos equipos, el controlador del dominio y el equipo Centos tengan la misma hora, o por lo menos que la diferencia de hora no sobrepase los 5 minutos. Para sincronizar nuestra hora con la del controlador del dominio podemos utilizar el comando "net time":

[localhost@root ~]# net time set -I 10.0.1.70

Una vez hemos sincronizado los relojes podemos solicitar el ticket, para esto utilizamos el siguiente comando e inctroducimos el password cuando nos lo pida:

[localhost@root ~]# kinit Adminsitrator@TEST-LAB.COM

Si todo sale bien, a este punto ya tenemos nuestro ticket kerberos, podemos confirmar que ya lo tenemos con el comando "klist":

Por ultimo, vamos a ejecutar el comando "net join" para agregar nuestra maquina Centos al dominio, lo haremos utilizando nuevamente las credenciales del usuario "Administrator", al presionar "enter" se nos pedira el password de este usuario.

[localhost@root ~]# net join ads -S dc-srv01.test-lab.com -U administrator
Enter administrator's password:
Using short domain name -- TEST-LAB
Joined 'CENTOS-BOX' to realm 'test-lab.com'

Si recibimos ese mensaje, ya hemos insertado nuestro equipo al dominio Active Directory exitosamente!. Al ser parte del dominio podemos tener acceso a la lista de usuarios y grupos del dominio, podemos utilizar el comando "wb-info" para probar la conexion y para obtener la lista de usuarios y grupos, como se muestra en el siguiente grafico:

Espero que esta informacion les haya sido de provecho, en un proximo post usaremos esta membresia a Active Directory para permitir acceso a Internet a los usuarios miembros de un determinado grupo de usuarios utilizando el Web Proxy Squid.

Instalacion de Samba en Centos y Conexion con Active Directory (Parte 1)

Continuando con la configuracion de nuestro equipo Centos, pasaremos ahora a instalar Samba y Winbind y configurarlo para hacernos miembros de un dominio Windows. La idea es que este equipo pueda reconocer a los usuarios creados en nuestro dominio Windows y poder autenticar usuarios contra este dominio, esto lo usaremos mas adelante para dar acceso a Internet a los usuarios de un determinado grupo del dominio usando el proxy server Squid. Para ser parte del dominio Windows (Active Directory) necesitaremos tambien instalar Kerberos y algunas librerias y headers de LDAP, para esto ejecutaremos el siguiente comando:

root@localhost ~]# yum install krb5-workstation krb5-devel openldap-devel

Ahora pasaremos a la instalación de Samba, para esto sera necesario descargar los fuentes de Samba desde este link, la version estable actual al momento en este post en la 3.4.5 y esta sera la que utilizaremos. Como veran, no instalaremos Samba desde RPM's sino que los compilaremos en nuestro sistema, de esta forma podremos agregar y cambiar algunas opciones al momento de la instalacion. Es importante tambien que guardemos los fuentes de esta instalacion, ya que seran necesarios en caso de querer desinstalar Samba en un futuro (tambien la vamos a necesitar en la instalacion de Squid), asi que haremos una carpeta en nuestro folder "home" y la llamaremos "sources" (o cualquier otro nombre que deseen) y aqui descargaremos los archivos de instalacion, para esto hacemos lo siguiente:

root@localhost ~]# mkdir sources

root@localhost ~]# cd sources

root@localhost sources]# wget www.samba.org/samba/ftp/stable/samba-3.4.5.tar.gz

Una vez hemos descargado los fuentes, utilizaremos el comando "tar" para desempaquetarlos:

root@localhost sources]# tar -xzf samba-3.4.5.tar.gz

Ya teniendo nuestros archivos de instalacion desempaquetados, entramos a la carpeta samba-3.4.5 y dentro de esta, a la carpeta source3 donde encontraremos el ejecutable "configure", al cual ya deben estar acostumbrados si han compilado programas anteriormente. Este ejecutable se encargara de revisar y confirmar que nuestro sistema tenga todo necesario para instalar Samba de acuerdo a los parametros que le especificaremos y si nuestro sistema contiene lo necesario, creara un archivo "Makefile" en base al cual se crearan los binarios de Samba. Ejecutaremos "configure" con los siguientes parametros:

root@localhost source3]# ./configure --prefix=/usr --localstatedir=/var --with-configdir=/etc/samba --with-privatedir=/etc/samba --with-fhs --with-syslog --with-utmp --with-swatdir=/usr/share/swat --with-shared-modules=idmap_rid --with-libsmbclient --with-automount --with-ads --with-acl-support --with-ldap

Si nuestro equipo pasa la prueba y termina el proceso sin nungun error, entonces estamos listos para continuar con la instalacion y crear los binarios, en caso de que nos devuelva algun error, debemos revisar que paquete o libreria hace falta en nuestro sistema o revisar las especificaciones que le pasamos al script "configure". Si todo sale bien, la salida de este script debe verse de esta manera:

Ahora ejecutaremos el comando "make", el cual se encargara de crear y compilar los binarios de Samba en base a la informacion recogida por el script "configure", este proceso puede tomarse varios minutos. Si este proceso no nos devuelve ningun error, ejecutamos entonces el comando "make install", este se encargara de crear los directorios necesarios e instalar los binarios y librerias compiladas anteriormente

root@localhost source3]# make
root@localhost source3]# make install

Una vez terminados estos procesos, tendremos instalado Samba/Winbind en nuestro equipo, ahora necesitamos configurarlo. En el proximo post veremos entonces la configuracion necesaria tanto de Samba como de Kerberos y otros archivos del sistema para lograr la conexion con Active Directory.

Instalacion Basica de CentOS 5.4 sobre la Red

Saludos nuevamente!

Luego de poco mas de un mes que sin acercarme al blog, estoy otra vez por aquí para hablarles de la instalación básica de Centos 5.4, lo cual se que para muchos no es nada nuevo. Lo que haremos será una instalación reducida de Centos, sin instalar ningún entorno grafico e instalando solo lo necesario para que nuestro sistema funcione. Me gusta usar este tipo de instalación porque nos economizamos el instalar paquetes que nunca utilizamos, asi nuestro sistema esta menos cargado y en cuanto a la seguridad, se reduce con esto considerablemente la superficie de ataque en nuestro servidor. Por ejemplo, para que instalar herramientas de ofimática en un servidor que solo será utilizado como proxy server? Prefiero también la instalación sin entorno grafico y manejar el servidor a través de consolas, ya sea localmente o usando SSH, con esto también nos economizamos la instalación de muuchos paquetes relacionados con el entorno grafico, los cuales suelen ser innecesarios para un servidor. Quise hacer esta entrada también porque en lo adelante planeo hablar de algunos programas que utilizo como Samba, Squid, IPtables, OpenNMS y pensé que seria bueno empezar desde el inicio, la instalación de Linux, en esta caso, Centos 5. Bueno, vamos entonces a entrar en materia y proceder con los pasos para instalar Centos.

Instalacion

Primero, como vamos a hacer una instalacion "Base" no necesitamos descargar el .ISO del DVD de instalacion, solo tenemos que bajar el .iso de la "netinstall" que es mucho mas pequeno, solo de algunos 9 MB. Lo puedes descargar haciendo clic aqui, o si quieres puedes elegir otros mirrors aqui. Una vez hayamos descargardo y quemado este .iso en un disco, lo utilizamos para bootear el equipo donde lo instalaremos. Una vez haya cargado nos aparecera el menu de instalacion, aqui presionamos "enter" para iniciar el proceso de instalacion:

Luego de presionar "enter" nos aparecera la ventana de seleccion de idioma, aqui se selecciona el idioma con el quieres continuar la instalacion y el idioma del teclado. El siguiente paso luego de seleccionar estos, es indicarle al programa de instalacion donde estan los fuentes del sistema operativo, en este caso elegiremos la opcion "FTP":

Luego de esta ventana, nos pedira la configuracion IP del equipo, si sera suplida por un servidor DHCP o si se la insertaremos manualmente. Recuerden que el programa de instalacion descargara los paquetes necesarios para la instalacion desde Internet, por lo que necesitamos tener acceso a Internet. En el caso de este ejemplo, seleccionaremos la opcion DHCP, y como no estoy usando IPv6 (y me imagino que ustedes tampoco) desactivare la pestana "Enable IPv6 Support".

En el siguiente paso especificaremos cual sera el servidor desde donde halaremos los archivos de instalacion, puedes encontrar la lista en este link. Para este caso insertaremos la siguiente direccion en la seccion "FTP site name" : ftp://ftp.ussg.iu.edu/ y en la seccion "CentOS directory" escribimos: linux/centos/5.4/os/i386/. Generalmente los mirrors de la lista tambien tienen los ISO's de instalacion completa, asi que los archivos para la instalacion "online" generalmente se encuentran en una subcarpeta llamada "os", como se puede ver en la ruta que especificamos en la seccion "CentOS Directory".

Nos movemos al boton "OK" y presionamos enter. Luego veremos un mensaje en pantalla que nos informara que esta descargando algunos archivos ("Retrieving images/minstg2.ing...). Si todo sale bien debe aparecernos la siguiente ventana, en caso contrario habria que revisar la conexion a Internet, la direccion y el directorio digitado o cambiar el mirror.

A partir de esta ventana, el proceso de instalacion es el mismo que en cualquier otra instalacion de Linux, primero nos pedira las particiones que queremos utilizar, si queremos hacer solo una particion o si que queremos definir como particionar nuestro disco. Tambien nos pedira especificar la zona horaria en que nos encontramos y luego especificar el password para el usuario "root". Luego el programa de instalacion nos llevara a la seleccion de seleccion de paquetes que seran instalados, como queremos una instalacion lo mas basica posible, de-seleccionaremos la opcion "Desktop-Gnome" y dejaremos las demas sin seleccionar. Seleccionaremos en esta ventana la opcion "Customize Software selection", esto nos permitira quitar de la lista de instalacion otros paquetes innecesarios.

Nos movemos nuevamente al boton "OK" y se nos presentara una segunda ventana con los paquetes de forma mas detallada, aqui solo seleccionaremos "Base", colocandonos encima y presionando la barra espaciadora. Podemos todavia reducir mas nuestra instalacion presionando "F2" encima de "Base", esto nos presentara el detalle de los paquetes de este grupo. Si se fijan, hay paquetes que podemos eliminar, como aspell y aspell-en (diccionarios), finger, wireless-tools, entre otros. Una vez seleccionados los paquetes que vamos a instalar seleccionarmos "OK", el programa nos notificara que guardara un log de la instalacion, procedera a formatear el disco e inciara la descarga de los paquetes.

En este punto lo que resta es esperar a que los paquetes se descarguen, el timpo que tardara dependera se nuestra conexion a Internet. Bueno, espero que esto les haya sido provechoso, en los proximos post hablare sobre la instalacion de Samba y como configurarlo para formar parte de un dominio Windows.