Hay dos formas de hacerlo, una es mediante el comando sys-unconfig (mirar la página de manual para más información) como ‘single user mode’, que lo que hace es borrar la configuración de red (dirección IP, máscara, gateway, hosts, tablas de rutas,…) y reiniciar el sistema. Cuando reinicia vuelve a pedir toda la información pertinente.

Otro método es tocar los ficheros de configuración. También conviene hacer estas modificaciones como ‘single user mode’. Los ficheros que hay que tocar son:
/etc/inet/netmasks    En este archivo se pone la máscara de red y la red.
/etc/inet/hosts           En este archivo se pone la dirección IP del servidor y el nombre con el que va asociado.
/etc/defaultrouter      En este archivo se pone la gateway por defecto. Puede no existir, no pasa nada. En ese caso revisar el fichero de las tablas de rutas.
/etc/hostname.<interface>     En este archivo debe estar el nombre asociado en /etc/inet/hosts con la dirección IP
/etc/net/*/hosts        En estos ficheros debe estar el nombre asociado con la IP en /etc/inet/hosts

Para entrar en ‘single user mode’, ejecutar como root el comando ‘/sbin/init S’. Con esto se pierde el acceso desde red, por lo que se debe ejecutar desde la consola.

Los cambios tendrán efecto después de reiniciar el servidor (o en su defecto, después de tirar abajo la interfaz de red y volverla a levantar, pero al tirarla no la tendremos disponible, por lo que hay que hacerlo desde consola).

Una  de dos, o detenemos automonter, o editamos el fichero /etc/auto_master y comentamos/eliminamos las entradas relativas a estos directorios.

Si bien Solaris es un Unix, con muchas características comunes con Linux, la forma de trabajar cambiará completamente, al no disponer de nuestros comandos favoritos de Linux, y tener Solaris otra terminología, para los dispositivos conectados al sistema.

La red, por supuesto, no podía ser una excepción, así que tenemos que olvidarnos del clásico eth0.

Recomiendo tomar nota del nombre de los dispositivos de red, al instalar el sistema, pero si no lo hemos hecho, podemos recurrir al siguiente comando, para saber cuál es nuestro dispositivo:

bash-3.00# kstat -c net | grep net
name:   bge0                            class:    net
name:   chipid                          class:    net
name:   driverinfo                      class:    net
name:   mii                             class:    net
name:   parameters                      class:    net
name:   phydata                         class:    net
name:   statistics                      class:    net
name:   dls_stat                        class:    net
name:   ip6stat                         class:    net
name:   ipdrop                          class:    net
name:   ipsec_stat                      class:    net
name:   ipstat                          class:    net
name:   ah_stat                         class:    net
name:   esp_stat                        class:    net
name:   lo0                             class:    net
name:   strstat                         class:    net
name:   tcpstat                         class:    net
name:   udpstat                         class:    net

Nuestro dispositivo es bge0
Como queremos saber qué hace este comando kstat, hacemos un man kstat,
"The kstat utility examines the available kernel  statistics,
 or  kstats, on the system and reports those statistics which
 match the criteria  specified  on  the  command  line.  Each
 matching statistic is printed with its module, instance, and
 name fields, as well as its actual value.
....."

bash-3.00# ifconfig bge0
bge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
 inet 10.150.10.205 netmask ffffff00 broadcast 10.150.10.255
 ether 0:18:8b:11:4f:59

Para permitir la entrada de root a través de este servicio, tenemos que editar el archivo /etc/ssh/sshd_config, y modificar la siguiente linea:

PermitRootLogin yes

Hecho esto, hemos de reiniciar el servicio ssh, con svcadm (service admin ?), que intuyo debe ser el comando que sustituye a los clásicos ‘service ssh restart’ o ‘/etc/init.d/ssh restart’

#svcadm restart ssh

Para cambiar la distribución del teclado a Spanish(104-Key), editamos el  archivo /boot/solaris/bootenv.rc, y añadimos/modificamos la siguiente linea:

setprop kbd-type ‘Spanish’

Aparte, desde Lanzador/Preferencias/Preferencias del Escritorio/Teclado/Comportamiento, pestaña de Distribuciones, deberíamos también elegir la distribución de nuestro agrado.

La instalación de Solaris por defecto no tiene mayor pega, y podemos recurrir a esta guia si fuera necesario.

Finalmente, instalaremos Oracle Database siguien esta última guia

En mi caso, me pasó hace dos dias que por error se borró TODA la documentación del proyecto más importante de la empresa (unos 5 gigazos) :-s   Lo suyo habría sido echar mano de las copias de seguridad, pero por un error humano, dichas copias no apuntaban al directorio correcto, o la docu no estaba en el directorio adecuado, que es lo mismo.

La opinión más extendida es que no se pueden recuperar archivos de una partición ext3, de hecho, si nos vamos al F.A.Q. de este sistema de archivos, podemos leer lo siguiente:

“Q: How can I recover (undelete) deleted files from my ext3 partition?

Actually, you can’t! This is what one of the developers, Andreas Dilger, said about it:

In order to ensure that ext3 can safely resume an unlink after a crash, it actually zeros out the block pointers in the inode, whereas
ext2 just marks these blocks as unused in the block bitmaps and marks the inode as “deleted” and leaves the block pointers alone.

Your only hope is to “grep” for parts of your files that have been deleted and hope for the best.”

Afortunadamente,  existen algunos irreductibles galos que resisten ahora y siempre a lo imposible, y hoy en concreto, voy a presentar una herramienta opensource, ext3grep, cuyo objetivo es recuperar archivos borrados del disco duro. Esta herramienta no es válida para recuperar particiones dañadas, ni nada por el estilo, tan sólo es para recuperar archivos borrados, y se basa en la búsqueda recursiva de inodos.

Pero antes de presentar la herramienta en sí, daré unas pautas y/o consejos, por si alguna vez os veis en una situación parecida…

- En primer lugar, cuanto antes se detecte la pérdida, más probabilidades de recuperar la información tenemos, como la mayoría sabrá, el recuperar un archivo o no muchas veces depende de si los bloques en los que residía esa información han sido sobreescritos, o no, ya que al hacer un borrado no se borra fisicamente la información, tan sólo las referencias a que esos datos existen. Por tanto, nada más detectar la pérdida de datos, hay que desmontar la partición, con un umount /miparticion .

- Por multitud de motivos, podemos querer hacer el trabajo de restauración desde otro ordenador, en este caso, y si no podemos desmontar fisicamente el disco duro para llevárnoslo, podemos hacer una copia a bajo nivel de la partición, usando dd : este programa copia bloques de disco duro, tal cual están, de un dispositivo a otro. Previo a este paso necesitaríamos preparar el disco duro sobre el que vamos a hacer la copia. Yo cogí un disco en buenas condiciones (no interesan disco con muchos bloques defectuosos), le hice una partición EXACTAMENTE IGUAL que la que tenía que recuperar, con los mismos cilindros, y el mismo tipo de sistema de ficheros (linux) usando fdisk, y no la formateé. Desconozco si de otras maneras también funcionaría, yo lo hice así y me funcionó :-p

La sintaxis para dd es sencilla, en este caso:  #dd if=/dev/sdORIGEN of=/dev/sdDESTINO input file= partición/disco origen  output file= partición/disco destino. Mucho ojo con el comando éste, que la podéis liar gorda si os equivocáis en el input y el output. En mi caso, para copiar 18 GigaBytes, de una partición de 38GB, tardé poco más de 3 horas, teniendo el disco destino por USB 2.0, y el de origen conectado por SATA, internamente, con una controladora RAID de por medio.

Bien, vamos al meollo, la recuperación de datos en sí. La herramienta que yo he utilizado, y que me ha dado unos resultados excelentes, es ext3grep, os recomiendo leeros la documentación al respecto, y aunque al final la herramienta es bastante sencilla de usar, nunca está de más saber bien cómo funcionan las cosas, sobretodo en casos tan críticos, donde meter la pata puede tener un coste muy alto.

Existen dos posibilidades, recuperar archivos individuales, o todos los archivos encontrados. La primera opción nos dará mayor precisión, pero es necesario conocer el nombre del archivo.  Con la segunda opción, recuperaremos más archivos, pero también recogeremos toda la ‘basura’ que todavía esté ‘disponible’

Al restaurar, se  creará un directorio RESTORED_FILES/, en nuestra ruta actual, donde guardará lo recuperado, respetando la jerarquía de directorios. Ni que decir que debéis posicionaros en una ruta diferente de aquella de dónde pretendéis recuperar datos (para algo hemos desmontado previamente la partición, para evitar errores de este tipo)

Previamente, definimos $IMAGE  como la ruta de la partición a restaurar:

$IMAGE=/dev/sdc1  (o la partición que toque, nótese que /dev/sdc no es una partición válida)

-Restaurar un fichero:


$ ext3grep $IMAGE --restore-file carlo/bin/start_kvm
[...]
Restoring carlo/bin/start_kvm

$ cat RESTORED_FILES/carlo/bin/start_kvm
#! /bin/sh
cd /usr/src/qgt/src
./host-linux 192.168.2.4 &
cd /opt/kvm/winXPpro
sudo modprobe kvm_intel
sudo kvm -m 384 -hda vdisk6GB.img -cdrom /dev/cdrom -localtime -std-vga -net nic,vlan=0,model=rtl8139 -net tap,vlan=0
#-snapshot # -daemonize
killall -9 host-linux

-Restaurar todos los ficheros:

$ ext3grep $IMAGE --restore-all

Después de un rato, no muy largo, tendremos nuestros preciados ficheros, y podremos decir aquello de ‘me encanta que los planes salgan bien’

Recopilación de diferentes comandos básicos para movernos por un sistemas de gestión de bases de datos mySQL, a través de un shell.

Conexión al SGBD:
root@Aramaki:~# mysql -u root -p
Enter password:
@ el parámetro -u especifica el usuario
@ el parámetro -p especifica que vamos a usar una contraseña
Ver las bases de datos:
mysql> show databases;
Seleccionar una base de datos database:
mysql> USE database;
Mostrar las relaciones para la base de datos seleccionada:
mysql> SHOW TABLES;
Crear una base de datos database:
mysql> CREATE DATABASE database;

Seguiré en otro momento….

Desde un shell, basicamente sería lo siguiente:
Para Exportar
#Visualizar las bases de datos
mysql > show database;

#Exportar una base de datos en particular
mysqldump -u usuario -p nombre_base_de_datos > archivo.sql

Para Importar
#crear la base de datos
mysql> create database nombre_base_de_datos;

#Proceso inverso al mysqldump
mysql -u root -p nombre_base_de_datos < ruta_base_de_datos.sql

Como root, podemos acceder directamente a la relación ‘user’, y hacer el cambio oportuno, pero si nuestro problema es que hemos perdido la clave de root, antes hemos de poner el servicio mysql en modo ‘abierto’.

Como root del sistema, ejecutamos:

root@Aramaki:~# mysqld --skip-grant-tables
091019 10:59:27 InnoDB: Started; log sequence number 0 43655
091019 10:59:27 [Note] mysqld: ready for connections.
Version: '5.0.51a-3ubuntu5.4' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)

(Nótese que Ctrl+C no cerrará el proceso, tendremos que abrir otra shell para continuar con nuestra faena)

Ahora sí que podemos atacar la base de datos, como admins de la misma. Recordemos que la tabla en la que se guardan los usuarios en un sistema mysql es la tabla ‘mysql’

root@Aramaki:~# mysql -u root -p      # el argumento -p sólo es necesario si vamos a especificar una contraseña diferente a NULL.
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 7
Server version: 5.0.51a-3ubuntu5.4 (Ubuntu)

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

mysql>use mysql;

Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed

mysql> update user set password=PASSWORD(”nuevaclave”) where User=’root’;

Query OK, 3 rows affected (0.00 sec)
Rows matched: 3  Changed: 3  Warnings: 0

mysql> flush privileges;  # con este comando reiniciamos el esquema de privilegios, con lo que –skip-grant-tables dejará de tener validez

mysql> quit;

Bye

Hecho ! Sólo nos faltaría reiniciar el demonio mysqld.

El mismo procedimiento podría ser usado para cambiar las claves de otros usuario, sólo que si somos root de la base de datos, no necesitaríamos poner el demonio en modo ‘todos los privilegios’.