Setting Up an LDAP Server Instance on AWS

This blog describes the basics of what it takes to get an existing LDAP server moved from the PV virtualization type to HVM. I encountered this situation personally while working for a client earlier this year. Efforts have been made to keep most of it generic enough to be useful for other situations involving system upgrades or replacements as well.

Background

Let me give a little background. On the project I was working on, we determined that we needed to update our LDAP server instance’s virtualization from PV to HVM. Windows¹ and Linux² guides to do this existed, but the resulting instances were unable to boot for me by swapping volumes.

Not only that, Amazon Linux AMI is out of support³ and 32-bit AMIs are no longer available to properly follow those Linux guides. We needed to start from scratch.(Almost!)

Prerequisites

Before you even get started, there are some things you should consider. The first thing I would recommend is to inventory what you are looking to update. Using a snapshot of the current system, take note of things that are running. Also, keep in mind the destination system, as some things are not immediately transferable.

Virtualization Settings?

Disks, memory… that sort of stuff. If it was built from a template, image, docker file, or anything of that sort, that could be handy, too.

Operating System?

In this case, Amazon Linux AMI, 32-bit. Running uname -a is helpful to get the specific kernel version.

Special Linux Consideration: What init system are you running?

sysvinit, systemd, upstart? There are many available, but it is highly likely you have either sysvinit or systemd.

I happen to be dealing with a SysV-style init system, but the destination platform uses systemd – we’ll deal with that later.

Special Linux Consideration: How do you install/update software?

The Amazon Linux offerings seem to be RPM-based, with yum pre-installed as a friendlier command line front-end than the base rpm program.
You may have other programs such as apt (Debian), pacman (Arch), dnf (Fedora), emerge (Gentoo), or simply using tarballs for your software installations. There are many ways to install software. Be sure you know which you will be using.

What Services Are Running?

On Linux, chkconfig can provide some insight into what services are running and when. The systemd init system can show similar info by running systemctl list-unit-files.

Overview of Steps

The process to set this up may be summarized as follows:

Launch a new instance
Attach a snapshot volume of the existing system
Transfer data to the new instance
Detach the snapshot volume (if desired)
Install and configure software and services
Final Considerations

Step 1: Launch a new instance

The current AMI Catalog shows two Amazon-provided Linux AMI products to choose from, Amazon Linux 2023 and Amazon Linux 2, both of them using HVM virtualization and 64-bit.

“Amazon Linux 2” is described as the successor of the Amazon Linux AMI, which we are coming from, so that is what I selected to build a new instance from. If you happen to already have an AMI in mind, select that instead.

Amazon already provides a guide for launching an instance, so I won’t go into those details. Be sure you have the correct instance type, key pair, and network settings.

Optional: In the launch wizard, you may go ahead and attach a volume created from your snapshot of the current instance. Feel free to do so as this can save time. When doing so, take note of the device name of the new volume. I used /dev/sdf for my source volume’s device name.

Take note of the Instance ID and other IDs along the way to save time and trouble.

Before continuing, make sure you are able to SSH into your new instance. You wouldn’t want to waste time setting up other parts if you cannot even log in!

Step 2: Attach a snapshot volume of the existing system

If you already attached a snapshot volume of your source system when launching your new instance, you may skip this section.

Though it may not be entirely necessary, I would recommend stopping your instance prior to attaching a volume. Maybe the virtualization handles this fine for others, but I had issues with mounting the volume

If you already have a volume you intend to attach, skip this paragraph. Otherwise, use the EC2 management console to navigate to your snapshot. In the actions dropdown menu, you can create a volume from the snapshot. There should be a message letting you know the ID of the new volume.

Navigate to your volume and use the actions dropdown to Attach Volume. The following screen will allow you to select the instance you created as well as enter the device name for the volume. I used /dev/sdf.

Navigate to your new instance, and you should find your volume under the Storage tab.

Start your instance if it is currently stopped.

Step 3: Transfer data to the new instance

This step is subjective to whatever you are trying to do. These particular steps were useful for migrating an existing installation of OpenDS, and therefore, was almost a simple “copy & paste” operation.

First, mount your source volume.

sudo mkdir /mnt/source
sudo mount /dev/sdf /mnt/source

Next, transfer the installation.

sudo cp -pr /mnt/source/opt/OpenDS /opt

Finally, unmount the source volume (if desired).

sudo umount /mnt/source

Sidenote: Some individuals may have their user data at the root of a volume’s filesystem and wish to simply mount the volume directly to whatever filesystem location is necessary. This would make it simpler to stand up instances with their data, so long as they are sure to have it mounted on every boot. That configuration is out of the scope of this document.

Step 4: Detach the snapshot volume

If you no longer need the snapshot volume, you may want to detach it from your new instance. Otherwise, you may skip this section.

I recommend stopping your target instance before detaching the volume to minimize potential issues. It may be enough to only have the volume’s device unmounted, but I would rather be safe than sorry.

Navigate to your volume, either directly through the Volumes link in the EC2 console or via the Storage tab for your instance. With the volume selected, you will find Detach Volume in the actions dropdown menu.

Take note of the volume and associated snapshots if you wish to delete them as part of the cleanup.

Be sure to start your instance back up if you stopped it.

Step 5: Install and configure software and services

With your new instance running, it’s time to make sure we have everything configured.

In case you did not run an update on the first boot, now would be a good time to run an update on the system as a whole.

sudo yum update -y

Next, we can focus on getting the service running. Our OpenDS installation requires Java to be installed. The original system had a full installation, but we should be good to go with a headless install to avoid things we will not be using.

I would choose the exact same Java version to minimize risk, but I’ll have to go with the closest supported option for now.

sudo yum install java-1.7.0-openjdk-headless

From here we can check that the service starts by running the OpenDS start-ds script, and shut it back down with appropriate stop-ds script. But what we really need is to have it start when the instance boots.

The original installation’s SysV-style init scripts did the trick, but now we are in the realm of systemd. We need a “unit file” to tell systemd about our service so it can be started automatically and to have it know to restart the service if it goes down.

Thanks to a few Google results ^{4, 5}, I came up with the following configuration and saved it as /etc/systemd/system/opends.service.

[Unit]
Description=OpenDS
Wants=network-online.target
After=network-online.target
Conflicts=shutdown.target

[Service]
User=root
Type=simple
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
ExecStart=/opt/OpenDS/current/bin/start-ds --quiet
ExecStop=/opt/OpenDS/current/bin/stop-ds --quiet
#Restart=always

[Install]
WantedBy=multi-user.target

Note: The leading # to comment out the Restart=always configuration. This is so we can ensure things are working smoothly. Consider deleting this line and reloading your configuration OR determine what value you want for it⁶.

Tell systemd to read our new configuration…

sudo systemctl daemon-reload

Enable our service…

sudo systemctl enable opends.service

We can query it…

systemctl is-enabled opends.service

And start it.

sudo systemctl start opends.service

Other subcommands that we’ll find useful include disable, stop, restart, and status.

We are effectively done! A quick use of the ldapsearch command in our OpenDS installation should show success.

cd /opt/OpenDS/current/bin
./ldapsearch --port 389 --baseDN dc=keyholesoftware,dc=com "(ou=Users)"

Final Considerations

To wrap it all up, any undesired objects may now be removed. Be sure to take extra care so as to not remove anything important. Make a snapshot of your instance (or perhaps create a new AMI based on what you just created!). Test out your new instance, and get to planning your cutover.

Congratulations! You did it! You set up an LDAP server instance. Share about your experience in the comments below. It’s helpful for me and potentially for other readers as well. Check out the Keyhole Dev Blog for more content like this.