Chainloading (patched) iPXE firmware with iPXE

      No Comments on Chainloading (patched) iPXE firmware with iPXE

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?

Continue reading

LDAP server with 389ds: Part 4 – Security

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.

Continue reading

LDAP server with 389ds: Part 3 – ACLs

      1 Comment on LDAP server with 389ds: Part 3 – ACLs

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.

Continue reading

LDAP server with 389ds: Part 1 – Installation

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.

Continue reading

Enabling ‘reserved host RAM’ on VMWare Wokstation Player

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.

Converting a disk image to VHD for Azure

      No Comments on Converting a disk image to VHD for Azure

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 \
  Fedora-Cloud-Base-27-1.6.x86_64.qcow2 \
  Fedora-Cloud-Base-27-1.6.x86_64.vhd

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.