Trabajar con el Disco duro en Unix

Empezar con Linux puede ser duro, pero si una cosa esta complicada es el trabajo con discos. No me refiero por supuesto a la comoda interfaz grafica, donde hacemos clic y vemos propiedades, sino a trabajar al ciento por ciento con la consola, ya sea por gusto a las complicaciones o porque mantenemos algun(os) servidor(es) sin mejores posibilidades.

Bueno, para mi personalmente el tiempo del ahorro de recursos ya ha pasado. Mi primera computadora fue un 8088 con menos de un Mhz de Taktung mientras que las actuales tienen varios Procesadores con más de 3 GHz. Los servidores siempre estaban mejorcitos. Los programas tambien han mejorado su rendimiento, no todos crecen nada mas. Pero bueno, eso es al final cuestion de gustos y harina de otro costal.

Ver las Particiones de manera bastante explicativa:

df -h

hacer imagenes de disco

dd if=/dev/disco of=/home/desktop/tu_imagen.img --> puede ser que necesitas sudo!

este articulo me gusto:
https://wiki.archlinux.de/title/Image-Erstellung_mit_dd

Controlando el disco duro en linux, detener, dormir, reactivar

Estoy trabajando en desacerme de mis viejos moustrosos servidores y sustituirlos por mis viejas moustrosas portatiles. He empezado con crear un servidor KVM en una Lenovo Sl500. Por ahora todo va bien, pero a pesar de que el monitor esta en mínimo, y el portátil tiene control avanzado de Energía, el disco duro esta siempre trabajando y caliente.

Parece ser que por defecto el standby para discos en Linux viene desactivado, que se puede controlar con hdparm y que este control es solo por sesion y hay que hacerlo manual cada vez que se reinicia. En el siguiente blog encontre una solución que tengo que probar y con la que no estoy del todo satisfecho

http://www.tacticalcode.de/2013/01/festplatte-automatisch-in-standby-mit-hdparm-und-udev.html

Pero sigo buscando...

update 10:43
http://blog.is-a-geek.org/festplatten-in-den-standby-modus-versetzen-unter-ubuntu-desktopserver-mit-hd-idle

update 20.01.17
hoy he tenido un poco de tiempo para realizar pruebas. Primero, intenté configurar los discos a través de la herramienta webmin, que es mi favorita para facilitar el mantenimiento linux.
En webmin encontramos un apartado para esto y es;
hardware --> partition and local disks --> idle parameters --> Standby timeout
esto funciona en el momento, pero la configuracion no se guarda, todavia no he mirado porque,

Otra alternativa, hdparm es bastante aceptable, pero hay que configurarla a traves de scripts para que se funcion de manera automatica. Basicamente:

hdparm -C /dev/sda       --> te dice el estado actual del sda

hdparm -y /dev/sda       --> lo pone en descanso

hdparm -S 10 /dev/sda      --> lo pone en descanso en un tiempo estimado

conectarse con un server por ssh usando una llave ida/rsa

ACTUALIZACION 21:11:2018
Si hemos perdido la clave publica, pero conservamos la privada. Podemos "recrearla" con el comando:

ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub 

ACTUALIZACION 14:11:2018

Cuando creamos el par de claves, ssh-keygen nos va a mostrar una salida artistica de la llave que se llama randomart. 

Este dibujito, no lo volveremos a ver nunca mas si no lo deseamos específicamente. Una opción sería, habilitar la visualizacion de la llave cuando nos conectamos por ssh con un servidor con la opcion adicional, de forma que el comando total nos queda asi:

ssh root@ssh-server -o VisualHostKey=yes

Con lo que nos mostrará el randomart de la clave que estamos usando para conectarnos.

Pero... y si quisiera usar el randomart para comparar claves, perdidas, danadas o simplemente confundidas?

Bueno, el servidor podría convertir las llaves públicas existentes en el archivo know_host así:

ssh-keygen -lvf  ~/.ssh/known_hosts---> ESTO ME GUSTA !!!

y podríamos comparar esta salida con el resultado en nuestro cliente con:

ssh-keygen -lv   ---> Y ESTO TAMBIEN :-)



ACTUALIZACION 16.05.2018

Tuve que configurarme un laptop nuevo para acceder a estos servidores desde la casa, pero cuando quise enviar su clave con ssh-copy-id y me pidió la contrasena de administrador que no tenia...

Tanto uso el sistema de llaves para ssh, que en un(os) servidores se me olvidó la contrasena. 

Claro, siempre podía logearme en el otro computador, por lo que desde este, importé la clave asi:

1. pasar la clave publica .pub al computador que sí permite logearse (sin contrasena, pues tiene clave ssh)
2. Ejecutar en consola, dentro del directorio donde esta la clave:  
   cat id_rsa.pub | ssh root@servidor-obj 'cat >> .ssh/authorized_keys && echo "Key copied"'
3. este comando manda la salida de cat, al archivo .ssh/authorized_keys de el servidor-obj deseado.

tambien puede interesarte:
https://victorhckinthefreeworld.com/2016/01/28/transferir-llaves-ssh-de-un-pc-a-otro-en-gnulinux/

********************************* 

valido para mac y linux:

ssh-keygen -t rsa -b 4096

-- algunos anaden -f ~/.ssh/id_rsa , si no lo haces, igual el programa preguntará el nombre y el camino del archivo. Si tampoco escribes algo especial, entonces tomará el valor por defecto arriba escrito.

-- también preguntará por una "paraphrase" que es una contraseña adicional para la clave. Personalmente pienso que es muy importante, puesto que si alguien se apropiara de la clave tendría fácil acceso a todos los ámbitos donde la clave funciona. Con una paraphrase tendría también que tener esta para cualquier conexión.

Este comando generara dos claves: id_rsa und id_rsa.pub en el directorio .ssh raiz del usuario.

La .pub es la clave pública, que se copiará en los servidores dentro del archivo "know_host" y la otra es la privada, que debe permanecer secreta en este directorio donde fué generada.

Hasta aqui con la parte cliente. Ahora debemos poner la clave pública entre las claves ssh aceptadas por el servidor. Para esto usaremos ssh-copy-id

ssh-copy-id root@server
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/user/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
user@server's password:

Number of key(s) added:        1

Now try logging into the machine, with:   "ssh 'user@server'"
and check to make sure that only the key(s) you wanted were added.

 -- OJO SOBRE EL USUARIO -- si queremos dar acceso a otro userx al servidor ssh hay que ejecutar:

ssh-copy-id userx@server     desde el computador del userx y en su cuenta. Teniendo el userx ya una cuenta en el servidor.

--- NOTA IMPORTANTE ---
Si por alguna razon ssh-copy-id no funcionara, se vale tambien copiar (por ftp/filezilla, scp, ssh-->vim, etc.) la clave .pub del cliente /root/.ssh/id_rsa.pub en el servidor en el archivo "host_allow" /root/.ssh/authorized_keys

Reseteando la contrasena de MariaDB en Linux Devuan (una variante Debian)

Update 09.01.17
He encontrado el origen del problema:
al detener el servicio mysql con service mysql stop, he iniciar en modo seguro con deb-maint. Puedo ver las tablas de los usuarios. Alli aparece lo siguiente;
+-----------+---------------------+---------------------+
| host         | user                      | password            |
+-----------+---------------------+---------------------+
| localhost | root                      | * Blablabla-foobar
| server      | root                      | * *Blablabla-foobar |
| 127.0.0.1 | root                      | * *Blablabla-foobar |
| ::1            | root                      | * *Blablabla-foobar |
| localhost  | debian-sys-maint | * *Blablabla-foobar |
| %             | user01                  |                     |
| %             | root                      | * *Blablabla-foobar |
+-----------+----------------------+---------------------+
el problema esta en el "hostname", para que funcione debes poner el "localhost" asi:
mysql -u root -h localhost -p
Pero mucho cuidado, pues esto no va a funcionar en la misma sesion, incluso tampoco con el mismo servicio, pues el modo seguro tambien se puede ejecutar "sin red" con lo que localhost tampoco funciona!



05.01.17 04:57

Si bien la contrasena de SQL no debería significar un problema grave, ya que es mas que seguro que tenemos la contrasena de root, por experiencia no resulta tan facil. Una cantidad de problemas se derivan de las versiones de SQL como de los systemas operativos que los albergan.

No estoy tratando aqui de competir contra las instrucciones de Oracle o MDB. Sino que documento aqui como resolví mis propios problemas, para tenerlo a mano en caso de volver a necesitarlo y ademas que si a alguien le sirven, me alegra.

service mysql stop
mysqld_safe --skip-grant-tables --skip-networking &

mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 4
Server version: 10.0.28-MariaDB-0+deb8u1 (Debian)
Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('new_password');
ERROR 1131 (42000): You are using MariaDB as an anonymous user and anonymous users are not

 Ujum... entonces pruebo toda la session desde el comienzo con root:

 service mysql stop
 mysqld_safe --skip-grant-tables --skip-networking &
 mysql -u root 
FLUSH PRIVILEGES;
SET PASSWORD FOR 'root'@'localhost' = PASSWORD('new_password');
ERROR 1131 (42000): You are using MariaDB as an anonymous user and anonymous users are not allowed to change passwords

???  

Parece que tengo un terrible problema...
Bueno, la verdadera razon de ese problema parece residir en la configuracion original de mysql
bastante interesante es que el comando...

mysql_secure_installation

tambien me devuelve ese error:

Enter current password for root (enter for none):
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

lentamente estoy pensando en reinstalar todo, pero antes un par de tips interesantes que también encontré:
 
1.- hay un usuario debian-sys-maint que tiene privilegios elevados y puede ejecutar y configurar bases de datos, su contrasena es un texto aleatorio guardado en el archivo

/etc/mysql/debian.cnf

con él te puedes logear y resetear contrasenas

2.- Con el usuario debian-sys-maint (quizas también con otro) puedes visualizar los usuarios configurados de mysql.

select host, user, password from mysql.user; 

en esta tabla puedes ver "encriptadas" las contrasenas, esto puede ser util a pesar de todo para estar seguro de los nombres de usuario, saber si un usuario con contrasena desconocida/olvidada tiene la misma de uno que conozcamos, o para constatar si nuestro cambio o reseteo de contrasenas esta funcionando.

3.- El comando: update mysql.user set password=password('tu-contrasena') where user='root';
sirve para resetear contrasenas.