viernes, 15 de agosto de 2008

DNS (Bind9) ACTUALIZADO DINÁMICAMENTE POR EL DHCP3-SERVER

Instalamos los paquete que vamos a necesitar, en este caso bind9 y dhcp3-server:
#apt-get install bind9
#apt-get install dhcp3-server
Al momento de instalar el bind9 automáticamente se crea un directorio llamado bind, dentro de este directorio se encuentran unos archivos basicos para la configuración y entre ellos se encuentra la llave, rndc.key; veámosla.
#more /etc/bind/rndc.key
Bien! Esta misma llave debemos copiarla en la carpeta del dhcp3.
#cp /etc/bind/rndc.key /etc/dhcp3
Verifique que la llave sea la misma, es decir que los caracteres no hayan cambiado
Como lo habiamos dicho con anterioridad al momento de instalar bind9 se crea un directorio dentro de etc llamado bind. Vamos a este directorio.
#cd /etc/bind
- Dentro de esta carpeta encontramos los archivos de configuración. Editaremos el archivo named.conf y definiremos las zonas:
#nano named.conf
- Agregamos la configuración de la llave que nos va a permitir actualizar dinámicamente el dns;
include "/etc/bind/rndc.key";
- Posteriormente agregamos la configuración de la zona directa
zone “thiney.com” {
type master;
file “/etc/bind/db.thiney”; Este archivo se debe crear

Para activar las actualizaciones con el DHCP ponemos esto:
notify yes;
allow-update {key "rndc-key";};
};
- Ahora procedemos a agregar la configuración de la zona inversa:
zone “5.168.192.in-addr.arpa” {
type master ;
file “/etc/bind/db.192.168.5”; Este archivo se debe crear
notify yes;
allow-update {key "rndc-key";};
};
- Guardamos el archivo
control x + si + enter
- Ahora dentro de bind creamos las bases de datos de la zonas, para facilitar todo copiamos el db.127 para la inversa y db.local para la directa.
#cp db.127 db.192.168.5
#cp db.local db.thiney

Como va todo? Espero que bien... Ahora editamos el archivo db.thiney. Este archivo debe contener los nombres de los host y la dirección así :
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.thiney.com. root.thiney.com. (
20080801 ; serial
604800 ; refresh
86400 ; retry
2419200 ; expire
604800 ) ; negative cache TTL
;
@ IN NS ns1.thiney.com.
@ IN A 192.168.5.2
@ IN MX 10 mx1.thiney.com.
www IN A 192.168.5.2
ftp IN CNAME www.
kate IN A 192.168.5.10

- Guardamos y procedemos a editar el archivo db.192.168.5, la zona inversa es utilizada para resolver direcciones IP a nombres.
;BIND reverse data file for broadcast zona
;
$TTL 604800
@ IN SOA ns1.thiney.com. root.thiney.com. (
20080801 ; serial
604800 ; refresh
86400 ; retry
2419200 ; expire
604800 ) ; negative cache TTL
;
@ IN NS ns1.thiney.com.
2 IN PTR ns1.thiney.com.
10 IN PTR kate.

Bueno, por último debemos agregar nuestro servidor DNS en el resolv.conf. Así que procederemos a editarlo
#nano /etc/resolv.conf
Agregamos lo siguiente:
search thiney.com
nameserver 192.168.5.2 (esta es la dirección IP de nuestro servidor DNS )

- Bueno, hemos terminado la configuración de nuestro DNS. Ahora vamos a reiniciar el servicio
#/etc/init.d/bind9 restart

- Lo probamos
#nslookup
> 192.168.5.2
Server: 192.168.5.2
Address: 192.168.5.2#53
2.5.168.192.in-addr.arpa name = ns1.thiney.com.

Existen dos comando que a mi parecer son bastante útil. Y son estos:
Named-checkzone:
#named-checkzone thiney.com /etc/bind/db.thiney
#named-checkzone thiney.com /etc/bind/db.192.168.5.2

Ambos comandos cargan los seriales de las zonas y si esta correcta la configuración nos arroja un OK. Así
zone thiney.com/IN: loaded serial 84
OK
Otro comando es el named-checkconf. Este verifica la configuración de nuestro archivo named.conf, si es correcta esta configuración no arroja ningún resultado, si hay errores nos índica la línea.
#named-checkconf
Si deseamos que nuestro DNS resuelva direcciones diferentes a la de nuestra red. Utilizamos los reenviadores, en el archivo named.conf.options. Descomentando algunas líneas y agregando los servidores de nuestro ISP (Proveedor de servicio de Internet) Editamos named.conf.options
#nano named.conf.options
y lo dejamos así:
forwarders {
200.13.249.101;
100.75.78.78;
};
Por último salimos de bind
#cd ..
Y le damos permisos SUID (Set User ID) a nuestro directorio.
#chmod 2775 -R bind

CONFIGURANDO EL DHCP3-SERVER

Como ya instalamos nuestro paquete procederemos a configurar el archivo. Vamos a la carpeta dhcp3 que se encuentra en el directorio etc. Entramos a esta carpeta.
#cd /etc/dhcp3
Dentro de esta se encuentra el archivo de configuración del dhcp. Editamos el archivo de configurar llamado dhcpd.conf
#nano dhcpd.conf
Como necesitamos que nuestro dhcp actualice dinámicamente el dns, debemos agregar estas lineas. Recuerda que ya copiamos la llave del bind al dhcp3. Ahora configuramos esta la ruta para la llave.
include "/etc/dhcp3/rndc.key";
#Agregando la zona directa
zone thiney.com {
primary 192.168.5.2;
key rndc-key;
}
#Agregando la zona inversa
zone 5.168.192.in-addr.arpa.{
primary 192.168.5.2;
key rndc-key;
}
#Esto es lo que activa las actualizaciones.
ddns-updates on;
ddns-update-style interim;
ddns-domainname "thiney.com";
ddns-rev-domainname "5.168.192.in-addr.arpa";
do-forward-updates on;
allow client-updates;
authoritative;
log-facility local7;

# CONFIGURACION DE MI RED LOCAL.
subnet 192.168.5.0 netmask 255.255.255.0 {
range 192.168.5.100 192.168.5.200;
option routers 192.168.5.1;
option broadcast-address 192.168.5.255;
option domain-name "thiney.com";
option domain-name-servers 192.168.5.2;
default-lease-time 600;
max-lease-time 1200;
}
Guardamos y salimos
#control + x + si + enter
Por último reiniciamos el servicio y confirmamos que nos este entregando direcciones.

martes, 12 de agosto de 2008

FUNCIONAMIENTO SQUID

Cuando una página se encuentra almacenada en la caché del servidor Squid, ocurre esto:

Paso 1º: En ésta imágen podemos ver cómo se establece la conexión entre el cliente y el servidor Intermediario, recordemos que esta conexión se establece ya que se esta utilizando un protocolo orientado a conexión, es decir que necesita establecer un canal para poder trasmitir.




Paso 2º: El usuario por medio de un cliente (un navegador), realiza una petición URL al servidor Intermediario. La petición URL en pocas palabras es una página web que el usuario esta solicitando,

Paso 3º:En esta imágen podemos observar que lo primero que hace un servidor proxy al momento de recibir una peticion URL, es buscar en su caché esta petición y la encuentra!!


Paso 4º:Una vez encontrada esta petición en la caché el servidor Intermediario le da una respuesta al cliente, es decir, la página web solicitada. Esta es la principal razón por la cual no es recomendado reinicar con frecuencia el servicio o el servidor Proxy. Ya que al reiniciar los datos en la caché son eliminados y estaria haciendo nuevamente el siguiente procedimiento para cada petición.




Cuando una página No se encuentra almacenada en la caché del servidor Squid, ocurre esto:

Paso 1º:En ésta imágen podemos ver cómo se establece la conexión entre el cliente y el servidor Intermediario, recordemos que esta conexión se establece ya que se esta utilizando un protocolo orientado a conexión, es decir que necesita establecer un canal para poder trasmitir.



Paso 2º:El usuario por medio de un cliente (un navegador), realiza una petición URL al servidor Intermediario. La petición URL en pocas palabras es una página web que el usuario esta solicitando,



domingo, 10 de agosto de 2008

Afiche Flisol

CONFIGURACION DEL SERVIDOR FTP (PROFTPD)


PROFTPD nace con la necesidad de tener un servidor FTP configurable y seguro, cuenta con un único fichero de configuración llamado proftpd.conf.

Presenta una gran ventaja con respecto a otros ya que su código ha sido portado a muchas plataformas, lo que lo hace bien interesante a la hora de elegir un servidor FTP, entre las mas reconocidas encontramos AIX, FreeBSD, DG/UX, Linux, Mac OS X, NetBSD, OpenBSD, Solaris, SunOS, entre otros...

Para empezar con la instalación de proftpd, debemos descargar el paquete.
Thiney:/#apt-get install proftpd
Escogemos el modo cómo se va a ejecutar, es decir, si lo hará bajo inetd (por servicio) ó standalone (servidor-forma independiente). La gran diferencia entre ambos métodos es la velocidad de ejecución y la carga que se le dará al equipo.

En este caso lo ejecutaré de forma independiente y procedemos a dar Aceptar. Una vez terminada la instalación se crea automática una carpeta dentro del directorio etc llamada proftdp. En esta se encuentra el archivo de configuración principal llamado proftd.conf, procedemos a editarlo con nuestro editor favorito.
Thiney:/# nano /etc/proftpd/proftpd.conf

Aproximadamente en la linea 10 encontramos el primer parámetro.
#Soporte para Ipv6: Activa o desactiva este parámetro de acuerdo a su necesidad. En este caso lo desactivamos.
UseIpv6 off
#Nombre del servidor FTP
ServerName "ftp.thiney.com"
#Modo en que se va a trabajar el servidor, en este caso independiente.
ServerType standalone
#Activa el mensaje de entrada antes o después del logueo del user
DeferWelcome on
#Personaliza el mensaje de bienvenida
ServerIdent on "BIENVENIDO AL SERVIDOR FTP.THINEY.COM"
#La siguiente linea nos garantiza la compatibilidad o no con la mayoría de clientes FTP. Por lo tanto procedemos a activarlo (on).
MultilineRFC2228 on

#Usaremos on, para que tome las opciones por defualt de un servidor ftp
DefaultServer on
#Si esta en on, podremos ver los links, si el link esta fuera de nuestro home no tendremos acceso a él
ShowSymlinks on
#Permite o Deniega la sobre-escritura de los archivos existentes, en este caso desactivamos la sobre-escritura.
AllowOverwrite off
#El número máximo en segundos, que puede estar un cliente, sin transferencia
TimeoutNoTransfer 900
#Ahora procedemos a cambiar el número máximo de segundos que puede estar el cliente-servidor sin recibir información de una transferencia.
TimeoutStalled 600
TimeoutIdle 160
#El siguiente parámetro es un filtro de protección para este servidor ProFTPd
DenyFilter \*.*/

#Puerto de escucha
Port 21
#Número de visitas máximas en el ftp
MaxInstances 13
#Usuario y grupo, Si no existen estos grupos o usuarios, debemos crearlo.
User proftpd
Group proftpd
#Personaliza el mensaje al momento de loguearse
AccessGrantMsg "LA CONEXION FUE EXCITOSA"
#Mensaje cuando el nombre o el pass ha fallado
AccessDenyMsg "HA FALLADO, VUELVA A LOGUEARTE"
#Enjaula al usuario dentro de su propio home
DefaultRoot ~
#El siguiente comando permite definir un fichero de contraseñas especifico a los usuarios y a los grupos.
AuthUserFile "/etc/passwd"
AuthGroupFile "/etc/group"

#Establece un número máximo de clientes que pueda estar conectados simultaneamente en el servidor
MaxClients 2 "MAX USER"
#Máximo numero de clientes por Host(ip)
MaxClientsPerHost 2 "MAX HOST"
#Máximo numero de clientes por usuario
MaxClientsPerUser 2 "MAX POR USER"
#A continuación desactivamos el parámetro que nos indica que los usuarios no requieren una shell, valida o "autentica". Esto le brinda un poco de seguridad a nuestro servidor FTP.
RequireValidShell off
#Le decimos que el directorio del ftp es /home/ftp y a continuación le damos unas características
Umask 077 077
AllowOverwrite off

#nuestro directorio de subida se encontrará en /home/ftp/subir, así que especificamos algunos permisos para el directorio
Umask 077 077
AllowOverwrite on
#El directorio tendrá acceso de lectura, escritura y grabación para todos(Allow All)
AllowAll
#Para denegar acceso a ciertos usuarios
DenyUser fercho
#Guardamos y salimos (control + X + Si + Enter)

Lo siguiente es crear las cuentas de usuario y el grupo
Thiney:/#adduser kate
Adding user 'kate' ...
Adding new group 'kate' (1007) ...
Adding new user 'kate' (1004) with group 'kate' ...
Creating home directory '/home/kate' ...
Copying files from '/etc/skel' ...
Enter new UNIX password:*******
Retype new UNIX password:*******
passwd: contraseña actualizada correctamente
Cambiando la información de usuario para kate
Introduzca el nuevo valor, o presione ENTER para el predeterminado
Nombre completo []: kate
Número de habitación []:
Teléfono del trabajo []:
Teléfono de casa []:
Otro []:
¿Es correcta la información? [y/N] y

Ahora editamos el archivo passwd ubicado en etc. En este archivo realizaremos dos cambios significativos.
Thiney:/#nano /etc/passwd
Vamos a la linea del usuario que acabamos de agregar, es decir, kate.
kate:x:1004:1007:kate,,,:/home/kate,:/bin/bash
Primero, cambiamos el /home para que todos queden alojados en /home/ftp/. Segundo, cambiamos el shell de /bin/bash a /bin/false, con el fin de que los usuarios no accedan a una shell completa; quedando así:
kate:x:1004:1007:kate,,,:/home/ftp,:/bin/false

En ProFTPd no es necesario agregar una nueva shell (/bin/false) en /etc/shells, pues en el archivo de configuración principal desactivamos este parámetro que indica que los usuarios no requieren una shell, valida o "autentica" (RequireValidShell off)

Por ultimo reiniciamos el servicio ProFTPd para que la configuración tenga efecto.
Thiney:/#/etc/init.d/proftpd restart
Stopping ftp server: proftpd.
Starting ftp server: proftpd.

Ahora ingresaremos al ftp desde la consola

Thiney:/#ftp 192.168.70.4
Connected to 192.168.70.4.
220 BIENVENIDO AL SERVIDOR FTP.THINEY.COM
Name (192.168.70.4:root): kate
331 Password required for kate
Password: ***** (ponemos nuestra contraseña)
230 LA CONEXION FUE EXCITOSA
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls (Listar contenido)
200 PORT command successful
150 Opening ASCII mode data connection for file list
-rw-r--r-- 1 thiney thiney 12449 Jul 30 01:46 servicios.odt
drwxrwxrwx 3 root root 4096 Aug 3 08:37 subir
226 Transfer complete.
ftp> exit
221 Goodbye.

Verificamos por medio del navegador, para esto ponemos la dirección de nuestro servidor ftp://192.168.70.4 o si ya tenemos el dns funcionando ponemos ftp://thiney.com/. Nos pedirá el nombre de Usuario y Contraseña, así:

Y listo!!

Si desea conocer mas parámetros para una configuración avanzada, lo invito a ingresar a la página oficial de proftpd http://www.proftpd.org/localsite/Userguide/linked/userguide.html

Hasta pronto

lunes, 4 de agosto de 2008

BENCHMARK

Qué es??
Apache Benchmark (ab) es una herramienta para la evaluación comparativa de servidores web. Esta herramienta permite a los administradores llevar a cabo unas buenas pruebas de carga, simulando miles y miles de conexiones por segundo, antes de poner en marcha un servidor Web.
Esta aplicación viene por defecto con Apache2, es decir, no es necesario descargarla o instalarla.

Recomendaciones:
*Usa la misma configuración de hardware y kernel (SO) para todas las pruebas.
*Toma por lo menos de 3 a 5 lecturas y utiliza el mejor resultado.

Es importante realizar la pruebas con y sin KeepAlive (-k). Este parámetro permiten múltiples solicitudes en una misma conexión TCP. Cuando se hacen comparativas con benchmarks se tiene que hacer con equipos equivalentes y que todo sea lo más parecido posible y en las mismas condiciones, así se garantiza que los resultados sean lo mas parecido a la realidad.

El Objetivo de estas pruebas es ver cómo reaccionan los diferentes servidores web en situaciones extremas. Trabajaremos con algunas variables (-n, -k, -c)

Donde:
-n: Es el número de peticiones.
-k: Nos índica si la conexión se cierra o queda abierta para recibir las demás peticiones. Consume menos recursos y hace que el servidor responda más rápido.
-c: Número de concurrencias, solicitudes simultáneas. El valor máximo es 20000

NOTA: El sistema tiene un tope determinado de peticiones para algunos procesos. Es posible forzar el sistema utlizando el comando ulimit:
Esta función obtendrá o modificará algún límite para el proceso actual, en este caso, nos permite aumentar el número de peticiones y trabajar con números más grandes. Podemos obtener más información sobre estos procesos con ulimit -a:



Como podemos ver open file (-n) se encuentra en 10000, es decir que solo podemos enviar 10000 peticiones simultáneamente con ab (concurrencia), para forzar el sistema o cambiar este límite, debemos utilizar ulimit -n mas el valor que se desee, este valor llega a 1048576. Pero no es necesario llegar a este número (1048576) ya que por defecto la concurrencia en apache tiene un limite y es de 20000 peticiones simultáneamente. Sin embargo lo haremos a manera de ejemplo:
ulimit -n (número de 0 a 1048576)
Esto queda así:
Nos enfocaremos en los tiempo de respuestas (Time per request) que la prueba ab nos arroje. Y con éste valor más el número de peticiones se crearán unas gráficas comparativas entre los diferentes servidores web.
TIPS: Las pruebas se realizan con 3 servidores web montados en una sola máquina, estos servicios se encuentran corriendo en los puertos 80, 81 y 82.
Es importante que la longitud del documento (Document Length), es decir, el tamaño del index sea el mismo en los 3 servicios. En este caso utilizamos un pequeño index de 29 bytes.
Tenga en cuenta el / al terminar la URL

Prueba 1º

Detalles:
Procesador: Mobile AMD Sempron 1,81 GHz
Memoria: 512 MB
S.0: Debian GNU/Linux 4.0 "Etch"
Apache Benchmark Version 2.0.40-dev.
Versiones de los servicios web:
Apache 2.2.3 lighttpd-1.4.13Cherokee 0.5.5

Conclusiones Personales: En esta gráfica podemos ver claramente el desempeño de los servidores web. Inicialmente vemos algo muy variable.Vemos un aumento en los tiempos de respuesta de los 3 servidores, estas variaciones se dan en los rangos del 50 al 2000, después de las 2000 peticiones los 3 servidores se estabilizan y los resultados en los tiempos de respuestas tambien.Cabe notar que los tiempos de respuestas entre ellos no son los mismos. Podemos ver claramente que el tiempo de respuesta del servidor apache es muy alto, en pocas palabras, se demora mucho procesando una petición, cosa que no ocurre con el servidor web cherokee. Este servidor muestra un mejor desempeño incluso frente al servidor Lighttpd. Recordemos que esta prueba es muy exigente ya que en cada petición se debe abrir y cerrar la conexión.

Prueba 2º
Detalles:
Procesador: Mobile AMD Sempron 1,81 GHz
Memoria: 512 MB
S.0: Debian GNU/Linux 4.0 "Etch"
Apache Benchmark Version 2.0.40-dev.
Versiones de los servicios web:
Apache 2.2.3 lighttpd-1.4.13 Cherokee 0.5.5


Conclusiones Personales: Esta prueba es muy parecida a la primera, solo que para esta prueba se utilizó la variable -k que nos índica que la conexión queda abierta para recibir las demás peticiones, podemos ver que los tiempos de respuestas son mas favorables para los tres servidores ya que esta variable hace que los servidores consuman menos recursos y como consecuencia responden más rápido.

Prueba 3º
Detalles:
Procesador: Mobile AMD Sempron 1,81 GHz
Memoria: 512 MB
S.0: Debian GNU/Linux 4.0 "Etch"
Apache Benchmark Version 2.0.40-dev.
Versiones de los servicios web:
Apache 2.2.3
lighttpd-1.4.13
Cherokee 0.5.5

Conclusiones Personales: En nuestra tercera prueba podemos observar y concluir que el servidor web Cherokee responde mejor cuando se le aplica mayor carga, es decir, cuando tienes mas peticiones que procesar. Estas fueron unas pequeñas pruebas que se realizaron a los servidores web para tener una idea propia del rendimiento de cada uno. De manera muy personal los invito a que utilicen esta aplicación (Apache Benchmark) y realicen sus propias pruebas, recordemos que el resultado variará de acuerdo a la capacidad del computador, de las versiones que utilice en los servidores, del sistema operativo, entre otros.

Hasta Pronto

domingo, 3 de agosto de 2008

LIGHTTPD Básico

Lo primero que vamos hacer es instalamos el paquete

apt-get install lighttpd
Si estas siguiendo paso a paso este manual, probablemente te salga este error al momento de arrancar el servicio.

Starting web server: can't bind to port: 80 Address already in use.
Nos esta indicando que el puerto 80 esta siendo usado, por tal motivo no puede arrancar. Efectivamente el cherokee esta corriendo en este puerto, y en el 81 se encuentra el apache, así que debemos cambiarle de puerto al lighttpd. Vamos a la carpeta lighttpd que se crea automáticamente en etc.
#cd /etc/lighttpd
Y edita al archivo de configuración lighttpd.conf
#nano lighttpd.conf
En la linea 59 aparece el puerto del servidor, se lo cambiamos, que quede así y si esta comentado lo descomentamos.
server.port = 81
Al momento de instalar lighttpd se crea en /var/www una pagina index.html, vamos y la ponemos bien bonita.
cd /etc/lighttpd# cd /var/www

#nano index.html
Ahora si podemos arrancar el servicio.

/etc/init.d/lighttpd restart

verificaremos por medio de un navegador. http://localhost

sábado, 2 de agosto de 2008

CHEROKEE Y HOSTVIRTUAL

En esta oportunidad vamos a instalar el cherokee con hostvirtual, les quiero recordar que en este mismo servidor tenemos instalado un Apache2 y luego se procederá a instalar el Lighttpd para poder realizar nuestras pruebas de estres del servidor web.

Lo primero que hacemos es descargar el paquete

#wget http://www.cherokee-project.com/cherokee-last-tarball/cherokee-0.8.0.tar.gz
Nos ubicamos en la carpeta donde se descargo el paquete y procedemos a desempaquetar y descomprir.
#tar -zxvf cherokee-0.8.0.tar.gz
Configuramos el archivo en el sistema
#./configure --localstatedir=/var
--prefix=/usr
--sysconfdir=/etc
--with-wwwroot=/var/www
Compilamos el paquete
#make
Y por último instalamos.
#make install
Muy bien ahora empezamos a configurar.
Entramos a la carpeta de cherokee que se crea automática en el directorio etc, después de instalarlo.
#cd /etc/cherokee/
aquí podemos ver varios archivos de configuración y algunas carpeta, muy similar al apache, bien entramos a sites-availables
#cd site-available
Copiamos el archivo example.com en con los nombres que querramos para nuestro hostvirtual.
#cp example.com thiney.com
Ahora lo editamos
#nano thiney.com
En la linea 4 ponemos el nombre de nuestro hostvirtual y el la linea 5 la ruta completa para llegar a ésta. Así:
## Virtual server for thiney.com
Server www.thiney.com {
DocumentRoot /var/www/cherokee1/
Directory / {
Handler common
}
}
Para nuestro segundo hostvirtual copiamos este archivo con el nombre que querramos
#cp thiney.com maritza.com

Y realizamos el mismo procedimiento cambiando el nombre del hostvirtual y la ruta para llegar a esta.
## Virtual server for example.com
Server www.maritza.com {
DocumentRoot /var/www/cherokee2
Directory / {
Handler common
}
}

viernes, 1 de agosto de 2008