org.apache.brooklyn.location.jclouds

Class CreateUserStatements

java.lang.Object

org.apache.brooklyn.location.jclouds.CreateUserStatements

public class CreateUserStatements
extends java.lang.Object

Method Summary

Modifier and Type	Method and Description
org.jclouds.domain.LoginCredentials	credentials()
static CreateUserStatements	get(JcloudsLocation location, org.jclouds.compute.domain.Image image, ConfigBag config) Returns the commands required to create the user, to be used for connecting (e.g.
java.util.List<org.jclouds.scriptbuilder.domain.Statement>	statements()

Methods inherited from class java.lang.Object

equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Method Detail

credentials

public org.jclouds.domain.LoginCredentials credentials()

statements

public java.util.List<org.jclouds.scriptbuilder.domain.Statement> statements()

get

public static CreateUserStatements get(JcloudsLocation location,
                                       @Nullable
                                       org.jclouds.compute.domain.Image image,
                                       ConfigBag config)

Returns the commands required to create the user, to be used for connecting (e.g. over ssh) to the machine; also returns the expected login credentials.

The returned login credentials may be null if we haven't done any user-setup and no specific user was supplied (i.e. if dontCreateUser was true and user was null or blank). In which case, the caller should use the jclouds node's login credentials.

There are quite a few configuration options. Depending on their values, the user-creation behaves differently:

• dontCreateUser says not to run any user-setup commands at all. If user is non-empty (including with the default value), then that user will subsequently be used, otherwise the (inferred) loginUser will be used.
• loginUser refers to the existing user that jclouds should use when setting up the VM. Normally this will be inferred from the image (i.e. doesn't need to be explicitly set), but sometimes the image gets it wrong so this can be a handy override.
• user is the username for brooklyn to subsequently use when ssh'ing to the machine. If not explicitly set, its value will default to the username of the user running brooklyn.
  • If the user value is null or empty, then the (inferred) loginUser will subsequently be used, setting up the password/authorizedKeys for that loginUser.
  • If the user is "root", then setup the password/authorizedKeys for root.
  • If the user equals the (inferred) loginUser, then don't try to create this user but instead just setup the password/authorizedKeys for the user.
  • Otherwise create the given user, setting up the password/authorizedKeys (unless dontCreateUser is set, obviously).
• publicKeyData is the key to authorize (i.e. add to .ssh/authorized_keys), if not null or blank. Note the default is to use ~/.ssh/id_rsa.pub or ~/.ssh/id_dsa.pub if either of those files exist for the user running brooklyn. Related is publicKeyFile, which is used to populate publicKeyData.
• password is the password to set for the user. If null or blank, then a random password will be auto-generated and set.
• privateKeyData is the key to use when subsequent ssh'ing, if not null or blank. Note the default is to use ~/.ssh/id_rsa or ~/.ssh/id_dsa. The subsequent preferences for ssh'ing are:
  • Use the privateKeyData if not null or blank (including if using default)
  • Use the password (or the auto-generated password if that is blank).
• grantUserSudo determines whether or not the created user may run the sudo command.

Parameters:

image - The image being used to create the VM

config - Configuration for creating the VM

Returns:

The commands required to create the user, along with the expected login credentials for that user, or null if we are just going to use those from jclouds.