Archivos de la categoría Linux

En esta categoría clasificaré todas las entradas relacionadas con el Sistema Operativo Linux.

Ejecutar comando scp sin que pida contraseña el servidor de origen

En la siguiente entrada de blog explico como utilizar el comando scp (Secure Copy o SCP es un medio de transferencia segura de archivos informáticos entre un host local y otro remoto o entre dos hosts remotos, usando el protocolo Secure Shell (SSH)) de Linux o Unix que nos permite realizar la copia de un fichero/s de un servidor a otro. Esto es muy útil cuando has creado una shell por ejemplo en un servidor de desarrollo y quieres simplemente copiarla de manera idéntica en el servidor de producción.

Ejemplo de formato de scp

scp -p -r $usuario@$servidor:fichero dir/

Ejemplo conectados como root en el servidor “destino”:

# scp -p -r shell.sh root@servidor:/ruta

Esto copia el fichero shell.sh en el servidor “servidor” conectado como root en la ruta “/ruta”. Para que no pida la contraseña, en el servidor “servidor” debe existir en el “home” del root el fichero .rhosts donde se detalla el servidor “destino” y el usuario del servidor “destino” que queremos que no pida la contraseña.

Ejemplo de fichero .rhosts del servidor “servidor”

[root@servidor ~]# more .rhosts
 destino root
 destino pepe --> Poniendo esto al usuario "pepe" tampoco se le pediría contraseña

Cómo saber si nuestro Unix o Linux es de 32 o 64 bits

Tanto en Unix como en Linux una manera sencilla de saber si nuestro sistema es de 32 o 64 bits es ejecuntando el comando uname desde la linea de comandos:

$ uname -a
Linux h0541.csub.scs.es 2.6.18-308.16.1.el5 #1 SMP Tue Sep 18 07:21:07
EDT 2012 x86_64 x86_64 x86_64 GNU/Linux

En este ejemplo se trata de un Linux de 64 bits.  Nos lo informa el x86_64. Sino sale esto es de 32 bits.

Saber cuando se reinició por última vez una base de datos Oracle

Para saber cuando rebotó una BBDD por última vez:

- desde Sistema Operativo (Unix/Linux):

# ps -ef | grep pmon
oracle   10541     1  0 Jan29 ?        00:03:27 ora_pmon_ORCL
oracle   13606 23880  0 12:25 pts/2    00:00:00 grep pmon

Sale la hora en el proceso. Esa hora corresponde a la última vez que se reinició la instancia de BD.

- desde SQLPLUS

select status, startup_time, instance_name from v$instance;

O lo que es lo mismo pero adornado:

select status Estado, to_char(startup_time, 'HH24:MI DD-MON-YY') "Hora y Fecha de Arranque", instance_name Instancia
from v$instance
/

Deshabilitar acceso a SQLPLUS usando “/as sysdba”

En la entrada de Blog anterior, expliqué como poder acceder como SYSDBA a sqlplus sin tener el password. Evidentemente, esto es un problema grave de seguridad, ya que si cualquiera se hace con el password del usuario oracle y/o cualquier usuario que pertenezca al grupo “dba” tendrá acceso como SYSDBA si hace lo explicado en la entrada de blog anterior. Esto es así porque en el fichero $ORACLE_HOME/rdbms/lib/config.* (.c o .s) que pertenece al grupo dba se dan privilegios implícitos para usar “/as sysdba” sin pedir contraseña a cualquier usuario de sistema operatativo que pertenezca a este grupo.

Pues la solución, es tan sencilla como sacar del grupo “dba” a todos aquellos usuarios de S.O y dejar el grupo vacio. De esta manera, al entrar a sqlplus, se nos solicitará el password.

Otra opción consiste en:

Editar el archivo “$ORACLE_HOME/rdbms/lib/config.c” y hacer referencia a un falso  grupo vacío. Posteriormente, “volver a vincular todos”, para volver a conectar todos los componentes de software de Oracle con el nuevo “grupo vacío” Oracle DBA.

Acceder como SYSDBA a SQLPLUS sin conocer el password

De entrada esta “pretensión” de querer entrar a sqlplus sin conocer el password del usuario “SYS” puede ser una pretensión un tanto ambiciosa, pero que como podréis comprobar es más necesario de lo habitual y no es tan difícil.

En ocasiones, si eres un DBA de esos a los que tu empresa te manda cada dos por tres a clientes diferentes donde han pasado diferentes DBA´s y te encuentras que cuando llegas al cliente, ni el mismo cliente conoce los passwords ni de SYS ni de SYSTEM. Pero almenos se tiene acceso al servidor con cuentas de usuario de sistema operativo, si es la de oracle, ya tenemos mucho ganado, sino con root nos bastaría, o incluso, simplemente con poder acceder a una cuenta de usuario que nos permita crear usuarios y asignarle el grupo que deseamos, ya tendríamos solucionado el problema de no conocer el password de SYS o SYSTEM.

Os pongo en situación:

No conocemos el password de SYS ni de SYSTEM. Pero tenemos que realizar tareas de administración.

Nos tenemos que plantear lo siguiente…

- ¿ Tenemos acceso al servidor con un usuario de sistema operativo ? ¿ cúal ?
- ¿ Tenemos acceso al servidor con el usuario de sistema operativo oracle ?
- ¿ Tenemos acceso al servidor con  el usuario root ?

Pues si tenemos acceso con “root” al sistema operativo es fácil. Si hacemos el “su” al usuario oracle ya podremos acceder al servidor de base de datos de dos maneras diferentes con perfil de DBA.

# su – oracle
$ whoami
oracle

– Ahora entramos a sqlplus: forma 1
$ sqlplus “/as sysdba”
$ show user
SQL> show user
USER is “SYS”
SQL>

– O  entramos a sqlplus: forma 2
$ sqlplus /nolog
$ show user
SQL> show user
USER is “”
SQL> connect /as sysdba
SQL> show user
USER is “SYS”

Si tenemos acceso con el usario “oracle”, pues simplemente ejecutar cualquiera de las formas anteriores del ejemplo.

Y sino tenemos acceso con “root” pero tenemos acceso con un usuario que tenga permisos para crear usuarios y cambiar el grupo. Lo que deberíamos hacer es crearnos un usuario con cualquier nombre y asignarlo al grupo “dba”, configuraríamos el .profile (.bash_profile) del usuario el entorno Oracle (Path, ORACLE_HOME, ORACLE_SID, etc…) y entraríamos posteriormente con ese usuario al S.O y luego a sqlplus como lo hemos hecho en cualquiera de los dos ejemplos anteriores.

Para hacer lo comentado anteriormente, primero crearemos el usuario:

# useradd usuario_dba -m -g dba
# passwd usuario_dba
Introduciremos el password.

Ahora configuraremos el entorno Oracle para este usuario. Para ello es necesario conocer algunas de las variables de entorno imprescindibles que tendremos en un “.profile” del usuario “oracle”. Este profile nos sirve de ejemplo y lo tendremos que adaptar al entorno que queremos administrar, es decir, cambiar el ORACLE_HOME y el ORACLE_SID  y adecuarlo al entorno que vamos a administrar.

Ejemplo de .bash_profile en Linux RedHat válido para el entorno Oracle:

#vi  .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

# User specific environment and startup programs

PATH=$PATH:$HOME/bin

export PATH

ORACLE_HOME=/u/oracle/11.2.0/ORCL
export ORACLE_HOME

PATH=$PATH:$ORACLE_HOME/bin:$ORACLE_HOME/OPatch
export PATH

ORACLE_SID=ORCL
export ORACLE_SID

LD_LIBRARY_PATH=/usr/lib64:$ORACLE_HOME/lib
export LD_LIBRARY_PATH

ORACLE_UNQNAME=ORCL
export ORACLE_UNQNAME

Las líneas anteriores adaptadas al servidor en concreto que queramos administrar serán las que deberemos añadir en nuestro “profile” del usuario que hayamos creado.

Una vez hecho esto, ya podemos salir y volver a entrar con el usuario para cargar el profile y ejecutar sqlplus como en los primeros ejemplos. Finalmente, comentar que si quisíeramos cambiar una vez conectados a sqlplus, por ejemplo, el password del usuario SYSTEM, lo podríamos hacer sin ningún problema ejecutando:

SQL> alter user SYSTEM identified by “<nuevo password>”;

¿ No es tan complicado verdad ?

SHLIB_PATH y LD_LIBRARY_PATH y su relación con el error ORA-12547: TNS:lost contact

Al intentar conectar a Oracle versión 8.1.7.0 en un entorno HP-UX me encontré con el siguiente error:

# sqlplus scott/tiger

SQL*Plus: Release 8.1.7.0.0 – Production on Mon May 19 14:47:42 2003
(c) Copyright 2000 Oracle Corporation.  All rights reserved.
/usr/lib/pa20_64/dld.sl: Unable to find library ‘libjox8.sl’.
ERROR:
ORA-12547: TNS:lost contact
Enter user-name:

 ¿ Que puede estar sucediendo ?

Basicamente es que Oracle no puede encontrar las librerias dinámicas compartidas. Por tanto, la solución parece, a priori, ser bastante sencilla. Y de hecho lo es.

Las librerias o bibliotecas compartidas son librerias que cargan los programas cuando se inician. Cuando una biblioteca compartida se instala correctamente, todos los programas que se inician automáticamente usan esta biblioteca compartida. Es más, en Linux estas bibliotecas se pueden actualizar, se pueden anular íncluso funciones específicas de una determinada biblioteca, y todo esto mientras los programas están en ejecución.

Para poder realizar estas tareas, se pueden configurar variables de entorno que nos permitan controlar estos procesos y normalmente se suelen usar para sustituir una biblioteca por una diferente para una ejecución particular, como por ejemplo un entorno ORACLE determinado.

Es aquí donde prestan protagonismo las variables de entorno que hago referencia en esta entrada de blog.

LD _LIBRARY_PATH y SHLIB_PATH es un conjunto de directorios separados por “:” en donde se especifica o fija la ruta donde primero se tiene que buscar para encontrar las librerias necesarias para ejecutar cualquier programa, como por ejemplo sqlplus.

¿ Pero que diferencia hay o porqué se usa una u otra ?

LD_LIBRARY_PATH funciona en muchos sistemas Unix como Sun  y Linux, SHLIB_PATH sólo funciona en HP-UX y su equivalencia en AIX es la variable de entorno LIBPATH con la misma sintaxis, lista separada por “:”.

Lo que quiere decir que para sistemas HP-UX usaremos las dos variables de entorno (SHLIB_PATH y LD_LIBRARY_PATH) para Linux o Sun Solaris sólo LD_LIBRARY_PATH y para AIX LIBPATH.

Ahora, volvamos al error que nos ha dado ORACLE y vamos a solucionarlo ….

Simplemente editaremos el fichero donde tengamos definidas las variables del entorno Oracle (normalmente el .profile del usuario Oracle) y añadiremos las rutas que nos muestra el error Oracle (/usr/lib) a las variables de entorno que toque en función del sistema Unix/Linux en el que estemos trabajando. En mi caso era HP-UX y tuve que configurar el entorno como sigue:

export ORACLE_SID=ORCL
export ORACLE_HOME=/u/oracle
export PATH=$PATH:$ORACLE_HOME/bin:$ORACLE_HOME/lib:$ORACLE_HOME/lib32
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$ORACLE_HOME/lib32:/usr/lib
export SHLIB_PATH=/usr/lib:/psg_pr103/oracle/lib:/psg_pr103/oracle/lib64

Ahora ya podríamos ejecutar sqlplus sin problemas.

Configurar el fichero sudoers para poder usar el comando sudo en las instalaciones Oracle

En muchas ocasiones nos encontraremos que en la documentación de Oracle se ha de ejecutar alguna instrucción usando el comando “sudo” de Linux. Pero puede suceder que no tengamos configurada la posibilidad del uso de ese comando para el usuario oracle o el usuario que vayamos a utilizar para la instalación y nos sale un error como este:

$ sudo root

oracle is not in the sudoers file.  This incident will be reported.

Seguidamente os explico como podemos configurar el comando sudo para poderlo usar en Redhat de la misma manera como se usa en Ubuntu o Debian.

Tenemos que hacerlo conectados como “root”. O bien, pedirle al administrador que tenga la cuenta de root que haga lo siguiente:

editar el archivo /etc/sudoers.
$ su -
# vi /etc/sudoers

al final del archivo pondremos la siguiente línea (se debe poner el nombre de usuario que queremos que pueda usar el comando “sudo”, en este ejemplo “oracle”):
 
oracle ALL=(ALL) ALL

Con ésto ya podremos usar el comando sudo con nuestra cuenta de usuario “oracle” en este caso. Siempre y cuando en la variable de entorno del PATH del usuario Oracle tengamos definida la ruta donde se encuentra el comando “sudo” y el comando lo podamos ejecutar con el usuario en concreto (es decir, tenga permisos de ejecución para ese usuario).

Instalar OPatch en Linux RedHat 5.X en Oracle 11GR2

OPatch

Es una herramienta que usa Oracle para instalar sus propios parches. Se puede descargar de Oracle Support (antiguo metalink) buscando normalmente el Patch 6880880.

Pasos…

$ cd $ORACLE_HOME

Renombrar el antiguo OPatch instalado….

$ mv OPatch OPatchOLD

Copiar el fichero descargado comprimido de OPatch bajado de Internet al directorio $ORACLE_HOME.

Procurar tener la última versión de OPatch, que puedes obtener buscando el Patch 6880880 en Oracle Support (Antiguo metalink).

$ ls –l p6880880_112000_Linux-x86-64.zip

$ unzip p6880880_112000_Linux-x86-64.zip

$ opatch -help (en la cabecera sale la versión actualizada)

Tiene que salir el directorio OPatch ya creado y el OPatchOLD que renombramos anteriormente. Pues ya estaría instalado. Ahora para que funcione deberíamos configurar la variable de entorno para que se ejecute desde cualquier ruta.

Ya podríamos eliminar el fichero .zip del directorio OPatch creado.

Configurar la variable de entorno PATH del usuario Oracle:

Este paso se puede hacer antes o después de la instalación. Si se ha usado alguna vez OPatch, seguramente esta variable de entorno ya estará configurada.

Añadir :$ORACLE_HOME/OPatch a la variable de entorno PATH

Entrar como el usuario “oracle” al servidor:

$ vi ~/.bash_profile

Anadir la siguiente linea (texto en negrita) a la variable de entorno PATH….

PATH=$PATH:$ORACLE_HOME/bin:$ORACLE_HOME/OPatch
export PATH

Salir y volver a entrar con el usuario oracle para que se cargue la variable de entorno.

;-)