-
15. Re: WARNING [HornetQServerImpl] Security risk!
jaikiran Aug 25, 2010 1:34 AM (in response to hughbragg)As mentioned in the run.sh of the standalone HornetQ installation:
# By default, the server is started in the non-clustered standalone configuration if [ a"$1" = a ]; then CONFIG_DIR=$HORNETQ_HOME/config/stand-alone/non-clustered; else CONFIG_DIR="$1"; fi
So by default (i.e. if you start the server using ./run.sh), the standalone server runs in non-clustered mode. That means that there won't be any broadcast/discovery attempts.
-
16. Re: WARNING [HornetQServerImpl] Security risk!
hughbragg Aug 25, 2010 1:47 AM (in response to jaikiran)I see thank you.
So even when it runs in the default non-clustered stand-alone more or non-clustered JBoss mode it still logs a warning about the cluster user password security risk even though there is no risk.
I'm hoping it's my lack of experience with HornetQ and clustering, but I worry that if there is an oversight with the logging, perhaps the cluster initialisation code is run anyway. Still, I don't suppose it's a big problem as long as the user password are secure.
Thanks again Jaikiran
-
17. Re: WARNING [HornetQServerImpl] Security risk!
jaikiran Aug 25, 2010 2:48 AM (in response to hughbragg)Hugh Bragg wrote:
I see thank you.
So even when it runs in the default non-clustered stand-alone more or non-clustered JBoss mode it still logs a warning about the cluster user password security risk
Yes, that's correct. Not sure whether that's intentional. Infact, I was curious too and had that on my TODO list to check whether it was an oversight. Never found the time until now. So I just checked the source HornetQServerImpl and I see that it logs that message irrespective of whether the configuration is clustered or not:
private void initialisePart2() throws Exception { ... if (ConfigurationImpl.DEFAULT_CLUSTER_USER.equals(configuration.getClusterUser()) && ConfigurationImpl.DEFAULT_CLUSTER_PASSWORD.equals(configuration.getClusterPassword())) { log.warn("Security risk! It has been detected that the cluster admin user and password " + "have not been changed from the installation default. " + "Please see the HornetQ user guide, cluster chapter, for instructions on how to do this."); } securityStore = new SecurityStoreImpl(securityRepository, securityManager, configuration.getSecurityInvalidationInterval(), configuration.isSecurityEnabled(), configuration.getClusterUser(), configuration.getClusterPassword(), managementService);
It appears to be using that cluster username/pass for it security store configurations (which I guess come into play even when the server isn't clustered).
Hugh Bragg wrote:
Right.