Hosting companies have to be more in this day and age. In the hosting world, the types of products and buzzwords change every year, so running a hosting company becomes less simple over time. Still when we look at which things remain the same, these are the details which become very important. For example, when we asked our techs what task is repetitive throughout their day, there is always one clear answer: OS Installs.
Back in 2016, we announced our very first Automated OS installer. The main goal was to automate installs, not just to improve the time our techs spend on these recurring tasks, but to help customers get things done quicker. We realize that as a growing hosting company, we can’t rely on “one size fits all” software options for our business. This means we have to calculate the value of developing our own. We have to hire programmers, and incorporate different types of skills into our company profile.
You’ll find that our development process for the automated OS installs project took some turns, but ultimately served as a learning experience.
Doing the Math
Before we start any sort of project in-house, we prioritize based on the ROI (return on investment). Automation is important, but requires development resources, so it’s very important to make sure when we automate something, it makes sense both in-house and to our customers. After analyzing a few months’ data, we saw hundreds of hours spent every month (even during slow months) on OS installs and re-installs. Even if we dedicated one year toward this project, it would justify itself in a matter of months!
Trying the Easy Way Out
As re-inventing the wheel can sometimes be very complex and expensive, we did some market research. Prior to starting any serious development, we always see what’s already available and relevant for our project. A quick search revealed a wealth of tools available for automating the OS install process, many of them completely free of charge, and some extremely cost prohibitive. One specific tool stood out to us and was targeted toward the hosting market.
Getting the tool online and integrating it with our system was painless and took roughly a week. It was a great start and saved our techs a tremendous amount of work for basic OS installs. Roughly 200 installs in, we started seeing the limitations. The tool worked flawlessly for simple OS installs, but adding options such as RAID, custom packages, and pre-made scripts wasn’t possible.
With the limitations in hand, we reached out to the software company for enhancements and simple bug fixes that we had encountered with their software. Long story short, the product could not be customized to our needs.
Other tools on the market didn’t have the sort of flexibility and options that we needed. We made the decision to build it from the ground up.
PXE Boot, Kickstart, and Lack of Documentation
Now that we knew that we had to build the OS installer from the ground up, it was time to find information on all of the technologies needed to put together a detailed specification of the software. PXE Boot, or Preboot Execution, was the first piece of the puzzle. A quick web search revealed a great deal of resources available on how PXE works, but very few that go into detail on how the protocol works and what’s required.
Piecing together information from Intel, Cisco, and similar open source software such as TFTPD, we were able to get a spec together for the software requirements.
When a server boots up, one of the options is called a “PXE” or “Network” boot. This boot option allows the server to boot to an OS (or installer) from the network. This is what is supposed to happen:
- The client (target server) sends a DHCP request for an IP.
- The DHCP request is routed by the network to a specific DHCP server.
- The DHCP server then responds back with an IP and additional TFTP information for the boot process.
- The client uses the information received via DHCP to establish a TFTP connection to the TFTP server and pull the necessary files. Based on the client, the TFTP server delivers a specific set of files.
- The install then proceeds.
Getting the installer booted up was only the first of many headaches. Linux based operating systems use a configuration file called “kickstart” and “preseed” to configure the settings for the installer. These files are downloaded by the installer from a HTTP source as soon as the installer boots. After roughly 100 installs (lots of trial and error) we had finally achieved the result we were aiming for: a complete CentOS install, 100% hands off.
Options, Options, Options!
Now that we have a fully operational installer, we have the flexibility of adding software RAID options, custom packages, and most importantly, scripting. Scripting will allow customers to install an OS, and have it automatically configured and secured to perform a specific task without having to spend hours setting everything up by hand. As of 2024, we have continued to update this project. This includes reengineering already developed installers for operating systems, like Ubuntu 20.4, and developing new ones, like Ubuntu 24.
Taking it to the next level
A hosting company is more than a CEO, hardware and its employees. There must be a common goal and a vision of the future. Skills have to be updated and goals must change.
ReliableSite has been around for almost 20 years. We have to ask, what more can we do with the technology we’ve already worked hard to create? When we reached our goal of an automated OS installer, we gained loads of options that helped us and our customers.
As far as ROI goes, our work on the auto-OS installer contributed toward our goal of instant provisioning and bare metal with cloud scaling. We have transitioned all of our services to support instant deploy bare metal servers. That was our vision for more than a decade and now we move forward with improving customer experiences in new ways.