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.
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
umount /mnt qemu-nbd --disconnect /dev/nbd0
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.
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
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
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.