Linux NetBoot Server with BSDPy and Docker

About a month ago I followed a guide here written by Graham Gilbert on setting up a NetBoot server on Ubuntu Linux using Docker and BSDPy. The guide is a setup using Ubuntu Linux, which is a great write up and very detailed in setting up. However, I needed to rebuild the server and I wanted to use CentOS 7 instead. The differences between the two versions of linux are just enough to have a few minor tweaks to the setup, but for the most part it is very similar. This guide will walk you through setting up Docker and BSDPy on CentOS 7 to get a working NetBoot server in your environment to deploy install or restore images for Mac's. (In my case, because of limited storage this is only going to server install images).

To start, grab a copy of CentOS 7 from the download site. I choose the minimal ISO because there isn't much needed for this. But you can choose the any ISO you want, but it doesn't really matter which on because there is not much needed for this guide unless you need to install the OS without an internet connection. Please note, this setup will be done in VirtualBox, so some things may differ if you are setting it up on a physical machine or in VMware. Once CentOS is installed, we need to make sure we have a network connection. In VirtualBox you will need to change the network adapter to be attached to Bridged Adapter this will give the VM an IP in the same subnet as the rest of your network.

We need to install Docker first, this can be done either from a script or from the Docker repository. I chose to go with the method from the repository. Log into your machine with a super user account that has sudo or root privileges and update the existing packages. Once that has completed add the Docker repo

$ sudo tee /etc/yum.repos.d/docker.repo <<-'EOF'
[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/$releasever/
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg
EOF

Install the Docker package:

sudo yum install docker-engine

then start the Docker daemon:

sudo service docker start

Now that we have Docker installed, it's time to setup a script to download and run the containers needed for the NetBoot server and a directory for the NetBoot (nbi) Images. Graham describes his method of working with containers as placing the necessary files and scripts in the directory /usr/local/docker. It is his way of working and he does not suggest that it is the best, but it is nice to keep things consistent if later on down the road you setup another Docker server on your network. For this guide we are going to follow suite with creating the /usr/local/docker directory and placing the script and data there.

mkdir -p /usr/local/docker/nbi

Now it's time to start working with the startup script. In the text editor of choice, start with the first part of the script that will download the Docker containers for tftpd, netboot-httpd, and bsdpy

#!/bin/bash

docker pull macadmins/tftpd
docker pull macadmins/netboot-httpd
docker pull bruienne/bsdpy:1.0

and make it executable

chmod 755 /user/local/docker/startup.sh

then run it with the command

/usr/local/docker/startup.sh (or if you are working in the /usr/local/docker directory, you can run it with ./startup.sh

At this point, Docker should start downloading the images if everything was installed properly. Then, add a few commands after the last docker pull to stop and remove any running or installed containers. This is not necessary, but it is nice to clean up any prior installs. Also note that it doesn't take much more time to pull and start a new container than it is to start a container that was previously pulled. The benefit of this method is that you know you are running the most current version. Docker will only pull a new container if it has been changed on the Docker hub.

#stop all docker containers
docker stop $(docker ps -a -q)
#remove all docker containers
docker rm $(docker ps -a -q)

Now, to finalize the startup script with getting the server IP and running the containers previously pulled.

#change permissions on /usr/local/docker/nbi
chmod -R 777 /usr/local/docker/nbi

#set IP address as variable
IP=$(ifconfig enp0s3 | awk '/inet / {print$2}')
echo $IP

#run docker containers 
docker run -d \
  -v /usr/local/docker/nbi:/nbi \
  --name web \
  --restart=always \
  -p 0.0.0.0:80:80 \
  macadmins/netboot-httpd

docker run -d \
  -v /usr/local/docker/nbi:/nbi \
  --name tftpd \
  --restart=always \
  -p 0.0.0.0:69:69/udp \
  macadmins/tftpd

docker run -d \
  -v /usr/local/docker/nbi:/nbi \
  --name bsdpy \
  --restart=always \
  -p 0.0.0.0:67:67/udp \
  -e BSDPY_IFACE=eth0 \
  -e BSDPY_NBI_URL=http://$IP \
  -e BSDPY_IP=$IP \
  bruienne/bsdpy:1.0

We can run the script again and at this point, if it was already run before you will notice that Docker is checking for any updates to the containers. You can verify that the containers are running with:

docker ps -a

The only thing left to do is to upload a nbi to the directory /usr/local/docker/nbi from your admin machine or a network share where your images are saved

scp -r /netboot/path/netboot.nbi root@netboothost:/usr/local/docker/nbi

Once the image has been uploaded we can restart the containers on the host with the startup script. Then check the docker logs with:

docker logs bsdpy

If everything went well you should see it found your NBI. If you want to keep the logs open while testing a deployment add -f to the command:

docker logs -f bsdpy

That's all. The NetBoot service has now been moved off the Mac Mini and onto a Linux server. Or in my case, I now have a NetBoot server to install OS X in my organization and don't have to rely on installing from USB.

CentOS 6.7 Network Card and VMware ESXi Template

Having a CentOS template in a VMware ESXi environment is not like having a Windows Server template when it comes to networking. There are a few gotchas to getting the network card to function after deploying from a template. This KB  from VMware was helpful in detailing what was needed to get the recently deployed template connected to the network.

Because a templates MAC address changes and the CentOS does not update it automatically we need to get the new address. To do this, right click on the virtual machine and go to "Edit Settings" in the "Network Adapter 1" you will find the new MAC address, make note of the last two octets and open the console of the virtual machine. Now you'll need to edit the ifcfg-eth0 configuration file with either vi or nano. My machine only has vi installed. This is located here:

vi /etc/sysconfig/network-scripts/ifcfg-eth0

edit the HWADDR to reflect the new MAC address, save the file and exit.

The next step is to edit the 70-persistent-rules file. This is another configuration file for the network interfaces in CentOS. To edit the file:

vi /etc/udev/rules.d/70-persistent-net.rules

On my virtual machine there were three lines with an eth0 configuration. I removed all but the one that was current with the new MAC address, which is usually the one at the end of the file. After editing, the file was saved and the virtual machine was rebooted. When logging in, the new network card was up and connected to the network.

Remotely Enable Windows Remote Desktop

In my organization, Windows Remote Desktop (RDP) is enabled by either Group Policy or Microsoft System Center Configuration Manager (SCCM). Recently there was a case where I moved some machines around in Active Directory, and SCCM did not update all the machines in their device collection query. In part, it disabled RDP on a number of machines. This was nothing critical, but just kept a few users from accessing their desktop while working remotely from home or on the road.

This post is going to guide you on enabling RDP from another computer. There are a few caveats to this, you need to be in a domain environment and be in the administrator group of the machine. This can be done with having the local administrator account on the machine enabled as well but that requires a few extra steps. You will also need to be on the same network as the computer you are trying to access, and you also need to download a copy of PsExec from the Windows SysInternals Suite.

Once you have downloaded PsExec find where it is and move it to either the root of the C:\ or a subfolder. (I like to keep all theses under C:\Tools). Run this command to open a remote command prompt on the remote computer

c:\tools\psexec.exe \\remote_computer cmd

If the firewall is not disabled via group policy than to disable it run:

netsh advfirewall set currentprofile state off

If you don't want to disable the firewall completely, you can set a rule for remote desktop that allows it through the firewall with:

netsh advfirewall firewall set rule group="remote desktop" new enable=Yes

But if you are in a domain setting, it is better to have Windows Firewall turned off for management of the machine and have a separate firewall that is at your gateway. After you have done this, you can start the Remote Registry Service via the MMC (Control Panel > Administrative Tools > Services), right click on "Services (Local), choose "Connect to another computer" and enter the name of the remote computer. Find the "Remote Registry" Service and start it. But leave the startup type to Manual, you don't really want this to be running all the time for security reasons. Leave this window open because we'll need it in a moment.

Now, open regedit and connect to the Remote Registry and enable RDP. Goto File > Connect Network Registry and enter the name of the remote computer and connect to it. Expand HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server and change the value of "fDenyTSConnections" from "1" to "0"

Go back to the Services window of the remote computer and find the service called "Remote Desktop Services" and start it, or if it is already running right click and restart the service. Now, you should be able to connect to a remote desktop session of the computer. If you have any problems, then you may want to check your firewall settings because local administrators should have permissions to connect on a fresh install of windows.

**Check the rest of the Windows Sysinternals Suite for more nifty tools.