domingo, 9 de noviembre de 2014

Conexión SSH a Ubuntu 14.04 (Virtual Machine)

Hace un par de semanas estuve teniendo muchos problemas para conectarme por medio de una conexión SSH a una maquina virtual que tenía Ubuntu 12.02 como SO, el problema era que el paquete instalación ya no estaba disponible para esa versión, fue una ardua batalla de varios días... el problema lo pude solucionar instalando la versión más reciente de Ubuntu, que para la fecha de escribir estas líneas era la 14.04.

El proceso de instalación de Ubuntu es muy sencillo, por lo que solo pongo unas pantallas del proceso... el cual es muy intuitivo:




Se debe iniciar sesión para poder empezar el proceso de instalación del paquete:

El siguiente paso es abrir una terminal (de comandos) desde el lanzador de programas:

Lo primero (y que deberá hacerse continuamente) es instalar las actualizaciones que sean necesarias, se debe utilizar el comando sudo apt-get update desde la terminal, se deberá proporcionar el password para proceder con la instalación. 

El proceso de actualización se iniciara y deberá durar unos minutos.


Una vez finalizada la actualización se debe instalar el paquete SSH, para esto vamos a utilizar el comando sudo apt-get install ssh:

En algún momento de la instalación, se solicitará confirmar la instalación, se debe contestar Y (Yes)

El proceso de instalación iniciara y puede durar unos minutos:


Ya concluida la instalación hay que revisar el archivo sshd_config, el cuál se encuentra en la ruta /etc/ssh, se debe validar que el puerto 22 esta libre, en caso de estar como comentario ( # ) se debe habilitar:

Si todo esta como se menciona, ya estamos en condiciones de probar las conexiones por SSH, primero probemos con una conexión local, para lo cual lo haremos desde la misma maquina virtual de Ubuntu, con un ssh localhost será suficiente, al ser la primera conexión solicitará se confirme la autentificación, que consiste en una habilitar una llave de seguridad, se debe contestar yes:

Una vez confirmada la autentificación se deberá proporcionar el password del usuario con el que se esta intentando hacer la conexión, para este ejemplo ha sido gpinedo y se proporciona el password que se especifico durante el proceso de instalación (párrafos atrás).

Una vez especificado el password correcto, se desplegaran mensajes de advertencia y ya estará establecida "una conexión local" por medio de SSH

Para cerrar la sesión solo se debe teclear exit y se regresará a la sesión de inicio.

Para poder establecer la conexión de manera remota necesitamos saber la IP que tiene asignada la maquina virtual, para saber la que tiene asignada utilizamos el comando ifconfig:


Lo siguiente es utilizar una herramienta para conexiones remotas, como es el caso de PUTTY, en la cuál se deberá poner la IP que tiene la maquina virtual:

Al abrir la conexión Open se establecerá la conexión, solicitando el nombre de usuario con el que se desea establecer la conexión. También se deberá teclear el password del usuario.

Si todo salió bien, ya tendremos una sesión remota en la maquina virtual. 

Debido a la diversidad de equipos que existen se pueden tener resultados diferentes a los mostrados en las imágenes anteriores, si existen errores en otros procesos similares puede deberse a diferentes factores. Como siempre, quedo para cualquier duda o comentario al respecto.

jueves, 4 de abril de 2013

sqlnet.ora SQLNET.AUTHENTICATION_SERVICES en Windows & Unix

Confieso que mi relación laboral con las consultorías la mayoría de la veces ha estado en términos "delicados", cuando me toca coordinar o recibir un proyecto procuro apegarme a lo que se establece en el libro  Análisis y Diseño de Sistemas - Kendall & Kendall (http://www.pearsoneducacion.net/kendall/). Lo que nos ha llevado a severas discusiones acerca de lo que pretenden entregar y lo que deben entregar. Pero bueno, ese no es el tema de esta publicación, el tema de que manera afecta las conexiones locales y remotas el archivo sqlnet.ora. 

Hace un par de días recibí un ambiente de Oracle eBS el cuál entre las cosas que se hicieron mal, las que no se hicieron y las que no se entregaron estaban los passwords de acceso a la base de datos. Después de varios correos me mandaron los passwords de acceso. Por lo regular siempre procuro hacer una validación con conexión remota.

Cuando se lo comenté, la respuesta inmediata fue que YO estaba mal, que él se podía conectar sin problemas.


Definitivamente alguien estaba equivocado, lo primero que me vino a la mente: el password que me mandó era incorrecto, pero antes de reclamar tenía que probar de la misma manera que el consultor estaba conectándose... de manera local.

¡Sorpresa! si me pude conectar. Volví a validar la conexión remota y volvió a fallar. ¡Damn!  Bueno, había que analizar... ¿que puede marcar la diferencia entre una conexión remota y una conexión local?

  1. Tnsnames.
  2. Listener.
Estos primeros dos quedaron descartados con un tnsping.


Lo siguiente era trabajar del lado del servidor, y de ese lado todo apuntaba al archivo SQLNET.ORA (%ORACLE_HOME%\network\admin) Este archivo controla el acceso a la base de datos por medio de los protocolos de red, métodos de autenticación, definir los tiempos de comprobación de actividad de las sesiones de los clientes. 

Esta es la configuración inicial del archivo:




La única línea existente era: NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT). No había nada más.

Los parámetros más relevantes que se pueden especificar en este archivo son los siguientes:

SQLNET.EXPIRE_TIME
El valor de este parámetro es en minutos. Es utilizado para especificar el intervalo de tiempo en que se validar si las conexiones clientes/servidor están activas. Esto permite asegurar que las sesiones a la base de datos no queden abiertas indefinidamente. El valor recomendado es de 10.

TCP.EXCLUDED_NODES
Aquí se especifican los clientes que NO podrán conectarse a la base de datos. El listado debe ir separado por coma ( , ) y puede ser por la IP (recomendable) o host.

TCP.INVITED_NODES
Aquí se indican los clientes SI podrán conectarse a la base de datos. El listado debe ir separado por coma ( , ) y puede ser por la IP (recomendable) o host.

TCP.VALIDNODE_CHECKING
Se se utilizan los parámetros TCP.INVITED_NODES y TCP.EXCLUDED_NODES. Este debe habilitarse a YES. De lo contrario no se tomará la configuración especificada. Por default el valor es NO.
 NAMES.DIRECTORY_PATH
En este parámetro se especifica el orden y método para resolver el Identificador de Conexión, y el Nombre del Servicio de Red. Los que están especificados son los siguientes:

  • TNSNAMES: Resuelve el nombre del servicio de red especificado en el archivo Tnsnames.ora del cliente o desde donde se vaya a hacer la conexión a la BD. 
  • EZCONNECT: Permite las conexiones a la base de datos, sin ninguna configuración. Los clientes usan una dirección TCP/IP sencilla, con un nombre de Host, Puerto y servicio opcional (Conn usuario/password@:puerto/nombre_servicio). 

SQLNET.AUTHENTICATION_SERVICES
Permite uno o más servicios de autenticación a nivel de sistema operativo. Este último es el que me interesa.

Para obtener más información acerca de los parámetros de sqlnet.ora pueden consultar la documentación oficial de Oracle Aquí

Este parámetro al igual que los demás, al NO estar especificados en el archivo toman un valor por default durante la instalación. En el caso de este parámetro permite que las conexiones LOCALES que se hagan con el usuario de sistema operativo propietario de la instalación se pueda conectar a la base de datos con privilegios de DBA, por ejemplo:

Tengo una abierta una consola de comandos con el usuario que hizo la instalación del RDBMS y la creación de la base de datos (Para este ejercicio me cambie a un equipo con Sistema Operativo Windows).


Si intento hacer una conexión LOCAL como as sysdba no debo tener ningún problema.


Esto es porque en el archivo sqlnet.ora de este equipo el parámetro SQLNET.AUTHENTICATION_SERVICES tiene el valor NTS. Lo que permite hacer conexiónes con autenticación del sistema operativo (Autentificación de Windows sin contraseña).


 La conexión es con el usuario SYS.


Esto puede ser mal interpretado, ya que se puede tener la impresión de hacer una conexión local con determinado usuario cuando en realidad la conexión que se hace con SYS. En los siguientes ejemplos se emuló la conexión con determinado usuario, uno de ellos no existe y cuando se solicitaba el password se ponía cualquier serie de caracteres, la conexión fue exitosa y en todos los casos el usuario conectado era SYS.




Si el parámetro SQLNET.AUTHENTICATION_SERVICES= (NTS) se pone como comentario:
 

El resultado es el siguiente:


Para los siguientes ejemplos se sigue manejando un entorno local, el host esta especificado como 10.10.10.10 porqué se tiene un "Adaptador de Bucle Invertido" Aquí explique el tema.

Ahora para hacer las conexiónes se tiene que hacer especificando usuario/contraseña y ALIAS de la base de datos especificado en el TNSNAMES.


Para hace la conexión con SYSTEM debe ser sqlplus system@orcl:


 La conexión de SYS como SYSDBA debe ser sys@orcl as sysdba:


 Los usuarios que no tienen privilgios y que intenten conectarse como SYSDBA no podran conectarse:


 Los usuarios inexistentes obviamente no se pueden conectar:

Bueno, ahora a poner las cosas en su lugar, después de las pruebas hay que poner esta configuración en Producción. Así que manos al teclado.

En Unix por default el parámetro SQLNET.AUTHENTICATION_SERVICES permite las conexiones locales sin autentificación, por lo que hay que ponerlo en NONE. 
*Como siempre, antes de editar cualquier archivo de configuración se debe hacer una copia de seguridad.

Listo, ahora probar, primero validar que se rechaza la conexión local sin autentificar:

Y confirmar que se puede hacer la conexión especificando el alias de la base de datos y usuario/password.

Una vez más confirmo que el password esta mal. Ahora si, a poner las cosas y a la gente en su lugar.

Voy con el consultor, me paro tras él y digo: "A ver, por favor intenta conectarte". Primero un sobresalto, voltea a verme con cara de fastidio. Abre una terminal, user/password de sistema operativo, sin problemas se conecta al servidor... 

Ya con una sesión en el servidor empieza a teclear los comandos... disfruto cada tecla que presiona... sqlplus "system as sysdba"...

Pocas veces mi sonrisa ha tenido que esforzarse para permanecer dentro de la dimensiones de mi cara. Sin voltear a verme dice:
-"Algo hiciste, no me deja conectar".
Respiro profundo para ocultar la risa, le contesto "Estoy haciendo que las conexiónes a la base de datos sean por autentificación, por lo que ahora tienes que poner usuario arroba y alias de la base de datos".

-"Y eso para qué" contesta de mala gana.
-"Para demostrarte que el password es incorrecto, Teclea el usuario, presiona enter y te va a pedir el password". Fue mi respuesta

Después de hacerlo y ver el mensaje en pantalla disfrute ver como sus orejas iban tomando el color de su rostro... rojo.
Se levanta de su lugar "a ver, hazlo tú" me dice. Tomo su lugar, presiono CTRL + C para interrumpir la sesión. Empiezo a teclear: sqlplus system@dev, la tecla ENTER casi sale del teclado después de presionarla.

"El password es..." me dice, pero lo interrumpo levantandome del lugar y cediéndolo mientras le contesto "hazlo, no vaya a ser que me equivoque".
Se sienta y teclea varias letras y números terminando con la tecla ENTER... aparece la leyenda "invalid username/password; logon denied" mi sonrisa esta a punto de estallar. Repite la tarea pero ahora más despacio y presionando cada tecla con un solo dedo... "invalid username/password; logon denied", se queda viendo la pantalla un par de segundos.


Le doy unas palmadas en la espalda mientras le digo "Cuando tengas el password correcto me lo mandas" me doy la vuelta y camino a mi lugar, por un momento tengo miedo de una agresión por la espalda... pero estoy trabajando con "Profesionales" así que sigo mi camino. Al llegar a mi lugar lo primero que hago es llamar a mi madre ¿por qué? porqué las mentadas de madre deben ser recordatorio para saludarlas.








lunes, 14 de enero de 2013

La misteriosa relación de Oracle E-Business Suite y NLS_LANGUAGE

En el equipo con el que estoy trabajando tengo instaladas varias herramientas para la realización de las funciones del día a día, por ejemplo:
  • SQL Developer.
  • Oracle Client 10g
  • Oracle RDBMS 10g
  • TOAD 9.6

Esto un poco por decidía y otro porque no he encontrado una herramienta que realmente cumpla mis expectativas al 100%, el caso es que un día me di cuenta que si me conecto con ellas a la base de datos (10.2.0.4) de la aplicación Oracle E-Business Suite no siempre se obtienen los mismos resultados ¿¡!?.

Vayamos a los hechos.

Estando conectado a la BD desde SQL Developer a la base de datos ejecuto una simple consulta para validar los datos de la misma.


El usuario con el que me conecte es el propietario de la tabla, en este caso es APPS.


Hasta aquí nada nuevo, nada extraña... todo Ok. pero si ejecuto unas consultas sobre una determinada tabla los resultados son los siguientes:


Supongamos, la escena:

Suena la extensión... contesto y...

Usuario - ¡Hola! Por favor me puedes mandar el listado de registros de la tabla PER_PEOPLE_V7
Yo -Claro, dame unos minutos...

Cuelgo y voy abriendo SQL Developer. Me conecto a la BD, tecleo usuario y password, la conexión se hace de manera exitosa, empiezo a teclear y los comandos aparecen en pantalla y presiono ENTER, 

Yo - (Pensando) mmmm, no tiene nada, a ver un count... no, no tiene nada.

Levanto el auricular de la extensión, marco los dígitos...

Usuario - ¿Si?
Yo - Hola, oye... esta tabla que me estas solicitando... ¿que información es la que esperas que te mande?
Usuario - Ah mira, es el listado del Personal que esta asignado a un usuario dentro de la aplicación, queremos hacer una depuración y bueno, pensamos que podemos empezar por saber que personal existe.
Yo -  Perfecto, solo era una pequeña duda, estoy trabajando en ello, dame unos minutos.
Usuario- Bye.

Cuelgo y mi mano va al teclado, sé que algo esta mal... es lo bueno; lo malo... es que no tengo ni la menor idea de qué sea. Acudo a quién siempre me ha ayudado en estos momentos de ignorancia e incertidumbre... Google. Después de varios minutos y buscar, buscar y buscar, se empieza a ver luz al final del túnel, parece que algo tiene que ver NLS_LANGUAGE.

Reviso el valor que tiene la sesión desde SQL Developer.


Inicio una sesión desde SQL Plus, habilito la conexión a la base de datos y hago unas consultas.


Lo siguientes es cambiar el valor del parámetros de la sesión que tengo en SQL Developer.


Lanzó un count para validar si ya muestra información.


¡Perfecto! ahora a extraer la información.


Como siempre, quedo para cualquier duda o comentario al respecto.




Colaboradores