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

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 \

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.

Running Fedora 27 on Google Compute Engine

      2 Comments on Running Fedora 27 on Google Compute Engine

Usually Linux distributions with a long life cycle like RHEL (or its free derivative CentOS), Debian or SLES are the way to go for virtual machines in a cloud environment. But sometimes you need to be a little bit closer to upstream. Maybe because your applications relies on newer version of some packages that are not (easily) available on distributions with long term support or maybe because you need a feature that has just not yet made it to RHEL, Debian or SLES.
In those cases, Fedora is an interesting choice, since it’s probably the Linux distribution that’s closest to upstream and provides the most features that could be considered ‘bleeding edge’. Unfortunately there’s currently no publicly available Fedora image on the Google Cloud Platform. But not to worry, it’s quite easy to run Fedora 27 on GCE.

The Fedora Project provides a compressed raw disk image that can be used to spawn VMs on different platforms, e.g. GCE. To use it with the Google Compute Engine, the image has to be renamed and repackaged though:

wget https://dl.fedoraproject.org/pub/fedora/linux/releases/27/CloudImages/x86_64/images/Fedora-Cloud-Base-27-1.6.x86_64.raw.xz
xz --decompress Fedora-Cloud-Base-27-1.6.x86_64.raw.xz
mv Fedora-Cloud-Base-27-1.6.x86_64.raw disk.raw
tar cfz Fedora-Cloud-Base-27-1.6.x86_64.tar.gz disk.raw --sparse
rm disk.raw

The image can now be uploaded into a Google Cloud Storage bucket:

gsutil mb gs://fedora-cloud-base-27
gsutil cp Fedora-Cloud-Base-27-1.6.x86_64.tar.gz gs://fedora-cloud-base-27/

Now, we can create an image and use that to spawn a GCE instance:

gcloud compute images create --source-uri gs://fedora-cloud-base-27/Fedora-Cloud-Base-27-1.6.x86_64.tar.gz fedora-cloud-base-27
gcloud compute instances create fedora27 --machine-type f1-micro --image fedora-cloud-base-27 --zone us-east1-b

Of course, you might want to choose a different machine-type or zone here.

Once the VM is booted (and assuming a metadata key value pair for the project provides a public ssh key) one can connect to the instance via:

gcloud compute ssh fedora@fedora27

Allow blacklisted VMWare Workstation Player graphics driver

For some reason, VMWare decided to blacklist some graphics drivers for their VMware Workstation Player. That includes the Mesa DRI drivers for most Intel IGPs, which results in unbearably slow graphic performance and potentially error messages such as “Hardware graphics acceleration is not available” or “No 3D support is available from the host” when starting a virtual machine

VMWare Workstation Player showing error message due to blacklisted driver

To enable hardware 3D acceleration for blacklisted drivers, the option mks.gl.allowBlacklistedDrivers needs to be enabled:

mks.gl.allowBlacklistedDrivers = TRUE

This can either be done globally in /etc/vmware/config, on a per-user basis in ~/.vmware/preferences or for each individual VM in the corresponding .vmx file.