Grain Request: Primary IP Address #67399
Replies: 28 comments
-
@Xiol, it all depends on your definition of what constitutes a 'primary' IP address. We have TONS of different network setups and different interface names, almost none of which would have the 'primary' ip address of eth0 (think bonding configurations, VLANs, Privacy Extensions, secondary IP's which are the real production IP's etc.). Look at the network module (https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.network.html#module-salt.modules.network); there's a ton of usefull stuff in there that could deliver your idea of the 'primary' IP address. Another idea is to go for the grains fqdn_ip4 and fqdn_ip6; it resolves to the IPs designated to the servers FQDN, which is usually the one you're looking for. |
Beta Was this translation helpful? Give feedback.
-
Yeah, I had considered that the meaning of primary IP would be specific to an organisation or use case. For us it's simply the first IP on the first interface which in almost all cases is also the IP we'd use for any management, essentially it'll be the IP on the interface with the default route. Chef does have a similiar thing to what I'm asking for, as their
Puppet also has an ipaddress fact, along with Ansible, which has this information available in I had considered the network module, but I didn't see anything in there that would easily return this information. |
Beta Was this translation helpful? Give feedback.
-
So you'd end up with something like res = {}
for family in ('inet', 'inet6')
gw = __salt__['network.default_route'](family)[0]['gateway']
out = __salt__['network.get_route'](gw)['source']
res[family + '_default_ip'] = out
return res Of course grains don't have access to the modules, so you'd have to initialize Another idea is to look at salt.utils; there's a ton of useful network stuff in there as well for these kinds of purposes; for the most part network module wraps around these utils |
Beta Was this translation helpful? Give feedback.
-
I like the idea of the default route.... However lets assume salt master is in the management network, therefore the IP address used by the minion to talk to the master could also be consider 'Management IP' you could have a gain with the minion_address_ipv4 minion_address_ipv6. |
Beta Was this translation helpful? Give feedback.
-
@damon-atkins This would work for us, however we exclusively use the SSH transport, so that would also have to be taken into consideration ;) |
Beta Was this translation helpful? Give feedback.
-
@damon-atkins the 'default route' idea is probably not such a bad one, but keep in mind that for example with Privacy Extensions, the outgoing IP (e.g. the 'default route') would by definition not be what the OP considers the 'Primary IP'. in summary, I think one of SaltStack's main strengths is that it doesn't try to derive these kinds of things for you, but rather grants you all the tools do so very easily for yourself depending on your specific conditions. |
Beta Was this translation helpful? Give feedback.
-
SSHD exports variable SSH_CONNECTION='Src SrcPort Dest DestPort' |
Beta Was this translation helpful? Give feedback.
-
Nuance belies much of this topic and concept more significantly and formatively than others. I am persuaded by the desire to find and assist a convention within salt as the other tools @Xiol has mentioned, but @The-Loeki describes very good reasons this often is not or cannot be conventional. |
Beta Was this translation helpful? Give feedback.
-
This really feels like a "batteries not included" answer for the common case. Yes, it won't be the right IP for everyone, in all cases. E.G. If I wanted to have nginx, memcached, or any other service bind on IP address other than Shouldn't we offer an experience that makes it easy to get started? Naturally, if this grain wasn't correct for advanced setups like routers, or complex docker hosts, the user could implement their own grain or custom logic. It seems like this feature doesn't make the hard things any harder, only keeps the easy things easy. |
Beta Was this translation helpful? Give feedback.
-
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue. |
Beta Was this translation helpful? Give feedback.
-
This feature available in every mature automation system, it should be in Salt. I fully agree with @ChrisLundquist here, even if it's not 100% accurate it's a good starting point for many deployments. |
Beta Was this translation helpful? Give feedback.
-
Thanks for following up here everyone. I will re-open! @Ch3LL Looping you in here - can you follow up on this issue when you get a moment? Just so someone currently at Salt can re-triage this as needed. |
Beta Was this translation helpful? Give feedback.
-
Thank you for updating this issue. It is no longer marked as stale. |
Beta Was this translation helpful? Give feedback.
-
Thank you for updating this issue. It is no longer marked as stale. |
Beta Was this translation helpful? Give feedback.
-
You need to thumbs up the original opening comment so it is sorted higher. |
Beta Was this translation helpful? Give feedback.
-
@rallytime i think we should be open to adding this and keep it as a feature request. does anyone want to give it a go? |
Beta Was this translation helpful? Give feedback.
-
I like this idea. I appreciate how difficult it would be to support all user cases since networks can be very different. I'm interested to get the IP address that the minion actually use to access the salt server. |
Beta Was this translation helpful? Give feedback.
-
Our current workaround:
Use it like:
|
Beta Was this translation helpful? Give feedback.
-
EDIT: I found a solution specific to my problem, but maybe it will help someone else, too. Tested on Debian Linux with only one IPv4 address configured:
Original comment:
|
Beta Was this translation helpful? Give feedback.
-
This work around does not work for me.
Coming from Chef and Puppet background, getting the ip is so simple. Really wish Salt could be more intelligent about this. Ubuntu 18.04
Ubuntu 14.04
|
Beta Was this translation helpful? Give feedback.
-
I end up writing custom grain with same logic as Ansible one. Works for us in AWS, but won't work if you have complex networking.
It's possible to get rid of external dependency but I wanted this code to be small and simple and without it, it will be black magic. |
Beta Was this translation helpful? Give feedback.
-
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue. |
Beta Was this translation helpful? Give feedback.
-
Unstale. |
Beta Was this translation helpful? Give feedback.
-
Thank you for updating this issue. It is no longer marked as stale. |
Beta Was this translation helpful? Give feedback.
-
The IP address that the salt-minion is using to connect to the salt-master. I would consider that as the "primary IP". |
Beta Was this translation helpful? Give feedback.
-
Based on the code used by Puppet, I've come up with the following custom grain (Linux only):
Adding support for other OS's is left for the interested reader. However, I'd be also interested to have it available on Windows. |
Beta Was this translation helpful? Give feedback.
-
Maybe provide the minion_ip using to talk to the salt master, and some doco on how to get a primary ip as an example. |
Beta Was this translation helpful? Give feedback.
-
Little workaround :
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
We seem to have a great need to find out the primary IP address of our servers from grains. This is all well and good when you know your primary network device is going to be called
eth0
, however with the new naming scheme in RHEL/CentOS 7 and some other systemd-based distributions,eth0
is no longer guaranteed to exist. I've not been able to find out a reliable way of getting this information from grains.I was initially looking at the
ipv4
grain for this, but looking at the source for that grain it seems it simply runs a sort on the IP addresses, so there is no guarantee that the IP you pick is going to be the primary one (e.g. index 1 if loopback is index 0).I've ended up writing a custom grain for this, but it's really something that would be useful in core as
grains['ip_interfaces']['eth0'][0]
isn't reliably going to work on newer distros.The custom grain I'm using is here: https://gist.github.com/Xiol/f8a27b24af936293c862. It probably needs a lot of love and less shelling out, and is very Linux specific.
Thanks
Beta Was this translation helpful? Give feedback.
All reactions