The twentieth anniversary edition of the world’s best-selling UNIX system administration book has been made even more invaluable by adding coverage of the leading Linux distributions: Ubuntu, RHEL, and openSUSE. System administrators looking to efficiently solve technical problems and maximize reliability and performance in production environments can now turn to UNIX® and Linux® System Administration Handbook, Fourth Edition, which has been systematically updated to reflect today’s most important enterprise Linux and UNIX distributions and most valuable administrative tools.
Drawing on decades of experience, the authors share clear, well-founded advice on constructing robust, production-grade systems and networks that can be easily maintained, monitored, and controlled. You’ll find detailed, up-to-date best practices advice and important new coverage of virtualization, cloud computing, security management, web load balancing and scalability, LDAP/Active Directory integration, modern web scripting languages, Spacewalk, DTrace, eco-friendly IT management, and much more. It reflects the latest versions of all these distributions:
Red Hat® Enterprise Linux® Ubuntu Linux openSUSE Oracle Solaris OpenSolaris AIX HP-UX
Sharing war stories and hard-won insights, the authors capture the behavior of UNIX and Linux systems in the real world, not just in ideal environments. They explain complex tasks in detail, with illustrations from actual production environments, and provide brand-new “Top 20 lists” of system administration rules, power-saving tips, and more.
CentOS + DRBD + HeartBeat + MYSQL DRBD (Distributed Replicated Block Device), es un sistema para almacenamiento distribuido usado en Linux para realizar replicaciones de sistemas de archivos por bloques. Este paquete consiste en un modulo del Kernel drbd-kmod, y scripts que permiten que se puedan realizar replicaciones muy similares a un RAID 1, en red. DRBD se suele usa acompañado de herramientas de High Availability (HA), como Heartbeat, para lograr servidores de alta disponibilidad.
Paquetes Necesarios
En el siguiente ejemplo utilizaremos como base un sistema 32 bits, para lo cual necesitaremos instalar por Yum, o por RPM los siguientes paquetes. • drbd.i386 • kmod-drbd.i686 • MySQL-server <– Aplica a nuestro caso se puede usar cualquier otro servicio. • Heartbeat* • Gnutls* • Ipvsadm*
Para ejecutar el modulo de drbd en el kernel debemos ejecutar lo siguiente:
• modprobe drbd
Instalación del Sistema Operativo CentOS. El sistema operativo lo instalaremos como una instalación normal, con las particiones que deseemos para el, con la única diferencia que dejaremos un espacio sin particionar para ser usado por DRBD, en esta partición almacenaremos en el futuro las aplicaciones que deseemos administrar con DRBD, por ejemplo, si deseamos como es nuestro caso que DRBD mantenga actualizado nuestro MySQL, debemos asegurarnos que TODA la data del MySQL se este almacenando en el volumen lógico del DRBD.
Preparación de la partición de DRBD
Para particionar el volumen que hemos dedicado a nuestro DRBD, será necesario crear un volumen físico, luego agruparlo y por último crear el volumen lógico, de la siguiente forma. • Pvcreate /dev/sda5 <–/dev/sda5 dependerá de la partición que nos de fdisk –l • Vgcreate drbd /dev/sda5 <– drbd es el nombre que le daremos al grupo de volúmenes. • Lvcreate -L1024M -n mysql-drbd drbd <– mysql-drbd es el nombre que le daremos a nuestro volumen lógico.
Configurar DRBD
Una vez hayamos preparado las particiones de DRBD en ambos servidores, es momento de proceder a realizar la configuración de DRBD, esto consiste en editar un fichero ubicado en la ruta /etc/drbd.conf, este archivo tiene características muy peculiares dependiendo de lo que deseamos realizar. En nuestro caso esta adaptado a las necesidades de MySQL, y quedaría de la siguiente forma.
# Our MySQL share
resource db {
protocol C;
handlers {pri-on-incon-degr “echo ‘!DRBD! pri on incon-degr’ | wall ; sleep 60 ; halt -f”; }
startup { wfc-timeout 0; degr-wfc-timeout 120; }
disk { on-io-error detach; } # or panic, …
syncer { rate 6M; }
on srv-nodo01-drbd {
device /dev/drbd1; #Este es el device que se crea para DRBD
disk /dev/mysql_drbd/mysql-drbd; #Este es el volumen lógico que creamos
address 10.134.16.210:7789; #ip servidor nodo01
meta-disk internal;
}
on srv-nodo02-drbd {
device /dev/drbd1;
disk /dev/mysql_drbd/mysql-drbd;
address 10.134.16.209:7789;
meta-disk internal;
}
}
Este es el contenido del archivo /etc/drbd.conf, y debe ser igual en ambos equipos por ende podemos hacer simplemente un scp o un rsync entre ambos para copiarlo.
Una vez configurado nuestros DRBD, debemos iniciar el servicio pero antes debemos crear los recursos que hemos configurado, en nuestro caso como se puede observar en el archivo el recurso se llama “db”, por tal motivo ejecutaremos el siguiente comando e iniciamos el servicio.
drbdadm create-md db
La ejecución de este comando dará las siguientes respuestas:
[root@node1 etc]# drbdadm create-md db
v08 Magic number not found
v07 Magic number not found
About to create a new drbd meta data block on /dev/sda5.
. ==> This might destroy existing data! <== Do you want to proceed? [need to type 'yes' to confirm] yes Creating meta data… initialising activity log NOT initialized bitmap (256 KB) New drbd meta data block sucessfully created.</blockquote>
service drbd start
Podemos ver que el servicio esta funcionando correctamente si ejecutamos lo siguiente en ambos equipos.
En este punto si nos fijamos en los resultados del comando anterior podremos observar que ambos nodos están configurados como secundarios, y como es de suponerse necesitamos que uno de ellos al menos, sea primario. Para realizar esta tarea es necesario hacer lo siguiente.
[root@node1 etc]# drbdadm — –overwrite-data-of-peer primary db
En este punto está listo configurado y operativo el DRBD, por lo que podemos formatear nuestro volumen lógico para dejarlo preparado para recibir información, de la siguiente forma.
mkfs.ext3 /dev/drbd1 ; mkdir /db ; mount /dev/drbd1 /db
Para probar ahora que todo este funcionando como esperamos podemos crear archivos falsos en nuestra partición, e intercambiar los roles de primario y secundario para verificar que se estén sincronizando nuestros archivos, para esto podemos seguir los siguientes pasos.
[root@node1 etc]# for i in {1..5};do dd if=/dev/zero of=/db/file$i bs=1M count=100;done
Este comando creará 5 ficheros de 100 megabytes, con el nombre file 1,file 2,file 3, file 4, file 5. Después de hacer el cambio de nodos manualmente como se describe a continuación, podremos verificar que nuestros ficheros se han replicado.
[root@node1 /]# umount /db ; drbdadm secondary db
[root@node2 /]# mkdir /db ; drbdadm primary db ; mount /dev/drbd1 /db
[root@node2 /]# ls /db/ file1 file2 file3 file4 file5 lost+found
Ahora podemos realizar el proceso contrario para verificar qque si por algún motivo nuestro nodo01 falla, la información del nodo02 podrá ser replicada al nodo01 sin problemas.
[root@node2 /]# rm /db/file2 ; dd if=/dev/zero of=/db/file6 bs=100M count=2
[root@node2 /]# umount /db/ ; drbdadm secondary db
[root@node1 /]# drbdadm primary db ; mount /dev/drbd1 /db
[root@node1 /]# ls /db/ file1 file3 file4 file5 file6 lost+found
En este punto ya hemos comprobado que nuestro DRBD funciona correctamente, y por ende solo nos queda configurar la última herramienta de HA, Heartbeat, que lo haremos después de configurar MySQL con las particiones de DRBD
Configuración de MYSQL
Para configurar MySQL con las particiones de DRBD es simple en nuestro archivo /etc/my.cfg, tenemos una directiva que nos dice donde se almacena la data de MySQL, esta directiva es datadir=/var/lib/mysql en este caso el datadir apunta al directorio /var/lib/MySQL, lo que haremos ahora es simplemente mover el directorio /var/lib/MySQL, a /db y luego crearemos un enlace simbólico lo que será suficiente para que la data almacenada por MySQL se escriba en nuestro volumen lógico. Para esto debemos detener el servicio de MySQL previamente.
Nodo 02
[root@node2 /]# service mysql stop
[root@node2 /]# mv /home/mysql/data /tmp
[root@node2 /]# ln -s /db/mysql/data /home/mysql/data
Una vez realizado esto ya estan preparados nuestros dos nodos, por lo que procederemos a iniciar Mysql en el Nodo01.
Configuración de Heartbeat
La configuración de Heartbeat consiste básicamente en 5 pasos que en su mayoría deberán ser ejecutados y realizados de forma idéntica en cada equipo.
• Editar el fichero vi /etc/sysctl.conf de la siguiente forma:
net.ipv4.ip_forward = 1
• Verificar que los servicios necesarios estén ejecutándose
chkconfig –level 2345 heartbeat on
chkconfig –del ldirectord
• Editar el fichero de heartbeat /etc/ha.d/ha.cf de la siguiente forma en AMBOS nodos:
#/etc/ha.d/ha.cf content
debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
keepalive 2
deadtime 30
warntime 10
initdead 120
udpport 694 #si hay varios heartbeat es necesario editar el Puerto
bcast eth0 # Linux
auto_failback on #(This will failback to machine1 after it comes back)
ping 10.10.150.100 #(Your gateway IP)
apiauth ipfail gid=haclient uid=hacluster
node machine1.myhost.com
node machine2.myhost.com
• Editar el fichero /etc/ha.d/haresources al igual que el ha.cf idénticos en ambos nodos.
• Ahora debemos editar el fichero de seguridad que nos permitirá que el heartbeat se autentifique entre el nodo01 y nodo02 únicamente, también deben ser idénticos en ambos nodos.
Primero compruebe que todos los dominios tienen la opción ‘Correo para usuario inexistente’ definida a ‘Rechazar’ pero no a reenviar. Puede cambiar este ajuste para todos los dominios usando “Operaciones en Grupo” en la página “Dominios” del CP de Parallels Plesk Panel. La prestación ‘Rechazar correo para usuario inexistente’ está disponible a partir de Parallels Plesk Panel 7.5.3.
Asimismo, compruebe que todas las redes e IPs incluidas en la lista blanca son de su confianza.
Compruebe cuántos mensajes hay en la cola de Qmail con:
# /var/qmail/bin/qmail-qstat
messages in queue: 27645
messages in queue but not yet preprocessed: 82
Si la cola tiene demasiados mensajes, intente descubrir la procedencia del SPAM.
Si el correo está siendo enviado por un usuario autorizado pero no desde el script PHP, puede ejecutar el comando que aparece a continuación para descubrir el usuario que envió la mayoría de mensajes (desde Plesk 8). Tenga en cuenta que es necesario tener activada la opción ‘Autorización SMTP’ en el servidor para poder ver estos registros:
Esta muestra los remitentes y destinatarios de los mensajes. Si el mensaje incluye demasiados destinatarios, probablemente se tratará de SPAM. Ahora intente encontrar este mensaje en la cola por su ID #2996948:
# find /var/qmail/queue/mess/ -name 2996948
examine el mensaje y encuentre la primera línea “Recibido” para saber desde dónde se envió la primera vez, por ejemplo, si encuentra:
Significa que este mensaje fue enviado a través de algún CGI por el usuario con UID 10003. Usando este UID puede encontrar el dominio correspondiente:
# grep 10003 /etc/passwd
Si la línea ‘Recibido’ contiene un UID de un usuario ‘apache’ (por ejemplo “invoked by uid 48″) – significa que el SPAM fue enviado a través de algún script PHP. En este caso, puede intentar conocer el spammer usando la información de los correos spam (direcciones de/para, asunto o cualquier otro dato). Generalmente es muy difícil descubrir la fuente de SPAM. Si está completamente seguro de que en este momento hay algún script enviando SPAM (la cola crece rápidamente sin motivo aparente), puede usar el siguiente script para saber qué scripts PHP se están ejecutando en este momento:
También puede aplicar el artículo 1711, que describe el procedimiento para conocer desde qué dominios se está enviando el correo a través de scripts PHP.
Líneas recibidas como:
Received: (qmail 19622 invoked from network); 13 Sep 2005 17:52:36 +0700
Received: from external_domain.com (192.168.0.1)
significan que el mensaje ha sido aceptado y entregado a través de SMTP y que el remitente es un usuario de correo autorizado.
Hoy en día resulta muy importante tener nuestros equipos con la hora adecuada, tanto para saber a que hora suceden eventos, así como para simplemente enviar y/o recibir correo de forma adecuada.
Si se trata de un entorno laboral/empresarial esta actividad pasa a ser una norma, pues de esta forma estaremos seguros de los registros generados en los sitemas y de esta forma realizaremos seguimiento de forma acertada utilizando los registros del sistema.
Puede hallar una definición formal del protocolo NTP en: wikipedia
Instalamos y configuramos la parte cliente de NTP
Para cambiar la zona horaria en sistemas operativos basados en CentOS 5.4 es necesario validar que se encuentra instalado el paquete que nos permitirá establecer la zona horaria en la que nos encontramos, con el comando:
En caso que no esté instalado, proceda a instalarlo con el comando:
# yum install tzdata.noarch
Y luego proceda a configurar la zona horaria con el comando:
tzselect
Responde al asistente escogiendo tu zona horaria por ejemplo: América y luego Caracas.
Ahora bien, para crear un servidor NTP como un cliente de otro servidor NTP para que la hora se actualice automáticamente de forma periódica el procedimiento es el siguiente:
* Instalar el programa ntpdate
# yum install ntp.i386
* Agregas una tarea programada para que actualice la hora cada 4 horas:
# crontab -e
* Dentro de la edición del crontab agregas la siguiente línea:
0 */4 * * * /usr/sbin/ntpdate -u 2.pool.ntp.org
Instalamos y configuramos la parte servidor de NTP
* Se debe instalar el paquete ntpdate como fue indicado anteriormente
* Modificar archivo de configuración /etc/ntp.conf con los siguientes valores:
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default kod nomodify notrap nopeer noquery
#restrict -6 default kod nomodify notrap nopeer noquery
# Permit all access over the loopback interface. This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1
#restrict -6 ::1
# Hosts on local network are less restricted.
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 0.centos.pool.ntp.org
server 1.centos.pool.ntp.org
server 2.centos.pool.ntp.org
#broadcast 192.168.1.255 key 42 # broadcast server
#broadcastclient # broadcast client
#broadcast 224.0.1.1 key 42 # multicast server
#multicastclient 224.0.1.1 # multicast client
#manycastserver 239.255.254.254 # manycast server
#manycastclient 239.255.254.254 key 42 # manycast client
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
# Drift file. Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /var/lib/ntp/drift
# Key file containing the keys and key identifiers used when operating
# with symmetric key cryptography.
keys /etc/ntp/keys
# Specify the key identifiers which are trusted.
#trustedkey 4 8 42
# Specify the key identifier to use with the ntpdc utility.
#requestkey 8
# Specify the key identifier to use with the ntpq utility.
#controlkey 8
# Permisos que se asignara para cada servidor de tiempo.
# En los ejemplos, no se permite a las fuente consultar, ni
# modificar el servicio en el sistema ni enviar mensaje de
# registro.
restrict 0.centos.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 1.centos.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
restrict 2.centos.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
# Se Activa la difusion hacia los clientes
broadcastclient
* Iniciar el servicio con:
# service ntpd start
* Agregar el servicio para que se inicie de forma automática con el sistema:
# chkconfig ntpd on
* Finalmente permitir al firewall recibir solicitudes de ntp de nuestros clientes agregando al archivo: /etc/sysconfig/iptables la siguiente línea:
-A RH-Firewall-1-INPUT -s 192.168.1.0/24 -m state --state NEW -p udp --dport 123 -j ACCEPT
Antes de la línea:
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
* Reiniciamos el firewall:
# service iptables restart
Y listoooooooooo ya tenemos nuestro propio cliente y servidor de hora NTP ¡¡¡¡¡ Si teneis alguna duda, comentarla¡¡¡
42.zip es un archivo zip de 42.374 bytes, contiene 16 archivos zips que a su vez contienen otros 16 zips y así hasta 6 veces. Los 16 últimos zips contienen un archivo de 4,3 Gb cada uno. Si descomprimimos el archivo 42.zip de 42.374 bytes obtendriamos 4.5 Pb de datos descomprimidos.
16 x 4294967295 = 68.719.476.720 (68GB)
16 x 68719476720 = 1.099.511.627.520 (1TB)
16 x 1099511627520 = 17.592.186.040.320 (17TB)
16 x 17592186040320 = 281.474.976.645.120 (281TB)
16 x 281474976645120 = 4.503.599.626.321.920 (4,5PB)
Este tipo de archivos se denominan Zips de la muerte o Zips bomba y suelen usarse como herramienta para ataques DoS.
PD: hay que ver como una cosa tan pequeña te puede joder el servidor enterito 😀 , así que pequeños sysadmins tener muy definidas las reglas de cuotas de disco con sus respectivas alertas a vuestro email 😀 raiola manda y no el panda
