Cómo obtener el group ID y el User ID en unix

Al menos en linux SuSE 9, se puede hacer lo siguiente:

1. Para saber el userID:

egrep username /etc/passwd

El userID es el que aparece en el tercer campo (los campos se separan con ":"), por ejemplo, si el resultado del comando anterior es la siguiente línea:

oracle:x:1000:1000:oracle admin:/u00/app/oracle:/usr/bin/ksh

entonces el userID es 1000. El cuarto campo indica el groupID (que también es 1000).

2. Para saber el groupID, también se puede hacer lo siguiente:

egrep groupname /etc/group

De igual manera que en punto anterior, el ID es el tercer campo

Usuarios no se pueden logear al Portal después de sincronizar eDirectory de Novell con OID

Se decidió que un directorio de Novell (eDirectory) se sincronizaría con el OID para tener la misma población de usuarios y que cada usuario tuviera el mismo password en ambos sistemas. Se probó un driver que desde Novell eDirectory "sincroniza" a las personas (es decir, "copia" su información almacenada en el eDirectory) hacia el OID y funcionó bien.

Sin embargo, los usuarios no podían logearse al Oracle Portal, pues éste marcaba un error después de dar usuario/password. Se revisó en el ODM la información de los atributos de un usuario que sí se podía logear al Portal con uno que no podía, y se encontró que el que no podía tenía el atributo orclpassword nulo, es decir, no tenía nada. Entonces se checaron los demás atributos y se encontró que el atributo "uid" también estaba nulo para el usuario que no se podía logear al Portal, no así para el que sí podía.

Entonces, se procedió agregar dicho atributo en el driver del Novell eDirectory y se le asignó el mismo valor que al atributo "cn". Teniendo el atributo "uid" con un valor diferente de nulo, ya se le generó automáticamente al usuario el atributo orclpassword en la sincronización, y ya se pudo logear al Oracle Portal.

OC4J no levanta (OAS 10g 10.1.4)

Había una vez una instalación de OAS 10g en tres capas:

1. Infraestructura
2. Middle Tier (Portal)
3. Web Cache

En cierta ocasión, después de bajar todo el sistema, al querer levantar la infraestructura notamos que tardaba mucho tiempo en ejecutarse el comando "opmnctl startall", y al final marcaba el error siguiente:

ias-component/process-type/process-set:
OC4J/OC4J_SECURITY/default_island

Error
--> Process (pid=14740)
time out while waiting for a managed process to start
Log:
/u00/app/oracle/product/oas10g/infra10o1/opmn/logs/OC4J~OC4J_SECURITY~default_island~1

La Base de Datos levantó bien, el Listener también, el HTTP Server también, pero el OC4J decía "Down" cuando se ejecutaba el comando "opmnctl status". Al revisar el log indicado por el error anterior, éste decía (sólo muestro parte del mensaje):

07/03/04 21:35:33 [warning] cannot open connection, type=*
oracle.idm.connection.ConnectionException: cannot open ldap context, serialNumber=11, type=ldap, operation=open

... (más del stack trace de java) ...

Caused by: javax.naming.NamingException: Unable to establish initial secure conn
ection to Oracle Internet Directory Server. Please verify that the correct Oracl
e Internet Directory Server parameters are specified in /u00/app/oracle/product/
oas10g/infra10o1/config/ias.properties. Make sure that the Oracle Internet Direc
tory Server specified in OIDhost, OIDsslport is up and running. Base Exception :
javax.naming.CommunicationException: prod26db.itesm.mx:636 [Root exception is j
ava.net.ConnectException: Connection refused]

El ODM (Oracle Directory Manager) se "congelaba", o bien, se quedaba "colgado" después de dar usuario/password y host/puerto. Esto empezó a levantar sospechas de que el problema se trataba de comunicación con el OID. Después de buscar mucho y no encontrar nada que nos ayudara, preguntamos a un experimentado consultor de OAS, quien nos dio el siguiente procedimiento:

1. Revisar el contenido de la tabla ODS.ODS_PROCESS
2. Respaldar dicha tabla (hicimos un simple "spool" desde sqlplus)
3. Dar de baja todo con "opmnctl stopall" (obviamente, bajar todas las capas)
4. Truncar la tabla ODS.ODS_PROCESS
5. Levantar todo con el "opmnctl startall"

Así procedimos, y todo levantó bien.

NOTA: Esto nos trajo consecuencias, como por ejemplo, que no levantara el servidor de replicación (OIDREPLD), el cual lo tuvimos que levantar a mano posteriormente con el comando "oidctl server=OIDREPLD instance=1 start".

Habrá que revisar qué más implicaciones tiene el truncar dicha tabla. Se los dejo de tarea, así como el investigar por qué sucedió eso.