Es bien conocido el hecho de que cuando se conecta una máquina a la red (lo he visto en Solaris, HP-UX, Windows, Linux, etc) si no se fuerza la tarjeta de red y el switch a la velocidad requerida, la transferencia de archivos y la comunicación es pésima.
En el trabajo, cada vez que se conecta un servidor a la red se debe forzar la interfaz de red, ya sea a 100 Mbps Full-Duplex o a 1000 Mbps Full-Duplex. Pero ojo, con las tarjetas Gigabit en Solaris he visto algunos problemas con el forzado, que explicaré a continuación.
Las inferces se pueden forzar con un archivo que modifica los parámetros a nivel de módulo en el Kernel (Ej: /kernel/drv/ce.conf) o a través del comando ndd (esto dura sólo hasta el reboot del servidor). El primer método es ún "poco" más complicado que el segundo, pero al final hacen lo mismo. En mi experiencia, da lo mismo cual de los métodos usar. En lo particular, utilizo ndd y el script /etc/rc2.d/S68net-tune.
Ahora viene lo importante. Con las tarjetas ce tenía el problema que cuando ocurría algun problema en el switch o reinicio de la máquina, el link de la tarjeta gigabit no volvía a subir. Tenía que activar la autonegociación para que levantara el link y después la forzaba a no autonegociar. Finalmente opté por dejarla a 1000 Mbps Full-Duplex con autonegociación ACTIVA.
En el caso de las ipge, cuando se fuerzan a 1000 Mbps Full-Duplex y autonegociación en OFF, el link nunca sube. La solución es dejar la Autonegociación en ON.
Ahora viene la pregunta (cuya respuesta no conocía y sólo me quedaba asumir): Por qué hay que dejar habilitada la autonegociación cuando se quiere forzar a 1000 Mbps Full-Duplex???
La respuesta la encontré en el documento de instalación y configuración de las tarjetas ipge (P/N: 819-4090-10):
De acuerdo a las especificaciones del IEEE 802.3, cuando se utiliza la velocidad de 1000 Mbit/sec sobre un medio de cobre, la autonegociación no es opcional. En la ausencia de autonegociación (por ejemplo, cuando se usa el modo Forced), la sincronización del link entre los link partners puede no ocurrir y el link no subirá.
Por lo tanto, para forzar una interfaz a 1 Gbps Full-Duplex en Solaris se debe dejar la autonegociación en 1 (On).
Ejemplo:
Para poder forzar la interfaz ipge1 con ndd, se debe ejecutar lo siguiente:
ndd -set /dev/ipge instance 1
ndd -set /dev/ipge adv_1000fdx_cap 1
ndd -set /dev/ipge adv_1000hdx_cap 0
ndd -set /dev/ipge adv_100fdx_cap 0
ndd -set /dev/ipge adv_100hdx_cap 0
ndd -set /dev/ipge adv_10fdx_cap 0
ndd -set /dev/ipge adv_10hdx_cap 0
ndd -set /dev/ipge adv_autoneg_cap 1
Saludos,
ChaZcaZ./
Wednesday, December 20, 2006
Wednesday, December 13, 2006
MPxIO de Solaris: como eliminar una LUN del sistema
Cuando se tiene configurado MPxIO y se desea eliminar una LUN del sistema, hay que tener presente que si la LUN no es eliminada del Traffic Manager (MPxIO), después pueden ocurrir cosas raras (personalmente, he presentado nuevas LUN y parecen ser idénticas a la eliminada, tamaños distintos, etc) que sólo se solucionan rebooteando el servidor (lo cual no es la idea).
El proceso de eliminar una LUN del sistema es simple, pero debe realizarse en orden. Básicamente, para eliminar una(s) LUN(s) del sistema se debe hacer lo siguiente:
1) Desmontar todos los filesystem que dependen de la(s) LUN(s) a eliminar (sacar de vfstab, etc)
2) Deportar diskgroup al que pertenece(n) la(s) LUN(s) o eliminar los volúmenes correspondientes (en el caso de VERITAS Volume Manager). Si es Solstice Disk Suite (o Solaris Volume Manager) eliminar los metadevices correspondientes.
Para el caso de VERITAS Volume Manager, utilizar el siguiente comando para sacar el disco en cuestión del control del VxVm (en caso de que el vxdisk list lo siga mostrando con error):
vxdisk rm disk_path
Si los discos están bajo el control de STMS, deben sacarlos utilizando:
3) Despresentar las LUNs desde el Storage (o desconectar discos en el caso de que sea una caja de discos sin inteligencia). La idea es que bajo MPxIO los discos queden en la condición unusable (esto se ve con el comando cfgadm -al -o show_FCP_dev en Solaris 8 y con cfgadm -al -o show_SCSI_LUN en Solaris 10, aunque el primer caso a mi me ha funcionado tanto en Solaris 8 como 10).
4) cfgadm no permite eliminar una única LUN del sistema, cuando el Storage conectado no es Sun (por lo menos eso me ha pasado con los StorageWorks HP EVA8000). Por esta razón, los discos se dejan en la condición unusable, para después poder eliminarlos con el siguiente comando (se debe hacer por cada PORT del Controlador del Storage por donde se ve el disco, de acuerdo a la salida del cfgadm -al -o show_FCP_dev):
cfgadm .c unconfigure -o unusable_FCP_dev DEVICE, donde DEVICE corresponde a cada puerto del controlador.
EJEMPLO
En este ejemplo, se tiene un servidor SunFire v880/Solaris 8/2 x HBA Sun/HP StorageWorks EVA8000/MPxIO/VERITAS Volume Manager 4.0.
En este punto ya se desmontaron filesystem, se sacaron de Volume Manager y se despresentaron las LUN desde el Storage.
Con el comando cfgadm -al -o show_FCP_dev debemos ver los discos en Condicion unusable:
# cfgadm -al -o show_FCP_dev
Ap_Id Type Receptacle Occupant Condition
c1 fc-private connected configured unknown
c1::21000004cf16426e,0 disk connected configured unknown
c1::21000004cf9b566c,0 disk connected configured unknown
c1::21000004cf9b6102,0 disk connected configured unknown
c1::21000004cf9b6107,0 disk connected configured unknown
c1::21000004cf9b6120,0 disk connected configured unknown
c1::21000004cfb47161,0 disk connected configured unknown
c1::508002000019f829 ESI connected configured unknown
c10 fc-fabric connected configured unknown
c10::50001fe150020dd9,0 array-ctrl connected unconfigured unknown
c10::50001fe150020dd9,1 disk connected configured unknown
c10::50001fe150020dd9,2 disk connected configured unknown
c10::50001fe150020dd9,3 disk connected configured unknown
c10::50001fe150020dd9,4 unavailable connected configured unusable
c10::50001fe150020ddb,0 array-ctrl connected unconfigured unknown
c10::50001fe150020ddb,1 disk connected configured unknown
c10::50001fe150020ddb,2 disk connected configured unknown
c10::50001fe150020ddb,3 disk connected configured unknown
c10::50001fe150020ddb,4 unavailable connected configured unusable
c10::50001fe150020ddd,0 array-ctrl connected unconfigured unknown
c10::50001fe150020ddd,1 disk connected configured unknown
c10::50001fe150020ddd,2 disk connected configured unknown
c10::50001fe150020ddd,3 disk connected configured unknown
c10::50001fe150020ddd,4 unavailable connected configured unusable
c10::50001fe150020ddf,0 array-ctrl connected unconfigured unknown
c10::50001fe150020ddf,1 disk connected configured unknown
c10::50001fe150020ddf,2 disk connected configured unknown
c10::50001fe150020ddf,3 disk connected configured unknown
c10::50001fe150020ddf,4 unavailable connected configured unusable
c11 fc-fabric connected configured unknown
c11::50001fe150020dd8,0 array-ctrl connected unconfigured unknown
c11::50001fe150020dd8,1 disk connected configured unknown
c11::50001fe150020dd8,2 disk connected configured unknown
c11::50001fe150020dd8,3 disk connected configured unknown
c11::50001fe150020dd8,4 unavailable connected configured unusable
c11::50001fe150020dda,0 array-ctrl connected unconfigured unknown
c11::50001fe150020dda,1 disk connected configured unknown
c11::50001fe150020dda,2 disk connected configured unknown
c11::50001fe150020dda,3 disk connected configured unknown
c11::50001fe150020dda,4 unavailable connected configured unusable
c11::50001fe150020ddc,0 array-ctrl connected unconfigured unknown
c11::50001fe150020ddc,1 disk connected configured unknown
c11::50001fe150020ddc,2 disk connected configured unknown
c11::50001fe150020ddc,3 disk connected configured unknown
c11::50001fe150020ddc,4 unavailable connected configured unusable
c11::50001fe150020dde,0 array-ctrl connected unconfigured unknown
c11::50001fe150020dde,1 disk connected configured unknown
c11::50001fe150020dde,2 disk connected configured unknown
c11::50001fe150020dde,3 disk connected configured unknown
c11::50001fe150020dde,4 unavailable connected configured unusable
Para explicar un poco la salida del comando anterior, tenemos lo siguiente:
- Este servidor tiene 3 controladoras de Fibra, que son c1 (controladora de discos internos de fibra), c10 y c11 (las 2 tarjetas HBA conectadas al EVA8000)
- El Storage EVA8K tiene 2 controladores y cada controlador tiene 4 Puertos. Esto implica que cada LUN la veré por 8 PATH distintos (2 Controllers * 4 Ports = 8 PATH).
- Por cada HBA se ve un controlador (los 4 PORTS de un controlador). Debajo de cada Puerto (array-ctrl) aparecen las LUN que están presentadas al servidor (el número de la LUN es el que está después de la ",").
En este caso, se ha despresentado una LUN, la LUN 4. Se puede apreciar que en todos los Puertos aparece la LUN ",4" en Condicion unusable. Hay que eliminarla una por una (8 veces) de cada Puerto. En el comando para eliminar, se debe poner el WWPN de cada Puerto (todo el chorizo hasta antes de la ","). De esta manera, el cfgadm va a eliminar todas los dispositivos que estén en estado unusable del Controlador indicado.
Para hacer todo en un sólo paso y poder automatizar el proceso de eliminación, hice un "script" que hace todo (pero todo lo que tiene que ver con MPxIO, no desmonta ni deporta grupos de discos):
cfgadm -al -o show_FCP_dev | grep unusable | awk '{print $1}' | while read t; do device=`echo $t | cut -d"," -f1`; cfgadm -c unconfigure -o unusable_FCP_dev $device; done
Finalmente, esto eliminará cualquier dispositivo /dev/* que esté colgado:
devfsadm -Cv
Saludos,
ChaZcaZ./
El proceso de eliminar una LUN del sistema es simple, pero debe realizarse en orden. Básicamente, para eliminar una(s) LUN(s) del sistema se debe hacer lo siguiente:
1) Desmontar todos los filesystem que dependen de la(s) LUN(s) a eliminar (sacar de vfstab, etc)
2) Deportar diskgroup al que pertenece(n) la(s) LUN(s) o eliminar los volúmenes correspondientes (en el caso de VERITAS Volume Manager). Si es Solstice Disk Suite (o Solaris Volume Manager) eliminar los metadevices correspondientes.
Para el caso de VERITAS Volume Manager, utilizar el siguiente comando para sacar el disco en cuestión del control del VxVm (en caso de que el vxdisk list lo siga mostrando con error):
vxdisk rm disk_path
Si los discos están bajo el control de STMS, deben sacarlos utilizando:
stmsboot -d #deshabilita STMSBOOT para todos los discos
O
stmsboot -d controller whatever #deshabilita STMS para un controlador especifico
3) Despresentar las LUNs desde el Storage (o desconectar discos en el caso de que sea una caja de discos sin inteligencia). La idea es que bajo MPxIO los discos queden en la condición unusable (esto se ve con el comando cfgadm -al -o show_FCP_dev en Solaris 8 y con cfgadm -al -o show_SCSI_LUN en Solaris 10, aunque el primer caso a mi me ha funcionado tanto en Solaris 8 como 10).
4) cfgadm no permite eliminar una única LUN del sistema, cuando el Storage conectado no es Sun (por lo menos eso me ha pasado con los StorageWorks HP EVA8000). Por esta razón, los discos se dejan en la condición unusable, para después poder eliminarlos con el siguiente comando (se debe hacer por cada PORT del Controlador del Storage por donde se ve el disco, de acuerdo a la salida del cfgadm -al -o show_FCP_dev):
cfgadm .c unconfigure -o unusable_FCP_dev DEVICE, donde DEVICE corresponde a cada puerto del controlador.
EJEMPLO
En este ejemplo, se tiene un servidor SunFire v880/Solaris 8/2 x HBA Sun/HP StorageWorks EVA8000/MPxIO/VERITAS Volume Manager 4.0.
En este punto ya se desmontaron filesystem, se sacaron de Volume Manager y se despresentaron las LUN desde el Storage.
Con el comando cfgadm -al -o show_FCP_dev debemos ver los discos en Condicion unusable:
# cfgadm -al -o show_FCP_dev
Ap_Id Type Receptacle Occupant Condition
c1 fc-private connected configured unknown
c1::21000004cf16426e,0 disk connected configured unknown
c1::21000004cf9b566c,0 disk connected configured unknown
c1::21000004cf9b6102,0 disk connected configured unknown
c1::21000004cf9b6107,0 disk connected configured unknown
c1::21000004cf9b6120,0 disk connected configured unknown
c1::21000004cfb47161,0 disk connected configured unknown
c1::508002000019f829 ESI connected configured unknown
c10 fc-fabric connected configured unknown
c10::50001fe150020dd9,0 array-ctrl connected unconfigured unknown
c10::50001fe150020dd9,1 disk connected configured unknown
c10::50001fe150020dd9,2 disk connected configured unknown
c10::50001fe150020dd9,3 disk connected configured unknown
c10::50001fe150020dd9,4 unavailable connected configured unusable
c10::50001fe150020ddb,0 array-ctrl connected unconfigured unknown
c10::50001fe150020ddb,1 disk connected configured unknown
c10::50001fe150020ddb,2 disk connected configured unknown
c10::50001fe150020ddb,3 disk connected configured unknown
c10::50001fe150020ddb,4 unavailable connected configured unusable
c10::50001fe150020ddd,0 array-ctrl connected unconfigured unknown
c10::50001fe150020ddd,1 disk connected configured unknown
c10::50001fe150020ddd,2 disk connected configured unknown
c10::50001fe150020ddd,3 disk connected configured unknown
c10::50001fe150020ddd,4 unavailable connected configured unusable
c10::50001fe150020ddf,0 array-ctrl connected unconfigured unknown
c10::50001fe150020ddf,1 disk connected configured unknown
c10::50001fe150020ddf,2 disk connected configured unknown
c10::50001fe150020ddf,3 disk connected configured unknown
c10::50001fe150020ddf,4 unavailable connected configured unusable
c11 fc-fabric connected configured unknown
c11::50001fe150020dd8,0 array-ctrl connected unconfigured unknown
c11::50001fe150020dd8,1 disk connected configured unknown
c11::50001fe150020dd8,2 disk connected configured unknown
c11::50001fe150020dd8,3 disk connected configured unknown
c11::50001fe150020dd8,4 unavailable connected configured unusable
c11::50001fe150020dda,0 array-ctrl connected unconfigured unknown
c11::50001fe150020dda,1 disk connected configured unknown
c11::50001fe150020dda,2 disk connected configured unknown
c11::50001fe150020dda,3 disk connected configured unknown
c11::50001fe150020dda,4 unavailable connected configured unusable
c11::50001fe150020ddc,0 array-ctrl connected unconfigured unknown
c11::50001fe150020ddc,1 disk connected configured unknown
c11::50001fe150020ddc,2 disk connected configured unknown
c11::50001fe150020ddc,3 disk connected configured unknown
c11::50001fe150020ddc,4 unavailable connected configured unusable
c11::50001fe150020dde,0 array-ctrl connected unconfigured unknown
c11::50001fe150020dde,1 disk connected configured unknown
c11::50001fe150020dde,2 disk connected configured unknown
c11::50001fe150020dde,3 disk connected configured unknown
c11::50001fe150020dde,4 unavailable connected configured unusable
Para explicar un poco la salida del comando anterior, tenemos lo siguiente:
- Este servidor tiene 3 controladoras de Fibra, que son c1 (controladora de discos internos de fibra), c10 y c11 (las 2 tarjetas HBA conectadas al EVA8000)
- El Storage EVA8K tiene 2 controladores y cada controlador tiene 4 Puertos. Esto implica que cada LUN la veré por 8 PATH distintos (2 Controllers * 4 Ports = 8 PATH).
- Por cada HBA se ve un controlador (los 4 PORTS de un controlador). Debajo de cada Puerto (array-ctrl) aparecen las LUN que están presentadas al servidor (el número de la LUN es el que está después de la ",").
En este caso, se ha despresentado una LUN, la LUN 4. Se puede apreciar que en todos los Puertos aparece la LUN ",4" en Condicion unusable. Hay que eliminarla una por una (8 veces) de cada Puerto. En el comando para eliminar, se debe poner el WWPN de cada Puerto (todo el chorizo hasta antes de la ","). De esta manera, el cfgadm va a eliminar todas los dispositivos que estén en estado unusable del Controlador indicado.
Para hacer todo en un sólo paso y poder automatizar el proceso de eliminación, hice un "script" que hace todo (pero todo lo que tiene que ver con MPxIO, no desmonta ni deporta grupos de discos):
cfgadm -al -o show_FCP_dev | grep unusable | awk '{print $1}' | while read t; do device=`echo $t | cut -d"," -f1`; cfgadm -c unconfigure -o unusable_FCP_dev $device; done
Finalmente, esto eliminará cualquier dispositivo /dev/* que esté colgado:
devfsadm -Cv
Saludos,
ChaZcaZ./
Como utilizar un Proxy bajo Consola en Ubuntu Linux
Cuando se está detrás de un proxy y se quiere hacer un apt-get por ejemplo desde línea de comando, este no funcionará si es que en el sources.list hay sitios que están en Internet.
Una solución para esto es utilizar la variable de entorno http_proxy
export http_proxy="http://direccion_ip_proxy:puerto/"
Saludos,
ChaZcaZ./
Una solución para esto es utilizar la variable de entorno http_proxy
export http_proxy="http://direccion_ip_proxy:puerto/"
Saludos,
ChaZcaZ./
Wednesday, October 18, 2006
Blog de Solaris solidos
Bueno, este post se me borró no se como, así que vuelvo a poner algunas direcciones interesantes:
1) Brendan Gregg:
Solido en Solaris. Escribió el DTraceToolkit (Solaris 10) y K9Toolkit (Solaris 8 en adelante). Tiene cosas interesantes:
http://bdgregg.blogspot.com/
http://blogs.sun.com/brendan
http://www.brendangregg.com/
2) Blog O'Matty:
Siempre tiene Tips de Solaris, Linux, etc. Es sólido el Blog:
http://prefetch.net/blog/index.php/
3) Derek Crudgington
Tiene varias cosas interesantes de Solaris:
http://hell.jedicoder.net/
Eso por ahora.
Saludos,
ChaZcaZ./
1) Brendan Gregg:
Solido en Solaris. Escribió el DTraceToolkit (Solaris 10) y K9Toolkit (Solaris 8 en adelante). Tiene cosas interesantes:
http://bdgregg.blogspot.com/
http://blogs.sun.com/brendan
http://www.brendangregg.com/
2) Blog O'Matty:
Siempre tiene Tips de Solaris, Linux, etc. Es sólido el Blog:
http://prefetch.net/blog/index.php/
3) Derek Crudgington
Tiene varias cosas interesantes de Solaris:
http://hell.jedicoder.net/
Eso por ahora.
Saludos,
ChaZcaZ./
Tuesday, October 17, 2006
VCS Seeding - Iniciar un Veritas Cluster con un solo nodo
Para proteger el cluster de una partición de red (network partition), Veritas CLuster Server (VCS) utiliza el concepto de seed. Por defecto, cuando un sistema sube, este no está seeded. Los sistemas pueden ser seeded automáticamente o manualmente. Notar que sólo los sistemas que han sido seeded pueden correr VCS.
Los sistemas son seeded automáticamente en una de 2 maneras:
- Cuando un sistema "unseeded" se comunica con un sistema "seeded"
- Cuando todos los sistemas en el cluster están "unseeded" y habilitados para comunicarse con los otros.
El control del "seeding" está establecido en el archivo /etc/gabtab. GAB es iniciado con la línea de comando /sbin/gabconfig -c -n X, donde X es igual al número de nodos en el cluster. Por ejemplo, la línea de comando en el archivo /etc/gabtab para un cluster de 4-nodos es /sbin/gabconfig -c -n 4. VCS requiere que se declare el número de nodos en el Cluster.
Cuando el último sistema es "booteado", el cluster "seedeará" y comenzará VCS en todos los sistemas. Desde ahora los sistemas pueden ser bajados y reiniciados en cualquier combinación. "Seeding" es automático siempre que al menos una instancia de VCS está corriendo en algún lugar del Cluster.
Para iniciar el cluster con menos nodos que el total, verificar que los nodos a ser excluídos están actualmente abajo. Luego, iniciat GAB con el comando /sbin/gabconfig -c -x. Esto "seedeará" manualmente el cluster y habilitará VCS para subir en todos los sistemas conectados.
Saludos,
ChaZcaZ./
Los sistemas son seeded automáticamente en una de 2 maneras:
- Cuando un sistema "unseeded" se comunica con un sistema "seeded"
- Cuando todos los sistemas en el cluster están "unseeded" y habilitados para comunicarse con los otros.
El control del "seeding" está establecido en el archivo /etc/gabtab. GAB es iniciado con la línea de comando /sbin/gabconfig -c -n X, donde X es igual al número de nodos en el cluster. Por ejemplo, la línea de comando en el archivo /etc/gabtab para un cluster de 4-nodos es /sbin/gabconfig -c -n 4. VCS requiere que se declare el número de nodos en el Cluster.
Cuando el último sistema es "booteado", el cluster "seedeará" y comenzará VCS en todos los sistemas. Desde ahora los sistemas pueden ser bajados y reiniciados en cualquier combinación. "Seeding" es automático siempre que al menos una instancia de VCS está corriendo en algún lugar del Cluster.
Para iniciar el cluster con menos nodos que el total, verificar que los nodos a ser excluídos están actualmente abajo. Luego, iniciat GAB con el comando /sbin/gabconfig -c -x. Esto "seedeará" manualmente el cluster y habilitará VCS para subir en todos los sistemas conectados.
Saludos,
ChaZcaZ./
Setear y revisar modo Duplex de interfaces de Red en Unix
Esto lo encontré alguna vez en Internet y lo he completado con algunas cosas que he utilizado. Es muy útil, ya que la mayoría de los problemas de red comienzan cuando la velocidad y/o el modo de conexión está configurado incorrectamente.
Solaris
Para checkear el Duplex:
ndd /dev/hme link_mode
Cuando retorna un valor 0 = half duplex, y 1 = full duplex
Para forzar a modo full duplex:
ndd -sec /dev/hme adv_100fdx_capndd -set /dev/hme adv_autoneg_cap 0
Para forzar a modo half duplex:
ndd -sec /dev/hme adv_100hdx_capndd -set /dev/hme adv_autoneg_cap 0
Linux
La herramiento original en Linux para setear la velocidad y el duplex es mii-tool. Ahora está destinado a ser reemplazado por ethtool, pero muchas tarjetas antiguas sólo soportan mii-tool.
Por ejemplo:
mii-tool -F 100baseTx-FD eth0
Para ver la configuración de las tarjetas de red, usar:
mii-tool -v
Lo siguiente también puede ser usado con algunas tarjetas comunes:
Para setear las tarjetas eepro100 a modo full-duplex:
en /etc/modules.conf (para Redhat Linux)
options eepro100 options=48
Para las tarjetas 3c59x: options 3c59x options=0x204 full_duplex=0x200
ethtool
El comando entrega información acerca de la configuración de la interfaz de red que se le pasa como parámetro. Ejemplo:
#ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: g
Wake-on: g
Current message level: 0x00000007 (7)
Link detected: yes
Para setear la velocidad y el duplex, se debe editar el archivo de configuración de la interfaz de red y se debe agregar la línea ETHTOOL_OPTS, como se muestra a continuación:
#
# File: /etc/sysconfig/network-script/ifcfg-eth0
#
DEVICE=eth0
IPADDR=192.168.1.100
NETMASK=255.255.255.0
BOOTPROTO=static
ONBOOT=yes
ETHTOOL_OPTS="speed 100 duplex full autoneg off"
Para setear la velocidad y duplex en forma dinámica, se puede hacer de la siguiente manera:
#ethtool -s eth1 speed 100 duplex full autoneg off
Solaris
Para checkear el Duplex:
ndd /dev/hme link_mode
Cuando retorna un valor 0 = half duplex, y 1 = full duplex
Para forzar a modo full duplex:
ndd -sec /dev/hme adv_100fdx_capndd -set /dev/hme adv_autoneg_cap 0
Para forzar a modo half duplex:
ndd -sec /dev/hme adv_100hdx_capndd -set /dev/hme adv_autoneg_cap 0
Linux
La herramiento original en Linux para setear la velocidad y el duplex es mii-tool. Ahora está destinado a ser reemplazado por ethtool, pero muchas tarjetas antiguas sólo soportan mii-tool.
Por ejemplo:
mii-tool -F 100baseTx-FD eth0
Para ver la configuración de las tarjetas de red, usar:
mii-tool -v
Lo siguiente también puede ser usado con algunas tarjetas comunes:
Para setear las tarjetas eepro100 a modo full-duplex:
en /etc/modules.conf (para Redhat Linux)
options eepro100 options=48
Para las tarjetas 3c59x: options 3c59x options=0x204 full_duplex=0x200
ethtool
El comando entrega información acerca de la configuración de la interfaz de red que se le pasa como parámetro. Ejemplo:
#ethtool eth0
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: No
Speed: 100Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: off
Supports Wake-on: g
Wake-on: g
Current message level: 0x00000007 (7)
Link detected: yes
Para setear la velocidad y el duplex, se debe editar el archivo de configuración de la interfaz de red y se debe agregar la línea ETHTOOL_OPTS, como se muestra a continuación:
#
# File: /etc/sysconfig/network-script/ifcfg-eth0
#
DEVICE=eth0
IPADDR=192.168.1.100
NETMASK=255.255.255.0
BOOTPROTO=static
ONBOOT=yes
ETHTOOL_OPTS="speed 100 duplex full autoneg off"
Para setear la velocidad y duplex en forma dinámica, se puede hacer de la siguiente manera:
#ethtool -s eth1 speed 100 duplex full autoneg off
FreeBSD
Para chequear el modo Duplex: Solo se usa ifconfig -a
Para forzar a modo Full Duplex: ifconfig xl0 media 100baseTX mediaopt full-duplex
Para forzar a modo Half Duplex: ifconfig xl0 media 100baseTX mediaopt half-duplex
Note: Esto funciona para todos los dispositivos, no sólo para el driver xl0.
IBM AIX
Para obtener una lista de adaptadores:
lsdev -HCc adapter
Para chequear el modo duplex:
lsattr -d ent#
Para forzar el modo full duplex:
chdev -l ent# -a media_speed=100_Full_Duplex -P reboot
Para forzar el modo half duplex:
chdev -l ent# -a media_speed=100_Half_Duplex -P reboot
HP-UX
Para obtener una lista de adaptadores:
HP-UX 10.x usa el "Network Management IDs "
lanscan -n
HP-UX 11.x usa los números "PPA"
lanscan -p
Para chequear el modo duplex:
lanadmin -x NMid# (HP-UX 10.x)
lanadmin -x PPA# (HP-UX 11.x)
Para forzar el modo full duplex:
lanadmin -X 100FD NMid# (HP-UX 10.x)
lanadmin -X 100FD PPA# (HP-UX 11.x)
Para forzar el modo half duplex:
lanadmin -X 100HD NMid# (HP-UX 10.x)
lanadmin -X 100HD PPA# (HP-UX 11.x)
Tru64
1) Para ver como estan configuradas las interfaces de red, utilizar el siguiente comando:
hwmgr -get attr -cat network
27:
name = ee0
category = network
sub_category = Ethernet
model = Intel 82559
hardware_rev = 8
firmware_rev =
MAC_address = 00-50-8B-65-AA-FA
MTU_size = 1500
media_speed = 100
media_selection = Automatic
media_type = Unshielded Twisted Pair (UTP)
loopback_mode = 0
promiscuous_mode = 0
full_duplex = 0
multicast_address_list = CF-00-00-00-00-00 01-00-5E-00-00-01 09-00-2B-00-00-0F 09-00-2B-02-01-04
interface_number = 1
link = Up
autoneg_enable = 1
registration_time = Thu Nov 3 18:08:36 2005
user_name = (null) (settable)
location = (null) (settable)
software_module = (null)
[…]
2) Esta interfaz está a 100Mbps Half-Duplex y con autonegociación. Se dejará forzada a 100Mbps Full-Duplex. Para esto, ejecutar:
/usr/sbin/lan_config -i ee0 -a0 -s100 -x1
3) Para que quede permanente después de cada boot, agregar la línea del lanconfig al final de archivo /etc/inet.local
Saludos,
ChaZcaZ./
Monday, October 16, 2006
Olvidar contraseña de root en Linux y FreeBSD - resetear
Cuando se olvida la contraseña de root o la persona que la conocía ya no trabaja en la empresa, la solución no es tan complicada.
A continuación muestro como se puede cambiar (o resetear) la contraseña de root en Linux y en FreeBSD. A lo mejor existen otros métodos, pero estos son los que yo conozco.
Para resetear la contraseña de root en Linux, debes hacer lo siguiente:
1. Iniciar el sistema con alguna distribución LiveCD (como Knoppix por ejemplo) o desde algún disco de rescate de alguna distro de Linux (como se bootea desde el CD de instalación de algunas distros, te da la opción de entrar en modo Rescue System, el cual ejecuta un Kernel, carga un ramdisk inicial e inicializa varios procesos del sistema. Para ingresar, solo debes escribir root como el usuario).
2. Una vez que están dentro de este “Linux”, debes identificar la partición que contiene el directorio /etc, ya que esta estará usualmente en tu partición / (root). Monta la partición bajo /mnt. El siguiente ejemplo usa /dev/hda3 como la partición root:
mount /dev/hda3 /mnt
3. Una vez montado el filesystem, necesitas editar el archivo /mnt/etc/shadow para resetear la contraseña de root. Este lo puedes editar con cualquier editor de textos, pero lo más recomendable (o más usado) es el vi.
4. Cuando esté cargado el archivo en el editor, debes buscar la entrada para el usuario root. Busca la contraseña encriptada, la cual es el segundo campo de la línea (los campos están separados por : ). Borra el password de tal manera que los dos punto y coma queden uno al lado del otro ( :: ) y guarda el archivo.
5. Una vez que el archivo fue editado, anda a la raiz (cd / ) y desmonta el filesystem con el siguiente comando:
umount /mnt
6. Finalmente, puedes rebotear el sistema, sacar el cd de Linux que pusiste y bootear desde el Linux instalado. Ahora la contraseña de root estará en blanco.
Para resetear la contraseña de root en FreeBSD:
1. Bootear el sistema en Single User Mode.
Para esto, cuando el sistema está iniciando, desplegará el siguiente mensaje:
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [kernel] in 10 seconds...
En este momento se debe presionar la barra espaciadora o cualquier otra tecla (menos [Enter]) y se verá el siguiente mensaje:
Type '?' for a list of commands, or 'help' for more detailed help.
ok
Ahora se debe tipear boot –s y presionar [Enter] para subir FreeBSD en Single User mode. Cuando el sistema sube, se debiera ver lo siguiente:
Enter full pathname of shell or RETURN for /bin/sh:
Presionar [Enter] y debiera aparecer el prompt #.
2. Montar el Filesystem
En el Prompt., ejecutar el comando mount. Este comando montará todos los filesystems listados en el archivo /etc/fstab:
# mount -t ufs -a
Adicionalmente, debiera ejecutarse este comando (si no funciona, continuar con el siguiente paso)
# swapon -a
3. Cambiar la contraseña de root
Ejecutar el comando passwd y el sistema solicitará la nueva contraseña para la cuenta root:
# passwd
New password:_
Retype new password:_
passwd: updating the database...
passwd: done
Si no funciona, probar agregando la opción –l:
# passwd -l
4. Subir en MultiUser mode
Finalmente, no es necesario rebootear para subir en multiuser mode. El comando exit causará que el sistema vaya a modo multiusuario sin reiniciar:
# exit
Eso es todo.
Saludos,
ChaZcaZ./
A continuación muestro como se puede cambiar (o resetear) la contraseña de root en Linux y en FreeBSD. A lo mejor existen otros métodos, pero estos son los que yo conozco.
Para resetear la contraseña de root en Linux, debes hacer lo siguiente:
1. Iniciar el sistema con alguna distribución LiveCD (como Knoppix por ejemplo) o desde algún disco de rescate de alguna distro de Linux (como se bootea desde el CD de instalación de algunas distros, te da la opción de entrar en modo Rescue System, el cual ejecuta un Kernel, carga un ramdisk inicial e inicializa varios procesos del sistema. Para ingresar, solo debes escribir root como el usuario).
2. Una vez que están dentro de este “Linux”, debes identificar la partición que contiene el directorio /etc, ya que esta estará usualmente en tu partición / (root). Monta la partición bajo /mnt. El siguiente ejemplo usa /dev/hda3 como la partición root:
mount /dev/hda3 /mnt
3. Una vez montado el filesystem, necesitas editar el archivo /mnt/etc/shadow para resetear la contraseña de root. Este lo puedes editar con cualquier editor de textos, pero lo más recomendable (o más usado) es el vi.
4. Cuando esté cargado el archivo en el editor, debes buscar la entrada para el usuario root. Busca la contraseña encriptada, la cual es el segundo campo de la línea (los campos están separados por : ). Borra el password de tal manera que los dos punto y coma queden uno al lado del otro ( :: ) y guarda el archivo.
5. Una vez que el archivo fue editado, anda a la raiz (cd / ) y desmonta el filesystem con el siguiente comando:
umount /mnt
6. Finalmente, puedes rebotear el sistema, sacar el cd de Linux que pusiste y bootear desde el Linux instalado. Ahora la contraseña de root estará en blanco.
Para resetear la contraseña de root en FreeBSD:
1. Bootear el sistema en Single User Mode.
Para esto, cuando el sistema está iniciando, desplegará el siguiente mensaje:
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [kernel] in 10 seconds...
En este momento se debe presionar la barra espaciadora o cualquier otra tecla (menos [Enter]) y se verá el siguiente mensaje:
Type '?' for a list of commands, or 'help' for more detailed help.
ok
Ahora se debe tipear boot –s y presionar [Enter] para subir FreeBSD en Single User mode. Cuando el sistema sube, se debiera ver lo siguiente:
Enter full pathname of shell or RETURN for /bin/sh:
Presionar [Enter] y debiera aparecer el prompt #.
2. Montar el Filesystem
En el Prompt., ejecutar el comando mount. Este comando montará todos los filesystems listados en el archivo /etc/fstab:
# mount -t ufs -a
Adicionalmente, debiera ejecutarse este comando (si no funciona, continuar con el siguiente paso)
# swapon -a
3. Cambiar la contraseña de root
Ejecutar el comando passwd y el sistema solicitará la nueva contraseña para la cuenta root:
# passwd
New password:_
Retype new password:_
passwd: updating the database...
passwd: done
Si no funciona, probar agregando la opción –l:
# passwd -l
4. Subir en MultiUser mode
Finalmente, no es necesario rebootear para subir en multiuser mode. El comando exit causará que el sistema vaya a modo multiusuario sin reiniciar:
# exit
Eso es todo.
Saludos,
ChaZcaZ./
cpio remoto - Copia remota
Cuando se necesita copiar algo de un servidor a otro, existen varios métodos (rcp, ftp, etc). Las veces que he tenido que hacerlo, he usado cpio. Es muy solido, mantiene los permisos, propietarios (siempre que los uid y gid sean los mismos).
Como ejemplo, se va a copiar el home del usuario chazcaz desde la máquina local hacia la máquina grodas (usuario chazcaz igual):
find /path_local/chazcaz/ | cpio -ocB | remsh grodas "cd /path_remoto/chazcaz/ ;cpio -imudcB"
Por otro lado, dentro de un mismo server se puede utilizar para copiar directorios completos, manteniendo privilegios, propietarios, permisos, etc. Como ejemplo, queremos copiar todo el contenido del directorio /chazcaz1 al directorio /chazcaz2. Esto se haría de la siguiente manera:
cd /chazcaz1
find . | cpio -pdmvu /chazcaz2
Saludos,
ChaZcaZ./
Como ejemplo, se va a copiar el home del usuario chazcaz desde la máquina local hacia la máquina grodas (usuario chazcaz igual):
find /path_local/chazcaz/ | cpio -ocB | remsh grodas "cd /path_remoto/chazcaz/ ;cpio -imudcB"
Por otro lado, dentro de un mismo server se puede utilizar para copiar directorios completos, manteniendo privilegios, propietarios, permisos, etc. Como ejemplo, queremos copiar todo el contenido del directorio /chazcaz1 al directorio /chazcaz2. Esto se haría de la siguiente manera:
cd /chazcaz1
find . | cpio -pdmvu /chazcaz2
Saludos,
ChaZcaZ./
Thursday, October 05, 2006
Configuracion de MPxIO en Fujitsu Siemens PrimerPower 450 / Solaris 10 / EVA8000
Este procedimiento tuve que hacer para poder configurar Traffic Manager (MPxIO) en un servidor Fujitsu Siemens con Solaris 10.
En un principio, vino un jote de Fujitsu Siemens Chile a configurar este asunto, pero ni siquiera pudo ver los discos. En ese momento, este compadre me instaló el driver lpfc, el cual es el driver para tarjetas HBA Emulex de Emulex.
Para poder ver los discos, tuve que modificar el archivo de configuracion del driver, que es el /kernel/drv/lpfc.conf. Ahí, uno pone los puertos de cada controlador del EVA, por que HBA se van a ver y el target que se le asignará a cada puerto. Se debe tener presente que en este caso, el Binding se está haciendo por WWPN (World Wide Port Name), por lo cual la variable que controla el Binding debe estar seteada en el valor que corresponde a WWPN.
Con esta configuración, veía los discos 4 veces ( cada controlador tenia 2 puertos habilitados) y con el comando format los devices aparecian de la forma catbdcsd. Esto ya estaba malo, porque cuando uno va a configurar los discos con MPxIO, en los dispositivos aparece el WWID de la LUN.
Fue imposible configurar el MPxIO con el driver lpfc. Asi que decidi entonces instalar el driver para HBA Emulex de Sun (SUNWemlxs y SUNWemlxu). Con estos drivers si funciono y esto fue lo que hice:
1) Instalar físicamente 2 o más tarjetas HBA Emulex Light Pulse LP10000
2) Presentar al menos una LUN al servidor
3) Instalar los paquetes SUNWemlxs y SUNWemlxu
4) Instalar parche 120222-11 o superior
5) Reiniciar
--> En esta altura, ya está instalado el driver y se pueden ver las LUN repetidas 4 veces (En estecaso, cada controlador tiene conectado 2 de los 4 puertos)
6) Con comando format, verificar que se están viendo 4 veces las LUN.
7) Ejecutar "luxadm -e port" para ver que Solaris ve los dispositivos correctamente a través deldriver (debiera ver 2):
root@prd1009 # luxadm -e port
/devices/pci@82,4000/lpfc@3/fp@0,0:devctl CONNECTED
/devices/pci@82,4000/lpfc@4/fp@0,0:devctl CONNECTED
8) Se habilitará el Traffic Manager (MPxIO) por puerto y no globalmente, para evitar tener problemas con lacontroladora de los discos internos. Para esto, se debe hacer lo siguiente:
- En el archivo /kernel/drv/fp.conf, la variable mpxio-disable debe estar configurada así:
mpxio-disable="yes";
- Editar el archivo /kernel/drv/fp.conf y agregar estas dos lineas al final (la información se saca de lasalida del comando luxadm -e probe):
name="fp" parent=/pci@82,4000/lpfc@3 port=0 mpxio-disable="no";
name="fp" parent="/pci@82,4000/lpfc@4" port=0 mpxio-disable="no";
- Editar el archivo /kernel/drv/scsi_vhci.conf y la variable device-type-scsi-options-list debe quedar como sigue (OJO con los espacios entre HP y HSV210 - Solo para EVA4000/6000/8000):
device-type-scsi-options-list ="HP HSV210", "symmetric-option";
- La variable symmetric-option del archivo /kernel/drv/scsi_vhci.conf debe tener el siguiente valor (solopara EVA):
symmetric-option = 0x1000000;
9) Reiniciar
10) A esta altura el MPxIO ya debe estar funcionando. Para comprobar, ejecutar el comando format, solo se debiera ver un disco por LUN:
root@prd1009 # format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c0t0d0/pci@83,4000/FJSV,ulsa@2,1/sd@0,0
1. c0t1d0/pci@83,4000/FJSV,ulsa@2,1/sd@1,0
2. c0t2d0/pci@83,4000/FJSV,ulsa@2,1/sd@2,0
3. c1t0d0/pci@83,4000/FJSV,ulsa@2/sd@0,0
4. c1t1d0/pci@83,4000/FJSV,ulsa@2/sd@1,0
5. c1t2d0/pci@83,4000/FJSV,ulsa@2/sd@2,0
6. c7t600508B4001064A30000500001A10000d025GBx2 /scsi_vhci/ssd@g600508b4001064a30000500001a10000
7. c7t600508B4001064A30000500001A40000d010GBx5 /scsi_vhci/ssd@g600508b4001064a30000500001a40000
8. c7t600508B4001064A300005000046E0000d010GB /scsi_vhci/ssd@g600508b4001064a300005000046e0000
9. c7t600508B4001064A30000500004780000d05GB /scsi_vhci/ssd@g600508b4001064a30000500004780000
10. c7t600508B4001064A30000500004690000d0100GB /scsi_vhci/ssd@g600508b4001064a30000500004690000
11. c7t600508B4001064A30000500004640000d0100GB /scsi_vhci/ssd@g600508b4001064a30000500004640000
12. c7t600508B4001064A30000500001950000d0100GBx1 /scsi_vhci/ssd@g600508b4001064a30000500001950000
13. c7t600508B4001064A30000500004730000d05GB /scsi_vhci/ssd@g600508b4001064a30000500004730000
Specify disk (enter its number): ^D
- Para corrobar que cada LUN tiene los 4 PATH, ejecutar el comando siguiente:
root@prd1009 # luxadm -v display /dev/rdsk/c7t600508B4001064A30000500001A10000d0s2
Displaying information for: /dev/rdsk/c7t600508B4001064A30000500001A10000d0s2
DEVICE PROPERTIES for disk: /dev/rdsk/c7t600508B4001064A30000500001A10000d0s2 Vendor: HP
Product ID: HSV210
Revision: 5031
Serial Num: Unavailable
Unformatted capacity: 51200.000 MBytes
Read Cache: Enabled
Minimum prefetch: 0x0
Maximum prefetch: 0x0
Device Type: Disk
device Path(s):
/dev/rdsk/c7t600508B4001064A30000500001A10000d0s2
/devices/scsi_vhci/ssd@g600508b4001064a30000500001a10000:c,raw Controller /devices/pci@82,4000/lpfc@4/fp@0,0
Device Address 50001fe150072d59,2
Host controller port WWN 10000000c955ae84 Class secondary State ONLINE Controller /devices/pci@82,4000/lpfc@3/fp@0,0 Device Address 50001fe150072d5c,2
Host controller port WWN 10000000c955af48 Class primary State ONLINE Controller /devices/pci@82,4000/lpfc@4/fp@0,0 Device Address 50001fe150072d5d,2
Host controller port WWN 10000000c955ae84 Class primary State ONLINE Controller /devices/pci@82,4000/lpfc@3/fp@0,0 Device Address 50001fe150072d58,2
Host controller port WWN 10000000c955af48 Class secondary State ONLINE
Eso es todo!.
Saludos,
ChaZcaZ./
En un principio, vino un jote de Fujitsu Siemens Chile a configurar este asunto, pero ni siquiera pudo ver los discos. En ese momento, este compadre me instaló el driver lpfc, el cual es el driver para tarjetas HBA Emulex de Emulex.
Para poder ver los discos, tuve que modificar el archivo de configuracion del driver, que es el /kernel/drv/lpfc.conf. Ahí, uno pone los puertos de cada controlador del EVA, por que HBA se van a ver y el target que se le asignará a cada puerto. Se debe tener presente que en este caso, el Binding se está haciendo por WWPN (World Wide Port Name), por lo cual la variable que controla el Binding debe estar seteada en el valor que corresponde a WWPN.
Con esta configuración, veía los discos 4 veces ( cada controlador tenia 2 puertos habilitados) y con el comando format los devices aparecian de la forma catbdcsd. Esto ya estaba malo, porque cuando uno va a configurar los discos con MPxIO, en los dispositivos aparece el WWID de la LUN.
Fue imposible configurar el MPxIO con el driver lpfc. Asi que decidi entonces instalar el driver para HBA Emulex de Sun (SUNWemlxs y SUNWemlxu). Con estos drivers si funciono y esto fue lo que hice:
1) Instalar físicamente 2 o más tarjetas HBA Emulex Light Pulse LP10000
2) Presentar al menos una LUN al servidor
3) Instalar los paquetes SUNWemlxs y SUNWemlxu
4) Instalar parche 120222-11 o superior
5) Reiniciar
--> En esta altura, ya está instalado el driver y se pueden ver las LUN repetidas 4 veces (En estecaso, cada controlador tiene conectado 2 de los 4 puertos)
6) Con comando format, verificar que se están viendo 4 veces las LUN.
7) Ejecutar "luxadm -e port" para ver que Solaris ve los dispositivos correctamente a través deldriver (debiera ver 2):
root@prd1009 # luxadm -e port
/devices/pci@82,4000/lpfc@3/fp@0,0:devctl CONNECTED
/devices/pci@82,4000/lpfc@4/fp@0,0:devctl CONNECTED
8) Se habilitará el Traffic Manager (MPxIO) por puerto y no globalmente, para evitar tener problemas con lacontroladora de los discos internos. Para esto, se debe hacer lo siguiente:
- En el archivo /kernel/drv/fp.conf, la variable mpxio-disable debe estar configurada así:
mpxio-disable="yes";
- Editar el archivo /kernel/drv/fp.conf y agregar estas dos lineas al final (la información se saca de lasalida del comando luxadm -e probe):
name="fp" parent=/pci@82,4000/lpfc@3 port=0 mpxio-disable="no";
name="fp" parent="/pci@82,4000/lpfc@4" port=0 mpxio-disable="no";
- Editar el archivo /kernel/drv/scsi_vhci.conf y la variable device-type-scsi-options-list debe quedar como sigue (OJO con los espacios entre HP y HSV210 - Solo para EVA4000/6000/8000):
device-type-scsi-options-list ="HP HSV210", "symmetric-option";
- La variable symmetric-option del archivo /kernel/drv/scsi_vhci.conf debe tener el siguiente valor (solopara EVA):
symmetric-option = 0x1000000;
9) Reiniciar
10) A esta altura el MPxIO ya debe estar funcionando. Para comprobar, ejecutar el comando format, solo se debiera ver un disco por LUN:
root@prd1009 # format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c0t0d0
1. c0t1d0
2. c0t2d0
3. c1t0d0
4. c1t1d0
5. c1t2d0
6. c7t600508B4001064A30000500001A10000d0
7. c7t600508B4001064A30000500001A40000d0
8. c7t600508B4001064A300005000046E0000d0
9. c7t600508B4001064A30000500004780000d0
10. c7t600508B4001064A30000500004690000d0
11. c7t600508B4001064A30000500004640000d0
12. c7t600508B4001064A30000500001950000d0
13. c7t600508B4001064A30000500004730000d0
Specify disk (enter its number): ^D
- Para corrobar que cada LUN tiene los 4 PATH, ejecutar el comando siguiente:
root@prd1009 # luxadm -v display /dev/rdsk/c7t600508B4001064A30000500001A10000d0s2
Displaying information for: /dev/rdsk/c7t600508B4001064A30000500001A10000d0s2
DEVICE PROPERTIES for disk: /dev/rdsk/c7t600508B4001064A30000500001A10000d0s2 Vendor: HP
Product ID: HSV210
Revision: 5031
Serial Num: Unavailable
Unformatted capacity: 51200.000 MBytes
Read Cache: Enabled
Minimum prefetch: 0x0
Maximum prefetch: 0x0
Device Type: Disk
device Path(s):
/dev/rdsk/c7t600508B4001064A30000500001A10000d0s2
/devices/scsi_vhci/ssd@g600508b4001064a30000500001a10000:c,raw Controller /devices/pci@82,4000/lpfc@4/fp@0,0
Device Address 50001fe150072d59,2
Host controller port WWN 10000000c955ae84 Class secondary State ONLINE Controller /devices/pci@82,4000/lpfc@3/fp@0,0 Device Address 50001fe150072d5c,2
Host controller port WWN 10000000c955af48 Class primary State ONLINE Controller /devices/pci@82,4000/lpfc@4/fp@0,0 Device Address 50001fe150072d5d,2
Host controller port WWN 10000000c955ae84 Class primary State ONLINE Controller /devices/pci@82,4000/lpfc@3/fp@0,0 Device Address 50001fe150072d58,2
Host controller port WWN 10000000c955af48 Class secondary State ONLINE
Eso es todo!.
Saludos,
ChaZcaZ./
Monday, August 07, 2006
Tru64: Agrandar un File System cambiando un disco pequeño por uno grande
Este procedimiento lo hice una vez que se me solicitó agregar espacio disponible en un filesystem de un servidor Tru64.
En esa oportunidad, el filesystem en cuestión formaba parte de un Dominio (DWProd20), al cual se le creaban 4 filesets. El dominio estaba formado por 1 disco (dsk77c) de 41GB. Se presentó un disco de 62GB (dsk78c), el cual se agregaría al dominio, se traspasaría la data del otro disco a este y finalmente se sacaría el disco de 41GB del Dominio para ser eliminado. Ambos discos son LUN de un Storage EVA5000.
Esto es lo que hice:
#
# Se debe verificar que la licencia para ADVFS Utilities está activa, puesto que es requisito
# para poder utilizar addvol y rmvol
# lmf
lmf> list
Product Status Users: Total Active
OSF-BASE active unlimited
OSF-BASE active, multiple unlimited
ADVFS-UTILITIES active unlimited
LSM-OA active unlimited
OSF-SVR active unlimited
OSF-USR active unlimited
OSF-USR active, multiple unlimited
# df -k
Filesystem 1024-blocks Used Available Capacity Mounted on
r2root_dmn#root 819200 347675 464528 43% /
/proc 0 0 0 100% /proc
r2usr_dmn#usr 8388608 1876262 6261184 24% /usr
[…]
DWProd18#fs1 104857600 56 104851696 1% /wdb0103
DWProd20#fs1 41943040 27184811 7504480 79% /DWTMC/Ficheros/Entrada
DWProd20#fs2 41943040 10652 7504480 1% /DWTMC/Ficheros/Sqlloader
DWProd20#fs3 41943040 7013091 7504480 49% /DWTMC/Ficheros/Historico
DWProd20#fs4 41943040 216664 7504480 3% /DWTMC/Ficheros/Log
DWProd19#fs1 10485760 1649710 8830080 16% /intneg
#
# Se realiza un scan para detector la nueva LUN que se ha presentado desde el EVA
# hwmgr scan scsi
hwmgr: Scan request successfully initiated
# hwmgr -view dev
HWID: Device Name Mfg Model Location
------------------------------------------------------------------------------
3: /dev/scp_scsi
4: /dev/kevm
[…]
201: /dev/disk/dsk75c COMPAQ HSV110 (C)COMPAQ IDENTIFIER=1618
202: /dev/disk/dsk76c COMPAQ HSV110 (C)COMPAQ IDENTIFIER=1619
203: /dev/disk/dsk77c COMPAQ HSV110 (C)COMPAQ IDENTIFIER=1621
204: /dev/disk/dsk78c COMPAQ HSV110 (C)COMPAQ IDENTIFIER=1622
#
# Pone una etiqueta por defecto al disco
# disklabel -rw /dev/rdisk/dsk78c
#
# Agrega el volumen /dev/disk/dsk78c al dominio DWProd20
# addvol /dev/disk/dsk78c DWProd20
# showfdmn DWProd20
Id Date Created LogPgs Version Domain Name
4360da46.0005ad20 Thu Oct 27 10:46:46 2005 512 4 DWProd20
Vol 512-Blks Free % Used Cmode Rblks Wblks Vol Name
1L 83886080 12965728 85% on 256 256 /dev/disk/dsk77c
2 125829120 125827072 0% on 256 256 /dev/disk/dsk78c
---------- ---------- ------
209715200 138792800 34%
#
# Se elimina el volumen /dev/disk/dsk77c del Dominio DWProd20
# Al removerlo comienza a hacer un balance del dominio para liberar el disco que se
# va a retirar.
# rmvol /dev/disk/dsk77c DWProd20
rmvol: Removing volume '/dev/disk/dsk77c' from domain 'DWProd20'
rmvol: Removed volume '/dev/disk/dsk77c' from domain 'DWProd20'
[Esto tarda varios minutos]
# showfdmn DWProd20
Id Date Created LogPgs Version Domain Name
4360da46.0005ad20 Thu Oct 27 10:46:46 2005 512 4 DWProd20
Vol 512-Blks Free % Used Cmode Rblks Wblks Vol Name
2L 125829120 63555728 49% on 256 256 /dev/disk/dsk78c
# df -k
Filesystem 1024-blocks Used Available Capacity Mounted on
r2root_dmn#root 819200 347675 464528 43% /
/proc 0 0 0 100% /proc
r2usr_dmn#usr 8388608 1876262 6261184 24% /usr
[…]
DWProd18#fs1 104857600 56 104851696 1% /wdb0103
DWProd20#fs1 62914560 23882608 31777872 43% /DWTMC/Ficheros/Entrada
DWProd20#fs2 62914560 10652 31777872 1% /DWTMC/Ficheros/Sqlloader
DWProd20#fs3 62914560 7013091 31777872 19% /DWTMC/Ficheros/Historico
DWProd20#fs4 62914560 216692 31777872 1% /DWTMC/Ficheros/Log
DWProd19#fs1 10485760 1649699 8830080 16% /intneg
Saludos,
ChaZcaZ./
En esa oportunidad, el filesystem en cuestión formaba parte de un Dominio (DWProd20), al cual se le creaban 4 filesets. El dominio estaba formado por 1 disco (dsk77c) de 41GB. Se presentó un disco de 62GB (dsk78c), el cual se agregaría al dominio, se traspasaría la data del otro disco a este y finalmente se sacaría el disco de 41GB del Dominio para ser eliminado. Ambos discos son LUN de un Storage EVA5000.
Esto es lo que hice:
#
# Se debe verificar que la licencia para ADVFS Utilities está activa, puesto que es requisito
# para poder utilizar addvol y rmvol
lmf> list
Product Status Users: Total Active
OSF-BASE active unlimited
OSF-BASE active, multiple unlimited
ADVFS-UTILITIES active unlimited
LSM-OA active unlimited
OSF-SVR active unlimited
OSF-USR active unlimited
OSF-USR active, multiple unlimited
Filesystem 1024-blocks Used Available Capacity Mounted on
r2root_dmn#root 819200 347675 464528 43% /
/proc 0 0 0 100% /proc
r2usr_dmn#usr 8388608 1876262 6261184 24% /usr
[…]
DWProd18#fs1 104857600 56 104851696 1% /wdb0103
DWProd20#fs1 41943040 27184811 7504480 79% /DWTMC/Ficheros/Entrada
DWProd20#fs2 41943040 10652 7504480 1% /DWTMC/Ficheros/Sqlloader
DWProd20#fs3 41943040 7013091 7504480 49% /DWTMC/Ficheros/Historico
DWProd20#fs4 41943040 216664 7504480 3% /DWTMC/Ficheros/Log
DWProd19#fs1 10485760 1649710 8830080 16% /intneg
#
# Se realiza un scan para detector la nueva LUN que se ha presentado desde el EVA
hwmgr: Scan request successfully initiated
HWID: Device Name Mfg Model Location
------------------------------------------------------------------------------
3: /dev/scp_scsi
4: /dev/kevm
[…]
201: /dev/disk/dsk75c COMPAQ HSV110 (C)COMPAQ IDENTIFIER=1618
202: /dev/disk/dsk76c COMPAQ HSV110 (C)COMPAQ IDENTIFIER=1619
203: /dev/disk/dsk77c COMPAQ HSV110 (C)COMPAQ IDENTIFIER=1621
204: /dev/disk/dsk78c COMPAQ HSV110 (C)COMPAQ IDENTIFIER=1622
#
# Pone una etiqueta por defecto al disco
#
# Agrega el volumen /dev/disk/dsk78c al dominio DWProd20
Id Date Created LogPgs Version Domain Name
4360da46.0005ad20 Thu Oct 27 10:46:46 2005 512 4 DWProd20
Vol 512-Blks Free % Used Cmode Rblks Wblks Vol Name
1L 83886080 12965728 85% on 256 256 /dev/disk/dsk77c
2 125829120 125827072 0% on 256 256 /dev/disk/dsk78c
---------- ---------- ------
209715200 138792800 34%
#
# Se elimina el volumen /dev/disk/dsk77c del Dominio DWProd20
# Al removerlo comienza a hacer un balance del dominio para liberar el disco que se
# va a retirar.
rmvol: Removing volume '/dev/disk/dsk77c' from domain 'DWProd20'
rmvol: Removed volume '/dev/disk/dsk77c' from domain 'DWProd20'
[Esto tarda varios minutos]
Id Date Created LogPgs Version Domain Name
4360da46.0005ad20 Thu Oct 27 10:46:46 2005 512 4 DWProd20
Vol 512-Blks Free % Used Cmode Rblks Wblks Vol Name
2L 125829120 63555728 49% on 256 256 /dev/disk/dsk78c
Filesystem 1024-blocks Used Available Capacity Mounted on
r2root_dmn#root 819200 347675 464528 43% /
/proc 0 0 0 100% /proc
r2usr_dmn#usr 8388608 1876262 6261184 24% /usr
[…]
DWProd18#fs1 104857600 56 104851696 1% /wdb0103
DWProd20#fs1 62914560 23882608 31777872 43% /DWTMC/Ficheros/Entrada
DWProd20#fs2 62914560 10652 31777872 1% /DWTMC/Ficheros/Sqlloader
DWProd20#fs3 62914560 7013091 31777872 19% /DWTMC/Ficheros/Historico
DWProd20#fs4 62914560 216692 31777872 1% /DWTMC/Ficheros/Log
DWProd19#fs1 10485760 1649699 8830080 16% /intneg
Saludos,
ChaZcaZ./
Solaris 10: Agregar nuevos servicios a inetd.conf
En Solaris 10, ya no se utiliza inted.conf para levantar y/o definir los servicios que serán administrados por el demonio inetd. Todos esos servicios son manejados ahora bajo SMF.
Entonces, si se necesita agregar un servicio que sea levantado por inetd (On Demand), se debe agregar la línea correspondiente al archivo /etc/inetd.conf y luego ejecutar el comando inetconv, para que sea convertido a SMF.
En particular, cada vez que se edite el archivo /etc/inetd.conf, debe ejecutarse el comando inetconv, para que los cambios tomen efecto.
Finalmente, con svcs -a se puede ver el estado del nuevo servicio y con el comando svcadm (o inetdadm en este caso) se puede subir, bajar o reiniciar el nuevo servicio.
Saludos,
ChaZcaZ./
Entonces, si se necesita agregar un servicio que sea levantado por inetd (On Demand), se debe agregar la línea correspondiente al archivo /etc/inetd.conf y luego ejecutar el comando inetconv, para que sea convertido a SMF.
En particular, cada vez que se edite el archivo /etc/inetd.conf, debe ejecutarse el comando inetconv, para que los cambios tomen efecto.
Finalmente, con svcs -a se puede ver el estado del nuevo servicio y con el comando svcadm (o inetdadm en este caso) se puede subir, bajar o reiniciar el nuevo servicio.
Saludos,
ChaZcaZ./
Thursday, July 13, 2006
Solaris 10: Oracle 10g - System V IPC
Solaris 10 trae un nuevo cambio, que no es menor. Hasta Solaris 9, cuando se necesitaba setear los parámetros de memoria compartida, semáforos y colas de mensajes (típico para una instalación de Oracle), había que agregar los parámetros en el archivo /etc/system y reiniciar el servidor para que los cambios tomaran efecto.
Ahora, en Solaris 10, los parámetros ya no se agregan en el archivo /etc/system y para que tengan efecto no es necesario reiniciar el servidor, ya que el cambio se realiza en forma dinámica. Ahora, los parámetros se configuran en "proyectos" (project). Esto permite tener en un mismo sistema distintas instancias de Base de Datos con distintos parámetros de System V IPC, por ejemplo.
Uno puede crear projects para lo que quiera. Sin embargo, si quiere que todos los procesos y Bases de Datos tengan los mismos parámetros, sólo se cambian los parámetros en el projecto "default", al cual pertenecen todos los usuarios. En este ejemplo, se modificarán los parámetros de memoria compartida/semáforos, de acuerdo a lo solicitado por el DBA y se realizará en el proyecto default.
Antes de ir al ejemplo, mostraré algunos comandos que ayudan a trabajar con proyectos:
id -p: muestra a qué proyecto(s) pertenece el usuario.
-bash-3.00$ id -p
uid=102(chazcaz) gid=14(sysadmin) projid=3(default)
cat /etc/project: es el archivo que guarda la base de datos de proyectos. Para hacer modificaciones, se utilizan los comandos prctl y rctladm.
-bash-3.00$ cat /etc/project
system:0::::
user.root:1::::
noproject:2::::
default:3::::project.max-shm-memory=(priv,1181116006,deny)
group.staff:10::::
projects: muestra a qué proyectos pertenece o tiene acceso el usuario
-bash-3.00$ projects
default
prctl: muestra o setea "resource controls" en un proceso en ejecución, tarea o proceso.
rctladm: muestra o modifica el estado global de "system resource controls"
projmod: modifica la información de un proyecto en el sistema
Además, muchas aplicaciones permiten ahora desplegar el uso o consumo de recursos por proyectos (prstat -J, ipcs -J, etc).
Bien, ahora el ejemplo. El DBA solicita modificar los siguientes parámetros de Kernel para una instalación de Oracle 10g en un servidor corriendo Solaris10:
project.max-sem-ids 100
semsys:seminfo_semmns 1024
process.max-sem-nsems 256
semsys:seminfo_semvmx 32767
project.max-shm-memory 4294967295
project.max-shm-ids 100
Lo primero que se debe hacer, es ir a http://docs.sun.com y bajar el documento Solaris Tunable Parameters (para Solaris10) y ver si existen estos parámetros y no están obsoletos.
Al revisar el documento, se encuentro que los parámetros semsys:seminfo_semmns y semsys:semingo_semvmx están obsoletos en Solaris10 y si se llegan a agregar al arhivo /etc/system, serán ignorados. También se encuentra que para configurar el resto de parámetros, se debe hacer a través de proyectos.
Entonces, se modificaran estos paramétros del project default, ya que el usuario oracle también pertenece a este proyecto. Se pueden configurar los 4 parámetros en una línea o se pueden hacer por separado. En nuestro caso, se realizará por separado con el comando projmod:
projmod -s -K "project.max-shm-memory=(privileged,4G,deny)" 'default'
projmod -s -K "process.max-sem-nsems=(privileged,256,deny)" 'default'
projmod -s -K "project.max-sem-ids=(privileged,100,deny)" 'default'
projmod -s -K "project.max-shm-ids=(privileged,100,deny)" 'default'
Para verificar el cambio, ejecutar los comandos:
prctl -i project default
prctl -i process $$
Finalmente, un usuario puede tener acceso a varios proyectos y para cambiarse de uno a otro debe hacerlo con el comando /usr/bin/newtask -p project_name. En otro post espero poder mostrar más cosas acerca de proyectos.
Para más información de los comandos projmod, prctl, etc, ir a http://docs.sun.com/app/docs/doc/817-1592/6mhahuoj5?a=view .
Saludos,
ChaZcaZ./
Ahora, en Solaris 10, los parámetros ya no se agregan en el archivo /etc/system y para que tengan efecto no es necesario reiniciar el servidor, ya que el cambio se realiza en forma dinámica. Ahora, los parámetros se configuran en "proyectos" (project). Esto permite tener en un mismo sistema distintas instancias de Base de Datos con distintos parámetros de System V IPC, por ejemplo.
Uno puede crear projects para lo que quiera. Sin embargo, si quiere que todos los procesos y Bases de Datos tengan los mismos parámetros, sólo se cambian los parámetros en el projecto "default", al cual pertenecen todos los usuarios. En este ejemplo, se modificarán los parámetros de memoria compartida/semáforos, de acuerdo a lo solicitado por el DBA y se realizará en el proyecto default.
Antes de ir al ejemplo, mostraré algunos comandos que ayudan a trabajar con proyectos:
id -p: muestra a qué proyecto(s) pertenece el usuario.
-bash-3.00$ id -p
uid=102(chazcaz) gid=14(sysadmin) projid=3(default)
cat /etc/project: es el archivo que guarda la base de datos de proyectos. Para hacer modificaciones, se utilizan los comandos prctl y rctladm.
-bash-3.00$ cat /etc/project
system:0::::
user.root:1::::
noproject:2::::
default:3::::project.max-shm-memory=(priv,1181116006,deny)
group.staff:10::::
projects: muestra a qué proyectos pertenece o tiene acceso el usuario
-bash-3.00$ projects
default
prctl: muestra o setea "resource controls" en un proceso en ejecución, tarea o proceso.
rctladm: muestra o modifica el estado global de "system resource controls"
projmod: modifica la información de un proyecto en el sistema
Además, muchas aplicaciones permiten ahora desplegar el uso o consumo de recursos por proyectos (prstat -J, ipcs -J, etc).
Bien, ahora el ejemplo. El DBA solicita modificar los siguientes parámetros de Kernel para una instalación de Oracle 10g en un servidor corriendo Solaris10:
project.max-sem-ids 100
semsys:seminfo_semmns 1024
process.max-sem-nsems 256
semsys:seminfo_semvmx 32767
project.max-shm-memory 4294967295
project.max-shm-ids 100
Lo primero que se debe hacer, es ir a http://docs.sun.com y bajar el documento Solaris Tunable Parameters (para Solaris10) y ver si existen estos parámetros y no están obsoletos.
Al revisar el documento, se encuentro que los parámetros semsys:seminfo_semmns y semsys:semingo_semvmx están obsoletos en Solaris10 y si se llegan a agregar al arhivo /etc/system, serán ignorados. También se encuentra que para configurar el resto de parámetros, se debe hacer a través de proyectos.
Entonces, se modificaran estos paramétros del project default, ya que el usuario oracle también pertenece a este proyecto. Se pueden configurar los 4 parámetros en una línea o se pueden hacer por separado. En nuestro caso, se realizará por separado con el comando projmod:
projmod -s -K "project.max-shm-memory=(privileged,4G,deny)" 'default'
projmod -s -K "process.max-sem-nsems=(privileged,256,deny)" 'default'
projmod -s -K "project.max-sem-ids=(privileged,100,deny)" 'default'
projmod -s -K "project.max-shm-ids=(privileged,100,deny)" 'default'
Para verificar el cambio, ejecutar los comandos:
prctl -i project default
prctl -i process $$
Finalmente, un usuario puede tener acceso a varios proyectos y para cambiarse de uno a otro debe hacerlo con el comando /usr/bin/newtask -p project_name. En otro post espero poder mostrar más cosas acerca de proyectos.
Para más información de los comandos projmod, prctl, etc, ir a http://docs.sun.com/app/docs/doc/817-1592/6mhahuoj5?a=view .
Saludos,
ChaZcaZ./
Monday, July 10, 2006
Solaris 10: Resolución de Nombres
En esta versión de Solaris, nuestros amigos de Sun se pusieron creativos y cambió un poco el tema de la resolución de nombres.
En primer lugar, ahora cuando uno quiere cambiar el nombre del servidor (o su dirección IP), ahora además debe cambiar la entrada correspondiente en el nuevo archivo /etc/inet/ipnodes.
NOTA: no existe un link simbólico /etc/ipnodes, como en el caso del link /etc/hosts -> /etc/inet/hosts. Esto es una pregunta de examen para la certificación.
El archivo /etc/inet/ipnodes lo crearon ya que la tabla hosts (/etc/hosts) sólo soporta direcciones IPv4. Con ipnodes, se tiene soporte IPv4 y IPv6.
Como normalmente se ha realizado, la secuencia de resolución de nombres se hace en el archivo /etc/nsswitch.conf (notar que se ha agregado una nueva línea ipnodes: files dns).
De esta manera, la resolución de nombres tiene el siguiente flujo:
1) /etc/inet/ipnodes
2) /etc/resolv.conf
3) /etc/inet/hosts
4) /etc/resolv.conf
Si se quiere cambiar para que la resolución pregunte primero a los archivos locales y después a los DNS, se debe realizar lo siguiente en el archivo /etc/nsswitch.conf
ipnodes: files
hosts: files dns
Así, la secuencia de resolución de nombres sería:
1) /etc/inet/ipnodes
2) /etc/inet/hosts
3) /etc/resolv.conf
Saludos,
ChaZcaZ./
En primer lugar, ahora cuando uno quiere cambiar el nombre del servidor (o su dirección IP), ahora además debe cambiar la entrada correspondiente en el nuevo archivo /etc/inet/ipnodes.
NOTA: no existe un link simbólico /etc/ipnodes, como en el caso del link /etc/hosts -> /etc/inet/hosts. Esto es una pregunta de examen para la certificación.
El archivo /etc/inet/ipnodes lo crearon ya que la tabla hosts (/etc/hosts) sólo soporta direcciones IPv4. Con ipnodes, se tiene soporte IPv4 y IPv6.
Como normalmente se ha realizado, la secuencia de resolución de nombres se hace en el archivo /etc/nsswitch.conf (notar que se ha agregado una nueva línea ipnodes: files dns).
De esta manera, la resolución de nombres tiene el siguiente flujo:
1) /etc/inet/ipnodes
2) /etc/resolv.conf
3) /etc/inet/hosts
4) /etc/resolv.conf
Si se quiere cambiar para que la resolución pregunte primero a los archivos locales y después a los DNS, se debe realizar lo siguiente en el archivo /etc/nsswitch.conf
ipnodes: files
hosts: files dns
Así, la secuencia de resolución de nombres sería:
1) /etc/inet/ipnodes
2) /etc/inet/hosts
3) /etc/resolv.conf
Saludos,
ChaZcaZ./
Solaris TIPS: Performance de Discos
En estos TIPS, pondré algunas papitas que permiten analizar el rendimiento de algunos subsistemas importantes del sistema operativo (Solaris en este caso, pero los conceptos son ampliables a los otros sabores de Unix y Linux). Voy a empezar con el subsistema de I/O (discos) y después iré agregando otros subsistemas (como CPU, Memoria, etc), espero. Estos tips son en el fondo recopilaciones de ideas que he sacado de libros, blueprints, escalamientos, etc.
La "utilización" de un disco (%busy) es un parámetro muy usado. Los discos son muestreados por una interrupción con un reloj de 100MHz, para ver si estos están ocupados o no. Además, el driver envía comandos al disco y mide cuanto se demora en responder y cuanto tiempo el disco está ocioso (idle) entre comandos. Un disco con un %busy de 100 indica que no tiene tiempo libre antes de que el siguiente comando es enviado. Discos que mantienen sobre un 35% de %busy en un intervalo de 30 segundos están probablemente causando algún tipo de problema de performance.
El comando "iostat" en Solaris sin argumentos, muestra un nuevo valor: service time. Esta valor está expresado en milisegundos y corresponde al tiempo promedio tomado en completar una solicitud de I/O, incluyendo el tiempo gastado en esperar porque terminen los requerimientos que estaban primeros en la cola de I/O.
Como Decidir cuando un Disco está Sobrecargado?
El valor clave que hay que mirar es el "service time" (svc_t) del comando iostat. Este es el tiempo tomado en servir un requerimiento de I/O en el disco, incluyendo el tiempo gastado en esperar en la cola debido a que otros requerimientos están siendo procesados. En situaciones de muy alta carga, peaks grandes de service time pueden ocurrir, por lo cual es importante tener un umbral de alta carga y/o un baseline del comportamiento del subsistema de I/O. Discos que tienen un %busy sobre 20% deben ser mirados constantemente para revisar el tiempo de servicio. En general, service time de hasta 20 milisegundos son aceptables para discos de fibra (actuales). Valores mayores indican que puede existir algún tipo de cuello de botella si es que la utilización es alta constantemente.
Continuará ...
La "utilización" de un disco (%busy) es un parámetro muy usado. Los discos son muestreados por una interrupción con un reloj de 100MHz, para ver si estos están ocupados o no. Además, el driver envía comandos al disco y mide cuanto se demora en responder y cuanto tiempo el disco está ocioso (idle) entre comandos. Un disco con un %busy de 100 indica que no tiene tiempo libre antes de que el siguiente comando es enviado. Discos que mantienen sobre un 35% de %busy en un intervalo de 30 segundos están probablemente causando algún tipo de problema de performance.
El comando "iostat" en Solaris sin argumentos, muestra un nuevo valor: service time. Esta valor está expresado en milisegundos y corresponde al tiempo promedio tomado en completar una solicitud de I/O, incluyendo el tiempo gastado en esperar porque terminen los requerimientos que estaban primeros en la cola de I/O.
Como Decidir cuando un Disco está Sobrecargado?
El valor clave que hay que mirar es el "service time" (svc_t) del comando iostat. Este es el tiempo tomado en servir un requerimiento de I/O en el disco, incluyendo el tiempo gastado en esperar en la cola debido a que otros requerimientos están siendo procesados. En situaciones de muy alta carga, peaks grandes de service time pueden ocurrir, por lo cual es importante tener un umbral de alta carga y/o un baseline del comportamiento del subsistema de I/O. Discos que tienen un %busy sobre 20% deben ser mirados constantemente para revisar el tiempo de servicio. En general, service time de hasta 20 milisegundos son aceptables para discos de fibra (actuales). Valores mayores indican que puede existir algún tipo de cuello de botella si es que la utilización es alta constantemente.
Continuará ...
Wednesday, July 05, 2006
Solaris versus HP-UX
Esto lo encontré en el siguiente website:
http://loudermilk.org/software/solaris-hpux.html
Lo encontré interesante y por eso lo coloco acá (ya que alguna vez la web original puede dejar de existir).
Solaris versus HP-UX
Background
I got my start as a UNIX sysadmin using Solaris back in college, and I've been a fan of Solaris ever since. Where I work, there is often talk of Sun versus HP for large UNIX systems, and I am always a proponent of Sun's systems, mainly because of Solaris.
Many people are quick to dismiss my opinion as a simple personal preference, thinking that since I'm more familiar with Solaris I'm basing my opinion on my emotions and not giving HP fair consideration. I have spent a decent amount of time on HP-UX, though, and I have created the list below to detail the reasons why I believe that from a system administrator's perspective, Solaris is a superior operating system to HP-UX.
For the comparison, I chose relatively older but still very popular versions of both operating systems:
Solaris 8 (also known as SunOS 5.8 or Solaris 2.8), released in 2000
HP-UX 11iv1 (also known as HP-UX 11.11), released in 2000
To be fair, I have found many features of HP-UX that I am quite fond of and wish Solaris had. I've pointed those out below as well.
What HP-UX gets wrong
No shadow passwords by default. Shadow passwords are possible, but you have to turn them on after installing the OS. Not having these is a huge security issue, and HP turns a blind eye toward it by making the administrator fix the gaping out-of-the-box security hole.
No process-tracing program by default. Out of the box, HP-UX has no equivalent of the Solaris truss or Linux strace program to let you trace a process' system calls. One is available (tusc), but it's on a supplemental CD. This is an essential tool of any operating system, and should be available on every installation.
No /usr/proc/bin-equivalent tools at all. The Solaris /usr/proc/bin utilities are incredibly useful. There's pstack to show you a process' stack (for each thread), psig to see the signal handlers for a process, ptree to draw an ASCII chart of a process' parents and children, and several others. Most of these aren't tools you need all the time, but when you need them, there is no substitute. HP-UX has none of these.
Difficult to tell how much physical memory is installed. This came as quite a shock to me, but there's no sure-fire, easy way to quickly see how much memory is installed in an HP-UX system. The most common answer I see to this question is to run dmesg and look for a particular message that was logged at boot time, but that doesn't work your system has been up a long time. There's a C interface to get this information, but no built-in command line utility. I eventually wrote a simple C program to return the amount of physical memory, but it shouldn't be that hard.
Difficult to tell if you have a more recent version of a particular patch installed. Let's suppose you hear about a security vulnerability in your OS, and the vendor has already released a patch. You want to check whether you already have this patch (or a later version of it) installed on your system, but this is difficult with HP-UX. With Solaris, the patch you're checking for would be named something like 123456-02. Any later versions of that patch would begin with "123456-" and increment the last number, so it's easy to see if you have the patch in question or later (meaning you don't need to worry about the issue the patch resolved). With HP-UX, the patch you're looking for would be named something like PHKL_12345, but any later versions of it would have completely different numbers. There's no way to easily tell if you have a later version of that patch — all you can easily tell is if you have the version in question or not.
Can't use @ or # characters in passwords by default. By default, the @ and # characters won't work in passwords because /bin/login interprets them as kill and erase, respectively. Sure, you can fix this, but would you ever have expected this? Suppose you're running a mixed environment, where the HP-UX systems use NIS or LDAP to use passwords created on another platform. Any users with these characters in their passwords won't be able to log in. Maybe these terminal settings were useful twenty years ago when we used our UNIX servers to connect dozens of 80-character terminals, but those days are long gone, and this default is ridiculous.
Can't tell what a device is from its hardware path. Maybe I'm just stupid, but I could stare at the HP-UX hardware paths for devices all day without realizing that 0/1/1/0.1.0 is a disk and 0/4/1/0 is a network adapter. In Solaris, those would be more like /devices/pci@1f,4000/scsi@3/sd@0,0:a for the disk and /devices/pseudo/clone@0:hme for the network adapter. These seem just as arbitrary at first, but there are clues in the pathnames: "sd" is the driver for SCSI disks, and "hme" is the driver for hundred-megabit Ethernet NICs.
No single command to shut down and power off. In Solaris, an init 5 will shut down and power off, and an init 0 will shut down and halt. HP-UX gives you only the latter, and if you're shutting down a system for hardware replacement, your only choice is to shutdown -h, wait for the console message that says it's okay to power off, and either physically power off then, or log in to the MP/GSP and issue the poweroff there.
The kernel must be relinked when tunables are changed. I thought we were past the days when you needed a compiler and some source code to make a tuning change to the kernel, but HP-UX isn't. Where Solaris would just need an edit to /etc/system, HP-UX needs to update some header files and relink the kernel.
Kernel tunable defaults are not reasonable. The HP-UX defaults for lots of tunables look like they haven't been updated in 15 years. For example, the default for the maximum number of processes any non-root user can have running (maxuprc) is 75.
Startup scripts belong in /etc, not /sbin. Most System V unices place startup scripts in /etc/init.d and /etc/rc?.d, but HP-UX puts them in /sbin/init.d and /sbin/rc?.d. If it was 20 years ago and we were having a debate about where the startup scripts should go, I'd vote for /sbin instead of /etc. But other vendors have been doing things one way for 20 years, and HP-UX could at least give admins coming from another flavor of UNIX the courtesy of a symlink. But they don't.
Huge copyright message at every login. If you've never logged in to a HP-UX system before, you're missing out — your login is greeted by a 28-line list of copyright messages. Every time. Is this really necessary? Somehow, I doubt Sun is jeopardizing their copyrights to Solaris by not assaulting their users with these notices dozens of times each day.
Syslog rotation is inadequate. HP-UX's idea of rotating the syslog is to copy syslog.log to OLDsyslog.log when the system boots. That leaves you with not much logging at all if you boot your system frequently, or probably too much logging if you rarely boot your system. Now, Solaris 8 isn't too much better at log rotation, but it rotates your syslog once a week and keeps four old copies in addition to the current one, so you always know how much log information you have. With HP-UX, you may have a little or you may have a lot. You'll probably never know until you need some old information and don't have it.
Sendmail configuration is painful. HP-UX doesn't give you the m4 configuration files for sendmail so that you can use the m4 macros to generate a sendmail.cf. Instead, they expect you to hack sendmail.cf directly. This is not the way sendmail is intended to be configured.
Load average calculations are different. In HP-UX, unlike Solaris, Linux, or just about any other UNIX, load averages reported by uptime are divided by the number of processors in the system, so that a load average of 1.0 means the system has as many processes in the run queue as it has processors. That's all well and good, and it might even be a better approach than the other vendors, but once again HP-UX breaks with tradition and confuses administrators of other platforms.
You need a patch and special mount option to read a CD-ROM with RockRidge extensions. The ISO9660 filesystem format, used on CD-ROMs, limits the filenames to 8.3-character names. RockRidge extensions allow longer filenames and allow UNIX file permissions to be stored on the CD-ROM. HP-UX is the only UNIX I've encountered that doesn't handle this format natively. Not only do you need a patch to support it, but you have to mount your CD-ROM with -o rr to read RockRidge extensions.
Swap volumes/files can not be removed on the fly. HP-UX lets you add a new swap volume or file while the system is running, but to remove it you have to reboot.
There is no /etc/nsswitch.conf. By default, there is no /etc/nsswitch.conf, and name service switch library uses compiled-in defaults. If you don't want to use the mysterious defaults, just create a file of your own.
Manual device file creation for LVM. LVM is nice, but when I create a volume group, I really shouldn't have to run mknod myself and stick a device file in /dev/vgxx.
What HP-UX gets right
Believe it or not, I actually do like quite a few things about HP-UX. They are outweighed in importance by the things I don't like, but I list them here nonetheless to prove I'm not just mean.
Startup/shutdown log. Many times I've watched a Solaris system boot and have seen a startup script print an error message. As soon as I can think, "hey, something's not right," it's off the screen and lost forever. HP-UX saves the output of the startup and shutdown scripts in a /etc/rc.log, so you can investigate any failures later. Don't beat them up about logging to /etc — /var isn't mounted when they need to start writing to the log.
Startup/shutdown messages are pretty. Instead of showing me stdout/stderr from every startup and shutdown script, HP-UX gives me a one-line summary of each thing it's doing, like "Starting NFS Server," and then either "OK" or "FAIL." This is nice, since some Solaris startup scripts print several lines of output and others print none at all. And since the detailed output is logged elsewhere, I don't lose any information.
Boot-up can be interrupted. If you're booting HP-UX, and you notice that a critical service failed to start, you can interrupt the boot with control-backslash, get a shell, and debug it immediately, rather than waiting for the system to come all the way up. This is useful when the service you're trying to debug is so critical that you know you'll need to reboot after making the fix anyway.
/etc/rc.config.d is nice. Most of the configuration of daemons that in Solaris would be done by editing various per-daemon configuration files in /etc is done in HP-UX by editing files in /etc/rc.config.d and setting the values of predefined variables. These files are sourced by the init.d startup scripts, and tell them things like whether an NFS server should start, where's the NTP server, what IP address should an interface have, etc. It's a more consistent interface to the system's configuration.
Kernel tunables can be set in terms of other tunables. You can choose to set a tunable's value absolutely — say, to 1024 — or in terms of another tunable — for example, to maxuprc * 10. This is pretty nice, since you can edit fewer tunables and have the relative ones scale automatically. This feature was removed in HP-UX 11iv2, though.
fstab is a better name than vfstab. Sorry, Solaris — /etc/vfstab should be /etc/fstab, because that's what everybody else calls it.
Patch rating system. Every HP-UX patch has a rating, so you can tell how widely used the patch is and how thoroughly tested it has been.
Downloaded patches can be bundled into a depot. When you download patches from HP's web site, you have the option of making the patches into a software depot. If you're installing them on multiple systems, this makes it a lot easier than managing all the patches individually.
Separation of analyze phase from install phase for software/patch installation. HP-UX's software distribution system (SD-UX) separates the analyze phase (checking disk space, checking prerequisites, etc.) from the installation phase when installing patches or software. With a bundle of patches, this can be a big time saver. You can perform the analyze phase for all the patches ahead of time, which won't modify anything on the system, and do the installation phase during your system's maintenance window. In Solaris, patches take a long time to install, and much of the time is spent calculating whether or not the patch should be applied at all.
The output of ioscan is easier to read than prtconf. If I want to quickly see what devices are attached to the system, HP-UX's ioscan is much easier to read than Solaris' prtconf. Of course, tea leaves are probably easier to read than prtconf, so that's not saying much.
Saludos,
ChaZcaZ
http://loudermilk.org/software/solaris-hpux.html
Lo encontré interesante y por eso lo coloco acá (ya que alguna vez la web original puede dejar de existir).
Solaris versus HP-UX
Background
I got my start as a UNIX sysadmin using Solaris back in college, and I've been a fan of Solaris ever since. Where I work, there is often talk of Sun versus HP for large UNIX systems, and I am always a proponent of Sun's systems, mainly because of Solaris.
Many people are quick to dismiss my opinion as a simple personal preference, thinking that since I'm more familiar with Solaris I'm basing my opinion on my emotions and not giving HP fair consideration. I have spent a decent amount of time on HP-UX, though, and I have created the list below to detail the reasons why I believe that from a system administrator's perspective, Solaris is a superior operating system to HP-UX.
For the comparison, I chose relatively older but still very popular versions of both operating systems:
Solaris 8 (also known as SunOS 5.8 or Solaris 2.8), released in 2000
HP-UX 11iv1 (also known as HP-UX 11.11), released in 2000
To be fair, I have found many features of HP-UX that I am quite fond of and wish Solaris had. I've pointed those out below as well.
What HP-UX gets wrong
No shadow passwords by default. Shadow passwords are possible, but you have to turn them on after installing the OS. Not having these is a huge security issue, and HP turns a blind eye toward it by making the administrator fix the gaping out-of-the-box security hole.
No process-tracing program by default. Out of the box, HP-UX has no equivalent of the Solaris truss or Linux strace program to let you trace a process' system calls. One is available (tusc), but it's on a supplemental CD. This is an essential tool of any operating system, and should be available on every installation.
No /usr/proc/bin-equivalent tools at all. The Solaris /usr/proc/bin utilities are incredibly useful. There's pstack to show you a process' stack (for each thread), psig to see the signal handlers for a process, ptree to draw an ASCII chart of a process' parents and children, and several others. Most of these aren't tools you need all the time, but when you need them, there is no substitute. HP-UX has none of these.
Difficult to tell how much physical memory is installed. This came as quite a shock to me, but there's no sure-fire, easy way to quickly see how much memory is installed in an HP-UX system. The most common answer I see to this question is to run dmesg and look for a particular message that was logged at boot time, but that doesn't work your system has been up a long time. There's a C interface to get this information, but no built-in command line utility. I eventually wrote a simple C program to return the amount of physical memory, but it shouldn't be that hard.
Difficult to tell if you have a more recent version of a particular patch installed. Let's suppose you hear about a security vulnerability in your OS, and the vendor has already released a patch. You want to check whether you already have this patch (or a later version of it) installed on your system, but this is difficult with HP-UX. With Solaris, the patch you're checking for would be named something like 123456-02. Any later versions of that patch would begin with "123456-" and increment the last number, so it's easy to see if you have the patch in question or later (meaning you don't need to worry about the issue the patch resolved). With HP-UX, the patch you're looking for would be named something like PHKL_12345, but any later versions of it would have completely different numbers. There's no way to easily tell if you have a later version of that patch — all you can easily tell is if you have the version in question or not.
Can't use @ or # characters in passwords by default. By default, the @ and # characters won't work in passwords because /bin/login interprets them as kill and erase, respectively. Sure, you can fix this, but would you ever have expected this? Suppose you're running a mixed environment, where the HP-UX systems use NIS or LDAP to use passwords created on another platform. Any users with these characters in their passwords won't be able to log in. Maybe these terminal settings were useful twenty years ago when we used our UNIX servers to connect dozens of 80-character terminals, but those days are long gone, and this default is ridiculous.
Can't tell what a device is from its hardware path. Maybe I'm just stupid, but I could stare at the HP-UX hardware paths for devices all day without realizing that 0/1/1/0.1.0 is a disk and 0/4/1/0 is a network adapter. In Solaris, those would be more like /devices/pci@1f,4000/scsi@3/sd@0,0:a for the disk and /devices/pseudo/clone@0:hme for the network adapter. These seem just as arbitrary at first, but there are clues in the pathnames: "sd" is the driver for SCSI disks, and "hme" is the driver for hundred-megabit Ethernet NICs.
No single command to shut down and power off. In Solaris, an init 5 will shut down and power off, and an init 0 will shut down and halt. HP-UX gives you only the latter, and if you're shutting down a system for hardware replacement, your only choice is to shutdown -h, wait for the console message that says it's okay to power off, and either physically power off then, or log in to the MP/GSP and issue the poweroff there.
The kernel must be relinked when tunables are changed. I thought we were past the days when you needed a compiler and some source code to make a tuning change to the kernel, but HP-UX isn't. Where Solaris would just need an edit to /etc/system, HP-UX needs to update some header files and relink the kernel.
Kernel tunable defaults are not reasonable. The HP-UX defaults for lots of tunables look like they haven't been updated in 15 years. For example, the default for the maximum number of processes any non-root user can have running (maxuprc) is 75.
Startup scripts belong in /etc, not /sbin. Most System V unices place startup scripts in /etc/init.d and /etc/rc?.d, but HP-UX puts them in /sbin/init.d and /sbin/rc?.d. If it was 20 years ago and we were having a debate about where the startup scripts should go, I'd vote for /sbin instead of /etc. But other vendors have been doing things one way for 20 years, and HP-UX could at least give admins coming from another flavor of UNIX the courtesy of a symlink. But they don't.
Huge copyright message at every login. If you've never logged in to a HP-UX system before, you're missing out — your login is greeted by a 28-line list of copyright messages. Every time. Is this really necessary? Somehow, I doubt Sun is jeopardizing their copyrights to Solaris by not assaulting their users with these notices dozens of times each day.
Syslog rotation is inadequate. HP-UX's idea of rotating the syslog is to copy syslog.log to OLDsyslog.log when the system boots. That leaves you with not much logging at all if you boot your system frequently, or probably too much logging if you rarely boot your system. Now, Solaris 8 isn't too much better at log rotation, but it rotates your syslog once a week and keeps four old copies in addition to the current one, so you always know how much log information you have. With HP-UX, you may have a little or you may have a lot. You'll probably never know until you need some old information and don't have it.
Sendmail configuration is painful. HP-UX doesn't give you the m4 configuration files for sendmail so that you can use the m4 macros to generate a sendmail.cf. Instead, they expect you to hack sendmail.cf directly. This is not the way sendmail is intended to be configured.
Load average calculations are different. In HP-UX, unlike Solaris, Linux, or just about any other UNIX, load averages reported by uptime are divided by the number of processors in the system, so that a load average of 1.0 means the system has as many processes in the run queue as it has processors. That's all well and good, and it might even be a better approach than the other vendors, but once again HP-UX breaks with tradition and confuses administrators of other platforms.
You need a patch and special mount option to read a CD-ROM with RockRidge extensions. The ISO9660 filesystem format, used on CD-ROMs, limits the filenames to 8.3-character names. RockRidge extensions allow longer filenames and allow UNIX file permissions to be stored on the CD-ROM. HP-UX is the only UNIX I've encountered that doesn't handle this format natively. Not only do you need a patch to support it, but you have to mount your CD-ROM with -o rr to read RockRidge extensions.
Swap volumes/files can not be removed on the fly. HP-UX lets you add a new swap volume or file while the system is running, but to remove it you have to reboot.
There is no /etc/nsswitch.conf. By default, there is no /etc/nsswitch.conf, and name service switch library uses compiled-in defaults. If you don't want to use the mysterious defaults, just create a file of your own.
Manual device file creation for LVM. LVM is nice, but when I create a volume group, I really shouldn't have to run mknod myself and stick a device file in /dev/vgxx.
What HP-UX gets right
Believe it or not, I actually do like quite a few things about HP-UX. They are outweighed in importance by the things I don't like, but I list them here nonetheless to prove I'm not just mean.
Startup/shutdown log. Many times I've watched a Solaris system boot and have seen a startup script print an error message. As soon as I can think, "hey, something's not right," it's off the screen and lost forever. HP-UX saves the output of the startup and shutdown scripts in a /etc/rc.log, so you can investigate any failures later. Don't beat them up about logging to /etc — /var isn't mounted when they need to start writing to the log.
Startup/shutdown messages are pretty. Instead of showing me stdout/stderr from every startup and shutdown script, HP-UX gives me a one-line summary of each thing it's doing, like "Starting NFS Server," and then either "OK" or "FAIL." This is nice, since some Solaris startup scripts print several lines of output and others print none at all. And since the detailed output is logged elsewhere, I don't lose any information.
Boot-up can be interrupted. If you're booting HP-UX, and you notice that a critical service failed to start, you can interrupt the boot with control-backslash, get a shell, and debug it immediately, rather than waiting for the system to come all the way up. This is useful when the service you're trying to debug is so critical that you know you'll need to reboot after making the fix anyway.
/etc/rc.config.d is nice. Most of the configuration of daemons that in Solaris would be done by editing various per-daemon configuration files in /etc is done in HP-UX by editing files in /etc/rc.config.d and setting the values of predefined variables. These files are sourced by the init.d startup scripts, and tell them things like whether an NFS server should start, where's the NTP server, what IP address should an interface have, etc. It's a more consistent interface to the system's configuration.
Kernel tunables can be set in terms of other tunables. You can choose to set a tunable's value absolutely — say, to 1024 — or in terms of another tunable — for example, to maxuprc * 10. This is pretty nice, since you can edit fewer tunables and have the relative ones scale automatically. This feature was removed in HP-UX 11iv2, though.
fstab is a better name than vfstab. Sorry, Solaris — /etc/vfstab should be /etc/fstab, because that's what everybody else calls it.
Patch rating system. Every HP-UX patch has a rating, so you can tell how widely used the patch is and how thoroughly tested it has been.
Downloaded patches can be bundled into a depot. When you download patches from HP's web site, you have the option of making the patches into a software depot. If you're installing them on multiple systems, this makes it a lot easier than managing all the patches individually.
Separation of analyze phase from install phase for software/patch installation. HP-UX's software distribution system (SD-UX) separates the analyze phase (checking disk space, checking prerequisites, etc.) from the installation phase when installing patches or software. With a bundle of patches, this can be a big time saver. You can perform the analyze phase for all the patches ahead of time, which won't modify anything on the system, and do the installation phase during your system's maintenance window. In Solaris, patches take a long time to install, and much of the time is spent calculating whether or not the patch should be applied at all.
The output of ioscan is easier to read than prtconf. If I want to quickly see what devices are attached to the system, HP-UX's ioscan is much easier to read than Solaris' prtconf. Of course, tea leaves are probably easier to read than prtconf, so that's not saying much.
Saludos,
ChaZcaZ
sar, iostat, mpstat en Linux
En Linux, los utilitarios sar, iostat, mpstat y otros vienen en un paquete que se llama "systat". En Ubuntu es fácil instalarlo, mediante apt-get o a través de la aplicación GUI Synaptic.
Saludos,
ChaZcaZ./
Saludos,
ChaZcaZ./
Blogs con música de la buena
- En este Blog postean mucha música, harto progresivo y música buena en general. Muy recomendable:
http://sonidosdeverdad.blogspot.com/
- Este Blog es parecido al anterior, pero se basa principalmente en guitarristas virtuosos. Está bueno para conocer nuevos músicos:
http://virtuososguitarristas.blogspot.com/
Saludos,
ChaZcaZ./
http://sonidosdeverdad.blogspot.com/
- Este Blog es parecido al anterior, pero se basa principalmente en guitarristas virtuosos. Está bueno para conocer nuevos músicos:
http://virtuososguitarristas.blogspot.com/
Saludos,
ChaZcaZ./
Friday, April 28, 2006
Limpiar flag FAILING cuando vxdisk list muestra status "online failing"
Durante una falla que cause que VERITAS Volume Manager vea un disco como failing cuando en realidad el disco no está malo, el flag failing del disco puede ser limpiado. Sin embargo, esto no se debe hacer cuando el status de un disco es unknown.
1) Listar los discos bajo VxVM para determinar cual disco está marcado como malo:
# vxdisk list
2) Limpiar el flag failing del disco que está marcado como failing:
# vxedit -g nombre_disk_group set failing=off nombre_disco
1) Listar los discos bajo VxVM para determinar cual disco está marcado como malo:
# vxdisk list
DEVICE TYPE DISK GROUP STATUS
c0t1d0s2 sliced disk01 rootdg online failing
c0t3d0s2 sliced rootdisk rootdg online
........(mas)
2) Limpiar el flag failing del disco que está marcado como failing:
# vxedit -g nombre_disk_group set failing=off nombre_disco
PID de un puerto abierto en Unix
Con el comando lsof se puede saber el PID del proceso owner que tiene un puerto abierto.
# lsof -i TCP:80
También es posible conocer los archivos abiertos por una dirección IP. Ejemplo:
# lsof -i TCP@172.20.77.162
En Linux lsof viene instalado por default. En Solaris hay que bajarlo (http://www.sunfreeware.com).
# lsof -i TCP:80
También es posible conocer los archivos abiertos por una dirección IP. Ejemplo:
# lsof -i TCP@172.20.77.162
FTP umask setting en HP-UX
El demonio ftp (ftpd) usa una configuración interna de umask, por default es 027.
Esto puede ser cambiado editando la entrada ftpd del archivo /etc/inted.conf. Por ejemplo, para cambiar el umask de ftpd a 022, la línea ftpd de /etc/inetd.conf debe ser como sigue:
ftp stream tcp nowait root /usr/lbin/ftpd ftpd -l -u 22
Luego se debe reiniciar inetd para que los cambios tengan efecto, con el siguiente comando:
# inetd -c
Esto puede ser cambiado editando la entrada ftpd del archivo /etc/inted.conf. Por ejemplo, para cambiar el umask de ftpd a 022, la línea ftpd de /etc/inetd.conf debe ser como sigue:
ftp stream tcp nowait root /usr/lbin/ftpd ftpd -l -u 22
Luego se debe reiniciar inetd para que los cambios tengan efecto, con el siguiente comando:
# inetd -c
Montar CD en HP-UX
Si se quiere montar un CDROM ISO 9660 en HP-UX, se tienen que iniciar los demonios pfs_mountd y pfsd.
# /usr/sbin/pfs_mountd &
[1] 1969
# /usr/sbin/pfsd &
[2] 1970
Editar o crear el archivo:
/etc/pfs_fstab
con el siguiente contenido:
/dev/dsk/c0t4d0 /ISO_CDROM pfs-iso9660 xlat=unix 0 0
/dev/dsk/c0t4d0 /ISO_RR_CDROM pfs-rrip xlat=unix 0 0
Crear los directorios, si no existen:
# ls -ld /ISO*
drwxr-xr-x 2 root root 28 Apr 2 11:20 ISO_CDROM
drwxr-xr-x 2 root root 28 Apr 2 11:20 ISO_RR_CDROM
Ahora se pueden montar los CDROMs:
# pfs_mount /ISO_CDROM
Y para desmontar:
# pfs_umount /ISO_CDROM
# /usr/sbin/pfs_mountd &
[1] 1969
# /usr/sbin/pfsd &
[2] 1970
Editar o crear el archivo:
/etc/pfs_fstab
con el siguiente contenido:
/dev/dsk/c0t4d0 /ISO_CDROM pfs-iso9660 xlat=unix 0 0
/dev/dsk/c0t4d0 /ISO_RR_CDROM pfs-rrip xlat=unix 0 0
Crear los directorios, si no existen:
# ls -ld /ISO*
drwxr-xr-x 2 root root 28 Apr 2 11:20 ISO_CDROM
drwxr-xr-x 2 root root 28 Apr 2 11:20 ISO_RR_CDROM
Ahora se pueden montar los CDROMs:
# pfs_mount /ISO_CDROM
Y para desmontar:
# pfs_umount /ISO_CDROM
Información útil de un servidor HP-UX (como un explorer)
El comando /opt/ignite/bin/print_manifest entrega información acerca del Modelo del Servidor, mamoria, procesadores, bits en que está corriendo el Sistema Operativo, dispositivos, versión del S.O., paquetes instalados, Disk y FileSystem Layout, parámetros de Kernel e información de Red.
Es una información útil que siempre se debiera tener a mano. No es tan completa como la información que se puede obtener de un explorer en Solaris (/opt/SUNWexplo/bin/explorer), pero cumple su objetivo.
Es una información útil que siempre se debiera tener a mano. No es tan completa como la información que se puede obtener de un explorer en Solaris (/opt/SUNWexplo/bin/explorer), pero cumple su objetivo.
Thursday, April 27, 2006
Acceso root remoto - ALLOW DENY
Para permitir o denegar el acceso root remoto (telnet, rlogin, etc), se deben modificar ciertos archivos dependiendo del sistema operativo. A continuación se muestra como configurar esto en Sun Solaris, Hp-UX y Tru64.
Sun Solaris
========
El archivo /etc/default/login controla el acceso como root al sistema. Existen varias opciones de configuración. Las más utilizadas son:
1) Permitir acceso root desde cualquier parte. Para esto, se debe comentar la línea CONSOLE, para que quede de la siguiente manera:
#CONSOLE=/dev/console
2) Sólo permitir que root se pueda logear desde la consola serial. Para esto, descomentar la línea CONSOLE, para que quede de la siguiente manera:
CONSOLE=/dev/console
3) Sólo permitir que root se pueda logear en modo Single-User. Para esto, la línea CONSOLE debe estar descomentada y sin ningún valor, como el siguiente ejemplo:
CONSOLE=
HP-UX
=====
En HP-UX, el control de acceso a root se establece con el archivo /etc/securetty. Si este archivo existe, entonces login security está activo. Si no existe el archivo, entonces no hay reestricción para que el root se conecte desde cualquier device. Algunos ejemplos son:
1) Restringir acceso root sólo a consola. Para esto, el archivo debe contener la línea:
console
2) Permitir acceso root a través de telnet. Para esto, el archivo debe contener la línea:
tty
3) Permitir acceso root a través de rlogin. Para esto, el archivo debe contener la línea:
pts
Tru64
=====
El control de acceso a root se establece con el archivo /etc/securettys. Algunos ejemplos son:
1) Restringir acceso root sólo a consola. El archivo sólo debe contener la línea:
/dev/console
2) Permitir acceso a través de telnet, rlogin. El archivo debe contener la línea:
ptys
Sun Solaris
========
El archivo /etc/default/login controla el acceso como root al sistema. Existen varias opciones de configuración. Las más utilizadas son:
1) Permitir acceso root desde cualquier parte. Para esto, se debe comentar la línea CONSOLE, para que quede de la siguiente manera:
#CONSOLE=/dev/console
2) Sólo permitir que root se pueda logear desde la consola serial. Para esto, descomentar la línea CONSOLE, para que quede de la siguiente manera:
CONSOLE=/dev/console
3) Sólo permitir que root se pueda logear en modo Single-User. Para esto, la línea CONSOLE debe estar descomentada y sin ningún valor, como el siguiente ejemplo:
CONSOLE=
HP-UX
=====
En HP-UX, el control de acceso a root se establece con el archivo /etc/securetty. Si este archivo existe, entonces login security está activo. Si no existe el archivo, entonces no hay reestricción para que el root se conecte desde cualquier device. Algunos ejemplos son:
1) Restringir acceso root sólo a consola. Para esto, el archivo debe contener la línea:
console
2) Permitir acceso root a través de telnet. Para esto, el archivo debe contener la línea:
tty
3) Permitir acceso root a través de rlogin. Para esto, el archivo debe contener la línea:
pts
Tru64
=====
El control de acceso a root se establece con el archivo /etc/securettys. Algunos ejemplos son:
1) Restringir acceso root sólo a consola. El archivo sólo debe contener la línea:
/dev/console
2) Permitir acceso a través de telnet, rlogin. El archivo debe contener la línea:
ptys
Cambio de zona horaria (Timezone) en Unix
A continuación se muestra como cambiar la Zonar Horaria (Timezone) en los sistemas operativos Sun Solaris, HP-UX, Tru64 y Linux Ubuntu.
Recordar que en Chile la hora se cambia 2 veces al año, por lo cual la zona horaria que se seleccione debe soportar estos cambios.
Sun Solaris
========
La zona horaria en Solaris se configura en el archivo /etc/TIMEZONE. Para el caso de Chile (que soporte los cambios de hora de invierno y verano) el archivo debe contener la siguiente línea:
TZ=Chile/Continental
HP-UX
=====
Para el caso de HP-UX, no existe una zona horaria de Chile que soporte cambio de hora. Para este caso, HP creó una nueva zona que se debe agregar manualmente al archivo donde residen las zonas horarias.
Para configurar la zona horaria que soporta cambio de hora, se debe realizar lo siguiente:
1) Agregar al final del archivo /usr/lib/tztab lo siguiente:
PST4SST
Tru64
=====
En Tru64, la zona horaria se define en el directorio /etc/zoneinfo/ y se establece haciendo un link a la zona que se requiere del archivo localtime.
Ejemplo:
lrwxrwxrwx 1 root system 19 Sep 1123:55 localtime -> ./Chile/Continental
===========
En Linux (la mayoría) el archivo /etc/localtime es el archivo de configuración de zona horaria. En realidad es un link simbólico al archivo de Zona. Por ejemplo, para tener configurada la Zona Santiago de Chile, así debe estar configurado:
lrwxrwxrwx 1 root root 36 2006-04-24 12:14 /etc/localtime -> /usr/share/zoneinfo/America/Santiago
En algunas distribuciones en lugar de hacer el Link Simbólico copian el archivo (en este caso Santiago) a /etc/localtime.
Recordar que en Chile la hora se cambia 2 veces al año, por lo cual la zona horaria que se seleccione debe soportar estos cambios.
Sun Solaris
========
La zona horaria en Solaris se configura en el archivo /etc/TIMEZONE. Para el caso de Chile (que soporte los cambios de hora de invierno y verano) el archivo debe contener la siguiente línea:
TZ=Chile/Continental
HP-UX
=====
Para el caso de HP-UX, no existe una zona horaria de Chile que soporte cambio de hora. Para este caso, HP creó una nueva zona que se debe agregar manualmente al archivo donde residen las zonas horarias.
Para configurar la zona horaria que soporta cambio de hora, se debe realizar lo siguiente:
1) Agregar al final del archivo /usr/lib/tztab lo siguiente:
PST4SST
0 23 8-14 3 1983-2038 6 PST4
0 1 9-14 10 1983-2038 0 SST3
NOTA: los numeros que aparecen en rojo son una modificación que realizó HP a esta zona horaria, puesto que con la configuracion antigua (0 1 8-14 10 1983-2038 0 SST3) la hora cambió una semana antes en Octubre del 2006.
TZ=PST4SST
export TZ
Tru64
=====
En Tru64, la zona horaria se define en el directorio /etc/zoneinfo/ y se establece haciendo un link a la zona que se requiere del archivo localtime.
Ejemplo:
lrwxrwxrwx 1 root system 19 Sep 11
===========
En Linux (la mayoría) el archivo /etc/localtime es el archivo de configuración de zona horaria. En realidad es un link simbólico al archivo de Zona. Por ejemplo, para tener configurada la Zona Santiago de Chile, así debe estar configurado:
lrwxrwxrwx 1 root root 36 2006-04-24 12:14 /etc/localtime -> /usr/share/zoneinfo/America/Santiago
En algunas distribuciones en lugar de hacer el Link Simbólico copian el archivo (en este caso Santiago) a /etc/localtime.
Wednesday, April 26, 2006
Export Display remoto en Ubuntu 5.10 Breezy Badger
En Ubuntu, por defecto no se permite abrir alguna aplicacion X desde un servidor remoto (por ejemplo, si en Ubuntu se hace un xhost + y en el servidor remoto se exporta el DISPLAY hacia Ubuntu, no se podra abrir la aplicacion X en Ubuntu(.
Esto se debe a que el servidor X de Ubuntu no escucha por peticiones TCP remotas. Para mejorar esta situacion se debe modificar el archivo xserverrc. Para esto, se debe hacer lo siguiente:
1) sudo vi /etc/X11/xinit/xserverrc
2) Eliminar la opcion "-nolisten tcp", para que la linea quede de la siguiente forma: exec /usr/bin/X11/X -dpi 100
3) Reiniciar el servidor X, con: sudo /etc/init.d/gdm restart
Con esto ya se podra exporta el DISPLAY hacia Ubuntu y desplegar aplicaciones X. Como prueba, hacer lo siguiente>
En Ubuntu:
---------------
- Abrir un terminal y ejecutar: xhost +ip_servidor_remoto
En servidor remoto:
-------------------------
- En un terminal, exportar el DISPLAY con los comandos:
DISPLAY=ip_Ubuntu:0.0
export DISPLAY
- Ejecutar una aplicacion X, por ejemplo, xterm
Si la prueba es satisfactoria, se debiera abrir una ventana de xterm en Ubuntu.
Saludos,
ChaZcaZ./
Esto se debe a que el servidor X de Ubuntu no escucha por peticiones TCP remotas. Para mejorar esta situacion se debe modificar el archivo xserverrc. Para esto, se debe hacer lo siguiente:
1) sudo vi /etc/X11/xinit/xserverrc
2) Eliminar la opcion "-nolisten tcp", para que la linea quede de la siguiente forma: exec /usr/bin/X11/X -dpi 100
3) Reiniciar el servidor X, con: sudo /etc/init.d/gdm restart
Con esto ya se podra exporta el DISPLAY hacia Ubuntu y desplegar aplicaciones X. Como prueba, hacer lo siguiente>
En Ubuntu:
---------------
- Abrir un terminal y ejecutar: xhost +ip_servidor_remoto
En servidor remoto:
-------------------------
- En un terminal, exportar el DISPLAY con los comandos:
DISPLAY=ip_Ubuntu:0.0
export DISPLAY
- Ejecutar una aplicacion X, por ejemplo, xterm
Si la prueba es satisfactoria, se debiera abrir una ventana de xterm en Ubuntu.
Saludos,
ChaZcaZ./
Subscribe to:
Posts (Atom)