Some intense months later, here I am with fresh ideas and happenings. Secrets follow. Well no, not really, but I’ll put everything in a list to make things easier to digest.
1. Getting in is hard, staying in seems even harder
When the commercials go out, the movie starts: the interview and then the orientation do not prepare you for the environment you’ll be swimming in, once you start your daily work. On my path to illumination I have realized that kitchen personnel, the people that cook that good food for you 3 times a day, are likely to be evaluated on par with the people they are feeding. At the end of the day nobody is getting any free meal.
I’ve also found out that the photos floating around the interwebs with colorful interiors, pool tables, arcades or pinball machines straight from the ’80s are true. What I have also learned is that an unhealthy balance between productivity and time spent having fun in the games room or sleeping in the library will lead to a PIP (performance improvement plan) before your 1st anniversary. Failing that is obviously your ticket out, but some people also choose to leave on their own terms. For the company the outcome is the same, though: a lifetime (maybe) “no rehire” stuck in your file.
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.