-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Machine rename support #498
Conversation
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 think you are missing some lock mechanism to forbid update of the name from the machine like the enable autogenerate machine name
from https://tailscale.com/kb/1098/machine-names/.
If you don't bring something like that, it would overwritten quickly I think.
Thanks for the feedback. But, that's the point of the nickname field. It's a new field and can only be set by cli (or api). When set, it overrides machine name. When cleared, machine name is used. So, |
Sorry I missed that point. Then, I think you should add a migration script to add the column in the database. See what is done in |
Well, |
Neat thanks ! |
@@ -40,6 +40,13 @@ func init() { | |||
} | |||
nodeCmd.AddCommand(expireNodeCmd) | |||
|
|||
renameNodeCmd.Flags().Uint64P("identifier", "i", 0, "Node identifier (ID)") |
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.
general thought: Is this a rename, or is it a setname or something?
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 just reused headscale namespaces rename
command to keep things familiar. I'm open for suggestions. Right now you can headscale nodes -i 1 rename newmachinename
to set the Nickname
field or headscale nodes -i 1 rename
to clear it.
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.
Ye, its mostly fine, I didnt have a really good name
@@ -207,6 +214,54 @@ var expireNodeCmd = &cobra.Command{ | |||
}, | |||
} | |||
|
|||
var renameNodeCmd = &cobra.Command{ |
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.
These command will need integration tests
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.
Will do
@@ -367,6 +368,29 @@ func (h *Headscale) ExpireMachine(machine *Machine) { | |||
h.db.Save(machine) | |||
} | |||
|
|||
// RenameMachine takes a Machine struct and sets the expire field to now. |
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.
This comment seems wrong ;)
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.
Oops. Result of pure laziness. Fixing...
@@ -40,6 +40,7 @@ type Machine struct { | |||
DiscoKey string | |||
IPAddresses MachineAddresses | |||
Name string | |||
Nickname string |
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 am a bit conflicted about the naming here; Nickname
doesnt just sound completely right, in a way, what is now called Name
should become HostName
and then Nickname
should be Name
or maybe GivenName
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 agree Nickname
is not a good name. I didn't want to change the name of an existing field. Shall I change the Name
to Hostname
and keep the db column name as name
?
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 am slightly concerned that the migration software actually understands this tho... I would like to have that sorted. I personally am not interested in having naming things we are not happy with accumulate.
I suspect that using something like RenameColumn
(https://gorm.io/docs/migration.html) would just end in an "infinite" loop, renaming it every startup
I think we can do:
Nickname string | |
GivenName string |
and HostName
, and add a comment above both with how they are set, and what they mean.
newNickname, err := NormalizeToFQDNRules( | ||
newName, | ||
h.cfg.OIDC.StripEmaildomain, | ||
) |
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.
Since this is a user set name, we should not modify the value, we should throw a "name is not valid error" instead of setting something the user didnt expect.
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.
OK, sounds good. I'll do that
name := machine.Name | ||
if len(machine.Nickname) > 0 { | ||
name = machine.Nickname | ||
} |
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 think we need to think about this a bit differently, if we implement this feature, we will have two name fields:
Name
Nickname
Name
should be the exact hostname that is passed by the Tailscale client, and should not be used in the DNS config.
Nickname
should be set as the Normalized name of Name
on registration (e.g. it will always have a value) and then it can be changed by the user later.
Nickname
should therefore always be used for the DNS Config.
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.
Then, we have to store the state of "Auto-generate from OS hostname" checkbox in database, right? Otherwise, each client update will overwrite this field.
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.
Yes, so the flow should be:
- Machine sends a register request with hostname: TailScaleNode-123
- We set the
HostName
(currentlyName
) field to TailScaleNode-123 - We Normalize TailScaleNode-123 and set the result to
GivenName
(currentlyNickname
)
Then if a user wants to rename the host, we let them do that and use the validation part of the Normalization infra.
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.
It does look like the GivenName
should be unique?
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.
Yes for the DNS to work properly, normalization function should check if GivenName is already registered in DB and add something to it. This step should behave proerly automatically without the use of an admin or the user to change anything. If the user is not satisfied with the name he could change it manually on the tailscale node.
Closing this in favour of #560 |
Changes:
nodes list
outputnodes rename
sets and clears nickname