Better handle errors in fetching the hostname on darwin (macOS) systems

[erikng]

This pull request mimics the code from :linux.

The current assumption on darwin machines is that there is an entry located in /etc/hosts. Given that most darwin machines are client devices, this more than likely is incorrect.

Issues that this can cause:

• ohai returns a value of null in the JSON. In my testing only the fqdn attribute will return this as a value.
• When uploading null data to a postgresql database, you will experience table issues.

This change drops the fqdn value if a hostname is not properly returned, but still returns a valid entry if there is an entry in /etc/hosts.

[mcquin]

Hi @erikng . Thanks for contributing to Ohai!

Sometimes I get worried about behavior changing changes. However, since ruby returns nil if a key is not in a hash, checks on node['fqdn'] won't behave differently than if node['fqdn'] were nil. I suppose users with node.attribute?('fqdn') && node['fqdn'].nil? might have some problems, but it's unlikely that's a common pattern.

Overally, I'm 👍 .

@erikng Do you have any insight on why hostname --fqdn sometimes falsely returns a blank string? If so, could you add that information to your comment? Additionally, can you please remove the WTF. Thanks!

[erikng]

Sure, essentially it's the way ohai looks up the host name. The assumption is macOS is similar to Ubuntu/etc in that you must add an entry to etc/hosts to fully resolve. Apple has other native mechanisms that resolve the host name (and ohai uses them!) and while you can certainly add an entry to etc/hosts, most commonly on Apple devices this won't be done.

As for the WTF comment should I remove it from the other comments in this file? Almost the entirety of this PR is taken from other functions.

[mcquin]

Ah. I see now that the comment was copied. Thank you for the delightful and descriptive comment @jaymzh. ❤️

sigh I guess just leave it.

[erikng]

Heh. Would you like me to still add the macOS comments about /etc/hosts?