Recently a coworker posted that children born this year would be in Generation Beta, and I was like “What? That sounds like too soon…” but then thought “Oh its just that thing when you get older and time flies by.” I saw a couple of articles saying it again, so decided to look at what was on thewikipedia article for generationsand saw that yes ‘beta’ was starting.. then I started looking at the lengths of the various generations and went “Hold On”.
Wikipedia_graphic
Let us break this down in a table:
Generation
Wikipedia
How Long
T (lost)
1883-1900
17
U (greatest)
1901-1927
26
V (silent)
1928-1945
17
W (boomer)
1946-1964
18
X
1965-1980
15
Y (millenial)
1981-1996
15
Z
1997-2012
15
alpha
2013-2025
12
beta
2026-2039
13
gamma
2040-???
??
So it is bad enough that Generation X,Millenials, and Z got shortened from 18 years to 15.. but alpha and beta are now down to 12 and 13? I realize that this is because all of this is a made up construct to make some people born in one age group angry/sad/afraid in another by editors who are needing to sell advertising for things which will solve the feelings of anger, sadness, or fear.. but could you at least be consistent.
I personally like some order to my starting and ending dates for generations so I am going to update some lists I have put out in the past with newer titles and times. We will use the definiton as outlined at https://en.wikipedia.org/wiki/Generation
A generation is all of the people born and living at about the same time, regarded collectively.[1] It also is “the average period, generally considered to be about 20–30 years, during which children are born and grow up, become adults, and begin to have children.”
For the purpose of trying to set eras, I think that the original 18 years for baby boomers makes sense, but the continual shrinkflation of generations after that is pathetic. So here is my proposal for generation ending dates outside. Choose which one you like the best when asked what generation you belong to.
Generation
Wikipedia
18 Years
T (lost)
1883-1900
1889-1907
U (greatest)
1901-1927
1908-1926
V (silent)
1928-1945
1927-1945
W (boomer)
1946-1964
1946-1964
X
1965-1980
1965-1983
Y (millenial)
1981-1996
1984-2002
Z
1997-2012
2002-2020
alpha
2013-2025
2021-2039
beta
2026-2039
2040-2058
gamma
2040-???
2059-2077
(*) I say wikipedia here, but they are basically taking dates from various other sources and putting them together.. which should be seen as more on the statement of social commentators who aren’t good at math.
I recently moved a home server from Fedora Linux 41 to CentOS Stream 10. The reason
for the move was not related to Fedora, but due to a series of hardware
failures on a 4 year old server. The internal NVME died and the 2 SSD
drives I had as a raid array for running virtual guests, mock builds and
other things started reporting SMART errors. With the recent release of
CentOS Stream 10, and most of my day work going to be related to it, I
figured it was time to buy some replacement drives and install a new
operating system.
While doing this reinstall, I saw other people were running into
issues and posting on mailing lists and forums for help. I figured I
would try to collect all the info in one place and see if it would help
people.
Problem 1: Old Hardware
Problem Description
You have tried to install CentOS Stream 10 on your system which ran
previous versions of CentOS without problems. However now the system
will crash at different points in the install or not boot at all during
the media. Re-cutting the ISO or other items does not fix the issue.
Why is this happening?
The issue is due to CentOS Stream 10 only supports hardware that has
the x86-64-v3instruction
set. This is an instruction set which Intel introduced in 2013 with
the Haswell chip set and AMD added similar instructions in 2015. Sadly,
Intel did not introduce the full instruction set to all their sold CPU’s
after 2013, so there are various ‘low end’ Atom and similar Cups built
from 2013 to maybe 2020 which will not work.
The reason for the change in instruction sets comes down to Red Hat
Enterprise Linux being aimed at data center hardware which
‘theoretically’ gets replaced on a 8 year life cycle. Owners of this
newer hardware usually want to use the hardware as much as possible so
want libraries and tools to use the newer instructions. There is also
the fact that supporting older hardware with newer code becomes harder
and harder running anything from manufacturers no longer giving driver
updates to the general problem of newer software using more memory and
CPU cycles. People with older hardware are generally going to need to
stick with CentOS Stream 9 until it reaches its EOL in early 2027 or
move to another operating system which is aimed to support older
systems.
What can I do?
This is a fundamental instruction set change. The only fixes are to
buy newer hardware, stay on an EL clone of 8 or 9, or move to a
different operating system.
Problem 2: Server Going
to Sleep Problem
Problem Description
The system was installed with the default ‘Server with GUI’ and after
the install completes the system goes into ‘deep sleep’ mode after no
activity on the GUI console. This may only occur after a user has logged
in one time to the server console, but may also happen without any user
interaction.
Why is this happening?
My first worry was that the system had died, but when pressing a key,
the system power back up from a low powered state. Doing a search for
bugs, I ran into problems with Red Hat’s https://issues.redhat.com
search capabilities and ended up looking through stack overflow and
other places. The issue seems to be that the default GNOME settings
assume that this is either a ‘desktop’ or ‘laptop’ which when not in
constant use will want to sleep to save power. This is not a useful
setting for a 24x7 server, and neither was the fact that the GUI
settings to turn this off mentioned on the GNOME pages did not seem to
exist in the version of GNOME shipped in the current CentOS Stream 10
(2024-12-30).
What can I do?
Doing some other searches I was able to cobble together some command
line options which turned off the settings.
## Set the inactive sleep to 0 when there is power to the
## system.
$ sudo -u gdm dbus-run-session gsettings \
set org.gnome.settings-daemon.plugins.power \
sleep-inactive-ac-timeout 0
## Do the same for the main user
$ dbus-run-session gsettings \
set org.gnome.settings-daemon.plugins.power \
sleep-inactive-ac-timeout 0
I am expecting that this will be reported to Red Hat at some point
and can be fixed in the install settings so new users won’t have this in
the future.
Problem 3:
Continuous prompt error mentioning EPEL
Problem Description
After enabling an external repository like the EPEL-10, the system
will continually pause during shell entries and give an error like:
Failed to search for file: Failed to download gpg key for
repo 'epel': Curl error (37):
Could not read a file:// file for
file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever_major
[Couldn't open file
/etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever_major]
Why is this happening?
This problem occurs because of two helpful changes coming into
contact with each other.
The first helpful tool is that the various shells in CentOS Stream 10
come with helpers which will catch ‘command not found’ and try to figure
out if you mistype it:
vm
bash: vm: command not found...
Similar command is: 'mv'
or if you need to install an additional package set from a
repository. This can be helpful even on systems which are controlled by
a tool like puppet or ansible as sometimes
something expected was just missed on the system.
The second helpful change is that a much used additional repository
EPEL is trying
to fix a reoccurring problem with EL releases. Since the release of EL8
in 2019, Red Hat has been doing a major release every 3 years and around
10 minor releases per major release every 6 months. In a change with
earlier Enterprise Linux, where major re-bases did not happen that much,
each minor release may see one or more subsystems upgraded or ‘aged out’
as what Red Hat call’s an application stream is no longer supported.
This is useful for systems which find they need a newer python for some
reason but still be on an older base operating system. However this is
also hard for people using external software which may no longer have
base libraries needed.
In order to fix this, EPEL has decided that for EL10 they would build
software CentOS Stream 10, and then branch every minor Red Hat
Enterprise Linux 10.x release with updates and changes which match what
is in a particular minor release. If a system administrator has decided
that a system needs to stay on 10.2 even after 10.3 is released, they
will be able set a variable which will keep EPEL working without having
to mirror a version from the Fedora archives. Other repositories like
rpmfusion should be able to do this also.
The problem is that the helper is not able to parse the new format of
the EPEL release files and so isn’t filling out the variable
$releasever_major. Because it is failing, the package cache
looks to be invalid so it tries to renew the cache EVERY time. This
becomes maddening if you have a shell prompt which is looking for a
‘command’ which hasn’t been installed on the system yet. My shell has an
additional helper looking for git and and such. It manipulates the
PS1 variable and so every command was giving me an error,
then a long pause and the repeated line about unable to download the gpg
key.
What can I do?
The command lookup helper in question comes with the GNOME
PackageKit. This may take a while for it to be updated to understand the
new repository environment $releasever_major so at the
moment, I suggest getting rid of the helper.
$ sudo dnf remove PackageKit-command-not-found
Updating Subscription Management repositories.
Unable to read consumer identity
This system is not registered with an entitlement server.
You can use subscription-manager to register.
Dependencies resolved.
Any shells currently in use may need to restart or resource their
.profile in order to stop erroring.
Problem 4:
Unwanted Subscription Manager Messages
Problem Description
Whenever a dnf command is given, there is a warning
printed out saying:
[root@xenadu etc]# dnf update
Updating Subscription Management repositories.
Unable to read consumer identity
This system is not registered with an entitlement server.
You can use subscription-manager to register.
Why is this happening?
This warning comes from the fact that CentOS Stream is the ‘upstream’
of Red Hat Enterprise Linux and in being that there is a desire to make
the two install as similar set of packages as possible for testing.
However in the case of ‘subscription-manager’ this is a tool which isn’t
useful for a CentOS system since subscribing it to the Red Hat
entitlement systems is not needed.
What can I do?
This problem is solved by removing a set of subscription manager
packages from the box:
[root@xenadu etc]# dnf remove subscription-manager*
Updating Subscription Management repositories.
Unable to read consumer identity
This system is not registered with an entitlement server.
You can use subscription-manager to register.
Dependencies resolved.
===============================================================
Package Arch Version Repository Size
===============================================================
Removing:
subscription-manager x86_64 1.30.2-2.el10 @anaconda 3.7 M
subscription-manager-rhsm-certificates
noarch 20220623-6.el10 @anaconda 27 k
Removing dependent packages:
insights-client noarch 3.2.8-2.el10 @AppStream 1.4 M
Removing unused dependencies:
libdnf-plugin-subscription-manager
x86_64 1.30.2-2.el10 @anaconda 44 k
python3-cloud-what x86_64 1.30.2-2.el10 @anaconda 156 k
python3-decorator noarch 5.1.1-12.el10 @anaconda 77 k
python3-iniparse noarch 0.5-10.el10 @anaconda 124 k
python3-inotify noarch 0.9.6-36.el10 @anaconda 302 k
python3-librepo x86_64 1.18.0-3.el10 @anaconda 187 k
python3-subscription-manager-rhsm
x86_64 1.30.2-2.el10 @anaconda 548 k
Transaction Summary
===============================================================
Remove 10 Packages
Freed space: 6.6 M
Is this ok [y/N]:
If you try to go to the CentOS
Forums, you will instead be directed to the status page. The CentOS Forums is
sadly one of the resources that went away the the end of CentOS Linux 7.
The system was a classic PHP web-forum which had been run for over a
decade by volunteers as a resource for the CentOS Community. Due to its
age, and its usefulness, there have been several requests to get it back
up and working. However, it looks highly unlikely for several
reasons:
The service was not actually ‘owned’ by the CentOS Project. It was
set up and run by various volunteers who were associated with the
project but was never a ‘core’ part of the project. So when Red Hat
‘bought’ CentOS in 2014, this service was not part of that merger.
The volunteers who were running the service mostly left after CentOS
Linux 8 was end of lifed earlier than thought on 2021-12-31. Many in the
community had thought the operating system would have a 10 year lifetime
like earlier releases, but Red Hat decided in 2021 to focus only on the
CentOS Stream versions.
The remaining volunteer announced that they would only support the
system until the end of CentOS Linux 7 in 2024. Announcements were put
on the forums that the service would be going away.
The contents of the forums could not be transferred to the CentOS
project (aka Red Hat) because the contents were never licensed under a
license which would allow for it. Basically any post on the forums was
under the copyright of the poster and possibly licensed to be viewed on
that forum only. Moving the posts and documents on the forum would have
required getting the permission of every individual poster where many of
them may no longer be contactable.
Various parts of the database are also covered by the GDPR, ‘Right
to Forget’ and similar laws around the world. Because again the
licensing of the forum was fairly informal, it was thought that
transfers would need further legal review.
Even putting the service in a ‘read-only’ format would have required
continual maintenance for a PHP code base which would have needed
porting to a newer operating system and toolkit. [Doing dumps and
rewrites for forums tends to end up with unreadable messes unless a lot
of extra time and effort is done.]
Since the remaining volunteer had done this for 4 years and didn’t
want to continue, it was decided to shut off the forums when CentOS
Linux 7 went away. For people who still wanted to discuss issues with
CentOS Stream, the Fedora Project added a section to its discourse
server: https://discussion.fedoraproject.org/c/neighbors/centos/71 which
has seen some traffic (mostly people asking for howtos).
Lessons (Re)-Learned.
The first lesson I have re-learned from this EOL is that the Internet
is ephemeral but operating system needs are forever. I have a very large
list of bookmarks in my browser which are no longer useful but on
checking, I realized that nearly every bookmark over 5 years was also no
longer where it was ‘originally’ pointing to. In some places, some
system administrator has made a redirect (which probably leads to
another redirect and another).. but in many cases the posts are gone
like so many tears in
the rain.
The second lesson I have re-learned is that copyright licenses are
much more important than we give them credence. When setting up a forum
or other group, make sure that you ensure that others can reuse what is
posted and the authors understand the permissions they are granting
others before they post.
The third lesson is when-ever possible make a local copy of things
you find important. If it is under some sort of copyleft, make a direct
copy and keep it in markdown or some similar format for later updates.
If it isn’t permissible, then rewrite it as best you can to make sure
that you know how restore backups on a CentOS Linux 5 system even though
the OS is now end-of-lifed for over 7 years.
This post is meant for the various junior system administrators who
have been tasked with fixing problems with CentOS 7 systems after the
software was removed from most of its mirrors. Most of these systems
have probably been running fine for a decade, and now possible critical
systems are generating failed cron jobs or other errors.
What happened?
On July 1st, 2024, CentOS Enterprise Linux 7 reached its end of life
as its upstream, Red Hat Enterprise Linux 7, had moved to Extended
Life(cycle) Support. As with previous releases, the operating system was
moved from the main mirrors to the CentOS vault, and the mirrorlists
were turned off. Once the software was removed from the main mirrors,
many secondary mirrors also removed the software as rsync and similar
scripts would see the old software was gone. At this point, some unknown
number of CentOS Linux systems ended up ‘non-supported.’
The systems may have been extremely low maintenance for years running
whatever tasks they had been without a problem. The people who initially
set them up have probably moved to other jobs, and some new person is
now finding out that things are broken. Maybe its a cron job which runs
one a week to run updates, or the kickstart used to reinstall an old
server now breaks. In most of these cases, there is little documentation
on what is being used, why it is being used, or how big a problem this
is going to be.
What is needed to be done?
Getting an infrastructure out of this place is really out of scope of
a single blog post. It generally requires getting various levels of
managements attention, and then long term planning on how to transform
an infrastructure into something more manageable. However in the short
term a site can make things workable by making a local mirror of content
from an upstream vault.
The reason to use a local vault is that the existing upstream vaults
are limited in bandwidth and scope. Plus as more sites try to use them,
the services may be curtailed or removed. When dealing with ‘End of
Life’ projects and software, it is better to assume that things will get
worse before they get better.
Hardware and software
requirements
In order to mirror CentOS 7 locally, you are going to need to set up
a webserver with at least 500 GB of free space (if you don’t want to
copy the out of date ‘atomic’ trees. ) The amount of memory and cpu
cores needed is dependent on the number of servers you are going to be
supporting. The more systems, the more memory and cores that might be
needed. In any case, I was able to set up a system with 2 cores and 4 GB
of ram to support 4 EL7 systems without problems.
Internet requirements
There are currently 3 major mirrors of the CentOS vault.
archive.kernel.org
linuxsoft.cern.ch
mirror.nsc.liu
It is best to find one which is ‘network’ close and set up scripts to
rsync data from the site. I found that each server will be busier at
different times, so expect that copying will take multiple hours.
In my /etc/httpd/conf.d/ I added the following config
file:
Alias "/mirrors" "/srv/mirrors"
<Directory /srv/mirrors>
AllowOverride None
Require all granted
Options +Indexes
</Directory>
Sample Yum repo config
Finally on the EL7 systems, I used a config like the following in
/etc/yum.repos.d/CentOS-EOL.repo
[base]
name=CentOS-$releasever - Base
baseurl=http://192.168.1.150/mirrors/centos-vault/7.9/os/$basearch/
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
#released updates
[updates]
name=CentOS-$releasever - Updates
baseurl=http://192.168.1.150/mirrors/centos-vault/7.9/updates/$basearch/
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
#additional packages that may be useful
[extras]
name=CentOS-$releasever - Extras
baseurl=http://192.168.1.150/mirrors/centos-vault/7.9/extras/$basearch/
gpgcheck=1
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
[centosplus]
name=CentOS-$releasever - Plus
baseurl=http://192.168.1.150/mirrors/centos-vault/7.9/centosplus/$basearch/
gpgcheck=1
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
At this point, updates were possible and I was able to reinstall a
system in order to rebuild some packages I needed. Similar work can be
done to set up mirrors of CentOS Linux 6 or third party repositories
like EPEL.
The Red Hat Enterprise Linux release cycle is fairly straight forward
with releases lasting about 10 years after their initial release.
RHEL ver
Release Date
EoMaint
EoExtended
5
2007-03-15
2017-03-31
2020-11-30
6
2010-11-10
2020-11-30
2024-06-30
7
2014-06-10
2024-06-30
2028-06-30
8
2019-05-07
2029-05-??
2031-05-??
9
2022-11-08
2032-05-??
2034-05-??
10
2025-??-??
2035-??-??
2037-??-??
On June 30, 2024, Red Hat will stop doing general maintenance support
of RHEL-7 and no more updates to that operating system will be available
without purchasing ‘Extended Life-cycle Support’ contracts from Red
Hat or similar contracts from SuSE’s Liberty
Linux, Perforce’s
OpenLogic, or various other consultants and companies offering
various services.
What is happening to EPEL-7
The Fedora Extra Packages for Enterprise Linux (EPEL) is a repository
of additional packages built against the Red Hat Enterprise Linux (RHEL)
releases. When a RHEL release leaves maintenance mode and moves into
‘Extended Life-cycle Support’, the EPEL package set corresponding to
that is closed and archived. No new builds or updates are done against
that particular release, all bugs related to that release are closed as
CANTFIX, and most mirrors will remove the content after the master
mirror moves items to archives.
The usual process for closing out an EPEL release depends on how much
work the central Fedora release engineering team have to deal with at
the time of the RHEL EOL. In cases where a Fedora release is needing a
high amount of focus, the only actions may be that new builds will be
turned off on the day of the EOL, and then later other steps will be
worked out. In other cases, all the actions occur fairly close
together.
A reminder email that the EOL is going to occur is sent to various
Fedora mailing lists like:
devel-announce@lists.fedoraproject.org and
epel-announce@lists.fedoraproject.org. System
administrators using EPEL should be following at least the second email
address to see what issues may be occurring with the repository.
The Fedora Build system is a complicated tool-set and so Release
Engineering have to disable the building and composing of that
particular EPEL release in multiple places. Because the release cycle is
so long for EPEL compared to Fedora releases, there may be
inconsistencies in how things were named or done. Basically it is a
slower process than with Fedora releases to make sure that the tools
continue to work after an EOL.
All bugzilla.redhat.com bugs related to that release will be closed
with a short stock answer tailored for that release as ‘CANTFIX’.
The release is now copied into the Fedora down-loaders
/pub/archive/epel tree with an appropriate name like
/pub/archive/epel/7.9.2024-07-01 and then symlinks are
made. A week is given for the archive mirrors to catch up with this new
directory tree.
The Fedora mirrormanager will be changed to point requests for
‘repo=epel-7’ to the mirrors which have /pub/archive.
The content then will be removed from the main mirror locations of
/pub/epel/ and mirrors who rsync will catch up to that in a
day or so.
Usually about a week to a month after this happens, either the
mailing lists or IRC will get people wondering where the content went.
However in the current age of Continuous Integration and Container
builds, changes in the EPEL-7 directory structure seem to cause
reactions hours after they occur.
How to deal with this EOL.
The main advice I have for system administrators dealing with an End
of Life operating system is the following:
Mirror the content locally from whatever mirrors you can find. This
lowers network bandwidth usage, and deals with the vagaries of archive
sites removing content because they no longer can handle the load from
large numbers of unexpected users.
Work with your management on how to deal with the technical load
that these systems are going to cause.
Budget out what extended maintenance costs for critical security
fixes to services like web-servers, databases, remote logins, etc are
going to take.
Budget out what mitigations are going to be required to keep these
systems from causing longer term headaches. This may be extra firewalls
or additional staff needed to take over software maintenance.
Budget out what replacements of the hardware and software to move to
an operating system which has long term maintenance support.
Actually this is a very long list and probably should be its own
blog post.
End Thoughts
Dealing with End of Life software is rarely an easy task. Just
realize that you aren’t alone and there are tens of millions of systems
which are going to be ‘unsupported’ on July 1st. Be patient with
yourself and your infrastructure as you deal with this. Good luck.
I am writing this on 2024-06-20 which means according to the IRC
centbot:
centbot: CentOS 7 will go EOL on 30 June, 2024 -- in 1 week,
10 hours, 22 minutes, and 41 seconds.
The CentOS Systems Administrator, Fabian Arrotin, has posted several updates
about what to expect starting Monday Jul 1st, 2024. The
first email
covers what services will stop after the 'End of Life' occurs:
mirrorlist.centos.org will be decommissioned. This will affect any system trying to do a `yum update` or similar command after that date.
forums.centos.org
will be turned off and decommissioned. This was a volunteer effort by various system administrators who are ending their work with CentOS at the end of 7.
torrent.centos.org
will be turned off and decommissioned. This was useful for putting out new isos, but was no longer done for the CentOS Stream project.
Removal of mirrorlist will probaby cause various cron jobs and similar tools to stop working. Manual work will be needed to either turn off the CentOS repos affected in /etc/yum.repos.d/ files or something similar. The loss of forums will mainly affect people looking for answers for problems with EL7 and before systems. Similar answers may be available at stackoverflow or similar sites.
Fabian's second email covers what systems mirroring CentOS Linux 7 can expect and when.
First it reiterates that all EL7 content from mirror.centos.org will be removed. Also that the mirrorlists will be turned off and no longer answering.
Second crawlers will be turned off to see what mirrors are 'up-to-date' with EL7 content as the release is over.
Third, the head rsync mirrors will continue to exist, but will only have an 'empty' filelist on it. This will cause all mirrors which do an rsync with --delete flags to remove all EL7 content from their mirror. This is normal for end of life releases as disk space needs to be used for other content.
The biggest issues that system administrators with EL7 systems need to be ready to do are the following:
Be prepared that existing scripts and tools pulling in EL7 content will break without work.
If you are mirroring EL7 content, and need to keep it, you need to check that the rsync scripts do not delete content which is no longer on the mirror. If you are using reposync or similar commands you will need to look for similar options.
You should look at mirroring the content local to your site until your organization has a transition plan to another operating system.
You should work with your management and financial resources on a transition plan if you haven't already.
ADDENDUM (2024-05-30T01:08+00:00): Multiple Amazon engineers reached out after I posted this and there is work on identifying what is causing this issue. Thank you to all the people who are burning the midnight oil on this.
ORIGINAL ARTICLE:
So starting earlier this year, the Fedora mirror manager mailing list started getting reports about heavier usage from various mirrors. Looking at the traffic reported, it seemed to be a large number of EL-7 systems starting to check in a lot more than in the past. At first I thought it was because various domains were beginning to move their operating systems from EL-7 to a newer release using one of the transition tools like Red Hat LEAPP or Alma ELevate. However, the surge didn't seem to die down, and in fact the Fedora Project mirrors have had regular problems with load due to this surge.
A couple of weeks ago, I finally had time to look at some graphs I had set up when I was in Fedora Infrastructure and saw this:
Cumulative EPEL releases since 2019
Basically the load is an additional 5 million systems starting to query both the Fedora webproxies for mirror data, and then mirrors around the world to get further information. Going through the logs, there seems to be a 'gradual' shift of additional servers starting to ask for content when they had not before. In looking at the logs, it is hard to see what the systems asking for this data are. EL-7 uses yum which doesn't report any user data beyond:
urlgrabber/3.10 yum/3.4.
That could mean the system is Red Hat Enterprise Linux 7, CentOS Linux 7, or even Amazon Linux 2 (which is sort of based on CentOS 7, but with various changes that using EPEL is probably not advised).
Because there wasn't a countme or any identifiers in the yum code, the older data-analysis program does a 'if I see an ip address 1 time a day, I count it once.. if I see it 1000 times, I count it once.' This had a problem of undercounting for various cloud and other networks behind a NAT router.. so normally maybe only 1 ip address would show up in a class C (/24) network space. What seemed to change is where we might only count one ip address in various networks, we were now seeing every ip address showing up in a Class C network.
Doing some backtracking of the ip addresses to ASN numbers, I was able to show that the 'top 10' ASNs changed dramatically in March
I am not sure what changed in Amazon in March, but it has had a tremendous impact on parts of Fedora Infrastructure and the volunteer mirror systems which use it.
