ORACLE: dbca & netca no arrancan...

...googleando encontré la respuesta!

Agregando esta línea al listener.ora se solucionó mi problema:

(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP(HOST=hostname)(PORT = 1521))

Anteriormente, lo solucionaba renombrando el archivo, y restaurándolo posteriormente a haber utilizado alguno de los asistentes.

Queda pendiente conocer la causa de este problema!

ORACLE: Creando una instancia de base de datos a mano.

Siempre es más sencillo y rápido utilizar el asistente (dbca) para contruir una instancia de base de datos, pero a su vez comienza a crecer la incertidumbre de "qué es lo que está haciendo por atrás". Entonces, me tomé el tiempo de seguir el instructivo de los propios manuales de Oracle en inglés, y me lancé a contruirla manualmente. Aunque como dije están los manuales de Oracle explicando paso a paso como hacerlo, lo está en inglés, así que para facilitarles un poco la vida a los hispanoparlantes como yo, voy a intentar aclarar un poco cuales son estos pasos.

• Especificar a través de la variable de ambiente ORACLE_SID el nombre de la instancia que vamos a construir. En mi caso, export ORACLE_SID=xyz

(Paso: 1)

• Asegurarse de que las variables de ambiente requeridas por Oracle, se encuentren definidas: ORACLE_SID, ORACLE_HOME y que la variable PATH contenga a $ORACLE_HOME/bin.

(Paso: 2)

• Es MUY IMPORTANTE seleccionar el método de autenticación para el/los administradores. Existen dos alternativas: archivos de contraseñas y a través del sistema operativo. En mi caso, utilicé el archivo de contraseñas. Este archivo lo generé con el comando orapwd, posicionado en el directorio dbs. Sin este archivo, los usuarios privilegiados como SYS, no pueden conectarse a través de TNS.

(Paso: 3)

(ANEXO: pasos para construir el archivo de contraseñas)

• Construir el archivo de parámetros de inicialización (init.ora). Se puede utilizar una plantilla que se encuentra ubicada en $ORACLE_HOME/dbs/init.ora. Se copia y se parametriza a gusto. Cada uno de los parámetros se puede visualizar en este manual de referencia.

(Paso: 4)

• Conectarse a lo que va a ser nuestra nueva instancia de base de datos. Estando conectado con el usuario unix propietario del software de base de datos, se puede conectar usando "sqlplus / as sysdba".

(Paso: 6 (el 5to paso lo obvié, porque es para bases en windows.))

• Una vez conectados, procedemos a construir el archivo de parámetros del servidor. Esto lo hacemos con la instrucción "create spfile from pfile='/.../initxyz.ora';", reemplazando [...] por la ruta absoluta donde se encuentra nuestra copia.

(Paso: 7)

• Arrancamos la instancia, sin montar la base con la instrucción: "startup nomount".

(Paso: 8)

• Construir la configuración de base de datos, con la instrucción "create database ...". En la descripción en inglés se muestra un ejemplo de la instrucción.

(Paso: 9)

• Construir el diccionario de base de datos. En el directorio $ORACLE_HOME/rdbms/admin se encuentran los script de administración, entre ellos hay que ejecutar dos: catalog.sql y catproc.sql

(Paso: 11 (el paso 10, habla sobre como contruir tablespaces adicionales.))

Repito: si quieren conectarse de esta forma: "sqlplus sys/pass@tns as sysdba" deberán tener generado el archivo de contraseñas!

Cualquier tipo de feedback sobre este artículo o cualquiera de los otros, será bienvenido.

ORACLE: Instalación del cliente Oracle 10.2.0.1 sobre Fedora 9 de 64 bits

Prerequisitos:

yum install libXp-1.0.0-11.fc9.i386
yum install libXt-1.0.4-5.fc9.i386
yum install libXtst-1.0.3-3.fc9.i386

export ORACLE_HOME=$ORACLE_BASE/product/10.2.0.1

Editar el archivo redhat-release con el siguiente contenido:

redhat release 4

Descargar el instalador desde el sitio de OTN.
Descomprimirlo: gunzip 10201_client_linux_x86_64.cpio.gz
Desempaquetarlo: cpio -idmv < 10201_client_linux_x86_64.cpio

Iniciar la instalación con el usuario oracle de unix:

./runInstaller &

LINUX: Kernel

Pasaron mil años desde el último kernel que compilé, creo que fué allá por la versión 2.0.x, cuando aún contaban con opciones limitadas, a diferencia de las millones de opciones con las que cuenta ahora. Pero llegó el momento de embarrarme nuevamente, y construir un kernel a la medida de mis necesidades.

ADVERTENCIA: Niños no hagan esto sin la supervisión de un adulto.

La plataforma de mis pruebas fué el servidor Linux / Fedora 9 de desarrollo de la consultora, jejeje. Gracias a Dios, Alá, Buda, todo resultó bien, y aún no me despidieron!

Este Fedora estaba utilizando el kernel 2.6.25 de 64 bits, y lo que hice fué actualizarlo al 2.6.28.

Acá voy a registrar la bitácora de mi trabajo, y no estoy escribiendo un manual para compilar un kernel, para ello ya hay varios distribuídos en la web y escrito por gente experta.

Los pasos desde aquella versión a la 2.6 practicamente, no cambiaron.

make mrproper
make clean
make menuconfig (si es que sabes de que se trata cada abreviatura de las opciones)
make xconfig (si queres un entorno visual, y con una mayor explicación de qué se trata cada opción, inclusive hasta te recomienda por qué optar!)
make dep
make
make modules
make modules_install
make install

Como se puede apreciar, primero instalé los módulos y luego el kernel, si lo hacía al revés cuando intentaba instalar el kernel detectaba una falta de símbolos, y dejaba el kernel a "medio instalar".

Es recomendable, agregarle un texto a la versión del kernel (opción: General Setup / Local Version). Este texto podrá visualizarse posteriormente con el comando: uname -r
Por otra parte, la instrucción "make modules_install", creará un directorio usando el texto como sufijo.

Por ejemplo: si "local version" lo configuramos con el texto "-test", el comando "uname -r" mostrará: 2.6.28-test, tanto el kernel, el system.map y el initrd.img tendrán este sufijo, al igual que el directorio de modulos: /lib/modules/2.6.28-test/

También hay que tener en cuenta de copiar la configuración (make xconfig) de compilación del kernel, esta configuración queda almacenada en el archivo .config en la raíz donde se encuentra los fuentes del kernel: "cp -i /usr/src/kernel/linux-2.6.28/.config /boot/config-2.6.28-test"

La regla menuconfig, es util cuando estamos trabajando en una terminal en modo texto, aparentemente utiliza los menú de dialog.
La regla xmenu, abre un menú visual usando las QT sobre X-Window.
La regla gmenu, es igual que la anterior, pero utilizando las GTK sobre X-Window.
La regla install, hasta me configuró el gestor de arranque grub, y yo creo que por cuestiones de seguridad, no pone la nueva entrada, como opción por defecto.
La regla mrproper, se supone que hasta inicializa el archivo .config a diferencia del clean que no lo hace, googleando me encontré que mrproper, era el nombre de un producto de limpieza europeo Mr. Proper, qué curioso, no?

LINUX: iptables (bitácora)

Llegó el momento de proteger un poco el servidor, y qué mejor que arrancar aprendiendo un poco de iptables. Aún mantengo el firewall sin reglas, solo me dedico a monitorear que es lo que está llegando al equipo, para no poner barreras de más y dejar sin conexión a algún cristiano que acceda al mismo. Para eso, arranco jugando con la generación de bitácoras. Primero le digo a rsyslogd qué mensajes quiero guardar y donde hacerlo, agregando esta línea al archivo /etc/rsyslog.conf:

• kern.warn /var/log/iptables.log

Luego para que el cambio surta efecto, reinicio el demonio de rsyslog:

• /etc/init.d/rsyslog restart

Ahora sí manos a la obra con el "misterioso, para mí" iptables, le damos la primer instrucción:

• iptables -A INPUT -i eth0 -j LOG --log-level warn

En mi caso, filtré todo lo que venga por la primer interfaz ethernet. Ahora, todo lo que esté llegando por esa interfaz quedará registrado en el archivo /var/log/iptables.log

A mí se me hizo bastante útil este tipo de monitoreo, antes de empezar a cerrar todo el equipo, espero a alguien más también le sirva.

Qué os disfrutéis!

ORACLE: cuidado con las NLS_...

...seguramente, como muchos, escribí una sentencia rápida para determinar los días hábiles de la semana:

SELECT TO_CHAR(SYSDATE, 'D') FROM DUAL;

Pero resulta, que en algunos ambientes, esta misma consulta me retornaba 1 y en otras 2 para el día lunes. Esto es porque en algunos países el primer día de la semana es el domingo, y en otros es el lunes.

Una posible solución, fué asegurarme de que el territorio de mi ambiente sea siempre el mismo, en cualquier lugar donde lo lance. Esto lo hice agregando a mi script el siguiente ALTER SESSION:

ALTER SESSION SET NLS_TERRITORY = AMERICA;

A partir de ahí, mi consulta siempre devuelve 2 para los lunes!

SELECT * FROM v$nls_valid_values;

Muestra todos los valores posibles para TERRITORY, LANGUAGE y CHARACTERSET.

SELECT * FROM v$nls_parameters;

Muestra la configuración de la instancia de base de datos.

SELECT * FROM nls_session_parameters;

SELECT * FROM nls_instance_parameters;

SELECT * FROM nls_database_parameters;

Muestran la configuración de la sesión, instancia y base de datos.

ORACLE: reubicar los datafiles.

Soy conciente de que no soy el primero en escribir sobre esto, pero bueno me llegó el momento, y tuve que reubicar un par de datafiles para poder liberar algo de espacio de mi sistema de archivos.

Esto lo hice en un Oracle 11g sobre fedora 9.

1. Saqué de línea el tablaspace en cuestión: alter tablespace mi_data offline;
2. Moví los datafiles a una nueva ubicación con un move de linux: mv /u01/oradata/midata.dbf /u02/oradata/midata.dbf
3. Luego hice esto mismo pero sobre el Oracle: alter database rename '/u01/oradata/midata.dbf' to '/u02/oradata/midata.dbf';
4. Por último, volví a poner en línea el tablespace: alter tablespace mi_data online;

No sé si habrá algo oculto por atrás, pero en mi caso no me hizo falta reiniciar la base, todo anduvo de maravilla (por ahora).

Configurando cliente de correo Mutt para el envío de notificaciones batch

Mi Linux no cuenta son servicios de correos activados, pero sí tengo acceso a la LAN de la empresa, en la cuál existe un servidor exchange.

Para que el cliente de correo mutt envíe los correos de salida a este servidor, me bastó con crear un archivo en el home de mi usuario, con el nombre .muttrc y la siguiente línea:

set smtp_url="smtp://mi_smtp_server.mi_dominio:mi_puerto_smtp"

Con esto fué suficiente, ahora soy feliz y puedo enviar correos desde mis shell scripts, con la siguiente sintaxis:

mutt -x -s "Mi subject" mi_correo@mi_dominio <<!
Mi contenido del mensaje
.
!

Muy interesante, no?

Apache + CGI + ANSI/C

Por un lado, hice el siguiente cambio en el archivo /etc/httpd/conf/httpd.conf


1.- Descomenté la línea:

AddHandler cgi-script .cgi


2.- Luego cambié este bloque...

<Directory "/var/www/cgi-bin">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>

...por este otro...

<Directory "/var/www/cgi-bin">
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all
</Directory>


3.- Por último, reinicié el apache.

4.- Construí el programa CGI en base al siguiente fuente:

ejemplo.c (/var/www/cgi-bin/ejemplo.cgi):

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <string.h>
int main(void) {
size_t qChr;
char *sStr;
qChr=strlen(getenv("QUERY_STRING"));
printf("Content-type: text/html\n\n");
printf("<html>\n");
printf("<body bgcolor=black text=lightgreen>\n");
sStr=(char*)malloc((qChr+1)*sizeof(char));
if(!sStr) {
printf("Error\n");
}
else {
memset((void*)sStr, (int)NULL, (qChr+1)*sizeof(char));
strcpy(sStr, getenv("QUERY_STRING"));
printf("%s\n", sStr);
}
printf("</body>\n");
printf("</html>\n");
return(0);
}

5.- Escribí el formulario HTML que invoca al programa CGI con el método GET:

/var/www/html/index.html:

<html>
<form action="http://miweb/cgi-bin/ejemplo.cgi" method="GET"> Director: <input type="text" name="dir"> <br>
Producer: <input type="text" name="prod">
<input type="submit" value="Fire">
</form>
</html>

6.- La alternativa al método GET es el método POST, en el documento HTML sólo cambié el GET por el POST. Principalmente, lo que cambia son dos cosas: los pares campo valor, no son mostrados en la barra de direcciones, y en el servidor dichos valores son recibidos por el proceso a través de la entrada estandar (stdin) en lugar de la variable de ambiente QUERY_STRING. El fuente C queda de la siguiente forma:

int main(void) {
char sBuff[1000];
memset((void*)sBuff, (int)NULL, sizeof(sBuff));
printf("Content-type: text/html\n\n");
printf("<html>\n");
printf("<body bgcolor=black text=lightgreen>\n");
fgets(sBuff, sizeof(sBuff)/sizeof(char), stdin);
printf("%s\n", sBuff); printf("</body>\n");
printf("</html>\n");
return(0);
}

Esto fué un pequeño apunte de mi prueba. Una forma de probar mi programa CGI fué, conectándome con telnet al puerto http (80) de mi servidor, y pasarle el siguiente texto a ciegas:

GET /cgi-bin/ejemplo.cgi?dir=123&prod=456 HTTP/1.1
Host: miweb
User-agent: pepe
<<línea en blanco>>

Donde mi servidor me responde la salida generada por mi programa CGI.

Si el método utilizado es POST, la solicitud debería ser algo parecido a esto:

POST http://miweb/cgi-bin/ejemplo.cgi HTTP/1.0
Host: miweb
Accept: text/html, text/plain, text/css, text/sgml, */*;q=0.01
Accept-Encoding: gzip, bzip2
Accept-Language: en
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Lynx/2.8.6rel.2 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.8g
Referer: http://miweb/ejemplo.html
Content-type: application/x-www-form-urlencoded
Content-length: 16
dir=123&prod=456
<<línea en blanco>>

"Espero os haya gustado"