Tinc1.1 generates Port automatically when port is occupied

[Eric Feliksik]

> 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>