Uncategorized

vRealize Automation vPostgres password

The password for vPostgres in vRealize Automation 7 is now encrpyted. This means you will not be able to log in to vPostgres without decrypting the password. To do this, follow these commands:

Check the password name value pair in file : /etc/vcac/server.xml

Eg:
password=”s2enc~Bp/gQ0sSz5ejlemiTxsflCjMNp0GsnHD6tvahuh5Fpw=”

Run the below command on VA to get encrypted password:

vcac-config prop-util -d --p "s2enc~Bp/gQ0sSz5ejlemiTxsflCjMNp0GsnHD6tvahuh5Fpw="

The above command give the password which you can connect to vPostgres.

Then run the following commands:

su postgres
cd /opt/vmware/vpostgres/current/bin
./psql vcac -W

Enter the password and it should let you in to the postgres console, connected to the vcac database.

The other way, is to log in as postgres user and change to the vcac database, but that really is too easy.

./psql postgres
psql.bin (9.4.5 (VMware Postgres 9.4.5.0-3183988 release))
Type "help" for help.
postgres=# \c vcac;
You are now connected to database "vcac" as user "postgres".
vcac=#

 

Advertisements

vRealize 7 Orchestrator endpoint

I’ve just hit a config issue when configuring the embedded vRealize 7 Orchestrator Endpoint in vRealize Automation 7, aka vRA 7. You may hit an error when running a vRealize Orchestrator data collection or hit this error when running a NSX data collection:

Workflow ‘vSphereVCNSInventory’ failed with the following exception:
Endpoint not found. There is no vRealize Orchestrator endpoint configured with property __VMware.VCenterOrchestrator.Plugin.NSX.Build.

In vRealize 6, we used to have to add the endpoint for orchestrator as:

https://vroserver:8281/vco

However vRA now has an embedded LB HAproxy running and you don’t need add port 8281. Therefore the endpoint config just looks like this:

https://vroserver/vco

Screen Shot 2016-01-08 at 10.44.50

One other thing. If you try to enter that endpoint in a browser, it won’t work. You need to append a forward slash, so it should look like this:

https://vroserver/vco/

You will need to add an orchestrator endpoint before being able to run a NSX data collection. You don’t need to configure the NSX plugin and that will get configured as long as your embeeded vRrealize orchestrator endpoint is correct. Additionally, use the load balancer address as required.

 

 

 

 

Monitoring vRealize Automation services using vRealize Orchestrator

You can list the services and their status on the vRealize Automation appliance by going to the following URL.

https://<vra-fqdn>/component-registry/services/status/current

It returns an XML page with elements containing information about the each service. Here’s a screenshot.

Screen Shot 2015-05-18 at 08.34.16

This gave me an idea as you can poll this URL to check the status of the services using a vRO workflow and email if the service status isn’t returned.

Here’s a basic example of some code to poll the URL in a vRO workflow.


// Create Properties object for reporting any unregistered services
var serviceReport = new Properties();

// Form URL constructor
var vraUrl = new URL("https://<va-fqdn>/component-registry/services/status/current");

// Get content
var content = vraUrl.getContent();

// Parse into JSON object
content = JSON.parse(content);

// Get object values
for ( var v in content.content){

	System.log("Service: " + content.content[v].serviceName + ". Intitialised: " + 
				content.content[v].serviceStatus.initialized + ". Status: " + content.content[v].serviceStatus.serviceInitializationStatus)

	if (content.content[v].serviceStatus.serviceInitializationStatus != "REGISTERED"){
		serviceReport.put(content.content[v].serviceName,content.content[v].serviceStatus.serviceInitializationStatus)
	}	
}

It’s a simple workflow that puts any services into a properties object based on some logic, in this case if not equal to REGISTERED. You could then email a support desk, or could retry and check again, or be really funky and check to see if there is a change control ticket open, and if not, then notify support. The key is once you have your workflow created, then you will need to schedule it to run, say every 5 minutes.

You don’t obviously have to use vRO either and use some enterprise monitoring solution, which is what I would recommend.

vRealize Orchestrator – adding permissions to vCenter using ONYX

I was asked a question about how to do something in javascript using the vCenter API and my response was ‘check ONYX’ to see what API calls are being made. My colleagues response was that he wasn’t a fan of Onyx. Now, for a moment I thought about what he said, carried on and got to the bottom of the problem. However later on, I gave some thought about what my colleague said and I do understand why ONYX doesn’t give you the desired out of the box solution, but it sure don’t half help get you there. So, I decided to pick a task and see what the ONYX output was and how helpful it was. The task was to add a user to a role in vCenter.

This was the output of ONYX

// ------- SetEntityPermissions -------

var entity = Server.findForType("VC:Folder", managedObject.vimHost.id + "/group-d1");

var permission = System.getModule("com.vmware.onyx").array(VcPermission, 1);
permission[0] = new VcPermission();
permission[0].principal = "CORP\\asmith";
permission[0].group = false;
permission[0].roleId = -2;
permission[0].propagate = true;

managedObject.setEntityPermissions(entity, permission);  // AuthorizationManager

It’s pretty rough I reckon, but I started to break down what it was doing to get me my solution. The first line :


var entity = Server.findForType("VC:Folder", managedObject.vimHost.id + "/group-d1");

Now, firstly I didn’t understand what this line was doing, but its obviously looking for VC:Folder called group-d1. Investigating this further, this is the root DC folder where I was adding permissions. When I tried to create this entity, it didn’t recognise what the managedObject was. Fair enough, as ONYX knew, but the script doesn’t have any input to tell it what object it was managing. So I found a script that created that entity for me:


//Assume only one VC is registered in the configurator
var dcFolders = VcPlugin.getAllDatacenterFolders();

//Default alarms are defined in the root object of the inventory.
var rootDCFolder;
for (i in dcFolders) {
     if (!dcFolders[i].parent) {
                //datacenter folder without parent - we found to root object
          rootDCFolder = dcFolders[i];
          System.log(rootDCFolder.name);
          break;
     }
}

So now I had the rootDCFolder entity which was the folder I was adding the permission to.

Looking at the next bit of ONYX output, it was building up the permissions I was applying.


var permission = System.getModule("com.vmware.onyx").array(VcPermission, 1);
permission[0] = new VcPermission();
permission[0].principal = "CORP\\asmith";
permission[0].group = false;
permission[0].roleId = -2;
permission[0].propagate = true;


I just swapped out and the first line above, var permission = System.getModule(“com.vmware.onyx”).array(VcPermission, 1);, for an array, so it looked like this:

var permission = new Array();

Pretty simple, and then I didn’t change any of the VcPermission method attributes as these were the permissions I wanted to set. This is actually the helpful stuff ONYX spits out in my opinion.

However, I needed to create the ‘authorizationManager’ object or AzMan that some of us would have come across before. So I looked at the API object explorer in vRealize Orchetrator and found the VC:Folder object method that was initially returned in the ONYX output.

I then created the authorizationManager as per what the API object explorer explained.

var entity = rootDCFolder.sdkConnection.authorizationManager;

So the last bit of ONYX code was to run the setEntityPermissions using the entity object I set as an instance of authorizationManager.

entity.setEntityPermissions(rootDCFolder, permission);  // AuthorizationManager

So this is the entire script:

// ------- GetEntity -------

var dcFolders = VcPlugin.getAllDatacenterFolders();
var rootDCFolder;
for (i in dcFolders) {
     if (!dcFolders[i].parent) {
                //datacenter folder without parent - we found to root object
          rootDCFolder = dcFolders[i];
          System.log(rootDCFolder.name);
          break;
     }
}

// ------- SetEntityPermissions -------

var entity = rootDCFolder.sdkConnection.authorizationManager;
var permission = new Array();
permission[0] = new VcPermission();
permission[0].principal = "CORP\\csmith";
permission[0].group = false;
permission[0].roleId = -2;
permission[0].propagate = true;

entity.setEntityPermissions(rootDCFolder, permission); 

So, it wasn’t too difficult but my colleague is right though as straight off the bat, ONYX output doesn’t look useful and can put people off. However, there was no way I would have got as far without using ONYX!

vRealize Orchestrator – Creating a naming convention using configuration elements

I often need a naming convention function and I use a very cool and easy script to give me a unique naming convention.

I take inputs from either an ASD form, or a catalogue form made up using drop down lists. For example, DEVWEB or PRODDB

I then match that naming convention in a configuration elememt and get the next availble number. Once I have that number, I just increment it, save it so it is ready to use next time I need to create a unique name.

In this case, the vmBaseName is the DEVWEB or PRODDB value

try {
	LockingSystem.lockAndWait(vmBaseName, workflow.id);

	if(namingConfigElement.getAttributeWithKey(vmBaseName) == null) {
		System.log(&quot;Creating attribute for &quot; +vmBaseName);
		namingConfigElement.setAttributeWithKey(vmBaseName,1)		
	} 

	var number = namingConfigElement.getAttributeWithKey(vmBaseName).value;
	number++;
	namingConfigElement.setAttributeWithKey(vmBaseName,number)
	var hostName = vmBaseName + number;
	System.log(&quot;Generated hostname: &quot;+hostName);	
} finally {
	LockingSystem.unlock(vmBaseName, workflow.id);
}

return hostName.toString();

This is what the configuration element looks like:
Screen Shot 2015-02-17 at 21.19.05

So in this example, the next server name would be DEVWEB1.

However I also may want a 3 digit number, beginning with lead zeros, so I use this function:

function pad(num, size) {

	var vmNumber = num+&quot;&quot;;
	while (vmNumber.length &lt; size) vmNumber = &quot;0&quot; + vmNumber;
	return vmNumber;

}

So when I look up the number, I use this line of code

var vmName = vmBaseName + pad(number,&quot;3&quot;);

So in this case, the name I get returned is DEVWEB001. A very handy way of getting a virtual machine unique name.

Installing a DHCP server in Centos 6.x

dhcp

1. Install CentOS 6.x or find an adequate server to run the dhcpd daemon

2. Run the following steps:

sudo yum install dhcp

3. Configuration steps

Edit the following file as shown below:

vim /etc/dhcp/dhcp.conf

Edit to fit your environment

# DHCP Server Configuration file.
# see /usr/share/doc/dhcp*/dhcpd.conf.sample
# see 'man 5 dhcpd.conf
#
subnet 10.10.10.0 netmask 255.255.255.0 {

option routers 10.10.10.1; #Default Gateway
option subnet-mask 255.255.255.0;
option domain-name "myorg.net";
option domain-name-servers 10.10.10.100;
range dynamic-bootp 10.10.10.101 10.10.10.199; #DHCP Range to assign
default-lease-time 43200;
max-lease-time 86400;
}

3.1 Configure DHCP to listen on a specific interface

If more than one network interface is attached to the system, but the DHCP server should only be started on one of the interface, configure the DHCP server to start only on that device. In /etc/sysconfig/dhcpd, add the name of the interface to the list of DHCPDARGS:

# Command line options here
DHCPDARGS=eth0

3.2  Starting the DHCP service

To start the DHCP service, use the command

/sbin/service dhcpd start

To stop the DHCP server, use the command 

/sbin/service dhcpd stop

3.3    DHCP server logs

On the DHCP server, the file /var/lib/dhcp/dhcpd.leases stores the DHCP client lease database. This file should not be modified by hand. DHCP lease information for each recently assigned IP address is automatically stored in the lease database. The information includes the length of the lease, to whom the IP address has been assigned, the start and end dates for the lease, and the MAC address of the network interface card that was used to retrieve the lease.

All times in the lease database are in Greenwich Mean Time (GMT), not local time.
The lease database is recreated from time to time so that it is not too large. First, all known leases are saved in a temporary lease database. The dhcpd.leases file is renamed dhcpd.leases~, and the temporary lease database is written to dhcpd.leases.

The DHCP daemon could be killed or the system could crash after the lease database has been renamed to the backup file but before the new file has been written. If this happens, the dhcpd.leases file does not exist, but it is required to start the service. Do not create a new lease file. If you do, all the old leases will be lost and cause many problems. The correct solution is to rename the dhcpd.leases~ backup file to dhcpd.leases and then start the daemon.

3.4   DHCP relay agent

The DHCP Relay Agent (dhcrelay) allows for the relay of DHCP and BOOTP requests from a subnet with no DHCP server on it to one or more DHCP servers on other subnets. When a DHCP client requests information, the DHCP Relay Agent forwards the request to the list of DHCP servers specified when the DHCP Relay Agent is started. When a DHCP server returns a reply, the reply is broadcast or unicast on the network that sent the original request.

The DHCP Relay Agent listens for DHCP requests on all interfaces unless the interfaces are specified in /etc/sysconfig/dhcrelay with the INTERFACES directive.

To start the DHCP Relay Agent, use the command 

service dhcrelay start