Apr 23

I recently had to get caught up on VMware upgrades, specifically going from vCenter 6.0 to 6.7… I know it was over due but I have to confess loosing the fat client is going to hurt.

Anyway in doing my pre-checks I came across the requirement of the distributed switch version 6. Well needless to say I had some still at version 5.5, I guess this slipped my mind since the last 5.5 updates. Anyway back in the day I would just do this via the fat client and be done with it but since the fat client is soon to be history and the web client is so much slower to get things done I decided I was going to automate or script it. This also gave me the chance to incorporate the items that sometimes gets missed, case in point the only way to backup the switch is via the web client but updating and DRS functions can be performed in either, did I mention I’m really going to miss the fat client!

Anyway my script first checks the current version just in case you forgot it was already updated, then if an update is needed grabs the DRS state of the cluster, takes a backup of the dvSwitch, sets the cluster to PartiallyAutomated (this part and the backup are often missed) updates the dvSwitch and then sets the cluster back to the DRS state. Pretty cool eh?

So here is the code… I’ve hard coded a few things just because the way powercli reads and sets the dvSwitch version.

# Script to update distributed switches
# Gets current state of DRS for cluster
# Sets cluster to PartiallyAutomated if needed
# dvswitch config backed up to d:\backups directory
# Updates dvswitch to level in $vdversion
# Sets cluster back to previous DRS setting
# added checks for current version dvs



import-module VMware.VimAutomation.Vds

Connect-VIServer $vCenter | Out-Null

$VDVersion = “6.0.0”
$Cluster = Get-Cluster $ClusterName
$switchversion = Get-VDSwitch -Name $VDSwitch | select-object version

If ($switchversion.version -lt $VDVersion ) {
Write-Host (get-date) “: The DVSwitch for $clustername can be udated to v$VDVersion” -ForegroundColor “yellow”

If ($switchversion.version -gt $VDVersion ) {
Write-Host (get-date) “: The DVSwitch for $clustername appears to be at a higher level than v$VDVersion. No additional action is needed.” -ForegroundColor “green”

ElseIf ($switchversion.version -eq $VDVersion) {
Write-Host (get-date) “: The DVSwitch for $clustername appears to be at v$VDVersion already, No additional action is needed.” -ForegroundColor “Green”

If ($Cluster.DrsEnabled -like “True”-And $switchversion -notlike $VDVersion ) {
Write-Host (get-date) “: DRS is Enabled, it will be temporarily disabled during upgrade.” -ForegroundColor “Yellow”
$ClusterDRSLevel = $Cluster.DrsAutomationLevel
Write-Host (get-date) “: DRS Cluster is currently set to $ClusterDRSLevel. It will changed back when complete.” -ForegroundColor “yellow”
Get-Cluster $Cluster | Set-Cluster -DrsAutomationLevel “PartiallyAutomated” -Confirm:$false
Get-VDSwitch -Name $VDSwitch | select-object Name,Version
Get-VDSwitch -Name $VDSwitch | Export-VDSwitch -Description “dvs Backup” -Destination “d:\backups\$VDswitch-$((Get-Date).ToString(‘yyyy-MM-dd-hh-mm’)).zip” -Force
Get-VDSwitch -Name $VDSwitch | Set-VDSwitch -Version $VDVersion
Write-Host (get-date) “: Upgrade is complete. Setting Cluster back to $ClusterDRSLevel.” -ForegroundColor “Green”
Get-Cluster $Cluster | Set-Cluster -DrsAutomationLevel $ClusterDRSLevel -Confirm:$false
Get-VDSwitch -Name $VDSwitch | select-object Name,Version

ElseIf ($Cluster.DrsEnabled -like “False”) {
Write-Host (get-date) “: DRS is Disabled, No additional action needed.” -ForegroundColor “Green”
Get-VDSwitch -Name $VDSwitch | select-object Name,Version
Get-VDSwitch -Name $VDSwitch | Export-VDSwitch -Description “dvs Backup” -Destination “d:\backups\$VDswitch-$((Get-Date).ToString(‘yyyy-MM-dd-hh-mm’)).zip” -Force
Get-VDSwitch -Name $VDSwitch | Set-VDSwitch -Version $VDVersion
Write-Host (get-date) “: Upgrade is complete.” -ForegroundColor “Green”
Get-VDSwitch -Name $VDSwitch | select-object Name,Version

Disconnect-Viserver $vcenter -confirm:$false | out-null

Jan 20

I had an instance where UCS Director would not allow any new update patches to be installed, constantly telling me I needed 20GB free. After deleting old patches, database backups and anything else I could find I finally got the free space to display 20GB.

At last I can install updates…. NOT!

Seems having 20GB free is not the same as having 20GB free to install updates…what gives? So I needed to add space to my primary disk.

I am running version 6.5 which already required a second 100GB disk for the database so I chose to only add 20GB to my primary disk. Feel free to add more or less because now you will have the instructions!

Shows disk information prior to adding 20GB.

Now add the additional space to the virtual machines’s primary disk. After the space is increased you should also take a snapshot before proceeding! Once you are done reboot the virtual machine.

Once rebooted fdisk – l now shows the increased disk space.

Now we can put that new space to good use by extending the sda3 partition using fdisk /dev/sda

Using the p command you can see the partition information.

Now let’s select the disk and partition to work on. Enter d, then 3, then n and p. This will re-partition partition 3 by extending the cylinder boundary.

Now we just have to write the new information using w and reboot!
Ignore the warning message displayed above, a restart of the virtual machine is expected.

After the virtual machine is up, resize2fs /dev/sda3 and reboot one more time.

Once the virtual machine is back up you can see the /dev/sda3 is now using the extended space and is ready for you to install updates!

Nov 18

Unfortunately older versions of phpMyAdmin have had serious security vulnerabilities including allowing remote users to eventually exploit root on the underlying private server. One can prevent a majority of these attacks through a simple process of locking down the entire directory with Apache’s native user/password restrictions. Follow the steps below to prevent these remote users from even attempting to exploit your version of phpMyAdmin.

Set Up the .htaccess File

We have to start off by allowing the .htaccess file to work within the phpmyadmin directory, this is accomplished my modifying the phpmyadmin configuration file.

Putty or SSH into your server and type the command below to get started. Leave the SSH session open you’ll need it again!
sudo nano /etc/phpmyadmin/apache.conf

Under the directory section, add the line “AllowOverride All” under “Directory Index” (without the “s), making the section look like this:

<Directory /usr/share/phpmyadmin>
Options FollowSymLinks
DirectoryIndex index.php
AllowOverride All

Hit Ctrl X to save and exit nano.

With the .htaccess file allowed, we can proceed to set up a native user whose login would be required to even access the phpmyadmin login page.

From the open putty or SSH session type:
sudo nano /usr/share/phpmyadmin/.htaccess

Now we need to setup user authorization within the new .htaccess file. Copy and paste the following text in:

AuthType Basic
AuthName “Restricted Files”
AuthUserFile /etc/apache2/.phpmyadmin.htpasswd
Require valid-user

Below you’ll see a quick explanation of each line

  • AuthType: This refers to the type of authentication that will be used to the check the passwords. The passwords are checked via HTTP and the keyword Basic should not be changed.
  • AuthName: This is text that will be displayed at the password prompt. You can put anything here.
  • AuthUserFile: This line designates the server path to the password file (which we will create in the next step.)
  • Require valid-user: This line tells the .htaccess file that only users defined in the password file can access the phpMyAdmin login screen.

Now we will go ahead and create the valid user information.
Use the htpasswd command, and place the file in a directory of your choice as long as it is not accessible from a browser. Although you can name the password file whatever you prefer, the convention is to name it .htpasswd.

From the open putty or SSH session type: The username would be a username you want to use!
sudo htpasswd -c /etc/apache2/.phpmyadmin.htpasswd username

A prompt will ask you to provide and confirm your password.
Once the username and passwords pair are saved you can see that the password is encrypted in the file.

Now from the open putty session restart apache:
sudo service apache2 restart

The phpMyAdmin session will now allow only the authorized user to reach the login page. Accessing youripaddress/phpmyadmin should display a login prompt similar to the one below.

Once you enter a valid username and password you can access phpmyadmin with the MySQL username and password.

Nov 18

phpMyAdmin is a free web software that allows you to work with MySQL, it provides a convenient visual front end to MySQL databases.

Before working with phpMyAdmin you need to have LAMP installed on your server. If you don’t have the Linux, Apache, MySQL, PHP stack on your server please install that first. These instructions are for Ubuntu only!

Install phpMyAdmin
The easiest way to install phpmyadmin is through apt-get:

Putty or SSH into your server and type the command below to get started. Leave the SSH session open you’ll need it again!
sudo apt-get install phpmyadmin apache2-utils

During the installation, phpMyAdmin will walk you through a basic configuration. Once the process starts up, follow these steps:

  • Select Apache2 for the server
  • Choose YES when asked about whether to Configure the database for phpmyadmin with dbconfig-common
  • Enter your MySQL password when prompted
  • Enter the password that you want to use to log into phpmyadmin

After the installation has completed, add phpmyadmin to the apache configuration.

From the open putty or SSH session type:
sudo nano /etc/apache2/apache2.conf

Now add the line below to the apache configuration.

Include /etc/phpmyadmin/apache.conf

Hit Ctrl X and save and exit nano.

Now Restart apache.
sudo service apache2 restart

You can then access phpmyadmin by going to youripaddress/phpmyadmin. If everything went well you should see the login screen below.

Nov 18

First off you will have to have an AWS account and create an S3 bucket to use for your website.

  1. Create an s3 bucket using your domain name as the bucket name (your bucket name should be www.example.com if you want your site to be example.com or www.example.com)
  2. Upload your content to the s3 bucket. Choose a consistent name for your website index files (index.html usually). You can also upload a custom page for 404 Not Found errors. Call this 404.html. Give Read permissions to every file in your website so that the public can view it. Don’t give any extra permissions to the bucket, just the files within.
  3. Configure your bucket as a website. With the AWS console ( https://console.aws.amazon.com/s3/) you can select your bucket, click properties, then select the “Website” tab. Click enabled and set your index document to “index.html” and your error document to “404.html”. You will also need to set your bucket with access permissions to allow access via the web (http://docs.amazonwebservices.com/AmazonS3/latest/dev/WebsiteAccessPermissionsReqd.html)
  4. Take a note of the “Endpoint” URL in the website configuration tab. This is where your website lives. You can open the link in a new window and you should see your website just as it will look. Click around and make sure everything works as expected.

You MUST use the endpoint address in all steps below. The normal www.example.com.s3.amazonaws.com won’t work – you need to use the regional version (http://www.example.com.s3-website-us-east-1.amazonaws.com/)

Now, we can set up the DNS to give you a clean, custom URL.

First, we will map www.example.com to your site.

Using your DNS provider’s tools, you need to create a CNAME record to map www.example.com to www.example.com.s3-website-us-east-1.amazonaws.com

The CNAME is the only thing you need if you just want www.example.com. Most people also want “example.com” to work so we need another step.

The “example.com” is often referred to as a naked domain or the apex record of the domain. The reason it’s a problem is that it can’t be a CNAME. CNAMEs only work on subdomains like “www.” This makes it more difficult to point at s3.

The usual approach is to use a service to automatically redirect any request going to example.com to point to www.example.com. This will then pick up your CNAME record and your site will be served from s3.

The automatic redirect is not possible with plain old DNS so you have to use another service. Some DNS providers offer this service along with their DNS (godaddy does, amazon route53 does not)

If your DNS provider doesn’t do it, there are a few free services. One that I’ve used is http://wwwizer.com/naked-domain-redirect – it doesn’t require any registration or payment.

To use this type of service, you need to create a DNS “A” record for your naked domain. The wwwizer.com service requires you to create an A record and point your naked domain (“example.com”) to That’s all they do the redirect to your CNAME!

So, with this setup, if a user types example.com into their browser, the following would happen:

  1. DNS query: example.com -> (wwwizer.com’s service)
  2. HTTP request to for example.com
  3. redirects example.com -> www.example.com
  4. DNS query: www.example.com -> CNAME to www.example.com.s3-website-us-east-1.amazonaws.com
  5. DNS query: www.example.com.s3-website-us-east-1.amazonaws.com -> points to Amazon S3
  6. HTTP request for www.example.com is now served by Amazon S3


Nov 13

Are you getting the FTP prompt below when trying to add themes or plugins in a newly created WordPress EC2 instance and do not want to setup and/or maintain FTP?

If so and you do not want to setup and/or maintain FTP services do this simple step.
Putty into your newly created instance and type:

sudo su
sudo chown –R apache:apache /var/www/html

This will change the owner to the Apache service allowing for HTTP theme and plugin changes.
Log back into WordPress and now you can update and add any Themes and/or plugin via HTTP!

Nov 09

I know…what a title…could I have added a few more acronyms!

This is Amazon’s help page which is pretty good but does not give you the details of actually creating a Linux EC2 instance to use. So first off log into the AWS portal, select EC2 and launch a new instance. I’m going to give you specific instructions for Ubuntu Server 14.04 which I feel is the easiest; you can use any version of Linux but remember the installs commands are different.

Once logged into AWS select the EC2 option and:
Select a Micro instance and click Next:Configure Instance Details

Keep all the items default with the exception of admin IAM role if you have one if not I’d suggest you create one now. The process is here!

Click Next: Add Storage keeping all settings default then click Next: Add Tags.
I would suggest adding a key similar to below but that is up to you.

Click Next: Configure Security Group and either create a new security group to allow the needed ports or select something you already have. I keep a group called MyDMZ that has my entire basic web and SSH ports with the SSH set to my local IP address only.

Click Review and Launch and then Launch from the review screen. Once you do this you are presented with the select key pair dialog. Select an existing or create a new key pair. This is required to connect to the instance via putty or SSH so make sure you have it saved. When ready click the Launch Instances button.

Once the server is built SSH into it and update Ubuntu, install Apache, MySQL and PHP at a minimum and remember the accounts you are asked to create.
Commands are listed below:
sudo su
apt-get update
apt-get upgrade –y
apt-get dist-upgrade –y
apt-get autoremove –y
apt-get install apache2 –y
apt-get mysql-server –y
apt-get phpmyadmin –y

After all this is installed you have to modify a few things…
Edit the apache config:
nano /etc/apache2/sites-enabled/000-default.conf

Add this line:
Include /etc/phpmyadmin/apache.conf

Save the config and restart apache:
service apache2 restart

Leave the SSH session open for now, you still need it!

After all this go to the public IP address in a web browser and verify phpmyadmin is setup.

Log into the local instance with your root id and password:
Return to your SSH session and modify the phpmyadmin config to point to your RDS instance.
nano /etc/phpmyadmin/config.inc.php

Add the lines below to the PMA config area just above the /* Authentication type */ and fill in your RDS instance details to the __FILL_IN_DETAILS_ areas.

$cfg[‘Servers’][$i][‘host’]          = ‘__FILL_IN_DETAILS__’;
$cfg[‘Servers’][$i][‘port’]          = ‘3306’;
$cfg[‘Servers’][$i][‘socket’]        = ”;
$cfg[‘Servers’][$i][‘connect_type’]  = ‘tcp’;
$cfg[‘Servers’][$i][‘extension’]     = ‘mysql’;
$cfg[‘Servers’][$i][‘compress’]      = FALSE;
$cfg[‘Servers’][$i][‘auth_type’]     = ‘config’;
$cfg[‘Servers’][$i][‘user’]          = ‘__FILL_IN_DETAILS__’;
$cfg[‘Servers’][$i][‘password’]      = ‘__FILL_IN_DETAILS__’;

The host info will be your endpoint FQDN address which can be found in the details section of your DB Instance. See below for an example.

Once this is saved go back to the PHPMYADMIN and select the RDS server from the Current Server pull down.

Now you can see and edit all tables and DB settings!




preload preload preload