-
Notifications
You must be signed in to change notification settings - Fork 265
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
Orion should return error and refuse to start when port is negative #3875
Comments
Looking to:
it seems that somebody (the kubernetes framework that start Orion?) is injecting a wrong variable value. Although probably Orion should react to this giving an error and refusing to start. |
Good point. Kubernetes indeed creates such environment variables according to service-resource. And one of those ENV will be called servicename_PORT . I had a Kubernetes service named Note; this Kubernetes created ENV is not only the port number, but whole tcp-address with port. Solutions include;
Thank you for your time. |
In Orion there is room to a little improvement, so I have re-scoped the issue to:
|
Well ...
Cause ... if the env var isn't set, then Orion will not use it. Now, if this is malfunctioning ( But, if a user has deliberately set the env var to -1 ... well, then the broker should fail - perhaps with a clear error message. Theoretically ... would need to run a test to be 100% sure. |
The user doesn't know anything about ours internals codifications ;). If he sets ORION_PORT to -1 and get Orion running in port 65535 that's weird. We should end with an error in that case. Maybe a "layer" checking env vars values before injecting them to actual settings internally could be helpful. Very minor issue, anyway. |
Sure, we don't want to be nasty :)
Try changing |
/usr/include/limits.h: #define USHRT_MAX 65535 |
So, I modified orion-ld:
And I get this:
The bug in not in the lib, but in the broker's main file (contextBroker.cpp for orion) |
I think it should be
instead of:
as Orion shouldn't limit itself the range of ports in which it can listen. In other words, users with enough privileges should be allowed to run Orion in privileged ports (i.e. ports <=1024). |
Sure, if you wish :) |
Hi @fgalan sir, As per my investigation, Currently Orion can run with any port number ( any -ve as well as +ve port number without any limit) but while querying with any API, Orion is only allowing the ports To fix the same I need to modify the
|
Fixed by PR #4287 |
Hello,
Testing new Orion version 3.0.0, in Kubernetes environment, the container comes up but does not show service at port 1026.
Only after specifying
-port 1026
argument, the component was reachable on this port, even from inside the container.Tested with
https://hub.docker.com/layers/fiware/orion/3.0.0/images/sha256-8c82ef33e15f97fa5c5947adebe7f727b6003a91f81e3f09d074c85ffb3ac1c6?context=explore
and
https://hub.docker.com/layers/fiware/orion/latest/images/sha256-090f0b274d1100809c155a96c1013b5b1665fe4131dfe69101f876e6d0e4e1cd?context=explore
Official documentation refers it should default to 1026:
https://github.com/telefonicaid/fiware-orion/blob/3.0.0/doc/manuals/admin/cli.md
Logs when starting component without
-port
argument or ENV:The text was updated successfully, but these errors were encountered: