FusionAuth / fusionauth-containers

Container definitions for docker, kubernetes, helm, and whatever containers come next!
https://fusionauth.io/
219 stars 68 forks source link

Silent Configuration without root database password #7

Closed MatthewLymer closed 3 years ago

MatthewLymer commented 5 years ago

I'm looking at using FusionAuth in a Kubernetes environment, where my database is already hosted by Amazon RDS, but I'll be hosting FusionAuth-app and ElasticSearch in Amazon EKS (kubernetes).

CREATE DATABASE "fusionauth" ENCODING 'UTF-8' LC_CTYPE 'en_US.UTF-8' LC_COLLATE 'en_US.UTF-8' TEMPLATE template0;
CREATE ROLE "fusionauth" WITH LOGIN PASSWORD '<hidden>';
GRANT ALL PRIVILEGES ON DATABASE "fusionauth" TO "fusionauth"; 
ALTER DATABASE "fusionauth" OWNER TO "fusionauth";

If I provide the following environment variables:

DATABASE_URL: jdbc:postgresql://myrdsurl:5432/fusionauth
DATABASE_USER: fusionauth
DATABASE_PASSWORD: <hidden>
FUSIONAUTH_SEARCH_SERVERS: http://search:9200
FUSIONAUTH_URL: http://fusionauth:9011

And I omit:

DATABASE_ROOT_USER: foo
DATABASE_ROOT_PASSWORD: bar

Then I am always greeted with the "Silent Configuration Mode Failed" failed message.

Why is the root database password required when the username and database has already been setup in Postgres?

MatthewLymer commented 5 years ago

Found a workaround

If you specify the root username and password as the account you just created, then you're able to get to the "FusionAuth Setup Wizard" step.

robotdan commented 5 years ago

Thanks for the update, glad you've gotten past this hurdle.

FusionAuth will attempt to enter silent configuration when the DATABASE_ROOT_USER, DATABASE_URL and FUSIONAUTH_SEARCH_SERVERS are provided in the environment.

In theory that means that omitting DATABASE_ROOT_USER should cause us to skip silent configuration, and go through maintenance mode which should be successful unless the schema does not yet exist, are some other db configuration is incorrect.

Since you are seeing the Silent Configuration Mode Failed message, unless we have a bug, that means that one of those environment variables is still being set.

When you omit the DATABASE_ROOT_USER, does that mean you removed it from the container env in kubernetes/deployments/fusionauth-deployment.yaml or just removed the value?

MatthewLymer commented 5 years ago

I am still passing in FUSIONAUTH_SEARCH_SERVERS and DATABASE_URL, but it looks like I am passing in DATABASE_ROOT_USER as an empty string, which is I guess where the problem is.

When I omit the environment variable entirely, it brings me to the Maintenance Mode screen asking for my database credentials to provision a new user and database.

However if I pass in DATABASE_ROOT_USER and DATABASE_ROOT_PASSWORD it will instead create the tables inside the database for me, which is what I want.

Upon reading the instructions again, it looks like I was supposed to create the tables myself using psql, which I glossed over entirely, so that's my bad.

In any case, the behavior it's doing now (configuring an existing database) is what I want to happen, but I was only able to do that by duplicating the fusionauth's database username/password in the other environment variables.

If this is unsupported then I guess you should close this, but I think this is a viable use-case for configuration.

robotdan commented 5 years ago

Thanks for the update.

but it looks like I am passing in DATABASE_ROOT_USER as an empty string, which is I guess where the problem is.

Ok, this is what I suspected. In theory we could be a bit more defensive and check if the environment variable is defined and non-empty, I'll have to think about that further.

Upon reading the instructions again, it looks like I was supposed to create the tables myself using psql, which I glossed over entirely, so that's my bad.

We do offer an "advanced" mode with instructions on creating the schema manually, but this is not how most will install FusionAuth. The intent of the silent mode configuration is to allow the maintenance mode steps (db configuration, schema creation and elastic search index creation) to happen non-interactively for deployments via docker, k8s, etc.

So, if this isn't working for you - then it is a bug, or we are missing some config example or documentation etc.

If I understand the issue, this isn't working as you expect, and you only got it to work by specifying the normal user and password in the DATABASE_ROOT_USER and DATABASE_ROOT_PASSWORD environment variables?

MatthewLymer commented 5 years ago

This is correct, if I provide DATABASE_ROOT_USER but it's blank then it'll go into "Silent Configuration Mode Failed", but if the env-var is not defined at all then I'll get the "Maintenance Mode" screen instead.

Setting DATABASE_ROOT_USER to the normal user made it work as I expected it to.

drpebcak commented 3 years ago

This should be resolved by #95