Search for a command to run...
![[OCI] Recuperación del acceso de un IaaS](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1752424474347%2Fafc877a0-a390-4874-944b-6f2720c22825.png&w=3840&q=75)
Ingeniero informático, Oracle ACE, DBA y Arquitecto OCI, con más de 15 años de experiencia en plataformas Oracle. Certificado en OCI Certified Architect Professional y OCI Migration and Integration Certified Professional.
No comments yet. Be the first to comment.
Os paso un script sencillo para supervisar nuestro Oracle Data Guard, cuya función es enviarnos una alerta si se detectan errores o advertencias. En caso que nuestro script haya detectado problemas, nos enviará un correo con la siguiente información:...
En el artículo de hoy vamos a ver las Calendar functions en 26ai, diseñadas para simplificar la "vida" a los desarrolladores. Antes de su existencia, esto se resolvía con ingeniosas combinaciones usan
![[26ai] SQL: Calendar functions/Aggregation Filters "CALENDAR"](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F587e3328-9877-4c7a-aad7-7811e251f81e.png&w=3840&q=75)
En el artículo de hoy vamos a ver como podemos recrear una PDB$Seed de manera fácil en caso que se quede corrupta y no tengamos backup. sys@> alter pluggable database PDB$SEED open read only; alter pl
![[OCI] Recreación PDB$SEED](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F289ede5b-558c-4f93-b5c0-fa04680c91ca.png&w=3840&q=75)
El artículo también se encuentra publicado en Ingles English version. En el artículo de hoy vamos a ver como podemos clonar una PDB usando RMAN Active Duplicate o bien usando una instrucción DDL entre
![[OCI] Clone PDB](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F8ce0c665-4a5d-459d-91cf-ffe3f47d8176.png&w=3840&q=75)
El artículo también se encuentra publicado en Ingles English version. En el artículo de hoy voy a compartir un sh que utilizo para ver de una manera rápida los jobs que se ejecutan desde Oracle Databa
![[OCI] Check Jobs DBCli](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F1376a869-58fa-491e-926a-a6ead08f9c80.png&w=3840&q=75)
El artículo también se encuentra publicado en Ingles English version. En el artículo de hoy vamos a ver la nueva sintaxis introducida para simplificar aún más los joins evitando errores comunes, hacie
![[26ai] JOIN_TO_ME](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F16a23f6e-ec4c-4f0a-9529-2c8a2af2ef5e.png&w=3840&q=75)
Vamos a ver como podríamos recuperar de forma fácil el acceso a un IaaS al que se ha perdido el authorized_keys del usuario opc.
Antes de entrar en faena, vamos hacer un pequeño resumen de lo que es cada punto:
authorized_keys: fichero que contiene las claves públicas para poder acceder a un servidor sin contraseña.
opc “Oracle Public Cloud”: cuenta del administrador del sistema. Todos los recursos que tengamos en nuestra tenancy, a la hora de acceder lo haremos con este usuario.
Accedemos a nuestra máquina y listamos el contenido de /home/opc/.ssh.
[opc@zdm-host .ssh]$ ls -lac
total 16
drwx------. 2 opc opc 75 Jul 13 14:24 .
drwx------. 5 opc opc 4096 Oct 18 2023 ..
-rw-------. 1 opc opc 400 Oct 18 2023 authorized_keys
-rw-rw-r--. 1 opc opc 514 Oct 18 2023 authorized_keys.zip
-rw-r--r--. 1 opc opc 203 Oct 30 2023 known_hosts
Ahí podemos ver diferentes archivos, ninguna clave pública ni privada, solo el authorized_keys, un backup del mismo y el known_hosts. Procedemos a eliminar el authorized_keys e intentamos loguearnos de nuevo:
¡Upps! Efectivamente, hemos perdido el acceso a nuestra máquina.
Esto es algo que nos puede pasar en el día a día, alguien borro sin querer el authorized_keys o bien que se ha corrompido o simplemente que modificaron los permisos del fichero. En este caso hay un backup, pero en el caso que no lo tengamos, tendríamos que generar nosotros la clave.
Para ambos problemas, la manera de solucionarla es idéntica.
Para poder solucionarlo tendremos que hacer un detach de nuestro boot volumen para adjuntarlo en otro IaaS.
Así que… let's get down to business!
Primer paso es detener la instancia afectada:
Una vez detenida, procedemos a realizar el detach del boot volumen. Para ello vamos a la sección de “Storage” y ahí veremos nuestro boot volumen.
Una vez que la operación ha terminado, el estado del boot volumen pasará a “Detached”
Antes de pasar al siguiente punto, recomiendo copiar el OCID:
Vamos a la IaaS donde vamos a realizar la recuperación del mismo. El primer paso que tenemos que hacer es adjuntar ahí nuestro boot volume. Para hacerlo iríamos a la sección de “Storage” y de ahí a “Attach block Volume”
En esta nueva ventana que aparece nos pedirá una serie de información acerca del boot volume. Copiamos ahí el OCID que habíamos copiado previamente e indicamos que queremos tener acceso read/write
Una vez finalizada podremos ver nuestro boot volume se ha adjuntado de manera correcta.
Si accedemos a la máquina, podemos ver el volumen que hemos adjuntado (/dev/sdb3):
[root@test ~]# fdisk -l /dev/sdb
Disk /dev/sdb: 200 GiB, 214748364800 bytes, 419430400 sectors
Disk model: BlockVolume
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 1048576 bytes
Disklabel type: gpt
Disk identifier: AEAC51C9-5D28-48CB-82FF-1B7312827FEB
Device Start End Sectors Size Type
/dev/sdb1 2048 411647 409600 200M EFI System
/dev/sdb2 411648 17188863 16777216 8G Linux swap
/dev/sdb3 17188864 419430365 402241502 191.8G Microsoft basic data
El siguiente paso es marcar como disponible para el S.O nuevo boot volumen por medio del comando mount:
[root@test ~]# mount -o nouuid /dev/sdb3 /mnt
[root@test ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 7.6G 0 7.6G 0% /dev/shm
tmpfs 3.1G 8.7M 3.1G 1% /run
efivarfs 256K 17K 235K 7% /sys/firmware/efi/efivars
/dev/mapper/ocivolume-root 30G 9.4G 21G 32% /
/dev/sda2 2.0G 412M 1.6G 21% /boot
/dev/mapper/ocivolume-oled 15G 178M 15G 2% /var/oled
/dev/sda1 100M 6.3M 94M 7% /boot/efi
tmpfs 1.6G 0 1.6G 0% /run/user/989
tmpfs 1.6G 0 1.6G 0% /run/user/1000
/dev/sdb3 192G 13G 179G 7% /mnt
Accedemos a /mnt/home/opc/.ssh para recuperar nuestro authorized_keys.
[root@test ~]# cd /mnt/home/opc/.ssh
[root@test .ssh]# unzip authorized_keys.zip && chown opc:opc authorized_keys
Archive: authorized_keys.zip
[root@test .ssh]# ls -lac
total 16
drwx------. 2 opc opc 75 Jul 13 15:38 .
drwx------. 5 opc opc 4096 Oct 18 2023 ..
-rw-------. 1 opc opc 400 Jul 13 15:38 authorized_keys
-rw-rw-r--. 1 opc opc 514 Jul 13 14:24 authorized_keys.zip
-rw-r--r--. 1 opc opc 203 Oct 30 2023 known_hosts
Accedemos, realizamos unzip y cambiamos el propietario/grupo del fichero.
Desmontamos /mnt y comprobamos que ya no se encuentra accesible, para poder realizar detach de nuevo:
[root@test ~]# umount /mnt
[root@test ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 7.6G 0 7.6G 0% /dev/shm
tmpfs 3.1G 8.7M 3.1G 1% /run
efivarfs 256K 17K 235K 7% /sys/firmware/efi/efivars
/dev/mapper/ocivolume-root 30G 9.4G 21G 32% /
/dev/sda2 2.0G 412M 1.6G 21% /boot
/dev/mapper/ocivolume-oled 15G 178M 15G 2% /var/oled
/dev/sda1 100M 6.3M 94M 7% /boot/efi
tmpfs 1.6G 0 1.6G 0% /run/user/989
tmpfs 1.6G 0 1.6G 0% /run/user/1000
Perfecto, vamos adjuntar de nuevo el boot volumen en la IaaS que habíamos perdido acceso:
Una vez terminada la operación, arrancamos de nuevo el entorno de nuevo y verificamos que hemos recuperado el acceso:
Using username "opc".
Authenticating with public key "imported-openssh-key"
Last login: Sun Jul 13 14:06:47 2025 from 10.98.140.36
[opc@zdm-host ~]$
Perfecto, tenemos acceso de nuevo. ¡Espero que os sirva!