Score:0

Compatible way to bind to 169.254.169.254?

in flag

I have an application which I can't change, running in a docker container on a bare metal server (no cloud environment)

It tries to connect to 169.254.169.254 (fetching IMDSv2 metadata). This ip / the service is not reachable and the application waits before the request times-out. During wait, the application does not respond.

I would like to solve this issue by providing a service on this ip. What's the correct way to do this, ideally without having special privileges for the container?

For the sake of testing, I started a simple webserver and added an internal IP route from 169.254.169.254 to 127.0.0.1 which solved the problem - however, this requires special docker privileges ( --cap-add NET_ADMIN).

Is there a better way to do this? (e.g. maybe there's a RHEL/Linux service which can bind on this special ip. Binding to 0.0.0.0 did not work)

cn flag
Bob
Is the app actually hard coded to reach out to that IP-address, or does it do so by resolving a FQDN? If it's the latter it should be trivial to the override that FQDN and point to an IP that either returns an immediate `connection refused` or a mock response.
cn flag
@Bob - it's probably via IP as that's the address used for retrieving instance metadata in e.g. AWS.
in flag
The application (oracle database btw) hard coded the IP. @shearn89 is right, they do it for detecting a possible cloud environment.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.