You don’t get to explicitly use Linux namespaces very often; one usually gets to make use of them when setting up containers or some sort of smart web hosting platform that allows hard resource limits to be put in place for customers, but even then the actual setup is hidden somewhere in the back. There are scenarios when containers simply require too much work for the particular task; I, at one time, faced the need of ensuring some network communication between 2 instances of the same service.
Communication? Same service? Have them listen on different addresses or on different ports and you’re done, you might say – but it’s not always that simple. If you have no control over the code but just want to replicate a certain behavior, there may simply not be an option to have instances listen on different ports. If the protocol also involves broadcasting, things become really complicated, as you don’t always have 2 IP addresses, on different interfaces, connected to the same network. Such scenario is easy to solve with virtualization or containers, but for this particular problem they’re overkill. The lightweight solution comes from manipulating Linux network namespaces.
While a public yum repository is easy to set up with S3, going private is more difficult. The privacy must be enforced by some plugin that can retrieve files from the S3 bucket using the API with stored credentials (maybe). Storing credentials can be avoided on EC2 machines that are assigned a proper role, but this is not possible in any other scenario.
Nevertheless, the first steps are common for both public and private setups:
1. Create the proper directory structure
This is achievable with the “createrepo” binary that can be installed on both RedHat and Debian-based systems (e.g. Fedora/Centos or Ubuntu). Running this program results in a “repodata” sub-directory being created with a couple of files that store parsed rpm information.
2. Sync the local repository with the S3 bucket
Going back in time to early 2000s, one can find a lot of businesses on “web hosting” or providing services directly from bare-metal servers. After all, the “cloud” only became a thing and gained traction in the last 5 to 10 years. Many such businesses survived to present day.
What was (and in many scenarios still is) the reality of being able to provide services from a colocated or on-premises bare-metal server?
The physical server had to be purchased before anything else; there were requirements on the enclosure size that sometimes prevented consumer-grade hardware from being used;
The operating system had to be installed by hand, from installation media;
The configuration was a tedious process, with many details being fixed throughout the days after going live.