Skip to content
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

Open
pintify opened this issue Feb 15, 2022 · 7 comments
Open

Server manager does not close properly #3796

pintify opened this issue Feb 15, 2022 · 7 comments

Comments

@pintify
Copy link

pintify commented Feb 15, 2022

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 certificate localhost 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

  1. Remove localhost certificate from HttpsKeystore
  2. Check opened ports on the system
  3. Port 443 is still in use
  4. The port remains used until Kura is stopped

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):

  • Raspberry Pi 4B
  • OS version: raspbian
  • Kura version: 5.0.1

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

@MMaiero MMaiero added the bug label Mar 20, 2022
@github-actions
Copy link
Contributor

This issue is stale because it has been open for 60 days with no activity.

@github-actions github-actions bot added the Stale label Oct 28, 2023
Copy link
Contributor

This issue was closed because it has been inactive for 14 days since being marked as stale.

@pintify
Copy link
Author

pintify commented Nov 13, 2023

Wow! I don't think this issue should be closed without fixing it.

@mattdibi mattdibi reopened this Nov 13, 2023
@mattdibi mattdibi removed the Stale label Nov 13, 2023
Copy link
Contributor

This issue is stale because it has been open for 60 days with no activity.

@pintify
Copy link
Author

pintify commented Oct 7, 2024

The issue remains on version 5.5.0, any update on this?

@mattdibi
Copy link
Contributor

mattdibi commented Oct 7, 2024

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:

  1. upload the new certificate
  2. change the alias used by the web server
  3. restart

Hope this helps.

@pintify
Copy link
Author

pintify commented Oct 9, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants