Seguimos repasando algunas de las posibilidades que nos ofrece hponcfg, utilidad que permite cambiar desde el sistema operativo GNU/Linux la configuración de la iLO (Integrated Lights-Out) de servidores HP Proliant.
En este caso vamos a ver como modificar los parámetros de red (IP, máscara, puerta de enlace, etc) que se utilizan para posteriormente acceder a la web de gestión iLO.
Seguimos utilizando los ejemplos en formato XML de HP Lights-Out XML PERL Scripting Sample for Linux. A continuación el utilizado para realizar modificaciones en los parámetros de red:
<!-- RIBCL Sample Script for HP Lights-Out Products -->
<!--Copyright (c) 2003,2010 Hewlett-Packard Development Company, L.P.-->
<!-- Description: This is a sample XML script to configure the -->
<!-- network settings for following devices: -->
<!-- Integrated Lights-Out 3 (iLO 3) -->
<!-- Integrated Lights-Out 2 (iLO 2) -->
<!-- Integrated Lights-Out (iLO) -->
<!-- Remote Insight Lights-Out Edition II (RILOE II) -->
<!-- NOTE: You will need to replace the USER_LOGIN and PASSWORD -->
<!-- and other values inside the quotation marks with values -->
<!-- that are appropriate for your environment. -->
<!-- Double check all values before executing this script. -->
<!-- Incorrect or mismatched network settings may cause you -->
<!-- to lose the ability to connect to your Lights-Out device.-->
<!-- Use CPQLOCFG.EXE ver 2.26 or greater with this script. -->
<!-- This script was written for iLO 3 firmware version 1.00 -->
<!-- release. -->
<!-- See "HP Integrated Lights-Out Management Processor -->
<!-- Scripting and Command Line Resource Guide" for more -->
<!-- information on scripting and the syntax of the RIBCL -->
<!-- XML. -->
<!-- Firmware support infomation for this script: -->
<!-- iLO 3 - All versions. -->
<!-- iLO 2 - All versions. -->
<!-- iLO - All versions. -->
<!-- RILOE II - All versions. -->
<RIBCL VERSION="2.0">
<LOGIN USER_LOGIN="adminname" PASSWORD="password">
<RIB_INFO MODE="write">
<MOD_NETWORK_SETTINGS>
<!-- Firmware support infomation for next 4 tags : -->
<!-- iLO 3 - All versions. -->
<!-- iLO 2 - All versions. -->
<!-- iLO - All versions. -->
<!-- RILOE II - None. -->
<ENABLE_NIC value="Yes"/>
<REG_DDNS_SERVER value="Yes"/>
<PING_GATEWAY value="No"/>
<DHCP_DOMAIN_NAME value="Yes"/>
<!-- Firmware support infomation for next 22 tags : -->
<!-- iLO 3 - All versions. -->
<!-- iLO 2 - All versions. -->
<!-- iLO - All versions. -->
<!-- RILOE II - All versions. -->
<SPEED_AUTOSELECT value="YES"/>
<NIC_SPEED value="100"/>
<FULL_DUPLEX value="Yes"/>
<DHCP_ENABLE value="No"/>
<IP_ADDRESS value="172.20.60.152"/>
<SUBNET_MASK value="255.255.255.0"/>
<GATEWAY_IP_ADDRESS value="172.20.60.1"/>
<DNS_NAME value="demoilo"/>
<DOMAIN_NAME value="internal.com"/>
<DHCP_GATEWAY value="Yes"/>
<DHCP_DNS_SERVER value="Yes"/>
<DHCP_WINS_SERVER value="Yes"/>
<DHCP_STATIC_ROUTE value="Yes"/>
<REG_WINS_SERVER value="Yes"/>
<PRIM_DNS_SERVER value="0.0.0.0"/>
<SEC_DNS_SERVER value="0.0.0.0"/>
<TER_DNS_SERVER value="0.0.0.0"/>
<PRIM_WINS_SERVER value="0.0.0.0"/>
<SEC_WINS_SERVER value="0.0.0.0"/>
<STATIC_ROUTE_1 DEST="0.0.0.0" GATEWAY="0.0.0.0"/>
<STATIC_ROUTE_2 DEST="0.0.0.0" GATEWAY="0.0.0.0"/>
<STATIC_ROUTE_3 DEST="0.0.0.0" GATEWAY="0.0.0.0"/>
<!-- Firmware support infomation for next 4 tags : -->
<!-- iLO 3 - All versions. -->
<!-- iLO 2 - None. -->
<!-- iLO - None. -->
<!-- RILOE II - None. -->
<DHCP_SNTP_SETTINGS value="Yes"/>
<SNTP_SERVER1 value="0.0.0.0"/>
<SNTP_SERVER2 value="0.0.0.0"/>
<TIMEZONE value="America/Anchorage"/>
<!-- This tag can be used on an iLO blade server to force iLO -->
<!-- to attempt to get an IP address from the signal backplane -->
<!-- in a server enclosure. The IP address must be set prior -->
<!-- with Mod_Enc_Bay_IP_Settings.xml -->
<!-- Firmware support infomation for next tag: -->
<!-- iLO 3 - All versions. -->
<!-- iLO 2 - All versions. -->
<!-- iLO - All versions. -->
<!-- RILOE II - None. -->
<!--
<ENCLOSURE_IP_ENABLE VALUE="Yes"/>
-->
<!-- Firmware support infomation for next tag: -->
<!-- iLO 3 - None. -->
<!-- iLO 2 - None. -->
<!-- iLO - None. -->
<!-- RILOE II - All versions. -->
<!--
<WEB_AGENT_IP_ADDRESS value="192.168.0.1"/>
-->
</MOD_NETWORK_SETTINGS>
</RIB_INFO>
</LOGIN>
</RIBCL>
En este XML tenemos que modificar primero los datos de conexión como administrador USER_LOGIN y PASSWORD y posteriormente a los parámetros que cada uno necesitemos modificar (IP_ADDRESS, SUBNET_MASK, GATEWAY_IP_ADDRESS…).
Si únicamente necesitáis cambiar los valores básicos, ahí va un script reducido y más fácil de entender:
<RIBCL VERSION="2.0">
<LOGIN USER_LOGIN="xxxxxxxx" PASSWORD="xxxxxxx">
<RIB_INFO MODE="WRITE" >
<MOD_NETWORK_SETTINGS>
<IP_ADDRESS VALUE = "192.168.0.100"/>
<SUBNET_MASK VALUE = "255.255.255.0"/>
<GATEWAY_IP_ADDRESS VALUE = "192.168.0.1"/>
<PRIM_DNS_SERVER value = "192.168.0.222"/>
<DHCP_ENABLE VALUE = "N"/>
</MOD_NETWORK_SETTINGS>
</RIB_INFO>
</LOGIN>
</RIBCL>
Una vez modificado todo el script a conveniencia lo ejecutamos contra la aplicación:
# hponcfg -f cambio-red.xml
Si en la salida de ejecución del comando recibimos “Script succeeded” el cambio debería haber funcionado y ya podríamos acceder con los nuevos datos.
Hponcfg es una utilidad que forma parte del HP Proliant Support Pack y que nos permite gestionar desde el sistema operativo todos los parámetros de iLO (Integrated Lights-Out) de servidores HP Proliant. Una vez descargado simplemente se instala como cualquier rpm:
#rpm -i hponcfg-3.0.0-0.noarch.rpm
Hoy vamos a ver como modificar la clave de acceso a la interfaz web de gestión de iLO sin tener que reiniciar el sistema y hacerlo en el arranque.
HP nos ofrece una serie de scripts en formato XML de ejemplo (HP Lights-Out XML PERL Scripting Sample for Linux) que podemos utilizar para realizar todas estas labores. Iré mostrando estos días los que me parecen más interesantes.
Para cambiar la clave de un usuario de acceso a iLO utilizaremos el siguiente script XML:
<!-- RIBCL Sample Script for HP Lights-Out Products -->
<!--Copyright (c) 2003,2010 Hewlett-Packard Development Company, L.P.-->
<!-- Description: This is a sample XML script to change a user's -->
<!-- password in the database of local users on -->
<!-- following devices: -->
<!-- Integrated Lights-Out 3 (iLO 3) -->
<!-- Integrated Lights-Out 2 (iLO 2) -->
<!-- Integrated Lights-Out (iLO) -->
<!-- Remote Insight Lights-Out Edition II (RILOE II) -->
<!-- NOTE: You will need to replace the values inside the quote -->
<!-- marks with values that are appropriate for your -->
<!-- environment. -->
<!-- Use CPQLOCFG.EXE ver 2.26 or greater with this script -->
<!-- This script was written for iLO 3 firmware version 1.00. -->
<!-- release. -->
<!-- See "HP Integrated Lights-Out Management Processor -->
<!-- Scripting and Command Line Resource Guide" for more -->
<!-- information on scripting and the syntax of the RIBCL -->
<!-- XML. -->
<!-- Firmware support infomation for this script: -->
<!-- iLO 3 - All versions. -->
<!-- iLO 2 - All versions. -->
<!-- iLO - All versions. -->
<!-- RILOE II - All versions. -->
<RIBCL VERSION="2.0">
<LOGIN USER_LOGIN="adminname" PASSWORD="password">
<USER_INFO MODE="write">
<MOD_USER USER_LOGIN="username">
<PASSWORD value="newpassword"/>
</MOD_USER>
</USER_INFO>
</LOGIN>
</RIBCL>
Como véis es bastante sencillo, solo tenemos que especificar los datos de acceso del usuario administrador actual y posteriormente elegir los nuevos datos del usuario a modificar. Finalmente ejecutamos el script del siguiente modo:
# hponcfg -f cambio-clave.xml
Si en la salida de ejecución del comando recibimos “Script succeeded” el cambio debería haber funcionado y ya podríamos acceder con los nuevos datos.
Un truco rápido de Nmap que nos permite comprobar si un puerto UDP está escuchando en una máquina remota (para local utilizaríamos netstat).
# nmap -p PUERTO -sU -P0 IP
Por ejemplo, si queremos comprobar si la máquina 192.168.0.150 tiene a la escucha el puerto UDP 161 del servicio SNMP:
# nmap -p 161 -sU -P0 192.168.0.150
Starting Nmap 5.00 ( http://nmap.org ) at 2010-03-26 18:11 CET
Interesting ports on servidor_xx (192.168.0.150):
PORT STATE SERVICE
161/udp open|filtered snmp
MAC Address: xx:xx:xx:xx:xx:xx
Nmap done: 1 IP address (1 host up) scanned in 0.74 seconds
En la salida podéis comprobar que el puerto está a la escucha, si fuera lo contrario veríamos en el estado closed.
En sistemas RedHat/CentOS (quizás me equivoque) por defecto al instalar snmp (Simple Network Management Protocol) el servicio escucha automáticamente en todas las IP configuradas del sistema -> 0.0.0.0:*, no obstante, me ha pasado que al instalar snmp en Debian por defecto el servicio únicamente escuchaba en localhost -> 127.0.0.1:*
Bien, buscando por Internet he encontrado diversas soluciones, pero la más sencilla y eficaz es la de añadir la siguiente directiva en el fichero de configuración snmpd.conf (normalmente en /etc/snmpd/snmpd.conf), donde xx.xx.xx.xx es la IP en la que queréis que escuche:
agentaddress xx.xx.xx.xx
Posteriormente recargáis el servicio:
service snmpd reload
Después, verificad que escucha por la IP que habéis configurado:
# netstat -nau
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 0.0.0.0:161 0.0.0.0:*
Si queréis, en Cybercity tenéis información ampliada sobre las distintas posibilidades.
Para actualizar Ruby Gems a la última versión estable, en primera instancia lo intenté de este modo:
gem update --system
Tras varios dolores de cabeza, actualización de dependencias y varios sucesos, no conseguía hacerlo, y pese a no tener la última versión, siempre recibía el siguiente mensaje:
# gem update --system
Updating RubyGems
Nothing to update
Finalmente, encontré una forma más sencilla de hacerlo, primero instalamos rubygems-update (como root):
gem install rubygems-update
Y después simplemente con el siguiente comando actualizaremos a la última versión estable de Ruby Gems (también como root):
update_rubygems
En caso de que utilicéis equipos que por ejemplo, tengan controladoras de disco RAID o cualquier componente un poquito “especial” es posible que durante la instalación de CentOS, RHEL o FEDORA tengáis que añadir los drivers de forma manual. Personalmente solo me ha sucedido una vez, concretamente con una controladora HP Embedded SATA RAID Controller.
Bien, en caso de que tengáis que añadir los drivers a mano durante la instalación, y una vez que hayáis conseguido los drivers, tendréis que grabarlos en un USB, CD, DVD o medio que queráis (en servidores HP, simplemente montad la imagen del diskette a través de la iLO).
Una vez iniciada la instalación, en el momento de empezar la instalación, escribimos “linux text updates dd” en caso de querer hacer la instalación en modo texto, o “linux updates dd” en caso de querer hacer la instalación en modo gráfico:
De este modo, el propio sistema nos pedirá que insertemos el CD/Diskette en el que tenemos los drivers, para que la instalación los cargue en memoria y los use durante la misma. Seleccionas el medio en el que tienes los drivers (aparecerán a modo de partición tipo sda o similar) y los cargamos.
Ahora mismo no tengo disponible una imagen de este punto del proceso, pero veréis que es muy intuitivo. Una vez cargados los drivers la instalación continúa de forma normal.
Aquí tenéis no obstante una guía de instalación de CentOS 5
En el caso de necesitar recoger de un fichero a partir de una determinada cadena de texto hasta el final del mismo, podemos utilizar AWK del siguiente modo:
awk '/regex/,0'
ó
awk '/regex/,EOF'
Voy a mostrar un ejemplo, tenemos un fichero de texto que contiene lo siguiente:
vim test
esto es
una prueba
test
probando
Pongamos el caso de que necesitamos sacar el contenido del fichero “test” a partir de la línea que tenga el texto prueba:
#] awk '/prueba/,0' test
una prueba
test
probando
En este caso es un ejemplo muy sencillo, para ficheros de log o similares podéis hacer uso de la potencia de las expresiones regulares para sacar la cadena de texto a partir de la cual imprimir el contenido del fichero.
Os recomiendo también leer este otro artículo de iniciación a AWK.
En caso de recibir el siguiente error en el log de APF:
Unable to load iptables module (ip_tables), aborting.
El problema solamente lo he encontrado en instalaciones Fedora, y se soluciona modificando el siguiente parámetro en el fichero de configuración de apf:
fichero: /etc/apf/conf.apf
Parámetro:
MONOKERN="0"
Lo pasamos a:
MONOKERN="1"
Y reiniciamos APF:
/etc/init.d/apf restart
El origen del problema reside en tener iptables compilado en el kernel de forma estática en lugar de como módulo.
Comentarios recientes