[erlang-questions] Inconsistent hostnames
Vlad Dumitrescu
vladdu55@REDACTED
Tue Jul 12 09:32:54 CEST 2016
Hi,
I ran into the same kind of problem when interfacing with Java nodes, but I
guess it happens with every external system where both parties need to come
up with the same host name. If the name resolution is done differently,
there are good chances that the names chosen on each side are different.
One way to improve that is to resolve the hostname before starting the VM
and use "-name foo@REDACTED" or "-sname foo@REDACTED", instead of relying
on Erlang's resolution algorithm. It helps in many cases, but not all (for
example if the short name has a dot, like 'myhost.local', Erlang doesn't
like that).
best regards,
Vlad
On Tue, Jul 12, 2016 at 3:12 AM, Ryan Stewart <zzantozz@REDACTED> wrote:
> > And I predict that it will be cumbersome to figure out what the
> "correct"
> > behaviour would be for both cases on all supported systems
> > and (mis)configurations?
>
> Well, I'd think that at least returning non-conflicting values in the
> various cases would be an improvement. Some sort of documentation of or
> warning about the behavior would be handy, too. I ran across it while
> building out some config management in Ansible, and it took some time to
> figure out why Erlang was complaining about its node names.
>
> On Mon, Jul 11, 2016 at 8:28 AM Raimo Niskanen <
> raimo+erlang-questions@REDACTED> wrote:
>
>> On Mon, Jul 11, 2016 at 03:08:17PM +0200, Oliver Korpilla wrote:
>> > Hello, Raimo.
>> >
>> > Agreed, it could cause surprises, but only on upgrading the system to a
>> newer OTP. Wouldn't it be a bit naive to expect no changes whatsoever when
>> doing that, anyway?
>>
>> "Naive" might be a harsh word. We have historically had internal
>> customers
>> that pay our salary refusing to upgrade to a newer OTP for lesser reasons
>> thus forcing us to maintain an old major release forever
>> (at least for very long), and we do not have those resources.
>>
>> But times have changed for the better so this might be called an
>> inconsistency that should be fixed. It is not my call, though.
>>
>> And I predict that it will be cumbersome to figure out what the "correct"
>> behaviour would be for both cases on all supported systems
>> and (mis)configurations?
>>
>> / Raimo
>>
>>
>> >
>> > Regards,
>> > Oliver
>> >
>> >
>> > Gesendet: Montag, 11. Juli 2016 um 14:36 Uhr
>> > Von: "Raimo Niskanen" <raimo+erlang-questions@REDACTED>
>> > An: erlang-questions@REDACTED
>> > Betreff: Re: [erlang-questions] Inconsistent hostnames
>> > On Tue, Jun 21, 2016 at 07:11:54PM +0000, Ryan Stewart wrote:
>> > > In deploying my erlang app to some new CentOS servers with erlang
>> 18.3, I
>> > > came across an oddity in networking. The server's networking config,
>> which
>> > > is admittedly messed up, looks something like:
>> > > short hostname: bob
>> > > long hostname: bob.prod.example.net
>> > > domain: example.com
>> > >
>> > > Now when I start erlang with "erl -sname x", net_adm:localhost()
>> returns "
>> > > bob.prod.example.net".
>> > >
>> > > However, if I start erlang with "erl -name x", net_adm:localhost()
>> returns "
>> > > bob.example.com".
>> > >
>> > > I believe this comes from net_kernel:create_hostpart/2, where it
>> follows
>> > > different paths on short vs long node names. On a long node name, it
>> > > appears to use short hostname + domain, where on a short node name, it
>> > > simply uses the long hostname. That decision appears to trickle
>> through the
>> > > rest of the networking libraries.
>> > >
>> > > I understand that we need to fix the config on the server. I just
>> wondered
>> > > if this might be considered a bug in erlang as well.
>> >
>> > This behaviour is old, and changing it would either surprise either some
>> > important "short names" using application or ditto "long names" one.
>> >
>> > For -name the Erlang networking code tries to parse the OS configuration
>> > files e.g /etc/resolv.conf to figure out the domain name.
>> > net_adm:localhost() then puts them together.
>> >
>> > For -sname the Erlang networking code tries to look up the short
>> hostname
>> > using the native resolver to find a fully qualified alias, and takes the
>> > domain from that.
>> >
>> > We might call this an annoying irregularity of not very big practical
>> > importance, probably not worth changing...
>> >
>> > I actually do not understand why net_adm:localhost() returns the long
>> > hostname for -sname in the first place. I think the documentation leaves
>> > room for returning the short hostname, but changing that could probably
>> > affect which IP address is used to contact EPMD which would surprise
>> > some important "short names" using application.
>> >
>> > >
>> > > Ryan
>> >
>> > > _______________________________________________
>> > > erlang-questions mailing list
>> > > erlang-questions@REDACTED
>> > > http://erlang.org/mailman/listinfo/erlang-questions
>> >
>> >
>> > --
>> >
>> > / Raimo Niskanen, Erlang/OTP, Ericsson AB
>> > _______________________________________________
>> > erlang-questions mailing list
>> > erlang-questions@REDACTED
>> >
>> http://erlang.org/mailman/listinfo/erlang-questions[http://erlang.org/mailman/listinfo/erlang-questions]
>>
>> --
>>
>> / Raimo Niskanen, Erlang/OTP, Ericsson AB
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160712/7e8a3ba5/attachment.htm>
More information about the erlang-questions
mailing list