Multipath es una herramienta que permite administrar los diferentes path's que existen hacia un LUN en un ambiente de SAN.
El Device Mapper de Linux permite agrupar todos los path's que un servidor ver hacia un LUN específico bajo un solo device file (/dev/mapper/mpathn por omisión) de manera que la administración se simplifique y dando la felxibilidad de utilizar diferentes políticas de balanceo de carga además de la alta disponibilidad que provee la arquitectura.
Requisitos
Para configurar multipath se debe tener instalado el paquete device-mapper-multipath. Además de esto, el servidor tiene que estar conectado a la SAN y sus tarjetas de fibra deben estar funcionando correctamente.
Iniciando multipath por primera vez
Cuando se va a iniciar multipath por primera vez, se deben realizar los siguientes pasos:
Verificación del archivo /etc/multipath.conf
Este es el archivo de configuración del demonio multipathd. La configuración que viene de fábrica es aceptable para la mayorí de los ambientes y solo debemos comentar las siguientes lineas:
blacklist {
devnode "*"
}
Con esto le decimos al demonio multipathd que no excluya nada a la hora de verificar los path's hacia los LUN's presentados.
Inicio del demonio multipathd
Para iniciar el demonio mulipathd ejecutamos el siguiente comando:
# /etc/init.d/multipathd
y verificamos que salga el mensaje [ OK ]
En el syslog (/var/log/messages) pueden aparecer los siguientes mensajes:
multipathd: cannot open /sbin/dasd_id : No such file or directory
multipathd: cannot open /sbin/gnbd_import : No such file or directory
multipathd: [copy.c] cannot open /sbin/dasd_id
multipathd: cannot copy /sbin/dasd_id in ramfs : No such file or directory multipathd: [copy.c] cannot open /sbin/gnbd_import
multipathd: cannot copy /sbin/gnbd_import in ramfs : No such file or directory
No representan ningún problema ya que son módulos que no estamos utilizando.
Para asegurarnos de que el demonio se iniciará cada vez que el servidor arranque, utilizanos el siguiente comando:
# chkconfig multipathd on
Descubrimiento de LUN's
Después de que se le hayan presentado los LUN's correspondientes al servidor en cualquiera de las cabinas se debe forzar a este a descubrir los LUN's.
Para descubirir LUN's sin reiniciar el servidor, se corre el siguiente comando:
# echo 1 > /sys/class/fc_host/hostn/issue_lip
El valor de n depende de cuantas tarjetas de fibra se tengan. Si se tienen 2, n tendrá los valores 0 y 1, por lo tanto se debe correr el comando tantas veces como tarjetas de fibra tengamos, variando el valor de n respectivamente.
En el syslog deben aparecer los discos descubiertos y el device mapper debe crear el device file correspondiente, como es el primer LUN que se está asignando, el nombre del device file debe ser /dev/mapper/mpath0
Para verificar que el device mapper ha configurado el multipath correctamente, se ejecutar el comando
# multipath -ll
y el resultado debe ser parecido a este:
# multipath -ll
mpath0 (360060e80141a230000011a2300000090) dm-7 HP,OPEN-V
[size=100G][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=4][active]
\_ 0:0:0:16384 sda 8:0 [active][ready]
\_ 0:0:1:16384 sdb 8:16 [active][ready]
\_ 1:0:0:16384 sdc 8:32 [active][ready]
\_ 1:0:1:16384 sdd 8:48 [active][ready]
De ahora en adelante el device file /dev/mapper/mpath0 puede ser utilizado como un disco más, por ejemplo, se puede hacer pvcreate sobre él para utilizarlo con LVM.
Desasignando LUN's
Si por alguna razón se deben desasignar los LUN's que a los cuales referencia /dev/mapper/mpath0, lo primero que hay que hacer es destruir toda la arquitectura de filesystems que exista sobre el device file. Una ves que esté "libre" se procede a borrar el device file de la siguiente manera:
# multipath -f /dev/mapper/mpath0
Luego se procede a "borrar" los paths hace el LUN
# echo 1 > /sys/block/sd?/device/delete
Donde “?” indica la letra correspondiente al “disco” por ejemplo sda.
Tuesday, July 28, 2009
Tuesday, June 23, 2009
Obtener el WWN de una HBA en RHEL 5
Esto lo hice con unas tarjetas QLogic. Primero hay que obtener el PCI ID
# lspci|grep Q
10:00.0 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03)
10:00.1 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03)
Con los PCI ID's hago lo siguiente:
# cat /sys/bus/pci/drivers/qla2xxx/*<PCI_ID>/host*/fc_host*/port_name
en este caso sería:
# cat /sys/bus/pci/drivers/qla2xxx/*10:00.0/host*/fc_host*/port_name
Actualización (2009-07-20)
Utilizando el filesystem /sys podemos acortar las cosas de la siguiente manera:
Para la primera tarjeta de fibra colocamos
# cat /sys/class/fc_host/host0/port_name
Para la segunda
# cat /sys/class/fc_host/host1/port_name
y así con las demás HBA's (si existen).
# lspci|grep Q
10:00.0 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03)
10:00.1 Fibre Channel: QLogic Corp. ISP2432-based 4Gb Fibre Channel to PCI Express HBA (rev 03)
Con los PCI ID's hago lo siguiente:
# cat /sys/bus/pci/drivers/qla2xxx/*<PCI_ID>/host*/fc_host*/port_name
en este caso sería:
# cat /sys/bus/pci/drivers/qla2xxx/*10:00.0/host*/fc_host*/port_name
Actualización (2009-07-20)
Utilizando el filesystem /sys podemos acortar las cosas de la siguiente manera:
Para la primera tarjeta de fibra colocamos
# cat /sys/class/fc_host/host0/port_name
Para la segunda
# cat /sys/class/fc_host/host1/port_name
y así con las demás HBA's (si existen).
Wednesday, April 22, 2009
Alfabeto fonético aeronáutico en IT
Si has trabajado en IT, seguramente has tenido que decir muchas veces códigos, nombres de usuarios, seriales, part numbers, etc. utilzando el teléfono.
Seguramente también lo has hecho en ambientes de mucho ruido (data centers por ejemplo) y no es una tarea fácil, más aún sabiendo que el otro extremo debe recibir, exactamente, lo que estás diciendo.
A pesar de esto he visto que no le prestamos atención a este tipo de transmisión de la información y nos nos aseguramos que las cosas lleguen correctamente a su destino. Es común escuchar los ¿qué? ¿cómo? repite, no te escucho.
También es común escuchar a personas deletreando frases o códigos y parándose a pensar en qué palabra pueden decir que comience con la letra requerida..... para la "s" puede ser.. Sevilla, Soria, Salamanca.... y así cualquier cosa que se les ocurra (o no).
Como siempre digo, la rueda no hay que inventarla, hay que usarla y si, ya alguien ha inventado un método de comunicación para ambientes con mucho ruido y donde hay que asegurarse de que el otro extremo recibe la información correcta. Se llama Alfabeto fonético aeronáutico y copio textualmente de wikipedia:
"Se utiliza para transmitir por vía oral cualquier tipo de información pero principalmente cuando se trata números o términos en los que es vital su correcta escritura y entendimiento, a pesar de ambigüedades o dificultades idiomáticas."
"Por medio de un acuerdo internacional entre los países miembros de OACI se decidió crear un alfabeto fonético para uso universal en radio transmisiones internacionales que está basado en el abecedario inglés (idioma acordado para uso aeronáutico internacional) que tomara el lugar de los alfabetos fonéticos existentes hasta esas fechas. Además de ser usado en transmisiones aeronáuticas reguladas por OACI (civiles) es usado en transmisiones de carácter militar, es el alfabeto estándar de la OTAN, y radioaficionados de todo el mundo."
Es decir que no es nada nuevo, no estamos decubriendo el agua tibia y si lo usa la OTAN y los radioaficionados, debe ser que funciona.
Entonces, vamos a usarlo, que seguro la comunicación es mucho más fluida.
Dejo el enlace (en español) para ir aprendiendo la letras, los números y cómo transmitirlos.
http://es.wikipedia.org/wiki/Alfabeto_fonético_de_la_OTAN
Seguramente también lo has hecho en ambientes de mucho ruido (data centers por ejemplo) y no es una tarea fácil, más aún sabiendo que el otro extremo debe recibir, exactamente, lo que estás diciendo.
A pesar de esto he visto que no le prestamos atención a este tipo de transmisión de la información y nos nos aseguramos que las cosas lleguen correctamente a su destino. Es común escuchar los ¿qué? ¿cómo? repite, no te escucho.
También es común escuchar a personas deletreando frases o códigos y parándose a pensar en qué palabra pueden decir que comience con la letra requerida..... para la "s" puede ser.. Sevilla, Soria, Salamanca.... y así cualquier cosa que se les ocurra (o no).
Como siempre digo, la rueda no hay que inventarla, hay que usarla y si, ya alguien ha inventado un método de comunicación para ambientes con mucho ruido y donde hay que asegurarse de que el otro extremo recibe la información correcta. Se llama Alfabeto fonético aeronáutico y copio textualmente de wikipedia:
"Se utiliza para transmitir por vía oral cualquier tipo de información pero principalmente cuando se trata números o términos en los que es vital su correcta escritura y entendimiento, a pesar de ambigüedades o dificultades idiomáticas."
"Por medio de un acuerdo internacional entre los países miembros de OACI se decidió crear un alfabeto fonético para uso universal en radio transmisiones internacionales que está basado en el abecedario inglés (idioma acordado para uso aeronáutico internacional) que tomara el lugar de los alfabetos fonéticos existentes hasta esas fechas. Además de ser usado en transmisiones aeronáuticas reguladas por OACI (civiles) es usado en transmisiones de carácter militar, es el alfabeto estándar de la OTAN, y radioaficionados de todo el mundo."
Es decir que no es nada nuevo, no estamos decubriendo el agua tibia y si lo usa la OTAN y los radioaficionados, debe ser que funciona.
Entonces, vamos a usarlo, que seguro la comunicación es mucho más fluida.
Dejo el enlace (en español) para ir aprendiendo la letras, los números y cómo transmitirlos.
http://es.wikipedia.org/wiki/Alfabeto_fonético_de_la_OTAN
Thursday, March 26, 2009
Configurando mailx para leer buzones en formato maildir
*** Actualización (28 de Junio de 2015) ***
Cuando digo mailx quiero decir heirloom-mailx. bsd-mailx no soporta buzones en formato maildir.
****
En un post anterior expliqué cómo configurar procmail para trabajar con buzones en formato maildir, ahora es necesario poder leer los correos. En este post explico cómo configurar mailx para que lea buzones en formato maildir.
Es muy fácil, solo definir la variable de ambiente MAIL para que contenga la "raiz" de la estructura de directorios maildir. Un ejemplo, asumamos que tengo mi procmail configurado para dejar los correos en formato maildir en la siguiente ubicación:
/var/spool/mail/usuarios/ricardo
Debajo de esta ruta se encuentran los directorios new, cur y tmp, entonces, la variable mail debe ser definida así:
MAIL="/var/spool/mail/usuarios/ricardo/"
Muy importante, nótese el "/" al final de la ruta
La variable puede ser definida de manera parametrizada también (y de manera más conveniente) como
MAIL="/var/spool/mail/usuarios/$LOGNAME/"
Cuando digo mailx quiero decir heirloom-mailx. bsd-mailx no soporta buzones en formato maildir.
****
En un post anterior expliqué cómo configurar procmail para trabajar con buzones en formato maildir, ahora es necesario poder leer los correos. En este post explico cómo configurar mailx para que lea buzones en formato maildir.
Es muy fácil, solo definir la variable de ambiente MAIL para que contenga la "raiz" de la estructura de directorios maildir. Un ejemplo, asumamos que tengo mi procmail configurado para dejar los correos en formato maildir en la siguiente ubicación:
/var/spool/mail/usuarios/ricardo
Debajo de esta ruta se encuentran los directorios new, cur y tmp, entonces, la variable mail debe ser definida así:
MAIL="/var/spool/mail/usuarios/ricardo/"
Muy importante, nótese el "/" al final de la ruta
La variable puede ser definida de manera parametrizada también (y de manera más conveniente) como
MAIL="/var/spool/mail/usuarios/$LOGNAME/"
Configurando procmail para que use Maildir
No voy a detallar mucho lo que es procmail ni en lo que es maildir ni si es mejor que mailbox. Este post, simplemente trata de explicar, de manera rápida, cómo configurar procmail para que trabaje con maildir. Más que todo, como una "chuleta" para mi y si le sirve a alguien, muy bien.
Simplemente, colocar en el ~/.procmailrc las siguientes líneas:
MAILDIR=/var/spool/mail/usuarios/ricardo/
DEFAULT=$MAILDIR
Esto es solo un ejemplo, lo importante aquí es que, el path que esté en la variable MAILDIR termine en "/"
Notas importantes:
Si se va a automatizar esto y el archivo .procmailrc se va a colocar en el /etc/skel (para que sea copiado a cada usuario que se crea de manera automática), es mejor definir la variable MAILDIR de la siguiente manera:
MAILDIR="/var/spool/mail/usuarios/$LOGNAME/"
Espero que les sirva.
Simplemente, colocar en el ~/.procmailrc las siguientes líneas:
MAILDIR=/var/spool/mail/usuarios/ricardo/
DEFAULT=$MAILDIR
Esto es solo un ejemplo, lo importante aquí es que, el path que esté en la variable MAILDIR termine en "/"
Notas importantes:
- MAILDIR debe existir, procmail se saldrá con un error si no existe.
- La estructura de directorios (new, cur, tmp) la creará procmail si no existe.
- No creo que sea buena idea colocar esto "system wide" para que el correo de root siga estando en /var/spool/mail/root (o donde sea que se haya configurado que deba estar el correo de root).
Si se va a automatizar esto y el archivo .procmailrc se va a colocar en el /etc/skel (para que sea copiado a cada usuario que se crea de manera automática), es mejor definir la variable MAILDIR de la siguiente manera:
MAILDIR="/var/spool/mail/usuarios/$LOGNAME/"
Espero que les sirva.
Thursday, March 12, 2009
Modem usb Novatel Ovation MC950D de Movistar en mandriva Linux 2008.0/2009.0
En la empresa en la que trabajo nos dan un modem usb para hacer las guardias y tener un poco de flexibilidad, léase, no quedarse amarrado en la casa los fines de semana de guardia. Eso está muy bien pero..... el software que te entregan solo funciona en windows.
Buscando en internet y haciendo varias pruebas he podido hacer que el modem usb funcione en Linux y esto es lo que he hecho.
El modem
Es un modem Ovation MC950D de Novatel Wireless que es el que da Movistar en España (a la fecha de publicación de este post).
Puede funcionar como almacén de datos (como un cdrom usb) o como modem usb
Reconociendo el modem en Linux
Cuando se conecta el modem al puerto usb, el sistema operativo lo ve como un cdrom usb. Trabajando de este modo no nos sirve por lo que debemos hacer que se "transforme" en modem usb. Para esto, nos fijamos el nombre del cdrom (sr0 si es el primer cdrom que el kernel detecta) y ejecutamos lo siguiente:
# eject /dev/sr0
En el /var/log/messages veremos como se "desconecta" el "cdrom" y se conecta otro dispositivo usb. Lo que ha pasado es que el modem ya no va a trabajar como almacén de datos, ahora trabajará como modem usb.
Si hacemos:
# lsusb
veremos esto
Bus 001 Device 009: ID 1410:4400
El vendorID es 1410 y el productID es 4400. Si el productID no es 4400 es porque todavía está trabajando como almacén de datos y algo hicimos mal.
Ya con el productID correcto cargamos el módulo usbserial se la siguiente manera:
modprobe usbserial vendor=0x1410 product=0x4400
y deberíamos obtener unas líneas como estas en el /var/log/messages
usbserial_generic 1-1:1.0: generic converter detected
usb 1-1: generic converter now attached to ttyUSB0
usbserial_generic 1-1:1.1: generic converter detected
usb 1-1: generic converter now attached to ttyUSB1
usbserial_generic 1-1:1.2: generic converter detected
usb 1-1: generic converter now attached to ttyUSB2
usbserial_generic 1-1:1.3: generic converter detected
usb 1-1: generic converter now attached to ttyUSB3
Ya tenemos el modem reconocido y configurado como tal en Linux, nos queda configurar algún programa que sirva de dialer, en este caso mostraré la configuración de wvdial.
Configurando wvdial
Para efectos de este post, usaré el PIN 1234.
Mi /etc/wvdial.conf está así
[Dialer Defaults]
Phone = *99***1#
Username = MOVISTAR
Password = MOVISTAR
Dial Command = ATDT
Stupid Mode = 1
[Dialer movistar]
Phone = *99***1#
Modem = /dev/ttyUSB0
Baud = 460800
Init1 = AT+CPIN=1234
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 =AT+CGDCONT=1,"IP","movistar.es";
ISDN = 0
Modem Type = USB Modem
Auto Reconnect = off
Auto DNS = off
[Dialer re-movistar]
Phone = *99***1#
Modem = /dev/ttyUSB0
Baud = 460800
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 =AT+CGDCONT=1,"IP","movistar.es";
ISDN = 0
Modem Type = USB Modem
Auto Reconnect = off
Auto DNS = off
Solo voy a explicar las secciones relevantes, si necesitas más información, man wvdial.conf.
Para empezar, tengo 3 secciones; Default, movistar y re-movistar.
En Default coloqué los parámetros comunes, en movistar los parámetros específicos para conectarme a movistar y en re-movistar solo eliminé el parámetro del PIN y explico. Aveces la conexión se cae (no se por qué) y el wvdial intentaba reconectarse y volvía a marcar el PIN, esto producía un error puesto que ya se había metido el PIN con anterioridad, por lo tanto coloqué el Auto Reconnect en off y cuando se cae la comunicación utilizo la sección re-movistar para que no marque el PIN nuevamente.
Otra cosa importante es lo de los servidores DNS, por alguna razón en varias ocaciones me daba el 10.11.12.13 que no son servidores DNS de movistar, así que le coloqué el Auto DNS en off y en el /etc/resolv.conf coloqué a mano los dns's que trae el escritorio movistar para windows:
194.179.1.100
194.179.1.101
Además de esto, hay que decirle a pppd que no agarre los servidores dns cuando establezca la conexión, entonces, en el /etc/ppp/options, verificar que no está la opción usepeerdns. También verificar que en el /etc/ppp/peer/wvdial tampoco aparece esa opción.
Conectándose
Para conectarnos a internet solo hay que ejecutar
# wvdial movistar
y mirar que nos den una IP.
Si tienes otra conexión ya configurada (ethernet, wifi) seguro ya tendrás una ruta por default. Como esto lo hago ocasionalmente, no me importa borrar esa ruta y colocar a mano como default gatway al otro extremo de la conexión ppp.
Para terminar la conexión, simplemente Ctrl+c en el mismo terminal donde ejecutamos wvdial.
Esto está muy crudo, se puede automatizar y todo eso pero no es el objetivo de este post ;)
Si la conexión se cae, usa el apartado re-movistar para que no vuelva a colocar el PIN.
Buscando en internet y haciendo varias pruebas he podido hacer que el modem usb funcione en Linux y esto es lo que he hecho.
El modem
Es un modem Ovation MC950D de Novatel Wireless que es el que da Movistar en España (a la fecha de publicación de este post).
Puede funcionar como almacén de datos (como un cdrom usb) o como modem usb
Reconociendo el modem en Linux
Cuando se conecta el modem al puerto usb, el sistema operativo lo ve como un cdrom usb. Trabajando de este modo no nos sirve por lo que debemos hacer que se "transforme" en modem usb. Para esto, nos fijamos el nombre del cdrom (sr0 si es el primer cdrom que el kernel detecta) y ejecutamos lo siguiente:
# eject /dev/sr0
En el /var/log/messages veremos como se "desconecta" el "cdrom" y se conecta otro dispositivo usb. Lo que ha pasado es que el modem ya no va a trabajar como almacén de datos, ahora trabajará como modem usb.
Si hacemos:
# lsusb
veremos esto
Bus 001 Device 009: ID 1410:4400
El vendorID es 1410 y el productID es 4400. Si el productID no es 4400 es porque todavía está trabajando como almacén de datos y algo hicimos mal.
Ya con el productID correcto cargamos el módulo usbserial se la siguiente manera:
modprobe usbserial vendor=0x1410 product=0x4400
y deberíamos obtener unas líneas como estas en el /var/log/messages
usbserial_generic 1-1:1.0: generic converter detected
usb 1-1: generic converter now attached to ttyUSB0
usbserial_generic 1-1:1.1: generic converter detected
usb 1-1: generic converter now attached to ttyUSB1
usbserial_generic 1-1:1.2: generic converter detected
usb 1-1: generic converter now attached to ttyUSB2
usbserial_generic 1-1:1.3: generic converter detected
usb 1-1: generic converter now attached to ttyUSB3
Ya tenemos el modem reconocido y configurado como tal en Linux, nos queda configurar algún programa que sirva de dialer, en este caso mostraré la configuración de wvdial.
Configurando wvdial
Para efectos de este post, usaré el PIN 1234.
Mi /etc/wvdial.conf está así
[Dialer Defaults]
Phone = *99***1#
Username = MOVISTAR
Password = MOVISTAR
Dial Command = ATDT
Stupid Mode = 1
[Dialer movistar]
Phone = *99***1#
Modem = /dev/ttyUSB0
Baud = 460800
Init1 = AT+CPIN=1234
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 =AT+CGDCONT=1,"IP","movistar.es";
ISDN = 0
Modem Type = USB Modem
Auto Reconnect = off
Auto DNS = off
[Dialer re-movistar]
Phone = *99***1#
Modem = /dev/ttyUSB0
Baud = 460800
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 =AT+CGDCONT=1,"IP","movistar.es";
ISDN = 0
Modem Type = USB Modem
Auto Reconnect = off
Auto DNS = off
Solo voy a explicar las secciones relevantes, si necesitas más información, man wvdial.conf.
Para empezar, tengo 3 secciones; Default, movistar y re-movistar.
En Default coloqué los parámetros comunes, en movistar los parámetros específicos para conectarme a movistar y en re-movistar solo eliminé el parámetro del PIN y explico. Aveces la conexión se cae (no se por qué) y el wvdial intentaba reconectarse y volvía a marcar el PIN, esto producía un error puesto que ya se había metido el PIN con anterioridad, por lo tanto coloqué el Auto Reconnect en off y cuando se cae la comunicación utilizo la sección re-movistar para que no marque el PIN nuevamente.
Otra cosa importante es lo de los servidores DNS, por alguna razón en varias ocaciones me daba el 10.11.12.13 que no son servidores DNS de movistar, así que le coloqué el Auto DNS en off y en el /etc/resolv.conf coloqué a mano los dns's que trae el escritorio movistar para windows:
194.179.1.100
194.179.1.101
Además de esto, hay que decirle a pppd que no agarre los servidores dns cuando establezca la conexión, entonces, en el /etc/ppp/options, verificar que no está la opción usepeerdns. También verificar que en el /etc/ppp/peer/wvdial tampoco aparece esa opción.
Conectándose
Para conectarnos a internet solo hay que ejecutar
# wvdial movistar
y mirar que nos den una IP.
Si tienes otra conexión ya configurada (ethernet, wifi) seguro ya tendrás una ruta por default. Como esto lo hago ocasionalmente, no me importa borrar esa ruta y colocar a mano como default gatway al otro extremo de la conexión ppp.
Para terminar la conexión, simplemente Ctrl+c en el mismo terminal donde ejecutamos wvdial.
Esto está muy crudo, se puede automatizar y todo eso pero no es el objetivo de este post ;)
Si la conexión se cae, usa el apartado re-movistar para que no vuelva a colocar el PIN.
Thursday, March 5, 2009
Administradores de UNIX trabajando en windows
Tengo varios años siendo administrador de sistemas UNIX y siempre me he hecho esta pregunta, ¿por qué tengo que trabajar con una computadora que tiene windows instalado si soy un administrador de UNIX?
Lo voy a poner de esta manera, ¿cuántos administradores de windows tienen en su estación de trabajo Linux (por ejemplo) ? ¿Por qué ellos si pueden trabajar con el sistema operativo que administran y nosotros no?
Ojo, no tengo nada en contra de los administradores de windows, de hecho, la gran mayoría simplemente se "encontró" con esa estación de trabajo que usa a diario.. pero... las preguntas siguen siendo válidas..... y siguen sin tener respuesta.
En ninguna entrevista de trabajo para un puesto de administrador de UNIX me han preguntado si se utilizar windows, ¿es que lo pre-suponen?, ¿por qué?
Hay quienes "intentan" responder a esta situación diciendo que las herramientas "corporativas" solo corren en windows.... muy bién, si son tan miopes que se tienen que amarrar a una herramienta en vez de usar una tecnología, al menos denme una herramienta adecuada para realizar mi trabajo, es decir, denme un equipo en el que pueda usar las herramientas "corporativas" y otro en el que pueda tener Linux (o cualquier otro unix) o denme una máquina lo suficientemente "poderosa" (solo pido 2 GB de RAM para montar una máquina virtual) para poder tener ambos sistemas operativos corriendo.
Ahora, alguien que lea esto puede pensar que es exactamente lo mismo trabajar desde windows que desde Linux, total, los servidores se acceden de manera remota y con tener un emulador de terminal es suficiente. Muy bien, eso te sirve si eres un administrador poco proficiente pero, si te gusta hacer script's, si quieres hacer pruebas, si quieres tener un ambiente "similar" (sin duda, Linux es "más similar" a cualquier *NIX que windows) al de los servidores, tu elección es tener Linux en tu estación de trabajo.
Ser un administrador de sistemas no es solo tirar algunos comandos y ya está, es pensar, evaluar, decidir y si tu dia a dia lo llevas en un ambiente muy similar al ambiente donde trabajas, seguro eres muchísimo más proficiente.
Si para ti es "natural" usar vi para editar un archivo, seguramente serás más hábil que el que usa word pad, notepad o ultraedit para el mismo fin. Si para ti es natural utilizar la línea de comandos, pipes, redirecciones, variables, etc, trabajar con un sistema muy parecido al "tuyo" se te hace un paseo. Es simple, la experiencia solo se gana haciendo las cosas varias veces.
Lo voy a poner de esta manera, ¿cuántos administradores de windows tienen en su estación de trabajo Linux (por ejemplo) ? ¿Por qué ellos si pueden trabajar con el sistema operativo que administran y nosotros no?
Ojo, no tengo nada en contra de los administradores de windows, de hecho, la gran mayoría simplemente se "encontró" con esa estación de trabajo que usa a diario.. pero... las preguntas siguen siendo válidas..... y siguen sin tener respuesta.
En ninguna entrevista de trabajo para un puesto de administrador de UNIX me han preguntado si se utilizar windows, ¿es que lo pre-suponen?, ¿por qué?
Hay quienes "intentan" responder a esta situación diciendo que las herramientas "corporativas" solo corren en windows.... muy bién, si son tan miopes que se tienen que amarrar a una herramienta en vez de usar una tecnología, al menos denme una herramienta adecuada para realizar mi trabajo, es decir, denme un equipo en el que pueda usar las herramientas "corporativas" y otro en el que pueda tener Linux (o cualquier otro unix) o denme una máquina lo suficientemente "poderosa" (solo pido 2 GB de RAM para montar una máquina virtual) para poder tener ambos sistemas operativos corriendo.
Ahora, alguien que lea esto puede pensar que es exactamente lo mismo trabajar desde windows que desde Linux, total, los servidores se acceden de manera remota y con tener un emulador de terminal es suficiente. Muy bien, eso te sirve si eres un administrador poco proficiente pero, si te gusta hacer script's, si quieres hacer pruebas, si quieres tener un ambiente "similar" (sin duda, Linux es "más similar" a cualquier *NIX que windows) al de los servidores, tu elección es tener Linux en tu estación de trabajo.
Ser un administrador de sistemas no es solo tirar algunos comandos y ya está, es pensar, evaluar, decidir y si tu dia a dia lo llevas en un ambiente muy similar al ambiente donde trabajas, seguro eres muchísimo más proficiente.
Si para ti es "natural" usar vi para editar un archivo, seguramente serás más hábil que el que usa word pad, notepad o ultraedit para el mismo fin. Si para ti es natural utilizar la línea de comandos, pipes, redirecciones, variables, etc, trabajar con un sistema muy parecido al "tuyo" se te hace un paseo. Es simple, la experiencia solo se gana haciendo las cosas varias veces.
Subscribe to:
Posts (Atom)