Richzendy.org

Normalmente es necesario reiniciar un servidor para que pueda reconocer al inicio los discos que se le han presentado desde una SAN, claro al iniciar el sistema operativo reescanea los dispositivos ( en mi caso unas tarjetas fiber channel que usan el driver qlaxxx ), el problema radica cuando se tiene que hacer esto en un servidor en plena producción… para resolver el problema se hace:

• Reescanear tus HBA’s qlogic:

[code="Bash'""]
#echo "scsi-qlascan" > /proc/scsi/driver-name/adapter-id
[/code]

En donde “driver-name” es el nombre del driver de tu tarjeta, en mi caso qlaxxx, pero puede ser ” qla2100/qla2200/qla2300″ y “adapter-id” es el número de instancia de tu HBA, en mi caso 0,1,2,3 así que las mando a re-escanear todas.

• Agregar el dispositivo:

Una vez hecho lo anterior, debemos obligar a que el sistema cree los dispositivos necesarios para poder montar el disco, para hacer esto usamos el siguiente comando:

[code="Bash'""]
# echo "scsi add-single-device 0 1 2 3" >/proc/scsi/scsi
[/code]

Debes reemplazar los números “0 1 2 3″ dependiendo de tu “Host Channel Id Lun“, según un tutorial que estaba siguiendo, esto se consigue haciendo un “dmesg | less” y buscando la información acerca de “Host Channel Id Lun”, yo no ví nada de esto en mi dmesg, así que probé usar un script que viene con el paquete fibreutils provisto por HP y que se debe conseguir con el cd que viene con tu servidor ( si tiene tarjetas de fibra ):

Dicho programa se llama lssd, así que lo ejecuto:

[code="Bash'""]
#/opt/hp/hp_fibreutils/lssd
sda 0,0,0,1 HP HSV210 5100
sdb 0,0,1,1 HP HSV210 5100
sdc 0,0,2,1 HP HSV210 5100
sdd 0,0,3,1 HP HSV210 5100
sde 2,0,0,1 HP HSV210 5100
sdf 2,0,1,1 HP HSV210 5100
sdg 2,0,2,1 HP HSV210 5100
sdh 2,0,3,1 HP HSV210 5100
sdi 0,0,0,2 HP HSV210 5100
sdj 0,0,1,2 HP HSV210 5100
sdk 0,0,2,2 HP HSV210 5100
sdl 0,0,3,2 HP HSV210 5100
sdm 2,0,0,2 HP HSV210 5100
sdn 2,0,1,2 HP HSV210 5100
sdo 2,0,2,2 HP HSV210 5100
sdp 2,0,3,2 HP HSV210 5100
[/code]

Pruebo agregar el dispositivo para sdb, al cual le corresponde la númeración 0,0,1,1

[code="Bash'""]
# echo "scsi add-single-device 0 0 1 1" >/proc/scsi/scsi
[/code]

Y aplico un fdisk -l y ya veo el nuevo disco ( tenía ya otro montado ), reviso el directorio /dev/mapper/ y veo un nuevo dispositivo creado ( mpath1p1 )

De ahora en adelande ya puedes usar el comando mount para montar dicho dispositivo en el punto de montaje que desees.

Ojo si el disco SAN fue creado recientemente, podrás verlo como dispositivo, pero es como tener un disco en blanco, por lo cual no podrás montarlo a menos que le crees una partición ( con fdisk o cfdisk ) y le crees un sistema de archivos ( mkfs ).

Espero les sirva de ayuda, pueden leer como referencia al igual que yo:

http://sysdigg.blogspot.com/2008/03/add-san-disks-on-rhel-without-reboot.html

Supongo que debe haber una alternativa mejor sin tener que usar el programa lssd ( propietario de hp ) si alguien la sabe, le agradezco hacermela saber

Ayer tenía la tarea de hacer una modificación en un archivo de configuración ( con privilegios de root ) en una serie de máquinas clientes con GNU/Linux, al preguntar a un grupo de amigos me dieron las siguientes soluciones:

1. Usar claves compartidas de ssh

Ajá, esto seria válido si ya tuviera las llaves compartidas,  en este caso como no las tengo, tendría que entrar a cada máquina y hacer la configuración, lo cual no es una opción no viable ya que eso es justo lo que quiero evitar.

2. Usar la opción sudo -S de la siguiente manera: echo “password” | sudo -S

Tengo un script que puede ejecutarse automáticamente en cada máquina, pero este se ejecuta con privilegios de usuario, dicho script puede ser modificado y cargado masivamente en cada máquina de la red vía rsync, el detalle con esta solución es que en la distribución cliente los usuarios no están por defecto en el grupo que pueden hacer sudo, por lo cual tendría que configurar /etc/sudoers máquina a máquina para poder implementar esta opción, con lo cual esto ya no es viable.

---

Viendo ya que la solución debería investigarla por mis medios, pensé en usar la librería:

http://search.cpan.org/~bnegrao/Net-SSH-Expect-1.09/lib/Net/SSH/Expect.pod

Que ya he usado con anterioridad  para otras cosas y hacerme un scriptcito en perl, pero de verdad me daba fastidio y pereza instalarla vía CPAN, investigando un poco más di con la solución mas perezosa usando el programa expect, acá hay un ejemplo de como ( el cual use ):

http://modp.com/wiki/sshpasswords

Expect no se usa necesariamente para hacer login remoto ssh o scp, realmente es un programa hecho en tcl que permite controlar programas en consola o linea de comandos ( CLI ) que tienen una interfase interactiva, por ejemplo esos programas que te preguntan opciones y opciones para poder realizar alguna función y requieren una intervención vía teclado para contestarlas, bueno expect bien configurado puede ser usado para responder todas esas preguntas de forma automática.

Sin más preámbulo acá está el cochino script que realice, cabe destacar que no tenía idea de cuantas máquinas cliente existían en la red ( aunque más o menos calculo que podrían ser unas 100 al menos ) ni de sus direcciones ip ( el cliente tiene eso registrado, pero me dio fastidio pedírselo):

#!/bin/bash
for n in {1..9} ; do
for i in {100..140} ; do

expect -c “set timeout 10; eval spawn scp /tmp/rc.local root@192.168.$n.$i:/etc/ ; expect ‘yes: $’; send yes\n ; \ expect ‘password: $’; send algunpassword\n ; expect ‘$ $’”

done
done

La linea realmente importante es la que empieza con el comando “expect” precisamente y vamos a explicar sus opciones:

set timeout 10 : Esta opción permite configurar 10 segundos de timeout en caso de no conseguir una respuesta.

eval spawn scp /tmp/rc.local root@192.168.$n.$i:/etc/ :

Esta opción es la que ejecuta realmente el scp, al final los últimos 2 octetos de la dirección ip, son variables, provistas por los for de arriba.

expect ‘yes: $’; send yes\n : Esas 2 opciones pueden ser consideradas una sola, y es que como en muchas de esas máquinas clientes nunca se ha conectado vía ssh, entonces se debe aceptar primero la clave RSA del ssh, entonces  “expect ‘yes: $” espera que se presente una linea que diga “yes:” y “send yes\n”  envía como respuesta yes y aplica un enter luego ( \n).

expect ‘password: $’; send algunpassword\n : Como en la anterior, esto puede ser considerado una sola instrucción y es muy similar a la anterior, se espera la cadena “password:” y cuando se reciba, se contesta con  “send algunpassword\n” enviando la password de la sesión e iniciando la transferencia.

expect ‘$ $’ : ya al final coloque esta opción la cual simplemente espera que se entregue un prompt para salir, realmente no se si era necesaria pero sin embargo la coloque por si acaso

Espero que le llegue a servir a alguno, como me sirvio a mi, en menos de 20 minutos ya tenía todos las máquinas cliente plenamente configuradas , tal vez hayan otras opciones incluso más elaboradas, pero me pareció buena esta debido a su sencillez, solo basta con instalar el paquete expect, el cual está en los repositorios de la mayoría de las distribuciones de GNU/Linux.

Por cuestiones de seguridad no me preocupe mucho, debido que todas esas máquinas están en una red local sin acceso a internet y los clientes son prácticamente terminales tontos en donde el usuario tiene perfiles de desktop muy bien delimitados y no tienen acceso a tty, además ya scp cifra la comunicación en la transferencia, incluso en la sesión de login.

Es un caso que debido a diversos motivos podría darse, sin embargo aparte de revisar tus logs, la cola de referidos y usar mailq de vez en cuando para ver que es lo que está pasando, para saber si tu servidor de correo es considerado spam o algún otro servidor ( del cual no tienes acceso administrativo o a los logs ) puedes usar este par de herramientas web, las cuales revisan entre las diversas listas negras ( blacklist ) si tu servidor esta rayado ( Disculpen el Venezolanismo ).

La primera viene del sitio web de openrbl, para citar un ejemplo, vamos a revisar el MTA de cantv.net ( relay.cantv.net ):

http://openrbl.org/client/#200.44.32.36

Esta herramienta web, verifica en diferentes listas negras de una vez por lo cual resulta muy completa esta búsqueda, al momento el relay de cantv aparece positivamente en lista negra de Fiveten.

La segunda herramienta, más que todo es el único sitio realmente importante que openrbl no revisa y es la lista de trend micro ( la cual es muy usada ) y volvemos a usar el MTA de cantv.net como conejillo de indias:

http://mail-abuse.com/cgi-bin/lookup?ip_address=200.44.32.36

En este caso, el relay de cantv.net paso la prueba y es considerado limpio.

El proceso para eliminar tu servidor de alguna de esas listas en algunos casos es tedioso como por ejemplo con la gente de trendmicro, así que procura revisar tu servidor frecuentemente y estar al tanto de la cuenta postmaster de tu dominio de correo.

Si quieres saber que crontabs en total tienes instalados en tu GNU/Linux, ejecuta en consola como root:

for i in `cut -d : -f 1 /etc/passwd` ; do crontab -l -u $i ; done

No, no, no vamos a actualizar nuestro fedora usando apt , simplemente mucha gente cree que al llegar una nueva versión de Fedora debemos actualizar usando el dvd o lo que es peor aún, “reinstalar”, pero el caso es grave cuando se tiene un servidor desde al cual solo se tiene acceso remoto ( aunque también podemos actualizar nuestro desktop de esta manera, de hecho yo lo hice así ), la solución es actualizarlo online como lo actualizamos? simple, sigue leyendo:

• Procura tener tu FC6 lo más actualizado posible.

• Procura tener suficiente espacio en disco ( al menos 3 GB si usas X)

• Primero actualizamos las notas de release:

rpm -Uvh http://mirror.internode.on.net/pub/fedora/linux/releases/7/Fedora/i386/os/Fedora/fedora-release-notes-7.0.0-1.noarch.rpm

• Luego actualizamos el fedora-release:

rpm -Uvh http://mirror.internode.on.net/pub/fedora/linux/releases/7/Fedora/i386/os/Fedora/fedora-release-7-3.noarch.rpm

• Si tenemos otros repositorios en nuestra configuración de yum, actualicemos los archivos para que apunten a servidores con paquetes de F7 o de plano desactivalos, para livna es fácil ya que solo actualizamos el rpm que configura el repo:

rpm -Uvh  http://livna-dl.reloumirrors.net/fedora/7/i386/livna-release-7-2.noarch.rpm

• Por ultimo hacemos un upgrade:

yum upgrade

En esta parte es muy probable que algún paquete exótico que hayas instalado de algún repositorio tb exótico te de problemas de dependencias, si es así y el paquete no es necesario ve pensando seriamente en desistalarlo o en buscar la actualización del paquete o del archivo de configuración del repo original para dicho paquete.

Si estamos actualizando un servidor y que no tiene X ( entorno gráfico ) la actualización tarda realmente poco ( no me responsabilizo si tu servidor no arranca luego de esto, así que usa esto bajo tu propio riesgo )

• Ahora es ir por una buena taza de café o a ver tv, ya que esto va a tardar

NOTA: probablemente te toque ejecutar en una consola ( tty ) el comando system-config-display luego del upgrade y reiniciar, al menos a mi luego de reiniciar no me aparecía el panel de gnome, ni los iconos del escritorio, luego de ejecutar el comando ( y cambiarme la resolución) todo funciono adecuadamente.

Actualización de la nota anterior: Luego me di cuenta que algo en mi configuración de usuario de gnome era lo que estaba mal ( el usuario root si entraba sin problemas ), lo solucione momentáneamente con un :

desde una tty externa y sin estar logueado en entorno gráfico:

mv  ~/.gnome* /tmp

( luego reviso que estaba mal en el profile de gnome )

tatica y yo hemos preparado un HowTo de como configurar mod_security de apache en forma fácil, sencilla y con unas buenas reglas diseñadas por terceros fácilmente actualizables.

Todo comenzó un día hablando con ella de su blog y la necesidad de tenerlo un poco asegurado, yo ya había hecho los pasos del HowTo hace un tiempo en mi blog cuando jaws aun no había implementado efectivamente la seguridad en los comentarios de los blogs y los (***modo censura*** Muchas Vulgaridades y recordatorios nada agradables para sus progenitoras ***modo censura***) spamers me tenían full el blog debido a comentarios que entraban vía el trackback a pesar de tenerlo deshabilitado… a mi me funciono en aquel entonces, ya luego actualice mi blog a una nueva versión de jaws y ahora esta usando akismet, asi que no es tan necesario para evitar el spam en los comentarios.

Asíque implementamos lo mismo en su blog y con buenos resultados, pero esta vez si documentamos entre los 2 todos los pasos.

Quien desee pasar a dar un vistazo el link del HowTo esta en esta dirección desde mi dominio:

http://richzendy.org/docs/mod_security+How_To/index.html

tatica también hara su parte y colocara una copia de este HowTo en su website.