Solucionar el acceso como 'root' al servidor de base de datos: Mysql, desde phpmyadmin.

Tenemos un equipo con Linux y queremos instalar un servidor de base de datos para poder acceder a base de datos para alguna aplicación web o de escritorio.

Una vez que lo instalamos, queremos acceder al mismo como 'root' para poder crear usuarios, bases de datos, etc. y al hacerlo desde la ventana de 'login' de 'phpmyadmin' nos dice que no tenemos acceso (aunque podemos acceder también con un usuario 'phpmyadmin' y la contraseña de administrador).

Para poder entrar como root, desde una consola como usuario root del sistema, accedemos por comandos al servidor Mysql:

?

1	mysql -hlocalhost -uroot -ppassword

Una vez que tenemos acceso mediante consola al servidor, podemos revisar todas las cuentas que ya están dadas de alta en la base de datos.

SELECT User,Host FROM mysql.user;
+------------------+-----------+
| User | Host |
+------------------+-----------+
| mysql.sys | localhost |
| root | localhost |

Lo siguiente es borrar el usuario root

> DROP USER 'root'@'localhost';
Query OK, 0 rows affected (0,00 sec)

Ahora creamos de nuevo el usuario 'root 'con la password que quereamos

> CREATE USER 'root'@'%' IDENTIFIED BY 'password';
Query OK, 0 rows affected (0,00 sec)

Una vez que creamos el usuario, debemos dar los permisos correspondientes al nuevo usuario.

> GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
Query OK, 0 rows affected (0,00 sec)

Y finalmente debemos hacer un flush para que nos coja automáticamente los cambios.

> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0,01 sec)

Después de ello intentamos iniciar sesión de nuevo, desde phpmyadmin y ya deberíamos poder acceder sin problema.

Breves notas sobre los servicios -puppet-.

 Unas breves notas sobre los servicios -puppet-:

• puppetserver.service: Es el servicio que pone en marcha el servidor puppet, que es quien presta servicio a los clientes de nuestra red.

• puppet.service: Es el servicio que pone en marcha el agente, que es el que hace que nuestro servidor sea a su vez cliente del servidor -puppet.educarex.pri-, que a su vez es quien propaga los módulos (desde la "Sección"), tanto para nuestros clientes como para el servidor.

• Para parar el cliente puppet (puppet-agent), haces un: systemctl stop puppet

• Si además de pararlo, queremos deshabilitarlo, entonces ejecutamos: systemctl disable puppet

Al parar en el servidor de nuestro centro el cliente puppet (puppet-agent), éste ya no recibirá "tareas" del servidor principal, o sea, del -puppet.educarex.pri-, algo que puede ser útil cuando se propagan tareas desde el servidor central hacia nuestros servidores, que pueden producir fallos por algún tipo concreto de error, con la posibilidad de que más adelante, cuando se soluciones los problemas/conflictos/errores se pueda volver a habilitarlo.

• Para sincronizar puppet se utiliza: sinc_puppet, que en principio se ejecutaría automáticamente. por defecto, en el inicio/arranque de cualquier equipo. Si no se estuviera ejecutando, habría que revisar la variable ENABLE en:  /etc/default/sincpuppet

• Con respecto a los certificados obsoletos, NO pasa nada porque los sigamos teniendo, el único problema es que ocupan espacio. En principio, nuestro servidor está configurado para que autofirme lo que le llegue... no es lo ideal por temas de seguridad pero al final la balanza en este caso se inclina por la labor de facilitarnos el trabajo y no estar pendiente de firmar, o no, las peticiones que vayan llegando al servidor.