VMworld is this week! While I am sad I cannot see many of you in person, I wanted to spend some time to review a few sessions that are rather pertinent for our global cloud providers. I am going to break this out into specific categories. The sessions I list below are not exhaustive in nature as there are over 40+ sessions that are Cloud Provider focused.
Continue reading “VMworld 2020 – Top Cloud Provider Sessions”VMware and Amazon Web Services are making a significant investment in providing a vSphere experience in a hyperscaler environment and we continue to see adoption for Cloud Service Providers utilizing VMware Cloud on AWS as an offering for managed services.
In this post, I will review my approach, what to expect on the exam, and my raw study notes.
I decided to prepare for the VMware Cloud on AWS Management Exam 2019 (Exam 5v0-31.19) and sit for it. While there’s a lot of great material that I will review below, I wanted to provide my approach for others.
It’s 30 questions and is done via the Pearson Vue site online. I thought it was very fair as a skill/badge exam and goes over many of the fundamental requirements. As expected, it’s true to the blueprint.
For me, I always prepare a final checklist of things I review before I take any examination. Below is my list of raw notes I used before I took the exam. As they are my raw notes, expect some abbreviations.
Anyway, enjoy the exam and I look forward to the expansion of VMware Cloud on AWS!
VMC on AWS Study Notes:
I wanted to start off my Monday morning with a bang, so decided to schedule my VCAP 3v0-624 exam for the first in the morning. Well, I passed!
Before walking into this exam, I wasn’t sure if I prepared enough, but I felt kind of comfortable once the exam started. I’d like to share what I did to prepare for this exam, although this is my first ever VCAP-Design.
I hope this helps others – cheers!
-Daniel
Updated – July 9th, 2020 with password policy and complexity.
So I’ve been playing with Photon OS recently with a few of our Cloud Provider solutions, very nice lightweight appliance.
However, one thing that surprised me is the minimal/lightweight install does not have ping installed nor can you ping it (ICMP echo replies). In my opinion, this is a basic function for any type of network troubleshooting. I understand it’s minimal…but go cut something else out. 🙂
So how do we set up some basic network functions?
cd to /etc/systemd/network
vi (or use your preferred text editor) a file called 10-eth0.network
There’s three sections required: Match, Network, and DHCP
Below is the code required:
[Match] Name=eth0 [Network] Domains=HOSTNAME domain.local Gateway=192.168.110.1 Address=192.168.110.61/24 DHCP=no [DHCP] UseDNS=false
Save it (wq!), and now it’s time to chmod the file so it can be read by the OS
chmod 644 10-eth0.network
Now we should see the correct permissions: 
Now restart the network daemon service.
systemctl restart systemd-networkd
Complete!
Pretty easy – as you can see, doesn’t exist. 
Now there’s two different versions of Photon – version 1 and 2. On version 1, it’s pretty easy – type in the following:
yum install iputils
Now for Photon 2.0 (which I’m currently using), repos are disabled by default and so I was getting a message stating “package not found” which was odd. However, digging in further, I found the repos were not enabled.
cd /etc/yum.repos.d/
I enabled three repos:
photon
photon-extras
photon-updates
We need to edit each file and change the enabled=0 to enabled=1
Once I did this, run “tdnf repolist” and we should now see the following:
Now let’s install it!
tdnf install iputils
Now we should see the following: 
Sucess! Ping is available now, along with netstat too.
This is a change in the firewall table. By default, ICMP echo and replies are dropped.
Here are the two commands required to enable ICMP traffic:
iptables -A OUTPUT -p icmp -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
Before I make the change on my system, I’m unable to ping
Make the iptables change….
Voila! We now get a response. 
Currently, I found a DNS issue with the vami_config_net file with a Photon 3.0 appliance deployment – it was not setting the DNS correctly and resorting to a 127.0.0.53 address. Moreover, the /etc/resolv.conf file should not be modified and if it is, changes do not persist post-reboot.
Two options:
Option 1 Example:
2
3
4
5
6
7
Name=e*
[Network]
Address=198.51.0.2/24
Gateway=198.51.0.1
DNS=198.51.0.1
Option 2
root@vcav [ ~ ]# more /etc/systemd/resolved.conf ....... # See resolved.conf(5) for details [Resolve] DNS=10.96.88.2 #DNS= #FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844 #Domains= LLMNR=false #MulticastDNS=yes #DNSSEC=no #DNSOverTLS=no #Cache=yes DNSStubListener=yes
I’ve had situations where I’ve locked myself out of a Photon instance. The process is pretty simple – follow this link: https://github.com/vmware/photon/blob/master/docs/photon_troubleshoot/resetting-a-lost-root-password.md
By default, Photon has a one year password expiration policy for accounts, including the root account. One can modify this and establish a no expiration policy, but also adjust other parameters.
From a root account, one can see the following:
root@vcd [ ~ ]# chage -l root Last password change : Mar 30, 2020 Password expires : Mar 30, 2021 Password inactive : never Account expires : never Minimum number of days between password change : 0 Maximum number of days between password change : 365 Number of days of warning before password expires : 7
One can modify this by using the “chage” command.
chage -m 0 root
From there, we can now see the password expiration has been removed.
root@vcd [ ~ ]# chage -l root Last password change : Mar 30, 2020 Password expires : never Password inactive : never Account expires : never Minimum number of days between password change : 0 Maximum number of days between password change : 99999 Number of days of warning before password expires : 7
Photon utilizes the standard PAM modules for password complexity. For those of you in a lab environment that utilize the same password or standard password methodology, one might need to adjust this.
The configuration file is under:
/etc/pam.d/system-password
We can see under this file that we have three lines –
root@usagemeter42 [ /etc/pam.d ]# more system-password # Begin /etc/pam.d/system-password password requisite pam_cracklib.so minlen=8 minclass=4 difok=4 maxsequence=0 retry=3 enforce_for_root password requisite pam_pwhistory.so retry=3 remember=5 enforce_for_root password required pam_unix.so sha512 shadow use_authtok # End /etc/pam.d/system-password
For me, I wanted to just disable the policy in its entirety. To do this, comment out the first line:
# Begin /etc/pam.d/system-password #password requisite pam_cracklib.so minlen=8 minclass=4 difok=4 maxsequence=0 retry=3 enforce_for_root password requisite pam_pwhistory.so retry=3 remember=5 enforce_for_root password required pam_unix.so sha512 shadow use_authtok # End /etc/pam.d/system-password
From there, one can change their password –
root@usagemeter42 [ /etc/pam.d ]# passwd New password: Retype new password: passwd: password updated successfully
Need help changing it from the default photon-appliance hostname?
Hostnamectl is the command for permanently changing the name – not just editing the /etc/hosts file.
hostnamectl set-hostname DanielApp-B
Reboot the system.
During some of my testing, my lab environment went bottoms up – thanks, Timo 😉
After my Photon appliances started back up, I could not SSH to them. So after some troubleshooting and help from the VMware internal team, figured out what happened.
Steps to resolve:
Log into the console and ls -l /var/vmware/skip_sshd and you can also check the status of sshd by typing “systemctl status sshd”
If the file does exist, you need to remove it. No clue why it was added when I had a hard power outage, but it did.
rm /var/vmware/skip_sshd
Now start up ssh..
systemctl start sshd
Voila! we can now see it’s started
Now, SSH works! 
Other great details on Photon commands can be found here: Photon OS Troubleshooting Guide
Thanks!
