-
Notifications
You must be signed in to change notification settings - Fork 14
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
Brittle behavior when starting subsequent tsnsrv instances. #62
Comments
efarrer
pushed a commit
to efarrer/tsnsrv
that referenced
this issue
Oct 4, 2023
Incorporate the --name into the state directory so that multiple instances will have unique state directories. Fixes: boinkor-net#62
efarrer
pushed a commit
to efarrer/tsnsrv
that referenced
this issue
Oct 18, 2023
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
pushed a commit
to efarrer/tsnsrv
that referenced
this issue
Jan 14, 2024
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
When a user runs tsnsrv as follows:
Then everything works wonderfully.
However if I try and start a second instance.
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.
The text was updated successfully, but these errors were encountered: