tinc - Feb 2015 - Tinc1.1 generates Port automatically when port is occupied

I like the config generator of tinc 1.1! An issue to consider on the
default behavior:

It turns out 'tinc -n mynet init mynodename' makes up a default Port=...
when the standard port is taken:
"Warning: could not bind to port 655. Tinc will instead listen on port
22911".

It is nice that this is autodetected and warned, but I wonder whether it is
nice to let this automatic-adaptation a default behavior:
- if people are able to read it, you can just as well leave it to a warning
and suggest running again with a --autoport flag to enable automatic port
generation
- if you cannot read it (e.g. you use configuration management tools to
setup tinc and distribute keys), you're in trouble. it will silently do
things different from what you want.
- it is too clever to be expected. You might not have tested this scenario,
especially since it will work as expected if you run the configuration an
even number of times (!)

You can prevent this by  calling "tinc -n mynet set Port 655"
explicitly of
course. But then you must first run into this issue to note it.

Cheers
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20150202/f98dcfa3/attachment.html>

On Mon, Feb 02, 2015 at 07:46:11PM +0100, Eric Feliksik wrote:
> I like the config generator of tinc 1.1! An issue to consider on the
> default behavior:
> 
> It turns out 'tinc -n mynet init mynodename' makes up a default
Port=...
> when the standard port is taken:
> "Warning: could not bind to port 655. Tinc will instead listen on port
> 22911".
The goal is to create a working setup as easily as possible. 
> - if people are able to read it, you can just as well leave it to a warning
> and suggest running again with a --autoport flag to enable automatic port
> generation
I'm sure I will get some emails from people complaining that if tinc
complains that you should rerun it with --autoport, why doesn't it do it
itself the first time?
> - if you cannot read it (e.g. you use configuration management tools to
> setup tinc and distribute keys), you're in trouble. it will silently do
> things different from what you want.
That's true. I could make it skip the automatic port selection step if
it's not running in an interactive TTY.
> - it is too clever to be expected. You might not have tested this scenario,
> especially since it will work as expected if you run the configuration an
> even number of times (!)
I don't understand this? Either port 655 is available or not. There is
one issue though, and that is when you run tinc init for multiple
netnames consecutively, without starting them. If port 655 is available,
then they will all try to use port 655. I could also have it check
existing configuration files instead for Port statements.
> You can prevent this by  calling "tinc -n mynet set Port 655"
explicitly of
> course. But then you must first run into this issue to note it.
Can you tell me more about how you are generating tinc configuration?
Because normally I would expect that if port 655 is taken when you run
"tinc init", you really don't want the new tinc network to try to
run on
port 655 as well. So I assume it is an issue if you are on one computer,
and trying to generate a configuration for another computer, instead of
running "tinc init" directly on that other computer. It would of
course
be nice if tinc could deduce the intended behavior automatically.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20150202/92a9b464/attachment.sig>

> The goal is to create a working setup as easily as possible.
>
This is going fairly well with 1.1 ;-) thank you.
> - if people are able to read it, you can just as well leave it to a
> warning
> > and suggest running again with a --autoport flag to enable automatic
port
> > generation
>
> I'm sure I will get some emails from people complaining that if tinc
> complains that you should rerun it with --autoport, why doesn't it do
it
> itself the first time?
>
Yeah, true..
>
> > - if you cannot read it (e.g. you use configuration management tools
to
> > setup tinc and distribute keys), you're in trouble. it will
silently do
> > things different from what you want.
>
> That's true. I could make it skip the automatic port selection step if
> it's not running in an interactive TTY.
>
Yes, that would be an improvement IMO. I must say that *I* do not really
like such differences in behavior much, though. I would personally opt for
making the choice interactive, then ("do you want to (F)orce the generation
of port=655 or (R)andomly pick another available port? F/R: "). Then it is
still super easy to use and very obvious that this qbehavior will not work
in non-interactive scripts. But this is a bit subjective, now I may be
conceived as pedantic :-)

>
> > - it is too clever to be expected. You might not have tested this
> scenario,
> > especially since it will work as expected if you run the configuration
an
> > even number of times (!)
>
> I don't understand this? (..)
>
I'll clarify this below.

>
> > You can prevent this by  calling "tinc -n mynet set Port
655" explicitly
> of
> > course. But then you must first run into this issue to note it.
>
> Can you tell me more about how you are generating tinc configuration?
> Because normally I would expect that if port 655 is taken when you run
> "tinc init", you really don't want the new tinc network to
try to run on
> port 655 as well. So I assume it is an issue if you are on one computer,
> and trying to generate a configuration for another computer, instead of
> running "tinc init" directly on that other computer. It would of
course
> be nice if tinc could deduce the intended behavior automatically.
>
What I do is generate a tinc config with ansible. If I have to generate a
new one, I delete the configuration directory and run the ansible script
again. I do not kill tincd. So when ansible then runs the tinc1.1
configuration commands, the configuration process is so clever to note the
port is not available and generates a new port. Then ansible restarts
tincd. Then tincd is on the random port. If I then again run ansible, this
time it succeeds binding to 655, as it became free when ansible restarted
tinc. Hence it will work if you run it a even number of times.

You can of course stop tinc before running ansible, but the point is simply
that nobody expects a running tincd to influence the behavior of the
configuration generating tinc.

I'm not sure if other people feel the same way, but I think it is a problem
and that would be solved by making the clever feature only work by default
if it is an interactive tty.

Cheers
Eric

> --
> Met vriendelijke groet / with kind regards,
>      Guus Sliepen <guus at tinc-vpn.org>
>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20150209/886d9ead/attachment.html>