Updated Solutions to Classic Challenges
A personal website dedicated to helping IT professionals review where we've been, where we are, and maybe where we are headed.
Problem: I recently ran into an SSH Timeout error while trying to execute a “packer build” for an AMI on AWS. This was very confusing to me because the files were tested successfully in a different AWS account.
Read More
Installing CentOS 8 on VMware Fusion 11.5 produces an error.
“Pane is dead” appears at the bottom of the screen. Rebooting doesn’t make the problem go away.
The easiest solution I can find is to conduct a custom install selecting Red Hat 8 as the OS and set the BIOS type to UEFI. When the virtual machine boots, attach the CentOS 8 .iso file, reboot, and continue the install as normal.
As best I can figure it, the root cause seems to be tied to how Fusion identifies CentOS 8. Fusion appears to identify it as “CentOS 5 or earlier 64-bit” which has either hardware settings, drivers, or both, that are incompatible with the CentOS 8 installer.
While I used UEFI, the custom install option will also work with “Legacy BIOS” selected.
This error is encountered when attempting to connect to an EC2 instance via SSH with a .pem file that doesn’t have the appropriate linux filesystem permissions in place.
CD to the directory where the file exists
Type : sudo chmod 400 <filename>
The next time you run ssh it should work.
I ran into this issue on a Macbook Pro running OS X. My file permissions were “too open” for use. The file permissions before I made the change were set to 0644 which threw the error.
I’ve recently started working with the MXChip 3166 and Azure IoT. While following the "Connect IoT DevKit AZ3166 to Azure IoT Hub” instructions (https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-arduino-iot-devkit-az3166-get-started ), I couldn’t get the Arduinio Board Manager software to run from within Visual Studio Code.
Read MoreI ran into a strange error today. I attempted to launch SQL Server Configuration Manger on a server deployed in Azure, and I was greeted with an error dialog that implied either the server was unreachable or that I didn’t have rights. The error read, “Cannot connect to WMI provider. You Do not have permission or the server is unreachable. Note that you can only manage SQL Server 2055 and later servers with SQL Server Configuration Manager. Invalid namespace [0x8004100e].” After a bit of digging, I found a solution, and possibly even a root cause.
Read MoreAmazon Web Services offers several services which are region specific. When encountering an error, the first thing you should do is validate that you are operating in the correct region(s). This was an issue I ran into recently when using CloudFormation.
Read MoreGit for Windows is a powerful tool for interacting with CI/CD pipelines. There are specific components that should be avoided during the installation when working with Amazon AWS’s CodeCommit service. More Specifically, the Git Credential Manager component should not be installed if you plan to use Git for Windows with Amazon's CodeCommit source code repository.
I ran into access denied errors a while back with Git and CodeCommit. I'd read the advice on Amazon's troubleshooting website (https://docs.aws.amazon.com/codecommit/latest/userguide/troubleshooting-ch.html) but to be honest, it didn't click with me. It wasn't until I had the errors and re-read the instructions, that it started to set in that I needed to reinstall Git and change the option.
Read MoreThis blog post details steps to resolve the "There are no active source control providers" in Visual Studio Code on Windows 10.
Read MoreThe recent news of a new Windows Server 2019 build sent me to the Microsoft Insider Preview Download site. As it was a Microsoft app I wanted to download, I decided to use MS Edge. I normally don't use the Edge browser, but I thought it would be best for accessing MS resources. As I attempted to start the download, I hit a wall. Error 715-123130 appeared whenever I tried to download any of the product links. No matter how many times I tried or how many different tabs I used, the same error appeared.
Read More
Today, ran across an error that I was previously unfamiliar with when running VMware workstation. The error occurred on my Windows 10 laptop with Workstation 14. The error read "VMware Workstation and Device/Credential Guard are not compatible. VMware Workstation can be run after disabling Device/Credential Guard." and was displayed as attempted to power on the VM.
A quick google search took me to a vmware KB article (https://kb.vmware.com/s/article/2146361) that lists the cause as "This issue occurs because Device Guard or Credential Guard is incompatible with Workstation." The fix, however, leads to a more general cause - VMware Workstation isn't compatible with Hyper-V. When reading through the fix, the advice starts with instructions for explicitly disabling the "device guard" feature. But then later on, the instructions state to uninstall the Hyper-V role completely. A few more google searches led me to discussion groups where people see issues running the two hypervisors on the same pc. It seems odd in 2018 that this would be an issue, but it seems to be true.
There was a time when I would have done this as I generally prefer the way Workstation handles vms and networking to hyper-v on a laptop. The problem here is that Docker for Windows 10 uses Hyper-V. So the decision isn't just VMware Workstation or Hyper-V, it's VMware workstation vs. Hyper-V AND Docker. Since I'm doing more with learning containers, I elected to not use VMware workstation.