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

[BUG] ALLOWED_HOSTS hardcodes 'mailman-web' breaking container use with host networking #549

Closed
cboylan opened this issue Aug 16, 2022 · 6 comments
Labels

Comments

@cboylan
Copy link
Contributor

cboylan commented Aug 16, 2022

Tag/version of Container Images
0.4.* but I believe 0.3.* is also affected

Currently ALLOWED_HOSTS hardcodes mailman-web which means you cannot use host networking or name your containers with different names. In particular it is the gethostbyname() call that fails because mailman-web does not resolve when using host networking or when you name the container differently.

In our proof of concept deployment I was able to modify names and urls using existing environment variables for everything else that needs to know where the web container is located. This usage was the only one that required me to replace the settings.py file. In particular we cannot use settings_local.py here because the settings.py definition of ALLOWED_HOSTS is always evaluated.

I'm not sure what the best way to address this would be to maintain backward compatibility. I think the best option may be to see if mailman-web resolves and if so add both the name and IP address to ALLOWED_HOSTS otherwise leave it out. That way we can catch and handle the gethostbyname() error if the name isn't valid.

I'm happy to submit a PR to address this, but was hoping for a bit of direction on the best approach before I did that.

@cboylan cboylan added the bug label Aug 16, 2022
@gsontag
Copy link

gsontag commented Feb 18, 2023

Just ran into this issue. Makes the image unuseable

@mm534
Copy link
Contributor

mm534 commented Jan 16, 2024

Also running into this when deploying to AWS Fargate. I've worked around it for now, but would be good if this line doesn't throw. It would simplify my deployment a lot. Would it be possible to make it optional? If it resolves add it in, otherwise handle the exception and not add it in?

@petergorla
Copy link

Also running into this when deploying to AWS Fargate. I've worked around it for now, but would be good if this line doesn't throw. It would simplify my deployment a lot. Would it be possible to make it optional? If it resolves add it in, otherwise handle the exception and not add it in?

Hey friend, would you have any documentation or crib notes that you could share regarding your Fargate deployment, please? This is exactly what I want to do, but not sure where to get started. Thanks!

@mm534
Copy link
Contributor

mm534 commented Jan 18, 2024

Perhaps something like - this?
That would give a chance to override it and keep existing behavior intact? i.e. gethostbyname(os.environ.get('SOME_ENV_VAR', 'mailman-web'))

@maxking
Copy link
Owner

maxking commented Jan 22, 2024

That would give a chance to override it and keep existing behavior intact? i.e. gethostbyname(os.environ.get('SOME_ENV_VAR', 'mailman-web'))

I am fine with adding another env var, MAILMAN_WEB_CONTAINER_NAME to replace mailman-web.

You can also just update ALLOWED_HOSTS completely in your settings.py.

Please feel free to send a PR.

@maxking
Copy link
Owner

maxking commented Jan 22, 2024

Actually, #681 fixes this, without adding additional env var. DJANGO_ALLOWED_HOSTS env var already allows supplementing ALLOWED_HOSTS so no point adding yet another var doing closely the same thing.

Closing this as fixed by #681.

@maxking maxking closed this as completed Jan 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants