Mostrando entradas con la etiqueta CentOS. Mostrar todas las entradas
Mostrando entradas con la etiqueta CentOS. Mostrar todas las entradas

Cómo configurar un servidor DHCP en una LAN.

Etiquetas: , , , | 0 comentarios

Introducción.

Acerca del protocolo DHCP.

DHCP (acrónimo de Dynamic Host Configuration Protocol que se traduce Protocolo de configuración dinámica de servidores) es un protocolo que permite a dispositivos individuales en una red de direcciones IP obtener su propia información de configuración de red (dirección IP; máscara de sub-red, puerta de enlace, etc.) a partir de un servidor DHCP. Su propósito principal es hacer más fáciles de administrar las redes grandes. DHCP existe desde 1993 como protocolo estándar y se describe a detalle en el RFC 2131.

Sin la ayuda de un servidor DHCP, tendrían que configurarse de forma manual cada dirección IP de cada anfitrión que pertenezca a una Red de Área Local. Si un anfitrión se traslada hacia otra ubicación donde existe otra Red de Área Local, se tendrá que configurar otra dirección IP diferente para poder unirse a esta nueva Red de Área Local. Un servidor DHCP entonces supervisa y distribuye las direcciones IP de una Red de Área Local asignando una dirección IP a cada anfitrión que se una a la Red de Área Local. Cuando, por mencionar un ejemplo, una computadora portátil se configura para utilizar DHCP, a ésta le será asignada una dirección IP y otros parámetros de red necesarios para unirse a cada Red de Área Local donde se localice.

Existen tres métodos de asignación en el protocolo DHCP:

• Asignación manual: La asignación utiliza una tabla con direcciones MAC (acrónimo de Media Access Control Address, que se traduce como dirección de Control de Acceso al Medio). Sólo los anfitriones con una dirección MAC definida en dicha tabla recibirá el IP asignada en la misma tabla. Ésto se hace a través de los parámetros hardware ethernet y fixed-address.
• Asignación automática: Una dirección de IP disponible dentro de un rango determinado se asigna permanentemente al anfitrión que la requiera.
• Asignación dinámica: Se determina arbitrariamente un rango de direcciones IP y cada anfitrión conectado a la red está configurada para solicitar su dirección IP al servidor cuando se inicia el dispositivo de red, utilizando un intervalo de tiempo controlable (parámetros default-lease-time y max-lease-time) de modo que las direcciones IP no son permanentes y se reutilizan de forma dinámica.

Acerca de dhcp por Internet Software Consortium, Inc.

Fundado en 1994, Internet Software Consortium, Inc., distribuye un conjunto de herramientas para el protocolo DHCP, las cuales consisten en:

• Servidor DHCP
• Cliente DHCP
• Agente de retransmisión.

Dichas herramientas utilizan un API (Application Programming Interface o Interfaz de Programación de Aplicaciones) modular diseñado para ser lo suficientemente general para ser utilizado con facilidad en los sistemas operativos que cumplen el estándar POSIX (Portable Operating System Interface for UNIX o interfaz portable de sistema operativo para Unix) y no-POSIX, como Windows.

URL: http://isc.org/products/DHCP/

Equipamiento lógico necesario.

Instalación a través de yum.

Si utiliza CentOS 5, Red Hat™ Enterprise Linux 5 o White Box Enterprise Linux 5, solo se necesita realizar lo siguiente para instalar o actualizar el equipamiento lógico necesario:

yum -y install dhcp

Instalación a través de up2date.

Si se utiliza Red Hat™ Enterprise Linux 4, solo bastará realizar lo siguiente para instalar o actualizar el equipamiento lógico necesario:

up2date -i dhcp

Procedimientos.

SELinux y el servicio dhcpd.

A fin de que SELinux permita al servicio dhcpd funcionar normalmente y sin protección alguna, utilice el siguiente mandato.

setsebool -P dhcpd_disable_trans 1

A fin de que SELinux permita al sistema funcionar normalmente y sin protección alguna como cliente DHCP, utilice el siguiente mandato.

setsebool -P dhcpc_disable_trans 1

Fichero de configuración /etc/dhcpd.conf.

Considerando como ejemplo que se tiene una red local con las siguientes características:

• Número de red 192.168.0.0
• Máscara de sub-red: 255.255.255.0
• Puerta de enlace: 192.168.0.1
• Servidor de nombres: 192.168.0.1, 148.240.241.42 y 148.240.241.10
• Servidor Wins: 192.168.0.1
• Servidores de tiempo (NTP): 200.23.51.205, 132.248.81.29 y 148.234.7.30.
• Rango de direcciones IP a asignar de modo dinámico: 192.168.0.11-192.168.0.199
• Dos direcciones IP se asignarán como fijas (192.168.1.252, 192.168.0.253 y 192.168.0.254) para las tarjetas de red con direcciones MAC (Media Access Control o Control de Acceso de Medios) 00:24:2B:65:54:84, 00:50:BF:27:1C:1C y 00:01:03:DC:67:23.

NOTA: Es indispensable conocer y entender perfectamente todo lo anterior para poder continuar con este documento.

Puede utilizar el siguiente contenido de ejemplo para adaptar y crear desde cero un nuevo fichero /etc/dhcpd.conf que se ajuste a una red y conjunto de sistemas en particular.

server-identifier proxy.redlocal.net;
ddns-update-style interim;
ignore client-updates;
authoritative;
option ip-forwarding off;
default-lease-time 21600;
max-lease-time 43200;

shared-network miredlocal {
 subnet 192.168.0.0 netmask 255.255.255.0 {
 option routers 192.168.0.1;
 option subnet-mask 255.255.255.0;
 option broadcast-address 192.168.0.255;
 option domain-name "redlocal.net";
 option domain-name-servers 192.168.0.1, 148.240.241.42, 148.240.241.10;
 option netbios-name-servers 192.168.0.1;
 option ntp-servers 200.23.51.205, 132.248.81.29, 148.234.7.30;
 range 192.168.0.11 192.168.0.199;
 }
 host impresora-laser {
  option host-name "epl5900.redocal.net";
  hardware ethernet 00:24:2B:65:54:84;
  fixed-address 192.168.1.252;
  }
 host servidor {
  option host-name "servidor.redlocal.net";
  hardware ethernet 00:50:BF:27:1C:1C;
  fixed-address 192.168.0.253;
  }
 host proxy {
  option host-name "proxy.redlocal.net";
  hardware ethernet 00:01:03:DC:67:23;
  fixed-address 192.168.0.254;
  }
}

Fichero de configuración /etc/sysconfig/dhcpd.

Una buena medida de seguridad es hacer que el servicio dhcpd solo funcione a través de la interfaz de red utilizada por la LAN, esto en el caso de tener múltiples dispositivos de red. Edite el fichero /etc/sysconfig/dhcpd y agregue como argumento del parámetro DHCPDARGS el valor eth0, eth1, eth2, etc., o lo que corresponda. Ejemplo, considerando que eth0 es la interfaz correspondiente a la LAN:

# Command line options here
DHCPDARGS=eth0

Iniciar, detener y reiniciar el servicio dhcpd.

Para iniciar por primera vez el servicio dhcpd, utilice:

/sbin/service dhcpd start

Para hacer que los cambios hechos a la configuración del servicio dhcpd surtan efecto, utilice:

/sbin/service dhcpd restart

Para detener el servicio dhcpd, utilice:

/sbin/service dhcpd stop

Agregar el servicio dhcpd al arranque del sistema.

Para hacer que el servicio de dhcpd esté activo con el siguiente inicio del sistema, en todos los niveles de corrida (2, 3, 4, y 5), se utiliza lo siguiente:

/sbin/chkconfig dhcpd on

Comprobaciones desde cliente DHCP.

Hecho lo anterior solo falta con configurar como interfaces DHCP las estaciones de trabajo que sean necesarias sin importar que sistema operativo utilicen.

Después de configurado e iniciado el servicio, desde una terminal como root en otro sistema que será utilizado como cliente, considerando que se tiene una interfaz de red denominada eth0, utilice los siguientes mandatos para desactivar la interfaz eth0 y asignar una nueva dirección IP a través del servidor dhcp.

/sbin/ifdown eth0
/sbin/dhclient eth0

Lo anterior deberá devolver el mensaje «Determinando la información IP para eth0...» y el símbolo de sistema. Para corroborar, utilice el mandato ifconfig para visualizar los dispositivos de red activos en el sistema.

La configuración del dispositivo de red, considerando como ejemplo la interfaz eth0 con dirección MAC 00:01:03:DC:67:23, solicitando los datos para los servidores DNS, correspondiente al fichero /etc/sysconfig/network-scripts/ifcfg-eth0, sería con el siguiente contenido: 

DEVICE=eth0
ONBOOT=yes
USERCTL=yes
BOOTPROTO=dhcp
PEERDNS=yes
HWADDR=00:01:03:DC:67:23
TYPE=Ethernet

Modificaciones necesarias en el muro cortafuegos.

Si se utiliza un cortafuegos con políticas estrictas, como por ejemplo Shorewall, es necesario abrir los puerto 67 y 68 por UDP (BOOTPS y BOOTPC, respectivamente).

Las reglas para el fichero /etc/shorewall/rules de Shorewall en un sistema con una zona (net), correspondería a lo siguiente:

#ACTION SOURCE DEST PROTO  DEST  SOURCE
#    PORT  PORT(S)1
ACCEPT net fw udp 67,68
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

Las reglas para el fichero /etc/shorewall/rules de Shorewall en un sistema con dos zonas (net y loc), donde solo se va a permitir el acceso al servicio dhcpd desde la red local, correspondería a lo siguiente:

#ACTION SOURCE DEST PROTO  DEST  SOURCE
#    PORT  PORT(S)1
ACCEPT loc fw udp 67,68
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

Autor: Joel Barrios Dueñas
Correo electrónico: darkshram en gmail punto com
Sitio de Red: http://www.alcancelibre.org/
Jabber ID: darkshram@jabber.org

Creative Commons Reconocimiento-NoComercial-CompartirIgual 2.1

Publicado por anonymous en 6:17

Actualización, instalación y desinstalación de software en Linux, Distribuciones Derivadas de Red Hat, paquetes RPM

Etiquetas: , , , , , | 0 comentarios


Introducción.

Una vez que ya ha experimentado con algunos de los mandatos básicos, se encontrará ahora con una pregunta: ¿Cómo actualizo, instalo o desinstalo software? Existen varios métodos que dependerán del formato utilizado para empaquetar los programas. Este documento le proporcionará la descripción de los posibles métodos y algunos ejemplos. Por favor siga el procedimiento al pie de la letra.


La parte teórica.

Antes de continuar, es indispensable se conozca primero el uso y el porque de cada método existente para el manejo del software. De esto se dependerá en adelante para mantener un saludable estado de cualquier sistema GNU/Linux®. Indistintamente del método, todos se deberá de realizar desde la cuenta de root, así que proceda con cuidado.


Manejo de paquetes a partir de archivos RPM®

El formato RPM® es el más utilizado en la actualidad. Tiene como ventaja principal el encargarse de verificar las posibles dependencias o requisitos para la instalación o actualización de un paquete en particular, así como también el verificar si el paquete que se procederá a desinstalar es requerido por otros paquetes presentes en el sistema.

Analizaremos entonces el uso del mandato rpm. Existen dos aplicaciones en el entorno gráfico que utilizan rpm en el trasfondo y que son de muy fácil utilización, son gnorpm y kpackage. Sin embargo es importante que el usuario novicio se familiarice con este mandato para poder entender el funcionamiento de las mencionadas aplicaciones en el entorno gráfico.

Sintaxis
rpm -[opciones] paquete.rpm
Nos limitaremos a abordar solo las opciones más comúnes que un nuevo usuario de Linux® podría necesitar. Si desea ver una descripción completa de las posibles opciones del mandato rpm, consulte el manual escribiendo man rpm en cualquier terminal o consola.

Instalación binarios contenidos en paquetes con formato RPM®.

Los paquetes de este tipo son programas previamente compilados, almacenados y listos para ser instalados en el sistema. Estos paquetes pueden tener las extensiones .i386.rpm para PC compatible con al menos un microprocesador 80386, es decir, cualquier PC de arquitectura Intel® o compatible, .i486.rpm para PC compatible un microprocesador 80486, .i586.rpm para PC compatible con microprocesador 80586, .i686.rpm para PC compatible con microprocesador 80686, .ppc.rpm para Machintosh® PowerPC o .noarch.rpm que puede utilizarse en cualquier arquitectura.

En la práctica, no se preocupe por encontrar paquetes i686 para su PC con microprocesador Intel Pentium III, puede instalar con total seguridad los paquetes para i386. Los paquetes noarch generalmente contiene archivos de texto -guiones para diversas funciones, archivos de configuración o documentación-, imágenes, sonidos, etc., es decir, archivos que trabajan indistintamente en uno u otro sistema.

La sintaxis que se sugiere utilizar en la mayoría de los casos para instalar o actualizar paquetería es la siguiente:

rpm -Uvh paquete.i386.rpm

El utilizar la opción U, que significa Update, a fin de conseguir un proceso limpio, hace que primero se consulte la base de datos de la paquetería instalada, procediendo a desinstalar a continuación la versión anterior e instalando la nueva. Aunque también puede utilizarse la opción i, que significa install, esta no continuará el proceso si existiese en el sistema una versión anterior de dicho paquete.

Desinstalación binarios contenidos en paquetes con formato RPM®.

rpm -e paquete

No requiere especificar el número de versión ni la extensión ya que consulta directamente la base de datos de la paquetería instalada en le sistema y procederá a desinstalar el paquete que lleve dicho nombre.

Instalación a partir de código fuente contenido en paquetes con formato RPM®.

Este procedimiento se aplica a los paquetes denominados SRPM, sobre los cuales seguramente ha leído en los foros y grupos d discusión, y requiere que se encuentren instalados en el sistema los paquetes de desarrollo -los paquetes contenidos en el CDROM de instalación que llevan "-devel-" en el nombre-, ya que el procedimiento implica que se realizará la compilación de programas.

La ventaja que tiene la construcción e instalación paquetería a partir de archivos SRPM es que los paquetes resultantes quedan compilados de forma especial para el sistema Linux® que tengamos instalado. Es de particular ayuda cuando se actualiza, por citar un ejemplo, de LinuxPPP® 5.x a LinuxPPP® 6.x y el usuario se topa con que alguna de sus aplicaciones favoritas simplemente ya no funcionan. Esto se debe a que la diferencia entre las versiones de las bibliotecas compartidas entre una y otra versión de LinuxPPP puede ser demasiada. Las distribuciones basadas sobre Red Hat™ Linux 5.x utilizan, entre otras cosas, libc5, en tanto que las versiones basadas sobre Red Hat™ 6.x hacen uso de Glibc-2.1.x y las versiones basadas sobre Red Hat™ 7.x hacen uso de Glibc-2.2.x.

Estos paquetes SRPM tienen la extensión .src.rpm y se procede sobre estos del siguiente modo:

rpmbuild --rebuild --clean paquete.src.rpm

Esta última línea de mandato coloca un paquete comprimido, normalmente un archivo con extensión .tar.gz o tar.bz2, en /usr/src/redhat/SOURCES y un archivo, conocido como spec, con las especificaciones del paquete en /usr/src/redhat/SPECS. A continuación se descomprime el archivo .tar.gz o tar.bz2 y se inicia la compilación y construcción del paquete RPM® con las especificaciones del spec.

Si al terminar el proceso en la última línea se obtiene + exit 0, solo restará instalar o actualizar con el paquete RPM® que ahora encontraremos, dependiendo de la arquitectura para la que se compiló, en alguno de los subdirectorios de /usr/src/redhat/RPMS.

rpm -Uvh /usr/src/redhat/RPMS/i386/paquete.i386.rpm

Confirmación de la existencia de paquetería en particular en el sistema.

En ocasiones es posible que se encuentre en una situación como esta: usted encuentra en algún sitio de Internet un paquete RPM® del cual se hablan maravillas en la descripción, pero desconoce si ya lo tendrá instalado, o si ya tiene una versión más reciente; podría averiguarlo descargando dicho paquete, que quizá tenga varios Mega-bytes en tamaño, utilizando una lenta conexión de modem y probando con la línea de mandato rpm -Uvh. Si resultó un paquete más reciente que el que usted tenía, habrán valido la pena los 10-15 minutos invertidos en descargar dicho paquete, pero si ya lo tenía instalado o bien se trataba de una versión anterior, usted desearía haber sabido que podía utilizar la siguiente línea de mandato:

rpm -q nombre_del_paquete_sin_número_de_versión

La correspondiente salida de esto nos dirá si el paquete se encuentra o no instalado y el número de versión.

Si nos interesa examinar la información sobre algún paquete instalado en el sistema, utilizamos la siguiente línea de mandato:

rpm -qi nombre_del_paquete_sin_número_de_versión

Lo anterior devuelve los detalles informativos respecto al paquete instalado.

Si queremos examinar dicha información pero en un paquete no instalado en el sistema, solo hace falta añadir p, que implica que nos referiremos a un paquete, en las opciones del mandato del modo siguiente:

rpm -qpi --clean cualquier_paquete_que_haya_descargado.i386.rpm

Verificación de firmas de paquetes RPM®.

Por cuestiones de seguridad, si usted descarga un paquete RPM® desde un sitio Web o servidor FTP distinto al oficial de la distribución o conjunto de paquetes que utilice, lo más saludable será verificar dicho paquete. JAMÁS descargue e instale paquetes de binarios desde sitios Web dedicados a actividades ilegales o de dudosa reputación.

Por si acaso, utilice la siguiente línea de mandato para verificar las firmas incluidas en paquetes antes de proceder a instalarlos:

rpm -Kv paquete.i386.rpm

Esto debe darle la siguiente salida, donde las x corresponden a la firma PGP de la persona que construyó el paquete:

paquete.i386.rpm: MD5 sum OK: xxxxxxxxxxxxxxxxxxxxx

Compare la firma PGP con la del empaquetador, misma que debe corresponder con la que este proporcione en el sitio Web desde donde descargue dicho paquete.


Instalación de paquetes a partir de paquetes .tar.gz o .tar.bz2.

Este el el método universal para todas las distribuciones de GNU/Linux® ya que funciona tanto en distribuciones basadas sobre Red Hat, como Debian, Stampede o Slackware. Debido a que no se guarda un registro sobre lo que se tiene instalado y lo que no, conviene, en le caso de distribuciones basadas sobre Red Hat™ Linux, dejar las carpetas resultantes con el código fuente en /usr/src/redhat/BUILD para tener una referencia y evitar romper las posibles dependencias entre los distintos paquetes.

La mayoría de estos paquetes, denominados tarballs, vienen con extensión .tar.gz o tar.bz2. Lo primero será copiarlos en la carpeta /usr/src/redhat/SOURCES y lo siguiente consiste en descomprimir estos con la siguiente línea de mandato:

tar -zxvf /usr/src/redhat/SOURCES/paquete.tar.gz /usr/src/redhat/BUILD/

Después acceda al interior de la carpeta resultante:

cd /usr/src/redhat/BUILD/paquete

Es necesario que lea la documentación que acompaña a dicho paquete y seguir las instrucciones proporcionadas por el autor. Por lo general son necesarios al menos tres pasos:

./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var make make install make clean

Algunos paquetes de binarios propietarios, como OpenOffice.org, incluyen documentación y un instructivo que detalla la instalación. OpenOffice.org requiere se ejecute el binario setup, con la opción /net si va ser utilizado por varios usuarios, contenido en la sub-carpeta bin.

cd /usr/src/redhat/BUILD/openoffice ./setup /net

En la mayoría de los casos, como ocurre con los programas con licencia GPL que se distribuyen como códigos fuentes, necesitará ejecutar algunos mandatos como se muestra a continuación:


Compilación desde código fuente.
./configure
Este prepara el Makefile y configura las opciones de compilación, mismas que en algunos casos pueden resultar demasiado complejas para un usuario novicio. Además de verifica si el sistema posee las bibliotecas de desarrollo necesarias para la compilación.
make
Este es el que realiza la compilación del código fuente. El procesos puede durar varios minutos.

make install
Este se encarga de realizar la instalación del los binarios y módulos compilados en los lugares correctos.
make clean
Opcionalmente podemos utilizar este mandato para limpiar los remanentes que se originaron por la compilación a fin de recuperar espacio en el disco duro.

Si por alguna razón necesita desinstalar el programa resultante, puede utilizar make uninstall.


En el mejor de los casos, si el tarball contiene un archivo spec, puede construirse un paquete RPM® de modo muy similar a la compilación e instalación desde paquetes SRPMS.

Solo requiere ejecutar la siguiente línea de mandato:

rpm -tb --clean paquete.tar.gz

Y, si obtuvimos en la última línea del proceso un + exit 0, finalmente podremos disponer de el paquete resultante:

rpm -Uvh /usr/src/redhat/RPMS/i386/paquete.i386.rpm

Ejercicios.

Antes de empezar, es necesario, si no lo ha hecho, instalar los paquetes de bibliotecas de desarrollo incluidas en el CDROM de instalación de la distribución que posea. Puede utilizar rpm -Uvh *-devel-*.

Instalación y desinstalación de un paquete RPM®



  1. Instale firestarter-x.x.x-x.i586.rpm con la siguiente línea mandato:

    rpm -Uvh firestarter-*.i586.rpm

  2. Ejecute el programa que acaba de instalar ejecutando firestarter

  3. Cierre el programa ejecutemos el mandato para verificar que versión tenemos instalada: y observe la salida

    rpm -q firestarter

  4. Proceda ahora a desinstalar el programa con la siguiente línea de mandato:

    rpm -e firestarter


Compilación e instalación desde un SRPM.



  1. Ejecute el siguiente mandato:

    rpmbuild --rebuild --clean firestarter-*.src.rpm

  2. Espere unos minutos, y si recibe en la última línea una salida +exit 0, cambie al directorio conde quedó el paquete RPM® de binarios:

    cd /usr/src/redhat/RPMS/i386 ; ls

  3. Instale el RPM® resultante con la siguiente línea de mandato:

    rpm -Uvh firestarter-*.i386.rpm

  4. Ejecute el programa que acaba de instalar ejecutando firestarter

  5. Cierre el programa ejecutemos el mandato para verificar que versión tenemos instalada: y observe la salida

    rpm -q firestarter

  6. Proceda ahora a desinstalar el programa con la siguiente línea de mandato:

    rpm -e firestarter


Compilación e instalación desde código fuente -tarball-.



  1. Abra una terminal o consola.

  2. Instale este paquete, que contiene un código fuente, con la siguiente línea de mandato.

    rpm -Uvh firestarter-*.src.rpm

  3. Revise el contenido de los siguientes directorios, ya que en estos encontrará un par de archivos nuevos:

    • cd /usr/src/redhat/SPECS ; ls

      En este encontrará un archivo llamado firestarter.spec

    • cd /usr/src/redhat/SOURCES ; ls

      En este otro encontrará firestarter-0.8.2.tar.gz

  4. Descomprima firestarter-0.8.2.tar.gz utilizando la siguiente línea de mandato:

    tar -zxvf /usr/src/redhat/SOURCES/firestarter-0.8.2.tar.gz /usr/src/redhat/BUILD

    Como resultado, ahora tendremos una carpeta firestarter-0.8.2.

  5. Cambie al directorio /usr/src/redhat/BUILD/firestarter-0.8.2: 
    cd /usr/src/redhat/BUILD/firestarter-0.8.2

  6. Ejecute el siguiente mandato y observe los mensajes que aparecerán en pantalla:

    ./configure

  7. Ejecute el siguiente mandato para iniciar la compilación, espere algunos minutos para que completen todos los procesos y observe los mensajes que aparecerán en pantalla, sobretodo asegurándose que la última línea se lea + exit 0:

    make

  8. Ejecute el siguiente mandato a fin de instalar el programa que acaba de compilar:

    make install

  9. Ejecute el siguiente mandato para comprobar que ha concluído exitosamente la primera parte del ejercicio,, invocando a firestarter, un programa de correo electrónico:

    firestarter

  10. Proceda a desinstalar firestarter:

    make uninstall

  11. Finalmente, a fin de recuperar algo de espacio en disco duro, procederemos a limpiar los módulos y binarios creados dentro de /usr/src/redhat/BUILD/firestarter-0.8.2

    make clean

Autor: Joel Barrios Dueñas
Correo electrónico: jbarrios arroba linuxparatodos punto net
Sitio de Red: http://www.linuxparatodos.net/

Publicado por anonymous en 14:38

Suscribirse a: Entradas (Atom)