[erlang-questions] reliably figure out hostname

[Geoff Cant]

Oh hey, that rabbit-hole goes way deeper. My system (dns/inet_db config is setup depending on os:type(), mac os gets generic unix treatment). There's a whole lot going on in inet_config to configure inet_db which affects name lookup. But the bit that figures out the hostname for my machine seems to boil down to:

5> {ok, U} = gen_udp:open(0, []).
{ok,#Port<0.597>}
6> inet:gethostname(U).
{ok,"Balder.local"}.

Which seems to be more or less the result of calling 'man 3 gethostname'.

Bleh.

You could just cheat and make the hostname part of your longname either a) the hostname of the system you're trying to connect to, or b) a local ip address converted to an atom (i.e. '127.0.0.1') if you make a hidden connection. It's a little non-kosher, but generally works.


Erlang distribution is about the only thing I use on a regular basis that expects DNS to be configured such that:
1. Any machine can construct its own hostname.
2. These hostnames can be passed off to any third party, and they can subsequently use that hostname to connect back to the original host.

In most places I've worked, 1 is dicey but fixable, and 2 prompts weird looks from the ops/network team.

Good luck,
-Geoff

On 2012-08-02, at 14:58 , Geoff Cant wrote:

> 
> From (hazy) memory, longnames are configured using
> net_adm:localhost(). This differs from the local host name resolution
> methods given in the thread in that it uses the contents of
> 'resolv.conf' (specifically the domain option) to construct the FQDN
> from the hostname.
> 
> https://github.com/erlang/otp/blob/master/lib/kernel/src/net_adm.erl#L74
> 
> 
> The last time I tried to write a reliable distribution based
> start/stop/status control script, I'm pretty sure I ended up inspecting
> the machine configuration, then manually starting distribution via
> something like:
> 
> https://github.com/archaelus/egc_examples/blob/master/rescriptmsh#L6
> 
> to ensure that I would get the name I wanted. Unfortunately I don't have
> permission yet to release the control script that implements all this.
> 
> Cheers,
> -Geoff
> 
> Tim Watson <watson.timothy@REDACTED> writes:
> 
>> Any takers for this? I can't be the only person who's had to figure
>> this out. The context is a distributed systems testing framework that
>> needs to support resolving 'localhost' to a proper host name so the
>> framework can become a hidden node and interact with the other erlang
>> nodes It is testing against. Having to specify the real host name
>> would make configuring the tool across different machines and
>> development environments unpleasantly complicated so figuring out the
>> right hostname is a boon in terms of keeping the configuration
>> overhead down, but doing this for long names nodes is proving highly
>> awkward.
>> 
>> Can anyone suggest a good portable solution?
>> 
>> On 31 Jul 2012, at 13:43, Tim Watson <watson.timothy@REDACTED> wrote:
>> 
>>> Is there a way to calculate the hostname reliably across platforms
>>> in Erlang? I have a non-distributed node that I wish to become a
>>> distributed node. Normally I call net_kernel:start([Name,
>>> shortnames]) and this is just fine. It also works with [Name,
>>> longnames] *sometimes and on some systems* - but other times it
>>> pukes. I've tried looking in the 'domain' or 'search' entries from
>>> inet:get_rc/0 but these are not always populated, even when dns
>>> config is clearly in place. I've also tried using
>>> inet_db:get_searchlist/0' but again, sometimes this returns [[]] but
>>> net_kernel:start([foobar, longnames]) doesn't work, whereas doing
>>> net_kernel:start([foobar@REDACTED, longnames]) does.
>>> 
>>> Am I missing something incredibly obvious here? *is* there actually
>>> a simple way of determining what the proper fqdn for the machine
>>> should be, without breaking out to the os? I had even considered
>>> doing inet:gethostbyname/1 but again, the search domains entry seems
>>> to be empty, so I'd assume that -name foobar will work whereas in
>>> fact, -name foobar@REDACTED is required otherwise net_kernel won't
>>> start.
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> 
> -- 
> Geoff Cant
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

--
Geoff Cant