-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
extended_bin: Support 'inet_dist_use_interface' in vm.args #891
Conversation
7697a70
to
c1722bc
Compare
Thanks. But weird that the command line kernel option is a tuple and not just an ip string. I don't like having to parse that in shell script :( but I guess no way around it. |
Support specifying the kernel option 'inet_dist_use_interface' in the vm.args file. If ERL_DIST_PORT is set while using Erlang/OTP 23+, make sure to hand over the 'inet_dist_use_interface' address to erl_call.
c1722bc
to
36137dd
Compare
Yes, ugliness 😒
I see no way, except maybe giving up on the idea of specifying the address to use by the main node and by |
Well I guess another way would be using Erlang instead, e.g. something along the following lines. But it's probably preferable not to spin up the VM for that job. # Convert {127,0,0,1} to 127.0.0.1
addr_tuple_to_str() {
addr="$1"
code="catch io:format(\"~s\", [inet:ntoa($addr)]), halt()."
result="$("$BINDIR/erl" -noinput -boot no_dot_erlang -eval "$code")"
if [ -n "$result" ]; then
printf '%s' "$result"
else
echo "Cannot parse IP address tuple: '$addr'" >&2
fi
} |
Oh, duh, its using a tuple because its using |
@@ -674,8 +690,17 @@ EPMD_MODULE="$(grep '^-epmd_module' "$VMARGS_PATH" || true)" | |||
if [ "$EPMD_MODULE" ]; then | |||
DIST_ARGS="${DIST_ARGS} ${EPMD_MODULE}" | |||
fi | |||
INET_DIST_USE_INTERFACE="$(grep '^-kernel *inet_dist_use_interface' "$VMARGS_PATH" || true)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the *
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to cope with the user adding superflous whitespace in vm.args
. I can totally live without that 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean additional spaces between -kernel
and inet_dist_use_interface
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd at least use it in quotes if it were possible, to clarify the intent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I probably need more coffee, you'd add quotes where exactly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah nevermind, I misread the regex and nested argument. The quotes are already there. I had initially read it as 'grep ...'
rather than grep '...'
Yes. That's the (only) way of telling the VM to dist-listen on |
|
||
if [ "$ERL_DIST_PORT" ]; then | ||
if [ "$INET_DIST_USE_INTERFACE" ]; then | ||
ADDRESS="$(addr_tuple_to_str "${INET_DIST_USE_INTERFACE#*inet_dist_use_interface }"):$ERL_DIST_PORT" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what is going on here with ${INET_DIST_USE_INTERFACE#*inet_dist_use_interface }
?
And have to make sure it is posix shell compliant? Not bash.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, looks like shellcheck caught something else so this must have passed and thus work ok with posix shell.
But I still don't know what it is doing :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
${INET_DIST_USE_INTERFACE#*inet_dist_use_interface }
At that point INET_DIST_USE_INTERFACE
is e.g. -kernel inet_dist_use_interface {127,0,0,1}
. The #*inet_dist_use_interface
thing is stripping everything up to the actual address tuple.
And have to make sure it is posix shell compliant?
It is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall I try to come up with something less magic, more readable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, no, this is good and makes sense. I was misreading (still early :) and thought it was like ${ADDRESS#*inet_dist_use_interface }
so had no idea why inet_dist_use_interface
was involved when I thought it was already just the address :)
Not obscure at all. Something we should have supported for using the shell, rpc, etc stuff a long long time ago :). I think this is good, just being cautious since tiny changes in this particular code has broken certain users before. It is a mess. |
Totally makes sense, I'm very happy with such detailed review! 👍 |
Specify 'inet_dist_use_interface' in vm.args rather than sys.config. This lets the extended start script parse the IP address, which allows for specifying the environment variable ERL_DIST_PORT to avoid using EPMD, which is now a documented use case. This feature requires at least Erlang/OTP 23.1 and Rebar3 3.18.0. For details, see: https://blog.erlware.org/epmdlessless/ erlware/relx#891
Support specifying the kernel option
inet_dist_use_interface
in thevm.args
file. IfERL_DIST_PORT
is set while using Erlang/OTP 23 or newer, make sure to hand over theinet_dist_use_interface
address toerl_call
's-address
option.My own use case is binding the VM to
127.0.0.1
(if not actually running a cluster) and still being able to useERL_DIST_PORT
.