Host Connection job should discover primary DNS and IP based on the node's hostname

Idea ID 2777833

Host Connection job should discover primary DNS and IP based on the node's hostname

hi,

the current mechanism of the Host Connection job to discover the node's primaryDnsName attribute is based on the "smallest IP".

assuming a server has following 2 ip addresses / dns names:

  • 1.1.1.1 / servername-backup.domain.com
  • 1.1.1.2 / servername.domain.com

as a result the node's primaryDnsName attribute would be set as "servername-backup.domain.com".

so far, at every customer I have been to this is not what they would see as the correct primary dns name.

my suggestion instead is to run the hostname command and resolve the dns name from it.

at the same time this could be used to set the node's primaryIpAddress (this attribute is currently not discovered by Host Connection by Shell job. here is another idea for this: https://community.microfocus.com/t5/CMS-Idea-Exchange/Discover-the-primary-IP-address-by-the-host-connection-job/idi-p/1663340).

I would be also glad to hear other opinion's about the "smallest IP" mechanism and if there are good use cases for it.

I could also imagine a new job parameter where discovery admins can decide whether to use the smallest IP mechanism or the hostname command to discover primaryDnsName / IP.

regards

daniel

17 Comments
Captain
Captain

We had a similar issue. We solved it by using the primary IP address of the interface that has a default gateway set. We needed a patch from MF to implement that, so the logic already exists.

Micro Focus Expert
Micro Focus Expert

"primary IP address of the interface that has a default gateway set" --> that sounds even more complex.

the question is, what is considered the primary DNS / IP of a server? all customers I have been to, they wanted to have DNS and IP corresponding to the result of the hostname command.

this is very easy to achieve and I know how to do it. instead of having to customize this for all customers I'd rather like to get it into the product by default

Captain
Captain

We consider the primary IP address of a server to be the first IP address of the interface where the default IP route goes to. Although this method is more complex, it has a better reliability for us as the DNS A and PTR records do not always match the server name due to legacy requirements.

If you take this case for example, there are two interfaces and one of them has two IP addresses. While doing the discovery, the Scanner finds which interface has the default gateway and takes the first IP address listed in ifconfig or ipconfig for that interface as the primary address. Of course, the primary address has to be the first one being configured on the interface, which is always the case for us but which does not seem to be the case for you. In uCMDB every interface has their gateway reported in the "InterfaceGateways" attribute. Whichever has something else than 0.0.0.0 listed there is elected as being the primary interface. So in this example, the Windows node has the address X.X.66.10 as its PrimaryIPAddress because it is the first one configured on the interface Production, which has its default gateway set to X.X.66.1

ViauJoc_0-1588282134235.png

If you want to rely on the DNS to do that, it is also possible and already available. You just need to configure a few things.

1. Enable the "DNS Resolver" discovery job (under Network Infrastructure > Basic). This will, for each IPAddress you have in your inventory that is linked to a Node, populate the AuthoritativeDnsName attribute in IPAddress and PrimaryDnsName in Nodes, that's it. Of course, if you think that trying to resolve all discovered IP addresses may be too heavy for your DNS servers, you may customize the job trigger to target only what you need.

2. Create an enrichment rule that will find, using a Join Relationship, a Node and an IPAddress for which IPAddress.AuthoritativeDnsName=Node.PrimaryDnsName. The cardinality of that Relationship on the Node side should be 1..1 just in case your DNS contains more than one PTR records pointing to the same server name. Then the enrichment will be to copy IPAddress.Name to Node.PrimaryIpAddress.

We did something similar to populate the PrimaryIpAddress of a specific Node type on which it was impossible to install the UDA. It works very well.

Hope this was useful.

Although it is possible to achieve what you want using this contraption, I still think that this is a very basic inventory requirement and it should be easier to enable and configure how to recognize the PrimaryIpAddress of a Node... but the DNS should not be the only option.

Micro Focus Expert
Micro Focus Expert

thanks for sharing your view on what is the primary ip / dns and how to get this, very useful. but even the approach you are describing is not part of UCMDB ootb, right?

also do I understand correctly, that in your case the hostname command can return e.g. "servername-backup" or "servername-B" instead of "servername" ? or do you say that even if it returns "servername", you do not necessarily want to have "servername.domain.com" as primaryDnsName but e.g. "servername-B.domain.com" ?

regarding your comment: "...which is always the case for us but which does not seem to be the case for you..." --> well, I never tested this as so far the hostname command was always reliable and the most easiest way to get the correct primary FQDN.

DNS Resolver job is not an option for us as it "suffers" the same "smallest IP" logic as described in the initial text. Furthermore this job does not do a shell connection to the servers, instead it resolves IPs from the probe which does not always return correct results. the most reliable way for me to resolve an IP is from the server itself and hence I see the Host Connection job as the primary source for IP AuthoritativeDnsName / Node primaryDnsName and Node primary IP. (though it still makes sense to use the DNS resolver job for those nodes where no shell access is available). In fact until recently the DNS Resolver job was the only ootb way to get an IP's AuthoritativeDnsName  and a node's primaryDnsName. With some of the latest CP's this feature was simply "copied" to the Host Connection job.

I would avoid enrichment rules as much as possible. If an attribute can be directly discovered by any job, the job should do so instead of creating an enrichment for this.

I agree with you, as we just found out there seem to be multiple ways of getting a node's primaryDnsName and hence my suggestion is to introduce a parameter on the Host Connection job so that every customer can decide which method fits best to him.

Captain
Captain

The basic "ingredients" for the recipe I am describing are available ootb, but you have to assemble it yourself.

In our case, the `hostname` command being run on the server will return "servername". If we do a DNS resolution, for "servername.mydomain.com", it will resolve to an IP address of that server that we shall consider the primary one. But, we also have another DNS entry for "servername.legacydomain.com" pointing to that same IP address. To top that, the reverse DNS lookup (PTR record) for that primary IP address will return "servername.legacydomain.com" instead of "servername.mydomain.com". So, in that case, the IPAddress.AuthoritativeDnsName will not match Node.PrimaryDnsName.

In some extreme cases, we had to replace the server with a new one, having a new name, while maintaining the same IP address and DNS resolution because we have a bunch of firewall rules, loadbalancing configurations and application settings pertaining to that IP address and legacy name. In this case, we would have 3 DNS entries:

  • servername.mydomain.com A 1.2.3.4
  • previous-server-name.legacydomain.com A 1.2.3.4
  • 1.2.3.4 PTR previous-server-name.legacydomain.com

I don't understand your point regarding the DNS resolver job suffering from the "smallest IP" logic. Do you have multiple PTR records pointing the the same server name?

I am not a fan of using enrichment rules to compensate for missing discovery capability either. This idea should definitely be taken into consideration. While waiting for MF to implement it, using enrichment rules and other features may be a quick way to obtain the result your are looking for and bring some immediate added-value to your organisation. Just make sure that this temporary solution keeps a manageable scope and that you can easily remove it when MF releases a CP with the new feature.

Cadet 1st Class Cadet 1st Class
Cadet 1st Class

The word "primary" is misleading.  These constructs are abstract; people think they exist, and so the product has attributes to populate… but there is no concrete data source for:

  • Primary IP Address of a Node
  • Primary DNS name for a particular IP

 

The connotation changes as you transition target audiences. Take a single server with two IPs; one dedicated for operations work while another is dedicated to a software component (e.g. database schema).  Which group would you ask to define the “primary” concepts?  There are plenty of cases to consider, like a hardware management card (e.g. iLO) in a blade server that could be mapped as “primary” for the hardware asset.  Or consider a shared server that hosts many things (e.g. shared DB server or shared web server), with 100 different IPs or DNS aliases in use.  Etc. 

 

Setting “primary” aside, you still have the act of gathering and tracking the data.  And that's a real need if you want to avoid woes in reconciliation.  The UCMDB allows you to create/extend a job to grab the necessary data.  Once you have a handle on the data, you can certainly use enrichments to pick and choose which to promote… though I like to keep flows buttoned up in a single step (i.e. same script used for gathering can do the ETL).  This is how I’ve done it over the years.  A couple targeted scripts, wrapped up in a package, and you're good to go.

 

In order to track IPs/names, I use something like nameListA to contain all values gathered from method A, nameListB from method B… and have one or more referenceName attributes to hold the one(s) used to match downstream.  This works great, describes the datasets, and avoids the confusion of “primary”.

 

On the DNS comments: I like to pull the zones in.  That way I have all the DNS mapping of A and CNAME entries for a each IP, across all zones.  If you need DNS context, then you need all of the applicable data… not just what a particular DNS forwarder server is providing the particular probe that's asking.  And you need to bridge similar gaps with different name resolution configurations on servers in the domain scope.  

 

Daniel, this is what you were talking about with resolving IPs from the target server itself.  A name lookup from the probe server, may not use the same resolution services as the target server.  You have local host file entries, NIS, WINS, etc.  Much more complexity there, but you get the idea. Like cluster heartbeat references, public vs DMZ references, load balancer references, and other areas that apps know about but the probe won’t see if you try to solve this with a dig/nslookup.

 

But if you take the DNS zones, along with the local host datasets and put them together as I suggested above, you have all the data for the rule to represent the desired data ("primary" construct).  

Captain
Captain

You are absolutely right about the definition of "primary" being different depending on the audience. We arbitrarily decided that it would be the OS sysadmin definition of Primary IP Address and Primary DNS Name that we would use in uCMDB. Microfocus should not decide for us what is the "best" way of obtaining the "primary" stuff. They should just provide helping features to obtain the information in different ways. Then it will up to each customer to decide which one they want to use or not.

Micro Focus Expert
Micro Focus Expert
Thank you for sharing your idea! It’s open for comments and kudos, and we’re looking forward to input from the community. Once there is enough community traction, it will be further reviewed by the product team
Micro Focus Expert
Micro Focus Expert
Status changed to: Waiting for Votes
 
Micro Focus Expert
Micro Focus Expert

@ViauJoc pls see my inital text where I explain the "smallest IP" logic which is currently used by "Host Connection" and "DNS Resolver" job. this is actually what my whole idea is about. I wanted to hear from other customers if the smallest IP is the right approach for them and I'd like to introduce another option based on the server hostname command.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.