These days, quite a few devices already come with built-in iPXE support: Some hypervisors (qemu, Proxmox, VMWare, VirtulBox, etc.) support iPXE right out of the gate but there’s also an increasing number of network equipment vendors that sell network interface cards with bundled iPXE support.
But what if the bundled iPXE firmware is out of date and/or lacking a relevant feature? Recompiling iPXE is not particularly difficult but changing the iPXE rom file on a hypervisor might be. Or it might be inadvisable due to a support contract. And flashing new rom files onto network interface cards is usually cumbersome and very time consuming.
So how about using iPXE chainloading to load a patched or otherwise customised iPXE rom?
Now that our 389ds instance is fully configured and ready to go, let’s have a look at how to back it up and potentially restore it if a disaster occurs.
In part 3 we’ve looked at ACLs and how to use them to restrict privileges of directory users. Unfortunately it’s still possible to access the 389 Directory Server instance that we’ve created all the way back in part 1 anonymously (i.e. without authenticating as a directory user) which renders the ACLs somewhat pointless. So it’s time to tighten up security a bit.
Now that we’ve set up an instance of the 389 Directory Server in part 1 and configured essential plugins in part 2, it’s time to take a closer look at access-control list (ACLs). After all, regular users of the directory shouldn’t be able to change data that they’re not supposed to or have universal read access in most use cases.
In part 1 we’ve looked at how to install 389 Directory Server and create an instance. While this left us with a fully working LDAP server there are some plugins that greatly increase quality of life and might even be considered essential.
The Lightweight Directory Access Protocol or LDAP for short has been around for quite a while. While more modern technologies like OpenID, OAuth or SAML are often used for authentication and authorisation purposes when it comes to applications, APIs etc. on the internet these days, LDAP is still widely used for various use cases. For same-sign on purposes it is the de-facto industry standard as a reliable and secure technology and will probably stay relevant for a really long time to come.
There are quite a few LDAP server implemenations, the most prominent probably Microsoft’s Active Directory and OpenLDAP. Two notable free and open source implementations with a more modern codebase than OpenLDAP are Apache Directory and Redhat’s 389 Directory Server. Both do work really well but since ApacheDS lacks at least some features (e.g. https://issues.apache.org/jira/browse/DIRSERVER-1844, the importance and implications of this, of course, depend on the use case) this series of posts will look at the 389 Directory Server and how to set it up in a secure manner.
VMware’s Workstation Player checks how much swap space is available before starting up any virtual machine. If the host’s available swap space isn’t at lest 50% of the VM’s memory it spits out a warning:
VMWare Workstation Player showing error message due to too little swap being available
Unfortunately the GUI does not offer an option to change this behavior and disable memory overcommitment. However this can be done by adding prefvmx.minVmMemPct = “100” to /etc/vmware/config:
prefvmx.minVmMemPct = "100"
Note that this option has to be set globally in /etc/vmware/config and does not work in a virtual machine’s *.vmx file or on a per-user basis in ~/.vmware/preferences.
On Linux qemu-nbd can be used to access disk images in different formats as if they were block devices.
For example, to mount a VHD file run
qemu-nbd --connect=/dev/nbd0 --format=vpc <vhd_file>
mount /dev/nbd0p1 /mnt/
To unmount and disconnect the nbd device run
qemu-nbd --disconnect /dev/nbd0
Currently the Fedora projects provides cloud images as qcow2 and raw disk files. Microsoft’s Azure however only supports VHD files. Fortunately qemu-img can convert between those formats:
qemu-img convert -f qcow2 -o subformat=fixed,force_size -O vpc \
Note that the subformat options fixed and force_size are required for Azure to be able to use the disk image since Azure only supports fixed sized disks.
Thankfully the Fedora Project provides cloud images that can be directly used or easily modified to run on almost any cloud environment. Though sometimes, it can be handy to build your own image.