Client-side Peer logout mechanism (covering both config.json and management cleanup)

[roonodz]

Is your feature request related to a problem? Please describe.
We use ansible to automatically enroll our servers in Netbird.

But sometimes we want to remove them. We do have an ansible code that will properly clear the server before it will be destroy so it would be nice to have a logout feature in the netbird client.

The problem is as follows

1. We can't use the ephemeral option because 10min is too short. Not all our servers should be deleted for such a short period of downtime.
2. We can't use the netbird client because there's no option to signoff/logout.

Describe the solution you'd like
Ideally, it would be great to have both options:

1. Configure the ephemeral timer at key setup. So we can setup a longer delay like 24h.
2. Add a parameter to signoff/logout from the netbird client command line.

Additional context
None

[b100dian]

There is an /etc/netbird/config.json or /var/snap/netbird/common/config.json that can be moved away (deleted if you know what you're doing) to achieve this in my experience

[enyachoke]

@b100dian will this clean up the peer for the server as well?

[roonodz]

Yes, my goal was to clean up the NetBird server database. The server is being decommissioned anyway.
And remove the configuration file does not achieve this goal.

[b100dian]

No, it doesn't remove the peer registration. This type of logout by removing configuration was useful for me when I cloned a VM that was already logged in.

[matanbaruch]

@roonodz
netbird logout was added
#4268

[saule1508]

it is called netbird deregister now. Unfortunately the logout functionality still does not exist

[lixmal]

What do you mean does not exist? What's missing?

[saule1508]

Sorry was not clear, and to be honest not totally clear for me ! From an end-user point of view it does indeed the trick, if they deregister and then do up again they start fresh with a new session that will be valid for 24 hours. But from an infra point of view, isn't that going to have a negative impact if all the users continuously deregister and register again ? Or can I safely advise the users to do that ?

In fact there is another issue that probably better describe my use case : #4209

So it is really avoiding to start working on something and be kicked out because the SSO login has expired

[nazarewk]

Closing as completed by #4268 as the original use case seems to be supported by this.