Author Archives: cidrick

Infoblox DHCP Filters for Mixed UEFI/BIOS PXE Boot

Posted on by

After migrating all of our DHCP helpers to Infoblox in the past few weeks, one of the annoyances we had was having to override the bootfile name in the DHCP lease for new hosts that were being built. Since all new server hardware purchases have UEFI enabled by default, in order to PXE boot from your TFTP server, you have to pass it a different bootfile (bootx64.efi) than you would if you were using a traditional BIOS-based system. Some of our admins were either manually overriding the host record in Infoblox to use bootx64.efi as its bootfile (instead of pxelinux.0 if you’re using syslinux), or, even worse, putting the machine into legacy BIOS mode in order to kickstart the box. What I needed was a way for Infoblox to automatically present the needed boot file without any extra steps in the provisioning process.

Continue reading Infoblox DHCP Filters for Mixed UEFI/BIOS PXE Boot→

OpenLDAP to Active Directory Proxy Configuration

Posted on by

One of the more glaring issues with the environment I’m currently supporting is that there’s no single sign on. Workstations and web tools (mostly Atlassian in nature – Stash, Jira, Confluence, et al) all authenticate against our Active Directory environment. However, all of our Linux and Solaris hosts authenticate against a separate OpenLDAP environment, so users have to maintain two different sets of credentials and passwords. This has all the extra baggage that comes from maintaining password policies, such as two different auth sources that you can get locked out from. I elected to take up the task to eliminate one of the environments, and given that our OpenLDAP database was significantly smaller than Active Directory, we decided to eliminate OpenLDAP from the environment.

I considered three approaches for achieving this. The quick and dirty method is to use SASL passthrough authentication, which is supported by OpenLDAP as detailed in this page. In short, you can take an existing user account in OpenLDAP and modify their userPassword attribute, replacing the existing hash with “{SASL}user@domain” which will point to a matching user in Active Directory. While this would satisfy the requirement of single sign-on, it still requires that you maintain an OpenLDAP backend database for all other data, such as homeDirectory, loginShell, uid, gid, and so on.

A second option is to not use an OpenLDAP server at all, and configure all your clients to natively talk to Active Directory. This isn’t terribly difficult as long as you’re using SSSD – see this excellent article on the subject. However, I’d have to gut a large amount of the environment to move to sssd, and it requires some software bloat – namely, Samba – in order to work. While this wasn’t necessarily a dealbreaker, I didn’t think it was the cleanest option.

The third method – and ultimately is the one we chose to pursue – is to continue leveraging an OpenLDAP backend, but proxy the requests to Active Directory. This has the benefit of utilizing a single source of authentication (AD, in our case) and allows us to continue using the native OpenLDAP client that all our hosts are currently utilizing without any additional configuration. Additionally, it would allow any applications that have weaker LDAP client support to continue to work. The OpenLDAP proxy can also remap fields on the fly, taking an OpenLDAP attribute and remap it to its AD equivalent – translating “uid” to “sAMAccountName”, for example. This allows for maximum flexibility without requiring any special configuration on the client side. The only real downside is that you add an additional layer of complexity to the flow of authentication, which means one extra spot you may have to troubleshoot in the event of auth issues. Still, it seemed this approach would be the best one for us.

Continue reading OpenLDAP to Active Directory Proxy Configuration→

Failed storage vmotion: when VMware’s log verbosity tells you Nothing At All

Posted on by

I recently was in the middle of migrating an entire cluster of VMs (190 in all) to a different datastore. 189 of them migrated just fine, but a single one gave me grief during the svmotion with the following error:

Relocate virtual machine
naughtyvm3161p
File /vmfs/volumes/f08ad362-ff1e8a5b/naughtyvm3161p/naughtyvm3161p-000001.vmdk was not found

This is especially curious, because when browsing the datastore, the vmdk certainly existed, albeit as naughtyvm3161p-000002.vmdk. Looking at all the config files (the vmx, the vmdk, et al) on the datastore with my favorite text editor, all of these reference the proper, existing 00002.vmdk file. The GUI, too, points to the proper file. So what on earth still thinks the VMDK was at its old name?

vpxa.log and hostd.log on the VM host were no help either – hostd.log just showed the error, and vpxa merely spat out a few thousand lines of it looking up the datastore with nothing meaningful about WHAT was referencing that file

2013-07-18T13:57:14.512Z [7B004B90 verbose 'Default' opID=AC56DD98-000446B3-3a-f0] [VpxaVmprovUtil] LocalPathToDatastoreUrl conversion: /vmfs/volumes/51e0170e-514c8539-b69a-68b599b15d64/naughtyvm3161p/naughtyvm3161p-000001.vmdk -> ds:///vmfs/volumes/51e0170e-514c8539-b69a-68b599b15d64/
2013-07-18T14:22:36.622Z [7AFA1B90 info 'DiskLib' opID=AC56DD98-00044873-1a-77] DISKLIB-DSCPTR: DescriptorDetermineType: failed to open '/vmfs/volumes/f08ad362-ff1e8a5b/naughtyvm3161p/naughtyvm3161p-000001.vmdk': Could not find the file (600000003)

Real helpful, as you can see. Peak snark was hit at around 9:57AM, when I realized I needed more coffee.

And then I noticed on a lark that this particular VM had a snapshot – based on the fact that it had a “delta” vmdk file. Why? No clue. None of these VMs should be using snapshots. After busting out the snapshot hatchet (the snatchet? the snapchet? idk) the storage vmotion was successful.

Goofy as hell, but that’s vmware for you.