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 with the API using 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.
How could a filesystem corruption happen? There are a couple of likely causes to it:
Kernel bugs: they are infrequent but they also did happen many times in the past and will still happen in the future. Not many things to be done about them, other than applying patches / keeping the kernel up to date;
Memory issues, e.g. memory errors propagated to the file system in control structures: they are usually mitigated with ECC memory but they can never be ruled out;
Underlying storage issues: quite unlikely but nevertheless possible;
Using the reset button on running servers: journaling file systems are almost always able to recover from such incident;
RAID controller issues: this could be the leading cause and not be easy to mitigate, even if firmware upgrade is sometimes possible.