[erlang-questions] detection of hostname

54 views
Skip to first unread message

Vlad Dumitrescu

unread,
Oct 22, 2012, 3:53:50 PM10/22/12
to erlang-questions
Hi!

In erlide we are starting erlang nodes from Java and lately we had
(and still have some) trouble with retrieving a host name that works.

The latest versions are starting an erlang node with "erl -name foo"
and read the hostname used by it. Today I got a report that this
method is not reliable either: for a machine called "desktop", erlang
may detect it is on a network and use "desktop.domain.com" as
hostname. But the DNS might not be able to resolve that name, and it
may not be in /etc/hosts either. So even if two erlang nodes can
connect to each other using this name, other programs that use other
ways to resolve the name can't connect.

I've been trying hardcoding "localhost" and "127.0.0.1" but that makes
the nodes unreachable from other machines, so one can't reliably do
RPCs.

My knowledge about name resolution in networking is poor (just what I
discovered while fighting this issue), so I'll ask a dumb question:
isn't there a method to get a host name that can be use in all
circumstances (when there is one)? That is it should be resolvable by
the OS, not something made-up from the machine name and the network
id...

Or if anybody has a suggestion for another method for starting an
Erlang node that one can later always connect to, I am open for
suggestions.

I could keep adding checks (look for /etc/hosts myself, query the DNS,
etc), but I can't possibly cover all OSs and all possible network
configurations. It feels like this is an operation that should have a
standardized implementation...

Thanks in advance!
best regards,
Vlad
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

Dmitry Kolesnikov

unread,
Oct 22, 2012, 4:07:04 PM10/22/12
to Vlad Dumitrescu, erlang-questions
Hello,

You have two options:

1. You are using FQDN for node name and relies on DNS. If you do not have DNS infra then like you notice /etc/hosts will help you on Unix/Linux, on Win an equivalent should exist.

2. You are using IP address.

- Dmitry

Vlad Dumitrescu

unread,
Oct 22, 2012, 4:41:17 PM10/22/12
to Dmitry Kolesnikov, erlang-questions
Hi Dmitry,

On Mon, Oct 22, 2012 at 10:07 PM, Dmitry Kolesnikov
<dmkole...@gmail.com> wrote:
> You have two options:
> 1. You are using FQDN for node name and relies on DNS. If you do not have DNS infra then like you notice /etc/hosts will help you on Unix/Linux, on Win an equivalent should exist.

This doesn't help if Erlang uses another method and uses another host
name, does it?

> 2. You are using IP address.

For which network adapter, when we have several? I'd have to add a
configuration parameter...

My question could be restated in a different way: is there a standard
way of retrieving the host name in such a way as to get an useable
name? Like in which order to query services, and such. If yes, does
Erlang use it? If no, why not?

Thanks!
regards,
Vlad

Dmitry Kolesnikov

unread,
Oct 22, 2012, 5:27:53 PM10/22/12
to Vlad Dumitrescu, erlang-questions
Hello Vlad,

I believe your question relates a network planning and administration...
According to my understanding Erlang uses DNS resolver routine supplied by OS.
Of course, if host has multiple names then this becomes an issue.

1. You have to come up with particular schema of FQDN assignment to you nodes.
2. You have to resolve synchronization of /etc/hosts across multiple node in the cluster.
3. If you have multiple adapter then they either provides HA within same network or accesses different sub-network. I do not think that you are planning to run Erlang cluster across different sub-networks.

So, I would repeat again but DNS is a standard way of retrieving host name but you have to put an effort to configure it.

I've been always running Erlang clusters within same IP network. I've used both approaches /etc/hosts and IP. IP worked fine when node had a static address but /etc/hosts were used with dynamic IP.

- Dmitry

Daniel Dormont

unread,
Oct 22, 2012, 8:09:52 PM10/22/12
to Dmitry Kolesnikov, erlang-questions
I had a similar question not too long ago, and the response I got was this:

Using 'erl -name something' without an @ sign is generally preferred, but your machine has to be configured right. In Linux specifically, you can use hostname -f to see what name Erlang will choose by default. If this name is not correct and you don't want to fight it, then just pass the machine's own IP address or more appropriate DNS using the @ sign with erl -name.

dan

Bengt Kleberg

unread,
Oct 23, 2012, 1:15:37 AM10/23/12
to erlang-questions
Greetings,

On Solaris the "method to get a host name" is described by the
file /etc/resolv.conf on each computer.


bengt

Vlad Dumitrescu

unread,
Oct 23, 2012, 2:32:57 AM10/23/12
to erlang-questions
Thank you all for the advice! I will use some of it to improve the detection.

I would still want to know how is it possible to run "erl -name foo"
and "erl -name bar" and these nodes can connect to each other all
right (the hostname erlang assigns being "desktop.domain.com"), but on
the same machine "ping desktop.domain.com" can't resolve the name...

The conclusion I draw is that the only way to know is to start a node
and try to connect to it.

Tim Watson

unread,
Oct 23, 2012, 4:52:06 AM10/23/12
to Vlad Dumitrescu, erlang-questions
This is very annoying and I came up against it myself recently for a systems testing framework Ive been working on. There doesn't seem to be a standard way to do this that will pick up all possible configurations, and the problem is more complicated of you take long names into account. I opted to make the user configure the node and host name (plus short or long names scheme) themselves so that I don't have to worry about it.

Raimo Niskanen

unread,
Oct 24, 2012, 3:21:58 AM10/24/12
to Vlad Dumitrescu, erlang-q...@erlang.org
On Tue, Oct 23, 2012 at 08:32:57AM +0200, Vlad Dumitrescu wrote:
> Thank you all for the advice! I will use some of it to improve the detection.
>
> I would still want to know how is it possible to run "erl -name foo"
> and "erl -name bar" and these nodes can connect to each other all
> right (the hostname erlang assigns being "desktop.domain.com"), but on
> the same machine "ping desktop.domain.com" can't resolve the name...

This problem of yours is a mess, and there is no simple answer.

The hostname is a property of the operating system. On Unixes it can
be retreived with the gethostname(2) syscall. That is what
inet:gethostname/0 does, also removing the domain name
if it is contained in the hostname. On BSD it is customary to
configure the fully qualified domain name as the hostname,
but not necessary. Therefore inet:gethostname/0 returns the
short hostname as it is more portable.

When a node starts it reads the hostname and uses it as a
base for the node name if neded. If the hostname contains
a domain name that is used as the domain name for the node,
if needed. If the node starts distributed with long names
some system configuration files (e.g. /etc/resolv.conf)
are parsed to try to find a domain name. On Unix, if the
domain name still is unknown, the short hostname is looked up
using the native lookup method (per default) to try to find
the domain name.

The process is also customizable through the inetrc file and
some environment variables. It is all in inet_config:init/0,
if the documentation (ERTS User's Guide, Inet configuration)
is not enough.

Erlang tries to do it's best to find the hostname and domain name,
but there are so many ways to misconfigure a system, some perfectly
valid. For instance the FQDN the machine thinks it has may be invalid
from the Internet because company policy want to hide network topology
and individual machines.

So, the short hostname returned by inet:gethostname() is the best guess.
The domain name returned by inet_db:res_option(domain) is the best
that can be guessed without knowing which interface and which IP address
that is supposed to be external. The default name lookup method (native)
is the one most likely to work since it is the same as the OS uses
and the one the system administrator has configured and is responsible for.

>
> The conclusion I draw is that the only way to know is to start a node
> and try to connect to it.
>
> best regards,
> Vlad
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions

--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB

Vlad Dumitrescu

unread,
Oct 24, 2012, 4:58:14 AM10/24/12
to Vlad Dumitrescu, erlang-q...@erlang.org
Thank you Raimo for the explanation!

My problem is that people will fiddle with the settings when getting
started with Erlang programming, until it works. But when starting
Eclipse, we have to be able to handle many different cases of
misconfiguration (legitimate or not), with no good way to let the user
configure anyhting. Hopefully, it is fixed now, in the latest erlide
nightly builds. Fortunately, this won't be a problem anymore in the
near future.

I am considering writing (and publishing) a script that would detect
what kind of Erlang communication is possible on a certain machine.
The script could say "Sorry buddy, you can't use long names on this
machine at all" or "Please add 'foo' to /etc/hosts to let short names
work". Whenever people discover some new edge case on their machines,
they can update the script. Maybe it would be useful to distribute
with OTP?

best regards,
Vlad

Attila Rajmund Nohl

unread,
Oct 24, 2012, 5:18:53 AM10/24/12
to Vlad Dumitrescu, erlang-q...@erlang.org
2012/10/24 Vlad Dumitrescu <vlad...@gmail.com>:
> Thank you Raimo for the explanation!
>
> My problem is that people will fiddle with the settings when getting
> started with Erlang programming, until it works. But when starting
> Eclipse, we have to be able to handle many different cases of
> misconfiguration (legitimate or not), with no good way to let the user
> configure anyhting. Hopefully, it is fixed now, in the latest erlide
> nightly builds. Fortunately, this won't be a problem anymore in the
> near future.
>
> I am considering writing (and publishing) a script that would detect
> what kind of Erlang communication is possible on a certain machine.
> The script could say "Sorry buddy, you can't use long names on this
> machine at all" or "Please add 'foo' to /etc/hosts to let short names
> work". Whenever people discover some new edge case on their machines,
> they can update the script. Maybe it would be useful to distribute
> with OTP?

I'm not sure how feasible it is. For example, the "Add 'foo' to
/etc/hosts" advice would not work at all if the operating system
doesn't use the /ets/hosts file for name resolving, for example on
Linux the /etc/nsswitch.conf file has a line like this:

hosts: dns

In an ideal world, you should only add a line "Turn to your system
administrator to properly configure your computer" to the
documentation. However, if there's no competent system administrator,
you're screwed even if you try to add a "crash course in system
administration" to your documentation or try to write a system
administrator script.

Vlad Dumitrescu

unread,
Oct 24, 2012, 5:32:16 AM10/24/12
to Attila Rajmund Nohl, erlang-q...@erlang.org
Hi Attila,

On Wed, Oct 24, 2012 at 11:18 AM, Attila Rajmund Nohl
<attila...@gmail.com> wrote:
> 2012/10/24 Vlad Dumitrescu <vlad...@gmail.com>:
>> I am considering writing (and publishing) a script that would detect
>> what kind of Erlang communication is possible on a certain machine.
>> The script could say "Sorry buddy, you can't use long names on this
>> machine at all" or "Please add 'foo' to /etc/hosts to let short names
>> work". Whenever people discover some new edge case on their machines,
>> they can update the script. Maybe it would be useful to distribute
>> with OTP?
>
> I'm not sure how feasible it is. For example, the "Add 'foo' to
> /etc/hosts" advice would not work at all if the operating system
> doesn't use the /ets/hosts file for name resolving, for example on
> Linux the /etc/nsswitch.conf file has a line like this:
>
> hosts: dns
>
> In an ideal world, you should only add a line "Turn to your system
> administrator to properly configure your computer" to the
> documentation. However, if there's no competent system administrator,
> you're screwed even if you try to add a "crash course in system
> administration" to your documentation or try to write a system
> administrator script.

You're right. The script can list a few things that might or might not
work as starting points, so that people aren't completely lost.

"You will likely have problems if you plan to use distributed Erlang
(which includes emacs+distel or erlide). Here is a list of detected
issues and some possible solutions. Since every network is different,
only your administrator can be sure which one will work. If you are
the administrator, try them one at a time until it works".

best regards,
Vlad

Raimo Niskanen

unread,
Oct 24, 2012, 9:02:42 AM10/24/12
to erlang-q...@erlang.org
That is a good paragraph. I would suggest changing the last line
to not insult anybody's intelligence into something like:
the administrator, use them as guidelines".
and let the reader resort to trying in the blind by him/herself.

>
> best regards,
> Vlad
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions

--

/ Raimo Niskanen, Erlang/OTP, Ericsson AB

Vlad Dumitrescu

unread,
Oct 24, 2012, 9:05:19 AM10/24/12
to erlang-q...@erlang.org
On Wed, Oct 24, 2012 at 3:02 PM, Raimo Niskanen
<raimo+erlan...@erix.ericsson.se> wrote:
>> "You will likely have problems if you plan to use distributed Erlang
>> (which includes emacs+distel or erlide). Here is a list of detected
>> issues and some possible solutions. Since every network is different,
>> only your administrator can be sure which one will work. If you are
>> the administrator, try them one at a time until it works".
>
> That is a good paragraph. I would suggest changing the last line
> to not insult anybody's intelligence into something like:
> the administrator, use them as guidelines".
> and let the reader resort to trying in the blind by him/herself.

You're right. I meant "if you are managing your own machine but are
not a network administrator professional" or something like that :-)

regards,
vlad
Reply all
Reply to author
Forward
0 new messages