I’d previously been using the Docker driver with Kitchen CI and kitchen-ansible to test my Ansible playbooks. I really like using Kitchen CI. Test-driven infrastructure development! Regression testing! It’s great.
There were several reasons I decided to switch from the Docker driver to Vagrant. My target hosts are all either VMs or bare metal servers, so Vagrant VMs more closely resemble that environment. In particular, there are a couple areas where Docker containers don’t perform well for this purpose:
I’m looking at starting another blog at impractical.bot, as a home for my impractical chatbots. I thought I should check out a blog software other than WordPress, since all of my infosec colleagues make fun of me for using it. One option on my list is Jekyll, which builds static sites. That’s great if you are worried about resources (i.e. super-cheap hosting) and security.
The Jekyll site includes a 4-step quickstart. Unfortunately, it failed for me at step #1:
Error installing jekyll, failed to build gem native extension
I’m running this on a Fedora 27 virtual machine that I spun up for testing Jekyll:
I had been using the Python socket module to create a very basic client-server for testing purposes, but soon I wanted to have something slightly more standard, like an HTTP server. I decided to try the Python Flask framework.
First I set up a Flask server on a CentOS 7 Linux VM running on VirtualBox:
Obviously, if you are dealing with a machine connected directly to the Internet, this would be a terrible solution. You’d want to add rules allowing only the hosts and ports from which you expect to receive connections. But for testing communications between my desktop and a virtual host running on it, this seemed like a quick solution.
After those 2 changes, I was able to load the sample “hello” Flask app in a browser:
I have a number of CentOS 7 servers that comprise a FreeIPA domain on a VirtualBox host-only network. Whenever I start a server though, it is liable to pick up an IP address that I’ve already assigned to another server (which is currently powered off) in /etc/hosts.
How do I assign it a specific static IP address?
In CentOS 7, you can use the Network Manager Text User Interface (nmtui) to edit the network settings. Here’s the first thing I tried, which wasn’t quite right:
Edit a connection
Select a connection, e.g. enp0s3
Change from Automatic to Manual
Enter 192.168.56.109/32 for addresses
Enter 192.168.56.255 for the gateway
When I used those settings, it didn’t work. No route to host, etc. I looked at the network interface settings via a different method:
# ip addr show
The brd (broadcast) address listed was the same as my ip address, 192.168.56.109, which was unexpected and probably why it wasn’t working!
I ran nmtui again and changed the address from 192.168.56.109/32 to 192.168.56.109/24 and it worked.
Since the /32 is interpreted as the subnet mask, it created a subnet with an address range of 1, and the broadcast address would be the same as the ip address. Specifying a subnet mask of /24 creates a subnet with 256 addresses, and a broadcast address of 192.168.56.255 (the same as was listed for the other machines on the virtual network that were using DHCP).
I’ve been testing FreeIPA on a small network of CentOS 7 hosts (all virtual machines running in VirtualBox on a host-only network). After installing the IPA server on one host and creating the realm (IPA.OSRIC.NET), I installed the IPA client on one of the other hosts and tried running kinit:
# kinit admin
kinit: Cannot contact any KDC for realm 'IPA.OSRIC.NET' while getting initial credentials
Searching for that error brought me to Kinit won’t connect to a domain server. Although that did not describe the same issue, it did point me to the /etc/krb5.conf file. The realms section looked like it was missing something:
The name or address of a host running a KDC for that realm. An optional port number, separated from the hostname by a colon, may be included.
I’m a Kerberos novice, but that seems like a necessary property. I’m not sure why the IPA client setup did not include it. I have a few more virtual machines to install the client on, so I’ll soon find if that behavior is consistent on subsequent installations.