-
Notifications
You must be signed in to change notification settings - Fork 43
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
Nebraska via a reverse proxy - relative URL? #621
Comments
I think a hostname would help to have the reverse proxy be serving the same hostname or being able to rewrite the hostname in the reverse proxy. |
Yeah that would partially sort it; having an internally resolvable hostname, with an entry in /etc/hosts on the clients to override the IP... but that does not work for ports. Everything would need to be switched to run on the same port, or I get the reverse proxy to translate it somehow |
NGINX reverse proxies are powerful but a bit hard to configure ;) In case it helps, you can also use a regular HTTP proxy: https://www.flatcar.org/docs/latest/setup/releases/update-strategies/#updating-behind-a-proxy |
Been a bit quiet on this for a while but I got things working via a reverse proxy. Proxied updates work fine; but Nebraska is showing all nodes behind the proxy with the same IP address. Makes sense (that's where the connection is initiated), but there's no way to identify which node is which - is there any way to pass the hostname, or the remote node's IP via the update protocol rather than basing it on the HTTP connection? Let me know if you need any more details. |
Each node identifies itself with the machine id from
|
Ah awesome - I'll give that a go, thanks @pothos |
I am working on getting updates to air-gapped Flatcar clients via Nebraska, using the host-flatcar-packages feature.
Current setup looks like this (IPs/ports are obfuscated) with a simple NGINX proxy running on our edge - we can't allow clients to directly connect to our Nebraska instance unfortunately:
The proxy works fine for the initial update GET from the client - the target Flatcar version is returned correctly.
When the client tries to download the package, the URL that it tries to connect to is http://1.2.3.4:6002/flatcar/flatcar-amd64-3227 - which it can't get to - this is provided in the response to the GET request as "url codebase".
Omaha request response: <?xml version="1.0" encoding="UTF-8"?> Sep 02 10:05:10 azure-test-hardened update_engine[1059]: <response protocol="3.0" server="nebraska"><daystart elapsed_seconds="0"></daystart><app appid="{e96281a6-d1af-4bde-9a0a-97b76e56dc5 7}" status="ok"><ping status="ok"></ping><updatecheck status="ok"><urls><url codebase="http://1.2.3.4:6002/flatcar/"></url></urls><manifest version="3227.2.2"><packages><package name=" flatcar-amd64-3227.2.2.gz" hash="2UPMTTvd0GCyn0/ewt9Ic7zTGmI=" size="345835476" required="true"></package></packages><actions><action event="postinstall" sha256="EUnaXqtOcgOwaAMpyJWayhoa5kV BOdri2N2mvqz7qAM=" DisablePayloadBackoff="true"></action></actions></manifest></updatecheck><event status="ok"></event></app></response>
I tried setting the -nebraska-url parameter to the Reverse Proxy URL http://10.0.0.1:6999 but this broke everything on the Nebraska front-end (I assume this URL is used for auth as well as serving updates).
Question is, is there a way to set the "url codebase" string returned by Nebraska to be either a relative URL (../../flatcar), to use the HTTP host header from the client, or to somehow hardcode it without using the -nebraska-url parameter and breaking things?
Please let me know if you have any ideas.
The text was updated successfully, but these errors were encountered: