Datacenter Journey on Datacenter Journey

Add SSH Keys GitHub Access on MacOS

Tue, 25 May 2021 16:20:25 -0700

When trying to update the website hosted in GitHub from a different laptop there was an issue with the submodules not being updated on the new laptop correctly. After searching multiple sites to try and correct this issue I was finally able to figure out what the problem was. The public folder wasn’t being properly recognized as a submodule within my Github repository when cloning it to the new laptop. To correct this there were a few things that needed to happen due to the new security changes deprecating the use of passwords for basic authentication with GitHub. I needed to add the SSH Keys from the new laptop to GitHub to then be able to add the submodule. For this post I will focus on creating, adding and testing the SSH keys for GitHub access and in the next post I will cover the error and steps for properly adding a git submodule.

Check for SSH Keys

You will want to open up your terminal and enter the following command to check if you have any existing SSH keys on your Mac.

ls -al ~/.ssh

You are looking for any of the following file names if they were created with the defaults.

id_rsa.pub
id_ecdsa.pub
id_ed25519.pub

If they are not present move on to the next section on Creating SSH Keys, if they are present skip to either the Add SSH Keys to ssh-agent or Add SSH Keys to GitHub.

Creating SSH Keys

To generate new SSH Keys run the command below making sure to replace the email address with the one used to access your GitHub account.

ssh-keygen -t ed25519 -C "emailaddress@company.com"

You will then be prompted to “Enter a file in which to save the key,” go ahead and press ‘Enter’ to accept the default location. Next, you will be prompted for a passphrase. You can either press ‘Enter’ to leave it blank or type in a passphrase. You will get a second prompt to confirm your previous entry.

Add SSH keys to ssh-agent

We need to start the ssh-agent in the background to proceed by running the following command.

eval "$(ssh-agent -s)"

This will generate a message with the agent process id. If we are doing this on macOS Sierra 10.12.2 or later, then we will need to create or modify the ~/.ssh/config file to load the keys into the ssh-agent. You can also choose whether or not to store the passphrases in your keychain. To check if the file already exists you will use the command below.

open ~/.ssh/config

If the file opens continue on to the next part otherwise to create the file you will run the touch command to create the config file.

touch ~/.ssh/config

Now that we have the config file open for editing you will add the information below into the file and save it. Make sure to the correct Identity file name and location, if you followed this guide the file is the same one we created under the “Creating SSH Keys” portion. If you chose to not enter a passphrase when creating the SSH keys then make sure to remove the line UseKeychain yes before saving the file. This will make sure that it’s not added to your Keychain on the Mac you are working on.

Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_ed25519

Next, we add your SSH private key to the ssh-agent and store your passphrase in the keychain (if you chose to complete that step.) If you created your key with a different name, make sure to replace id_ed25519 in the command with the name of your private key file.

Adding SSH Keys to GitHub account

First, we need to copy the newly created SSH key to the clipboard. to do this you will run the command below. Make sure to change the name of the .pub file if you created a different one.

pbcopy < ~/.ssh/id_ed25519.pub

If that pbcopy command doesn’t work then you can go to the ~/.ssh folder and open the file with a text editor or vi to copy the contents to the clipboard.

Now you will need to log into your GitHub account online. In the upper right hand corner click on your profile picture and go down to select “Settings”.

On the next page on the left hand side you will go to “SSH and GPG keys”. On that page you will then click on “New SSH Key”

You will need to give your new SSH key a Title to identify it like “Personal MacAroni Pro” so that it’s descriptive and easy to identify what machine this is for. Paste the key contents from your clipboard into the Key section and then click “Add SSH key”. You might be prompted to enter your GitHub password and click “Confirm password”.

Test SSH Connection (Optional)

If you want to test the connection to make sure your SSH key was added successfully go to your terminal and type the following command

ssh -T git@github.com

You should get a warning similar to the one listed below.

The authenticity of host 'github.com (IP ADDRESS)' can't be established.
 RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
 Are you sure you want to continue connecting (yes/no)?

You can verify that the fingerprint matches GitHub’s public key fingerprints listed below and then type yes

SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8 (RSA)
 SHA256:br9IjFspm1vxR3iA35FWE+4VTyz1hYVLIE2t1/CeyWQ (DSA)

If everything is successful you will get a message like the one below with your GitHub username instead of the word username.

Hi username! You've successfully authenticated, but GitHub does not 
 provide shell access.

If Prompted for Username & Password (Optional)

If you are prompted for a username and password then the chances are that you need to update the URL of orgin to use SSH instead of HTTPS. You will probably notice a message similar to the one below.

Username for 'https://github.com':

To not be prompted for the credentials you will run the following command replacing username with your username and repository with the name of your repository.

git remote set-url origin git@github.com:username/repository.git

Install Specific Version Hugo MacOS

Thu, 06 May 2021 22:31:25 -0700

I ran into a display formatting issue when trying to work on my blog from a different laptop. The problem was that when I initially built the site using Github and Hugo it was with an older version of Hugo. The theme being used hasn’t been updated in a while and probably isn’t compatible with the newer version of Hugo due to a change that was made somewhere along the line and never tested. Luckily I still have the original laptop I was using to build the site and was able to verify what version of Hugo is installed and that the formatting is displaying correctly. I then had to try and find out how to get that version installed on the new laptop since I already had cloned the blog repository.

The easiest way to install the latest version of Hugo on macOS is to use Homebrew and run the command below. The problem was that this installed v0.83.1 at the time of this writing which is much newer than what I originally installed almost two years ago.

brew install hugo

If you want to install a specific older version of Hugo then you need to go to the release page and search for the version you want to install.

https://github.com/gohugoio/hugo/releases

For this document, we will be installing version 0.55.6 by searching for that version and then clicking on the version number link. You will then get a list of available installations for the different operating systems. Here we are installing the x64 version for macOS and will download the tarball to perform the installation which is named as follows hugo_0.55.6_macOS-64bit.tar.gz.

It’s usually a good idea to verify that the tarball download wasn’t corrupted by running the command below to verify.

tar tvf ~/Downloads/hugo_0.55.6_macOS-64bit.tar

There are a few tasks you will want to perform to make running hugo quicker and easier. Run the following command to determine whether your default shell is bash or zsh.

echo $SHELL

Depending on which shell you are running you will need to edit the profile using one of the commands below.

vi ~/.bash_profile
 #or
 vi ~/.zprofile

Using the vi editor you can then hit i to enter insert mode and then you will add a line to append the following information to the profile.

export PATH=$PATH:$HOME/bin

After you have added the information you will hit the esc key to switch back to command mode and type :wq to save the changes and exit the file. To have the information available for our current session you will need to source the file using one of the following commands based on your default shell.

source ~/.bash_profile
 #or
 source ~/.zprofile

To install the specific version of hugo in the local bin directory. First, check to see if you already have a bin directory by running the command to list its contents.

ls ~/bin

If you get a message that there is no such directory then you will need to create it with the following command.

mkdir ~/bin

Now we can extract the tarball to the local user bin directory using the following commands. First, you will want to change your working directory and then extract the tarball. Make sure to replace the path with the location of where you have the tarball downloaded.

cd ~/bin
 tar -xvzf ~/Downloads/hugo_0.55.6_macOS-64bit.tar

Check to see if the tarball was extracted and installed correctly running the two commands below. The first command will verify that hugo is in the local bin directory and the second command verifies that the version you installed runs.

# checks the path
 which hugo

 # displays the version
 hugo version

If you are going to be installing multiple versions I recommend renaming the hugo file have the version number after it. This will allow you to specify which version of Hugo you want to have running when working on your site. The command below shows you how to rename the file to include the version number. Make sure to replace ‘martinez’ with your username.

mv /Users/martinez/bin/hugo /Users/martinez/bin/hugo55.6

Now to run any of the hugo commands you will use the new file name for example to check the path and version.

# check the path
 which hugo55.6

 #display the version
 hugo55.6 version

Install VCSA Certificates MacOS

Wed, 20 May 2020 20:06:43 -0700

We’ve all come across the pesky invalid certificate error when trying to access vCenter, stating that your connection is not private. Many of us click through and “Accept the risk” because we know that the site we are accessing is legitimate. However, there are times where not having a trusted website can cause an issue and prevent specific actions. For example, without a trusted certificate, it blocks access to upload files to datastores. The workaround would be to log in directly to an ESXi host and upload the data that way. That’s too much work, in my opinion, which is why I would instead install a trusted certificate and simplify things.

To install the certificate and have the vCenter address show as a secure site, you need to head to the FQDN of your vCenter. For example, in my environment, it would be https://mzvmvcs001.martinez.local. Then in the bottom right-hand corner, you will find a link named “Download trusted root CA certificates.” You will need to click on the link and download the certificate bundle in .zip form. If you are using Chrome, you will need to right-click and select “Save Link As…”

Save the download.zip file to the location of your choice and then open the file to extract the contents. You will find the extracted data in a folder named certs with three sub-folders named lin, mac, and win. Next, open up the Keychain Access application to install the newly downloaded certificate. Browse to the win folder and select the first file that ends in .0.crt. Right-click on the file and select “Open With” and choose Keychain Access. A pop up will appear with the title “Add Certificates.” In the bottom right corner will be a drop-down to select which Keychain to add the certificate. You will want to add the certificate to “System” and click on “Add,” you will be prompted to either use your fingerprint for Touch ID or enter your password to complete the process.

In Keychain Access, go to “System” on the right-hand side and then look for a certificate named “CA” with an X on the image to the left of the name. To install either double-click on the certificate or right-click it and select “Get Info.” It will display that the certificate is not trusted, and you might have to expand “Trust,” by clicking the carat. Hit the drop-down next to “When using this certificate” and select “Always Trust.” You will receive a prompt to use Touch ID or Use Password to make the change. After a few seconds, the icon next to the image should change to a + sign. This change means that the certificate is marked as trusted for all users.

If you try and access the VCSA at this point, you will no longer get a message that the site is untrusted. If you click on the lock icon next to the FQDN of your vCenter in the address bar, you will see that that site is now secure.

Subscribe via my newsletter or RSS feed

Installing PowerShell Core Windows

Thu, 20 Feb 2020 20:12:02 -0800

I previously wrote an article on how to install PowerShell Core on macOS. I recently needed to install PowerShell Core on a Windows machine and found the process less than ideal compared to macOS. I was able to find a simpler way to install and upgrade PowerShell Core that did not involve me having to open a web browser to download the MSI installer. Below is the command to run in PowerShell and have the MSI downloaded. I have also included the screenshots for the installation.

iex "& { $(irm https://aka.ms/install-powershell.ps1) } -UseMSI"

Once you run the command, the MSI installer is downloaded and starts the installation wizard. You need to click Next to continue.

The next screen shows you the location of the default installation directory. You can either choose to leave the default or change the folder path. Then click Next.

The next screen allows you to select the optional actions to include with the installation. By default, it selects Add PowerShell to Path Environment Variable and Register Windows Event Logging Manifest. In the screenshot, I also decided to include Enable PowerShell Remoting and Add ‘Open here’ context menus to Explorer. Then click Next, followed by Install to start the installation process.

It takes a little bit to complete the installation, after which you can select the option to Launch PowerShell Core and then click Finish.

Once you do that, you arrive back at the PowerShell window. You can see information about the version of PowerShell Core downloaded along with the link.

Subscribe via my newsletter or RSS feed

Change MacOS Screenshot Defaults

Tue, 18 Feb 2020 13:55:10 -0800

I’ve been taking lots of screenshots lately for blog posts and find myself constantly updating the files and locations. I’m not a fan of having to repeatedly rename multiple files or move them into the appropriate folder locations to keep them organized. The process is time-consuming, and since I don’t always write the blog post after performing the actions, it can lead to confusion. I did some searching and found that it’s straightforward to change the default location and name of screenshot files take with a Mac. Rather than have to look for this information every time I need to do it decided it would be helpful to me and possibly others to write a quick post on the steps.

Before changing the default location from the Desktop to a location of your choosing, the folder must exist before making the change. Also, be aware that if you delete or move the new screenshots folder, it can cause issues. If you are changing just the default name and not the folder location, then you don’t have to worry about folders.

Changing the default file name of screenshots

Open Terminal and type the commands listed below. Make sure to replace the text between the quotes “ ” with the new default name you want to assign. Once that is completed, you must restart the SystemUIServer process by running the killall command. Now any new screenshots taken are saved with the new default name prefix instead of “Screen Shot.”

defaults write com.apple.screencapture name "HomeLab"
 killall SystemUIServer

Changing the default file location of screenshots

Remember that the directory location must exist before changing the default path as the command does not create it for you. If Terminal is not already open, you need to open it and run the subsequent commands. Make sure to change the directory path after “location” with the folder you want to set.

defaults write com.apple.screencapture location ~/Documents/Blog/macOS

First Promotion - Computer Operator

Mon, 10 Feb 2020 18:54:20 -0700

My first official promotion was not everything that I thought it would be. The position was not very technical; in my opinion, most of the work was operational and related to the AS/400 system. During my training, it became very apparent to me that I would not want to stay in the role very long. However, I did realize that being on the day shift would allow me to make new contacts within the organization and showcase my work ethic and ability to learn quickly.

My schedule was Thursday through Monday since there was one other computer operator who worked Monday through Friday. The duties of the role were to answer AS/400 system messages, swap out backup tapes, and assist the Helpdesk staff with issues. It does not sound like much work to do, and honestly, the reason is that it was not. That has its drawbacks and benefits for someone like me. The disadvantages were that there was not much work to keep me busy, especially during the weekends. The advantages I found, became apparent after weeks on the job, which was time to study and learn skills to advance. The other benefit was being able to talk with and shadow coworkers in different positions during my weekday shift while there was double coverage.

I was able to meet and establish a relationship with some of the server administrators, network engineers, and desktop technicians. If there is one thing that you take away from this post is how important it is to build relationships and learn from others. This skill and I believe it is a skill, is one that should be continually worked on, improved, and evolved for different situations. Relationship building may come naturally, so some and seem very difficult to others. However, there is no denying the benefits that this can have on you and your career.

I was able to expand my world and knowledge just by speaking with coworkers and asking plenty of questions. I am incredibly grateful for those people taking the time to sit with me and answer all of the questions I had for them. Not only did it help me to learn more about how to support the applications, but it expanded my view of IT. All of a sudden, I became more aware of other areas of IT, of which I had no previous exposure to and piqued my interest. It was at this time that I became interested in both networking and servers, which aspired to move into an admin role in one of those two areas.

As much as I wanted to jump into one of the admin roles, I knew that there was still so much that I needed to learn. I picked up a few books that were recommended to me and tried to get up to speed. It didn’t take long for me to realize that most of what would be required was not something I was going to pick up quickly. I began to ask different questions, like how people came into the roles that they held, what did they recommend I do, or learn to get to where they are? Many mentioned they had previously been desktop technicians or had been doing server/network for many years prior.

Armed with this new information, I went to talk to the desktop technician manager about a position with his team. He mentioned that they would be hiring a new technician soon. So, I asked him what I would need to know or have to be considered a potential candidate for a chance to earn the position. He told me that he would be looking for someone that has or could obtain the CompTIA A+ certification, possessed technical knowledge, troubleshooting skills, and was an excellent communicator. Another question I asked was what the job would consist of on a day to day basis. My goal was to know what to prepare during the interview and the role.

Now that I had an idea of what it might take to get a technician position, it was time to start preparing if my application was accepted and got asked to interview for the job. I purchased a CompTIA A+ certification book to begin reading and plan to take the two exams required to obtain my A+ certification. I read the entire book, took the practice exams, and tried to prepare as much as possible to get the certification. Before I scheduled to take the test, the PC Technician position posted, and I submitted my application. Unlike the Computer Operator position, I would not be the only applicant. There were several external candidates along with two other coworkers who I worked with at the Helpdesk. I found out that my coworkers also knew that it would be helpful if they had an A+ certification, and they might be studying as well. It wouldn’t be the first time that I would have to compete for a position with people that I knew.

I was lucky enough to receive the call to come in for an interview with the PC Technician manager, and it turns out I was well prepared. All the studying that I had done helped me out and made me realize the importance of certifications and studying for them, but that importance wouldn’t last long, unfortunately. I was able to answer most of the technical questions during the interview and did not struggle with the situational or personality questions. I informed the manager that I was studying for the A+ exam and was planning on taking it soon.

It took a little while for a decision to get made. The manager informed me that he selected me as the candidate to fill the position. I was given an offer which, which I accepted without hesitation. That is a topic that I hope to talk about more in future posts — using the lessons that I’ve learned as I’ve moved up and around. I received instructions to keep the acceptance to myself until they had spoken to all of the other candidates. Management would then send an official announcement out to the IT organization.

Decommission 6.7 Additional External Platform Services Controller(s) (PSC)

Sun, 08 Dec 2019 22:54:33 -0800

Back when I deployed my vSphere 6.5 environment in my lab, I wanted to be able to set up Enhanced Link Mode (ELM). To do that, you needed to have an external Platform Services Controller (PSC), but that is no longer the case. Starting in an early version of 6.7, you are now able to connect multiple vCenters in ELM without having to deploy an external PSC. Based on the design recommendations back in 6.5, I decided to implement more than one PSC for redundancy. However, now I feel that it’s time to remove the extra PSC and converge the remaining external PSC into the VCSA. I will cover that process in an upcoming post for those interested in knowing how to do that.

The first thing that you need to do is make sure that your VCSA is not pointing to the PSC you are decommissioning. To check what PSC the VCSA is using for Single Sign-On (SSO) or repoint it use the post below.

Repoint VCSA to a different PSC

Once verified that any VCSAs are not using the PSC, you can shut down the PSC and start the decommissioning process. With the PSC shutdown ssh into another PSC in the SSO domain to perform the unregister commands. Launch Bash shell by running the shell command at the command prompt.

Command> shell

I like to take note of the before and after state to make sure everything is successful. So the first thing to do is run the vdcrepadmin script to show the partners. You need to change directories to the location of the executable.

cd /usr/lib/vmware-vmdir/bin/

Now to run the vdcrepadmin command to show the existing servers and the PSC partners. Replace fqdn_psc with the Fully Qualified Domain Name (FQDN) of your PSC.

./vdcrepadmin -f showservers -h fqdn_psc -u administrator
./vdcrepadmin -f showpartners -h fqdn_psc -u administrator

Shutdown the PSC to decommission it, and once it is powered off, you can now start running the commands to unregister it from the domain. Please note that this process is irreversible, and you can not rejoin the PSC to the same domain. If you want to rejoin it to the domain, a reinstall or redeploy of the PSC would need to take place. To unregister the stopped PSC, you will run the cmsso-util unregister command below. Make sure to replace the fqdn_psc and administrator@domain_name with the appropriate names for your environment. After hitting return/enter, it will prompt for the password of the SSO Administrator.

cmsso-util unregister --node-pnid fqdn_psc --username administrator@domain_name

The process takes about two minutes to complete, during which it will unregister the PSC and start/stop services. Once complete, you will receive a message stating “Success” and return to the command prompt.

To verify the removal of the PSC from the domain once again, run the vdcrepadmin commands. The unregistered PSC is no longer showing as pictured below.

Repoint VCSA to Different PSC

Thu, 05 Dec 2019 21:29:20 -0800

To repoint your vCenter Server Appliance (VCSA) to a different Platform Services Controller (PSC), you will need to use the cmsso-util repoint command. Using this process is for several different scenarios, including freeing up the capacity load, PSC maintenance, decommissioning a PSC, and various others.

To start, verify what PSC the VCSA is currently pointing to by logging into the VCSA and starting the Bash shell. Then run the command below to check what PSC is currently in use.

/usr/lib/vmware-vmafd/bin/vmafd-cli get-ls-location --server-name local

Now that you know what PSC is currently in use, you can repoint the VCSA to a different PSC. To do that, you will run the command below, replacing fqdn_psc with the Fully Qualified Domain Name (FQDN) of the new PSC.

cmsso-util repoint --repoint-psc fqdn_psc

Once the repoint is complete, perform another check to verify the VCSA is pointing to the new PSC.

/usr/lib/vmware-vmafd/bin/vmafd-cli get-ls-location --server-name localhost

vCenter 6.5 VAMI Updates Fail with Environment Not Ready

Sun, 10 Nov 2019 19:40:33 -0800

In a previous post, I mentioned that it had been a while since I had logged into my lab environment, and it was time for some updates. I was running vCenter 6.5u1, and before going to 6.7 wanted to be on the latest release of 6.5. It also allowed me to document the process and share with others who might be inexperienced in how to perform updates from the VCSA (vCenter Server Appliance) VAMI (VMware Appliance Management Interface). Unbeknown to me, the process would fail, and I would also be troubleshooting and documenting the process to resolve the issue as well.

After logging into the vCenter VAMI and checking the repository for updates, it found the update to bring the VCSA from 6.5u1 to 6.5u3. Selecting to “Install All Updates” and then clicking “Accept” on the EULA, the VCSA started installing the update. However, the updates didn’t begin and stalled at 0%. A message displayed stating, “Environment is not ready to be updated.” Clicking on “Show Details” presented additional information as to why it was not ready to install updates. There was a message that said, “Appliance (OS) root password is expired or is going to expire soon. Please change the root password before installing an update.”

Going to the Administration section and trying to set the root password not to expire gave an error stating, “Permission Denied.” Attempting to change the root password also failed with the error message “Could not set the password.”

Knowing the current root password makes this an easy issue to resolve, but it requires logging into the appliance via the console or SSH. Once successfully logged in, you will need to type in shell to launch the BASH interface. To change the password type in passwd and then type in the new password to use twice. If done correctly, you will receive a message that “password updated successfully.” If you want to verify the change, you can type in chage -l root, and it will present the password information in the screenshot below.

Logging back into the VAMI and trying to “Install All Updates” again will now proceed with the installation. After about 15-20 minutes, the updates should complete and give you a message stating, “Packages upgraded successfully, reboot is required to complete installation.” Going to the Summary section, click on “Reboot” then on “OK” to proceed with the system reboot. After rebooting, log back in to check for additional updates, and if there are none, the update is complete.

PowerShell Cmdlet Conflicts

Sun, 03 Nov 2019 08:39:26 -0800

Recently, I had something come up with a client who was migrating from Hyper-V to vSphere. One of the administrators is a big PowerShell user and brought to my attention that the Microsoft Hyper-V and VMware PowerCLI modules share some of the cmdlet names. Duplicate names become an issue when trying to manage particular objects like VMs since both modules have the Get-VM cmdlet. Due to this conflict, he removed the PowerCLI module to continue maintaining the Hyper-V servers. I decided to do some testing and figure out how he would be able to have both modules and manage both environments with PowerShell.

First, I installed both Modules on my Windows machine to try and replicate the issue my client was having. Then, I verified that both modules were present by running the following command.

Get-Module -ListAvailable | Where-Object {($_.Name -match 'Hyper-V') -or ($_.Name -match 'VMware.VimAutomation.Core')}

Now, he stated that when he runs the command Get-VM against vSphere, it tries to run the Hyper-V cmdlet. When I run the command Get-Command Get-VM, I get the following result showing that it will run the cmdlet for the PowerCLI Module. The reason is that the PowerCLI module is the one only one imported when starting PowerShell.

Once I import the Hyper-V module and rerun the command to above now, it shows that it will run the Hyper-V cmdlet.

Import-Module -Name Hyper-V
Get-Command Get-VM

However, when I run the command Get-Command Get-VM -All now, it shows that I have two cmdlets with the same name for different modules. The reason that it will run the Hyper-V cmdlet let when both modules are present is because it searches in alphabetical order. This has to be the reason my client was having the issue with the Get-VM command running the Hyper-V cmdlet instead of the PowerCLI one he was trying to run.

There are two solutions I’m going to demonstrate work regardless of which cmdlet takes precedence. The first way is to include the module name as a path before the cmdlet. This method can become quite cumbersome to type every time, especially if you want to run the PowerCLI cmdlets.

Hyper-V\Get-VM
VMware.VimAutomation.Core\Get-VM

The second solution is to include a custom prefix when importing the modules with the commands below in a new PowerShell session. Then you can verify that they were imported successfully by running the last command to show them.

Import-Module -Name VMware.VimAutomation.Core -Prefix VMW
Import-Module -Name Hyper-V -Prefix MS
Get-Command Get-*VM

I did notice something interesting when importing the modules with the custom prefixes in my new session when running the Get-Command Get-VM and Get-Command Get-VM -All. It shows once again only the cmdlets for PowerCLI.

I hope this is useful to others that might encounter an issue with two different modules with conflicting cmdlet names. This issue brings up an important consideration when creating your custom modules, to make sure you use unique cmdlet names. Leave me a comment if you found this helpful.

Send F11 Key on macOS

Tue, 22 Oct 2019 19:51:06 -0700

I enjoy using a Mac both for work and at home. There is an issue that I have come upon more than one occasion, and it always takes me a while to remember how to fix it. Figured I could post it here so that I have it as a reference and maybe help someone else as well.

There are times when accessing the console for both ESXi and UCS KVM, where you are required to send the F11 key. There are a few different key combinations that you can use to accomplish this, depending on your keyboard or macOS version. The first way is to use FN-CMD-F11, the other is just FN-F11. If you use those key combinations and it still doesn’t seem to work, you will need to go to System Preferences > Keyboard > Shortcuts and uncheck the box next to “Show Desktop” for F11.

Standalone ESXi Upgrade 6.5 to 6.7u3

Thu, 03 Oct 2019 21:33:40 -0700

After logging in to my ESXi host after some time away, I realized that it was still running vSphere 6.5u1. It was time to do an upgrade, and as stated in my last post, I’m running a nested lab environment from a single physical host. I am unable to leverage VUM (vCenter Upgrade Manager) to do the upgrades since my vCenter and everything else lives on the one host I need to upgrade. I’ll be walking you through the process to perform the update so that you can complete it and subsequent updates.

Pre-planning

To have a successful upgrade in any situation, one of the most important steps, in my opinion, is doing the pre-planning and research. Before even starting to do any of the real work, you need to make sure you have everything you need, and you have thought through the entire process. First, I check to make sure that the upgrade path that I’m taking between versions is possible to jump straight to. If not, is there a version I need to go to in-between. Next, it’s time to check the release notes of the version I’m upgrading to and see what some of the known issues are and if I will be affected by them. If there are no show stoppers at this point, I move forward and get the Image Profile Name of the update. Finally, I log into my account on my.vmware.com to download the VMware vSphere Hypervisor (ESXi) Offline Bundle, which should be a .zip file.

Preparing the host

Before beginning the upgrade, you need to shut down and running Virtual Machines that are on the host and take a back up of any critical VMs. Now we will enable a local datastore to use for Swap to avoid any potential errors during the upgrade process. Logging into the UI and on the left-hand side in the Navigator, go to Manage and then under the System tab click on Swap, then Edit settings. Click the drop-down and select a local datastore to use.

Now, you will use that same datastore to upload the Offline Bundle to that you downloaded earlier. Using the UI Navigator again, you will go to Storage, and then under the Datastores tab, click on the local datastore that you selected to apply as Swap. Click on the Datastore browser, then Upload, and browse to the location of the Offline Bundle. You will choose the file and copy it to the datastore for use with the upgrade later. You can now close the Datastore browser.

Next, put the host into Maintenance Mode. You can perform this in any number of ways, using the GUI, PowerCLI, or ESXCLI. For this example, we will use the ESXCLI commands since we will be using that medium for the upgrade, as well. Either from the console or via SSH log into your ESXi host and then run the following command to enable it.

esxcli system maintenanceMode set -e True

I always find it good practice to reboot the host before performing any upgrades to make sure I have a clean memory state. You can do that with the following command replacing the information inside the <>. The number after the -d is the delay in seconds before rebooting. The text after the -r is the reason for the reboot.

esxcli system shutdown reboot -d <15> -r <Clear memory before upgrading to 6.7u3>

Upgrading the host

Once the host is back up and accessible, you will log back in from the console or via SSH. Then, I like to list out the contents of the datastore where I copied the Offline Bundle to and make sure I see it. Use the ‘ls’ command followed by the datastore path to list the contents of the directory. Make sure to replace the name within the <> with the name of your datastore.

ls /vmfs/volumes/<SATA_1TB_Disk2>/

Now you will start the upgrade of the ESXi host using the following command again, replacing the profile, datastore, and file names within the <>. Once it completes, you will get a message with the result of running the command. If updated successfully, you would get a notification that a reboot is required for the update to take effect, followed by the VIBs installed.

esxcli software profile update -p <ESXi-6.7.0-20190802001-standard> -d /vmfs/volumes/<SATA_1TB_Disk2>/<update-from-esxi6.7-6.7_update03.zip>

To complete the upgrade, reboot the ESXi host once again using ESXCLI commands.

esxcli system shutdown reboot -d <15> -r <Complete upgrade to 6.7u3>

You can now log in to verify that you are indeed on the new version and take your host out of maintenance mode.

esxcli system maintenanceMode set -e False

Final Thoughts

I hope this was informative and helpful to anyone new to upgrading a standalone ESXi host manually or if you need a refresher. Please comment below if you found this post useful or would like to see something specific in a future post.

My Home Lab

Tue, 01 Oct 2019 21:27:30 -0700

It’s been a while since I had done much with my home lab and decided it was time to give it some much-needed attention. The last update it received was around the time that ESXi 6.5u1 was released. For those of you interested, I am currently running a Supermicro SYS-5028D-TN4T mini-tower running an Intel 8-core Xeon D-1540 processor with 128GB of memory. For network connectivity, it comes with 2x 10GbE and 2x 1GbE ports, and for storage, 4x 3.5in hot-swappable drive days and 2x 2.5in fixed internal drive bays. I purchased this back in September 2015 for around $3300 as a birthday gift to myself, and it has been running rock solid for the last four years. I say it was a gift, but it was more like an investment in myself that has more than paid for itself in the knowledge dividends it has provided me.

The original reason for the purchase was that during that time, I was working for a VAR (Value Added Reseller) and they didn’t have a lab environment to play in. As part of my offer letter, there was an incentive that would increase my base salary a specified amount for specific certifications obtained. Not only would I be able to earn that money back, but I would also be able to learn the necessary skills required to pass these exams. It didn’t take long for me to do the math and realize that the one-time hardware purchase would net me more in annual salary for that year alone. Thinking back on how much my lab has helped me over the years in gaining knowledge and progressing my career. I’m starting to think it might be time to make some additional investments to expand my home lab.

I initially bought this server to help me study for the VCAP-DCV (VMware Certified Advanced Professional-Data Center Virtualization) Deploy exam. I maxed it out on memory to allow me to build a nested environment and not have to purchase multiple physical servers. It allowed me to spin up multiple virtual ESXi instances to practice the skills needed to pass the exam. After that, it became a place for me to quickly spin up and test new versions of software and scripts in a lab environment. I gained the necessary initial hands-on experience of a variety of products before deploying into my work environments. That experience permitted me to not only pass several certification exams but also move on to new positions and gain even more exposure to new products/technologies. I wouldn’t have been able to obtain all of that experience as quickly as I did without a lab environment. It enabled me to try new things and break even more stuff in the process. I probably learned more while trying to fix something I broke in the process of making “improvements” to my lab.

Since the initial build of my lab, there haven’t been any notable equipment changes from a compute perspective. The significant changes to my lab have come in the form of network changes with some still in progress. I was fortunate enough that my employer had an old small business Cisco router and 2950 Catalyst switch that wasn’t being used to get started. I had my buddy Chance come over, and we did a whole whiteboard session on how we were going to design the network with VLANs, subnets, etc. Then he configured all the network gear for me, and it was then up to me to start setting up the servers to support the new environment and align with the network design. When I left that employer and had to give back the router and switch, then it was time to look for replacements. I was lucky enough to have a new coworker that was getting rid of a Juniper SRX210 and allowed me to have it as a replacement for the old Cisco gear.

Fast forward a few months, and the Juniper wasn’t filling all the needs/wants that I had for my environment. I also didn’t have the time to learn how to configure and manage the Juniper to make changes, so I started to look for alternatives. I wanted something that would be easy to operate, remote VPN access, have 1Gb managed ports, oh and by the way, also be cost-effective. I wasn’t asking for much, was I? It turns out that I wasn’t because I came across some products by Ubiquiti. They had what I was looking for, and I eventually ended up purchasing the following items.

For my routing and VPN needs, I bought the UniFi Security Gateway. It has a built-in Firewall, support of multiple VLANs, VPN and a Radius Server. For the 1Gb managed switch I decided to start with the UniFi Switch 8-60W which has eight GbE (GigabitEthernet) RJ45 ports, four of which are PoE (Power over Ethernet) ports. I also decided that I might as well get a new wireless AP (Access Point) that ties in with the rest of the setup. I got the UniFi AP AC LR, which is an 802.11ac Long Range AP with 2.4 & 5Ghz bands capable of 450 & 867 Mbps, respectively. The software for these products all integrated, and the interface was a breeze to manage. I had everything wired up and serving data in no time. It was so easy that I even spun up a separate network just for all of my home and family’s devices with only internet access. That allowed me to keep my lab separated and secure from any other device in my house that only required access to the internet.

I am a firm believer in having a lab environment to test out new products. A lab doesn’t have to be at home; you can set one up at work; it can be in the cloud, or even on your workstation. You don’t have to buy a single expensive machine like I did to get started, and there are plenty of cheaper alternatives. Most of them will still give you a lot of flexibility and room to grow. Some employers might give you the luxury of setting one up at work with any spare or decommissioned equipment. There are also plenty of other creative ways to get a lab built. However, you have to be willing to put in the time and effort to get it setup. That is what is going to set you apart from other people is your willingness to perform extra steps that others might not be willing to complete.

As I have noted, part of my lab has evolved, and I have no plans to call it complete at this time. I made some changes a while back and broke my VPN and will need to spend some time getting that functional again for remote access. I am finishing up another post about the process I just went through of upgrading my standalone ESXi host from 6.5u1 to 6.7u3 using the offline update and ESXCLI commands. Then it’s on to upgrading the rest of the components vCenter, vRealize Orchestrator, Log Insight, UCS Emulator, and the list goes on.

That’s just the beginning since I plan on learning more about the vRealize Suite, which is a hybrid cloud management platform. The plan is to install, configure, and document that process and use it to prepare for the VCP-CMA (VMware Certified Professional-Cloud Management and Automation) exam. Automation is everywhere, and my lab will be the focal point for me to learn more about it and be able to help others in the process. I’ll keep everyone posted on the changes and expansion to the lab as they happen. If only I had a budget as big as my ambitions and desire to learn until then I’ll have to find a way to make do.

Homelab Links

Supermicro 5028D-TN4T Mini Tower - https://www.wiredzone.com/supermicro-servers-compact-embedded-processor-sys-5028d-tn4t-10024470
UniFi Security Gateway - https://www.ui.com/unifi-routing/usg/
UniFi Switch 8-60W - https://www.ui.com/unifi-switching/unifi-switch-8/
UniFi AP AC LR - https://www.ui.com/unifi/unifi-ap-ac-lr/

Change UCS Fabric Interconnect IPs

Tue, 24 Sep 2019 20:01:03 -0700

It doesn’t often happen that you need to change the Management IP Addresses on Cisco UCS Fabric Interconnects once they are configured and placed into production. If you do have to change them for whatever reason, as I have had to in the past, I thought it would be good to post the process and commands here for reference. Make sure you replace any information located within the < > to the IP information of your Fabric Interconnects. This can all be done non-disruptively to your environment since this will only affect the IPs for management of the Fabric Interconnets and the management IPs of any configured servers.

scope fabric-interconnect a
set out-of-band ip <management IP of FI A> netmask <subnet mask> gw <default gateway>

Repeat for the second fabric interconnect.

scope fabric-interconnect b
set out-of-band ip <management IP of FI B> netmask <subnet mask> gw <default gateway>

To change the Virtual IP used for system management, this should be in the same VLAN as the individual fabric interconnect IPs:

scope system
set virtual-ip <management IP of cluster>

Finally check to see that there are no errors, then actually commit if everything checks out:

commit-buffer verify-only
commit-buffer

Attention: Something to be aware of if you happen to change the management IPs to a different subnet, you must recreate any “mgmt-IP” pools. The new pools are required because the mgmt-IP pools must reside on the same subnet as the management IPs of the Fabric Interconnects. You accomplish this by deleting the existing ones and creating new ones with the new management IP ranges.

Project Pacific Announcement

Thu, 05 Sep 2019 21:10:43 -0700

For those of you that haven’t heard VMware made a few big announcements during this year’s VMworld US. One of the more interesting to me was the announcement of Project Pacific. In my opinion, this has to be one of the more critical and landscape changing for system administrators and developers. Think of it as the next evolution of vSphere and a step ladder for organizations to be able to implement an application platform.

So what exactly is Project Pacific? It’s a re-architecture of vSphere to integrate and embed native Kubernetes into the ESXi hypervisor. What this does is aligns the management of the infrastructure to that of the modern application builds. Many of the new applications are built using containers and leveraging Kubernetes to be able to manage the orchestration of those containers. However, many of those containers still need to communicate with traditional stateful application workloads like databases. Those stateful applications are mostly running in virtual machines.

Many admins are familiar with leveraging many of the vSphere features like vMotion, snapshots, security, policies, encryption, and setting resource limits and reservations for VMs. Now imagine the ability to utilize many of those same features for containers using Kubernetes Namespaces. Now to take it even a step further what if you could manage both of those environments and polices from the same management platform. That is what precisely what Project Pacific aims to accomplish. Unifying and simplifying management of the modern application is transformative and allows organizations to manage their infrastructure in a way that was not previously possible.

To learn more, I recommend checking out link below to VMware’s blog entry Introducing Project Pacific and the additional links provided on that page.

Introducing Project Pacific