Ability to remove a node about headscale

[juanfont]

Done! Although you might have to reload headscale for changes to take effect. We will be working on that next.

[viq]

Seems also the same is true for ephemeral nodes - they get cleaned up only on headscale restart.

[juanfont]

That really sounds like something is being cached. Are you serving this through Cloudflare by any chance?

…

On Thu, 22 Jul 2021 at 22:35, viq ***@***.***> wrote: Seems also the same is true for ephemeral nodes - they get cleaned up only on headscale restart. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABMGQZMIKDPN7PXIDJKM73TZB6KLANCNFSM5AQFGKQA> .

[viq]

No, purely my infra: couple OpenBSD boxes on libvirt on a dedicated server, and all the pieces are running on them. The only possible caching is via nginx, and I thought I disabled it in config.

…

On Thu, 22 Jul 2021, 23:11 Juan Font, ***@***.***> wrote: That really sounds like something is being cached. Are you serving this through Cloudflare by any chance? On Thu, 22 Jul 2021 at 22:35, viq ***@***.***> wrote: > Seems also the same is true for ephemeral nodes - they get cleaned up only > on headscale restart. > > — > You are receiving this because you modified the open/close state. > Reply to this email directly, view it on GitHub > <#52 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AABMGQZMIKDPN7PXIDJKM73TZB6KLANCNFSM5AQFGKQA > > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE4DZNFUYQ4C7AYTMCMLN3TZCCQ7ANCNFSM5AQFGKQA> .

[juanfont]

Can you make sure all the requests arriving to nginx are fwded to Headscale? It sounds very weird...

…

On Thu, 22 Jul 2021 at 23:24, viq ***@***.***> wrote: No, purely my infra: couple OpenBSD boxes on libvirt on a dedicated server, and all the pieces are running on them. The only possible caching is via nginx, and I thought I disabled it in config. On Thu, 22 Jul 2021, 23:11 Juan Font, ***@***.***> wrote: > That really sounds like something is being cached. Are you serving this > through Cloudflare by any chance? > > On Thu, 22 Jul 2021 at 22:35, viq ***@***.***> wrote: > > > Seems also the same is true for ephemeral nodes - they get cleaned up > only > > on headscale restart. > > > > — > > You are receiving this because you modified the open/close state. > > Reply to this email directly, view it on GitHub > > < #52 (comment) > >, > > or unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/AABMGQZMIKDPN7PXIDJKM73TZB6KLANCNFSM5AQFGKQA > > > > . > > > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#52 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AAE4DZNFUYQ4C7AYTMCMLN3TZCCQ7ANCNFSM5AQFGKQA > > . > — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABMGQ7NHZAGIOBM3OOGKRDTZCECVANCNFSM5AQFGKQA> .

[viq]

I just verified with tailscaled on a couple machines connecting directly to headscale's port 8000, and even when headscale logged removal of the ephemeral node, all other machines still show it listed in tailscale status. They'll get removed if I restart tailscaled and it talks to headscale for updates, but without restarts/re-connections those nodes do remain listed.

[viq]

Though I'll add this is with `0.3.4`, I didn't try building `master`. Would you expect different result there?

…

On Sun, 25 Jul 2021, 12:01 Juan Font, ***@***.***> wrote: Reopened #52 <#52>. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE4DZNS6AJTTAAPDE7R3ATTZPOITANCNFSM5AQFGKQA> .

[juanfont]

I will tag a new release as soon as #63 is merged. Apologies for the late response, busy week :(

[viq]

Thanks :) No need to apologise, those are very quick responses for my standards ;)

…

On Sun, 25 Jul 2021, 18:06 Juan Font, ***@***.***> wrote: I will tag a new release as soon as #63 <#63> is merged. Apologies for the late response, busy week :( — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#52 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE4DZJOJV4RKBCR55R75H3TZQZBFANCNFSM5AQFGKQA> .

[juanfont]

This is fixed now :)

[djkazic]

I'm seeing this behavior on headscale 0.22.3.

I'd register a node A, then once I see it in headscale nodes list, remove it with headscale nodes delete -i 5. Confirmed it's gone from the list, but tailscale status on my other machines would still have it there, and it could continue to network.

Only when I restart the tailscale daemon does the connection drop. If I restart the tailscale app of the removed node, similarly, it updates then.

I looked at the code and there doesn't seem to be any polling now, but rather usage of a mapper. Does that mapper suffer from the same issue as what was seen here?

Context: I wanted to write some code that would be able to eject a node from the tailnet, but this doesn't seem possible.

Update: figured out what I did wrong. I should have been calling expire prior to deleting the machines.