Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MINIO_ENABLE_HTTPS is not taking into account #36

Closed
benqua opened this issue Jun 2, 2022 · 12 comments
Closed

MINIO_ENABLE_HTTPS is not taking into account #36

benqua opened this issue Jun 2, 2022 · 12 comments
Assignees
Labels
awaiting-feedback Blocked on input from the author kind/bug Some behavior is incorrect or out of spec resolution/no-repro This issue wasn't able to be reproduced

Comments

@benqua
Copy link

benqua commented Jun 2, 2022

What happened?

When trying to create a s3 bucket with an https endpoint, the variable MINIO_ENABLE_HTTPS is not taking into account and the provider try to access the endpoint with http.

Steps to reproduce

With

❯ env | grep -i minio
MINIO_ACCESS_KEY=<my key>
MINIO_ENDPOINT=s3.pub1.infomaniak.cloud
MINIO_SECRET_KEY=<secret>
MINIO_ENABLE_HTTPS=true

and

bucket = minio.S3Bucket("mlflow-bucket",
    acl="private",
    bucket="mlflow-models")

I get:
* [FATAL] Unable to check bucket (mlflow-models): Get "http://s3.pub1.infomaniak.cloud/mlflow-models/?location=": dial tcp 185.125.25.50:80: connect: connection refused

Expected Behavior

Because MINIO_ENABLE_HTTPS is set to true, the request should be done on "https://s3.pub1.infomaniak.cloud/mlflow-models/?location=" (https instead of http)

Actual Behavior

http is used instead of https.

Versions used

CLI
Version 3.33.2
Go Version go1.17.10
Go Compiler gc

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

@benqua benqua added kind/bug Some behavior is incorrect or out of spec needs-triage Needs attention from the triage team labels Jun 2, 2022
@stack72
Copy link
Contributor

stack72 commented Jun 4, 2022

Hi @benqua

The environment variable MINIO_ENABLE_HTTPS isn't going to rewrite your endpoint to be http or https - it's simply instructing the minio provider to expect ssl requests or not - under the hood, it's actually mapping to the following:

minioAdmin, err := madmin.New(config.S3HostPort, config.S3UserAccess, config.S3UserSecret, config.S3SSL)

where the config.S3SSL variable is a true or false based on what you are setting the environment to. There is no logic to rewrite the S3HostPort based on the value of that parameter. So your endpoint must be configured correctly

What this parameter does do, is ensure that if the endpoint is https, that we don't try and make insecure connections to it

I hope that helps?

Paul

@stack72 stack72 added awaiting-feedback Blocked on input from the author and removed needs-triage Needs attention from the triage team labels Jun 4, 2022
@stack72 stack72 self-assigned this Jun 4, 2022
@benqua
Copy link
Author

benqua commented Jun 7, 2022

Hi @stack72 , thank you for your answer.

Sorry, but I still don't get how to make sure the provider use https instead of http. The variable MINIO_ENDPOINT doesn't accept an url that specify the protocole. If I set MINIO_ENDPOINT=https://s3.pub1.infomaniak.cloud instead of MINIO_ENDPOINT=s3.pub1.infomaniak.cloud, I get another error, basically saying I shouldn't include the protocole (I don't have access to the code right now to give you the exact error). The S3HostPort (taken from MINIO_ENDPOINT) doesn't include the protocole, right?

How should I instruct the provider to do a request on https://s3.pub1.infomaniak.cloud/mlflow-models/?location= instead of http://s3.pub1.infomaniak.cloud/mlflow-models/?location= ? What do I miss?

@stack72
Copy link
Contributor

stack72 commented Jun 7, 2022

Hi @benqua

I'm sorry for the incorrect information here - you are indeed correct. I am not 100% sure why this is causing you a problem. I went digging in the issues for the upstream provider and found the following

aminueza/terraform-provider-minio#58

I am going to try and run a test and see what I can find out here. Is there any chance you'd need to supply a cert for the HTTPS request to be made (in the case of a self signed certificate or something)?

Paul

@benqua
Copy link
Author

benqua commented Jun 7, 2022

Yes, I saw the above link before opening the issue; it confirms my configuration looks good.

The error message shows that the provider is trying to make a request to an http (without ssl) url, so it likely doesn't have anything to do with the certificate. (Moreover, the url is the one of a public cloud provider).

My guess is that the environment variable MINIO_ENABLE_HTTPS is somehow not correctly passed to the upstream provider or that the value it should have is not true to activate https.

@stack72
Copy link
Contributor

stack72 commented Jun 7, 2022

Hi @benqua

Please can you try 1 last thing - it may help me out here:

pulumi config set minio:minioSsl true and then see if that works for you?

I want to try and identify if there's an issue with environment variables here

Paul

@benqua
Copy link
Author

benqua commented Jun 7, 2022

Sure, I will, however, I won't be able to do it before tonight (CET time).

I will also test bucket creation directly with the terraform provider.

@stack72
Copy link
Contributor

stack72 commented Jun 7, 2022

Not a worry at all - take the time you need :) I want to work out the correct fix here

@benqua
Copy link
Author

benqua commented Jun 7, 2022

Ok, will do.

Just asking myself if there isn't a type mismatch: here the minioSsl is described as a boolean, while in the terraform github issue the word true is a quoted string, not the unquoted true boolean value of terraform HCL. Not sure it is related to the issue, but it looks suspicious.

@benqua
Copy link
Author

benqua commented Jun 7, 2022

@stack72 I can confirm that it works with pulumi config set minio:minioSsl true !

@stack72
Copy link
Contributor

stack72 commented Jun 7, 2022

Ok, this is good news :) thank you for confirming! This gives me enough that I can fix up now

@benqua
Copy link
Author

benqua commented Jun 27, 2022

Great! Did you find a way to fix it?

@mikhailshilkov mikhailshilkov removed the awaiting-feedback Blocked on input from the author label Jul 28, 2023
@mjeffryes
Copy link
Member

Unfortunately, it looks like this issue hasn't seen any updates in a while. If you're still encountering this problem, could you leave a quick comment to let us know so we can prioritize it? (Commenting will bump it back into our triage queue.)

@mjeffryes mjeffryes added the awaiting-feedback Blocked on input from the author label Sep 27, 2024
@mjeffryes mjeffryes added the resolution/no-repro This issue wasn't able to be reproduced label Oct 25, 2024
@mjeffryes mjeffryes self-assigned this Nov 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting-feedback Blocked on input from the author kind/bug Some behavior is incorrect or out of spec resolution/no-repro This issue wasn't able to be reproduced
Projects
None yet
Development

No branches or pull requests

4 participants