How can I change the database user password so that the Spring Boot application can still use the database? The environment is Docker and Jenkins.
Changing the password from 'password1' to 'password2' does not work. The Sprint Boot application fails to connect to the (MySql) database. The error is: cannot connect due to invalid user credentials.
My environment consists of:
1 - My docker-compose.yml I have:
services:
xyzdb:
image: mysql:8.0.12
environment:
- MYSQL_ROOT_PASSWORD=admin
- MYSQL_DATABASE=geosoldatabase
- MYSQL_USER=johan
- MYSQL_PASSWORD=${LOCAL_MYSQL_PASSWORD}
volumes:
- /var/mysql-data:/var/lib/mysql
ports:
- "3306:3306"
Etc.
2 - The Spring Boot apllication.properties file contains:
spring.datasource.url = jdbc:mysql://xyxdb:3306/geosoldatabase
spring.datasource.username = johan
spring.datasource.password = bladiebladiebla <== very first password
3 - To change the password I did the following actions:
Changed the user password by entering the database docker container and change the name with:
ALTER USER 'johan'#'%' IDENTIFIED BY 'xyzabc123';
ALTER USER 'johan' IDENTIFIED WITH mysql_native_password BY 'xyzabc123';
Commit;
flush privileges;
Updated 2 environment variables in my Jenkins System environment
LOCAL_MYSQL_PASSWORD=xyzabc123
SPRING.DATASOURCE.PASSWORD=xyzabc123
This does not work. Starting the Spring Boot application (after rebooting Jenkins) fails on not being able to connect to the database with the user name. There is a wrong password.
When I change all 3 updates (in the above 2 points) back to the initial password, then everything works fine.
What did I forget?
For months, no solution was suggested. That's a signal.
Since a few months I work with a Dockerized version of MySQL. That works fine. No issues yet.
The 'good' workaround is by using MySQL via Docker.
Related
I'm working with a containerized Laravel app that is supposed to be connecting to a remote rds database, here is a sample .env
DB_HOST=xxxxxx.rds.amazonaws.com
DB_DATABASE=sample
DB_USERNAME=sample
DB_PASSWORD=sample
DB_PORT=3306
DATABASE_DRIVER=mysql
The container works as it should but the problem is, it cannot connect to the remote rds database, when I try running composer ie:
$ docker exec -ti laravel-php bash
$ composer install
I get this error:
[PDOException]
SQLSTATE[HY000] [1045] Access denied for user 'sample'#'192.168.66.1' (using password: YES)
Script php artisan clear-compiled handling the post-install-cmd event returned with error code 1
192.168.66.1 as my docker container's ip, I suspect that the db policy is open via #localhost access since my dev ops confirmed that it's open for public connections.
I'm using docker-compose version 2 btw, here's a sample docker-compose:
version: '2'
services:
sample-server:
build:
context: ./
dockerfile: sample.server.docker
volumes:
- ../backend:/var/www
ports:
- "8081:80"
environment:
- VIRTUAL_HOST=sample.local
links:
- sample-php
depends_on:
- sample-php
sample-php:
build:
context: ./
dockerfile: sample.php.docker
volumes:
- .:/var/www
links:
- sample-database
environment:
- "DB_PORT=3306"
- "DB_HOST=sample-database"
sample-database:
image: mysql:5.7
environment:
- "MYSQL_ROOT_PASSWORD=samplepassword"
- "MYSQL_DATABASE=sample"
ports:
- "33081:3306"
sample-nginx-proxy:
image: jwilder/nginx-proxy
ports:
- "80:80"
volumes:
- /var/run/docker.sock:/tmp/docker.sock:ro
networks:
default:
external:
name: sample-nginx-proxy
How can I fix this?
Check the following:
Database is publicly accessible:
Connecting outside the VPC that the database resides, more specifically accessed over the internet, requires that the database is configured for Public Accessibility. Which you said is already done. As you have an internal IP, and the database does not have a public IP, this is not really required.
Basic Configuration:
Check that the database name, and port is set correctly, which I am sure you have done.
Security Group Inbound Rules:
This is most likely the case, the database will have one or more security groups. Ensure that the security group is configured to allow inbound access from the client in your case: 192.168.66.1
Confirm the IP address of the client:
192.168.66.1 is a strange IP for the container, the first 4 IP Addresses of a VPC Subnet are reserved.
Confirm the network routing:
Confirm that the VPC that contains the client can connect to the database. As the client is running within a docker container ensure that the container can access the database. Easy way to do this is enable ICMP packets on an EC2 instance in the database subnet, and check you can Ping it or use the VPC route analyser.
Check the database user rights:
Can the database user connect for any address not localhost.
Security on the VPC:
Check the ACLs of the subnets for both inbound and outbound
UPDATE:
Here is a link from AWS: Troubleshooting for Amazon RDS.
I guess that's a MySql issue, how did you create the user?
If you want to allow access from everywhere just put %:
GRANT ALL PRIVILEGES ON *.* TO 'sample'#'%' IDENTIFIED BY 'samplepassword' with grant option;
FLUSH PRIVILEGES;
I'm using Laravel Sail as my development environment. According to the docs,
when the MySQL container is starting, it will ensure a database exists whose name matches the value of your DB_DATABASE environment variable.
This works perfectly for my development environment, but not so much when it comes to testing since my .env.testing defines a separate database, and it seems this database does not get created - when I sail mysql into the container and run show databases; it is not listed. As a result, running sail test fails every test where the database is concerned.
SQLSTATE[HY000] [1045] Access denied for user ...
My .env file contains this:
DB_CONNECTION=mysql
DB_HOST=mysql
DB_PORT=3306
DB_DATABASE=dev
My .env.testing file contains this:
DB_CONNECTION=mysql
DB_HOST=mysql
DB_PORT=3306
DB_DATABASE=test
DB_USERNAME and DB_PASSWORD are the same in both files.
How can I create this database so that it's available when running sail test?
EDIT:
As I dug through the repository code I found that the database is being created when the mysql container image is built, but it doesn't look like there's an option for creating multiple databases.
MYSQL_DATABASE
This variable is optional and allows you to specify the name of a database to be created on image startup. If a user/password was supplied (see below) then that user will be granted superuser access (corresponding to GRANT ALL) to this database.
Add the following to docker-compose.yml under the services: key and set your host in .env.testing to mysql_test:
mysql_test:
image: "mysql:8.0"
environment:
MYSQL_ROOT_PASSWORD: "${DB_PASSWORD}"
MYSQL_DATABASE: "${DB_DATABASE}"
MYSQL_USER: "${DB_USERNAME}"
MYSQL_PASSWORD: "${DB_PASSWORD}"
MYSQL_ALLOW_EMPTY_PASSWORD: "yes"
networks:
- sail
You should be able to create the test database alongside the original dev database on the existing mysql container:
sail mysql
mysql> CREATE DATABASE test;
I have not tested this using mysql but the same process works on postgres:
sail psql
dev=# CREATE DATABASE test;
The problem is my localhost Laravel project just won't connect to MySQL, I get the following error:
Access denied for user 'root'#'localhost' (using password: YES)
OS: macos high sierra
Browser: Chrome;
MySql version: 8.0.12
Laravel version: 5.6
Homestead Version: 7.0
Things I have tried to fix it:
Checked that there is an instance of MySql running - It's running.
Check the credentials in the .env file and config/database.php - The credentials are correct (Mysql root user password has been change from the one generated on installation)
I checked if I could connect via terminal to double check that the credentials are correct - I can and they are correct
Tried creating a new MySql user with all root privileges. - same error.
I can run php artisan migrate in the terminal and the tables are created. which I thought was strange as the site is denied.
I completely removed MySql 3 times. (following this guide: https://gist.github.com/vitorbritto/0555879fe4414d18569d) - same error
So then I started from the beginning destroyed the vagrant box and Laravel project and started from the beginning - Same error.
Fought the urge to punch my computer.
.env (Updated)
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=homestead
DB_USERNAME=homestead
DB_PASSWORD=secret
yaml:
---
ip: "192.168.10.10"
memory: 2048
cpus: 1
provider: virtualbox
authorize: ~/.ssh/id_rsa.pub
keys:
- ~/.ssh/id_rsa
folders:
- map: ~/Sites
to: /home/vagrant/Sites
sites:
- map: site.test
to: /home/vagrant/Sites/sitetest/public
databases:
- homestead
/etc/hosts
##
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
127.0.0.1 site.test
The default password for homestead is not something.
According to laravel docs it is secret.
A homestead database is configured for both MySQL and PostgreSQL out
of the box. For even more convenience, Laravel's .env file configures
the framework to use this database out of the box.
To connect to your MySQL or PostgreSQL database from your host
machine's database client, you should connect to 127.0.0.1 and port
33060 (MySQL) or 54320 (PostgreSQL). The username and password for
both databases is homestead / secret.
Docs at: https://laravel.com/docs/5.6/homestead
Update:
You can also grant your user the permissions to play with the database with:
GRANT ALL PRIVILEGES ON database_name.* TO 'username'#'localhost';
In the hosts file, when running Homestead, you'll have to change 127.0.0.1 site.test to 192.168.10.10 site.test
Of course that will only work after vagrant up
You can solve your problem by caching your config:
php artisan config:cache
Cd into your Homestead directory
run vagrant ssh
run php artisan migrate
try this
first inside in mysql run sudo mysql -u root -p
next execute this command :
use mysql;
update user set plugin='' where User="root";
flush priviliges;
exit
I'm using 2 docker images one with my nodeJS backend server the other with my MySQL database. On the docker-compose file I'm defining the passwords, ports and hostnames correctly:
sql:
image: mysql:5.7.22
hostname: sql
ports:
- 3306:3306
secrets:
- db_root_pass
- db_user_pass
environment:
MYSQL_USER: user
MYSQL_PASSWORD_FILE: /run/secrets/db_user_pass
MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root_pass
provider:
image: monokilho/app:dev
hostname: provider
ports:
- 3000:3001
- 9221:9229
secrets:
- db_user_pass
command: node --inspect=0.0.0.0:9229 appModule.js
And on my DB_config.js file for NodeJS I have the connection setup like so:
db_config.host = 'sql';
db_config.port = '3306';
db_config.user = 'user';
db_config.password = fs.readFileSync('/run/secrets/db_user_pass', 'utf8');
db_config.database = 'app';
db_config.multipleStatements = true;
Problem is that although, using this exact configurations, docker connects Node to MySQL just fine on my local windows machine, when I upload the images to my remote linux server I continue to get:
Access denied for user 'user'#'8b2e56e566b2.network_default'
I've already remade the secrets, tried manually adding the passwords to the config on NodeJS and nothing... what makes it even weirder is that if I go on the MySQL container to connect directly or if I make another MySQL container and remotely connect it works, so I know the password input on MySQL config is correct and it is accepting remote connections.
Any suggestion what might be the difference between windows and linux for this behavior to happen? Thanks in advance.
PS: If needed windows is windows 10 and linux distro is ububtu 16.04.
EDIT: The access denied error appears on the mysql logs so the nodejs docker can reach the mysql docker and the network should be fine.
Apparently the mysql config was ignoring a sneaky \n on the password file allowing it to work normally with a command line connection, while on the nodejs it was bugging the connection.
I am trying to develop a micro service that gets information from a remote database but when I run the container it fails to make a connection to that database.
The container is running locally (I'm still developing it) and the database is hosted in AWS RDS Aurora MySQL.
The database is in use on multiple production websites using the same user I'm trying to use in the container. The user has full permission to the database and my local PHPMyAdmin connects to the database using that same user and I've had no trouble managing the db with it.
The problem is that the database connection in the container fails with an Access denied error.
The database user is setup as dbuser#% yet the error says:
Access denied for user 'dbuser'#'[my public ip]' (using password:
YES).
I attempted to add another account for dbuser#[my public ip] and gave it the same permissions as the wildcard host account and that makes no difference.
As another test I added a curl call inside the container to load an external page to make sure it can make external connections and that succeeds. It's just the db connection failure that makes no sense.
My dockerfile looks like this:
FROM php:7.2-apache
RUN apt-get update
RUN docker-php-ext-install mysqli pdo pdo_mysql
RUN a2enmod rewrite
I'm hoping someone has come across this and/or knows what I'm missing here.
Thanks in advance!
Some more info:
I'm using Docker for Windows and docker-compose to run my container. My docker-compose.yml file looks like:
version: "3"
services:
web:
image: repository/container:latest
volumes:
- ./src:/var/www/html
deploy:
replicas: 5
resources:
limits:
cpus: "0.1"
memory: 50M
restart_policy:
condition: on-failure
ports:
- "80:80"
networks:
- inv
networks:
inv:
Starting the container with docker run --network host ... will make the container share the network stack of the host. That should solve the problem.
I ended up fixing this by copying the original connection code from my API and replacing the connection code in my container with it.
I commented out the broken code and compared the two but see no difference. No quote marks in the host string, no typos, nothing that makes sense.
The only difference is the way I'm setting the variables that build the host string. The values of those variables are the same so it really doesn't make sense.
Regardless, doing this fixed it.