Installing PSC SSL Cert from machine certificate

In relation to the action plan provided by Paul, it would be indeed beneficial to replace the Lookup Service SSL certificate on a Platform Services Controller 6.0 to be the same as the PSC Machine SSL Certificate.

I would recommend to use below steps - they are based on provided KB article, however, the difference is that we are not going to generate new certicate for Lookup Service SSL certificate - we are going to use the same certificate like for PSC Machine SSL Certificate. By doing this, it will be no difference in certificate that is present on port 443 (Machine SSL certificate) and 7444 (Lookup service SSL certificate).

Please find below the procedure to change the lookupservice certificate (presented on port 7444) to be the same as the PSC Machine SSL Certificate (presented on port 443):

1. Connect to PSC server as root through SSH session.

2. Make a new directory

mkdir /ssl

3. Run the following VECS-CLI commands to export the PSC Machine SSL Cert

/usr/lib/vmware-vmafd/bin/vecs-cli entry getcert --store MACHINE_SSL_CERT --alias __MACHINE_CERT --output /ssl/machine_ssl.crt

/usr/lib/vmware-vmafd/bin/vecs-cli entry getkey --store MACHINE_SSL_CERT --alias __MACHINE_CERT --output /ssl/machine_ssl.key

4. Run this command to generate a .p12 file consisting of both the ssoserver.cer and ssoserver.key file:

openssl pkcs12 -export -in /ssl/machine_ssl.crt -inkey /ssl/machine_ssl.key -name "ssoserver" -passout pass:changeme -out /ssl/ssoserver.p12

Note: Do not modify the -passout value. This must remain as changeme.

5. Run this command to backup the existing ssoserver.p12 file:

cp /usr/lib/vmware-sso/vmware-sts/conf/ssoserver.p12 /usr/lib/vmware-sso/vmware-sts/conf/ssoserver.p12.backup

6. Run this command to replace the old ssoserver.p12 with the newly generated ssoserver.p12 file:

cp /ssl/ssoserver.p12 /usr/lib/vmware-sso/vmware-sts/conf/ssoserver.p12

7. Run this command to restart the Platform Services Controller services:

service-control --stop --all

service-control --start --all

WordPress - instalace

su -l [webmaster]
cd [web-document-root-directory]
fetch https://wordpress.org/latest.zip
unzip latest.zip
mv wordpress [site-name]

su -l root
cd /usr/local/etc/apache24/extra/
vi httpd-vhosts.conf

<VirtualHost *:80>
    ServerAdmin david.pasek@gmail.com
    DocumentRoot "/usr/home/[webmaster]/[site-name]/"
    ServerName [site-name].dpasek.com
    ServerAlias [site-name].dpasek.com
    Options Indexes FollowSymLinks Includes
    ErrorLog "/var/log/[site-name]-error.log"
    CustomLog "/var/log/[site-name]-access_log" common
</VirtualHost>

apachectl restart

mysql -u root -p
CREATE DATABASE wp_[site-name] CHARACTER SET utf8 COLLATE utf8_bin;
grant all privileges on wp_[site-name].* to 'wp_[site-name]'@'localhost' identified by "pwd-[site-name]";

PowerCLI installation

Find-Module VMware.PowerCLI
Install-Module VMware.PowerCLI

Get-Module -ListAvailable VMware*

Update-Module VMware.PowerCLI

VCSA HA heartbeating

Q: What method is used for VCSA HA heartbeating (to validate that the primary VC is really not available)?

A:
There is a TCP hearbeat that happens every second between the nodes (initiated from the Active node). We monitor the active node via that heartbeat and ping. A failover is triggered when there are 3 lost heartbeats followed by 5 failed pings. Therefore, the node (or network) would need to be down for at least 8 seconds for a failover to be triggered.

The heartbeating technology that we use is based off of FDM (which is what vSphere HA uses) so it is a mature methodology that should work quite well.