http://code.google.com/p/googlesitemapgenerator/

Yo me decidí a probarlo debido a comentarios que había recibido, que después de instalarlo al cierto tiempo los sitios adonde lo instalaron empezaron a recibir mas trafico de Google.

Para instalarlo en un servidor linux, es indispensable que tengas acceso de “root” ya que es necesario modificar la configuración de apache2.

Esta guía aplica para linux debian y ubuntu, ya que siguiendo estos pasos lo pude instalar sin ningún problema en debian etch y ubuntu lucid.

Yo baje la beta disponible hasta el momento de esta guía, el cual tenia el siguiente nombre:

sitemap_linux-i386-beta1-20091231.tar.gz

Este archivo lo baje el directorio raíz, /root.

Después de bajarlo ejecute el siguiente comando:

tar -zxvf sitemap_linux-i386-beta1-20091231.tar.gz

Despues de descomprimir este archivo, ingrese a la carpeta adonde se descomprimió con el siguiente comando:

cd sitemap-install/

Dentro de ahi hay un archivo llamando install.sh, lo ejecute y me dio una serie de problemas ya que no localizaba el archivo ejecutable del apache2; este inconveniente lo solucione ejecutando el siguiente comando:

./install.sh -t /usr/sbin/apache2 -g www-data

Con este comando definí el ejecutable de apache2 y el grupo al que pertenece.

Después de aceptar los términos, nos da un sumario de lo que vamos a instalar:

Do you agree with the Terms of Service? [N/y]y

Google Sitemap Generator will be installed into

/usr/local/google-sitemap-generator

***************************************************************************

The following information about your Apache installation has been detected:

* Apache version: 2.2

* Apache architecture: 32 bits

* Apache root configuration file: /etc/apache2/apache2.conf

* Apache group: www-data

***************************************************************************

Is all of this information correct? If you answer No, installation will

terminate and you’ll need to restart the installation, using the necessary

command line options. [N/y]y

Do you agree with the Terms of Service? [N/y]y
Google Sitemap Generator will be installed into/usr/local/google-sitemap-generator
***************************************************************************The following information about your Apache installation has been detected:  * Apache version: 2.2  * Apache architecture: 32 bits  * Apache root configuration file: /etc/apache2/apache2.conf  * Apache group: www-data***************************************************************************Is all of this information correct? If you answer No, installation willterminate and you’ll need to restart the installation, using the necessarycommand line options. [N/y]y

Procedamos con la instalación.

Después nos muestra unas opciones, yo escogí que genere el sitemap pero que no lo envié a los motores de búsqueda automáticamente, es la opción 1:

Google Sitemap Generator will start creating Web Sitemap files as soon as it

starts up. Do you want Google Sitemap Generator to start submitting these

files automatically? There are three options:

1.  First installation. Start with automatic submission disabled.

2.  First installation. Start with automatic submission enabled.

3.  Reinstallation. Use the old automatic submission settings.

Specify your choice [1]:1

Program files successfully copied.

Google Sitemap Generator settings successfully updated.

Google Sitemap Generator init scripts successfully installed.

Apache configuration successfully updated.

Old configuration is saved at /etc/google-sitemap-generator/httpd.install.conf

Después de esto nos va a pedir que definamos una contraseña para la consola de administración:

Ready to set the password for the administration console.

Password (5 or more characters):

Confirm password:

Luego nos va a decir que el daemon esta corriendo y que necesita reiniciar el apache2,  seleccionamos que si, y nos va a dar error al reiniciar el apache2, no se preocupen esto lo solucionaremos después:

Google Sitemap Generator daemon successfully started.

To start the Google Sitemap Generator module in Apache, you must restart Apache.

Do you want to restart Apache now? [N/y]y

apache2: bad user name ${APACHE_RUN_USER}

Failed to restart Apache. You need restart it manually.

After you restart Apache, you can go to http://<this-server-address>:8181/ to

configure the application.

Google Sitemap Generator (Beta) was successfully installed.

Luego, tenemos que habilitar administración remota, para poder ingresar la consola de administración desde otra computadora, esto lo hacemos ejecutando el siguiente comando:

/usr/local/google-sitemap-generator/bin/sitemap-daemon remote_admin enable

Set remote_admin successful.

Try to reload setting to make remote_admin take effect…

Reload setting command is sent.

Setting is reloaded successfully.

Ahora nos pasamos a la configuración de apache2, necesitamos habilitar el modulo de ssl, esto lo hacemos con el siguiente comando:

a2enmod

Escribimos ssl y luego presionamos enter:

ssl

Enabling module ssl.

See /usr/share/doc/apache2.2-common/README.Debian.gz on how to configure SSL and create self-signed certificates.

Run ‘/etc/init.d/apache2 restart’ to activate new configuration!

Tenemos que reiniciar el apache2, pero no lo vamos a hacer todavía.

El Google sitemap generator agrega la siguiente linea en la configuración de /etc/apache2/apache2.conf:

Include /usr/local/google-sitemap-generator/conf/httpd.conf

Este archivo contiene la siguiente configuración:

Listen 8181

NameVirtualHost *:8181

<VirtualHost *:8181>

DocumentRoot “/usr/local/google-sitemap-generator/admin-console”

ScriptAlias /cgi-bin/ “/usr/local/google-sitemap-generator/admin-console/cgi-bin/”

<Directory “/usr/local/google-sitemap-generator/admin-console” >

Allow from all

Options ExecCGI

DirectoryIndex index.html

</Directory>

</VirtualHost>

LoadModule google_sitemap_generator_module “/usr/local/google-sitemap-generator/lib/mod_sitemap.so”

/etc/init.d/apache2 restart

https://10.10.10.1:8181/

Felicidades, han instalado el Google Sitemap Generator para linux.

Monitoreo de ancho de banda

Esto es muy importante, ya que al monitorear cuanto ancho de banda consume un servidor en tiempo real podemos determinar cuales son sus horas pico y así optimizarlo. Para monitorear esto recomiendo el programa iptraf. Con este programa podrán monitorear todo lo que esta sucediendo en nuestra interface de red. Les adjunto algunas imágenes:

Monitoreo de consumo de CPU y Memoria

Otra de las tareas de un sysadmin es monitorear el consumo de CPU y Memoria (RAM y SWAP), linux viene con el comando “top”. A mi en lo personal no me gusta, así que uso el programa htop. Este programa es muy completo ya que nos detalla el consumo de CPU y Memoria por proceso, así como el consumo general de los recursos del sistema. Es mucho mas amigable a comparación del top normal. Incluso conforme se va usando el procesador o los núcleos del procesador el programa lo indica de una manera “gráfica” tal como lo muestra la siguiente imagen que tome de un servidor en producción:

Monitoreo de consumo de disco duro

Cada cierto tiempo es necesario que entremos a revisar cuando espacio en disco hay libre en los servidores que manejamos. Para saber el espacio en disco duro se ejecuta el comando “df” en linux. A mi en lo personal no me gusta, prefiero uno mas “amigable” así que utilizo uno llamado discus. Este programa es que te indica cuanto espacio esta usado y cuando espacio hay libre, así como los porcentajes de los mismos. Aquí les adjunto una foto con la comparación del “df” con el “discus”.

Monitoreo del I/O

Para que quede claro que es el I/O.

En computación, entrada/salida, también abreviado E/S o I/O (del original en inglés input/output), es la colección de interfaces que usan las distintas unidades funcionales (subsistemas) de un sistema de procesamiento de información para comunicarse unas con otras, o las señales (información) enviadas a través de esas interfaces. Las entradas son las señales recibidas por la unidad, mientras que las salidas son las señales enviadas por ésta.

En términos mas “amigables” es la entrada y salida de datos, que en realidad significa actividad del disco duro. Entre mas sea la actividad de READ (lectura) y WRITE (escritura) mas alto va a ser el I/O y por consiguiente mas lento se pondrá el servidor. Por eso es que para servidores que van a servir sitios con mucho trafico, recomiendan discos duros SCSI o SAS por su alto rendimiento a comparación de otros discos duros (como por ejemplo IDE o SATA) por consiguiente su I/O va a ser menor y va a poder servir data mucho mas rapido.

Para monitorear el I/O yo utilizo la herramienta “iotop” (se necesita python 2.5 y un kernel 2.6.20 para que funcione) es una interfaz simple que indica que proceso esta escribiendo o leyendo en el disco duro, tal como lo muestra la siguiente imagen:

Monitoreo de peticiones de DNS

Si administras un servidor de DNS, en alguna ocasión vas a querer saber cuantas peticiones tu servidor de DNS tu servidor recibe. Para monitorear esto utilizo el programa dnstop con este se puede monitorear cuantas peticiones esta teniendo tu servidor ya sea por clase de dominio .net .org, direcciones ip, por dominio o por sub dominios.

Para ejecutarlo solo ejecutas el comando:

dnstop eth1

Tienes que especificar la interface en la cual quieres que “escuche” el programa. Presionando los botones de 1 2 3 4 puedes ver los diferentes tipos de reportes que tiene.

Adjunto imagen del programa:

Monitoreo de trafico WEB

La mayoría de nosotros estamos a cargo de un servidor que sirve paginas web, es muy importante el monitoreo en tiempo real para saber que archivos estamos sirviendo, cuantas peticiones por segundo estamos manejando y el trafico que estamos teniendo (en megas). El servidor web mas usado es apache, yo utilizo la herramienta llamada “apachetop“.

Con este programa podemos monitorear que archivos servimos con mayor frecuencia, cuantos bytes/kylobytes/megabytes servimos, cuantas peticiones por segundo, peticiones totales y un promedio general de todo lo que sirve el apache.

Adjunto una imagen del apachetop corriendo en un servidor en producción:

Monitoreo de puertos abiertos

Otra de las tareas de un sysadmin es estar al tanto de que puertos hay abiertos en un servidor. Como lo dice la regla, si un servicio no te sirve, quitalo del sistema. Para monitorear puertos uso la herramienta llamada nmap.

Con el comando:

nmap -v 127.0.0.1

Saque un listado de puertos abiertos en el servidor. Si su servidor tiene varias direcciones IP es importante que hagan un escaneo de puertos a todos los IP.

Adjunto imagen del resultado que muestra nmap:

Espero que les sirvan estas herramientas, así como estas hay miles de herramientas e incluso pueden haber mejores. Cualquier sugerencia/comentario es bienvenido.

En esta guía, explicare como montar un servidor BIND 9 primario con servidores de DNS esclavos, siempre utilizando BIND 9 en todos los servidores.

Como ejemplo, vamos a utilizar las siguientes direcciones IP para los servidores de DNS:

Servidor Primario de DNS: 10.1.1.1 – ns1.hola.com

Servidor Secundario de DNS: 10.1.1.2 – ns2.hola.com

Servidor Terciario de DNS: 10.1.1.3 – ns3.hola.com

Instalemos el paquete bind9. Esto lo hacemos de la siguiente manera:

web:/etc# apt-get install bind9
Reading package lists... Done
Building dependency tree... Done
Suggested packages:
  bind9-doc
The following NEW packages will be installed:
  bind9
0 upgraded, 1 newly installed, 0 to remove and 5 not upgraded.
Need to get 297kB of archives.
After unpacking 782kB of additional disk space will be used.
Get:1 http://ftp.debian.org etch/main bind9 1:9.3.4-2etch3
Fetched 297kB in 0s (760kB/s)
Selecting previously deselected package bind9.
Unpacking bind9 (from .../bind9_1%3a9.3.4-2etch3_i386.deb) ...
Setting up bind9 (9.3.4-2etch3) ...
Adding group `bind' (GID 104) ...
Done.
Adding system user `bind' (UID 104) ...
Adding new user `bind' (UID 104) with group `bind' ...
Not creating home directory `/var/cache/bind'.
wrote key file "/etc/bind/rndc.key"
Starting domain name service...: bind.

Listo, ya esta instalado bind9.

Yo necesito que el servidor lleve un historial de las peticiones que hacen al servidor, así que modifico el archivo /etc/bind/named.conf y agrego lo siguiente al final:

logging {
channel “querylog” { file “/var/log/bind9.log”; print-time yes; };
category queries { querylog; };
};

Ademas de esto, tengo que configurar el servidor BIND primario para que solo acepte peticiones hacia los dominios de los cuales es un Servidor de Dominio, (los dominios de los cuales el va a ser un name server) y también las direcciones IP de los servidores BIND esclavos.

El archivo /etc/bind/named.conf.options se encuentra configurado de la siguiente manera:

options {
directory “/var/cache/bind”;

// If there is a firewall between you and nameservers you want
// to talk to, you might need to uncomment the query-source
// directive below. Previous versions of BIND always asked
// questions using port 53, but BIND 8.1 and later use an unprivileged
// port by default.

// query-source address * port 53;

// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0′s placeholder.

// forwarders {
// 0.0.0.0;
// };

auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};

Le haré los siguientes cambios:

options {
directory “/var/cache/bind”;
allow-query { 10.1.1.1/28; } ;
allow-transfer { none; };
// If there is a firewall between you and nameservers you want
// to talk to, you might need to uncomment the query-source
// directive below.  Previous versions of BIND always asked
// questions using port 53, but BIND 8.1 and later use an unprivileged
// port by default.

// query-source address * port 53;

// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0′s placeholder.

// forwarders {
//      0.0.0.0;
// };

auth-nxdomain no;    # conform to RFC1035
recursion no;
};

acl slaves {
10.1.1.2/29;           // ns2
10.1.1.3/29;         // ns3
};

Explicare cada campo.

allow-query { 10.1.1.1/28; } ;

IP del servidor Primario de DNS

allow-transfer { none; };

Con este parámetro restringimos la transferencia de zonas a Servidores DNS esclavos que no estén autorizados. Esta es una buena medida de seguridad, ya que evitamos que personas ajenas se enteren de las direcciones IP que están dentro de la zona de DNS de un dominio.

acl slaves {
10.1.1.2/29;           // ns2
10.1.1.3/29;         // ns3
};

Listado de acceso (access list) de los servidores de DNS esclavos.

Después de hacer estos cambios vamos a crear una zona de DNS para el dominio hola.com.

Creamos un archivo llamado hola.com.hosts en el directorio /var/cache/bind. Dentro de este archivo pondremos lo siguiente:

$TTL 86400
@ IN SOA ns1.hola.com. root.hola.com. (
2008281000 ; serial
3600 ; refresh
7200 ; retry
604800 ; expire
86400 ; minimum
)
@ IN NS ns1.hola.com.
@ IN NS ns2.hola.com.
@ IN NS ns3.hola.com.
IN A 10.1.1.5
www IN CNAME hola.com.

Con esta zona de DNS de hola.com estamos apuntando, hola.com y  www.hola.com hacia la IP 10.1.1.5.

Hay que tener en cuenta que los sub dominios ns1.hola.com, ns2.hola.com y ns3.hola.com, los configure con mi proveedor de dominio, (Godaddy) ya que desde el proveedor del dominio (Godaddy)  indicaremos al mundo de Internet que ns1.hola.com apunta a 10.1.1.1 y asi sucesivamente con los otros servidores de DNS. Sin esto, nuestros servidores de DNS no van a funcionar.

En las zonas del dominio definiremos quien puede hacer una petición de resolución de nombre al dominio, a quien le damos permiso para que pueda copiar las zonas; que en este caso solo seria a los servidores de DNS esclavos.

Agregamos la zona en el servidor primario de DNS, del dominio hola.com en el archivo /etc/bind/named.conf.local

zone “hola.com” {
type master;
notify no;
allow-query { any; };
allow-transfer { slaves; };
file “hola.com.hosts”;
};

En los servidores esclavos de DNS la configuración seria la siguiente en /etc/named.conf.local:

zone “hola.com” {
type slave; masters { 10.1.1.1; };
allow-query { any; };
file “hola.com.hosts”;
};

Explico que significa cada campo.

En el servidor primario de DNS:

zone “hola.com” {       Definimos el dominio.
allow-query { any; };   Cualquier computadora puede hacer una petición de DNS a este dominio.
allow-transfer { slaves; };  Con este parámetro le damos permiso a los servidores esclavos de DNS que puedan hacer una copia de la zona de DNS para el dominio hola.com
file “hola.com.hosts”;   Archivo donde se encuentra los parámetros de la zona para el dominio hola.com.

En los servidores de DNS secundarios:

zone “hola.com” {  Dominio.
type slave; masters { 10.1.1.1; };  Definimos a quien le debe pedir una copia de la zona de DNS para el dominio hola.com que en nuestro caso seria el servidor de DNS primario.
allow-query { any; }; Cualquier computadora puede hacer una petición de DNS a este dominio.
file “hola.com.hosts”; Archivo donde se encuentra los parámetros de la zona para el dominio hola.com.

Reiniciaremos el servicio de BIND en el servidor primario de DNS antes que los secundarios. Esto lo hacemos con el siguiente comando:

/etc/init.d/bind9 restart

Despues de reiniciarlos, verificaremos en el el “syslog” que nuestros servidores de DNS secundarios esten copiando la zona de DNS para hola.com. Encontraremos un registro similar a este:

tail -f /var/log/syslog

Nov 5 15:43:57 ns1 named[1966]: client 10.1.1.2#48716: transfer of ‘hola.com.us/IN’: AXFR started
Nov 5 15:43:57 ns1 named[1966]: client 10.1.1.2#48716: transfer of ‘hola.com/IN’: AXFR ended

Nov 5 15:43:57 ns1 named[1966]: client 10.1.1.3#48716: transfer of ‘hola.com/IN’: AXFR started
Nov 5 15:43:57 ns1 named[1966]: client 10.1.1.3#48716: transfer of ‘hola.com/IN’: AXFR ended

Con esto confirmamos que las zonas de DNS para hola.com fueron transferidas hacia los servidores de DNS secundarios.

Ahora es necesario confirmar que los archivos de las zonas de DNS en los servidores secundarios se esten creando correctamente. Entramos a los servidores de DNS secundarios, y hacemos un “cat” al archivo hola.com.hosts en el directorio /var/cache/bind.

Si todo esta bien mirarian algo similiar a esto:

rolando@web:/var/cache/bind$ cat hola.com.hosts
$ORIGIN .
$TTL 86400 ; 1 day
hola.com IN SOA ns1.hola.com. root.hola.com. (
2008281000 ; serial
3600 ; refresh (1 hour)
7200 ; retry (2 hours)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS ns1.hola.com.
NS ns2.hola.com.
NS ns3.hola.com.
A 10.1.1.5
$ORIGIN hola.com.
www CNAME hola.com.

Felicidades, han montado un servidor de DNS primario con 2 secundarios. Cualquier duda o comentario es bienvenido.

Les recomiendo que compren estos libros, si quieren aprender en su totalidad bind 9, los pueden comprar en Amazon con los siguientes enlaces:

Tuve que recurrir a la famosa opción “-9″ no es la mejor manera para matar un proceso, pero ay casos que ay que usarlo.

En debian el comando killall viene en el paquete llamado psmisc, así que procedí a instalarlo:

apt-get install psmisc

Despues de instalar el comando ejecute el comando:

db:/home/rolando# killall -9 slon

Luego confirme que ya no estuviera corriendo los procesos slon con el siguiente comando:

db:/home/rolando# ps aux | grep slon
root     21903  0.0  0.0   2852   708 pts/0    S+   16:39   0:00 grep slon

Confirme que ya no estaba corriendo procesos de slon.

Este comando también se puede usar para matar un gran listado de procesos, asi evitamos el tedioso procedimiento de ir matando proceso por proceso.