If you have played around with vRealize Orchestrator (and vCenter Orchestrator before it) for long enough, you have undoubtedly locked yourself out at least once, either at the console or in VAMI or both. KB 2069041 details the process to reset the password and it’s simple enough, for the most part. You still have to deal with a lockout period in both the console and VAMI, and since the only user that likely exists is root, it appears to me to be just a way to DoS yourself when you most desperately need access to your vRO. The lockout can be disabled, though.
While looking for the KB to reset the password, I found this article (if anyone knows who fdo is, please let me know, their profile page is blank) which describes how to disable the lockout at the console/ssh. Just edit /etc/pam.d/common-auth and comment out the line containing pam_tally2.so and you can get back in, whether you have changed root’s password or not. However, you cannot get into the VAMI still. Let’s see what else uses pam_tally2.so in the PAM configuration directory:
vro01:/var/log # grep tally /etc/pam.d/*
/etc/pam.d/common-account:account required pam_tally2.so
/etc/pam.d/common-account-vmware.local:account required pam_tally2.so
/etc/pam.d/common-auth:#auth required pam_tally2.so deny=3 onerr=fail even_deny_root unlock_time=86400 root_unlock_time=300
/etc/pam.d/common-auth-vmware.local:#auth required pam_tally2.so deny=3 onerr=fail even_deny_root unlock_time=86400 root_unlock_time=300
/etc/pam.d/vami-sfcb:auth required /lib64/security/pam_tally2.so deny=4 even_deny_root unlock_time=1200 root_unlock_time=1200
/etc/pam.d/vami-sfcb:account required /lib64/security/pam_tally2.so
Winner! There’s 3 different files (two are symlinks) containing that pattern and one has the word vami in it, bingo! Just get in and put a # in front of the auth line (the bolded one) to comment it out and suddenly you’ll be able to log in to the VAMI again. I do not know if this persists across updates, so you may want to revisit this after your next upgrade to be sure – I’ll come back and add a note whenever I do my next update.
You can now no longer DoS yourself, or be DoSed by accidental or malicious coworkers. However, keep in mind that this may violate your corporate standards for security, and that’s a political problem, not a technical one – perhaps in that situation, you can adjust the timers instead of disabling it entirely. I think it’s safe to say that this is perfect for everyone’s lab, though!
Over the past three years, my Puppet for vSphere Admins series has meandered through a number of topics, mostly involved on the Puppet side and somewhat light on the vSphere side. That changed a bit with my article Make the Puppet vRealize Automation plugin work with vRealize Orchestrator, describing how to use the plugin’s built-in workflows to perform some actions on your VMs. However, you had to invoke the workflows one by one, and they only worked on existing VMs. That is not good enough for automation! Today, we will start to look at how to integrate the Puppet Enterprise plugin into other workflows to provide end-to-end lifecycle management for your VMs.
What is the lifecycle of a VM? This can vary quite a bit, so the lifecycle we will work with today is made to be generic enough for everyone to use, but flexible enough that everyone can expand on it. It consists of:
- Updating ancillary systems prior to VM creation (IPAM, DNS, etc)
- Deploying a Virtual Machine
- Installing Puppet Enterprise on the VM
- Using Puppet Enterprise to provision services on and configure the VM
- Add the new VM to a vCenter tag-based backup system
- Delete the VM (removes from backups)
- Purge the record from PE
- Update ancillary systems after VM removal (IPAM, DNS, etc)
I’m pretty excited about this post! I’ve been building up Puppet for vSphere Admins for a few years now but the final integration aspects between Puppet and vSphere/vCenter were always a little clunky and difficult to maintain without specific dedication to those integration components. Thanks to Puppet and VMware, that’s changed now.
Puppet announced version 2.0 of their Puppet Plugin for vRealize Automation this week. There’s a nice video attached, but there’s one problem – it’s centered on vRealize Automation (vRA) and I am working with vRealize Orchestrator (vRO)! vRO is included with all licenses of vCenter, whereas vRA is a separate product that costs extra, and even though vRA requires a vRO engine to perform a lot of its work, it abstracts a lot of the configuration and implementation details away that vRO-only users need to care about. This means that much of the vRA documentation and guides you find, for the Puppet plugin or otherwise, are always missing some of the important details needed to implement the same functionality – and sometimes won’t work at all if it relies on vRA functionality not available to us.
Don’t worry, though, the Puppet plugin DOES work with vRO! We’ll look at a few workflows to install, run, and remove puppet from nodes and then discuss how we can use them within larger customized workflows. You must already have an installed vRealize Orchestrator 7.x instance configured to talk to your vCenter instance. I’m using vRO 7.0.0 with vCenter 6.0. If you’re using a newer version, some of the dialogs I show may look a little different. If you’re still on vRO 6.x, the configuration will look a LOT different (you may have to do some research to find the equivalent functionality) but the workflow examples should be accurate.
Puppet provides a User Guide for use with a reference implementation. I’ll be mostly repeating Part 2 when installing and configuring, but reality tends to diverge from reference so we’ll explore some non-reference details as well.
I just configured a brand new vRealize Orchestrator Appliance v6.0.3 with a vCenter Server (not appliance) v6.0U1. The deployment of the OVF is pretty simple, but configuration was trickier than I expected. VMware’s guide is accurate if everything works well but painfully inadequate if you require any troubleshooting. Take a run through the guide, I’m not going to speak to what it does cover, and if you have problems, maybe one of these tips will help you.
Any time you change authentication, you MUST restart the vRO service. You may see all the status icons go from green to red to blue and back to green, which makes it appear that some services are restarting, but they aren’t. If you’re not sure, click the restart button as shown below. Bonus: when the page responds and says the service, the service is ready to use, unlike some other VMware products *cough*vSphereWebClient*cough*