Faster amps install

[grechaw]

This method speeds up amp installation a lot.
I forgot to remove the amps from the project and deployment -- if we want to go ahead with this technique ill do the extra bit.

[srinathgit]

@grechaw ,

I think here it is assumed that "App-Services" is set to "digest" auth. In case if all servers were set to cert-auth, digest with ssl or other authentication type, this may not work. I see the same in undo() method as well

[grechaw]

Yes, I know -- I was hoping I could ask you how to generalize.

[srinathgit]

I think we can use a method like newInstallerClient() in DeployHubAmpsCommand but that would mean that 'sslContext' for stagingAppConfig has to be set to the one obtained using 'admin' certificate (cert whose common name is 'admin' or the security user , user will be logged as the security user). Is that an acceptable change ?

    private DatabaseClient newInstallerClient() {
    	ManageConfig manageConfig = ((HubConfigImpl)hubConfig).getManageConfig();
    	AppConfig stagingAppConfig = hubConfig.getStagingAppConfig();
    	DatabaseClientConfig config = new DatabaseClientConfig(hubConfig.getHost(), 8000, manageConfig.getSecurityUsername(), manageConfig.getSecurityPassword());
	    config.setCertFile(stagingAppConfig.getAppServicesCertFile());
	    config.setCertPassword(stagingAppConfig.getAppServicesCertPassword());
	    config.setDatabase("Security");
	    config.setExternalName(stagingAppConfig.getAppServicesExternalName());
	    config.setSecurityContextType(stagingAppConfig.getAppServicesSecurityContextType());
	    config.setSslContext(stagingAppConfig.getAppServicesSslContext());
	    config.setSslHostnameVerifier(stagingAppConfig.getAppServicesSslHostnameVerifier());
	    config.setTrustManager(stagingAppConfig.getAppServicesTrustManager());
	    return configuredDatabaseClientFactory.newDatabaseClient(config);
    }

[grechaw]

thanks @srinathgit that's exactly what i needed. I'll take it for a spin

[srinathgit]

Ok ... One thing I noticed with using this newInstallerClient() method is that, if all the servers (App-Services, Manage and Admin) are set to cert-auth, setting stagingAppConfig 's 'sslContext' to the one obtained from certificate whose common name matches 'securityUser' results in LoadModulesCommand, DeleteModulesCommand, GenerateModelArtifactsCommand and LoadSchemasCommand (and maybe some other command ?)running as 'securityUser' and not as 'hub-admin-user' as intended.

[srinathgit]

1. It looks like using mlSecurityUserName/mlSecurityPassword anywhere outside of ManageClient can cause issues. Every class that uses the ManageClient like RoleManager, UserManager etc have a way of choosing to use mlSecurityUserName/mlSecurityPassword (and other configurations like securitysslContext etc) by overriding useSecurityUser() method to return 'true', else it uses the regular mlManageUsername/mlManagePassword (non security user sslContext etc) .
2. If we choose to use mlSecurityUserName/mlSecurityPassword anywhere else, then either stagingAppConfig's sslContext or HubConfigImpl.stagingSslContext (depending on what we choose to use) have to be set to user with higher privilege (a security user say "admin") and not to "hub-admin-user"

[grechaw]

It sounds like you've identified a general problem though -- whenever ml-app-deployer chooses to use the security user, then the certs will no longer be valid right?

[srinathgit]

1. No, ml-app-deployer can use the right security context when it uses security user. This was fixed in ManageConfig requires additional setSecuritySslContext() method marklogic/ml-app-deployer#295
2. The issue with using security user anywhere outside of ManageConfig/ ManageClient is that the ManageClient can toggle between using regular user and security user based on whether useSecurityUser() returns true or false. We can't do that in the newInstallerClient() method and in that method stagingAppConfig.sslContext has to be set to the higher privileged user (security user) and not the regular user ("hub-admin-user) making some of the other commands like LoadModulesCommand, DeleteModulesCommand, GenerateModelArtifactsCommand , LoadSchemasCommand etc run as "securityUser" and not as "hub-admin-user" as we desire.

[grechaw]

But that's why I wanted a special client for just these amps -- it has to be done by the security user and should never be attempted by the manage user. That's why I reached in and got the security username and password from manage client.

I'm willing (if you are) to take this as a design bug. This amps installation method will no longer be needed once CMA supports amps (see blocked bug
marklogic/ml-app-deployer#299)

[grechaw]

meaning, once CMA and ml-app-deployer have a fix, then we can again support certs for security user installation. I don't think it's an important must-have right now (my opinion only, not informed)

[srinathgit]

yeah, I agree using newInstallerClient() will be a design bug; hopefully CMA supports amps sooner so that it is no longer needed. Until it happens, we may have to document that if users have all the servers set to ssl/cert auth they will have to override stagingAppConfig's certificate related properties to use security user's credentials