No xauth program cannot forward with spoofing

Al  tratar de realizar una conexión SSH con ambiente gráfico a un Servidor Solaris 11, me tope con el problema que al ejecutar un comando "xeyes" o "xclock" para verificar el ambiente gráfico, resulta que no se abría ninguno de estos clientes y se mostraba el mensaje "Can't open display".

Trate ejecutando como usuario root el comando "xhost +" con la finalidad que todos los usuarios pudiesen conectarse sin problemas, no obstante el problema persistía. Al ver el contenido de la variable DISPLAY, ésta no contenía nada y al tratar de asignar un valor a ésta como "IP:0.0" no parecía funcionar.

Por ultimo decidí realizar un debug del intento de conexión, para mi sorpresa encontré lo siguiente luego de ingresar el password del Servidor:

Password: 
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env XMODIFIERS = @im=none
debug1: Sending env LANG = en_US.UTF-8
debug1: Remote: No xauth program; cannot forward with spoofing.
debug1: Remote: Channel 0 set: LANG=en_US.UTF-8
Last login: Mon Dec 15 18:52:10 2014 from 192.168.1.59
Oracle Corporation      SunOS 5.11      11.2    June 2014
oracle@miservidor:~$

Respuesta: el paquete "xauth" no se encuentra instalado en el sistema. Instale el paquete con "pkg install xauth" y luego realice unas pruebas y funciono.

Saludos!

Obtener la Arquitectura del JDK (32 bits o 64 bits) en Unix

Si estamos en una plataforma que usa JDK híbrido como se es el caso de HP-PA, HP-IA o Solaris, el uso del argumento '-d64' es requerido.

Por ejemplo en Solaris 11 Sparc de 64bits:

java -d64 -version

Si estamos usando un JDK de 64bits éste comando nos mostrara correctamente que la versión es de 64bits, de lo contrario nos mostrará que la JVM no soporta 64bits. 

Nota: El uso del argumento '-d64' aparece desde la versión 1.7 por lo que en versiones anteriores no funcionara.

Localización de archivos oraInst.loc y oratab en Solaris 11

Estos archivos los encontramos comúnmente en Linux o en AIX en la ruta /etc no obstante para un Unix como es el caso de Solaris, la ruta donde se encuentran estos archivos es diferente.

En Solaris los encontramos en la ruta /var/opt/oracle

sun.security.pkcs11.ConfigurationException Unknown keyword 'useEcX963Encoding'

Cuando se está configurando Forms/Reports11gR2 en Solaris 11 Sparc y utilizar Jdk 1.7 puede que el asistente se quede en el paso de crear el servidor administrado WLS_FORMS. Si vamos a ver el log de éste Servidor veremos el siguiente mensaje de error:

java.lang.ExceptionInInitializerError
        at weblogic.rjvm.LocalRJVM.getLocalRJVM(LocalRJVM.java:72)
        at weblogic.rjvm.JVMID.<init>(JVMID.java:373)
        at weblogic.rjvm.JVMID.setLocalID(JVMID.java:239)
        at weblogic.rjvm.RJVMService.setJVMID(RJVMService.java:48)
        at weblogic.rjvm.RJVMService.start(RJVMService.java:30)
        at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
        at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
Caused By: java.security.ProviderException: Error parsing configuration
        at sun.security.pkcs11.Config.getConfig(Config.java:71)
        at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:110)
        at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:86)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
        at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:224)
        at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206)
        at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187)
        at sun.security.jca.ProviderList.getProvider(ProviderList.java:232)
        at sun.security.jca.ProviderList$3.get(ProviderList.java:147)
        at sun.security.jca.ProviderList$3.get(ProviderList.java:142)
        at java.util.AbstractList$Itr.next(AbstractList.java:358)
        at java.security.SecureRandom.getPrngAlgorithm(SecureRandom.java:542)
        at java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:187)
        at java.security.SecureRandom.<init>(SecureRandom.java:155)
        at weblogic.rjvm.LocalRJVM.<init>(LocalRJVM.java:90)
        at weblogic.rjvm.LocalRJVM.<init>(LocalRJVM.java:28)
        at weblogic.rjvm.LocalRJVM$LocalRJVMMaker.<clinit>(LocalRJVM.java:31)
        at weblogic.rjvm.LocalRJVM.getLocalRJVM(LocalRJVM.java:72)
        at weblogic.rjvm.JVMID.<init>(JVMID.java:373)
        at weblogic.rjvm.JVMID.setLocalID(JVMID.java:239)
        at weblogic.rjvm.RJVMService.setJVMID(RJVMService.java:48)
        at weblogic.rjvm.RJVMService.start(RJVMService.java:30)
        at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
Caused By: java.security.ProviderException: Error parsing configuration
        at sun.security.pkcs11.Config.getConfig(Config.java:71)
        at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:110)
        at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:86)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
        at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:224)
        at sun.security.jca.ProviderConfig$2.run(ProviderConfig.java:206)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.jca.ProviderConfig.doLoadProvider(ProviderConfig.java:206)
        at sun.security.jca.ProviderConfig.getProvider(ProviderConfig.java:187)
        at sun.security.jca.ProviderList.getProvider(ProviderList.java:232)
        at sun.security.jca.ProviderList$3.get(ProviderList.java:147)
        at sun.security.jca.ProviderList$3.get(ProviderList.java:142)
        at java.util.AbstractList$Itr.next(AbstractList.java:358)
        at java.security.SecureRandom.getPrngAlgorithm(SecureRandom.java:542)
        at java.security.SecureRandom.getDefaultPRNG(SecureRandom.java:187)
        at java.security.SecureRandom.<init>(SecureRandom.java:155)
        at weblogic.rjvm.LocalRJVM.<init>(LocalRJVM.java:90)
        at weblogic.rjvm.LocalRJVM.<init>(LocalRJVM.java:28)
        at weblogic.rjvm.LocalRJVM$LocalRJVMMaker.<clinit>(LocalRJVM.java:31)
        at weblogic.rjvm.LocalRJVM.getLocalRJVM(LocalRJVM.java:72)
        at weblogic.rjvm.JVMID.<init>(JVMID.java:373)
        at weblogic.rjvm.JVMID.setLocalID(JVMID.java:239)
        at weblogic.rjvm.RJVMService.setJVMID(RJVMService.java:48)
        at weblogic.rjvm.RJVMService.start(RJVMService.java:30)
        at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
        at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
Caused By: sun.security.pkcs11.ConfigurationException: Unknown keyword 'useEcX963Encoding', line 15
        at sun.security.pkcs11.Config.parse(Config.java:425)
        at sun.security.pkcs11.Config.<init>(Config.java:194)
        at sun.security.pkcs11.Config.getConfig(Config.java:67)

Para solucionar este error lo que debemos hacer es ir a modificar el archivo java.security que se encuentra en la ruta $JAVA_HOME/jre/lib/security

En el modificamos y quitamos la entrada siguiente:

security.provider.1=com.oracle.security.ucrypto.UcryptoProvider ${java.home}/lib/security/ucrypto-solaris.cfg
security.provider.2=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/sunpkcs11-solaris.cfg
security.provider.3=sun.security.provider.Sun
security.provider.4=sun.security.rsa.SunRsaSign
.....

A:

security.provider.1=com.oracle.security.ucrypto.UcryptoProvider ${java.home}/lib/security/ucrypto-solaris.cfg
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
....

Nota: Asegurarse de reajustar el correlativo de los provider 1,2,3,4....

Luego de éste cambio reintentamos el paso en el cual se quedo el  asistente y continuará sin problemas.

Nota2: Otro workaround por éste error sería utilizar JDK 1.6

Instalar JDK 1.7 en Oracle Solaris 11

Resulta que tuve que instalar un JDK 1.7 64bits en Oracle Solaris 11 para una instalación que tengo que realizar de Forms y pues nunca pensé que éste tipo de instalación me diera alguna clase de problema, pero resulta que si tiene su truco poder completarla.

Luego de haber descomprimido el JDK descargado (que pesa como 16MB) y posteriormente ejecutar el comando "java -version" obtuve la siguiente salida:

Error occurred during initialization of VM
java/lang/NoClassDefFoundError: java/lang/Object

Resulta que éste JDK por su tamaño al parecer no viene por completo, que se debe hacer ?? se debe hacer lo siguiente:

- Bajar el JDK 1.7 32bits
- Bajar el JDK 1.7 64bits
- Descomprimir primero el JDK de 32bits
- Descomprimir posteriormente el JDK de 64bits en el mismo lugar donde está el de 32bits (solo debe quedar una carpeta).

En otras palabras se combina los dos JDK, es por ello que el JDK de 64bits es tan pequeño en tamaño, pues al final hay que combinarlo con el de 32bits. Haciendo eso el "java -version" ya muestra la salida correctamente.

Acceder directamente como usuario root en Solaris 11

Por defecto, luego de haber instalado Solaris 11 no se puede acceder directamente como usuario root. Esto se debe a que éste se encuentra como rol.

Veremos un mensaje como el siguiente:
Roles can not login directly

Accedamos como un usuario administrador, hacemos su a root e invocamos el comando cat /etc/user_attr para ver los atributos de los usuarios, con lo que veremos que efectivamente root es un rol:

Para arreglar esto siempre como usuario root ejecutamos el comando: rolemod -K type=normal root

Con ésto ya podremos iniciar sesión como usuario root.

Como acceder a Solaris por medio de SSH

Un día me encontré con el problema que al tratar de acceder a un Oracle Solaris 10 a través de SSH, la conexión se establecía, pero al ingresar el password del usuario con el que trataba de acceder nunca era reconocido, esto se debe a que por defecto Solaris no permite el acceso mediante SSH.

Para habilitar el acceso hay que seguir estos simples pasos:

1. Conectados como usuario root, modificamos el siguiente archivo:  /etc/ssh/sshd_config
2. Luego buscamos la siguiente entrada en ese archivo que hemos abierto:  PermitRootLogin
3. Por defecto la entrada tiene no es por ello que la cambiaremos por: yes
4. Grabamos los cambios.
5. Finalmente debemos reiniciar el servicio de SSH para que este reconozca los nuevos cambios, para ello ejecutaremos los siguientes comandos en el siguiente orden:

• svcadm disable ssh
• svcadm enable  ssh

Con esto, ya podremos acceder a nuestro servidor Solaris a través de SSH.

Como cambiar el Hostname en Oracle Solaris 10

Si al momento de instalar Oracle Solaris en su versión 10 no se muestra la opción para cambiar el Hostname de nuestro nuevo sistema, deberemos seguir los siguientes pasos para cambiar el Hostname:


1) Crearemos el siguiente archivo:

     vi /etc/nodename

     Agregamos a este archivo el nombre que le queremos poner a nuestro servidor.
     Por ejemplo:  db-repository

2) Luego debemos modificar el siguiente archivo: vi /etc/hosts
Modificamos la entrada donde tenemos nuestra ip hasta que nos quede por ejemplo así:

    #
    # Internet host table
    #
    ::1 localhost
    127.0.0.1 localhost
    192.168.10.199 db-repository

3) Por último debemos modificar el siguiente archivo, que por defecto esta vació vi/etc/hostname.e1000g0

    Nota: e1000g0 es el nombre de la interfaz de nuestro servidor, la cual puede ser diferente en su caso.

    Agregamos a este archivo el mismo nombre de hostname que hemos ido agregando a los archivos que hemos ido modificando.

4) Finalmente reiniciamos nuestro servidor:   init 6

Cuando ya se haya reiniciado nuestro servidor, podemos verificar que nuestro servidor tenga el hostname que hemos especificado, para ello ejecutamos el siguiente comando, el cual nos debe mostrar el hostname que decidimos:

    bash-3.2# hostname 

    db-repository