-
Notifications
You must be signed in to change notification settings - Fork 6
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
Controller: auto-discover server after nethsecurity-controller restoration #978
Labels
testing
Packages are available from testing repositories
Milestone
Comments
stephdl
changed the title
Controller: autodiscovery the server after a nethsecurity-controller restauration
Controller: Auto-Discover Server After NethSecurity-Controller Restoration
Dec 13, 2024
stephdl
changed the title
Controller: Auto-Discover Server After NethSecurity-Controller Restoration
Controller: auto-discover server after nethsecurity-controller restoration
Dec 13, 2024
gsanchietti
pushed a commit
that referenced
this issue
Jan 10, 2025
Make sure that ns-plug always try to connect to the controller. This fix will allow automatica re-connection in case of disaster recovery of the remote controller. #978
Test case 1
Test case 2
|
Testing image version: 8-23.05.5-ns.1.4.1-22-g15229b475 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue Description:
During a backup restoration process that involves replacing the nethsecurity-controller module, the connection between the controller and the nethsecurity instance is lost. This happens because the TCP ports differ between the old and new modules. Once the restoration is complete, the ns8 module operates normally, but the nethsecurity instance becomes unreachable and is not visible in the system.
To resolve this, manual intervention is currently required: you need to access the nethsecurity instance and manually restart the ns-plug service.
Proposed Improvement (NFR):
Develop a solution that ensures the connection between nethsecurity and the ns8 controller is automatically restored after a backup restoration, eliminating the need for manual intervention.
Steps to Reproduce:
Proposed Solution:
The connection between the instances is established via an OpenVPN tunnel (tun-nsplug). When the tunnel goes down, a trigger could automatically restart the ns-plug service. The downside is that the service has a 60-second timeout period for attempts before it stops.
Alternative Solutions:
Implement a cron job that monitors the connection status. If the tunnel goes down due to a lack of connectivity, the job can automatically restart the ns-plug service.
This enhancement aims to make the restoration process more seamless and reliable.
The text was updated successfully, but these errors were encountered: