Erlang/OTP Forums

Author Message

<  Erlang patches mailing list  ~  patch: Allow the erlang nodename host part to differ from th

uwiger
Posted: Fri May 07, 2010 3:50 pm Reply with quote
User Joined: 03 Jul 2006 Posts: 604 Location: Sweden
http://github.com/uwiger/otp/tree/epmd_fullnames

Allow the erlang nodename host part to differ from the hostname

This patch makes it possible (practical) to start erlang nodes
using e.g. -sname n@myhost or -name n@myhost.mydomain where the
host/domain differs from that of the machine in question.
While this was possible before, there were some limitations that
made it impractical. The main problem was that nodes use only the
name part when talking to epmd. This made it impossible to run
different nodes with the same name part on the same machine.
(which invalidates one of the good reasons for doing this; a
practical way to name nodes in a cluster is to use the same name
part on all nodes - myproduct@host1, myproduct@host2, etc.)

It turns out that epmd does not need changing. Rather, the nodes
send the full node name rather than just the name part. This is
done only if the flag -epmd_fullnames true is used. This means
that by default, everything works as before.

To make it backwards compatible, a node using "fullname" mode,
trying to connect to another node, will first try asking epmd
with the full node name. If that fails, it will retry with only
the name part. This makes it possible for "fullname" nodes to
connect to "halfname" nodes (although not the other way around).

The kernel test suites have been run. They didn't succeed
completely, but the failures seemed related to hard-coded
hostnames that only exist in the Erlang/OTP environment.

erl_interface has not been touched. This should be fixed, but
is not required for the feature to be useful for those who do
not use erl_interface.

(Forgot to check for whitespace changes before committing - sorry.
There are two lines in there that seem to have shifted, but my
network is almost dead, so for now, I'll let it be.)

BR,
Ulf W
---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com


________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org

---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com

Post received from mailinglist
View user's profile Send private message Visit poster's website
uwiger
Posted: Fri May 07, 2010 3:51 pm Reply with quote
User Joined: 03 Jul 2006 Posts: 604 Location: Sweden
http://github.com/uwiger/otp/tree/epmd_fullnames

Allow the erlang nodename host part to differ from the hostname

This patch makes it possible (practical) to start erlang nodes
using e.g. -sname n@myhost or -name n@myhost.mydomain where the
host/domain differs from that of the machine in question.
While this was possible before, there were some limitations that
made it impractical. The main problem was that nodes use only the
name part when talking to epmd. This made it impossible to run
different nodes with the same name part on the same machine.
(which invalidates one of the good reasons for doing this; a
practical way to name nodes in a cluster is to use the same name
part on all nodes - myproduct@host1, myproduct@host2, etc.)

It turns out that epmd does not need changing. Rather, the nodes
send the full node name rather than just the name part. This is
done only if the flag -epmd_fullnames true is used. This means
that by default, everything works as before.

To make it backwards compatible, a node using "fullname" mode,
trying to connect to another node, will first try asking epmd
with the full node name. If that fails, it will retry with only
the name part. This makes it possible for "fullname" nodes to
connect to "halfname" nodes (although not the other way around).

The kernel test suites have been run. They didn't succeed
completely, but the failures seemed related to hard-coded
hostnames that only exist in the Erlang/OTP environment.

erl_interface has not been touched. This should be fixed, but
is not required for the feature to be useful for those who do
not use erl_interface.

(Forgot to check for whitespace changes before committing - sorry.
There are two lines in there that seem to have shifted, but my
network is almost dead, so for now, I'll let it be.)

BR,
Ulf W
---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com


________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org

Post received from mailinglist
View user's profile Send private message Visit poster's website
uwiger
Posted: Sat May 08, 2010 11:16 am Reply with quote
User Joined: 03 Jul 2006 Posts: 604 Location: Sweden
On 05/08/2010 12:02 PM, Björn Gustavsson wrote:
> On Fri, May 7, 2010 at 5:50 PM, Ulf Wiger
> <ulf.wiger@erlang-solutions.com> wrote:
>>
>> http://github.com/uwiger/otp/tree/epmd_fullnames
>
> Thanks! Included in 'pu'.
>

On the topic of test suites, I did look into writing some tests
to verify the functionality, but at first sight, it was not obvious
how to do this. Thinking about it some more, perhaps the
test_server functions to start slave/peer nodes will be adequate?

This is how I went about connecting two nodes on my laptop
(hostname: uwiger-laptop).

1. Start the first node:
erl -sname n@host1 -epmd_fullnames true

2. Start the second node:
erl -sname n@host2 -epmd_fullnames true

3. In the second node:
1> inet_db:add_host({127,0,0,1}, ["host1"]).
2> inet_db:set_lookup([file, native]).
3> net:ping(n@host1).

Running epmd with the -debug flag helps illustrate what's happening.

If the -epmd_fullnames flag is omitted, an error will be issued
when trying to start the second node, as the Name parts are the
same on both nodes.

The above also works with -name n@host1.somedomain instead of
-sname. Then, the call to inet_db:add_host/2 must be:
inet_db:add_host({127,0,0,1}, ["host1.somedomain"]) instead.

There are other ways to configure the name lookup, as documented in
the ERTS User's Guide.


Re. the documentation - I didn't change it since it is not documented
even today that you can use -sname name@host in the first place, so
I thought that perhaps the feature could be included as an undocumented
feature to begin with? The ambition level of the documentation could be
discussed - ranging from some terse descriptions of each individual
option to a chapter in a User's Guide.

First, perhaps, a decision could be made about whether to include the
feature at all - not least because there is a migration aspect to
consider, should the fullnames option become a future default.

BR,
Ulf W
---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com


________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org

---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com

Post received from mailinglist
View user's profile Send private message Visit poster's website
uwiger
Posted: Sat May 08, 2010 11:16 am Reply with quote
User Joined: 03 Jul 2006 Posts: 604 Location: Sweden
On 05/08/2010 12:02 PM, Björn Gustavsson wrote:
> On Fri, May 7, 2010 at 5:50 PM, Ulf Wiger
> <ulf.wiger@erlang-solutions.com> wrote:
>>
>> http://github.com/uwiger/otp/tree/epmd_fullnames
>
> Thanks! Included in 'pu'.
>

On the topic of test suites, I did look into writing some tests
to verify the functionality, but at first sight, it was not obvious
how to do this. Thinking about it some more, perhaps the
test_server functions to start slave/peer nodes will be adequate?

This is how I went about connecting two nodes on my laptop
(hostname: uwiger-laptop).

1. Start the first node:
erl -sname n@host1 -epmd_fullnames true

2. Start the second node:
erl -sname n@host2 -epmd_fullnames true

3. In the second node:
1> inet_db:add_host({127,0,0,1}, ["host1"]).
2> inet_db:set_lookup([file, native]).
3> net:ping(n@host1).

Running epmd with the -debug flag helps illustrate what's happening.

If the -epmd_fullnames flag is omitted, an error will be issued
when trying to start the second node, as the Name parts are the
same on both nodes.

The above also works with -name n@host1.somedomain instead of
-sname. Then, the call to inet_db:add_host/2 must be:
inet_db:add_host({127,0,0,1}, ["host1.somedomain"]) instead.

There are other ways to configure the name lookup, as documented in
the ERTS User's Guide.


Re. the documentation - I didn't change it since it is not documented
even today that you can use -sname name@host in the first place, so
I thought that perhaps the feature could be included as an undocumented
feature to begin with? The ambition level of the documentation could be
discussed - ranging from some terse descriptions of each individual
option to a chapter in a User's Guide.

First, perhaps, a decision could be made about whether to include the
feature at all - not least because there is a migration aspect to
consider, should the fullnames option become a future default.

BR,
Ulf W
---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com


________________________________________________________________
erlang-patches (at) erlang.org mailing list.
See http://www.erlang.org/faq.html
To unsubscribe; mailto:erlang-patches-unsubscribe@erlang.org

Post received from mailinglist
View user's profile Send private message Visit poster's website

Display posts from previous:  

All times are GMT
Page 1 of 1
This forum is locked: you cannot post, reply to, or edit topics.

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum