iThinkVirtual™

Install PowerShell and VMware PowerCLI on CentOS

| 04/03/2018 | Tags: , , , ,

Just a few days ago, PowerShell Core v6.0 was released for Windows, Linux, and macOS systems.  Alongside this release came the release of VMware PowerCLI 10.0.0.78953 which is VMware’s own “PowerShell-like” utility.  

In my previous post, I covered how to install those on to a macOS 10.13.x “High Sierra” system.  In this post, I am going to show how to install both on to a CentOS 7 system as this is the distro I mostly use in my environments.  I may follow this up with an Ubuntu install version.  Anyway, let’s get to it!

Note: If you’re interested in installing this on other Linux distros, please consult the following link.

There is a prerequisite needed before PowerShell can be installed on CentOS and that is to add the PowerShell Core repository (recommended) to your CentOS system.

sudo curl https://packages.microsoft.com/config/rhel/7/prod.repo | sudo tee /etc/yum.repos.d/microsoft.repo

This will prompt you to enter your password since “sudo is being used. Great!  With the prerequisite complete, it’s time to install PowerShell Core 6.0.1.  Run the following command to do so and enter your password when prompted.

sudo yum install -y powershell

Awesome!  Now, to launch a PowerShell session in CentOS, enter the following.

pwsh

Within a PowerShell session, you can check the version of PowerShell by running the following.

$PSVersionTable.PSVersion

As new versions of PowerShell are released, simply update PowerShell by running the following command.

sudo yum update -y powershell

While leveraging the PowerShell Core repository is the recommended installation method, there are alternate methods as well.  For more information on that along with uninstallation commands, please see the following link.

Congratulations!  You’ve successfully installed PowerShell Core 6.0.1 onto CentOS!  Next comes the fun stuff for us VMware enthusiasts, installing VMware PowerCLI from the “PSGallery”.  Let’s continue!

Since VMware PowerCLI has moved from being its own native installer to the PSGallery, the PSGallery needs to be “Trusted” before anything from it can be installed.  To trust the PSGallery, entering the following command in the PowerShell session.

Note: This is optional and if it is skipped, you will be prompted to trust the gallery when entering the PowerCLI module install command

Set-PSRepository -Name "PSGallery" -InstallationPolicy "Trusted"

Next, run the following command to install the VMware.PowerCLI module.  This will find and install the latest version of the module available in the PSGallery

Find-Module "VMware.PowerCLI" | Install-Module -Scope "CurrentUser" -AllowClobber

Note: Alternatively, you could set the “-Scope” parameter to “AllUsers” and if you wanted to install a different version you could use the “-RequiredVersion” parameter and specify the version number.

Once this finishes, we can check to make sure the module is installed by running the following command.

Get-Module "VMware.PowerCLI" -ListAvailable | FT -Autosize

And if you’d like to see all of the VMware installed modules, run the following.

Get-Module "VMware.*" -ListAvailable | FT -Autosize

As new versions of VMware.PowerCLI are released, you can run the following command to update it.

Update-Module "VMware.PowerCLI"

With VMware.PowerCLI now installed, you can connect to your vCenter Server or ESXi host and begin using its cmdlets to obtain information or automate tasks!

I went ahead and ran the following to ensure the module was imported.  

Import-Module "VMware.PowerCLI"

I noticed one caveat, the SRM module does not seem to be supported in PowerShell Core, so I hope that gets resolved soon.

Let’s test connecting to vCenter server…

Connect-VIServer -Server "<Server_Name>"

I also noticed an error when running the above command stating that the “InvalidCertificateAction” setting was “Unset” and not supported.

To bypass this, enter the following command and then enter “Y” when prompted.  This will set the parameter for the current user.

Set-PowerCLIConfiguration -InvalidCertificateAction "Ignore"

Note: Alternatively, you can also use the “-Scope” parameter and enter “Session”, “User”, or “AllUsers” to apply the setting to those options respectively.

Now, if we try to connect to vCenter again, we should be successful.

Well, that about does it!  I hope that you have found this post useful and I thank you for stopping by and reading my content.  I’d like to give a shoutout to Jim Jones for his post on the same topic.  Until next time!

-virtualex-

Pingbacks: From Zero to PowerCLI: CentOS Edition

Install PowerShell and VMware PowerCLI on macOS

Just a few days ago, PowerShell Core v6.0 was released for Windows, Linux, and macOS systems.  Alongside this release came the release of VMware PowerCLI 10.0.0.78953 which is VMware’s own “PowerShell-like” utility.  In this post, I am going to show how to install both on to a macOS system.  Let’s get to it!

There are a few prerequisites needed before PowerShell can be installed on macOS which I will cover, and they are as follows:

  • Homebrew – Homebrew installs the stuff you need that Apple didn’t.
  • Homebrew-Cask – extends Homebrew and brings its elegance, simplicity, and speed to macOS applications and large binaries alike.
  • Xcode Command Line Tools

Per the instructions on the Homebrew site, copy and paste the following command into a terminal window to install Homebrew.

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

This will prompt you to press Enter to continue and the prompt you to enter your password.  It will also check if Xcode command line tools are installed, and if not, it will download and install it for you before completing the installation of Homebrew. Nice!

Now, the next step is to install Homebrew-Cask and per its sites installation notes, copy and paste the following command into a terminal window.

brew tap caskroom/cask

Great!  With the prerequisites complete, it’s time to install PowerShell Core 6.0.1.  Run the following command to do so and enter your password when prompted.

brew cask install powershell

Awesome!  Now, to launch a PowerShell session in macOS, enter the following in terminal.

pwsh

Within a PowerShell session, you can check the version of PowerShell by running the following.

$PSVersionTable.PSVersion

As new versions of PowerShell are released, simply update the Homebrew formulae and update PowerShell by running the following commands in terminal.

brew update
brew cask upgrade powershell

While leveraging Homebrew is the recommended installation method, there are alternate methods as well.  For more information on that along with uninstallation commands, please see the following link.

Congratulations!  You’ve successfully installed PowerShell Core 6.0.1 onto macOS!  Next comes the fun stuff for us VMware enthusiasts, installing VMware PowerCLI from the “PSGallery”.  Let’s continue!

Since VMware PowerCLI has moved from being its own native installer to the PSGallery, the PSGallery needs to be “Trusted” before anything from it can be installed.  To trust the PSGallery, entering the following command in the PowerShell session.

Note: This is optional and if it is skipped, you will be prompted to trust the gallery when entering the PowerCLI module install command

Set-PSRepository -Name "PSGallery" -InstallationPolicy "Trusted"

Next, run the following command to install the VMware.PowerCLI module.  This will find and install the latest version of the module available in the PSGallery

Find-Module "VMware.PowerCLI" | Install-Module -Scope "CurrentUser" -AllowClobber

Note: Alternatively, you could set the “-Scope” parameter to “AllUsers” and if you wanted to install a different version you could use the “-RequiredVersion” parameter and specify the version number.

Once this finishes, we can check to make sure the module is installed by running the following command.

Get-Module "VMware.PowerCLI" -ListAvailable | FT -Autosize

And if you’d like to see all of the VMware installed modules, run the following.

Get-Module "VMware.*" -ListAvailable | FT -Autosize

As new versions of VMware.PowerCLI are released, you can run the following command to update it.

Update-Module "VMware.PowerCLI"

With VMware.PowerCLI now installed, you can connect to your vCenter Server or ESXi host and begin using its cmdlets to obtain information or automate tasks!

I went ahead and ran the following to ensure the module was imported.  

Import-Module "VMware.PowerCLI"

I noticed one caveat, the SRM module does not seem to be supported in PowerShell Core, so I hope that gets resolved soon.

Let’s test connecting to vCenter server…

Connect-VIServer -Server "<Server_Name>"

I also noticed an error when running the above command stating that the “InvalidCertificateAction” setting was “Unset” and not supported.

To bypass this, enter the following command and then enter “Y” when prompted.  This will set the parameter for the current user.

Set-PowerCLIConfiguration -InvalidCertificateAction "Ignore"

Note: Alternatively, you can also use the “-Scope” parameter and enter “Session”, “User”, or “AllUsers” to apply the setting to those options respectively.

Now, if we try to connect to vCenter again, we should be successful.

Well, that about does it!  I hope that you have found this post useful and I thank you for stopping by and reading my content.  I’d like to give a shoutout to Mike White for his post on the same topic.  Until next time!

-virtualex-

Pingbacks: Installing PowerShell/PowerCLI on a Mac

Deploy A Virtual Appliance Using PowerCLI

| 04/02/2018 | Tags: , , ,

Hello all and thank you for visiting my blog!  In today’s post, I am going to cover how to deploy a VMware virtual appliance (.ova) using PowerCLI.  “Why?” you asked?  Well, because scripting and automation via PowerCLI is fun and awesome!  Sure, it’s simple enough to deploy an appliance natively within the vSphere Web Client by selecting the .ova that you’d like to import, press a few mouse clicks, enter some info, and off you go!  But who wants to do stuff the easy way?  It takes the fun away!

In my opinion, scripting this out is just as easy since you can pre-populate your information into variables, and then run a simple “one-liner” command to kick off the deployment.  Pretty neat right? 

Now, I do understand that initially doing a deployment this way is a bit time-consuming.  But once you have the method and process down, you can create a simple PowerShell script with all of your information embedded, then simply tweak/adjust it as needed per appliance.  The only time-consuming part is identifying the proper variables for each appliance.  Please keep in mind that while most appliances have the same initial setup variables, some may have more and some may have less so it is always best to follow the initial steps I’ll cover below for each appliance to ensure you have all the correct information for your deployment and/or script.

Well, let’s get to it, shall we!

In this example, I will be using the latest version of PowerCLI which, at the time of this writing, is 6.5.4.7155375, to deploy the VMware Support Assistant appliance for vSphere 6.5.

To kick things off, we will be using two important variables, $ovfPath, and $ovfConfig.  The latter will use the $ovfPath variable to discover the correct variable properties to build out our $ovfConfig.  I’ll assume that you’re already connected to your vCenter server in the PowerCLI session but, if not, please go ahead and do so using the “Connect-VIServer” cmdlet.

Let’s define our $ovfPath first:

$ovfPath = "<path_to_ova_file>"

Next, let’s define $ovfConfig

$ovfConfig = Get-OvfConfiguration -Ovf $ovfPath

Great!  Now if we simply type $ovfConfig, it will check our $ovfPath for the file and list the setup properties.

We can see that it has identified “Common“, “IpAssignment“, “NetworkMapping“, and “vami” as the starting base properties.  Next, we will have to drill down into each of these properties to determine the full property “Value” to define our variable with.

So starting with “Common“, let’s drill down more by typing:

$ovfConfig.Common

This now identifies the next “Common” property which is “varoot_password“.  Let’s drill into that to see what it finds.

$ovfConfig.Common.varoot_password

This gives us more information about the property and the key one here is “Value“. 

This means that we have reached the last property entry needed to define our first config variable with.  Great! With this information, our first defined configuration variable will look like this:

$ovfConfig.Common.varoot_password.Value = "<some_password>"

Let’s now move to the next property, “IpAssignment“.  Following the same logic as before and drilling into this property identifies “IpProtocol” which requires a “string” value of “IPv4 or IPv6“. 

This means our next defined variable will look like this.

$ovfConfig.IpAssignment.IpProtocol.Value = "IPv4"

Now for the next property, “NetworkMapping“.  Drilling down into this property identifies “Network_1” which again will be a “string” value for our variable.  This string is the VM PortGroup that you want to attach to the appliance, whether it be on a virtual Standard Switch (vSS) or Distributed Switch (vDS).

This defined variable will look like this.

$ovfConfig.NetworkMapping.Network_1.Value = "<some_vm_portgroup>"

Getting the gist of this yet?  Let’s move onto the final property, “vami“.  Again, following the same logic we’ve been doing and drilling into the “vami” property, we can see that it has identified the “appliance” as “VMware_vCenter_Support_Assistant_Appliance“.  Drilling down further, there are multiple properties discovered in this one and they are “gateway“, “domain“, “searchpath“, “DNS“, “ip0“, and “netmask0“.

Whoa! Quite a few huh?  Yet again, drilling into each of these lets us know that “string” values are required for each property.

These config variables will be defined like this.

$ovfConfig.vami.VMware_vCenter_Support_Assistant_Appliance.gateway.Value = "<gateway_ip>"
$ovfConfig.vami.VMware_vCenter_Support_Assistant_Appliance.domain.Value = "<domain_name>"
$ovfConfig.vami.VMware_vCenter_Support_Assistant_Appliance.searchpath.Value = "<dns_searchpath>"
$ovfConfig.vami.VMware_vCenter_Support_Assistant_Appliance.DNS.Value = "<dns_ip(s)>"
$ovfConfig.vami.VMware_vCenter_Support_Assistant_Appliance.ip0.Value = "<appliance_ip>"
$ovfConfig.vami.VMware_vCenter_Support_Assistant_Appliance.netmask0.Value = "<netmask_ip>"

From what we’ve obtained so far, all of our defined variables look like this.

Ready to deploy the appliance?  Not quite yet!  There are some additional variables we can create/define to make the syntax of our command shorter, neater, and nicer.  First, let’s see what the cmdlet requires.  The cmdlet used to deploy an appliance is “Import-vApp“.  Clinking that link and reviewing the table show us what is required or not.

From this table, I am going to define some more variables for the following parameters.

  • Source
  • Name
  • VMHost
  • Datastore
  • DiskStorageFormat
  • Location
  • OvfConfiguration

Now, with all of the variables defined, we are ready to enter the “Import-VApp” command with the required parameters.

Import-VApp -Source $ovfpath -OvfConfiguration $ovfConfig -Name $VMName -VMHost $VMHost -Location $Cluster -Datastore $Datastore -DiskStorageFormat $DiskFormat -Confirm:$false

A progress bar will load in your session showing that the deployment has kicked off, and a short while later it will end, meaning that the appliance has been successfully deployed.

A quick look at the vSphere Client, and we can see that the appliance is indeed there and configured as per the settings we defined earlier in our configuration.

At this point, you can safely power-on the appliance and proceed with normal setup processes.  Also, as I noted earlier, you can take all of these variables and create a PowerShell script to deploy your appliances with and just add/remove/change variables as needed per appliance!  Automation at its finest!

Well, I’d like to thank you for stopping by and supporting my page.  I do hope that you have found this information useful, and hope you’ll return again.  Thanks much and I’ll catch you on the next one!

-virtualex-

vSphere…Synology…NFS v4.1

| 31/12/2017 | Tags: , , , ,

Welcome, and thanks for visiting my blog!

In this post, I am going to cover how to enable NFS v4.1 on a Synology device and then mount and NFS v4.1 datastore in VMware vSphere 6.5.  By default, Synology devices support NFS v4 natively, and although they can also support NFS v4.1, it is not enabled.  Well, not to worry because I am going to show you just how to enable the feature on your device.

NFS v4 and v4.1 have been around for quite a few years but it has not taken off then way NFS v3 did way back when.  There were some major flaws pointed out with NFSv4 so NFSv4.1 was created to rectify those flaws, and VMware was one of the first major companies to adopt and support the new Network File System.  But unless your storage device supported the newer NFS versions, you would be stuck mounting NFSv3 volumes by default.

In this demo, I will be using my new replacement Synology DiskStation DS415+ and my homelab “datacenter” running the latest version vSphere 6.5.  So let’s jump right in!

Using a terminal application like PuTTY, connect to your Synology device via SSH using an admin user account.  This can be the default “admin” account and any new user account with Administrator privileges.  Once connected enter the following command to change the directory:

cd /usr/syno/etc/rc.sysv

Once in this directory, run the following command (enter the account password if prompted):

sudo cat /proc/fs/nfsd/versions

This will show us the current NFS version currently enabled and supported by the Synology device. 

We can see that all versions prior to 4.1 have a “+” sign next to them and 4.1 has a “-” sign next to it.  Let’s change that!

In order to change this, we will need to edit a shell (S83nfsd.sh) file using “vi”.  Run the following command to open the file with VI Editor:

sudo vi S83nfsd.sh

This will open the shell file and will place the cursor at Line 1, Character 1 as depicted in the following screenshot.  

Navigate down to line 90 using the down arrow and you will see the following line of text.

This is where the magic happens!  To edit the file now, press the “I” key on your keyboard to initiate an “Insert” then add the following to the end of the text so the line looks like the following screenshot.

-V 4.1

To commit and save this change, first press the Esc key.  Next type the following command and hit “Enter” to write and then quit vi editor.

:wq

 

 

Next, we need to restart the NFS service.  To do so enter the following command:

sudo ./S83nfsd.sh restart

 

If we again run the following command, we will see that there is now a “+” sign next to 4.1.  Hooray!

sudo cat /proc/fs/nfsd/versions

 

Now that we have enabled NFSv4.1 functionality on your storage device, let’s go ahead and mount an NFS volume to our hosts in vSphere.

I have enabled NFS and NFS v4 support then created the following shares with assigned permissions on my device, and am going to mount the ISOs share first in this example by issuing a command via PowerCLI.  We can also see that I do not have any NFS mounts currently in my environment

I’ve launched PowerCLI and connected to my vCenter Server using the Connect-VIServer cmdlet then issued the following command:

Get-VMHost | New-Datastore -Nfs -FileSystemVersion '4.1' -Name SYN-NFS04-ISOs -Path "/volume3/NFS04-ISOs" -NfsHost DS415 -ReadOnly

*Note:* an important argument here in the “-FileSystemVersion”.  If I do not specify the version, it will assume version 3.0 by default.

If I go back and look at my datastores via the Web Client, I can see that my new NFS 4.1 datastore has been mounted to each one of my ESXi hosts. Nice!

*Bonus:* If I’d like to easily remove this datastore from all of my hosts, I can issue the following command via PowerCLI.

Get-VMHost | Remove-Datastore -Datastore SYN-NFS04-ISOs -Confirm:$false

Now I can see that the host has been removed successfully!

Well, that about wraps this one up.  I hope that this has been useful and informative for you and I’d like to thank you for reading!  Until next time!

-virtualex-

macOS 10.13 High Sierra on ESXi 6.5

**NOTE: This is completely for experimental purposes and is unsupported by both Apple and VMware**

Hello all!  This is just a quick follow up to my previous guide on running macOS 10.12 Sierra on ESXi 6.x, where I have now successfully updated the VM to macOS 10.13 High Sierra.

If you simply try to run the upgrade via a self-made ISO, or via the Mac App Store, the final image will fail to boot.  The reason being is because starting with macOS 10.13, Apple has converted the file system from Hierarchical File System Plus (HFS Plus orHFS+) to the new Apple File System (APFS).  During the upgrade process, the HFS+ will be converted to APFS, and the unlocker utility which allows us to even run a macOS VM on ESXi doesn’t support APFS.  In fact, support for ESXi, in general, is no longer available in the latest Unlocker 2.1.1 so I am still using the Unlocker 2.1.0 for ESXi, and Unlocker 2.1.1 for VMware Workstation 14.

For this quick tutorial, I am using the latest VMware ESXi 6.5 Update 1 Build 7388607 and I started by simply cloning my macOS 10.12 VM to a new virtual machine.

Once powered on, go to the Mac App Store and download the macOS High Sierra installation.  When the download is complete, DO NOT run the installer and quit it instead.  You will now have the installer application available in your Applications folder.

Now, open a Terminal session and enter the following command as one line.  Depending on the account you’re are logged in with, sudo may or may not be needed.

sudo /Applications/Install\ macOS\ High\ Sierra.app/Contents/Resources/startosinstall --converttoapfs NO --agreetolicense --nointeraction

The key argument here is the “–converttoapfs NO” which prevents the OS from converting the drives file system format from HFS+ to APFS.  Additionally, the “–nointeraction” argument is optional.

Now sit back, relax, and let the upgrade do its thing.  When the upgrade is complete, the VM should have successfully booted up and you will now be running macOS High Sierra.

-virtualex

Pingbacks:

Fixing A Corrupt Domain Controller – Stop Code 0x00002e2

Yesterday morning I discovered that my Synology NAS had an unexpected shutdown in the middle of the night while my homelab VMs/workloads were still running.  This caused both of my Domain Controllers databases to become corrupt resulting in being unable to boot those machines.  When attempting to boot them, they would get stuck in a BSOD boot-loop and would display a Stop Error Code of 0x00002e2.

.

After some research I was able to figure out how to recover my VMs and get them to boot up again.  This had happened to me once before sometime earlier this year and luckily I remembered that I had taken some notes on how to fix it so I figured this time I would put together a formal “How To:” guide to have it documented for myself and hopefully to help others facing this issue as well.  So without further adieu…let’s get to it!

.

To start, you will need to power-on the machine and then keep pressing the F8 key to bring up the “Advanced Boot Options” boot menu.  Navigate down to Directory Services Repair Mode enter press Enter to boot you into Safe Mode.

When you reach the login screen, log in with the Local Administrator account since Active Directory Domain Services are obviously unavailable.

Once at the Desktop, open an elevated Command Prompt window.

As a best practice, I feel it is always wise and important to make a backup of the files before doing any modifications.  Since we will be backing up the NTDS directory, create a directory at your preferred location to store the backup files.  I chose to make a backup folder on the root of “C:\” and a sub-directory with the name/date of the directory I am backing up.

md C:\Backup\NTDS_11122017

Then copy everything from the “C:\Windows\NTDS” directory to this new location using xcopy.

xcopy C:\Windows\NTDS\* C:\Backup\NTDS_11122017 /E /Y /V /C /I

Once done, let’s rename any .log file extensions in the NTDS directory to .log.old

cd C:\Windows\NTDS

ren *.log *.log.old

Now, this is where we get to the good stuff!

First, run the following command to repair the database.

esentutl /p "C:\Windows\NTDS\ntds.dit"

This will display the following warning message, click “OK

Let it do its thing and you will see the following once complete.

Now we need to use the NTDS Utility (ntdsutil.exe) to activate the NTDS instance and compact the DB to a new file which will then be used to overwrite the original.  I will be compacting it to a new TEMP directory within the NTDS directory.  The command will automatically create the new directory if it’s not already present.  Enter the following commands.

ntdsutil

activate instance ntds

files

compact to C:\Windows\NTDS\TEMP

If successful, you will be presented with instructions to copy the newly compacted file to the NTDS directory, overwriting the original, and also to delete any .log files in the NTDS directory.  Before we can do that we need to exit out of the ntdsutil.  Type quit twice to exit.

quit

quit

Let’s follow those instructions and also delete the *.log.old files we renamed earlier.

copy "C:\Windows\NTDS\TEMP\ntds.dit" "C:\Windows\NTDS\ntds.dit"

Yes

Ensure you are still in the NTDS directory before entering the following delete commands.

del *.log

del *.log.old

The hard part is now over!  Let’s go ahead and reboot the machine normally.

If all goes well and as expected, your machine will boot successfully and you can log in again with an Active Directory Domain Admin account.

Awesome!  Well, I hope you’ve found this guide useful.  Please feel free to share this and provide me some feedback/comments below.  Thanks for reading!

 

-virtualex-

Create a macOS/OS X VM on VMware ESXi 6.5 & VMware Workstation 12.x

| 12/02/2017 | Tags: ,

Create a macOS/OS X VM on VMware ESXi 6.5 & VMware Workstation 12.5.2 Pro

 

**NOTE: This is completely for experimental purposes and is unsupported by both Apple and VMware**

Running a MacOS/ OS X virtual machine is not anything new and has been supported for quite some time, as long as you are running said VM on a supported hypervisor with Apple Hardware.  But many of the “Non-Apple” users in the world would not be able to take advantage of this without owning some type of Apple Computer.  Luckily, there is an alternative method for running a Mac-based VM on non-apple hardware-based VMware ESXi and/or VMware Workstation for Windows!  In this tutorial, I am going to show you just how to do so.  Please keep in mind that the methods described in this article are not supported nor endorsed by Apple or VMware in any way, so please use at your own risk.

Before we can begin, there are a few tools required to ensure this works flawlessly.

  • macOS Sierra installation media in .iso format (You can use an older OS as well but for this demo, I will be installing macOS Sierra 10.12.3)
    • This media will have to be created as the OS comes as a .app by default.
    • This link has a good tutorial for creating said media.
  • Unlocker Utility
    • Current Stable version 2.0.8 works up to OS X Yosemite on ESXi 6.0 and Workstation 11
    • Version 2.0.9 RC adds support for macOS Sierra on ESXi 6.5 and Workstation 12.x
  • Type 1 Hypervisor (ESXi) or a Type 2 Hypervisor (VMware Workstation)

 

Ready? Here we go!  I’ll start by showing you how to create a macOS Sierra VM on VMware Workstation 12.5.2 Pro…

VMware Workstation 12.5.2 Pro
  • Make sure that VMware Workstation is installed but not running.
  • Extract the contents on the Unlockler 2.0.9RC.
  • Open a command prompt and navigate to the extracted folder
  • Run win-install.cmd.  This will patch your VMware Workstation to unlock the capabilities to run a Mac OS.  It will also download the latest VMware Tools (darwin.iso) for macOS into the extracted directory.

 

  • Launch VMware Workstation and create the shell VM

  

  • When choosing the hardware compatibility, you can optionally change this to version 10 so that you do not need to manually edit the .vmx file after the shell has been created.

 

  • I am going to leave it at version 12 and manually edit the .vmx file afterwards.  Continue creating your shell by following along…

 

  • Now that we have the shell created, we still need to attach the ISO to the VM.  Click on the CD/DVD (SATA) option on the left side in the Devices pane.  Once in the settings, select the ISO image.

  • Next, navigate to the directory that houses the virtual machine’s files.  Edit the .vmx file with your preferred text editor.  I personally love using NotePad++.  Scroll to the bottom of the text and add the following line.  This will enable the VM to boot up.
    • If you opted to change the hardware version to version 10 in the earlier steps, disregard this and move on to the next step.
smc.version = "0"

  • At this point, the VM is ready to be powered on to install macOS Sierra.  I will cover the installation steps further down in this tutorial, but first, let me cover the procedures for enabling this on ESXi.  I will be showing how to do so on ESXi 6.5a (Build 48872370)

VMware ESXi 6.5a (Build 48872370)

  • For ESXi we first need to copy the unlocker utility to a local or shared datastore.  You can accomplish this by using vCenter, ESXi Host UI, or WinSCP.  For simplicity, I opted to use WinSCP and copied the folder into a newly created “Tools” folder on a local datastore.  You can also take this time to upload the .ISO to the local datastore for use later in this tutorial.

  • Now that the files have been copied, open an SSH connection to your ESXi host, and navigate to the unlocker directory.

  • We can then type “ls” to view the contents of the directory.

  • Next, we must make the installation script executable.  I also like to make the uninstallation script executable as well.  Do so by running the following commands.
chmod +x esxi-install.sh

chmod +x esxi-uninstall.sh

  • Typing “ls” again will now display the (2) scripts in green text, indicating that they are now executable.

  • Run the installer script by running the following command
./esxi-install.sh

  • The script will only take a brief moment to run, afterward, a reboot is required.  Once it has finished type
reboot

  • After the ESXi host has restarted, connect to the ESXi Host UI and begin building the shell VM by following along.

  • Now that the shell VM is created, we need to go back into the VM’s settings and attach the .ISO that you uploaded to the datastore in a previous step.

  • At this point, the VM is ready to be powered on to install macOS Sierra!  Unlike with the VMware Workstation instructions, there is no need to change the hardware version to version 10 or manually modify the .vmx file.

  • In the next section, I will cover the installation steps for MacOS Sierra.
Installing macOS Sierra

**The following instructions apply to both an ESXi and Workstation built macOS VM**

  • Start by powering on the virtual machine and opening the Remote Console view

  • Once the VM has booted the .ISO, you will be presented with this screen.  Click next and then go to the taskbar and open Disk Utility.  We need to create a partition to install macOS onto.

  • After the partition has been created, we can actually start the macOS installation.

  • After the VM has rebooted, we can continue the installation/configuration of macOS.

  • Finally, the macOS VM is ready to use!  For the finishing touches, it is recommended to install VMware Tools on this VM.  When we ran the installation script at the start of this procedure, it downloaded a “tools” folder inside of the unlocker tool folder and inside it contains the darwin.iso which is used to install VMware tools.  This should be the latest release of VMware Tools 10.1.0.  Optionally, you can always download the tools from VMware’s website.
  • In order to install the VMware Tools, we first need to eject the mounted install media.  Afterwards, connect the CD/DVD drive to the darwin.iso file.

  • Once the VMware Tools (darwin.iso) is mounted, double-click the “Install VMware Tools” package to begin the installation.  After it completes, reboot the VM for the changes to take effect.

 

Optional Tweaks
Adjusting Screen Resolution
  • By default, the macOS VM will only support (1) resolution natively, 1024 x 768.  

  • If you’d like to change this to support a higher resolution for say…a larger monitor, please download the following file on the macOS VM.  Once the file has been downloaded to the “Downloads” folder in the VM. Open the “Terminal” application and navigate to the folder.  We need to make the script executable, just as we did earlier with the unlocker scripts.
cd Downloads/VMware-Fix-resolution/

chmod +x vmware-resolutionSet

  • Now we can run the script and specify the desired resolution.  In this example, I am going to choose a 1440 x 900 resolution.  Do so by running the following
./vmware-resolutionSet 1440 900

  • On the ESXi-based VM, I did notice that it does not set a resolution higher than 1176 x 885 while in the Remote Console.  But, the VMware Workstation-based VM does indeed set the desired resolution.

 

Disable Beam Synchronization to Improve VM Performance
  • Download the following application and place it in the “Applications” folder.  Double-click it to launch the application.  Afterwards, add it to the user’s “Logon Option” so it runs every time at login.

I hope that you’ve found this information useful.  Please do leave comments below and subscribe to my blog!  Thanks for stopping by!

-virtualex-

Pingbacks:

How To: Create A VMFS5 Datastore On A USB Drive

Create A VMFS5 Datastore On A USB Drive

Ever wondered if it was possible to use a USB Drive as a VMFS5 datastore in VMware vSphere 6.0?  I sure know that I have!  Not that I would like to run any VM’s on said datastore, as I’m sure performance would not be optimal, but instead to test its functionality and use it for storing ESXi host logs for example.  Well, I ran into an issue today where I needed to unmount all of my NFS mounts on ESXi 6.0 U2 in order to recreate some of the volumes before remounting them.  The problem was that I was unable to unmount one of my volumes because it was bound to the ESXi host for scratch logs.  As I didn’t have a spare drive of any sort to attach to my host so that I could reconfigure the location for scratch logs, I began tinkering with the idea of using a small USB drive as a temporary datastore for these logs.

After doing a little research, I came across a post from Florian Grehl aka @virten  showing exactly how to accomplish this so I figured I’d share the process of doing so.  Keep in mind that this should only be used for testing purposes and should not be used in production environments.  This is unsupported by VMware.  Here we go!

Ensure that the USB device is unplugged from the ESXi host then begin by connecting to your ESXi host and stopping the USB arbitrator service.  This service is responsible for allowing USB device passthrough from an ESXi host to a virtual machine, so keep in mind that you will no longer be able to pass through USB devices to VM’s until this is restarted.  (Note: restarting service after creating and mounting USB datastore will break connectivity and recognition of the USB datastore).   To stop the service, run the following command:

/etc/init.d/usbarbitrator stop

2016-08-11_17-12-192016-08-11_17-12-35

Optionally, if you’d like to permanently disable the service so it persists thru reboots, run the following command:

chkconfig usbarbitrator off

Plug the USB drive into your ESXi host.  For the purposes of this tutorial, I am using a small Lexar 8GB USB device.  If you navigate to the storage devices section on your host, you should now see the connected USB device is recognized by the hypervisor.  Make note of the device identifier number (mpx.vmhbaXX) for this device.

vSphere Client:

 2016-08-14_16-53-34

vSphere Web Client:

2016-08-14_17-02-22

vSphere HTML5 Web Client:

2016-08-14_17-02-44

You can also list the device information to determine the identifier by running the following command:

ls /dev/disks/

2016-08-11_17-13-09

As we can see, my identifier is mpx.vmhba40:C0:T0:L0 for this device which also matches the identifier from the GUI pics above.  Note: The other USB (mpx.vmhba32:C0:T0:L0) is a separate USB where ESXi is installed on.

2016-08-14_16-48-33

Next, we need to create a GPT (GUID Partition Table) label on the device.  To do so, run the following command using the correct identifier for the drive.  In my case, I will run with mpx.vmhba40 for all of the following commands.  Be sure to change this to your correct ID.

partedUtil mklabel /dev/disks/mpx.vmhba40\:C0\:T0\:L0 gpt

2016-08-14_17-04-20

Now run the following command to get the partition table information.

partedUtil getptbl /dev/disks/mpx.vmhba40\:C0\:T0\:L0

2016-08-14_17-05-36

This returned the following output for me…

gpt

973 255 63 15634432

2016-08-14_17-06-01

Next, we need to create a partition in which you will need to know the start sector and end sector which all depend on the size of the device drive and GUID.  As an FYI…

  • The start sector is always 2048
  • The GUID for VMFS is always AA31E02A400F11DB9590000C2911D1B8
  • The end sector is calculated using the values obtained by running the previous command.
    • Formula: 973 x 255 x 63 – 1 = 15631244

2016-08-11_17-33-01

We can also run the following command to calculate the end sector value.  This should return an identical value that matches the previous calculation. 

eval expr $(partedUtil getptbl /dev/disks/mpx.vmhba40\:C0\:T0\:L0 | tail -1 | awk '{print $1 " \\* " $2 " \\* " $3}') - 1

2016-08-14_17-10-052016-08-14_17-10-45

If everything has gone smoothly so far, you should be ready to create the VMFS partition.  Run the following command, ensuring to replace the identifier and end sector values with your own.

partedUtil setptbl /dev/disks/mpx.vmhba40\:C0\:T0\:L0 gpt "1 2048 15631244 AA31E02A400F11DB9590000C2911D1B8 0"

2016-08-14_17-12-022016-08-14_17-12-42

Lastly, we need to format the partition with VMFS using vmkfstools.  Do so by running the following (Note: “” in the command below can be any name you like so feel free to use a different name for your datastore):

vmkfstools -C vmfs5 -S USB_Datastore /dev/disks/mpx.vmhba40\:C0\:T0\:L0:1

2016-08-14_17-13-58

Sit tight…wait about one minute…and…voila!  

2016-08-14_17-16-35

After a quick rescan/refresh you should now have and see your mounted VMFS5 USB Datastore!

vSphere Client:

2016-08-14_17-17-40

vSphere Web Client:

2016-08-14_17-18-21

vSphere HTML5 Web Client:

2016-08-14_17-18-52

After I changed the “Syslog” configuration for my scratch logs to use this new datastore, I was finally able to unmount my NFS datastores.  I hope this helps so please feel free to comment below.

Shoutout to Florian Grehl for his wonderful post!

Cheers!

-virtualex-

Pingbacks:

USB Devices as VMFS Datastore in vSphere ESXi 6.0

PernixData FVP Freedom Woes With Missing Supermicro System UUID

PernixData FVP Freedom Woes With Missing System UUID

Recently, I’ve been wanting to give PernixData FVP Freedom a run in my HomeLab Datacenter to better familiarize myself with the product and see how much of a performance improvement I’d get if any at all.  I’ve heard from so many people how much they love the product so I figured “why not”?

For those who are not familiar with PernixData FVP, it accelerates Storage and Virtual Machines by moving read and write operations to the server tier, instead of the storage tier, using Flash or RAM to ensure the fastest VM performance.  This, in turn, reduces VM latency by a claimed 10x and overall SAN utilization by over 80%.

 To start off, I visited the PernixData website and went ahead to register for the free FVP Freedom product.  A short time later  I received an email and obtained my download and license key information, along with all the documentation needed to get it up and running.  I installed the ESXi host VIBs and opted to deploy the .ova appliance version so that the deployment would be a piece of cake.  Once I got the product up and running, I logged into the Management appliance and attempted to configure my cluster and add resources, but for some reason, none of my hosts’ were showing up.  I kept getting the “No PernixData compatible hosts have been detected in the cluster“, and only (1) of my (5) hosts was detected but it was not part of the cluster that I was configuring yet.

This is where I ran into a snag that took quite a bit of time to research and find a fix.  Luckily, another blogger by the moniker “vWilmo” who’d experienced this same issue and described how to fix it, so I figured I’d write a similar entry for my own reference, and to help others who may frequent my blog.  I will also be sharing his link at the bottom of this page.

Ultimately, the issue stemmed from the fact that Supermicro did not generate any system UUIDs for my boards and FVP needs them to detect the hosts to use as resources.  KB 1006250 references the situation of an ESXi host not having a unique UUID but did not offer a solution other than to contact the manufacturer (which I did via email and am still awaiting a reply).  To confirm this, I ran a script I found online called Get-VMHostUUID to pull the UUID’s from all of my hosts connected to my vCenter server.  Upon review, it only returned a value for my “white box” host, and returned all “zero” values for my remaining (4) Supermicro systems.  I also ran prnxcli via SSH connection to my host which returned an error as well.

 2016-08-05_15-10-50 2016-08-05_19-20-02

As my Supermicro systems run an AMI (American Megatrends) BIOS, there is a BIOS utility that can be used to generate a new UUID for the system which can be found here.  Download this file and extract the contents.  The file we need to use is named AMIDEDOS.exe, so I took this file and placed it on a DOS formatted USB drive that I had created with Rufus back when I needed to flash my BIOS and upgrade my Intel NIC firmware.

 2016-08-05_19-39-09

Insert and boot into the USB, then navigate to the directory that houses the file mentioned above. 

 2016-08-05_20-18-14

Enter the following command:

AMIDEDOS.exe /su auto

 2016-08-05_20-18-25

If successful, this will generate a new system UUID for you and you should then receive an output like this:

 2016-08-05_20-19-25

Reboot your host, SSH into it and run the prnxcli command.  If it runs successfully you should see an output like this:

 2016-08-05_20-30-04

After I completed this process on all of my (4) impacted hosts, I ran the Get-VMHostUUID script again and was happy to see that I now had a valid UUID for each host which match each prnxcli output.

 2016-08-05_20-52-42

Upon logging into the vCenter Web Client, I noticed that there is now a PernixData plugin icon in the vCenter Web Client interface which can be selected to launch the PernixData Management Console or access the FVP dashboard from within the Web Client.

 2016-08-06_11-02-462016-08-06_11-03-07

Lastly, I logged into the PernixData FVP Management console again, and I was now able to create my cluster and assist hosts as resources.  The only caveat is that there is a single-cluster limitation with the FVP Freedom version license, so if have all of your hosts in a single cluster then you are good.  Unfortunately for me, I have (3) clusters so I need to pick which one I want to use FVP with.  I decided to use my Management Cluster since that houses the majority of my VMs at the moment.

 2016-08-05_20-54-12

After letting it work its magic for a few hours, I noticed that the VM latency had reduced drastically to an average ~ +/- 2.0 ms and overall performance was great!  I must say that I am really impressed, satisfied, and glad that I gave this program a shot!

2016-08-06_16-18-52 2016-08-06_16-19-00 2016-08-06_16-19-25

Well,  I hope that you have found this useful, thanks for stopping by!

Special thanks to Geoff Wilmington aka @vWilmo for helping me to solve this as I am lucky I found your post.  Another shout out to Andy Daniel aka @vNephologist from PernixData for his willingness to communicate with and try to assist me with this problem.

Pingbacks:

Installing phpIPAM on Ubuntu 16.04

| 08/05/2016 | Tags: , , ,

Installing phpIPAM on Ubuntu 16.04

I have been thinking, for a while now, about deploying an IP Address Management (IPAM) system in my Home Lab environment to keep track of my assigned addresses across my various VLANs.  In looking for the right solution, I came across many different choices, from Infloblox to Microsoft’s very own IPAM feature within Microsoft Windows Server 2012 R2.  I read many articles, and kept seeing rave reviews and tons of praise about phpIPAM and that it was simple to install and get it running (at least that’s how it’s advertised).  I went to the phpIPAM website to lookup more information and noticed they have an installation guide available.  Upon observing it, I quickly became disappointed at the lack of detailed instructions to actually deploy it on a system.  I guess they assume everyone has adequate knowledge of Linux operating systems, but myself personally, I’m still pretty novice at Linux and am looking to become more proficient with it.  I figured this is a good opportunity to get some hands-on Linux experience since I already knew how to, at the ver least, install an OS!  

So like any normal “noob” at this, I started consulting “Mr. Google” searching for easy to follow guides on installing phpIPAM and stumbled across one that made it all look very simple (I will share all links at the end of this post).  I spun up an Ubuntu VM and followed the guide precisely, step-by-step, and was disappointed when I could not access the phpIPAM installation web page.  After more searching, I stumbled on even more articles and each one used different methods to get it to work properly.  I thought to myself, “there has to be an easier way to get this working right?”  

So after countless hours of trial and error, taking little tid-bits from several references, I managed to finally get phpIPAM successfully deployed and working on Ubuntu 16.04.  At this point, I figured it would be a great idea to document my installation steps so that I can share my experience with all of you and hope that this guide will be of some value.  Let’s get to it!

Prerequisites:

  • Ubuntu Server 16.04 64-bit
    • Linux, Apache, MySQL, PHP (LAMP) configuration
      • apache2
      • MariaDB (MySQL replacement) or MySQL
      • php7.0 + modules
        • libapache2-mod-php7.0
        • php7.0-cli
        • php7.0-curl (optional)
        • php7.0-gmp
        • php7.0-json
        • php7.0-ldap
        • php7.0-mcrypt (optional, for phpmyadmin)
        • php7.0-mysql
        • php7.0-xml
      • php-pear
      • php-apcu (to speed-up php)
      • phpmyadmin (optional)
        • php-mbstring
        • php-gettext
  • phpIPAM 
  • Web Browser

For the purposes of this guide, I will not cover the actual OS installation steps and am confident that you can easily get an OS installed and running.

I will first configure the server with a LAMP configuration.  I began with a “vanilla” or shall I say “minimal” installation of Ubuntu Server 16.04 64-bit and I will be running all of the commands as the root user.  Having had Linux installed and my server ready means that the “L” part of the “LAMP” configuration is already done.  FYI – features that define a LAMP configuration and be installed in any order.

 2016-05-08_14-04-29

Log in with your local account then enter:

sudo su

 2016-05-08_14-07-02

First, I updated apt-get by running:

apt-get update

 2016-05-08_14-24-48

Once completed, we will move on to the “M” phase of the configuration and install the MySQL database.  I chose to use MariaDB instead of MySQL as I’ve read there are many performance improvements over MySQL.

To install MariaDB, run the following:

apt-get -y install mariadb-server mariadb-client wget

 2016-05-08_14-32-37

When the components have finished installing, we can set a root password for MariaDB by entering the following:

mysql_secure_installation

2016-05-08_14-36-52

You will then be asked the following series of questions:

  • Enter current password for root (enter for none): <– press enter
  • Set root password? [Y/n] <– y
  • New password: <– Enter the new MariaDB root password here
  • Re-enter new password: <– Repeat the password
  • Remove anonymous users? [Y/n] <– y
  • Disallow root login remotely? [Y/n] <– y
  • Remove test database and access to it? [Y/n] <–y
  • Reload privilege tables now? [Y/n] <– y

Next, test the login to MariaDB by entering the following:

mysql -u root -p

Enter the root users password that you previously configured.  If successful, you should see a screen similar to this:

2016-05-08_14-41-05

To exit MariaDB, type quit and press Enter

 

Now, I have just completed the “M” phase of our LAMP configuration and can move on to the “A” phase and install Apache2.

To install apache2, simply run the following command:

apt-get -y install apache2

2016-05-08_14-45-15

When that has finished, test apache to make sure it works by opening a web browser and browse to the VM’s IP or FQDN (http://ipaddress or http://FQDN).  I will use Google Chrome and access it via hostname (FQDN) since I’ve created the DNS record already.

2016-05-08_14-51-32

Success!  This now completes the “A” phase of the LAMP configuration and I can now move on to the final “P” phase by installing PHP7.0

I will begin by simply installing php7.0 and the Apache2 php module.  To do this, enter the following:

apt-get -y install php7.0 libapache2-mod-php7.0

 

2016-05-08_14-57-02

When that finishes, restart apache by running:

systemctl restart apache2

To test that PHP7.0 installed successfully, I will make an info.php file in the web server directory by running the following:

vim /var/www/html/info.php

2016-05-08_15-03-21

You can also use nano instead of vi or vim.  Then I add the following lines by first pressing “I” for “Insert

<?php
phpinfo();
?>

2016-05-08_15-07-54

Save the file by pressing “esc” followed by “Shift :” then type the letters “wq” and press Enter.  Next, run the following command to change ownership of the file:

chown www-data:www-data /var/www/html/info.php

2016-05-08_15-08-42

Now, I can test to ensure PHP is running under Apache2 by opening a web browser and navigating to the IP or FQDN /info.php link (http://ipaddress/info.php or http://FQDN/info.php).  If successful, you should see a page like this.

2016-05-08_15-11-57

Perfect!  Now I will add some additional php modules that will be needed for phpIPAM to work along with some others to add support for MariaDB.  I’ll start with the following command to list the available php7.0 modules.

apt-cache search php7.0

I’ll then install the necessary php modules that are needed by phpIPAM to add support for the database (MariaDB) by entering the following (some of them may have already been installed via php 7.0 installation earlier) :

apt-get -y install php7.0-cli php7.0-curl php7.0-gmp php7.0-json php7.0-ldap php7.0-mcrypt php7.0-mysql php7.0-xml php-pear

2016-05-08_15-24-36

Restart apache2 by running:

systemctl restart apache2

Point your web browser to the /info.php page again and reload it.  If all is well, you should see the new modules installed along with “mysqli“.  Now I know that MariaDB is supported in my php 7.0 installation

2016-05-08_15-28-47

At this point, I have finished the “P” phase in the LAMP configuration and can move on to installing phpIPAM.  But before doing that, I want to add a few extra modules to my PHP configuration to make it run faster via APCU, and to add support for PHPMyAdmin and SSL.

Start by entering the following to speed up PHP

apt-get -y install php-apcu

Then restart apache2 with

systemctl restart apache2

2016-05-08_15-34-20

If you want to ensure it’s installed and running, again load the /info.php site in your web browser and look for the following

2016-05-08_15-34-44

If you’d like, and for security concerns, you can delete the info.php at this time by running 

rm -f /var/www/html/info.php

Now, I am going to enable SSL so that I have (https://) access to my web server as well.  Do this by running the following:

a2enmod ssl
a2ensite default-ssl

Then restart apache2 again with

systemctl restart apache2

2016-05-08_15-39-22

Test it by launching your apache web server link in your web browser using (https://ipaddress or https://FQDN)

2016-05-08_15-41-262016-05-08_15-41-53

The last thing to officially complete my “P” phase of my LAMP configuration is to install phpMyAdmin to allow me to manage my database easily from a web browser.  To install, enter:

apt-get -y install phpmyadmin php-mbstring php-gettext

2016-05-08_15-44-27

You will be presented with the following screen.  Select the “apache2” option by pressing the “space bar” on the highlighted object, and press Enter.

 2016-05-08_15-46-14

Next, you will be presented with this screen.  Select “Yes” and press Enter.

 2016-05-08_15-48-01

On this next screen, just press Enter as a random password will be generated for the phpmyadmin account

 2016-05-08_15-49-29

Next, I need to explicitly enable “crypt” and “mbstring” or the web page will not load properly.  Do this by running the following:

phpenmod mcrypt
phpenmod mbstring

Then, restart apache 2 again with:

systemctl restart apache2

2016-05-08_15-55-34

And the final command to finish the installation is to run the following:

echo "update user set plugin='' where User='root'; flush privileges;" | mysql --defaults-file=/etc/mysql/debian.cnf mysql

2016-05-08_15-57-37

Test phpMyAdmin by navigating to the web server /phpmyadmin page (http(s)://ipaddress/phpmyadmin or http(s)://FQDN/phpmyadmin).  The login is root and the database password you created earlier.

2016-05-08_16-00-27

Excellent!  Now, my LAMP configuration is complete and I can start with the phpIPAM configurations and installation.

Since I’ve already installed all of the required modules, the next thing to do is download the phpipam file and then extracting it to the web servers directory (/var/www/html).  Start by changing over to the /tmp directory

cd /tmp

Next, download phpipam.  I am using the latest version which, at the time of this writing, is phpipam-1.2.1.tar

wget https://sourceforge.net/projects/phpipam/files/phpipam-1.2.1.tar

2016-05-08_16-10-20 2016-05-08_16-10-48

Extract the file to the web server directory:

tar -xvf phpipam-1.2.1.tar -C /var/www/html

2016-05-08_16-19-56

The files have been extracted to a new folder at /var/www/html/phpipam.  Now we need to edit the config.php file in that directory.  But there is no such file so we have to create it by copying the default config.dist.php file to config.php.  Do this by running:

cp /var/www/html/phpipam/config.dist.php /var/www/html/phpipam/config.php

2016-05-08_16-20-12

Now we can edit this file with vim, vi, or nano:

vim /var/www/html/phpipam/config.php

2016-05-08_16-21-03

By default, the file will look like this and I will need to change the following selections:

2016-05-08_16-22-09 2016-05-08_16-22-56

I will make the following changes before saving and exiting the file:

2016-05-08_16-25-16 2016-05-08_16-25-53

Since I have defined the ‘BASE’, it also explicitly said to change this in the .htaccess file.  To open and edit this file, enter:

vim /var/www/html/phpipam/.htaccess

2016-05-08_16-29-01

By default, the file looks like this and I will be changing the following line

2016-05-08_16-29-18

To look like this before saving and exiting the file:

2016-05-08_16-30-03

Next, I will edit the default apache web file (000-default.conf) by entering:

vim /etc/apache2/sites-available/000-default.conf

2016-05-08_16-35-38

By default it looks like this:

2016-05-08_16-35-55

I will be adding the following lines before saving and exiting the file.  This will also allow you enable “Prettify Links” while using an HTTP connection.

<Directory "/var/www/html">
     Options FollowSymLinks
     AllowOverride all
     Require all granted
     Order allow,deny
     Allow from all
</Directory>

If you would like to enable “Prettify Links” while using an HTTPS connection, you need to edit the default apache https web file (default-ssl.conf) by entering:

vim /etc/apache2/sites-available/default-ssl.conf

Look for the same “Directory” area as in the previous step (scroll about halfway down).  By default it will look like this:

Change the entry to the following:

<Directory "/var/www/html">
     Options FollowSymLinks
     AllowOverride all
     Require all granted
     Order allow,deny
     Allow from all
     SSLOptions +StdEnvVars
</Directory>

Now I have to restart the apache2 service again but before doing so, I need to enable “mod_rewrite” by first entering the following and then restarting apache2 as described earlier:

a2enmod rewrite

systemctl restart apache2

2016-05-08_16-40-41

If all is successful, you can now open your web browser and navigate to your web server’s /phpipam URL (http(s)://ipaddress/phpipam or http(s)://FQDN/phpipam) and be presented with the following:

2016-05-08_16-42-29

This is awesome!!  Now, I can select “Automatic database installation“, enter the “root” username and password and click “Install phpipam database

2016-05-08_16-44-07

After a few brief moments, you should see the “Database installed successfully” and you can press “Continue” to log in.

2016-05-08_16-45-56

Enter a password to set the “Admin Password” then click “Save Settings

2016-05-08_16-47-47

After another brief few seconds, you will see a “Settings updated, installation complete!” message and you can click “Proceed to login

2016-05-08_16-49-08

At this point, you will be presented with the phpipam login screen, where you can enter “Admin” and the password you’ve created for the account, then begin configuring your subnets, etc within the dashboard!  I will not go over the configurations in this post as I still need to poke around it a bit, but I’m sure you will find it pretty easy and self-explanatory.

2016-05-08_16-51-32 2016-05-08_16-51-54

Well, that is it!  I hope that you’ve all found this guide to be useful and I welcome any feedback.  Please feel free to rate this post above and share!

**Update**

  • If you would like to check the status by running a ping check, resolve IP addresses, and add the ability to automatically scan for new hosts to automatically add to phpIPAM every 15 minutes, you must add the following cronjob…
crontab -e

Then enter the following at the end of the file…

*/15 * * * * /usr/bin/php -c /etc/php/7.0/cli/php.ini /var/www/html/phpipam/functions/scripts/pingCheck.php

*/15 * * * * /usr/bin/php -c /etc/php/7.0/cli/php.ini /var/www/html/phpipam/functions/scripts/resolveIPaddresses.php

*/15 * * * * /usr/bin/php -c /etc/php/7.0/cli/php.ini /var/www/html/phpipam/functions/scripts/discoveryCheck.php

(Optional)

Instead of running a Discovery Check at the specified 15-minute interval, I also added a rule to do a check every day at 11 AM (see code below).  Please note that I currently have the rule disabled by adding a “#” at the beginning of the line, but if I ever do decide to use that instead of the 15-minute check, I can remove the hashtag and place it in front of the 15-minute check rule.

0 11 * * * /usr/bin/php -c /etc/php/7.0/cli/php.ini /var/www/html/phpipam/functions/scripts/discoveryCheck.php

  • If you’d like to force phpIPAM to always use HTTPS, edit the .htaccess file again:
vim /var/www/html/phpipam/.htaccess

Enter the following:

RewriteCond %{HTTPS} !=on

RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

Cheers!

-virtualex-

Ping backs: