[jaikiran]

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.

[hughbragg]

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

[jaikiran]

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:

Still, I don't suppose it's a big problem as long as the user password are secure.

Right.