Community
Participate
Working Groups
Based on a Skype discussion, the reasons for picking "localhost" are (+ == pro localhost, - == IP determined by /etc/hosts): + A service provider can overwrite the default with an ECF specific property upon service registration (org.eclipse.ecf.osgi.services.distribution.IDistributionConstants.SERVICE_EXPORTED_CONTAINER_FACTORY_ARGUMENTS) - This sort of configuration should be determined dynamically. Either via system properties, configadmin or InetAddress.getLocalhost()... if they are strictly necessary in the first place. A service provider certainly does not want to make this decision/configuration during service registration. Especially since the arguments are RemoteServiceContainer specific and the currently active container is not known to the service provider during service registration. + InetAddress.getLocalhost().getHostName()/.getHostAddress is a non-reliable way to determine the public IP address - It is the defined way to determine a host address/host name (in Java). It uses the system wide configuration which e.g. comes from /etc/hosts or DHCP. Why duplicate this kind of configuration into a (static) ECF specific property? + registering a service with the public IP address exposes a security risk - Binding a RemoteServiceContainer to 0.0.0.0 instead of 127.0.0.1 is the security risk. Setting the service endpointId to "127.0.0.1" does not enhance security significantly as any skilled attacker will simple do a port scan. + production system need configuration anyway - Administrators will usually set up /etc/hosts correctly or use dynamic means of configuration (DHCP) + dual homed devices need extra configuration - This is not the default (yet) and thus KISS should be applied So what are the possible implementations: a) Do not register host containers automatically (see bug #303979 for counter arguments) b) Create containers automatically, but by default only bind the RemoteServiceContainer to the loopback interface (while printing a warning/info). However, hostname(s) should not be hardcoded to "localhost" but determined dynamically: b1) via InetAddress.getLocalhost().getHost*() b2) System properties b3) OSGi Configadmin c) Create containers automatically and bind them to 0.0.0.0 (b1-3 apply here too). Whatever we decide upon, behavior should be consistent across providers.
Created attachment 180100 [details] Skype discussion for reference
FWIW: - r-OSGi currently does not work with IDistributionConstants.SERVICE_EXPORTED_CONTAINER_FACTORY_ARGUMENTS set to anything else but "r-osgi:// + hostname that points to current host (localhost|public ip|public hostname) + "9278" as the r-osgi bundle creates the endpoint based on system properties/defaults for port/InetAddress (this is related to bug #267521). - generic correctly works with a URI of e.g. "osgiservices://" + public hostname + "12345:" + "/foobar"
Changing target to 3.5 since this won't be addressed in time for 3.4
I'm resolving this bug, as I think we've done what we can on this issue in the short term. If others have contributions to do things in better/easier way (e.g. one of the options listed in the original bug report) then either reopen this bug and attach the contribution (or express intentions about doing contribution), or open a new enhancement request.