miércoles, 29 de agosto de 2018

Oracle: file 1 needs to be either taken out of backup mode or media recovered



Cómo arrancar una base de datos Oracle cuando nos encontramos con este mensaje.



Hoy he tenido que re-arrancar una base de datos Oracle por problemas con una aplicación y al re-arrancarla, la base de datos no se iniciaba. Al inspeccionar el log de conexión, me he encontrado con que justo después de ejecutar el comando startup, aparecía el siguiente mensaje:

file 1 needs to be either taken out of backup mode or media recovered

Por lo visto, había algún proceso de backup de la base de datos que se había quedado zombie en memoria y no permitía al Oracle arrancar normalmente.

Para poder iniciar la base de datos con normalidad, he tenido que finalizar este proceso de backup y re-abrir la base de datos. Los pasos para finalizar el proceso de backup y rearrancar la BBDD han sido:

Nos conectamos a la base de datos:

root@epwprd:/>su - oradb1 epwprd:oradb1 1>sqlplus /nolog SQL*Plus: Release 11.2.0.3.0 Production on Mon Aug 29 16:46:53 2018 Copyright (c) 1982, 2011, Oracle. All rights reserved. SQL>connect /as sysdba Connected. SQL>

A continuación, verificamos el status del backup:

SQL> select * from V$BACKUP; FILE# STATUS CHANGE# TIME ---------- ------------------ 1 ACTIVE 504855 29-AUG-18 2 ACTIVE 504860 29-AUG-18 3 ACTIVE 504865 29-AUG-18 4 ACTIVE 504870 29-AUG-18 5 ACTIVE 504870 29-AUG-18 6 ACTIVE 504875 29-AUG-18 7 ACTIVE 504875 29-AUG-18 8 ACTIVE 504881 29-AUG-18 8 rows selected.

Finalizamos el proceso de backup:

SQL> ALTER DATABASE END BACKUP; Database altered.

Re-abrimos la base de datos:

SQL> alter database open; Database altered.

Si verificamos el estado del backup, vemos que ya no está activo:

SQL> select * from V$BACKUP; FILE# STATUS CHANGE# TIME ---------- ------------------ 1 NOT ACTIVE 504855 29-AUG-18 2 NOT ACTIVE 504860 29-AUG-18 3 NOT ACTIVE 504865 29-AUG-18 4 NOT ACTIVE 504870 29-AUG-18 5 NOT ACTIVE 504870 29-AUG-18 6 NOT ACTIVE 504875 29-AUG-18 7 NOT ACTIVE 504875 29-AUG-18 8 NOT ACTIVE 504881 29-AUG-18 8 rows selected.

A partir de este momento, ya podemos realizar el proceso de startup de Oracle con normalidad.
0

miércoles, 22 de agosto de 2018

Acceder por SSH con usuario de Active Directory



Cómo acceder a un sistema operativo Linux vía SSH con un usuario y contraseña de una cuenta de directorio activo (Active Directory). Probado en SUSE Linux Enterprise Server.



Si queremos acceder a una máquina Linux vía SSH usando un usuario y contraseña de una cuenta de directorio activo (Active Directory), podemos hacerlo de la siguiente forma en SUSE Linux Enterprise.

Instalamos samba, winbind y kerberos, con todos sus paquetes:

HOST# zypper install krb5* samba*

A continuación, debemos editar varios archivos de configuración. En cada uno de ellos, cambiaremos los valores DOMINIO y DOMINIO.LOCAL por el nombre de dominio de nuestra empresa.

Empezamos por el archivo de configuración de samba. Reemplazamos su contenido:

HOST# vi /etc/samba/smb.conf

[global] workgroup = DOMINIO idmap gid = 10000-20000 idmap uid = 10000-20000 kerberos method = secrets and keytab realm = DOMINIO.LOCAL security = ADS template homedir = /home/%D/%U template shell = /bin/bash winbind offline logon = yes winbind refresh tickets = yes winbind use default domain = yes

NOTA: la última línea, "winbind use default domain = yes", hace que nos podamos logear con el usuario de dominio directamente, sin tener que usar "DOMINIO/usuario" como nombre de usuario de Linux.

Editamos el archivo de configuración de kerberos y lo reemplazamos:

HOST# vi /etc/krb5.conf

[libdefaults] default_realm = DOMINIO.LOCAL clockskew = 300 [realms] DOMINIO.LOCAL = { kdc = dc1.dominio.local default_domain = DOMINIO.LOCAL admin_server = dc1.dominio.local } [domain_realm] .dominio.local = DOMINIO.LOCAL [appdefaults] pam = { ticket_lifetime = 1d renew_lifetime = 1d forwardable = true proxiable = false minimum_uid = 1 }

Editamos el archivo de configuración winbind de PAM y lo reemplazamos:

HOST# vi /etc/security/pam_winbind.conf

[global] cached_login = yes krb5_auth = yes krb5_ccache_type = FILE

Editamos nsswitch.conf y añadimos compatibilidad con winbind en estos dos parámetros:

HOST# vi /etc/nsswitch.conf

passwd: compat winbind group: compat winbind

Debemos asegurarnos de tener configurado un servidor de consulta DNS que tenga acceso al dominio:

HOST# cat /etc/resolv.conf nameserver 192.168.110.4 nameserver 192.168.110.5

HOST# ping dominio.local PING dominio.local (192.168.110.4) 56(84) bytes of data. 64 bytes from dc1.dominio.local (192.168.110.4): icmp_seq=1 ttl=128 time=0.1ms 64 bytes from dc1.dominio.local (192.168.110.4): icmp_seq=2 ttl=128 time=0.2ms 64 bytes from dc1.dominio.local (192.168.110.4): icmp_seq=3 ttl=128 time=0.2ms 64 bytes from dc1.dominio.local (192.168.110.4): icmp_seq=4 ttl=128 time=0.2ms ^C --- dominio.local ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3049ms rtt min/avg/max/mdev = 0.161/0.202/0.231/0.031 ms

Unimos la máquina al dominio:

HOST# net ads join -U Administrador%Password Using short domain name -- DOMINIO Joined 'HOST' to dns domain 'dominio.local'

Activamos winbind como login source en PAM:

HOST# pam-config --add --winbind

Activamos la creación automática de carpetas /home/DOMINIO/usuario para que los usuarios puedan entrar al sistema (sin carpeta home no pueden acceder por SSH):

HOST# pam-config -a --mkhomedir

Arrancamos samba y winbind:

HOST# systemctl start smb

HOST# systemctl start winbind

Hacemos que sean persistentes a resets de la máquina:

HOST# systemctl enable smb Created symlink /etc/systemd/system/multi-user.target.wants/smb.service → /usr/lib/systemd/system/smb.service.

HOST# systemctl enable winbind Created symlink /etc/systemd/system/multi-user.target.wants/winbind.service → /usr/lib/systemd/system/winbind.service.

Limpiamos la cache de login. De esta manera, los usuarios de dominio ya podrán acceder vía SSH sin necesidad de reiniciar la máquina para aplicar cambios:

HOST# systemctl stop nscd

HOST# nscd -i passwd

HOST# nscd -i group

HOST# systemctl start nscd

Por último, elegimos qué usuarios del dominio podrán acceder vía SSH al servidor añadiéndolos manualmente al archivo de configuración de SSH (sino, todos los usuarios del dominio tienen acceso):

HOST# vi /etc/ssh/sshd_config

AllowUsers root blai

NOTA: poner aquí también todos los usuarios locales - como root - a los que queramos seguir permitiendo acceder al servidor vía SSH. Los usuarios deben estar separados por espacios.

Por último, reiniciamos el daemon de sshd para aplicar los cambios:

HOST# service sshd restart

A partir de ahora, ya podemos acceder al servidor que acabamos de configurar usando nuestro nombre de usuario de dominio y su correspondiente password.
0

miércoles, 15 de agosto de 2018

Cambiar DNS de un pool DHCP en un switch Aruba



Cómo modificar, paso a paso, la lista de servidores de consulta DNS de un pool de DHCP que sirve direcciones IP a PCs de oficina en un switch de la marca Aruba.



Recientemente, tuve que modificar (añadir) servidores de consulta DNS a un pool DHCP en un switch Aruba / HPE. Para hacer este cambio, tenemos que modificar el apartado "dns-server" dentro del pool donde está configurado el DHCP para la red que nos interesa.

La configuración original que me encontré era parecida a esta:

# sh conf [...] dhcp-server pool "DHCP-Workstation" default-router "10.0.1.10" dns-server "192.168.10.20,8.8.8.8" domain-name "empresa.local" network 10.0.1.0 255.255.255.0 range 10.0.1.51 10.0.1.254 exit dhcp-server enable [...]

Para realizar el cambio de servidores DNS, primero tenemos que deshabilitar el DHCP en el switch:

# dhcp-server disable

Ahora accedemos al pool en cuestión para configurarlo:

# dhcp-server pool "DHCP-Workstation"

Si no hemos deshabilitado el pool antes de reconfigurarlo, el switch nos devolverá el siguiente error:

# dhcp-server pool "DHCP-Workstation" DHCP server should be disabled before changing the reconfiguration.

Modificamos la lista de servidores de consulta DNS estableciendo un nuevo valor para dns-server. Las IPs de los servidores de consulta deben ir separadas por comas:

# dns-server "192.168.10.20,192.168.10.21,192.168.30.20,8.8.8.8"

Guardamos los cambios en memoria:

# wr mem

Verificamos que la nueva configuración haya quedado guardada:

# sh conf [...] dhcp-server pool "DHCP-Workstation" default-router "10.0.1.10" dns-server "192.168.10.20,192.168.10.21,192.168.30.20,8.8.8.8" domain-name "empresa.local" network 10.0.1.0 255.255.255.0 range 10.0.1.51 10.0.1.254 exit dhcp-server enable [...]

Activamos de nuevo el dhcp:

# dhcp-server enable

Y guardamos este último cambio en memoria:

# wr mem

A partir de este momento, los PCs que reciban IP por DHCP a través de este switch ya accederán a los nuevos servidores de consulta DNS cuando tengan que resolver FQDNs.
0

miércoles, 8 de agosto de 2018

Error de SSL Cipher al acceder a un Sonicwall



Cómo acceder a un firewall Sonicwall cuando el navegador nos dice SSL_ERROR_NO_CYPHER_
OVERLAP o ERR_SSL_VERSION_OR_CIPHER_MISMATCH al acceder vía http/https al Sonicwall.




Recientemente, me encontré con un error al acceder vía navegador a un firewall de la marca Sonicwall. Al acceder vía Firefox, el navegador me devolvía el siguiente error (SSL_ERROR_NO_CYPHER_OVERLAP):



Al probarlo desde Chrome, aparecía un error parecido (ERR_SSL_VERSION_OR_CIPHER_MISMATCH):



Estos errores se debían a que el dispositivo usaba una versión antigua de SSL que los navegadores modernos ya no soportan. Por ello, intenté acceder al Sonicwall via HTTP, pero este redirigía todas las peticiones hacia HTTPS, así que no había forma de acceder sin SSL.

En Chrome y Firefox ya no es posible elegir protocolos SSL inferiores a TLS 1.0, por lo que lo que hice fue acceder con Internet Explorer, navegador que aún permite configurar SSL 3.0.

Para usar SSL 3.0 en Internet Explorer hace falta activarlo primero. Para ello, clicamos el icono "Herramientas" y vamos a "Opciones de Internet". Luego vamos a la pestaña "Opciones avanzadas" y nos desplazamos hasta la parte inferior hasta llegar a la opción "SSL 3.0":



Marqué la opción SSL 3.0 y ahora sí, ya pude acceder al Sonicwall:



Al acceder al panel de administración del Sonicwall, vi que este estaba usando el firmware versión 5.8.1.15 (una versión muy antigua), por lo que realicé una actualización de firmware del Sonicwall. Después de esto, el dispositivo ya funcionó correctamente con TLS 1.0+ en navegadores actuales.
0

miércoles, 1 de agosto de 2018

No RDP por actualización Oracle cifrado CredSSP



Cómo solucionar "Error de autenticación" a un escritorio remoto por la actualización de Oracle de cifrado CredSSP. Cómo volver a conectar por escritorio remoto a un servidor afectado.



Si te has conectado a un servidor Windows por escritorio remoto y te has encontrado con esta ventana:



Microsoft ofrece varias formas de solucionar este problema ocasionado por una actualización de seguridad, pero la solución más simple, bajo mi punto de vista, no se contempla en su artículo. Mi propuesta para solucionar el error es la siguiente.

Accedemos al explorador de archivos de Windows, hacemos clic derecho sobre Equipo/Computer y nos dirigimos al apartado Propiedades/Properties:



A continuación, nos dirigimos a Configuración de acceso remoto/Remote Settings:



La configuración que no nos permite conectar por RDP es la opción "permitir solo conexiones desde ordenadores que ejecuten escritorio remoto con Network Level Authentication":



Para poder volver a conectar vía RDP, cambiamos la opción seleccionada por "Permitir conexiones desde ordenadores que ejecuten cualquier versión de escritorio remoto":



Aplicamos los cambios y ya podremos conectar por escritorio remoto como lo hacíamos hasta ahora.
0