This post has been sitting in my drafts folder for quite some time now. It was easier to set everything up than to find spare time to do a write-up.
What’s the Big Idea?
While studying for LPIC and RedHat certifications, I always had a need to test different things on various Linux platforms in order to learn how they work (or don’t). At some point this has become fairly frustrating due to haphazard management, and I came up with a brilliant at the time idea of setting up my own home lab environment where I could easily provision new virtual machines to play around with.
Why Linux Home Lab?
Simply because the host OS that runs virtualisation is CentOS Linux, and guests that I use are Linux systems as well. However, don’t get yourself confused, this home lab can be used to run *BSD, Debian, Solaris or Windows guests too.
Well. Some people say Porsche. Some people say Porsh-uh. I don’t choose sides. I let the car do the talking. OK. Fine. I say Porsh-uh. It’s longer. Better chance someone will overhear me talking about it. Porsh-uhhhh.
I stuck with Oracle VirtualBox many years ago, although nowadays I also use the Xen Project Hypervisor and KVM (Proxmox). It does the job well, is cross-platform, easy to set up (type 2 hypervisor) and software is free of charge. A personal preference for my home environment, I guess.
You can get one of those 1TB USB 3.0 military-grade shock resistance portable hard drives, get it fully LUKS encrypted, put NTFS filesystem on top and use with VirtualBox on both Linux and Windows computers. You’ll need FreeOTFE or LibreCrypt for Windows, it works fine on Windows 7, but I didn’t test with any other version, so YMMV. You end up having all of your virtual machines stored on an encrypted portable disk, with USB 3.0 giving a fair amount of speed to run multiple VMs simultaneously.
Needs for the Home Lab
I need a home lab where I can provision and run multiple Linux (mainly CentOS) boxes for various testing purposes (web, database, proxy, email, LDAP etc.) even when there is no Internet access available. This, however, must not prevent me from installing packages on any of those virtual machines.
All virtual machines have to reside on a single local area network (LAN) so that they can communicate with each other assuming that local firewall (iptables, firewalld) is configured to permit this.
Moreover, there needs to be a central management server on the LAN so that I don’t have to configure basic things like addresses or DNS on newly provisioned machines myself. The central management server should, at least, do the following:
- Act as a DHCP server to provide leases for DHCP clients.
- Act as a DNS server (with internal zones).
- Act as an NFS server for file sharing.
- Provide NTP services for time configuration and sync.
- Contain a local repository of packages available to clients. I’m talking about Spacewalk here.
- Work as a mail relay so that clients can send emails out if required.
- Apply some basic security configuration to clients. This includes firewall configuration, SELinux, Linux security limits, kernel sysctl configuration etc.
- Ideally, provision clients as a database or a web server, depending on their role. I’m talking about Puppet here. This can then be extended further.
All virtual machines have to have an easy access from the PC they are hosted on. I’m referring to the Host-only VirtualBox networking mode.
Home Lab Networking
The network schema for the home lab is very basic. It can be seen below.
VirtualBox LAN is on 10.8.8.0/24. This is a Host-only network (see https://www.virtualbox.org/manual/ch06.html) with a VirtualBox built-in DHCP server disabled.
There is a Puppet management server, that has two network interfaces: eth1 is a Host-only network with a static IP address of 10.8.8.2, eth0 is a NAT network for Internet access. Other servers are test boxes used for illustrative purposes only. They all have an eth0 Host-only network adapter attached (with no Internet access) and get IP leases from the Puppet DHCP server. By design, the only server that can access the Internet is the master Puppet server.
Optionally, the Puppet server can be configured as a router to provide Internet access to other virtual machines.
Check this blog post for how to configure Linux server as a router.
CentOS Template and The Master Server
UPDATE: as of April 2016, my home lab is on CentOS 7. The set up is practically the same, the major difference is that you need to replace service/chkconfig with systemctl, and use firewalld (or disable it and use iptables).
The way I see it all working is quite simple. There is a CentOS 6.7 (minimal) VirtualBox template created with a Spacewalk client already installed. I should update to CentOS 7 at some point, I know. Eventually. Moreover, the template has a Puppet agent deployed with a default server role that is pre-defined (check Part 7 for more details on server roles).
There is a Puppet master server set up, that acts as a Puppet master (surprise surprise), plus contains Spacewalk for software content management. On top of that, the server provides DHCP, DNS, NTP and SMTP relay services to clients.
When a new virtual machine is manually provisioned from the CentOS template, it boots up and gets an IP address lease from the DHCP server. Then with a bit of manual work, I can SSH and get the VM registered with Spacewalk, and run a puppet agent test. This will then push NTP, SMTP etc. configuration from the Puppet master. You get the idea. And there is much more that could be automated.
Setting up the Management Server
The main emphasis here is put on setting up the management Puppet server. The whole lab environment is deployed on my laptop. It’s an octa-core (VT-x, VT-d) machine with 12GB of RAM and a second HDD installed to store VirtualBox images.
The Puppet server has the following specs:
- 2 CPU cores
- 6GB of RAM
- 4GB swap
Once the CentOS template and the management server are created, I can use the lab pretty much anywhere I go, even with no Internet access.
I do have VirtualBox 5 with a GUI installed on my machine, however, the first part that covers VirtualBox setup is dedicated for a headless machine (no GUI). This is for advanced users as we all know how easy it is to install VirtualBox on a GUI based machine, don’t we?
Below is the list of steps that leads to the creation of the management server.
Part 1: Setup VirtualBox 5.0 on a Headless CentOS 6 Server
Part 2: Setup BIND DNS Server on CentOS 6
Part 3: Setup NTP Server on CentOS 6
Part 4: Setup DHCP Server on CentOS 6
Part 5: Setup Postfix to Relay Mail to an External SMTP Server on CentOS 6
Part 6: Setup Spacewalk 2.4 on CentOS 6
Part 7: Setup Puppet Server with Hiera on CentOS 6
Part 8: Setup NFS Server on CentOS 6