-
Notifications
You must be signed in to change notification settings - Fork 312
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
Server manager does not close properly #3796
Comments
This issue is stale because it has been open for 60 days with no activity. |
This issue was closed because it has been inactive for 14 days since being marked as stale. |
Wow! I don't think this issue should be closed without fixing it. |
This issue is stale because it has been open for 60 days with no activity. |
The issue remains on version 5.5.0, any update on this? |
Hi there @pintify, thanks for pinging us. Given this is not a common use-case scenario, the fix for this particular issue wasn't scheduled and thus remains a known issue in 5.5.0. I don't think we have any reference in the docs about this but, from what I understand, the correct procedure for changing a certificate at runtime should be:
Hope this helps. |
Thanks for the update and the new procedure. We are currently using the one I describe up in the issue: close manually and remotely the server manager prior to update the certificate. |
Describe the bug
The bundle
org.eclipse.kura.http.server.manager
does not close properly. At least in case of error with the certificate. If you remove the certificatelocalhost
from the default Httpskeystore, the server goes into error and leave the endpoint on port 443 opened, preventing any further deployment of the web interface.To Reproduce
Steps to reproduce the behavior (it is advisable to backup file
/opt/eclipse/kura/user/security/httpskeystore.ks
before this as it will be emptied during the test):beware the web portal will be lost after the test until you restore the keystore file and restart Kura
Expected behavior
The server should get an error and be closed but the port should not be present, allowing a restart of the service once everything is fine again or it is restarted from the platform (Kapua).
Target Environment (please complete the following information):
Additional context
This test was found when the localhost certificate was being updated. At some time any user should do this and will find the issue it he does not want to restart Kura
There is a workaround possible by stopping the bundle prior to the critical operation and starting it again after it. Make sure you have remote access to the device via Kapua or similar, as the web interface will get down after the stop
The text was updated successfully, but these errors were encountered: