vpostgres

Automating the silent installation of Site Recovery Manager 5.8 w/Embedded vPostgres DB

10.28.2014 by William Lam // 6 Comments

Last week I had a nice email exchange with Ben Meadowcroft who is the Product Manager for VMware's Site Recovery Manager. While chatting with Ben, I learned about new feature that I was not aware of in the latest SRM 5.8 release which now supports an embedded vPostgres database. Not only does this greatly simplify the installation and not requiring an external database like Microsoft SQL or Oracle, it is also on par in terms scalability with the external databases which is great for customers. I definitely like this improvement in the SRM installation and making it easier to evaluate and POC without requiring a large resource footprint.

UPDATE (11/09/15) - For silent installation of SRM 6.x, please take a look at this article here as some of the install params have changed.

In addition to new database feature, I also learned that SRM supports a silent mode installation which I was not aware of before either. I figured this might come in handy for those needing to automate an SRM deployment given you will need at least two installation: one for the protection site and one for the recovery site. I did not see much documentation on this topic and it has been awhile since I have played with SRM, I thought this would be a good opportunity for some automation goodness as well as checking out some of the new SRM 5.8 features including VSAN support as well as the new vSphere Web Client integration.

In my lab, I wanted to run the a minimal setup and the least amount of Windows 🙂 With that, I was able to use two VCSA, 2 SRM hosts running on Windows 2008 R2 and six Nested ESXi hosts as shown in the diagram below:

To perform a silent installation of SRM, you need to specify a list of 35 parameters to the actual executable which is quite daunting and can also be quite error prone. It actually took me a few tries before I was able to get it working and I wanted to make easier so that anyone can just consume it. I decided to create a simple Windows batch script called install_srm.bat which wraps all the required parameters in a set of variables that can easily be modified by anyone. Out of the 35, only 31 of the parameters can be edited and of those only 15 is really required to be tweaked (which is clearly noted in the script) but also shown below:

SRM_INSTALLER - The full path to the SRM 5.8 installer
DR_TXT_VCHOSTNAME - vCenter Server IP/Hostname
DR_TXT_VCUSR - vCenter Server Username
DR_TXT_VCPWD - vCenter Server Password
VC_CERTIFICATE_THUMBPRINT - vCenter Server SSL SHA1 Thumbprint
DR_TXT_LSN - SRM Local Site Name
DR_TXT_ADMINEMAIL - SRM Admin Email Address
DR_CB_HOSTNAME_IP - SRM Server IP/Hostname
DR_TXT_CERTPWD - SSL Certificate Password
DR_TXT_CERTORG - SSL Certificate Organization Name
DR_TXT_CERTORGUNIT - SSL Certification Organization Unit Name
DR_EMBEDDED_DB_DSN - SRM DB DSN Name
DR_EMBEDDED_DB_USER - SRM DB Username
DR_EMBEDDED_DB_PWD - SRM DB Password
DR_SERVICE_ACCOUNT_NAME - Windows System Account to run SRM Service

Note: To retrieve the vCenter Server SSL Certificate Thumbprint, you can either view the details using a regular web browser as shown in the screenshot below

or you can run the following command on a UNIX/Linux using the openssl utility to extract the thumbprint:

echo -n | openssl s_client -connect [VC-IP-ADDRESS]:443 2>/dev/null | openssl x509 -noout -fingerprint -sha1

Depending on the number of SRM installations you require, you will need to modify the script to perform those additional deployments. As you can see below, I have my two SRM sites implemented. I have also gone ahead and paired both my SRM setups as well as deploy and configure the vSphere Replication 5.8 using the vSphere Web Client. I definitely recommend checking out the latest SRM 5.8 release if you have not already and you may also want to consider using the embedded vPostgres database for future SRM installation to help simplify the deployment and management of SRM.

For those of you who are interested in the variable mappings to the SRM UI installer (which is pretty straight forward), I took screenshots of each step and mapped them for your convenience.

Monitoring vCenter SSO User Account Expiration

01.29.2013 by William Lam // 2 Comments

Did you know that user accounts created in the vCenter SSO Server automatically expire by default after 365 days? If you do not update your password prior to the expiration date, in about a years time you could potentially be locked out of your vCenter SSO Server which also applies to the [email protected] account.

You can change the default password expiration policy by logging into the vSphere Web Client with an SSO Administrator account. Under the configuration section of "Sign-On and Discovery", there is a Password Policies tab that allows you can modify password policies. By default, this is set to 365 days. I would also recommend that after you have installed and setup your vCenter SSO Server, you add at least one user or group from your directory service such as Active Directory and assign it to the SSO Administrator group. This will ensure that you can still log in to the SSO configuration in the event the local SSO user accounts are locked out.

Even though you can change the password expiration policy, there is still no automated notification or alerting built-in for user accounts that are going to expire. The best you can do is to create a calendar event to remind you update your passwords prior to the expiration date. I am sure that many of you are anxious to add another color event to your already busy schedule 🙂

While investigating alternative options a few weeks back, the only method that I have found to retrieve the status for each SSO user is to directly connect to the vCenter SSO Database. There are two specific tables of interest, one which provides the current password policy and the other providing the last password changed date for each SSO user:

ims_authn_password_policy
ims_principal_data

Disclaimer: This "may" not be officially supported by VMware.

Instead of having you manually dig around in the SSO Database, I have created a Perl script called getSSOUserExpiration.pl which can connect to either a MSSQL or vPostgress backend SSO database. The script which will automatically list out the current password policy as well as user accounts that will be expiring in N days, where N is input provided by the user. You also have the ability to configure the script to automatically email you the results which is nice for a daily or weekly report and can be setup using a cronjob or a scheduled task. There are several configuration variables that will need to be adjusted based on your environment and these are all located within the script itself. For more details on how to setup and use the script, please take a look at the Setup and Configuration section below.

Note: To reduce any negative impact to the vCenter SSO Database, you should add or ask your DBA's to create a limited read-only account and limit access to the following tables above. You may even be able to have your DBA's create a scheduled routine for the specific queries and have that emailed to you internally.

Here is a screenshot of connecting to a vPostgres backend Database:

Here is a screenshot of connecting to a MSSQL backend database:

Here is a screenshot of what the email report looks like:

Note: The email body should contain the specific vCenter SSO Database, but I am not sure why it is not showing up in Gmail, but it does work for other email clients.

Setup and Configuration

To connect to a vPostgres DB, you will need to install the following two perl packages: perl-DBI and perl-DBD-Pg. In this example, I am using the vMA appliance and the zypper package installer. For more details on how to add a SLES repo, please take a look at the following article. I also assume if you are connecting to a vPostgres DB, then you are using the VCSA (vCenter Server Appliance) and by default it does not accept remote connections. We will need to also make two configuration changes to the VCSA for our script to be able to connect to the database.

Step 1 - Run the following two commands to install both perl packages:

sudo zypper in perl-DBI
sudo zypper in perl-DBD-Pg

Step 2 - SSH into your VCSA and in the following configuration file /storage/db/vpostgres/pg_hba.conf you will need to add the network in which you will be connecting from:

host all all 172.30.0.0/24 trust

Step 3 - SSH into your VCSA and in the following configuration file /storage/db/vpostgres/postgresql.conf you will need to add the IP Address(s) that you want vPostgres to listen for remote connection. If you use "*", it will allow all addressees:

listen_addresses = '*'

Step 4 - For the changes to go into effect, you will need to restart the vPostgres DB by running the following command:

service vmware-vpostgres restart

Step 5 - Modify the getSSOUserExpiration.pl script and provide the credentials to your vCenter SSO DB. If you need help in identifying the vCenter SSO DB credentials, please refer to this article for the details.

MSSQL

To connect to an MSSQL DB, there are a few additional steps and packages that will be required. We will be using FreeTDS which provides libraries to connect to an MSSQL DB for UNIX/Linux platforms. There was a bit of trial and error in getting the MSSQL solution working and I would like to thank Reuben Stump for his assistance. The following article was used as a reference for the setup below.

Step 1 - Run the following two commands to install the required packages:

sudo zypper in perl-DBI
sudo zypper in gcc

Step 2 - Download and extract the contents of the FreeTDS package:

wget ftp://ftp.astron.com/pub/freetds/stable/freetds-stable.tgz
tar -zxvf freetds-stable.tgz
cd freetds-0.91

Step 3 - Compile and install FreeTDS under /usr/local/freetds:

export SYBASE=/usr/local/freetds/
./configure --prefix=/usr/local/freetds
make
sudo make install

Step 4 - Add your vCenter SSO Server details into the FreeTDS configuration file located in /usr/local/freetds/etc/freetds.conf

[sso]
host = 172.30.0.239
port = 1433
tds version = 7.0

In the example above, I named my database entry "sso" but you can use any name and this will be referenced when editing the script in step 5.

Step 5 - Modify the getSSOUserExpiration.pl script and provide the credentials to your vCenter SSO DB.

vCloud Suite Virtual Appliances: Passwords, Databases, URLs, etc

01.07.2013 by William Lam // 11 Comments

I recently re-organized my home lab and I got rid of a bunch of VMs for random projects that I have been working on last year. Part of this re-organization was to re-deploy a few of the virtual appliances found within the vCloud Suite. As part of the deployment, I often find myself scouring various documents looking for default credentials to the OS, VAMI interface or the application. It is not always easy to find and I often end up going to Google or the VMTN forums for the answer.

As a fun little exercise, I thought why not deploy all of the latest virtual appliance that are available in the vCloud Suite and just document the latest usernames/passwords for the application, OS, VAMI interface, database configurations, URLs, etc.? This would primarily be a reference for myself, but thought it might also benefit others as well. Duncan Epping had done this awhile back for vCloud Director and few other virtual appliance and funny enough, his site was one of the first ones I found for the default vCloud Director password.

Not only have I deployed all the virtual appliances from the vCloud Suite, which can be seen from the screenshot below, but I also went through each appliance and validated the credentials for the application, OS or VAMI interface if applicable as well as identify all database credentials and configurations which are not all publicly documented (this took a bit of digging in the appliances, but was not too difficult if you know where to look).

Note: All credentials and configurations were identified by going through public documentation and exploring the virtual appliances, internal VMware documentation and Wikis were not used (that would have been too easy)

Below is a quick summary of the credentials for the each of the application, OS, VAMI interface as well as applicable database configurations for the 15 virtual appliances within the vCloud Suite. To view the full report on all the virtual appliances in the vCloud Suite, you can refer to either the Spreadsheet or HTML report.

vCenter Infrastructure Navigator 2.0.0

Default App Username: N/A
Default App Password: N/A
Default OS Username: root
Default OS Password: SET DURING DEPLOYMENT
Default VAMI Username: root
Default VAMI Password: SAME AS OS PASSWORD
Database Type: N/A
Database Name: N/A
Default Database Port: N/A
Default DB Username: N/A
Default DB Password: N/A

vCenter Operations Manager (UI) 5.6.0

Default App Username: admin
Default App Password: admin
Default OS Username: root
Default OS Password: vmware
Default VAMI Username: N/A
Default VAMI Password: N/A
Database Type: vPostgres
Database Name: cmapp
Default Database Port: 5432
Default DB Username: cm
Default DB Password: RANDOMLY-GENERATED (refer to spreadsheet/HTML report below for more details)

vCenter Operations Manager (Analytics) 5.6.0

Default App Username: N/A
Default App Password: N/A
Default OS Username: root
Default OS Password: vmware
Default VAMI Username: N/A
Default VAMI Password: N/A
Database Type: vPostgres
Database Name: alivevm
Default Database Port: 5432
Default DB Username: alive
Default DB Password: RANDOMLY-GENERATED (refer to spreadsheet/HTML report below for more details)

vCenter Orchestrator 5.1.0

Default App Username: vmware
Default App Password: vmware
Default OS Username: root
Default OS Password: vmware
Default VAMI Username: root
Default VAMI Password: vmware
Database Type: postgres
Database Name: vmware
Default Database Port: 5432
Default DB Username: vmware
Default DB Password: vmware

vCenter Server Appliance 5.1.0b

Default App Username: N/A
Default App Password: N/A
Default OS Username: root
Default OS Password: vmware
Default VAMI Username: root
Default VAMI Password: vmware
Database Type: vPostgres
Database Name: VCDB
Default Database Port: 5432
Default DB Username: vc
Default DB Password: RANDOMLY-GENERATED (refer to spreadsheet/HTML report below for more details)

vCloud Connector (Server) 2.0.0

Default App Username: N/A
Default App Password: N/A
Default OS Username: root
Default OS Password: vmware
Default VAMI Username: admin
Default VAMI Password: vmware
Database Type: vPostgres
Database Name: hcs1
Default Database Port: 5432
Default DB Username: postgres
Default DB Password: postgres

vCloud Connector (Node) 2.0.0

Default App Username: N/A
Default App Password: N/A
Default OS Username: root
Default OS Password: vmware
Default VAMI Username: admin
Default VAMI Password: vmware
Database Type: vPostgres
Database Name: hcs
Default Database Port: 5432
Default DB Username: postgres
Default DB Password: N/A

vCloud Director 5.1.1

Default App Username: N/A
Default App Password: N/A
Default OS Username: root
Default OS Password: Default0
Default VAMI Username: root
Default VAMI Password: vmware
Database Type: Oracle
Database Name: XE
Default Database Port: 1521
Default DB Username: vcloud
Default DB Password: VCloud

vCloud Networking and Security 5.1.2

Default App Username: admin
Default App Password: default
Default OS Username: admin
Default OS Password: default
Default VAMI Username: N/A
Default VAMI Password: N/A
Database Type: N/A
Database Name: N/A
Default Database Port: N/A
Default DB Username: N/A
Default DB Password: N/A

vFabric Application Director 5.0.0

Default App Username: admin
Default App Password: SET DURING DEPLOYMENT
Default OS Username: root or darwin_user
Default OS Password: SET DURING DEPLOYMENT
Default VAMI Username: root
Default VAMI Password: SAME AS OS PASSWORD
Database Type: postgres
Database Name: darwin
Default Database Port: 5432
Default DB Username: darwin
Default DB Password: N/A

vFabric Hyperic Server (Server) 5.0.0

Default App Username: hqadmin
Default App Password: SET DURING DEPLOYMENT
Default OS Username: root
Default OS Password: SET DURING DEPLOYMENT
Default VAMI Username: root
Default VAMI Password: SET DURING DEPLOYMENT
Database Type: N/A
Database Name: N/A
Default Database Port: N/A
Default DB Username: N/A
Default DB Password: N/A

vFabric Hyperic Server (DB) 5.0.0

Default App Username: N/A
Default App Password: SET DURING DEPLOYMENT
Default OS Username: root
Default OS Password: SET DURING DEPLOYMENT
Default VAMI Username: root
Default VAMI Password: SAME AS OS PASSWORD
Database Type: vPostgres
Database Name: HQ
Default Database Port: 5432
Default DB Username: hqadmin
Default DB Password: SET DURING DEPLOYMENT

vMA 5.1.0

Default App Username: N/A
Default App Password: N/A
Default OS Username: vi-admin
Default OS Password: SET DURING DEPLOYMENT
Default VAMI Username: vi-admin
Default VAMI Password: SAME AS OS PASSWORD
Database Type: N/A
Database Name: N/A
Default Database Port: N/A
Default DB Username: N/A
Default DB Password: N/A

vSphere Data Protection 5.1.1

Default App Username: root
Default App Password: changeme
Default OS Username: root
Default OS Password: SET DURING DEPLOYMENT
Default VAMI Username: N/A
Default VAMI Password: N/A
Database Type: postgres
Database Name: vdrdb
Default Database Port: 5555
Default DB Username: admin
Default DB Password: N/A

vSphere Replication 5.1.0.1

Default App Username: N/A
Default App Password: N/A
Default OS Username: root
Default OS Password: SET DURING DEPLOYMENT
Default VAMI Username: root
Default VAMI Password: SAME AS OS PASSWORD
Database Type: vPostgres
Database Name: vrmsdb
Default Database Port: 5432
Default DB Username: vrmsdb
Default DB Password: N/A