Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Brittle behavior when starting subsequent tsnsrv instances. #62

Open
efarrer opened this issue Oct 4, 2023 · 0 comments · May be fixed by #70
Open

Brittle behavior when starting subsequent tsnsrv instances. #62

efarrer opened this issue Oct 4, 2023 · 0 comments · May be fixed by #70

Comments

@efarrer
Copy link
Contributor

efarrer commented Oct 4, 2023

When a user runs tsnsrv as follows:

TS_AUTHKEY=... tsnsrv --name first http://localhost:9090

Then everything works wonderfully.

However if I try and start a second instance.

TS_AUTHKEY=... tsnsrv --name second http://localhost:9090

Then the second instance will fail and the tailscale console will report the error: "Duplicate node key" under the Machine tab.

The conflict is caused by the tsnsrv alwasys using the .config/tsnet-tsnsrv directory (on Linux) to store configuration. This behavior can be avoided by using the -stateDir or TS_STATE_DIR for the second instance however the failure is surprising and will likely lead to confusion. A better solution would be to use a unique directory name (based on the --name parameter) for each tsnsrv instance such as .config/tsnet-tsnsrv-. This would eliminate the surprises and confusion for users.

The cost of this proposal is that it is a backwards incompatible change and that existing users would need to recreate their instances (use a new key). If desired tsnsrv could warn users of the incompatibility by warning all users that have a .config/tsnet-tsnsrv directory that they should delete this directory and recreate their instances.
efarrer pushed a commit to efarrer/tsnsrv that referenced this issue Oct 4, 2023
Fix issue with instances sharing config dir.
d7cde7d 
Incorporate the --name into the state directory so that multiple
instances will have unique state directories.

Fixes: boinkor-net#62
@efarrer efarrer mentioned this issue Oct 4, 2023
Closed
efarrer pushed a commit to efarrer/tsnsrv that referenced this issue Oct 18, 2023
Fix issue with instances sharing config dir.
f060c41 
For legacy installations (where a tsnet-tsnsrv directory has been
created) a new "machine-name" fill will be created in the tsnet-tsnsrv
directory if it doesn't already exist. The machine-name will contain the
name that was passed with the -name command line argument.

If the machine-name file already exists and it matches what was passed
with the -name command line argument then that directory will be used as
the configuration directory.

If the tsnet-tsnsrv directory doesn't exist or if the machine-name
doesn't match then a new tsnet-tsnsrv-<name> directory will be used to
store tsnet configuration.

This allows for more that one tsnsrv instance to be started without
having to specify a config directory without needing to set the
TS_STATE_DIR env var or pass the -stateDir flag.

Fixes: boinkor-net#62
@efarrer efarrer linked a pull request Oct 18, 2023 that will close this issue
Open
efarrer pushed a commit to efarrer/tsnsrv that referenced this issue Jan 14, 2024
Fix issue with instances sharing config dir.
86bfe5a 
For legacy installations (where a tsnet-tsnsrv directory has been
created) a new "machine-name" fill will be created in the tsnet-tsnsrv
directory if it doesn't already exist. The machine-name will contain the
name that was passed with the -name command line argument.

If the machine-name file already exists and it matches what was passed
with the -name command line argument then that directory will be used as
the configuration directory.

If the tsnet-tsnsrv directory doesn't exist or if the machine-name
doesn't match then a new tsnet-tsnsrv-<name> directory will be used to
store tsnet configuration.

This allows for more that one tsnsrv instance to be started without
having to specify a config directory without needing to set the
TS_STATE_DIR env var or pass the -stateDir flag.

Fixes: boinkor-net#62
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
1 participant
@efarrer